Эксплуатация технически сложного оборудования, типа систем хранения данных, подразумевает наличие у администратора определенных навыков. Однако высокие технологии шагают в массы. И, соответственно, растет число пользователей, впервые столкнувшиеся с ними. Уверены, что статьи в стиле 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 позволяют использовать их в решениях по видеонаблюдению любого масштаба и любой сложности, а возможность установки в них совместимых накопителей делает итоговую стоимость оборудования максимально финансово привлекательной.

Всем привет. Мы продолжаем знакомить вас с системой хранения данных Аэродиск ВОСТОК, выполненной на базе российского процессора Эльбрус 8C.

В этой статье мы (как и обещали) детально разберем одну из популярнейших и интереснейших тем, связанной с Эльбрусами, а именно производительность. На тему производительности Эльбруса есть достаточно много спекуляций, причем абсолютно полярных. Пессимисты говорят, что производительность Эльбруса сейчас никакая, и чтобы догнать топовых производителей потребуются десятилетия (т.е. в условиях нынешней реальности никогда). С другой стороны, оптимисты говорят, что уже сейчас Эльбрус 8C показывает хорошие результаты, а в ближайшие пару лет с выходом новых версий процессоров (Эльбрус 16С и 32С) мы сможем догнать и перегнать ведущих мировых производителей процессоров.

Мы в Аэродиске люди практичные, поэтому пошли самым простым и понятным (для нас) путем: протестировать, зафиксировать результаты и только потом делать выводы. В итоге мы провели довольно большое количество тестов и обнаружили ряд особенностей работы Эльбруса 8С архитектуры e2k (в том числе, и приятных) и, конечно же, сравнили это с аналогичными СХД на процессорах Intel Xeon архитектуры amd64.

Кстати, более подробно о тестах, результатах и о будущем развитии СХД на Эльбрусах мы поговорим на нашем очередном вебинаре "ОколоИТ" 15.10.2020 в 15 00. Зарегистрироваться можно по ссылке ниже.

РЕГИСТРАЦИЯ НА ВЕБИНАР

Тестовый стенд

Мы создали два стенда. Оба стенда состоят из сервера с Linux-ом, подключенного через 16G FC-коммутаторы к двум котроллерам СХД, в которой установлено 12 SAS SSD 960 ГБ дисков (11,5 ТБ сырой емкости или 5,7 ТБ полезной емкости, если используем RAID-10).

Схематично стенд выглядит следующим образом.

Стенд 1 e2k (Эльбрус)

Конфигурация оборудования следующая:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
• Коммутатор FC 16 G 2 шт.
• СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Стенд 2 amd64 (Intel)

Для сравнения с аналогичной конфигурации на e2k использовалась похожая конфигурация СХД с похожим процессором по характеристикам на amd64:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
• Коммутатор FC 16 G 2 шт.
• СХД Aerodisk Engine N2 (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 32 GB DDR4, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Важное замечание: используемые в тесте процессоры Эльбрус 8С поддерживают оперативную память только DDR3, это конечно плохо, но не долго. Эльбрус 8СВ (в наличие его у нас пока нет, но скоро будет) поддерживает DDR4.

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

Для генерации нагрузки мы использовали популярную и проверенную временем программу Flexible IO (FIO).

Обе СХД сконфигурированы согласно нашим же рекомендациям по настройке, исходя из требований к высокой производительности на блочном доступе, поэтому используем дисковые пулы DDP (Dynamic Disk Pool). Чтобы не искажать результаты тестирования, на обеих СХД отключаем, компрессию, дедупликацию и RAM-кэш.

Созданы 8 D-LUN-ов в RAID-10 по 500 ГБ, каждый, суммарный полезный объём составляет 4 ТБ (т.е. примерно 70% от возможной полезной емкости данной конфигурации).

Выполняться будут основные и популярные сценарии использования СХД, в частности:

первые два теста эмулируют работу транзакционной СУБД. В этой группе тестов нам интересны IOPS-ы и задержка.

1) Случайное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random

2) Случайная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random

вторые два теста эмулируют работу аналитической части СУБД. В этой группе тестов нам также интересны IOPS-ы и задержка.

3) Последовательное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

4) Последовательная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

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

5) Последовательное чтение большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

6) Последовательная запись большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

Каждый тест будет длиться один час без учета времени прогрева массива в 7 минут.

Результаты тестов

Результаты тестов сведены в две таблицы.

Эльбрус 8С (СХД Аэродиск Восток 2-Э12)

Intel Xeon E5-2603 v4 (СХД Аэродиск Engine N2)

Результаты получились крайне интересные. В обоих случаях мы хорошо утилизировали процессорные мощности СХД (70-90% утилизации), и при таком раскладе явно бросаются в глаза плюсы и минусы обоих процессоров.

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

Если говорить о случайной нагрузке небольшими блоками, то:

• с точки зрения случайного чтения Intel, безусловно, впереди Эльбруса, разница в 2 раза;
• с точки зрения случайной записи однозначно ничья, оба процессора показали примерно равные и достойные результаты.

В последовательной нагрузке небольшими блоками картина другая:

• и при чтении, и при записи Intel существенно (в 2 раза) опережает Эльбрус. При этом, если у Эльбруса показатель IOPS ниже чем у Intel, но выглядит достойно (200-300 тысяч), то с задержками явная проблема (они в три раза выше чем у Intel). Вывод, текущая версия Эльбруса 8С очень не любит последовательные нагрузки небольшими блоками. Явно есть над чем работать.

