Компоненти и речник на Veeam Log Diving

Ние във Veeam обичаме трупи. И тъй като повечето от нашите решения са модулни, те пишат много журнали. И тъй като обхватът на нашата дейност е да гарантираме безопасността на вашите данни (т.е. спокоен сън), тогава регистрационните файлове трябва не само да записват всяко кихане, но и да го правят в някои подробности. Това е необходимо, за да може в случай на нещо да е ясно как се е случило това „какво“, кой е виновен и какво трябва да се направи по-нататък. Това е като в криминалистиката: никога не знаеш какво малко нещо ще ти помогне да откриеш убиеца на Лора Палмър.

Затова реших да се спра на поредица от статии, в които последователно ще говоря какво записваме в логовете, къде ги съхраняваме, как да не се побъркаме от структурата им и какво да търсим вътре в тях.

Защо поредица от статии и защо не описвате всичко наведнъж?

Простото изброяване кой дневник къде е и какво се съхранява в него е доста катастрофално начинание. И е страшно дори да си помислим да поддържаме тази информация актуална. Прост списък на всички възможни типове регистрационни файлове във Veeam Backup & Replication е таблица на няколко листа с малък шрифт. Да, и ще бъде от значение само по време на публикуването, защото. когато бъде пуснат следващият пач, може да се появят нови логове, логиката на съхранената информация в старите ще се промени и т.н. Следователно ще бъде много по-изгодно да се обясни тяхната структура и същността на информацията, съдържаща се в тях. Това ще ви позволи да се ориентирате по-добре в местата, отколкото баналното тъпчене с имена.

Ето защо, за да не се втурваме стремглаво към басейна от текстови листове, нека направим малко подготвителна работа в тази статия. Затова днес няма да навлизаме в самите регистрационни файлове, а ще отидем отдалеч: ще съставим речник и ще обсъдим малко структурата на Veeam по отношение на генерирането на регистрационни файлове.

Речник и жаргон

Тук, на първо място, си струва да се извиним на защитниците на чистотата на руския език и свидетелите на речника на Ожегов. Всички много обичаме родния си език, но проклетата ИТ индустрия работи на английски. Е, не ние го измислихме, но се случи исторически. Не съм виновен, той сам дойде (c)

В нашия бизнес проблемът с англицизмите (и жаргона) има своята специфика. Когато под невинни думи като "домакин" или "гост" целият свят отдавна разбира съвсем конкретни неща, то на ⅙ от земята продължава героичното объркване и залитане с ровене в речниците. И строго задължителният аргумент "Ама на нашата работа...".

Плюс това има чисто нашата терминология, която е присъща на продуктите на Veeam, въпреки че някои думи и фрази са отишли ​​при хората. Затова сега ще се съгласим какъв термин какво означава и в бъдеще под думата „гост“ ще имам предвид точно това, което е написано в тази глава, а не това, с което сте свикнали на работа. И да, това не е моя лична приумица, това са утвърдени термини в бранша. Борбата с тях е донякъде безсмислена. Въпреки че винаги съм за разхлаждането в коментарите.

За съжаление има много термини в нашата работа и продукти, така че няма да се опитвам да ги изброявам всички. Само най-основната и необходима информация за резервни копия и регистрационни файлове за оцеляване в морето. За интересуващите се мога и аз предложете статия колеги за лентите, където също даде списък с термини, свързани с тази част от функционалността.

Домакин (домакин): В света на виртуализацията това е машина с хипервизор. Физически, виртуални, облачни – няма значение. Ако нещо работи с хипервайзор (ESXi, Hyper-V, KVM и т.н.), тогава това „нещо“ се нарича хост. Независимо дали става въпрос за клъстер с десет стелажа или вашия лаптоп с лаборатория за една и половина виртуални машини - ако сте стартирали хипервайзор, вие сте станали хост. Тъй като хипервайзорът хоства виртуални машини. Има дори история, че VMware по едно време искаше да постигне твърда асоциация на думата хост с ESXi. Но тя не го направи.

В съвременния свят понятието "хост" практически се е сляло с понятието "сървър", което внася известно объркване в комуникацията, особено що се отнася до инфраструктурата на Windows. Така че всяка машина, която хоства някаква услуга, представляваща интерес за нас, може спокойно да се нарече хост. Например в логовете на WinSock всичко е отбелязано с думата хост. Класическият „Хостът не е намерен“ е пример за това. Така че започваме от контекста, но помнете – в света на виртуализацията хост е това, което хоства гости (повече за това в два реда по-долу).

