Компоненти и речник за нуркање Veeam Log

Ние во Veeam сакаме логови. И бидејќи повеќето од нашите решенија се модуларни, тие пишуваат многу дневници. И бидејќи опсегот на нашата активност е да обезбедиме безбедност на вашите податоци (т.е. мирен сон), тогаш дневниците не само што треба да го снимаат секое кивање, туку и да го прават тоа во некои детали. Ова е неопходно за во случај на нешто да биде јасно како се случило ова „што“, кој е виновен и што треба да се направи понатаму. Тоа е како во форензичката наука: никогаш не знаете која ситница ќе ви помогне да го пронајдете убиецот на Лора Палмер.

Затоа, решив да се замалам во серија написи, каде што последователно ќе зборувам за тоа што пишуваме на дневниците, каде ги складираме, како да не полудиме со нивната структура и што да бараме внатре во нив.

Зошто серија написи и зошто да не опишете сè одеднаш?

Едноставното наведување кој дневник е каде и што е зачуван во него е прилично катастрофален потфат. И страшно е дури и да се размислува за ажурирање на овие информации. Едноставен список на сите можни типови на дневници во Veeam Backup & Replication е табела на неколку листови со ситни букви. Да, и ќе биде релевантно само во моментот на објавување, бидејќи. кога ќе се објави следната закрпа, може да се појават нови дневници, логиката на зачуваните информации во старите ќе се промени итн. Затоа, ќе биде многу попрофитабилно да се објасни нивната структура и суштината на информациите содржани во нив. Ова ќе ви овозможи подобро да се движите низ местата отколку баналното преполнување на имиња.

Затоа, за да не брзаме во базенот со текстуални листови, ајде да направиме подготвителна работа во оваа статија. Затоа, денес нема да навлеземе во самите дневници, туку ќе одиме од далеку: ќе составиме речник и малку ќе разговараме за структурата на Veeam во однос на генерирање логови.

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

Овде, пред сè, вреди да се извиниме на шампионите на чистотата на рускиот јазик и на сведоците на речникот на Ожегов. Сите ние многу го сакаме нашиот мајчин јазик, но проклетата ИТ индустрија работи на англиски. Па, не го смисливме, но тоа се случи историски. Не сум јас виновен, тој самиот дојде (в)

Во нашиот бизнис, проблемот со англицизмите (и жаргонот) има свои специфики. Кога под невини зборови како „домаќин“ или „гостин“ целиот свет одамна разбрал многу конкретни работи, тогаш на ⅙ од земјата продолжува херојската конфузија и тетеравењето со пикање во речници. И строго задолжителниот аргумент „Но на нашата работа ...“.

Плус, постои чисто нашата терминологија, која е својствена за производите на Veeam, иако некои зборови и фрази отидоа кај луѓето. Затоа, сега ќе се договориме што значи терминот, а во иднина под зборот „гостин“ ќе мислам токму на она што е напишано во ова поглавје, а не на што сте навикнати на работа. И да, ова не е мој личен каприц, ова се добро воспоставени термини во индустријата. Борбата со нив е донекаде бесмислена. Иако секогаш сум за ладење во коментарите.

За жал, има многу термини во нашата работа и производи, па нема да се трудам да ги набројувам сите. Само најосновните и неопходни информации за резервните копии и трупците за опстанок во морето. За заинтересираните можам и јас предложи статија колегите за касети, каде што даде и листа на термини поврзани со тој дел од функционалноста.

Домаќин (домаќин): Во светот на виртуелизацијата, ова е машина со хипервизор. Физички, виртуелен, облак - не е важно. Ако нешто работи со хипервизор (ESXi, Hyper-V, KVM итн), тогаш ова „нешто“ се нарекува домаќин. Без разлика дали се работи за кластер со десет решетки или вашиот лаптоп со лабораторија за една и пол виртуелна машина - ако лансиравте хипервизор, станавте домаќин. Бидејќи хипервизорот е домаќин на виртуелни машини. Постои дури и приказна дека VMware едно време сакаше да постигне цврста поврзаност на зборот домаќин со ESXi. Но, таа не.

