Программно-определяемый подход к хранению данных

В этой статье мы рассмотрим и протестируем новую версию программно-определяемой системы хранения данных (Software-Defined Storage, SDS) Veritas Access 7.3 — многоцелевого масштабируемого хранилища данных на базе обычных серверов архитектуры x86 с поддержкой файлового, блочного и объектного доступа. Наша основная задача — познакомиться с продуктом, c его функционалом и возможностями.

Компания Veritas — это синоним надежности и опыта в сфере управления информацией, владеющая многолетней традицией лидерства на рынке резервного копирования, производящая решения для анализа информации и обеспечения ее высокой доступности. В Software-Defined Storage решении Veritas Access мы видим будущее и уверены, что через некоторое время продукт обретет популярность и займёт одну из ключевых позиций на рынке SDS решений.
В качестве платформы, на которой был создан Access, выступил продукт с давней историей InfoScale (Veritas Storage Foundation), который во времена отсутствия виртуализации был на пике популярности в Highly Аvailable (HA) решениях. И от младшего брата Veritas Access мы ожидаем продолжение истории успеха НА в виде Software-Defined Storage.

Один из плюсов Veritas Access — это цена. Продукт лицензируется по числу активных ядер (примерно 1000$/1 CORE в GPL (global price list)), стоимость совершенно не зависит от количества дисков и общего объема системы хранения. За узлы разумно использовать малоядерные высокопроизводительные однопроцессорные сервера. Грубо говоря, лицензия Access на 4х узловой кластер будет стоить $20 000–$30 000, что на фоне других SDS решений, где стоимость начинается от 1500 долларов за терабайт сырого места в GPL, выглядит очень привлекательно.

Основным преимуществом, которое отличает Veritas Access от Ceph и близких ей по духу SDS решений, является его «коробочность»: Veritas Access — это полноценный продукт Enterprise уровня. Внедрение и поддержка Access не сопряжена со сложностями, которые под силу только специалистам с глубокими знаниями nix SDS систем. Вообще внедрить любое SDS решение — задача не особо сложная, основные трудности возникают в процессе эксплуатации в виде добавление узлов при выходе их из строя, переносе данных, обновлении и др. И в случае с Access все проблемы понятны, поскольку решения описаны еще для Storage Foundation. А в случае Ceph нужно иметь квалифицированный персонал, который сможет оказать специализированную поддержку. Кому-то комфортно работать с готовым решением в виде Access’a, кому-то кажется удобным конструктор Ceph с более гибким подходом, но требующим знаний. Мы не будем сравнивать Access с другими SDS решениями, а постараемся дать небольшой обзор нового продукта. Возможно, он поможет сделать выбор в вопросе, с каким SDS-решением вам будет комфортнее работать.

Для прозрачности тестирования, максимально приближенного к продакшену, мы совместно с коллегами из одного из дистрибьюторов Veritas – компании OCS, собрали на физических серверах пятиузловый стенд: двухузловый кластер в ЦОДе Открытых Технологий и трехузловый в ЦОДе OCS. Ниже будут фотографии и схемы.

File vs Block vs Object Storage

Veritas Access работает на раздачу по всем протоколам, предоставляя файловый, блочный и объектный доступы. Разница только в том, что файловый доступ настраиваться очень легко через WEB интерфейс, а настройка двух других на текущий момент мало описана и сложна.



NFS, S3 работают на узлах в режиме active-active. iSCSI и CIFS в текущем релизе 7.3 работает в active-passive. Сервисы, подключенные по NFS, S3 продолжат работу при выходе из строя любого из узлов, а сервисы, подключенные по CIFS, iSCSI, могут не пережить потерею узла, на котором активен CIFS (Samba). Пройдет некоторое время, пока кластер поймет, что узел вышел из строя, и запустит службу CIFS (Samba) на другом узле, аналогично с iSCSI. Active-active для iSCSI и CIFS обещан в следующих релизах.

iSCSI в 7.3 представлен как tech preview, в версии Veritas Access 7.3.1, выход которой обещан на 17 декабря 2017 г, будет полноценная реализация iSCSI в active-active.

