My ve společnosti Veeam milujeme protokoly. A protože většina našich řešení je modulárních, zapisují spoustu logů. A protože náplní naší činnosti je zajistit bezpečnost vašich dat (tedy klidný spánek), pak by měly protokoly každé kýchnutí nejen zaznamenat, ale také provést poměrně podrobně. To je nutné, aby v případě něčeho bylo jasné, jak se to „co“ stalo, kdo je vinen a co je třeba udělat dál. Je to jako ve forenzní vědě: nikdy nevíte, jaká maličkost vám pomůže najít vraha Laury Palmerové.
Proto jsem se rozhodl vrhnout se na sérii článků, kde budu postupně mluvit o tom, co do logů píšeme, kde je ukládáme, jak se nezbláznit z jejich struktury a co v nich hledat.
Proč série článků a proč nepopsat vše najednou?
Pouhé vypisování, který log kde je a co je v něm uloženo, je dost katastrofální počin. A je děsivé vůbec pomýšlet na udržování těchto informací v aktuálním stavu. Jednoduchý seznam všech možných typů protokolů ve Veeam Backup & Replication je tabulka na několika listech malým písmem. Ano, a bude to relevantní pouze v době zveřejnění, protože. při vydání dalšího patche se mohou objevit nové logy, změní se logika uložených informací ve starých atd. Proto bude mnohem výnosnější vysvětlit jejich strukturu a podstatu informací v nich obsažených. To vám umožní lépe se orientovat v místech než banální napěchování jmen.
Abychom se proto nehrnuli bezhlavě do zásoby textových listů, udělejme v tomto článku nějaké přípravné práce. Proto se dnes nedostaneme k samotným logům, ale půjdeme zpovzdálí: sestavíme glosář a trochu probereme strukturu Veeam z hlediska generování logů.
Slovník a žargon
Zde se především sluší omluvit zastáncům čistoty ruského jazyka a pamětníkům Ozhegovova slovníku. Všichni máme moc rádi svůj rodný jazyk, ale ten zatracený IT průmysl funguje v angličtině. No, my jsme na to nepřišli, ale stalo se to historicky. Není to moje chyba, přišel sám (c)
V našem podnikání má problém anglicismů (a žargonu) svá specifika. Když pod nevinnými slovy jako „hostitel“ nebo „host“ celý svět dávno rozumí velmi konkrétním věcem, pak na ⅙ země pokračuje hrdinský zmatek a potácení se s šťoucháním do slovníků. A přísně obligátní argument "Ale u nás v práci...".
Navíc je zde čistě naše terminologie, která je produktům Veeam neodmyslitelná, i když některá slova a fráze se dostala k lidem. Proto se nyní dohodneme na tom, co pojem znamená, a v budoucnu budu pod slovem „host“ označovat přesně to, co je napsáno v této kapitole, a ne to, na co jste v práci zvyklí. A ano, není to můj osobní rozmar, to jsou v branži zažité pojmy. Bojovat s nimi je poněkud zbytečné. I když jsem vždy zastáncem toho, aby se v komentářích ulevilo.
Bohužel termínů je v naší práci a produktech hodně, takže se je nebudu snažit všechny vyjmenovávat. Jen ty nejzákladnější a nejnutnější informace o zálohách a logech pro přežití v moři. Pro zájemce mohu také kolegům o páskách, kde také uvedl seznam pojmů souvisejících s danou částí funkčnosti.
Host (hostitel): Ve světě virtualizace se jedná o stroj s hypervizorem. Fyzické, virtuální, cloudové – na tom nezáleží. Pokud na něčem běží hypervizor (ESXi, Hyper-V, KVM atd.), pak se toto „něco“ nazývá hostitel. Ať už jde o cluster s deseti racky nebo váš notebook s laboratoří pro jeden a půl virtuálních strojů – pokud jste spustili hypervizor, stali jste se hostitelem. Protože hypervizor hostí virtuální stroje. Existuje dokonce příběh, že VMware chtěl svého času dosáhnout pevného spojení slova hostitel s ESXi. Ale neudělala to.
V moderním světě se pojem „hostitel“ prakticky spojil s pojmem „server“, což vnáší do komunikace určitý zmatek, zejména pokud jde o infrastrukturu Windows. Takže každý stroj, který hostí nějakou službu, která nás zajímá, může být bezpečně nazýván hostitelem. Například v protokolech WinSock je vše označeno slovem hostitel. Klasické „Hostitel nenalezen“ je toho příkladem. Vycházíme tedy z kontextu, ale pamatujte – ve světě virtualizace je hostitel to, co hostí hosty (více o tom na dvou řádcích níže).
Z místního žargonu (v tomto případě spíše zkratek) se zde připomíná, že VMware je VI, vSphere je VC a Hyper-V je HV.
Host (Host): Virtuální počítač běžící na hostiteli. Zde není co vysvětlovat, vše je tak logické a jednoduché. Mnozí sem však pilně tahají některé další významy.
Proč? Nevím.
Host OS, respektive operační systém hostujícího počítače. A tak dále.
Úloha zálohování/replikace (jobA): Čistý Wim žargon, označující některé úkoly. Úloha zálohování == Úloha zálohování. Nikdo nepřišel na to, jak to krásně přeložit do ruštiny, takže všichni říkají „JobA“. S důrazem na poslední slabiku.
Ano, prostě to vezmou a řeknou „jóba“. A i v dopisech se tak píše a vše je v pořádku.
Všechny druhy úloh zálohování, úloh zálohování atd., díky, ale není potřeba. Jen práce a bude vám rozumět. Hlavní věc je klást důraz na poslední slabiku.
Záloha (Záloha, záloha. U true-oldfags je záloha povolena): Kromě samozřejmého (někde ležící záložní kopie dat) to znamená i samotnou úlohu (o tři řádky výše, pokud jste již zapomněli), v důsledku čehož se objeví samotný záložní soubor. Pravděpodobně jsou pánové, rodilí mluvčí angličtiny, příliš líní říkat, že jsem pokaždé provedl zálohování, takže řeknou, že jsem zálohoval, a všichni si dokonale rozumí. Zvu vás k podpoře této úžasné iniciativy.
Konsolidovat (konsolidace): Termín, který se objevil v ESXi 5.0 Možnost v nabídce snímků, která spouští proces mazání takzvaných osiřelých snímků. Tedy snapshoty, které jsou fyzicky dostupné, ale vypadly ze zobrazené logické struktury. Teoreticky by tento proces neměl mít vliv na soubory zobrazené ve správci snímků, ale stát se může cokoliv. Podstatou procesu konsolidace je, že data ze snímku (podřízeného disku) jsou zapsána na hlavní (nadřazený) disk. Proces slučování disků se nazývá sloučení. Pokud byl vydán příkaz konsolidace, lze záznam snímku odstranit z databáze před sloučením a odstraněním snímku. A pokud snímek nelze z nějakého důvodu odstranit, objeví se tyto stejné osiřelé snímky. O práci se snímky má VMware . A my také nějak o nich .
Datové úložiště (Stora nebo úložiště): Velmi široký pojem, ale ve světě virtualizace je chápán jako místo, kde se ukládají soubory virtuálního stroje. Ale v každém případě zde musíte velmi jasně porozumět kontextu a při sebemenších pochybách si ujasnit, co přesně měl váš partner na mysli.
Proxy (Proxy): Je důležité okamžitě pochopit, že Veeam Proxy není úplně totéž, na co jsme zvyklí na internetu. V rámci produktů Veeam se jedná o jakousi entitu, která se zabývá přenosem dat z jednoho místa na druhé. Pokud nejdete do detailů, pak je VBR příkazový a řídicí server a proxy jsou jeho tahouni. To znamená, že proxy je stroj, přes který proudí provoz a na kterém jsou nainstalovány komponenty VBR, které pomáhají tento provoz řídit. Například k přenosu dat z jednoho kanálu do druhého nebo jednoduše k přilnutí disků k sobě (režim HotAdd).
Úložiště (úložiště): Technicky se jedná pouze o záznam v databázi VBR, udávající místo, kde jsou zálohy uloženy, a jak se k tomuto místu připojit. Ve skutečnosti to může být buď jen CIFS koule, nebo samostatný disk, server nebo bucket v cloudu. Opět jsme v kontextu, ale chápeme, že úložiště je jen místo, kde jsou vaše zálohy.
Snímek (SnapshOt): Milovníci oxfordské gramatiky raději říkají, kdo je snímek a kdo snímek, ale negramotná většina těží z větší masy. Pokud někdo neví, jedná se o technologii, která umožňuje obnovit stav disku v určitém okamžiku. To se provádí buď dočasným přesměrováním I/O operací mimo hlavní disk – pak se to bude nazývat snímek RoW (Redirect on Write) – nebo přesunem přepisovatelných bloků z vašeho disku na jiný – to se bude nazývat CoW (Copy on Write). ) snímek. Právě díky širokým možnostem využití těchto funkcí může Veeam pracovat se zálohovací magií. Přísně vzato nejen oni, ale to je záležitost příštích vydání.
V dokumentaci a protokolech ESXi je kolem tohoto termínu chaos a v souvislosti se zmínkou o snímcích můžete najít samotné snímky a předělat protokol a dokonce i delta disk. Dokumentace Veeam takovou trhlinu neobsahuje a snímek je snímek a protokol redo je přesně soubor REDO vytvořený nezávislým neperzistentním diskem. Soubory REDO se vymažou, když je virtuální počítač vypnutý, takže jejich záměna za snímky je cestou k selhání.
Syntetika (Syntetika): Syntetické zálohy jsou zpětné přírůstkové a trvalé zálohy. V případě, že jste se s tímto pojmem nesetkali, je to jen jeden z mechanismů používaných k vybudování transformace řetězce záloh. V protokolech však můžete najít také koncept Transform, který se používá v rámci vytváření úplných kopií z přírůstků (syntetické plné).
Úkol (úkol): Toto je proces zpracování každého jednotlivého stroje v rámci zakázky. To znamená: máte zálohovací úlohu, která zahrnuje tři stroje. To znamená, že každý vůz bude zpracován jako součást samostatného úkolu. Celkem budou čtyři protokoly: hlavní pro úlohy a tři pro úkoly. Je zde však důležitá nuance: postupem času se slovo „úkol“ stalo zbytečně nejednoznačným. Když mluvíme o obecných protokolech, máme na mysli, že úloha je přesně virtuální počítač. Ale existují „úkoly“ jak na proxy, tak na úložišti. Tam to může znamenat virtuální disk, virtuální stroj a celou úlohu. To znamená, že je důležité neztratit kontext.
Služba Veeam %name%.: Ve prospěch úspěšných záloh funguje více služeb najednou, jejichž seznam najdete ve standardní výbavě. Jejich názvy celkem transparentně odrážejí jejich podstatu, ale mezi rovnými je ten nejdůležitější – Veeam Backup Service, bez kterého se zbytek neobejde.
VSS: Technicky by VSS měl vždy znamenat službu Microsoft Volume Shadow Copy Service. Ve skutečnosti jej mnozí používají jako synonymum pro Application-Aware Image Processing. Což je samozřejmě kategoricky špatně, ale tohle je příběh z kategorie „Jakékoli SUV se dá nazvat džípem a bude vám rozumět“.
Fantastické klády a kde žijí
Tuto kapitolu chci začít odhalením velkého tajemství – jaký čas je zobrazen v protokolech?
Pamatovat:
- ESXi vždy zapisuje protokoly v UTC+0.
- vCenter uchovává protokoly podle času svého časového pásma.
- Veeam uchovává protokoly podle času a časového pásma serveru, na kterém je.
- A pouze události Windows ve formátu EVTX netrpí vazbou na nic. Při otevření se čas přepočítá pro vůz, na kterém byly otevřeny. Nejpohodlnější možnost, i když jsou s ní potíže. Jediným hmatatelným problémem je rozdíl v lokalitách. To je prakticky zaručená cesta k nečitelným logům. Ano, existují možnosti, jak to ošetřit, ale nehádejme se s tím, že vše v IT funguje v angličtině, a souhlasme s tím, že na serverech bude vždy nastaveno anglické národní prostředí. Ale prosím tě.
Nyní si povíme něco o místech, kde kulatiny žijí a jak je získat. V případě VBR existují dva přístupy.
První možnost je vhodná, pokud nechcete v obecné hromadě hledat soubory, které se konkrétně týkají vašeho problému. K tomu máme samostatného průvodce, do kterého můžete zadat konkrétní zakázku a konkrétní období, pro které potřebujete protokoly. Pak si složky projde sám a vše potřebné vloží do jednoho archivu. Kde ji hledat a jak s ní pracovat, je podrobně popsáno v .
Průvodce však neshromažďuje protokoly všech úloh a pokud například potřebujete prostudovat protokoly obnovení, převzetí služeb při selhání nebo obnovení služeb při selhání, vaše cesta leží ve složce %ProgramData%/Veeam/Backup. Toto je hlavní úložiště loga VBR a %ProgramData% je skrytá složka a to je v pořádku. Mimochodem, výchozí umístění lze znovu přiřadit pomocí klíče registru typu REG_SZ: LogDirectory ve větvi HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.
Na počítačích se systémem Linux by měly být protokoly pracovních agentů vyhledány v /var/log/VeeamBackup/pokud používáte účet root nebo sudo. Pokud taková oprávnění nemáte, vyhledejte přihlášení /tmp/VeeamBackup.
U agenta Veeam pro %OS_name% je třeba vyhledat protokoly %ProgramData%/Veeam/Koncový bod (nebo %ProgramData%/Veeam/Backup/Endpoint) A /var/log/veeam resp.
Pokud používáte Application-Aware Image Processing (a s největší pravděpodobností používáte), pak se situace poněkud zkomplikuje. Budete potřebovat protokoly našeho pomocníka, které jsou uloženy uvnitř samotného virtuálního stroje, a protokoly VSS. O tom, jak a kde získat toto štěstí, je podrobně napsáno . A samozřejmě existuje shromáždit potřebné systémové protokoly.
Události Windows se pohodlně shromažďují podle . Pokud používáte Hyper-V, věci se zkomplikují, protože budete potřebovat také všechny jeho protokoly z větve Applications and Service Logs > Microsoft > Windows. I když vždy můžete jít hloupější cestou a jednoduše sebrat všechny objekty z %SystemRoot%System32winevtLogs.
Pokud se při instalaci/upgradu něco pokazí, pak vše potřebné najdete ve složce %ProgramData%/Veeam/Setup/Temp. I když nebudu zastírat, že v událostech OS najdete užitečnější informace než v těchto logech. Zbytek zajímavostí leží v %Temp%, ale jsou tam hlavně instalační logy souvisejícího softwaru, jako je základ, knihovny .Net a další věci. Všimněte si, že Veeam je nainstalován z msi a všechny jeho součásti jsou také nainstalovány jako samostatné balíčky msi, i když to nebylo zobrazeno v GUI. Pokud se tedy instalace jedné z komponent nezdaří, bude celá instalace VBR zastavena. Proto musíte jít do protokolů a zjistit, co přesně se rozbilo a v jakém bodě.
A nakonec life hack: pokud se během instalace zobrazí chyba, nespěchejte a klikněte na OK. Nejprve vezmeme protokoly a poté klikneme na OK. Tímto způsobem získáte protokol, který končí v okamžiku chyby, bez odpadu na konci.
A stane se, že se potřebujete dostat do logů vSphere. Okupace je velmi nevděčná, ale když si člověk vyhrne rukávy, musí dělat něco jiného. V nejjednodušší verzi potřebujeme protokoly s událostmi virtuálního stroje vmware.log, které jsou umístěny vedle jeho souboru .vmx. Ve složitějším případě otevřete Google a zeptejte se, kde se nacházejí protokoly vaší hostitelské verze, protože VMware rád toto místo mění z vydání na vydání. Například, , ale pro . Pro protokoly vCenter opakujte postup . Obecně nás ale budou zajímat protokoly událostí hostitele hostd.log, události hostitele spravované vCenter vpxa.log, protokoly jádra vmkernel.log a protokoly ověřování auth.log. No a v nejvíce opomíjených případech se může hodit protokol SSO, který leží ve složce SSO.
Těžkopádný? Zmatený? děsivé? To ale není ani polovina informací, se kterými naše podpora denně pracuje. Takže jsou opravdu skvělé.
Komponenty Veeam
A na závěr tohoto úvodního článku si povíme něco málo o komponentách Veeam Backup & Replication. Neboť když hledáte příčinu bolesti, bylo by hezké pochopit, jak pacient funguje.
Jak tedy asi každý ví, Veeam Backup je takzvaná aplikace založená na SQL. Tedy veškerá nastavení, veškeré informace a obecně vše, co je pouze nutné pro běžné fungování – to vše má v její databázi. Nebo spíše ve dvou databázích, pokud mluvíme o hromadě VBR a EM: VeeamBackup a VeeamBackupReporting. A tak se stalo: vložili jsme další aplikaci - objeví se další databáze. Aby se všechna vejce neskladovala v jednom košíku.
Ale aby celá tato ekonomika fungovala hladce, potřebujeme sadu služeb a aplikací, které spojí všechny komponenty dohromady. Jen jako příklad, takto to vypadá v jedné z mých laboratoří:
Působí jako šéfdirigent Zálohovací služba Veeam. Je to on, kdo je zodpovědný za výměnu informací se základnami. Je také zodpovědný za spouštění všech úkolů, organizování přidělených zdrojů a práci jako jakési komunikační centrum pro různé konzole, agenty a vše ostatní. Jedním slovem, bez něj to rozhodně nejde, ale to vůbec neznamená, že si všechno dělá sám.
Pomáhá mu při plnění jeho plánu Veeam Backup Manager. Nejedná se o službu, ale o subjekt, který spouští úlohy a sleduje proces jejich provádění. Pracovní ruce zálohovací služby, pomocí kterých se připojuje k hostitelům, vytváří snímky, monitoruje uchovávání a tak dále.
Ale zpět k výčtu služeb. Služba Veeam Broker. Objevilo se ve verzi 9.5 (a toto není kryptotěžař, jak si tehdy někteří mysleli). Shromažďuje informace o hostitelích VMware a udržuje jejich relevanci. Ale neběhejte hned psát rozzlobené komentáře, že vás špehujeme a prozradíme všechna přihlašovací jména / hesla vedoucímu. Vše je poněkud jednodušší. Když spustíte zálohu, první věc, kterou musíte udělat, je připojit se k hostiteli a aktualizovat všechna data o jeho struktuře. Jedná se o poměrně pomalý a těžkopádný příběh. Jen si pamatujte, jak dlouho vám trvá přihlášení přes webové rozhraní, a pamatujte, že se tam počítá pouze horní vrstva. A pak je ještě potřeba otevřít celou hierarchii na správné místo, mimochodem. Jedním slovem hrůza. Pokud spustíte tucet záloh, pak každá úloha musí provést tento postup. Pokud mluvíme o velkých infrastrukturách, pak tento proces může trvat deset minut i více. Proto bylo rozhodnuto vyčlenit k tomu samostatnou službu, jejímž prostřednictvím bude možné přijímat vždy aktuální informace. Při spuštění zkontroluje a prohledá veškerou přidanou infrastrukturu a poté se snaží pracovat pouze na úrovni postupných změn. Takže i když spustíte sto záloh najednou, všechny budou vyžadovat informace od našeho brokera a nebudou hostitele trápit svými požadavky. Pokud se obáváte o zdroje, pak podle našich výpočtů potřebuje 5000 virtuálních strojů jen asi 100 Mb paměti.
Dále máme Konzole Veeam. Je jím Veeam Remote Console, je Veeam.Backup.Shell. Toto je stejné GUI, které vidíme na snímcích obrazovky. Vše je jednoduché a zřejmé - konzoli lze spustit odkudkoli, pokud je to Windows a existuje připojení k serveru VBR. Jediné, co lze říci, je, že proces FLR připojí body lokálně (tj. na stroji, kde běží konzole). Různé Veeam Explorers poběží také lokálně, protože jsou součástí konzole. Ale už mě to přeneslo do divočiny...
Další zajímavou službou je Veeam Backup Catalog Data Service. V seznamu služeb známá jako služba Veeam Guest Catalog. Zabývá se indexováním souborových systémů na hostujících počítačích a těmito znalostmi plní složku VBRCatalog. Používá se pouze tam, kde je povoleno zaškrtávací políčko indexování. A má smysl ji povolit pouze v případě, že máte Enterprise Manager. Proto rada od srdce: nezapínejte indexování jen tak, pokud nemáte EAT. Ušetřete si nervy a podpořte čas.
Také z dalších důležitých služeb stojí za zmínku Instalační služba Veeam, s jehož pomocí se potřebné komponenty dodávají a instalují na proxy, repozitáře a další brány. Ve skutečnosti vezme potřebné balíčky .msi na servery a nainstaluje je.
Veeam Data Mover - pomocí pomocných agentů spuštěných na proxy (nejen) se zabývá přesouváním dat. Například při zálohování bude jeden agent číst soubory z hostitelského datového úložiště a druhý je pečlivě zapisuje do zálohy.
Samostatně bych rád poznamenal důležitou věc, na kterou klienti často reagují – to je rozdíl ve verzích služeb a informací v modulu snap-in Programy a funkce. Ano, seznam bude stejný, ale verze mohou být zcela nesouhlasné. Z vizuálního hlediska to není moc cool, ale je to úplně normální, pokud vše funguje stabilně. Například u služby Installer je číslo verze daleko za sousedními. Hrůza a noční můra? Ne, protože není zcela přeinstalován, ale jeho DLL je jednoduše aktualizována. V patchi v9.5 U4 se stala noční můra technické podpory: během aktualizace dostaly všechny služby nové verze, kromě té nejdůležitější. V patchi U4b dopravní služba předběhla všechny ostatní až o dvě verze (soudě podle čísel). A to je také normální - byla v něm nalezena závažná chyba, takže oproti zbytku obdržel bonusovou aktualizaci. Takže abych to shrnul: rozdíly ve verzích MOHOU být problém, ale pokud existuje rozdíl a vše funguje správně, pravděpodobně by měl být. Nikdo vám ale nezakazuje si to vyjasnit v technické podpoře.
Jednalo se o tzv. povinné nebo Závazné služby. A existuje celá řada pomocných, jako je pásková služba, služba připojení, služba vPowerNFS a tak dále.
Pro Hyper-V je obecně vše stejné, pouze existuje specifikum Integrační služba Veeam Backup Hyper-V a svůj vlastní ovladač pro práci s CBT.
A na závěr si řekněme, kdo na virtuálních strojích při zálohování pracuje. Spouštění skriptů před a po zmrazení, vytváření stínové kopie, shromažďování metadat, práce s protokoly transakcí SQL atd. Pomocník hosta Veeam. A pokud jsou souborové systémy indexovány, Veeam Guest Indexer . Jedná se o dočasné služby nasazené po dobu zálohování a po ní odstraněné.
V případě linuxových strojů je vše mnohem jednodušší díky přítomnosti velkého množství vestavěných knihoven a možnostem samotného systému. Například indexování se provádí prostřednictvím mlocate.
To je prozatím vše
Už si netroufám ti ublížit krátký Úvod do motorového prostoru Veeam považuji za ukončený. Ano, k samotným doupatům jsme se ani nepřiblížili, ale věřte, že aby informace v nich prezentované nepůsobily jako nesouvislý proud vědomí, je takový úvod naprosto nezbytný. Na samotné logy plánuji jít až ve třetím článku a plánem dalšího je vysvětlit, kdo logy generuje, co přesně se v nich zobrazuje a proč přesně a ne jinak.
Zdroj: www.habr.com