А вот в последовательной нагрузке большими блоками картина прямо противоположная:

• оба процессора показали примерно равный результат в MB/s, но есть одно НО. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры amd64). Будем надеяться, что этот успех получит дальнейшее развитие.

Есть ещё одна интересная особенность Эльбруса, на которую внимательный читатель может обратить внимание, посмотрев на таблицу. Если взглянуть на разницу показателей чтения и записи у Intel, то во всех тестах чтение опережает запись в среднем примерно на 50%+. Это норма, к которой все (в том числе и мы) привыкли. Если посмотреть на Эльбрус, то показатели записи значительно ближе к показателям чтения, чтение опережает запись, как правило, на 10 30%, не более.

О чем это говорит? О том, что Эльбрус очень любит запись, а это, в свою очередь, говорит о том, что этот процессор будет очень полезен в задачах, где запись явно преобладает над чтением (кто сказал закон Яровой?), что также является несомненным преимуществом архитектуры e2k, и это преимущество нужно развивать.

Выводы и ближайшее будущее

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

Intel сильно превзошел Эльбрус в случайном чтении небольшими блоками, а также в последовательном чтении и записи небольшими блоками.

При случайной записи небольшими блоками оба процессора показывают равные результаты.

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

Кроме того, Эльбрус в отличии от Intel, одинаково хорошо справляется как с нагрузками чтения, так и с нагрузками записи, в то время как у Intel чтение всегда значительно лучше записи.
Исходя из полученных результатов можно сделать вывод о применимости систем хранения данных Аэродиск Восток на процессоре Эльбрус 8С в следующих задачах:

• информационные системы с преобладанием операций записи;
• файловый доступ;
• онлайн-трансляции;
• видеонаблюдение;
• резервное копирование;
• медиа-контент.

Коллективу МЦСТ есть ещё над чем работать, но результат их работы виден уже сейчас, что, конечно, не может не радовать.

Данные тесты проводились на ядре Linux для e2k версии 4.19, на текущий момент в бета-тестах (в МЦСТ, в Базальт СПО, а также у нас, в Аэродиске) находится ядро Linux 5.4-e2k, в котором, кроме всего прочего, серьезно переработан планировщик и много оптимизаций под скоростные твердотельные накопители. Также специально для ядер ветки 5.х.х АО МЦСТ выпускает новый компилятор LCC версии 1.25. По предварительным результатам, на том же процессоре Эльбрус 8С, собранное новым компилятором новое же ядро, окружение ядра, системные утилиты и библиотеки и, собственно, ПО Аэродиск ВОСТОК позволит получить ещё более значительный прирост производительности. И это без замены оборудования на том же процессоре и с теми же частотами.

Мы ожидаем выхода версии Аэродиск ВОСТОК на базе ядра 5.4 ближе к концу года, и как только работа над новой версией будет завершена, мы обновим результаты тестирования и также опубликуем их здесь.

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

Эльбрус уже сейчас показывает хорошие результаты, если сравнивать его с процессорами amd64 среднего уровня. До верхних в линейке моделей серверных процессоров Intel или AMD 8-ке Эльбруса, конечно, далеко, но она туда и не целилась, для этого будут выпущены процессоры 16С и 32С. Вот тогда и поговорим.

Мы понимаем, что после этой статьи вопросов про Эльбрус станет ещё больше, поэтому мы решили организовать ещё один онлайн-вебинар ОколоИТ, чтобы в прямом эфире на эти вопросы дать ответы.

В этот раз у нас в гостях будет заместитель генерального директора компании МЦСТ, Константин Трушкин. Записаться на вебинар можно по ссылке ниже.

РЕГИСТРАЦИЯ НА ВЕБИНАР

Всем спасибо, как обычно ждем конструктивной критики и интересных вопросов.

В данной статье мы немного поговорим о мониторинге СХД IBM Storwize и других СХД, поддерживающих протоколы CIM/WBEM. Необходимость такого мониторинга оставлена за скобками, будем считать это аксиомой. В качестве системы мониторинга будем использовать Zabbix.

В последних версиях Zabbix компания стала уделять шаблонам гораздо больше внимания стали появляться шаблоны для мониторинга сервисов, СУБД, Servers hardware (IMM/iBMC) через IPMI. Мониторинг СХД пока остаётся вне шаблонов из коробки, поэтому для интеграции в Zabbix информации о статусе и производительности компонентов СХД нужно использовать кастомные шаблоны. Один из таких шаблонов я предлагаю вашему вниманию.


Сначала немного теории.
Для доступа к статусу и статистике СХД IBM Storwize можно использовать:
1) Протоколы CIM/WBEM;
2) RESTful API (в IBM Storwize поддерживается, начиная с ПО версии 8.1.3);
3) SNMP Traps (ограниченный набор trap'ов, нет статистики);
4) Подключение по SSH с последующим удаленным подходит для неторопливого bash-скриптинга.

Интересующиеся могут подробнее ознакомиться с различными методами мониторинга в соответствующих разделах вендорской документации, а также в документе IBM Spectrum Virtualize scripting.

Мы будем использовать протоколы CIM/WBEM, позволяющие получать параметры работы СХД без значительных изменений ПО для различных СХД. Протоколы CIM/WBEM работают в соответствии со Storage Management Initiative Specification (SMI-S). Storage Management Initiative Specification основана на открытых стандартах CIM (Common Information Model) и WBEM (Web-Based Enterprise Management), определяемых Distributed Management Task Force.

