В Veeam обичаме логовете. И тъй като повечето от нашите решения са модулни, те генерират доста много логове. Тъй като нашата сфера на дейност е осигуряване на безопасността на вашите данни (т.е. мирен сън), логовете трябва не само да записват всеки детайл, но и да го правят достатъчно подробно. Това е необходимо, за да разберем в случай на проблем какво точно се е случило, кой е виновен и какво да правим след това. Тук е като в криминалистиката: никога не знаеш кой малък детайл може да ти помогне да намериш убиеца на Лора Палмър.
Затова реших да започна поредица от статии, в които последователно ще разкажа какво записваме в логовете, къде ги съхраняваме, как да не полудяваме от структурата им и какво да търсим в тях.
Защо поредица от статии и защо не да опиша всичко наведнъж?
Просто да изброя какъв лог къде се намира и какво съдържа — е доста неудачна идея. А поддържането на тази информация актуална е дори страшно да си помислим. Простото изброяване на всички възможни видове логове в Veeam Backup & Replication е таблица с няколко страници на малък шрифт. И ще бъде актуална само в момента на публикуване, тъй като при излизането на следващия патч могат да се появят нови логове, да се промени логиката на съхраняваната информация в старите и т.н. Затова ще бъде много по-изгодно да обясним структурата им и същността на съдържащата се в тях информация. Това ще улесни ориентацията на място, отколкото просто запаметяване на имената.
Затова, за да не скочим веднага в дълбоките текстови води, да направим малко подготовка в тази статия. Днес няма да разглеждаме самите логове, а ще подходите отдалеч: ще съставим глосар и ще обсъдим структурата на Veeam от гледна точка на генерацията на логове.
Глосар и жаргони
Тук първо трябва да се извиня на защитниците на чистотата на българския език и на свидетелите на речника на Ожегов. Всички ние много обичаме родния си език, но проклетата IT индустрия работи на английски. Не сме ние, които сме го измислили, така е исторически. Не съм виновен, той сам дойде.
В нашата индустрия проблемата с англицизмите (и жаргона) има своя специфика. Когато под невинни думи като «хост» или «гост» целият свят вече разбира изключително конкретни неща, на ⅙ от сушата продължава героичното размирие и колебание с търсене в речниците. И строго задължителен аргумент «А при нас на работа…».
Освен това имаме и собствена терминология, която е специфична именно за продуктите Veeam, макар че някои думи и изрази се утвърдиха в обществото. Затова сега ще се споразумеем какво означава всеки термин, и впоследствие под думата «гост» ще имам предвид именно това, което е написано в тази глава, а не онова, с което сте свикнали на работното си място. И да, това не е лично мое желание, а утвърдени термини в индустрията. Битката с тях е донякъде безсмислена. Въпреки това, винаги съм отворен за дискусии в коментарите.
За съжаление, термините в нашата работа и продукти са изключително много, така че няма да се опитвам да изброя всички. Само най-базовите и необходими за оцеляване в морето от информация за бекъпи и лога. За интересуващите се мога също на колегите за лентите, където той също предоставя списък с термини, свързани с тази част от функционалността.
Host (Хост): В света на виртуализацията това е машина с хипервизор. Физическа, виртуална, облачна — не е важно. Ако на нещо е стартиран хипервизор (ESXi, Hyper-V, KVM и т.н.), то това «нещо» се нарича хост. Няма значение дали става дума за клъстер от десет сървъра или вашия лаптоп с лаборатория от една и половина виртуални машини — ако сте стартирали хипервизор, то вече сте хост. Защото хипервизорът хоства виртуални машини. Има дори анекдот, че 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 snapshots. Тоест снимки, които физически съществуват, но са изпаднали от показаната логическа структура. Теоретично, този процес не трябва да засяга показваните във мениджъра на снимките файлове, но стават и такива работи. Същността на процеса на консолидация е, че данните от снимката (child disk) се записват в основния (parent) диск. Процесът на обединение на дисковете се нарича мърдж (merge). Ако е дадена команда за консолидация, записът за снимката може да бъде изтрит от базата преди снимката да бъде смърджирана и изтрита. И ако не е успяло да се изтрие снимката по каквато и да е причина, тогава се появяват тези orphaned snapshots. За работата със снимките 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 около този термин цари хаос, и в контекста на споменаването на snapshots може да се срещнат самите snapshots, redo log и дори delta disk. В документацията на Veeam няма такъв хаос, и snapshot — това е snapshot, а redo log е именно REDO файл, създаден от независим non-persistent диск. REDO файловете се изтриват при изключване на виртуалната машина, така че да ги бъркаш с snapshots — е пътят към провал.
Синтетичен (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 води логове според времето и часовата зона на сървъра, на който е инсталиран.
- И само по себе, Windows събития в EVTX формат не зависят от никого. При отварянето на времето то се преизчислява спрямо компютъра, на който са отворени. Най-удобният вариант, въпреки че понякога има трудности и с него. Единствената съществена трудност е разликата в локализациите. Това е практически гарантирано път към нечетими логове. Да, има варианти как да се справим, но нека просто не спорим, че всичко в ИТ работи на английски и да се уговорим винаги да настроим сървърите на английска локализация. Моля.
Сега все пак да поговорим за местата, където живеят логовете и как да ги получим. В случай на VBR има два подхода.
Първият вариант подхожда, ако нямате желание да търсите в купчината файлове, свързани точно с вашия проблем. За това имаме отделен магьосник, на който можете да посочите конкретна задача и конкретен период, за който ви трябват логовете. След това той сам ще прегледа папките и ще събере всичко необходимо в един архив. Относно това къде да го търсите и как да работите с него, е подробно написано в .
Въпреки това, магьосникът не събира логовете на всички задачи и, например, в случай на необходимост да разгледате логовете на ресторанта, фейловера или фейлбека, вашият път води до папката %ProgramData%/Veeam/Backup. Това е основното хранилище за логове на VBR, а %ProgramData% е скрита папка и това е нормално. Между другото, местоположението по подразбиране може да бъде преназначено с помощта на регистровия ключ тип REG_SZ: LogDirectory в клона HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication.
На линуксови машини логовете на работните агенти следва да се търсят в /var/log/VeeamBackup/, ако се използва root или sudo акаунт. Ако нямате такива права, търсете логовете в /tmp/VeeamBackup.
За Veeam agent for %OS_name% логовете трябва да се търсят в %ProgramData%/Veeam/Endpoint (или %ProgramData%/Veeam/Backup/Endpoint) и /var/log/veeam съответно.
Ако използвате Application-Aware Image Processing (а вероятно го правите), ситуацията е малко по-сложна. Ще ви трябват логовете на нашия helper, които се съхраняват в самата виртуална машина, и логовете на 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 файл. В по-сложния случай отваряме Google и питаме, къде се намират логовете за вашата версия на хоста, тъй като VMware обожава да сменя това място от версия на версия. Ето, например, , а ето за . За логовете на vCenter повтаряме процедурата . Но в общия случай нас ни интересуват логовете от събитията на хоста hostd.log, събитията на хостовете под управление на vCenter vpxa.log, логовете на ядрото vmkernel.log и логовете за удостоверяване auth.log. И в най-проблематичните случаи може да ви потрябва логът на SSO, който се намира в папката SSO.
Обемисто? Заплетено? Страшно? А всъщност това дори не е половината информация, с която нашата поддръжка работи на ежедневна основа. Така че наистина те са много добри.
Компоненти на Veeam
И в заключение на тази уводна статия, нека поговорим малко за компонентите на Veeam Backup & Replication. Защото когато търсите причина за проблемите, е добре да разбирате как е устроен пациентът.
Както със сигурност е известно на всички, Veeam Backup е така нареченото SQL-базирано приложение. Тоест, всички настройки, информация и всичко необходимо за нормалното му функциониране се намира в неговата база. Всъщност, в две бази, ако говорим за връзката VBR и EM: VeeamBackup и VeeamBackupReporting, съответно. Постепенно се налага: инсталираме още едно приложение — появява се още една база. За да не съхраняваме всичките яйца в една кошница.
Но за да работи всичко безпроблемно, ще ни е необходим набор от услуги и приложения, които свързват всички компоненти в едно. Изключително за пример, ето как изглежда това в една от моите лаборатории:
В ролята на главен диригент се явява Veeam Backup Service. Именно той отговаря за обмена на информация с базите. Също така отговаря за стартирането на всички задачи, управлява ресурсите и служи за център за комуникации между различни конзоли, агенти и всичко останало. С други думи, без него определено не може, но това съвсем не означава, че той прави всичко сам.
В изпълнението на замисленото му помага Veeam Backup Manager. Това не е услуга, а същност, занимаваща се с стартирането на задачи и следяща процеса на изпълнението им. Работните ръце на backup service-а, с които се свързва към хостовете, създава снимки, следи времето за задържане и така нататък.
Но нека се върнем към списъка с услуги. 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 — с помощта на стартирани на прокси (и не само) помощни агенти се занимава с прехвърляне на данни. Например, по време на архивиране един агент ще чете файлове от datastore на хоста, а другият — внимателно ще ги записва в резервното копие.
Отделно искам да отбележа важен аспект, на който често реагират клиентите — това е разликата в версиите на услугите и информацията в инструмента 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.
И накрая ще говорим за това, кой работи на виртуални машини по време на резервно копие. За стартиране на предварителни и последващи скриптове, за създаване на шадоу копия, събиране на метаданни, работа с логове на SQL транзакции и друго се използва Veeam Guest Helper. И ако се извършва индексация на файловите системи, Veeam Guest Indexer . Това са временни услуги, които се разгръщат за времето на резервното копие и се изтриват след него.
В случай на Linux машини всичко е много по-просто заради наличието на голямо количество вградени библиотеки и възможности на самата система. Например, индексацията се извършва чрез mlocate.
На това засега е всичко
Не смея да ви мъча повече и краткото въведение в подкапотното пространство на Veeam считам за завършено. Да, дори не сме се доближили до самите логове, но повярвайте, за да информацията, представена в тях, да не изглежда като несвързан поток на съзнанието, такова въведение е изключително необходимо. Планирам да премина към самите логове само в третата статия, а планът за следващата е да обясня, който генерира логовете, какво именно е отображено в тях и защо точно така, а не по друг начин.
Източник: habr.com