Подробнее про режимы:

• Active-active: с приложением работают два (и больше) узла кластера, так называемый режим «приложение стоит на СХД двумя ногами», то есть выход одного узла кластера, работающего с приложением, не приведет к отказу в доступе и потери данных.
• Active-passive: приложение работает только с одним узлом кластера, в этом случае «приложение стоит на СХД одной ногой». Критична потеря узла, возможна потеря записываемых данных (появлении ошибки) и кратковременного прекращения доступа. Для файловой помойки, записи видеоархива с камер — это не критично. А если решите забэкапить базу данных по CIFS, и в момент записи бэкапа перестанет работать узел, который взял нагрузку – случится “ой” и бэкап придётся начать сначала. Соответственно если выйдет из строя узел который нагрузку не принимал или узел, на который пишется зеркало данных – ничего страшного не случится, лишь немного снизится производительность.

Почему SDS?

Немного теории.

Традиционные системы хранения отлично справляются с текущими задачами, обеспечивая необходимую производительность и доступность данных. Но стоимость хранения и управление разными поколениями СХД являются определённо не самыми сильными сторонами традиционных решений. Масштабирование по архитектуре Scale-up, где наращивание производительности идёт путём замены отдельных компонентов системы, не способны сдержать рост неструктурированных данных в современном IT-мире.

Помимо архитектуры вертикального масштабирования Scale-up появились решения Scale-out, где масштабирование осуществляется добавлением новых узлов и распределением нагрузки между ними. Используя такой подход, проблема роста неструктурированных данных решается быстро и доступно.

Минусы традиционных систем хранения данных:

• Высокая стоимость
• Малый срок актуальности СХД
• Сложное управление СХД различных поколений и производителей
• Архитектура масштабирования Scale-up

Плюсы Software-Defined Storage с горизонтальным масштабированием Scale-out:

• Нет зависимости от аппаратной части системы, для узлов можно использовать любые сервера х86
• Гибкое и надёжное решение с простым масштабированием и поддержкой избыточности
• Предсказуемый уровень обслуживания приложений на основе политик
• Низкая стоимость
• Производительность

Минусы программно-определяемую систему хранения данных:

• Отсутствие единой точки для техподдержки
• Требуются более квалифицированные инженеры
• Необходимость в N-кратном объеме ресурсов (избыточный объем)

При попытках расширить традиционную систему хранения после 3–5 лет использования пользователь сталкивается с резко повышающимися издержками, которые вынуждают покупать новую СХД. При появлении разрозненных устройств различных производителей теряется контроль над обеспечением уровня качества и надежности подсистемы хранения в целом, что, как правило, сильно затрудняет решение бизнес-задач.

Программно-определяемая СХД позволяет взглянуть на проблему размещения растущих данных c другой стороны: ее внедрение сохраняет производительность и доступность информации, не разводя зоопарк из различных производителей и поколений СХД, что делает работу с данными доступнее во всех планах.

Основные преимущества для бизнеса

• Доступная и надежная система хранения, которая поддерживает ваше существующее оборудование: и старое, и новое на платформе x86.
• Высокая производительность, отвечающая требованиям неструктурированных данных — идеальное решение для хранения большого количества небольших файлов с низкой задержкой, а также обслуживания потоковых нагрузок посредством предоставления высокой скорости записи.
• Высокая доступность. Благодаря многоузловой масштабируемой файловой системе, которая обеспечивает возможность перехода на другой ресурс на локальном, метро- и глобальном удалении узлов друг от друга без прекращения доступа.
• Единое решение хранения для новых и устаревших приложений. Решение для хранения данных с поддержкой нескольких протоколов (CIFS, NFS, iSCSI и S3)
• Простой в использовании интерфейс WEB, SSH и RESTful API.
• Гибкая масштабируемая архитектура. Легко добавлять новые узлы для повышения производительности, отказоустойчивости и увеличения емкости.

Основные технические характеристики

