Tęsiame nardymą į nuostabų spėliojimo... trikčių šalinimo pagal rąstus pasaulį. IN sutarėme dėl pagrindinių terminų reikšmės ir viena akimi pažvelgėme į bendrą Veeam struktūrą kaip į vieną programą. Šios užduotis yra išsiaiškinti, kaip formuojami žurnalo failai, kokia informacija juose rodoma ir kodėl jie atrodo taip, kaip atrodo.
Kaip manote, kas yra šie „rąstai“? Daugumos nuomone, bet kokios aplikacijos žurnalams reikėtų priskirti savotiškos visagalės esybės, kuri dažniausiai vegetuoja kur nors kieme, tačiau reikiamu momentu pasirodo iš niekur spindinčiais šarvais ir visus gelbsti, vaidmenį. Tai reiškia, kad juose turi būti viskas, nuo menkiausių klaidų kiekviename komponente iki atskirų duomenų bazės operacijų. Ir taip, kad po klaidos iš karto buvo parašyta, kaip dar taisyti. Ir visa tai turėtų tilpti į porą megabaitų, ne daugiau. Tai tik tekstas! Tekstiniai failai negali užimti dešimčių gigabaitų, aš tai kažkur girdėjau!
Taigi rąstai
Realiame pasaulyje žurnalai yra tik diagnostinės informacijos archyvas. O ką ten saugoti, iš kur gauti informacijos saugojimui ir kiek ji turi būti išsami, sprendžia patys kūrėjai. Kažkas eina minimalizmo keliu vesdamas ON / OFF lygio įrašus, o kažkas stropiai grėbia viską, ką gali pasiekti. Nors yra ir tarpinis variantas su galimybe pasirinkti taip vadinamą Logging Level, kai pats nurodote kiek detalią informaciją norite saugoti ir kiek turite papildomos vietos diske =) VBR, beje, turi šešis tokius lygius. Ir, patikėkite manimi, jūs nenorite matyti, kas atsitiks su detaliausiu registravimu su laisvos vietos diske.
gerai. Maždaug supratome, ką norime sutaupyti, tačiau kyla teisėtas klausimas: iš kur gauti šios informacijos? Žinoma, mes dalyvaujame įvykių, skirtų prisiregistruoti savo vidiniais procesais, dalis. Tačiau ką daryti, kai yra sąveika su išorine aplinka? Kad neįslystų į ramentų ir dviračių pragarą, Veeam linkęs nesugalvoti jau išrastų išradimų. Kai yra paruošta API, įmontuota funkcija, biblioteka ir pan., pirmenybę teiksime paruoštoms parinktims prieš pradėdami tverti savo gudrybes. Nors užtenka ir pastarojo. Todėl analizuojant žurnalus svarbu suprasti, kad liūto dalis klaidų tenka pranešimams iš trečiųjų šalių API, sistemos skambučiams ir kitų bibliotekų. Šiuo atveju VBR vaidmuo tenka šių klaidų persiuntimui į žurnalo failus. O pagrindinė vartotojo užduotis yra išmokti suprasti, kuri linija yra iš ko ir už ką šis „kas“ atsakingas. Taigi, jei klaidos kodas iš VBR žurnalo nukreipia jus į MSDN puslapį, viskas gerai.
Kaip sutarėme anksčiau: Veeam yra vadinamoji SQL programa. Tai reiškia, kad visi nustatymai, visa informacija ir apskritai viskas, kas reikalinga tik normaliam veikimui – viskas saugoma jos duomenų bazėje. Taigi paprasta tiesa: ko nėra žurnaluose, greičiausiai yra duomenų bazėje. Tačiau tai taip pat nėra sidabrinė kulka: kai kurių dalykų nėra nei vietiniuose Veeam komponentų žurnaluose, nei jo duomenų bazėje. Todėl turite išmokti ištirti pagrindinio kompiuterio žurnalus, vietinio kompiuterio žurnalus ir visų dalykų, kurie yra susiję su atsarginės kopijos kūrimo ir atkūrimo procese, žurnalus. O taip pat būna, kad reikiamos informacijos išvis niekur nėra. Tai yra būdas.
Kai kurie tokių API pavyzdžiai
Šis sąrašas nesiekia būti išskirtinai išsamus, todėl jame nereikia ieškoti galutinės tiesos. Jo tikslas yra tik parodyti dažniausiai mūsų produktuose naudojamas trečiųjų šalių API ir technologijas.
Pradėkime nuo "VMware".
Pirmas sąraše bus vSphere API. Naudojamas autentifikavimui, hierarchijos skaitymui, momentinių vaizdų kūrimui ir trynimui, informacijos apie mašinas užklausai ir daugybei kitų dalykų. Sprendimo funkcionalumas labai platus, todėl versijai galiu rekomenduoti VMware vSphere API Reference и . Dėl daugiau dabartinių versijų viskas yra tik Google.
VIX API. Juodoji hipervizoriaus magija, kuriai yra atskira . VMware API darbui su failais pagrindiniame kompiuteryje neprisijungiant prie jų tinkle. Paskutinis variantas, kai reikia įdėti failą į mašiną, su kuria nėra geresnio ryšio kanalo. Skausmas ir kančia, jei failas yra didelis ir pagrindinis kompiuteris įkeltas. Bet čia galioja taisyklė, kad net 56,6 Kb/s yra geriau nei 0 Kb/s. „Hyper-V“ šis dalykas vadinamas „PowerShell Direct“. Bet tai buvo tik anksčiau
vSpehere Web Services API Pradedant nuo vSphere 6.0 (apytiksliai nuo tada, kai ši API pirmą kartą buvo pristatyta 5.5 versijoje), ji naudojama darbui su svečių įrenginiais ir beveik visur išstūmė VIX. Tiesą sakant, tai dar viena API, skirta vSphere valdyti. Besidomintiems rekomenduoju studijuoti vadovas.
VDDK (Virtual Disk Development Kit). Biblioteka, kuri iš dalies buvo aptarta š . Naudojamas virtualiems diskams skaityti. Kadaise tai buvo VIX dalis, bet laikui bėgant buvo perkelta į atskirą gaminį. Tačiau kaip paveldėtojas naudoja tuos pačius klaidų kodus kaip ir VIX. Tačiau dėl tam tikrų priežasčių pačiame SDK nėra šių klaidų aprašymo. Todėl empiriškai buvo išsiaiškinta, kad VDDK klaidos su kitais kodais yra tik vertimas iš dvejetainio į dešimtainį kodą. Ją sudaro dvi dalys – pirmoji pusė yra nedokumentuota informacija apie kontekstą, o antroji dalis – tradicinės VIX/VDDK klaidos. Pavyzdžiui, jei matome:
VDDK error: 21036749815809.Unknown error
Tada drąsiai konvertuojame tai į šešioliktainį ir gauname 132200000001. Neinformatyvią 132200 pradžią tiesiog atmetame, o likusi dalis bus mūsų klaidos kodas (VDDK 1: Unknown error). Apie dažniausiai pasitaikančias VDDK klaidas visai neseniai buvo atskiras .
Dabar pažvelkime Langai.
Čia standarte galima rasti viską, kas mums būtiniausia ir svarbiausia Įvykių peržiūros programa. Tačiau yra vienas laimėjimas: pagal ilgametę tradiciją „Windows“ registruoja ne visą klaidos tekstą, o tik jos numerį. Pavyzdžiui, 5 klaida yra „Prieiga uždrausta“, o 1722 – „RPC serveris nepasiekiamas“, o 10060 – „Baigėsi ryšio laikas“. Žinoma, puiku, jei prisimeni pačius žinomiausius, bet kaip su iki šiol nematytais?
Ir kad gyvenimas visai neatrodytų kaip medus, klaidos taip pat saugomos šešioliktaine forma su priešdėliu 0x8007. Pavyzdžiui, 0x8007000e iš tikrųjų yra 14, trūko atminties. Kodėl ir kam tai buvo padaryta – tamsos gaubia paslaptis. Tačiau visą klaidų sąrašą galima atsisiųsti nemokamai ir be SMS iš .
Beje, kartais yra ir kitų priešdėlių, ne tik 0x8007. Tokioje liūdnoje situacijoje, norint suprasti HRESULT („rezultato rankena“), reikia dar labiau įsigilinti į kūrėjams. Įprastame gyvenime nepatariu to daryti, bet jei staiga prispaudėte prie sienos ar tiesiog smalsu, dabar žinote, ką daryti.
Tačiau „Microsoft“ bendražygiai mūsų šiek tiek pagailėjo ir parodė pasauliui naudingumą . Tai maža konsolės laimės dalis, kuri gali išversti klaidų kodus į žmones nenaudojant „Google“. Tai veikia taip.
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"Kyla teisėtas klausimas: kodėl iššifravimo iš karto neįrašome į žurnalus, o paliekame šiuos paslaptingus kodus? Atsakymas yra trečiųjų šalių programose. Kai pats ištraukiate kokį nors WinAPI iškvietimą, jo atsakymą nesunku iššifruoti, nes tam yra net specialus WinAPI iškvietimas. Tačiau, kaip jau minėta, viskas, kas mums pateikiama tik atsakymuose, patenka į mūsų žurnalus. O čia, norint iššifruoti, reikėtų nuolat stebėti šį sąmonės srautą, iš jo ištraukti gabalus su Windows klaidomis, iššifruoti ir įklijuoti atgal. Būkime atviri, ne pati įdomiausia veikla.
„Windows“ failų valdymo API naudojamas visais įmanomais būdais dirbant su failais. Failų kūrimas, trynimas, atidarymas rašymui, darbas su atributais ir t.t. ir t.t.
minėta aukščiau „PowerShell Direct“. kaip VIX API analogas Hyper-V pasaulyje. Deja, ne toks lankstus: daug funkcionalumo apribojimų, jis neveikia su kiekviena šeimininko versija ir ne su visais svečiais.
RSC (Remote Procedure Call) Nemanau, kad yra vienas asmuo, dirbęs su WIndows ir nematęs su RPC susijusių klaidų. Nepaisant populiarios klaidingos nuomonės, tai nėra vienas protokolas, o bet koks kliento-serverio protokolas, atitinkantis daugybę parametrų. Tačiau jei mūsų žurnaluose yra RPC klaida, 90 % atvejų tai bus klaida iš Microsoft RPC, kuri yra DCOM (Distributed Component Object Model) dalis. Tinkle galite rasti daugybę dokumentų šia tema, tačiau didžioji jos dalis yra gana pasenusi. Bet jei yra didelis noras studijuoti temą, galiu rekomenduoti straipsnius , ir ilgas sąrašas .
Pagrindinės RPC klaidų priežastys mūsų žurnaluose yra nesėkmingi bandymai susisiekti tarp VBR komponentų (pavyzdžiui, serveris > tarpinis serveris) ir dažniausiai dėl ryšio problemų.
Viršuje tarp visų geriausių yra klaida RPC serveris nepasiekiamas (1722). Paprastais žodžiais tariant, klientas negalėjo užmegzti ryšio su serveriu. Kaip ir kodėl – nėra vieno atsakymo, tačiau dažniausiai tai yra autentifikavimo arba tinklo prieigos prie 135 prievado problema. Pastaroji būdinga infrastruktūroms su dinamine prievado priskyrimu. Šioje temoje yra net . Ir „Microsoft“ turi rasti gedimo priežastį.
Antra pagal populiarumą klaida: galutinių taškų atvaizdavimo priemonėje (1753) daugiau galinių taškų nėra. RPC klientui arba serveriui nepavyko priskirti sau prievado. Paprastai įvyksta, kai serveris (mūsų atveju svečio mašina) buvo sukonfigūruotas dinamiškai paskirstyti prievadus iš siauro diapazono, kuris baigėsi. Ir jei prisijungiate iš kliento pusės (mūsų atveju VBR serverio), tai reiškia, kad mūsų VeeamVssAgent arba nepasileido, arba nebuvo užregistruota kaip RPC sąsaja. Yra ir šia tema .
Na, o norėdami užbaigti 3 populiariausias RPC klaidas, prisiminkime, kad RPC funkcijos iškvietimas nepavyko (1726). Rodoma, jei ryšys užmegztas, bet RPC užklausos neapdorojamos. Pavyzdžiui, mes prašome informacijos apie VSS būseną (staiga šiuo metu ten daroma šešėlinė mina, ir mes bandome lipti), o atsakydami į mus – tylėkite ir ignoruokite.
„Windows Tape Backup“ API reikalingas darbui su juostinėmis bibliotekomis ar įrenginiais. Kaip jau minėjau pradžioje: mums nėra malonu rašyti savo tvarkykles ir tada kentėti su kiekvieno įrenginio palaikymu. Todėl vim neturi savo tvarkyklių. Viskas per standartinę API, kurios palaikymą įgyvendina patys techninės įrangos pardavėjai. Taip daug logiškiau, tiesa?
SMB / CIFS Iš įpročio visi juos rašo greta, nors ne visi prisimena, kad CIFS (Common Internet File System) yra tik privati SMB (Server Message Block) versija. Taigi nėra nieko blogo apibendrinti šias sąvokas. Samba jau yra LinuxUnix diegimas ir turi savų ypatumų, bet aš nukrypstu. Čia svarbu: kai Veeam prašo ką nors įrašyti į UNC kelią (serverio katalogą), serveris naudoja failų sistemos tvarkyklių hierarchiją, įskaitant mup ir mrxsmb, kad galėtų rašyti į kamuoliuką. Atitinkamai, šios tvarkyklės taip pat generuos klaidas.
Negali be Winsock API. Jei ką nors reikia padaryti tinkle, VBR veikia per „Windows Socket“ API, populiariai žinomą kaip „Winsock“. Taigi, jei žurnale matome krūvą IP:Port, tai yra. Oficialioje dokumentacijoje yra geras galimų dalykų sąrašas .
minėta aukščiau WMI („Windows Management Instrumentation“) yra savotiška visagalė API, skirta valdyti viską ir visus „Windows“ pasaulyje. Pavyzdžiui, dirbant su „Hyper-V“, beveik visos prieglobos užklausos perduodamos per jį. Žodžiu, daiktas yra absoliučiai nepakeičiamas ir labai galingas savo galimybėmis. Siekiant padėti išsiaiškinti, kur ir kas sugedo, labai padeda integruotas WBEMtest.exe įrankis.
Ir paskutinis sąraše, bet jokiu būdu ne mažiau svarbus - VSS (Volume Shadow Storage). Tema yra tokia neišsemiama ir paslaptinga, kiek ja buvo parašyta daug dokumentų. Shadow Copy paprasčiausiai suprantamas kaip specialus momentinės nuotraukos tipas, kuris iš esmės ir yra. Jo dėka „VMware“ galite kurti programas atitinkančias atsargines kopijas, o „Hyper-V“ – beveik viską. Aš planuoju padaryti atskirą straipsnį su šiek tiek spaudimu apie VSS, bet kol kas galite pabandyti perskaityti . Tik būkite atsargūs, nes. Bandymas žaibiškai suprasti VSS gali sukelti smegenų traumą.
Galbūt šiuo klausimu galime sustoti. Užduotį paaiškinti pagrindinius dalykus laikau baigta, todėl kitame skyriuje jau pažvelgsime į žurnalus. Bet jei turite klausimų, nedvejodami užduokite juos komentaruose.
Šaltinis: www.habr.com