Kolega saya yang luar biasa dari departemen dukungan teknis menulis tidak hanya berbahaya, tetapi juga tips dan trik yang berguna untuk menyiapkan Veeam Backup & Replication. Sejak publikasi artikel untuk pengguna pemula, penulisnya, Evgeny Ivanov, sambil terus bekerja sama dengan tim Rumania di Bucharest, telah pindah dari jabatan insinyur senior ke posisi pemimpin tim. Tetapi Eugene tidak meninggalkan bidang teknis dan sastra, yang karenanya banyak terima kasih kepadanya!
Artikel baru Zhenya berisi rekomendasi untuk spesialis Veeam Backup & Replication yang sudah berpengalaman yang dihadapkan dengan tugas untuk memanfaatkan sumber daya infrastruktur cadangan. Namun, artikel ini akan bermanfaat bagi mereka yang hanya berencana untuk menginstal dan mengkonfigurasi produk kami.

Optimalisasi distribusi beban di masa tabung hangat

Untuk tips yang bermanfaat, selamat datang di kucing.

Tentang kelebihan instalasi terdistribusi

Veeam Backup & Replication adalah perangkat lunak modular yang terdiri dari berbagai komponen, yang masing-masing menjalankan fungsi tertentu. Di antara komponen-komponen ini adalah direktur utama server cadangan Veeam, server proxy, repositori, akselerator WAN, dan lainnya. Sejumlah komponen dapat diinstal pada satu mesin (tentu saja, cukup kuat), yang dilakukan banyak pengguna. Namun, instalasi terdistribusi memiliki kelebihan, yaitu:

Untuk perusahaan dengan jaringan cabang, dimungkinkan untuk menginstal komponen yang diperlukan secara lokal di cabang-cabang ini. Ini membantu untuk mengoptimalkan lalu lintas, mengatur sebagian besar lagi secara lokal.
Seiring infrastruktur Anda tumbuh, Anda perlu meningkatkan solusi cadangan Anda. Jika cadangan lebih lama ("jendela cadangan" semakin besar), Anda dapat menginstal server proxy tambahan. Jika Anda perlu meningkatkan kapasitas repositori cadangan, Anda dapat mengonfigurasi repositori cadangan skala-out dan menambahkan luasan baru sesuai kebutuhan.
Untuk beberapa komponen, Anda dapat memastikan ketersediaan konstan (Ketersediaan Tinggi) - misalnya, jika Anda memiliki beberapa server proxy yang digunakan dan salah satu dari mereka tiba-tiba dimatikan, maka yang lain akan terus bekerja dan cadangan tidak akan terpengaruh.

Harus diingat bahwa sistem terdistribusi hanya akan efektif dengan distribusi beban yang masuk akal. Jika tidak, kemacetan dapat terjadi, kelebihan komponen individu - dan ini penuh dengan penurunan umum dalam produktivitas dan perlambatan.

Bagaimana data dikirimkan?

Untuk memiliki gagasan yang lebih jelas tentang di mana dan di mana data ditransfer selama proses pencadangan, pertimbangkan diagram ini (misalnya, ambil infrastruktur pada platform vSphere):

Seperti yang Anda lihat, data ditransfer dari lokasi sumber (sumber) ke target (target) menggunakan "agen transportasi" (VeeamAgent.exe) yang bekerja di kedua lokasi. Jadi, ketika pekerjaan cadangan berjalan, hal berikut terjadi:

Agen transportasi "sumber" berjalan pada server proxy; itu membaca data dari datastore, melakukan kompresi dan deduplikasi, dan mengirimkan data dalam bentuk ini ke agen transportasi "target".
Agen transportasi "target" berjalan langsung di repositori (Windows / Linux) atau di gateway (server gateway), jika CIFS digunakan. Agen ini, pada gilirannya, juga melakukan deduplikasi di sisinya dan menyimpan data dalam file cadangan (.VBK, .VIB, dll.).

Dengan demikian, 2 komponen selalu terlibat dalam pengiriman data, bahkan jika mereka sebenarnya berada di mesin yang sama. Ini harus dipertimbangkan ketika merencanakan penyebaran solusi.