• Высокодоступная масштабируемая файловая система обеспечивает отказоустойчивость как на локальном уровне, так и глобально средствами репликации.
• Управление хранением данных на основе политик, которыми можно гибко настроить уровень доступности, производительности, защиты данных и безопасности томов.
• Многопротокольный доступ к файлам и объектам: работа с NFS, SMB3 / CIFS, iSCSI, FTP и S3, включая поддержку чтения и записи на один том с использованием разных протоколов.
• Гибридное облако:
  — OpenStack: поддержка Cinder и Manila
  — Amazon (AWS): поддержка интерфейса и протокола S3.
• Централизованный пользовательский интерфейс — единое окно для управления всеми узлами с простым и интуитивно понятным интерфейсом.
• Поддержка гетерогенной памяти DAS, SSD, SAN, а также облака.
• Storage Tiering: поддержка тиринга между разными томами хранения: облака, SAN, DAS и SSD.
• Read Caching: возможность использования SSD для кеша.
• Storage Optimization: поддержка дедупликации и сжатия
• Снапшоты.
• Direct Backup Ready: встроенный клиент NetBackup для резервного копирования, а также поддержка Veritas Enterprise Vault.
• Гибкие возможности аутентификации с поддержкой LDAP, NIS и AD.
• Гибкие возможности управления с поддержкой WEB, SSH и RESTful API.

АРХИТЕКТУРА

Veritas Access гибко и легко масштабируется увеличением узлов. Это решение подходит, в первую очередь, для работы с неструктурированными данными, а также с другими задачами хранения. Потребность в программно-определяемых СХД диктует переход к многоцелевым, многопротокольным продуктам, которые сочетают в себе надёжность, высокую производительность и доступную стоимость.

Кластер Veritas Access состоит из подключенных серверов — узлов. Вместе они образуют объединенный кластер, совместно использующий все основные ресурсы. Минимальная эталонная архитектура состоит из двухузлового конвергентного решения для хранения данных.



Фундамент Veritas Access — Veritas Storage Foundation

Наработки, полученные в течение жизненного цикла Veritas Storage Foundation, нашли свое логичное применение в современном продукте класса SDS, коим является Veritas Access. В основном свое проявление в Access находят следующие компоненты:

• Veritas Cluster Server (VCS) —система кластеризации прикладных сервисов.
• Veritas Cluster File System (CFS) — кластерная файловая система.
• Veritas Cluster Volume Manager (CVM) — кластерный менеджер логических томов.
• Flexible Storage Sharing (FSS) — технология, позволяющая объединить все локальные ресурсы хранения узлов в единый пул, доступный любому узлу в кластере.

В качестве узлов Veritas Access 7.3 используются серверы x86 с операционной системой Linux Red Hat релиза 6.6 – 6.8. Начиная с релиза 7.3.0.1 — RedHat 7.3 – 7.4. Объединение в кластер происходит за счет технологии VCS. В качестве пула хранения используются любые доступные диски. Для добавления узла в кластер необходимо наличие в сервере минимум 4-х портов Ethernet. Минимум 2 порта идут на клиентский доступ и минимум 2 порта идут на межузловой интерконнект. Для межузлового интерконнекта Veritas рекомендует использовать InfiniBand.

По оперативной памяти рекомендация 32 Гбайт на продакшен. Veritas Cluster File System (CFS) позволяет кешировать данные за счёт оперативной памяти, следовательно любой размер памяти выше 32 Гбайт лишним не будет, но и меньше лучше не использовать. Для тестирования вполне хватит и 8 Гбайт, программных ограничений нет.

Трёхузловую конфигурацию лучше избегать, рекомендуем использовать два узла или сразу четыре, пять и т.д. Текущее ограничение одного кластера – 20 узлов. Кластер InfoScale поддерживает 60, так что 20 узлов — не предел.

Кластер VCS обеспечивает отказоустойчивое функционирование сервисов доступа к данным по протоколам NFS, CIFS, S3, FTP, Oracle Direct NFS и соответствующей инфраструктуры на узлах Veritas Access, причем в определенных конфигурациях возможно обеспечить запись и чтение одних и тех же данных с использованием различных протоколов.

