Системы хранения данных

Эксплуатация технически сложного оборудования, типа систем хранения данных, подразумевает наличие у администратора определенных навыков. Однако высокие технологии шагают в массы. И, соответственно, растет число пользователей, впервые столкнувшиеся с ними. Уверены, что статьи в стиле How To являются отличным способом пополнить багаж знаний как для новичков, так и узнать нюансы и особенности для опытных пользователей.

В данной статье мы рассмотрим порядок подключения СХД Qsan к гипервизору VMware ESXi, а также по возможности дадим практические советы по тюнингу настроек для достижения максимальной эффективности использования оборудования.

В рамках данной статьи мы рассмотрим процессы подключения СХД Qsan с использованием блочных протоколов доступа iSCSI и Fibre Channel. Условно в процессе подключения можно выделить несколько основных этапов:

1. Физическая и логическая коммутация
2. Действия на стороне СХД
3. Действия на стороне хоста(ов)

В статье приведены скриншоты настройки гипервизоров ESXi 6.7 под управлением vSphere. В случае Standalone ESXi пункты меню могут называться чуть иначе и ряд настроек отсутствовать.

Физическая и логическая коммутация

Совокупность оборудования и линий связи между СХД и серверами образуют так называемую SAN сеть. Отказоустойчивое подключение участников SAN сети подразумевает постоянное наличие хотя бы одного пути между инициатором (хост) и таргетом (СХД). Т.к. СХД сейчас практически поголовно имеют минимум два контроллера, каждый сервер должен иметь связь с каждым из них. В простейшем варианте серверы подключаются к СХД напрямую. Такой режим работы называют Direct Attach. СХД Qsan поддерживают такой режим работы. В этом случае каждый сервер должен иметь двухпортовую HBA для соединения с каждым контроллером СХД. Т.е. между сервером и СХД будет 2 пути. При наличии максимального количества опциональных портов в таком режиме к СХД можно подключить до 10 серверов через iSCSI или до 8 серверов через Fibre Channel.

В большинстве случаев серверы соединяются с СХД через коммутаторы. Для большей надежности их должно быть два (в общем случае их, конечно же, может быть больше, но это они все равно делятся на две группы фабрики). Этим выполняется защита от выхода из строя самого коммутатора, линка и порта контроллера СХД/HBA. В этом случае каждый сервер и каждый контроллер СХД подключается к каждому коммутатору. Т.е. между каждым сервером и СХД будет 4 пути (в случае двух коммутаторов).

Важные замечания по поводу параметров SAN сети:

• Фабрики между собой не соединяются для изоляции в случае возникновения ошибок в сети;
• Если протокол iSCSI делит использование коммутаторов с другими сервисами, то весь трафик iSCSI должен быть помещен в изолированный VLAN;
• Для протокола Fibre Channel необходимо настроить в коммутаторах зонирование по принципу один инициатор один или несколько таргетов для исключения взаимовлияния серверов друг на друга;
• Для iSCSI соединений со скоростью 10G и выше рекомендуется включить поддержку кадров большого размера (MTU=9000) с целью увеличения производительности. Важно помнить, что необходимо изменить MTU у всех участников сети: порты контроллера СХД, физические коммутаторы, виртуальные коммутаторы vSwitch, порты vKernel.

Для Qsan параметр MTU меняется на каждом порту каждого контроллера в меню iSCSI Ports

Для ESXi параметр MTU меняется у vSwitch: хост Configure Virtual Switches Edit для конкретного коммутатора

Для vKernel параметр MTU меняется хост Configure Virtual Switches Edit Settings для конкретного порта

Для получения инструкций по изменению MTU у физических коммутаторов рекомендуем обратиться к документации конкретного производителя.

Действия на стороне СХД

Необходимые настройки на СХД можно разделить на два этапа:

• Настройка интерфейсов
• Настройка пространства хранения

Настраивать интерфейсы требуется в основном в случае использования протокола iSCSI: необходимо задать IP адреса портов на вкладке iSCSI Ports. IP адреса портов должны быть из разных подсетей, чтобы однозначно маршрутизировался трафик на стороне хоста.

В случае использования интерфейса Fibre Channel ничего настраивать, как правило, не нужно.

Далее необходимо создать пространство хранения. Сначала создается пул группа физических накопителей, работающих совместно. Пулов в пределах СХД может быть несколько. Накопители внутри пула объединяются в соответствии с выбранным при его создании уровнем RAID, обеспечивая заданную надежность. Пулы создаются на вкладке Pools Create Pool, где запускается пошаговый мастер.