Load balancing antara server proxy dan repositori

Pertama, mari kita mendefinisikan konsep "tugas". Dalam terminologi Veeam Backup & Replication, setiap tugas memproses satu disk mesin virtual. Artinya, jika Anda memiliki tugas cadangan (pekerjaan), yang mencakup 5 VM dengan masing-masing 2 disk, ini berarti Anda harus memproses 10 tugas (dan jika mesin hanya memiliki 1 disk, maka 1 tugas = 1 VM). Veeam Backup & Replication mampu memproses beberapa tugas secara paralel, tetapi jumlah mereka, tentu saja, tidak terbatas.

Untuk setiap server proxy di propertinya, Anda dapat menentukan jumlah tugas maksimum untuk eksekusi paralel:

Untuk operasi cadangan standar, interpretasi yang sama akan untuk repositori: satu tugas adalah untuk mentransfer data dari satu disk virtual. Di antarmuka, tampilannya sangat mirip:

Di sini kita harus memperbaiki aturan yang sangat penting No. 1: pastikan untuk menyeimbangkan saat menetapkan sumber daya proxy dan repositori dan ketika menentukan jumlah maksimum tugas untuk pemrosesan paralel!

Contoh

Misalkan Anda memiliki 3 proxy, yang masing-masing dapat memproses 4 tugas secara paralel (mis., Total 12 disk virtual dari sumber VM). Tetapi repositori dikonfigurasikan untuk hanya memproses 4 tugas secara paralel (omong-omong, ini adalah nilai default). Dengan pengaturan ini, hanya 4 drive yang akan disimpan secara paralel dari lokasi sumber ke tujuan, meskipun mereka bisa untuk semua 12. Artinya, sumber daya akan kekurangan beban.

Namun, ketika datang untuk membuat cadangan penuh sintetis (dan operasi serupa), konsep tugas relatif ke repositori mengambil makna yang sedikit berbeda. Kami ingat bahwa operasi seperti itu tidak melibatkan proxy, tetapi dilakukan secara lokal di repositori (Windows atau Linux) atau (dalam kasus berbagi CIFS) menggunakan gateway.

Dalam opsi ini, saat membangun rantai cadangan normal, tugas = tugas cadangan. Artinya, batas 4 tugas untuk pemrosesan paralel di sini akan berarti bahwa cadangan sintetis untuk 4 tugas cadangan dapat dibuat secara bersamaan di repositori.

Ketika membangun rantai cadangan didekomposisi sesuai dengan VM asli (yang disebut "penyimpanan dengan penyimpanan" - per-VM), tugas = 1 VM. Artinya, batas 4 tugas untuk pemrosesan paralel di sini akan berarti bahwa 4 file VBK untuk 4 mesin virtual dapat dihasilkan pada repositori secara bersamaan.

Jadi, kita sampai pada aturan No. 2: Bergantung pada pengaturan cadangan, jumlah tugas yang sama dapat berarti beban yang sama sekali berbeda pada repositori. Karena itu, ketika merencanakan sumber daya, Anda pasti perlu memeriksa pengaturan yang sama: mode cadangan, jadwal tugas, cara mengatur rantai cadangan.

Catatan: Tidak seperti pengaturan proxy, repositori dapat menonaktifkan batas jumlah tugas. Dalam hal ini, repositori akan menerima semua data yang berasal dari server proxy. Tapi ini hanya kebebasan nyata dari pembatasan, karena ada risiko kelebihan dan penyimpanan repositori dalam pekerjaan tugas cadangan. Karenanya, kami sangat tidak menyarankan untuk memberikan batasan ini.

Contoh lain