WBEM работает поверх протокола HTTP. Через WBEM можно работать не только с СХД, но и с HBA, коммутаторами и ленточными библиотеками.

Согласно SMI Architecture и Determine Infrastructure, основным компонентом реализации SMI является WBEM-сервер, обрабатывающий CIM-XML запросы от WBEM-клиентов (в нашем случае от скриптов мониторинга)

CIM объектно-ориентированная модель, основанная на Unified Modeling Language (UML). Управляемые элементы определяются в виде CIM-классов, у которых есть свойства и методы для представления управляемых данных и функций.

Согласно www.snia.org/pywbem, для доступа к СХД через CIM/WBEM можно использовать PyWBEM open source библиотеку, написанную на Python, и обеспечивающую разработчикам и системным администраторам реализацию протокола CIM для доступа к CIM-объектам и проведения различных операций с WBEM-сервером, работающим согласно SMI-S или другим CIM-спецификациям.
Для соединения с WBEM-сервером используем конструктор класса WBEMConnection:

conn = pywbem.WBEMConnection(server_uri, (self.login, self.password),            namespace, no_verification=True)

Это виртуальное соединение, поскольку CIM-XML/WBEM работает поверх HTTP, реальное соединение происходит в момент вызова методов для экземпляра класса WBEMConnection. В соответствии с IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines (Example C-8, стр. 412), в качестве CIM namespace для СХД IBM Storwize будем использовать root/ibm.

Обратите внимание, что для сбора статистики по протоколу CIM-XML/WBEM, необходимо включить пользователя в соответствующую группу безопасности. В противном случае при выполнении WBEM-запросов, вывод атрибутов экземпляра класса будет пустым.

Для доступа к статистике СХД пользователь, под которым осуществляется вызов конструктора WBEMConnection(), должен обладать правами по крайней мере RestrictedAdmin (есть для code_level > 7.8.0) или Administrator (не рекомендую по соображениям безопасности). Подключаемся к СХД через SSH и смотрим номера групп:
> lsusergrp
id name role remote
0 SecurityAdmin SecurityAdmin no
1 Administrator Administrator no
2 CopyOperator CopyOperator no
3 Service Service no
4 Monitor Monitor no
5 RestrictedAdmin RestrictedAdmin no

Добавляем пользователя zabbix в нужную группу:

> chuser -usergrp 5 zabbix

Кроме того, в соответствии с IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines (стр. 415) нужно включить сбор статистики на СХД. Так, для сбора статистики каждую минуту:
> startstats -interval 1

Проверяем:
> lssystem | grep statistics
statistics_status on
statistics_frequency 1


Чтобы получить все существующие классы СХД, необходимо использовать метод EnumerateClassNames().
Пример:

classnames = conn.EnumerateClassNames(namespace='root/ibm', DeepInheritance=True)for classname in classnames:     print (classname)

Для получения значений параметров СХД предназначен метод EnumerateInstances() класса WBEMConnection, возвращающий список экземпляров CIMInstance().
Пример:

instances = conn.EnumerateInstances(classname,                   namespace=nd_parameters['name_space'])for instance in instances:     for prop_name, prop_value in instance.items():          print('  %s: %r' % (prop_name, prop_value))

Для некоторых классов, содержащих большое множество экземпляров, таких как IBMTSSVC_StorageVolume, полный запрос всех экземпляров может быть довольно медленным. Он может генерировать большие объемы данных, которые должны быть подготовлены СХД, переданы по сети и обработаны скриптом. На такой случай есть метод ExecQuery(), позволяющий получить только интересующие нас свойства экземпляра класса. Этот метод предполагает использование языка запросов, подобного SQL либо CIM Query Language (DMTF:CQL), либо WBEM Query Language (WQL), для опроса CIM-объектов СХД:

request = 'SELECT Name FROM IBMTSSVC_StorageVolumeStatistics'objects_perfs_cim = wbem_connection.ExecQuery('DMTF:CQL', request)

Чтобы определить, какие классы нам нужны для получения параметров объектов СХД, читаем документацию, например How system concepts map to CIM concepts.
Так, для получения параметров (не счётчиков производительности) физических дисков (Disk Drives) будем опрашивать Class IBMTSSVC_DiskDrive, для получения параметров Volumes Class IBMTSSVC_StorageVolume, для получения параметров массивов Class IBMTSSVC_Array, для получения параметров MDisks Class IBMTSSVC_BackendVolume и т.д.

По производительности можно почитать Functional diagrams of the Common Information Model agent (конкретно Block server performance subprofile) и IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines (Example C-11, стр. 415).
Для получения статистики СХД по Volumes, необходимо в качестве значения параметра ClassName указать IBMTSSVC_StorageVolumeStatistics. Необходимые для сбора статистики свойства класса IBMTSSVC_StorageVolumeStatistics можно посмотреть в Node Statistics.
Также, для анализа производительности можно использовать классы IBMTSSVC_BackendVolumeStatistics, IBMTSSVC_DiskDriveStatistics, IBMTSSVC_NodeStatistics.

Для записи данных в систему мониторинга будем использовать механизм zabbix traps, реализованный на python в модуле py-zabbix. Структуру классов СХД и их свойств расположим в словаре в формате JSON.

