Ми у 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 має . І ми теж якось про них .
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_MACHINESOFTWAREVeeamVeeam 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%System32winevtLogs.
Якщо у вас щось ламається під час встановлення/апгрейду, все необхідне можна знайти в папці %ProgramData%/Veeam/Setup/Temp. Хоча не приховуватиму, що в івентах ОСі можна знайти більш корисну інфу, ніж у цих логах. Цікаве, що залишилося, лежить в % Temp %, але там в основному логи установки супутнього софту, на зразок бази, бібліотек .Net та іншого. Врахуйте, що Veeam ставиться з msi, і всі його компоненти також встановлюються як окремі пакети msi, навіть якщо це не було відображено в GUI. Отже, якщо інсталяція одного з компонентів зазнала невдачі, всю інсталяцію VBR буде зупинено. Тому треба йти в логі та дивитися, що саме зламалося і в якийсь момент.
І лайфхак наостанок: отримавши помилку при встановленні, не поспішайте натискати ОК. Спочатку забираємо логи, потім тиснемо ОК. Так ви отримаєте балку, що закінчується в момент помилки, без сміття в кінці.
І буває так, що потрібно залазити до логів vSphere. Заняття дуже невдячне, але, засукавши рукави, доводиться робити не таке. У найпростішому варіанті нам знадобляться логи з івентами віртуалки vmware.log, які лежать поруч із її .vmx файлом. У складнішому випадку відкриваємо гугл і запитуємо, де лежать логи для вашої версії хоста, оскільки VMware любить це місце міняти від релізу до релізу. Ось наприклад, , а ось для . Для логів 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 Мб пам'яті.
Далі у нас іде 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, за допомогою якого відбувається доставка та встановлення необхідних компонентів на проксі, репозиторії та інші гейтвеї. Фактично, він відвозить потрібні .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 вважаю закінченим. Так, ми навіть близько не дійшли до самих ліг, але повірте, щоб інформація, представлена в них, не здавалася безладним потоком свідомості, такий вступ абсолютно точно необхідний. Перейти до самих логів я планую лише у третій статті, а план на наступну — пояснити, хто генерує логи, що саме в них відображено і чому саме так, а не інакше.
Джерело: habr.com
