Привет, с вами сегодня команда техподдержки Veeam Support Team. Мы уже рассказывали читателям Хабра о фантастических тварях разнообразных клиентах и где они обитают, и о том, чем и как занимается наш отдел.
А в новом сезоне мы решили начать публикацию технических постов с разбором реальных кейсов, с которыми к нам обращаются пользователи. Хочется верить, что эти материалы помогут кому-то разобраться в тонкостях работы с нашим продуктом без звонка в саппорт – а мы используем сэкономленное таким образом время для написания новых полезных статей.
Итак, сегодня разбираем кейс «Проблема с восстановлением на уровне файлов – ошибка при развертывании Linux FLR appliance», который стал одним из наиболее популярных за прошедшие месяцы.
Суть вопроса
При нормальной работе для восстановления файлов гостевой ОС (не Windows) забэкапленной виртуальной машины выполняется монтирование (mount) дисков этой самой забэкапленной машины на вспомогательную линуксовую ВМ (Linux FLR appliance). После этого можно просматривать содержимое файловой системы с помощью Veeam Backup Browser, выбирать необходимые файлы и восстанавливать их в нужное местоположение. Подробнее см. здесь (на англ. языке) или здесь (на русском).
Вспомогательная ВМ временно развертывается на ESXi-хосте исключительно с целью поддержки восстановления, а затем убирается. Однако при ее развертывании в консоли Veeam Backup & Replication может появиться сообщение об ошибке вот такого вида: “Linux FLR appliance deploy failed: Module 'MonitorLoop' power on failed.”
Как понять, что что-то пошло не так
Нюанс в том, что проблема происходит на довольно специфическом этапе – только при восстановлении файлов гостевой ОС, отличной от Windows, и конкретно при развертывании вспомогательной ВМ.
Сообщение об ошибке выглядит в консоли вот так:
Мы видим, что проблема связана с модулем MonitorLoop. Об этом же говорит и журнал соответствующей сессии FLR-восстановления, который хранится в файле с именем вида year_month_day_hour_minute_second.log. В нем мы обнаруживаем следующие записи:
[05.07.2017 17:16:49] <06> Info Mounting restore point. VM: [fileserver], BackupDate: [09.01.2017 18:31:12], Oib: [aa6038d3-bf68-42d6-86c0-de3a48784066]
[05.07.2017 17:17:49] <06> Error Failed to mount oib «aa6038d3-bf68-42d6-86c0-de3a48784066»
[05.07.2017 17:17:49] <06> Error Linux FLR appliance deploy failed: Module 'MonitorLoop' power on failed. (Veeam.Backup.Common.CAppException)
Кроме того, поскольку за развертывание вспомогательной ВМ (FLR appliance) отвечает сервис монтирования VeeamMountSvc, то в его журнале Svc.VeeamMount log тоже будет сделана подобная запись (правда, в ней не будет фигурировать проблемный модуль):
[05.07.2017 17:16:49] <23> Error Recreating WCF proxy…
[05.07.2017 17:16:49] <23> Error Linux FLR appliance deploy failed (System.ServiceModel.FaultException`1[Veeam.Backup.Interaction.MountService.CRemoteInvokeExceptionInfo])
«Кто виноват?»
Продолжая наше расследование, выясняем, что имеется статья VMware KB, из которой явствует, что модуль MonitorLoop контролирует ресурсы, выделяемые виртуальной машине. Конкретно же наша ошибка генерируется VMkernel, и ее можно обнаружить в журнале VMkernel:
Первопричиной является тот факт, что у хоста ESXi недостаточно ресурсов для работы вспомогательной ВМ. Естественно, процесс восстановления файлов без нее даст сбой. Чтобы выяснить, чего не хватает, можно углубиться в анализ логов VMkernel, а можно оценить необходимые ресурсы, основываясь на здравом смысле. А он утверждает, что критичные ресурсы – это, скорее всего, CPU и RAM, доступные для работы ВМ на данном хосте, а также свободное место для хранения файла подкачки. Недостаток последнего встречается довольно часто, так что если вы уверены, что ресурсами оперативной памяти и процессора все в порядке, то причина возникающей ошибки почти наверняка — недостаток места для хранения файлов вспомогательной ВМ и ее файла подкачки.
«Что делать?»
Для того, чтобы уяснить, что конкретно нужно поправить, запускаем мастер восстановления File-Level Restore и идем в настройки вспомогательной ВМ (FLR Helper Appliance).
Здесь для хоста, указанного в поле Host, нужно проверить две вещи:
- Достаточно ли у хоста ресурсов памяти и ЦПУ для работы ВМ. Вспомогательная машина потребляет минимум этих ресурсов, так что главное, чтобы они были доступны на момент ее развертывания. Если нужно, выберите другой хост, где эти ресурсы гарантированно будут в наличии.
- По умолчанию Veeam сохраняет файл подкачки вспомогательной ВМ на хранилище, указанное как NFS datastore – это обычная Windows-папка на сервере монтирования (mount server). Однако так бывает не всегда.
На картинке ниже показана настройка хоста ESXi, отвечающая за дефолтное место хранения файлов подкачки виртуальных машин: host → Configuration → Virtual Machines → Swap File Location.
Есть вероятность, что дефолтная настройка – Virtual machine directory (хранить в каталоге ВМ) – была изменена, а на вновь указанной для этой цели СХД закончилось место. В результате развернуть новые ВМ, включая вспомогательные, невозможно. Проверьте, не ваш ли это случай.
Аналогичая ошибка может произойти со вспомогательной ВМ в ходе SureBackup – причиной будет все та же нехватка ресурсов.
Бонус-трек
А знаете ли вы, что подробнее о работе продуктов Veeam всегда можно почитать в онлайн-справке, которая открывается по нажатию клавиши F1 из любого диалога в консоли продукта, включая главное окно?
Это относится и к шагам разнообразных мастеров настроек – нажимаете F1 на любом шаге мастера, и в вашем дефолтном браузере открывается соответствующий параграф документации в справочной онлайн-системе Help Center.
Профит!
Мы собираемся и дальше выкладывать разборы популярных кейсов из числа тех, которые поступают к нам в саппорт. Cвои пожелания можно высказывать в комментариях. До новых встреч!
Ссылки к сегодняшнему посту:
• Документ «Базовые сценарии использования Veeam Backup & Replication 9.5» на русском языке
• Описание процесса восстановления файлов гостевой ОС (FLR)
• Статья базы знаний VMware
Автор: polarowl