• Необходимо выбрать тип пула: thick (место выделяется сразу) или thin (место выделяется по мере заполнения). Отметим, что thick пулы являются более производительными.
• Выбрать конкретные диски
• Уровень RAID
• Указать параметры физических накопителей, влияющие на их производительность. Рекомендуется использовать установки по умолчанию для максимальной скорости:
  • Enable Disk Write Cache
  • Enable Disk Read-ahead
  • Enable Disk Command Queuing
  • Disable Disk Standby
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  Помимо обычных пулов Qsan поддерживает создание AutoTiering пулов при условии активации соответствующей лицензии. С принципом работы таких пулов можно ознакомиться в отдельной статье.

  
  

  После создания пула(ов) необходимо создать тома (volume): Volumes Create volumes. Также запустится пошаговый мастер создания тома.

  
  
  
  
  
  
  
  

  Необходимо задать требуемый размер тома, тип тома выбирается как RAID volume. На свойствах остановимся подробнее.

  
  
  • Block Size размер блока, который будет эмулироваться для хоста. Для ESXi он должен быть 512 байт в силу требований VMware. В противном случае такой диск нельзя будет подключить к ESXi. СХД не сможет установить размер блока меньше, чем у физических накопителей. Поэтому нельзя использовать в СХД диски с разметкой 4Kn (блок 4КБ) совместно с VMware. Требуются накопители 512n или 512e.
  • Background I/O Priority приоритет фоновых задач (расширение, миграция и пр.)
  • Erase Volume Data необходимость зануления создаваемого тома. Значение Fast Erase соответствует записи нулей в первый гигабайт пространства, может быть полезно при повторном использовании дисков с целью удалить остатки предыдущих данных (стереть таблицы размещения). Full Erase запись нулей по всему объему, полезно для достижения максимальной производительности в случае использования RAID 1/10.
  • Enable Cache Mode (Write-back Cache) включение кэша СХД. Очень сильно влияет на производительность.
  • Enable Video Editing Mode снижение производительности ради более стабильных результатов. Для использования совместно с VMware лучше выключить.
  • Enable Read-ahead включение упреждающего чтения. Положительно влияет на производительность.
  • Enable Fast RAID Rebuild при активации данной настройки система будет вести трекинг всех записываемых блоков, чтобы понимать, сколько реальных данных записано на том. В случае выхода из строя диска в составе RAID группы во время ребилда не будут копироваться пустые блоки, что может ускорить данный процесс. Однако стоит помнить, что использование Fast Rebuild снижает производительность при случайном доступе.
  
  

  Заключительным этапом в настройке СХД является публикация томов для доступа к ним со стороны хостов через функционал LUN mapping Map LUN.

  
  
  
  
  
  
  
  
  • Необходимо выбрать протокол доступа: FCP (Fibre Channel) или iSCSI. Доступ к одному и тому же тому может быть только через один протокол.
  • Allowed Host список хостов, которым разрешен доступ к тому. По умолчанию разрешено всем (*). Однако рекомендуется всегда явно указывать разрешения для исключения конфликтов доступа и, соответственно, повреждения файловой системы. Для Fibre Channel указываются WWPN хостов (с возможностью выбора из всех доступных в SAN сети). Для iSCSI указываются IQN хостов. В случае нескольких хостов они добавляются по кнопке Add Host. Со стороны ESXi значения WWPN и IQN можно узнать на вкладке Хост Configure Storage adapters
  
  
  
  
  
  • LUN ID с которым том будет виден хостам. Также по этому идентификатору легко опознать том со стороны сервера. Для корректной работы кластера VMware LUN ID должен быть одинаковым для одного и того же тома для всех узлов кластера.
  
  

  Действия на стороне хоста

  
  

  При использовании протокола iSCSI необходимо выполнить:

  
  
  • один раз добавить Software iSCSI адаптер, если этого не было сделано ранее: Хост Configure Storage adapters Add Software Adapter.
  • Создать отдельные vKernel для работы с iSCSI (минимум два для связи с каждым контроллером СХД). Можно подключить их на существующий vSwitch, но желательно подключить на отдельный, не имеющий Port Group с виртуальными машинами с целью упрощения администрирования. У данного vSwitch должно быть минимум 2 физических линка для отказоустойчивости. vKernel следует назначить IP адреса из разных подсетей, чтобы хост мог однозначно маршрутизировать трафик. Также очень важно для каждого vKernel изменить параметр Failover таким образом, чтобы он использовал только один физический линк, т.к. VMware не поддерживает Teaming для iSCSI. В итоге должно получиться следующее:
  
  

  VMkernel Adapter (vmk#)	Physical Network Adapter (vmnic#)
  iSCSI-1 (СХД Контроллер 1)	Active Adapters vmnic1 Unused Adapters vmnic3
  iSCSI-2 (СХД Контроллер 2)	Active Adapters vmnic3 Unused Adapters vmnic1

  
  

  Установки Failover меняются через изменение настроек Port Group

  
  
  
  
  
  
  
  
  • В свойствах Software iSCSI Initiator необходимо указать адреса таргетов, т.е. СХД на вкладке Dynamic Discovery должны быть введены все используемые IP адреса контроллеров СХД
  
  
  
  
  
  • После любого изменения параметров СХД и SAN сети необходимо выполнить Rescan: Хост Storage Adapter Rescan Storage. Итогом будет появление (т.к. мы добавляем новый том) нового устройства, доступного по 4 путям (согласно топологии подключения через два коммутатора в Dynamic Discovery указано 4 IP адреса портов СХД) с LUN ID = 0, как мы и задавали при публикации на СХД.
  
  
  
  
  

  При использовании протокола Fibre Channel все гораздо проще: достаточно выполнить Rescan для обнаружения нового тома. В нашем примере это том с LUN ID = 1, доступный по 4 путям (по 2 на каждом порту HBA).

  
  
  
  
  

  Следующим шагом будет создание Datastore на новом томе: Хост Actions Storage New Datastore.

  
  

  По умолчанию VMware использует политику работы с многопутевыми устройствами как Most Recently User (MRU). Для большей эффективности и повышения производительности необходимо для каждого Datastore изменить политику на Round Robin, при которой все доступные пути до СХД будут использоваться равномерно. Политика меняется в меню Хост Storage Devices Наше Устройство Properties Edit Multi-Path. После применения политики Round Robin все пути будут использоваться для ввода/вывода (Active I/O).

  
  
  
  
  
  
  
  

  В случае использования кластера из нескольких хостов ESXi действия, описанные выше, необходимо повторить на каждом из хостов кроме создания нового Datastore. Т.к. Datastore уже был создан ранее, он появится у остальных членов кластера после выполнения команды Rescan.

  
  

  В рамках данной статьи конечно же были рассмотрены далеко не все операции, необходимые для каждодневного взаимодействия серверов ESXi и СХД Qsan. Более полная информация содержится в обязательных для ознакомления руководствах пользователей обоих вендоров.

Мы продолжаем цикл публикаций из серии How To для пользователей СХД Qsan. В данной статье пойдет речь о подключении СХД к серверам на базе Windows Server, в том числе при использовании функционала виртуализации Hyper-V.

В статье мы будем рассматривать подключения СХД Qsan с использованием блочных протоколов доступа iSCSI и Fibre Channel. Сам процесс подключения можно разделить на несколько основных этапов:

1. Физическая и логическая коммутация
2. Действия на стороне СХД
3. Действия на стороне хоста(ов)

В статье приведены скриншоты настройки операционной системы Windows Server 2016/2019 с нелокализованным интерфейсом. Часть описания, не относящаяся напрямую к ОС, взята из нашего предыдущего обзора по настройке ESXi.

Физическая и логическая коммутация

Совокупность оборудования и линий связи между СХД и серверами образуют так называемую SAN сеть. Отказоустойчивое подключение участников SAN сети подразумевает постоянное наличие хотя бы одного пути между инициатором (хост) и таргетом (СХД). Т.к. СХД сейчас практически поголовно имеют минимум два контроллера, каждый сервер должен иметь связь с каждым из них. В простейшем варианте серверы подключаются к СХД напрямую. Такой режим работы называют Direct Attach. СХД Qsan поддерживают такой режим работы. В этом случае каждый сервер должен иметь двухпортовую HBA для соединения с каждым контроллером СХД. Т.е. между сервером и СХД будет 2 пути. При наличии максимального количества опциональных портов в таком режиме к СХД можно подключить до 10 серверов через iSCSI или до 8 серверов через Fibre Channel.

В большинстве случаев серверы соединяются с СХД через коммутаторы. Для большей надежности их должно быть два (в общем случае их, конечно же, может быть больше, но это они все равно делятся на две группы фабрики). Этим выполняется защита от выхода из строя самого коммутатора, линка и порта контроллера СХД/HBA. В этом случае каждый сервер и каждый контроллер СХД подключается к каждому коммутатору. Т.е. между каждым сервером и СХД будет 4 пути (в случае двух коммутаторов).

Важные замечания по поводу параметров SAN сети:

• Фабрики между собой не соединяются для изоляции в случае возникновения ошибок в сети;
• Если протокол iSCSI делит использование коммутаторов с другими сервисами, то весь трафик iSCSI должен быть помещен в изолированный VLAN;
• Для протокола Fibre Channel необходимо настроить в коммутаторах зонирование по принципу один инициатор один или несколько таргетов для исключения влияния серверов друг на друга;
• Для iSCSI соединений со скоростью 10G и выше рекомендуется включить поддержку кадров большого размера (MTU=9000) с целью увеличения производительности. Важно помнить, что необходимо изменить MTU у всех участников сети: порты контроллера СХД, физические коммутаторы, физические и виртуальные порты сетевых карт серверов.

Для Qsan параметр MTU меняется на каждом порту каждого контроллера в меню iSCSI Ports

В Windows Server параметр MTU меняется в настройках драйвера адаптера:
Control Panel\Network and Internet\Network Connections Свойства конкретного адаптера Configure Advanced Jumbo Packet (у некоторых адаптеров этот пункт может называться что-то типа Large Packets)

Для получения инструкций по изменению MTU у физических коммутаторов рекомендуем обратиться к документации конкретного производителя.

Действия на стороне СХД

Необходимые настройки на СХД можно разделить на два этапа:

• Настройка интерфейсов
• Настройка пространства хранения

Настраивать интерфейсы требуется в основном в случае использования протокола iSCSI: необходимо задать IP адреса портов на вкладке iSCSI Ports. IP адреса портов должны быть из разных подсетей, чтобы однозначно маршрутизировался трафик на стороне хоста.

В случае использования интерфейса Fibre Channel ничего настраивать, как правило, не нужно.

Далее необходимо создать пространство хранения. Сначала создается пул группа физических накопителей, работающих совместно. Пулов в пределах СХД может быть несколько. Накопители внутри пула объединяются в соответствии с выбранным при его создании уровнем RAID, обеспечивая заданную надежность. Пулы создаются на вкладке Pools Create Pool, где запускается пошаговый мастер.

• Необходимо выбрать тип пула: thick (место выделяется сразу) или thin (место выделяется по мере заполнения). Отметим, что thick пулы являются более производительными.
• Выбрать конкретные диски
• Уровень RAID
• Указать параметры физических накопителей, влияющие на их производительность.
  Рекомендуется использовать установки по умолчанию для максимальной скорости:
  
  • Enable Disk Write Cache
  • Enable Disk Read-ahead
  • Enable Disk Command Queuing
  • Disable Disk Standby

Помимо обычных пулов Qsan поддерживает создание AutoTiering пулов при условии активации соответствующей лицензии. С принципом работы таких пулов можно ознакомиться в отдельной статье.

После создания пула(ов) необходимо создать тома (volume): Volumes Create volumes. Также запустится пошаговый мастер создания тома.

Необходимо задать требуемый размер тома, тип тома выбирается как RAID volume. Рассмотрим их более подробно.

• Block Size размер блока, который будет эмулироваться для хоста. Для Windows Server рекомендуется задать значение 4КБ как наиболее оптимальное.
• Background I/O Priority приоритет фоновых задач (расширение, миграция и пр.)
• Erase Volume Data необходимость зануления создаваемого тома. Значение Fast Erase соответствует записи нулей в первый гигабайт пространства, может быть полезно при повторном использовании дисков с целью удалить остатки предыдущих данных (стереть таблицы размещения). Full Erase запись нулей по всему объему, полезно для достижения максимальной производительности в случае использования RAID 1/10.
• Enable Cache Mode (Write-back Cache) включение кэша СХД. Очень сильно влияет на производительность.
• Enable Video Editing Mode снижение производительности ради более стабильных результатов. Если не предполагается использование тома в системах видеонаблюдения, лучше выключить данный параметр.
• Enable Read-ahead включение упреждающего чтения. Положительно влияет на производительность.
• Enable Fast RAID Rebuild при активации данной настройки система будет вести трекинг всех записываемых блоков, чтобы понимать, сколько реальных данных записано на том. В случае выхода из строя диска в составе RAID группы во время ребилда не будут копироваться пустые блоки, что может ускорить данный процесс. Однако стоит помнить, что использование Fast Rebuild снижает производительность при случайном доступе.

Заключительным этапом в настройке СХД является публикация томов для доступа к ним со стороны хостов через функционал LUN mapping Map LUN.

• Необходимо выбрать протокол доступа: FCP (Fibre Channel) или iSCSI. Доступ к одному и тому же тому может быть только через один протокол.
• Allowed Host список хостов, которым разрешен доступ к тому. По умолчанию разрешено всем (*). Однако рекомендуется всегда явно указывать разрешения для исключения конфликтов доступа и, соответственно, повреждения файловой системы. Для Fibre Channel указываются WWPN хостов (с возможностью выбора из всех доступных в SAN сети). Для iSCSI указываются IQN хостов. В случае нескольких хостов они добавляются по кнопке Add Host. Со стороны Windows значения WWPN и IQN можно узнать через консольную (PowerShell) команду Get-InitiatorPort

• LUN ID с которым том будет виден хостам. Также по этому идентификатору легко опознать том со стороны сервера. В случае использования Windows Cluster для корректной работы LUN ID должен быть одинаковым для одного и того же тома для всех узлов кластера.

Действия на стороне хоста

Первоначально необходимо один раз установить на сервере компонент Multipath IO, который обеспечивает работу многопутевого ввода/вывода. Данное действие производится через стандартный диалог Add Roles and Features

При использовании протокола iSCSI необходимо выполнить:

• В свойствах Software iSCSI Initiator необходимо указать адреса таргетов, т.е. СХД на вкладке Discovery должны быть введены все используемые IP адреса контроллеров СХД
• После обнаружение таргетов к ним необходимо подключиться при помощи кнопки Connect. Отметим важные детали:
  
  • Необходимо добавить подключаемые таргеты в список Избранных, чтобы в случае разрыва соединения происходило автоматическое переподключение
  • Необходимо включить поддержку MPIO
  • Хотя автоматическое определение маршрутизации в большинстве случаев работает корректно, мы все же рекомендуем не пренебрегать явным указанием с какого сетевого интерфейса сервера необходимо подключаться к конкретному таргету (Advanced Settings)
  • Если через один и тот же сетевой интерфейс сервера производится работа с нескольким портами СХД, то подключение через Connect нужно проделать для каждого пути

• После любого изменения параметров СХД и SAN сети необходимо выполнить Rescan в стандартной оснастке управления дисками или в Device Manager. Итогом будет появление (т.к. мы добавляем новый том) нового устройства, доступного в нашем конкретном примере по 4 путям (согласно топологии подключения через два коммутатора в Discovery указано 4 IP адреса портов СХД) с LUN ID = 0, как мы и задавали при публикации на СХД. Также следует убедиться, что для диска установлена политика Round Robin, при которой все доступные пути до СХД будут использоваться равномерно.

При использовании протокола Fibre Channel все гораздо проще: достаточно выполнить Rescan для обнаружения нового тома. В нашем примере это том с LUN ID = 1, доступный по 4 путям. Как и в случае с iSCSI следует убедиться, что для диска установлена политика Round Robin, при которой все доступные пути до СХД будут использоваться равномерно.

Важное замечание касательно конфигурирования MPIO. По умолчанию Windows видит дисковые устройства по отдельности, т.е. каждый путь к устройству это отдельный диск.

Чтобы ОС склеила все одинаковые диски в единое устройство, необходимо в стандартной оснастке MPIO добавить новое устройство как многопутевое. Для iSCSI устройств устанавливается отдельное разрешение. По окончании настройки потребуется перезагрузить сервер. Данную настройку необходимо произвести однократно для каждой СХД. После чего все вновь презентованные диски будут опознаваться ОС как многопутевые.

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

В рамках этой статьи были рассмотрены преимущественно базовые операции, необходимые для подключения серверов Windows Server к СХД Qsan. Для получения более полной информации настоятельно рекомендуется ознакомиться с руководствами пользователей, предоставляемыми обоими вендорами.

Окружающий мир определенно не такой, каким он был десяток лет назад. В то время никто бы не поверил, что за нами будет пристально следить 24 часа в сутки огромное количество видеокамер. Если раньше видеонаблюдение было развернуто лишь в наиболее уязвимых, с точки зрения безопасности, местах, то сейчас редко можно встретить даже мелкий магазинчик без собственных видеокамер. В крупных мегаполисах применяется масштабное наблюдение за улицами, дворами домов и прочими общественными местами. Можно по-разному относиться к постоянному наблюдению за людьми и объектами (кто-то видит в этом безопасность, а кто-то признаки тотального контроля), но решать технические вопросы в данной сфере все равно необходимо.

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

От использования DVR (такие маленькие коробочки, совмещающие в себе софт видеонаблюдения и один или несколько HDD для хранения результатов) сейчас уже почти отказались из-за проблем с масштабированием по производительности, количеству камер и емкости. Поэтому в качестве хранилища выступает либо набор дисков, расположенных внутри сервера, либо внешняя СХД с файловым или блочным доступом.

Собственно, от хранилища, каким бы оно не было, требуются весьма простые на первый взгляд параметры:

• Объем
• Производительность
• Надежность

Объем определяется из количества камер и их типа (считай, разрешения и применяемым ими кодеком), а также глубиной хранения. Любые вменяемые производители камер, а уж тем более вендоры ПО по работе с ними, имеют в открытом доступе калькуляторы для расчета необходимой емкости в зависимости от ваших потребностей. Но в любом случае даже скромный десяток камер с временем хранения в две недели затребует нескольких ТБ дискового пространства. С ростом количества камер и глубины архива потребность в хранилище легко может идти на сотни ТБ и даже ПБ.

С производительностью несколько сложнее. Более 95% времени на хранилище осуществляется запись данных в последовательном режиме (т.е. в максимально комфортном для накопителей). Вместе с тем, периодически происходит поиск по индексной базе и воспроизведение материала. Конечно же на показатель производительности напрямую влияет количество и тип камер. Но современный софт давно научился кэшировать входящие потоки на стороне сервера прежде всего с целью индексации событий и объектов, попавших в объективы камер. Поэтому непосредственная запись на устройство хранения осуществляется крупными порциями по несколько ГБ. Отсюда и требования к хранилищу по части скорости записи относительно невелики: лишь бы успеть записать подготовленный материал за то время, пока набирается следующий. Однако итоговая производительность должна учитывать конкурентные запросы на поиск и воспроизведение, из-за чего массив должен содержать в себе достаточное количество HDD для этого.

О массиве было упомянуто неспроста. Ведь обеспечить первичную надежность (а вместе с тем и требуемую производительность) разумнее всего при помощи RAID. Дальнейшее увеличение надежности возможно уже только лишь за счет дублирования: контроллеров, путей, массива данных.

Внутренние диски сервера могут обеспечить все указанные выше требования лишь отчасти. Так емкость можно нарастить при помощи внешних полок расширения, если требуется обеспечить бОльшую глубину архива. Да и с производительностью дисковой подсистемы едва ли возникнут проблемы при той нагрузке, которую сможет обеспечить сам сервер (точнее ПО видеонаблюдения). А вот с надежностью могут возникнуть вопросы. Ведь будет единая точка отказа в виде самого сервера.

Нивелировать этот недостаток может внешняя система хранения. Если произойдет отказ сервера, потоки с камер можно перенаправить на другие серверы, которые, в свою очередь, могут без проблем получить доступ к пространству хранения временно выбывшего из строя собрата. Также возможно применение двухконтроллерных СХД для исключения самой СХД как точки отказа. Консолидация же множества серверов позволит сэкономить на дисках, не теряя при этом в производительности и той же надежности.

Если сравнивать между собой файловые и блочные протоколы доступа к СХД в контексте систем видеонаблюдения, то SAN системы будут иметь ряд преимуществ из-за более простой и потому более дешевой реализации системы хранения. Ведь чисто блочным СХД не требуются сверхмощное железо и продвинутые возможности встроенной ОС. Функционал типа дедупликации или тиринга будет бессилен перед сжатым видео, которое перезаписывается по кругу. Все это в конечном итоге положительно скажется на стоимости решения, разумеется, в пользу SAN.

Практические советы по построению систем видеонаблюдения

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

Если масштаб системы видеонаблюдения таков, что достаточно 1-2 серверов по обработке потоков, то абсолютно нерентабельно использовать в данной конфигурации внешние СХД (кроме случаев с требованиями к повышенной отказоустойчивости). Достаточно использовать внутренние RAID контроллеры и диски. При большем количестве серверов наличие СХД как раз, наоборот, позволит снизить стоимость решения за счет консолидации дисковых ресурсов.

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

• Производительность в RAID массивах хоть и масштабируется с увеличением количества HDD в группе, но постоянная конкурентная запись видеопотоков от множества серверов не всегда позволит получать требуемые скоростные показатели для каждого из них. Разумным решением будет создание отдельных RAID массивов для групп из 2-4 серверов.
• С точки зрения надежности, при использовании HDD большой емкости необходимо использовать как минимум RAID6 с количеством дисков в группе не более 12-14. В случае использования большего числа дисков необходимо объединять такие группы в RAID60. Также следует учитывать, что, при постоянной записи на массив, ребилд для диска емкостью 10-14ТБ легко может занять 2 и более недели. И различные технологии ускорения вроде Fast Rebuild здесь, увы, не помогут. Если позволяют бюджеты, то для повышения надежности все же стоит рассматривать RAID10.

Интерфейс подключения СХД к серверам не играет большой роли с точки зрения производительности. Поэтому чаще всего используется максимально бюджетный вариант с iSCSI. Более того, в случае прямого подключения сервера к СХД вполне достаточно даже скорости 1GbE, благо дополнительные карты расширения с таким интерфейсом для СХД Qsan стоят дешевле портов 10GbE на коммутаторах. Но если подключение происходит все же с использованием коммутатора(ов), то 10GbE, конечно же, является предпочтительным.

В случае использования двухконтроллерных моделей СХД следует учитывать, что на стороне серверов должна быть поддержка MPIO. Акцент на этом моменте сделан не случайно: достаточно часто с целью удешевления на стороне видеосерверов используются клиентские версии ОС (Windows 7-10 и т.п.), которые не могут работать с MPIO.

Также не следует забывать, что блочный доступ подразумевает монопольное использование дискового ресурса конкретным сервером (кроме случаев кластеризации видеосерверов в виртуальных средах). Поэтому необходимо обязательно со стороны СХД настроить контроль доступа к публикуемым томам при помощи LUN Masking. В случае плановой или аварийной замены видеосервера будет достаточно изменить параметры LUN Masking для продолжения работы.

Если рассматривать выбор конкретной СХД для целей видеонаблюдения, то на эту роль вполне подойдут младшие модели (например, серию XCubeSAN XS12xx), поскольку предполагается работа с обычными HDD, latency которых просто несоизмеримы с производительностью контроллеров. При большом количестве дисков особенно выигрышно будут смотреться конфигурации с использованием полок высокой плотности сторонних производителей, благо Qsan официально поддерживает подобное. Переход на старшие линейки СХД оправдан лишь в тех случаях, когда суммарная потоковая запись на СХД предполагается выше, чем 3 ГБ/с, что характерно для очень больших инсталляций с несколькими десятками видеосерверов.

Номенклатура и возможности СХД Qsan позволяют использовать их в решениях по видеонаблюдению любого масштаба и любой сложности, а возможность установки в них совместимых накопителей делает итоговую стоимость оборудования максимально финансово привлекательной.

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




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

40 лет развития распределённых СХД

Первые сетевые хранилища в привычном нам виде появились в 1980-х. Многие из вас сталкивались с NFS (Network File System), AFS (Andrew File System) или Coda. Спустя десятилетие мода и технологии изменились, а распределённые файловые системы уступили место кластерным СХД на основе GPFS (General Parallel File System), CFS (Clustered File Systems) и StorNext. В качестве базиса использовались блочные хранилища классической архитектуры, поверх которых с помощью программного слоя создавалась единая файловая система. Эти и подобные решения до сих пор применяются, занимают свою нишу и вполне востребованы.

На рубеже тысячелетий парадигма распределённых хранилищ несколько поменялась, и на лидирующие позиции вышли системы с архитектурой SN (Shared-Nothing). Произошёл переход от кластерного хранения к хранению на отдельных узлах, в качестве которых, как правило, выступали классические серверы с обеспечивающим надёжное хранение ПО; на таких принципах построены, скажем, HDFS (Hadoop Distributed File System) и GFS (Global File System).

Ближе к 2010-м заложенные в основу распределённых систем хранения концепции всё чаще стали находить отражение в полноценных коммерческих продуктах, таких как VMware vSAN, Dell EMC Isilon и наша Huawei OceanStor. За упомянутыми платформами стоит уже не сообщество энтузиастов, а конкретные вендоры, которые отвечают за функциональность, поддержку, сервисное обслуживание продукта и гарантируют его дальнейшее развитие. Такие решения наиболее востребованы в нескольких сферах.

Операторы связи

Пожалуй, одними из старейших потребителей распределённых систем хранения являются операторы связи. На схеме видно, какие группы приложений производят основной объём данных. OSS (Operations Support Systems), MSS (Management Support Services) и BSS (Business Support Systems) представляют собой три дополняющих друг друга программных слоя, необходимых для предоставления сервиса абонентам, финансовой отчётности провайдеру и эксплуатационной поддержки инженерам оператора.

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

Наши расчёты показывают, что переход от классических СХД к блочным позволяет сэкономить до 70% бюджета только за счёт отказа от выделенных СХД класса hi-end и использования обычных серверов классической архитектуры (обычно x86), работающих в связке со специализированным ПО. Сотовые операторы уже довольно давно начали приобретать подобные решения в серьезных объёмах. В частности, российское операторы используют такие продукты от Huawei более шести лет.

Да, ряд задач с помощью распределённых систем выполнить не получится. Например, при повышенных требованиях к производительности или к совместимости со старыми протоколами. Но не менее 70% данных, которые обрабатывает оператор, вполне можно расположить в распределённом пуле.

Банковская сфера

В любом банке соседствует множество разношёрстных IT-систем, начиная с процессинга и заканчивая автоматизированной банковской системой. Эта инфраструктура тоже работает с огромным объёмом информации, при этом большая часть задач не требует повышенной производительности и надёжности систем хранения, например разработка, тестирование, автоматизация офисных процессов и пр. Здесь применение классических СХД возможно, но с каждым годом всё менее выгодно. К тому же в этом случае отсутствует гибкость расходования ресурсов СХД, производительность которой рассчитывается из пиковой нагрузки.

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

Озёра данных

На схеме выше приведён перечень типичных потребителей сервисов data lake. Это могут быть службы электронного правительства (допустим, Госуслуги), прошедшие цифровизацию предприятия, финансовые структуры и др. Всем им необходимо работать с большими объёмами разнородной информации.

Эксплуатация классических СХД для решения таких задач неэффективна, так как требуется и высокопроизводительный доступ к блочным базам данных, и обычный доступ к библиотекам сканированных документов, хранящихся в виде объектов. Сюда же может быть привязана, допустим, система заказов через веб-портал. Чтобы всё это реализовать на платформе классической СХД, потребуется большой комплект оборудования под разные задачи. Одна горизонтальная универсальная система хранения вполне может закрывать все ранее перечисленные задачи: понадобится лишь создать в ней несколько пулов с разными характеристиками хранения.

Генераторы новой информации

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

Десять лет назад такими генераторами стали социальные сети, это потребовало создания большого количества новых алгоритмов, аппаратных решений и т. д. Сейчас выделяются три главных драйвера роста объёмов хранения. Первый cloud computing. В настоящее время примерно 70% компаний так или иначе используют облачные сервисы. Это могут быть электронные почтовые системы, резервные копии и другие виртуализированные сущности.
Вторым драйвером становятся сети пятого поколения. Это новые скорости и новые объёмы передачи данных. По нашим прогнозам, широкое распространение 5G приведёт к падению спроса на карточки флеш-памяти. Сколько бы ни было памяти в телефоне, она всё равно кончается, а при наличии в гаджете 100-мегабитного канала нет никакой необходимости хранить фотографии локально.

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

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

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

Какие же проблемы влечет за собой появление новых данных? Первейшая среди них, конечно, сам объём информации и расчётные сроки её хранения. Один только современный автономный автомобиль без водителя каждый день генерирует до 60 Тбайт данных, поступающих со всех его датчиков и механизмов. Для разработки новых алгоритмов движения эту информацию необходимо обработать за те же сутки, иначе она начнёт накапливаться. При этом храниться она должна очень долго десятки лет. Только тогда в будущем можно будет делать выводы на основе больших аналитических выборок.

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

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

Всё это требует выработки новых подходов и алгоритмов хранения и обработки информации. И такие подходы появляются.

Технологии новой эпохи

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



В новых решениях Huawei искусственный интеллект используется уже на уровне самого хранилища, которое оборудовано ИИ-процессором, позволяющим системе самостоятельно анализировать своё состояние и предсказывать отказы. Если СХД подключить к сервисному облаку, которое обладает значительными вычислительными способностями, искусственный интеллект сможет обработать больше информации и повысить точность своих гипотез.

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



Теперь об эволюции носителей данных. Первые флеш-накопители были выполнены по технологии SLC (Single-Level Cell). Основанные на ней устройства были быстрыми, надёжными, стабильными, но имели небольшую ёмкость и стоили очень дорого. Роста объёма и снижения цены удалось добиться путём определённых технических уступок, из-за которых скорость, надёжность и срок службы накопителей сократились. Тем не менее тренд не повлиял на сами СХД, которые за счёт различных архитектурных ухищрений в целом стали и более производительными, и более надёжными.

Но почему понадобились СХД класса All-Flash? Разве недостаточно было просто заменить в уже эксплуатируемой системе старые HDD на новые SSD того же форм-фактора? Потребовалось это для того, чтобы эффективно использовать все ресурсы новых твердотельных накопителей, что в старых системах было попросту невозможно.

Компания Huawei, например, для решения этой задачи разработала целый ряд технологий, одной из которых стала FlashLink, позволившая максимально оптимизировать взаимодействия диск контроллер.

Интеллектуальная идентификация дала возможность разложить данные на несколько потоков и справиться с рядом нежелательных явлений, таких как WA (write amplification). Вместе с тем новые алгоритмы восстановления, в частности RAID 2.0+, повысили скорость ребилда, сократив его время до совершенно незначительных величин.

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



А ещё блочные хранилища данных готовятся встретить NVMe. Напомним, что классическая схема организации доступа к данным работала так: процессор обращался к RAID-контроллеру по шине PCI Express. Тот, в свою очередь, взаимодействовал с механическими дисками по SCSI или SAS. Применение NVMe на бэкенде заметно ускорило весь процесс, однако несло в себе один недостаток: накопители должны были иметь непосредственное подключение к процессору, чтобы обеспечить тому прямой доступ в память.

Следующей фазой развития технологии, которую мы наблюдаем сейчас, стало применение NVMe-oF (NVMe over Fabrics). Что касается блочных технологий Huawei, они уже сейчас поддерживают FC-NVMe (NVMe over Fibre Channel), и на подходе NVMe over RoCE (RDMA over Converged Ethernet). Тестовые модели вполне функциональны, до официальной их презентации осталось несколько месяцев. Заметим, что всё это появится и в распределённых системах, где Ethernet без потерь будет весьма востребован.



Дополнительным способом оптимизации работы именно распределённых хранилищ стал полный отказ от зеркалирования данных. Решения Huawei больше не используют n копий, как в привычном RAID 1, и полностью переходят на механизм EC (Erasure coding). Специальный математический пакет с определённой периодичностью вычисляет контрольные блоки, которые позволяют восстановить промежуточные данные в случае их потери.

Механизмы дедупликации и сжатия становятся обязательными. Если в классических СХД мы ограничены количеством установленных в контроллеры процессоров, то в распределённых горизонтально масштабируемых системах хранения каждый узел содержит всё необходимое: диски, память, процессоры и интерконнект. Этих ресурсов достаточно, чтобы дедупликация и компрессия оказывали на производительность минимальное влияние.

И об аппаратных методах оптимизации. Здесь снизить нагрузку на центральные процессоры удалось с помощью дополнительных выделенных микросхем (или выделенных блоков в самом процессоре), играющих роль TOE (TCP/IP Offload Engine) или берущих на себя математические задачи EC, дедупликации и компрессии.



Новые подходы к хранению данных нашли воплощение в дезагрегированной (распределённой) архитектуре. В системах централизованного хранения имеется фабрика серверов, по Fibre Channel подключённая к SAN с большим количеством массивов. Недостатками такого подхода являются трудности с масштабированием и обеспечением гарантированного уровня услуги (по производительности или задержкам). Гиперконвергентные системы используют одни и те же хосты как для хранения, так и для обработки информации. Это даёт практически неограниченный простор масштабирования, но влечёт за собой высокие затраты на поддержание целостности данных.

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

От интеграции к конвергенции

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

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

Самый совершенный из доступных нам сейчас методов конвергенции подразумевает создание универсальной гибридной системы. Именно такой, какой должна стать наша OceanStor 100D. Универсальный доступ использует те же самые аппаратные ресурсы, логически разделённые на разные пулы, но допускающие миграцию нагрузки. Всё это можно сделать через единую консоль управления. Таким способом нам удалось реализовать концепцию один ЦОД одна СХД.



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

Массовая СХД нового поколения

OceanStor Pacific отвечает требованиям надёжности на уровне шести девяток (99,9999%) и может использоваться для создания ЦОД класса HyperMetro. При расстоянии между двумя дата-центрами до 100 км системы демонстрируют добавочную задержку на уровне 2 мс, что позволяет строить на их основе любые катастрофоустойчивые решения, в том числе и с кворум-серверами.



Продукты новой серии демонстрируют универсальность по протоколам. Уже сейчас OceanStor 100D поддерживает блочный доступ, объектовый доступ и доступ Hadoop. В ближайшее время будет реализован и файловый доступ. Нет нужды хранить несколько копий данных, если их можно выдавать через разные протоколы.



Казалось бы, какое отношение концепция сеть без потерь имеет к СХД? Дело в том, что распределённые системы хранения данных строятся на основе быстрой сети, поддерживающей соответствующие алгоритмы и механизм RoCE. Дополнительно увеличить скорость сети и снизить задержки помогает поддерживаемая нашими коммутаторами система искусственного интеллекта AI Fabric. Выигрыш производительности СХД при активации AI Fabric может достигать 20%.



Что же представляет собой новый узел распределённой СХД OceanStor Pacific? Решение форм-фактора 5U включает в себя 120 накопителей и может заменить три классических узла, что даёт более чем двукратную экономию места в стойке. За счёт отказа от хранения копий КПД накопителей ощутимо возрастает (до +92%).

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



Эти серверы мало подходят для гиперконвергентных решений. Во-первых, приложений для ARM достаточно мало, а во-вторых, трудно соблюсти баланс нагрузки. Мы предлагаем перейти к раздельному хранению: вычислительный кластер, представленный классическими или rack-серверами, функционирует отдельно, но подключается к узлам хранения OceanStor Pacific, которые также выполняют свои прямые задачи. И это себя оправдывает.

Для примера возьмём классическое решение для хранения больших данных с гиперконвергентной системой, занимающее 15 серверных стоек. Если распределить нагрузку между отдельными вычислительными серверами и узлами СХД OceanStor Pacific, отделив их друг от друга, количество необходимых стоек сократится в два раза! Это снижает затраты на эксплуатацию дата-центра и уменьшает совокупную стоимость владения. В мире, где объём хранимой информации растет на 30% в год, подобными преимуществами не разбрасываются.

***

Больше информации о решениях Huawei и сценариях их применения вы можете получить на нашем сайте или обратившись непосредственно к представителям компании.

Обстоятельно аргументируем, что делает OceanStor Dorado 18000 V6 по-настоящему хай-эндовой системой хранения данных с порядочным заделом на ближайшие годы. Заодно развеиваем распространённые опасения относительно All-Flash-хранилищ и показываем, за счёт чего Huawei выжимает из них максимум: end-to-end NVMe, дополнительное кэширование на SCM и целая пачка других решений.

Новый ландшафт данных новое хранение данных

Интенсивность работы с данными повышается во всех отраслях. И банковская сфера тому нагляднейшая иллюстрация. За последние несколько лет число банковских транзакций увеличилось в десять с лишним раз. Как показывает исследование BCG, только в России на отрезке с 2010 по 2018 год количество безналичных транзакций с помощью пластиковых карт показало более чем тридцатикратный рост с 5,8 до 172 на одного человека в год. Дело прежде всего в триумфе микроплатежей: большинство из нас сроднилось с онлайн-банкингом, и банк у нас теперь под рукой в телефоне.

IT-инфраструктура кредитной организации должна быть готова к такому вызову. А это действительно вызов. Помимо всего прочего, если раньше банку требовалось обеспечить доступность данных лишь в свои рабочие часы, то теперь 24/7. Ещё недавно 5 мс считались приемлемой нормой задержкой, и что же? Сейчас даже 1 мс перебор. Для современной системы хранения данных целевое значение 0,5 мс.

То же самое с надёжностью: в 2010-е сформировалось эмпирическое понимание того, что достаточно довести её уровень до пяти десяток 99,999%. Правда, понимание это успело устареть. В 2020 году для бизнеса абсолютно нормально требовать 99,9999% применительно к хранилищу и 99,99999% применительно к архитектурному решению в целом. И это вовсе не блажь, а насущная необходимость: либо временного окна на обслуживание инфраструктуры нет, либо оно крохотное.



Для наглядности удобно спроецировать эти показатели на плоскость денег. Проще всего на примере финансовых организаций. На диаграмме выше указано, какую сумму в течение часа зарабатывает каждый из топ-10 мировых банков. У одного только Промышленного и коммерческого банка Китая это ни много ни мало $5 млн. Ровно во столько обойдётся часовой простой IT-инфраструктуры крупнейшей кредитной организации КНР (причём в расчёте учтена лишь упущенная выгода!). При таком ракурсе видно, что сокращение даунтайма и повышение надёжности не то что на единицы процентов даже на доли процента полностью рационально обоснованны. Не только из соображений повышения конкурентоспособности, но и попросту ради сохранения рыночных позиций.

Сопоставимые изменения происходят в других индустриях. Например, в воздушных перевозках: до пандемии авиасообщение год от года только набирало обороты, и многие стали пользоваться им почти как такси. Что касается потребительских паттернов, в обществе укоренилась привычка к тотальной доступности сервисов: по прибытии в аэропорт нам требуется подключение к Wi-Fi, доступ к платёжным сервисам, к карте местности и т. д. Как следствие, нагрузка на инфраструктуру и сервисы в публичных пространствах возросла многократно. И те подходы к её, инфраструктуры, построению, которые мы считали приемлемыми даже год назад, стремительно устаревают.

Не рано ли переходить на All-Flash?

Для решения задач, о которых было сказано выше, с точки зрения производительности AFA all-flash arrays, то есть полностью построенные на флеше массивы, подходят как нельзя лучше. Разве что до последнего времени сохранялись сомнения в том, сравнимы ли они по надёжности с собранными на основе HDD и с гибридными. В конце концов, у твердотельной флеш-памяти есть такой показатель, как средняя наработка на отказ, или MTBF (mean time between failures). Деградация ячеек вследствие операций ввода-вывода, увы, данность.

Так что перспективы All-Flash омрачал вопрос, как предотвратить гибель данных в том случае, если SSD прикажет долго жить. Резервное копирование вариант привычный, вот только время восстановления было бы неприемлемо большим исходя из современных требований. Другой выход наладить второй уровень хранения на шпиндельных накопителях, однако при такой схеме теряется часть преимуществ строго флешевой системы.

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



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

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

Согласно отчётам агентства ESG, на All-Flash системах хранения данных Dorado V6 реально добиться снижения стоимости владения до 78% на интервале в пять лет в том числе за счёт эффективной дедупликации и компрессии и благодаря невысоким энергопотреблению и тепловыделению. Немецкая аналитическая компания DCIG также рекомендует их к использованию как оптимальные с точки зрения TCO из доступных на сегодняшний день.

Использование твердотельных накопителей даёт возможность экономить полезное пространство, снижает число отказов, сокращает время на обслуживание решения, уменьшает энергопотребление и тепловыделение СХД. И оказывается, что AFA в экономическом отношении как минимум сопоставим с традиционными массивами на шпиндельных накопителях, зачастую же превосходит их.

Роял-флеш от Huawei

Среди наших All-Flash хранилищ топовое место принадлежит hi-end-системе OceanStor Dorado 18000 V6. Да и не только среди наших: целом по индустрии она держит рекорд скорости до 20 млн IPOS в максимальной конфигурации. Кроме того, она чрезвычайно надёжна: пусть даже полетят разом два контроллера, или до семи контроллеров один за другим, или сразу целый движок данные уцелеют. Изрядные преимущества восемнадцатитысячной даёт зашитый в неё ИИ, в том числе гибкость в управления внутренними процессами. Посмотрим, за счёт чего всё это достигается.



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

Контроллер в системах OceanStor Dorado построен на процессоре собственной разработки и производства Huawei Kunpeng 920. В нём задействован модуль управления Intelligent Baseboard Management Controller (iBMC), тоже наш. Чипы ИИ, а именно Ascend 310, которые оптимизируют предсказания по отказам и дают рекомендации по настройкам, также хуавеевские, равно как и платы ввода-вывода модуль Smart I/O. Наконец, и контроллеры в твердотельных накопителях спроектированы и изготовлены нашими силами. Всё это дало базу для того, чтобы сделать интегрально сбалансированное и высокопроизводительное решение.

За последний год мы реализовали проект по внедрению этой, самой топовой своей СХД в одном из крупных российских банков. В результате более 40 единиц OceanStor Dorado 18000 V6 в metro-кластере показывают стабильную производительность: с каждой системы удаётся снять более миллиона IOPS, и это с учётом задержек из-за расстояния.

Сквозной NVMe

Новейшие системы хранения данных Huawei поддерживают end-to-end NVMe, на чём мы неспроста делаем акцент. Традиционно используемые протоколы доступа к накопителям были разработаны в седой айтишной древности: в фундаменте у них SCSI-команды (привет, 1980-е!), которые тянут за собой уйму функций для обеспечения обратной совместимости. Какой способ доступа ни возьми, протокольный overhead в таком случае колоссальный. В итоге у хранилищ, которые используют завязанные на SCSI протоколы, задержка ввода-вывода не может быть ниже 0,40,5 мс. В свою очередь, будучи протоколом, созданным для работы с флеш-памятью и избавленным от костылей ради пресловутой обратной совместимости, NVMe Non-Volatile Memory Express сбивает latency до 0,1 мс, притом не на СХД, а на всём стеке, от хоста до накопителей. Неудивительно, что NVMe лежит в русле трендов развития data storages на обозримое будущее. Сделали ставку на NVMe и мы и постепенно отходим от SCSI. Все производимые сегодня системы хранения данных Huawei, включая линейку Dorado, NVMe поддерживают (правда, как end-to-end он реализован только на передовых моделях серии Dorado V6).

FlashLink: пригоршня технологий

Краеугольная для всей линейки OceanStor Dorado технология FlashLink. Точнее, это термин, объединяющий интегральный набор технологий, которые служат для обеспечения высоких производительности и надёжности. Сюда входят технологии дедупликации и компрессии, функционирования системы распределения данных RAID 2.0+, разделения холодных и горячих данных, цельнострайповой последовательной записи данных (случайные записи, с новыми и изменёнными данными, агрегируются в крупный стек и пишутся последовательно, что повышает скорость чтения-записи).

Помимо всего прочего, FlashLink включает в себя две важные составляющие Wear Leveling и Global Garbage Collection. На них стоит остановиться отдельно.

Фактически любой твердотельный накопитель это СХД в миниатюре, с большим числом блоков и контроллером, который обеспечивает доступность данных. А обеспечивается она в том числе за счёт того, что данные с убитых ячеек перебрасываются в не убитые. Тем самым гарантируется, что их удастся прочитать. Существуют различные алгоритмы такого переноса. В общем случае контроллер старается отбалансировать износ всех ячеек накопителя. У такого подхода есть минус. Когда внутри SSD происходит перемещение данных, число осуществляемых им операций ввода-вывода разительно сокращается. На текущий момент это неизбежное зло.

Таким образом, если в системе много твердотельных накопителей, на графике её производительности вырисовывается пила, с резкими подъёмами и спадами. Беда в том, что какой-то один накопитель из пула может запустить миграцию данных в любой момент, а общий performance снимается единовременно со всех SSD в массиве. Но инженеры Huawei придумали, как избежать возникновения пилы.

Благо и контроллеры в накопителях, и контроллер хранилища, и микрокод у Huawei родные, эти процессы в OceanStor Dorado 18000 V6 запускаются централизованно, синхронно на всех накопителях массива. Причём по команде контроллера СХД и именно тогда, когда нет большой нагрузки по вводу-выводу.

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

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

Как следствие, у OceanStor Dorado 18000 V6 очень короткий период потери производительности на операции Wear Leveling, а выполняется она, в основном когда никаким другим процессам не мешает. Это даёт высокую стабильную производительность на постоянной основе.

Из чего складывается надёжность OceanStor Dorado 18000 V6

В современных системах хранения данных выделяется четыре уровня надёжности:

• аппаратная, на уровне накопителя;
• архитектурная, на уровне оборудования;
• архитектурная вместе с программной частью;
• совокупная, относящаяся к решению в целом.

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



Надёжность накопителей гарантируется в первую очередь ранее описанными Wear Leveling и Global Garbage Collection. Когда SSD выглядит для системы как чёрный ящик, ей невдомёк, как конкретно в нём изнашиваются ячейки. Для OceanStor Dorado 18000 V6 накопители прозрачны, благодаря чему возможна равномерная балансировка по всем накопителям массива равномерно. Таким образом получается значительно продлить срок жизни SSD и заручиться высоким уровнем надёжности их функционирования.



Также на надёжность накопителя влияют дополнительные избыточные ячейки в нём. И наряду с простым резервом в СХД используются так называемые DIF-ячейки, где содержатся контрольные суммы, а также дополнительные коды, позволяющие уберечь каждый блок от единичной ошибки, в дополнение к защите на уровне RAID-массива.



Залогом надёжности архитектурной служит решение SmartMatrix. Вкратце это четыре контроллера, которые сидят на пассивном бекплейне в составе одного движка (engine). Два таких движка соответственно, с восемью контроллерами подключаются к общим полкам с накопителями. Благодаря SmartMatrix, даже если перестанут функционировать семь контроллеров из восьми, сохранится доступ ко всем данным как на чтение, так и на запись. А при потере шести контроллеров из восьми можно будет даже продолжать операции кэширования.



Платы ввода-вывода на том самом пассивном бекплейне доступны всем контроллерам, как по фронтенду, так и по бэкенду. При такой схеме подключения full-mesh, что бы ни выходило из строя, доступ к накопителям всегда сохраняется.



О надёжности архитектуры уместнее всего говорить в контексте вариантов отказов, защиту от которых система хранения данных в состоянии обеспечить.

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



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



Увы, объективно не исключён отказ одиночного компонента. В таком случае производительность на какое-то время просядет: необходимо, чтобы перестроились пути и возобновился доступ по операциям ввода-вывода относительно тех блоков, которые либо пришли на запись, но ещё не были записаны, либо были запрошены на чтение. У OceanStor Dorado 18000 V6 средний тайминг перестроения составляет примерно одну секунду значительно меньше, чем у ближайшего аналога в индустрии (4 с). Достигается это благодаря всё тому же пассивному бекплейну: когда контроллер выходит из строя, остальные сразу видят его ввод-вывод, и в частности какой блок данных не был дозаписан; в итоге ближайший контроллер подхватывает процесс. Отсюда и возможность восстановить производительность буквально за секунду. Надо добавить, интервал стабилен: секунда на один контроллер, секунда на другой и т. д.



В пассивном бекплейне OceanStor Dorado 18000 V6 все платы доступны всем контроллерам без какой-либо дополнительной адресации. А значит, любой контроллер способен подхватить ввод-вывод по любому порту. В какой бы фронтенд-порт ни пришёл ввод-вывод, контроллер готов будет его отработать. Отсюда минимальное число внутренних пересылок и заметное упрощение балансировки.

Балансировка по фронтенду выполняется с помощью драйвера multipathing, и дополнительно осуществляется балансировка внутри самой системы, благо все контроллеры видят все порты ввода-вывода.



Традиционно все массивы Huawei выполнены таким образом, что не имеют единой точки отказа. Замене на горячую, без перезагрузки системы, поддаются все её компоненты: контроллеры, модули питания, модули охлаждения, платы ввода-вывода и пр.



Повышает надёжность системы в целом и такая технология, как RAID-TP. Это название RAID-группы, которая позволяет подстраховаться на случай одновременного выхода из строя до трёх накопителей. Причём ребилд на 1 Тбайт стабильно занимает менее 30 минут. Лучший из зафиксированных результатов в восемь раз быстрее, чем с тем же объёмом данных на шпиндельном накопителе. Таким образом, есть возможность использовать чрезвычайно ёмкие накопители, допустим на 7,68 или даже 15 Тбайт, и не беспокоиться о надёжности системы.

Важно, что ребилд осуществляется не в spare drive, а в spare space резервную ёмкость. В каждом накопителе выделено место, используемое для восстановления данных после отказа. Таким образом, восстановление производится не по схеме много в один, а по схеме много во много, благодаря чему и удаётся заметно ускорить процесс. И до тех пор пока имеется свободная ёмкость, восстановление можно продолжать.



Отдельно следует упомянуть о надёжности решения из нескольких хранилищ в metro-кластере, или, в терминологии Huawei, HyperMetro. Такие схемы поддерживаются на всём модельном ряду наших систем хранения данных и допускают работу и с файловым, и с блочным доступом. Причём на блочном функционирует как по Fibre Channel, так и по Ethernet (в том числе по iSCSI).

В сущности, речь идёт о двунаправленной репликации с одной СХД на другую, при которой реплицированному LUN придан тот же LUN-ID, что и основному. Работает технология прежде всего благодаря консистентности кэшей с двух разных систем. Таким образом, для хоста абсолютно всё равно, с какой стороны он находится: и здесь и там он видит один и тот же логический диск. Как следствие, ничто не мешает развернуть кластер отказоустойчивости, растянутый на две площадки.

Для кворума же используется физическая или виртуальная Linux-машина. Расположена та может быть на третьей площадке, и требования к её ресурсам невелики. Распространённый сценарий арендовать виртуальную площадку исключительно под размещение кворумной VM.

Технология допускает и расширение: два хранилища в metro-кластере, дополнительная площадка с асинхронной репликацией.



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

Те же и ИИ

Как уже было сказано, в OceanStor Dorado 18000 V6 встроены процессоры с алгоритмами искусственного интеллекта Ascend. Задействуются они, во-первых, для прогнозирования отказов, а во-вторых, для формирования рекомендаций по настройке, что также увеличивает производительность и надёжность хранилища.

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



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

Совместимость

В 20192020 годах было много инсинуаций по поводу взаимодействия нашего оборудования с продуктами VMware. Чтобы окончательно пресечь их, ответственно заявляем: VMware партнёр Huawei. Были проведены все мыслимые тесты на совместимость нашего железа с её ПО, и в итоге на сайте VMware в листе hardware compatibility указаны доступные на сегодняшний день СХД нашего производства без каких-либо оговорок. Иначе говоря, с программной средой VMware можно использовать хранилища Huawei, включая Dorado V6, с полноценной поддержкой.



То же касается нашего сотрудничества с Brocade. Мы продолжаем взаимодействовать и проводить тесты на совместимость нашей продукции и по их результатам с полной уверенностью утверждаем, что наши системы хранения данных полностью совместимы с новейшими FC-коммутаторами Brocade.

Что дальше?

Мы продолжаем развивать совершенствовать свои процессоры: они становятся быстрее, надёжнее, растёт их производительность. Улучшаем и чипы ИИ на их базе в том числе выпускаются модули, которые ускоряют дедупликацию и компрессию. Те, кто имеет доступ к нашему конфигуратору, могли заметить, что в моделях Dorado V6 эти карты уже доступны к заказу.

Также мы движемся в сторону дополнительного кэширования на Storage Class Memory энергонезависимой памяти с особо низкими задержками, порядка десяти микросекунд на чтение. Помимо всего прочего, SCM даёт прирост производительности, прежде всего при работе с big data и при решении OLTP-задач. После ближайшего апдейта SCM-карты должны стать доступны для заказа.

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

По результатам теста SPC-1, признанного независимого стандарта в оценке производительности систем хранения данных, full-SSD хранилище корпоративного класса Huawei Dorado 18000 V6 поставило новый мировой IOPS-рекорд и подтвердило своё превосходство на глобальном рынке по другим техническим параметрам, включая время задержки и соотношение цена производительность.



В октябре 2020 года hi-end система хранения данных Dorado 18000 V6 заняла первое место в наиболее авторитетном индустриальном тесте производительности SPC-1. Преодолев отметку 21 млн операций ввода-вывода в секунду, она побила предыдущий отраслевой рекорд: у решения, находящегося теперь на втором месте, максимальный достигнутый показатель в два с лишним раза ниже.



Надо отметить, что высочайшую производительность наша All-Flash СХД удерживала в том числе при работе алгоритмов уплотнения данных (сжатие и компрессия), служащих для повышения эффективности хранения. В общем случае эти процессы могут периодически снижать производительность, однако в Dorado 18000 V6 они оптимизированы таким образом, чтобы избегать подобных спадов или сводить их к минимуму.

Впечатляющие результаты наше хранилище продемонстрировало и по соотношению стоимость производительность: 2,914 юаня, или около $0,436, в расчёте на 1 IOPS. Среднее время отклика системы в ходе проведения теста составило 0,286 мс, что значительно лучше целевого показателя для современных систем хранения данных (0,5 мс). В свою очередь, коэффициент полезного использования ёмкости в рамках SPC-1 был зафиксирован на уровне 68,35% выше, чем у прочих продуктов в топ-10 рейтинга.

Испытания производительности систем хранения данных регулярно проводит независимая, не аффилированная с вендорами организация Storage Performance Council. В ходе бенчмаркинга замеряется, сколько IOPS способна выдавать СХД при произвольных нагрузках ввода-вывода, когда занята обработкой онлайн-транзакций (OLTP) в режиме реального времени. Таким образом удаётся оценить, насколько производительно решение при обслуживании критически важных бизнес-приложений: биллинговых систем, сервисов интернет-банкинга, медицинских информационных систем, ERP-платформ и т. д.

Перечисленные достижения стали возможны в том числе благодаря инновационным решениям, использованным в Dorado 18000 V6: ИИ-чипам Ascend 310, сквозному NVMe, набору технологий FlashLink, архитектуре SmartMatrix и др. В деталях преимущества системы мы недавно описали в отдельном посте на Хабре.

Системы хранения данных Huawei проходят тесты SPC с 2010 года, и это не первый рекорд, поставленный ими.

Полная версия официального отчёта о результатах тестирования доступна на сайте Storage Performance Council.

Привет, меня зовут Павел. Я работаю ведущим системным инженером группы внедрения в департаменте вычислительных систем компании STEP LOGIC. В этом посте я поделюсь своими наблюдениями о флеш-системе хранения данных Huawei OceanStor Dorado V6, которую мы тестировали в полях в инфраструктуре заказчика.

Если дальше ожидаете увидеть данные по полученным в результате тестирования показателям IOPS, то спешу разочаровать. Немного отойду от привычной схемы и сначала расскажу о результатах проверки дополнительных функций. Это позволит оценить возможности ввода в эксплуатацию и дальнейшего обслуживания глазами (и руками) системного администратора, системного инженера со стороны заказчика.

Если система хранения хороша с точки зрения IOPS и Bandwidth, но неудобна в обслуживании и не имеет набора дополнительных возможностей, которые помогают организовать поддержку, миграцию и клонирование системы (точнее ее содержимого) это может стать камнем преткновения.

Подробно остановлюсь на функциях:

• HyperSnap мгновенный виртуальный снимок одна из разновидностей моментальных снимков, фиксация данных в определенный момент времени.
• HyperCDP функция создания мгновенных снимков с высокой частотой (через малый промежуток времени).
• HyperClone создает полные копии исходных данных с использованием расписания. Механизм применяется для резервного копирования, защиты, анализа и тестирования данных. В отличие от классического моментального снимка, на создание клона требуется определенное время, клон не грузит основной LUN.
• SmartQOS позволяет настроить приоритеты ввода-вывода: повысить или понизить приоритет выделенному LUN'у и тем самым управлять скоростью обмена данными.

А о результатах тестирования производительности и отказоустойчивости я напишу во второй части.

О технических параметрах Dorado V6

СХД OceanStor Dorado V6 впервые представлена в сентябре 2019 года. В линейке продуктов пять моделей, условно распределенных на три класса low-end (Dorado 3000), mid-end (Dorado 5000/6000) и hi-end (Dorado 8000/18000). Модели в линейке объединяет схожая архитектура, интерфейс управления и набор функций. Основные различия в максимальной емкости и производительности.

Из отличительных особенностей OceanStor Dorado V6 базируется на процессорах и контроллерах производства компании Huawei. Из-за санкций США Huawei вынуждены были отказаться от процессоров Intel для своих СХД, перейдя на ARM-чипы собственного производства. У флагманских моделей Dorado 8000 V6 и 18000 V6 количество ядер на контроллер переваливает за сотню, а точнее 128 и 192 ядра соответственно. Если быть точным сам чип Kunpeng 920 на архитектуре ARMv8.2 может иметь от 24 до 64 ядер. Такое высокое суммарное количество ядер получается путем установки нескольких подобных процессоров в 1 контроллер.

Ниже речь пойдет о Huawei OceanStor Dorado 3000 V6 (24 ядра на контроллер), которая может применяться как для вспомогательных систем и сервисов, так и в качестве основной СХД для небольших компаний.

Почему выбрана именно Dorado 3000 V6?

Как это часто бывает младшие модели оборудования выглядят не так ярко на фоне представителей hi-end из этой же линейки и незаслуженно получают меньше внимания. Поэтому после 21 миллиона IOPS, которые были достигнуты Huawei на своей OceanStor Dorado 18000 V6, хотелось посмотреть, на что годится самая бюджетная All-flash СХД от Huawei.

Заказчик, совместно с которым проводилось тестирование, планировал купить аналогичную модель СХД, но с увеличенным суммарным сырым объемом и дополнительной полкой расширения (Disk Enclosure). У компании были опасения в части производительности системы, которые мы и постарались преодолеть в процессе тестирования.

Коротко о стенде для тестирования

В тесте мы использовали следующую конфигурацию Huawei OceanStor Dorado 3000 V6:

• пара контроллеров Active-Active с единым кэшем 192 Гб;
• 48 процессорных ядер, по 24 ядра на каждый контроллер;
• восемь SSD-дисков 7,68 Тб;
• две карты расширения Smart-IO 4х16Gb FC;
• две карты расширения Smart-IO 4х10Gb Ethernet.

Примечание. Dorado V6 3000, в отличие от более мощных моделей в этой же линейке, поддерживает установку только накопителей SAS 3.0. NVMe формата Palm доступны начиная с модели 5000 V6.

Рисунок 1. Фронтальная панель установленной в стойку Huawei OceanStor Dorado V6 3000.

Для чистоты эксперимента, чтобы абстрагироваться от нюансов существующей инфраструктуры, уже используемой заказчиком для рабочих целей (и не нагружать лишний раз production SAN), было принято решение подключить СХД к серверу виртуализации (VMware ESXi 6.5) напрямую двумя FC-интерфейсами. Сервер виртуализации обеспечивал работу двух виртуальных машин, в которых мы запускали утилиту генерации и измерения нагрузки VDBench (Oracle), также был установлен драйвер multipath (Huawei Ultrapath).

На СХД мы создали дисковое пространство Storage Pool (далее SP), включающее в себя все восемь SSD дисков, с параметром отказоустойчивости RAID-6 и двумя резервными дисками Hot Spare. Диски LUN, созданные на данном SP, были подключены к виртуальным машинам как RDM-диски.

HyperSnap

HyperSnap представляет собой ни что иное, как Snapshot, созданный на LUN'е. Используется для резервного копирования, тестирования и других задач.

Важно отметить, что такой Snapshot работает по принципу ROW (redirect-on-write), вместо ранее считавшимся классическим COW (copy-on-write). Согласно этому алгоритму, новые данные не заменяют на старые, а записываются на свободное место. Такой Snapshot по сути является таблицей со ссылками. При создании снимка HyperSnap СХД записывает все сведения об изменениях в специально выделенную часть виртуального диска LUN Metadata. Снимок HyperSnap не является полной копией данных и поэтому не занимает много места.

Собственно, алгоритм ROW уже своего рода классика для Flash-массивов.

Рисунок 2. Отличия алгоритмов COW и ROW.

Примечание. Известные системы резервного копирования, например, от Veeam и Commvault, поддерживают интеграцию с инструментами Huawei и могут использовать Snapshot для резервного копирования, расширяя таким образом окно бэкапа (оптимальное время, подходящее для создания копий, когда нагрузка на систему минимальна).

Технология HyperSnap позволяет подключать созданный снимок к серверу подобно обычным логическим дискам LUN. Их можно монтировать не только на чтение, но и на чтение-запись для оперативного подключения актуальных данных к тестовой среде.

На рисунке 3 показан снимок, созданный с именем LUNGroup006_last, прародителем которого является диск LUN LUNGroup006_000. LUNGroup006_000 при этом уже был смонтирован на одной из тестовых виртуальных машин.

Рисунок 3. Мгновенный снимок HyperSnap с именем LUNGroup006.

Подключаем его на тот же хост и следим через интерфейс фирменного драйвера MultiPath от Huawei UltraPath. Эта функция является не только важным элементом отказоустойчивости, но и просто удобным рабочим инструментом, способным прямо с хоста однозначно определить доступные тома.

Рисунок 4. Консоль управления фирменного драйвера MultiPath от Huawei UltraPath.

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

Кроме того, LUN'ы можно добавлять в так называемые Consistency Groups, что позволяет делать снимки указанных данных в один и тот же момент данных. Это крайне важно, если вы придерживаетесь рекомендаций вендоров и раскладываете файлы и логи тех же баз данных по разным LUN'ам.

HyperCDP

Если HyperSnap механизм достаточно традиционный, то HyperCDP развитие Snapshot с возможностью создания снимков один за другим с большой частотой. Проще говоря, это набор мгновенных снимков, который можно создавать по расписанию с задержкой минимум 3 секунды.

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

Помимо функции защиты, HyperCDP имеет еще одно важное преимущество. При использовании данной функции практически не страдает производительность. Это мы и проверим в процессе тестирования.

Для теста заведем на нашей СХД 16 LUN по 512 Гб, подключим их к одной ВМ и дадим нагрузку с помощью бенчмарка VDBench.

Примечание. VDBench сам по себе довольно прост, Oracle распространяет его бесплатно, из сопутствующего ПО требуется лишь установленный JRE.

В вызываемом файле конфигурации необходимо задать параметры, которые будут использоваться при тестировании. Допустим, VDBench будет писать блоком 8 килобайт с 70% полностью рандомного чтения и параметрами дедупликации и компрессии 2 к 1.

На СХД мы также настроим HyperCDP-план, который позволит в процессе делать снимки каждого из 16 LUN'ов с интервалом в 10 секунд. Ограничим эту задачу 500 объектами (для каждого LUN'а). Максимальное же количество в рамках одного плана может быть 60000.