Во современиот свет, концептот „домаќин“ практично се спои со концептот „сервер“, што внесува одредена конфузија во комуникацијата, особено кога станува збор за инфраструктурата на Windows. Така, секоја машина што е домаќин на некоја услуга од интерес за нас може безбедно да се нарече домаќин. На пример, во дневниците на WinSock сè е означено со зборот домаќин. Класичниот „Домаќинот не е пронајден“ е пример за ова. Така, тргнуваме од контекстот, но запомнете - во светот на виртуелизацијата, домаќинот е она што е домаќин на гостите (повеќе за ова во два реда подолу).

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

Гостин (гостин): Виртуелната машина работи на домаќинот. Нема што да се објаснува овде, се е толку логично и едноставно. Сепак, многумина вредно влечат тука некои други значења.

За што? не знам.
Гостин ОС, соодветно, оперативниот систем на гостинската машина. И така натаму.

Работа за резервна копија/репликација (jobA): Чист жаргон на Вим, означувајќи некои од задачите. Работа за резервна копија == Резервна работа. Никој не сфатил како убаво да го преведе на руски, па сите велат „JobA“. Со акцент на последниот слог.

Да, тие едноставно го земаат и велат „joba“. Па дури и со букви пишуваат така, и се е во ред.
Секакви резервни задачи, задачи за резервна копија итн., благодарам, но нема потреба. Само работа, и ќе бидете разбрани. Главната работа е да се стави акцент на последниот слог.

Бекап (резервна копија, резервна копија. За true-oldfags, резервна копија е дозволена): Покрај очигледното (резервна копија од податоците што лежат некаде), значи и самата работа (три реда погоре, ако веќе сте заборавиле), како резултат на што се појавува самата резервна датотека. Веројатно, господата што зборуваат мајчин англиски јазик се премногу мрзливи да кажат дека ја извршував мојата резервна работа секој пат, па тие само велат дека сум ја извршил мојата резервна копија и сите се разбираат совршено. Ве повикувам да ја поддржите оваа прекрасна иницијатива.

Консолидација (консолидација): Термин што се појави во ESXi 5.0 Опција во менито за слики што го започнува процесот на бришење на таканаречените сирачиња снимки. Односно, снимки кои се физички достапни, но испаднале од прикажаната логичка структура. Теоретски, овој процес не треба да влијае на датотеките прикажани во менаџерот за слики, но сè може да се случи. Суштината на процесот на консолидација е дека податоците од снимката (детски диск) се запишуваат на главниот (родител) диск. Процесот на комбинирање на дискови се нарекува спојување. Ако е издадена команда за консолидација, тогаш записот од снимката може да се отстрани од базата на податоци пред да се спои и избрише сликата. И ако снимката не можеше да се избрише поради која било причина, тогаш се појавуваат истите тие сираче снимки. За работата со снимки, VMware има добар KB. И ние исто така некако за нив напиша на Хабре.

Продавница за податоци (Стора или складиште):  Многу широк концепт, но во светот на виртуелизацијата се подразбира како место каде што се складираат датотеките на виртуелната машина. Но, во секој случај, тука треба многу јасно да го разберете контекстот и, со најмал сомнеж, да разјасните што точно имал на ум вашиот соговорник. 

Прокси (прокси): Важно е веднаш да се разбере дека Veeam Proxy не е сосема ист како на што сме навикнати на Интернет. Во рамките на производите на Veeam, ова е еден вид ентитет кој се занимава со пренос на податоци од едно на друго место. Ако не навлегувате во детали, тогаш VBR е сервер за команди и контрола, а проксите се неговите работни сили. Односно, прокси е машина низ која тече сообраќај и на која се инсталирани VBR компоненти кои помагаат да се управува овој сообраќај. На пример, за пренос на податоци од еден канал на друг, или едноставно за прилепување на дисковите за себе (режим HotAdd).

