Pokračujeme v našem ponoření do fascinujícího světa troubleshootingování podle logů. V jsme se dohodli na významu základních termínů a jedním okem jsme nahlédli do obecné struktury Veeam jako jednotné aplikace. Úkolem na toto je porozumět, jak se tvoří log soubory, jaké informace v nich jsou zobrazeny a proč vypadají tak, jak vypadají.
Co si vlastně myslíte, co jsou tyto "logy"? Většina lidí se domnívá, že logy jakékoli aplikace by měly plnit roli jakési všemocné entity, která většinu času přežívá někde na okraji, ale v pravý moment se objevuje zčista jasna v zářivých brněních a všechno zachraňuje. To znamená, že by měly obsahovat vše, počínaje těmi nejmenšími chybami v každé komponentě, až po jednotlivé transakce databáze. A aby po chybě bylo ihned napsáno, jak to opravit. A to všechno by se mělo vejít do pár megabajtů, ne víc. Vždyť je to jen text! Textové soubory přece nemohou zabírat desítky gigabajtů, to jsem někde slyšel!
Takže, logy
Ve skutečném světě jsou logy jen archivy diagnostických informací. A co tam uchovávat, odkud brát informace pro ukládání a jak podrobné by měly být, rozhodují sami vývojáři. Někdo jde cestou minimalismu a uchovává záznamy o zapnutí/vypnutí, zatímco jiný pečlivě sbírá vše, co se mu dostane do rukou. Existuje také střední cesta s možností volby takzvané úrovně logování, kdy sám určuješ, jak podrobné informace chceš uchovávat a kolik máš volného místa na discích =) V VBR je těchto úrovní celých šest, mimochodem. A věřte, že nechcete vidět, co se děje při maximálně podrobném logování se volným místem na vašem disku.
Dobře. Přibližně jsme pochopili, co chceme uchovávat, ale vyvstává zákonná otázka: odkud brát tyto informace? Část událostí pro logování samozřejmě generujeme sami našimi interními procesy. Ale co dělat, když dochází k interakci s vnějším prostředím? Abychom se vyhnuli chaosu z různých zástěr a komplikovaných řešení, Veeam má tendenci nevynalézat již vynalezené věci. Kdykoliv je k dispozici již hotové API, vestavěná funkce systému, knihovna atd., dáme přednost hotovým variantám, než abychom začali vymýšlet svoje složité řešení. I když i těch je dost. Proto je při analýze logů důležité chápat, že většina chyb pochází z komunikace se třetími stranami API, systémovými voláními a dalšími knihovnami. V tomto případě spočívá úloha VBR v předávání těchto chyb do logovacích souborů tak, jak jsou. A hlavní úkol uživatele je naučit se chápat, která řádka patří komu a co ten „kdo“ odpovídá. Proto, pokud kód chyby z logu VBR vás vede na stránku MSDN, je to v pořádku a správně.
Jak jsme se dohodli dříve: Veeam je takzvaná aplikace založená na SQL. To znamená, že všechna nastavení, všechny informace a vlastně všechno, co je potřeba pro normální fungování — všechno je uloženo v jeho databázi. Odtud pramení jednoduchá pravda: to, co chybí v logách, je pravděpodobně v databázi. Ale ani to není stříbrná kulka: některé věci nejsou ani v lokálních logách komponent Veeam, ani v jeho databázi. Proto je třeba se naučit zkoumat logy hostitele, logy místního stroje a logy vůbec všechno, co se účastní procesu zálohování a obnovy. Někdy se také stává, že potřebné informace nejsou nikde. Taková je cesta.
Několik příkladů takových API
Tento seznam si nemá za cíl být výjimečně úplný, takže v něm nehledejte pravdu v poslední instanci. Jeho úkolem je pouze ukázat nejčastější třetí strany API a technologie používané v našich produktech.
Začněme s VMware.
Prvním na seznamu bude vSphere API. Používá se pro autentifikaci, čtení hierarchie, vytváření a mazání snapshotů, požadování informací o strojích a mnoho (opravdu mnoho) dalšího. Funkcionalita řešení je velmi široká, proto všem doporučuji VMware vSphere API Reference pro verzi a . Pro aktuálnější verze je to snadno dostupné pomocí vyhledávače.
VIX API. Černá magie hypervizoru, pro kterou existuje samostatný . VMware API pro práci se soubory na hostiteli bez připojení k nim přes síť. Poslední záchrana, když je třeba umístit soubor do stroje, ke kterému není lepší způsob komunikace. Přináší to bolest a trápení, pokud je soubor velký a hostitel je přetížen. Ale zde platí pravidlo, že i 56,6 kB/s je lepší než 0 kB/s. V Hyper-V se podobná funkce nazývá PowerShell Direct. To však platilo pouze do příchodu
vSphere Web Services API Od verze vSphere 6.0 (zhruba, protože toto API bylo poprvé představeno ve verzi 5.5) se používá pro práci s hostovanými stroji a již takřka všude vytlačilo VIX. V podstatě jde o další API pro správu vSphere. Zajímavým doporučuji prostudovat manuál.
VDDK (Virtual Disk Development Kit). Knihovna, o které se částečně hovořilo v této . Používá se pro čtení virtuálních disků. Před dlouhou dobou byla součástí VIX, ale postupem času byla vytržena do samostatného produktu. Na oplátku se jako nástupce využívá stejné chybové kódy jako VIX. Přesto z nějakého důvodu ve samotném SDK není žádný popis těchto chyb. Proto bylo empiricky zjištěno, že chyby VDDK s jinými kódy jsou pouze překlady z binárního do desítkového kódu. Skládá se ze dvou částí – první polovina je nedokumentovaná informace o kontextu, a druhá část jsou tradiční chyby VIX/VDDK. Například, pokud vidíme:
VDDK chyba: 21036749815809.Nejednoznačná chyba
Pak to snadno převedeme na hex a dostaneme 132200000001. Neinformativní začátek 132200 jednoduše opustíme, a zbytek bude náš chybový kód (VDDK 1: Neznámá chyba). O nejčastějších chybách VDDK byl nedávno napsán samostatný .
Nyní se podívejme na Windows.
Zde je všechno potřebné a důležité pro nás nalezení ve standardním Event Viewer. Ale je zde jeden háček: podle dávné tradice Windows ukládá neúplný text chyby, ale pouze její číslo. Například chyba 5 – to je „Přístup odepřen“, a 1722 – to je „RPC server není k dispozici“, a 10060 – to je „Časový limit připojení“. Určitě je skvělé, pokud si pamatujete nejznámější, ale co dělat s dosud neviděnými?
Aby život nebyl příliš sladký, chyby se uchovávají také v šestnáctkové podobě s prefixem 0x8007. Například 0x8007000e - to je ve skutečnosti 14, Out of Memory. Proč a pro koho to bylo uděláno - to zůstává tajemstvím. Nicméně, úplný seznam chyb si můžete stáhnout zdarma a bez SMS z .
Mimochodem, někdy se vyskytují i jiné prefixy, nejen 0x8007. V tak smutné situaci je pro porozumění HRESULT ('result handle') potřeba se ještě hlouběji ponořit do pro vývojáře. V běžném životě vám to nedoporučuji, ale pokud vás na to zatlačilo okolí nebo jste zvědaví, nyní víte, co dělat.
Ale pánové v Microsoftu se nad námi trochu smilovali a představili světu nástroj . Je to malý kousek konzolového štěstí, který umí překládat chybové kódy do lidského jazyka bez použití Googlu. Funguje to zhruba takto.
C:UsersrootDesktop>err.exe 0x54f
# pro hex 0x54f / desítkový 1359
ERROR_INTERNAL_ERROR winerror.h
# Došlo k interní chybě.
# jako HRESULT: Závažnost: ÚSPĚCH (0), ZAŘÍZENÍ_NULL (0x0), Kód 0x54f
# pro hex 0x54f / desítkový 1359
ERROR_INTERNAL_ERROR winerror.h
# Došlo k interní chybě.
# 2 shody nalezeny pro "0x54f"Vzniká oprávněná otázka: proč tedy hned do logů nepíšeme rozluštění, ale necháváme tyto tajemné kódy? Odpověď je v třetích stranách aplikací. Když sám voláte nějaký WinAPI, není problém jeho odpověď rozluštit, protože k tomu existuje speciální WinAPI volání. Ale jak již bylo zmíněno, do našich logů přichází všechno, co k nám při odpovědích přijde. A pro rozluštění by bylo nutné neustále monitorovat tento tok vědomí, vyzvedávat kusy s chybami Windows, rozluštit je a vložit zpět. Řekněme si na rovinu, není to zrovna nejzábavnější činnost.
API pro správu souborů Windows se využívá při práci se soubory. Vytváření souborů, mazání, otevírání pro zápis, práce s atributy a tak dále.
Výše zmíněný PowerShell Direct jako ekvivalent VIX API ve světě Hyper-V. Bohužel není tak flexibilní: má spoustu omezení ve funkčnosti, nefunguje s každou verzí hostitele a určitě ne se všemi hosty.
RPC (Remote Procedure Call) Myslím, že není člověka, který pracoval s Windows a neviděl chyby spojené s RPC. Přes populární mýtus to není jeden konkrétní protokol, ale jakýkoli klient-server protokol, který splňuje určité parametry. Pokud však v našich logách najdeme chybu RPC, v 90 % případů to bude chyba od Microsoft RPC, který je součástí DCOM (Distributed Component Object Model). V síti najdete obrovské množství dokumentace na toto téma, nicméně většina z ní je značně zastaralá. Pokud máte silnou touhu se tématu věnovat, mohu doporučit články , a dlouhý seznam .
Hlavní příčiny vzniku RPC chyb v našich logách jsou neúspěšné pokusy o interakci mezi komponenty VBR (server > proxy, například) a nejčastěji kvůli problémům s připojením.
Nejvíce prominentní chybou je chyba The RPC server is unavailable (1722). Zjednodušeně řečeno, klient se nedokázal připojit k serveru. Jak a proč – na tuto otázku neexistuje jednoznačná odpověď, ale obvykle se jedná o problém s autentizací nebo s přístupem na port 135. To je obvyklé pro infrastruktury s dynamickým přiřazováním portů. Na toto téma existuje dokonce . A od Microsoft – k vyhledávání příčin poruchy.
Druhá nejčastější chyba: There are no more endpoints available from the endpoint mapper (1753). RPC klient nebo server se nedokázali přiřadit port. Obvykle se objevuje, když byl server (v našem případě hostitelský stroj) nastaven na dynamické přiřazování portů z úzkého rozsahu, který se vyčerpal. A pokud se podíváme ze strany klienta (v našem případě VBR serveru), znamená to, že náš VeeamVssAgent se nespustil nebo nebyl registrován jako RPC rozhraní. Na toto téma také existuje .
No a abychom uzavřeli Top-3 RPC chyb, vzpomeňme na RPC function call failed (1726). Tato chyba se objevuje, pokud bylo spojení navázáno, ale RPC požadavky neprobíhají. Například žádáme informace o stavu VSS (co kdyby se zrovna nyní prováděla stínová kopie) a v odpovědi nám přichází ticho a ignorace.
Windows Tape Backup API je potřeba pro práci s pásem knihoven nebo pohony. Jak jsem již zmínil na začátku: psát své ovladače a pak se trápit s podporou každého zařízení, to nás vůbec netěší. Proto Veeam nemá žádné vlastní ovladače. Všechno jde přes standardní API, jehož podporu implementují sami dodavatelé hardwaru. Tak je to mnohem logičtější, že?
SMB/CIFS Všichni je zvyklí psát vedle sebe, přestože si mnozí ani nepamatují, že CIFS (Common Internet File System) je pouze soukromá verze SMB (Server Message Block). Takže na tom není nic špatného. Samba — to je již realizace pro Linux/Unix a má své vlastní zvláštnosti, ale to jsem odbočil. Důležité je, že když Veeam požaduje, abychom něco zapsali přes UNC cestu (serverdirectory), server používá hierarchii ovladačů souborového systému, včetně mup a mrxsmb, pro zapsání na sdílenou složku. Odpovídající chyby budou generovány také těmito ovladači.
Nedá se obejít bez Winsock API. Pokud je potřeba něco udělat přes síť, VBR pracuje přes Windows Socket API, které je v lidovém názvosloví známé jako Winsock. Takže pokud vidíme v logu pár IP:Port, to je ono. V oficiální dokumentaci je docela pěkný seznam možných .
Výše zmíněný WMI (Windows Management Instrumentation) — to je jakési všemocné API pro správu všeho a všech na světě Windows. Například při práci s Hyper-V se většina dotazů na hostitele uskutečňuje právě přes něj. Jednoduše řečeno, je to naprosto nenahraditelné a velmi mocné ve svých možnostech. Při pokusu pomoci zjistit, kde a co se pokazilo, velmi pomáhá vestavěný nástroj WBEMtest.exe.
A poslední na seznamu, ale rozhodně ne poslední z hlediska důležitosti — VSS (Volume Shadow Storage). Tato problematika je natolik nevyčerpatelná a záhadná, kolik je o ní napsáno dokumentace. Shadow Copy lze nejlépe chápat jako zvláštní typ snapshotu, kterým v zásadě je. Díky němu lze ve VMware provádět aplikací konzistentní zálohy, a v Hyper-V téměř všechno. Mám v plánu napsat samostatný článek s jakousi syntézou o VSS, ale zatím si můžete přečíst . Jen opatrně, protože pokus o pochopení VSS hned napoprvé může vést k úrazům hlavy.
Na tom bych asi měl skončit. Považuji úkol vysvětlit nejzákladnější věci za splněný, takže v následující kapitole se už podíváme na logy. Ale pokud máte nějaké dotazy, neváhejte je vyjádřit v komentářích.
Zdroj: habr.com