Рисунок 5. Веб-интерфейс с примером созданного HyperCDP-плана.

Остается запустить VDBench с указанными ранее параметрами и наблюдать за текущей производительностью.

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

Рисунок 6. Результаты теста HyperCDP.

Подождем еще немного, пока количество HyperCDP-объектов всех LUN'ов не перевалит за сотню, и проверим еще раз.

Рисунок 7. Результаты теста HyperCDP с количеством объектов более 100.

Подводя промежуточные итоги, стоит отметить, что эмулируемый в рамках теста сервис не испытал каких-либо воздействий в плане деградации производительности, и за полтора часа мы получили 500 снимков 16-ти LUN'ов, что в сумме составляет 8000 объектов.

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

HyperClone

Из названия HyperClone становится очевидно, что эта функция делает точную копию указанного LUN'а.

При этом созданная связка пары исходного и целевого LUN'ов продолжит пребывать в работоспособном состоянии, позволяя синхронизировать данные в любую сторону.

При создании клона также можно выбрать скорость синхронизации:

В отличие от снимков HyperCDP клон не грузит основной LUN. В веб-интерфейсе соответствующего раздела доступна синхронизация в обе стороны: Synchronize и Reversе Sync. Если данные на первичном LUN'е были изменены и должны быть перенесены на вторичный, используется инкрементальная синхронизация, т.к. СХД отслеживает изменения созданных пар.

