Sa Veeam, mahilig kami sa mga log. At dahil ang karamihan sa aming mga solusyon ay modular, nagsusulat sila ng napakaraming log. At dahil ang saklaw ng aming aktibidad ay upang matiyak ang kaligtasan ng iyong data (ibig sabihin, mahimbing na pagtulog), hindi lang dapat i-record ng mga log ang bawat pagbahin, ngunit gawin din ito sa ilang detalye. Ito ay kinakailangan upang kung may mangyari ay malinaw kung paano ito "ano" nangyari, sino ang dapat sisihin, at kung ano ang kailangang gawin sa susunod. Parang sa forensics: hindi mo alam kung anong maliit na bagay ang tutulong sa iyo na mahanap ang pumatay kay Laura Palmer.
Samakatuwid, nagpasya akong maglunsad ng isang serye ng mga artikulo kung saan palagi kong pag-uusapan kung ano ang isinulat namin sa mga log, kung saan namin iniimbak ang mga ito, kung paano hindi mabaliw sa kanilang istraktura at kung ano ang hahanapin sa loob ng mga ito.
Bakit isang serye ng mga artikulo at bakit hindi ilarawan ang lahat nang sabay-sabay?
Ang simpleng paglilista kung aling log ang matatagpuan kung saan at kung ano ang nakaimbak dito ay isang medyo nakapipinsalang ideya. At nakakatakot na isipin ang tungkol sa pagpapanatiling napapanahon ang impormasyong ito. Ang isang simpleng listahan ng lahat ng posibleng uri ng mga log sa Veeam Backup & Replication ay isang talahanayan ng ilang mga sheet sa maliit na print. At ito ay magiging may kaugnayan lamang sa oras ng paglalathala, dahil... Kapag ang susunod na patch ay inilabas, ang mga bagong log ay maaaring lumitaw, ang lohika ng nakaimbak na impormasyon sa mga luma ay magbabago, atbp. Samakatuwid, magiging mas kapaki-pakinabang na ipaliwanag ang kanilang istraktura at ang kakanyahan ng impormasyong nakapaloob sa kanila. Ito ay magbibigay-daan sa iyo upang mas mahusay na mag-navigate sa mga lugar kaysa sa karaniwang pag-cramming ng mga pangalan.
Samakatuwid, upang hindi magmadali sa pool ng mga text sheet, gawin natin ang ilang gawaing paghahanda sa artikulong ito. Samakatuwid, ngayon hindi namin susuriin ang mga log sa kanilang sarili, ngunit pupunta mula sa malayo: mag-iipon kami ng isang glossary at tatalakayin nang kaunti ang istraktura ng Veeam mula sa punto ng view ng pagbuo ng mga log.
Glossary at jargon
Dito, una sa lahat, ito ay nagkakahalaga ng paghingi ng tawad sa mga kampeon ng kadalisayan ng wikang Ruso at ang mga saksi ng diksyunaryo ni Ozhegov. Mahal na mahal nating lahat ang ating katutubong wika, ngunit gumagana sa Ingles ang mapanghamak na industriya ng IT. Buweno, hindi namin ito naisip, ngunit ganito ang nangyari sa kasaysayan. Hindi ko kasalanan, siya mismo ang dumating (c)
Sa aming negosyo, ang problema ng Anglicisms (at jargon) ay may sariling mga detalye. Kapag sa pamamagitan ng mga inosenteng salita tulad ng "host" o "panauhin" ay matagal nang naiintindihan ng buong mundo ang napaka-espesipikong mga bagay, pagkatapos ay sa β ng lupain ang kabayanihan na pagkalito at paglaboy-laboy sa pagsundot sa mga diksyunaryo ay nagpapatuloy. At ang mahigpit na obligadong argumento "Ngunit sa aming trabaho ...".
Dagdag pa, mayroon lamang ang aming terminolohiya, na partikular na likas sa mga produkto ng Veeam, kahit na ang ilang mga salita at parirala ay naging popular. Samakatuwid, ngayon ay magkakasundo tayo sa kung ano ang ibig sabihin ng termino, at sa hinaharap, sa pamamagitan ng salitang "panauhin" ay eksaktong ibig sabihin ko kung ano ang nakasulat sa kabanatang ito, at hindi kung ano ang nakasanayan mo sa trabaho. And yes, this is not my personal whim, these are well-established terms in the industry. Ito ay medyo walang kabuluhan upang labanan ang mga ito. Kahit na palagi akong pabor na maging mabait sa mga komento.
Sa kasamaang palad, maraming mga termino at produkto sa aming trabaho, kaya hindi ko susubukan na ilista ang lahat ng ito. Tanging ang pinakapangunahing impormasyon tungkol sa mga backup at log na kinakailangan para sa kaligtasan sa dagat. Sa mga interesado pwede din ako mga kasamahan tungkol sa mga feed, kung saan nagbigay din siya ng listahan ng mga terminong nauugnay sa bahaging iyon ng functionality.
Host: Sa mundo ng virtualization, ito ay isang makina na may hypervisor. Pisikal, virtual, ulap - hindi mahalaga. Kung mayroong nagpapatakbo ng hypervisor (ESXi, Hyper-V, KVM atbp), kung gayon ang "isang bagay" na ito ay tinatawag na isang host. Kung isa man itong kumpol na may sampung rack o ang iyong laptop na may lab para sa isa at kalahating virtual machine, kung naglunsad ka ng hypervisor, naging host ka. Dahil ang hypervisor ay nagho-host ng mga virtual machine. Mayroong kahit isang kuwento na ang VMware sa isang pagkakataon ay nais na makamit ang isang matatag na pagkakaugnay ng salitang host sa ESXi. Ngunit hindi niya ito magawa.
Sa modernong mundo, ang konsepto ng "host" ay halos pinagsama sa konsepto ng "server," na nagdudulot ng isang tiyak na kalituhan sa komunikasyon, lalo na pagdating sa imprastraktura ng Windows. Kaya ang anumang makina kung saan matatagpuan ang ilang serbisyong interesado sa amin ay maaaring ligtas na tawaging host. Halimbawa, sa WinSock log ang lahat ay minarkahan ng salitang host. Ang klasikong "Host not found" ay isang halimbawa nito. Kaya nagpapatuloy kami mula sa konteksto, ngunit tandaan - sa mundo ng virtualization, ang host ang nagho-host ng mga bisita (higit pa sa dalawang linya sa ibaba).
Mula sa lokal na jargon (mas malamang kahit na mga acronym, sa kasong ito), naaalala ko na ang VMware ay VI, ang vSphere ay VC, at ang Hyper-V ay HV.
Bisita: Isang virtual machine na tumatakbo sa isang host. Wala man lang dapat ipaliwanag dito, lahat ay lohikal at simple. Gayunpaman, maraming masigasig na nag-drag ng ilang iba pang mga kahulugan dito.
Para saan? hindi ko alam.
Ang Guest OS, ayon sa pagkakabanggit, ay ang operating system ng guest machine. At iba pa.
Backup/Replication Job (jobA): Purong Wim jargon na nagsasaad ng isa sa mga gawain. Backup job == Backup Job. Walang nakaisip kung paano isalin ito nang maganda sa Russian, kaya lahat ay nagsasabing "jobA". Na may diin sa huling pantig.
Oo, ganyan lang sila magsabi ng "joba". At nagsusulat pa sila ng ganoon sa mga titik, at maayos ang lahat.
Lahat ng uri ng backup na trabaho, backup na gawain, atbp., salamat, ngunit hindi na kailangan. Gumawa ka lang ng trabaho, at maiintindihan ka nila. Ang pangunahing bagay ay upang ilagay ang diin sa huling pantig.
Backup (Backup, backup. Para sa true-oldfags, BackUp ay pinapayagan): Bilang karagdagan sa halata (isang backup na kopya ng data na nakalagay sa isang lugar), nangangahulugan din ito ng trabaho mismo (tatlong linya sa itaas, kung nakalimutan mo na), bilang isang resulta kung saan ang parehong backup na file ay lilitaw. Marahil, mga ginoo, ang mga nagsasalita ng Ingles ay masyadong tamad na sabihin na pinapatakbo ko ang aking backup na trabaho sa bawat oras, kaya sinasabi lang nila na pinatakbo ko ang aking backup, at lahat ay lubos na nagkakaintindihan. Iminumungkahi kong suportahan ang kahanga-hangang inisyatiba.
Pagsama-samahin (Consolidation): Isang terminong lumabas sa ESXi 5.0 Isang opsyon sa snapshot menu na nagsisimula sa proseso ng pagtanggal ng tinatawag na orphaned snapshot. Ibig sabihin, ang mga snapshot na pisikal na magagamit, ngunit nawala sa ipinapakitang lohikal na istraktura. Sa teorya, ang prosesong ito ay hindi dapat makaapekto sa mga file na ipinapakita sa snapshot manager, ngunit anumang bagay ay maaaring mangyari. Ang kakanyahan ng proseso ng pagsasama-sama ay ang data mula sa isang snapshot (child disk) ay nakasulat sa pangunahing (magulang) disk. Ang proseso ng pagsasama ng mga disk ay tinatawag na pagsasama. Kung ibinigay ang isang command ng pagsasama-sama, ang snapshot record ay maaaring tanggalin mula sa database bago ang snapshot ay pinagsama at tinanggal. At kung ang snapshot ay hindi matanggal sa anumang kadahilanan, ang parehong mga ulilang snapshot ay lilitaw. May impormasyon ang VMware tungkol sa pagtatrabaho sa mga snapshot . At kami din kahit papaano tungkol sa kanila .
Datastore (Stora o hundredaj): Isang napakalawak na konsepto, ngunit sa mundo ng virtualization ito ay tumutukoy sa lugar kung saan naka-imbak ang mga file ng virtual machine. Ngunit sa anumang kaso, kailangan mong malinaw na maunawaan ang konteksto at, kung mayroon kang kaunting pagdududa, linawin kung ano ang eksaktong ibig sabihin ng iyong kausap.
Proxy: Mahalagang maunawaan kaagad na ang Veeam Proxy ay hindi eksaktong kapareho ng nakasanayan natin sa Internet. Sa loob ng mga produkto ng Veeam, ito ay isang partikular na entity na nakikibahagi sa paglilipat ng data mula sa isang lugar patungo sa isa pa. Nang walang mga detalye, ang VBR ay isang command server, at ang mga proxy ay ang mga workhorse nito. Ibig sabihin, ang proxy ay isang makina kung saan dumadaloy ang trapiko at kung saan naka-install ang mga bahagi ng VBR na tumutulong sa pag-iwas sa trapikong ito. Halimbawa, maglipat ng data mula sa isang channel patungo sa isa pa o mag-attach ng mga disk sa iyong sarili (HotAdd mode).
Imbakan: Sa teknikal, ito ay isang entry lamang sa VBR database, na nagpapahiwatig ng lokasyon kung saan naka-imbak ang mga backup, at kung paano kumonekta sa lokasyong ito. Sa katunayan, maaari itong maging isang bahagi lamang ng CIFS o isang hiwalay na disk, server o bucket sa cloud. Muli, nasa konteksto kami, ngunit naiintindihan namin na ang isang repositoryo ay isang lugar lamang kung saan matatagpuan ang iyong mga backup.
Snapshot (SnapshOt): Ang mga mahilig sa gramatika ng Oxford ay mas gustong sabihin kung sino ang isang snapshot, kung sino ang isang snapshot, ngunit ang hindi marunong bumasa at sumulat ay nanalo dahil sa mas malaking masa. Kung sinuman ang hindi nakakaalam, ito ay isang teknolohiya na nagpapahintulot sa iyo na ibalik ang estado ng isang disk sa isang tiyak na punto ng oras. Ginagawa ito alinman sa pamamagitan ng pansamantalang pag-redirect ng mga operasyon ng I/O palayo sa pangunahing disk - pagkatapos ay tatawagin itong RoW (Redirect on Write) snapshot - o sa pamamagitan ng paglipat ng mga rewritable block mula sa iyong disk patungo sa isa pa - ito ay tatawaging CoW (Kopyahin sa Sumulat) snapshot. Ito ay salamat sa malawak na posibilidad para sa paggamit ng mga function na ito na magagawa ng Veeam ang backup magic nito. Mahigpit na pagsasalita, hindi lamang para sa kanila, ngunit ito ay isang bagay ng paparating na paglabas.
Sa dokumentasyon at mga log ng ESXi ay may kaguluhan sa paligid ng terminong ito, at sa konteksto ng pagbanggit ng mga snapshot maaari kang makahanap ng mga snapshot mismo, mag-redo log at maging ang delta disk. Walang ganoong discord sa dokumentasyon ng Veeam, at ang snapshot ay snapshot, at ang redo log ay eksaktong REDO file na nilikha ng isang independiyenteng hindi permanenteng disk. Ang mga REDO file ay tinatanggal kapag ang virtual machine ay naka-off, kaya ang pagkalito sa kanila ng mga snapshot ay isang recipe para sa pagkabigo.
Sintetiko: Ang mga sintetikong backup ay tumutukoy sa reverse incremental at forever forward na mga backup. Kung hindi mo pa nakikita ang terminong ito, isa lang ito sa mga mekanismong ginagamit para bumuo ng backup chain transformation. Gayunpaman, sa mga log maaari mo ring mahanap ang konsepto ng Transform, na ginagamit bilang bahagi ng paglikha ng mga buong kopya mula sa mga increment (synthetic full).
Gawain: Ito ang proseso ng pagproseso ng bawat indibidwal na makina sa loob ng isang trabaho. Iyon ay: mayroon kang backup na trabaho na may kasamang tatlong makina. Nangangahulugan ito na ang bawat makina ay ipoproseso sa loob ng isang hiwalay na gawain. Sa kabuuan, magkakaroon ng apat na log: ang pangunahing isa para sa trabaho at tatlo para sa mga gawain. Gayunpaman, mayroong isang mahalagang nuance: sa paglipas ng panahon, ang salitang "taska" ay naging labis na hindi maliwanag. Kapag pinag-uusapan natin ang tungkol sa mga pangkalahatang log, ang ibig nating sabihin ay isang VM ang gawain. Ngunit parehong ang proxy at ang repository ay may sariling "mga gawain". Doon ito ay maaaring mangahulugan ng isang virtual disk, isang virtual machine, o ang buong trabaho. Ibig sabihin, mahalagang huwag mawala ang konteksto.
Veeam %name% Serbisyo: Para sa kapakinabangan ng matagumpay na pag-backup, maraming mga serbisyo ang gumagana nang sabay-sabay, ang isang listahan ng kung saan ay matatagpuan sa karaniwang kagamitan. Ang kanilang mga pangalan ay nagpapakita ng kanilang kakanyahan nang malinaw, ngunit kabilang sa mga katumbas ay mayroong pinakamahalaga - Veeam Backup Service, kung wala ang iba ay hindi gagana.
VSS: Sa teknikal, ang VSS ay dapat palaging tumayo para sa Microsoft Volume Shadow Copy Service. Talagang ginagamit ng marami bilang kasingkahulugan para sa Application-Aware na Pagproseso ng Larawan. Na, siyempre, ay tiyak na mali, ngunit ito ay isang kuwento mula sa kategoryang "Anumang SUV ay matatawag na jeep, at maiintindihan ka nila."
Mga kamangha-manghang log at ang mga lugar kung saan sila nakatira
Gusto kong simulan ang kabanatang ito sa pamamagitan ng pagbubunyag ng isang mahusay na lihim - anong oras ang ipinapakita sa mga tala?
Tandaan:
- Palaging nagsusulat ng mga log ang ESXi sa UTC+0.
- Pinapanatili ng vCenter ang mga log batay sa oras ng timezone nito.
- Pinapanatili ng Veeam ang mga log batay sa oras at timezone ng server kung saan ito naka-install.
- At tanging ang mga wind event sa format na EVTX ang hindi nagdurusa mula sa pagiging nakatali sa anumang bagay. Kapag binubuksan, ang oras ay muling kinakalkula ayon sa makina kung saan sila binuksan. Ang pinaka-maginhawang opsyon, kahit na may mga paghihirap dito. Ang tanging kapansin-pansing kahirapan ay ang pagkakaiba sa mga lokal. Ito ay halos garantisadong landas sa hindi nababasang mga log. Oo, may mga opsyon kung paano ito gagamutin, ngunit huwag lang nating pagtalunan ang katotohanang gumagana ang lahat sa IT sa Ingles, at sumang-ayon na palaging itakda ang lokal na Ingles sa mga server. Oh pakiusap.
Ngayon pag-usapan natin ang mga lugar kung saan nakatira ang mga log at kung paano makukuha ang mga ito. Sa kaso ng VBR, mayroong dalawang diskarte.
Ang unang opsyon ay angkop kung hindi ka sabik na maghanap ng mga file sa pangkalahatang heap na partikular na nauugnay sa iyong problema. Upang gawin ito, mayroon kaming isang hiwalay na wizard, kung saan maaari mong tukuyin ang isang partikular na trabaho at isang tiyak na panahon kung saan kailangan mo ng mga log. Susunod, siya mismo ang dadaan sa mga folder at ilagay ang lahat ng kailangan niya sa isang archive. Tungkol sa kung saan hahanapin ito at kung paano ito gagawin, nakasulat ito nang detalyado sa .
Gayunpaman, ang wizard ay hindi nangongolekta ng mga log mula sa lahat ng mga gawain at, halimbawa, kung kailangan mong pag-aralan ang mga log ng isang restaurant, failover o failback, ang iyong landas ay nasa folder. %ProgramData%/Veeam/Backup. Ito ang pangunahing logostore ng VBR at ang %ProgramData% ay isang nakatagong folder at ayos lang. Sa pamamagitan ng paraan, ang default na lokasyon ay maaaring muling italaga gamit ang REG_SZ: LogDirectory type registry key sa HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication branch.
Sa mga makina ng Linux, ang mga log ng mga nagtatrabahong ahente ay dapat matagpuan sa /var/log/VeeamBackup/, kung gumagamit ka ng root o sudo account. Kung wala kang ganoong mga pribilehiyo, hanapin ang mga log in /tmp/VeeamBackup.
Para sa ahente ng Veeam para sa %OS_name% na mga log ay dapat hanapin %ProgramData%/Veeam/Endpoint (O %ProgramData%/Veeam/Backup/Endpoint) At /var/log/veeam ayon sa pagkakabanggit.
Kung gumagamit ka ng Application-Aware Image Processing (at malamang na ikaw ay), kung gayon ang sitwasyon ay nagiging mas kumplikado. Kakailanganin mo ang aming mga helper log, na nakaimbak sa loob mismo ng virtual machine, at mga VSS log. Paano at saan makukuha ang kaligayahang ito ay nakasulat nang detalyado sa . At syempre meron upang mangolekta ng mga kinakailangang log ng system.
Ito ay maginhawa upang mangolekta ng mga kaganapan sa Windows ayon sa . Kung gagamit ka ng Hyper-V, magiging mas kumplikado ang usapin, dahil kakailanganin mo rin ang lahat ng log nito mula sa Applications and Service Logs > Microsoft > Windows branch. Bagama't maaari kang palaging kumuha ng mas hangal na ruta at kunin lamang ang lahat ng mga bagay mula sa %SystemRoot%System32winevtLogs.
Kung may masira sa panahon ng pag-install/pag-upgrade, ang lahat ng kailangan mo ay makikita sa %ProgramData%/Veeam/Setup/Temp folder. Bagama't hindi ko itatago ang katotohanang makakahanap ka ng mas kapaki-pakinabang na impormasyon sa mga kaganapan sa OS kaysa sa mga log na ito. Ang natitirang mga kawili-wiling bagay ay nasa %Temp%, ngunit mayroong pangunahing mga log ng pag-install ng kaugnay na software, tulad ng database, .Net na mga aklatan at iba pang mga bagay. Pakitandaan na ang Veeam ay naka-install mula sa isang msi, at lahat ng mga bahagi nito ay naka-install din bilang hiwalay na mga pakete ng msi, kahit na hindi ito ipinakita sa GUI. Samakatuwid, kung ang pag-install ng isa sa mga bahagi ay nabigo, ang buong pag-install ng VBR ay titigil. Samakatuwid, kailangan mong pumunta sa mga log at makita kung ano ang eksaktong sinira at sa anong sandali.
At isang huling hack sa buhay: kung nakatanggap ka ng isang error sa panahon ng pag-install, huwag magmadali upang i-click ang OK. Una naming kinuha ang mga log, pagkatapos ay i-click ang OK. Sa ganitong paraan makakakuha ka ng isang log na nagtatapos sa sandali ng error, nang walang basura sa dulo.
At nangyayari na kailangan mong makapasok sa mga log ng vSphere. Ito ay isang napaka walang pasasalamat na trabaho, ngunit kapag ikaw ay gumulong sa iyong mga manggas, kailangan mong gumawa ng iba pa. Sa pinakasimpleng bersyon, kakailanganin namin ng mga log na may mga virtual machine event na vmware.log, na matatagpuan sa tabi ng .vmx file nito. Sa isang mas kumplikadong kaso, buksan ang Google at itanong kung nasaan ang mga log para sa iyong bersyon ng host, dahil gustong-gusto ng VMware na baguhin ang lokasyong ito mula sa release hanggang release. Halimbawa, , ngunit para sa . Para sa mga vCenter log, inuulit namin ang pamamaraan . Ngunit sa pangkalahatan, magiging interesado kami sa mga host ng event logs hostd.log, host ng mga event na pinamamahalaan ng vCenter vpxa.log, kernel logs vmkernel.log at authentication logs auth.log. Well, sa pinaka-advanced na mga kaso, ang SSO log, na matatagpuan sa SSO folder, ay maaaring maging kapaki-pakinabang.
Mahirap? nalilito? Nakakatakot? Ngunit hindi pa ito kalahati ng impormasyon kung saan gumagana ang aming suporta sa araw-araw. Kaya sila ay talagang, talagang cool.
Mga Bahagi ng Veeam
At para tapusin ang panimulang artikulong ito, pag-usapan natin ang tungkol sa Veeam Backup & Replication na mga bahagi. Dahil kapag hinahanap mo ang sanhi ng sakit, ito ay magiging maganda upang maunawaan kung paano gumagana ang pasyente.
Kaya, tulad ng malamang na alam ng lahat, ang Veeam Backup ay isang tinatawag na SQL-based na application. Iyon ay, lahat ng mga setting, lahat ng impormasyon at, sa pangkalahatan, lahat ng bagay na kinakailangan para sa normal na paggana - lahat ng ito ay nasa database nito. O sa halip, sa dalawang database, kung pinag-uusapan natin ang tungkol sa kumbinasyon ng VBR at EM: VeeamBackup at VeeamBackupReporting, ayon sa pagkakabanggit. At kaya nangyari: nag-install kami ng isa pang application - lilitaw ang isa pang database. Upang hindi maiimbak ang lahat ng mga itlog sa isang basket.
Ngunit para gumana nang maayos ang buong negosyong ito, kakailanganin namin ang isang hanay ng mga serbisyo at application na magkokonekta sa lahat ng mga bahagi nang magkasama. Halimbawa lamang, ito ang hitsura sa isa sa aking mga laboratoryo:
Nagsisilbing punong konduktor Serbisyo ng Backup ng Veeam. Siya ang responsable sa pakikipagpalitan ng impormasyon sa mga database. Siya rin ang may pananagutan sa paglulunsad ng lahat ng mga gawain, pagsasaayos ng mga inilalaang mapagkukunan at pagtatrabaho bilang isang uri ng sentro ng komunikasyon para sa iba't ibang mga console, ahente at lahat ng iba pa. Sa isang salita, walang ganap na paraan kung wala siya, ngunit hindi iyon nangangahulugan na siya mismo ang gumagawa ng lahat.
Tulungan siyang matupad ang kanyang mga plano Veeam Backup Manager. Ito ay hindi isang serbisyo, ngunit isang entity na naglulunsad ng mga trabaho at sinusubaybayan ang proseso ng kanilang pagpapatupad. Ang mga gumaganang kamay ng backup na serbisyo, kung saan ito kumokonekta sa mga host, ay lumilikha ng mga snapshot, sinusubaybayan ang pagpapanatili, at iba pa.
Ngunit bumalik tayo sa listahan ng mga serbisyo. Serbisyo ng Veeam Broker. Lumitaw sa v9.5 (at hindi ito isang crypto miner, gaya ng iniisip ng ilan noon). Nangongolekta ng impormasyon tungkol sa mga host ng VMware at pinapanatili itong napapanahon. Ngunit huwag kaagad tumakbo upang magsulat ng mga galit na komento na kami ay nag-espiya sa iyo at naglalabas ng lahat ng iyong mga login/password sa drag major. Ang lahat ay medyo mas simple. Kapag nagsimula ka ng backup, ang unang bagay na kailangan mong gawin ay kumonekta sa host at i-update ang lahat ng data tungkol sa istraktura nito. Ito ay isang medyo mabagal at mahirap gamitin na kuwento. Tandaan lamang kung gaano katagal ang iyong operasyon sa pag-log in sa pamamagitan ng web interface, at tandaan na ang tuktok na layer lamang ang isinasaalang-alang doon. At pagkatapos ay kailangan mo pa ring palawakin ang buong hierarchy sa tamang lugar, sa pamamagitan ng paraan. Sa madaling salita, horror. Kung maglulunsad ka ng isang dosenang backup, ang bawat trabaho ay kailangang dumaan sa pamamaraang ito. Kung pinag-uusapan natin ang tungkol sa malalaking imprastraktura, maaaring tumagal ang prosesong ito ng sampung minuto o higit pa. Samakatuwid, napagpasyahan na maglaan ng isang hiwalay na serbisyo para dito, kung saan posible na makatanggap ng palaging napapanahon na impormasyon. Sa pagsisimula, sinusuri at sinusuri nito ang lahat ng idinagdag na imprastraktura, at pagkatapos ay sinusubukang gumana lamang sa antas ng mga incremental na pagbabago. Kaya kahit na mayroon kang isang daang backup na tumatakbo nang sabay-sabay, lahat sila ay hihiling ng impormasyon mula sa aming broker, at hindi pahihirapan ang mga host sa kanilang mga kahilingan. Kung nag-aalala ka tungkol sa mga mapagkukunan, ayon sa aming mga kalkulasyon, para sa 5000 virtual machine kailangan mo lamang ng halos 100 Mb ng memorya.
Susunod na mayroon kami Veeam Console. Aka Veeam Remote Console, aka Veeam.Backup.Shell. Ito ang parehong GUI na nakikita natin sa mga screenshot. Ang lahat ay simple at halata - ang console ay maaaring ilunsad mula sa kahit saan, hangga't ito ay Windows at may koneksyon sa VBR server. Ang tanging bagay na masasabi ay ang proseso ng FLR ay maglalagay ng mga puntos nang lokal (i.e. sa makina kung saan tumatakbo ang console). Well, ang iba't ibang Veeam Explorers ay tatakbo din nang lokal, dahil bahagi sila ng console. Ngunit dinala na ako nito sa kagubatan...
Ang susunod na kawili-wiling serbisyo ay Veeam Backup Catalog Data Service. Sa listahan ng mga serbisyo ito ay kilala bilang Veeam Guest Catalog Service. Siya ay nakikibahagi sa pag-index ng mga file system sa mga guest machine at pinupunan ang VBRCatalog folder ng kaalamang ito. Ginagamit lang kung saan naka-enable ang checkbox sa pag-index. At makatuwiran lamang na paganahin ito kung mayroon kang Enterprise Manager. Samakatuwid, payo mula sa kaibuturan ng aking puso: huwag paganahin ang pag-index ng ganoon lang kung wala kang EM. I-save ang iyong mga ugat at oras ng suporta.
Gayundin sa iba pang mahahalagang serbisyo ito ay nagkakahalaga ng pagpuna Serbisyo ng Veeam Installer, sa tulong kung saan ang mga kinakailangang bahagi ay inihahatid at naka-install sa mga proxy, repositoryo at iba pang mga gateway. Sa katunayan, inihahatid niya ang mga kinakailangang .msi na pakete sa mga server at ini-install ang mga ito.
Veeam Data Mover - sa tulong ng mga auxiliary agent na inilunsad sa mga proxy (at hindi lamang) ito ay nakikibahagi sa paglilipat ng data. Halimbawa, kapag nagba-back up, ang isang ahente ay magbabasa ng mga file mula sa host datastore, at ang pangalawa ay maingat na isusulat ang mga ito sa backup.
Hiwalay, gusto kong tandaan ang isang mahalagang bagay na madalas na reaksyon ng mga kliyente - ito ang pagkakaiba sa mga bersyon ng mga serbisyo at impormasyon sa snap-in ng Programs and Features. Oo, ang listahan ay magiging pareho, ngunit ang mga bersyon ay maaaring ganap na hindi magkatugma. Ito ay hindi masyadong cool mula sa isang visual na punto ng view, ngunit ito ay ganap na normal kung ang lahat ay gumagana nang maayos. Halimbawa, ang numero ng bersyon ng serbisyo ng Installer ay nahuhuli sa mga kapitbahay nito. Horror at bangungot? Hindi, dahil hindi ito muling na-install nang buo, ngunit ang DLL nito ay na-update lamang. Sa v9.5 U4 patch, isang bangungot sa suporta sa tech ang naganap: sa panahon ng pag-update, ang lahat ng mga serbisyo ay nakatanggap ng mga bagong bersyon, maliban sa pinakamahalaga. Sa U4b patch, ang serbisyo ng transportasyon ay nauna sa lahat ng iba pa ng kasing dami ng dalawang bersyon (paghusga sa mga numero). At ito ay normal din - isang malubhang bug ang natagpuan sa loob nito, kaya nakatanggap ito ng pag-update ng bonus na may kaugnayan sa iba. Kaya, upang ibuod: ang mga pagkakaiba sa bersyon ay MAAARING maging isang problema, ngunit kung mayroong isang pagkakaiba at lahat ay gumagana nang maayos, kung gayon malamang na ito ay dapat. Ngunit walang nagbabawal sa iyo na linawin ito gamit ang teknikal na suporta.
Ito ang tinatawag na mandatory o Mandatory services. At mayroong isang buong pakete ng mga auxiliary, tulad ng Tape Service, Mount Service, vPowerNFS Service at iba pa.
Para sa Hyper-V sa pangkalahatan ang lahat ay pareho, mayroon lamang isang tiyak Veeam Backup Hyper-V Integration Service at sarili nitong driver para sa pagtatrabaho sa CBT.
At sa dulo ay pag-uusapan natin kung sino ang gumagana sa mga virtual machine sa panahon ng backup. Ito ay ginagamit upang magpatakbo ng mga script bago at pagkatapos ng pag-freeze, lumikha ng mga kopya ng anino, mangolekta ng metadata, magtrabaho kasama ang mga log ng transaksyon sa SQL, atbp. Veeam Guest Helper. At kung ang mga file system ay na-index, Veeam Guest Indexer . Ito ay mga pansamantalang serbisyo na na-deploy para sa tagal ng pag-backup at tinanggal pagkatapos nito.
Sa kaso ng mga makina ng Linux, ang lahat ay mas simple dahil sa pagkakaroon ng isang malaking bilang ng mga built-in na aklatan at ang mga kakayahan ng system mismo. Halimbawa, ang pag-index ay ginagawa sa pamamagitan ng mlocate.
Yun lang muna
Hindi na ako naglakas-loob na pahirapan ka at maikli Itinuturing kong kumpleto ang pagpapakilala sa Veeam engine compartment. Oo, hindi pa kami nakakalapit sa mga log mismo, ngunit maniwala ka sa akin, upang ang impormasyong ipinakita sa kanila ay hindi mukhang isang hindi magkakaugnay na daloy ng kamalayan, ang gayong pagpapakilala ay ganap na kinakailangan. Plano kong lumipat sa mga log mismo sa ikatlong artikulo lamang, at ang plano para sa susunod ay ipaliwanag kung sino ang bumubuo ng mga log, kung ano ang eksaktong ipinapakita sa kanila at kung bakit eksakto sa ganitong paraan at hindi sa ibang paraan.
Pinagmulan: www.habr.com