Назад | Перейти на главную страницу

поведение кластера Hyper-V при потере сетевого подключения

Настроить:

  1. (довольно новый) кластер Hyper-V R2 с 2 узлами (в конфигурации аварийного переключения). Физическая хост-ОС: Windows Server 2008.
  2. Около восьми виртуальных машин (смешанные: Windows Server 2008 и Linux)

Вчера у нас отключили электричество примерно на 15 минут.

Наши блейды подключены к ИБП, поэтому физические хост-машины (Windows Server 2008) никогда не выходили из строя. Наши главные переключатели не включены ИБП (пока), и мы наблюдали поведение, подобное приведенному ниже (по результатам анализа журналов событий).

  1. Узлы в кластере потеряли средства связи (из-за выхода из строя внешних коммутаторов).
  2. Кластер хочет сбить один ( first) узлов (для запуска аварийного переключения?).
  3. Предыдущий шаг влияет на кластерное хранилище, в котором расположены виртуальные жесткие диски виртуальных машин.
  4. Все виртуальные машины были жестоко остановлены и были обнаружены в отказоустойчивом состоянии в диспетчере отработки отказа в ОС хоста. Виртуальные машины Linux вызывали панику ядра и выглядели так, как будто у них был вырван диск.

Вся эта установка довольно нова для нас, поэтому мы все еще изучаем ее.

Вопрос:

Вскоре мы ставим переключатели на ИБП, но нам было интересно, является ли вышеуказанное поведение ожидаемым (кажется довольно хрупким) или есть очевидные улучшения конфигурации для обработки такого сценария?

Я могу загрузить evtx файл о том, что именно происходило в случае необходимости.

Наиболее вероятное объяснение такого поведения связано с конфигурацией кворума. Взгляни на http://technet.microsoft.com/en-us/library/cc731739.aspx.

По сути, когда ваш сетевой коммутатор вышел из строя, два узла потеряли связь друг с другом. В этот момент ни один из узлов не знал, что делает другой. Если один узел решил, что он собирается взять на себя владение всеми кластерными ресурсами (то есть виртуальными машинами) и загружать их, кто скажет, что другой не будет делать то же самое? Вы окажетесь в сценарии, в котором оба узла пытаются полностью владеть все виртуальные машины, и у вас будет действительно неприятное повреждение жесткого диска.

Конфигурация кворума решает эту проблему, заявляя, что для того, чтобы узел функционировал, он должен контактировать с большинством узлов (и, возможно, также с диском или общим файловым ресурсом). Если он не может этого сделать, он перестанет функционировать как член кластера.

Чтобы убедиться, что это так, откройте диспетчер отказоустойчивого кластера и проверьте «Конфигурация кворума» на странице сводки для кластера. Если это Большинство узлов и у вас четное число узлов, то почти наверняка произошло то, что я описал.

Решение состоит в том, чтобы установить небольшой диск, называемый Disk Witness (50 МБ более чем достаточно), и добавить его в хранилище для вашего кластера (но НЕ в общие тома кластера). Затем измените конфигурацию кворума на Большинство узлов и дисков. С этим параметром, если вы столкнулись с той же ошибкой, что и раньше, узел, который владел диском во время сбоя, продолжил бы работу (и фактически принял бы владение всеми ресурсами с другого узла), а другой узел остановился бы. Виртуальные машины, которые переключились на работающий узел, подверглись бы жесткому перезапуску, но, по крайней мере, они были бы в сети как можно быстрее.

Как вы заявили, в идеальном случае ваши переключатели также должны быть на ИБП. Это полностью предотвратило бы сбой; однако вы также должны убедиться, что используете рекомендуемую конфигурацию кворума для количества имеющихся у вас узлов.