Примечание. Ранее рассмотренные варианты создания снимков HyperSnap и HyperCDP занимают намного меньше дополнительного пространства на хранилище, т.к. не являются полной копией данных

Рисунок 8. Настройка HyperClone.

Для разрыва связи достаточно удалить созданную пару в разделе веб-интерфейса Data Protection, в закладке Clone Pairs.

Рисунок 9. Удаление клон-пары.

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

SmartQOS

В принципе, сервис SmartQoS штука не новая. Системы, которые обеспечивают нужную полосу пропускания для критичных сервисов за счет приоритизации, существовали и ранее. Использовать разные LUN'ы под различные сервисы совершенно нормальная практика. В этом случае иногда возникает необходимость выставить максимальные показатели производительности по IOPS или Bandwidth на те или иные объекты.

Рисунок 10. Настройка политики SmartQoS.

Такой подход бывает необходим в определенных ситуациях, например, утренний Boot Storm у VDI. Инженеры Huawei учли этот факт есть возможность включать нужный режим QoS по расписанию.

Функция прячется под кнопкой Advanced.

Рисунок 11. Настройка расписания (раздел Advanced).

Выполнить проверку просто необходимо создать политику SmartQOS для одного из LUN'ов с параметрами ниже.

Рисунок 12. Созданная политика SmartQoS001.

