A Veeam ens encanten els registres. I com que la majoria de les nostres solucions són modulars, escriuen molts registres. I com que l'abast de la nostra activitat és garantir la seguretat de les vostres dades (és a dir, un son reparador), els registres no només haurien de registrar cada esternut, sinó que també ho haurien de fer amb cert detall. Això és necessari perquè en cas d'alguna cosa quedi clar com va passar aquest "què", qui té la culpa i què s'ha de fer després. És com en la ciència forense: mai saps quina petita cosa t'ajudarà a trobar l'assassí de Laura Palmer.
Per això, vaig decidir fer un swing a una sèrie d'articles, on parlaré seqüencialment del que escrivim als troncs, on els guardem, com no tornar-se boig amb la seva estructura i què buscar-hi dins.
Per què una sèrie d'articles i per què no descriure-ho tot alhora?
Simplement enumerar quin registre és on i què s'hi emmagatzema és una tasca força desastrosa. I fa por fins i tot pensar a mantenir aquesta informació actualitzada. Una llista senzilla de tots els tipus de registres possibles a Veeam Backup & Replication és una taula en diversos fulls en lletra petita. Sí, i només serà rellevant en el moment de la publicació, perquè. quan s'alliberi el següent pedaç, poden aparèixer nous registres, canviarà la lògica de la informació emmagatzemada en els antics, etc. Per tant, serà molt més rendible explicar-ne l'estructura i l'essència de la informació que hi conté. Això us permetrà navegar millor pels llocs que l'amuntegament banal de noms.
Per tant, per no precipitar-nos a la piscina de fulls de text, fem un treball preparatori en aquest article. Per tant, avui no entrarem en els registres en si, sinó que anirem de lluny: compilarem un glossari i parlarem una mica de l'estructura de Veeam pel que fa a la generació de registres.
Glossari i argot
Aquí, en primer lloc, val la pena demanar perdó als defensors de la puresa de la llengua russa i als testimonis del diccionari d'Ozhegov. Tots estimem molt la nostra llengua materna, però la maleïda indústria informàtica opera en anglès. Bé, no ens ho vam plantejar, però va passar històricament. No és culpa meva, va venir ell mateix (c)
En el nostre negoci, el problema dels anglicismes (i l'argot) té les seves pròpies particularitats. Quan sota paraules innocents com "amfitrió" o "convidat", el món sencer ha entès coses molt específiques durant molt de temps, aleshores a la ⅙ de la terra continua la confusió heroica i la sorpresa amb la ficció en els diccionaris. I l'argument estrictament obligatori "Però a la nostra feina...".
A més, hi ha purament la nostra terminologia, que és inherent als productes Veeam, tot i que algunes paraules i frases han anat a la gent. Per tant, ara ens posarem d'acord sobre quin terme significa què, i en el futur, sota la paraula "convidat", vull dir exactament el que està escrit en aquest capítol, i no a què esteu acostumats a la feina. I sí, aquest no és el meu caprici personal, són termes ben establerts en el sector. Combatre'ls és una mica inútil. Encara que sempre estic a favor de relaxar-me als comentaris.
Malauradament, hi ha molts termes al nostre treball i productes, així que no intentaré enumerar-los tots. Només la informació més bàsica i necessària sobre còpies de seguretat i registres per a la supervivència al mar. Per als interessats, també puc col·legues sobre cintes, on també va donar una llista de termes relacionats amb aquesta part de la funcionalitat.
Amfitrió (amfitrió): En el món de la virtualització, aquesta és una màquina amb un hipervisor. Físic, virtual, núvol: no importa. Si alguna cosa està executant un hipervisor (ESXi, Hyper-V, KVM, etc.), aquest "alguna cosa" s'anomena host. Tant si es tracta d'un clúster amb deu bastidors com del vostre ordinador portàtil amb un laboratori per a una màquina virtual i mitja, si vau llançar un hipervisor, us convertiu en un amfitrió. Perquè l'hipervisor allotja màquines virtuals. Fins i tot hi ha una història que en un moment VMware va voler aconseguir una associació ferma de la paraula host amb ESXi. Però ella no ho va fer.
En el món modern, el concepte "amfitrió" pràcticament s'ha fusionat amb el concepte de "servidor", cosa que genera certa confusió a la comunicació, sobretot quan es tracta d'infraestructura de Windows. Així, qualsevol màquina que allotja algun servei del nostre interès es pot anomenar amfitrió amb seguretat. Per exemple, als registres de WinSock tot està marcat amb la paraula host. El clàssic "No s'ha trobat l'amfitrió" n'és un exemple. Per tant, partim del context, però recordeu: al món de la virtualització, un amfitrió és el que allotja els hostes (més sobre això en dues línies a continuació).
Des de l'argot local (més aviat sigles, en aquest cas), aquí es recorda que VMware és VI, vSphere és VC i Hyper-V és HV.
Convidat (convidat): La màquina virtual que s'executa a l'amfitrió. Aquí no hi ha res a explicar, tot és tan lògic i senzill. Tanmateix, molts arrosseguen aquí amb diligència alguns altres significats.
Per a què? No ho sé.
OS convidat, respectivament, el sistema operatiu de la màquina convidada. Etcètera.
Treball de còpia de seguretat/replicació (jobA): Argot pur de Wim, que denota algunes de les tasques. Feina de còpia de seguretat == Feina de còpia de seguretat. Ningú no ha sabut com traduir-lo bé al rus, així que tothom diu "JobA". Amb èmfasi en l'última síl·laba.
Sí, simplement l'agafen i diuen "joba". I fins i tot a les cartes escriuen així, i tot està bé.
Tot tipus de tasques de còpia de seguretat, tasques de còpia de seguretat, etc., gràcies, però no cal. Només una feina, i t'entendràs. El més important és posar l'accent a l'última síl·laba.
Còpia de seguretat (còpia de seguretat, còpia de seguretat. Per als veritables vells, es permet la còpia de seguretat): A més de l'obvi (una còpia de seguretat de les dades que es troben en algun lloc), també significa la feina en si (tres línies més amunt, si ja ho heu oblidat), com a resultat de la qual apareix el fitxer de còpia de seguretat. Probablement, els senyors parlants nadius d'anglès són massa mandrós per dir que he executat la meva tasca de còpia de seguretat cada vegada, així que només diuen que he fet la meva còpia de seguretat i tothom s'entenen perfectament. Us convido a donar suport a aquesta meravellosa iniciativa.
Consolidar (consolidar): Un terme que va aparèixer a ESXi 5.0 Una opció al menú d'instantànies que inicia el procés d'eliminació de les anomenades instantànies orfes. És a dir, instantànies que estan disponibles físicament, però que han caigut fora de l'estructura lògica mostrada. En teoria, aquest procés no hauria d'afectar els fitxers que es mostren al gestor d'instantànies, però pot passar qualsevol cosa. L'essència del procés de consolidació és que les dades de la instantània (disc secundari) s'escriuen al disc principal (parent). El procés de combinació de discos s'anomena fusió. Si s'ha emès una ordre de consolidació, el registre de la instantània es pot eliminar de la base de dades abans de fusionar i suprimir la instantània. I si la instantània no es pot suprimir per qualsevol motiu, apareixen aquestes mateixes instantànies òrfenes. Sobre el treball amb instantànies, VMware té . I també en parlem d'alguna manera .
Magatzem de dades (emmagatzematge o emmagatzematge): Un concepte molt ampli, però en el món de la virtualització, s'entén com un lloc on s'emmagatzemen els fitxers de les màquines virtuals. Però, en qualsevol cas, aquí cal entendre el context molt clarament i, amb el més mínim dubte, aclarir què tenia exactament al cap el teu interlocutor.
Proxy (proxy): És important entendre immediatament que Veeam Proxy no és el mateix al que estem acostumats a Internet. Dins dels productes Veeam, es tracta d'una mena d'entitat que s'ocupa de la transferència de dades d'un lloc a un altre. Si no entreu en detalls, llavors VBR és un servidor d'ordres i control, i els servidors intermediaris són els seus cavalls de batalla. És a dir, un proxy és una màquina per on flueix el trànsit i en la qual s'instal·len components VBR que ajuden a dirigir aquest trànsit. Per exemple, per transferir dades d'un canal a un altre, o simplement per enganxar els discos a si mateix (mode HotAdd).
Repositori (Repositori): Tècnicament, això és només una entrada a la base de dades VBR, que indica el lloc on s'emmagatzemen les còpies de seguretat i com connectar-se a aquest lloc. De fet, pot ser només una bola CIFS o un disc, servidor o cub separat al núvol. De nou, estem en context, però entenem que un repositori és només un lloc on hi ha les vostres còpies de seguretat.
Instantània (SnapshOt): Els amants de la gramàtica d'Oxford prefereixen dir qui és instantània i qui és instantània, però la majoria analfabeta es beneficia de la massa més gran. Si algú no ho sap, es tracta d'una tecnologia que permet restaurar l'estat d'un disc en un moment determinat. Això es fa ja sigui redirigint temporalment les operacions d'E/S fora del disc principal; llavors s'anomenarà instantània RoW (Redirect on Write) o movent blocs reescrivibles del vostre disc a un altre; això s'anomenarà CoW (Copy on Write). ) instantània. És gràcies a les àmplies possibilitats d'utilitzar aquestes funcions que Veeam pot fer la seva màgia de còpia de seguretat. En sentit estricte, no només ells, sinó que aquest és el tema dels propers llançaments.
Hi ha un caos al voltant d'aquest terme a la documentació i els registres d'ESXi, i en el context d'esmentar instantànies, podeu trobar instantànies en si mateixes, i refer el registre, i fins i tot el disc delta. La documentació de Veeam no conté aquesta llàgrima, i una instantània és una instantània, i un registre de refer és exactament un fitxer REDO creat per un disc independent no persistent. Els fitxers REDO s'eliminen quan s'apaga la màquina virtual, de manera que confondre'ls amb instantànies és un camí cap al fracàs.
Sintètics (sintètics): Les còpies de seguretat sintètiques són còpies de seguretat incrementals inverses i avançades per sempre. En cas que no us trobeu amb aquest terme, és només un dels mecanismes utilitzats per construir una transformació de la cadena de còpia de seguretat. Tanmateix, als registres també podeu trobar el concepte de transformació, que s'utilitza en el marc de la creació de còpies completes a partir d'increments (complet sintètic).
Tasca (Tasca): Aquest és el procés de processament de cada màquina individual dins del treball. És a dir: tens una tasca de còpia de seguretat, que inclou tres màquines. Això vol dir que cada cotxe es processarà com a part d'una tasca independent. En total, hi haurà quatre registres: el principal de feines i tres de tasques. No obstant això, aquí hi ha un matís important: amb el temps, la paraula "tasca" s'ha tornat innecessàriament ambigua. Quan parlem de registres generals, volem dir que una tasca és exactament una màquina virtual. Però hi ha "tasques" tant al proxy com al repositori. Allà pot significar un disc virtual, una màquina virtual i tota la feina. És a dir, és important no perdre el context.
Servei Veeam %name%: Per a les còpies de seguretat reeixides, funcionen diversos serveis alhora, una llista dels quals es pot trobar a l'equip estàndard. Els seus noms reflecteixen de manera bastant transparent la seva essència, però entre iguals hi ha el més important: Veeam Backup Service, sense el qual la resta no funcionarà.
VSS: Tècnicament, VSS sempre hauria de significar Microsoft Volume Shadow Copy Service. De fet, molts l'utilitzen com a sinònim de processament d'imatges sensibles a l'aplicació. La qual cosa, per descomptat, és categòricament incorrecte, però aquesta és una història de la categoria "Qualsevol SUV es pot anomenar jeep, i us entendreu".
Troncs fantàstics i on viuen
Vull començar aquest capítol revelant el gran secret: quina hora es mostra als registres?
Recordeu:
- ESXi sempre escriu els registres a UTC+0.
- vCenter manté els registres segons l'hora de la seva zona horària.
- Veeam manté els registres per hora i zona horària del servidor on es troba.
- I només els esdeveniments de Windows en format EVTX no pateixen vinculació a res. Quan s'obren, es torna a calcular l'hora del cotxe en què es van obrir. L'opció més convenient, tot i que hi ha dificultats. L'única dificultat tangible és la diferència de llocs. Aquest és un camí pràcticament garantit als registres il·legibles. Sí, hi ha opcions per tractar-ho, però no discutim amb el fet que tot en TI funciona en anglès i acceptem que sempre s'estableixi la configuració regional de l'anglès als servidors. Oh si us plau.
Ara parlem dels llocs on viuen els troncs i de com aconseguir-los. En el cas de VBR, hi ha dos enfocaments.
La primera opció és adequada si no teniu ganes de buscar fitxers a la pila general que estiguin relacionats específicament amb el vostre problema. Per fer-ho, disposem d'un assistent separat, al qual podeu especificar una feina concreta i un període específic per al qual necessiteu registres. A continuació, repassarà les carpetes i posarà tot el que necessiteu en un sol arxiu. A on cercar-lo i com treballar-hi es descriu detalladament a .
Tanmateix, l'assistent no recull els registres de totes les tasques i, per exemple, si necessiteu estudiar els registres de la restauració, la migració per error o la recuperació per error, el vostre camí es troba a la carpeta %ProgramData%/Veeam/Backup. Aquesta és la botiga de logotips de VBR principal i %ProgramData% és una carpeta oculta i això està bé. Per cert, la ubicació predeterminada es pot reassignar mitjançant la clau de registre del tipus REG_SZ: LogDirectory a la branca de còpia de seguretat i replicació HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam.
A les màquines Linux, els registres de l'agent de treball s'han de buscar a /var/log/VeeamBackup/si utilitzeu un compte root o sudo. Si no teniu aquests privilegis, cerqueu els inicis de sessió /tmp/VeeamBackup.
Per a l'agent Veeam per a %OS_name% s'han de cercar els registres %ProgramData%/Veeam/Endpoint (O %ProgramData%/Veeam/Backup/Endpoint) I /var/log/veeam respectivament.
Si utilitzeu el processament d'imatges sensible a l'aplicació (i molt probablement ho feu), la situació es complica una mica. Necessitareu els registres del nostre ajudant, que s'emmagatzemen a la pròpia màquina virtual, i els registres de VSS. Sobre com i on aconseguir aquesta felicitat, està escrit detalladament a . I és clar que n'hi ha per recollir els registres del sistema necessaris.
Els esdeveniments de Windows es recullen convenientment segons . Si utilitzeu Hyper-V, les coses es compliquen més, ja que també necessitareu tots els seus registres des de la branca d'Aplicacions i serveis > Microsoft > Windows. Tot i que sempre podeu anar pel camí més estúpid i simplement recollir tots els objectes de %SystemRoot%System32winevtLogs.
Si alguna cosa es trenca durant la instal·lació/actualització, tot el que necessiteu es pot trobar a la carpeta %ProgramData%/Veeam/Setup/Temp. Tot i que no amagaré el fet que als esdeveniments del sistema operatiu podeu trobar més informació útil que en aquests registres. La resta d'interessants es troba a %Temp%, però principalment hi ha registres d'instal·lació de programari relacionat, com ara la base, les biblioteques .Net i altres coses. Tingueu en compte que Veeam s'instal·la des de msi i tots els seus components també s'instal·len com a paquets msi separats, encara que això no es mostrés a la GUI. Per tant, si la instal·lació d'un dels components falla, s'aturarà tota la instal·lació de VBR. Per tant, heu d'entrar als registres i veure què es va trencar exactament i en quin moment.
I, finalment, un truc de vida: si rebeu un error durant la instal·lació, no us preneu a fer clic a D'acord. Primer agafem els registres i després feu clic a D'acord. D'aquesta manera obtindreu un registre que acaba en el moment de l'error, sense escombraries al final.
I passa que necessiteu entrar als registres de vSphere. L'ocupació és molt ingrata, però, arremangats les mànigues, cal fer una altra cosa. En la versió més senzilla, necessitem registres amb esdeveniments de màquina virtual vmware.log, que es troben al costat del seu fitxer .vmx. En un cas més difícil, obriu Google i pregunteu on es troben els registres de la vostra versió d'amfitrió, ja que a VMware li encanta canviar aquest lloc d'una versió a una altra. Per exemple, , però per . Per als registres de vCenter, repetiu el procediment . Però, en general, estarem interessats en els registres d'esdeveniments de l'amfitrió hostd.log, els esdeveniments de l'amfitrió gestionats per vCenter vpxa.log, els registres del nucli vmkernel.log i els registres d'autenticació auth.log. Bé, en els casos més descuidats, el registre SSO, que es troba a la carpeta SSO, pot ser útil.
Feixuc? Confós? Por? Però aquesta no és ni la meitat de la informació amb la qual treballa el nostre suport diàriament. Així que són molt, molt xulos.
Components Veeam
I com a conclusió d'aquest article introductori, parlem una mica dels components de Veeam Backup & Replication. Perquè quan busqueu la causa del dolor, estaria bé entendre com funciona el pacient.
Així, com probablement tothom sap, Veeam Backup és una anomenada aplicació basada en SQL. És a dir, tota la configuració, tota la informació i, en general, tot el que només és necessari per al funcionament normal, tot això es troba a la seva base de dades. O millor dit, en dues bases de dades, si estem parlant d'un munt de VBR i EM: VeeamBackup i VeeamBackupReporting, respectivament. I així va passar: vam posar una altra aplicació -apareix una altra base de dades. Per no emmagatzemar tots els ous en una cistella.
Però perquè tota aquesta economia funcioni sense problemes, necessitem un conjunt de serveis i aplicacions que uneixin tots els components. Només com a exemple, aquest és el que sembla en un dels meus laboratoris:
Actua com a director en cap Servei de còpia de seguretat de Veeam. És ell qui s'encarrega de l'intercanvi d'informació amb les bases. També és responsable de llançar totes les tasques, d'orquestrar els recursos assignats i de treballar com una mena de centre de comunicacions per a una varietat de consoles, agents i tota la resta. En una paraula, definitivament no hi ha manera sense ell, però això no vol dir en absolut que ho faci tot ell mateix.
L'ajuda en el compliment del seu pla Gestor de còpies de seguretat de Veeam. No es tracta d'un servei, sinó d'una entitat que llança treballs i supervisa el procés de la seva execució. Les mans de treball del servei de còpia de seguretat, amb les quals es connecta als amfitrions, crea instantànies, supervisa la retenció, etc.
Però tornem a la llista de serveis. Servei de broker Veeam. Va aparèixer a la v9.5 (i això no és un miner criptogràfic, com alguns van pensar aleshores). Recull informació sobre els amfitrions de VMware i manté la seva rellevància. Però no corri immediatament a escriure comentaris enutjats que us estem espiant i filtrant tots els inicis de sessió / contrasenyes al taschmajor. Tot és una mica més senzill. Quan feu una còpia de seguretat, el primer que heu de fer és connectar-vos a l'amfitrió i actualitzar totes les dades sobre la seva estructura. Aquesta és una història bastant lenta i feixuga. Només recordeu el temps que trigueu a iniciar sessió a través de la interfície web i recordeu que només s'hi compta la capa superior. I llavors encara heu d'obrir tota la jerarquia al lloc correcte, per cert. En una paraula, horror. Si feu una dotzena de còpies de seguretat, cada treball ha de fer aquest procediment. Si estem parlant de grans infraestructures, aquest procés pot durar deu minuts o més. Per això, es va decidir destinar-hi un servei a part, a través del qual es podrà rebre informació sempre actualitzada. A l'inici, comprova i escaneja tota la infraestructura afegida i, a continuació, intenta funcionar només a nivell de canvis incrementals. Així, fins i tot si feu un centenar de còpies de seguretat al mateix temps, tots demanaran informació al nostre corredor i no turmentaran els amfitrions amb les seves peticions. Si us preocupen els recursos, segons els nostres càlculs, 5000 màquines virtuals només necessiten uns 100 Mb de memòria.
A continuació tenim Consola Veeam. És Veeam Remote Console, és Veeam.Backup.Shell. Aquesta és la mateixa GUI que veiem a les captures de pantalla. Tot és senzill i obvi: la consola es pot llançar des de qualsevol lloc, sempre que sigui Windows i hi hagi una connexió al servidor VBR. L'únic que es pot dir és que el procés FLR muntarà punts localment (és a dir, a la màquina on s'executa la consola). Bé, una varietat de Veeam Explorers també s'executarà localment, perquè formen part de la consola. Però ja m'ha portat a la natura...
Un altre servei interessant és Servei de dades de catàleg de còpia de seguretat de Veeam. Conegut com Veeam Guest Catalog Service a la llista de serveis. Es dedica a indexar sistemes de fitxers en màquines convidades i omple la carpeta VBRCatalog amb aquest coneixement. Només s'utilitza quan la casella de selecció d'indexació està habilitada. I només té sentit activar-lo si teniu Enterprise Manager. Per tant, un consell des del fons del meu cor: no activeu la indexació així si no teniu EAT. Estalvieu els vostres nervis i temps de suport.
També d'altres serveis importants cal destacar Servei d'instal·lador Veeam, amb l'ajuda del qual es lliuren i s'instal·len els components necessaris en servidors intermediaris, repositoris i altres passarel·les. De fet, porta els paquets .msi necessaris als servidors i els instal·la.
Veeam Data Mover - amb l'ajuda d'agents auxiliars llançats en proxies (i no només) es dedica a desplaçar dades. Per exemple, quan es fa una còpia de seguretat, un agent llegirà fitxers del magatzem de dades de l'amfitrió i el segon els escriurà amb cura a la còpia de seguretat.
Per separat, m'agradaria assenyalar una cosa important a la qual sovint reaccionen els clients: aquesta és la diferència en les versions dels serveis i la informació al complement Programes i funcions. Sí, la llista serà la mateixa, però les versions poden ser completament discordants. No és molt xulo des del punt de vista visual, però és del tot normal si tot funciona de manera estable. Per exemple, per al servei d'instal·lador, el número de versió està molt per darrere dels veïns. Horror i malson? No, perquè no es reinstal·la completament, però simplement s'actualitza la seva DLL. Al pegat v9.5 U4, es va produir un malson de suport tècnic: durant l'actualització, tots els serveis van rebre noves versions, excepte la més important. En el pegat U4b, el servei de transport va superar tots els altres en dues versions (a jutjar pels números). I això també és normal: s'hi va trobar un error greu, de manera que va rebre una actualització de bonificació respecte a la resta. Per tant, per resumir-ho: les diferències de versió PODEN ser un problema, però si hi ha una diferència i tot funciona correctament, probablement ho hauria de ser. Però ningú us prohibeix aclarir-ho al suport tècnic.
Aquests eren els anomenats serveis obligatoris o Obligatoris. I hi ha un munt d'auxiliars, com ara Tape Service, Mount Service, vPowerNFS Service, etc.
Per a Hyper-V, en general, tot és igual, només que n'hi ha un específic Servei d'integració de Veeam Backup Hyper-V i el teu propi conductor per treballar amb CBT.
I al final, parlem de qui treballa a les màquines virtuals durant la còpia de seguretat. Per executar scripts abans i després de la congelació, per crear una còpia d'ombra, recopilar metadades, treballar amb registres de transaccions SQL, etc. Ajudant convidat de Veeam. I si els sistemes de fitxers estan indexats, Indexador convidat de Veeam . Es tracta de serveis temporals desplegats durant la durada de la còpia de seguretat i eliminats després d'aquesta.
En el cas de les màquines Linux, tot és molt més senzill a causa de la presència d'un gran nombre de biblioteques integrades i de les capacitats del propi sistema. Per exemple, la indexació es fa mitjançant mlocate.
Això és tot per ara
No m'atreveixo a fer-te mal més curt Considero que s'ha acabat la introducció al compartiment del motor Veeam. Sí, ni tan sols ens hem acostat als caus en si, però creieu-me, perquè la informació que s'hi presenten no sembli un corrent de consciència incoherent, aquesta introducció és absolutament necessària. Tinc la intenció d'anar als propis registres només al tercer article, i el pla per al següent és explicar qui genera els registres, què es mostra exactament en ells i per què exactament, i no d'una altra manera.
Font: www.habr.com