Для организации файловых систем размером до 3 Пбайт может применяться масштабируемая файловая система (Scale-out), позволяющая, в частности, подключить внешнее облачное хранилище в рамках единого пространства имен. При построении распределенных систем хранения или катастрофоустойчивости может быть настроена файловая репликация между различными хранилищами Veritas Access. Данная технология позволяет асинхронно реплицировать файловую систему исходного кластера в удаленный кластер с минимальным интервалом в 15 минут, причем удаленная файловая система остается открытой на чтение во время репликации. Поддерживается балансировка нагрузки между репликационными линками и мгновенное переключение удаленной файловой системы в режим запись при недоступности источника и переключение сервиса репликации с одного узла на другой в случае сбоя.

Количество параллельных операций репликации не ограничено. Важно отметить, что технология репликации использует функционал Veritas CFS/VxFS (журнал изменения файлов File Change Log и мгновенные копии на уровне файловой системы) для быстрого определения изменений, что позволяет избежать потерь времени на сканирование файловой системы и значительно увеличить производительность репликации.

АРХИТЕКТУРА РАБОТЫ С ДИСКАМИ

Схема стенда совместно с OCS:

Фото стенда в Открытых Технологиях:

Скачивание и установка

Получить дистрибутив Linux Red Hat Enterprise на подписку на 30 дней можно по этой ссылке. После оформления триала будут доступны на скачивание дистрибутивы Red Hat, в частности нужные релизы 6.6–6.8.

Получить дистрибутив Veritas Access можно по этой ссылке. Для этого нужно заполнить триальную форму. В процессе установки система сама предложит ключ на 60 дней. Добавить основную лицензию можно позднее через панель веб администрирования в разделе Settings > Licensing

Вся документация для версии 7.3 доступна по ссылке.



Установку Veritas Access условно можно разделить на два этапа:

1. Установка и настройка Red Hat Enterprise Linux
2. Установка Veritas Access

Установка Linux Red Hat Enterprise Linux

Обычная установка Linux без каких-либо сложностей.




Требования к Red Hat:


При наличии подписки Red Hat установщик Veritas Access сам подтянет необходимые ему модули RPM. Начиная с релиза Access 7.3 все необходимые модули добавлены в репозиторий установщика.

На паблик интерфейсах помимо IP адресов необходимо установить флаг Connection automatically или ONBOOT=yes в конфигурационном файле интерфейсов.



Установка Veritas Access:

Установочные файлы необходимо разместить на одном узле. Установка запускается командой:

# ./installaccess node1_ip node2_ip nodeN_ip

где node1_ip, node2_ip — любой из ip адресов публичного интерфейса.

В процессе установки Veritas Access есть моменты, которым стоит уделить внимание:

1. Установщик Veritas Access рассчитан на идеальную установку. Любой шаг влево-вправо для него критичен и может привести к ошибке установки. Аккуратно вписываем адреса, маски, имена.
2. Установку нужно запускать локально с любого хоста или через механизм управления серверами в условиях отсутствия физического доступа к ним, не ssh.
3. Если у вас не получилось установить Veritas Access с первого раза, рекомендую переустановить Red Hat и запустить установку Veritas Access с нуля. В случае ошибки установщик не предусматривает откат системы до начала установки, что приводит к повторной установки с частично запущенными сервисами Veritas Access и может вызвать проблемы.

После установки Veritas Access будет доступно 2 консоли управления:


• web — в нашем случае это https://172.25.10.250:14161
• ssh — на 172.25.10.250 с логином master (пароль по умолчанию master) и root

После установки Access необходимо предоставить кластеру все диски каждого узла, которые планируете использовать в кластере под данные. Этот процесс не автоматический, так как возможно у вас будут на некоторые диски кластера другие планы.
Команды CLISH:

# vxdisk list
# vxdisk export diskname1-N
# vxdisk scandisks

Для “нестандартных” серверных дисков необходимо указать модель диска и адрес, на котором лежит S/N диска. В моём случае на SATA дисках команда получилась:

