Многие из вас используют или интересуются решением StarWind Virtual SAN, которое является сейчас одним из основных продуктов на рынке для организации отказоустойчивых кластеров хранилищ (а еще и самым технологически продвинутым). Сегодня мы поговорим об узле Witness node в кластерах и о том, как он помогает защитить его от массовых сбоев в виртуальной среде.
Как большинство из вас знает, кластер из нескольких систем (серверов и хранилищ на базе них) обеспечивает работоспособность инфраструктуры в условиях, когда, как правило, больше половины серверов продолжают функционировать. Средства высокой доступности (High Availability, HA) позволяют следить за состоянием серверов и путей коммуникации, чтобы своевременно обнаружить вышедшие из строя компоненты инфраструктуры и начать восстановление систем, переключив нагрузку на резервный узел или узлы.
В среде StarWind Virtual SAN используются стандартные механизмы защиты кластера путем канала коммуникации доступности систем (Heartbeat) - это такие регулярные сигналы между серверами по выделенному каналу, которые позволяют узлам понимать, что системы работают, поэтому никаких действий по восстановлению не требуется.
Но что делать, когда кластер из хранилищ разделяется напополам в условиях, например, выхода из строя сетевого оборудования или других проблем? В этом случае каждый узел может пытаться восстановить работоспособность инфраструктуры и возникнет ситуация split-brain, когда оба узла считают, что выжили только они и хранят у себя наиболее актуальную копию данных.
Подобно аналогичным механизмам в VMware vSphere или Microsoft Hyper-V, решение StarWind Virtual SAN имеет собственную технологию (а также стратегию восстановления, Failover Strategy) Node Majority, которая реализуется компонентом Witness node (свидетель), то есть узлом, который размещен в другой серверной комнате, на сторонней площадке или вообще в облаке.
Надо отметить, что узел Witness вам потребуется только в двухузловых кластерах, когда обнаружение одним из хостов события изоляции его от другого может быть интерпретировано двояко (неясно, кто из них сейчас рабочий). В случае с тремя узлами кластера StarWind Virtual SAN, развертывание узла Witness вам не потребуется, а механизм Node Majority функционирует на базе имеющихся трех узлов.
Реализуется механизм Node Majority за счет техники голосования (voting) - когда кластер теряет узел, то выжившие узлы коммуницируют между собой, собирают кворум голосов (2 из 3) и решают, что именно оставшийся сегмент из двух узлов продолжает держать актуальную копию данных, а изолированный узел завершает обслуживание своих хранилищ до восстановления работоспособности.
Итак, чтобы использовать механизм Node Majority, вам нужно выбрать данный пункт во время настройки канала репликации на соответствующем шаге мастера:
Далее вы создаете партнерский узел для завершения настройки кластера:
В кластере есть отдельный канал, по которому идет синхронизация содержимого хранилищ, и который обслуживает сигналы доступности Heartbeats. Это все также настраивается при конфигурации кластера:
При завершении настройки кластера вы просто запускаете его синхронизацию на партнерский узел с основного узла:
В итоге вы увидите созданные устройства в консоли StarWind Management Console:
Теперь нужно добавить компонент Witness как партнерский узел к уже существующему узлу с данными. Просто выбираете нужное устройство и нажимаете там Add Replica:
Появляется мастер настройки репликации, где можно выбрать Witness Node, как режим синхронизации. Обратите внимание, что Witness не будет хранить данных виртуальной инфраструктуры, он только поможет собрать кворум голосов в случае сбоя одного из узлов и предотвратить ситуацию split-brain:
Далее мы указываем данные основного узла кластера:
Выбираем хранилище для файлов:
И таким же образом, как и для партнерского узла, настраиваем канал синхронизации и хартбитов:
Далее добавленный узел вы увидите как хост, работающий в режиме Witness:
Очевидно, что Witness node надо помещать не в ту же сеть, в которой работают оба узла кластера хранилищ StarWind Virtual SAN, но он должен быть доступен со стороны обоих узлов. Желательно поместить его в облако, если ваша организация использует гибридную инфраструктуру, включающую в себя онпремизные и облачные сервисы. Канал для компонента Witness нужен небольшой, так как данных при операциях с хранилищами по нему не передается.
Также в качестве Witness вы можете использовать обычную SMB-шару на одном из серверов, для этого вам лишь понадобится использовать сценарий CreateHASmbWitness.ps1, который идет в комплекте стандартных сценариев PowerShell для StarWind Virtual SAN:
Инструкции по настройке этого механизма через файловую шару находятся вот тут.
Ну и в завершение рекомендуем вам посмотреть отличное видео от StarWind по настройке решения Virtual SAN, в котором также затрагивается тема Witness node:
Скачать полнофункциональную пробную версию StarWind Virtual SAN можно бесплатно по этой ссылке. Почитать о гиперконвергентных программно-аппаратных комплексах от этого вендора можно вот тут.