Продолжаем наше погружение в увлекательный мир гадан... траблшутинга по логам. В предыдущей статье мы договорились о значении базовых терминов и одним глазком рассмотрели общую структуру Veeam, как единого приложения. Задача на эту - разобраться как формируются лог файлы, что за информация в них отображена и почему они выглядят как выглядят.
Как вы думаете, что вообще такое эти "логи"? По мнению большинства, логам любого приложения должна быть отведена роль этакой всемогущей сущности, которая большую часть времени прозябает где-то на задворках, но в нужный момент появляется из ниоткуда в сияющих доспехах и всех спасает. То есть в них должно быть всё, начиная с малейших ошибок в каждом компоненте, до отдельных транзакций базы. И чтобы после ошибки сразу писалось как ещё исправить. И умещаться это всё должно в пару мегабайт, не больше. Это же просто текст! Не могут текстовые файлы занимать десятки гигабайт, я где-то это слышал!
Итак, логи
В реальном мире логи это всего лишь архив диагностической информация. И что там хранить, откуда брать информацию для хранения и насколько подробной она должна быть, решать самим разработчикам. Кто-то идёт по пути минимализма храня записи уровня ВКЛ/ВЫКЛ, а кто-то старательно сгребает всё до чего только смог дотянуться. Хотя есть ещё и промежуточный вариант с возможностью выбора так называемого Logging Level, когда ты сам указываешь насколько подробную информацию ты хочешь хранить и насколько у тебя много лишнего места на дисках =) У VBR таких уровней аж шесть, кстати говоря. И, поверьте, вы не хотите видеть что происходит при максимально подробном логировании со свободным местом на вашем диске.
Хорошо. Мы примерно поняли что хотим сохранять, но встаёт законный вопрос: откуда брать эту информацию? Часть событий для логирования, конечно, формируем мы сами нашими внутренними процессами. Но что делать, когда происходит взаимодействие с внешней средой? Чтобы не скатываться в кромешный ад из костылей и велосипедов, Veeam имеет тенденцию не изобретать уже изобретённые изобретения. Всегда, когда есть уже готовое API, встроенная в систему функция, библиотека и т.п., мы отдадим преимущество готовым вариантам, прежде чем начинать городить свои хитроумные решения. Хотя последних тоже хватает. Поэтому при анализе логов важно понимать, что львиная доля ошибок приходится на сообщения от сторонних API, системных вызовов и прочих библиотек. В данном случае роль VBR сводится к форварду этих ошибок в файлы логов as is. А основная задача пользователя - научиться понимать, какая строчка от кого, и за что этот “кто” отвечает. Поэтому, если код ошибки из лога VBR приводит вас на страницу MSDN, это нормально и правильно.
Как мы договорились ранее: Veeam — это так называемое SQL-based приложение. А значит все настройки, вся информация и вообще всё, что только необходимо для нормального функционирования — всё хранится в его базе. Отсюда простая истина: то, чего нет в логах, скорее всего есть в базе. Но и это не серебряная пуля: некоторых вещей нет ни в локальных логах компонентов Veeam, ни в его базе. Поэтому надо научиться изучать логи хоста, логи локальной машины и логи вообще всего, что участвует в процессе бекапа и рестора. А бывает и так, что нужной информации нет вообще нигде. Таков путь.
Несколько примеров таких API
Данный список не ставит себе целью быть исключительной полноты, так что не надо в нём искать истину в последней инстанции. Его задача - лишь показать самые частые сторонние API и технологии, используемые в наших продуктах.
Начнём с VMware.
Первым в списке будет vSphere API. Используется для аутентификации, чтения иерархии, создания и удаления снапшотов, запроса информации о машинах и многого (очень многого) чего другого. Функционал решения очень широкий, поэтому всем желающим могу порекомендовать VMware vSphere API Reference для версии 5.5 и 6.0. Для более актуальных версий всё просто гуглится.
VIX API. Чёрная магия гипервизора, для которой есть отдельный список ошибок. VMware API для работы с файлами на хосте без подключения к ним по сети. Вариант последней надежды, когда надо положить файлик в машину, до которой нет более лучшего канала связи. Представляет из себя боль и страдание, если файлик большой, а хост загружен. Но тут работает правило, что даже 56,6 Кб/с это лучше чем 0 Кб/с. В Hyper-V подобная штука называется PowerShell Direct. Но так было только до появления
vSpehere Web Services API Начиная с vSphere 6.0 (примерно, т.к. впервые этот API был представлен на версии 5.5) используется для работы с гостевыми машинами и уже практически везде вытеснил VIX. По сути, это ещё один API для управления vSphere. Интересующимся могу посоветовать изучить отличный мануал.
VDDK (Virtual Disk Development Kit). Библиотека, о которой частично говорилось в этой статье. Используется для чтения виртуальных дисков. Когда-то давно была частью VIX, однако со временем вынесена в отдельный продукт. Зато на правах наследника использует те же коды ошибок, что и VIX. Но по какой-то причине в самом SDK нет никакого описания этих ошибок. Поэтому опытным путём было выяснено, что ошибки VDDK с другими кодами -- всего лишь трансляция из бинарного в десятичный код. Состоит из двух частей – первая половина являет собой недокументированную информацию о контексте, а вторая часть -- традиционные VIX/VDDK ошибки. Например, если видим:
VDDK error: 21036749815809.Unknown error
То смело конвертируем это в hex и получаем 132200000001. Неинформативное начало 132200 просто откидываем, а остаток и будет нашим кодом ошибки (VDDK 1: Unknown error). Про самые частые VDDK errors как раз недавно была отдельная статья.
Теперь посмотрим на WIndows.
Здесь всё самое нужное и важное для нас можно найти в стандартном Event Viewer. Но есть одна загвоздка: по давней традиции Windows логирует не полноценный текст ошибки, а только её номер. К примеру, ошибка 5 -- это “Access denied”, а 1722 -- это “The RPC server is unavailable”, ну и 10060 -- это “Connection timed out”. Конечно, здорово, если ты помнишь самые известные, однако как быть с доселе невиданными?
А чтобы жизнь совсем мёдом не казалось, ошибки ещё и в шестнадцатеричном виде хранятся, с префиксом 0x8007. К примеру, 0x8007000e -- это на самом деле 14, Out of Memory. Зачем и для кого так было сделано - тайна, покрытая мраком. Однако полный список ошибок можно скачать бесплатно и без СМС из девцентра.
Кстати, иногда встречаются и другие префиксы, а не только 0x8007. В такой печальной ситуации для понимания HRESULT (“result handle”) нужно ещё глубже влезать в документацию для разработчиков. В обычной жизни делать я вам такое не советую, но если вдруг прижали к стенке или просто интересно, теперь вы знаете, что делать.
Но товарищи в Microsoft несколько сжалились над нами и явили миру утилиту ERR. Это небольшой кусочек консольного счастья, который умеет переводить коды ошибок на человеческий без использования гугла. Работает она примерно так.
C:\Users\root\Desktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"Возникает законный вопрос: а чего ради мы в логи сразу не пишем расшифровку, а оставляем эти таинственные коды? Ответ в сторонних приложениях. Когда ты сам дёргаешь какой-то WinAPI вызов, то расшифровать его ответ не составляет труда, ибо для этого даже есть свой специальный WinAPI вызов. Но как было уже сказано, в наши логи попадает всё, что только приходит к нам в ответах. И тут уже для расшифровки пришлось бы постоянно мониторить этот поток сознания, выцеплять из него куски с ошибками винды, расшифровывать их и вставлять обратно. Скажем честно, не самое увлекательное занятие.
Windows File Management API всячески используется при работе с файлами. Создание файлов, удаление, открытие на запись, работа с атрибутами и прочее, и прочее.
Упомянутый выше PowerShell Direct как аналог VIX API в мире Hyper-V. К сожалению, не такой гибкий: масса ограничений по функциональности, работает не с каждой версией хоста и далеко не со всеми гостями.
RPC (Remote Procedure Call) Я думаю, что нет ни одного человека, работавшего с WIndows, кто бы не видел ошибок, связанных с RPC. Несмотря на популярное заблуждение, это не какой-то единый протокол, а любой клиент-серверный протокол, удовлетворяющий ряду параметров. Однако если в наших логах есть ошибка RPC, в 90% случаев это будет ошибка от Microsoft RPC, который является частью DCOM (Distributed Component Object Model). В сети можно найти огромное количество документации на эту тему, однако львиная её доля довольно сильно устарела. Но если есть острое желание изучить тему, то могу рекомендовать статьи What is RPC?, How RPC Works и длиннющий список ошибок RPC.
Основные причины возникновения RPC ошибок в наших логах - это неудавшиеся попытки взаимодействия между компонентами VBR (сервер > прокси, например) и чаще всего из-за проблем со связью.
Топовый топ среди всех топов - это ошибка The RPC server is unavailable (1722). Если по-простому, то клиент не смог установить соединение с сервером. Как и почему - единого ответа нет, но обычно это проблема с аутентификацией или с сетевым доступом до порта 135. Последнее характерно для инфраструктур с динамическим назначением портов. На эту тему есть даже отдельная КВ. А у Microsoft - объёмный гайд по поиску причин неисправности.
Вторая по популярности ошибка: There are no more endpoints available from the endpoint mapper (1753). RPC клиент или сервер не смогли назначить себе порт. Обычно возникает, когда сервер (в нашем случае гостевая машина) был настроен на динамическое выделение портов из узкого диапазона, который закончился. А если заходить со стороны клиента (в нашем случае VBR-сервера), это значит, что наш VeeamVssAgent или не запустился, или не был зарегистрирован как RPC интерфейс. На эту тему так же есть отдельная КВ.
Ну и чтобы завершить Топ-3 ошибок RPC, вспомним RPC function call failed (1726). Появляется, если связь была установлена, но RPC запросы не отрабатывают. Например, мы запрашиваем информацию о статусе VSS (вдруг там прямо сейчас шедоу копи делается, а мы лезть пытаемся), а в ответ нам тишина и игнор.
Windows Tape Backup API нужен для работы с ленточными библиотеками или приводами. Как я упоминал в начале: писать свои драйвера и мучиться потом с поддержкой каждого устройства нам нет никакого удовольствия. Поэтому у вима нет никаких своих драйверов. Всё через стандартный API, поддержку которого реализуют сами вендоры железа. Так ведь намного логичней, правда?
SMB/CIFS Все по привычке пишут их рядом, хотя далеко не все помнят, что CIFS (Common Internet File System) - это просто частная версия SMB (Server Message Block). Так что ничего плохого в обобщении этих понятий нет. Вот Samba - это уже Linux\Unix реализация, и там есть свои особенности, но это я отвлёкся. Что тут важно: когда Veeam просит записать что-то по UNC пути (\server\directory), сервер использует иерархию драйверов файловой системы, включая mup и mrxsmb, для записи на шару. Соответственно, ошибки генерировать будут тоже эти драйверы.
Никак нельзя обойтись без Winsock API. Если что-то надо сделать по сети, VBR работает через Windows Socket API, в народе известный как Winsock. Так что если видим в логе связку IP:Port, это оно. В официальной документации есть неплохой список возможных ошибок.
Упомянутый выше WMI (Windows Management Instrumentation) - это некое всемогущее API для управления всего и всем в мире Windows. Например, при работе с Hyper-V практически все запросы к хосту происходят именно через него. Словом, вещь совершенно незаменимая и очень мощная в своих возможностях. В попытках помочь выяснить, где и что сломалось, очень помогает встроенная тула WBEMtest.exe.
И последний по списку, но совершенно не последний по значимости - VSS (Volume Shadow Storage). Тема настолько неисчерпаемая и загадочная, насколько много по ней написано документации. Shadow Copy проще всего понимать как особый тип снапшота, которым по сути он и является. Благодаря ему в VMware можно делать application-consistent бекапы, а в Hyper-V вообще чуть ли не всё. У меня есть в планах сделать отдельную статью с некой выжимкой по VSS, но пока можете попробовать почитать это описание. Только осторожно, т.к. попытка понять VSS с наскока может привести к травмам головного мозга.
На этом, пожалуй, можно и остановиться. Задачу объяснить самые базовые вещи считаю выполненной, так что в следующей главе уже будем смотреть на логи. Но если остались вопросы, то не стесняйтесь озвучивать их в комментариях.