Загружаем шаблон на сервер Zabbix, убеждаемся что с сервера мониторинга есть доступ к СХД по протоколу WEB (TCP/5989), размещаем конфигурационные файлы, скрипты обнаружения и мониторинга на сервере мониторинга. Далее добавляем в планировщик запуск скриптов. В итоге: мы обнаруживаем объекты СХД (массивы, физические и виртуальные диски, enclosures и многое другое), передаём их в Zabbix discoveries, считываем статус их параметров, считываем статистику производительности (perfomance counters), передаём всё это в соответствующие Zabbix Items нашего шаблона.

Шаблон Zabbix, python-скрипты, структуру классов СХД и их свойств, а также примеры конфигурационных файлов, можно найти здесь: github.com/pavlovdo/pystormon.

Всем привет. Этой статьей мы начинаем знакомить вас с новой версией российской гиперконвергентной системы AERODISK vAIR v2, в частности, со встроенным гипервизором АИСТ, который сейчас получил возможность работать автономно от vAIR, используя внешние СХД.

Изначально мы хотели рассказать о функциональности новой версии vAIR в одной статье, но материала получилось очень много, и мы встали перед выбором: либо сократить материал, либо разбить его на три части. Мы выбрали второй вариант и разбили материал следующим образом:

• Управление кластером и гипервизор АИСТ
• Файловая система ARDFS
• Аппаратные платформы, лицензирование и поддержка

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

Коротко об архитектуре. Основные отличия между первой и второй версией

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

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

• Принцип работы файловой системы ARDFS
• Архитектура vAIR

На уровне большой картинки на данный момент архитектура vAIR v2 выглядит следующим образом:

Ну а теперь переходим к деталям.

Косметические изменения

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

Стандартный блок данных, которым оперирует ARDFS, изменился с 4МБ до 64 МБ. Сделано это было также с целью увеличения производительности ввода-вывода.

Ещё одним маленьким, но приятным бонусом, который получился в результате оптимизации ARDFS и ConfigDB, стало снижение минимальных системных требований по количеству нод в кластере. Первая версия vAIR требовала не менее четырех нод, во второй-же версии начинать можно с трёх нод. Мелочь, но тоже приятно.

АИСТ покинул гнездо

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

Для справки: и АИСТ, и vAIR как два отдельных продукта прошли всю необходимую экспертизу регуляторов и, соответственно, добавлены во всех необходимые гос. реестры Минцифры и Роспатента, чтобы по-честному считаться российским ПО.

Чтобы не было путаницы, поясним. По факту АИСТ и vAIR не являются разными продуктами. Гипервизор АИСТ это составная и обязательная часть гиперконвергентной системы vAIR, при этом АИСТ может использоваться в качестве самостоятельного решения, а также АИСТ может всегда быть обновлен до полноценного vAIR-а.

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

Сценарий 1. Просто гиперконвергент

Тут все просто. АИСТ используется как составная часть vAIR и работает с хранилищем ARDFS. Это то, что было в первой версии, и остается сейчас.

Виртуальные машины, сеть и хранилище работают в рамках одной отказоустойчивой аппаратной платформы (3 ноды+).

Сценарий 2. Просто виртуализация

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

При этом в этой схеме всегда остается возможность добавить локальных дисков во все физические серверы, объединить их быстрым (от 10 Гбит/сек) интерконнектом и обновить лицензию АИСТа до vAIR, получив в итоге гибридный сценарий (см. ниже).

Сценарий 3. Гибридный сценарий

Самый интересный сценарий. Мы одновременно с гиперконвергентом используем в качестве хранилища виртуальных машин сторонние СХД (например ENGINE или ВОСТОК :-)). Полезным является то, что к любой виртуалке, которая хранится на ARDFS, мы можем легко прицепить дополнительные виртуальные диски с СХД. И наоборот, к любой виртуалке, которая лежит на СХД, мы можем прицепить виртуальные диски с ARDFS. Это открывает очень много возможностей, начиная с задач постепенной и бесшовной миграции инфраструктуры между разными хранилищами, заканчивая полезным использованием старых СХД и серверов хранения, которые и выкинуть жалко, и подарить некому.

В итоге, когда мы пишем vAIR, мы имеем ввиду большой продукт в целом гиперконвергентную систему, которая включает в себя гипервизор АИСТ и файловую систему ARDFS. А если мы пишем АИСТ, то имеем в виду только компонент, который отвечает за серверную виртуализацию и виртуальную сеть. Чтобы внести ещё больше ясности, приводим ниже таблицу с разбивкой функционала по компонентам.

Обзор функционала. Что нового и для чего

Функции управления

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

Предусмотрен сценарий развертывания управляющей виртуальной машины (УВМ), которая через RestfulAPI может осуществлять полноценное управление всем кластером.

Кстати RestfulAPI, как понятно выше, есть, он описан и работает (по нему будет отдельная статья). Его спокойно можно использовать для автоматизации операций и интеграции со смежными системами. К примеру, уже сейчас есть интеграция (и, кстати, есть внедрение в продуктив) с российским VDI-решением Термидеск, как раз реализованная на базе нашего API. Плюс ещё несколько продуктов вендоров-партнеров на подходе.

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

Сам интерфейс разбит на несколько логических частей.

1) Основная область управления, в которой выполняются почти все операции

2) Основное меню, которое выдвигается наведением курсора

3) Панель действий, на которой отображаются доступные для выбранного объекта действия.