Репозиториум (Репозиториум):  Технички, ова е само запис во базата на податоци VBR, означувајќи го местото каде што се чуваат резервните копии и како да се поврзете на ова место. Всушност, тоа може да биде или само CIFS топка или посебен диск, сервер или кофа во облакот. Повторно, ние сме во контекст, но разбираме дека складиштето е само место каде што се вашите резервни копии.

 Снимка (SnapshOt): Љубителите на граматиката од Оксфорд претпочитаат да кажат кој е снимка, а кој е снимка, но неписменото мнозинство има корист од поголемата маса. Ако некој не знае, ова е технологија која ви овозможува да ја вратите состојбата на дискот во одреден момент во времето. Ова се прави или со привремено пренасочување на I/O операциите подалеку од главниот диск - тогаш ќе се вика RoW (Redirect on Write) слика - или со преместување блокови што може да се препишуваат од вашиот диск на друг - ова ќе се вика CoW (Копирај на запишување ) снимка. Благодарение на широките можности за користење на овие функции, Veeam може да направи резервна магија. Строго кажано, не само тие, туку ова е работа на следните изданија.

Има хаос околу овој термин во документацијата и дневниците на ESXi, а во контекст на спомнувањето на снимките, можете да најдете самите снимки, и да го повторите дневникот, па дури и делта-диск. Документацијата на Veeam не содржи такво кинење, а снимката е снимка, а дневникот за повторување е точно датотека REDO создадена од независен неупорен диск. REDO-датотеките се бришат кога виртуелната машина е исклучена, па нивното мешање со снимки е пат до неуспех.

Синтетички (Синтетички): Синтетичките резервни копии се обратни поединечни и засекогаш напредни резервни копии. Во случај да не сте го сретнале овој термин, тој е само еден од механизмите што се користат за изградба на трансформација на резервниот синџир. Сепак, во дневниците можете да го најдете и концептот на Transform, кој се користи во рамките на создавање целосни копии од зголемувања (синтетички целосни).

Задача (Задача): Ова е процес на обработка на секоја поединечна машина во рамките на работата. Тоа е: имате резервна работа, која вклучува три машини. Тоа значи дека секој автомобил ќе се обработува како дел од посебна задача. Севкупно, ќе има четири дневници: главниот за работни места и три за задачи. Сепак, тука има важна нијанса: со текот на времето, зборот „задача“ стана непотребно двосмислен. Кога зборуваме за општи логови, мислиме дека задачата е токму VM. Но, има „задачи“ и на прокси и на складиштето. Таму може да значи виртуелен диск, виртуелна машина и целата работа. Односно, важно е да не се изгуби контекстот.

Veeam %name% услуга:  Во корист на успешните резервни копии, неколку услуги работат одеднаш, чиј список може да се најде во стандардната опрема. Нивните имиња сосема транспарентно ја отсликуваат нивната суштина, но меѓу еднаквите постои најважниот - Veeam Backup Service, без кој остатокот нема да работи.

VSS: Технички, VSS секогаш треба да значи Microsoft Volume Shadow Copy Service. Всушност, многумина го користат како синоним за обработка на слики со свесни апликации. Што, секако, е категорично погрешно, но ова е приказна од категоријата „Секој теренец може да се нарече џип, и ќе бидете разбрани“.

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

Сакам да го започнам ова поглавје со откривање на големата тајна - колку време е прикажано во дневниците?

Запомнете:

• 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/Endpoint (Или %ProgramData%/Veeam/Backup/Endpoint) И /var/log/veeam соодветно.

Ако користите Application-Aware Image Processing (и најверојатно сте), тогаш ситуацијата станува нешто покомплицирана. Ќе ви требаат дневниците на нашиот помошник, кои се зачувани во самата виртуелна машина, и логовите на VSS. За тоа како и каде да ја добиете оваа среќа, детално е напишано во овој напис. И секако дека има посебен напис да ги собере потребните системски дневници. 

