Mēs Veeam mīlam žurnālus. Un, tā kā lielākā daļa mūsu risinājumu ir modulāri, tie pieraksta diezgan daudz žurnālu. Tā kā mūsu darbības joma ir jūsu datu drošības garantēšana (t.i., mierīgs miegs), žurnāliem jāfiksē ne tikai katra sīkumu, bet arī jāsniedz pietiekami detalizēta informācija. Tas ir nepieciešams, lai, ja kaut kas notiktu, būtu skaidrs, kā tas notika, kurš ir atbildīgs un ko darīt tālāk. Šeit kā kriminālistikā: nekad nevari zināt, kāda sīkums palīdzēs atrast Loras Palmers slepkavu.
Tāpēc es nolēmu uzsākt rakstu sēriju, kurā secīgi stāstīšu par to, ko mēs rakstām žurnālos, kur mēs tos glabājam, kā nenonākt prātā no to struktūras un ko meklēt tajos.
Kāpēc rakstu sērija un kāpēc neaprakstīt visu uzreiz?
Vienkārši uzskaitīt, kurš žurnāls kur atrodas un kas tajā glabājas — ir diezgan bezjēdzīga ideja. Un doma par šo informācijas atjaunināšanu ir biedējoša. Vienkārša visu iespējamo žurnālu veidu Veeam Backup & Replication uzskaitīšana ir tabula vairākiem lapām ar maziem burtiem. Un tā būs aktuāla tikai izdošanas brīdī, jo pēc nākamā ielāgojuma var parādīties jauni žurnāli, var mainīties glabājamās informācijas loģika vecajos utt. Tāpēc, daudz izdevīgāk būs izskaidrot to struktūru un saturu, kas tajos iekļauts. Tas ļaus labāk orientēties nekā banāla vārdu mācīšanās.
Tādēļ, lai nekristu galvā dziļajos tekstu jūklos, šajā rakstā veiksim sagatavošanas darbus. Tādējādi šodien mēs neiesim iekšā pašos žurnālos, bet skatīsim tos no tālienes: sastādīsim vārdnīcu un nedaudz apspriedīsim Veeam struktūru no žurnālu ģenerēšanas viedokļa.
Vārdnīca un žargonismi
Šeit vispirms jāpiedod krievu valodas tīrības aizstāvjiem un Ožegova vārdnīcas sekotājiem. Mēs visi ļoti mīlam savu dzimto valodu, bet nolādētā IT industrija strādā angļu valodā. Nu, mēs to neizdomājām, tā ir vēstures sakritība. Es neesmu vainīga, tas pats atnāca.
Mūsu nozarē anglicizmu (un žargona) problēma ir ar savām īpatnībām. Kad nevainīgos vārdos, piemēram, "host" vai "viesis", visā pasaulē jau sen tiek saprasti pavisam konkrēti jēdzieni, tad ⅙ daļā sauszemes turpinās varonīgs haoss, ar norādīšanu uz vārdnīcām. Un obligātais arguments "Bet pie mums darbā...".
Ir arī mūsu pašu terminoloģija, kas raksturīga tieši Veeam produktiem, lai gan daži vārdi un frāzes ir kļuvuši populāri. Tāpēc tagad mēs vienosimies, ko katrs termins nozīmē, un turpmāk zem vārda "viesis" es sapratīšu tieši to, kas ir uzrakstīts šajā nodaļā, nevis to, pie kā jūs esat pieraduši savā darbā. Un jā, tas nav personīgi mans kaprīze, tas ir pieņemti terminoloģijas nozares termiņi. Cīnīties ar tiem ir nedaudz bezjēdzīgi. Tomēr es vienmērmu šaubām komentāros.
Diemžēl terminoloģija mūsu darbā un produktos ir ļoti plaša, tāpēc mēģināt uzskaitīt visus es neplānoju. Tikai vissvarīgākie un nepieciešamie informācijas izdzīvošanai par dublēšanas operācijām un žurnāliem. Interesentiem es varu arī kolēģiem par lentēm, kur viņš arī sniedza terminoloģijas sarakstu, kas attiecas uz šo funkcionalitātes daļu.
Host (Host): Virtualizācijas pasaulē tas ir dators ar hipervizoru. Fizisks, virtuāls, mākoņains – nav svarīgi. Ja kaut kas ir uzsācis hipervizoru (ESXi, Hyper-V, KVM utt.), tad to sauc par hostu. Neatkarīgi no tā, vai tas ir klasteris uz desmit rāmjiem vai jūsu klēpjdators ar pusotru virtuālo mašīnu – ja esat palaidis hipervizoru, tad esat kļuvuši par hostu. Jo hipervizors hostē virtuālās mašīnas. Pat ir stāsts, ka VMware kādā laikā vēlējās panākt stingru asociāciju starp vārdu host un ESXi. Bet viņiem neizdevās.
Mūsdienu pasaulē jēdziens "host" praktiski ir saplūdis ar jēdzienu "serveris", kas rada noteiktu neskaidrību saziņā, īpaši, ja runa ir par Windows infrastruktūru. Tāpēc jebkura ierīce, uz kuras atrodas kāds mums interesants serviss, var tikt droši dēvēta par hostu. Piemēram, WinSock žurnālos ar vārdu host tiek atzīmēts viss. Klasisks "Host not found" ir šī piemērs. Tātad izsvērsim no konteksta, bet atcerēsimies — virtualizācijas pasaulē host ir tas, kas hostē viesus (par to divās rindās zemāk).
No vietējām žargoniem (drīzāk akronīmiem, šajā gadījumā) šeit pieminams, ka VMware ir VI, vSphere ir VC, bet Hyper-V ir HV.
Viesis (Guest): Virtuālā mašīna, kas darbojas uz hosta. Te pat nav ko skaidrot, viss ir tik loģiski un vienkārši. Tomēr daudzi centīgi velk šeit kādus citus nozīmes.
Kāpēc? Es nezinu.
Viesu operētājsistēma (Guest OS), attiecīgi, viesu mašīnas operētājsistēma. Un tā tālāk.
Dublēšanas/Replikācijas uzdevums (Backup/Replication Job): Tīri VMware žargonis, kas apzīmē kādu no uzdevumiem. Backup job == Dublēšanas uzdevums. Kā to skaisti iztulkot uz latviešu — neviens nav izdomājis, tāpēc visi saka "uzdevums". Ar uzsvaru uz pēdējo slogu.
Jā, tā vienkārši paņem un saka "uzdevums". Un pat vēstulēs tā raksta, un viss ir labi.
Visādi Dublēšanas darbi, Dublēšanas uzdevumi utt., paldies, bet nē. Vienkārši uzdevums, un jūs tiksiet saprasti. Galvenais — uzsvars uz pēdējo slogu.
Dublēšana (Backup, bēkaps. Patiesiem vecajiem faniem atļauts teikt bakups): Papildus acīmredzamajam (būt rezervē saglabātai datu kopijai), tas nozīmē arī pašu uzdevumu (trīs rindkopas iepriekš, ja jau aizmirsāt), kā rezultātā rasties tas pats dublēšanas fails. Droši vien, angļu valodas runātāji ir pārāk slinki, lai katru reizi teiktu I ran my backup job, tāpēc viņi vienkārši saka I ran my backup, un visi viens otru lieliski saprot. Ieteiktu atbalstīt šo brīnišķīgo iniciatīvu.
Konsolidācija (Consolidate): Termins, kas parādījies ESXi 5.0. Opcija izvēlnē darbam ar snappšotiem, kas uzsāk procesu, lai izdzēstu sauktos orphaned snappšotus. Proti, snappšoti, kas fiziski pastāv, bet izkrituši no redzamu loģisko struktūru. Teorētiski šim procesam nevajadzētu skart menedžerī redzamos snappšotu failus, tomēr gadās visādi. Satura procesa konsolidācija ir tāda, ka dati no snappšota (child disk) tiek ierakstīti galvenajā (parent) diskā. Disku apvienošanas process tiek saukts par mēržošanu (merge). Ja ir dota komanda konsolidēšanai, tad ieraksts par snappšotu var tikt dzēsts no datu bāzes ātrāk, nekā snappšots tiks apvienots un dzēsts. Un, ja snappšota izdzēšana neizdodas kādas iemesla dēļ, tad parādās šie paši orphaned snappšoti. Par darbu ar snappšotiem VMware ir . Un mēs arī kādreiz par viņiem .
Datastore (Stora vai storādžs): Ļoti plaša jēdziena, tomēr virtualizācijas pasaulē to saprot kā vietu, kur tiek glabāti virtuālo mašīnu faili. Taču jebkurā gadījumā šeit ir jāizprot konteksts, un pie mazākajām šaubām jāpaskaidro, ko tieši jūsu sarunu biedrs domājis.
Proxy (Proksi): Svarīgi saprast, ka Veeam Proxy nav gluži tas pats, ar ko esam pieraduši saskarties internetā. Veeam produktu kontekstā tas ir kāda būtība, kas nodarbojas ar datu pārsūtīšanu no vienas vietas uz citu. Ja neiedziļināmies detaļās, tad VBR ir komandu serveris, bet proksi ir tā darba zirgi. Proksi ir dators, caur kuru plūst trafiks, un uz kuru ir uzstādīti VBR komponenti, kas palīdz šo trafiku pārvaldīt. Piemēram, pārsūtīt datus no viena kanāla uz citu vai vienkārši pieslēgt diskus (HotAdd režīmā).
Repository (Repotis): Tehniski tas ir vienkārši ieraksts VBR datubāzē, kas norāda uz vietu, kur glabājas dublējumi, un kā pie šīs vietas piekļūt. Faktiski tas var būt gan vienkārša CIFS koplietošanas mape, gan atsevišķs disks, serveris vai mākoņa spainis. Atkal esam kontekstā, bet saprotam, ka repository ir vienkārši vieta, kur atrodas jūsu dublējumi.
Snapshot (Snaops): Oksfordas gramatikas mīļotāji dod priekšroku runāt par to kā snaEpšot vai snaEpšot, tomēr neizglītotā vairums uzvar, pateicoties lielākai masai. Ja kāds nezina – tā ir tehnoloģija, kas ļauj atjaunot diska stāvokli noteiktā brīdī. To var izdarīt, pāradresējot I/O operācijas no galvenā diska – tad tas tiek saukts par RoW (Redirect on Write) snaapsi – vai nu pārvietojot pārrakstāmos blokos no jūsu diska uz citu – tas tiks saukts par CoW (Copy on Write) snaapsi. Tieši šo funkciju plašās pielietošanas iespējas ļauj Veeam veikt savu dublēšanas maģiju. Strikti runājot, ne tikai viņiem, bet tas ir tuvāko laidienos.
ESXi dokumentācijā un žurnālos ap šo terminu valda haoss, un kontekstā, kurā tiek pieminēti snapshots, var sastapt gan pašus snapshots, gan redo log, un pat delta disks. Veeam dokumentācijā šādas neskaidrības nav, un snapshots ir snapshots, bet redo log ir tieši REDO fails, ko izveidojis neatkarīgs non-persistent disks. REDO faili tiek dzēsti, kad virtuālā mašīna tiek izslēgta, tāpēc tos sajaukt ar snapshots ir ceļš uz izgāšanos.
Sintētisks (Sintētika): Sintētiskie backupi pieder pie reverse incremental un forever forward backupiem. Ja jūs vēl neesat saskārušies ar šo terminu, tad tas ir viens no mehānismiem, ko izmanto, lai veidotu backup ķēdi. Tomēr žurnālos var sastapt arī terminu Transform, kas tiek izmantots pilnu kopiju izveidē no inkrementiem (sintētiskais pilnais).
Uzdevums (Uzdevums): Tas ir katras atsevišķas mašīnas apstrādes process darba iecelšanā. Proti: ja jums ir backup darba iecelšana, kurā ir iekļautas trīs mašīnas. Tātad, katra mašīna tiks apstrādāta katra sava uzdevuma ietvaros. Tā rezultātā būs četri žurnāli: viens pamatžurnāls darba iecelšanai un trīs uzdevumiem. Tomēr šeit ir viens svarīgs nianses: laika gaitā vārds "uzdevums" ir kļuvis par pārāk daudznozīmīgu. Kad runājam par kopējiem žurnāliem, mēs domājam, ka uzdevums ir tieši VM. Taču savi "uzdevumi" ir arī proxy un glabātuvē. Tur tas var nozīmēt gan virtuālo disku, gan virtuālo mašīnu, gan visu darba iecelšanu. Tātad ir svarīgi nezaudēt kontekstu.
Veeam %name% Pakalpojums (Pakalpojums): Uz veiksmīgu backupu labklājību strādā vairāki pakalpojumi, kuru sarakstu var atrast standartajā rīkā. To nosaukumi pietiekami caurspīdīgi atspoguļo to būtību, tomēr starp līdzīgiem ir vissvarīgākais — Veeam Backup Service, bez kura pārējie nedarbosies.
VSS: Tehniski VSS vienmēr jāapzīmē ar Microsoft Volume Shadow Copy Service. Faktiski to izmanto daudzi kā sinonīmu Application-Aware Image Processing. Kas, protams, ir kategoriski nepareizi, tomēr tā ir stāsts no kategorijas "Jebkuru SUV var saukt par džipu, un tevi sapratīs".
Fantastiski žurnāli un vietas, kur tās apdzīvo
Vēlos sākt šo nodaļu ar lielās noslēpuma atklāšanu — kāds laiks tiek rādīts žurnālos?
Atcerieties:
- ESXi vienmēr raksta žurnālus UTC+0.
- vCenter reģistrē žurnālus pēc sava laika zonas.
- Veeam reģistrē žurnālus pēc laika un laika zonas serverī, uz kura tas ir uzstādīts.
- Un tikai Windows notikumi EVTX formātā nav piesaistīti nekam. Atverot, laiks tiek pārrēķināts atbilstoši datoram, uz kura tos atver. Tas ir visērtākais variants, lai gan reizēm ir grūtības arī ar to. Vienīgā jūtamā grūtība ir lokalizācijas atšķirības. Tas ir praktiski garantēts ceļš uz nesalasāmiem žurnāliem. Jā, ir varianti, kā to risināt, bet vienkārši nepieķersimies tam, ka viss IT strādā angļu valodā, un vienosimies vienmēr iestatīt serveros angļu valodas lokalizāciju. Lūdzu.
Tagad tomēr runāsim par vietām, kur dzīvo žurnāli un kā tos iegūt. VBR gadījumā ir divi pieejas veidi.
Pirmais variants ir piemērots, ja jums nav vēlēšanās meklēt kopējā kaudzē failus, kas tieši attiecas uz jūsu problēmu. Tam mums ir atsevišķs vednis, kuram varat norādīt konkrētu darbu un konkrētu laika periodu, par kuru jums vajadzīgi žurnāli. Vēlāk tas pats izskenēs mapītes un saliks visu nepieciešamo vienā arhīvā. Par to, kur to meklēt un kā ar to strādāt, sīkāk aprakstīts .
Tomēr vednis apkopo žurnālus nevis visu darbu un, piemēram, ja nepieciešams pētīt restorāna, failover vai failback žurnālus, tad ceļš ved uz mapīti %ProgramData%/Veeam/Backup. Tas ir galvenais VBR žurnālu glabātava, un %ProgramData% ir slēgta mape, un tas ir normāli. Starp citu, noklusējuma vietu var pārdēvēt, izmantojot reģistra atslēgu tipa REG_SZ: LogDirectory HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication nodaļā.
Linux mašīnās darba aģentu žurnālus jāmeklē /var/log/VeeamBackup/, ja tiek izmantota root vai sudo konts. Ja jums šādu privilēģiju nav, tad meklējiet žurnālus /tmp/VeeamBackup.
Veeam aģentam %OS_name% žurnāli jāsameklē %ProgramData%/Veeam/Endpoint (vai %ProgramData%/Veeam/Backup/Endpoint) un /var/log/veeam atbilstoši.
Ja izmantojat Application-Aware Image Processing (un, visticamāk, jūs to izmantojat), situācija nedaudz sarežģījas. Jums būs nepieciešami mūsu palīga žurnāli, kas glabājas pašā virtuālajā mašīnā, un VSS žurnāli. Par to, kā un kur iegūt šo laimi, sīkāk aprakstīts . Un, protams, ir par nepieciešamo sistēmas žurnālu apkopošanu.
Windows notikumus ērti apkopot saskaņā ar . Ja jūs izmantojat Hyper-V, tas sarežģī jautājumu, jo jums būs nepieciešami arī visi tā žurnāli no Applications and Service Logs > Microsoft > Windows. Tomēr vienmēr varat izvēlēties aplamu ceļu un vienkārši paņemt visus objektus no %SystemRoot%System32winevtLogs.
Ja, ja ir kaut kas, kas sabojājas instalācijas / uzlabojuma laikā, tad visu nepieciešamo var atrast mapē %ProgramData% / Veeam / Setup / Temp. Lai gan es nevēlos slēpt, ka OS notikumos var atrast noderīgāku informāciju nekā šajos žurnālos. Viss interesantais atrodas %Temp%, bet tur galvenokārt ir saistītā programmatūras instalācijas žurnāli, piemēram, datu bāzes, .Net bibliotēkas un citi. Ņemiet vērā, ka Veeam tiek instalēts no msi, un visi tā komponensti tiek instalēti kā atsevišķi msi pakotnes, pat ja tas nav atspoguļots GUI. Tādējādi, ja kāda komponenta instalācija neizdodas, visa VBR instalācija tiks apturēta. Tāpēc ir jāiet uz žurnāliem un jāpārbauda, kas tieši salūza un kurā brīdī.
Un dzīves hacks noslēgumā: saņemot kļūdu instalācijas laikā, nesteidzieties nospiest OK. Vispirms paņemiet žurnālus, tad nospiediet OK. Tādējādi jūs iegūsiet žurnālu, kas beidzas kļūdas brīdī, bez liekā satura beigās.
Un ir tā, ka dažreiz ir jāiet uz vSphere žurnāliem. Tas ir ļoti nepatīkams darbs, bet, uzsukot piedurknes, nākas to darīt un ne tikai to. Visvienkāršākajā variantā mums būs nepieciešami žurnāli ar virtuālās mašīnas notikumiem vmware.log, kas atrodas blakus tās .vmx failam. Sarežģītākā gadījumā atveram Google un jautājam, kur atrodas žurnāli jūsu viesu versijai, jo VMware mīl šo vietu mainīt no izlaišanas uz izlaišanu. Šeit, piemēram, , bet šeit ir . Attiecībā uz vCenter žurnāliem atkārtojam procedūru . Bet vispārīgi mūs interesēs hosta notikumu žurnāli hostd.log, vCenter pārvaldīto hostu notikumi vpxa.log, kodola žurnāli vmkernel.log un autentifikācijas žurnāli auth.log. Nu un visgrūtākajos gadījumos var noderēt SSO žurnāls, kas atrodas SSO mapē.
Apgrūtinoši? Jauki? Bailīgi? Bet tas pat nav puse informācijas, ar kuru strādā mūsu atbalsts ikdienā. Tāpēc viņi tiešām ir ļoti forši.
Veeam komponenti
Un kā noslēgumu šim ievada rakstam nedaudz parunāsim par Veeam Backup & Replication komponentiem. Jo, kad meklējiet sāpju cēloni, ir labi saprast, kā ir iekārtots pacients.
Tātad, kā visiem noteikti ir zināms, Veeam Backup ir tā sauktais SQL balstīts lietojums. Proti, visas iestatījumi, visa informācija un viss, kas nepieciešams normālai darbībai, ir tā datubāzē. Vai, precīzāk sakot, divās datubāzēs, ja runājam par VBR un EM salikumu: VeeamBackup un VeeamBackupReporting atbilstoši. Tā tas ir izveidojies: uzstādām vēl vienu lietojumu — parādās vēl viena datubāze. Lai neuzglabātu visus olas vienā grozā.
Taču, lai viss šis bizness darbotos saskaņoti, mums nepieciešams pakalpojumu un lietojumu kopums, kas savienos visus komponentus kopā. Izņēmuma gadījumā, lūk, kā tas izskatās vienā no manām laboratorijām:
Galvenā diriģenta lomā ir Veeam Backup Service. Tieši viņš ir atbildīgs par informācijas apmaiņu ar datubāzēm. Tāpat viņš ir atbildīgs par visu uzdevumu uzsākšanu, nodrošinot izdalīto resursu orķestrāciju un darbojas kā saziņas centrs dažādām konsolēm, aģentiem un citiem elementiem. Vārdu sakot, bez viņa noteikti nekas nesanāks, taču tas absolūti nenozīmē, ka viņš visu veic pats.
Plānotā izpildē viņam palīdz Veeam Backup Manager. Tas nav pakalpojums, bet entitāte, kas nodarbojas ar uzdevumu uzsākšanu un uzrauga to izpildes procesu. Darba rokas backup service, ar kurām viņš pieslēdzās hostiem, izveido snapshotus, uzrauga retenciju un tā tālāk.
Taču atgriezīsimies pie pakalpojumu saraksta. Veeam Broker Service. Parādījās v9.5 (un tas nav kriptovalūtu ieguves programmatūra, kā to toreiz domāja daži). Tas apkopo informāciju par VMware hostiem un nodrošina tās aktualitāti. Bet nesteidzieties rakstīt dusmīgus komentārus, ka mēs jūs špiono un leakojam visus lietotājdatus/ parole taču. Viss ir nedaudz vienkāršāk. Kad jūs uzsākat dublēšanu, vispirms ir jāpieslēdzas hostam un jāatjaunina visi dati par tā struktūru. Tas ir diezgan lēns un apjomīgs process. Vienkārši atcerieties, cik ilgi jums ilgst pieslēgšanās operācija caur tīmekļa saskarni, un ņemiet vērā, ka tur tiek skaitīts tikai augšējais slānis. Un pēc tam vēl ir jāatver visa hierarhija līdz nepieciešamajai vietai, starp citu. Vārdu sakot, šausmas. Ja jūs uzsākat desmit dublējumus, katrai darbībai būs jāveic šī procedūra. Ja runa ir par lielām infrastruktūrām, tad šis process var aizņemt desmit minūtes un vairāk. Tāpēc tika pieņemts lēmums izveidot atsevišķu pakalpojumu, caur kuru vienmēr varēs iegūt aktuālu informāciju. Tas starta brīdī pārbauda un skenē visu pievienoto infrastruktūru, pēc tam cenšas strādāt tikai ar inkrementālām izmaiņām. Tātad pat ja jums tiks palaisti simts dublējumi vienlaikus, tie visi pieprasīs informāciju no mūsu brokera, nevis mocīs hostus ar saviem pieprasījumiem. Ja uztraucaties par resursiem, tad pēc mūsu aprēķiniem 5000 virtuālajām mašīnām ir vajadzīgas apmēram 100 Mb atmiņas.
Tālāk mums ir Veeam Console. Tas ir Veeam Remote Console, tas ir Veeam.Backup.Shell. Tas ir tieši tas GUI, ko mēs redzam ekrānuzņēmumos. Viss ir vienkārši un acīmredzami — konsoli var palaist no jebkuras vietas, kamēr tā ir Windows un ir savienojums ar VBR serveri. Vienīgais, ko var teikt: FLR process montēs punktus lokāli (t.i., uz mašīnas, kurā palaista konsole). Un dažādie Veeam Explorers arī tiks palaisti lokāli, jo viņi ir konsoles daļa. Bet tas jau mani aizved uz citiem tematiem…
Nākamais interesantais pakalpojums — Veeam Backup Catalog Data Service. Serviss ir pazīstams kā Veeam Guest Catalog Service. Tas indeksē failu sistēmas viesmašīnās un piepilda ar šīm zināšanām VBRCatalog mapīti. Tas tiek izmantots tikai tad, ja ir ieslēgta indeksēšanas opcija. Un to ir jēga ieslēgt tikai tad, ja jums ir Enterprise Manager. Tāpēc, no sirds iesaku: neslēdziet indeksēšanu vienkārši tāpat, ja jums nav EM. Saglabājiet nervus un atbalsta laiku.
No citiem svarīgiem pakalpojumiem jāatzīmē Veeam Installer Service, ar kura palīdzību notiek nepieciešamo komponentu piegāde un uzstādīšana proxy, krātuves un citu vārteju sistēmās. Patiesībā tas piegādā nepieciešamos .msi paketes uz serveriem un veic to instalēšanu.
Veeam Data Mover — izmantojot uz proxy (un ne tikai) izpildāmus palīgaprīkus, nodarbojas ar datu pārvietošanu. Piemēram, veicot dublēšanu, viens aģents lasīs failus no hosta datu krātuves, bet otrs tos rūpīgi ierakstīs dublējumā.
Atsevišķi jāatzīmē svarīga lieta, uz kuru bieži reaģē klienti — tas ir pakalpojumu un informācijas versiju atšķirības Programmas un funkcijas rīkā. Jā, saraksts būs vienāds, bet versijās var būt pilnīgs juceklis. Tas nav ļoti patīkami vizuāli, tomēr pilnībā normāli, ja viss strādā stabilitāti. Piemēram, Installer pakalpojumā versijas numurs ievērojami atpaliek no blakus esošajiem. Šausmas? Nē, jo tas netiek pilnībā pārinstalēts, bet vienkārši tiek atjauninātas tā DLL. V9.5 U4 ielā liela tehniskā atbalsta murgu atjaunināšanas laikā visas pakalpojumu versijas bija jaunas, izņemot galveno. U4b, transporta pakalpojums apsteidza visus pārējos pat par divām versijām (ja spriež pēc skaitļiem). Un tas arī ir normāli — tajā tika atrasta nopietna kļūda, tāpēc tas saņēma bonusu atjauninājumu attiecībā pret citiem. Tāpēc, apkopojot, versiju atšķirības VAR būt problēma, bet, ja atšķirība ir, un viss darbojas pareizi, tad, visticamāk, tā tiešām ir nepieciešama. Bet neviens jums neaizliedz to precizēt tehniskajā atbalstā.
Tā bija tā sauktā obligātā vai Mandatory pakalpojumi. Bet ir arī vesela virkne palīgpakalpojumu, piemēram, Tape Service, Mount Service, vPowerNFS Service un tā tālāk.
Hyper-V gadījumā viss ir tāds pats, tikai ir specifisks Veeam Backup Hyper-V Integration Service un savs draiveris CBT darbībai.
Un un beigā mēs runāsim, kas strādā ar virtuālajām mašīnām dublēšanas laikā. Pre- un post-freeze skriptu palaišanai, šedou kopijai, metadatu apkopošanai, SQL darījumu žurnālu apstrādei un citiem procesiem tiek izmantots Veeam Guest Helper. Un, ja notiek failu sistēmu indeksēšana, Veeam Guest Indexer . Tie ir pagaidu pakalpojumi, kas tiek izveidoti dublēšanas laikā un noņemti pēc tam.
Jaunās Linux mašīnās viss ir daudz vienkāršāk, pateicoties daudzajiem iebūvētajiem bibliotēkām un paša sistēmas iespējām. Piemēram, indeksēšana tiek veikta, izmantojot mlocate.
Uz šo brīdi viss.
Negribu jūs vairāk mocīt un īsi uzskatu, ka ievads Veeam iekšējās struktūrās ir noslēdzies. Jā, mēs patiesībā pat tuvu netikām līdz pašiem žurnāliem, bet ticiet man, lai informācija, kas tajos ir, neizklausītos kā bezsakara apziņas plūsma, šāds ievads noteikti ir nepieciešams. Par pašu žurnālu es plānoju runāt tikai trešajā rakstā, bet nākamais plāns ir izskaidrot, kurš ģenerē žurnālus, kas tieši tajos tiek attēlots un kāpēc tieši tā, nevis citādi.
Avots: habr.com