Misalkan Anda memiliki tugas cadangan yang mencakup sejumlah VM yang cukup besar dengan total 100 disk virtual. Pada saat yang sama, repositori dikonfigurasi untuk menyimpan rantai cadangan “dengan tangan” (per-VM). Pengaturan pemrosesan paralel adalah sebagai berikut: untuk proxy - 10 disk sekaligus, dan untuk repositori - tidak ada batasan. Selama cadangan tambahan, beban pada repositori akan terbatas karena pengaturan proxy, dan dengan demikian saldo akan dipertahankan. Tetapi kemudian tiba saatnya untuk membuat cadangan penuh sintetis. Cadangan seperti itu tidak menggunakan proxy, dan semua operasi untuk membuat "sintetis" berlangsung secara eksklusif di repositori. Karena tidak ada batasan pada pemrosesan paralel tugas-tugas untuk repositori, server repositori akan mencoba memproses seratus keseluruhan sekaligus. Ini akan membutuhkan tekanan sumber daya yang signifikan dan kemungkinan besar akan menyebabkan kelebihan.

Fitur menggunakan share CIFS sebagai repositori

Jika Anda bekerja dengan repositori yang didasarkan pada server Windows atau Linux, maka agen "target" mulai langsung di server ini. Namun, jika Anda menggunakan folder berbagi CIFS (berbagi CIFS) sebagai repositori, maka agen "target" dimulai pada mesin yang dirancang khusus untuk tujuan ini - inilah yang disebut "Gateway", yang akan menerima aliran data yang masuk dari agen di sisi VM sumber. Agen "target" akan menerima data ini dan kemudian mengirim blok data ke bola CIFS. Mesin bantu ini harus ditempatkan sedekat mungkin ke mesin yang menyediakan folder bersama SMB - ini sangat penting untuk skrip yang menggunakan konektivitas WAN.

Peraturan nomor 3: Anda tidak boleh menempatkan mesin bantu (proxy \ gateway) di satu situs, dan folder berbagi CIFS dibagikan di situs lain (termasuk di cloud) - jika tidak, Anda akan memiliki masalah jaringan yang konstan.

Anda juga dapat menerapkan ke gateway semua pertimbangan di atas untuk menyeimbangkan beban pada sistem. Selain itu, Anda harus ingat bahwa gateway memiliki 2 pengaturan tambahan: server dapat ditetapkan secara eksplisit atau dipilih secara otomatis:

Pada prinsipnya, setiap server Windows yang termasuk dalam infrastruktur cadangan Veeam dapat digunakan sebagai gateway. Bergantung pada skenario penempatan Anda, salah satu opsi mungkin cocok untuk Anda:

Server yang ditentukan secara eksplisit - ini, tentu saja, menyederhanakan banyak hal, karena Anda akan tahu persis mesin apa yang digunakan oleh agen "target". Opsi ini direkomendasikan, khususnya, untuk kasus-kasus ketika akses ke bola hanya diizinkan dari server tertentu, serta untuk skenario dengan infrastruktur terdistribusi - Anda mungkin ingin menggunakan agen pada mesin yang terletak di dekat file server dengan target sebagai orang yang masuk akal bolanya.
Server yang dipilih secara otomatis (Opsi pemilihan otomatis ). Di sini, hal-hal berubah menjadi menarik: jika Anda menggunakan beberapa server proxy, kemudian memilih opsi ini, ternyata, mengarah pada fakta bahwa program menggunakan lebih dari satu gateway, mendistribusikan beban. Saya perhatikan bahwa "secara otomatis" tidak berarti "sewenang-wenang" - aturan pemilihan yang cukup spesifik diterapkan di sini.

Bagaimana cara kerjanya?

Agen "target" dimulai pada server proxy yang melakukan pencadangan.

Dalam kasus rantai cadangan biasa, logikanya adalah ini: jika ada beberapa tugas yang dieksekusi secara bersamaan, masing-masing dengan server proxy sendiri, maka Anda dapat menjalankan beberapa agen "target". Namun, dalam satu pekerjaan, logikanya berbeda: bahkan jika VM yang terkandung di dalamnya diproses oleh proxy yang berbeda, agen "target" akan diluncurkan hanya pada satu - pada yang akan mulai bekerja terlebih dahulu.
Dalam kasus rantai cadangan "rantai", agen "target" yang terpisah diluncurkan untuk setiap VM. Jadi, bahkan dalam tugas yang sama, distribusi beban terjadi.

