У меня есть два узла, которые загружаются с iscsi для реализации кластера Windows 2008. И я использую опцию большинства дисков в качестве кворума вместо iscsi. Но когда соединение iscsi кворума не удалось (может быть сброс сервера san), отказоустойчивый кластер тоже выходит из строя. Если я сброшу один из узлов, он может открыться, но его системный диск отключится. Я не могу изменить его статус как онлайн, потому что он говорит, что он зарезервирован отказоустойчивым кластером (диск находится на iscsi, поскольку используется загрузка iscsi). И этот диск работает только для чтения. Ничего на нем нельзя ни удалить, ни записать. Итак, я не могу снова присоединить узел к кластеру. Приходится переустановить windows. Итак, я спрашиваю, как я могу реализовать больше резервных копий кворума? Я имею в виду, могу ли я использовать и большинство дисков, и большинство файловых ресурсов одновременно? AFAIK, каждый узел также хранит копию кворума. Но я не знаю, что иногда серверы san отключаются. И iscsi-соединение кворума и iscsi-соединения узлов теряются. Итак, ни кворума, который хранится в узлах, ни кворума iscsi диска недостаточно, чтобы снова запустить кластер. Я хочу использовать как большинство дисков, так и большинство файловых ресурсов одновременно. Я могу это сделать? Есть ли у вас другие предложения? С уважением.
Я думаю, вам нужно пересмотреть свою архитектуру. Фактически у вас есть 1 компонент, который вызывает 2 сбоя одновременно: ваш сервер SAN вызовет сбой 2 каналов. Этот сценарий обычно не обрабатывается отказоустойчивым кластером, если вы не принимаете дополнительных мер. Если вы используете сервер SAN, он должен быть отказоустойчивым и никогда не сбрасываться, если не для обслуживания, и вы знаете, что вам придется остановить кластер. Я написал программное обеспечение отказоустойчивого кластера в оболочке POSIX и протестировал его также в Windows с помощью CYGWIN, он может работать, но поскольку это классический скрипт unix, он использует много вилок, и поэтому в Windows он потребляет гораздо больше процессора, чем в Linux. Если вас может заинтересовать новое решение: https://github.com/nackstein/back-to-work/
это проблема любого отказоустойчивого кластера Microsoft, использующего Server 2012 или более раннюю версию, использующего либо большинство дисков, либо большинство узлов и дисков. Диск-свидетель - это точка отказа для кластера. Даже если все узлы работают, в случае отказа диска-свидетеля (мы теряем к нему доступ) кластер выходит из строя. так что делать?
1) Убедитесь, что ваш диск-свидетель имеет высокую доступность, поэтому вероятность его перехода в автономный режим ниже 2) Рассмотрите возможность использования вместо этого файлового ресурса-свидетеля и альтернативного файлового ресурса-свидетеля, выберите узел и файловый ресурс-свидетель в качестве типа кворума 3) Используйте Windows Server 2012 R2 для вашего кластер. Server 2012 r2 использует динамическую модель кворума и не страдает той же проблемой.