От местния жаргон (в този случай по-скоро дори акроними) тук се припомня, че VMware е VI, vSphere е VC, а Hyper-V е HV.

Гост (Гост): Виртуалната машина, работеща на хоста. Тук няма какво да се обяснява, всичко е толкова логично и просто. Мнозина обаче усърдно влачат тук някои други значения.

За какво? Не знам.
Guest OS, съответно операционната система на гост машината. И така нататък.

Задание за архивиране/репликация (jobA): Чист Wim жаргон, обозначаващ някои от задачите. Задача за архивиране == Задача за архивиране. Никой не е измислил как да го преведе красиво на руски, така че всички казват „JobA“. С ударение върху последната сричка.

Да, те просто го вземат и казват „joba“. И дори в писмата пишат така и всичко е наред.
Всякакви задачи за архивиране, задачи за архивиране и т.н., благодаря, но няма нужда. Само работа и ще бъдете разбрани. Основното нещо е да поставите ударението върху последната сричка.

Архивиране (Архивиране, резервно копие. За истински стари фагове архивирането е разрешено): В допълнение към очевидното (резервно копие на данни, лежащо някъде), това означава и самата работа (три реда по-горе, ако вече сте забравили), в резултат на което се появява самият архивен файл. Вероятно господата, за които английският е роден, са твърде мързеливи, за да кажат, че съм изпълнявал резервното си копие всеки път, така че те просто казват, че съм изпълнявал резервното си копие и всички се разбират перфектно. Приканвам ви да подкрепите тази прекрасна инициатива.

Консолидиране (Консолидиране): Термин, който се появи в ESXi 5.0 Опция в менюто за моментни снимки, която стартира процеса на изтриване на така наречените осиротели моментни снимки. Тоест моментни снимки, които са физически налични, но са изпаднали от показаната логическа структура. Теоретично този процес не трябва да засяга файловете, показани в мениджъра на моментни снимки, но всичко може да се случи. Същността на процеса на консолидация е, че данните от моментната снимка (детски диск) се записват на основния (родителски) диск. Процесът на комбиниране на дискове се нарича сливане. Ако е издадена команда за консолидация, тогава записът на моментната снимка може да бъде премахнат от базата данни, преди снимката да бъде обединена и изтрита. И ако моментната снимка не може да бъде изтрита по някаква причина, тогава се появяват същите тези осиротели снимки. Относно работата с моментни снимки, VMware има добър KB. И ние също по някакъв начин за тях написа на Хабре.

Datastore (Stora или съхранение):  Много широко понятие, но в света на виртуализацията се разбира като място, където се съхраняват файлове на виртуална машина. Но във всеки случай тук трябва много ясно да разберете контекста и при най-малкото съмнение да изясните какво точно е имал предвид вашият събеседник. 

Прокси (прокси): Важно е веднага да разберете, че Veeam Proxy не е съвсем същото като това, с което сме свикнали в Интернет. В рамките на продуктите на Veeam това е един вид обект, който се занимава с прехвърляне на данни от едно място на друго. Ако не навлизате в подробности, тогава VBR е команден и контролен сървър, а прокситата са неговите работни коне. Тоест, прокси е машина, през която протича трафик и на която са инсталирани VBR компоненти, които помагат да се управлява този трафик. Например, за прехвърляне на данни от един канал към друг или просто за прилепване на дискове към себе си (режим HotAdd).

Хранилище (Хранилище):  Технически това е просто запис в базата данни на VBR, указващ мястото, където се съхраняват архивите, и как да се свържете с това място. Всъщност това може да бъде или просто CIFS топка, или отделен диск, сървър или кофа в облака. Отново, ние сме в контекст, но разбираме, че хранилището е просто място, където са вашите архиви.

 Моментна снимка (SnapshOt): Любителите на граматиката в Оксфорд предпочитат да казват кой е снимка и кой е снимка, но неграмотното мнозинство печели от по-голямата маса. Ако някой не знае, това е технология, която ви позволява да възстановите състоянието на диск в определен момент от време. Това се прави или чрез временно пренасочване на входно-изходните операции далеч от основния диск - тогава ще се нарича моментна снимка RoW (Пренасочване при запис) - или чрез преместване на презаписваеми блокове от вашия диск на друг - това ще се нарича CoW (Копиране при запис ) моментна снимка. Благодарение на широките възможности за използване на тези функции, Veeam може да направи своята резервна магия. Строго погледнато, не само те, но това е въпрос на следващите издания.

