Vi fortsætter vores dyk ind i den fascinerende verden af logg... troubleshooting. I har vi aftalt betydningen af grundlæggende termer og kort kigget på den overordnede struktur i Veeam som en samlet applikation. Opgaven for denne gang er at forstå, hvordan logfiler dannes, hvilken information der vises i dem, og hvorfor de ser ud, som de gør.
Hvad tænker I overhovedet, hvad er disse „logs“? De fleste mener, at logfilerne fra enhver applikation skal have rollen som en slags allmægtig entitet, der det meste af tiden ligger gemt i baggrunden, men i det rigtige øjeblik dukker op fra ingenting i strålende rustninger og redder alle. Det vil sige, de skal indeholde alt fra de mindste fejl i hver komponent til individuelle database-transaktioner. Og efter en fejl skal der straks skrives, hvordan man kan rette det. Og alt dette skal kunne være i et par megabyte, højst. Det er jo bare tekst! Tekstfiler kan ikke fylde dusinvis af gigabyte, jeg har hørt det et sted!
Så, logs
I den virkelige verden er logs blot arkiver af diagnostisk information. Og hvad der skal opbevares, hvor informationen skal hentes fra, og hvor detaljeret den skal være, bestemmer udviklerne selv. Nogle går minimalistisk til værks og gemmer kun VÆGT/AF-værdier, mens andre flittigt samler alt, hvad de kan nå. Der er også en mellemvej med muligheden for at vælge såkaldt Logging Level, hvor du selv angiver, hvor detaljeret information du ønsker at gemme, og hvor meget unødvendig plads du har på dine diske =) VBR har i alt seks af disse niveauer, for at sige det sådan. Og tro mig, du vil ikke se, hvad der sker ved maksimal detaljeringsgrad med ledig plads på din disk.
Godt. Vi har nogenlunde forstået, hvad vi vil gemme, men det rejser det legitime spørgsmål: hvor skal vi hente disse oplysninger fra? Nogle af de hændelser, vi logger, bliver naturligvis genereret af vores interne processer. Men hvad skal man gøre, når der er interaktion med et eksternt miljø? For ikke at ende i en kaotisk situation med krampeløsninger og improvisationer, har Veeam en tendens til ikke at genopfinde den dybe tallerken. Altid, når der allerede findes et API, en indbygget funktion i systemet, et bibliotek osv., vil vi prioritere de eksisterende løsninger, før vi begynder at bygge vores egen komplicerede løsninger. Selvom der er mange af dem også. Derfor er det vigtigt at forstå, at en stor del af fejlene stammer fra meddelelser fra eksterne API'er, systemopkald og andre biblioteker. I dette tilfælde går VBR's rolle ud på at videresende disse fejl til logfilerne, som de er. Den primære opgave for brugeren er at lære at forstå, hvilken linje kommer fra hvem, og hvad denne “ hvem” har ansvaret for. Så hvis fejlkoden i VBR-loggen fører dig til en side på MSDN, er det helt normalt og korrekt.
Som vi sagde tidligere: Veeam er en såkaldt SQL-baseret applikation. Det betyder, at alle indstillinger, alle oplysninger og generelt alt, hvad der er nødvendigt for en normal drift, opbevares i databasen. Heraf den enkle sandhed: det, der ikke findes i loggene, er sandsynligvis i databasen. Men det er ikke en sølvkugle: visse oplysninger findes hverken i Veeam-komponenternes lokale logs eller i databasen. Derfor skal man lære at studere værtslogger, logs fra den lokale maskine og logs fra alt, hvad der deltager i backup- og gendannelsesprocessen. Nogle gange er der faktisk slet ingen ønskede oplysninger at finde. Sådan er vejen.
Nogle eksempler på sådanne API'er
Denne liste har ikke som mål at være fuldkommen, så lad være med at lede efter den sidste sandhed her. Dens opgave er blot at vise de mest almindelige tredjeparts API'er og teknologier, der bruges i vores produkter.
Lad os starte med VMware.
Først på listen er vSphere API. Det bruges til autentificering, læsning af hierarkiet, oprettelse og sletning af snapshots, forespørgsel af oplysninger om maskiner og meget (meget meget) andet. Løsningens funktionalitet er meget bred, så jeg kan anbefale VMware vSphere API Reference for versionen og . For mere aktuelle versioner er det bare at søge på Google.
VIX API. Den sorte magi ved hypervisoren, som har en særskilt . VMware API til at arbejde med filer på værten uden at være tilsluttet dem over netværket. En sidste udvej, når man skal lægge en fil på en maskine, som man ikke har bedre forbindelser til. Det kan være en smerte, hvis filen er stor, og værten er belastet. Men her gælder reglen, at selv 56,6 Kb/s er bedre end 0 Kb/s. I Hyper-V kaldes en lignende funktion PowerShell Direct. Men det var kun indtil
vSpehere Web Services API Fra og med vSphere 6.0 ( cirka, da dette API først blev præsenteret i version 5.5) anvendes det til at arbejde med gæstemaskiner og har næsten helt erstattet VIX. I bund og grund er det endnu et API til at styre vSphere. Dem, der er interesserede, kan jeg anbefale at studere manual.
VDDK (Virtual Disk Development Kit). Et bibliotek, som delvist blev nævnt i denne . Det bruges til at læse virtuelle diske. Engang var det en del af VIX, men er med tiden blevet udskilt som et separat produkt. Dog bruger det som arving de samme fejlkoder som VIX. Men af en eller anden grund er der ingen beskrivelse af disse fejl i selve SDK'en. Derfor er det blevet konstateret gennem erfaring, at VDDK-fejl med andre koder blot er oversættelse fra binær til decimal kode. Består af to dele - den første halvdel er udocumenteret information om konteksten, og den anden del er traditionelle VIX/VDDK fejl. For eksempel, hvis vi ser:
VDDK error: 21036749815809.Unknown error
Så konverterer vi dette til hex og får 132200000001. Den uinformerende begyndelse 132200 foreslår vi bare at ignorere, og resten vil være vores fejlkode (VDDK 1: Unknown error). Om de mest almindelige VDDK-fejl var der for nylig lavet en særskilt .
Nu lader os se på Windows.
Her kan vi finde alt det, der er nødvendigt og vigtigt for os i den standard Event Viewer. Men der er et problem: ifølge en gammel tradition logger Windows ikke den fulde fejlmeddelelse, men kun dens nummer. For eksempel er fejl 5 - 'Adgang nægtet', og 1722 - 'RPC-serveren er utilgængelig', og 10060 - 'Forbindelsen timed out'. Det er selvfølgelig godt, hvis du kan huske de mest kendte, men hvordan med de hidtil usete?
Og for at livet ikke skal virke som en konstant honningdrøm, opbevares fejl også i hexadecimalt format med prefix 0x8007. For eksempel, 0x8007000e — det betyder faktisk 14, Out of Memory. Hvorfor og for hvem det blev gjort — er en gåde dækket af mørke. Dog kan den fulde liste over fejl downloades gratis og uden SMS fra .
Forresten, nogle gange er der også andre præfikser end blot 0x8007. I sådan en trist situation skal du dykke endnu dybere ned i for udviklere. I det daglige liv vil jeg ikke anbefale dig at gøre det, men hvis du pludselig er presset mod væggen eller bare er nysgerrig, så ved du nu, hvad du skal gøre.
Men folkene hos Microsoft viste noget medfølelse over for os og præsenterede en nyttig værktøj . Dette er et lille stykke konsollykke, der kan oversætte fejlkoder til menneskelig forståelse uden brug af Google. Den fungerer omtrent sådan her.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# En intern fejl opstod.
# som en HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# En intern fejl opstod.
# 2 matches found for "0x54f"Der opstår det legitime spørgsmål: hvorfor skriver vi ikke straks oversættelsen i loggene, men efterlader disse mystiske koder? Svaret ligger i tredjepartsapplikationer. Når du selv kalder en WinAPI-funktion, er det ikke en udfordring at oversætte dens svar, da der endda findes en særlig WinAPI-funktion til det. Men som tidligere nævnt, havner alt, hvad vi får i svarene, i vores logs. Og her måtte vi konstant overvåge denne bevidsthedsstrøm, trække de dele med Windows-fejl ud, oversætte dem og indsætte dem tilbage. Lad os være ærlige, det er ikke den mest underholdende aktivitet.
Windows File Management API bliver flittigt brugt til at arbejde med filer. Oprettelse af filer, sletning, åbning til skrivning, arbejde med attributter og meget mere.
Den nævnte ovenfor PowerShell Direct som en analog til VIX API i Hyper-V verdenen. Desværre ikke så fleksibel: mange funktionalitetsbegrænsninger, fungerer ikke med hver værtversion og heller ikke med alle gæster.
RPC (Remote Procedure Call) Jeg tror, at der ikke er én person, der har arbejdet med Windows, som ikke har set fejl relateret til RPC. På trods af den udbredte misforståelse er det ikke en enkelt protokol, men enhver klient-server protokol, der opfylder en række parametre. Men hvis vi har en RPC-fejl i vores logs, vil det i 90% af tilfældene være en fejl fra Microsoft RPC, som er en del af DCOM (Distributed Component Object Model). Der findes en overflod af dokumentation om dette emne online, men meget af den er ret forældet. Hvis du dog har en stærk trang til at studere emnet, kan jeg anbefale artikler. , og en lang liste .
De primære årsager til, at RPC-fejl opstår i vores logs, er mislykkede forsøg på interaktion mellem VBR-komponenter (server > proxy, for eksempel) og oftest på grund af kommunikationsproblemer.
Topfejlen blandt alle fejl er fejlmeddelelsen The RPC server is unavailable (1722). For at sige det enkelt, så kunne klienten ikke etablere forbindelse til serveren. Hvordan og hvorfor – der er ikke et entydigt svar, men det er normalt et problem med autentificering eller netværksadgang til port 135. Det sidste er typisk for infrastrukturer med dynamisk portallokering. Der er endda en . Og Microsoft har et til fejlfinding af problemer.
Den næst mest almindelige fejl: There are no more endpoints available from the endpoint mapper (1753). RPC-klienten eller serveren kunne ikke tildele en port til sig selv. Dette opstår typisk, når serveren (i vores tilfælde den virtuelle maskine) er konfigureret til dynamisk portallokering fra et snævert interval, som er opbrugt. Hvis vi ser på det fra klientens side (i vores tilfælde VBR-serveren), betyder det, at vores VeeamVssAgent ikke er startet, eller ikke er blevet registreret som RPC-interface. Der er også artikler om dette. .
Og for at afslutte Top-3 RPC-fejlene, lad os nævne RPC function call failed (1726). Denne fejl opstår, hvis forbindelsen er etableret, men RPC-anmodningerne ikke går igennem. For eksempel, hvis vi anmoder om information om VSS-status (hvis der lige nu tages en skyggekopi, og vi forsøger at få adgang til det), men vi får stilhed og bliver ignoreret.
Windows Tape Backup API er nødvendigt for arbejde med båndbiblioteker eller drev. Som jeg nævnte i starten: det er ikke særlig sjovt at skrive sine egne drivere og så kæmpe med at støtte hver enhed. Derfor har Veeam ikke sine egne drivere. Alt går gennem en standard API, som hardwareleverandørerne selv implementerer. Det giver meget mere mening, ikke?
SMB/CIFS Alle skriver dem tæt på hinanden af vane, selvom ikke alle husker, at CIFS (Common Internet File System) bare er en privat version af SMB (Server Message Block). Så der er intet dårligt i at forenkle disse begreber. Samba er allerede Linux/Unix-implementeringen, og der er nogle specifikke detaljer, men det er jeg blevet distraheret af. Hvad der er vigtigt her: når Veeam beder om at skrive noget til en UNC-sti (serverdirectory), bruger serveren hierarkiet af filsystemdrivere, inklusive mup og mrxsmb, til at skrive til delingen. Følgelig vil disse drivere også generere fejl.
Man kan på ingen måde undvære Winsock API. Hvis der skal gøres noget over netværket, virker VBR gennem Windows Socket API, kendt som Winsock. Så hvis vi ser IP:Port linket i loggen, er det dét. I den officielle dokumentation er der en god liste over mulige .
Den nævnte ovenfor WMI (Windows Management Instrumentation) er et altomfattende API til at styre alt og alle i Windows-verdenen. For eksempel, når man arbejder med Hyper-V, sker næsten alle forespørgsler til værten netop gennem det. Kort sagt, det er helt uundgåeligt og meget kraftfuldt i sine muligheder. I forsøg på at hjælpe med at finde ud af, hvor og hvad der er gået galt, hjælper det indbyggede værktøj WBEMtest.exe meget.
Og den sidste på listen, men absolut ikke den mindste i betydning — VSS (Volume Shadow Storage). Emnet er så ubegribelig og mystisk, som der er skrevet meget dokumentation om. Shadow Copy kan bedst forstås som en særlig type snapshot, som den i bund og grund er. Takket være det kan man i VMware lave applikationskonsistente backups, og i Hyper-V kan man faktisk gøre næsten alt. Jeg har planer om at lave en separat artikel med en slags resumé om VSS, men indtil videre kan du prøve at læse . Bare vær forsigtig, da et forsøg på at forstå VSS hurtigt kan føre til hjernerystelser.
På dette punkt kan vi vel stoppe. Jeg anser opgaven med at forklare de mest grundlæggende ting for fuldført, så i det næste kapitel ser vi på loggene. Men hvis der er spørgsmål, så tøv ikke med at stille dem i kommentarerne.
Kilde: habr.com