# vxddladm addjbod vid=ATA pid="WDC WD1003FBYX-0" serialnum=18/131/16/12

Это небольшой минус SDS систем относительно жестких дисков не из Hardware Compatibility Lists. Каждый вендор закладывает свои стандарты в диски, видя терабайт в разном количестве байтов, секторов, размещая идентификаторы в различные адреса. И ситуация вполне нормальная. Если SDS система хранения неправильно определит диски, ей нужно немного помочь, в случае с Access инструкция здесь.

И тут прослеживается плюс Access’а: возникла нестандартная ситуация — есть документ с её решением, который ищется гуглом, вдобавок есть подробная справка в самом модуле vxddladm. Нет необходимости читать буржуйские форумы, допиливать на коленке с непредсказуемым результатом в продакшене. Если проблему не удаётся решить самостоятельно, всегда можно обратиться в техподдержку.

В итоге каждый диск должен быть доступен каждому узлу кластера.



После установки папка с установочными файлами будет удалена.

Как всё работает

В нашем случае кластер состоит из двух узлов:



Каждый узел имеет физические и виртуальные IP адреса. Физические IP назначены каждому узлу как уникальные, виртуальные IP обслуживают все узлы кластера. По физическим интерфейсам можно проверить доступность узла, подключиться — непосредственно по ssh. В случае недоступности узла его физические интерфейсы будут недоступны. Виртуальные IP каждого узла обслуживают все узлы кластера и активны, пока есть хотя бы один живой узел кластера. Клиенты работают только с виртуальными адресами.

Каждая шара отображает информацию о том, по каким IP она доступна.



В любой момент времени один узел выполняет роль мастера, на скриншоте это узел va73_02. Мастер узел выполняет задачи администрирования, распределению нагрузки. Роль мастера узла может быть передана или взята другим узлом в случае потери доступности или выполнения ряда условий, заложенных в логику кластера Veritas Access. При потери внутреннего интерконнекта может случится неприятная ситуация, при которой каждый узел станет мастером. Надежности внутреннего интерконнекта нужно уделять отдельное внимание.

Управление

В Veritas Access доступно 3 интерфейса управления: CLISH в режиме root и master, WEB и REST API.

ssh master mode (login root, master)	web

ssh master mode

Самая полная консоль управление кластером Veritas Access, доступ осуществляется по ssh на IP управления с логином master (пароль по умолчанию master). Имеет интуитивно понятный упрощенный набор команд и подробную справку.

ssh node mode

Обычная консоль управления Linux, доступ осуществляется по ssh c логином root на IP управления.

WEB

WEB консоль управленияr кластером, доступ осуществляется по логину root или master на IP управления по порту: 14161, протокол https.

WEB консоль интерпретирует команды в ssh master mode.



С каждым релизом наблюдается расширение возможностей управления по WEB.

Первоначальная настройка

Буквально пару слов по запуску Veritas Access как системы хранения.

1. Объединяем диски в storage pool



2. Создаём файловую систему исходя из типа дисков, данных и требуемой защиты (аналог RAID)



3. Расшариваем файловую систему по нужным протоколам. Одну файловую систему можно расшарить по нескольким протоколам и, к примеру, получить доступ к одним и тем же файлам как по NFS так и по CIFS, как временно так и постоянно.



4. Вы великолепны.

Подключение по ISCSI внешних СХД и любых других устройств хранения

Veritas Access поддерживает использование для хранения любые томов iSCSI или СХД сторонних производителей. Диски сторонних систем хранения нужно предоставлять по отдельности в RAW формате. Если это невозможно, используется RAID 5 из 3-х дисков. Защита данных обеспечивается средствами файловой системы Veritas Access и представлена в разделе выше. В защите данных на уровне hardware raid нет необходимости, в настройках файловой системы Access указывается число узлов, на которых будут зазеркалированы ваши данные.

Подключённые по iSCSI тома возможно включить в общие пулы.
Добавление iSCSI диска выглядит так:

