Мы в 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, дело jgznm усложняется, так как вам понадобятся ещё и все его логи из ветки 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 считаю оконченным. Да, мы даже близко не дошли до самих логов, но поверьте, чтобы информация, представленная в них, не казалась бессвязным потоком сознания, такое вступление совершенно точно необходимо. Перейти к самим логам я планирую только в третьей статье, а план на следующую объяснить кто генерирует логи, что именно в них отображено и почему именно в так, а не как-то иначе.
