Me Veeamis meeldib logisid jälgida. Kuna enamik meie lahendustest on moodulaarne, kirjutavad nad üsna palju logisid. Ja kuna meie tegevusvaldkond on teie andmete turvalisuse tagamine (st teie rahu öösel), peavad logid mitte ainult fikseerima iga väikese detaili, vaid ka tegema seda piisavalt detailselt. See on vajalik selleks, et vajaduse korral mõista, kuidas miski juhtus, kes oli süüdi ja mida edasi teha. Siin on nagu kriminaalinduktsioonis: kunagi ei tea, missugune pisiasi aitab sul Lorale Palmerele mõrvari leida.
Seetõttu otsustasin kirjutada artiklite seeria, kus järkjärgult räägin sellest, mida me logidesse kirjutame, kus me neid salvestame, kuidas mitte hulluks minna nende struktuurist ja mida nende seest otsida.
Miks just artiklite seeria ja miks mitte kõik korraga kirjeldada?
Lihtsalt loetleda, kus logid asuvad ja mida need sisaldavad, on üsna keeruline ettevõtmine. Ja mõte selle teabe ajakohasena hoidmisest on isegi hirmutav. Kõikide Veeam Backup & Replication logitüüpide loetlemine tähendaks mitme lehe paksuse peene kirja tabeli koostamist. Ja see oleks aktuaalne ainult avaldamise hetkel, kuna järgmise plaastri ilmumisega võivad tekkida uued logid, muutuda vana teabe salvestamise loogika jne. Seetõttu on palju kasulikum selgitada nende struktuuri ja selles sisalduva teabe olemust. See aitab paremini orienteeruda, kui lihtsalt nimede pähe õppimine.
Seetõttu, et mitte hüpata pea ees tekstilisse sügavikku, teeme selles artiklis eeltöö. Seega täna ei sukelduda logidesse endasse, vaid lähme kaugelt: koostame glossaariumi ja arutame natuke Veeami struktuuri logide genereerimise seisukohalt.
Glossaar ja žargoon
Siin tasub kõigepealt vabandada vene keele austajate ja Ožegovi sõnaraamatu tunnistajate ees. Me kõik armastame oma emakeelt, kuid neetud IT-tööstus töötab inglise keeles. See ei olnud meie valik, vaid ajaloos nii kujunes. Mina ei ole süüdi, ta tuli ise (c)
Meie valdkonnas on anglicismide (ja žargooni) probleemil oma eripära. Kui süütute sõnade nagu «host» või «külaline» taga mõistetakse juba ammu midagi väga konkreetset, siis ⅙ osa maast on endiselt kangelaslik segadus ja segadus sõnaraamatutesse viimiseks. Ja rangelt kohustuslik argument «Aga meil tööl...».
Lisaks on meil puhtalt oma terminoloogia, mis on omane just Veeami toodetele, kuigi mõned sõnad ja väljendid on juba rahva sekka jõudnud. Seega lepime nüüd kokku, mida iga termin tähendab, ja edaspidi mõtlen ma sõna «külaline» all just seda, mis on selles peatükis kirjas, mitte seda, millega olete harjunud oma töös. Ja jah, see ei ole isiklikult minu kapriis, need on tööstuses kehtestatud terminid. Nendega võitlemine on mõttetult vaevaline. Kuigi kommentaarides ma olen alati arutelu poolt.
Kahjuks on meie töös ja toodetes väga palju termineid, seega ei hakka ma neid kõiki loetlema. Ainult kõige baasemad ja vajalikud, et ellu jääda infomeres varukoopiate ja logide kohta. Huvi korral võin ka kolleegide poolt lintide kohta, kus ta tõi välja ka terminite nimekirja, mis on seotud selle funktsionaalsuse osaga.
Host (Host): Virtuaalsete süsteemide maailmas on see masin, kus töötab hüperviisor. Füüsiline, virtuaalne, pilv — pole vahet. Kui hüperviisor (ESXi, Hyper-V, KVM jne) on millegi peal käimas, siis nimetatakse seda "millegiks" hostiks. Olgu see klaster kümne serveriga või teie sülearvuti, kus on poolteist virtuaalmasinat — kui hüperviisor töötab, siis olete saanud hostiks. Sest hüperviisor hostib virtuaalmasinaid. On isegi vahelugemine, et VMware soovis kunagi saavutada tugevat seost sõna host ja just ESXi vahel. Kuid nad ei suutnud.
Tänapäeva maailmas on mõisted «host» ja «server» praktiliselt kokku sulanud, mis tekitab suhtlemisel teatavat segadust, eriti kui räägime Windowsi infrastruktuurist. Seega võib igasugust masinat, millel asub meie jaoks huvitav teenus, julgelt nimetada hostiks. Näiteks WinSocki logides tähistatakse sõnaga host kõike, mis ette satub. Klassikaline näide on «Host not found». Seega lähtu kontekstist, aga peame meeles — virtualiseerimise maailmas on host see, kes majutab külalisi (sellest räägin kahe lause pärast).
Siinsetest lokaalsetest slängidest (pigem akronüümidest) võib tuua näiteks, et VMware on VI, vSphere on VC ja Hyper-V on HV.
Külastaja (Guest): Virtuaalne masin, mis töötab hostil. Siin ei ole isegi vaja selgitada, kõik on nii loogiline ja selge. Siiski toovad paljud siia sisse erinevaid tähendusi.
Miks? Ma ei tea.
Guest OS, vastavalt siis külalismasina operatsioonisüsteem. Ja nii edasi.
Varundamine/Replikatsiooni Ülesanne (Backup/Replication Job): Puhas VMware släng, mis tähistab ühte ülesannet. Backup job == Varundamise Ülesanne. Kuidas seda eesti keelde ilusasti tõlkida, pole keegi välja mõelnud, seega kõik räägivad „ülesanne”. Rõhk viimasele silbile.
Jah, nii lihtsalt öeldakse 'job'. I isegi kirjutatakse seda kirjadese, ja kõik on hästi.
Igast sorti varukoopiate tööd, varukoopiaülesanded jne, aitäh, aga pole vaja. Lihtsalt job, ja teid mõistetakse. Peamine on panna rõhk viimasel silbil.
Backup (varukoopia, bäkup. Tõeliste vintage-huviliste seas on lubatud ka bakUp): Lisaks ilmsele (kusagil asuvate andmete varukoopia), tähistab see ka iseeda tööd (kolm rida ülalpool, kui olete juba unustanud), mille tulemusel see varukoopiafail ilmub. Tõenäoliselt on inglise keele emakeele rääkijad liiga laisad, et iga kord öelda 'I ran my backup job', seega nad lihtsalt ütlevad 'I ran my backup', ja kõik saavad üksteisest suurepäraselt aru. Soovitan toetada seda imelist algatust.
Consolidate (Konsolideerimine): Termin, mis ilmus ESXi 5.0-s. Menüü valik, mis haldab snapshots'i, käivitab nii-öelda mahajäänud snapshots'ide eemaldamise protsessi. Nii et snapshots'id, mis füüsiliselt eksisteerivad, kuid on kadunud kuvatusest. Teoreetiliselt ei peaks see protsess mõjutama snapshots'i halduris kuvatavaid faile, kuid juhtub ka igasuguseid asju. Konsolideerimise protsessi tuum on see, et snapshots'ist (child disk) andmed kirjutatakse peamisele (parent) kettale. Ketaste ühendamise protsess on tuntud kui merge. Kui on antud konsolideerimise käsk, võib teave snapshots'i kohta kustutada andmebaasist enne, kui snapshots on kokku liidetud ja eemaldatud. Ja kui snapshots'i ei õnnestu mingil põhjusel eemaldada, siis ilmuvad need samad mahajäänud snapshots'id. VMware-l on snapshots'ide haldamise kohta . Ja meie oleme ka sellest .
Datastore (Säilitamine või salvestamine): Väga lai mõisted, kuid virtualiseerimise maailmas mõistetakse selle all kohta, kus hoitakse virtuaalmasinate faile. Kuid iga juhul on oluline mõista konteksti väga täpselt ja väikseimagi kahtluse korral selgitada, mida teie vestluskaaslane täpselt silmas pidas.
Proxy (Proksi): Oluline on kohe selgeks teha, et Veeam Proxy ei ole just see, millega oleme harjunud interneti avarustes. Veeami toodete raames on see omamoodi üksus, mis tegeleb andmete liigutamisega ühest kohast teise. Kui mitte liiga süvitsi minna, siis VBR on juhtserver ja proxy on selle tööhobused. Proxy on seade, mille kaudu voolab liiklus ja kuhu on paigaldatud VBR komponendid, mis aitavad liiklust juhtida. Näiteks andmete edastamine ühest kanalist teise või lihtsalt ketaste (HotAdd režiim)ühendamine.
Repository (Repository): Tehniliselt on see lihtsalt VBR andmebaasi sissekanne, mis näitab kohta, kus varukoopiad asuvad, ja kuidas sellele kohale ühenduda. Tegelikult võib see olla lihtsalt CIFS kaust või eraldi ketas, server või pilve ämbter. Jällegi, me oleme kontekstis, aga mõistame, et repository on lihtsalt koht, kus teie varukoopiad asuvad.
Snapshot (Snapshot): Oxfordi grammatikahuvilised eelistavad rääkida kas snäppshotist või snäppshotist, kuid kirjaoskamatu enamus võidab suurema massi tõttu. Kes ei tea — see on tehnoloogia, mis võimaldab taastada kettaseisundi kindlal aj momentil. Seda tehakse kas ajutise I/O operatsioonide suunamise teel peamisest kettast kõrval — seda nimetatakse RoW (Redirect on Write) snäppshotiks — või kirjutatavate blokke eemaldamise teel teie kettalt teisele — seda nimetatakse CoW (Copy on Write) snäppshotiks. Just tänu nende funktsioonide laiale rakendamisvõimele suudab Veeam täita oma varunduse maagia. Täpselt öeldes, mitte ainult nemad, vaid ka eelseisvad väljaanded.
ESXi dokumentatsioonis ja logides valitseb selle termini ümber kaos, ning snäppshotte mainides võib kohata nii snäppshotte, redo logi kui ka delta ketast. Veeami dokumentatsioonis sellist segadust ei esine, ja snäppshot on snäppshot, samas kui redo log on just REDO fail, mis on loodud sõltumatu mitte-püsiva kettaga. REDO failid eemaldatakse virtuaalkeskkonna väljalülitamisel, nii et nende segamine snäppshotidega viib kukkumiseni.
Süntetiline (Synthetic): Sünteetilised varukoopiad kuuluvad tagasipööratud inkrementaalsete ja igavese edasiviimise varukoopiate alla. Kui te pole selle terminiga varem kokku puutunud, siis see on lihtsalt üks mehhanism, mida kasutatakse varukoopiate ahela ümberkujundamiseks. Logides võib aga kohata ka mõistet Transform, mida kasutatakse täisteede loomise raames inkrementidest (synthetic full).
Ülesanne (Task): See on iga eraldi masina töötlemise protsess tööülesande raames. See tähendab: teil on varukoopia tööülesanne, kuhu on lisatud kolm masinat. Seega töödeldakse iga masinat eraldi tööülesandena. Kokku saab neli logi: üks põhine tööülesande kohta ja kolm tööülesannete kohta. Siiski on siin oluline nüanss: aja jooksul on sõna „tööülesanne” muutunud liiga mitmeti mõistetavaks. Kui räägime üldisest logidest, siis mõistame, et tööülesanne on just VM. Kuid ka proksil ja salvestusruumis on omad „töötlemised”. Seal võib see tähendada nii virtuaalset kettast, virtuaalset masinat kui ka kogu tööülesannet. Seega on oluline konteksti mitte kaotada.
Veeam %name% Teenus (Service): Mitmete teenuste, mille loetelu on standardvarustus, toetab edukate varukoopiate tegemist. Nende nimed peegeldavad nende olemust, kuid nende seas on üks kõige olulisem — Veeam Backup Service, ilma milleta teised ei tööta.
VSS: Tehniliselt peaks VSS alati tähendama Microsoft Volume Shadow Copy Service. Tegelikult kasutatakse seda paljuski sünonüümina Application-Aware Image Processing'ule. Mis on muidugi kategooriliselt vale, kuid see on lugu, milles "iga maastur võib olla džipp ja sind mõistetakse".
Fantastilised logid ja nende elupaigad
Soovin alustada seda peatükki suurte saladuste paljastamisega — mis kellaaega logides näidatakse?
Meeles pidama:
- ESXi kirjutab logid alati UTC+0.
- vCenter salvestab logid oma ajavööndi ajaga.
- Veeam salvestab logid serveri aja ja ajavööndi järgi, kus see asub.
- Ja ainult Windowsi sündmused EVTX formaadis ei ole millegagi seotud. Avamisel arvutatakse aeg ümber selle masina järgi, millel neid avatakse. See on kõige mugavam variant, kuigi ka sellega võivad esineda raskused. Ainuke märkimisväärne probleem on lokaalide erinevus. See on peaaegu garanteeritud tee mitte loetavatesse logidesse. Jah, on variante, kuidas seda parandada, aga las jääb, et kõik IT-sektoris töötab inglise keeles, ja lepime kokku, et seadistame serveritel alati ingliskeelse lokaali. Palun.
Nüüd räägime kohtadest, kus logid asuvad ja kuidas neid hankida. VBR juhtumi puhul on kaks lähenemist.
Esimene variant sobib, kui teil ei ole soov leida oma murega seotud faile suurest hulgast. Selleks on meil eraldi viisard, kuhu saab sisestada konkreetse töö ja konkreetse perioodi, mille jooksul logisid vajate. Edasi jookseb see ise mööda kaustasid ja kogub kõik vajaliku ühte arhiivi. Kuidas seda otsida ja kuidas sellega töötada, on üksikasjalikult kirjas .
Kuid viisard kogub logisid mitte kõigi ülesannete kohta ja näiteks juhul, kui on vaja uurida restorani, failover'i või failback'i logisid, viib teie tee kausta %ProgramData%/Veeam/Backup. See on peamine logide salvestuskoht VBR-is, ning %ProgramData% on peidetud kaust, mis on normaalne. Muide, vaikeasukohta saab muuta registrivõtme REG_SZ abil: LogDirectory HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication harus.
Linuxi masinatel tuleb tööagentide logisid otsida kaustastvar/log/VeeamBackup/, kui kasutatakse root- või sudo-kontot. Kui selliseid privileege ei ole, siis otsige logisid kaustast /tmp/VeeamBackup.
Veeam agent for %OS_name% logisid tuleb otsida kaustast %ProgramData%/Veeam/Endpoint (või %ProgramData%/Veeam/Backup/Endpoint) ja /var/log/veeam vastavalt.
Kui kasutate rakendusele toetuvat pilditöötlust (mis tõenäoliselt on nii), siis olukord on veidi keerulisem. Teil on vaja meie abistaja logisid, mis on salvestatud virtuaalkeskkonda, ning VSS logisid. Kuidas ja kust neid hankida, on põhjalikult kirjeldatud . Ja loomulikult on olemas tööriistade komplekt süsteemsete logide kogumiseks.
Windowsi sündmusi on mugav koguda vastavalt . Kui kasutate Hyper-V-d, siis on olukord keerulisem, kuna vajate ka kõiki selle logisid jaotuses Applications and Service Logs > Microsoft > Windows. Kuigi alati on võimalik minna lihtsamat teed ja lihtsalt võtta kõik objektid kaustast %SystemRoot%System32winevtLogs.
Kui teil tekib midagi paigaldamise/uuendamise ajal viga, siis leiate kogu vajaliku informatsiooni kaustast %ProgramData%/Veeam/Setup/Temp. Kuigi ma ei varja, et operatsioonisüsteemi üritustes on rohkem kasulikku teavet kui nendes logides. Ülejäänud huvitav info asub %Temp%-kaustas, kuid seal on enamasti installimise logid kaasneva tarkvara, näiteks andmebaasi, .Net raamatukogude jms kohta. Pidage meeles, et Veeam installitakse msi kaudu, ja kõik selle komponentide installerid installitakse ka eraldi msi pakettidena, isegi kui see ei olnud GUI-s näidatud. Seega, kui ühe komponendi installimine ebaõnnestub, peatub kogu VBR-i installimine. Seetõttu tuleb minna logidesse ja vaadata, mis täpselt läks katki ja millal.
Ja viimane näpunäide: kui saate installimise ajal vea, siis ärge kiirustage OK-nuppu vajutama. Esiteks võtke logid, siis vajutage OK. Nii saate veateate logi, mis lõpeb veahetkel, ilma, et seal oleks lõpus prügi.
On occasion, it becomes necessary to dig into the vSphere logs. It’s a thankless task, but rolling up your sleeves, you have to do even more challenging work. In the simplest case, we need the logs with the events from vmware.log, which are located next to its .vmx file. In more complex situations, we open Google and ask where the logs for your host version are located, as VMware loves to change this depending on the release. For example, , and here for . For vCenter logs, we repeat the procedure . But generally, we will be interested in the host event logs hostd.log, events of hosts managed by vCenter vpxa.log, kernel logs vmkernel.log, and authentication logs auth.log. In the most advanced cases, you might also need the SSO log, which is found in the SSO folder.
Cumbersome? Confusing? Scary? Yet, this is not even half of the information our support team works with daily. So they are truly impressive.
Veeam Components
As a conclusion to this introductory article, let’s discuss the components of Veeam Backup & Replication. Because when you are searching for the causes of problems, it’s good to understand how the patient is structured.
Nii et, nagu kõik teavad, on Veeam Backup SQL-põhine rakendus. See tähendab, et kõik seadistused, kogu teave ja kõik, mis on vajalik normaalseks toimimiseks, asub selle andmebaasis. Täpsemalt kahes andmebaasis, kui räägime VBR ja EM paarist: VeeamBackup ja VeeamBackupReporting, vastavalt. Nii on see välja kujunenud: kui paigaldame veel ühe rakenduse, lisandub veel üks andmebaas. Et mitte hoida kõiki mune ühes korvis.
Aga et see kõik sujuvalt toimiks, on meil vaja rida teenuseid ja rakendusi, mis ühendavad kõik komponendid. Näiteks, nii see minu ühes laboris välja näeb:
Peamise dirigendina tegutseb Veeam Backup Service. Just tema vastutab andmebaasidega teabe vahetamise eest. Samuti käivitab ta kõik ülesanded, tegeleb eraldatud ressursside orkestreerimisega ning töötab mitmesuguste konsoolide, agentide ja muu vahelise suhtluskeskusena. Ütlematagi selge, et ilma temata ei saa kuidagi, kuid see ei tähenda, et ta teeks kõike üksi.
Tema kavandatu teostamisel aitab Veeam Backup Manager. See ei ole teenus, vaid üksus, mis tegeleb tööde käivitamise ja nende täitmise protsessi jälgimisega. Backup teenuse tööriistad, millega see ühendub hostidega, loob snapshots, jälgib hoidmise tingimusi ja nii edasi.
Aga naaseme teenuste loendi juurde. Veeam Broker Service. Ilmus v9.5 (ja see ei ole krüptokaevandaja, nagu mõned tookord arvasid). Tegeleb VMware hostide teabe kogumise ja selle ajakohasena hoidmisega. Kuid ärge tõttake kohe vihaselt kommenteerima, et me teid nuhime ja kõik teie sisselogimised/paroolid taustajuhile saadame. Asjad on veidi lihtsamad. Kui käivitate varunduse, peate esmalt ühendust võtma hostiga ja värskendama kogu teavet selle struktuuri kohta. See on üsna aeglane ja tülikas protsess. Simply remember how long it takes to log in through the web interface, and bear in mind that only the top layer is considered. And then you still need to expand the entire hierarchy to the required location, by the way. In a word, awful. If you are running a dozen backups, then each job needs to go through this procedure. If it’s about large infrastructures, this process can take ten minutes or more. Therefore, the decision was made to allocate a separate service for this, through which always current information can be obtained. At startup, it checks and scans the entire added infrastructure, and then tries to operate only at the level of incremental changes. So even if you have a hundred backups starting simultaneously, they will all request information from our broker instead of tormenting the hosts with their queries. If you are concerned about resources, our calculations show that for 5000 virtual machines, only about 100 Mb of memory is needed.
Edasi liikudes Veeam Console. Samuti tuntud kui Veeam Remote Console, Veeam.Backup.Shell. See on see GUI, mida me näeme ekraanipiltidel. Kõik on lihtne ja selge — konsooli saab käivitada igaühes, oluline on, et see oleks Windows ja oleks ühendus VBR serveriga. Ainus asi, mida võib öelda: FLR protsess mountib punktid kohalikult (st masinasse, kus konsool on käivitatud). Samuti käivitatakse erinevad Veeam Explorers kohalikult, kuna need on osa konsoolist. Kuid see viib mind juba sügavamatesse detaljidesse…
Järgmine huvitav teenus — Veeam Backup Catalog Data Service. Teenuste nimekirjas tuntud kui Veeam Guest Catalog Service. Tegutseb külalismasinate failisüsteemide indekseerimisega ja täidab nende teadmistest kausta VBRCatalog. Kasutatakse ainult seal, kus on aktiveeritud indekseerimise kast. Selle aktiveerimine on mõttekas ainult juhul, kui teil on Enterprise Manager. Seetõttu soovitus südame põhjast: ärge aktiveerige indekseerimist lihtsalt niisama, kui teil pole EM-i. Hoidke oma närve ja toe aega.
Samuti tasub ära märkida teised olulised teenused Veeam Installer Service, millega toimub vajalike komponentide edastamine ja installatsioon proksides, hoidlatest ja teistest väravatest. Tegelikult toob see vajalikud .msi paketid serveritesse ning teostab nende installatsiooni.
Veeam Data Mover — käivitatavate abiteenuste kaudu proksides (ja mujal) tegeleb andmete edasiviimisega. Näiteks varundamise korral loeb üks teenus faile hosti andmekeskkonnast, samas kui teine kirjutab need hoolikalt varukoopia.
Erinevat versioonid teenustest ja teabest, mida kuvab Programs and Features, on asi, millele kliendid tihti tähelepanu pööravad. Jah, nimekiri on sama, kuid versioonides võib olla täielik segadus. See ei ole visuaalselt just meeldiv, kuid on täiesti normaalne, kui kõik töötab stabiilselt. Näiteks Installer teenusel on versiooni number tugevalt maha jäänud kõrvalolevatest. Kohutav? Ei, sest see ei installita täielikult uuesti, vaid lihtsalt uuendatakse selle DLL-i. Patchis v9.5 U4 toimus tehnilise toe õudusunenägu: kõigil teenustel olid uued versioonid, välja arvatud kõige olulisemal. Patchis U4b ületas transportteenus teised koguni kahe versiooniga (numbrite järgi). Ja see on samuti normaalne — seal leiti tõsine viga, seega sai see boonuseks värskenduse võrreldes teistega. Kokkuvõtteks: versioonide erinevus võib olla probleem, kuid kui erinevus on olemas ja kõik töötab korralikult, siis tõenäoliselt nii peabki olema. Aga keegi ei keela teil seda tehniliselt toelt üle küsida.
Need on nnidatud kohustuslikud või Mandatory teenused. Lisaks on palju abiteenuseid, nagu Tape Service, Mount Service, vPowerNFS Service jne.
Hyper-V puhul kehtib põhimõtteliselt sama, kuid on mõned spetsiifilised Veeam Backup Hyper-V Integration Service ja oma draiver CBT töö jaoks.
Lõpuks räägime, kes töötab virtuaalmasinates varundamise ajal. Pre- ja post-freeze skriptide käivitamiseks, varjutavate koopiate loomiseks, metainfo kogumiseks, SQL tehingu logidega töötamiseks jne kasutatakse Veeam Guest Helper. Kui toimub failisüsteemide indekseerimine, Veeam Guest Indexer . Need on ajutised teenused, mis käivitatakse varundamise ajaks ja kustutatakse pärast seda.
Linux masinate puhul on kõik oluliselt lihtsam, kuna süsteemil on palju sisseehitatud teeke ja funktsioone. Näiteks indekseerimine toimub läbi mlocate.
Sellega on hetkel kõik.
Ma ei kinkinud teid enam ning lühidalt Veeam'i all oleva teema on lõpuks lõpetatud. Jah, me ei ole isegi lähedale jõudnud logide juurde, kuid uskuge mind, et teave, mis neis esitatakse, ei muutuks juhuslikuks mõttekäiguks, on selline sissejuhatus äärmiselt vajalik. Logide juurde plaanin ma minna alles kolmandas artiklis, kuid järgmise artikli plaan on selgitada, kes logisid genereerib, mis täpselt neis kajastub ja miks just nii, mitte kuidagi teisiti.
Allikas: habr.com