Далее снова обратимся к помощи бенчмарка VDBench (в тестировании он встретится еще не раз). СХД с точностью как в аптеке отмеряет нашей эмуляции сервиса предоставляемые IOPS'ы. Для наглядности ниже привожу показания со стороны тестового ПО и со стороны Dorado.

Рисунок 13. Результат выполнения политики SmartQOS.

Выглядит SmartQOS весьма неплохо. По результатам его тестирования могу порекомендовать Dorado к использованию в любой инфраструктуре как для оптимизации работы уже существующих сервисов, так и для изначального планирования, особенно если в СХД размещены крупные базы данных или VDI, требующие особого подхода.

Для последних также важно наличие такой настройки как Burst, когда политика позволяет превысить максимальные значения на определенный срок, задаваемый администратором. Это поможет проще пережить уже упоминаемый ранее Boot Storm. Если у Dorado будет возможность не жертвовать другими сервисами, она спокойно перейдет в режим Burst в политике и обеспечит требуемые параметры производительности.

Подведение итогов для первой части

При подведении итогов принято говорить о преимуществах и недостатках. В данном случае хочется и похвалить, и поругать Huawei за новый веб-интерфейс. В целом, он простой и логичный. Разобраться с ним можно, даже не имея опыта общения с продуктами компании Huawei. С другой стороны, современные интерфейсы должны быть интуитивно понятны во всем. Здесь же выезжающие справа фреймы можно закрыть исключительно нажатием кнопок снизу ОК или Cancel, хотя интуитивно хочется просто тапнуть по неактивному полю страницы.

