Два года назад я познакомился с новой линейкой массивов Huawei Dorado V6 и начал рассказывать вам о них. Сегодня мы продолжим знакомиться с этими системами и их value-added-функционалом (как называет это вендор), который позволяет расширить возможности системы и добавляет полезные и нужные функции в системы хранения данных. Мы в компании “Онланта” пользуемся богатым набором фич этих систем и хотим немного рассказать о них для вас.
SmartTier
22 января 2021 года в публичный доступ выложили прошивку 6.1 для Dorado V6, в которой появилась поддержка SCM (storage class memory). Теперь наличие накопителей двух классов в системах Dorado дает возможность организации тиринга между быстрым классом (SSD) и сверхбыстрым классом (SCM).
31 августа 2021 года вышла прошивка 6.1.2, с которой стали поддерживаться два типа SCM-накопителей – SCM-карточки и SCM в виде накопителей.
Тиринг работает классическим образом: данные, недавно записанные хостом, предпочтительно записываются на SCM. Это повышает производительность при записи данных. Данные, к которым не было доступа в течение длительного времени, переносятся на уровень SSD. Когда емкость SCM недостаточна, данные записываются на SSD.
Карточки будут трех видов:
U.2 2,5' для контроллеров 3000/5000 с SAS-бэкэндом, максимум четыре накопителя на систему, объём накопителя - 800GB;
PALM SCM для 3000/5000/6000 с NVMe-бэкэндом, максимум восемь накопителей на систему, объём накопителя - 800GB или 1.6TB;
SCM-карты для 8000/16000, максимум восемь накопителей на систему, объём накопителя - 800GB.
SmartCache
SmartCache также появился в системах Dorado V6 с приходом SCM-накопителей. Они более ёмкие, чем DRAM и при этом более производительные, чем просто Flash. Соответственно, благодаря SCM у нас появляется ещё один кэш в виде прослойки между DRAM и Flash.
При записи данных на массив они попадают в DRAM-кэш. Если к этим данным больше нет обращений, они вытесняются из DRAM в SmartCache, а со временем вытесняются вообще из кэша. Соответственно, при чтении данных они будут сначала запрашиваться в DRAM-кэше. При их отсутствии далее следует запрос в SmartCache, а если и там их не оказалось, тогда данные будут читаться уже с SSD-накопителей.
SmartQoS
Quality of Service (QoS) позволяет приоритезировать ввод-вывод на дисковых ресурсах СХД для обеспечения минимальной производительности или ограничения максимальной производительности для исключения негативного влияния. QoS может быть ограничен как сверху, так и снизу. Нижний QoS обеспечивается за счёт ограничений на менее приоритетных LUNах/шарах/снепшотах, пока не будет обеспечена требуемая производительность LUN'а с минимальным QoS. QoS гарантирует не только достаточную производительность самой дисковой подсистемы, но и обеспечение достаточного уровня производительности CPU и кэша для высокоприоритетных сущностей. Функционал полезен для выделения ресурсов СХД для критичных приложений или данных и обеспечения их приемлемой скорости работы. Естественно, если общей производительности системы недостаточно, остальные ресурсы будут страдать от нехватки производительности. При этом, ограничение QoS сверху позволит неожиданно появившейся нагрузке на каком-то из ресурсов не оказать негативное влияние на работу всей системы.
Принцип работы основан на выделении некоторого количества токенов каждому из LUNов/шар. Управление приоритезацией происходит посредством управления очередью ввода-вывода. Если система понимает, что производительности начинает не хватать, то у лунов с меньшим приоритетом (и меньшим количеством токенов) или без настроенных QoS система начинает забирать эти токены, что ограничивает их очередь ввода-вывода, при этом она позволяет луну с более высоким приоритетом продолжать работать на том же уровне.
Также реализован механизм burst, когда система накапливает неиспользуемые токены в тот момент, когда производительность луна находится ниже верхней границы, Это позволяет при увеличении нагрузки превысить верхний лимит на несколько секунд, а после расходования "лишних" токенов производительность будет снова ограничена верхним лимитом.
Уровень burst и его продолжительность могут быть настроены администратором по своему усмотрению.
QoS ограничивает производительность только со стороны хостов и не распространяется на операции через VAAI.
Юзкейсы в данном случае могут быть следующими:
нижний QoS для луна с некой продуктивной БД, которая критична к задержкам и на плечах которой лежит вся работа компании;
верхний QoS для лунов в ночное время по полосе пропускания, чтобы ночное резервное копирование не влияло на работу продуктивных систем.
SmartDeduplication/SmartCompression
Функционал дедупликации и компрессии призван сократить избыточность данных в системе хранения для сохранения её ёмкости, а также уменьшить количество операций записи на накопители. Это позволяет продлить срок жизни SSD-накопителей.
Дедупликация и компрессия не работают для снепшотов. Дедупликация осуществляется на уровне дискового пула. Дедупликация и компрессия поддерживаются только на тонких томах.
Производится инлайн-процессинг, дедупликация и компрессия производятся в кэше контроллера до записи на накопители. Если система испытывает недостаток ресурсов, то инлайн-процессинг прекращается и позже, при высвобождении ресурсов выполняется пост-процессинг.
Система разделяет данные на блоки фиксированного размера и анализирует сходство между блоками. Затем система дедуплицирует идентичные блоки данных и выполняет сжатие аналогичных блоков. По умолчанию размер блока равен 8KB. Сначала выполняется дедупликация, потом компрессия. Для расчета хэшей используется SHA1. Когда система хранения ищет повторяющиеся блоки данных, она сравнивает отпечатки (fingerprints) блоков данных. Если отпечатки совпадают, система побайтово сравнивает блоки данных.
Включить дедупликацию и компрессию на уже созданном луне невозможно. Её можно включать и выключать, если она была включена при создании луна.
Лицензирование: требует лицензии на функционал SmartDedupe и SmartCompression различных уровней (зависит от эффективности дедупа и компрессии), либо приобретения лицензии на эффективную ёмкость.
SmartVirtualization
Технология виртуализации сторонних СХД силами Huawei Dorado позволяет консолидировать ресурсы хранения одной системой Dorado. В случае её использования стоит пристальное внимание уделить именно производительности, чтобы единственная Dorado не стала узким местом в сети хранения.
Для виртуализации сторонних СХД поддерживается только FC-протокол, а для массивов Huawei поддерживается и iSCSI.
При работе данной функции у нас есть дополнительная сущность в системе хранения – eDevLUN.
eDevLUN содержит два вольюма:
Meta volume – вольюм с метаданными (занимает примерно 1% от вольюма с данными) и хранится на Huawei;
Data volume – виртуализованный лун с другой СХД.
Поддерживается два режима работы:
Write back – ACK хоста после попадания в кэш OceanStore;
Write through – ACK хоста после попадания в кэш OceanStore и виртуализованной СХД.
При использовании технологии SmartVirtualization в связке с менее производительными СХД мы имеем возможность получить и увеличение производительности за счёт использования кэша самой Dorado.
При этом виртуализовать другую систему хранения мы можем как онлайн без остановки предоставления доступа сервера к старой СХД, так и с остановкой. Конечно, процесс с остановкой более простой и менее ответственный. При офлайн-тейковере нужно сменить софт мультипасинга предыдущего вендора на Huawei UltraPath. Для онлайн-тейковера поддерживается только встроенный в ОС мультипасинг, иначе тейковер может не произойти.
Лицензирование: если виртуализуется СХД от Huawei, то лицензия не требуется. Если же производится виртуализация системы стороннего вендора, требуется лицензия на функционал.
SmartMigration
SmartMigration – функционал, реализующий любые перемещения данных в пределах массива и между массивами.
В пределах массива – это чаще всего перемещение тома с одной группы дисков на другую или изменение уровня RAID для хранимых данных.
Между массивами SmartMigration обычно является логическим продолжением функциональности SmartVirtualization, которая позволяет вам мигрировать данные незаметно для хоста со старой СХД на новую. Миграция происходит онлайн, прозрачно для хоста ввиду того, что мы уже настроили SmartVirtualization и произвели переключение работы с луном на старой СХД через новый массив Huawei.
Во время миграции данные от хоста пишутся на оба луна (ACK хосту прилетает после записи на вторую систему), т.е. в любой момент можно прервать задание миграции и вернуться к работе с луном на старой СХД или даже разобрать SmartVirtualization и настроить хост на прямую работу со старой СХД.
Таск на миграцию копирует данные из целевого тома внутри луна в целевой том таргетного луна. В момент, когда мы делаем split, происходит обмен идентификаторами Data Volume ID, и тогда луну начинает принадлежать целевой вольюм с перенесенными данными уже на локальной системе. За счёт этого миграция происходит прозрачно для хоста. Таргетный лун содержит вольюм с исходными данными и более не нужен, поэтому удаляется вместе с таском миграции.
Одновременно может мигрировать восемь лунов, а остальные встают в очередь.
Лицензирование: требует отдельной лицензии, но обычно эта лицензия присутствует в базовой поставке. Также возможна покупка услуги миграции (лицензии будут включены в услугу).
SmartContainer
SmartContainer также появился в прошивке 6.1.2. Относиться к этому функционалу можно по-разному, но тем не менее теперь есть возможность запуска контейнеров на системах Huawei Dorado. С одной стороны, это логично, ведь было понятно, что сам ОС СХД использует контейнеры для своей работы. Так почему бы не дать возможность работать с контейнерами и пользователям? С другой стороны, не знаю, кому это будет нужно уже с точки зрения отказоустойчивости, когда все наши ресурсы хранения и вычислительные мощности находятся на одной железке. Но оставим лирику. Итак, у нас есть полноценный Kubernetes, iSulad и даже Helm, но не стоит забывать, что системы Dorado V6 построены на ARM-архитектуре.
Как видно из диаграммы, все сервисы соседствуют в рамках одной системы. Как пишет сама компания Huawei, сервисам, обслуживающим систему хранения данных, выделяются эксклюзивные ресурсы, так что запущенные контейнеры не должны влиять на общую производительность системы.
Что касается отказоустойчивости, то тут ситуация такая же, как и при работе самой СХД. У нас классическая двухконтроллерная (или четырёх) система, и при выходе из строя одного из контроллеров все её процессы продолжат работать на контроллере-партнёре.
Huawei разделяет в системе два типа сетевых интерфейсов:
Front-end – интерфейсный модуль, который используется для связи между хостом и контейнером. Поддерживаются карты 10 Gbit/s or 25 Gbit/s;
Back-end – интерфейсный модуль, который используется для связи между контейнером и системой хранения. Поддерживаются только 25 Gbit/s карты.
Соответственно, для работы с контейнерами у вас должно быть установлено минимум четыре интерфейсных модуля.
Включение поддержки контейнеров потребует перезапуска всех контроллеров.
SmartMulti-Tenant
SmartMulti-Tenant позволяет разделить нашу систему хранения данных на несколько виртуальных систем и отдать каждому из заказчиков свою собственную систему, за рамки которой они не смогут выйти. Эти виртуальные СХД называются vStore. Управление на уровне vStore осуществляется только через CLI.
vStore используют логические интерфейсы (LIF). LIF принадлежит только одному vStore, что обеспечивает логическую изоляцию портов.
Соответственно, для файловых протоколов мы может изолировать порты на уровне LIF'ов, а вот для блочного доступа придётся выделять отдельные физические порты.
В каждом vStore есть независимые экземпляры протокола NAS, включая NFS, iSCSI и FC. В каждом vStore есть свои пользователи, группы пользователей, правило сопоставления пользователей, политики безопасности, общие ресурсы NFS, домен AD, служба DNS, служба NIS и служба LDAP.
Данный функционал полезен, если по каким-то причинам нам необходимо отдать систему нескольким разным пользователям – будь это разные клиенты облачного провайдера или же разные департаменты нашей собственной компании.
HyperReplication
HyperReplication можно назвать базовой технологией для обеспечения DR и резервного копирования.
Может быть использовано два вида репликации.
Синхронная (synchronous) – данные с хоста отправляются одновременно (Dual Wright) на обе системы, и только после успешной записи на обе системы хост получает ACK об успешной записи данных;
Асинхронная (asynchronous) – данные с хоста записываются на первую систему, и хост получает сразу ACK об успешной записи данных. Данные на вторую площадку копируются по расписанию с заданным интервалом. В данном случае для репликации данных используются снепшоты лунов.
Поддерживается технология Fast Wright: первая система не запрашивает вторую о ее готовности начать принимать данные, а сразу отправляет данные и ждёт ответа о получении. При использовании тонких лунов (при первоначальной синхронизации между системами) нулевые блоки не передаются.
Пара – это связь между луном на основной системе и луном на вторичной системе. При репликации данные могут быть синхронизированы только с первичного LUN на вторичный LUN через канал репликации. Перед синхронизацией данных необходимо установить пару между двумя LUN.
Группа консистентности – это набор пар, участвующих в репликации. Например, у нас есть несколько лунов под БД. В случае недоступности основной системы мы должны будем переключить их все. Все они связаны между собой единой информационной системой, и работа без одного из них не может быть продолжена.
Лун на второстепенной системе становится доступен на запись в двух случаях.
Лун (или вся СХД) на основной системе выходит из строя, и каналы удаленной репликации находятся в отключенном состоянии.
Лун выходит из строя, но каналы удаленной репликации находятся в нормальном состоянии. Пара должна быть разделена, прежде чем вы разрешите запись на лун второстепенной системы.
Разделение (Splitting) – это процесс остановки синхронизации данных между первичным и вторичным LUN. Разделение может выполняться для одной пары удаленной репликации или нескольких пар удаленной репликации в группе консистентности. После разделения парное отношение между первичным и вторичным LUN по-прежнему существует, а права доступа хостов к первичному и вторичному LUN остаются неизменными, но процесс синхронизации данных при этом останавливается полностью.
Primary/Secondary Switchover – переключение между первичной и вторичной системами хранения. Может быть выполнено как для конкретного луна, так и для группы консистентности. В данном случае подразумевается ручное запланированное переключение, например, для обслуживания на первичном сайте или иных работах, которые подразумевают полную или частичную недоступность первичной системы хранения. Также Primary/Secondary Switchover используется после восстановления основной системы, чтобы переключиться обратно на её использование.
При синхронизации данных между системами применяются следующие технологии повышения производительности:
Inline-сжатие;
Intelligent-сжатие – система заранее определяет, можно ли сжать данные, предотвращая ненужное сжатие и повышая эффективность передачи.
HyperClone
Предполагает полное (физическое) копирование данных с исходного луна в онлайн. Huawei предлагает этот функционал для защиты данных на случай, если с сорсным луном или данными на нём что-то произойдёт. Это не тонкие клоны как у конкурентов, которые можно было бы использовать для test&dev (для этого используются тонкие снепшоты с возможностью переключения их в режим RW).
По окончании синхронизации данных на исходном и таргетном луне запись с хоста пишется на оба луна до момента совершения split'а (в режиме Write through). После split копия становится полноценным луном и содержит актуальные данные на момент split. После split можно запустить Revers Sync. После Revers Sync split происходит автоматически. Поддерживается не более восьми клонов на один лун.
HyperSnap
Снепшоты мы используем чаще всего для резервного копирования или для клонирования каких-либо систем для их повторного (вероятнее тестового) использования, либо для возможности отката какой-либо системы к исходному состоянию. Huawei в массивах Dorado V6 использует ROW (redirect-on-write) снепшоты, которые я считаю более эффективными с точки зрения производительности по сравнению с COW (copy-on-write) снепшотами. Когда система хранения принимает запрос на запись для изменения существующих данных, она записывает новые данные в новое место и направляет указатель измененного блока данных в новое место, что быстрее предварительного копирования изменяемого блока в область для снепшотов.
Поддерживается каскадирование снепшотов и консистентные группы снепшотов.
Снепшот в системах Dorado V6 является отдельной сущностью, поэтому на него не распространяются QoS, наложенные на лун. Этот момент стоит учитывать при резервном копировании.
Откат текущего состояния можно делать как на исходный лун, так и на предыдущий снепшот. Стоит учитывать, что откат к исходному луну и/или снепшоту и удаление снепшота – это разные операции. Удаление происходит практически моментально, а вот откат занимает некоторое время. Также стоит отметить, что для данной операции по умолчанию задается приоритет – Hight, но он может быть изменен:
Low: 0 MB/s to 5 MB/s;
Medium: 10 MB/s to 20 MB/s;
High: 50 MB/s to 70 MB/s;
Highest: Более 100 MB/s.
Для файловых шар также доступен механизм моментальных снимков, но они доступны только для чтения. После создания объекта HyperSnap клиентские приложения могут получить доступ к снепшоту в каталоге snapshot.
HyperCDP
Это продолжение развития функционала HyperSnap для резервного копирования. По сути это всё тот же HyperSnap, но теперь он позволяет задать расписание для создания снепшотов от нескольких секунд до нескольких дней, недель и месяцев в зависимости от ваших требований. Агрессивные настройки HyperCDP в несколько секунд позволяют снизить RPO и RTO. Далее по заданному расписанию создаются снепшоты заданных томов, и мы также имеем возможность работать с ними как с обычными снепшотами.
HyperNDMP
Функционал, позволяющий осуществлять резервное копирование данных с СХД напрямую на ленточную библиотеку.
Большинство современных продуктов для резервного копирования, такие как Veeam или Commvault, умеют работать с данным протоколом, что позволяет сократить бекапный трафик, не используя для передачи данных "прокси" серверы системы резервного копирования. Восстановление данных также может быть выполнено при помощи NDMP.
Поддерживаются несколько режимов для резервного копирования.
Full backup – полное копирование всех данных.
Differential incremental backup – производится резервное копирование изменённых файлов с момента предыдущей резервной копии.
Cumulative incremental backup – производится резервное копирование изменённых файлов с момента предыдущей полной резервной копии.
Также есть три режима восстановления.
Full recovery – восстановление всех данных.
Direct access recovery (DAR) – ПО СРК читает все данные с ленты, а восстанавливает то, что указывает пользователь.
Non-DAR recovery – ПО СРК последовательно запрашивает части данных с ленточной библиотеки, пока не найдет необходимые для восстановления.
HyperMetro
HyperMetro – реализация метрокластера от компании Huawei. Сегодня сложно представить хотя бы одного производителя СХД, который бы не предлагал собственную реализацию метрокластера. Данный функционал доступен как для блочных лунов, так и для файловых шар.
Синхронизация между системами на уровне лунов делает настройку системы крайне простой и быстрой. Можно собирать группы консистентности из нескольких лунов, если они имеют между собой логическую зависимость на уровне серверов.
СХД между собой могут соединяться по любым типам соединений – Fibre Channel и Ethernet. Сам процесс конфигурирования займёт не более 10 минут (при условии, что на физическом уровне всё уже готово и работает корректно). Как и в случае с SmartVirtualization, нам необходимо будет добавить удалённую систему, после этого создать HyperMetro Domain и уже перейти к настройке HyperMetro Pairs.
Не стоит также забывать, что для корректной работы хостов должен быть сконфигурирован мультипасинг.
Кворумный сервер рекомендуется (может быть как физическим, так и виртуальным на linux), либо используется система арбитража (статический выбор приоритетной системы). Статический арбитраж указывается на уровне пар лунов и может быть заменен на другую площадку в онлайне без последствий. Можно использовать два кворумных сервера, второй из которых будет находится в режиме standby. Кворумный сервер общается с СХД только по Ethernet, используя для этого mgmt или data-порты массива.
Используются те же механизмы Dual Wright и Data Change Log, как и при синхронной репликации. Поддерживается технология Fast Wright: первая система не запрашивает вторую о её готовности начать принимать данные, а сразу отправляет данные и ждёт ответа о получении. При использовании тонких лунов, при первоначальной синхронизации между системами нулевые блоки не передаются.
HyperMetro может работать поверх виртуализованных eDev лунов.
Поддерживается 3DC реализация. Между основными площадками:
A/A (синхронная);
A/P (асинхронная);
Mutual (двухсторонняя, если на обеих площадках есть прод).
Может быть как последовательная DC1->DC2->DC3, так и каскадная DC1->DC2, DC1->DC3. На третью только A/P (асинхронная).
Небольшое заключение
Дополнительный функционал, который есть у систем хранения данных, отлично расширяет их возможности для решения различных задач. Начиная от банальной экономии дискового пространства благодаря дедупликации и сжатию, упрощению копирования данных для тестовых сред при помощи клонирования, облегчению процесса резервного копирования при помощи снепшотов доили для организации DR-решений. При приобретении новой системы хранения стоит заранее подумать о том, что из всего предложенного может понадобиться вам и приобрести соответствующие лицензии на объем или функционал.
