Vi i Veeam elsker tømmerstokker. Og siden de fleste av våre løsninger er modulære, skriver de mange logger. Og siden omfanget av aktiviteten vår er å sikre sikkerheten til dataene dine (dvs. avslappende søvn), bør loggene ikke bare registrere hvert nys, men også gjøre det i noen detalj. Dette er nødvendig slik at det i tilfelle noe er klart hvordan dette "hva" skjedde, hvem som har skylden og hva som må gjøres videre. Det er som i rettsmedisin: du vet aldri hvilken liten ting som vil hjelpe deg med å finne Laura Palmers morder.
Derfor bestemte jeg meg for å ta en sving på en serie artikler, hvor jeg sekvensielt vil snakke om hva vi skriver til loggene, hvor vi lagrer dem, hvordan vi ikke skal gå gale med strukturen deres og hva vi skal se etter inni dem.
Hvorfor en serie artikler og hvorfor ikke beskrive alt på en gang?
Bare å liste opp hvilken logg som er hvor og hva som er lagret i den er en ganske katastrofal oppgave. Og det er skummelt å tenke på å holde denne informasjonen oppdatert. En enkel liste over alle mulige typer logger i Veeam Backup & Replication er en tabell over flere ark med liten skrift. Ja, og det vil bare være relevant på publiseringstidspunktet, fordi. når neste patch er utgitt, kan nye logger dukke opp, logikken til den lagrede informasjonen i de gamle vil endre seg, etc. Derfor vil det være mye mer lønnsomt å forklare strukturen deres og essensen av informasjonen i dem. Dette vil tillate deg å navigere i stedene bedre enn den banale proppfulle av navn.
Derfor, for ikke å haste hodestups inn i bassenget av tekstark, la oss gjøre noe forberedende arbeid i denne artikkelen. Derfor vil vi i dag ikke komme inn på selve loggene, men gå langveisfra: vi vil kompilere en ordliste og diskutere Veeam-strukturen litt når det gjelder generering av logger.
Ordliste og sjargong
Her er det først og fremst verdt å be om unnskyldning til forkjemperne for renheten til det russiske språket og vitnene til Ozhegovs ordbok. Vi elsker alle morsmålet vårt veldig mye, men den fordømte IT-bransjen opererer på engelsk. Vel, vi kom ikke på det, men det skjedde historisk. Det er ikke min feil, han kom selv (c)
I vår virksomhet har problemet med anglisisme (og sjargong) sine egne detaljer. Når hele verden under uskyldige ord som "vert" eller "gjest" lenge har forstått veldig spesifikke ting, så fortsetter heroisk forvirring og svimlende med å stikke i ordbøker på ⅙ av landet. Og det strengt obligatoriske argumentet "Men på vårt arbeid ...".
I tillegg er det rent terminologien vår, som er iboende i Veeam-produkter, selv om noen ord og uttrykk har gått til folket. Derfor vil vi nå bli enige om hvilket begrep som betyr hva, og i fremtiden vil jeg med ordet "gjest" mene nøyaktig det som er skrevet i dette kapittelet, og ikke hva du er vant til på jobben. Og ja, dette er ikke mitt personlige innfall, dette er veletablerte begreper i bransjen. Å bekjempe dem er litt meningsløst. Selv om jeg alltid er for å slappe av i kommentarer.
Dessverre er det mange begreper i arbeidet og produktene våre, så jeg skal ikke prøve å liste dem alle opp. Kun den mest grunnleggende og nødvendige informasjonen om sikkerhetskopier og logger for overlevelse i sjøen. For de interesserte kan jeg også kolleger om bånd, hvor han også ga en liste over termer knyttet til den delen av funksjonaliteten.
Vert (vert): I virtualiseringens verden er dette en maskin med hypervisor. Fysisk, virtuell, sky – det spiller ingen rolle. Hvis noe kjører en hypervisor (ESXi, Hyper-V, KVM etc), så kalles dette "noe" en vert. Enten det er en klynge med ti rack eller den bærbare datamaskinen din med en lab for halvannen virtuelle maskiner – hvis du lanserte en hypervisor, ble du en vert. Fordi hypervisoren er vert for virtuelle maskiner. Det er til og med en historie om at VMware en gang ønsket å oppnå en fast assosiasjon av ordet vert med ESXi. Men det gjorde hun ikke.
I den moderne verden har konseptet "vert" praktisk talt smeltet sammen med konseptet "server", noe som skaper en viss forvirring i kommunikasjonen, spesielt når det gjelder Windows-infrastruktur. Så enhver maskin som er vert for en tjeneste av interesse for oss, kan trygt kalles en vert. For eksempel, i WinSock-loggene er alt merket med ordet vert. Klassikeren «Host not found» er et eksempel på dette. Så vi tar utgangspunkt i konteksten, men husk - i virtualiseringens verden er en vert det som er vert for gjester (mer om dette på to linjer nedenfor).
Fra lokal sjargong (heller til og med akronymer, i dette tilfellet), huskes det her at VMware er VI, vSphere er VC og Hyper-V er HV.
Gjest (gjest): Den virtuelle maskinen som kjører på verten. Det er ingenting å forklare her, alt er så logisk og enkelt. Imidlertid drar mange flittig hit noen andre betydninger.
For hva? Jeg vet ikke.
Guest OS, henholdsvis operativsystemet til gjestemaskinen. Og så videre.
Sikkerhetskopierings-/replikeringsjobb (jobbA): Ren Wim-sjargong, som betegner noen av oppgavene. Backup jobb == Backup jobb. Ingen har funnet ut hvordan den skal oversettes vakkert til russisk, så alle sier "JobA". Med vekt på siste stavelse.
Ja, de bare tar det og sier "joba". Og selv i brev skriver de sånn, og alt er bra.
Alle slags sikkerhetskopieringsjobber, sikkerhetskopieringsoppgaver, etc., takk, men ikke nødvendig. Bare en jobb, og du vil bli forstått. Det viktigste er å legge vekt på den siste stavelsen.
Backup (Backup, backup. For true-oldfags er backup tillatt): I tillegg til det åpenbare (en sikkerhetskopi av data som ligger et sted), betyr det også selve jobben (tre linjer over, hvis du allerede har glemt), som et resultat av at selve sikkerhetskopifilen vises. Sannsynligvis er herrer som har engelsk som morsmål for late til å si at jeg kjørte backupjobben min hver gang, så de sier bare at jeg kjørte backupen min, og alle forstår hverandre perfekt. Jeg inviterer deg til å støtte dette fantastiske initiativet.
Konsolidere (konsolidering): Et begrep som dukket opp i ESXi 5.0 Et alternativ i øyeblikksbildemenyen som starter prosessen med å slette såkalte foreldreløse øyeblikksbilder. Det vil si øyeblikksbilder som er fysisk tilgjengelige, men falt ut av den viste logiske strukturen. Teoretisk sett skal ikke denne prosessen påvirke filene som vises i øyeblikksbildebehandlingen, men alt kan skje. Essensen av konsolideringsprosessen er at dataene fra øyeblikksbildet (underordnet disk) skrives til hoveddisken (overordnet). Prosessen med å kombinere disker kalles merge. Hvis en konsolideringskommando er utstedt, kan øyeblikksbildeposten fjernes fra databasen før øyeblikksbildet slås sammen og slettes. Og hvis øyeblikksbildet av en eller annen grunn ikke kunne slettes, vises de samme foreldreløse øyeblikksbildene. Om å jobbe med øyeblikksbilder har VMware . Og vi også på en eller annen måte om dem .
Datalager (Stora eller lagring): Et veldig bredt konsept, men i virtualiseringens verden forstås det som et sted hvor virtuelle maskinfiler lagres. Men i alle fall, her må du forstå konteksten veldig tydelig og, med den minste tvil, avklare hva akkurat din samtalepartner hadde i tankene.
Fullmakt (Proxy): Det er viktig å umiddelbart forstå at Veeam Proxy ikke er helt det samme som det vi er vant til på Internett. Innenfor Veeam-produkter er dette en slags enhet som driver med overføring av data fra ett sted til et annet. Hvis du ikke går inn på detaljer, er VBR en kommando- og kontrollserver, og proxyer er arbeidshestene. Det vil si at en proxy er en maskin som trafikk flyter gjennom og som VBR-komponenter er installert på som hjelper til med å administrere denne trafikken. For eksempel for å overføre data fra en kanal til en annen, eller ganske enkelt for å feste disker til seg selv (HotAdd-modus).
Repository (Repository): Teknisk sett er dette bare en oppføring i VBR-databasen, som indikerer stedet hvor sikkerhetskopiene er lagret, og hvordan du kobler til dette stedet. Faktisk kan det enten bare være en CIFS-ball eller en separat disk, server eller bøtte i skyen. Igjen, vi er i kontekst, men vi forstår at et depot bare er et sted hvor sikkerhetskopiene dine er.
Øyeblikksbilde (SnapshOt): Grammatikkinteresserte i Oxford foretrekker å si hvem som er øyeblikksbilde og hvem som er øyeblikksbilde, men det analfabeter flertallet drar nytte av den større massen. Hvis noen ikke vet, er dette en teknologi som lar deg gjenopprette tilstanden til en disk på et bestemt tidspunkt. Dette gjøres enten ved å midlertidig omdirigere I/O-operasjoner bort fra hoveddisken - da vil det bli kalt RoW (Redirect on Write) snapshot - eller ved å flytte overskrivbare blokker fra disken din til en annen - dette vil bli kalt CoW (Copy on Write) ) øyeblikksbilde. Det er takket være de brede mulighetene for å bruke disse funksjonene at Veeam kan utføre sin backup-magi. Strengt tatt er det ikke bare dem, men dette er spørsmålet om de neste utgivelsene.
Det er kaos rundt dette begrepet i ESXi-dokumentasjonen og loggene, og i sammenheng med å nevne øyeblikksbilder, kan du finne selve øyeblikksbilder og gjøre om logg, og til og med deltadisk. Veeam-dokumentasjonen inneholder ikke en slik rive, og et øyeblikksbilde er et øyeblikksbilde, og en redo-logg er nøyaktig en REDO-fil opprettet av en uavhengig ikke-vedvarende disk. REDO-filer slettes når den virtuelle maskinen er slått av, så å forveksle dem med øyeblikksbilder er en vei til feil.
Syntetisk (syntetisk): Syntetiske sikkerhetskopier er omvendt inkrementelle og for alltid fremover backup. I tilfelle du ikke har kommet over dette begrepet, er det bare en av mekanismene som brukes til å bygge en backupkjedetransformasjon. Men i loggene kan du også finne konseptet Transform, som brukes i rammeverket for å lage hele kopier fra inkrementer (syntetisk full).
Oppgave (Task): Dette er prosessen med å behandle hver enkelt maskin i jobben. Det vil si: du har en backup-jobb, som inkluderer tre maskiner. Dette betyr at hver bil vil bli behandlet som en del av en egen oppgave. Totalt vil det være fire logger: den viktigste for jobber og tre for oppgaver. Det er imidlertid en viktig nyanse her: Over tid har ordet «oppgave» blitt unødvendig flertydig. Når vi snakker om generelle logger, mener vi at en oppgave akkurat er en VM. Men det er "oppgaver" både på proxyen og på depotet. Der kan det bety en virtuell disk, en virtuell maskin og hele jobben. Det vil si at det er viktig å ikke miste konteksten.
Veeam %name% tjeneste: Til fordel for vellykkede sikkerhetskopier fungerer flere tjenester samtidig, en liste over dem finnes i standardutstyret. Navnene deres gjenspeiler ganske transparent essensen deres, men blant likeverdige er det den viktigste - Veeam Backup Service, uten hvilken resten ikke vil fungere.
VSS: Teknisk sett skal VSS alltid stå for Microsoft Volume Shadow Copy Service. Faktisk brukes det av mange som et synonym for Application-Aware Image Processing. Noe som selvfølgelig er kategorisk feil, men dette er en historie fra kategorien «Enhver SUV kan kalles en jeep, og du vil bli forstått».
Fantastiske tømmerstokker og hvor de bor
Jeg vil starte dette kapittelet med å avsløre den store hemmeligheten - hvilken tid vises i loggene?
Huske:
- ESXi skriver alltid logger i UTC+0.
- vCenter fører logger i henhold til tiden for tidssonen.
- Veeam fører logger etter tid og tidssone til serveren den er på.
- Og bare Windows-hendelser i EVTX-format lider ikke av binding til noe. Ved åpning beregnes tiden på nytt for bilen de ble åpnet på. Det mest praktiske alternativet, selv om det er vanskeligheter med det. Den eneste konkrete vanskeligheten er forskjellen i lokaliteter. Dette er en praktisk talt garantert vei til ulesbare logger. Ja, det finnes alternativer for hvordan dette skal behandles, men la oss bare ikke krangle med at alt innen IT fungerer på engelsk, og godta å alltid sette den engelske lokaliteten på serverne. Å vær så snill.
La oss nå snakke om stedene der tømmerstokkene bor og hvordan du får tak i dem. Når det gjelder VBR, er det to tilnærminger.
Det første alternativet er egnet hvis du ikke er ivrig etter å se etter filer i den generelle haugen som er spesifikt relatert til problemet ditt. For å gjøre dette har vi en egen veiviser, som du kan spesifisere en spesifikk jobb til og en bestemt periode du trenger logger for. Deretter vil han gå gjennom mappene selv og legge alt du trenger i ett arkiv. Hvor du skal lete etter det og hvordan du arbeider med det er beskrevet i detalj i .
Veiviseren samler imidlertid ikke loggene for alle oppgaver, og hvis du for eksempel trenger å studere loggene for gjenoppretting, failover eller failback, ligger banen din i mappen %ProgramData%/Veeam/Backup. Dette er den viktigste VBR-logobutikken og %ProgramData% er en skjult mappe, og det er greit. Forresten, standardplasseringen kan tilordnes på nytt ved å bruke REG_SZ: LogDirectory type registernøkkel i HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication-grenen.
På Linux-maskiner bør arbeideragentlogger ses etter i /var/log/VeeamBackup/hvis du bruker en root- eller sudo-konto. Hvis du ikke har slike privilegier, så se etter pålogginger /tmp/VeeamBackup.
For Veeam-agent for %OS_name% skal logger søkes inn %ProgramData%/Veeam/Endepunkt (eller %ProgramData%/Veeam/Backup/Endpoint) Og /var/log/veeam henholdsvis.
Hvis du bruker Application-Aware Image Processing (og mest sannsynlig gjør du det), så blir situasjonen noe mer komplisert. Du trenger loggene til hjelperen vår, som er lagret inne i selve den virtuelle maskinen, og VSS-loggene. Om hvordan og hvor du kan få denne lykken, er det skrevet i detalj i . Og selvfølgelig er det det for å samle de nødvendige systemloggene.
Windows-hendelser samles praktisk iht . Hvis du bruker Hyper-V, blir ting mer komplisert, siden du også trenger alle loggene fra applikasjons- og tjenesteloggene > Microsoft > Windows-grenen. Selv om du alltid kan gå den mer dumme veien og bare plukke opp alle objektene fra %SystemRoot%System32winevtLogs.
Hvis noe går i stykker under installasjon/oppgradering, finner du alt du trenger i mappen %ProgramData%/Veeam/Setup/Temp. Selv om jeg ikke skal legge skjul på at i OS-hendelser kan du finne mer nyttig informasjon enn i disse loggene. Resten av det interessante ligger i %Temp%, men det er hovedsakelig installasjonslogger for relatert programvare, som basen, .Net-biblioteker og andre ting. Merk at Veeam er installert fra msi og alle komponentene er også installert som separate msi-pakker, selv om dette ikke ble vist i GUI. Derfor, hvis installasjonen av en av komponentene mislykkes, vil hele VBR-installasjonen bli stoppet. Derfor må du gå inn i loggene og se nøyaktig hva som gikk i stykker og på hvilket tidspunkt.
Og til slutt, et livshack: hvis du får en feil under installasjonen, ikke skynd deg å klikke OK. Først tar vi loggene, og klikker deretter OK. På denne måten vil du få en logg som slutter ved feiltidspunktet, uten søppel på slutten.
Og det hender at du må komme inn i vSphere-loggene. Okkupasjonen er veldig utakknemlig, men etter å ha brettet opp ermene, må man gjøre noe annet. I den enkleste versjonen trenger vi logger med virtuelle maskinhendelser vmware.log, som ligger ved siden av .vmx-filen. I et vanskeligere tilfelle, åpne Google og spør hvor loggene for vertsversjonen din er plassert, siden VMware elsker å endre dette stedet fra utgivelse til utgivelse. For eksempel, , men for . For vCenter-logger, gjenta prosedyren . Men generelt vil vi være interessert i vertshendelseslogger hostd.log, vertshendelser administrert av vCenter vpxa.log, kjernelogger vmkernel.log og autentiseringslogger auth.log. Vel, i de mest forsømte tilfellene kan SSO-loggen, som ligger i SSO-mappen, komme godt med.
Tungt? Forvirret? Skummelt? Men dette er ikke engang halvparten av informasjonen vår support jobber med på daglig basis. Så de er veldig, veldig kule.
Veeam-komponenter
Og som en avslutning på denne innledende artikkelen, la oss snakke litt om komponentene i Veeam Backup & Replication. For når du leter etter årsaken til smerte, ville det vært fint å forstå hvordan pasienten fungerer.
Så, som alle sikkert vet, er Veeam Backup en såkalt SQL-basert applikasjon. Det vil si alle innstillinger, all informasjon og generelt alt som bare er nødvendig for normal funksjon - alt dette er i databasen. Eller rettere sagt, i to databaser, hvis vi snakker om en haug med VBR og EM: henholdsvis VeeamBackup og VeeamBackupReporting. Og så skjedde det: vi la en annen applikasjon - en annen database dukker opp. For ikke å lagre alle eggene i en kurv.
Men for at all denne økonomien skal fungere problemfritt, trenger vi et sett med tjenester og applikasjoner som vil binde alle komponentene sammen. Bare som et eksempel, dette er hvordan det ser ut i en av laboratoriene mine:
Fungerer som sjefdirigent Veeam Backup Service. Det er han som har ansvaret for informasjonsutvekslingen med basene. Han er også ansvarlig for å lansere alle oppgaver, orkestrere tildelte ressurser og jobbe som et slags kommunikasjonssenter for en rekke konsoller, agenter og alt annet. Med et ord, det er definitivt ingen vei uten ham, men dette betyr ikke i det hele tatt at han gjør alt selv.
Hjelper ham i oppfyllelsen av planen hans Veeam Backup Manager. Dette er ikke en tjeneste, men en enhet som lanserer jobber og overvåker prosessen med å utføre deres. Backup-tjenestens arbeidende hender, som den kobler til verter med, lager øyeblikksbilder, overvåker oppbevaring og så videre.
Men tilbake til listen over tjenester. Veeam meglertjeneste. Dukket opp i v9.5 (og dette er ikke en kryptogruvearbeider, som noen trodde da). Engasjert i å samle informasjon om VMware-verter og opprettholde dens relevans. Men ikke løp umiddelbart for å skrive sinte kommentarer om at vi spionerer på deg og lekker alle pålogginger/passord til taschmajor. Alt er noe enklere. Når du kjører en sikkerhetskopi, er det første du må gjøre å koble til verten og oppdatere alle data om strukturen. Dette er en ganske treg og tungvint historie. Bare husk hvor lang tid det tar for deg å logge på via nettgrensesnittet, og husk at kun det øverste laget telles der. Og da må du fortsatt åpne hele hierarkiet til rett sted, forresten. Med et ord, skrekk. Hvis du kjører et dusin sikkerhetskopier, må hver jobb gjøre denne prosedyren. Hvis vi snakker om store infrastrukturer, kan denne prosessen ta ti minutter eller mer. Derfor ble det besluttet å tildele en egen tjeneste for dette, der det vil være mulig å motta alltid oppdatert informasjon. Ved oppstart sjekker og skanner den all lagt til infrastruktur, og prøver deretter å fungere bare på nivået av inkrementelle endringer. Så selv om du kjører hundre sikkerhetskopier samtidig, vil de alle be om informasjon fra megleren vår, og vil ikke plage vertene med sine forespørsler. Hvis du er bekymret for ressurser, trenger 5000 virtuelle maskiner ifølge våre beregninger bare ca. 100 Mb minne.
Neste har vi Veeam-konsoll. Han er Veeam Remote Console, han er Veeam.Backup.Shell. Dette er den samme GUI som vi ser i skjermbildene. Alt er enkelt og åpenbart – konsollen kan startes fra hvor som helst, så lenge det er Windows og det er en tilkobling til VBR-serveren. Det eneste som kan sies er at FLR-prosessen vil montere punkter lokalt (dvs. på maskinen der konsollen kjører). Vel, diverse Veeam Explorers vil også kjøre lokalt, fordi de er en del av konsollen. Men det har allerede ført meg ut i villmarken ...
En annen interessant tjeneste er Veeam Backup Catalog Data Service. Kjent som Veeam Guest Catalog Service i listen over tjenester. Han er engasjert i å indeksere filsystemer på gjestemaskiner og fyller VBRCatalog-mappen med denne kunnskapen. Den brukes bare der indekseringsboksen er aktivert. Og det er bare fornuftig å aktivere det hvis du har Enterprise Manager. Derfor, råd fra bunnen av mitt hjerte: ikke slå på indeksering bare sånn hvis du ikke har EAT. Spar nervene og støtte tid.
Også fra andre viktige tjenester er det verdt å merke seg Veeam installasjonstjeneste, ved hjelp av hvilken de nødvendige komponentene leveres og installeres på proxyer, repositories og andre gatewayer. Faktisk tar den de nødvendige .msi-pakkene til serverne og installerer dem.
Veeam Data Mover - ved hjelp av hjelpeagenter lansert på proxyer (og ikke bare) er den engasjert i å skifte data. For eksempel, når du sikkerhetskopierer, vil en agent lese filer fra vertsdatalageret, og den andre vil nøye skrive dem til sikkerhetskopien.
Separat vil jeg merke meg en viktig ting som klienter ofte reagerer på - dette er forskjellen i versjoner av tjenester og informasjon i programmer og funksjoner snap-in. Ja, listen vil være den samme, men versjonene kan være helt uenige. Det er ikke veldig kult fra et visuelt synspunkt, men det er helt normalt hvis alt fungerer stabilt. For eksempel for installasjonstjenesten er versjonsnummeret langt bak naboene. Skrekk og mareritt? Nei, fordi den ikke er fullstendig installert på nytt, men DLL-filen er ganske enkelt oppdatert. I patch v9.5 U4 oppsto et mareritt for teknisk støtte: under oppdateringen mottok alle tjenester nye versjoner, bortsett fra den viktigste. I U4b-lappen overtok transporttjenesten alle de andre med så mye som to versjoner (ut fra tallene å dømme). Og dette er også normalt - det ble funnet en alvorlig feil i den, så den fikk en bonusoppdatering i forhold til resten. Så for å oppsummere: versjonsforskjeller KAN være et problem, men hvis det er en forskjell og alt fungerer som det skal, bør det sannsynligvis være det. Men ingen forbyr deg å avklare dette i teknisk støtte.
Dette var de såkalte obligatoriske eller obligatoriske tjenestene. Og det er en hel haug med hjelpetjenester, for eksempel Tape Service, Mount Service, vPowerNFS Service og så videre.
For Hyper-V, generelt, er alt det samme, bare det er en spesifikk Veeam Backup Hyper-V Integration Service og din egen driver for arbeid med CBT.
Og til slutt, la oss snakke om hvem som jobber på virtuelle maskiner under sikkerhetskopiering. For å kjøre skript før og etter frysing, lage en skyggekopi, samle inn metadata, jobbe med SQL-transaksjonslogger, etc. Veeam gjestehjelper. Og hvis filsystemer er indeksert, Veeam gjesteindekser . Dette er midlertidige tjenester som er distribuert i løpet av sikkerhetskopieringen og fjernet etter den.
Når det gjelder Linux-maskiner, er alt mye enklere på grunn av tilstedeværelsen av et stort antall innebygde biblioteker og egenskapene til selve systemet. For eksempel gjøres indeksering gjennom mlocate.
Det er alt for nå
Jeg tør ikke såre deg lenger kort Jeg anser introduksjonen til Veeam-motorrommet som over. Ja, vi har ikke engang kommet i nærheten av selve hi, men tro meg, slik at informasjonen som presenteres i dem ikke virker som en usammenhengende bevissthetsstrøm, er en slik introduksjon helt nødvendig. Jeg planlegger å gå til selve loggene bare i den tredje artikkelen, og planen for den neste er å forklare hvem som genererer loggene, nøyaktig hva som vises i dem og hvorfor akkurat, og ikke ellers.
Kilde: www.habr.com