Вопрос или проблема
Работал над проектом с использованием S2D на двухузловом WSFC с файлообменным свидетелем на FSx, с узлами, размещенными на двух экземплярах EC2, работающих под управлением Windows Server 2022, каждый с объемом EBS. Автоматизация использует FailoverClusterDsc для настройки кластера и Enable-ClusterStorageSpacesDirect для включения S2D.
Все работает нормально. Кластер настраивается, и хранилище кластеризуется. Интересно, что после первого запуска Enable-ClusterStorageSpacesDirect второй том EBS исчезает, и у нас остается только один.
У нас есть дополнительная автоматизация для добавления узла в кластер, если один узел уничтожен, и это также работает.
Однако, пытаясь восстановить после одновременного уничтожения обоих узлов, мы сталкиваемся с проблемами.
Кластер недоступен, поэтому мы не можем присоединить новые узлы к существующему кластеру, но если мы удалим объекты AD и создадим новый кластер, все работает до тех пор, пока мы не запустим Enable-ClusterStorageSpacesDirect.
Он жалуется, что на узле 2 нет подходящих дисков. Единственное решение, которое я нашел, это уничтожить и воссоздать диски, но это, очевидно, теряет все данные и упускает смысл.
Есть ли способ запустить кластер с помощью PowerShell и файлообменного свидетеля, чтобы мы могли присоединить узлы и использовать существующее хранилище?
Или способ сделать так, чтобы новый кластер знал о существующем хранилище, которое теперь считает первичным пулом?
Кажется, должен быть способ восстановиться после полного отказа оборудования, который уничтожение приблизит, но не удалось найти информацию на Reddit, Stack Exchange или Microsoft docs.
Нам нужно иметь возможность восстановиться после такой аварийной ситуации и сделать узлы как можно более заменяемыми, но сохранить файлы, хранящиеся на S2D?
Я пытался найти способ сохранить кластер в сети только со свидетелем, кажется, это невозможно с файлообменным свидетелем. Невозможно дать свидетелю все голоса. Я пытался добавить хранилище S2D обратно в новый кластер, но оно просто определяется как первичный пул и не может быть кластеризовано так же.
Растянутый кластер на основе S2D не поддерживается, даже с Windows Server 2025. Microsoft удалили эту функциональность вместе с обновленным, переписанным и значительно более быстрым стеком NVMe и инициатором NVMe/TCP прямо перед тем, как WS2025 достиг этапа GA, оставив растянутый кластер как функцию только для локального Azure.
https://learn.microsoft.com/en-us/azure/azure-local/concepts/stretched-clusters
Так что неудивительно, что вы сталкиваетесь с проблемами с этой настройкой в Windows Server 2022. Мое предложение — придерживаться чего-то известного и официально поддерживаемого. Например, Storage Replica встроена и полностью поддерживается для ваших нужд. Также стоит рассмотреть сторонние решения, их много!
Ответ или решение
Теория
Настройка отказоустойчивого кластера Windows Server с использованием Storage Spaces Direct (S2D) на платформах EC2 может быть сложной задачей, особенно при полном отказе кластера. Ваша текущая конфигурация включает два узла с файловым свидетелем на FSx и автоматизацию через FailoverClusterDsc для создания кластера и Enable-ClusterStorageSpacesDirect для активации S2D. Однако восстановление после одновременного отказа обоих узлов вызывает проблемы, так как кластер не может быть восстановлен с использованием прежних данных. Важным аспектом успешного восстановления является понимание того, как кластер взаимодействует с внутренними объектами Active Directory и хранилищем.
Пример
Ваш случай иллюстрирует проблему: после уничтожения обоих узлов, кластера как такового не существует, и его нельзя просто восстановить, добавив новые узлы к существующему кластеру. Когда вы пытаетесь создать новый кластер, предыдущие диски видятся как "первоначальный пул" и не распознаются как часть кластера.
Применение
Для решения этой проблемы и обеспечения возможности восстановления необходимо предпринять несколько шагов:
-
Резервное копирование важных данных: Перед изменениями убедитесь, что все данные надежно резервируются. Amazon S3 или другие облачные решения могут быть подходящими вариантами.
-
Проверка конфигурации файлового свидетеля: Файловый свидетель должен функционировать корректно и быть доступным, чтобы в случае аварии он мог быть задействован для определения состояния кластера.
-
Автоматизация восстановления: Разработайте скрипты на PowerShell для автоматизации восстановления кластера. Это должно включать:
- Удаление старых объектов AD, связанных с кластером.
- Создание нового кластера и привязка его к существующим данным.
- Повторное выполнение Enable-ClusterStorageSpacesDirect с учетом обнаруженного "первоначального пула", возможно, с использованием идентификаторов постоянного хранения для повторной привязки дисков.
-
Оценка альтернатив: Рассмотрите использование Microsoft Storage Replica для синхронизированного хранения данных. Эта технология хорошо поддерживается и может предложить простые механизмы для восстановления данных.
-
Использование поддерживаемых решений: Избегайте применения неподдерживаемых конфигураций, таких как растянутые кластеры для S2D в Windows Server 2022. Исследуйте возможности Azure и других облачных решений для подобных задач.
Следуя данным рекомендациям, вы сможете предотвратить потерю данных при отказе узлов и минимизировать время простоя. Существуют также сторонние решения, которые могут дополнительно улучшить возможности резервного копирования и восстановления.