Что касается результатов тестов они говорят сами за себя. Dorado V6 в реальной жизни выглядит достаточно неплохо, даже в начальной своей конфигурации. По цене младшая Dorado V6 соперничает со многими гибридными СХД, которые показывают куда более скромные результаты в тестах производительности. Ее можно рассматривать к покупке практически под любые сервисы. Разве что для резервного копирования All-flash массивы все еще слишком дороги.

Системы хранения данных, основанные на ДНК, могут стать выходом для человечества, которое генерирует все большие объемы информации. По сравнению со всеми прочими носителями у ДНК просто феноменальная плотность записи данных. Еще одно преимущество в случае ДНК для хранения данных в оптимальных условиях не нужна энергия, причем информацию можно сохранять сотни лет. Через несколько веков данные можно без проблем считать конечно, при условии наличия соответствующих технологий.

Но есть у ДНК и минусы. Например, сейчас еще нет стандартов кодирования информации в нити ДНК. Синтезирование искусственных молекул дело достаточно дорогое, а считывание хранимой информации может занимать дни и недели. Многократное обращение к нитям ДНК за информацией приводит к нарушению структуры молекул, так что в итоге могут возникнуть ошибки. Сейчас предложен метод, который поможет решить некоторые из этих проблем. Система хранения данных (пока что лишь изображений) представляет собой нечто среднее между обычной файловой системой и базой на основе метаданных.