Настаните на Windows погодно се собираат според овој HF. Ако користите Hyper-V, работите стануваат покомплицирани, бидејќи ќе ви требаат и сите негови дневници од гранката Апликации и сервисни дневници > Microsoft > Windows. Иако секогаш можете да одите на поглупав начин и само да ги соберете сите објекти од %SystemRoot%System32winevtLogs.

Ако нешто се скрши при инсталација/надградба, тогаш сè што ви треба може да се најде во папката %ProgramData%/Veeam/Setup/Temp. Иако нема да го кријам фактот дека во настаните на ОС можете да најдете повеќе корисни информации отколку во овие дневници. Остатокот од интересното лежи во %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. Па, во најзанемарените случаи, дневникот на ДЗС, кој се наоѓа во папката ДЗС, може да ни се најде.

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

Veeam компоненти

И како заклучок на оваа воведна статија, ајде да зборуваме малку за компонентите на Veeam Backup & Replication. Бидејќи кога ја барате причината за болката, би било убаво да разберете како функционира пациентот.

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

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

Делува како главен диригент Услуга за резервна копија на Veeam. Тој е одговорен за размена на информации со базите. Тој е исто така одговорен за започнување на сите задачи, оркестрирање на доделените ресурси и работа како еден вид комуникациски центар за различни конзоли, агенти и сè друго. Со еден збор, дефинитивно нема начин без него, но тоа воопшто не значи дека тој сè прави сам.

Му помага во исполнувањето на неговиот план Менаџер за резервни копии на Veeam. Ова не е услуга, туку субјект кој започнува работни места и го следи процесот на нивно извршување. Работните раце на услугата за резервна копија, со кои се поврзува со хостовите, создава снимки, го следи задржувањето итн.

Но, назад на листата на услуги. Услуга за брокер на Veeam. Се појави во v9.5 (и ова не е крипто-рудар, како што некои мислеа тогаш). Собира информации за хостовите на VMware и ја одржува нејзината важност. Но, немојте веднаш да трчате да пишувате лути коментари дека ве шпионираме и ги објавуваме сите најавувања/лозинки на ташмајор. Сè е малку поедноставно. Кога правите резервна копија, првото нешто што треба да направите е да се поврзете со домаќинот и да ги ажурирате сите податоци за неговата структура. Ова е прилично бавна и незгодна приказна. Само запомнете колку време ви е потребно за да се најавите преку веб-интерфејсот и запомнете дека таму се брои само горниот слој. И тогаш сè уште треба да ја отворите целата хиерархија на вистинското место, патем. Со еден збор, хорор. Ако извршите десетина резервни копии, тогаш секоја работа треба да ја направи оваа постапка. Ако зборуваме за големи инфраструктури, тогаш овој процес може да трае десет минути или повеќе. Затоа, беше одлучено да се додели посебна услуга за ова, преку која ќе може да се добиваат секогаш ажурирани информации. При стартување, ја проверува и скенира целата додадена инфраструктура, а потоа се обидува да работи само на ниво на поединечни промени. Така, дури и да извршите сто резервни копии во исто време, сите тие ќе бараат информации од нашиот брокер и нема да ги измачуваат домаќините со нивните барања. Ако сте загрижени за ресурсите, тогаш според нашите пресметки, на 5000 виртуелни машини им треба само околу 100 Mb меморија.

Следно имаме Veeam конзола. Тој е Veeam Remote Console, тој е Veeam.Backup.Shell. Ова е истиот GUI што го гледаме на сликите од екранот. Сè е едноставно и очигледно - конзолата може да се стартува од каде било, се додека е Windows и има врска со серверот VBR. Единственото нешто што може да се каже е дека процесот FLR ќе ги монтира точките локално (т.е. на машината каде што работи конзолата). Па, различни Veeam Explorers исто така ќе работат локално, бидејќи тие се дел од конзолата. Но, тоа веќе ме однесе во дивината ...