4) Панель задач, которая показывает, какие задачи выполняются или были выполнены над выбранным объектом, вызывается выбором объекта и последующим кликом по кнопке задачи.

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

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

Лирическое отступление: когда я эту функцию показал моему старому товарищу, который является тру-админом (то есть он админил системы в те славные времена, когда систем ещё не существовало) он воскликнул:
Вы нормальные там??!!! Нельзя админить серьезные системы через мобилу!!!
Хочу отметить, что во втором своём высказывании он, безусловно прав, лазить по серьезным кластерам через мобилку опасно, можно ткнуть не туда и всё как обычно упадёт, но всегда есть НО
Я напомнил ему ситуацию, в которую он попал несколько лет назад, когда потратил примерно 40 минут времени и 10 тонн мата на то, чтобы перезагрузить пару зависших виртуалок на известном гипервизоре, используя свой смартфон. Ноутбука у него с собой не было, а его заказчик с паром из ушей требовал устранить проблему здесь и сейчас.
Вспомнив об этом случае, мой товарищ тру-админ перестал сомневаться в нашей нормальности :-).

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

Гипервизор АИСТ

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

Отказоустойчивость виртуальных машин (HAVM) реализована классическим и понятным образом. Она может быть активна или неактивна для каждой виртуалки, а включается на этапе создания ВМ или в процессе её редактирования.

Если параметр HAVM активен, то в случае отказа ноды кластера, ВМ автоматически перезапуститься на другой ноде.

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

Для защиты данных на уровне ВМ, а также для большей гибкости администрирования предусмотрены мгновенные снимки и клоны (которые можно превратить в шаблоны ВМ соответственно). Важной доработкой и одновременно крайне большой радостью является то, что снэпшоты делаются на горячую (при работающей ВМ) и полностью поддерживают консистентность файловых систем гостевых ОС (Linux, Solaris, Windows, BSD) и ряда поддерживаемых СУБД (пока только PostgreSQL и MySQL). При этом с помощью RestfulAPI никто не мешает реализовать консистентные снимки для других систем внутри гостевой ОС самостоятельно.

Для внешнего хранения из коробки поддерживается NFS, то есть хранить виртуалки можно на распределенном хранилище ARDFS (доступно в vAIR) или на внешней СХД по протоколу NFS. Опционально предусмотрена поддержка блочных внешних СХД по протоколам iSCSI и FC.

Миграция виртуальных машин со сторонних гипервизоров

Миграция, причем неважно откуда и куда, всегда стоит особняком во всей ИТ-жизни. За время полутора лет эксплуатации нашими заказчиками первой версии vAIR они (и мы автоматически) регулярно сталкивались с проблемами миграции виртуальных машин со сторонних гипервизоров в АИСТ. Штатный конвертер KVM штука хорошая, но крайне капризная. Поэтому в vAIR v2 (и в АИСТе соответственно) мы предусмотрели человеческий конвертер ВМ из VMware/Hyper-V прямо в интерфейсе vAIR/АИСТ.

Для конвертации администратор выбирает шару NFS (пока только NFS), где лежат файлы виртуальных машин VMware или Hyper-V. Далее vAIR сам сканирует шару на наличие нужных ему файлов и формирует доступный список для миграции. Далее выбираем целевой пул ARDFS (или внешнюю СХД), то есть куда будем конвертировать, выбираем нужные файлы ВМ (можно несколько, они будут конвертироваться по очереди) запускаем и идём пить пиво.

Когда пиво выпито, новые, уже сконвертированные, виртуалки ждут нас уже внутри vAIR-а в выключенном состоянии.

Мониторинг и логирование

Функции мониторинга реализованы как локально, так и удаленно. Администратор может работать со счетчиками утилизации ресурсов CPU, RAM, сетевых интерфейсов и подсистемой ввода-вывода (IOPS, MB/s, latency), как на уровне отдельных нод, так и на уровне кластера в целом.

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

Для логирования и алертинга предусмотрен журнал событий (ноды, порты, физические диски (SMARTCTL), сенсоры, температура и т.п.) с разбивкой по категориям и возможностью оповещения по электронной почте. Опционально поддерживается SNMP.

Кроме описанных выше возможностей гипервизор АИСТ позволяет выполнять функционал, который мы считаем must have, поэтому сильно его разрисовывать не будем, а просто перечислим:

• Обновление ПО без остановки и миграции виртуальных машин
• Живая миграция ВМ, а в ближайшем будущем с возможностью динамичного распределения ресурсов (а-ля DRS)
• Распределённые виртуальные коммутаторы с поддержкой VLAN-ов
• Расширение кластера без остановки виртуальных машин
• Автоподдержка (автоматическое оповещение производителя и заведение тикетов в тех. поддержку, при согласии заказчика, само собой)
• Метрокластер (отдельная большая функция, которой мы посветим позже отдельную статью)

Детально ознакомиться с особенностями функционала можно в технической документации, которая есть у нас на сайте:

https://aerodisk.ru/upload/Datasheet_AIST_final_11042021.pdf

В завершение первой части

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

На подобные утверждения мы всегда задавали вопрос.

А эти компании сразу появились на свет с тысячей бородатых разрабов в толстых свитерах?

ИЛИ другой вариант

А вы когда родились вам сразу было 35 лет, у вас была машина, семья, дача, работа и образование? Это в комплекте вам врачи в роддоме выдавали?

