Við höldum áfram að dýfa okkur inn í heillandi heim giska ... bilanaleit með logs. IN við vorum sammála um merkingu grunnhugtakanna og horfðum á heildarskipulag Veeam sem eina umsókn með einu auga. Verkefni þessa er að finna út hvernig annálaskrár myndast, hvers konar upplýsingar birtast í þeim og hvers vegna þær líta út eins og þær líta út.
Hvað heldurðu að þessi "log" séu? Að mati flestra ætti logs hvers umsóknar að fá hlutverk eins konar almáttugs aðila sem gróður oftast einhvers staðar í bakgarðinum, en birtist á réttu augnabliki upp úr engu í skínandi herklæðum og bjargar öllum. Það er að segja að þeir ættu að innihalda allt, allt frá minnstu villum í hverjum þætti til einstakra gagnagrunnsviðskipta. Og svo að eftir villuna var strax skrifað hvernig annað ætti að laga það. Og allt þetta ætti að passa í nokkur megabæt, ekki meira. Þetta er bara texti! Textaskrár geta ekki tekið tugi gígabæta, ég heyrði það einhvers staðar!
Svo logarnir
Í hinum raunverulega heimi eru logs bara skjalasafn greiningarupplýsinga. Og hvað á að geyma þar, hvar á að fá upplýsingar til geymslu og hversu ítarlegar þær eiga að vera, er undir framkvæmdaraðilum sjálfum komið að ákveða. Einhver fetar braut naumhyggjunnar með því að halda skrá yfir ON / OFF stigið og einhver rakar af kostgæfni öllu sem hann getur náð. Þó að það sé líka millivalkostur með möguleika á að velja svokallað Logging Level, þegar þú gefur sjálfur til kynna hversu nákvæmar upplýsingar þú vilt geyma og hversu mikið auka diskpláss þú hefur =) VBR hefur sex slík stig, við the vegur. Og trúðu mér, þú vilt ekki sjá hvað gerist við nákvæmustu skráninguna með lausu plássi á disknum þínum.
Fínt. Við skildum nokkurn veginn hvað við viljum spara, en réttmæt spurning vaknar: hvaðan á að fá þessar upplýsingar? Auðvitað erum við hluti af atburðum til að skrá okkur með innri ferlum okkar. En hvað á að gera þegar það er samspil við ytra umhverfið? Til þess að renna ekki inn í helli af hækjum og reiðhjólum, hefur Veeam tilhneigingu til að finna ekki upp uppfinningar sem þegar hafa verið fundnar upp. Alltaf þegar það er tilbúið API, innbyggð aðgerð, bókasafn osfrv., munum við velja tilbúna valkosti áður en við byrjum að girða búnaðinn okkar. Þó það síðarnefnda sé líka nóg. Þess vegna, þegar þú greinir annála, er mikilvægt að skilja að stærstur hluti villanna fellur á skilaboð frá þriðja aðila API, kerfissímtölum og öðrum bókasöfnum. Í þessu tilviki snýst hlutverk VBR um að senda þessar villur áfram til eins og er annálaskrár. Og aðalverkefni notandans er að læra að skilja hvaða lína er frá hverjum og hvað þessi „hver“ ber ábyrgð á. Svo ef villukóði úr VBR skránni fer með þig á MSDN síðu, þá er það í lagi og rétt.
Eins og við vorum sammála um áðan: Veeam er svokallað SQL byggt forrit. Þetta þýðir að allar stillingar, allar upplýsingar og almennt allt sem er aðeins nauðsynlegt fyrir eðlilega virkni - allt er geymt í gagnagrunni þess. Þess vegna er hinn einfaldi sannleikur: það sem er ekki í annálunum er líklegast í gagnagrunninum. En þetta er heldur ekki silfurkúla: sumt er ekki í staðbundnum skrám Veeam íhluta, né í gagnagrunni þess. Þess vegna þarftu að læra hvernig á að rannsaka hýsingarskrárnar, annála staðbundinnar vélar og skrár yfir allt sem tekur þátt í afritunar- og endurheimtarferlinu. Og það kemur líka fyrir að nauðsynlegar upplýsingar liggja hvergi fyrir. Það er leiðin.
Nokkur dæmi um slík API
Þessi listi miðar ekki að því að vera einstaklega tæmandi, svo það er engin þörf á að leita að endanlegum sannleika í honum. Tilgangur þess er aðeins að sýna algengustu API og tækni þriðja aðila sem notuð eru í vörum okkar.
Við skulum byrja VMware.
Fyrstur á listanum verður vSphere API. Notað til auðkenningar, lesa stigveldið, búa til og eyða skyndimyndum, biðja um upplýsingar um vélar og margt (mjög margt) fleira. Virkni lausnarinnar er mjög breiður, svo ég get mælt með VMware vSphere API tilvísun fyrir útgáfuna и . Fyrir fleiri núverandi útgáfur er allt bara gúgglað.
VIX API. Svartur galdur hypervisor, sem það er sérstakt . VMware API til að vinna með skrár á gestgjafanum án þess að tengjast þeim í gegnum netið. Afbrigði af þrautavara þegar þú þarft að setja skrá í vél sem engin betri samskiptarás er til. Það er sársauki og þjáning ef skráin er stór og hýsillinn er hlaðinn. En hér virkar sú regla að jafnvel 56,6 Kb/s er betra en 0 Kb/s. Í Hyper-V er þetta kallað PowerShell Direct. En það var aðeins áður
vSpehere Web Services API Frá vSphere 6.0 (u.þ.b. frá því að þetta API var fyrst kynnt í útgáfu 5.5) er það notað til að vinna með gestavélum og hefur komið í stað VIX nánast alls staðar. Reyndar er þetta annað API til að stjórna vSphere. Fyrir þá sem hafa áhuga mæli ég með að læra handbók.
VDDK (Virtual Disk Development Kit). Bókasafnið, sem var að hluta til rætt í þessu . Notað til að lesa sýndardiska. Einu sinni var það hluti af VIX, en með tímanum var það flutt í sérstaka vöru. En sem erfingi notar það sömu villukóða og VIX. En af einhverjum ástæðum er engin lýsing á þessum villum í SDK sjálfu. Þess vegna kom í ljós með reynslu að VDDK villur með öðrum kóða eru bara þýðing úr tvíundarkóða yfir í aukastaf. Það samanstendur af tveimur hlutum - fyrri helmingurinn er óskráðar upplýsingar um samhengið og seinni hlutinn eru hefðbundnar VIX / VDDK villur. Til dæmis, ef við sjáum:
VDDK error: 21036749815809.Unknown error
Síðan breytum við þessu djarflega í hex og fáum 132200000001. Við fleygum einfaldlega óupplýsandi byrjuninni á 132200, og afgangurinn verður villukóðinn okkar (VDDK 1: Óþekkt villa). Um algengustu VDDK villurnar var nýlega aðskilin .
Nú skulum við líta á Windows.
Hér er allt sem er okkur nauðsynlegast og mikilvægast að finna í staðlinum Event Viewer. En það er einn galli: samkvæmt langri hefð skráir Windows ekki allan texta villunnar, heldur aðeins númer hennar. Til dæmis er villa 5 „Aðgangi hafnað“ og 1722 er „RPC miðlarinn er ekki tiltækur“ og 10060 er „Tímamörk tengd“. Auðvitað er frábært ef þú manst eftir þeim frægustu, en hvað með þá sem hingað til hafa ekki sést?
Og svo lífið virðist alls ekki eins og hunang, eru villur einnig geymdar á sextándu formi, með forskeytinu 0x8007. Til dæmis, 0x8007000e er í raun 14, Minnislaust. Hvers vegna og fyrir hverja þetta var gert er ráðgáta hulin myrkri. Hins vegar er hægt að hlaða niður heildarlista yfir villur ókeypis og án SMS frá .
Við the vegur, stundum eru önnur forskeyti, ekki bara 0x8007. Í svona sorglegum aðstæðum, til að skilja HRESULT („niðurstöðuhandfang“), þarftu að kafa enn dýpra í fyrir þróunaraðila. Í venjulegu lífi ráðlegg ég þér ekki að gera þetta, en ef þú þrýstir skyndilega upp að veggnum eða ert bara forvitinn, þá veistu núna hvað þú átt að gera.
En félagarnir hjá Microsoft vorkenndu okkur aðeins og sýndu heiminum gagnsemi . Þetta er lítið stykki af huggahamingju sem getur þýtt villukóða yfir á mannlega án þess að nota Google. Þetta virkar svona.
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"Réttmæt spurning vaknar: hvers vegna skrifum við ekki afkóðunina strax í annálana, heldur skiljum eftir þessa dularfullu kóða? Svarið er í forritum frá þriðja aðila. Þegar þú dregur eitthvert WinAPI símtal sjálfur er ekki erfitt að ráða viðbrögð þess, því það er meira að segja sérstakt WinAPI kall fyrir þetta. En eins og áður hefur verið nefnt, fer allt sem kemur aðeins til okkar í svörum inn í skrárnar okkar. Og hér, til þess að afkóða það, þyrfti maður stöðugt að fylgjast með þessum meðvitundarstraumi, draga úr honum bita með Windows villum, afkóða þá og líma aftur. Við skulum vera heiðarleg, ekki mest spennandi athöfnin.
Windows File Management API notað á allan mögulegan hátt þegar unnið er með skrár. Búa til skrár, eyða, opna til að skrifa, vinna með eiginleika og svo framvegis og svo framvegis.
nefnd hér að ofan PowerShell Direct sem hliðstæða VIX API í Hyper-V heiminum. Því miður, ekki svo sveigjanlegt: miklar takmarkanir á virkni, það virkar ekki með öllum útgáfum gestgjafans og ekki með öllum gestum.
CPR (Remote Procedure Call) Ég held að það sé ekki einn einstaklingur sem hefur unnið með Windows sem hefur ekki séð RPC-tengdar villur. Þrátt fyrir hinn vinsæla misskilning er þetta ekki ein samskiptaregla, heldur allar samskiptareglur viðskiptavinar-miðlara sem uppfyllir fjölda breytu. Hins vegar, ef það er RPC villa í annálum okkar, mun 90% tilvika vera villa frá Microsoft RPC, sem er hluti af DCOM (Distributed Component Object Model). Þú getur fundið mikið magn af skjölum um þetta efni á netinu, en bróðurparturinn af þeim er frekar úreltur. En ef það er bráð löngun til að kynna sér efnið, þá get ég mælt með greinum , og langur listi .
Helstu orsakir RPC villna í annálum okkar eru misheppnaðar tilraunir til að hafa samskipti á milli VBR íhluta (þjónn > proxy, til dæmis) og oftast vegna samskiptavandamála.
Efsti toppurinn meðal allra toppa er villa RPC þjónninn er ekki tiltækur (1722). Í einföldu máli, viðskiptavinurinn gat ekki komið á tengingu við netþjóninn. Hvernig og hvers vegna - það er ekkert eitt svar, en venjulega er það vandamál með auðkenningu eða með netaðgangi að höfn 135. Hið síðarnefnda er dæmigert fyrir innviði með kraftmikilli höfn. Um þetta efni er jafnvel . Og Microsoft hefur til að finna orsök bilunarinnar.
Næstvinsælasta villa: Það eru ekki fleiri endapunktar tiltækir frá endapunktakortara (1753). RPC biðlarinn eða þjónninn tókst ekki að úthluta sjálfum sér gátt. Gerist venjulega þegar þjónninn (í okkar tilfelli, gestavélin) hefur verið stillt til að úthluta höfnum á virkan hátt frá þröngu svið sem er lokið. Og ef þú skráir þig inn frá biðlarahliðinni (í okkar tilfelli, VBR þjóninum), þýðir þetta að VeeamVssAgent okkar annað hvort byrjaði ekki eða var ekki skráð sem RPC tengi. Það er líka um þetta efni .
Jæja, til að klára efstu 3 RPC villurnar skulum við muna að RPC aðgerðakallið mistókst (1726). Birtist ef tenging hefur verið komið á en RPC beiðnir eru ekki unnar. Til dæmis óskum við eftir upplýsingum um stöðu VSS (allt í einu er verið að gera skugganámu þarna, og við erum að reyna að klifra), og til að bregðast við okkur, þegja og hunsa.
Windows Tape Backup API þarf til að vinna með segulbandasafni eða drifum. Eins og ég nefndi í upphafi: við höfum enga ánægju af því að skrifa eigin ökumenn og þjást síðan með stuðningi hvers tækis. Þess vegna hefur vim enga eigin rekla. Allt í gegnum staðlað API, sem stuðningur er útfærður af vélbúnaðarframleiðendum sjálfum. Svo miklu rökréttara, ekki satt?
SMB / CIFS Af vana skrifa allir hlið við hlið, þó ekki allir muni eftir því að CIFS (Common Internet File System) er bara einkaútgáfa af SMB (Server Message Block). Það er því ekkert að því að alhæfa þessi hugtök. Samba er nú þegar LinuxUnix útfærsla, og það hefur sína sérkenni, en ég víkja. Hvað er mikilvægt hér: þegar Veeam biður um að skrifa eitthvað á UNC slóðina (serverdirectory), notar þjónninn stigveldi skráarkerfisrekla, þar á meðal mup og mrxsmb, til að skrifa á kúluna. Í samræmi við það munu þessir ökumenn einnig búa til villur.
Get ekki verið án Winsock API. Ef eitthvað þarf að gera í gegnum netið vinnur VBR í gegnum Windows Socket API, almennt þekkt sem Winsock. Þannig að ef við sjáum fullt af IP: Port í skránni, þá er þetta það. Opinbera skjölin hafa góðan lista yfir mögulegar .
nefnd hér að ofan WMI (Windows Management Instrumentation) er eins konar almáttugur API til að stjórna öllu og öllum í Windows heiminum. Til dæmis, þegar unnið er með Hyper-V, fara næstum allar beiðnir til gestgjafans í gegnum það. Í einu orði sagt, hluturinn er algjörlega óbætanlegur og mjög öflugur í getu sinni. Til að reyna að finna út hvar og hvað er bilað hjálpar innbyggða WBEMtest.exe tólið mikið.
Og síðastur á listanum, en alls ekki síst í mikilvægi - VSS (Volume Shadow Storage). Efnið er jafn ótæmandi og dularfullt og mikið hefur verið skrifað um það. Skuggaafritun er einfaldlega skilin sem sérstök tegund af skyndimynd, sem hún er í rauninni. Þökk sé honum geturðu gert forritssamræmt afrit í VMware og næstum allt í Hyper-V. Ég hef áform um að gera sérstaka grein með smá klemmu á VSS, en í bili geturðu prófað að lesa . Farðu bara varlega, því. að reyna að skilja VSS í fljótu bragði getur leitt til heilaskaða.
Á þessu getum við kannski hætt. Ég tel það verkefni að útskýra grunnatriðin lokið, svo í næsta kafla munum við nú þegar líta á annálana. En ef þú hefur einhverjar spurningar skaltu ekki hika við að spyrja þær í athugasemdunum.
Heimild: www.habr.com