Има хаос около този термин в документацията и регистрационните файлове на ESXi и в контекста на споменаването на моментни снимки можете да намерите самите моментни снимки, и повторете журнала, и дори делта диск. Документацията на Veeam не съдържа такова разкъсване, а моментната снимка е моментна снимка, а журналът за повторение е точно REDO файл, създаден от независим непостоянен диск. REDO файловете се изтриват, когато виртуалната машина е изключена, така че объркването им с моментни снимки е път към провал.

Синтетика (Синтетика): Синтетичните архиви са обратни инкрементални и завинаги напред архиви. В случай, че не сте срещали този термин, това е само един от механизмите, използвани за изграждане на трансформация на резервна верига. В регистрационните файлове обаче можете да намерите и концепцията за трансформация, която се използва в рамките на създаване на пълни копия от нараствания (синтетични пълни).

Задача (Задача): Това е процесът на обработка на всяка отделна машина в рамките на работата. Тоест: имате резервно задание, което включва три машини. Това означава, че всяка кола ще бъде обработена като част от отделна задача. Общо ще има четири лога: основният за работни места и три за задачи. Тук обаче има важен нюанс: с течение на времето думата "задача" стана ненужно двусмислена. Когато говорим за общи регистрационни файлове, имаме предвид, че задачата е точно VM. Но има „задачи“ както на проксито, така и на хранилището. Там може да означава виртуален диск, виртуална машина и цялата работа. Тоест, важно е да не се губи контекстът.

Veeam %name% услуга:  В полза на успешното архивиране работят няколко услуги наведнъж, чийто списък можете да намерите в стандартното оборудване. Имената им доста прозрачно отразяват същността им, но сред равните е най-важното - Veeam Backup Service, без което останалите няма да работят.

VSS: Технически, VSS винаги трябва да означава Microsoft Volume Shadow Copy Service. Всъщност той се използва от мнозина като синоним на Application-Aware Image Processing. Което, разбира се, е категорично погрешно, но това е история от категорията „Всеки SUV може да се нарече джип и ще бъдете разбрани“.

Фантастични трупи и къде живеят

Искам да започна тази глава, като разкрия голямата тайна - колко часа се показва в регистрационните файлове?

Помня:

• ESXi винаги записва регистрационни файлове в UTC+0.
• vCenter поддържа регистрационни файлове според часа на своята часова зона.
• Veeam поддържа регистрационни файлове по време и часова зона на сървъра, на който се намира.
• И само събитията на Windows във формат EVTX не страдат от обвързване с нищо. При отваряне времето се преизчислява за автомобила, на който са отворени. Най-удобният вариант, въпреки че има трудности с него. Единствената осезаема трудност е разликата в локалите. Това е практически гарантиран път към нечетливи регистрационни файлове. Да, има опции за това как да се третира това, но нека просто не спорим с факта, че всичко в ИТ работи на английски, и да се съгласим винаги да задаваме английски език на сървърите. О Моля те. 

Сега нека поговорим за местата, където живеят трупите и как да ги вземем. В случая с VBR има два подхода. 

Първият вариант е подходящ, ако нямате търпение да търсите файлове в общата купчина, които са конкретно свързани с вашия проблем. За целта имаме отделен съветник, на който можете да посочите конкретна работа и конкретен период, за който имате нужда от регистрационни файлове. След това той сам ще прегледа папките и ще постави всичко необходимо в един архив. Къде да го търсите и как да работите с него е описано подробно в този HF.

Съветникът обаче не събира регистрационните файлове на всички задачи и, например, ако трябва да проучите регистрационните файлове на възстановяването, прехода при срив или възстановяването при срив, вашият път е в папката %ProgramData%/Veeam/Backup. Това е основното лого хранилище на VBR и %ProgramData% е скрита папка и това е добре. Между другото, местоположението по подразбиране може да бъде преназначено с помощта на ключа на системния регистър тип REG_SZ: LogDirectory в клона HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.

На Linux машини регистрационните файлове на работния агент трябва да се търсят в /var/log/VeeamBackup/ако използвате root или sudo акаунт. Ако нямате такива привилегии, потърсете логове /tmp/VeeamBackup. 

За Veeam агент за %OS_name% регистрационните файлове трябва да се търсят в %ProgramData%/Veeam/Крайна точка (Or %ProgramData%/Veeam/Backup/Крайна точка) И /var/log/veeam съответно.

