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

Сбой среды кластера Hyper-V

У нас есть среда с двумя хостами, оптоволокном (NIC Team) и медным (Nic Team2). Узлы сгруппированы и используют стандарт 2012-R2 (обновленный) с кластеризацией Hyper-V и пулами хранения. Виртуальные машины представляют собой примерно 50 компьютеров Debian, распределенных равномерно. Сети представляют собой три подсети: кластер, коммутатор 0, коммутатор 1. Две - это кластер и клиент, одна - только кластер.

Время от времени вся среда дает сбой. Наиболее заметными признаками являются скачок ЦП на виртуальных машинах до 100% и невозможность использования сетевого доступа к физическим и виртуальным машинам. Единственный способ борьбы с этим - принудительное отключение обоих хостов, которые после этого возвращаются в нормальное состояние.

Вот то, что, как мне кажется, я знаю из сканирования журналов и просмотра наших совокупных данных журналов и производительности (примечание: не каждое сообщение относится к каждому инциденту, это совокупность):

Windows:

-TCP порты исчерпаны / локальная конечная точка TCP такая же, как и удаленная, с повторным использованием локальных портов - идентификатор события 4227

-Доступ к вводу / выводу перенаправлен по сети - EventCode = 5121

-Кластерный общий том приостановлен - EventCode = 5121

-TCP локальная конечная точка такая же, как удаленная, повторное использование локальных портов - идентификатор события 4227

-Эфемерное исчерпание порта - событие с кодом 4231

Linux:

-Высокий CPU в ТОПе - ksoftirq

Моя интерпретация: есть утечка либо на стороне хоста, либо на стороне виртуальной машины, которая съедает все порты TCP и вызывает резервное копирование VMQ. Это создает отставание в среде, что в конечном итоге приводит к сбою.

Моя проблема: как определить, что именно вызывает проблему? Есть ли способы смягчить проблему, не зная специфики?

Поскольку функциональность Teaming не имеет встроенной функции балансировки нагрузки, которая бы в равной степени балансировала нагрузку между объединенными сетевыми интерфейсами, проблема может быть основана на аспекте конфигурации объединения сетевых адаптеров, пробовали ли вы удалить группы для целей тестирования?

Не прямой ответ, а несколько общих советов


Большинство проблем, с которыми мы столкнулись, были решены путем установки исправлений, опубликованных MS. Их было так много, что они посвятили страницы их списку, и я не думаю, что они потрудились выкатить их все в обновления:

Hyper-V 2012 R2 и связанные исправления (также ссылки на другие соответствующие списки, например HNV, кластеры)

Кто-то опубликовал сценарий, который установит большинство из них. Я думаю, что это вот этот.

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

Руководство по правильной настройке VMQ

Наблюдаемые нами состояния паузы также были вызваны двумя причинами. Низкая производительность хранилища и LUN большого размера. Последнее было проблемой только тогда, когда у нас было слишком много активных снимков VSS во время окна резервного копирования - вероятно, в данном случае это не актуально. Проверьте журнал диагностики кластера для получения дополнительной информации о событии автоматической паузы или найдите (например) код состояния / причины c000026e в Интернете.

Устранение неполадок CSV

Помимо этого ... Обновления драйверов и прошивки на сетевой карте и устройствах хранения.