Hos Veeam elsker vi logs. Og da de fleste af vores løsninger er modulære, skriver de en del logs. Og da omfanget af vores aktivitet er at sikre sikkerheden af dine data (dvs. afslappende søvn), bør logfilerne ikke kun registrere hvert nys, men også gøre det i nogle detaljer. Dette er nødvendigt, så hvis der sker noget, er det klart, hvordan dette "hvad" skete, hvem der har skylden, og hvad der skal gøres derefter. Det er ligesom i retsmedicin: du ved aldrig, hvilken lille ting der hjælper dig med at finde Laura Palmers morder.
Derfor besluttede jeg at lancere en serie artikler, hvor jeg konsekvent vil tale om, hvad vi skriver i logs, hvor vi opbevarer dem, hvordan man ikke skal gå amok med deres struktur, og hvad man skal kigge efter inde i dem.
Hvorfor en serie artikler og hvorfor ikke beskrive alt på én gang?
Blot at angive hvilken log der er placeret hvor og hvad der er gemt i den er en temmelig katastrofal idé. Og det er skræmmende overhovedet at tænke på at holde disse oplysninger opdateret. En simpel liste over alle mulige typer logfiler i Veeam Backup & Replication er en tabel med flere ark med småt. Og det vil kun være relevant på udgivelsestidspunktet, fordi... Når den næste patch frigives, kan nye logfiler dukke op, logikken for gemte informationer i gamle kan ændre sig osv. Derfor vil det være meget mere fordelagtigt at forklare deres struktur og essensen af informationen i dem. Dette vil give dig mulighed for bedre at navigere i steder end banal propfyldning af navne.
Derfor, for ikke at skynde sig hovedkulds ind i puljen af tekstark, lad os lave noget forberedende arbejde i denne artikel. Derfor vil vi i dag ikke dykke ned i selve logfilerne, men vil gå langvejs fra: vi vil kompilere en ordliste og diskutere lidt strukturen af Veeam fra synspunktet om at generere logfiler.
Ordliste og jargon
Her er det først og fremmest værd at undskylde for forkæmperne for det russiske sprogs renhed og vidnerne til Ozhegovs ordbog. Vi elsker alle vores modersmål meget, men den forbandede it-industri arbejder på engelsk. Nå, vi kom ikke frem til dette, men sådan skete det historisk. Det er ikke min skyld, han kom selv (c)
I vores forretning har problemet med anglicismer (og jargon) sine egne detaljer. Når hele verden med uskyldige ord som "vært" eller "gæst" længe har forstået meget specifikke ting, så fortsætter den heroiske forvirring og vandringen med at stikke i ordbøger på ⅙ af landet. Og det strengt obligatoriske argument "Men på vores arbejde ...".
Derudover er der udelukkende vores terminologi, som er iboende specifikt i Veeam-produkter, selvom nogle ord og sætninger er blevet populære. Derfor bliver vi nu enige om, hvilket udtryk betyder hvad, og i fremtiden vil jeg med ordet "gæst" mene præcis det, der står i dette kapitel, og ikke hvad du er vant til på arbejdet. Og ja, det er ikke mit personlige indfald, det er veletablerede termer i branchen. Det er lidt meningsløst at bekæmpe dem. Selvom jeg altid går ind for at være sød i kommentarerne.
Desværre er der mange termer og produkter i vores arbejde, så jeg vil ikke forsøge at liste dem alle sammen. Kun de mest basale oplysninger om backups og logfiler, der er nødvendige for overlevelse til søs. For de interesserede kan jeg også kolleger om feeds, hvor han også leverede en liste over termer relateret til den del af funktionaliteten.
Vært: I virtualiseringens verden er dette en maskine med en hypervisor. Fysisk, virtuel, sky - det er lige meget. Hvis noget kører en hypervisor (ESXi, Hyper-V, KVM osv.), så kaldes dette "noget" en vært. Uanset om det er en klynge med ti racks eller din bærbare computer med et laboratorium til halvanden virtuel maskine, hvis du lancerede en hypervisor, blev du vært. Fordi hypervisoren er vært for virtuelle maskiner. Der er endda en historie om, at VMware på et tidspunkt ønskede at opnå en fast association af ordet vært med ESXi. Men hun kunne ikke gøre det.
I den moderne verden er begrebet "vært" praktisk talt smeltet sammen med begrebet "server", hvilket bringer en vis forvirring til kommunikation, især når det kommer til Windows-infrastruktur. Så enhver maskine, hvor en tjeneste af interesse for os er placeret, kan roligt kaldes en vært. For eksempel i WinSock-logfiler er alt markeret med ordet vært. Klassikeren "Host not found" er et eksempel på dette. Så vi går ud fra konteksten, men husk - i virtualiseringens verden er værten det, der er vært for gæsterne (mere om disse to linjer nedenfor).
Fra lokal jargon (mere sandsynligt endda akronymer, i dette tilfælde), husker jeg, at VMware er VI, vSphere er VC, og Hyper-V er HV.
Gæst: En virtuel maskine, der kører på en vært. Der er ikke engang noget at forklare her, alt er så logisk og enkelt. Mange trækker dog flittigt nogle andre betydninger hertil.
For hvad? Jeg ved ikke.
Guest OS er henholdsvis gæstemaskinens operativsystem. Og så videre.
Sikkerhedskopiering/replikeringsjob (jobA): Ren Wim-jargon, der betegner en af opgaverne. Backup job == Backup job. Ingen har fundet ud af at oversætte dette smukt til russisk, så alle siger "jobA". Med vægt på sidste stavelse.
Ja, sådan går de bare og siger "joba". Og de skriver endda sådan med bogstaver, og alt er fint.
Alle former for backup-arbejde, backup-opgaver osv. tak, men ingen grund. Bare gør et arbejde, og de vil forstå dig. Det vigtigste er at lægge vægt på den sidste stavelse.
Backup (Backup, backup. For true-oldfags er BackUp tilladt): Ud over det åbenlyse (en sikkerhedskopi af de data, der ligger et sted), betyder det også selve jobbet (tre linjer ovenfor, hvis du allerede har glemt det), som et resultat af hvilket den samme sikkerhedskopifil vises. Sandsynligvis, mine herrer, engelsktalende er for dovne til at sige, at jeg kørte mit backup-job hver gang, så de siger bare, at jeg kørte min backup, og alle forstår hinanden perfekt. Jeg foreslår at støtte dette vidunderlige initiativ.
Konsolidere: Et udtryk, der dukkede op i ESXi 5.0 En mulighed i snapshot-menuen, der starter processen med at slette såkaldte forældreløse snapshots. Det vil sige snapshots, der er fysisk tilgængelige, men som er faldet ud af den viste logiske struktur. Teoretisk set burde denne proces ikke påvirke de filer, der vises i snapshot-manageren, men alt kan ske. Essensen af konsolideringsprocessen er, at data fra et snapshot (underordnet disk) skrives til den primære (overordnede) disk. Processen med at flette diske kaldes flette. Hvis der blev givet en konsolideringskommando, kan snapshot-posten slettes fra databasen, før snapshottet flettes og slettes. Og hvis øjebliksbilledet af en eller anden grund ikke kunne slettes, så dukker de samme forældreløse snapshots op. VMware har information om at arbejde med snapshots . Og vi taler også på en eller anden måde om dem .
Datalager (Stora eller hundredaj): Et meget bredt begreb, men i virtualiseringens verden refererer det til det sted, hvor virtuelle maskinfiler er gemt. Men under alle omstændigheder skal du meget tydeligt forstå sammenhængen og, hvis du er den mindste tvivl, præcisere, hvad din samtalepartner præcist mente.
Proxy: Det er vigtigt med det samme at forstå, at Veeam Proxy ikke er helt det samme, som vi er vant til på internettet. Inden for Veeam-produkter er dette en bestemt enhed, der er engageret i at overføre data fra et sted til et andet. Uden at gå i detaljer er VBR en kommandoserver, og proxyer er dens arbejdsheste. Det vil sige, at en proxy er en maskine, som trafikken flyder igennem, og hvorpå der er installeret VBR-komponenter, som hjælper med at styre denne trafik. For eksempel kan du overføre data fra en kanal til en anden eller blot vedhæfte diske til dig selv (HotAdd-tilstand).
Depot: Teknisk set er dette kun en indgang i VBR-databasen, der angiver den placering, hvor sikkerhedskopierne er gemt, og hvordan man forbinder til denne placering. Faktisk kan det enten være en CIFS-share eller en separat disk, server eller bucket i skyen. Igen er vi i kontekst, men vi forstår, at et repository blot er et sted, hvor dine backups er placeret.
Snapshot: Elskere af Oxford grammatik foretrækker at sige, hvem der er et øjebliksbillede, hvem der er et øjebliksbillede, men analfabeterne vinder på grund af den større masse. Hvis nogen ikke ved det, er dette en teknologi, der giver dig mulighed for at gendanne en disks tilstand på et bestemt tidspunkt. Dette gøres enten ved midlertidigt at omdirigere I/O-operationer væk fra hoveddisken - så vil dette blive kaldt RoW (Redirect on Write) snapshot - eller ved at flytte de genskrivbare blokke fra din disk til en anden - dette vil blive kaldt CoW (Kopier på Skriv) øjebliksbillede. Det er takket være de brede muligheder for at bruge disse funktioner, at Veeam kan udføre sin backup-magi. Strengt taget ikke kun for dem, men dette er et spørgsmål om kommende udgivelser.
I dokumentationen og ESXi logs er der kaos omkring dette udtryk, og i forbindelse med at nævne snapshots kan du finde selve snapshots, redo log og endda delta disk. Der er ingen sådan uenighed i Veeam-dokumentationen, og et øjebliksbillede er et øjebliksbillede, og en redo-log er præcis en REDO-fil, der er oprettet af en uafhængig ikke-vedvarende disk. REDO filer slettes, når den virtuelle maskine er slukket, så at forveksle dem med snapshots er en opskrift på fejl.
Syntetisk: Syntetiske sikkerhedskopier henviser til omvendte inkrementelle og evigt fremadrettede sikkerhedskopier. Hvis du ikke er stødt på dette udtryk, er det simpelthen en af de mekanismer, der bruges til at bygge en backup-kædetransformation. I loggene kan du dog også finde konceptet Transform, som bruges som led i at skabe hele kopier fra trin (syntetisk fuld).
Opgave: Dette er processen med at behandle hver enkelt maskine i et job. Det vil sige: du har et backupjob, der omfatter tre maskiner. Det betyder, at hver maskine vil blive behandlet inden for en separat opgave. I alt vil der være fire logs: Den primære til jobbet og tre til opgaverne. Der er dog en vigtig nuance: Med tiden er ordet "taska" blevet alt for tvetydigt. Når vi taler om generelle logfiler, mener vi, at opgaven er en VM. Men både proxyen og depotet har deres egne "opgaver". Der kan dette betyde en virtuel disk, en virtuel maskine eller hele jobbet. Det vil sige, at det er vigtigt ikke at miste konteksten.
Veeam %name% Service: Til gavn for vellykkede sikkerhedskopier fungerer flere tjenester på én gang, en liste over dem kan findes i standardudstyret. Deres navne afspejler deres essens ganske gennemsigtigt, men blandt ligestillede er der den vigtigste - Veeam Backup Service, uden hvilken resten ikke vil fungere.
VSS: Teknisk set bør VSS altid stå for Microsoft Volume Shadow Copy Service. Faktisk brugt af mange som et synonym for Application-Aware Image Processing. Hvilket selvfølgelig er kategorisk falsk, men dette er en historie fra kategorien "Enhver SUV kan kaldes en jeep, og de vil forstå dig."
Fantastiske træstammer og de steder, hvor de bor
Jeg vil starte dette kapitel med at afsløre en stor hemmelighed - hvad tid vises i loggene?
Husk:
- ESXi skriver altid logs i UTC+0.
- vCenter opbevarer logfiler baseret på tidspunktet for dets tidszone.
- Veeam fører logs baseret på tid og tidszone på den server, som den er installeret på.
- Og kun vindbegivenheder i EVTX-formatet lider ikke under at være bundet til noget. Ved åbning genberegnes tiden efter den maskine, de blev åbnet på. Den mest bekvemme mulighed, selvom der er vanskeligheder med det. Den eneste mærkbare vanskelighed er forskellen i lokaliteter. Dette er en næsten garanteret vej til ulæselige logfiler. Ja, der er muligheder for, hvordan man behandler dette, men lad os bare ikke argumentere med, at alt i IT fungerer på engelsk, og accepterer altid at indstille den engelske lokalitet på serverne. Åh, tak.
Lad os nu tale om de steder, hvor stokkene lever, og hvordan man får dem. I tilfældet med VBR er der to tilgange.
Mulighed XNUMX er velegnet, hvis du ikke er ivrig efter at lede efter filer i den generelle bunke, der relaterer specifikt til dit problem. Til dette har vi en separat guide, hvortil du kan angive et specifikt job og en bestemt periode, du skal bruge logfiler til. Dernæst vil han selv gennemgå mapperne og lægge alt, hvad han har brug for, i ét arkiv. Om hvor man skal lede efter det, og hvordan man arbejder med det, er det skrevet detaljeret i .
Guiden indsamler dog ikke logfiler fra alle opgaver, og hvis du for eksempel skal studere logfilerne for en restaurant, failover eller failback, ligger din sti i mappen %ProgramData%/Veeam/Backup. Dette er den primære VBR-loglagring, og %ProgramData% er en skjult mappe, og det er fint. Standardplaceringen kan i øvrigt omtildeles ved hjælp af en registreringsnøgle af typen REG_SZ: LogDirectory i grenen HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.
På Linux-maskiner skal logfiler for fungerende agenter findes i /var/log/VeeamBackup/, hvis du bruger en root- eller sudo-konto. Hvis du ikke har sådanne privilegier, så kig efter logs ind /tmp/VeeamBackup.
For Veeam-agent for %OS_name% skal der søges i logfiler %ProgramData%/Veeam/Endpoint (eller %ProgramData%/Veeam/Backup/Endpoint) Og /var/log/veeam hhv.
Hvis du bruger Application-Aware Image Processing (og det gør du højst sandsynligt), så bliver situationen noget mere kompliceret. Du skal bruge vores hjælpelogs, som er gemt inde i selve den virtuelle maskine, og VSS-logs. Hvordan og hvor man får denne lykke er skrevet i detaljer i . Og det er der selvfølgelig at indsamle de nødvendige systemlogfiler.
Det er praktisk at indsamle Windows-begivenheder iflg . Hvis du bruger Hyper-V, bliver sagen mere kompliceret, da du også skal bruge alle dens logfiler fra Applications and Service Logs > Microsoft > Windows-grenen. Selvom du altid kan tage en mere dum rute og blot tage alle objekter fra %SystemRoot%System32winevtLogs.
Hvis noget går i stykker under installationen/opgraderingen, så kan alt hvad du har brug for findes i mappen %ProgramData%/Veeam/Setup/Temp. Selvom jeg ikke vil skjule det faktum, at du kan finde mere nyttig information i OS-begivenheder end i disse logfiler. De resterende interessante ting ligger i %Temp%, men der er hovedsageligt installationslogfiler af relateret software, såsom databasen, .Net-biblioteker og andre ting. Bemærk venligst, at Veeam er installeret fra en msi, og alle dens komponenter er også installeret som separate msi-pakker, selvom dette ikke blev vist i GUI. Hvis installationen af en af komponenterne fejler, vil hele VBR-installationen derfor stoppe. Derfor skal du gå til logfilerne og se, hvad der præcist gik i stykker og i hvilket øjeblik.
Og et sidste life hack: Hvis du modtager en fejl under installationen, så skynd dig ikke at klikke på OK. Først tager vi logfilerne, og klik derefter på OK. På denne måde får du en log, der slutter i fejløjeblikket, uden skrald til sidst.
Og det sker, at du skal komme ind i vSphere-logfilerne. Det er et meget utaknemmeligt arbejde, men når du smøger ærmerne op, skal du gøre noget andet. I den enkleste version skal vi bruge logfiler med virtuelle maskine-hændelser vmware.log, som er placeret ved siden af dens .vmx-fil. I et mere komplekst tilfælde skal du åbne Google og spørge, hvor logfilerne for din version af værten er, da VMware elsker at ændre denne placering fra udgivelse til udgivelse. For eksempel, , men for . For vCenter-logfiler gentager vi proceduren . Men generelt vil vi være interesserede i værtshændelseslogfiler hostd.log, værtshændelser administreret af vCenter vpxa.log, kernelogfiler vmkernel.log og autentificeringslogfiler auth.log. Nå, i de mest avancerede tilfælde kan SSO-loggen, som er placeret i SSO-mappen, være nyttig.
Besværligt? Forvirret? Skræmmende? Men det er ikke engang halvdelen af den information, som vores support arbejder med på daglig basis. Så de er virkelig, virkelig seje.
Veeam komponenter
Og for at afslutte denne indledende artikel, lad os tale lidt om Veeam Backup & Replication-komponenterne. For når man leder efter årsagen til smerte, ville det være rart at forstå, hvordan patienten arbejder.
Så, som alle sikkert ved, er Veeam Backup en såkaldt SQL-baseret applikation. Det vil sige alle indstillinger, alle oplysninger og generelt alt, hvad der er nødvendigt for normal funktion - alt dette er i dens database. Eller rettere sagt i to databaser, hvis vi taler om en kombination af VBR og EM: henholdsvis VeeamBackup og VeeamBackupReporting. Og så skete det: vi installerer en anden applikation - en anden database dukker op. For ikke at gemme alle æggene i én kurv.
Men for at hele denne virksomhed skal fungere problemfrit, har vi brug for et sæt tjenester og applikationer, der forbinder alle komponenterne sammen. Bare for eksempel, sådan ser det ud i et af mine laboratorier:
Fungerer som chefdirigent Veeam Backup Service. Han er ansvarlig for udveksling af information med databaserne. Han er også ansvarlig for at lancere alle opgaver, orkestrere tildelte ressourcer og fungere som en slags kommunikationscenter for diverse konsoller, agenter og alt muligt andet. Med et ord er der absolut ingen vej uden ham, men det betyder slet ikke, at han gør alt selv.
Hjælper ham med at gennemføre sine planer Veeam Backup Manager. Dette er ikke en tjeneste, men en enhed, der lancerer jobs og overvåger processen med deres udførelse. Sikkerhedskopieringstjenestens arbejdende hænder, som den forbinder til værter med, opretter øjebliksbilleder, overvåger tilbageholdelse og så videre.
Men lad os vende tilbage til listen over tjenester. Veeam Broker Service. Dukkede op i v9.5 (og dette er ikke en kryptominer, som nogle troede dengang). Indsamler oplysninger om VMware-værter og holder dem opdateret. Men løb ikke med det samme for at skrive vrede kommentarer om, at vi udspionerer dig og lækker alle dine logins/adgangskoder til drag major. Alt er lidt enklere. Når du starter en sikkerhedskopi, er den første ting, du skal gøre, at oprette forbindelse til værten og opdatere alle data om dens struktur. Det er en ret langsom og uhåndterlig historie. Bare husk, hvor lang tid din login-handling via webgrænsefladen tager, og husk, at kun det øverste lag tages i betragtning der. Og så skal du i øvrigt stadig udvide hele hierarkiet til det rigtige sted. Med et ord, rædsel. Hvis du starter et dusin sikkerhedskopier, skal hvert job gennemgå denne procedure. Hvis vi taler om store infrastrukturer, så kan denne proces tage ti minutter eller mere. Derfor blev det besluttet at tildele en særskilt service til dette, hvorigennem det vil være muligt at modtage altid opdateret information. Ved opstart tjekker og scanner den al tilføjet infrastruktur og forsøger derefter kun at arbejde på niveauet med trinvise ændringer. Så selvom du har hundrede sikkerhedskopier kørende samtidigt, vil de alle anmode om oplysninger fra vores mægler og vil ikke plage værterne med deres anmodninger. Hvis du er bekymret for ressourcer, så har du ifølge vores beregninger for 5000 virtuelle maskiner kun brug for omkring 100 Mb hukommelse.
Næste har vi Veeam konsol. Aka Veeam Remote Console, aka Veeam.Backup.Shell. Dette er den samme GUI, som vi ser på skærmbillederne. Alt er enkelt og indlysende – konsollen kan startes hvor som helst, så længe det er Windows, og der er forbindelse til VBR-serveren. Det eneste, der kan siges, er, at FLR-processen vil montere punkter lokalt (dvs. på den maskine, hvor konsollen kører). Nå, forskellige Veeam Explorers vil også køre lokalt, fordi de er en del af konsollen. Men det har allerede ført mig ud i naturen...
Den næste interessante service er Veeam Backup Catalog Data Service. På listen over tjenester er det kendt som Veeam Guest Catalog Service. Han er engageret i at indeksere filsystemer på gæstemaskiner og fylder VBRCatalog-mappen med denne viden. Bruges kun, hvor indekseringsafkrydsningsfeltet er aktiveret. Og det giver kun mening at aktivere det, hvis du har Enterprise Manager. Derfor et råd fra bunden af mit hjerte: Aktiver ikke indeksering bare sådan, hvis du ikke har EM. Spar dine nerver og støtte tid.
Også af andre vigtige tjenester er det værd at bemærke Veeam Installatør Service, ved hjælp af hvilken de nødvendige komponenter leveres og installeres på proxyer, repositories og andre gateways. Faktisk leverer han de nødvendige .msi-pakker til serverne og installerer dem.
Veeam Data Mover — ved hjælp af hjælpeagenter lanceret på fuldmagter (og ikke kun) overfører den data. For eksempel vil den ene agent under backup læse filer fra værtens datalager, og den anden vil omhyggeligt skrive dem til sikkerhedskopien.
Separat vil jeg gerne bemærke en vigtig ting, som klienter ofte reagerer på - forskellen i versioner af tjenester og information i programmer og funktioner snap-in. Ja, listen vil være den samme, men versionerne kan være fuldstændig inkonsistente. Dette er ikke særlig godt ud fra et visuelt synspunkt, men det er helt normalt, hvis alt fungerer stabilt. For eksempel halter versionsnummeret af Installer-tjenesten langt bagefter sine naboer. Rædsel og mareridt? Nej, fordi det ikke er geninstalleret helt, men dets DLL bliver simpelthen opdateret. I v9.5 U4-patchen opstod der et mareridt med teknisk support: under opdateringen modtog alle tjenester nye versioner, undtagen den vigtigste. I U4b-patchen var transporttjenesten foran alle andre med hele to versioner (at dømme efter tallene). Og det er også normalt - der blev fundet en alvorlig fejl i den, så den modtog en bonusopdatering i forhold til de andre. Så for at opsummere: versionsforskelle KAN være et problem, men hvis der er en forskel og alt fungerer korrekt, så burde det højst sandsynligt være det. Men ingen forbyder dig at afklare dette med teknisk support.
Disse var de såkaldte obligatoriske eller obligatoriske tjenester. Og der er en hel pakke af hjælpesystemer, såsom Tape Service, Mount Service, vPowerNFS Service og så videre.
For Hyper-V generelt er alt det samme, kun der er et specifikt Veeam Backup Hyper-V Integration Service og sin egen driver til at arbejde med CBT.
Og til sidst vil vi tale om, hvem der arbejder på virtuelle maskiner under backup. Det bruges til at køre scripts før og efter fryse, oprette skyggekopier, indsamle metadata, arbejde med SQL-transaktionslogfiler osv. Veeam gæstehjælper. Og hvis filsystemer er indekseret, Veeam Guest Indexer . Disse er midlertidige tjenester, der er implementeret i sikkerhedskopieringens varighed og slettes efter den.
I tilfælde af Linux-maskiner er alt meget enklere på grund af tilstedeværelsen af et stort antal indbyggede biblioteker og systemets egenskaber. For eksempel sker indeksering gennem mlocate.
Det er alt for nu
Jeg tør ikke plage dig mere og kort Jeg anser introduktionen til Veeam-motorrummet for at være komplet. Ja, vi er ikke engang kommet tæt på selve loggene, men tro mig, så informationen i dem ikke virker som en usammenhængende strøm af bevidsthed, er en sådan introduktion absolut nødvendig. Jeg planlægger først at gå videre til selve logfilerne i den tredje artikel, og planen for den næste er at forklare, hvem der genererer logfilerne, hvad der præcist vises i dem, og hvorfor netop på denne måde og ikke på en anden måde.
Kilde: www.habr.com