Pokračujeme v našom ponorení sa do fascinujúceho sveta hádania ... riešenie problémov pomocou protokolov. IN zhodli sme sa na význame základných pojmov a pozreli sme sa na celkovú štruktúru Veeamu ako na jednu aplikáciu jedným okom. Úlohou tohto je zistiť, ako sa vytvárajú protokolové súbory, aké informácie sa v nich zobrazujú a prečo vyzerajú tak, ako vyzerajú.
Čo si myslíte, že sú tieto "logy"? Logy ľubovoľnej aplikácie by podľa väčšiny mali mať pridelenú rolu akejsi všemocnej entity, ktorá väčšinu času vegetí niekde na dvore, no v ten správny moment sa z ničoho nič objaví v žiarivom brnení a všetkých zachráni. To znamená, že by mali obsahovať všetko, od najmenších chýb v každom komponente až po jednotlivé databázové transakcie. A aby sa po chybe hneď písalo, ako to inak opraviť. A to všetko by sa malo zmestiť do niekoľkých megabajtov, nie viac. Je to len text! Textové súbory nemôžu zabrať desiatky gigabajtov, niekde som to počul!
Takže logy
V reálnom svete sú protokoly len archívom diagnostických informácií. A čo tam uložiť, kde získať informácie na uloženie a ako podrobné by to malo byť, je na rozhodnutí samotných vývojárov. Niekto ide cestou minimalizmu tým, že si vedie záznamy o úrovni ZAP/VYP a niekto usilovne zhrabuje všetko, na čo dosiahne. Je tu síce aj medziľahlá možnosť s možnosťou zvoliť si takzvanú Logging Level, kedy si sám určíte, aké podrobné informácie chcete ukladať a koľko miesta na disku máte navyše =) VBR má mimochodom šesť takýchto úrovní. A verte mi, nechcete vidieť, čo sa stane s najpodrobnejším protokolovaním s voľným miestom na disku.
Dobre. Zhruba sme pochopili, čo chceme zachrániť, no vyvstáva legitímna otázka: odkiaľ tieto informácie získať? Samozrejme, súčasťou udalostí pre prihlásenie tvoríme sami našimi internými procesmi. Čo však robiť, keď dôjde k interakcii s vonkajším prostredím? Aby sme neskĺzli do pekla s barlami a bicyklami, Veeam má tendenciu nevymýšľať vynálezy, ktoré už boli vynájdené. Vždy, keď je k dispozícii hotové API, vstavaná funkcia, knižnica atď., dáme prednosť hotovým možnostiam pred tým, ako začneme ohradzovať naše mašinky. Hoci aj to posledné stačí. Preto je pri analýze protokolov dôležité pochopiť, že najväčší podiel chýb pripadá na správy z API tretích strán, systémové volania a iné knižnice. V tomto prípade úloha VBR spočíva v preposielaní týchto chýb do log súborov. A hlavnou úlohou používateľa je naučiť sa pochopiť, ktorá linka je od koho a za čo je tento „kto“ zodpovedný. Takže ak vás kód chyby z denníka VBR privedie na stránku MSDN, je to v poriadku a správne.
Ako sme sa zhodli skôr: Veeam je takzvaná aplikácia založená na SQL. To znamená, že všetky nastavenia, všetky informácie a vo všeobecnosti všetko, čo je len potrebné pre bežné fungovanie – všetko je uložené v jeho databáze. Z toho vyplýva jednoduchá pravda: čo nie je v protokoloch, je s najväčšou pravdepodobnosťou v databáze. Ale ani to nie je strieborná guľka: niektoré veci nie sú v lokálnych protokoloch komponentov Veeam ani v jeho databáze. Preto sa musíte naučiť, ako študovať protokoly hostiteľa, protokoly lokálneho počítača a protokoly všetkého, čo sa podieľa na procese zálohovania a obnovy. A tiež sa stáva, že potrebné informácie nie sú dostupné vôbec nikde. To je cesta.
Niekoľko príkladov takýchto rozhraní API
Tento zoznam si nekladie za cieľ byť výnimočne úplný, preto v ňom netreba hľadať konečnú pravdu. Jeho účelom je iba ukázať najbežnejšie API a technológie tretích strán používané v našich produktoch.
Začnime s VMware.
Prvý na zozname bude vSphere API. Používa sa na autentifikáciu, čítanie hierarchie, vytváranie a odstraňovanie snímok, vyžiadanie si informácií o počítačoch a oveľa (veľmi) ďalšie. Funkcionalita riešenia je veľmi široká, preto pre verziu môžem odporučiť VMware vSphere API Reference и . Pri aktuálnejších verziách sa všetko len vygoogli.
VIX API. Čierna mágia hypervízora, pre ktorú existuje samostatné . VMware API pre prácu so súbormi na hostiteľovi bez pripojenia k nim cez sieť. Variant poslednej možnosti, keď potrebujete vložiť súbor do stroja, ku ktorému neexistuje lepší komunikačný kanál. Je to bolesť a utrpenie, ak je súbor veľký a hostiteľ je načítaný. Tu ale funguje pravidlo, že aj 56,6 Kb/s je lepšie ako 0 Kb/s. V Hyper-V sa táto vec nazýva PowerShell Direct. Ale to bolo len predtým
vSpehere Web Services API Počnúc od vSphere 6.0 (približne odkedy bolo toto API prvýkrát predstavené vo verzii 5.5) sa používa na prácu s hosťujúcimi strojmi a nahradilo VIX takmer všade. V skutočnosti je to ďalšie API na správu vSphere. Pre záujemcov odporúčam naštudovať Manuálny.
VDDK (Virtual Disk Development Kit). Knižnica, o ktorej sa v tomto čiastočne hovorilo . Používa sa na čítanie virtuálnych diskov. Kedysi bol súčasťou VIX, no postupom času bol presunutý do samostatného produktu. Ale ako dedič používa rovnaké chybové kódy ako VIX. Z nejakého dôvodu však v samotnej súprave SDK nie je žiadny popis týchto chýb. Preto sa empiricky zistilo, že chyby VDDK s inými kódmi sú len prekladom z binárneho do desiatkového kódu. Pozostáva z dvoch častí – v prvej polovici sú nezdokumentované informácie o kontexte a v druhej časti sú tradičné chyby VIX/VDDK. Napríklad, ak vidíme:
VDDK error: 21036749815809.Unknown error
Potom to smelo prevedieme na hex a dostaneme 132200000001. Neinformatívny začiatok 132200 jednoducho zahodíme a zvyšok bude náš chybový kód (VDDK 1: Neznáma chyba). O najčastejších chybách VDDK bol len nedávno samostatný .
Teraz sa pozrime na Wownds.
Tu sa v norme nachádza všetko, čo je pre nás najpotrebnejšie a najdôležitejšie prehliadač udalostíAle je tu jeden háčik: podľa dlhoročnej tradície Windows Nezaznamenáva celý text chyby, ale iba jej číslo. Napríklad chyba 5 znamená „Prístup odmietnutý“, 1722 znamená „Server RPC nie je dostupný“ a 10060 znamená „Časový limit pripojenia vypršal“. Samozrejme, je skvelé, ak si pamätáte tie najčastejšie, ale čo tie, ktoré ste ešte nikdy nevideli?
A aby sa život vôbec nezdal medom, chyby sa ukladajú aj v hexadecimálnej podobe, s predponou 0x8007. Napríklad 0x8007000e je v skutočnosti 14, Nedostatok pamäte. Prečo a pre koho sa tak stalo, je záhadou zahalenou tmou. Kompletný zoznam chýb si však môžete stiahnuť zadarmo a bez SMS .
Mimochodom, niekedy existujú aj iné predpony, nielen 0x8007. V takejto smutnej situácii, aby ste pochopili HRESULT (“výsledková rukoväť”), musíte sa ponoriť ešte hlbšie do pre vývojárov. V bežnom živote vám to neodporúčam, ale ak ste sa zrazu pritlačili k stene alebo ste len zvedaví, teraz viete, čo robiť.
Ale súdruhovia v Microsofte sa nad nami trochu zľutovali a ukázali svetu pomôcku . Toto je malý kúsok konzolového šťastia, ktorý dokáže preložiť chybové kódy do ľudského jazyka bez použitia 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"Vynára sa legitímna otázka: prečo okamžite nezapíšeme dešifrovanie do denníkov, ale ponecháme tieto záhadné kódy? Odpoveď je v aplikáciách tretích strán. Keď vytiahnete nejaké volanie WinAPI sami, nie je ťažké rozlúštiť jeho odpoveď, pretože na to existuje dokonca aj špeciálne volanie WinAPI. Ale ako už bolo spomenuté, všetko, čo k nám prichádza iba v odpovediach, sa dostáva do našich denníkov. A tu by človek na to, aby ho dešifroval, musel neustále sledovať tento prúd vedomia, vyťahovať z neho kúsky s chybami Windows, dešifrovať ich a vkladať späť. Povedzme si úprimne, nie je to najvzrušujúcejšia aktivita.
Windows API na správu súborov využívaný všetkými možnými spôsobmi pri práci so súbormi. Vytváranie súborov, odstraňovanie, otváranie na zapisovanie, práca s atribútmi a tak ďalej a tak ďalej.
spomenuté vyššie PowerShell Direct ako analóg VIX API vo svete Hyper-V. Bohužiaľ, nie tak flexibilné: veľa obmedzení funkčnosti, nefunguje to s každou verziou hostiteľa a nie so všetkými hosťami.
RPC (Vzdialené volanie procedúry) Nemyslím si, že existuje jediná osoba, ktorá pracovala s WIndows a nevidela chyby súvisiace s RPC. Napriek rozšírenej mylnej predstave nejde o jeden protokol, ale o akýkoľvek protokol klient-server, ktorý spĺňa množstvo parametrov. Ak sa však v našich protokoloch vyskytne chyba RPC, v 90 % prípadov to bude chyba od Microsoft RPC, ktorá je súčasťou DCOM (Distributed Component Object Model). Na nete nájdete obrovské množstvo dokumentácie na túto tému, no leví podiel na tom je dosť zastaraný. Ale ak existuje akútna túžba študovať tému, potom môžem odporučiť články , a dlhý zoznam .
Hlavnými príčinami chýb RPC v našich protokoloch sú neúspešné pokusy o komunikáciu medzi komponentmi VBR (napríklad server > proxy) a najčastejšie problémy s komunikáciou.
V hornej časti medzi všetkými vrcholmi je chyba Server RPC je nedostupný (1722). Jednoducho povedané, klient nemohol nadviazať spojenie so serverom. Ako a prečo - neexistuje jednoznačná odpoveď, ale zvyčajne ide o problém s autentifikáciou alebo so sieťovým prístupom k portu 135. Ten je typický pre infraštruktúry s dynamickým prideľovaním portov. Na túto tému existuje dokonca . A Microsoft má nájsť príčinu poruchy.
Druhá najpopulárnejšia chyba: V mapovači koncových bodov (1753) nie sú k dispozícii žiadne ďalšie koncové body. Klientovi RPC alebo serveru sa nepodarilo priradiť port. Zvyčajne sa vyskytuje, keď bol server (v našom prípade hosťovský počítač) nakonfigurovaný na dynamické prideľovanie portov z úzkeho rozsahu, ktorý skončil. A ak sa prihlásite zo strany klienta (v našom prípade servera VBR), znamená to, že náš VeeamVssAgent sa buď nespustil, alebo nebol zaregistrovaný ako rozhranie RPC. Existuje aj na túto tému .
Aby sme dokončili top 3 chyby RPC, spomeňme si, že volanie funkcie RPC zlyhalo (1726). Zobrazí sa, ak bolo vytvorené pripojenie, ale požiadavky RPC sa nespracúvajú. Napríklad požadujeme informácie o stave VSS (zrazu sa tam práve teraz robí tieňová mína a my sa snažíme liezť) a ako odpoveď na nás mlčanie a ignorovanie.
Windows API na zálohovanie pásky potrebné na prácu s páskovými knižnicami alebo jednotkami. Ako som spomenul na začiatku: nemáme potešenie písať si vlastné ovládače a potom trpieť s podporou každého zariadenia. Preto vim nemá žiadne vlastné ovládače. Všetko cez štandardné API, ktorého podporu implementujú samotní predajcovia hardvéru. Oveľa logickejšie, však?
SMB / CIFS Každý ich píše spolu zo zvyku, hoci nie každý si pamätá, že CIFS (Common Internet File System) je jednoducho proprietárna verzia SMB (Server Message Block). Takže nie je nič zlé na zovšeobecnení týchto konceptov. Samba je na druhej strane LinuxJe to implementácia pre Unix a má svoje vlastné špecifiká, ale odbočím. Dôležité je, že keď Veeam požiada o zápis niečoho do cesty UNC (adresár servera), server použije hierarchiu ovládačov súborového systému vrátane mup a mrxsmb na zápis na zdieľaný disk. V dôsledku toho budú tieto ovládače tiež generovať chyby.
Bez toho to nejde Winsock APIAk je potrebné niečo urobiť cez sieť, VBR funguje prostredníctvom Windows Socket API, bežne známe ako Winsock. Takže ak v protokole vidíme pripojenie IP:Port, je to tak. Oficiálna dokumentácia obsahuje dobrý zoznam možných .
spomenuté vyššie WMI (Windows Management Instrumentation je akési všemocné API na správu všetkého a všetkých na svete. WindowsNapríklad pri práci s Hyper-V sa takmer všetky požiadavky na hostiteľa spracovávajú cez neho. Skrátka, je absolútne nevyhnutný a veľmi výkonný. Vstavaný nástroj WBEMtest.exe je veľmi užitočný pri zisťovaní, čo je pokazené.
A posledný na zozname, ale v žiadnom prípade nie najmenej dôležitý - VSS (Volume Shadow Storage). Téma je taká nevyčerpateľná a tajomná, koľko dokumentácie o nej bolo napísaných. Tieňová kópia je najjednoduchšie chápaná ako špeciálny typ snímky, ktorou v podstate aj je. Vďaka nemu môžete robiť zálohy konzistentné s aplikáciami vo VMware a takmer všetko v Hyper-V. Mám v pláne urobiť samostatný článok s nejakým žmýkaním o VSS, ale zatiaľ môžete skúsiť čítať . Len buďte opatrní, pretože. pokus o bleskové pochopenie VSS môže viesť k poraneniu mozgu.
V tomto sa možno môžeme zastaviť. Úlohu vysvetliť najzákladnejšie veci považujem za splnenú, takže v ďalšej kapitole sa už pozrieme na logy. Ale ak máte nejaké otázky, pokojne sa ich spýtajte v komentároch.
Zdroj: hab.com
