Клиент:
Крупная компания с собственным ЦОД, несколькими десятками блейд-серверов, и несколькими СХД. Количество виртуальных машин в кластере Vmware vSphere более тысячи. Количество пользователей информационных систем - более 4 000 человек.
Проблема:
Периодическое зависание отдельных гипервизоров, до состояния «не отвечает в физической консоли». Зависаниям были подвержены все гипервизоры, вне зависимости от размещенных на них виртуальных машин.
Разумеется, отказы 10-25% аппаратного парка в сутки для бизнеса было огромной проблемой, которую и было поручено решать нам.
Решение:
Была проведена диагностика всей аппаратной части инфраструктуры – без замечаний.
СХД аналогично – без замечаний.
Подняли версию гипервизоров до максимально возможной – безрезультатно.
Параллельно обвязали аппаратную часть инфраструктуры мониторингом, получили первую зацепку: зависание хоста вызывает 100% утилизация CPU на i/o wailt. Логично было предположить, что это поведение связано с системой хранения, но, несмотря на ошибки в журналах гипервизора о потере доступа к одной конкретной системе хранения данных, мониторинг самой СХД, как встроенный, так и внешний, говорили о ее полном здравии.
Сеть хранения была так же проверена – никаких отказов на ней не фиксировалось.
Второй зацепкой стало наблюдение: при обновлении версий гипервизоров мы брали даунтайм у клиентского подразделения информационной безопасности на их виртуальные машины, на которых размещался, в том числе, сканер уязвимостей, и пока виртуальные машины мигрировали на новый гипервизор, отказы гипервизоров временно прекратились.
Опрос сотрудников подразделения ИБ показал, что они занимаются сканированием только рабочих станций и виртуальных машин (но не аппаратного оборудования), и не используют потенциально опасные методы, типа брутфорса или попыток DoS-атак. Во что мы, конечно же, не поверили, и стали средствами vSphere собирать дамп трафика со сканера уязвимостей, направленный в сторону сетевого сегмента, где размещены интерфейсы физического оборудования.
Буквально за несколько часов наблюдений была поймана попытка подбора пароля на ISCSI-интерфейс той самой "проблемной" системы хранения данных, которая, спустя несколько неудачных попыток авторизации, включала режим противодействия брутфорс-атаке и блокировала попытки подключения к ней на несколько минут. Разумеется, в этот момент гипервизор, работавший с данными на СХД, терял к ней связь, получал ошибку ввода-вывода, а далее утилизация процессора стопорила аппаратный хост намертво.
Проблема была сдана заказчику, и в последствии решена блокировкой определенного вида трафика на межсетевом экране сервисного сегмента локальной сети.