Русский
Русский
English
Статистика
Реклама

Блог компании skilline

Подключение СХД Qsan к гипервизору VMware ESXi

16.06.2020 10:18:24 | Автор: admin

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

Подключение СХД Qsan к серверам в среде Windows Server и Hyper-V

29.06.2020 10:05:23 | Автор: admin

Мы продолжаем цикл публикаций из серии 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. Для получения более полной информации настоятельно рекомендуется ознакомиться с руководствами пользователей, предоставляемыми обоими вендорами.
Подробнее..

СХД Qsan в системах видеонаблюдения

14.07.2020 10:11:05 | Автор: admin

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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru