We gaan door met onze onderdompeling in de fascinerende wereld van gissen ... probleemoplossing aan de hand van logboeken. IN we waren het eens over de betekenis van de basistermen en keken met één oog naar de algehele structuur van Veeam als één applicatie. De taak voor deze is om erachter te komen hoe logbestanden worden gevormd, wat voor soort informatie erin wordt weergegeven en waarom ze eruit zien zoals ze eruit zien.
Wat denk je dat deze "logs" zijn? Volgens de meesten zouden de logboeken van elke applicatie de rol moeten krijgen van een soort almachtige entiteit die meestal ergens in de achtertuin vegeteert, maar op het juiste moment uit het niets verschijnt in glanzend pantser en iedereen redt. Dat wil zeggen, ze zouden alles moeten bevatten, van de kleinste fouten in elk onderdeel tot individuele databasetransacties. En zodat na de fout meteen werd geschreven hoe het anders moest worden opgelost. En dit alles zou in een paar megabytes moeten passen, niet meer. Het is maar tekst! Tekstbestanden kunnen geen tientallen gigabytes aan, ik heb het ergens gehoord!
De logboeken dus
In de echte wereld zijn logboeken slechts een archief met diagnostische informatie. En wat daar moet worden opgeslagen, waar informatie voor opslag kan worden verkregen en hoe gedetailleerd deze moet zijn, is aan de ontwikkelaars zelf om te beslissen. Iemand volgt het pad van minimalisme door records bij te houden van het AAN / UIT-niveau, en iemand harkt ijverig alles wat ze kunnen bereiken. Al is er ook een tussenliggende optie met de mogelijkheid om het zogenaamde Logging Level te selecteren, wanneer je zelf aangeeft hoe gedetailleerd informatie je wilt opslaan en hoeveel extra schijfruimte je hebt =) VBR heeft overigens zes van dergelijke niveaus. En geloof me, je wilt niet zien wat er gebeurt met de meest gedetailleerde logging met vrije ruimte op je schijf.
Prima. We hebben ongeveer begrepen wat we willen opslaan, maar een legitieme vraag rijst: waar halen we deze informatie vandaan? Natuurlijk maken we deel uit van de gebeurtenissen om onszelf te loggen door onze interne processen. Maar wat te doen als er een interactie is met de externe omgeving? Om niet in een hel van krukken en fietsen te glijden, heeft Veeam de neiging om geen uitvindingen uit te vinden die al zijn uitgevonden. Telkens wanneer er een kant-en-klare API, ingebouwde functie, bibliotheek, enz. Is, geven we de voorkeur aan kant-en-klare opties voordat we beginnen met het afschermen van onze constructies. Hoewel dat laatste ook voldoende is. Daarom is het bij het analyseren van logboeken belangrijk om te begrijpen dat het leeuwendeel van de fouten wordt veroorzaakt door berichten van API's van derden, systeemaanroepen en andere bibliotheken. In dit geval komt de rol van VBR neer op het doorsturen van deze fouten naar de as is-logbestanden. En de belangrijkste taak van de gebruiker is om te leren begrijpen welke regel van wie is en waarvoor deze "wie" verantwoordelijk is. Dus als een foutcode uit het VBR-logboek u naar een MSDN-pagina leidt, is dat prima en correct.
Zoals eerder afgesproken: Veeam is een zogenaamde SQL-gebaseerde applicatie. Dit betekent dat alle instellingen, alle informatie en in het algemeen alles wat alleen nodig is voor normaal functioneren - alles wordt opgeslagen in de database. Vandaar de simpele waarheid: wat niet in de logs staat, staat hoogstwaarschijnlijk in de database. Maar ook dit is geen wondermiddel: sommige dingen staan niet in de lokale logboeken van Veeam-componenten, noch in de database ervan. Daarom moet u leren hoe u de hostlogboeken, de logboeken van de lokale machine en de logboeken van alles wat bij het back-up- en herstelproces betrokken is, kunt bestuderen. En het komt ook voor dat de benodigde informatie nergens beschikbaar is. Dat is de manier.
Enkele voorbeelden van dergelijke API's
Deze lijst beoogt niet uitzonderlijk volledig te zijn, dus het is niet nodig om hierin naar de ultieme waarheid te zoeken. Het doel is alleen om de meest voorkomende API's en technologieën van derden weer te geven die in onze producten worden gebruikt.
Laten we beginnen VMware.
De eerste op de lijst zal zijn vSphere-API. Wordt gebruikt voor authenticatie, het lezen van de hiërarchie, het maken en verwijderen van snapshots, het opvragen van informatie over machines en nog veel (heel veel) meer. De functionaliteit van de oplossing is erg breed, dus ik kan de VMware vSphere API Reference voor de versie aanbevelen и . Voor meer actuele versies wordt alles gewoon gegoogeld.
VIX-API. De zwarte magie van de hypervisor, waarvoor een aparte . VMware API voor het werken met bestanden op de host zonder er via het netwerk verbinding mee te maken. Een laatste redmiddel wanneer u een bestand in een machine moet plaatsen waar geen beter communicatiekanaal voor is. Het is pijn en lijden als het bestand groot is en de host is geladen. Maar hier werkt de regel dat zelfs 56,6 Kb/s beter is dan 0 Kb/s. In Hyper-V wordt dit ding PowerShell Direct genoemd. Maar dat was alleen vroeger
vSpehere Web Services-API Vanaf vSphere 6.0 (ongeveer, aangezien deze API voor het eerst werd geïntroduceerd op versie 5.5) wordt het gebruikt om met gastmachines te werken en heeft het VIX bijna overal verdrongen. In feite is dit een andere API voor het beheer van vSphere. Voor degenen die geïnteresseerd zijn, raad ik aan om te studeren handmatig.
VDDK (Ontwikkelingskit voor virtuele schijven). De bibliotheek, die hierin gedeeltelijk aan de orde kwam . Wordt gebruikt om virtuele schijven te lezen. Ooit maakte het deel uit van de VIX, maar na verloop van tijd werd het verplaatst naar een apart product. Maar als erfgenaam gebruikt het dezelfde foutcodes als VIX. Maar om de een of andere reden is er geen beschrijving van deze fouten in de SDK zelf. Daarom werd empirisch ontdekt dat VDDK-fouten met andere codes slechts een vertaling zijn van binaire naar decimale code. Het bestaat uit twee delen - de eerste helft is ongedocumenteerde informatie over de context en het tweede deel is de traditionele VIX / VDDK-fouten. Als we bijvoorbeeld zien:
VDDK error: 21036749815809.Unknown error
Dan zetten we dit stoutmoedig om in hex en krijgen we 132200000001. We negeren gewoon het niet-informatieve begin van 132200, en de rest is onze foutcode (VDDK 1: Onbekende fout). Over de meest voorkomende VDDK-fouten was er onlangs nog een aparte .
Laten we nu eens kijken naar Ramen.
Hier vindt u alles wat voor ons het meest noodzakelijk en belangrijk is in de norm event Viewer. Maar er is één addertje onder het gras: volgens een lange traditie registreert Windows niet de volledige tekst van de fout, maar alleen het nummer ervan. Fout 5 is bijvoorbeeld "Toegang geweigerd", en 1722 is "De RPC-server is niet beschikbaar", en 10060 is "Time-out verbinding". Het is natuurlijk geweldig als je je de beroemdste herinnert, maar hoe zit het met de tot nu toe ongeziene?
En zodat het leven helemaal niet als honing lijkt, worden fouten ook in hexadecimale vorm opgeslagen, met het voorvoegsel 0x8007. 0x8007000e is bijvoorbeeld eigenlijk 14, onvoldoende geheugen. Waarom en voor wie dit is gedaan, is een in duisternis gehuld mysterie. Een volledige lijst met fouten kan echter gratis en zonder sms worden gedownload .
Trouwens, soms zijn er andere voorvoegsels, niet alleen 0x8007. In zo'n trieste situatie moet je, om HRESULT ("resultaathandvat") te begrijpen, nog dieper ingaan voor ontwikkelaars. In het gewone leven raad ik je dit niet aan, maar als je plotseling tegen de muur drukt of gewoon nieuwsgierig bent, weet je nu wat je moet doen.
Maar de kameraden bij Microsoft hadden een beetje medelijden met ons en toonden de wereld een hulpprogramma . Dit is een klein stukje consolegeluk dat foutcodes in mensen kan vertalen zonder Google te gebruiken. Het werkt zo.
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"Een legitieme vraag rijst: waarom schrijven we de decodering niet meteen naar de logs, maar laten we deze mysterieuze codes achter? Het antwoord is in toepassingen van derden. Wanneer je zelf een WinAPI-aanroep trekt, is het niet moeilijk om de respons te ontcijferen, omdat hier zelfs een speciale WinAPI-aanroep voor is. Maar zoals eerder vermeld, komt alles wat alleen in reacties bij ons binnenkomt in onze logboeken. En hier, om het te decoderen, zou je constant deze bewustzijnsstroom moeten volgen, er stukken met Windows-fouten uit moeten halen, ze moeten decoderen en terugplakken. Laten we eerlijk zijn, niet de meest opwindende bezigheid.
Windows Bestandsbeheer-API op alle mogelijke manieren gebruikt bij het werken met bestanden. Bestanden maken, verwijderen, openen om te schrijven, werken met attributen, enzovoort, enzovoort.
hierboven vermeld PowerShell Direct als een analoog van de VIX API in de Hyper-V-wereld. Helaas niet zo flexibel: veel beperkingen op functionaliteit, het werkt niet met elke versie van de host en niet met alle gasten.
RPC (Remote Procedure Call) Ik denk niet dat er één persoon is die met Windows heeft gewerkt die geen RPC-gerelateerde fouten heeft gezien. Ondanks de populaire misvatting is dit geen enkel protocol, maar elk client-serverprotocol dat aan een aantal parameters voldoet. Als er echter een RPC-fout in onze logboeken staat, is dit in 90% van de gevallen een fout van Microsoft RPC, dat deel uitmaakt van DCOM (Distributed Component Object Model). U kunt een enorme hoeveelheid documentatie over dit onderwerp op internet vinden, maar het leeuwendeel ervan is behoorlijk verouderd. Maar als er een acuut verlangen is om het onderwerp te bestuderen, dan kan ik artikelen aanbevelen , en lange lijst .
De belangrijkste oorzaken van RPC-fouten in onze logboeken zijn mislukte pogingen om te communiceren tussen VBR-componenten (bijvoorbeeld server > proxy) en meestal door communicatieproblemen.
De bovenste van alle toppen is de fout De RPC-server is niet beschikbaar (1722). Simpel gezegd, de client kon geen verbinding maken met de server. Hoe en waarom - er is geen eenduidig antwoord, maar meestal is het een probleem met authenticatie of met netwerktoegang tot poort 135. Dit laatste is typerend voor infrastructuren met dynamische poorttoewijzing. Over dit onderwerp is er zelfs . En Microsoft heeft om de oorzaak van de storing te vinden.
Tweede meest voorkomende fout: er zijn geen eindpunten meer beschikbaar via de eindpunttoewijzer (1753). De RPC-client of -server kan zichzelf geen poort toewijzen. Komt meestal voor wanneer de server (in ons geval de gastmachine) is geconfigureerd om dynamisch poorten toe te wijzen uit een smal bereik dat is geëindigd. En als u zich aanmeldt vanaf de clientzijde (in ons geval de VBR-server), betekent dit dat onze VeeamVssAgent niet is gestart of niet is geregistreerd als een RPC-interface. Er is ook over dit onderwerp .
Om de top 3 RPC-fouten te voltooien, onthouden we dat RPC-functieaanroep is mislukt (1726). Verschijnt als de verbinding tot stand is gebracht, maar RPC-verzoeken niet worden verwerkt. We vragen bijvoorbeeld informatie over de status van VSS (plotseling wordt daar nu een schaduwmijn gemaakt en we proberen te klimmen), en als reactie op ons, zwijgen en negeren.
Windows Tape Back-up-API nodig om met bandbibliotheken of stations te werken. Zoals ik in het begin al zei: we hebben er geen plezier in om onze eigen stuurprogramma's te schrijven en vervolgens te lijden onder de ondersteuning van elk apparaat. Daarom heeft vim geen eigen stuurprogramma's. Allemaal via een standaard API, waarvan de ondersteuning wordt geïmplementeerd door de hardwareleveranciers zelf. Zoveel logischer toch?
SMB / CIFS Uit gewoonte schrijft iedereen ze naast elkaar, hoewel niet iedereen zich herinnert dat CIFS (Common Internet File System) slechts een privéversie is van SMB (Server Message Block). Er is dus niets mis met het generaliseren van deze concepten. Samba is al een LinuxUnix-implementatie en heeft zijn eigen bijzonderheden, maar ik dwaal af. Wat hier belangrijk is: wanneer Veeam vraagt om iets naar het UNC-pad (serverdirectory) te schrijven, gebruikt de server de hiërarchie van stuurprogramma's voor het bestandssysteem, inclusief mup en mrxsmb, om naar de bal te schrijven. Dienovereenkomstig zullen deze stuurprogramma's ook fouten genereren.
Kan niet zonder Winsock-API. Als er iets via het netwerk moet worden gedaan, werkt VBR via de Windows Socket API, in de volksmond bekend als Winsock. Dus als we een heleboel IP:Port in het logboek zien, is dit het. De officiële documentatie heeft een goede lijst van mogelijke .
hierboven vermeld WMI (Windows Management Instrumentation) is een soort almachtige API om alles en iedereen in de Windows-wereld te beheren. Als u bijvoorbeeld met Hyper-V werkt, gaan bijna alle verzoeken aan de host er doorheen. Kortom, het ding is absoluut onvervangbaar en zeer krachtig in zijn mogelijkheden. In een poging om erachter te komen waar en wat er kapot is, helpt de ingebouwde WBEMtest.exe-tool veel.
En als laatste op de lijst, maar zeker niet het minst belangrijk - VSS (Volume Schaduwopslag). Het onderwerp is net zo onuitputtelijk en mysterieus als er zoveel documentatie over geschreven is. Schaduwkopie kan het eenvoudigst worden opgevat als een speciaal type momentopname, wat het in essentie ook is. Dankzij hem maak je applicatieconsistente back-ups in VMware, en bijna alles in Hyper-V. Ik heb plannen om een apart artikel te maken met wat druk op VSS, maar voor nu kun je proberen te lezen . Wees voorzichtig, want. VSS in een flits proberen te begrijpen kan leiden tot hersenletsel.
Hierop kunnen we misschien stoppen. Ik beschouw de taak van het uitleggen van de meest basale dingen als voltooid, dus in het volgende hoofdstuk zullen we al naar de logboeken kijken. Maar als je vragen hebt, stel ze dan gerust in de comments.
Bron: www.habr.com