Ons gaan voort met ons onderdompeling in die fassinerende wêreld van raai ... probleemoplossing deur logs. IN ons het ooreengekom oor die betekenis van die basiese terme en met een oog na die algehele struktuur van Veeam as 'n enkele toepassing gekyk. Die taak vir hierdie een is om uit te vind hoe loglêers gevorm word, watter soort inligting daarin vertoon word en hoekom hulle lyk soos hulle lyk.
Wat dink jy is hierdie "logs"? Volgens die meeste moet die logs van enige toepassing die rol van ’n soort almagtige entiteit toegeken word wat meeste van die tyd iewers in die agterplaas plant, maar op die regte oomblik uit die niet in blink wapenrusting verskyn en almal red. Dit wil sê, hulle moet alles bevat, van die geringste foute in elke komponent tot individuele databasistransaksies. En sodat daar na die fout dadelik geskryf is hoe anders om dit reg te stel. En dit alles behoort in 'n paar megagrepe te pas, nie meer nie. Dit is net teks! Tekslêers kan nie tiene gigagrepe vat nie, ek het dit iewers gehoor!
Dus die logs
In die regte wêreld is logs net 'n argief van diagnostiese inligting. En wat om daar te stoor, waar om inligting vir berging te kry en hoe gedetailleerd dit moet wees, is aan die ontwikkelaars self om te besluit. Iemand volg die pad van minimalisme deur rekord te hou van die AAN / AF-vlak, en iemand hark ywerig alles wat hulle kan bereik. Alhoewel daar ook 'n tussenopsie is met die vermoë om die sogenaamde Logging Level te kies, wanneer jy self aandui hoe gedetailleerde inligting jy wil stoor en hoeveel ekstra skyfspasie jy het =) VBR het terloops ses sulke vlakke. En glo my, jy wil nie sien wat gebeur met die mees gedetailleerde logging met vrye spasie op jou skyf nie.
Goed. Ons het min of meer verstaan wat ons wil spaar, maar 'n wettige vraag ontstaan: waar om hierdie inligting vandaan te kry? Natuurlik vorm ons deel van die gebeure om onsself aan te meld deur ons interne prosesse. Maar wat om te doen wanneer daar 'n interaksie met die eksterne omgewing is? Om nie in 'n pikhel van krukke en fietse te gly nie, is Veeam geneig om nie uitvindings uit te dink wat reeds uitgevind is nie. Wanneer daar ook al 'n klaargemaakte API, ingeboude funksie, biblioteek, ens. is, sal ons voorkeur gee aan klaargemaakte opsies voordat ons ons kontrepesies begin omhein. Alhoewel laasgenoemde ook genoeg is. Daarom, wanneer logboeke ontleed word, is dit belangrik om te verstaan dat die grootste deel van foute op boodskappe van derdeparty-API's, stelseloproepe en ander biblioteke val. In hierdie geval kom die rol van VBR daarop neer om hierdie foute aan te stuur na die log-lêers soos dit is. En die hooftaak van die gebruiker is om te leer verstaan watter lyn van wie is, en waarvoor hierdie "wie" verantwoordelik is. So as 'n foutkode van die VBR-logboek jou na 'n MSDN-bladsy neem, is dit goed en korrek.
Soos ons vroeër ooreengekom het: Veeam is 'n sogenaamde SQL-gebaseerde toepassing. Dit beteken dat alle instellings, alle inligting en in die algemeen alles wat net nodig is vir normale funksionering - alles in sy databasis gestoor word. Vandaar die eenvoudige waarheid: wat nie in die logs is nie, is heel waarskynlik in die databasis. Maar hierdie is ook nie 'n silwer koeël nie: sommige dinge is nie in die plaaslike logboeke van Veeam-komponente nie, en ook nie in sy databasis nie. Daarom moet u leer hoe om die gasheerlogboeke, die logboeke van die plaaslike masjien en die logboeke van alles wat by die rugsteun- en herstelproses betrokke is, te bestudeer. En dit gebeur ook dat die nodige inligting glad nie nêrens beskikbaar is nie. Dit is die manier.
Enkele voorbeelde van sulke API's
Hierdie lys is nie daarop gemik om buitengewoon volledig te wees nie, so dit is nie nodig om die uiteindelike waarheid daarin te soek nie. Die doel daarvan is slegs om die mees algemene derdeparty-API's en tegnologieë wat in ons produkte gebruik word, te wys.
Kom ons begin met VMware.
Eerste op die lys sal wees vSphere API. Word gebruik vir verifikasie, lees van die hiërargie, skep en verwyder kiekies, versoek inligting oor masjiene, en nog baie (baie) meer. Die funksionaliteit van die oplossing is baie wyd, so ek kan die VMware vSphere API Reference vir die weergawe aanbeveel и . Vir meer huidige weergawes word alles net gegoogle.
VIX API. Die swart magie van die hypervisor, waarvoor daar 'n aparte . VMware API om met lêers op die gasheer te werk sonder om aan hulle oor die netwerk te koppel. 'n Variant van laaste uitweg wanneer jy 'n lêer in 'n masjien moet plaas waarheen daar geen beter kommunikasiekanaal is nie. Dit is pyn en lyding as die lêer groot is en die gasheer is gelaai. Maar hier werk die reël dat selfs 56,6 Kb/s beter is as 0 Kb/s. In Hyper-V word hierdie ding PowerShell Direct genoem. Maar dit was eers voorheen
vSpehere Web Services API Vanaf vSphere 6.0 (ongeveer sedert hierdie API die eerste keer op weergawe 5.5 bekendgestel is) word dit gebruik om met gasmasjiene te werk en het VIX byna oral vervang. Trouens, dit is nog 'n API vir die bestuur van vSphere. Vir diegene wat belangstel, beveel ek aan om te studeer handleiding.
VDDK (Virtual Disk Development Kit). Die biblioteek, wat gedeeltelik hierin bespreek is . Word gebruik om virtuele skywe te lees. Eens op 'n tyd was dit deel van die VIX, maar met verloop van tyd is dit na 'n aparte produk geskuif. Maar as 'n erfgenaam gebruik dit dieselfde foutkodes as VIX. Maar om een of ander rede is daar geen beskrywing van hierdie foute in die SDK self nie. Daarom is empiries uitgevind dat VDDK-foute met ander kodes net 'n vertaling van binêre na desimale kode is. Dit bestaan uit twee dele - die eerste helfte is ongedokumenteerde inligting oor die konteks, en die tweede deel is die tradisionele VIX / VDDK-foute. Byvoorbeeld, as ons sien:
VDDK error: 21036749815809.Unknown error
Dan skakel ons dit met vrymoedigheid om na hex en kry 132200000001. Ons gooi eenvoudig die oninsiggewende begin van 132200 weg, en die res sal ons foutkode wees (VDDK 1: Onbekende fout). Oor die mees algemene VDDK-foute was daar onlangs 'n aparte .
Laat ons nou kyk Vensters.
Hier kan alles wat vir ons die nodigste en belangrikste is, in die standaard gevind word Event ViewerMaar daar is een haakplek: volgens 'n lang tradisie Windows Dit teken nie die volledige foutteks aan nie, maar slegs die nommer daarvan. Byvoorbeeld, fout 5 beteken "Toegang geweier", 1722 beteken "Die RPC-bediener is nie beskikbaar nie", en 10060 beteken "Verbinding het 'n tydsverloop gehad". Natuurlik is dit wonderlik as jy die mees algemene foute onthou, maar wat van die foute wat jy nog nooit tevore gesien het nie?
En sodat die lewe glad nie soos heuning lyk nie, word foute ook in heksadesimale vorm gestoor, met die voorvoegsel 0x8007. Byvoorbeeld, 0x8007000e is eintlik 14, buite geheue. Waarom en vir wie dit gedoen is, is 'n raaisel wat in duisternis gehul is. 'n Volledige lys foute kan egter gratis en sonder SMS vanaf afgelaai word .
Terloops, soms is daar ander voorvoegsels, nie net 0x8007 nie. In so 'n hartseer situasie, om HRESULT (“resultaat hanteer”) te verstaan, moet jy nog dieper delf in vir ontwikkelaars. In die gewone lewe raai ek jou nie aan om dit te doen nie, maar as jy skielik teen die muur gedruk het of net nuuskierig is, weet jy nou wat om te doen.
Maar die kamerade by Microsoft het hulle 'n bietjie oor ons ontferm en die wêreld 'n nut gewys . Dit is 'n klein stukkie konsole-geluk wat foutkodes in menslike kan vertaal sonder om Google te gebruik. Dit werk so.
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"'n Regmatige vraag ontstaan: hoekom skryf ons nie dadelik die dekripsie aan die logs nie, maar laat hierdie geheimsinnige kodes? Die antwoord is in derdeparty-toepassings. Wanneer jy self 'n WinAPI-oproep trek, is dit nie moeilik om die reaksie daarvan te ontsyfer nie, want daar is selfs 'n spesiale WinAPI-oproep hiervoor. Maar soos reeds genoem, kom alles wat net na ons toe kom in antwoorde in ons logs. En hier, om dit te dekripteer, sou 'n mens hierdie stroom van bewussyn voortdurend moes monitor, stukke met Windows-foute daaruit moet uittrek, dit dekripteer en terugplak. Kom ons wees eerlik, nie die opwindendste aktiwiteit nie.
Windows Lêerbestuur-API op elke moontlike manier gebruik wanneer daar met lêers gewerk word. Die skep van lêers, uitvee, oopmaak vir skryf, werk met eienskappe, ensovoorts, ensovoorts.
bogenoemde PowerShell Direct as 'n analoog van die VIX API in die Hyper-V wêreld. Ongelukkig nie so buigsaam nie: baie beperkings op funksionaliteit, dit werk nie met elke weergawe van die gasheer nie en nie met alle gaste nie.
RPC (Remote Procedure Call) Ek dink nie daar is 'n enkele persoon wat met WIndows gewerk het wat nie RPC-verwante foute gesien het nie. Ten spyte van die gewilde wanopvatting, is dit nie 'n enkele protokol nie, maar enige kliënt-bediener protokol wat aan 'n aantal parameters voldoen. As daar egter 'n RPC-fout in ons logs is, sal dit 90% van die tyd 'n fout wees van Microsoft RPC, wat deel is van DCOM (Distributed Component Object Model). U kan 'n groot hoeveelheid dokumentasie oor hierdie onderwerp op die internet vind, maar die grootste deel daarvan is redelik verouderd. Maar as daar 'n akute begeerte is om die onderwerp te bestudeer, kan ek artikels aanbeveel , en lang lys .
Die hoofoorsake van RPC-foute in ons logs is mislukte pogings om te kommunikeer tussen VBR-komponente (bediener > proxy, byvoorbeeld) en meestal as gevolg van kommunikasieprobleme.
Die boonste top onder alle tops is die fout Die RPC-bediener is nie beskikbaar nie (1722). In eenvoudige terme kon die kliënt nie 'n verbinding met die bediener bewerkstellig nie. Hoe en hoekom - daar is geen enkele antwoord nie, maar gewoonlik is dit 'n probleem met verifikasie of met netwerktoegang tot poort 135. Laasgenoemde is tipies vir infrastruktuur met dinamiese poorttoewysing. Oor hierdie onderwerp is daar selfs . En Microsoft het om die oorsaak van die mislukking te vind.
Tweede gewildste fout: Daar is nie meer eindpunte beskikbaar vanaf die eindpuntkartering nie (1753). Die RPC-kliënt of -bediener kon nie vir homself 'n poort toewys nie. Kom gewoonlik voor wanneer die bediener (in ons geval, die gasmasjien) gekonfigureer is om poorte dinamies toe te ken vanaf 'n nou reeks wat geëindig het. En as jy van die kliënt se kant af aanmeld (in ons geval, die VBR-bediener), beteken dit dat ons VeeamVssAgent óf nie begin het nie óf nie as 'n RPC-koppelvlak geregistreer is nie. Daar is ook oor hierdie onderwerp .
Wel, om die Top 3 RPC-foute te voltooi, laat ons onthou dat RPC-funksieoproep misluk het (1726). Verskyn as die verbinding tot stand gebring is, maar RPC-versoeke word nie verwerk nie. Ons versoek byvoorbeeld inligting oor die status van VSS (skielik word daar op die oomblik 'n skadumyn gemaak, en ons probeer klim), en in reaksie op ons, stil en ignoreer.
Windows Bandrugsteun-API nodig om met bandbiblioteke of aandrywers te werk. Soos ek aan die begin genoem het: ons het geen plesier om ons eie drywers te skryf en dan te ly met die ondersteuning van elke toestel nie. Daarom het vim nie enige drywers van sy eie nie. Alles deur 'n standaard API, waarvan die ondersteuning deur die hardeware verskaffers self geïmplementeer word. Soveel meer logies, reg?
SMB / CIFS Almal skryf hulle uit gewoonte saam, alhoewel nie almal onthou dat CIFS (Common Internet File System) bloot 'n eie weergawe van SMB (Server Message Block) is nie. Daar is dus niks verkeerd met die veralgemening van hierdie konsepte nie. Samba, aan die ander kant, is LinuxDit is 'n Unix-implementering, en dit het sy eie eienaardighede, maar ek dwaal af. Wat hier belangrik is, is dat wanneer Veeam versoek om iets na 'n UNC-pad (bedienergids) te skryf, die bediener 'n hiërargie van lêerstelseldrywers, insluitend mup en mrxsmb, gebruik om na die gedeelde skyf te skryf. Gevolglik sal hierdie drywers ook foute genereer.
Kan nie sonder Winsock APIAs iets oor die netwerk gedoen moet word, werk VBR deur Windows Socket API, algemeen bekend as Winsock. So as ons 'n IP:Poort-verbinding in die logboek sien, is dit dit. Die amptelike dokumentasie het 'n goeie lys van moontlike .
bogenoemde WMI (Windows Bestuursinstrumentasie is 'n soort almagtige API vir die bestuur van alles en almal in die wêreld. WindowsByvoorbeeld, wanneer jy met Hyper-V werk, word byna alle versoeke aan die gasheer daardeur verwerk. Kortom, dit is absoluut onontbeerlik en baie kragtig. Die ingeboude WBEMtest.exe-instrument is baie nuttig wanneer jy probeer uitvind wat foutief is.
En laaste op die lys, maar geensins die minste in belangrikheid nie - VSS (Volume Shadow Berging). Die onderwerp is so onuitputlik en geheimsinnig soos wat baie dokumentasie daaroor geskryf is. Shadow Copy word die eenvoudigste verstaan as 'n spesiale tipe momentopname, wat dit in wese is. Danksy hom kan jy toepassing-konsekwente rugsteun in VMware maak, en byna alles in Hyper-V. Ek het planne om 'n aparte artikel met 'n bietjie druk op VSS te maak, maar vir eers kan jy probeer om te lees . Wees net versigtig, want. om VSS in 'n japtrap te probeer verstaan, kan tot breinbesering lei.
Hieroor kan ons miskien stop. Ek beskou die taak om die mees basiese dinge te verduidelik as afgehandel, so in die volgende hoofstuk sal ons reeds na die logs kyk. Maar as jy enige vrae het, vra dit gerus in die kommentaar.
Bron: will.com