Друга интересна услуга е Услуга за податоци од каталог за резервни копии на Veeam. Познат како услуга за каталог на гости Veeam во списокот на услуги. Тој се занимава со индексирање датотечни системи на гостински машини и ја пополнува папката VBRCatalog со ова знаење. Се користи само таму каде што е овозможено полето за избор на индексирање. И има смисла да го овозможите само ако имате Enterprise Manager. Затоа, совет од се срце: не вклучувај го индексирањето само така ако немаш ЈАДЕТЕ. Заштедете ги вашите нерви и време за поддршка.

Исто така, од други важни услуги вреди да се забележи Сервис за инсталирање на Veeam, со чија помош се испорачуваат и инсталираат потребните компоненти на прокси, складишта и други порти. Всушност, ги зема потребните .msi пакети на серверите и ги инсталира. 

Veeam Data Mover - со помош на помошни агенти лансирани на прокси (и не само) се занимава со префрлање податоци. На пример, при правење резервна копија, еден агент ќе чита датотеки од продавницата за податоци на домаќинот, а вториот внимателно ќе ги запише во резервната копија.

Одделно, би сакал да забележам една важна работа на која клиентите често реагираат - ова е разликата во верзиите на услугите и информациите во приклучокот за програми и функции. Да, списокот ќе биде ист, но верзиите може да бидат целосно несогласни. Не е многу кул од визуелна гледна точка, но сосема е нормално ако сè работи стабилно. На пример, за услугата Installer, бројот на верзијата е далеку зад соседните. Хорор и кошмар? Не, затоа што не е целосно инсталиран, но неговиот DLL едноставно се ажурира. Во patch v9.5 U4, се случи кошмар за техничка поддршка: за време на ажурирањето, сите услуги добија нови верзии, освен најважната. Во лепенката U4b, транспортната услуга ги престигна сите други за дури две верзии (судејќи според бројките). И ова е исто така нормално - во него беше пронајдена сериозна грешка, па доби бонус ажурирање во однос на останатите. Така да сумираме: разликите во верзијата МОЖЕ да бидат проблем, но ако има разлика и сè работи како што треба, тогаш веројатно треба да биде. Но, никој не ви забранува да го разјасните ова во техничката поддршка.

Тоа беа таканаречените задолжителни или Задолжителни услуги. И има цел куп помошни, како што се Tape Service, Mount Service, vPowerNFS Service и така натаму.

За Hyper-V, генерално, сè е исто, само има специфика Услуга за интеграција на Hyper-V Backup Veeam и свој двигател за работа со CBT.

И на крајот, ајде да зборуваме за тоа кој работи на виртуелни машини за време на резервната копија. Да се ​​извршуваат скрипти пред и после замрзнување, да се создаде копија во сенка, да се собираат метаподатоци, да се работи со дневници на трансакции SQL итн. Veeam Гостин Помошник. И ако датотечните системи се индексирани, Indexer за гости Veeam . Ова се привремени услуги распоредени за времетраењето на резервната копија и отстранети по него.

Во случајот со Linux машините, сè е многу поедноставно поради присуството на голем број вградени библиотеки и можностите на самиот систем. На пример, индексирањето се врши преку mlocate.

Тоа е се за сега

Не се осмелувам повеќе да те повредам кратко Сметам дека воведот во моторниот простор Veeam е завршен. Да, не сме се ни приближиле до самите дувла, но верувајте, за да не изгледаат информациите презентирани во нив како некохерентен тек на свеста, таков вовед е апсолутно неопходен. Планирам да одам до самите логови само во третата статија, а планот за следната е да објаснам кој ги генерира логовите, што точно е прикажано во нив и зошто точно, а не поинаку.

Извор: www.habr.com