Подробнее о проблемах

Разрабатываемые системы хранения данных в ДНК предусматривают добавление определенных меток последовательностей (sequence tags) к участкам ДНК, которые содержат данные. Для получения необходимой информации в молекулу добавляются участки, которые способны образовывать пары оснований с нужными метками. Все это используется для амплификации полной последовательности. Примерно как пометить каждое изображение в коллекции собственным ID, а затем настроить все так, чтобы амплифицировался один конкретный ID.

Метод достаточно эффективен, но у него есть два ограничения. Во-первых, этап амплификации, который выполняется при помощи процесса полимеразной цепной реакции (ПЦР), имеет ограничения на размер амплифицируемой последовательности. При этом каждый тег занимает часть и так ограниченного пространства, поэтому добавление подробных меток сокращает объем пространства для хранения данных.

Еще одно ограничение заключается в том, что ПЦР, амплифицирующая определенные фрагменты ДНК с данными, потребляет часть исходной библиотеки ДНК. То есть каждый раз, когда мы считываем данные, часть их уничтожается. Ученые сравнивают такой способ поиска информации со сжиганием стога сена для обнаружения иголки. Если это делать часто, в итоге можно потерять вообще всю базу данных. Правда, есть способы восстанавливать потерянные участки, но этот метод не идеален, поскольку при его использовании увеличивается вероятность появления ошибки в ДНК и участках данных.


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

