Veritas infoscale что это

Такого еще не было: опыт построения Veritas HA Cluster поверх VMware vSAN

В одном проекте мы строили новую ИТ-инфраструктуру и консолидировали на нее базы данных Oracle. Базы были разных объемов и степени критичности (вплоть до Business Critical). Казалось бы, штатная задача. Но в ней таилась одна особенность, о которую мы поломали немало копий, — развертывание на VMware кластера Veritas HA.

Условия задачи

Итак, мы строили абсолютно новую ИТ-инфраструктуру на заранее выбранных нашим заказчиком решениях. Исходные условия:

БД Oracle должны запускаться в виртуальных машинах на платформе виртуализации VMware vSphere.

Данные виртуальных машин должны располагаться на двух разных хранилищах: программно-определяемой СХД VMware vSAN и отдельной внешней СХД.

Защита критичных БД Oracle должна быть обеспечена двумя эшелонами:

с помощью ПО Veritas InfoScale Availability (он же хорошо известный в Enterpise сегменте как Veritas Cluster Server);

наличием отдельной Standby копии.

Схема решения выглядит так:

Уникальность vs сложность

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

Oracle на VMware — можно

Очень долго компания Oracle вела негласную войну с VMware, отказываясь официально предоставлять техподдержку заказчикам, которые запускали СУБД Oracle на VMware. Наверняка администраторы СУБД Oracle знакомы со статьей в базе знаний Metalink Note 249212.1. В 2019 году политика вендора изменилась. Oracle объявил о стратегическом партнерстве с VMware и наконец начал оказывать техподдержку.

VMware vSAN

Это программно-определяемая система хранения данных от VMware. Для создания общего отказоустойчивого хранилища используются локальные диски, установленные в серверах виртуализации. Во всем мире более 30 тысяч компаний используют VMware vSAN в своих ИТ-инфраструктурах.

Veritas InfoScale Availability в виртуальных машинах

С понятными условиями разобрались. Как делать Standby и зачем он нужен — тоже все ясно. Но в условиях задачи есть суперважные базы данных, простой которых критичен. Крупные компании часто одним из инструментов защиты критически важных СУБД Oracle выбирают решение Veritas InfoScale Enterprise (он же Veritas Cluster Server). Заказчик нас попросил применить это решение, чтобы защитить самые критичные БД Oracle в виртуальных машинах.

Мы проконсультировались с Veritas и VMware и выяснили, что такие конфигурации используют несколько заказчиков в Европе, а в нашей стране подобное никто раньше не делал. Звучало как вызов!

Вообще у VMware vSphere есть встроенный механизм обеспечения высокой доступности виртуальных машин (vSphere HA). Он позволяет перезапустить виртуальную машину, если случился сбой гипервизора, на котором она работала. Механизм проверен годами и работает без нареканий. Зачем же тогда использовать что-то еще? vSphere HA не может обеспечить некоторые важные опции:

не проверяет статус работы приложения внутри виртуальной машины и не «умеет» реагировать на различные сбои, возникающие в гостевой ОС (например, сбой сетевого адаптера);

не отвечает за порядок старта сервисов внутри гостевой ОС и выполнение необходимых проверок в случае рестарта виртуальной машины;

всегда есть задачи по эксплуатации критичных сервисов (например, выполнение обновлений версий ПО), при исполнении которых хотелось бы минимизировать время простоя.

Получается, что повысить надежность работы приложения и его доступность можно двумя способами — на уровне приложения (если оно это умеет) и средствами кластеризации. А в отдельных случаях, как у нас — обоими сразу.

Внимание к виртуальным дискам

Чтобы создать классический отказоустойчивый кластер, данные нужно хранить на общем диске, и к нему должны иметь доступ все узлы кластера.

Выключаем виртуальную машину и добавляем параметр вида scsiX:Y.sharing = «multi-writer» в конфигурационный файл. Также важно не забыть для общих дисков в этом же конфигурационном файле добавить параметр disk.EnableUUID = «TRUE» для корректной работы кластерного ПО Veritas.

Однако за высокую доступность и надежность придется заплатить существенными ограничениями, с которыми придется мириться при дальнейшей эксплуатации системы. Основные из них:

Нельзя менять размер общего диска «на лету». Для этого придется выключать оба узла кластера и только после этого производить манипуляции с диском. Пожалуй, это самая больная тема. Когда заканчивается место на диске, где лежит критичная БД, становится не до шуток.

Нельзя использовать снапшоты для общих дисков. Соответственно, нельзя будет использовать средства безагентского резервного копирования для бэкапа данных. Как следствие, технология Change Block Tracking для инкрементального резервного копирования также не поддерживается.

