Nastavljamo naše uranjanje u fascinantan svijet nagađanja ... rješavanje problema pomoću zapisa. U složili smo se oko značenja osnovnih pojmova i jednim okom promatrali ukupnu strukturu Veeama kao jedne aplikacije. Zadatak za ovaj je shvatiti kako se datoteke dnevnika formiraju, kakve se informacije prikazuju u njima i zašto izgledaju tako kako izgledaju.
Što mislite, što su ovi "cjepanici"? Prema većini, logovima svake aplikacije treba dodijeliti ulogu svojevrsnog svemoćnog entiteta koji većinu vremena vegetira negdje u dvorištu, ali se u pravom trenutku pojavi niotkuda u sjajnom oklopu i spasi sve. Odnosno, trebali bi sadržavati sve, od najmanjih grešaka u svakoj komponenti do pojedinačnih transakcija baze podataka. I tako da je nakon greške odmah napisano kako je drugačije popraviti. I sve bi to trebalo stati u par megabajta, ne više. To je samo tekst! Tekstualne datoteke ne mogu imati desetke gigabajta, negdje sam to čuo!
Dakle cjepanice
U stvarnom svijetu dnevnici su samo arhiva dijagnostičkih informacija. A što tamo pohraniti, gdje dobiti informacije za pohranu i koliko detaljne trebaju biti, na samim programerima je da odluče. Netko slijedi put minimalizma vodeći evidenciju o razini ON / OFF, a netko marljivo grablje sve što stigne. Iako postoji i međuopcija s mogućnošću odabira tzv. Logging Level, kada sami naznačite koliko detaljnih podataka želite pohraniti i koliko dodatnog prostora na disku imate =) VBR inače ima šest takvih razina. I, vjerujte mi, ne želite vidjeti što se događa s najdetaljnijim logovanjem sa slobodnim prostorom na vašem disku.
Fino. Otprilike smo shvatili što želimo uštedjeti, ali postavlja se opravdano pitanje: odakle dobiti te informacije? Naravno, i sami smo dio događaja za bilježenje putem naših internih procesa. Ali što učiniti kada postoji interakcija s vanjskim okruženjem? Kako ne bi skliznuo u pakao štaka i bicikala, Veeam nastoji ne izmišljati izume koji su već izmišljeni. Kad god postoji gotov API, ugrađena funkcija, biblioteka itd., dat ćemo prednost gotovim opcijama prije nego počnemo ograđivati svoje naprave. Iako je i ovo drugo dovoljno. Stoga je pri analizi zapisa važno razumjeti da lavovski udio pogrešaka otpada na poruke API-ja trećih strana, sistemske pozive i druge biblioteke. U ovom slučaju, uloga VBR-a svodi se na prosljeđivanje tih pogrešaka u zapisničke datoteke. A glavni zadatak korisnika je naučiti razumjeti koja je linija od koga i za što je taj "tko" odgovoran. Dakle, ako vas šifra pogreške iz VBR dnevnika odvede na MSDN stranicu, to je u redu i točno.
Kao što smo se ranije dogovorili: Veeam je takozvana aplikacija temeljena na SQL-u. To znači da sve postavke, sve informacije i općenito sve što je jedino potrebno za normalno funkcioniranje - sve je pohranjeno u svojoj bazi podataka. Otuda jednostavna istina: ono čega nema u zapisnicima najvjerojatnije je u bazi podataka. Ali ni ovo nije srebrni metak: neke stvari nisu u lokalnim zapisnicima Veeamovih komponenti, niti u njegovoj bazi podataka. Stoga morate naučiti kako proučavati zapise glavnog računala, zapise lokalnog stroja i zapise svega što je uključeno u proces izrade sigurnosne kopije i vraćanja. A događa se i da potrebne informacije uopće nisu dostupne nigdje. To je put.
Neki primjeri takvih API-ja
Ovaj popis nema za cilj biti iznimno potpun, pa u njemu nema potrebe tražiti konačnu istinu. Njegova je svrha samo prikazati najčešće API-je i tehnologije trećih strana koje se koriste u našim proizvodima.
Počnimo s tim VMware.
Prvi na listi bit će vSphere API. Koristi se za provjeru autentičnosti, čitanje hijerarhije, stvaranje i brisanje snimaka, traženje informacija o strojevima i još mnogo (vrlo mnogo) više. Funkcionalnost rješenja je vrlo široka, tako da mogu preporučiti VMware vSphere API Reference za verziju и . Za aktualnije verzije sve je samo guglano.
VIX API. Crna magija hipervizora, za koju postoji poseban . VMware API za rad s datotekama na hostu bez povezivanja s njima preko mreže. Varijanta u krajnjoj nuždi kada trebate staviti datoteku u stroj do kojeg nema boljeg komunikacijskog kanala. To je bol i patnja ako je datoteka velika, a host učitan. Ali ovdje vrijedi pravilo da je i 56,6 Kb/s bolje od 0 Kb/s. U Hyper-V, ova stvar se zove PowerShell Direct. Ali to je bilo samo prije
vSpehere Web Services API Počevši od vSphere 6.0 (otprilike, budući da je ovaj API prvi put predstavljen u verziji 5.5) koristi se za rad s gostujućim strojevima i gotovo svugdje je istisnuo VIX. Zapravo, ovo je još jedan API za upravljanje vSphereom. Za zainteresirane preporučam da prouče priručnik.
VDDK (Virtual Disk Development Kit). Knjižnica, o kojoj je u ovom djelomično bilo riječi . Koristi se za čitanje virtualnih diskova. Nekada davno bio je dio VIX-a, no s vremenom je premješten u zaseban proizvod. Ali kao nasljednik, koristi iste kodove grešaka kao VIX. Ali iz nekog razloga, nema opisa tih grešaka u samom SDK-u. Stoga je empirijski utvrđeno da su VDDK pogreške s drugim kodovima samo prijevod iz binarnog u decimalni kod. Sastoji se od dva dijela - prva polovica su nedokumentirane informacije o kontekstu, a drugi dio su tradicionalne VIX / VDDK pogreške. Na primjer, ako vidimo:
VDDK error: 21036749815809.Unknown error
Zatim to hrabro pretvorimo u hex i dobijemo 132200000001. Jednostavno odbacimo neinformativni početak 132200, a ostatak će biti naš kod pogreške (VDDK 1: Nepoznata pogreška). O najčešćim VDDK pogreškama, nedavno je bilo odvojeno .
Pogledajmo sada Windows.
Ovdje se u standardu može naći sve što nam je najpotrebnije i najvažnije Event Viewer. Ali postoji jedna začkoljica: prema dugoj tradiciji Windows ne bilježi cijeli tekst pogreške, već samo njen broj. Na primjer, pogreška 5 je "Pristup odbijen", a 1722 je "RPC poslužitelj je nedostupan", a 10060 je "Veza je istekla". Naravno, super je ako se prisjetite onih najpoznatijih, ali što je s onima dosad neviđenima?
A kako život uopće ne bi izgledao kao med, pogreške se također pohranjuju u heksadecimalnom obliku, s prefiksom 0x8007. Na primjer, 0x8007000e je zapravo 14, nema memorije. Zašto i za koga je to učinjeno misterij je obavijen tamom. Međutim, potpuni popis pogrešaka može se preuzeti besplatno i bez SMS-a .
Usput, ponekad postoje i drugi prefiksi, a ne samo 0x8007. U tako žalosnoj situaciji, da biste razumjeli HRESULT ("regulator rezultata"), trebate zaroniti još dublje u za programere. U običnom životu ne savjetujem vam da to radite, ali ako ste se iznenada pritisnuli uza zid ili ste samo znatiželjni, sada znate što vam je činiti.
Ali drugovi iz Microsofta su nam se malo sažalili i pokazali svijetu uslužni program . Ovo je mali komad sreće konzole koji može prevesti kodove grešaka u ljudski bez upotrebe Googlea. Radi ovako.
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"Postavlja se opravdano pitanje: zašto dešifriranje ne upišemo odmah u zapisnike, nego ostavimo te tajanstvene kodove? Odgovor je u aplikacijama trećih strana. Kada sami povučete neki WinAPI poziv, nije teško dešifrirati njegov odgovor, jer postoji čak i poseban WinAPI poziv za to. Ali kao što je već spomenuto, sve što nam dolazi samo u odgovorima ulazi u naše dnevnike. I ovdje, da bi se to dešifriralo, moralo bi se stalno pratiti ovaj tok svijesti, izvlačiti iz njega dijelove s Windows greškama, dešifrirati ih i zalijepiti natrag. Budimo iskreni, nije najuzbudljivija aktivnost.
Windows File Management API koristiti na sve moguće načine pri radu s datotekama. Stvaranje datoteka, brisanje, otvaranje za pisanje, rad s atributima i tako dalje i tako dalje.
gore navedeno PowerShell Direct kao analog VIX API-ja u Hyper-V svijetu. Nažalost, nije tako fleksibilan: puno ograničenja u funkcionalnosti, ne radi sa svakom verzijom hosta i ne sa svim gostima.
RPC (Remote Procedure Call) Mislim da ne postoji niti jedna osoba koja je radila s WIndowsom, a da nije vidjela pogreške povezane s RPC-om. Unatoč popularnoj zabludi, ovo nije jedan protokol, već bilo koji klijent-poslužitelj protokol koji zadovoljava brojne parametre. Međutim, ako postoji RPC pogreška u našim zapisima, 90% vremena bit će to pogreška Microsoft RPC-a, koji je dio DCOM-a (Distributed Component Object Model). Na netu možete naći ogromnu količinu dokumentacije o ovoj temi, ali je lavovski dio dosta zastario. Ali ako postoji akutna želja za proučavanjem teme, onda mogu preporučiti članke , i dugačak popis .
Glavni uzroci RPC pogrešaka u našim zapisima su neuspjeli pokušaji komunikacije između VBR komponenti (poslužitelj > proxy, na primjer) i najčešće zbog problema u komunikaciji.
Vrh vrha među svim vrhovima je pogreška RPC poslužitelj je nedostupan (1722). Jednostavno rečeno, klijent nije mogao uspostaviti vezu s poslužiteljem. Kako i zašto – nema jedinstvenog odgovora, ali obično je to problem s autentifikacijom ili s mrežnim pristupom portu 135. Potonji je tipičan za infrastrukture s dinamičkim dodjeljivanjem porta. Na ovu temu, postoji čak . A Microsoft ima pronaći uzrok neuspjeha.
Druga najpopularnija pogreška: nema više dostupnih krajnjih točaka iz mapera krajnjih točaka (1753). RPC klijent ili poslužitelj nije uspio sebi dodijeliti port. Obično se događa kada je poslužitelj (u našem slučaju, stroj za goste) konfiguriran za dinamičku dodjelu portova iz uskog raspona koji je završio. A ako se prijavite s klijentske strane (u našem slučaju VBR poslužitelja), to znači da se naš VeeamVssAgent ili nije pokrenuo ili nije registriran kao RPC sučelje. Ima i na ovu temu .
Pa, da dovršimo 3 najveće RPC pogreške, sjetimo se da poziv RPC funkcije nije uspio (1726). Pojavljuje se ako je veza uspostavljena, ali se RPC zahtjevi ne obrađuju. Na primjer, tražimo informacije o statusu VSS-a (odjednom se upravo tamo pravi mina sjene, a mi se pokušavamo popeti), a kao odgovor na nas šutnja i ignoriranje.
Windows Tape Backup API potreban za rad s knjižnicama traka ili pogonima. Kao što sam spomenuo na početku: nemamo zadovoljstvo pisati vlastite upravljačke programe i onda patiti s podrškom za svaki uređaj. Stoga vim nema vlastite upravljačke programe. Sve kroz standardni API, čiju podršku implementiraju sami proizvođači hardvera. Toliko logičnije, zar ne?
SMB / CIFS Iz navike, svi ih pišu jednu pored druge, iako se ne sjećaju svi da je CIFS (Common Internet File System) samo privatna verzija SMB (Server Message Block). Dakle, nema ništa loše u generaliziranju ovih pojmova. Samba je već implementacija LinuxUnixa i ima svoje osobitosti, ali skrenuo sam. Ono što je ovdje važno: kada Veeam zatraži da nešto upiše u UNC stazu (direktorij poslužitelja), poslužitelj koristi hijerarhiju upravljačkih programa datotečnog sustava, uključujući mup i mrxsmb, za upisivanje u loptu. Sukladno tome, ti će upravljački programi također generirati pogreške.
Ne može bez Winsock API. Ako nešto treba učiniti preko mreže, VBR radi preko Windows Socket API-ja, popularno poznatog kao Winsock. Dakle, ako vidimo hrpu IP:Port u zapisniku, to je to. Službena dokumentacija ima dobar popis mogućih .
gore navedeno WMI (Windows Management Instrumentation) je vrsta svemogućeg API-ja za upravljanje svime i svima u Windows svijetu. Na primjer, kada radite s Hyper-V-om, gotovo svi zahtjevi hostu prolaze kroz njega. Jednom riječju, stvar je apsolutno nezamjenjiva i vrlo moćna u svojim mogućnostima. U pokušaju da se otkrije gdje i što je pokvareno, ugrađeni alat WBEMtest.exe puno pomaže.
I zadnji na popisu, ali nikako najmanje važan - VSS (Volume Shadow Storage). Tema je toliko neiscrpna i tajanstvena koliko je o njoj napisano mnogo dokumentacije. Shadow Copy najjednostavnije je shvatiti kao posebnu vrstu snapshota, što u biti i jest. Zahvaljujući njemu, u VMwareu možete napraviti sigurnosne kopije konzistentne s aplikacijom, a u Hyper-V gotovo sve. Planiram napraviti zaseban članak s malo stiskanja o VSS-u, ali za sada možete pokušati pročitati . Samo oprezno, jer. pokušaj razumijevanja VSS-a u trenu može dovesti do ozljede mozga.
Na ovome, možda, možemo stati. Zadatak objašnjavanja najosnovnijih stvari smatram završenim, pa ćemo u sljedećem poglavlju već pogledati zapisnike. Ali ako imate pitanja, slobodno ih postavite u komentarima.
Izvor: www.habr.com