В продолжении этой мысли позволим себе процитировать нашу же старую статью:

притча на эту тему.

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

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

В жизни это совсем не так. Практически всегда (за редким исключением), новый серьезный продукт создается небольшим коллективом до 10 человек (а обычно 2-3). При этом на этапе создания закладывается 80% всего функционала продукта. Далее продукт силами этого маленького коллектива выходит на рынок (или как-то еще громко заявляет о себе), и там его уже подхватывают инвесторы (фонды, холдинги или крупные производители).

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

На этом мы завершаем первую часть цикла статей про vAIR v2. В следующей статье подробно расскажем о функционале файловой системы ARDFS.

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

Голосование доступно тут, на Хабре, а также в нашем телеграм-чате https://t.me/aerodisk

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

Тестирование СХД Аэродиск Восток на базе процессоров Эльбрус 8С на новом ядре 5.4 показало крайне позитивный результат: 1,4 миллиона IOPS! Пока оптимисты верили и надеялись, а пессимисты снисходительно улыбались, программисты работали писали код. В итоге новая версия ядра Линукс v5.4 для архитектуры Эльбрус позволила в разы улучшить производительность подсистемы ввода-вывода и полностью реализовать процессора Эльбрус 8С/СВ для систем хранения данных.

По этому прекрасному поводу мы в Аэродиске, предварительно обновив боевую версию встроенного Альт-Линукса в СХД ВОСТОК до ядра 5.4, повторно выполнили нагрузочное тестирование СХД, которое мы публиковали полгода назад. С прошлым отчетом можно ознакомиться по данной ссылке.

Новые тесты проводились на долгожданном ядре Линукс для e2k версии 5.4, которое появилось начале 2021 года, за что хотим сказать огромное спасибо коллективам разработчиков МЦСТ, Базальт СПО, а также Михаилу Шигорину лично.

В ядре 5.4 изменений много, но нас интересуют только основные изменения с точки зрения СХД, а их можно разделить на следующие группы:

Общие обновления:

• переработан планировщик ввода-вывода, что позволяет лучше параллелить IO между дисками;
• много мелких оптимизаций под скоростные твердотельные накопители;
• и самое главное изменение новый компилятор от МЦСТ (LCC версии 1.25).

Обновления от Аэродиска:

• обновлённый таргет-драйвер, который позволяет лучше параллелить IO между процессорными ядрами;
• обновление логики работы связки ядро процессора диск для систем на Эльбрусе.

Тестовый стенд

Тестирование мы выполняли на том же железе, что и в прошлый раз. Стенд состоит из сервера с Линуксом, подключенного через FC-коммутатор к двум контроллерам СХД Восток, в которой установлено 12 SAS SSD дисков.

Конфигурация оборудования следующая:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
• Коммутатор FC 16G 1 шт.
• СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Ниже схема стенда.

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

Также как и в прошлый раз для нагрузочных тестов мы использовали популярную и проверенную временем программу Flexible IO (FIO).

СХД сконфигурирована исходя из наших рекомендаций к высокой производительности на блочном доступе или просто настройки для ALL-Flash систем. Поэтому используем не менее двух дисковых пулов DDP (Dynamic Disk Pool). Чтобы не бить в одну точку и максимально реализовать вычислительный потенциал платформы создаем несколько LUN-ов в RAID-10 (8 шт. по 500 ГБ каждый).

Все LUN-ы презентуем двум контроллерам (пополам, по 4 каждому), чтобы максимально утилизировать все ресурсы СХД.

В ходе тестирование будут выполняться следующие популярные сценарии использования СХД, в частности:

Последовательная нагрузка маленькими блоками 4k

• 100%_read_4k_sequential
• 100%_write_4k_sequential

Случайная нагрузка маленькими блоками 4k

• 100%_read_4k_random
• 100%_write_4k_random

Последовательная нагрузка большими блоками 128k

• 100%_read_128k_sequential
• 100%_write_128k_sequential

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

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

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

Результаты тестов

Последовательная нагрузка маленькими блоками 4k

100%_read_4k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_4k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Результаты теста с использованием последовательного характера нагрузки небольшими блоками 4k нас впечатлили, получилось !1,4 миллиона! IOPS на чтение и 700k на запись. Если сравнивать это с предыдущим нашим тестом на ядре 4,19 (371k и 233k IOPS), то это скачек в четыре раза при том, что железо мы не меняли.

Также отмечаем довольно небольшую утилизацию CPU, она примерно на 20% ниже предыдущего теста (69/71% против 76/92%).
Задержки при этом остались на том же уровне, что и полгода назад, это не значит, что с этим мы думаем мириться, это значит, что над этим мы ещё будем работать. В конце статьи, будет итоговая таблица сравнения с тестом полугодовой давности на ядре 4,19.

Случайная нагрузка маленькими блоками 4k

100%_read_4k_random
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_4k_random
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Показатели случайной нагрузки маленькими блоками, характерной для транзакционных СУБД остались практически без изменений по сравнению с прошлым тестом. СХД Восток на Эльбрусе вполне нормально справляется с подобными задачами, выдавая 118k IOPS на чтение и 84k IOPS на запись при довольно высокой утилизации CPU.

Отмечаем, что для Эльбруса в отличии от других процессоров работа в режиме постоянной загрузки близкой к 100% является штатной ситуацией (он для этого создавался). Мы это проверяли, оставляя СХД Восток с нагруженным процессором под 95% на несколько дней и результат был следующий: 1) процессор был холодный; 2)процессор и система в целом работали в нормальном режиме. Поэтому к высокому уровню утилизации процессоров Эльбрус следует относиться спокойно.

