У нас есть среда с двумя хостами, оптоволокном (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 в Интернете.
Помимо этого ... Обновления драйверов и прошивки на сетевой карте и устройствах хранения.