Мы в Veeam любим логи. А поскольку большинство наших решений модульные, то логов они пишут достаточно много. А раз сфера нашей деятельности — это обеспечение сохранности ваших данных (т.е. спокойного сна), то логи должны не только фиксировать каждый чих, но и делать это довольно подробно. Это необходимо чтобы в случае чего было понятно, как это “чего” случилось, кто виноват, и что нужно делать дальше. Тут как в криминалистике: никогда не знаешь, какая мелочь поможет тебе найти убийцу Лоры Палмер.
Поэтому я решил замахнуться на серию статей, где последовательно расскажу о том, что мы пишем в логи, где их храним, как не сойти с ума от их структуры и что же искать у них внутри.
Почему серия статей и почему не описать всё разом?
Просто перечислить, какой лог где лежит и что в нём хранится — затея довольно гиблая. А про поддержание этой информации в актуальном виде даже и думать страшно. Простое перечисление всех возможных видов логов в Veeam Backup & Replication — это таблица на несколько листов мелким шрифтом. Да и актуальна она будет только на момент публикации, т.к. при выходе следующего патча могут появиться новые логи, изменится логика хранимой информации в старых, и т.д. Поэтому гораздо выгоднее будет объяснить их структуру и суть содержащейся в них информации. Это позволит лучше ориентироваться на местах, чем банальная зубрёжка названий.
Поэтому, чтобы не бросаться с головой в омут текстовых простыней, давайте в этой статье проведём некую подготовительную работу. Поэтому сегодня мы не будем залезать в сами логи, а зайдём издалека: составим глоссарий и немного обсудим структуру Veeam с точки зрения генерации логов.
Глоссарий и жаргонизмы
Здесь прежде всего стоит извиниться перед поборникам чистоты русского языка и свидетелями словаря Ожегова. Мы все очень любим свой родной язык, но проклятая IT индустрия работает на английском. Ну вот не мы это придумали, а так исторически сложилось. Не виноватая я, он сам пришёл (с)
В нашем деле проблема англицизмов (и жаргона) имеет свою специфику. Когда под невинными словами вроде «хост» или «гость» весь мир уже давно понимает совершенно конкретные вещи, то на ⅙ части суши продолжается героический разброд и шатание с тыканьем в словари. И строго обязательный аргумент «А вот у нас на работе...».
Плюс есть чисто наша терминология, которая присуща именно продуктам Veeam, хотя некоторые слова и обороты ушли в народ. Поэтому сейчас мы договоримся, какой термин что значит, и в дальнейшем под словом «гость» я буду иметь в виду именно то, что написано в этой главе, а не то, что вы привыкли у себя на работе. И да, это не лично моя прихоть, это устоявшиеся в индустрии термины. Воевать с ними несколько бессмысленно. Хотя похоливорить в каментах я всегда за.
К сожалению, терминов в нашей работе и продуктов крайне много, так что пытаться перечислить их все я не буду. Только самые базовые и необходимые для выживании в море информации о бекапах и логах. Для интересющихся могу также предложить статью коллеги про ленты, где он также приводил список терминов, относящихся к той части функциональности.
Host (Хост): В мире виртуализации это машина с гипервизором. Физическая, виртуальная, облачная — неважно. Если на чём-то запущен гипервизор (ESXi, Hyper-V, KVM etc), то это «что-то» называется хостом. Будь это кластер на десять стоек или ваш ноутбук с лабой на полторы виртуалки — если запустили гипервизор, то стали хостом. Потому что гипервизор хостит виртуальные машины. Есть даже байка, что VMware в своё время хотела добиться твёрдой ассоциации слова хост именно с ESXi. Но не сдюжила.
В современном мире понятие «хост» практически слилось с понятием «сервер», что вносит определённую смуту в общение, особенно если речь про Windows инфраструктуру. Так что любая машина, на которой находится какой-то интересный нам сервис, может быть смело названа хостом. Например, в логах WinSock словом host помечается всё подряд. Классическое «Host not found» тому примером. Так что исходим из контекста, но помним — в мире виртуализаци хост — это то, что хостит гостей (об этом двумя строчками ниже).
Из локальных жаргонизмов (скорее даже акронимов, в данном случае) тут вспоминается, что VMware — это VI, vSphere — это VC, а Hyper-V — это HV.
Guest (Гость): Виртуальная машина, работающая на хосте. Тут даже и объяснять нечего, настолько всё логично и просто. Однако многие старательно тащат сюда какие-то иные смыслы.
Зачем? Я не знаю.
Guest OS, соответственно, операционка гостевой машины. И так далее.
Backup/Replication Job (джобА): Чисто вимовский жаргонизм, обозначающий какое-то из заданий. Backup job == Бекапная Джоба. Как это красиво перевести на русский — никто не придумал, поэтому все говорят «джобА». С ударением на последний слог.
Да, вот так просто берут и говорят «джоба». И даже в письмах так пишут, и всё хорошо.
Всякие Бекапные работы, Задания Бекапа и т.д., спасибо, но не надо. Просто джоба, и вас поймут. Главное — ударение ставить на последний слог.
Backup (Бэкап, бекап. Для труЪ-олдфагов допускается бакУп): Помимо очевидного (лежащая где-то резервная копия данных), означает ещё и саму джобу (три строчки выше, если уже забыли), в результате которой и появляется тот самый бекапный файл. Вероятно, господа носители английского слишком ленивые, чтобы каждый раз говорить I ran my backup job, поэтому они просто говорят I ran my backup, и все друг дружку отлично понимают. Предлагаю поддержать это замечательное начинание.
Consolidate (Консолидация): Термин, появившийся в ESXi 5.0 Опция в меню работы со снапшотами, запускающая процесс удаления так называемых orphaned снапшотов. То есть снапшотов, которые физически имеются, но выпали из отображаемой логической структуры. Теоретически, данный процесс не должен затронуть отображаемые в менеджере снапшотов файлы, однако бывает всякое. Суть процесса консолидации в том, что данные из снапшота (child disk) записываются в основной (parent) диск. Процесс объединения дисков называется мёржем (merge). Если была отдана команда на консолидацию, то запись о снапшоте может быть удалена из базы раньше, чем снапшот будет смёржен и удалён. И если снапшот не удалось удалить по любой причине, то появляются эти самые orphaned снапшоты. Про работу со снапшотами у VMware есть неплохое KB. И мы тоже как-то про них писали на Хабре.
Datastore (Стора или сторадж): Очень широкое понятие, однако в мире виртуализации под ним понимают место, где хранятся файлы виртуальных машин. Но в любом случае тут надо очень чётко понимать контекст и при малейших сомнениях уточнять, что именно ваш собеседник имел в виду.
Proxy (Прокси): Важно сразу понять, что Veeam Proxy — это не совсем тоже самое, к чему мы привыкли на полях интернета. В пределах продуктов от Veeam это некая сущность, которая занимается перекладываем данных из одного места в другое. Если не вдаваться в подробности, то VBR — это командный сервер, а прокси — это его рабочие лошадки. То есть прокси — это машина, через которую течёт трафик и на которой установлены компоненты VBR, которые помогают этим трафиком рулить. Например, перекладывать данные из одного канала в другой или просто цеплять к себе диски (HotAdd mode).
Repository (Репозиторий): Технически это просто запись в базе VBR, указывающая на место, где хранятся бекапы, и как к этом месту подключиться. Фактически это может быть как просто CIFS шара, так и отдельный диск, сервер или бакет в облаке. Опять же, находимся в контексте, но понимаем, что репозиторий — это просто место, где лежат ваши бекапы.
Snapshot (СнапшОт): Любители оксфордской грамматики предпочитают говорить кто снЭпшот, кто снЕпшот, однако безграмотное большинство выигрывает за счёт большей массы. Если кто не знает — это технология, позволяющая восстановить состояние диска на определённый момент времени. Делается это или за счёт временного перенаправления I/O операций в сторону от основного диска — тогда это будет называться RoW (Redirect on Write ) снапшот — или за счёт вынесения перезаписываемых блоков с вашего диска на другой - это будет называться CoW (Copy on Write) снапшот. Именно благодаря широким возможностям по применению этих функций Veeam и может творить свою бекапную магию. Строго говоря, не только лишь им, но это дело ближайших релизов.
В документации и логах ESXi вокруг этого термина творится хаос, и в контексте упоминания снапшотов можно встретить и сами снапшоты, и redo log и даже delta disk. В документации Veeam такого раздрая нет, и снапшот — это снапшот, а редо лог это именно REDO файл, созданный независимым non-persistent диском. REDO файлы удаляются при выключении виртуалки, так что путать их со снапшотами — путь к провалу.
Synthetic (Синтетика): Синтетические бекапы относятся к reverse incremental и forever forward бекапам. Если вы вдруг не сталкивались с этим термином, то это просто один из механизмов, используемых для построения\преобразования бекапной цепочки. Однако в логах также можно встретить понятие Transform, которое используется в рамках создания полных копий из инкрементов (synthetic full).
Task (Таска): Это процесс обработки каждой отдельной машины в рамках джобы. То есть: имеете вы бекапную джобу, куда включено три машины. Значит, каждая машина будет обрабатываться в рамках отдельной таски. Итого, будет четыре лога: основной на джобу и три на таски. Однако тут есть важный нюанс: со временем слово «таска» стало излишне многозначным. Когда мы говорим про общие логи, то подразумеваем, что таска — это именно ВМ. Но свои «таски» есть и на прокси, и на репозитории. Там это может означать и виртуальный диск, и виртуальную машину, и всю джобу. То есть важно не потерять контекст.
Veeam %name% Service (Сервис): На благо успешных бекапов трудится сразу несколько сервисов, список которых можно найти в стандартной оснастке. Их имена достаточно прозрачно отражают их суть, однако среди равных есть самый важный — Veeam Backup Service, без которого остальные работать не будут.
VSS: Технически VSS всегда должен обозначать Microsoft Volume Shadow Copy Service. Фактически используется многими как синоним Application-Aware Image Processing. Что, конечно же, категорически неверно, однако это история из разряда «Любой внедорожник можно назвать джипом, и тебя поймут».
Фантастические логи и места, где они обитают
Хочу начать эту главу с раскрытия великой тайны — какое время отображается в логах?
Запоминайте:
- ESXi всегда пишет логи в UTC+0.
- vCenter ведёт логи по времени своей таймзоны.
- Veeam ведёт логи по времени и таймзоне сервера на котором стоит.
- И только виндовые ивенты в EVTX формате не страдают привязкой ни к чему. При открытии время пересчитывается под машину, на которой их открыли. Самый удобный вариант, хотя бывают сложности и с ним. Единственная ощутимая трудность — разница локалей. Это практически гарантированный путь к нечитаемым логам. Да, есть варианты, как это лечить, но давайте просто не будем спорить с тем, что всё в IT работает на английском, и договоримся всегда выставлять на серверах английскую локаль. Ну пожалуйста.
Теперь всё же поговорим о местах, где живут логи и как их заполучить. В случае VBR есть два подхода.
Вариант первый подходит, если вы не горите желанием выискивать в общей куче файлы, относящиеся именно к вашей беде. Для этого у нас есть отдельный визард, которому можно указать конкретную джобу и конкретный период, за который вам нужны логи. Далее он сам пробежится по папочкам и сложит всё необходимое в один архив. О том, где его искать и как с ним работать, подробно написано в этой КВ.
Однако визард собирает логи не всех заданий и, например, в случае необходимости изучить логи рестора, фейловера или фейлбека путь ваш лежит в папку %ProgramData%/Veeam/Backup. Это главное логохранилище VBR, а %ProgramData% является скрытой папкой и это нормально. Кстати, место по умолчанию можно переназначить с помощью реестрового ключа типа REG_SZ: LogDirectory в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\.
На линуксовых машинах логи рабочих агентов следует искать в /var/log/VeeamBackup/, если используется рутовый или sudo аккаунт. Если таких привилегий у вас нет, то ищите логи в /tmp/VeeamBackup.
Для Veeam agent for %OS_name% логи надо искать в %ProgramData%/Veeam/Endpoint (или %ProgramData%/Veeam/Backup/Endpoint) и /var/log/veeam соответственно.
Если вы используете Application-Aware Image Processing (а скорее всего вы его используете), то ситуация несколько усложняется. Вам понадобятся логи нашего хелпера, которые хранятся внутри самой виртуалки, и логи VSS. О том, как и где добывать это счастье, подробно написано в этой статье. И, конечно же, есть отдельная статья по сбору необходимых системных логов.
События Windows удобно собирать согласно этой КВ. Если вы используете Hyper-V, дело усложняется, так как вам понадобятся ещё и все его логи из ветки Applications and Service Logs > Microsoft > Windows. Хотя всегда можно пойти более дуболомным путём и просто забрать все объекты из %SystemRoot%\System32\winevt\Logs.
Если у вас что-то ломается во время установки/апгрейда, то всё необходимое можно найти в папке %ProgramData%/Veeam/Setup/Temp. Хотя не буду скрывать, что в ивентах ОСи можно найти более полезную инфу, чем в этих логах. Оставшееся интересное лежит в %Temp%, но там в основном логи установки сопутствующего софта, вроде базы, библиотек .Net и прочего. Учтите, что Veeam ставится из msi, и все его компоненты также устанавливаются как отдельные msi пакеты, даже если это не было отображено в GUI. Следовательно, если инсталляция одного из компонентов потерпела неудачу, вся инсталляция VBR будет остановлена. Поэтому надо идти в логи и смотреть, что именно сломалось и в какой момент.
И лайфхак напоследок: получив ошибку при установке, не торопитесь нажимать ОК. Сначала забираем логи, потом жмём ОК. Так вы получите лог, заканчивающийся в момент ошибки, без мусора в конце.
И бывает так, что нужно залезать в логи vSphere. Занятие очень неблагодарное, но, засучив рукава, приходится делать и не такое. В простейшем варианте нам понадобятся логи с ивентами виртуалки vmware.log, которые лежат рядом с её .vmx файлом. В более сложном случае открываем гугл и спрашиваем, где лежат логи для вашей версии хоста, так как VMware обожает это место менять от релиза к релизу. Вот, например, статья для 7.0, а вот для 5.5. Для логов vCenter повторяем процедуру гуглежа. Но в общем случае нам будут интересны логи ивентов хоста hostd.log, ивенты хостов под управлением vCenter vpxa.log, логи ядра vmkernel.log и логи аутентификации auth.log. Ну и в самых запущенных случаях может пригодиться лог SSO, который лежит в папке SSO.
Громоздко? Запутано? Страшно? А ведь это даже не половина информации, с которой работает наш саппорт на ежедневной основе. Так что они действительно очень круты.
Компоненты Veeam
И в качестве завершения этой вводной статьи немного поговорим о компонентах Veeam Backup & Replication. Ибо когда ищешь причину болей, неплохо бы было понимать, как устроен пациент.
Итак, как наверняка известно всем, Veeam Backup — это так называемое SQL-based приложение. То есть все настройки, вся информация и вообще всё, что только необходимо для нормального функционирования — всё это находится в его базе. Вернее, в двух базах, если мы говорим про связку VBR и EM: VeeamBackup и VeeamBackupReporting, соответственно. Так и повелось: ставим ещё одно приложение — появляется ещё одна база. Дабы не хранить все яйца в одной корине.
Но чтобы всё это хозяйство работало слаженно, нам понадобится набор сервисов и приложений, которые свяжут все компоненты воедино. Исключительно для примера, вот так это выглядит в одной из моих лабораторий:
В роли главного дирижёра выступает Veeam Backup Service. Именно он отвечает за обмен информацией с базами. Также он отвечает за запуск всех заданий, занимается оркестрацией выделяемых ресурсов и работает этаким центром коммуникаций для разнообразных консолей, агентов и всего прочего. Словом, без него точно никак, но это совершенно не значит, что он делает всё сам.
В исполнении задуманного ему помогает Veeam Backup Manager. Это не сервис, а сущность, занимающаяся запуском джоб и следящая за процессом их выполнения. Рабочие руки backup service'a, которыми он подсоединяется к хостам, создаёт снапшоты, следит за ретеншеном и так далее.
Но вернёмся к списку сервисов. Veeam Broker Service. Появился в v9.5 (и это не майнер крипты, как тогда подумали некоторые). Занимается сбором информации о VMware хостах и поддержанием её актуальности. Но не бегите сразу писать гневные комментарии, что мы за вами шпионим и сливаем все логины/пароли тащмайору. Всё несколько проще. Когда вы запускаете бекап, то первым делом надо подключиться к хосту и обновить все данные о его структуре. Это довольно медленная и громоздкая история. Просто вспомните, сколько у вас длится операция логина через веб интерфейс, и помните, что там считается только верхний слой. А потом ещё надо всю иерархию раскрыть до нужного места, кстати. Словом, ужас. Если вы запускаете десяток бекапов, значит, каждой джобе надо проделать эту процедуру. Если речь о больших инфраструктурах, то этот процесс может занять минут десять и больше. Поэтому было принято решение выделить под это отдельный сервис, через который можно будет получать всегда актуальную информацию. Он при старте проверяет и сканирует всю добавленную инфраструктуру, а потом старается работать только на уровне инкрементальных изменений. Так что даже если у вас будет запускаться одновременно сто бекапов, они все запросят информацию у нашего брокера, а не будут мучить хосты своими запросами. Если переживаете за ресурсы, то по нашим подсчётам на 5000 виртуалок надо всего около 100 Mb памяти.
Далее у нас идёт Veeam Console. Он же Veeam Remote Console, он же Veeam.Backup.Shell. Это тот самый GUI, который мы видим на скриншотах. Всё просто и очевидно — консоль можно запускать откуда угодно, лишь бы это был Windows и была связь до VBR сервера. Единственное, что можно сказать: FLR процесс будет монтировать точки локально (т.е. на машину, где запущена консоль). Ну и разномастные Veeam Explorers тоже будут запускаться локально, ибо они — часть консоли. Но это меня в дебри уже понесло…
Следующий интересный сервис — Veeam Backup Catalog Data Service. В списке сервисов известен как Veeam Guest Catalog Service. Занимается индексированием файловых систем на гостевых машинах и наполняет этими знаниями папку VBRCatalog. Используется только там, где включена галочка индексации. А включать её есть смысл, только если у вас есть Enterprise Manager. Поэтому совет от всей души: не включайте индексацию просто так, если у вас нет ЕМ. Поберегите свои нервы и время саппорта.
Также из других важных сервисов стоит отметить Veeam Installer Service, с помощью которого происходит доставка и установка необходимых компонентов на прокси, репозитории и прочие гейтвеи. Фактически, он отвозит нужные .msi пакеты на сервера и проводит их установку.
Veeam Data Mover — с помощью запускаемых на проксях (и не только) вспомогательных агентов занимается перекладыванием данных. Например, при бекапе один агент будет читать файлы с датасторы хоста, а второй — их тщательно записывать в бекап.
Отдельно хочется отметить важную вещь, на которую часто реагирую клиенты — это разность версий сервисов и информации в оснастке Programs and Features. Да, список будет одинаковый, а вот в версиях может быть полный раздрай. Это не очень здорово с визуальной точки зрения, однако полностью нормально, если всё работает стабильно. Например, у Installer сервиса номер версии сильно отстаёт от соседних. Ужас и кошмар? Нет, ибо он не переустанавливается целиком, а просто обновляется его DLL. В патче v9.5 U4 произошёл страшный сон техподдержки: при обновлении все сервисы получили новые версии, кроме самого главного. В патче U4b транспортный сервис обогнал все остальные аж на две версии (если судить по цифрам). И это тоже нормально — в нём была найдена серьёзная бага, поэтому он получил бонусное обновление относительно остальных. Поэтому, подводя итог: разница версий МОЖЕТ быть проблемой, но если разница присутствует, а все работает исправно, то скорее всего так и надо. Но никто вам не запрещает уточнить это в техподдержке.
Это были так называемые обязательные или Mandatory services. А есть ещё целая пачка вспомогательных, таких, как Tape Service, Mount Service, vPowerNFS Service и так далее.
Для Hyper-V в целом всё тоже самое, только есть специфичный Veeam Backup Hyper-V Integration Service и свой драйвер для работы с CBT.
И в конце поговорим, кто работает на виртуалках во время бекапа. Для запуска pre- и post-freeze скриптов, для создания шедоу копи, сбора метаданных, работы с логами SQL транзакций и прочего используется Veeam Guest Helper. И если происходит индексация файловых систем, Veeam Guest Indexer . Это временные сервисы, разворачиваемые на время бекапа и удаляемые после него.
В случае Linux машин всё намного проще из-за наличия большого количества встроенных библиотек и возможностей самой системы. Например, индексинг делается через mlocate.
На этом пока всё
Не смею вас больше мучать и краткое введение в подкапотное пространство Veeam считаю оконченным. Да, мы даже близко не дошли до самих логов, но поверьте, чтобы информация, представленная в них, не казалась бессвязным потоком сознания, такое вступление совершенно точно необходимо. Перейти к самим логам я планирую только в третьей статье, а план на следующую — объяснить, кто генерирует логи, что именно в них отображено и почему именно так, а не как-то иначе.