Saat membuat cadangan sintetis, server proxy tidak digunakan, dan di sini mesin untuk memulai agen "target" dipilih sebagai berikut: ambil server mount bantu (server mount tempat file dipasang, misalnya, selama operasi pemulihan) yang terkait dengan repositori, dan itu memulai agen. Jika server mount tidak tersedia karena alasan tertentu, dimungkinkan untuk beralih ke utara cadangan Veeam. Seperti yang Anda pahami, tidak akan ada distribusi muatan di versi ini.

Oleh karena itu, saya ulangi: ( PENTING! ) Tidak disarankan untuk skenario seperti itu untuk menghapus batas jumlah tugas yang diproses secara paralel, karena ketika melakukan operasi dengan "sintetis" ini dapat menyebabkan kelebihan yang berlebihan dari server mount atau bahkan server cadangan Veeam.

Fitur tambahan

Repositori yang dapat diukur. SOBR adalah seperangkat repositori standar (di sini mereka disebut "luasan"). Jika Anda sudah menggunakan SOBR, maka dalam tugas cadangan tentukan itu, dan tidak sejauh. Sejauh ini, Anda dapat menggunakan beberapa pengaturan, misalnya, load balancing.

Semua prinsip dasar yang berfungsi untuk repositori reguler juga berfungsi untuk SOBR. Untuk mengoptimalkan penggunaan sumber daya, Anda dapat menyarankan pengaturan SOBR dengan penyimpanan cadangan "crypto" (per-VM - ini adalah opsi default), dengan kebijakan penempatan "Kinerja" ("optimalkan kinerja yang lebih baik") dan distribusi rantai di seluruh repositori-tingkat-s.

Transfer cadangan (salinan cadangan). Di sini, agen "sumber" akan bekerja pada repositori sumber. Segala sesuatu yang disebutkan di atas juga berlaku untuk repositori sumber (kecuali untuk fakta bahwa dalam kasus pekerjaan transfer Cadangan Salin Cadangan, operasi dengan "sintetis" tidak dilakukan pada repositori sumber).

Catatan: Jika repositori sumber adalah bagian CIFS, maka agen "sumber" dimulai pada server pemasangan yang sesuai (dengan kemampuan untuk beralih ke server cadangan Veeam).

Perangkat dengan deduplikasi bawaan. Untuk sistem penyimpanan DataDomain dan StoreOnce (dan mungkin untuk orang lain di masa mendatang), yang untuknya integrasi dengan Veeam dikonfigurasikan, pertimbangan yang sama berlaku untuk pangsa CIFS. Untuk repositori di StoreOnce dengan deduplikasi di sisi sumber (mode Bandwidth Rendah ), hanya persyaratan untuk menempatkan gateway sedekat mungkin ke repositori mungkin kehilangan relevansi - gateway di satu situs dapat dikonfigurasi untuk mengirim data ke StoreOnce di situs lain melalui WAN.

Server proxy yang disukai. Fitur ini muncul, seperti yang Anda ingat, dalam rilis 9.5, dan bertanggung jawab untuk memelihara "daftar prioritas proxy" yang akan dipatuhi program ketika bekerja dengan repositori tertentu.

Jika proksi dari daftar ini tidak tersedia, maka tugas akan berfungsi dengan yang lain tersedia. Namun, jika ada akses ke proxy, tetapi server proxy tidak memiliki slot gratis untuk memproses tugas, maka tugas cadangan akan ditangguhkan sambil menunggu mereka. Oleh karena itu, Anda perlu menggunakan fitur ini dengan sangat hati-hati (dan tidak dalam gaya "dihidupkan dan dilupakan") - kami memiliki pengguna yang dengan demikian "menutup" tugas cadangan. Anda dapat membaca lebih lanjut tentang fitur ini di sini (dalam bahasa Inggris).

Kesimpulannya

Tidak masalah jika Anda menginstal Veeam Backup & Replication untuk pertama kalinya atau Anda adalah pengguna lama - saya ingin percaya bahwa dalam artikel ini Anda akan menemukan informasi yang berguna bagi Anda dan dengan bantuannya mengoptimalkan operasi infrastruktur cadangan atau bahkan menghilangkan potensi risiko kehilangan data. Berikut ini beberapa tautan yang lebih berguna:

Optimalkan load balancing dalam infrastruktur Veeam Backup & Replication