Когда нет денег на железное хранилище от именитого вендора, или деньги есть, но негде взять железо для тестов, нам на помощь приходят Virtual Storage Appliance, или сокращённо — VSA. Виртуализированный контроллер столь желанного хранилища, позволяющий получить практически все функции своего железного собрата, кроме ну совсем уж экзотических и реализуемых только на физическом железе. VSA есть практически у всех (а может, и просто у всех) вендоров классических СХД: HPE, Dell EMC, NetApp, IBM и т.д. Бывают и обратные ситуации, вроде Nutanix и StarWind, но сегодня не о них. Для порядка не забудем открытые разработки во главе с FreeNAS, чей функционал вызывает уважение.
Другая особенность VSA, которой по определению лишены железные братья — наличие бесплатного функционала, обычно ограниченного допустимым размером хранилища и поддержкой “корпоративных” протоколов вроде FC. (Хотя нередко имеются и триальные версии на какой-то временной период, но речь сейчас не об этом.)
Сегодня мы рассмотрим работу с Dell EMC UnityVSA, начиная с первых шагов по развертыванию, включая создание файловой системы, настройки NAS и NDMP, а закончим интеграцией с Veeam Backup & Replication. Почему именно эта VSA? Просто потому что подобных материалов на Хабре я не нашёл и решил устранить эту несправедливость.
Краткое вступление
Dell EMC UnityVSA или, как это модно говорить, Software-Defined Storage (SDS) позволяет в рамках одной системы держать сразу несколько хранилищ разного типа, работающих по разным протоколам. Поставляется в двух видах: бесплатном Community Edition, с ограничением в 4TB, и платном варианте Professional. Всё ниженаписанное было сделано на Community Edition и должно не противоречить версии Professional, а то и совпадать с ней полностью.
UnityVSA позволяет создавать хранилища всех основных типов, поддерживает множество протоколов, тут ничего интересного. Важная для нас часть заключена в интеграции с VMware vSphere, а значит, мы можем получить volume-снапшоты со всеми вытекающими плюсами, начиная от быстрых бекапов, поддержки оптимальных значений RTO и RPO, до ещё одного барьера защиты от потери данных.
Развертывание
UnityVSA поставляется в виде стандартного OVA файла и не задаёт лишних вопросов при установке.
На что стоит обратить внимание:
- Для инсталяции одиночной ноды потребуется 18 GB RAM. В HA режиме уже все 30 GB RAM. Можно поджать после установки, но это может сказать на производительности, так что на свой страх и риск.
- Аплаенсу потребуется 4 сетевых карты. Хорошо (но, не обязательно), если они будут 10 GbE. Одна — для управления самой VSA, другие — для приёма и передачи данных со стораджа. Потом можно свободно добавлять ещё.
- По верной традиции рекомендуется использовать статические IP и создать соответствующие DNS(A) и PTR записи, чтобы резолвить FQDN.
- Машина разворачивается с дефолтным набором дисков, поэтому если в качестве самого стораджа вы планируете использовать виртуальные диски, их можно добавить перед первым запуском.
Первый запуск
После загрузки (а первый раз грузится она весьма небыстро) перед нами будет стоять выбор инструмента для первоначальной настройки. Конечно же, можно всё делать по старинке в консоли, а можно воспользоваться весьма удобным веб-интерфейсом, который работает через Unisphere. Вот список из первых приходящих в голову плюсов второго подхода:
- Единая консоль для управления несколькими устройствами
- Как следствие: появляются функции вроде возможности делать реплики на удалённые площадки
- Есть интеграция с VMware vCenter API
- Железные Dell Unity тоже работают с ним
Кстати, неочевидный нюанс про консоль: дефолтные креды из документации admin/Password123# подходят только для WebGUI. Для консоли надо использовать service/Password123#.
Итак, открываем веб-интерфейс и попадаем в визард первоначальной конфигурации. Описывать каждый его шаг затея странная, но можно остановиться на шаге Pools. Здесь мы объединяем подключённые диски в виртуальную сущность, которую в дальнейшем будем презентовать подсистемам хранилища.
Каждый диск сразу надо поместить в Tier. Как и везде, идея их существования — это разделение нагрузок. Extreme хорошо назначать быстрым SSD, Perfomance — гибридным SATA c SSD кэшем, а в Capacity — всё остальное. В UnityVSA есть встроенный механизм FAST VP, который хитрым образом следит за частотой использования блоков данных и перемещает их между tier-ами.
Также не забываем создать несколько iSCSI интерфейсов. Раз уж просили с нас четыре сетевушки, вот пусть все и работают =)
NAS
Dell EMC UnityVSA поддерживает три вида хранилищ: файловые, блочные и VMware (маркетинг такой маркетинг). Среди них NAS — самое простое в настройке. Так что давайте посмотрим, как они создаются.
Идём в Storage > File > NAS Servers, нажимаем + и проходим все шаги мастера, где самое сложное — это выбрать поддерживаемые протоколы и назначить IP адрес.
Прямо в мастере можно связать будущий NAS с Active Directory, что очень удобно. Причём можно выбрать, появится сервер в списке машин как обычная Windows-машина или же под каким-то кастомным OU. Очень удобно в квадрате. Если у вас развёрнуто два NAS на этой платформе, можно сразу настроить как взаимную репликацию, так и одностороннюю.
По завершению работы мастера у нас всё готово для создания файловой системы и самой шары. Unisphere позволяет создавать сразу несколько FS с разными настройками, и грех этим не воспользоваться. Давайте подумаем, почему:
- Эффективное использование места и контроль за нагрузкой. На манер виртуальных дисков, каждая система может быть сделана Thin или Thick. Про все прелести и недостатки обоих подходов сказано уже до нас, так что не будем углубляться.
- Снапшоты. Вы не поверите, но аплаенс из коробки идёт с настроенным расписанием снапшотов, обеспечивающих гранулярное восстановление. Вам остаётся только активировать нужный сценарий. И, конечно же, можно настроить своё расписание.
- FAST VP. Уже упоминавшаяся выше функция автоматической миграции данных между tier-ами хранилища.
- Репликация. Наличие возможности включить синхронную или асинхронную репликацию данных — это очень жирный плюс. Репликацию можно настроить с помощью визарда, да ещё и позволят контролировать объёмы трафика.
Для создания файловой системы переходим в раздел File Systems и запускаем очередной визард.
Выбираем протокол, вводим название и переходим к шагу File Level Retention (FLR). Эта штука позволяет нам реализовать стратегию WORM: все записанные файлы будут недоступны для редактирования на указанный период времени.
Работает в двух режимах: в первом информацию не могут изменять пользователи, во втором вообще никто, даже администраторы. Сделано это для соответствия законодательству. Важно помнить, что однажды включив эту функцию, выключить её уже не получится.
На следующих шагах мастера можно сразу создать SMB-шару, и причин не воспользоваться этой возможностью я не вижу. Помимо общих настроек, также предложат включить одно из расписаний создания снапшотов для сохранности данных. Впоследствии на этой же файловой системе можно создавать другие SMB-шары.
NDMP
Главная задача данного протокола — это обеспечение трансфера данных между NAS и другим хранилищем напрямую. Чем меньше обработки на пути данных, тем выше скорость трансфера. Изначально этот протокол был разработан NetApp, но благодаря хитросплетениям судьбы оказался у EMC. Поддержка протокола реализована практически во всём бекапном софте, поэтому включать его строго обязательно.
Включается он на этапе создания NAS сервера, но если вы пропустили нужную галочку, всегда можно наверстать упущенное в его настройках, на вкладке Protection & Events.
При активации протокола будет создан новый пользователь с правами на чтение и запись, который будет использоваться при бекапах и восстановлении. Так что не пренебрегайте сложностью пароля, хотя Unity и не даёт создавать простые.
Подключаем ESXi
Теперь давайте разбираться, какие типы хранилищ может предоставлять Dell EMC UnityVSA для использования с VMware ESXi.
Если рассматривать поверхностно, то UnityVSA — это SDS со всеми плюсами в виде гибкости настроек, возможностью обеспечения доступа для удалённых площадок, выделения "песочниц" для разработчиков, тестеров и т.д.
Если посмотреть документацию, то там будут практически все варианты блочных и файловых хранилищ, поэтому сложнее найти, какой тип хранилища оно не может предоставлять, чем пытаться перечислить все поддерживаемые.
Но раз мы говорим про VMware-среду, то VMFS, NFS и VVol тут есть в лучше виде. iSCSI и FC для блочных хранилищ, конечно же, обеспечено.
Сам процесс настройки тоже как в лучших домах Европы: выделяем место на хранилище, обозначаем LUN'ы (не обязательно), подключаем к vCenter. Все необходимые операции будут проделаны автоматически во время подключения, включая возможность автоматической регистрации и сканирования хранилища.
Но это лирика. Гораздо больший интерес представляет наличие интеграции с VAAI (vStorage API for Array Integration) и VASA (vStorage API for Storage Awareness).
VAAI: — это API, позволяющее выполнять ряд операций с данными прямо на сторадже, снимая нагрузку с хоста. Операции вроде клонирования, копирования, создание снапшота, перезапись нулями и т.д. будут производиться без нагрузки на хост самим Storage Process'ом. Помимо снижения нагрузки, это ещё и повысит скорость их выполнения.
VASA: — API позволяющее vCenter лучше понимать состояние и возможности хранилища. Этакий продвинутый мониторинг, позволяющий более тонко настраивать политики использования стораджа. Правда, есть ограничение: если вы будете подключать несколько vCenter'ов, использовать VASA можно только с одним из них.
Самое время перейти к настройке. В первую очередь надо разрешить доступ на стороне UnityVSA. Заходим в ACCESS > VMware и на вкладке vCenter запускаем визард подключения. Заполняем все поля, жмём Find и убеждаемся, что наш vCenter со всеми хостами в статусе Can be imported.
На следующей вкладке смело включаем использование VASA провайдера. Для этого потребуется указать учётку администратора UnityVSA, или равного ему. Процесс регистрации будет запущен на всех хостах из предыдущего пункта.
На последнем шаге убеждаемся, что всё верно, и жмём Finish.
Если всё успешно (а неуспешно тут может быть, только если опечатались в кредах), то на вкладке ESXi Hosts будет примерно такая картина.
Подключаем к vCenter
Настала пора создать уже VMFS хранилище и подключить его к нашей инфраструктуре!
Идём в Storage > VMware и запускаем визард создания нового хранилища. В своём примере я создам блочное VMFS хранилище.
На следующих шагах задаём имя, затем размер и указываем, из какого пула брать диски. Как мы помним, UnityVSA может определять типы дисков и назначать им соответствующий tier. Здесь же можно задать лимит I/O.
На вкладке Access указываем, какие хосты будут иметь доступ к нашему хранилищу и по какому протоколу. Обычно лучше выбрать сразу все, чтобы не иметь в будущем проблем с vMotion, но тут уже зависит от конкретно вашей инфраструктуры. Так же здесь можно назначить LUN ID.
На вкладках Snapshot и Replication назначаются очевидные функции для защиты данных. Схему создания снапшотов можно изменить на свою, а вот для синхронной репликации понадобится дополнительная инсталяция ещё одной UnityVSA.
Через несколько секунд хранилище будет создано, и можно будет наблюдать их в интерфейсе VMware vCenter.
Интеграция с Veeam
Несмотря на все возможности по сохранению данных, которые даёт нам UnityVSA из коробки, полноценные бекапы делать оно не умеет, поэтому внешний софт тут необходим. И желательно с поддержкой интеграции, чтобы снизить нагрузку на продакшн.
В Veeam Backup & Replication реализована поддержка Dell EMC API для прямого общения с Unity Storage Array. Это позволяет создавать снапшоты виртуальных машине на уровне хранилища. Уже много раз обсуждали их плюсы, поэтому подробно останавливаться на них мы не будем, а я просто приведу списком самые очевидные:
- Минимизация нагрузки на хост
- Быстрое создание снапшота и малое время работы на нём, что очень важно для высоконагруженных машин
- Возможность гранулярного восстановления напрямую со снапшота на хранилище
Мы рассмотрим, как подключить UnityVSA к Veeam и настроить Veeam Backup Proxy для правильной работы.
На вкладке Storage Infrastructure запускаем визард добавления нового хранилища и выбираем Dell EMC.
Veeam поддерживает несколько моделей, поэтому выбираем Unity.
Затем указываем FQDN или IP, и создаём учётную запись. Если вы используете самоподписной сертификат, то получите соответствующее предупреждение, и начнётся проверка учётной записи.
Если всё хорошо, то на следующем шаге предстоит выбрать, по каким протоколам можно связываться с вашим хранилищем. Fiber Channel в Community-лицензию Dell не входит, поэтому можно его отключить. (А можно и оставить, в дальнейшем он отключится автоматически.)
По умолчанию, Veeam будет пытаться выбрать наиболее подходящий прокси из списка имеющихся, но я всем советую указывать конкретный, чтобы получить гарантированный результат. Причём, если указан конкретный прокси, то остальные иметь доступа к хранилищу не будут. На этом же шаге можно выбрать, какие именно volumes должен обрабатывать Veeam (если у вас их несколько).
После прохождения всех пунктов визарда запустится процесс сканирования хранилища, и оно станет доступно в интерфейсе Veeam.
Теперь вернёмся в консоль Unity, чтобы разрешать доступ для Veeam Backup Proxy. Для этого идём на вкладку Access > Hosts и запускаем визард добавления нового хоста.
На следующем шаге важно задать имя iSCSI-инициатору, если UnityVSA не обнаружит его автоматически (а это нормальная ситуация). Можно создать сразу несколько, чтобы получилось MPIO. И немного капитанства: если iSCSI-инициатор не настроен на вашем прокси, сейчас самое время его включить и настроить.
Проходим визард до конца и получаем свидетельство об успешном добавлении нового хоста.
Теперь создаём задание на бекап. В общем случае оно ничем не отличается от стандартного, поэтому остановимся лишь на самых важных пунктах.
В этом примере я добавлю в задание только те машины, которые находятся на UnityVSA. Технически, можно добавить и машины с обычных стораджей, это потребует на одну галочку больше, о чём поговорим дальше.
На шаге Storage:
- Если у вас в задании все машины на одном хранилище, лучше выбрать ту самую прокси, у которой есть доступ до хранилища.
- Если машины лежат на разных, то можно оставить автоматическое определение, если не хотите гнать все данные через один прокси.
Далее заходим в Advanced и открываем вкладку Integration. Именно здесь находится самая важная галочка — Enable backup from storage snapshots, благодаря которой Veeam будет задействовать API хранилища. Здесь же можно ограничить количество машин, которое будет одновременно находиться в снапшоте. Это полезная функция для обладателей очень больших инсталяций и нагруженных систем.
И вторая важная галочка — Failover to standart backup. Если в задании будут машины на хранилищах, не поддерживающих снапшоты, то Veeam будет работать со стандартным снапшотом гипервизора, иначе задание будет сразу завершено с ошибкой.
Больше ничего настраивать не надо. Проходим визард до конца и запускаем бекап. Если всё настроено правильно, то в логе задания будет строчка Creating storage snapshot, а в логе каждой машины можно заметить, что сразу после создания снапшота и сбора информации о дисках снапшот на гипервизоре был удалён. В моём случае машина проработала на снапшоте всего 7 секунд.
Отличный результат, как мне кажется.
И ещё почитать на тему:
