Nastavljamo naše uranjanje u fascinantan svijet rješavanja problema kroz logove. U dogovorili smo se o značenju osnovnih pojmova i jednim okom pogledali opću strukturu Veeam-a kao jedinstvene aplikacije. Zadatak za ovu — razjasniti kako se formiraju log datoteke, koja se informacija u njima prikazuje i zašto izgledaju onako kako izgledaju.
Kako mislite, što zapravo predstavljaju ti „logovi“? Po mišljenju mnogih, logovima svake aplikacije treba dodijeliti ulogu svojevrsne svemoćne entiteta koja veći dio vremena provodi negdje u pozadini, ali u pravom trenutku se pojavljuje iz ničega u sjajnim oklopima i spašava sve. To znači da u njima trebaju biti sve informacije, počevši od najmanjih grešaka u svakom komponentu pa do pojedinačnih transakcija baze. I da se nakon greške odmah zapiše kako to ispraviti. I sve to treba stati u nekoliko megabajta, ne više. Pa to je samo tekst! Ne mogu tekstualne datoteke zauzimati desetke gigabajta, negdje sam to čuo!
Dakle, logovi
U stvarnom svijetu logovi su samo arhiv dijagnostičkih informacija. I što tu čuvati, odakle uzimati informacije za pohranu i koliko detaljne one trebaju biti, odlučuju sami programeri. Neki idu putem minimalizma, čuvajući zapise razine UKLJUČENO/ISKLJUČENO, dok se neki trudom skupljaju sve do čega su mogli doprijeti. Ipak, postoji i međuprostor s mogućnošću odabira takozvane razine logiranja, kada sami određujete koliko detaljnu informaciju želite čuvati i koliko imate suvišnog prostora na diskovima =) U VBR-u postoji čak šest takvih razina, uzgred rečeno. I, vjerujte, ne želite vidjeti što se događa pri maksimalno detaljnom logiranju s dostupnim slobodnim prostorom na vašem disku.
Dobro. Otprilike smo shvatili što želimo čuvati, ali postavlja se legitimno pitanje: odakle uzeti te informacije? Dio događaja za logiranje, naravno, formiramo sami našim unutarnjim procesima. No, što učiniti kada dođe do interakcije s vanjskim okruženjem? Kako bismo izbjegli ulazak u pakleno stanje prepuno improvizacija, Veeam ima tendenciju ne izmišljati već izmišljene izume. Uvijek kada postoji već gotov API, ugrađena funkcija u sustav, knjižnica itd., dati ćemo prednost gotovim rješenjima prije nego što počnemo smišljati svoja složena rješenja. Iako ih također ima dovoljno. Stoga je prilikom analize logova važno razumjeti da velika većina grešaka dolazi iz poruka od vanjskih API-ja, sistemskih poziva i drugih knjižnica. U tom slučaju, uloga VBR-a svodi se na prosljeđivanje tih grešaka u log datoteke takvima kakve jesu. A osnovni zadatak korisnika je naučiti razumjeti koja linija dolazi od koga, i za što je taj “netko” odgovoran. Dakle, ako kod greške iz VBR loga vodi do stranice MSDN, to je normalno i ispravno.
Kao što smo se ranije dogovorili: Veeam je takozvana SQL-bazirana aplikacija. Dakle, sve postavke, sve informacije i općenito sve što je potrebno za normalno funkcioniranje — sve je pohranjeno u njegovoj bazi. Odatle dolazi jednostavna istina: ono što nema u logovima, vjerojatno postoji u bazi. No, to nije čarobni metak: nekih stvari nema ni u lokalnim logovima Veeam komponenti, ni u njegovoj bazi. Zato je potrebno naučiti proučavati logove hosta, logove lokalnog računala i logove svih koji sudjeluju u procesu sigurnosne kopije i obnove. A ponekad se dogodi i da potrebne informacije nema nigdje. Takav je put.
Nekoliko primjera takvih API-ja
Ovaj popis nema za cilj biti isključivo potpun, pa nemojte u njemu tražiti apsolutnu istinu. Njegova svrha je samo prikazati najčešće vanjske API-je i tehnologije koje se koriste u našim proizvodima.
Počnimo s VMware.
Prvi na popisu bit će vSphere API. Koristi se za autentifikaciju, čitanje hijerarhije, stvaranje i brisanje snapseva, zahtjev informacija o strojevima i mnogo (zaista mnogo) drugih stvari. Funkcionalnost rješenja je vrlo široka, stoga svima zainteresiranima mogu preporučiti VMware vSphere API Referencu za verziju i . Za novije verzije lako se može pronaći putem pretraživača.
VIX API. Crna magija hipervizora, za koju postoji poseban . VMware API za rad s datotekama na hostu bez povezivanja s njima putem mreže. Opcija posljednje nade, kada je potrebno staviti datoteku na mašinu, do koje nema boljeg kanala veze. Predstavlja bol i patnju, ako je datoteka velika, a host opterećen. No tu vrijedi pravilo da je čak 56,6 Kb/s bolje od 0 Kb/s. U Hyper-V slična stvar zove se PowerShell Direct. Ali to je bilo samo do pojave
vSphere Web Services API Počevši od vSphere 6.0 (približno, jer je ovaj API prvi put predstavljen u verziji 5.5) koristi se za rad s gostujućim mašinama i već praktički svuda je istisnuo VIX. U suštini, to je još jedan API za upravljanje vSphere. Zainteresiranima bih preporučio da prouče priručnik.
VDDK (Virtual Disk Development Kit). Knjižnica o kojoj se djelomično govorilo u ovoj . Koristi se za čitanje virtualnih diskova. Nekada davno bila je dio VIX, međutim s vremenom je izdvojena u poseban proizvod. No na pravima nasljednika koristi iste kodove pogrešaka kao i VIX. Ali iz nekog razloga u samom SDK-u nema nikakvog opisa tih pogrešaka. Stoga je putem iskustva utvrđeno da su VDDK pogreške s drugim kodovima samo translacija iz binarnog u decimalni kod. Sastoji se od dva dijela - prva polovica predstavlja nedokumentirane informacije o kontekstu, dok je druga polovica - tradicionalne VIX/VDDK pogreške. Na primjer, ako vidimo:
VDDK error: 21036749815809.Unknown error
Slobodno to konvertiramo u hex i dobijemo 132200000001. Neinformativni početak 132200 jednostavno odbacujemo, a ostatak će biti naš kod pogreške (VDDK 1: Unknown error). O najčešćim VDDK pogreškama nedavno je bio pisan poseban .
Sada pogledajmo Windows.
Ovdje se sve što nam je potrebno i važno može pronaći u standardnom Event Viewer. No postoji jedan problem: prema staroj tradiciji Windows bilježi ne potpuni tekst pogreške, već samo njen broj. Na primjer, pogreška 5 — to je “Pristup odbijen”, a 1722 — to je “RPC poslužitelj nije dostupan”, pa čak i 10060 — to je “Veza istekla”. Naravno, sjajno je ako se sjecaš najpoznatijih, ali što učiniti s dosad neviđenim?
A kako život ne bi bio previše sladak, greške se čuvaju i u heksadecimalnom obliku, s prefiksom 0x8007. Na primjer, 0x8007000e — to je zapravo 14, Out of Memory. Zašto i za koga je to napravljeno — tajna je obavijena tamom. Međutim, cijeli popis grešaka može se preuzeti besplatno i bez SMS-a s .
Usput, ponekad se pojavljuju i drugi prefiksi, a ne samo 0x8007. U toj tužnoj situaciji, za razumijevanje HRESULT (“handle rezultata”) potrebno je dublje zaroniti u za programere. U svakodnevnom životu ne bih vam to savjetovao, ali ako vas slučajno pritisne situacija ili vas jednostavno zanima, sada znate što učiniti.
Ali prijatelji u Microsoftu su se malo smilovali nad nama i predstavili svijetu alat . To je mali dio konzolne sreće, koji zna prevesti kodove grešaka na ljudski jezik bez korištenja Googlea. Radi otprilike ovako.
C:UsersrootDesktop>err.exe 0x54f
# za heks 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Došlo je do unutarnje greške.
# kao HRESULT: Težina: USPJEH (0), OBJEKT_NULL (0x0), Kod 0x54f
# za heks 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Došlo je do unutarnje greške.
# 2 podudaranja pronađena za "0x54f"Postavlja se legitimno pitanje: zašto odmah ne pišemo objašnjenje u logove, već ostavljamo te tajanstvene kodove? Odgovor leži u vanjskim aplikacijama. Kada sami pozivate neki WinAPI poziv, nije teško dešifrirati njegov odgovor jer za to postoji poseban WinAPI poziv. No, kao što je već rečeno, u naše logove dolazi sve što dolazi u odgovorima. I tada bi za dešifriranje trebalo stalno nadgledati ovaj tok svijesti, izvući dijelove s greškama sustava Windows, dešifrirati ih i ponovno ih umetnuti. Ispričavam se, ali to nije najuzbudljiviji zadatak.
Windows File Management API se u raznim situacijama koristi pri radu s datotekama. Kreiranje datoteka, brisanje, otvaranje za pisanje, rad s atributima i još mnogo toga.
Navedeni PowerShell Direct je analogan VIX API-u u svijetu Hyper-V. Nažalost, nije tako fleksibilan: ima mnogo ograničenja u funkcionalnosti, ne radi sa svakom verzijom hosta i daleko ne sa svim gostima.
RPC (Remote Procedure Call) Mislim da ne postoji osoba koja je radila s Windowsom a da nije vidjela pogreške vezane uz RPC. Unatoč popularnom zabludi, to nije neki jedinstveni protokol, već bilo koji klijent-poslužiteljski protokol koji zadovoljava određene kriterije. Međutim, ako imamo pogrešku RPC u našim zapisima, u 90% slučajeva to će biti pogreška povezane s Microsoft RPC-om, koji je dio DCOM (Distributed Component Object Model). Na mreži se može pronaći ogromna količina dokumentacije na ovu temu, no veliki dio nje je prilično zastario. Ako postoji izražena želja za proučavanjem ove teme, mogu preporučiti članke , i dug popis .
Glavni uzroci pojavljivanja RPC pogrešaka u našim zapisima su neuspjeli pokušaji interakcije između komponenti VBR (poslužitelj > proxy, na primjer) i najčešće zbog problema s komunikacijom.
Najčešća pogreška je The RPC server is unavailable (1722). U pravilu, 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 do porta 135. To je karakteristično za infrastrukture s dinamičkim dodjeljivanjem portova. Na ovu temu postoji čak i . A kod Microsofta — o pronalaženju uzroka kvarova.
Druga najčešća pogreška: There are no more endpoints available from the endpoint mapper (1753). RPC klijent ili poslužitelj nisu mogli dodijeliti port. Obično se događa kada je poslužitelj (u našem slučaju gostujuća mašina) konfiguriran za dinamičko dodjeljivanje portova iz uskog raspona koji je istekao. A ako gledamo sa strane klijenta (u našem slučaju VBR poslužitelja), to znači da naš VeeamVssAgent ili nije pokrenut, ili nije registriran kao RPC sučelje. Na ovu temu također postoji .
I kako bismo završili Top-3 RPC pogreške, spomenimo RPC function call failed (1726). Ova se pogreška pojavljuje ako je veza uspostavljena, ali RPC zahtjevi ne prolaze. Na primjer, tražimo informacije o statusu VSS (možda se trenutno radi o shadow copy, a mi pokušavamo pristupiti), a u odgovoru imamo tišinu i ignoriranje.
Windows Tape Backup API potrebno za rad s trakastim bibliotekama ili pogonima. Kao što sam spomenuo na početku: pisanje vlastitih drajvera i mučenje s podrškom za svako uređaj nam ne donosi nikakvo zadovoljstvo. Zato Veeam nema vlastite drajvere. Sve ide preko standardnog API-ja, čiju podršku implementiraju sami proizvođači hardvera. Tako je mnogo logičnije, zar ne?
SMB/CIFS Svi ih po navici pišu zajedno, iako daleko nije svima poznato da je CIFS (Common Internet File System) samo privatna verzija SMB (Server Message Block). Dakle, nije ništa loše u generalizaciji ovih pojmova. Samba — to je već LinuxUnix implementacija, i tu postoje svoje osobitosti, ali skrenuo sam s teme. Ono što je važno: kada Veeam traži da snimi nešto po UNC putu (serverdirectory), server koristi hijerarhiju drajvera datotečnog sustava, uključujući mup i mrxsmb, za snimanje na dijeljenu mapu. Prema tome, greške će također generirati ti drajveri.
Nema šanse da se obavimo bez Winsock API. Ako treba nešto napraviti preko mreže, VBR radi kroz Windows Socket API, poznatiji kao Winsock. Tako da ako vidimo u logu poveznicu IP:Port, to je to. U službenoj dokumentaciji postoji dobar popis mogućih .
Navedeni WMI (Windows Management Instrumentation) — ovo je moćni API za upravljanje svime i svakime u svijetu Windowsa. Na primjer, pri radu s Hyper-V, praktički svi upiti na host javljaju se baš putem njega. Ukratko, stvar koja je potpuno nezamjenjiva i vrlo moćna u svojim mogućnostima. U pokušajima pomoći da se shvati gdje i što je pokvareno, vrlo pomaže ugrađeni alat WBEMtest.exe.
I posljednji na popisu, ali nikako ne manje važan — VSS (Volume Shadow Storage). Tema je toliko neiscrpna i tajanstvena koliko je mnogo dokumentacije o njoj napisano. Shadow Copy je najlakše razumjeti kao posebnu vrstu snimke, kojom u stvari i jest. Zahvaljujući njemu, u VMware-u možete raditi application-consistent backup-e, a u Hyper-V-u gotovo sve. Planiram napisati poseban članak s nekim sažetkom o VSS-u, ali za sada možete pokušati pročitati . Samo budite oprezni, jer pokušaj razumijevanja VSS-a s površnog pregleda može dovesti do povreda mozga.
Na tome, valjda, možemo stati. Smatram da je zadatak objašnjenja osnovnih stvari ispunjen, pa ćemo u sljedećem poglavlju već gledati logove. Ako imate pitanja, slobodno ih postavite u komentarima.
Izvor: habr.com
