Veeam ima rad loge. Ker so rešitve modulne, pišemo precej veliko logov. Ker je naše področje dejavnosti zaščita vaših podatkov (tj. miren spanec), morajo logi ne samo beležiti vsak izdih, temveč to početi tudi podrobno. To je potrebno, da bo jasno, kako se je 'to' zgodilo, kdo je kriv in kaj storiti naprej. Tukaj je kot v kriminalistiki: nikoli ne veš, kateri detajl ti lahko pomaga najti morilca Laura Palmer.
Zato sem se odločil, da se lotim serije člankov, kjer bom postopoma povedal, kaj zapisujemo v loge, kje jih shranjujemo, kako ne izgubiti razum pri njihovi strukturi in kaj iskati v njih.
Zakaj serija člankov in zakaj ne opisati vsega naenkrat?
Samo našteti, kateri log je kje in kaj vsebuje, je precej brezizhodna ideja. Razmišljanje o tem, kako to informacijo ohranjati posodobljeno, je še bolj zastrašujoče. Preprosto naštevanje vseh mogočih vrst logov v Veeam Backup & Replication - to je tabela na več listih s tankim tiskom. In to bo aktualno le ob objavi, saj lahko z naslednjim popravkom pridejo novi logi, spremeni se logika shranjenih informacij v starih itd. Zato je veliko bolj smiselno razložiti njihovo strukturo in bistvo vsebine. To bo omogočilo boljše usmerjanje v praksi kot preprosto pomnjenje imen.
Zato, da ne bi skočili v globoko v jezero besedil, naredimo v tem članku neko pripravljalno delo. Danes se ne bomo potopili v same loge, temveč se bomo lotili od daleč: sestavili bomo glosar in nekoliko razpravljali o strukturi Veeam z vidika generiranja logov.
Glosar in žargonizmi
Tu se moram najprej opravičiti pred zagovorniki čistosti ruščine in pričevalci Ožegovega slovarja. Vsi zelo ljubimo svoj materni jezik, toda prekleta IT industrija deluje v angleščini. No, to nismo mi izmislili, ampak se je zgodilo zgodovinsko. Nisem kriva, prišel je sam (c)
V našem oboru je problém anglicismů (a žargonu) docela specifický. Když pod nevinnými slovy jako „host“ nebo „doma“ zbytek světa už dávno rozumí velmi konkrétním věcem, pak na ⅙ části pevniny pokračuje heroický rozpor a nepořádek s hledáním ve slovnících. A striktně povinný argument „A my to máme v práci…“.
Plus máme čistě naši terminologii, která je charakteristická právě pro produkty Veeam, i když některá slova a obraty se dostala mezi lidi. Takže se teď dohodneme, co který termín znamená, a v budoucnu pod slovem „host“ budu mít na mysli přesně to, co je napsáno v této kapitole, a ne to, co jste zvyklí používat u sebe v práci. A ano, to není osobní rozmar, to jsou ustálené termíny v průmyslu. Bojovat s nimi je trochu beznadějné. I když na procházku do komentářů jsem vždy pro.
Bohužel, termínů v naší práci a produktech je nesmírně mnoho, takže se nebudu pokoušet vyjmenovat všechny. Pouze ty nejzákladnější a nezbytné pro přežití v moři informací o zálohách a logách. Pro zájemce mohu také kolegy o pásech, kde také přinesl seznam termínů souvisejících s tou částí funkčnosti.
Host (Hostitel): Ve světě virtualizace je to stroj s hypervizorem. Fyzický, virtuální, cloudový — to je jedno. Pokud na něčem běží hypervizor (ESXi, Hyper-V, KVM atd.), pak se tomu „něčemu“ říká hostitel. Ať už je to klastr na deset stojanů nebo váš notebook s laboratoří na jedno a půl virtuálního stroje — pokud jste spustili hypervizor, stali jste se hostitelem. Protože hypervizor hostí virtuální stroje. Existuje dokonce příběh, že VMware kdysi chtěla dosáhnout pevné asociace slova hostitel právě s ESXi. Ale nedokázali to.
V moderním světě se pojem „hostitel“ prakticky spojil s pojmem „server“, což vnáší určitý zmatek do komunikace, zejména pokud jde o Windows infrastrukturu. Takže jakýkoli stroj, na kterém se nachází nějaká pro nás zajímavá služba, může být klidně nazván hostitelem. Například v logách WinSock je slovo host označeno pro všechno možné. Klasické „Host not found“ je toho příkladem. Takže vycházíme z kontextu, ale pamatujeme — ve světě virtualizace hostitel je to, co hostí hosty (o tom níže dvě řádky).
Iz lokalnih žargonov (verjetno bolj akronimov v tem primeru) se spominjam, da je VMware VI, vSphere je VC, Hyper-V pa HV.
Gost (Guest): Virtualni stroj, ki deluje na gostitelju. Tu ni kaj razlagati, vse je tako logično in preprosto. Kljub temu pa mnogi skušajo v to vnesti kakšne druge pomene.
Zakaj? Ne vem.
Gostiteljski operacijski sistem (Guest OS), ustrezno operacijski sistem gostujočega stroja. In tako naprej.
Zadatek varnostnega kopiranja / replikacije (Backup/Replication Job): Čisti VMwarejev žargon, ki označuje eno od nalog. Backup job == Varnostna kopija naloga. Kako to lepo prevesti v slovenščino — nihče ni prišel na to, zato vsi pravijo 'naloga'. S poudarkom na zadnjem zlogu.
Da, tako enostavno vzamejo in rečejo 'naloga'. Tudi v e-pošti tako pišejo in vse je v redu.
Različne varnostne naloge, naloge varnostne kopije itd., hvala, ampak ne potrebujem. Samo naloga in vas bodo razumeli. Glavno je, da poudarite zadnji zlog.
Varnostna kopija (Backup, bkap. Za prave starejše oboževalce je dovoljen tudi bakup): Poleg očitnega (ležeča tam rezervna kopija podatkov), pomeni tudi samo nalogo (tri vrstice zgoraj, če ste že pozabili), zaradi katere nastane tista varnostna kopija. Verjetno so angleški nosilci jezika preveč leni, da bi vsakokrat rekli 'Izvedel sem svojo nalogo za varnostno kopiranje', zato preprosto rečejo 'Izvedel sem varnostno kopijo' in si vsi odlično razumemo. Predlagam, da podpiramo to čudovito pobudo.
Konsolidacija (Consolidate): Termin, ki se je pojavil v ESXi 5.0. Možnost v meniju za delo s posnetki, ki zažene postopek odstranjevanja tako imenovanih orphaned posnetkov. To so posnetki, ki fizično obstajajo, a so izpadli iz prikazane logične strukture. Teoretično ta postopek ne bi smel vplivati na datoteke, prikazane v upravitelju posnetkov, a se zgodi tudi to. Namen postopka konsolidacije je, da se podatki iz posnetka (child disk) zapišejo na glavni (parent) disk. Postopek združevanja diskov imenujemo mërž (merge). Če je bila dana ukazna za konsolidacijo, se lahko zapis o posnetku odstrani iz baze prej, preden je posnetek združen in odstranjen. In če posnetka ni bilo mogoče odstraniti iz kateregakoli razloga, se pojavijo ti orphaned posnetki. O delu s posnetki ima VMware . In tudi mi smo o tem .
Shranjevanje (Datastore): To je zelo široka definicija, vendar v svetu virtualizacije pod njo razumemo prostor, kjer so shranjene datoteke virtualnih strojev. V vsakem primeru je treba zelo jasno razumeti kontekst in ob najmanjšem dvomu razjasniti, kaj natančno ima vaš sogovornik v mislih.
Proxy (Proxy): Pomembno je takoj razumeti, da Veeam Proxy ni povsem enako temu, kar smo navajeni na območju interneta. V okviru izdelkov Veeam je to neka entiteta, ki se ukvarja s prenašanjem podatkov iz enega mesta na drugo. Brez podrobnosti, VBR je komandni strežnik, proxy pa so njegove delovne konjice. Torej, proxy je stroj, skozi katerega teče promet in na katerem so nameščene komponente VBR, ki pomagajo upravljati ta promet. Na primer, prenašati podatke iz enega kanala v drugega ali preprosto priključiti diske (HotAdd način).
Repository (Repozitorij): Tehnično je to preprosto zapis v bazi VBR, ki kaže na mesto, kjer so shranjeni varnostni kopiji, in kako se povezati s tem mestom. Dejansko je to lahko preprosto CIFS delitev ali ločen disk, strežnik ali vedro v oblaku. Spet, imamo kontekst, vendar razumemo, da je repozitorij preprosto mesto, kjer ležijo vaše varnostne kopije.
Snapshot (Snapshot): Oboževalci oksfordske gramatike raje govorijo kdo snapshOt, kdo snaPshot, vendar neizobražen večinski del prevladuje zaradi večje množice. Če kdo ne ve - to je tehnologija, ki omogoča obnovitev stanja diska v določenem trenutku. To se doseže bodisi z začasnim preusmerjanjem I/O operacij stran od glavnega diska - takrat se to imenuje RoW (Redirect on Write) snapshot - ali z izhajanjem ponovno zapisovanih blokov z vašega diska na drugega - to se imenuje CoW (Copy on Write) snapshot. Zahvaljujoč širokim možnostim uporabe teh funkcij Veeam lahko ustvarja svojo varnostno magijo. Strogo gledano, ne le on, ampak to je naloga bližnjih različic.
V dokumentaciji in dnevnikih ESXi okoli tega izraza vlada zmeda, v kontekstu omembe posnetkov pa lahko srečamo tako same posnetke, kot redo log in celo delta disk. V dokumentaciji Veeam take zmešnjave ni, in posnetek je posnetek, redo log pa je prav REDO datoteka, ustvarjena z neodvisnim non-persistent diskom. REDO datoteke se izbrišejo ob ugasnjenju virtualnega stroja, zato je zmešanje z posnetki pot do propada.
Synthetic (Sinteza): Sintetične varnostne kopije se nanašajo na reverse incremental in forever forward varnostne kopije. Če se s tem izrazom še niste srečali, je to preprosto eden od mehanizmov, ki se uporablja za oblikovanje prenove varnostne kopije. V dnevnikih se lahko srečate tudi z izrazom Transform, ki se uporablja pri ustvarjanju celotnih kopij iz inkrementov (synthetic full).
Task (Naloga): To je proces obdelave vsake posamezne naprave v okviru dela. To pomeni: imate varnostno delo, v katerem so vključene tri naprave. Torej, vsaka naprava se bo obdelala v okviru ločene naloge. Na koncu bo štiri dnevnike: en glavni za delo in tri za naloge. Vendar je tukaj pomembna opomba: skozi čas je beseda „naloga“ postala preveč večznačna. Ko govorimo o skupnih dnevnikih, imamo v mislih, da naloga predstavlja VM. Vendar pa imajo svoje „naloge“ tudi na proxyju in repozitoriju. Tam lahko to pomeni tako virtualni disk, kot virtualno napravo in celotno delo. Pomembno je, da ne izgubimo kontekst.
Veeam %name% Service (Storitev): Za uspešne varnostne kopije skrbi več storitev, katere seznam lahko najdete v standardnem orodju. Njihova imena dovolj jasno odražajo njihovo bistvo, vendar med enakimi izstopa najpomembnejša — Veeam Backup Service, brez katere ostale ne bodo delovale.
VSS: Tehnično VSS vedno mora označevati Microsoft Volume Shadow Copy Service. Dejansko ga mnogi uporabljajo kot sinonim za Application-Aware Image Processing. Kar je seveda kategorično napačno, toda to je zgodba iz razreda „Vsak terenski avtomobil lahko imenuješ džip in te bodo razumeli“.
Fantastični dnevniki in kraji, kjer prebivajo
Hočem začeti to poglavje s razkritjem velike skrivnosti — kateri čas se prikazuje v dnevnikih?
Zapomnite si:
- ESXi vedno piše dnevnike v UTC+0.
- vCenter vodi dnevnike po času svoje časovne cone.
- Veeam vodi dnevnike po času in časovni coni strežnika, na katerem je nameščen.
- In addition, Windows events in the EVTX format are not tied to anything. When opened, the time is recalculated for the machine on which they are opened. This is the most convenient option, although there can be challenges with it as well. The only significant difficulty is the difference in locales. This is practically a guaranteed path to unreadable logs. Yes, there are options to address this, but let's just agree that everything in IT works in English and always set English locale on servers. Please.
Now let's talk about where logs reside and how to obtain them. In the case of VBR, there are two approaches.
The first option is suitable if you are not eager to search through the pile for files related to your specific issue. For this, we have a separate wizard, where you can specify a particular job and a specific period for which you need logs. Then, it will scan the folders and assemble everything necessary into one archive. Detailed instructions on where to find it and how to work with it are written in .
However, the wizard collects logs not for all tasks, and for example, if you need to examine logs for a restaurant, failover, or fallback, your path lies in the folder %ProgramData%/Veeam/Backup. This is the main log storage for VBR, and %ProgramData% is a hidden folder, which is normal. By the way, the default location can be reassigned using a registry key of type REG_SZ: LogDirectory in the HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication branch.
On Linux machines, the logs of working agents should be looked for in /var/log/VeeamBackup/, if you are using a root or sudo account. If you don't have such privileges, then look for the logs in /tmp/VeeamBackup.
For Veeam agent for %OS_name%, logs should be found in %ProgramData%/Veeam/Endpoint (ali %ProgramData%/Veeam/Backup/Endpoint) i /var/log/veeam ustrezno.
If you are using Application-Aware Image Processing (which you likely are), the situation becomes slightly more complicated. You will need logs from our helper, which are stored inside the virtual machine, and VSS logs. Detailed information on how and where to obtain this content is written in . And of course, there is on collecting the necessary system logs.
Windows events can be conveniently collected according to . If you are using Hyper-V, it gets complicated, as you will also need all its logs from the Applications and Service Logs > Microsoft > Windows branch. However, you can always take a more brute-force approach and simply grab all objects from %SystemRoot%\System32\winevt\Logs.
Če se med namestitvijo/posodobitvijo kaj pokvari, lahko vse potrebno najdete v mapi %ProgramData%/Veeam/Setup/Temp. Čeprav ne bom skrival, da lahko v dogodkovnih zapisih operacijskega sistema najdete bolj koristne informacije kot v teh logih. Preostali zanimivi podatki se nahajajo v %Temp%, vendar so tam predvsem logi namestitve spremljajoče programske opreme, kot so podatkovne baze, knjižnice .Net in podobno. Upoštevajte, da se Veeam namesti iz msi, vsi njegovi sestavni deli pa se prav tako nameščajo kot ločeni msi paketi, tudi če to ni bilo prikazano v GUI. Zato, če je namestitev enega od komponenta neuspešna, se bo celotna namestitev VBR ustavila. Zato morate preveriti loge in videti, kaj točno je šlo narobe in kdaj.
In še hiter nasvet na koncu: ko prejmete napako pri namestitvi, ne hitite pritisniti OK. Najprej zgrabite loge, nato pritisnite OK. Tako boste dobili log, ki se konča ob trenutku napake, brez odvečnega dela na koncu.
In včasih je potrebno poiskati loge v vSphere. Ni ravno hvaležno opravilo, a z zavihkom rokavov je treba narediti tudi to. V najbolj osnovni različici bomo potrebovali loge z dogodki virtualnega stroja vmware.log, ki ležijo ob njegovem .vmx datoteki. V bolj zapletenem primeru odprete Google in vprašate, kje ležijo logi za vašo različico gostitelja, ker VMware rad spremeni to lokacijo z vsako različico. Tukaj je, na primer, , tukaj pa za . Za loge vCenter ponovimo postopek . Na splošno nas zanimajo logi dogodkov gostitelja hostd.log, dogodki gostiteljev pod nadzorom vCenter vpxa.log, logi jedra vmkernel.log in logi za avtentikacijo auth.log. No, v najbolj zapletenih primerih lahko pride prav tudi log SSO, ki leži v mapi SSO.
Zamudno? Zmedeno? Strašno? A to niti ni polovica informacij, s katerimi se naš podpora vsakodnevno ukvarja. Tako da so resnično zelo dobri.
Komponente Veeam
In kot zaključek tega uvodnega članka malo poklepetajmo o komponentah Veeam Backup & Replication. Ker ko iščete vzrok težav, je dobro razumeti, kako je bolnik zgrajen.
Torej, kot zagotovo ve vsak, Veeam Backup je tako imenovana aplikacija, ki temelji na SQL. To pomeni, da so vse nastavitve, vse informacije in pravzaprav vse, kar je potrebno za normalno delovanje — vse to se nahaja v njegovi bazi. Oziroma v dveh bazah, če govorimo o povezavi VBR in EM: VeeamBackup in VeeamBackupReporting, ustrezno. Tako je tudi prišlo: namestimo še eno aplikacijo — pojavi se še ena baza. Da ne bi shranjevali vseh jajc v en koš.
Toda za to, da vse to deluje usklajeno, potrebujemo niz storitev in aplikacij, ki bodo povezale vse komponente v eno celoto. Izključno za primer, tako to izgleda v eni izmed mojih laboratorijev:
V vlogi glavnega dirigenta nastopa Veeam Backup Service. Ta je odgovoren za izmenjavo informacij z bazami. Prav tako je odgovoren za zagon vseh opravil, se ukvarja z orkestracijo dodeljenih virov in deluje kot nekakšen komunikacijski center za različne konzole, agente in vse ostalo. Skratka, brez njega ne gre, a to še ne pomeni, da vse počne sam.
Pri načrtovanem mu pomaga Veeam Backup Manager. To ni storitev, ampak entiteta, ki se ukvarja z zagonom opravil in spremlja potek njihovega izvajanja. Delovne roke storitve za varnostno kopiranje, s katerimi se povezuje z gosti, ustvarja posnetke, spremlja zadrževanje in tako naprej.
Vrnimo se k seznamu storitev. Veeam Broker Service. Pojavila se u v9.5 (i to nije kripto rudara, kako su tada neki pomislili). Bavi se prikupljanjem informacija o VMware domaćinima i održavanjem ažurnosti tih informacija. No, nemojte odmah početi pisati ogorčene komentare da vas špijuniramo i otkrivamo sve logine/lozinke tašmajoru. Sve je malo jednostavnije. Kada pokrećete backup, prvo se treba povezati s domaćinom i ažurirati sve podatke o njegovoj strukturi. To je prilično spora i neuredna stvar. Samo se setite koliko traje operacija logina preko web sučelja, i imajte na umu da se tu računa samo gornji sloj. A zatim treba još otkriti cijelu hijerarhiju do potrebnog mesta, mora se reći. Ukratko, strašno. Ako pokrećete desetak backupa, svakoj će se jobi morati obaviti ova procedura. Kada se radi o velikim infrastrukturnim sistemima, ovaj proces može potrajati deset minuta ili više. Zbog toga je donesena odluka da se odredi poseban servis za to, kroz koji će se uvek moći dobiti ažurirane informacije. On prilikom pokretanja proverava i skenira celu dodatu infrastrukturu, a onda se trudi raditi samo na nivou inkrementalnih promena. Tako da čak i ako pokrećete istovremeno sto backupa, svi će zatražiti informacije od našeg brokera, a ne će mučiti domaćine svojim zahtevima. Ako se brinete za resurse, prema našim proračunima na 5000 virtuelnih mašina potrebno je svega oko 100 Mb memorije.
Dalje imamo Veeam Console. Ona je poznata kao Veeam Remote Console, ili Veeam.Backup.Shell. To je taj GUI koji vidimo na snimcima ekrana. Sve je jednostavno i očigledno — konzolu možete pokretati s bilo kog mesta, sve dok je to Windows i postoji veza sa VBR serverom. Jedina stvar koju možemo reći: FLR proces će montirati tačke lokalno (tj. na mašini na kojoj je konzola pokrenuta). I raznovrsni Veeam Explorers takođe će se pokretati lokalno, jer su oni deo konzole. No, o tome sam se već raspisao…
Sledeća zanimljiva usluga — Veeam Backup Catalog Data Service. Na seznamu storitev je znan kot Veeam Guest Catalog Service. Ukvarja se z indeksiranjem datotečnih sistemov na gostiteljskih napravah in polni to znanje v mapo VBRCatalog. Uporablja se le tam, kjer je omogočeno indeksiranje. Aktivirati ga ima smisel le, če imate Enterprise Manager. Zato iskren nasvet: ne omogočajte indeksiranja kar tako, če nimate EM. Varčujte s svojimi živci in časom podpore.
Poleg drugih pomembnih storitev velja izpostaviti Veeam Installer Service, s pomočjo katerega poteka dostava in namestitev potrebnih komponent na proxy, repozitorije in druge vstopne točke. Dejansko dostavi potrebne .msi pakete na strežnike in izvede njihovo namestitev.
Veeam Data Mover — s pomočjo pomožnih agentov, ki delujejo na proxyjih (in ne le tam), upravlja prenos podatkov. Na primer, pri varnostnem kopiranju bo en agent prebral datoteke z gostiteljskih datastorov, drugi pa jih skrbno zapisoval v varnostno kopijo.
Posebej bi želel izpostaviti pomembno stvar, na katero pogosto reagirajo stranke — to je razlika v različicah storitev in informacijah v orodju Programs and Features. Da, seznam bo enak, vendar so v različicah lahko velike razlike. To ni ravno optimalno z vizualnega vidika, vendar je povsem normalno, če vse deluje stabilno. Na primer, verzija Installer storitve močno zaostaja za sosednjimi. Groza in nočna mora? Ne, saj se ne namesti v celoti, temveč se preprosto posodobi njegova DLL datoteka. V popravku v9.5 U4 se je zgodila strašna nočna mora tehnične podpore: ob posodobitvi so vse storitve dobile nove različice, razen najpomembnejšega. V popravku U4b je transportna storitev prehitela vse druge kar za dve različici (če sodiš po številkah). In to je tudi normalno — v njej je bila najdena resna napaka, zato je dobila bonus posodobitev v primerjavi z ostalimi. Zato, da povzamem: razlika v različicah LAHKO predstavlja težavo, vendar če razlika obstaja in vse deluje pravilno, je verjetno tako tudi treba. Ampak nikdo vam ne preprečuje, da bi to preverili pri tehnični podpori.
To so bile tako imenovane obvezne storitve ali Mandatory services. Obstaja pa še cela vrsta pomožnih, kot so Tape Service, Mount Service, vPowerNFS Service in tako naprej.
Za Hyper-V je v splošnem enako, le da obstaja specifična Veeam Backup Hyper-V Integration Service in svoj gonilnik za delo s CBT.
Na koncu bomo govorili o tem, kdo dela na virtualkah med varnostnim kopiranjem. Za zagon pre- in post-freeze skriptov, za ustvarjanje šedovskih kopij, zbiranje metapodatkov, delo s SQL transakcijskimi logi in drugo se uporablja Veeam Guest Helper. In če pride do indeksacije datotečnih sistemov, Veeam Guest Indexer . To so začasne storitve, ki se razvrstijo med varnostnim kopiranjem in se odstranijo po njem.
Pri Linux strojih je vse veliko lažje zaradi številnih vgrajenih knjižnic in možnosti samega sistema. Na primer, indeksiranje se izvede preko mlocate.
To je zaenkrat vse.
Ne morem vas več mučiti in kratko uvod v zakulisje Veeama štejem za končan. Da, niti približno nismo prišli do samih logov, vendar verjemite, da je tak uvod nujno potreben, da informacije, predstavljene v njih, ne izgledajo kot nepovezan tok zavesti. Takoj do samih logov nameravam preiti šele v tretjem članku, načrt za naslednjega pa je razložiti, kdo generira loge, kaj točno je v njih prikazano in zakaj ravno tako, in ne kako drugače.
Izvor: habr.com