Новая система

Основа технологии капсулы из диоксида кремния, в которых хранятся отдельные файлы. К каждой капсуле прикрепляются ДНК-метки, которые показывают, что в файле. Размер каждой капсулы составляет около 6 микрометров. Благодаря такой системе ученым удалось научиться извлекать отдельные изображения с точностью 100%. Набор файлов, который они создали, не очень велик их всего 20. Но если учитывать возможности ДНК, то масштабировать такую систему можно до секстиллиона файлов.

Закодированы эти 20 файлов были во фрагменты ДНК длиной около 3000 нуклеотидов, это около 100 байт данных. В одну капсулу из кремнезема можно поместить файл размером до гигабайта. После того, как файл помещен в оболочку, на его поверхность помещаются метки из одноцепочечной ДНК. К одной оболочке можно прикрепить несколько меток, которые служат ключевыми словами. Например, рыжий, кот, животное.

Помеченные таким образом капсулы из кремнезема объединяются в единую библиотеку данных. Она не так компактна, как хранилище из чистой ДНК, но зато данные в этом случае не повреждаются.

Поиск файлов

Для поиска файлов используется группа ключевых слов меток. Например, если нужно найти изображение кошки, используются метки оранжевый, кошка и домашний. Для поиска тигра только оранжевый и кошка. Скорость поиска в такой системе пока что очень невелика что-то около 1 кБ в секунду.

Еще одна хитрость связана с тем, что каждая метка связана с флуоресцентными молекулами разного цвета. Поэтому в ходе запроса любые капсулы с нужными метками будут светиться определенным цветом. Сейчас уже есть устройства, которые используют лазеры для разделения объектов по цвету флуоресценции, так что выделить нужные данные технически возможно.

При этом остальная часть библиотеки затрагиваться не будет, а значит, не пострадают данные. Стог сена ради поиска одной иголки сжигать уже не требуется. Дополнительный плюс в возможности логического поиска с разными критериями. Например, условия запроса могут быть сложными: true для кот, false для домашний, true для черный и т.п.

Не только поиск

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

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

Что произошло?

16 сентября вышла новая версия операционной системы iOS 14 для мобильных устройств экосистемы Apple. Обновился также и встроенный браузер Safari не только на смартфонах и планшетах, но и на ноутбуках и десктопах. В новой версии браузера появился встроенный функционал блокировки трекинговых пикселей на сайтах для лучшей защиты пользовательских данных. Блокируются популярные пиксели для веб-аналитики, например:

• Google Tag Manager
• Google Analytics
• Facebook
• Яндекс.Метрика
• Mail.ru (myTarget)
• Doubleclick (Floodlight)
• VK

Вот так это выглядит:

Статистику по заблокированным пикселям можно также отследить в Safari:

И в iPhone и iPad:

Что происходит, если серфить интернет с помощью обновленного браузера Safari:

• ни одна стандартная система веб-аналитики, а значит и бренды, не могут отследить действия пользователя;
• пользователь не попадает в ремаркетинговые аудитории;
• не работает Google Tag Manager.

Как ограничение работает на самом деле?

Многие тематические ресурсы и обозреватели (такие, как Apple Insider и Search Engine Journal) не совсем корректно поняли сообщениями в браузере Safari и вышли с громким сообщением, что трекинг-системы перестали работать. На самом деле обновленная версия браузера не блокирует работу трекинговых систем, а повышает конфиденциальность даннх пользователей и показывает пользователю сообщение о том, какие трекинг-системы обнаружены на веб-сайте.

Как решить проблему?

Весной в Google Tag Manager появилась бета-версия функции настройки отслеживания на стороне сервера (Server-side Tagging).

Как работает Server-side Tagging

Если вкратце, то тегирование на стороне сервера позволяет запускать контейнеры Google Tag Manager на серверном окружении. К сожалению, на данный момент инструмент все еще находится в стадии бета-тестирования, поэтому пока что доступен только вариант установки на серверах Google Cloud Platform, однако будем надеяться, что поддержка других серверов появится в ближайшее время.

Отличия от стандартных контейнеров

Во многом тегирование на стороне сервера похоже на стандартные контейнеры Google Tag Manager:

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

Однако, есть и отличия:

• контейнер серверного типа отличается от web-, app- и AMP-контейнеров;
• триггеры срабатывают не при наступлении событий на сайте, а при получении входящих HTTP-запросов;
• эти HTTP-запросы обрабатываются Клиентом это новая сущность GTM, которая является адаптером между устройством пользователя и серверным контейнером;
• клиент обрабатывает запросы, генерирует объект данных события и выгружает его в виртуальный контейнер, с помощью которого теги могут обращаться к объектам событий, чтобы отправлять данные в сторонние системы.

Вот схема работы нового типа контейнеров:

А вот как выглядит интерфейс отличий от стандартного веб-контейнера совсем немного:

Более подробно про добавление тегов на стороне сервера можно прочитать в официальной документации.

Преимущества Server-side Tagging

С помощью тегирования на стороне сервера мы можем проводить полноценную веб-аналитику без необходимости установки какого-либо пикселя в код сайта. При правильной настройке, мы сможем забыть о блокировке трекинга как со стороны производителей браузеров, так и со стороны плагинов блокировки рекламы (например, AdBlock). Помимо этого, браузер перестает загружать скрипты пикселей с внешних серверов, соответственно, ощутимо возрастает скорость работы сайта для пользователей.

Скорость загрузки сайта

При переносе логики создания и обработки событий на сторону сервера, у нас появляется замечательная возможность убрать из кода сайта огромное количество JS-кода от сторонних поставщиков, что значительно скажется на скорости загрузки и отрисовки страниц в браузере пользователя.

Все данные хранятся у вас

Вы полностью контролируете и владеете всеми данными на сервере Google Cloud:

• сервера Google Cloud обрабатывают только те данные, которые вы хотите обрабатывать;
• вы владеете всеми данными. Google не использует ваши данные для рекламных целей;
• вы всегда знаете и контролируете в каком регионе хранятся ваши данные;
• хранение данных производится со всеми современными стандартами безопасности.

Обходим блокировки трекеров отслеживания

Блокировка трекеров и пикселей обычно осуществляется двумя способами:

• блокируется JS-код от трекеров (пиксели на сайте);
• блокируется домен трекера, чтобы предотвратить отправку данных на него.

С помощью серверного отслеживания мы обходим обе эти проблемы:

• мы переносим логику из пикселей на серверное окружение, не размещая на сайте JS-код, поэтому браузер не сможет его заблокировать;
• мы можем привязать к серверному контейнеру свой домен, поэтому блокировка по домену не будет работать.

Недостатки серверного отслеживания

Дополнительные расходы на сервер в облаке

На данный момент GTM поддерживает размещение серверных контейнеров только на серверах Google Cloud. Стоимость аренды одного сервера начинается от 40 долларов в месяц.

Не все пиксели можно поставить через серверный контейнер

Серверный контейнер работает как замена JS-коду на стороне браузера, поэтому поставщик пикселя должен уметь принимать данные через HTTP-запросы.

Для простого отслеживания, как правило это не является проблемой. Но проблемы могут возникнуть, если в скрипте используется сложный JS-код, который нельзя перенести на сервер, как например в Вебвизоре от Яндекс.Метрики. Он точно не будет работать.

Как внедрить отслеживание на стороне сервера?

1. Создать серверный контейнер в Google Tag Manager;
2. Зарегистрироваться на Google Cloud Platform, создать новый проект и настроить способ оплаты;
3. Развернуть сервер Google Cloud AppEngine;
4. Привязать свой домен к созданному серверу;
5. Перенести теги, триггеры и переменные из веб-контейнера в серверный контейнер GTM.

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