Nadaljujemo naše potovanje v zanimiv svet diagnostike težav prek logov. V smo se dogovorili o pomenu osnovnih izrazov in delno pregledali splošno strukturo Veeam kot enotne aplikacije. Naloga za to je razumeti, kako se oblikujejo log datoteke, kakšne informacije so v njih prikazane in zakaj izgledajo tako, kot izgledajo.
Kaj menite, kaj sploh so te 'logi'? Po mnenju večine bi morali logi vsake aplikacije igrati vlogo neke vsemožne entitete, ki večino časa prebiva nekje v ozadju, vendar pa se v pravem trenutku pojavi iz nikoder v sijočih oklepih in reši vse. To pomeni, da bi morali vsebovati vse, od najmanjših napak v vsaki komponenti do posameznih transakcij v bazi. In po napaki bi takoj napisali, kako jo odpraviti. In vse to bi moralo stati v nekaj megabajtih, ne več. To je vendar samo besedilo! Ne morejo besedilne datoteke zasedati desetine gigabajtov, nekje sem to slišal!
Torej, logi
V resničnem svetu so logi le arhiv diagnostičnih informacij. In kaj tam shraniti, od kod pridobiti informacije za shranjevanje in kako podrobne morajo biti, odločajo sami razvijalci. Nekateri se odločijo za minimalizem in shranjujejo samo zapise o VKLJ. / IZK.L., drugi pa natančno zbirajo vse, do česar lahko pridejo. Čeprav obstaja tudi vmesna možnost izbire t.i. Logging Level, ko sami določite, koliko podrobne informacije želite shraniti in koliko prostega prostora imate na diskih =) V VBR je teh ravni kar šest, mimogrede. In, verjemite, nočete videti, kaj se dogaja pri maksimalnem podrobnem beleženju z prostim prostorom na vašem disku.
Dobro. Približno smo razumeli, kaj želimo shraniti, toda postavlja se upravičeno vprašanje: kje dobiti te informacije? Del dogodkov za beleženje, seveda, oblikujemo sami s svojimi notranjimi procesi. Toda kaj storiti, ko pride do interakcije z zunanjim okoljem? Da se ne bi spuščali v pekel od obvez, ima Veeam tendenco, da ne izumlja že izumljenega. Vedno, ko obstaja že pripravljen API, vgrajena funkcija v sistemu, knjižnica itd., bomo dali prednost že pripravljeni različici, preden začnemo graditi svoje zapletene rešitve. Čeprav jih je tudi kar nekaj. Zato je pri analizi logov pomembno razumeti, da se večina napak nanaša na sporočila iz tretjih API-jev, sistemskih klicev in drugih knjižnic. V tem primeru se vloga VBR omeji na posredovanje teh napak v log datoteke kot so. Glavna naloga uporabnika je naučiti se razumeti, kateri vrstici pripada komu in za kaj je odgovoren ta “nekdo”. Zato, če koda napake iz VBR loga pripelje vas na stran MSDN, je to normalno in pravilno.
Kot smo se dogovorili prej: Veeam je tako imenovana aplikacija, ki temelji na SQL. To pomeni, da vse nastavitve, vse informacije in pravzaprav vse, kar je potrebno za normalno delovanje — vse se hrani v njegovi bazi. Tukaj je preprosta resnica: kar ni v logih, je verjetno v bazi. A to ni srebrna krogla: nekaterih stvari ne najdem niti v lokalnih logih Veeam komponent niti v njegovi bazi. Zato se je treba naučiti preučevati loge gostitelja, loge lokalnega računalnika in loge vsega, kar sodeluje v procesu varnostnega kopiranja in restavriranja. Včasih je tako, da potrebne informacije ni nikjer. To je pot.
Nekaj primerov takih API-jev
Ta seznam ne cilja na izjemno popolnost, zato ga ni treba iskati kot zadnjo instanco resnice. Njegova naloga je le pokazati najpogostejše zunanje API-je in tehnologije, ki se uporabljajo v naših izdelkih.
Začnimo s VMware.
Prvi v seznamu bo vSphere API. Uporablja se za avtentikacijo, branje hierarhije, ustvarjanje in brisanje posnetkov ter pridobivanje informacij o strojih in še mnogo (zelo mnogo) drugega. Funkcionalnost rešitve je zelo široka, zato vsem zainteresiranim priporočam VMware vSphere API Reference za različico in . Za bolj aktualne različice se vse enostavno guglira.
VIX API. Črna magija hipervizorja, za katero obstaja poseben . VMware API za delo s datotekami na gostitelju brez povezovanja z njimi prek omrežja. Možnost zadnje rešitve, ko je treba datoteko daljati v napravo, do katere ni boljšega kanala povezave. Predstavlja bolečino in trpljenje, če je datoteka velika, gostitelj pa je obremenjen. A tu velja pravilo, da je celo 56,6 Kb/s boljše od 0 Kb/s. V Hyper-V se takšna stvar imenuje PowerShell Direct. A tako je bilo le do pojava
vSphere Web Services API Od različice vSphere 6.0 naprej (približno, saj je bil ta API prvič predstavljen v različici 5.5) se uporablja za upravljanje z gostiteljskimi napravami in je praktično povsod nadomestil VIX. V bistvu je to še en API za upravljanje z vSphere. Tistim, ki jih zanima, lahko priporočim, da si ogledajo manual.
VDDK (Virtual Disk Development Kit). Knjižnica, o kateri je delno govora v tem . Uporablja se za branje virtualnih diskov. Nekdaj je bila del VIX, vendar je s časom postala ločen izdelek. Vendar pa kot dedič uporablja iste kode napak kot VIX. A iz nekega razloga v samem SDK ni nobenega opisa teh napak. Zato se je izkušeno ugotovilo, da so napake VDDK z drugimi kodami le prenos iz binarnega v decimalno kodo. Sestavljena je iz dveh delov – prva polovica predstavlja nedokumentirane informacije o kontekstu, druga polovica pa so tradicionalne VIX/VDDK napake. Na primer, če vidimo:
VDDK napaka: 21036749815809.Unknown error
Potem brez skrbi pretvorimo to v hex in dobimo 132200000001. Pomanjkljiv začetek 132200 preprosto prezremo, ostanek pa bo naš koda napake (VDDK 1: Unknown error). O najpogostejših VDDK napakah je bila pravkar objavljena ločena .
Zdaj poglejmo na Windows.
Tukaj lahko najdete vse, kar potrebujete in je pomembno za nas, v standardnem Event Viewer. A tu je ena težava: po stari tradiciji Windows beleži ne celotno besedilo napake, temveč le njen številčni identifikator. Na primer, napaka 5 — to je “Dostop zavrnjen”, napaka 1722 — to je “RPC strežnik ni na voljo”, in napaka 10060 — to je “Čas povezave je potekel”. Seveda je super, če se spomnite najbolj znanih, a kako ravnati z doslej nevidenimi?
Da bi življenje ni bilo preveč sladko, se napake shranjujejo tudi v šestnajstični obliki s predpono 0x8007. Na primer, 0x8007000e pomeni v resnici 14, Out of Memory. Zakaj in za koga je bilo to storjeno, ostaja skrivnost. Vendar pa lahko celoten seznam napak brezplačno prenesete brez SMS iz .
Mimogrede, včasih se pojavijo tudi drugi predponi, ne le 0x8007. V takšni žalostni situaciji pa je potrebno še globlje raziskati HRESULT ('result handle') za razvijalce. V vsakdanjem življenju vam tega ne bi priporočal, ampak če vas je to zanimalo ali ste pod pritiskom, zdaj veste, kaj storiti.
Vendar so nas prijatelji iz Microsofta nekoliko usmilili in svetu predstavili orodje . To je majhen delček konzolne sreče, ki zna prevajati kode napak v človeški jezik brez uporabe Googla. Deluje nekako tako.
C:UsersrootDesktop>err.exe 0x54f
# za hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Prišlo je do notranje napake.
# kot HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# za hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Prišlo je do notranje napake.
# 2 ujemanja za "0x54f"Zakonito vprašanje pa se postavi: zakaj takoj ne pišemo razlage v dnevnike, temveč pustimo te skrivnostne kode? Odgovor leži v zunanjih aplikacijah. Ko sam upravljate klic WinAPI, ni težko razločiti njegovega odgovora, saj je za to celo poseben klic WinAPI. Toda kot že rečeno, v naše dnevnike pride vse, kar dobimo v odgovorih. In tu bi bilo potrebno nenehno spremljati ta tok zavesti, iz njega izluščiti dele z napakami Windows, jih razložiti in ponovno vključiti. Povedimo odkrito, ni ravno najprivlačnejša dejavnost.
Windows File Management API se v vseh pogledih uporablja pri delu s datotekami. Ustvarjanje datotek, brisanje, odpiranje za zapis, delo z atributi in še veliko več.
Omenjeni PowerShell Direct je analog VIX API v svetu Hyper-V. Na žalost ni tako prilagodljiv: veliko omejitev glede funkcionalnosti, ne deluje z vsako različico gostitelja in daleč od vseh gostov.
RPC (Remote Procedure Call) Mislim da ne postoji osoba koja je radila s Windows sustavom a da nije vidjela greške povezane s RPC-om. Iako postoji rašireno uvjerenje da je to jedinstveni protokol, riječ je o bilo kojem klijentsko-poslužiteljskom protokolu koji zadovoljava određene kriterije. Međutim, ako imamo grešku RPC u našim zapisima, u 90% slučajeva to će biti greška Microsoft RPC-a, koji je dio DCOM-a (Distributed Component Object Model). Na internetu postoji ogromna količina dokumentacije o ovoj temi, ali većina nje je prilično zastarjela. Ako imate snažnu želju za istraživanjem, mogu preporučiti članke. , i dugački popis .
Glavni uzroci pojave RPC grešaka u našim zapisima su neuspjeli pokušaji interakcije između VBR (poslužitelj > proxy, na primjer) i najčešće zbog problema s povezivanjem.
Najveća među svim greškama je greška The RPC server is unavailable (1722). Pojednostavljeno, klijent nije mogao uspostaviti vezu s poslužiteljem. Nema jedinstvenog odgovora na pitanje zašto, ali obično je riječ o problemima s autentikacijom ili s mrežnim pristupom do porta 135. Ovo je karakteristično za infrastrukture s dinamičkim dodjeljivanjem portova. O tome postoji čak i . A od Microsofta — za pronalaženje uzroka neispravnosti.
Druga po popularnosti greška: There are no more endpoints available from the endpoint mapper (1753). RPC klijent ili poslužitelj nisu mogli dodijeliti port. Obično se javlja kada je poslužitelj (u našem slučaju virtualna mašina) bio postavljen na dinamičko dodjeljivanje portova iz uskog opsega koji je ispunjen. Ako gledamo s klijentove strane (u našem slučaju VBR poslužitelja), to znači da naš VeeamVssAgent ili nije pokrenut, ili nije registriran kao RPC sučelje. O tome također postoji .
A kako bismo završili Top-3 RPC greške, spomenimo RPC function call failed (1726). Pojavljuje se ako je veza uspostavljena, ali RPC zahtjevi ne funkcioniraju. Na primjer, tražimo informaciju o statusu VSS-a (možda se baš sada vrši shadow copy, a mi pokušavamo pristupiti), a u odgovoru imamo tišinu i ignoriranje.
Windows Tape Backup API potrebuje za delo z trakastimi knjižicami ali pogoni. Kot sem že omenil na začetku: pisanje svojih gonilnikov in potem mučenje s podporo za vsak napravo nam ne prinaša nobenega veselja. Zato nima Veeam svojih gonilnikov. Vse gre skozi standardni API, katerega podporo zagotavljajo sami proizvajalci strojne opreme. Tako je mnogo bolj smiselno, mar ne?
SMB/CIFS Vsi jih običajno pišejo skupaj, čeprav se le malokdo spomni, da je CIFS (Common Internet File System) pravzaprav le zasebna različica SMB (Server Message Block). Tako da ni nič slabega v posploševanju teh pojmov. Tukaj pa je Samba že LinuxUnix implementacija, in tam so svoje posebnosti, vendar sem se malo odmaknil. Kar je tukaj pomembno: ko Veeam zahteva zapisovanje nečesa po UNC poti (serverdirektorij), strežnik uporablja hierarhijo gonilnikov datotečnega sistema, vključno z mup in mrxsmb, za zapis na deljeno mapo. Posledično bodo tudi napake generirale ti gonilniki.
Nikakor ne moremo brez Winsock API. Če je treba kaj narediti preko omrežja, VBR deluje preko Windows Socket API, ki je v ljudskem jeziku znan kot Winsock. Tako da, če v dnevniku vidimo kombinacijo IP:Port, je to to. V uradni dokumentaciji je kar dober seznam možnih .
Omenjeni WMI (Windows Management Instrumentation) je nekakšen vsemogočni API za upravljanje vsega in vseh v svetu Windows. Na primer, pri delu s Hyper-V se skoraj vsi zahtevki do gostitelja izvajajo prav preko njega. Skratka, stvar, ki je popolnoma nenadomestljiva in zelo močna v svojih možnostih. Pri poskusih, da bi ugotovili, kje in kaj je narobe, zelo pomaga vgrajeno orodje WBEMtest.exe.
In zadnji po vrsti, a povsem ne zadnji po pomenu — VSS (Volume Shadow Storage). Tema je tako neizčrpna in skrivnostna, kolikor je veliko napisanega dokumentacije o njej. Shadow Copy je najlažje razumeti kot poseben tip posnetka, s katerim v bistvu to tudi je. Zahvaljujoč temu je v VMware mogoče opraviti application-consistent varnostne kopije, v Hyper-V pa skoraj vse. Imam v načrtu napisati poseben članek z nekakšnim povzetkom o VSS, vendar lahko zaenkrat preberete . Le previdno, ker lahko poskus razumevanja VSS na hitro privede do poškodb možganov.
Na tem mestu se verjetno lahko ustavimo. Nalogo razložiti najbolj osnovne stvari štejem za izpolnjeno, tako da bomo v naslednjem poglavju že pogledali dnevnike. Če pa imate kakšna vprašanja, jih ne oklevajte izraziti v komentarjih.
Izvor: habr.com