Без Storage vMotion миграцию общих виртуальных дисков на горячую выполнить будет невозможно.

Хорошая новость — обычный vMotion для перемещения виртуальных машин между гипервизорами успешно работает.

Дьявол в деталях

Хотим поделиться еще несколькими нюансами, не все из которых были задокументированы на момент реализации нашего проекта.

Не забудьте сконфигурировать Anti-affinity правила, чтобы оба узла виртуального кластера случайно не оказались на одном гипервизоре. Для этого потребуется лицензия VMware vSphere Enterprise Plus с ее функционалом DRS.

Даже несмотря на то, что использовать снапшоты нельзя, администраторы системы резервного копирования (СРК) могут случайно поставить на безагентский бэкап ваши виртуальные машины. Пара кликов мыши в консоли управления СРК — и кластер из двух узлов неработоспособен. Расследование инцидента показало следующее: СРК принудительно включает CBT на виртуальном диске (а как мы уже зафиксировали, данная технология не поддерживается с multi-writer диском) и при первой попытке записать что-то на виртуальный диск гипервизор сыпет ошибками. Чтобы избежать этого, мы рекомендуем:

добавить параметр ctkDisallowed=»true» (он был описан в базе знаний VMware, но по неизвестным причинам статья закрыта);

в СРК контрольно добавить в исключения общие диски узлов кластера.

Начиная с версии VMware vSphere 6.7 P01 (build 15160138) на vSAN можно не использовать общие диски в формате thick eager-zeroed. До этой версии общие диски приходилось создавать вручную из командной строки с помощью утилиты vmkfstools.

А с версии VMware vSphere 6.7 Update 3 (build 14320388) vSAN поддерживает SCSI-3 persistent резервации, но применение технологии SCSI-3 PR IO fencing с общими VMDK-дисками в Veritas Cluster не поддерживается. Для арбитража ситуации Split Brain требуется задействовать Coordination Point Server.

Что в результате?

В нашем случае получилось создать необходимую конфигурацию и выполнить все требования заказчика. Критичные базы данных Oracle получили эшелонированную защиту от различных сбоев.

Подойдет ли описанная конфигурация всем? Хм, сомневаемся. На выходе получается слоеный пирог из нескольких технологий с весомым списком ограничений при дальнейшей эксплуатации. Но с ограничениями придется смириться, если на другой чаше весов находятся драгоценные минуты простоя и огромное влияние системы на бизнес. И перед использованием подобного решения мы рекомендуем оценить все «за» и «против» в каждом отдельном случае.

Автор: Дмитрий Горохов, руководитель направления виртуализации «Инфосистемы Джет»

Роман Родин, инженер-проектировщик вычислительных комплексов «Инфосистемы Джет»

Источник

Как Veritas InfoScale помогает добиться непрерывности бизнес-процессов в эпоху цифровизации

Данные — основа основ в мире современного бизнеса. Но их количество постоянно увеличивается, а приложения эволюционируют и превращаются в многоуровневые сложные структуры.

Когда одного бэкапа мало: причины проблемы

Со временем в мире увеличивается не только количество данных, которое к 2025 году должно достигнуть впечатляющей цифры в 175 зеттабайтов, но и нагрузка на ИТ-специалистов. От ИТ-служб компаний требуется постоянно следить за современными трендами и применять новые подходы, включая виртуализацию, перевод инфраструктуры в «облако» или гибридные схемы её построения. При этом они же должны поддерживать развёртывание и интеграцию приложений от различных производителей, понимать, от какой именно среды (или сред) зависит их работоспособность, и оперативно восстанавливать данные при помощи резервных копий.

Учитывая постоянное усложнение ИТ-инфраструктуры, эти службы вынуждены тратить большую часть своего времени не на актуальные вопросы цифровой трансформации, а на попытки минимизировать простои и оптимизировать расходы. Также внимания требуют законодательные акты и позиция государственных регулирующих органов по поводу защиты и хранения конфиденциальных данных. В итоге инфраструктура становится не только сложной, но и непрозрачной, что резко снижает эффективность ИТ-служб и повышает расходы компаний, как минимум, по двум направлениям.

Во-первых, с ростом количества данных увеличивается и число обязательных бэкапов. А это «раздувает» затраты на содержание инфраструктуры за счёт оплаты услуг ЦОДов. Во-вторых, многоуровневые приложения могут одновременно использовать услуги сразу нескольких служб, и на определение реального источника сбоя уходит значительно больше времени, чем раньше. Особенно, если весь процесс поиска и устранения проходит в ручном режиме. Это означает увеличение простоев и проблемы с непрерывностью бизнеса. Если приложение приносит доход, то такие простои приводят к вполне реальным финансовым убыткам.

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