1. Включаем iSCSI в разделе storage:



2. Добавляем iSCSI device:



3. Подключаем iSCSI диск:





В качестве тестового диска iSCSI — win2012

Раздача по ISCSI томов хранения

Процесс настройки в текущем релизе немного своеобразный, детально можно с ним ознакомится стр. 437 в Command Reference Guide (iSCSI target service). Для многих команд в текущем релизе нет возможности посмотреть настройки, т.е. все параметры лучше предварительно записывать в ТХТ файл.



Важное замечание, в версии 7.3 есть баг, из-за которого не стартует служба iSCSI!



Его пофиксить можно следующим образом:

На узлах нужно поправить файл /opt/VRTSnas/pysnas/target/target_manager.py
В строке 381, исправить [1] на [-1].



Процесс запуска раздачи по iSCSI выглядит так:

va73.Target> iscsi service start
ACCESS Target SUCCESS V-288-0 iSCSI Target service started

va73.Target> iscsi target portal add 172.25.10.247
ACCESS Target SUCCESS V-288-0 Portal add successful. 

va73.Target> iscsi target create iqn.2017-09.com.veritas:target
ACCESS Target SUCCESS V-288-0 Target iqn.2017-09.com.veritas:target created successfull

va73.Target> iscsi target store add testiscsi iqn.2017-09.com.veritas:target
ACCESS Target SUCCESS V-288-0 FS testiscsi is added to iSCSI target iqn.2017-09.com.veritas:target.

va73.Target> iscsi lun create lun3 3 iqn.2017-09.com.veritas:target 250g
ACCESS Target SUCCESS V-288-0 Lun lun3 created successfully and added to target iqn.2017-09.com.veritas:target

va73.Target> iscsi service stop
ACCESS Target SUCCESS V-288-0 iSCSI Target service stopped

va73.Target> iscsi service start
ACCESS Target SUCCESS V-288-0 iSCSI Target service started

Еще одно важное замечание: без перезапуска службы iSCSI новые параметры не применяются!

Если что-то идёт не так, логи iSCSI target работы можно смотреть по путям:

/opt/VRTSnas/log/iscsi.target.log
/opt/VRTSnas/log/api.log
/var/log/messages

На этом, собственно, все. Подключаем наш iSCSI том к VMware ESXi.





Устанавливаем виртуальную машину на том iSCSI, работа без нагрузки:



Так выглядит имитация отказа SLAVE узла под нагрузкой (копирование 10 Гбайт)

Интеграция Veritas Access c Veritas NetBackup

Важным преимуществом Veritas Access является встроенная интеграция с ПО резервного копирования Veritas NetBackup, обеспечиваемой предустановленным по умолчанию на всех узлах агентом NetBackup Client, который настраивается через командный интерфейс Veritas Access CLISH. Доступны следующие типы операций бекапа:

• полный;
• дифференциально-инкрементальный;
• кумулятивно-инкрементальный;
• мгновенная копия контрольной точки на уровне VxFS.



Долгосрочное хранилище резервных копий для NetBackup

Возможности Veritas Access по интеграции с NetBackup позволяют рассмотреть его как более дешевую и простую альтернативу ленточным носителям для задачи долговременного хранения резервных копий. В этом случае интеграция может быть выполнена с использованием стороннего свободного ПО OpenDedup, которое устанавливается на медиасервере NetBackup и подключается как логическое устройство NetBackup Storage Unit. OpenDedup инсталлируется на томе со специализированной файловой системой OpenDedup SDFS, которая размещается внутри контейнера S3 bucket на хранилище Veritas Access. При дублировании резервных копий политика NetBackup (Storage Lifecycle Policy) управляет записью на логическое устройство NetBackup Storage Unit, и данные отправляются в дедуплицированном виде по протоколу S3 на хранилище Veritas Access. Следует отметить, что несколько медиасерверов могут одновременно выполнять запись в один и тот же контейнер S3 bucket, что, в отличие от ленточных носителей, способных выполнять только компрессию потока данных с гораздо меньшей эффективностью, обеспечивает глобальную дедупликацию при хранении долговременных копий.

