Jätkame meie süvenemist põnevasse logide tõrketuvastusmaailma. Me oleme kokku leppinud baasterminite tähenduses ja heitsime pilgu Veeami üldstruktuurile kui ühele rakendusele. Selle ülesanne on mõista, kuidas loogifailid formuleeritakse, millist teavet need sisaldavad ja miks nad välja näevad just sellisena.
Kuidas te arvate, mis need "logid" üldse on? Enamiku arvates peaks iga rakenduse logid omama rolli ülivõimsa olendi näol, kes enamiku ajast lebab kuskil tagaplaanil, kuid õigel hetkel ilmub välja säravate soomustega ja päästab kõik. See tähendab, et neis peaks olema kõik, alates väikseimatest vigadest igas komponendis kuni üksikute andmebaasi tehinguteni. Ja pärast vigu peaks kohe olema kirjas, kuidas neid parandada. See kõik peaks mahu kokku mõnda megabaiti, mitte rohkem. See on ju lihtsalt tekst! Tekstifailid ei saa kaaluda kümneid gigabaite, olen seda kuskil kuulnud!
Nii et logid
Reaalses maailmas on logid lihtsalt arhiiv diagnostilisi andmeid. Arendajad peavad ise otsustama, mida salvestada, kust andmeid võtta ja kui detailsed need peaks olema. Mõned valivad minimalismi, hoides ainult sisse-/väljalülitamise taseme kandeid, teised koguvad hoolikalt kokku kõik, mis kätte saadav on. On ka vahepealne variant, kus saad valida nii-öelda Logging Level'i, kus saad ise määrata, kui detailset teavet soovid salvestada ja kui palju üleliigset ruumi sul kettal on =) VBR-l on selliseid tasemeid kuus, muide. Ja uskuge, te ei taha näha, mis toimub maksimaalselt detailses logimises, kui teie kettal on vaba ruumi.
Hästi. Me oleme enam-vähem aru saanud, mida soovime salvestada, kuid õigustatud küsimus on: kust seda teavet saada? Osaliselt loome logimise jaoks sündmusi meie siseprotsesside kaudu. Kuid mida teha, kui toimub suhtlemine väliskeskkonnaga? Et mitte sattuda karmi olukorda, kus rakendatakse erinevaid lahendusi, kaldub Veeam mitte leiutama juba leiutatud lahendusi. Igal juhul, kui on olemas juba olemasolev API, süsteemi sisse ehitatud funktsioon, teek jne, eelistame olemasolevaid lahendusi, enne kui hakkame looma oma keerukaid lahendusi. Kuigi neidki on piisavalt. Seetõttu on logide analüüsimisel oluline mõista, et enamus vigu tuleneb kolmandate API, süsteemi kutsumiste ja teiste raamatukogude teadetest. Antud juhul on VBR roll nende vigade edastamine logifailides sellisena nagu nad on. Peamine ülesanne kasutajale on õppida aru saama, missugune rida kuulub kellelegi ja mille eest see “keegi” vastutab. Seega, kui VBR logist saadud veakood viib teid MSDNi lehele, on see normaalne ja õige.
Nagu eelnevalt kokku leppisime: Veeam on nii-öelda SQL-põhine rakendus. See tähendab, et kõik seadistused, kogu teave ja tegelikult kõik, mis on vajalik normaalseks toimimiseks — kõik salvestatakse selle andmebaasi. Seega on lihtne tõde: mida logides ei leidu, see tõenäoliselt leidub andmebaasis. Kuid see ei ole hõbedane kuul: mõningaid asju ei leidu ei Veeam komponentide kohalikest logidest, ega ka tema andmebaasist. Seetõttu on oluline õppida, kuidas uurida hosti logisid, kohaliku masina logisid ja kõiki logisid, mis osalevad varundus- ja taastamisprotsessis. Juhtub ka, et vajalikke andmeid ei ole üldse kusagil. See on tee.
Mõned näited sellistest API-dest
See loetelu ei püüa saavutada täielikkust, seega ärge otsige sellest tõde viimase instantsina. Kõik, mida see peab tegema, on näidata kõige sagedamini kasutatavaid kolmandate osapoolte API-sid ja tehnoloogiaid, mida meie toodetes kasutatakse.
Alustame VMware.
Esimene loendis on vSphere API. Kasutatakse autentimiseks, hierarhia lugemiseks, snapshotide loomiseks ja kustutamiseks, teabe pärimiseks masinate kohta ja paljuks (väga paljuks) muuks. Lahenduse funktsionaalsus on väga ulatuslik, seega soovitan huvilistele tutvuda VMware vSphere API Reference versiooniga. ja . Viimaste versioonide kohta on lihtsalt guugeldatav.
VIX API. Hüperviisori musta maagia jaoks, mille jaoks on eraldi . VMware API failide haldamiseks hostis ilma võrku ühendamata. Viimane lootus, kui on vaja fail masina sisse viia, kuhu pole paremat ühendusteed. See on piin ja kannatus, kui fail on suur ja host on koormatud. Kuid siin kehtib reegel, et isegi 56,6 Kb/s on parem kui 0 Kb/s. Hyper-V-s nimetatakse sarnast lahendust PowerShell Direct. Kuid see oli nii ainult kuni
vSphere Web Services API Käesolevat versiooni 6.0 (umbes, kuna see API esitati esmakordselt versioonis 5.5) kasutatakse külalismasinatega töötamiseks ja see on praktiliselt kõikjal asendanud VIX-i. Sisuliselt on see veel üks API vSphere'i haldamiseks. Huvi korral võin soovitada uurida käsiraamatut.
VDDK (Virtual Disk Development Kit). Raamatukogu, millest on osaliselt räägitud selles . Kasutatakse virtuaalsete ketaste lugemiseks. Kunagi oli see osa VIX-ist, kuid aja jooksul on see eraldi tooteks saadetud. Samas kasutab see pärijana samu vigade koode nagu VIX. Kuid mingil põhjusel ei ole selles SDK-s vigade kirjeldust. Seetõttu on kogemuste põhjal selgunud, et VDDK vead teiste koodidega on lihtsalt binaarsest kümnendsüsteemi kodeerimine. Koosneb kahest osast – esimene pool sisaldab dokumenteerimata teavet konteksti kohta, teine pool aga traditsioonilised VIX/VDDK vead. Näiteks, kui näeme:
VDDK error: 21036749815809.Unknown error
Siis konverteerime selle julgelt heksaks ja saame 132200000001. Mitteinformatiivne algus 132200 loobime kõrvale, ning ülejäänud on meie veakood (VDDK 1: Unknown error). Viimati räägiti just kõige sagedamatest VDDK vigadest eraldi .
Nüüd vaatame Windows.
Siit leiame kõik vajalikud ja tähtsad asjad standardses Event Viewer. Kuid on üks nüanss: kaua aega tagasi traditsiooniliselt logib Windows mitte tervet veateadet, vaid ainult selle numbri. Näiteks, error 5 — see on 'Access denied' (juurdepääs keelatud), ja 1722 — see on 'The RPC server is unavailable' (RPC-server pole saadaval), ning 10060 — see on 'Connection timed out' (ühenduse aegumine). Loomulikult on tore, kui sa mäletad kõige tuntumaid, kuid kuidas olla seni nägematute vigadega?
Ja et elu ei oleks liiga lihtne, salvestatakse vead ka kuues kohal vääringus, eelnevaga 0x8007. Näiteks, 0x8007000e — see on tegelikult 14, Out of Memory (mälu otsas). Miks ja kelle jaoks see nii tehtud on — jääb saladuseks. Siiski, täieliku veateabe loendi saab tasuta alla laadida ja ilma SMS-ita .
. Muide, mõnikord leidub ka teisi eelseadeid, mitte ainult 0x8007. Nii kurvas olukorras, et mõista HRESULT ('tulemuse käepide'), peab veel sügavamale laskuma arendajate jaoks. Tavalises elus ma ei soovita seda teha, aga kui sind sundida või lihtsalt huvitab, siis nüüd tead, mida teha.
Aga Microsofti kaaslased on natuke armu meie üle ja on ilmutanud meile tööriista . See on väike tükk konsooli õnnistust, mis oskab tõlkida veakoodid inimkeelde ilma Google'ita. See töötab umbes nii.
C:UsersrootDesktop>err.exe 0x54f
# hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"Tekkib seaduslik küsimus: miks me logides kohe ei kirjuta tõlgendust, vaid jätame need salapärased koodid? Vastus peitub kolmandate osapoolte rakendustes. Kui sa ise teed mõne WinAPI kutse, siis tema vastuse tõlgendamine ei ole raske, sest selleks on isegi oma eraldi WinAPI kutse. Kuid nagu juba öeldud, meie logidesse jõuab kõik, mis iganes meie vastustes esineb. Ja siinkohal oleks tõlgendamiseks pidevalt vajalik selle teadlikkuse voogu jälgida, et sellest välja noppida Windowsi vigu, neid tõlgendada ja tagasi sisestada. Öeldes ausalt, see ei ole just kõige põnevam tegevus.
Windowsi Failihalduse API kasutatakse igasuguste failidega seotud toimingute jaoks. Failide loomine, kustutamine, kirjutamiseks avamine, atribuutide käsitlemine ja muu, ja muu.
Ülalmainitud PowerShell Direct kuid, mis on VIX API analoog Hyper-V maailmas. Kahjuks mitte nii paindlik: palju funktsionaalsuse piiranguid, ei tööta iga hosti versiooniga ja mitte kõikide külalistega.
RPC (Kaugprotseduurikõne) Usun, et ei ole ühtegi inimest, kes on töötanud Windowsiga, kes ei oleks näinud RPC-ga seotud vigu. Vaatamata levinud eksiarvamusele, ei ole see mingi ühtne protokoll, vaid mis tahes kliendi- ja serveriprotokoll, mis vastab rida parameetritele. Siiski, kui meie logides on RPC viga, on 90% juhtudest see Microsofti RPC viga, mis on osa DCOM-ist (Jaotatud Komponente Objektimudel). Internetist leiab tohutult dokumentatsiooni selle teema kohta, kuid suur osa sellest on üsna vananenud. Kui on tungiv soov teemat uurida, võin soovitada artikleid. , ja pikk nimekiri .
RPC vigade peamised põhjused meie logides on ebaõnnestunud katsed suhelda VBR-i komponentide vahel (server > proksi, näiteks) ja kõige sagedamini probleemid ühenduses.
Kõrgeim tase kõigi tippude seas — see on viga: RPC server ei ole saadaval (1722). Lihtsalt öeldes ei suutnud klient serveriga ühendust luua. Kuidas ja miks — ühte kindlat vastust ei ole, kuid tavaliselt on see probleem autentimise või võrgu ligipääsuga pordile 135. Viimane on iseloomulik infrastruktuurile, kus sadamate dünaamiline määramine toimub. Selle teema kohta on isegi . Ja Microsoftil on defektide põhjuste leidmiseks.
Teine enim levinud viga: Endpoint mapper ei saa rohkemate lõpp-punktide tasuta (1753). RPC klient või server ei suutnud ennast pordile määrata. See tekib tavaliselt siis, kui server (meie puhul külalismasin) on seadistatud dünaamiliseks sadamate määramiseks kitsas vahemikus, mis on otsa saanud. Ja kui vaadata kliendi poole (meie puhul VBR-server), siis tähendab see, et meie VeeamVssAgent kas ei käivitunud või ei olnud registreeritud RPC liidesena. Selle teema kohta on samuti .
Ja lõpetuseks, tuletame meelde RPC kolme peamist viga: 'RPC function call failed (1726)'. See viga tekib siis, kui ühendus on loodud, kuid RPC-päringud ei toimi. Näiteks, kui me üritame saada teavet VSS-i oleku kohta (kas seal parajasti luuakse varukoopia) ja vastuseks on meie jaoks vaikus ja ignoreerimine.
Windows Tape Backup API on vajalik lintraamatukogude või draivide haldamiseks. Nagu ma juba alguses mainisin: oma draiverite kirjutamine ja seejärel iga seadme toe haldamine pole meeltmööda. Seetõttu ei ole vimas oma draivereid. Kõik toimub standardse API kaudu, mille tuge pakuvad seadme tootjad ise. See on ju palju loogilisem, eks?
SMB/CIFS Kõik kirjutavad neid tavaliselt kõrvuti, kuigi kaugel ei pruugi kõik mäletada, et CIFS (Common Internet File System) on lihtsalt SMB (Server Message Block) eriversioon. Nii et nende mõistete üldistamisel pole midagi halba. Samba on juba Linux/Unix'i rakendus ja seal on oma eripärad, aga ma kaldun kõrvale. Oluline on see, et kui Veeam palub midagi UNC-teel (serverdirectory) salvestada, kasutab server failisüsteemi draiverite hierarhiat, sealhulgas mup ja mrxsmb, et salvestada jagatud kettale. Seetõttu genereerivad vead samuti need draiverid.
Ilma selleta ei saa kindlasti hakkama Winsock API. Kui on vaja midagi võrgus teha, töötleb VBR Windows Socket API kaudu, tuntud kui Winsock. Nii et kui näeme logis IP:Port kombinatsiooni, siis see on see. Ametlikus dokumentatsioonis on olemas üsna hea nimekiri võimalikest .
Ülalmainitud WMI (Windows Management Instrumentation) — see on mingi kõikvõimas API Windowsi kõigega haldamiseks. Näiteks Hyper-V töötamise ajal toimub praktiliselt kõik päringud hostile just läbi selle. Ühesõnaga, asi on täiesti asendamatu ja väga võimas oma võimalustes. Proovi aidata välja selgitada, kus ja mis on katki, aitab palju sisseehitatud tööriist WBEMtest.exe.
Viimane, kuid mitte vähem oluline — VSS (Volume Shadow Storage). Teema on nii sügavalt mitmekesine ja salapärane, kui palju on selle kohta dokumentatsiooni kirjutatud. Shadow Copy'd on kõige lihtsam mõista kui erilist tüüpi snapshot'i, millega see sisuliselt ongi. Tänu sellele saab VMware's teha rakenduse jaoks kooskõlastatud varukoopiaid, ja Hyper-V's on see peaaegu kõikehõlmav. Plaanin kirjutada uuest artiklist, mis käsitleb VSS-i, kuid seni võite proovida lugeda . Olge ettevaatlik, sest VSS-i mõistmine pealiskaudselt võib põhjustada ajukahjustusi.
Sellega võib vist piirduda. Olen täitnud ülesande selgitada kõige baasemaid asju, seega järgmises peatükis vaatame logisid juba. Kuid kui küsimusi on jäänud, siis ärge kartke neid kommentaarides esitada.
Allikas: habr.com
