Failover Clustered Storage Spaces а-ля Cluster-in-a-box (проверка отказа ресурсов кластера в сценарии бюджетной СХД)

(Ликбеза по технологии Windows server 2012 - Storage Spaces, как настраивать и обзора всего того, что это может дать, в статье не будет. Кому интересно, все есть как на сайте разработчика ОС, так и других обзоров по Storage Spaces навалом)

Наверняка многие знают про новый функционал по работе с дисковой подсистемой появившейся в Windows Server 2012, а именно  Storage Spaces, позволяющий объединять диски с разными интерфейсами, в единый дисковый пул и дальнейшим созданием виртуальных дисков на этом пуле, с необходимым уровнем отказоустойчивости.

Так же не является секретом, то что Storage Spaces возможно кластеризовать и с точки зрения Microsoft , получить  не дорогое решение высоко доступного хранилища. Доступ к системе хранения может быть как файловый (CIFS, NFS, SMBScale-Out), так и блочный (iSCSI).

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

В тестировании использовалось ящик от Supermicro - 6036ST-6LR, а в общем схема подключения выглядит приблизительно так:

Если в паре слов, то к SAS HBA каждого узла кластера подключен один из двух SAS-портов жесткого диска, что и обеспечивает отказоустойчивость в данной концепции.

NIC1 - внешняя сеть для управления узлами и ресурсами кластера

NIC2 - внутренняя сеть для виртуальной инфраструктуры (в данной статье не используется)

NIC3 - сеть для heartbit'ов узлов кластера

Ресурсы кластера:

Iscsi - кластеризованный iSCSI Target

fs-1 - кластеризованный  SMB

fs-so-1 - высоко доступный файловый ресурс в режиме Active-Active (актуально только для ОС Windows 8 / Windows 2012 и выше)

Отработка фэйловера проверялась жестким ресетом узла-владельца ресурса. Перед сбросом узла, запускался опрос ресурса по сети (ping) и операция копирования файла с/на ресурс .

iSCSI Target -Так как это блочный доступ, то по умолчанию кэш для тома включен и при фэйловере копирование не прервалось. Восстановление в среднем 20-30 сек.

SMB File  Server - В среднем обработка отказапроисходит около одной минуты (40-60 сек). Конекшн не рвется и в принципе для файловой помойки сойдет, а вот для приложений которые не умеют ждать (тайм аут около 1мин) решение не годится.

SMB Scale-Out File  Server  - Результат достаточно любопытен. Т.к. режим Active-Active достигается алгоритмом 'round robin', то получились следующее результаты:

                • если сессия открыта на том узле который умирает, то сессия (копирование) висела практически до восстановления узла на котором она была открыта (надо будет еще потестить)

                • если сессии открываются часто, то отработка отказа происходит практически моментально

                • если сессия открыта и фэйлится узел не тот на котором эта сессия активна, то прерывания и затыка не происходит совсем.

Важно: прозрачное переключение SMB3.0 и Scale-Out поддерживаются только клиентами Windows 8 и Windows 2012.

Отойдя немного от идеи использования Clustered Storage Spaces в качестве бюджетного СХД, хотелось бы заметить, сами узлы кластера фактически без какого либо тайм аута взаимодействуют с дисковым пулом. Например переключение высоко доступнойвиртуальной машины происходит с теми же задержками, что и при использовании любой другой СХД в кластере Hyper-V.

 

. Иными словами, при использовании нескольких  дисковых полок и производительных серверов, подключенных  через SAS коммутатор, можно получить не плохое решение для определенных задач (например VDI, где необходимо приобрести только лицензии на клиентские ВМ, и одну лицензию Win2012Std, для RDCB+RDWA)

Вывод: На мой субъективный взгляд, решение хорошо подходит для построения реально бюджетной виртуальной инфраструктуры на основе Windows Hyper-V Server 2012.

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

PS: В статье не рассмотрены вопросы касающееся непосредственно надежности самого  Storage Spaces, в частности не выдергивались диски и не "ломались" SAS интерфейсы /порты  (симуляция отказа одного из путей на SBB 6037B-DE2R16L выполнить не получится из-за конструктивных особенностей подключения узлов к бэкплэйну корзины).

Так же не производились тесты скорости (такие модные плюшки, появившихся в Windows Server 2012 R2, как тиринг и кэширование записи, тестировать пока не планирую).

В планах имеется тестирование работы высоко доступных приложений, непосредственно на узлах кластера (например гипервизор или MS SQL Server).

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