Настраивается всё довольно просто, но начиная с версии 8.1 требуются сертификаты.

Тома хранения:



Интерфейс NetBackup:

Обновление Veritas Access на версию выше

Мы начинали изучать и тестировать Veritas Access версии7.2, но после недели тестирования вышла новая 7.3.

Встал вопрос интересного кейса — обновление.

Кейс актуальный, с которым владельцы SDS решений рано или поздно столкнутся.

Возможность обновления предусмотрена в админке по логину master.

Veritas Access как система хранения для VMware по NFS

Следует отметить простоту использования NFS. Его использование не требует внедрения и освоения сложной FC-инфраструктуры, непростых процессов настроек зонинга или разбирательства с iSCSI. Использовать NFS для доступа к датастору также просто и тем, что гранулярность хранения при этом равна файлу VMDK, а не целиком датастору, как в случае блочных протоколов. Датастор NFS — это обычная монтируемая на хост сетевая шара с файлами дисков виртуальных машин и их конфигами. Это, в свою очередь, облегчает резервное копирование и восстановление, так как единицей копирования и восстановления является простой файл, отдельный виртуальный диск отдельной виртуальной машины. Нельзя сбрасывать со счетов и то, что при использовании NFS вы автоматически получаете thin provisioning, а дедупликация высвобождает вам пространство непосредственно на уровень датастора, что делает его доступным администратору и пользователям VM, а не на уровень стораджа, как в случае использования LUN-а. Это все также выглядит крайне привлекательно с точки зрения использования виртуальной инфраструктуры.

Наконец, используя датастор по NFS, вы не ограничены лимитом в 2 Tбайта. Это как нельзя кстати в случае, если вам, например, приходится администрировать большое количество сравнительно слабонагруженных вводом-выводом машин. Их всех можно поместить на один большой датастор, бэкапить и управлять которым гораздо проще, чем десятком разрозненных VMFS LUN-ов по 2 Tбайта каждый.

Кроме того, вы можете свободно не только увеличивать, но и уменьшать датастор. Это может быть очень полезной возможностью для динамичной инфраструктуры с большим количеством разнородных VM, таких как среды облачных провайдеров, где VM постоянно создаются и удаляются, и данный конкретный датастор для размещения этих VM, может не только расти, но и уменьшаться.

Но есть и минусы:

Ну, во-первых, это невозможность использовать RDM (Raw-device mapping), который может понадобиться, например, для реализации кластера MS Cluster Service, если вы его хотите использовать. С NFS нельзя загрузиться (по крайней мере простым и обычным способом, типа boot-from-SAN). Использование NFS сопряжено с некоторым увеличением нагрузки на сторадж, так как ряд операций, которые в случае блочного SAN реализуются на стороне хоста, в случае NFS поддерживается стораджем. Это всяческие блокировки, разграничение доступа, и так далее.

Подключения VMware к Veritas Access по NFS выглядит вот так, согласитесь, это очень просто:




Для проверки отказоустойчивости и производительности мы разметили виртуальную машину на win 2008 R2 на шару, которая находится в зеркале на двух узлах.

Так выглядит имитация отказа мастер узла без нагрузки, в момент выдергивания кабеля latency поднялся с 0.7 до 7:



Так выглядит имитация отказа мастер узла под нагрузкой (копирование 10 Гбайт):




Так выглядит имитация отказа SLAVE узла под нагрузкой (копирование 10 Гбайт):

S3 И ОБЪЕКТНОЕ ХРАНЕНИЕ

Один из основных недостатков NFS, iSCSI, CIFS — сложность использования на больших расстояниях. Задачу по пробросу NFS шары в соседний город можно назвать как минимум интересной, а сделать это по S3 не составит никаких трудностей. Популярность объектного хранения растёт, всё больше приложений поддерживают объектные стораджи и S3 в частности.

