При развертывании кластера Hyper-V обязательно используйте Teaming

Как говорится, знал где у меня тонкое место в кластере, и по закону Мерфи это тонкое место сработало. Самое интересное что сработало с неожиданным результатом. Вчера вечером мне начали падать смски о том, что у меня не отвечают некоторые виртуальные машины в кластере. Плюс итоговая смс о недоступности одного из четырех узлов самого кластера. Ну, какзалось бы, обычная ситуация, упала нода, виртуалки выключились "по питанию", перескочили на другую ноду, стартуют, мониторинг отправляет сообщения о том, что виртуалки были недоступны... Но каково было мое удивление, когда я зашел на мониторинг и увидел что те виртуалки, которые были на упавшей ноде, все еще недоступны! Еще удивительнее, что в оснастке Failover Clustering все эти машины живы и работают на УПАВШЕЙ ноде, а сама нода в списке активна! Оснастка Hyper-V между тем говорит что нода недоступна.

Полистав ресурсы Failover Clustering стало понятно, что на ноде упал сетевой интерфейс, через который организован выход виртуалок в свет. Второй интерфейс с heartbeat работает. Получилась интересная ситуация. Для кластера пострадавшая нода пострадавшей не является. Более того, виртуальные машины при такой неисправности переместить на другие ноды невозможно. При попытке создать задания на миграцию виртуальных машин, оно отваливается по недоступности RPC, что естественно, так как эти действия проходят по пострадавшему сетевому интерфейсу. Подключившись к ноде через iLO, попытался перегрузить ноду. Процесс перезагрузки застрял на этапе сохранения виртуальных машин для их quick migration, который опять же был послан с кластер сервиса. Виртуалки так и зависли на 0% Saving. Пришлось идти на крайние меры и перегружать блейд по питанию. После перезагрузки, сетевой интерфейс пришел в норму и виртуальные машины снова мигрировали через failback на свою родную ноду. Подытожив, можно сказать, что при построении кластера, обязательно используйте функции тиминга сетевых интерфейсов (если у вас их только два на нодах), чтобы отказ одного интерфейса не приводил к таким последствиям. Плюс для себя выяснил, что Hyper-V не отрабатывает корректно отказ сетевого интерфейса виртуализации, при работоспособности heartbeat интерфейса. Я разворачивал свой кластер, еще во времена, когда Microsoft официально не рекомендовал использовать функции тиминга при построении кластера, ввиду неотработанности механизма, а блейды первого поколения были только с двумя, неделимыми интерфейсами. По этому пришлось смириться с этим узким местом, которое мне теперь не дает покоя. Скорее всего буду извлекать ноды одну за одной из работающего кластера, поднимать новый с использованием тиминга, и мигрировать виртуальные машины.

Что именно произошло с сетевым интерфейсом, я так и не понял. В журнале системы только одна запись на событие 1127 от Failover Clustering о том, что сетевой интерфейс на ноде недоступен. Проверка работоспособности интерфейса в первые минуты обнаружения его неисправности показала что стек TCP/IP на нем поднят верно, интерфейс пингуется изнутри, но не пингуется снаружи. Если бы это был обыкновенный сервер, я бы подумал, что из интерфейса выдернули сетевой кабель. Но это ведь blade сервер, с избыточными контактами на каждое соединение. Не могли же все контакты разом отказать, и более того, после программной перезагрузки операционной системы, волшебным образом восстановиться... В общем тайна, покрытая мраком по этому единичному сбою.

Поделиться

Опубликовать в Facebook
Опубликовать в LiveJournal

При развертывании кластера Hyper-V обязательно используйте Teaming: Один комментарий

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>