Ако използвате Application-Aware Image Processing (и най-вероятно сте), тогава ситуацията става малко по-сложна. Ще ви трябват регистрационните файлове на нашия помощник, които се съхраняват в самата виртуална машина, както и регистрационните файлове на VSS. За това как и къде да получите това щастие, е написано подробно в тази статия. И разбира се има отделна статия за събиране на необходимите системни регистрационни файлове. 

Windows събитията се събират удобно според този HF. Ако използвате Hyper-V, нещата стават по-сложни, тъй като ще ви трябват и всички негови регистрационни файлове от клона Applications and Service Logs > Microsoft > Windows. Въпреки че винаги можете да отидете по по-глупавия начин и просто да вземете всички обекти от %SystemRoot%System32winevtLogs.

Ако нещо се повреди по време на инсталация/надграждане, тогава всичко, от което се нуждаете, може да бъде намерено в папката %ProgramData%/Veeam/Setup/Temp. Въпреки че няма да скрия факта, че в събитията на OS можете да намерите по-полезна информация, отколкото в тези дневници. Останалото интересно се крие в %Temp%, но има главно инсталационни журнали за свързан софтуер, като базата, .Net библиотеки и други неща. Обърнете внимание, че Veeam е инсталиран от msi и всички негови компоненти също са инсталирани като отделни msi пакети, дори ако това не е показано в GUI. Следователно, ако инсталирането на един от компонентите е неуспешно, цялата инсталация на VBR ще бъде спряна. Следователно трябва да влезете в регистрационните файлове и да видите какво точно се е счупило и в кой момент.

И накрая, един лайфхак: ако получите грешка по време на инсталацията, не бързайте да щракнете върху OK. Първо вземаме регистрационните файлове, след което щракнете върху OK. По този начин ще получите дневник, който завършва в момента на грешката, без боклук в края.

И се случва, че трябва да влезете в регистрационните файлове на vSphere. Заниманието е много неблагодарно, но, запретнал ръкави, човек трябва да работи нещо друго. В най-простата версия се нуждаем от регистрационни файлове със събития на виртуална машина vmware.log, които се намират до неговия .vmx файл. В по-труден случай отворете Google и попитайте къде се намират регистрационните файлове за вашата хост версия, тъй като VMware обича да променя това място от издание на издание. Например, статия за 7.0, но за 5.5. За регистрационни файлове на vCenter повторете процедурата гугъл. Но като цяло ще се интересуваме от регистрационните файлове на хост събития hostd.log, събития на хост, управлявани от vCenter vpxa.log, регистрационни файлове на ядрото vmkernel.log и регистрационни файлове за удостоверяване auth.log. Е, в най-пренебрегваните случаи SSO дневникът, който се намира в папката SSO, може да бъде полезен.

Тромаво? объркани? Страшен? Но това не е дори половината от информацията, с която нашата поддръжка работи ежедневно. Така че те са наистина, наистина готини.

Компоненти на Veeam

И като заключение на тази уводна статия, нека поговорим малко за компонентите на Veeam Backup & Replication. Защото, когато търсите причината за болката, би било хубаво да разберете как работи пациентът.

И така, както вероятно всички знаят, Veeam Backup е така нареченото SQL-базирано приложение. Тоест, всички настройки, цялата информация и като цяло всичко, което е необходимо само за нормалното функциониране - всичко това е в неговата база данни. Или по-скоро в две бази данни, ако говорим за куп VBR и EM: VeeamBackup и VeeamBackupReporting, съответно. И така се случи: поставихме друго приложение - появява се друга база данни. За да не съхранявате всички яйца в една кошница.

Но за да може цялата тази икономика да работи гладко, се нуждаем от набор от услуги и приложения, които ще свържат всички компоненти заедно. Само като пример, ето как изглежда в една от моите лаборатории:

Действа като главен диригент Услуга за архивиране на Veeam. Той е този, който отговаря за обмена на информация с базите. Той също така отговаря за стартирането на всички задачи, организирането на разпределените ресурси и работата като нещо като комуникационен център за различни конзоли, агенти и всичко останало. С една дума, без него определено няма как, но това изобщо не означава, че той прави всичко сам.

Помага му в изпълнението на плана му Veeam Backup Manager. Това не е услуга, а организация, която пуска задачи и следи процеса на тяхното изпълнение. Работните ръце на услугата за архивиране, с които тя се свързва с хостове, създава моментни снимки, следи запазването и т.н.