Для настройки и тестирования S3 есть удобный и бесплатный инструмент — S3 Browser. Настройка S3 на Veritas Access довольно проста, но своеобразна. Для доступа по S3 нужно получить связку ключей Access Key и Secret Key. Доменные пользовали видят свои ключи через WEB интерфейс Access, ключи для root пользователя в текущем релизе получаются скриптами через консоль CLISH.



Подключили по S3 NetBackup:

РЕПЛИКАЦИЯ

Veritas Access поддерживает синхронную и асинхронную репликацию. Репликация идёт в базовом функционале без дополнительных лицензий и настраивается довольно просто. Асинхронная репликация осуществляется на базе файловых систем, синхронная — на базе томов. Для проверки работы репликации мы объединили наш кластер Veritas Access и кластер дистрибьютора OCS средствами репликации на уровне файловых систем. Для связи между площадками был организован IPSEC туннель.

Еще раз схема стенда:



Настройка репликации через WEB браузер:



После успешной авторизации появляется Replication link:



Проверили работоспособность.

Примонтировали две шары с каждого кластера на две папки:

[root@vrts-nbu03 mnt]# showmount -e vrts-access.veritas.lab
Export list for vrts-access.veritas.lab:
/vx/VMware-Test *
/vx/test_rpl_in *
[root@vrts-nbu03 mnt]# showmount -e 192.168.3.210
Export list for 192.168.3.210:
/vx/NAS      *
/vx/test_rpl *
[root@vrts-nbu03 mnt]# mount -t nfs 192.168.3.210:/vx/test_rpl /mnt/repl_out/
[root@vrts-nbu03 mnt]# mount -t nfs vrts-access.veritas.lab:/vx/test_rpl_in /mnt/repl_in/
[root@vrts-nbu03 mnt]#

Скопировали данные в папку источника:



Запустили задание репликации, чтобы не ждать таймер:

va73>
va73> replication job sync test_rpl_job
Please wait...
ACCESS replication SUCCESS V-288-0 Replication job sync 'test_rpl_job'.
va73>

Файлы появились в папке получателя:

ВЫВОДЫ

Veritas Access — это интересное Software-Defined Storage решение, которое нестыдно предложить заказчику. Это действительно доступная, легко масштабируемая система хранения данных с поддержкой файлового, блочного и объектного доступа. Access предоставляет возможности построения высокопроизводительного и экономически эффективного хранилища для неструктурированных данных. Возможности по интеграции с OpenStack, облачными провайдерами и другими технологиями Veritas позволяют применять это решение в следующих сферах:

• Медиахолдинги: хранение фото- и видеоконтента;
• Госсектор: хранения ведиоархивов системами типа «безопасный город»;
• Спорт: хранение видеоархивов и другой важной информации стадионами и другими спортивными объектами;
• Телекоммуникации: хранение первичных данных биллинга CDR (Call Detail Records);
• Финансовый сектор: хранение выписок, платежных документов, сканов паспортов и т.д.;
• Страховые компании: хранение документации, сканов паспортов, фотографий и т.д.;
• Медицинский сектор: хранение рентгеновских снимков, МРТ снимков, результатов анализов и т.д.;
• Облачные провайдеры: организация хранения для OpenStack.
• Альтернатива ленточным системам хранения



Сильные стороны:

• Легкая масштабируемость;
• Любые х86 сервера;
• Относительно невысокая стоимость.

Слабые стороны:

• В текущим релизе продукт требует повышенного внимания инженеров;
• Слабая документация;
• CIFS, iSCSI работают в режиме active-passive.

Команда Veritas Access регулярно выпускают новые релизы в соответствии с графиком (roadmap), устраняя ошибки и добавляя новые возможности. Из интересного в новом релизе Veritas Access 7.3.1 от 17 декабря 2017 ожидается: полноценная реализация iSCSI, erasure coding, до 32 узлов в кластере.

Если у вас есть вопросы по работе, функционалу или настройке — пишите, звоните, мы всегда готовы к помощи и сотрудничеству.

Дмитрий Смирнов,
Инженер-конструктор,
Открытые Технологии
Тел: +7 495 787-70-27
dsmirnov@ot.ru