Также с прошлого ядра сохранилась приятная особенность. Если посмотреть на задержки при случайной нагрузке маленькими блоками, то внимание привлекает то, что задержки на запись ниже, чем на чтение (3 мс против 8 мс), когда мы все привыкли, что должно быть наоборот. Эльбрус с точки зрения случайного характера нагрузки по-прежнему любит запись больше чем чтение, что несомненно является отличным преимуществом, которое грех не использовать.

Последовательная нагрузка большими блоками 128k

100%_read_128k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_128k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Ещё полгода назад СХД Восток на базе процессоров Эльбрус показала отличный результат в тесте последовательной нагрузки большими блоками, что актуально для видеонаблюдения или трансляций. Особой фишкой Эльбруса были ультранизкие задержки при работе с большими блоками (0,4-0,5 мс против 5 6 мс у аналогичного процессора архитектуры x-86).

При чтении данных большими блоками данное преимущество удалось не только закрепить, но и развить. Максимальную скорость на новом ядре удалось поднять в два раза (5,7 ГБ/с на ядре 5.4 против 2,6 ГБ/с на ядре 4.19) при задержках 0,3 мс! Также нагрузка на процессор при данном тесте тоже выглядит лучше (52% на 5,4 против 75% на 4,19).

А вот с записью не так все радужно. К сожалению, в новой версии ядра получить ультранизкие задержки на запись уже не удается, во всяком случае пока. Они находятся на уровне 11 мс (а было 0,5 мс), что в целом не плохо, т.к. примерно такой же уровень задержек при таком тесте мы видим на процессорах других архитектур. Так или иначе это наше домашнее задание, над которым мы будем работать. При этом позитивный момент все-таки есть. Как и в других тестах утилизация процессора значительны снижена (74% против 95%).

Итоговые результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8 С, ядро 5.4

Улучшение в 5.4 зеленые, ухудшения 5.4 оранжевые

Для сравнения, результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8С, ядро 4.19

Улучшение в 5.4 зеленые, ухудшения в 5.4 оранжевые

Прогресс виден не вооруженным глазом! Новая версия ядра 5.4 для архитектуры Эльбрус позволила выжать практические максимумы из совсем не нового процессора Эльбрус 8С (2016 г. выпуска). На данный момент даже у самых ярых пессимистов уже не повернется язык назвать процессор Эльбрус медленным, все таки полтора миллиона IOPS это много.

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

Кроме того, Эльбрус отлично себя показывает в случайной нагрузке на запись, показывая минимальные задержки, что актуально для классических транзакционных СУБД.

Безусловно есть ещё над чем работать (те же задержки при записи больших потоков), но за прошедшие полгода коллектив МЦСТ проделал титаническую работу, и она дала видимый результат, что не может не радовать.

В конце этого 21-ого года мы ожидаем новый процессор Эльбрус 16С, который, кроме того что будет намного быстрее, ещё будет поддерживать аппаратную виртуализацию, а это значит что у нас в России наконец-то появится полностью отечественные не только СХД, но и системы виртуализации, и гиперконвергентные системы (кто сказал АИСТ и vAIR?))).

Кстати о птичках! В течение этой недели мы определимся с датами следующего технического вебинара ОколоИТ про нашу систему виртуализации АИСТ и гиперконвергентную систему vAIR, ссылка на регистрацию появится в этой статье (следите за обновлением), а также в нашем телеграмм-чате.
Ну и само собой, не можем не напомнить о бесплатных курсах по системам Аэродиск, на которые можно записаться тут.

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

TL;DR: Вводная статья с описанием разных вариантов хранения данных. Будут рассмотрены принципы, описаны преимущества и недостатки, а также предпочтительные варианты использования.

Зачем это все?

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

Надежно хранить данные в больших объемах, а также выдерживать отказы физических носителей весьма интересная и сложная инженерная задача.

Хранение данных

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

По способу подключения есть следующие варианты:

• Внутреннее. Сюда относятся классическое подключение дисков в компьютерах, накопители данных устанавливаются непосредственно в том же корпусе, где и будут использоваться. Типовые шины для подключения SATA, SAS, из устаревших IDE, SCSI.

подключение дисков в сервере

• Внешнее. Подразумевается подключение накопителей с использованием некоторой внешней шины, например FC, SAS, IB, либо с использованием высокоскоростных сетевых карт.

дисковая полка, подключаемая по FC

По типу используемых накопителей возможно выделить:

• Дисковые. Предельно простой и вероятно наиболее распространенный вариант до сих пор, в качестве накопителей используются жесткие диски
• Ленточные. В качестве накопителей используются запоминающие устройства с носителем на магнитной ленте. Наиболее частое применение организация резервного копирования.
• Flash. В качестве накопителей применяются твердотельные диски, они же SSD. Наиболее перспективный и быстрый способ организации хранилищ, по емкости SSD уже фактически сравнялись с жесткими дисками (местами и более емкие). Однако по стоимости хранения они все еще дороже.
• Гибридные. Совмещающие в одной системе как жесткие диски, так и SSD. Являются промежуточным вариантом, совмещающим достоинства и недостатки дисковых и flash хранилищ.

Если рассматривать форму хранения данных, то явно выделяются следующие:

• Файлы (именованные области данных). Наиболее популярный тип хранения данных структура подразумевает хранение данных, одинаковое для пользователя и для накопителя.
• Блоки. Одинаковые по размеру области, при этом структура данных задается пользователем. Характерной особенностью является оптимизация скорости доступа за счет отсутствия слоя преобразования блоки-файлы, присутствующего в предыдущем способе.
• Объекты. Данные хранятся в плоской файловой структуре в виде объектов с метаданными.

По реализации достаточно сложно провести четкие границы, однако можно отметить:

• аппаратные, например RAID и HBA контроллеры, специализированные СХД.

RAID контроллер от компании Fujitsu

• Программные. Например реализации RAID, включая файловые системы (например, BtrFS), специализированные сетевые файловые системы (NFS) и протоколы (iSCSI), а также SDS

пример организации LVM с шифрованием и избыточностью в виртуальной машине Linux в облаке Azure

Давайте рассмотрим более детально некоторые технологии, их достоинства и недостатки.

DAS

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

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

SAN

Storage area network, она же сеть хранения данных, является технологией организации системы хранения данных с использованием выделенной сети, позволяя таким образом подключать диски к серверам с использованием специализированного оборудования. Так решается вопрос с утилизацией дискового пространства серверами, а также устраняются точки отказа, неизбежно присутствующие в системах хранения данных на основе DAS. Сеть хранения данных чаще всего использует технологию Fibre Channel, однако явной привязки к технологии передачи данных нет. Накопители используются в блочном режиме, для общения с накопителями используются протоколы SCSI и NVMe, инкапсулируемые в кадры FC, либо в стандартные пакеты TCP, например в случае использования SAN на основе iSCSI.

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

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

NAS

Network attached storage, или сетевое файловое хранилище, представляет дисковые ресурсы в виде файлов (или объектов) с использованием сетевых протоколов, например NFS, SMB и прочих. Принципиально базируется на DAS, но ключевым отличием является предоставление общего файлового доступа. Так как работа ведется по сети сама система хранения может быть сколько угодно далеко от потребителей (в разумных пределах разумеется), но это же является и недостатком в случае организации на предприятиях или в датацентрах, поскольку для работы утилизируется полоса пропускания основной сети что, однако, может быть нивелировано с использованием выделенных сетевых карт для доступа к NAS. Также по сравнению с SAN упрощается работа клиентов, поскольку сервер NAS берет на себя все вопросы по общему доступу и т.п.

Unified storage

Универсальные системы, позволяющие совмещать в себе как функции NAS так и SAN. Чаще всего по реализации это SAN, в которой есть возможность активировать файловый доступ к дисковому пространству. Для этого устанавливаются дополнительные сетевые карты (или используются уже существующие, если SAN построена на их основе), после чего создается файловая система на некотором блочном устройстве и уже она раздается по сети клиентам через некоторый файловый протокол, например NFS.

SDS

Software-defined storage программно определяемое хранилище данных, основанное на DAS, при котором дисковые подсистемы нескольких серверов логически объединяются между собой в кластер, который дает своим клиентам доступ к общему дисковому пространству.

Наиболее яркими представителями являются GlusterFS и Ceph, но также подобные вещи можно сделать и традиционными средствами (например на основе LVM2, программной реализации iSCSI и NFS).

N.B. редактора: У вас есть возможность изучить технологию сетевого хранилища Ceph, чтобы использовать в своих проектах для повышения отказоустойчивости, на нашем практическим курсе по Ceph. В начале курса вы получите системные знания по базовым понятиям и терминам, а по окончании научитесь полноценно устанавливать, настраивать и управлять Ceph. Детали и полная программа курса здесь.

Пример SDS на основе GlusterFS

Из преимуществ SDS можно построить отказоустойчивую производительную реплицируемую систему хранения данных с использованием обычного, возможно даже устаревшего оборудования. Если убрать зависимость от основной сети, то есть добавить выделенные сетевые карты для работы SDS, то получается решение с преимуществами больших SAN\NAS, но без присущих им недостатков. Я считаю, что за подобными системами будущее, особенно с учетом того, что быстрая сетевая инфраструктура более универсальная (ее можно использовать и для других целей), а также дешевеет гораздо быстрее, чем специализированное оборудование для построения SAN. Недостатком можно назвать увеличение сложности по сравнению с обычным NAS, а также излишней перегруженностью (нужно больше оборудования) в условиях малых систем хранения данных.

Гиперконвергентные системы

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

Облака и эфемерные хранилища

Логическим продолжением перехода на виртуализацию является запуск сервисов в облаках. В предельном случае сервисы разбиваются на функции, запускаемые по требованию (бессерверные вычисления, serverless). Важной особенностью тут является отсутствие состояния, то есть сервисы запускаются по требованию и потенциально могут быть запущены столько экземпляров приложения, сколько требуется для текущей нагрузки. Большинство поставщиков (GCP, Azure, Amazon и прочие) облачных решений предлагают также и доступ к хранилищам, включая файловые и блочные, а также объектные. Некоторые предлагают дополнительно облачные базы, так что приложение, рассчитанное на запуск в таком облаке, легко может работать с подобными системами хранения данных. Для того, чтобы все работало, достаточно оплатить вовремя эти услуги, для небольших приложений поставщики вообще предлагают бесплатное использование ресурсов в течение некоторого срока, либо вообще навсегда.

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

Заключение

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