Сбой среды кластера 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 в Интернете.
Кроме этого ... Обновления драйверов и микропрограмм на сетевой карте и устройствах хранения.