Но обратно към списъка с услуги. Брокерска услуга на Veeam. Появи се във v9.5 (и това не е крипто копач, както някои си мислеха тогава). Събира информация за VMware хостове и поддържа нейната уместност. Но не бягайте веднага да пишете гневни коментари, че ви шпионираме и изтичаме всички данни за влизане / пароли на taschmajor. Всичко е малко по-просто. Когато стартирате архивиране, първото нещо, което трябва да направите, е да се свържете с хоста и да актуализирате всички данни за неговата структура. Това е доста бавна и тромава история. Само си спомнете колко време ви отнема да влезете през уеб интерфейса и не забравяйте, че там се брои само най-горният слой. И тогава все още трябва да отворите цялата йерархия на правилното място, между другото. С една дума ужас. Ако стартирате дузина резервни копия, тогава всяка задача трябва да изпълни тази процедура. Ако говорим за големи инфраструктури, тогава този процес може да отнеме десет минути или повече. Затова беше решено да се отдели отделна услуга за това, чрез която ще бъде възможно да получавате винаги актуална информация. При стартиране той проверява и сканира цялата добавена инфраструктура и след това се опитва да работи само на ниво постепенни промени. Така че дори да стартирате сто резервни копия едновременно, всички те ще поискат информация от нашия брокер и няма да измъчват хостовете с техните заявки. Ако се притеснявате за ресурсите, тогава според нашите изчисления 5000 виртуални машини се нуждаят само от около 100 Mb памет.

Следващото имаме Veeam конзола. Той е Veeam Remote Console, той е Veeam.Backup.Shell. Това е същият GUI, който виждаме на екранните снимки. Всичко е просто и очевидно - конзолата може да се стартира отвсякъде, стига да е Windows и да има връзка към VBR сървъра. Единственото нещо, което може да се каже е, че FLR процесът ще монтира точки локално (т.е. на машината, на която работи конзолата). Е, различни Veeam Explorers също ще работят локално, защото са част от конзолата. Но вече ме отнесе в дивата природа ...

Друга интересна услуга е Veeam Backup Catalog Data Service. Известна като Veeam Guest Catalog Service в списъка с услуги. Той се занимава с индексиране на файлови системи на гост машини и запълва папката VBRCatalog с това знание. Използва се само когато квадратчето за индексиране е активирано. И има смисъл да го активирате само ако имате Enterprise Manager. Затова съвет от дъното на сърцето ми: не включвайте индексирането просто така, ако нямате EAT. Спестете си нервите и времето за подкрепа.

Заслужава да се отбележи и от други важни услуги Услуга за инсталиране на Veeam, с помощта на които се доставят и инсталират необходимите компоненти на проксита, хранилища и други портали. Всъщност той взема необходимите .msi пакети на сървърите и ги инсталира. 

Veeam Data Mover - с помощта на помощни агенти, стартирани на проксита (и не само), той се занимава с прехвърляне на данни. Например, когато архивирате, единият агент ще прочете файлове от хранилището за данни на хоста, а вторият внимателно ще ги запише в резервното копие.

Отделно бих искал да отбележа важно нещо, на което клиентите често реагират - това е разликата във версиите на услугите и информацията в модула за програми и функции. Да, списъкът ще бъде същият, но версиите могат да бъдат напълно противоречиви. Не е много готино от визуална гледна точка, но е напълно нормално, ако всичко работи стабилно. Например за услугата Installer номерът на версията е далеч зад съседните. Ужас и кошмар? Не, защото не е напълно преинсталиран, а неговата DLL просто се актуализира. В кръпка v9.5 U4 се случи кошмар за техническа поддръжка: по време на актуализацията всички услуги получиха нови версии, с изключение на най-важната. В корекцията U4b транспортната услуга изпревари всички останали с цели две версии (съдейки по числата). И това също е нормално - в него беше открита сериозна грешка, така че получи бонус актуализация спрямо останалите. И така, за да обобщим: разликите във версиите МОГАТ да са проблем, но ако има разлика и всичко работи правилно, тогава вероятно трябва да бъде. Но никой не ви забранява да изясните това в техническата поддръжка.

Това бяха така наречените задължителни или Задължителни услуги. И има цял куп спомагателни, като 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 приключи. Да, дори не сме се доближили до самите леговища, но повярвайте ми, за да не изглежда информацията, представена в тях, като несвързан поток на съзнанието, такова въведение е абсолютно необходимо. Смятам да премина към самите логове едва в третата статия, а планът за следващата е да обясня кой генерира логовете, какво точно се показва в тях и защо точно, а не по друг начин.

Източник: www.habr.com