Pokračujeme v našem ponoření do fascinujícího světa hádání ... odstraňování problémů pomocí protokolů. V shodli jsme se na významu základních pojmů a podívali jsme se na celkovou strukturu Veeamu jako na jedinou aplikaci jedním okem. Úkolem tohoto je zjistit, jak se tvoří soubory protokolu, jaké informace se v nich zobrazují a proč vypadají tak, jak vypadají.
Jaké jsou podle vás tyto "logy"? Podle většiny by logům jakékoli aplikace měla být přisouzena role jakési všemocné entity, která většinu času vegetí někde na dvorku, ale v pravou chvíli se z ničeho nic objeví v nablýskané zbroji a všechny zachrání. To znamená, že by měly obsahovat vše, od sebemenších chyb v každé komponentě až po jednotlivé databázové transakce. A aby se po chybě hned psalo, jak to jinak opravit. A to vše by se mělo vejít do několika megabajtů, ne více. Je to jen text! Textové soubory nemohou zabrat desítky gigabajtů, někde jsem to slyšel!
Takže logy
V reálném světě jsou protokoly pouze archivem diagnostických informací. A co tam uložit, kde získat informace pro uložení a jak podrobné by to mělo být, je na rozhodnutí samotných vývojářů. Někdo jde cestou minimalismu tím, že si vede záznamy o úrovni ZAP/VYP a někdo pilně shrabuje vše, na co dosáhne. Sice existuje i mezilehlá možnost s možností vybrat si tzv. Logging Level, kdy si sami označíte, jak podrobné informace chcete ukládat a kolik místa na disku navíc máte =) VBR má mimochodem šest takových úrovní. A věřte mi, že nechcete vidět, co se stane s tím nejpodrobnějším protokolováním s volným místem na disku.
Pokuta. Zhruba jsme pochopili, co chceme zachránit, ale vyvstává legitimní otázka: odkud tyto informace získat? Samozřejmě jsme součástí událostí pro přihlášení sami našimi interními procesy. Co ale dělat, když dojde k interakci s vnějším prostředím? Aby společnost Veeam nesklouzla do pekla s berličkami a jízdními koly, nevymýšlí vynálezy, které již byly vynalezeny. Kdykoli je k dispozici hotové API, vestavěná funkce, knihovna atd., dáme přednost hotovým možnostem, než začneme oplotit naše chytrostí. I když to druhé také stačí. Proto je při analýze protokolů důležité pochopit, že lví podíl chyb připadá na zprávy z API třetích stran, systémová volání a další knihovny. V tomto případě se role VBR snižuje na předávání těchto chyb do souborů protokolu. A hlavním úkolem uživatele je naučit se porozumět tomu, která linka je od koho a za co je tento „kdo“ zodpovědný. Pokud vás tedy chybový kód z protokolu VBR zavede na stránku MSDN, je to v pořádku a správné.
Jak jsme se shodli dříve: Veeam je takzvaná aplikace založená na SQL. To znamená, že veškerá nastavení, veškeré informace a obecně vše, co je pouze nutné pro normální fungování – vše je uloženo v jeho databázi. Z toho plyne prostá pravda: co není v protokolech, je s největší pravděpodobností v databázi. Ale ani to není stříbrná kulka: některé věci nejsou v místních protokolech komponent Veeam ani v její databázi. Proto se musíte naučit, jak studovat protokoly hostitele, protokoly místního počítače a protokoly všeho, co se účastní procesu zálohování a obnovy. A také se stává, že potřebné informace nejsou dostupné vůbec nikde. To je ta cesta.
Některé příklady takových API
Tento seznam si neklade za cíl být výjimečně úplný, takže v něm není třeba hledat konečnou pravdu. Jeho účelem je pouze ukázat nejběžnější API a technologie třetích stran používané v našich produktech.
Začněme VMware.
První na seznamu bude vSphere API. Používá se pro ověřování, čtení hierarchie, vytváření a mazání snímků, vyžádání informací o strojích a mnoho (velmi mnoho) další. Funkčnost řešení je velmi široká, takže pro verzi mohu doporučit VMware vSphere API Reference и . U aktuálnějších verzí se vše jen vygoogluje.
VIX API. Černá magie hypervizoru, pro kterou existuje separát . VMware API pro práci se soubory na hostiteli bez připojení k nim přes síť. Poslední možnost, když potřebujete vložit soubor do počítače, ke kterému neexistuje lepší komunikační kanál. Je to bolest a utrpení, pokud je soubor velký a hostitel je načten. Zde ale funguje pravidlo, že i 56,6 Kb/s je lepší než 0 Kb/s. V Hyper-V se tato věc nazývá PowerShell Direct. Ale to bylo jen předtím
vSpehere Web Services API Počínaje vSphere 6.0 (přibližně od doby, kdy bylo toto API poprvé představeno ve verzi 5.5) se používá pro práci s hostujícími stroji a téměř všude nahradilo VIX. Ve skutečnosti se jedná o další API pro správu vSphere. Zájemcům doporučuji nastudovat manuál.
VDDK (Virtual Disk Development Kit). Knihovna, o které se v tomto částečně diskutovalo . Slouží ke čtení virtuálních disků. Kdysi to bylo součástí VIX, ale postupem času bylo přesunuto do samostatného produktu. Ale jako dědic používá stejné chybové kódy jako VIX. Ale z nějakého důvodu není popis těchto chyb v samotném SDK. Proto bylo empiricky zjištěno, že chyby VDDK s jinými kódy jsou pouze překladem z binárního do desítkového kódu. Skládá se ze dvou částí – v první polovině jsou nedoložené informace o kontextu a ve druhé části jsou tradiční chyby VIX/VDDK. Pokud například vidíme:
VDDK error: 21036749815809.Unknown error
Pak to směle převedeme na hex a dostaneme 132200000001. Jednoduše zahodíme neinformativní začátek 132200 a zbytek bude náš chybový kód (VDDK 1: Neznámá chyba). O nejčastějších chybách VDDK byl nedávno samostatný .
Nyní se podívejme Okna.
Zde lze ve standardu nalézt vše, co je pro nás nejnutnější a nejdůležitější Prohlížeč událostí. Má to ale jeden háček: podle dlouhé tradice Windows nezaprotokoluje celý text chyby, ale pouze její číslo. Například chyba 5 je „Přístup odepřen“ a 1722 je „Server RPC není k dispozici“ a 10060 je „Vypršel časový limit připojení“. Samozřejmě je skvělé, když si pamatujete ty nejznámější, ale co dosud nevídané?
A aby život vůbec nevypadal jako med, chyby se ukládají i v šestnáctkovém tvaru, s předponou 0x8007. Například 0x8007000e je ve skutečnosti 14, nedostatek paměti. Proč a pro koho se tak stalo, je záhadou zahalenou temnotou. Kompletní seznam chyb si však můžete stáhnout zdarma a bez SMS .
Mimochodem, někdy existují i jiné předpony, nejen 0x8007. V takové smutné situaci, abyste porozuměli HRESULT (“výsledková rukojeť”), se musíte ponořit ještě hlouběji do pro vývojáře. V běžném životě vám to nedoporučuji, ale pokud jste se náhle přitiskli ke zdi nebo jste jen zvědaví, nyní víte, co dělat.
Jenže soudruzi v Microsoftu se nad námi trochu slitovali a ukázali světu utilitu . Jedná se o malý kousek konzolového štěstí, který dokáže přeložit chybové kódy do lidské podoby bez použití Google. Funguje to takto.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"Nabízí se legitimní otázka: proč dešifrování okamžitě nezapíšeme do protokolů, ale ponecháme tyto záhadné kódy? Odpověď je v aplikacích třetích stran. Když sami vytáhnete nějaké volání WinAPI, není těžké rozluštit jeho odpověď, protože pro to existuje dokonce speciální volání WinAPI. Ale jak již bylo řečeno, vše, co k nám přichází pouze v odpovědích, se dostává do našich logů. A tady by člověk, aby to dešifroval, musel tento proud vědomí neustále sledovat, vytahovat z něj kousky s chybami Windows, dešifrovat je a vkládat zpět. Buďme upřímní, není to ta nejvíce vzrušující činnost.
Windows File Management API při práci se soubory všemi možnými způsoby. Vytváření souborů, mazání, otevírání pro zápis, práce s atributy a tak dále a tak dále.
Zmíněno výše PowerShell Direct jako analog VIX API ve světě Hyper-V. Bohužel ne tak flexibilní: mnoho omezení funkčnosti, nefunguje to s každou verzí hostitele a ne se všemi hosty.
RPC (Vzdálené volání procedury) Nemyslím si, že existuje jediná osoba, která by pracovala s WIndows a která by neviděla chyby související s RPC. Přes populární mylnou představu se nejedná o jeden protokol, ale o jakýkoli protokol klient-server, který splňuje řadu parametrů. Pokud se však v našich protokolech vyskytne chyba RPC, v 90 % případů se bude jednat o chybu od Microsoft RPC, která je součástí DCOM (Distributed Component Object Model). Na netu najdete k tomuto tématu obrovské množství dokumentace, ale lví podíl na ní je značně zastaralý. Ale pokud existuje akutní touha studovat téma, pak mohu doporučit články , a dlouhý seznam .
Hlavními příčinami chyb RPC v našich protokolech jsou neúspěšné pokusy o komunikaci mezi komponentami VBR (například server > proxy) a nejčastěji kvůli problémům s komunikací.
Nahoře mezi všemi vrcholy je chyba Server RPC je nedostupný (1722). Jednoduše řečeno, klient nemohl navázat spojení se serverem. Jak a proč - neexistuje jednoznačná odpověď, ale obvykle se jedná o problém s autentizací nebo se síťovým přístupem k portu 135. Ten je typický pro infrastruktury s dynamickým přidělováním portů. Na toto téma existuje dokonce . A Microsoft má najít příčinu poruchy.
Druhá nejoblíbenější chyba: V mapovači koncových bodů (1753) nejsou k dispozici žádné další koncové body. Klientovi RPC nebo serveru se nepodařilo přiřadit port. Obvykle se vyskytuje, když byl server (v našem případě hostující počítač) nakonfigurován tak, aby dynamicky přiděloval porty z úzkého rozsahu, který skončil. A pokud se přihlásíte ze strany klienta (v našem případě ze serveru VBR), znamená to, že se náš VeeamVssAgent buď nespustil, nebo nebyl zaregistrován jako rozhraní RPC. Existuje také na toto téma .
Abychom dokončili 3 nejčastější chyby RPC, připomeňme si, že volání funkce RPC selhalo (1726). Zobrazí se, pokud bylo navázáno připojení, ale požadavky RPC nejsou zpracovány. Například požadujeme informace o stavu VSS (najednou se tam právě teď dělá stínová mina a my se snažíme lézt) a v odpověď na nás mlčení a ignorování.
Windows Tape Backup API potřebné pro práci s páskovými knihovnami nebo jednotkami. Jak jsem zmínil na začátku: není nám potěšením psát si vlastní ovladače a pak trpět s podporou každého zařízení. Proto vim nemá žádné vlastní ovladače. To vše prostřednictvím standardního API, jehož podporu implementují sami prodejci hardwaru. Tak mnohem logičtější, že?
SMB / CIFS Ze zvyku je všichni píší vedle sebe, i když ne každý si pamatuje, že CIFS (Common Internet File System) je jen soukromá verze SMB (Server Message Block). Na zobecnění těchto pojmů tedy není nic špatného. Samba je již implementací LinuxUnix a má své vlastní zvláštnosti, ale to jsem odbočil. Co je zde důležité: když Veeam požádá o zapsání něčeho do cesty UNC (adresář serveru), server použije hierarchii ovladačů souborového systému, včetně mup a mrxsmb, k zápisu do koule. V souladu s tím budou tyto ovladače také generovat chyby.
Bez toho to nejde Winsock API. Pokud je třeba něco udělat přes síť, VBR funguje prostřednictvím rozhraní Windows Socket API, lidově známého jako Winsock. Takže pokud v protokolu vidíme spoustu IP:Port, je to ono. Oficiální dokumentace má dobrý seznam možných .
Zmíněno výše WMI (Windows Management Instrumentation) je jakési všemocné API pro správu všeho a všech ve světě Windows. Například při práci s Hyper-V procházejí téměř všechny požadavky na hostitele. Jedním slovem, ta věc je naprosto nenahraditelná a ve svých schopnostech velmi silná. Ve snaze pomoci zjistit, kde a co je rozbité, velmi pomáhá vestavěný nástroj WBEMtest.exe.
A poslední na seznamu, ale v žádném případě ne nejméně důležité - VSS (Volume Shadow Storage). Téma je tak nevyčerpatelné a tajemné, kolik dokumentace k němu bylo napsáno. Stínová kopie je nejjednodušeji chápána jako speciální typ snímku, kterým v podstatě je. Díky němu můžete dělat zálohy konzistentní s aplikacemi ve VMware a téměř vše v Hyper-V. Mám v plánu udělat samostatný článek s nějakým zmáčknutím o VSS, ale zatím můžete zkusit číst . Jen buďte opatrní, protože. pokus o bleskové pochopení VSS může vést k poranění mozku.
U toho se možná můžeme zastavit. Úkol vysvětlit nejzákladnější věci považuji za splněný, takže v další kapitole se již podíváme na logy. Ale pokud máte nějaké dotazy, klidně se jich zeptejte v komentářích.
Zdroj: www.habr.com