Pokračujeme v našej ponore do fascinujúceho sveta diagnostiky záznamov… a troubleshooting po logoch. V sme sa dohodli na význame základných termínov a jedným okom preskúmali celkovú štruktúru Veeam ako jedného aplikácie. Úlohou na túto — zistiť, ako sa vytvárajú logy, aké informácie sú v nich zobrazené a prečo vyzerajú tak, ako vyzerajú.
Čo si myslíte, čo vlastne sú tieto „logy“? Podľa väčšiny by logom akéhokoľvek aplikácie mala byť pridelená úloha akéhosi všemocného subjektu, ktorý väčšinu času vegetuje niekde na okraji, ale v pravý moment sa objaví z nikadiaľ v žiarivých brneniach a všetkých zachráni. Teda v nich by malo byť všetko, začínajúc od najmenších chýb v každom komponente až po jednotlivé transakcie databázy. A aby sa po chybe hneď zapisovalo, ako to opraviť. A to všetko by sa malo zmestiť do niekoľkých megabajtov, nie viac. Veď je to len text! Nemôžu textové súbory zaberať desiatky gigabajtov, niekde som to počul!
Takže logy
V reálnom svete sú logy len archívom diagnostických informácií. A čo tam uchovávať, odkiaľ získať informácie na uchovanie a aké podrobné by mali byť, rozhodujú samotní vývojári. Niekto ide cestou minimalizmu a uchováva záznamy úrovne ZAPNUTÉ/VYPNUTÉ, zatiaľ čo niekto sa snaží nazbierať všetko, čo len môže dosiahnuť. Hoci existuje aj medziverzia s možnosťou výberu takzvaného Logging Level, kde si sám určujete, aké podrobné informácie chcete uchovávať a koľko máte voľného miesta na diskoch =) V VBR je týchto úrovní dokonca šest, mimochodom. A veríte, nechcete vidieť, čo sa deje pri maximálne podrobných logoch s voľným miestom na vašom disku.
Dobre. Približne sme si uvedomili, čo chceme uchovávať, ale vzniká zákonná otázka: odkiaľ získať tieto informácie? Časť udalostí na logovanie samozrejme generujeme sami našimi internými procesmi. Ale čo robiť, keď dôjde k interakcii s vonkajším prostredím? Aby sme sa nezabudli v chaose kostýmov a bicyklov, Veeam má tendenciu nevymýšľať už vymyslené. Vždy, keď existuje už hotové API, zabudovaná funkcia v systéme, knižnica atď., uprednostníme hotové možnosti, skôr než začneme vytvárať svoje zložitosti. Aj keď tých posledných je dosť. Preto je pri analýze logov dôležité pochopiť, že veľká časť chýb pochádza z odpovedí od externých API, systémových volaní a rôznych knižníc. V tomto prípade je úloha VBR obmedzená na posielanie týchto chýb do logovacích súborov tak, ako sú. Hlavná úloha používateľa — naučiť sa chápať, ktorá riadka patrí komu a za čo ten
Ako sme sa dohodli predtým: Veeam — to je takzvaná aplikácia na báze SQL. To znamená, že všetky nastavenia, všetky informácie a vôbec všetko, čo je potrebné pre normálne fungovanie — všetko je uložené v jeho databáze. Odtiaľ vyplýva jednoduchá pravda: to, čo nie je v logoch, pravdepodobne je v databáze. Ale ani toto nie je strieborná guľka: niektoré veci nie sú ani v lokálnych logoch komponentov Veeam, ani v jeho databáze. Preto sa treba naučiť skúmať logy hostiteľa, logy lokálneho počítača a logy vôbec všetkých, ktoré sa zúčastňujú na procese zálohovania a obnovenia. A niekedy je tak, že potrebné informácie nie sú nikde. Taká je cesta.
Niekoľko príkladov takýchto API
Tento zoznam si nedáva za cieľ byť výnimočne úplný, takže v ňom netreba hľadať pravdu v konečnej inštancii. Jeho úloha — len ukázať najčastejšie externé API a technológie, ktoré sa používajú v našich produktoch.
Začneme s VMware.
Prvým v zozname bude vSphere API. Používa sa na autentifikáciu, čítanie hierarchie, vytváranie a odstraňovanie snapshotov, požadovanie informácií o strojoch a mnohom (veľmi mnohom) inom. Funkcionalita riešenia je veľmi široká, preto všetkým záujemcom môžem odporučiť VMware vSphere API Reference pre verziu a . Pre aktuálnejšie verzie sa to jednoducho vyhľadá.
VIX API. Čierna mágia hypervízora, pre ktorú existuje samostatný . VMware API na prácu s súbormi na hostiteľovi bez sieťového pripojenia. Posledná možnosť, keď treba vložiť súbor do stroja, ku ktorému nie je lepší spôsob pripojenia. Predstavuje bolesť a utrpenie, ak je súbor veľký a hostiteľ je preťažený. Ale tu platí pravidlo, že aj 56,6 kB/s je lepšie ako 0 kB/s. V Hyper-V sa podobná funkcia nazýva PowerShell Direct. Ale to bolo len do príchodu
vSphere Web Services API Od vSphere 6.0 (približne, keďže tento API bol prvýkrát predstavený vo verzii 5.5) sa používa na prácu s hosťovanými strojmi a už takmer všade nahradil VIX. V podstate ide o ďalší API na správu vSphere. Zaujímavým by som odporúčal preskúmať návod.
VDDK (Virtual Disk Development Kit). Knižnica, o ktorej bolo čiastočne zmienené v tejto . Používa sa na čítanie virtuálnych diskov. Kedysi bola súčasťou VIX, avšak časom bola vydelená ako samostatný produkt. Predsa však na základe dedičstva využíva tie isté chybové kódy ako VIX. Ale z nejakého dôvodu v samotnom SDK nie je žiadny popis týchto chýb. Preto sa zistilo experimentálne, že chyby VDDK s inými kódmi sú len translačné kódy z binárneho na desiatkový kód. Skladá sa z dvoch častí – prvá polovica predstavuje nedokumentované informácie o kontexte, zatiaľ čo druhá časť sú tradičné chyby VIX/VDDK. Napríklad, ak vidíme:
VDDK error: 21036749815809.Unknown error
Môžeme to jednoducho previesť na hex a dostaneme 132200000001. Neinformatívny začiatok 132200 jednoducho vynecháme, a zvyšok bude naším chybovým kódom (VDDK 1: Unknown error). O najčastejších chybách VDDK bola nedávno písaná samostatná .
Teraz sa pozrime na Windows.
Tu nájdeme všetko, čo potrebujeme, v štandardnom Event Viewer. Ale je tu jeden zádrhel: podľa starej tradície Windows loguje nie kompletný text chyby, ale iba jej číslo. Napríklad, chyba 5 – to je „Prístup odmietnutý“, a 1722 – to je „RPC server je nedostupný“, a 10060 – to je „Čas pripojenia vypršal“. Určite je skvelé, ak pamätáš najznámejšie, avšak čo robiť s doteraz nevídanými?
Aby život nezdál se úplně jako med, chyby se také ukládají v šestnáctkové podobě s prefixem 0x8007. Například 0x8007000e je ve skutečnosti 14, nedostatek paměti. Proč a pro koho to bylo uděláno, to je zahaleno tajemstvím. Kompletní seznam chyb si však 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 pochopení HRESULT („výsledek“ nebo „handle výsledku“) potřeba se ponořit ještě hlouběji do pro vývojáře. V běžném životě bych vám to raději nedoporučil, ale pokud vás to přesto zajímá nebo vás tlačí do kouta, teď už víte, co dělat.
Ale pánové z Microsoftu na nás přece jen trochu mysleli a představili světu nástroj . Je to kousek konzolového štěstí, který dokáže překládat chybové kódy do lidské řeči bez použití Googlu. Funguje to přibližně takto.
C:UsersrootDesktop>err.exe 0x54f
# pro hex 0x54f / des. 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. 1359
ERROR_INTERNAL_ERROR winerror.h
# Došlo k interní chybě.
# 2 shody nalezeny pro "0x54f"Vzniká legitimní otázka: proč rovnou nezapisujeme do logů rozšifrování, ale necháváme tyto tajemné kódy? Odpověď leží ve třetích aplikacích. Když sám voláš nějaké volání WinAPI, tak není problém jeho odpověď rozšifrovat, protože k tomu existuje speciální volání WinAPI. Ale jak už bylo řečeno, do našich logů se dostane všechno, co k nám přijde v odpovědích. A tady by se pro rozšifrování musely neustále monitorovat tyto proudy myšlenek, vybírat z nich kousky s chybami systému Windows, rozšifrovat je a vkládat zpět. Řekněme si upřímně, není to moc vzrušující činnost.
Windows File Management API se používá na všechny způsoby při práci se soubory. Vytváření souborů, mazání, otevírání pro zápis, práce s atributy a další a další.
Výše zmíněné PowerShell Direct je analogem VIX API ve světě Hyper-V. Bohužel, není tak flexibilní: má spoustu omezení ohledně funkčnosti, nefunguje s každou verzí hostitele a daleko ne se všemi hosty.
RPC (Remote Procedure Call) Myslím si, že niet človeka, ktorý by pracoval s Windows, a nevidel by chyby súvisiace s RPC. Napriek rozšírenému omylu to nie je jednotný protokol, ale akýkoľvek klient-server protokol, ktorý spĺňa určité parametre. Ak však v našich logoch vidíme chybu RPC, v 90 % prípadov to bude chyba od Microsoft RPC, ktorý je súčasťou DCOM (Distributed Component Object Model). Na internete nájdete obrovské množstvo dokumentácie na túto tému, ale väčšina z nej je dosť zastaraná. Ak máte však silnú túžbu študovať tému, môžem odporučiť články , a dlhý zoznam .
Hlavné dôvody, prečo sa v našich logoch vyskytujú chyby RPC, sú zlyhané pokusy o interakciu medzi komponentami VBR (server > proxy, napríklad) a najčastejšie kvôli problémom s komunikáciou.
Najpopulárnejšou chybou je chyba The RPC server is unavailable (1722). Ak to zjednodušíme, klient sa nedokázal pripojiť k serveru. Prečo a ako — na to neexistuje jednostranná odpoveď, ale obvykle to súvisí s autentifikáciou alebo sieťovým prístupom k portu 135. To je typické pre infraštruktúry s dynamickým pridelovaním portov. Na túto tému je dokonca . A od Microsoftu — na hľadanie príčin porúch.
Druhá najpopulárnejšia chyba: There are no more endpoints available from the endpoint mapper (1753). RPC klient alebo server sa nedokázali priradiť port. Obvykle sa vyskytuje, keď bol server (v našom prípade hostiteľský stroj) nastavený na dynamické pridelovanie portov z úzkeho rozsahu, ktorý sa vyčerpal. A ak sa na to pozrieme zo strany klienta (v našom prípade VBR servera), znamená to, že náš VeeamVssAgent sa buď nespustil, alebo nebol registrovaný ako RPC rozhraní. Na túto tému je tiež .
A aby sme uzavreli Top-3 chýb RPC, spomeňme RPC function call failed (1726). Objavuje sa, ak bolo pripojenie vytvorené, ale RPC požiadavky nefungujú. Napríklad sa pýtame na informácie o stave VSS (náhodou sa práve teraz robí shadow copy, a my sa pokúšame prístupovať), a v odpovedi je ticho a ignorácia.
Windows Tape Backup API je potrebné na prácu s páskovými knižnicami alebo pohonmi. Ako som už spomenul na začiatku: písať vlastné ovládače a mučiť sa potom s podporou každého zariadenia nás neteší. Preto nemá Veeam žiadne vlastné ovládače. Všetko ide cez štandardné API, ktorého podporu zabezpečujú sami výrobcovia hardvéru. Takto je to oveľa logickejšie, však?
SMB/CIFS Všetci ich zvyčajne píšu vedľa seba, aj keď nie všetci si pamätajú, že CIFS (Common Internet File System) je jednoducho súkromná verzia SMB (Server Message Block). Takže nie je nič zlé na zjednodušení týchto pojmov. Samba je už implementácia pre Linux/Unix a tam sú svoje špecifiká, ale to som sa trošku odklonil. Dôležité tu je: keď Veeam žiada o zapísanie niečoho cez UNC cestu (serverdirectory), server používa hierarchiu ovládačov súborového systému, vrátane mup a mrxsmb, na zápis na zdieľanú jednotku. Zodpovedajúce chyby budú generovať tiež tieto ovládače.
Nedá sa obísť bez Winsock API. Ak potrebuje niečo spraviť cez sieť, VBR pracuje cez Windows Socket API, známe medzi ľuďmi ako Winsock. Takže ak vidíme v logu kombináciu IP:Port, to je ono. V oficiálnej dokumentácii je slušný zoznam možných .
Výše zmíněné WMI (Windows Management Instrumentation) — to je akési všemocné API na správu všetkého a všetkých vo svete Windows. Napríklad, pri práci s Hyper-V sa takmer všetky dopyty na hostiteľa uskutočňujú práve cez neho. Jednoducho, vec úplne nepostrádateľná a veľmi mocná vo svojich možnostiach. V pokusoch pomôcť zistiť, kde a čo sa pokazilo, veľmi pomáha zabudovaný nástroj WBEMtest.exe.
A posledný v poradí, ale rozhodne nie posledný z hľadiska významu — VSS (Volume Shadow Storage). Téma je taká nevyčerpateľná a záhadná, ako je napísaných dokumentácií. Shadow Copy je najlepšie chápať ako špeciálny typ snímky, ktorou v podstate je. Vďaka nemu je možné v VMware robiť aplikáciou konzistentné zálohy, a v Hyper-V takmer všetko. Mám v pláne napísať samostatný článok s akousi zhrňujúcou informáciou o VSS, ale zatiaľ môžete skúsiť prečítať . Len opatrne, pokus pochopiť VSS na prvýkrát môže viesť k poraneniu hlavy.
Na tomto by sme sa asi mohli zastaviť. Úlohu vysvetliť najzákladnejšie veci považujem za splnenú, takže v nasledujúcej kapitole sa už pozrieme na logy. Ale ak máte otázky, neváhajte ich vyjadriť v komentároch.
Zdroj: habr.com