Veritas EDSR и InfoScale

Veritas InfoScale было разработано для того, чтобы повысить доступность инфраструктуры и уровень её QoS (качество обслуживания), используя кластерную технологию. Это решение автоматизирует процесс создания планов восстановления, самостоятельно определяет вышедшие из строя узлы инфраструктуры и практически мгновенно запускает приложения на резервном ЦОД. По своей сути Veritas InfoScale — это программно-определяемое связующее звено между ПО и сетевой инфраструктурой, которое применяет виртуализацию для того, чтобы «отвязать» критически важное ПО, базы данных и многоуровневые приложения от их привычной среды. Это позволяет не только в кратчайшие сроки восстановить инфраструктуру после сбоя, но и, например, провести её безболезненный перевод в «облако», тестирование уязвимостей или обновление аппаратной части серверов.

Преимущества Veritas InfoScale:

· Поддержка всех основных платформ и ОС включая Unix, Linux™ и Windows®, а также платформ виртуализации — VMware® ESX®, Red Hat® Enterprise Virtualization (RHEV), Oracle® VM, и Hyper-V.

· Поддержка различных физических систем хранения данных, от жёстких дисков и твердотельных накопителей, до SAN, DAS и массивов JBOD.

· Поддержка крупнейших облачных платформ Google Cloud Platform (GCP), Amazon Web Services (AWS) и Azure.

· Veritas™ Virtual Business Services — встроенная служба, отвечающая за автоматизированное восстановление работоспособности многокомпонентных приложений, которые используют сразу несколько виртуальных и физических сред.

· Fire Drill — автоматическая система тестирования процессов восстановления в случае сбоев, которая не затрагивает рабочую среду и не влияет на доступность приложений.

· Высокий уровень безопасности с Veritas InfoScale Operations Manager (VIOM), включая двухфакторную аутентификацию и поддержку SNMP v3.

· Дедупликация и сжатие данных, которые помогают снизить объёмы резервных копий.

· Простота развёртывания, настройки и мониторинга, включая удобную панель управления и систему отчётов.

Клиентский опыт

Одно из важных качеств Veritas InfoScale — масштабируемость. Оно позволяет обеспечивать непрерывность бизнеса даже крупных мировых компаний. Один из клиентов, ведущий деятельность в сфере финансовых услуг и располагающий штатом сотрудников в 200 000 человек, поделился результатами внедрения продукта. Компания использует InfoScale для защиты приложений, работающих примерно на 5000 системах. Ранее клиент сталкивался с большим количеством продолжительных простоев, длительность которых не только снижала эффективность работы ИТ-команд, но и негативно влияла на производительность сотрудников всей организации. Кроме того, простои препятствовали получению дохода от неработающего приложения. После внедрения InfoScale клиент отметил, что скорость восстановления существенно выросла. За год общее время простоя сократилось в 12 раз для отказов, влияющих на производительность сотрудников, и в 48 раз для отказов, влияющих на доходы. Теперь для устранения сбоя приходится привлекать меньше сотрудников, поскольку приложение и связанные с ним сценарии автоматически запускаются на резервных серверах. Автоматизированное аварийное переключение позволяет клиенту получить дополнительный доход в размере 6 миллионов долларов за одно событие простоя или в общей сложности 12 миллионов долларов в год. В масштабе всей организации это более 322 000 дополнительных рабочих часов.

Получить исследование Forrester

«Снижение расходов и прочие выгоды для бизнеса благодаря повышению доступности с Veritas InfoScale»

Источник

Veritas Access 7.3: плюсы, минусы, подводные камни

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

В этой статье мы рассмотрим и протестируем новую версию программно-определяемой системы хранения данных (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 – компании 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.

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

Почему SDS?

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

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

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

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

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

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

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

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

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

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

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

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

АРХИТЕКТУРА

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

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

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

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

По оперативной памяти рекомендация 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:

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

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

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

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

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

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

Это небольшой минус 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). Имеет интуитивно понятный упрощенный набор команд и подробную справку.

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

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

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

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

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

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

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

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

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

Подключение по 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 выглядит так:

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

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

На этом, собственно, все. Подключаем наш 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 требуются сертификаты.

Обновление 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:

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

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

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

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

ВЫВОДЫ

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 узлов в кластере.

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

Источник