Kami di Veeam suka balak. Dan kerana kebanyakan penyelesaian kami adalah modular, mereka menulis banyak log. Dan memandangkan skop aktiviti kami adalah untuk memastikan keselamatan data anda (iaitu, tidur yang lena), maka log bukan sahaja perlu merekodkan setiap bersin, tetapi juga melakukannya dengan terperinci. Ini adalah perlu supaya dalam kes sesuatu adalah jelas bagaimana "apa" ini berlaku, siapa yang harus dipersalahkan, dan apa yang perlu dilakukan seterusnya. Ia seperti dalam sains forensik: anda tidak pernah tahu perkara kecil apa yang akan membantu anda mencari pembunuh Laura Palmer.
Oleh itu, saya memutuskan untuk melihat satu siri artikel, di mana saya akan bercakap secara berurutan tentang apa yang kita tulis pada log, di mana kita menyimpannya, bagaimana untuk tidak menjadi gila dengan strukturnya dan apa yang perlu dicari di dalamnya.
Mengapa satu siri artikel dan mengapa tidak menerangkan semuanya sekaligus?
Hanya menyenaraikan log yang mana dan apa yang disimpan di dalamnya adalah satu usaha yang agak merugikan. Dan adalah menakutkan untuk memikirkan tentang memastikan maklumat ini dikemas kini. Penyenaraian ringkas semua jenis log yang mungkin dalam Veeam Backup & Replication ialah jadual pada beberapa helaian dalam cetakan kecil. Ya, dan ia akan relevan hanya pada masa penerbitan, kerana. apabila tampalan seterusnya dikeluarkan, log baharu mungkin muncul, logik maklumat yang disimpan dalam yang lama akan berubah, dsb. Oleh itu, ia akan menjadi lebih menguntungkan untuk menerangkan struktur mereka dan intipati maklumat yang terkandung di dalamnya. Ini akan membolehkan anda menavigasi tempat dengan lebih baik daripada menjejalkan nama.
Oleh itu, untuk tidak tergesa-gesa masuk ke dalam kumpulan helaian teks, mari lakukan beberapa kerja persediaan dalam artikel ini. Oleh itu, hari ini kita tidak akan masuk ke dalam log itu sendiri, tetapi akan pergi dari jauh: kita akan menyusun glosari dan membincangkan sedikit struktur Veeam dari segi penjanaan log.
Glosari dan jargon
Di sini, pertama sekali, patut memohon maaf kepada juara kemurnian bahasa Rusia dan saksi kamus Ozhegov. Kita semua sangat menyukai bahasa ibunda kita, tetapi industri IT yang terkutuk itu beroperasi dalam bahasa Inggeris. Nah, kami tidak menciptanya, tetapi ia berlaku mengikut sejarah. Bukan salah saya, dia datang sendiri (c)
Dalam perniagaan kami, masalah anglicisms (dan jargon) mempunyai spesifiknya sendiri. Apabila di bawah perkataan yang tidak bersalah seperti "tuan rumah" atau "tetamu" seluruh dunia telah lama memahami perkara yang sangat spesifik, maka pada β tanah, kekeliruan heroik dan terhuyung-hayang dengan memasukkan kamus berterusan. Dan hujah yang sangat wajib "Tetapi pada kerja kami ...".
Selain itu, terdapat terminologi kami semata-mata, yang wujud dalam produk Veeam, walaupun beberapa perkataan dan frasa telah disampaikan kepada orang ramai. Oleh itu, sekarang kita akan bersetuju dengan istilah apa yang bermaksud apa, dan pada masa akan datang, di bawah perkataan "tetamu", saya akan maksudkan dengan tepat apa yang ditulis dalam bab ini, dan bukan apa yang biasa anda lakukan di tempat kerja. Dan ya, ini bukan kehendak peribadi saya, ini adalah istilah yang mantap dalam industri. Melawan mereka agak sia-sia. Walaupun saya sentiasa memihak untuk berehat dalam komen.
Malangnya, terdapat banyak istilah dalam kerja dan produk kami, jadi saya tidak akan cuba menyenaraikan semuanya. Hanya maklumat yang paling asas dan perlu tentang sandaran dan balak untuk kelangsungan hidup di laut. Bagi yang berminat, saya juga boleh rakan sekerja tentang pita, di mana dia juga memberikan senarai istilah yang berkaitan dengan bahagian fungsi itu.
Hos (Hos): Dalam dunia virtualisasi, ini adalah mesin dengan hypervisor. Fizikal, maya, awan - tidak mengapa. Jika sesuatu menjalankan hypervisor (ESXi, Hyper-V, KVM dll), maka "sesuatu" ini dipanggil hos. Sama ada gugusan dengan sepuluh rak atau komputer riba anda dengan makmal untuk satu setengah mesin maya - jika anda melancarkan hipervisor, anda menjadi hos. Kerana hypervisor menjadi tuan rumah mesin maya. Malah ada cerita bahawa VMware pada satu masa ingin mencapai perkaitan kukuh perkataan hos dengan ESXi. Tetapi dia tidak.
Dalam dunia moden, konsep "hos" secara praktikal telah digabungkan dengan konsep "pelayan", yang membawa beberapa kekeliruan kepada komunikasi, terutamanya apabila ia berkaitan dengan infrastruktur Windows. Jadi mana-mana mesin yang mengehoskan beberapa perkhidmatan yang menarik minat kami boleh dipanggil hos dengan selamat. Sebagai contoh, dalam log WinSock semuanya ditandakan dengan perkataan hos. "Hos tidak ditemui" klasik ialah contoh ini. Oleh itu, kita bermula dari konteks, tetapi ingat - dalam dunia virtualisasi, hos adalah yang menjadi hos tetamu (lebih lanjut mengenai perkara ini dalam dua baris di bawah).
Daripada jargon tempatan (bukan akronim, dalam kes ini), diingatkan di sini bahawa VMware ialah VI, vSphere ialah VC, dan Hyper-V ialah HV.
Tetamu (Tetamu): Mesin maya yang berjalan pada hos. Tiada apa yang perlu dijelaskan di sini, semuanya sangat logik dan mudah. Namun, ramai yang rajin mengheret di sini beberapa maksud lain.
Untuk apa? saya tak tahu.
OS tetamu, masing-masing, sistem pengendalian mesin tetamu. Dan sebagainya.
Kerja Sandaran/Replikasi (jobA): Jargon Wim tulen, menandakan beberapa tugas. Kerja sandaran == Kerja sandaran. Tiada siapa yang tahu cara menterjemahkannya dengan cantik ke dalam bahasa Rusia, jadi semua orang berkata "JobA". Dengan penekanan pada suku kata terakhir.
Ya, mereka hanya mengambilnya dan berkata "joba". Dan walaupun dalam surat mereka menulis seperti itu, dan semuanya baik-baik saja.
Segala macam kerja Sandaran, Tugasan Sandaran, dsb., terima kasih, tetapi tidak perlu. Hanya pekerjaan, dan anda akan difahami. Perkara utama ialah meletakkan tekanan pada suku kata terakhir.
Sandaran (Sandaran, sandaran. Untuk true-oldfags, sandaran dibenarkan): Sebagai tambahan kepada yang jelas (salinan sandaran data yang terletak di suatu tempat), ini juga bermaksud kerja itu sendiri (tiga baris di atas, jika anda sudah terlupa), akibatnya fail sandaran muncul. Mungkin, tuan-tuan penutur asli bahasa Inggeris terlalu malas untuk mengatakan saya menjalankan tugas sandaran saya setiap kali, jadi mereka hanya mengatakan saya menjalankan sandaran saya, dan semua orang memahami satu sama lain dengan sempurna. Saya menjemput anda untuk menyokong inisiatif hebat ini.
Penyatuan (Penyatuan): Istilah yang muncul dalam ESXi 5.0 Pilihan dalam menu syot kilat yang memulakan proses memadam syot kilat yang dipanggil yatim piatu. Iaitu, syot kilat yang tersedia secara fizikal, tetapi terkeluar daripada struktur logik yang dipaparkan. Secara teorinya, proses ini tidak boleh menjejaskan fail yang dipaparkan dalam pengurus syot kilat, tetapi apa-apa boleh berlaku. Intipati proses penyatuan ialah data daripada syot kilat (cakera kanak-kanak) ditulis ke cakera utama (induk). Proses menggabungkan cakera dipanggil merge. Jika arahan penyatuan telah dikeluarkan, maka rekod syot kilat boleh dialih keluar daripada pangkalan data sebelum syot kilat digabungkan dan dipadamkan. Dan jika syot kilat itu tidak dapat dipadamkan atas sebarang sebab, maka syot kilat yatim piatu yang sama ini muncul. Mengenai bekerja dengan syot kilat, VMware ada . Dan kami juga entah bagaimana tentang mereka .
Datastore (Stora atau storan): Konsep yang sangat luas, tetapi dalam dunia maya, ia difahami sebagai tempat di mana fail mesin maya disimpan. Tetapi dalam apa jua keadaan, di sini anda perlu memahami konteks dengan sangat jelas dan, dengan sedikit keraguan, jelaskan apa sebenarnya yang difikirkan oleh teman bicara anda.
Proksi (Proksi): Adalah penting untuk memahami dengan segera bahawa Veeam Proxy tidak sama seperti yang biasa kita lakukan di Internet. Dalam produk Veeam, ini adalah sejenis entiti yang berurusan dengan pemindahan data dari satu tempat ke tempat lain. Jika anda tidak pergi ke butiran, maka VBR ialah pelayan arahan dan kawalan, dan proksi adalah kuda kerjanya. Maksudnya, proksi ialah mesin yang melaluinya trafik mengalir dan komponen VBR dipasang yang membantu mengurus trafik ini. Sebagai contoh, untuk memindahkan data dari satu saluran ke saluran lain, atau hanya untuk melekatkan cakera pada dirinya sendiri (mod HotAdd).
Repositori (Repositori): Secara teknikal, ini hanyalah entri dalam pangkalan data VBR, yang menunjukkan tempat sandaran disimpan, dan cara menyambung ke tempat ini. Malah, ia boleh sama ada hanya bola CIFS atau cakera berasingan, pelayan atau baldi dalam awan. Sekali lagi, kami berada dalam konteks, tetapi kami faham bahawa repositori hanyalah tempat di mana sandaran anda berada.
Syot Kilat (SnapshOt): Peminat tatabahasa Oxford lebih suka mengatakan siapa snapshot dan siapa snapshot, tetapi majoriti buta huruf mendapat manfaat daripada jisim yang lebih besar. Jika sesiapa tidak tahu, ini adalah teknologi yang membolehkan anda memulihkan keadaan cakera pada masa tertentu. Ini dilakukan sama ada dengan mengalihkan sementara operasi I/O dari cakera utama - kemudian ia akan dipanggil petikan RoW (Redirect on Write) - atau dengan mengalihkan blok boleh tulis semula dari cakera anda ke cakera lain - ini akan dipanggil CoW (Copy on Write). ) syot kilat. Terima kasih kepada kemungkinan yang luas untuk menggunakan fungsi ini yang Veeam boleh melakukan sihir sandarannya. Tegasnya, bukan sahaja mereka, tetapi ini adalah soal keluaran seterusnya.
Terdapat huru-hara di sekitar istilah ini dalam dokumentasi dan log ESXi, dan dalam konteks menyebut syot kilat, anda boleh mencari syot kilat sendiri, dan buat semula log, dan juga cakera delta. Dokumentasi Veeam tidak mengandungi koyakan seperti itu, dan petikan ialah petikan, dan log buat semula ialah fail REDO yang dicipta oleh cakera tidak berterusan bebas. Fail REDO dipadamkan apabila mesin maya dimatikan, jadi mengelirukan mereka dengan syot kilat adalah jalan kepada kegagalan.
Sintetik (Sintetik): Sandaran sintetik ialah sandaran tambahan terbalik dan sandaran hadapan selama-lamanya. Sekiranya anda belum menemui istilah ini, ia hanyalah salah satu daripada mekanisme yang digunakan untuk membina transformasi rantaian sandaran. Walau bagaimanapun, dalam log anda juga boleh menemui konsep Transform, yang digunakan dalam rangka kerja mencipta salinan penuh daripada kenaikan (sintetik penuh).
Tugas (Tugas): Ini ialah proses memproses setiap mesin individu dalam kerja. Iaitu: anda mempunyai kerja sandaran, yang merangkumi tiga mesin. Ini bermakna setiap kereta akan diproses sebagai sebahagian daripada tugas yang berasingan. Secara keseluruhan, akan ada empat log: yang utama untuk pekerjaan dan tiga untuk tugas. Walau bagaimanapun, terdapat nuansa penting di sini: dari masa ke masa, perkataan "tugas" telah menjadi tidak semestinya samar-samar. Apabila kita bercakap tentang log umum, kami maksudkan bahawa tugas adalah betul-betul VM. Tetapi terdapat "tugas" pada proksi dan pada repositori. Di sana ia boleh bermakna cakera maya, mesin maya, dan keseluruhan kerja. Iaitu, adalah penting untuk tidak kehilangan konteks.
Perkhidmatan %name% Veeam: Untuk manfaat sandaran yang berjaya, beberapa perkhidmatan berfungsi serentak, senarai yang boleh didapati dalam peralatan standard. Nama mereka agak telus mencerminkan intipati mereka, tetapi antara yang sama ada yang paling penting - Perkhidmatan Sandaran Veeam, tanpanya yang lain tidak akan berfungsi.
VSS: Secara teknikal, VSS hendaklah sentiasa mewakili Microsoft Volume Shadow Copy Service. Malah, ia digunakan oleh ramai orang sebagai sinonim untuk Pemprosesan Imej Sedar Aplikasi. Yang, tentu saja, adalah salah, tetapi ini adalah cerita dari kategori "Mana-mana SUV boleh dipanggil jip, dan anda akan difahami."
Log hebat dan tempat tinggalnya
Saya ingin memulakan bab ini dengan mendedahkan rahsia besar - pukul berapa dipaparkan dalam log?
Ingat:
- ESXi sentiasa menulis log dalam UTC+0.
- vCenter menyimpan log mengikut masa zon waktunya.
- Veeam menyimpan log mengikut masa dan zon waktu pelayan yang dihidupkan.
- Dan hanya acara Windows dalam format EVTX tidak mengalami pengikatan kepada apa-apa. Apabila dibuka, masa dikira semula untuk kereta di mana ia dibuka. Pilihan yang paling mudah, walaupun terdapat kesukaran dengannya. Satu-satunya kesukaran yang ketara ialah perbezaan dalam tempat. Ini adalah laluan yang dijamin secara praktikal ke log tidak boleh dibaca. Ya, terdapat pilihan untuk menangani perkara ini, tetapi jangan berhujah dengan fakta bahawa segala-galanya dalam IT berfungsi dalam bahasa Inggeris, dan bersetuju untuk sentiasa menetapkan tempat bahasa Inggeris pada pelayan. Oh tolonglah.
Sekarang mari kita bincangkan tentang tempat tinggal kayu balak dan cara mendapatkannya. Dalam kes VBR, terdapat dua pendekatan.
Pilihan pertama adalah sesuai jika anda tidak berminat untuk mencari fail dalam timbunan umum yang secara khusus berkaitan dengan masalah anda. Untuk melakukan ini, kami mempunyai wizard yang berasingan, yang mana anda boleh menentukan kerja tertentu dan tempoh tertentu yang anda perlukan log. Kemudian dia akan menyemak sendiri folder dan meletakkan semua yang anda perlukan ke dalam satu arkib. Di mana untuk mencarinya dan cara bekerja dengannya diterangkan secara terperinci dalam .
Walau bagaimanapun, wizard tidak mengumpul log semua tugas dan, sebagai contoh, jika anda perlu mengkaji log pemulihan, failover atau failback, laluan anda terletak dalam folder %ProgramData%/Veeam/Sandaran. Ini ialah kedai logo VBR utama dan %ProgramData% ialah folder tersembunyi dan tidak mengapa. Dengan cara ini, lokasi lalai boleh ditetapkan semula menggunakan REG_SZ: kunci pendaftaran jenis LogDirectory dalam cawangan HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup dan Replication.
Pada mesin Linux, log ejen pekerja harus dicari dalam /var/log/VeeamBackup/jika menggunakan akaun root atau sudo. Jika anda tidak mempunyai keistimewaan sedemikian, maka cari log masuk /tmp/VeeamBackup.
Untuk ejen Veeam untuk %OS_name% log harus dicari masuk %ProgramData%/Veeam/Endpoint (Atau %ProgramData%/Veeam/Backup/Endpoint) Dan /var/log/veeam masing-masing.
Jika anda menggunakan Pemprosesan Imej Sedar Aplikasi (dan kemungkinan besar anda menggunakannya), maka keadaan menjadi lebih rumit. Anda memerlukan log pembantu kami, yang disimpan di dalam mesin maya itu sendiri, dan log VSS. Mengenai bagaimana dan di mana untuk mendapatkan kebahagiaan ini, ia ditulis secara terperinci . Dan sudah tentu ada untuk mengumpul log sistem yang diperlukan.
Acara Windows mudah dikumpulkan mengikut . Jika anda menggunakan Hyper-V, perkara menjadi lebih rumit, kerana anda juga memerlukan semua lognya daripada Log Aplikasi dan Perkhidmatan > Microsoft > cawangan Windows. Walaupun anda sentiasa boleh menggunakan cara yang lebih bodoh dan hanya mengambil semua objek daripada %SystemRoot%System32winevtLogs.
Jika sesuatu rosak semasa pemasangan/naik taraf, semua yang anda perlukan boleh didapati dalam folder %ProgramData%/Veeam/Setup/Temp. Walaupun saya tidak akan menyembunyikan fakta bahawa dalam acara OS anda boleh mencari maklumat yang lebih berguna daripada dalam log ini. Selebihnya yang menarik terletak pada %Temp%, tetapi terdapat terutamanya log pemasangan untuk perisian berkaitan, seperti pangkalan, perpustakaan .Net dan perkara lain. Ambil perhatian bahawa Veeam dipasang daripada msi dan semua komponennya juga dipasang sebagai pakej msi yang berasingan, walaupun ini tidak ditunjukkan dalam GUI. Oleh itu, jika pemasangan salah satu komponen gagal, keseluruhan pemasangan VBR akan dihentikan. Oleh itu, anda perlu masuk ke dalam log dan lihat apa sebenarnya yang pecah dan pada titik mana.
Dan akhirnya, penggodaman hayat: jika anda menerima ralat semasa pemasangan, jangan tergesa-gesa untuk mengklik OK. Mula-mula kita ambil log, kemudian klik OK. Dengan cara ini anda akan mendapat log yang berakhir pada masa ralat, tanpa sampah pada akhirnya.
Dan kebetulan anda perlu masuk ke dalam log vSphere. Pekerjaan itu sangat tidak bersyukur, tetapi, setelah menyingsing lengan baju, seseorang perlu melakukan sesuatu yang lain. Dalam versi paling mudah, kami memerlukan log dengan peristiwa mesin maya vmware.log, yang terletak di sebelah fail .vmxnya. Dalam kes yang lebih sukar, buka Google dan tanya di mana log untuk versi hos anda berada, kerana VMware suka menukar tempat ini dari keluaran ke keluaran. Sebagai contoh, , tetapi untuk . Untuk log vCenter, ulangi prosedur . Tetapi secara amnya, kami akan berminat dengan log acara hos hostd.log, acara hos yang diuruskan oleh vCenter vpxa.log, log kernel vmkernel.log dan log pengesahan auth.log. Nah, dalam kes yang paling diabaikan, log SSO, yang terletak dalam folder SSO, mungkin berguna.
Menyusahkan? keliru? menakutkan? Tetapi ini bukan separuh daripada maklumat yang menyokong kami bekerja setiap hari. Jadi mereka benar-benar hebat.
Komponen Veeam
Dan sebagai kesimpulan kepada artikel pengenalan ini, mari kita bercakap sedikit tentang komponen Veeam Backup & Replication. Kerana apabila anda mencari punca kesakitan, adalah baik untuk memahami bagaimana pesakit berfungsi.
Jadi, seperti yang mungkin semua orang tahu, Veeam Backup ialah aplikasi berasaskan SQL yang dipanggil. Iaitu, semua tetapan, semua maklumat dan secara umum semua yang hanya diperlukan untuk berfungsi normal - semua ini ada dalam pangkalan datanya. Atau sebaliknya, dalam dua pangkalan data, jika kita bercakap tentang sekumpulan VBR dan EM: VeeamBackup dan VeeamBackupReporting, masing-masing. Dan begitulah berlaku: kami meletakkan aplikasi lain - pangkalan data lain muncul. Agar tidak semua telur disimpan dalam satu bakul.
Tetapi untuk semua ekonomi ini berfungsi dengan lancar, kami memerlukan satu set perkhidmatan dan aplikasi yang akan mengikat semua komponen bersama-sama. Sebagai contoh, inilah rupanya di salah satu makmal saya:
Bertindak sebagai ketua konduktor Perkhidmatan Sandaran Veeam. Dialah yang bertanggungjawab untuk pertukaran maklumat dengan pangkalan. Dia juga bertanggungjawab untuk melancarkan semua tugas, mengatur sumber yang diperuntukkan dan bekerja sebagai sejenis pusat komunikasi untuk pelbagai konsol, ejen dan segala-galanya. Dalam satu perkataan, pasti tidak ada cara tanpa dia, tetapi ini tidak bermakna sama sekali bahawa dia melakukan segala-galanya sendiri.
Membantunya dalam memenuhi rancangannya Pengurus Sandaran Veeam. Ini bukan perkhidmatan, tetapi entiti yang melancarkan pekerjaan dan memantau proses pelaksanaannya. Perkhidmatan sandaran berfungsi, yang dengannya ia bersambung kepada hos, mencipta syot kilat, memantau pengekalan dan sebagainya.
Tetapi kembali kepada senarai perkhidmatan. Perkhidmatan Broker Veeam. Muncul dalam v9.5 (dan ini bukan pelombong kripto, seperti yang difikirkan oleh sesetengah orang pada masa itu). Mengumpul maklumat tentang hos VMware dan mengekalkan perkaitannya. Tetapi jangan segera berlari untuk menulis komen marah bahawa kami mengintip anda dan membocorkan semua log masuk / kata laluan ke taschmajor. Segala-galanya agak lebih mudah. Apabila anda menjalankan sandaran, perkara pertama yang perlu anda lakukan ialah menyambung ke hos dan mengemas kini semua data tentang strukturnya. Ini adalah cerita yang agak perlahan dan menyusahkan. Ingatlah berapa lama masa yang diperlukan untuk anda log masuk melalui antara muka web, dan ingat bahawa hanya lapisan atas dikira di sana. Dan kemudian anda masih perlu membuka keseluruhan hierarki ke tempat yang betul, dengan cara itu. Dalam satu perkataan, seram. Jika anda menjalankan sedozen sandaran, maka setiap kerja perlu melakukan prosedur ini. Jika kita bercakap tentang infrastruktur yang besar, maka proses ini boleh mengambil masa sepuluh minit atau lebih. Oleh itu, telah diputuskan untuk memperuntukkan perkhidmatan yang berasingan untuk ini, di mana ia akan dapat menerima maklumat yang sentiasa terkini. Pada permulaan, ia menyemak dan mengimbas semua infrastruktur tambahan, dan kemudian cuba berfungsi hanya pada tahap perubahan tambahan. Jadi walaupun anda menjalankan seratus sandaran pada masa yang sama, mereka semua akan meminta maklumat daripada broker kami, dan tidak akan menyeksa hos dengan permintaan mereka. Jika anda bimbang tentang sumber, maka mengikut pengiraan kami, 5000 mesin maya hanya memerlukan kira-kira 100 Mb memori.
Seterusnya kita ada Konsol Veeam. Dia ialah Veeam Remote Console, dia ialah Veeam.Backup.Shell. Ini adalah GUI yang sama yang kita lihat dalam tangkapan skrin. Segala-galanya mudah dan jelas - konsol boleh dilancarkan dari mana-mana sahaja, selagi ia adalah Windows dan terdapat sambungan ke pelayan VBR. Satu-satunya perkara yang boleh dikatakan ialah proses FLR akan melekapkan mata secara setempat (iaitu pada mesin tempat konsol sedang berjalan). Nah, pelbagai Veeam Explorers juga akan dijalankan secara tempatan, kerana ia adalah sebahagian daripada konsol. Tetapi ia telah membawa saya ke dalam hutan ...
Satu lagi perkhidmatan yang menarik ialah Perkhidmatan Data Katalog Sandaran Veeam. Dikenali sebagai Perkhidmatan Katalog Tetamu Veeam dalam senarai perkhidmatan. Dia terlibat dalam mengindeks sistem fail pada mesin tetamu dan mengisi folder VBRCatalog dengan pengetahuan ini. Ia digunakan hanya apabila kotak semak pengindeksan didayakan. Dan ia hanya masuk akal untuk mendayakannya jika anda mempunyai Pengurus Perusahaan. Oleh itu, nasihat dari lubuk hati saya: jangan hidupkan pengindeksan begitu sahaja jika anda tidak mempunyai MAKAN. Simpan saraf anda dan masa sokongan.
Juga dari perkhidmatan penting lain perlu diperhatikan Perkhidmatan Pemasang Veeam, dengan bantuan komponen yang diperlukan dihantar dan dipasang pada proksi, repositori dan gerbang lain. Malah, ia membawa pakej .msi yang diperlukan ke pelayan dan memasangnya.
Penggerak Data Veeam - dengan bantuan ejen tambahan yang dilancarkan pada proksi (dan bukan sahaja) ia terlibat dalam peralihan data. Sebagai contoh, apabila membuat sandaran, seorang ejen akan membaca fail daripada stor data hos, dan yang kedua akan menulisnya dengan teliti ke sandaran.
Secara berasingan, saya ingin ambil perhatian satu perkara penting yang pelanggan sering bertindak balas - ini ialah perbezaan dalam versi perkhidmatan dan maklumat dalam snap-in Program dan Ciri. Ya, senarainya akan sama, tetapi versinya boleh menjadi sumbang sepenuhnya. Ia tidak begitu hebat dari sudut pandangan visual, tetapi ia benar-benar normal jika semuanya berfungsi dengan stabil. Sebagai contoh, untuk perkhidmatan Pemasang, nombor versi jauh di belakang nombor yang berdekatan. Seram dan mimpi ngeri? Tidak, kerana ia tidak dipasang semula sepenuhnya, tetapi DLLnya hanya dikemas kini. Dalam tampung v9.5 U4, mimpi ngeri sokongan teknikal berlaku: semasa kemas kini, semua perkhidmatan menerima versi baharu, kecuali yang paling penting. Dalam tampung U4b, perkhidmatan pengangkutan mengatasi semua yang lain sebanyak dua versi (berdasarkan nombor). Dan ini juga biasa - pepijat yang serius ditemui di dalamnya, jadi ia menerima kemas kini bonus berbanding yang lain. Jadi untuk meringkaskannya: perbezaan versi BOLEH menjadi masalah, tetapi jika terdapat perbezaan dan semuanya berfungsi dengan baik, maka ia mungkin sepatutnya. Tetapi tiada siapa yang melarang anda untuk menjelaskan perkara ini dalam sokongan teknikal.
Ini adalah apa yang dipanggil perkhidmatan mandatori atau Mandatori. Dan terdapat sejumlah besar alat bantu, seperti Perkhidmatan Pita, Perkhidmatan Gunung, Perkhidmatan vPowerNFS dan sebagainya.
Untuk Hyper-V, secara umum, semuanya sama, cuma ada yang khusus Perkhidmatan Integrasi Hyper-V Sandaran Veeam dan pemandu anda sendiri untuk bekerja dengan CBT.
Dan pada akhirnya, mari kita bercakap tentang siapa yang bekerja pada mesin maya semasa sandaran. Untuk menjalankan skrip pra dan selepas pembekuan, untuk membuat salinan bayangan, mengumpul metadata, bekerja dengan log transaksi SQL, dsb. Pembantu Tetamu Veeam. Dan jika sistem fail diindeks, Pengindeks Tetamu Veeam . Ini adalah perkhidmatan sementara yang digunakan untuk tempoh sandaran dan dialih keluar selepasnya.
Dalam kes mesin Linux, semuanya lebih mudah kerana kehadiran sejumlah besar perpustakaan terbina dalam dan keupayaan sistem itu sendiri. Sebagai contoh, pengindeksan dilakukan melalui mlocate.
Itu sahaja buat masa ini
Saya tak berani nak sakitkan awak lagi pendek Saya menganggap pengenalan kepada petak enjin Veeam sudah tamat. Ya, kami tidak mendekati sarang itu sendiri, tetapi percayalah, supaya maklumat yang disampaikan di dalamnya tidak kelihatan seperti aliran kesedaran yang tidak jelas, pengenalan seperti itu sangat diperlukan. Saya merancang untuk pergi ke log itu sendiri hanya dalam artikel ketiga, dan rancangan untuk yang seterusnya adalah untuk menerangkan siapa yang menjana log, apa sebenarnya yang dipaparkan di dalamnya dan mengapa sebenarnya, dan bukan sebaliknya.
Sumber: www.habr.com