Неизвестный инструмент стирает наши виртуальные машины, и мы не можем идентифицировать его

Представление консоли виртуальной машины Windows 2008 R2 в vSphere показывает следующий экран:

«Операция 2 из 2» «Протирающий диск»

Может кто-нибудь посоветовать, что это за программа?

Некоторая информация об этой тайне:

Ряд виртуальных машин в настоящее время осуществляется. Симптом - после перезагрузки появляется сообщение «ОС не найдена».

• ВМ работают на ESXi. ВМ работают на конкретном хранилище данных
• Netapp NFS При монтировании диска в рабочем окне не отображается таблица разделов, еще не удалось выполнить шестнадцатеричный дамп.
• Виртуальная машина не была сброшена жестко, должна быть программная перезагрузка, инициированная ОС
• Не подключен iso. Не было «не гостевого» доступа к виртуальной машине, поэтому должен быть RDP или аналогичный
• Резервное копирование выполняется с помощью программного обеспечения Netapp для резервного копирования в течение ночи
• NFS, о которой идет речь, имеет тонкую настройку на бэкэнде (на уровне массива) и исчерпала пространство сразу после того, как мы увидели эти проблемы.

К сожалению, похоже, что мы, возможно, не дошли до сути того, что было приложением, но чтобы получить некоторую пользу от этого инцидента, я хотел создать справочный ответ. Это VMware и управление виртуальным уровнем. Многие администраторы отделены друг от друга и не могут быстро получить гостевой доступ или доступ к хранилищу, и это для них :)

http://support.seagate.com/kbimg/flash/laptop/Laptop.swf, похоже, наиболее близко соответствует реальному приложению, найденному @MosheKatz.

Если это произошло в будущем, расследование должно быть следующим:

• Вы заметили, что некоторые, но не все виртуальные машины потерпели крах. Вы подозреваете, что это связано с проблемой хранения (так как обычно это наиболее вероятная причина)
• Сначала попробуйте выделить общий фактор. Все ли сбойные виртуальные машины используют одно и то же хранилище данных? В этом случае они были, но некоторые Машины были в порядке, поэтому мы исключили очевидные проблемы с оборудованием.
• Проверьте все сломанные виртуальные машины, чтобы увидеть, был ли общий фактор (время, функция и т. Д.). В этом случае не было.

• Проверьте на другие необычные события. Здесь что-то подняло флаг:

• • Хранилище NFS было тонким (на уровне массива). Это означает, что хотя, например. Хосты ESXi представлены 200 ГБ, фактически доступно только 100 ГБ. Однако только массив обладает этими знаниями. Мы обнаружили, что несколько виртуальных машин были приостановлены, поскольку у них не хватило места на диске. Мы, хотя это и могло быть основной причиной, поэтому наша первая задача заключалась в том, чтобы выделить больше памяти на серверной части, чтобы устранить это как проблему.

• Как только это было решено (простое изменение пользовательского интерфейса), и приостановленные виртуальные машины были успешно перезапущены, мы вернулись к первоначальной проблеме. Мы смонтировали виртуальные диски со сломанных виртуальных машин на работающую виртуальную машину и увидели, что на дисках нет таблицы разделов. У нас не было шестнадцатеричной программы просмотра, поэтому пришлось предположить, что диски теперь пусты.

• Система мониторинга оповестила новую виртуальную машину, которая просто перестала отвечать на запросы. Это было здорово, поскольку нагрузка на виртуальные машины несколько минут назад просто перестала отвечать из-за проблемы с дисковым пространством, поэтому тот факт, что эта новая виртуальная машина была быстро найдена, был признаком хорошего администрирования мониторинга.

• Мы открыли консоль и проверили гостя, и увидели скриншот выше.

• • На этом этапе я отправился в чат-комнату с ошибками сервера, чтобы узнать, можно ли идентифицировать программу, в то время как мой коллега по хранилищу проверил все журналы и события виртуального уровня, чтобы убедиться, что из нашего региона не выполнялась операция хранения.
• Что мы должны были сделать, так это приостановить работу виртуальной машины, позволить записать файл приостановки и проанализировать дамп, чтобы определить, можно ли определить работающую программу. Приостановить работу виртуальной машины в ядре PDF VMware KB

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

Итак, вывод был сделан пользователем по инициативе очистки диска. Это все, что касается моего расследования, но я надеюсь, что вы нашли его полезным.

Уроки выучены:

• Резервное копирование и тестирование ваших восстановлений
• Убедитесь, что все пользователи, особенно администраторы, знают, что они работают в среде с тонким предоставлением, и должны избегать чего-либо, например форматирования диска с записью (т. Е. Записи с нагрузкой 1).
• Иметь хорошую систему мониторинга на месте.
• И новый для меня: в любой большой виртуальной среде подготовьте инструменты, готовые к ВМ, даже выключенные, с установленными средствами диагностики; производительность, сетевое хранилище. Если бы это было доступно, мы могли бы смонтировать и выполнить шестнадцатеричный дамп на поврежденном диске, чтобы увидеть, действительно ли он пуст, или просто пропустить mbr. Мы могли бы также увидеть, было ли это записано с 1.

Я думаю, что ваша проблема - стандартная функция восстановления пространства VMware.

Эта статья может вам помочь: прояснение вопросов о виртуальном диске с эффективным использованием пространства