U Veeamu volimo logove. Budući da su većina naših rješenja modularna, pišu prilično mnogo logova. S obzirom na to da je naša djelatnost osiguranje očuvanja vaših podataka (tj. miran san), logovi ne bi trebali samo zabilježiti svaki zvuk, već to raditi prilično detaljno. To je potrebno kako bi u slučaju bilo kakvih problema bilo jasno kako je do toga došlo, tko je kriv i što treba učiniti dalje. Ovde je kao u kriminologiji: nikad ne znaš koja sitnica može pomoći u pronalaženju ubice Laure Palmer.
Zato sam odlučio započeti seriju članaka u kojima ću postupno pričati o tome što zapisujemo u logove, gdje ih pohranjujemo, kako ne poludjeti od njihove strukture i što zapravo tražiti unutar njih.
Zašto serija članaka i zašto ne opisati sve odjednom?
Jednostavno nabrojati koji se logovi nalaze gdje i što u njima stoji — prilično je beznačajna ideja. A o održavanju tih informacija u ažurnom stanju i razmišljati je zastrašujuće. Jednostavno nabrajanje svih mogućih vrsta logova u Veeam Backup & Replication — to je tabela na nekoliko stranica sitnim fontom. I bit će relevantno samo u trenutku objave, jer s izlaskom sljedeće zakrpe mogu se pojaviti novi logovi, promijeniti logika pohranjene informacije u starima itd. Zbog toga će biti mnogo korisnije objasniti njihovu strukturu i suštinu sadržane informacije. To će omogućiti bolju orijentaciju na terenu nego dosadna memorisanja naziva.
Dakle, kako bismo izbjegli skakanje s glavom u more tekstualnih maramica, hajde da u ovom članku obavimo neku pripremnu práci. Zato danas nećemo zalaziti u same logove, već ćemo prići s daljine: sastaviti ćemo glosar i malo razgovarati o strukturi Veeama s gledišta generacije logova.
Glosar i žargonizmi
Ovdje se prije svega ispričavam pobornicima čistoće hrvatskog jezika i svjedocima Ožegovljevog rječnika. Svi jako volimo svoj materinji jezik, ali prokleta IT industrija radi na engleskom. Pa, nismo mi to smislili, tako je povijesno ispalo. Nije moja krivnja, on je sam došao (c)
U našem poslu, problem anglizama (i žargona) ima svoju specifičnost. Kada pod nevinoj rečima poput „host“ ili „gost“ čitav svet već dugo razume veoma konkretne stvari, na ⅙ dela kopna nastavlja se herojsku raspojasanost i lutanje sa tikanjem u rečnike. I strogo obavezan argument „A kod nas na poslu…”.
Pored toga, postoji isključivo naša terminologija, koja pripada proizvodima Veeam, iako su neke reči i izrazi postali opšteprihvaćeni. Zato ćemo sada dogovoriti šta termin znači, i ubuduće pod rečju „gost“ mislim tačno ono što je napisano u ovoj glavi, a ne ono na šta ste navikli na poslu. I da, ovo nije moja lična prohtjev, to su ustaljeni termini u industriji. Borba protiv njih je pomalo besmislena. Iako rado učestvujem u raspravama u komentarima.
Nažalost, termina u našem radu i proizvodima je jako mnogo, tako da neću pokušavati da navedem sve. Samo one najosnovnije i neophodne za preživljavanje u moru informacija o backup-ima i logovima. Za zainteresovane mogu također kolega o trakama, gde je takođe naveo listu termina koji se odnose na tu funkcionalnost.
Host (Host): U svetu virtualizacije, to je mašina sa hipervizorom. Fizička, virtualna, cloud — nije važno. Ako je na nečemu pokrenut hipervizor (ESXi, Hyper-V, KVM itd.), to „nešto“ se naziva hostom. Bilo da je to klaster od deset rackova ili vaš laptop sa labaratorijom koja hostuje jednu i po virtuelku — ako ste pokrenuli hipervizor, onda ste postali host. Jer hipervizor hostuje virtuelne mašine. Čak postoji i priča da je VMware u svoje vreme želeo da postigne čvrstu asocijaciju reči host isključivo sa ESXi. Ali nije uspelo.
U savremenom svetu, pojam „host“ praktično se stapa s pojmom „server“, što unosi određenu zabunu u komunikaciju, posebno kada je reč o Windows infrastrukturi. Tako da bilo koja mašina na kojoj se nalazi neki interesantan servis može smelo biti nazvana hostom. Na primer, u logovima WinSock, reč host označava sve i svašta. Klasičan primer je „Host not found“. Tako da polazimo od konteksta, ali pamtimo — u svetu virtualizacije, host je ono što hostuje goste (to se objašnjava u sledećih nekoliko rečenica).
Od lokalnih žargonizama (više akronima, u ovom slučaju) ovdje se sjeća da je VMware – VI, vSphere – VC, a Hyper-V – HV.
Gost (Guest): Virtualna mašina koja radi na hostu. Ovdje nema potrebe za objašnjavanjem, sve je logično i jednostavno. Međutim, mnogi inzistiraju na tome da ovdje donesu neke druge smisle.
Zašto? Ne znam.
Gost OS, odnosno operativni sustav gostujuće mašine. I tako dalje.
Backup/Replication Job (posao): Čisti VMware žargon koji označava neki od zadataka. Backup job == Posao Beka. Kako to lijepo prevesti na hrvatski — nitko nije smislio, stoga svi kažu 'posao'. S naglaskom na posljednjem slogu.
Da, jednostavno uzmu i kažu 'posao'. Čak i u e-mailovima tako pišu, i sve je u redu.
Razne Beka radnje, Zadatci Beka i slično, hvala, ali ne treba. Samo 'posao', i razumjet će vas. Najvažnije je staviti naglasak na posljednji slog.
Backup (Beka, beka. Za istinske starije se dopušta bakup): Pored očiglednog (rezervne kopije podataka koja negdje leži), ovo također označava i sam posao (tri retka iznad, ako ste već zaboravili), nakon čega nastaje taj beka datotek. Vjerojatno, gospođe govornici engleskog su previše lijeni da svaki put kažu 'I ran my backup job', pa jednostavno kažu 'I ran my backup', i svi se odlično razumiju. Predlažem podržati ovu divnu inicijativu.
Konsolidacija (Consolidate): Termin koji se pojavio u ESXi 5.0 Opcija u izborniku za rad s snapshotima koja pokreće proces brisanja takozvanih orphaned snapshotova. To su snapshotovi koji fizički postoje, ali su ispali iz prikazane logičke strukture. Teoretski, ovaj proces ne bi trebao utjecati na datoteke prikazane u menadžeru snapshotova, iako se zna dogoditi sve. Suština procesa konsolidacije je da se podaci iz snapshot-a (child disk) zapisuju na glavni (parent) disk. Proces spajanja diskova naziva se mješavina (merge). Ako je izdata naredba za konsolidaciju, zapis o snapshot-u može biti uklonjen iz baze ranije nego što bude miješan i uklonjen. A ako se snapshot iz bilo kojeg razloga ne može izbrisati, tada se pojavljuju ovi orphaned snapshotovi. O radu sa snapshotovima VMware ima . I mi smo također jednom o njima .
Skladište (Datastore): Vrlo širok pojam, no u svetu virtualizacije podrazumeva mesto gde se čuvaju fajlovi virtuelnih mašina. U svakom slučaju, ovde je važno jasno razumeti kontekst i u slučaju najmanjih sumnji razjasniti šta je vaš sagovornik mislio.
Proxy (Proksi): Važno je odmah razumeti da Veeam Proxy nije sasvim isto što i ono na što smo navikli na poljima interneta. U okviru proizvoda od Veeam to je neka vrsta entiteta koja se bavi premeštanjem podataka iz jednog mesta na drugo. Ako ne idemo u detalje, VBR je komandni server, dok je proksi njegov radni konj. To znači da je proksi mašina kroz koju prolazi saobraćaj i na kojoj su instalirane VBR komponente koje pomažu u upravljanju tim saobraćajem. Na primer, premeštanje podataka iz jednog kanala u drugi ili jednostavno povezivanje diskova (HotAdd mode).
Repository (Repozitorij): Tehnički, to je samo upis u VBR bazi koji ukazuje na mesto gde se čuvaju backup-ovi i kako se ovoj lokaciji pristupa. U praksi, to može biti i jednostavna CIFS šara, kao i poseban disk, server ili oblak. Ponovo, nalazimo se u kontekstu, ali razumemo da je repozitorij jednostavno mesto gde su vaši backup-ovi.
Snapshot (Snapshot): Ljubitelji oksfordske gramatike vole da kažu ko je snEpšot, ko snEpšot, ali neukost većine pobedi zbog svoje mase. Ako neko ne zna — to je tehnologija koja omogućava obnavljanje stanja diska u određenom trenutku. To se radi ili preusmeravanjem I/O operacija od glavnog diska — tada će se zvati RoW (Redirect on Write) snapshot — ili premeštanjem prepisanih blokova s vašeg diska na drugi — tada će se zvati CoW (Copy on Write) snapshot. Upravo zahvaljujući širokim mogućnostima korišćenja ovih funkcija Veeam može da stvara svoju backup magiju. Strogo govoreći, ne samo on, ali to je predmet narednih izdanja.
U dokumentaciji i logovima ESXi oko ovog termina postoji kaos, a u kontekstu spominjanja snimaka može se susresti i sami snimci, i redo log, pa čak i delta disk. U dokumentaciji Veeam tog nereda nema, i snimak je snimak, dok je redo log zapravo REDO datoteka, stvorena nezavisnim non-persistent diskom. REDO datoteke se brišu prilikom isključivanja virtuelne mašine, tako da njihovo mešanje sa snimcima vodi ka neuspehu.
Sintetička (Synthetic): Sintetičke kopije odnose se na reverse incremental i forever forward kopije. Ako se slučajno niste susretali s ovim terminom, to je samo jedan od mehanizama koji se koriste za izgradnju transformacijskih lanca kopija. Međutim, u logovima takođe možete sresti pojam Transform, koji se koristi u okviru stvaranja potpunih kopija iz inkremenata (sintetička puna).
Zadatak (Task): To je proces obrade svake pojedinačne mašine u okviru posla. Dakle: imate posao za pravljenje kopija, u koji su uključene tri mašine. Znači, svaka mašina će se obrađivati u okviru posebnog zadatka. Ukupno će biti četiri loga: jedan glavni za posao i tri za zadatke. Međutim, ovde postoji važna nijansa: vremenom je reč 'zadatak' postala previše višeznačna. Kada govorimo o opštim logovima, podrazumevamo da je zadatak zapravo VM. Ali svoje 'zadace' imaju i proxy i repozitorij. Tamo to može značiti i virtuelni disk, i virtuelnu mašinu, i ceo posao. Dakle, važno je ne izgubiti kontekst.
Veeam %name% Servis (Service): Na korist uspešnih kopija radi nekoliko servisa, čiji spisak možete pronaći u standardnoj alatki. Njihova imena prilično jasno odražavaju njihovu suštinu, ali među jednakima postoji najvažniji — Veeam Backup Service, bez kojeg drugi ne mogu raditi.
VSS: Tehnički, VSS uvek treba označavati Microsoft Volume Shadow Copy Service. U praksi, mnogi ga koriste kao sinonim za Application-Aware Image Processing. Što je, naravno, kategorijski pogrešno, ali to je priča iz domena 'Svaki SUV se može nazvati džipom, i bićeš shvaćen'.
Fantastični logovi i mesta gde obitavaju
Želim započeti ovo poglavlje otkrivanjem velike tajne — koje vreme se prikazuje u logovima?
Zapamtite:
- ESXi uvek zapisuje logove u UTC+0.
- vCenter vodi logove prema vremenu svoje vremenske zone.
- Veeam vodi logove prema vremenu i vremenskoj zoni servera na kojem se nalazi.
- Samo Windows događaji u EVTX formatu nisu vezani ni za šta. Kada se otvore, vreme se preračunava prema računaru na kojem su otvoreni. To je najprikladnija opcija, iako ponekad ima komplikacija. Jedina značajna poteškoća je razlika u lokalima. To je praktično zagarantovani put do nečitljivih logova. Da, postoje načini kako to rešiti, ali hajde da se ne raspravljamo o tome da sve u IT-u funkcioniše na engleskom, i dogovorimo se da uvek postavljamo englesku lokalizaciju na serverima. Molim vas.
Sada ćemo ipak razgovarati o mestima gde žive logovi i kako ih nabaviti. U slučaju VBR postoje dva pristupa.
Prva opcija je pogodna ako nemate želju da pretražujete u ukupnoj gomili datoteka koje se odnose upravo na vaš problem. Za to imamo poseban čarobnjak, kome možete označiti konkretan zadatak i određeni period za koji su vam potrebni logovi. Zatim će on sam pretražiti foldere i skupiti sve što vam je potrebno u jedan arhiv. O tome gde ga tražiti i kako raditi s njim, detaljno je napisano u .
Međutim, čarobnjak ne sakuplja logove svih zadataka i, na primer, u slučaju potrebe da proučite logove restorana, failover-a ili failback-a, vaš put vodi u folder %ProgramData%/Veeam/Backup. To je glavno skladište logova VBR-a, a %ProgramData% je skriveni folder i to je normalno. Usput, kao podrazumevana lokacija može se promeniti pomoću registracijskog ključa tipa REG_SZ: LogDirectory u grani HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication.
Na Linux mašinama logove radnih agenata trebalo bi tražiti u /var/log/VeeamBackup/, ako koristite root ili sudo nalog. Ako nemate takve privilegije, onda tražite logove u /tmp/VeeamBackup.
Za Veeam agent za %OS_name% logove treba tražiti u %ProgramData%/Veeam/Endpoint (ili %ProgramData%/Veeam/Backup/Endpoint) i /var/log/veeam odgovarajuće.
Ako koristite Application-Aware Image Processing (a verovatno ga koristite), situacija se malo komplikuje. Biće vam potrebni logovi našeg helper-a, koji se čuvaju unutar same virtuelne mašine, i VSS logovi. O tome kako i gde doći do ovog blaga, detaljno je napisano u . I, naravno, postoji u vezi s prikupljanjem neophodnih sistemskih logova.
Windows događaje je lako sakupljati prema . Ako koristite Hyper-V, situacija se komplikuje jer će vam biti potrebni i svi njegovi logovi iz grane Applications and Service Logs > Microsoft > Windows. Iako uvek možete ići na prostiji način i jednostavno uzeti sve objekte iz %SystemRoot%\System32\winevt\Logs.
Ako nešto pođe po zlu tijekom instalacije/upgradea, sve potrebne informacije možete pronaći u mapi %ProgramData%/Veeam/Setup/Temp. Iako neću skrivati da se u događajima operativnog sustava mogu naći korisnije informacije nego u ovim logovima. Ostale zanimljive informacije su u %Temp%, ali se uglavnom radi o logovima instalacije pratećeg softvera, poput baze, .Net knjižnica i sličnog. Imajte na umu da se Veeam instalira putem msi, a svi njegovi komponenti također se instaliraju kao zasebni msi paketi, čak i ako to nije prikazano u GUI. Dakle, ako instalacija jedne od komponenti ne uspije, cijela instalacija VBR-a će se zaustaviti. Stoga je potrebno pogledati logove i provjeriti što točno nije uspjelo i u kojem trenutku.
I jedan savjet za kraj: kada dobijete grešku tijekom instalacije, ne žurite pritisnuti OK. Prvo uzmite logove, a zatim pritisnite OK. Tako ćete dobiti log koji se završava u trenutku greške, bez viška informacija na kraju.
Ponekad je potrebno zaviriti u logove vSphere. To je vrlo nezahvalna zadaća, ali kad zasučete rukave, morate raditi i takve stvari. U najjednostavnijem slučaju, trebaju nam logovi sa događajima virtualnog stroja vmware.log, koji se nalaze pored njegovog .vmx datoteke. U složenijem slučaju otvorite Google i pitajte gdje se nalaze logovi za vašu verziju hosta, jer VMware voli mijenjati ta mjesta od izdanja do izdanja. Evo, na primjer, , a ovo je za . Za logove vCenter ponavljamo postupak . U općenitom slučaju, zanimat će nas logovi događaja hosta hostd.log, događaji hostova pod upravljanjem vCenter vpxa.log, logovi jezgre vmkernel.log i logovi autentifikacije auth.log. U najtežim slučajevima može biti koristan i log SSO, koji se nalazi u mapi SSO.
Previše? Zbunjujuće? Zastrašujuće? A to još nije ni polovica informacija s kojima naš tim podrške svakodnevno radi. Tako da su oni zaista sjajni.
Komponente Veeam
I za kraj ovog uvodnog članka malo ćemo razgovarati o komponentama Veeam Backup & Replication. Jer kada tražite uzrok problema, dobro bi bilo razumjeti kako je pacijent strukturiran.
Dakle, kako je svima dobro poznato, Veeam Backup je aplikacija bazirana na SQL-u. To znači da su sve postavke, sve informacije i zapravo sve što je potrebno za normalno funkcioniranje — sve to se nalazi u njegovoj bazi. Tačnije, u dvije baze, ako govorimo o vezi VBR i EM: VeeamBackup i VeeamBackupReporting, redom. Tako to ide: instaliramo još jednu aplikaciju — pojavljuje se još jedna baza. Da ne bismo svi jaja čuvali u jednoj košari.
No, da bi sve to funkcioniralo usklađeno, trebat će nam skup servisa i aplikacija koji će povezati sve komponente u cjelinu. Isključivo za primjer, ovako to izgleda u jednom od mojih laboratorija:
U ulozi glavnog dirigenta nastupa Veeam Backup Service. On je odgovoran za razmjenu informacija s bazama. Također, on pokreće sve zadatke, bavi se orkestracijom dodijeljenih resursa i djeluje kao centar komunikacija za razne konzole, agente i sve ostalo. Ukratko, bez njega definitivno ne može, ali to ne znači da sve radi sam.
U realizaciji zamišljenog pomaže mu Veeam Backup Manager. To nije servis, već entitet koji se bavi pokretanjem poslova i prati proces njihove izvedbe. To su radne ruke backup servisa, koje se povezuj i s hostovima, stvaraju snimke, paze na trajanje i tako dalje.
No, vratimo se popisu servisa. Veeam Broker Service. Pojavio se u v9.5 (i to nije kripto rudara, kao što su tada mislili neki). Bavi se prikupljanjem informacija o VMware hostovima i održavanjem njihovih podataka ažurnim. No, nemojte odmah početi pisati gnjevne komentare da vas špijuniramo i da tražimo sve lozinke/korisničke račune za tašmajora. Sve je malo jednostavnije. Kada pokrenete backup, prvo se morate povezati s hostom i ažurirati sve podatke o njegovoj strukturi. To je prilično sporo i opterećujuće. Samo se sjetite koliko traje operacija prijave putem web sučelja, i zapamtite da se tamo računa samo gornji sloj. A zatim još morate otkriti cijelu hijerarhiju do željenog mjesta, usput rečeno. Ukratko, strašno. Ako pokrećete desetak backupova, svakoj jobi treba proći ovu proceduru. Ako je riječ o velikim infrastrukturnim sistemima, taj proces može potrajati deset minuta ili više. Stoga je donesena odluka da se izdvoji poseban servis za to, preko kojeg uvijek možete dobiti ažurirane informacije. Prilikom pokretanja provjerava i skenira cijelu pridruženu infrastrukturu, a zatim nastoji raditi samo na razini inkrementalnih promjena. Tako da čak i ako pokrećete sto backupova istodobno, svi će zatražiti informacije od našeg brokera, a ne će mučiti hostove svojim zahtjevima. Ako ste zabrinuti za resurse, prema našim proračunima za 5000 virtualnih mašina potrebno je samo oko 100 Mb memorije.
Dalje imamo Veeam Console. Također poznata kao Veeam Remote Console, odnosno Veeam.Backup.Shell. To je taj GUI koji vidimo na snimkama ekrana. Sve je jednostavno i očigledno — konzolu možete pokretati s bilo kojeg mjesta, samo da to bude Windows i da postoji veza do VBR servera. Jedina stvar koju možemo reći: FLR proces će montirati punktove lokalno (tj. na mašini na kojoj je pokrenuta konzola). I raznoliki Veeam Exploreri također će se pokretati lokalno, jer su oni dio konzole. No, ovo me već odvelo u dubine…
Sljedeći zanimljiv servis — Veeam Backup Catalog Data Service. Na popisu usluga poznat je kao Veeam Guest Catalog Service. Bavi se indeksiranjem datotečnih sustava na gostujućim strojevima i puni tim znanjima mapu VBRCatalog. Koristi se samo tamo gdje je uključena oznaka za indeksiranje. A uključiti je smisleno samo ako imate Enterprise Manager. Stoga, iskreni savjet: ne uključujte indeksiranje tek tako, ako nemate EM. Čuvajte svoje nerve i vrijeme podrške.
Također, od drugih važnih usluga valja istaknuti Veeam Installer Service, putem kojeg se vrši isporuka i instalacija potrebnih komponenti na proxyjima, repozitorijima i drugim prolazima. U suštini, on dostavlja potrebne .msi pakete na poslužitelje i provodi njihovu instalaciju.
Veeam Data Mover — uz pomoć pokrenutih na proxyjima (i ne samo) pomoćnih agenata bavi se prebacivanjem podataka. Na primjer, prilikom izrade sigurnosne kopije jedan agent će čitati datoteke s datastorea hosta, dok će drugi pažljivo zapisivati u sigurnosnu kopiju.
Odvojeno želim istaknuti važnu stvar na koju klijenti često reagiraju — to je razlika verzija usluga i informacija u alatima Programs and Features. Da, popis će biti isti, no u verzijama može biti potpuni razdor. To nije baš zdravo s vizualne točke gledišta, no potpuno je normalno ako sve radi stabilno. Na primjer, kod Installer servisa broj verzije znatno zaostaje za susjednim. Horor i katastrofa? Ne, jer se ne reinstalira u cijelosti, već se jednostavno ažurira njegova DLL. U patchu v9.5 U4 dogodila se strašna noćna mora tehničke podrške: prilikom ažuriranja svi su servisi dobili nove verzije, osim najvažnijeg. U patchu U4b transportni servis prestigao je sve ostale čak za dvije verzije (ako sudimo prema brojevima). I to je također normalno — u njemu je pronađen ozbiljan bug, pa je dobio bonus ažuriranje u odnosu na ostale. Stoga, zaključujući: razlika verzija MOŽE biti problem, ali ako razlika postoji, a sve radi ispravno, onda je vjerojatno tako i treba biti. No, nitko vam ne zabranjuje da to razjasnite u tehničkoj podršci.
Ovo su bile takozvane obavezne ili Mandatory usluge. A postoji još cijeli niz pomoćnih, poput Tape Service, Mount Service, vPowerNFS Service i tako dalje.
Za Hyper-V u cjelini je sve isto, samo što postoji specifični Veeam Backup Hyper-V Integration Service i svoj vozač za rad s CBT.
I na kraju ćemo razgovarati o tome tko radi na virtualnim strojima tijekom izradnje sigurnosne kopije. Za pokretanje pre- i post-freeze skripti, za izradu shadow kopija, prikupljanje metapodataka, rad s logovima SQL transakcija i drugo koristi se Veeam Guest Helper. I ako se događa indeksiranje datotečnih sustava, Veeam Guest Indexer . To su privremene usluge koje se pokreću za vrijeme izrade sigurnosne kopije i uklanjaju nakon toga.
U slučaju Linux strojeva, sve je mnogo jednostavnije zbog velikog broja ugrađenih biblioteka i mogućnosti samog sustava. Na primjer, indeksiranje se vrši putem mlocate.
To je za sada sve
Neću vas više mučiti i kratko uvod u unutarnji prostor Veeam smatram završenim. Da, čak ni blizu nismo došli do samih logova, ali vjerujte mi, kako bi informacije predstavljene u njima izgledale koherentno, ovakav uvod je zasigurno potreban. Planiram preći na same logove tek u trećem članku, a plan za sljedeći je objasniti tko generira logove, što je točno u njima prikazano i zašto baš tako, a ne na neki drugi način.
Izvor: habr.com
