Вся прелесть и ужас VDDK ошибок в том, что, с одной стороны, совершенно точно понятно, где сломалось, а с другой — совершенно непонятно, почему, и как это теперь чинить. Это примерно как RPC call function failed в мире Windows.
Хотя не всё так ужасно, конечно же. Некоторые ошибки имеют совершенно конкретные причины и методы лечения. А некоторые — давно известный список наиболее частых причин и вариантов их исправления.
Наш Veeam Technical Support, конечно же, накапливает в себе подобные знания, и сегодня мы немного подглядим в их записи. Поэтому с превеликим удовольствием представляю вам топ самых частых VDDK errors и методы их устранения.
VDDK errors. Что это и как они получаются?
Как можно догадаться из названия, это какие-то проблемы на уровне VDDK Api (Virtual Disk Development Kit) — лучшего способа взаимодействия с vSphere инфраструктурой. Не важно, будет это отдельный ESXi хост или развесистый vCenter, но если нам надо что-то записать или считать из нашей инфраструктуры, лучший способ для этого — бесплатно распространяемый VDDK.
Если максимально упростить, то выглядит это взаимодействие примерно так: Veeam сервер хочет, например, что-то прочитать с хоста (или записать) и шлёт ему соответствующий запрос. Создаётся вызов на чтение с указанием, из какого диска, сколько хочется прочитать, с какого оффсета и в какой буфер в памяти. Или записать, аналогично, из указанного буфера. Всё просто.
Но это в идеальном мире.
В реальном же иногда на пути этого простого алгоритма случаются ошибки, из-за которых не получается завершить запрос. И вместо ожидаемого ответа к нам приходит номер ошибки, который тщательно записывается в логи.
Вот о самых частых таких ошибках мы сегодня и поговорим
Важный дисклеймер!
Не уверен — не делай! Не нажимай и вообще ничего не трогай! Позвонить или написать в саппорт Veeam всегда лучше, чем ставить эксперименты на своём проде. Благо саппорт у нас русскоязычный и технических крайне грамотный.
При малейших сомнениях позвонить и спросить: «У меня вот такая проблема, я нашёл в сети вот такой вариант решения, это поможет мне её решить?» — нормально и правильно. Что не нормально и не правильно, так это будучи не уверенным в своих действиях наворотить дел, а потом просить восстановить всё из руин за пять минут, и чтобы ничего не потерялось.
Да, мы, конечно же, поможем и в этом случае, но лучшая битва — та, которой не было. Поэтому всегда старайтесь критически оценивать свои действия, и всем большого аптайма.
VDDK error 1: Unknown error
На самом деле по этой ошибке у нас есть целая КВ статья. И, как она гласит, чаще всего эта ошибка возникает, если у вас установлено слишком много счётчиков производительности — и скачайте патч от VMware, который вам всё поправит.
С одной стороны, даже и комментировать нечего. Вот проблема, вот описание (пусть даже не очень понятное), и, что самое важное — вот вам ещё и ссылка на лекарство. Однако не всё так просто. По нашим наблюдениям, эта ошибка может возникать не только из-за скучной проблемы со счётчиками, но также из-за:
- Повреждения конкретного VMDK файла. То есть машина ваша вот прямо сейчас работает, но возможно, что скоро перестанет. Или — классический случай — вы её выключите и больше не сможете включить. Словом, приятного вас ожидает мало. Да, есть всякие тулы для проверки целостности и коррекции ошибок, однако это не панацея.
- Повреждения всего datastore. Тут даже и комментировать ничего не хочется. Надеемся, у вас есть запасной.
- Проблема с HBA контроллером. Да, проблемы идут по нарастающей. Хорошо если это просто плата сгорела и всё ограничится заменой с проверкой рейда. А если рейд был повреждён и его придётся пересчитывать?
- И самая безобидная, но тоже причина: ESXi хост периодически теряет связь с vCenter.
Ну хорошо, жути нагнал, скажете вы. А дальше-то что? Как понять, что пора срочно бежать за новыми дисками — или достаточно поставить патчик и выдыхать?
А я вам отвечу — держите набор простейших тестов, которые в случае чего помогут вам принять правильное решение.
- Запускаем Storage vMotion или просто клонируем подозрительную машину на другой датастор, а потом пытаемся запустить бекап. Если клонирование не прошло — однозначно беда где-то в дисковой подсистеме. Режим паранойи на максимум — и проверять всё, от дисков до контроллеров.
Если клонировалось и забекапилось успешно, значит, был повреждён VMDK, т. к. во время клонирования VMware пересоздаёт его содержимое, и теперь там точно нет ошибок.
- Были случаи, когда перезагрузка хоста лечила проблему. Да, это не шутка. «Семь бед — один ресет» всё ещё актуально.
- Если вы уже и перезагрузились, и патч поставили, и машину клонировали, и всё равно ничего не работает — бегом в саппорт VMware.
- Если клонированная машина успешно забекапилась, попробуйте мигрировать её обратно на продакшн сторадж и продолжайте использовать вместо старой. Можно даже делать это ночью на выключенных машинах, чтобы процесс прошёл быстрее и по пути ничего не потерялось.
VDDK error 2: Value: 0x0000000000000002
Практически всегда идёт рука об руку с VDDK error 1. По нашей статистике, появление ошибки обычно связано с определёнными версиями связки vCenter/ESXi, так что лучший совет здесь — это обновиться хотя бы до версии 6.7. А лучше и 7.0.
Если же не помогло, то переходим к плану Б.
Сама ошибка появляется, когда у ESXi хоста заканчивается память, выделенная под буфер NFC read. По умолчанию, Veeam работает в асинхронном режиме чтения NBD/NFC, что в нормальных условиях может потребовать расширения этого буфера. Но происходит это не всегда. Поэтому для отключения данного режима есть специальный ключик:
Name: VMwareDisableAsyncIo
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Type: REG_DWORD
Value: 1После его создания надо перезапустить Veeam Backup Service и быть готовым к производительности, просевшей примерно на 10%.
Другой вариант — это зайти со стороны хоста и перезапустить management агентов:
/etc/init.d/hostd restart
/etc/init.d/vpxa restartПодробно процедура описана в КВ от VMware, так что не будем её переписывать.
И стандартный набор вариантов, которые не будет лишним перебрать в процессе диагностики:
- Мигрировать машины с ошибками на другой хост.
- Попробовать другой Transport mode — HotAdd с виртуальным прокси или DirectSAN.
VDDK error 3: One of the parameters is invalid
Ошибка, практически всегда случающаяся при использовании Virtual Appliance режима (он же HotAdd mode).
Тут особенно рассказывать нечего, просто дам ссылки на две наших KB, где расписано много вариантов, и даже если вы сразу придёте в саппорт, вас попросят проделать всё там написанное.
КВ1218 — Общее описание возможных проблем и методы их устранения.
KB1332 — В случае если ваш Veeam сервер работает как прокси для HotAdd режима
VDDK error 13: You do not have access rights to this file
И на этот случай у нас имеется KB2008. Да, там очень много вариантов устранения этой беды, но такая уж ошибка. Однозначно сказать, что именно случилось именно в вашем случае, практически невозможно, поэтому надо брать и перебирать весь список.
Что хочется сказать дополнительно. Очень внимательно относитесь к секции Additional Troubleshooting. Да, там написаны, возможно, слишком очевидные для многих вещи. Но даже такие банальности ускользают от взгляда самых профессиональных профессионалов. Нередки случаи, когда спустя неделю в попытках решить всё самостоятельно они приходят в саппорт только лишь для того, чтобы узнать, что невнимательно прочитали список технических требований, или нечто такое. И обидно, и жалко потраченного времени.
И два совета на все времена:
- Если машина с ролью Veeam proxy была хоть раз клонирована или реплицирована, у её клонов мог сохраниться UUID оригинальной машины. Из-за чего диски временно маунтятся хостом к одной машине, а читать мы их пытаемся с другой. Да, звучит странно, но бывает и такое.
- Если реплицированная машина выключена (а это нормально для реплик — быть выключенными), само собой, все VDDK вызовы и попытки присоединиться будут обречены на провал.
VDDK error 18000: Cannot connect to the host
В большинстве случаев вина за эту ошибку лежит на баге в самом VDDK. А конкретно виновата библиотека gvmomi.dll. И проявляет он себя только под большой нагрузкой. Например, когда много машин бекапится в параллельном режиме, одна из функций принимает значение 0, и библиотека может схлопнуться. А следом падает всё остальное.
Такая вот печальная история.
Но самое плохое в этой истории — то, что никак не получается точно воспроизвести условия возникновения бага. Это то, что тестировщики называют плавающими багами. Поэтому невозможно точно сказать, сколько именно параллельно обрабатываемых машин вызывает падение.
Однако согласно официальным release notes это баг был полностью исправлен. Так что правильный выход из положения — обновить свой хост. Но если по какой-то из причин сделать это невозможно, единственное, чем мы можем помочь — это посоветовать уменьшить количество одновременно обрабатываемых машин.
Больше никак.
VDDK error 14008: The specified server could not be contacted
Итак, если вас постигла эта беда, то первым делом надо проверять сеть. Скорее всего, сбоит связь между vCenter и Veeam proxy. Смотрим, все ли порты открыты и доступны, все ли DNS имена правильно резолвятся в ожидаемые IP адреса. Причём проверять надо конкретный прокси, задействованный в неудавшейся джобе, а не стоящий рядом точно такой же (бывают случаи).
95% кейсов с этой ошибкой закрываются с пометкой «Проблема с DNS/портами в инфраструктуре клиента».
Поэтому ещё раз призываю вас очень внимательно проверить, везде ли указан верный DNS сервер, нет ли закрытых портов и в какие IP резолвятся FQDN имена.
В старых версиях VDDK была схожая ошибка, возникавшая при использовании недефолтного порта для работы с vCenter, на которую приходились оставшиеся 5%, но сейчас VMware скрыло КВ с её описанием, что, вероятно, означает, что КВ более не релевантна. Но можете поискать её в интернет-архивах по номеру 2108658 (Backup fails when a non-default port is specified for VMware vCenter Server).
VDDK error 14009: The server refused connection
И последняя ошибка в нашем сегодняшнем топе — The server refused connection. Тут всё абсолютно банально: что-то мешает установить связь между хостом и прокси. В большинстве случаев оказывается виноват фаервол. Но — тонкий момент — не из-за закрытых портов, а из-за вносимых задержек. Так что первым делом проверяем открытость порта 443, а потом смотрим на таймауты.
Если оба варианта ничего не дали — идём в саппорт. Придётся проверять сам хост. Возможно, он просто слишком загружен и не успевает отвечать вовремя, а, возможно, и что-то другое.
И в завершение немного полезных ссылок:
- Портал нашей орденоносной технической поддержки.
- Veeam Support Knowledge Base