Arsitektur Solusi Backup dengan menggunakan Veeam dan Ceph

Arsitektur dari melakukan backup mesin virtual pada VMWare dan Hyper-V mirip. Veeam menggunakan data mover untuk mentransfer data dari host sumber ke repositori backup. Data mover berjalan pada server proxy dan server repositori. Untuk menggunakan Ceph sebagai penyimpanan backend dari repositori backup, Anda dapat melakukan mount RBD atau CephFS pada server fisik Linux atau mesin virtual sebagai server repositori.

Jika server proxy dan server repositori adalah mesin virtual di dalam kluster hipervisor, Anda dapat memperoleh manfaat dari pengangkutan data berkecepatan tinggi tanpa jaringan antara disk VM, server proxy, dan server repositori. Konfigurasi terbaik dari sebuah kluster hypervisor besar adalah dengan mendeploy satu server proxy VM dan satu server repositori VM pada setiap host VMWare. Atau, Anda dapat mendeploy satu backup proxy VM pada setiap host VMWare dan satu host repositori off-host untuk mengurangi beban kerja dari VMWare produksi Anda.

Ada tiga cara untuk menggunakan perangkat Ambedded Ceph sebagai repositori untuk Veeam Backup and Replication.CephFS dan perangkat blok RBD dapat digunakan sebagai repositori cadangan on-premises.Penyimpanan objek S3 dapat digunakan sebagai lapisan kapasitas untuk lokasi jarak jauh.

Untuk cara mengatur blok perangkat Ceph RBD dan sistem file CephFS sebagai repositori cadangan Veeam untuk mencadangkan mesin virtual dan file, Anda dapat menemukan detailnya pada white paper di bagian akhir halaman ini.

Lingkungan Uji

Kluster Ceph

• Tiga Mars 400 dengan 3x monitor, 20 OSD, dan 1x MDS (server metadata)
• Setiap daemon Ceph berjalan pada satu mikroserver Arm A72 dual-core
• Sistem Operasi: CentOS 7
• Perangkat lunak Ceph: Nautilus 14.2.9 Arm64
• Jaringan: 4x jaringan 10Gb per Mars 400 

Veeam Backup & Replication 10, Versi: 10.0.1.4854

Server Backup Veeam

• CPU: Intel Xeon E5-2630 2.3GHz DUAL
• DRAM: 64GB
• Jaringan: 2x 10Gb sfp+ bonding
• Diska: 1TB untuk sistem, 256GB SATA3 SSD untuk volume
• Windows Server 2019

 Server Proxy Veeam

• diletakkan bersama dengan Server Cadangan Veeam

 Server Repositori

• Mesin Maya

◇ CPU: 4 inti 2.3GHz

◇  DRAM: 8GB

◇  Jaringan: jembatan

◇  Disk: disk virtual 50GB

◇  OS: CentOS 7.8.2003

• Server Baremetal

◇  CPU: Intel Xeon X5650 2.67GHz DUAL

◇  DRAM: 48GB

◇  Jaringan: 2-port 10Gb sfp+ ikatan

◇  Disk: 1TB untuk sistem

◇  OS: CentOS 7.6.1810

Tuan Rumah Hyper-V

◇  CPU: Intel Xeon E5-2630 2.3GHz DUAL

◇  DRAM: 64GB

◇ Jaringan: Ikatan 2-port 10Gb sfp+

◇ Disk: 1TB untuk sistem

◇  Server Windows 2019

Tuan Rumah VMWare

◇  CPU: Intel Xeon E5-2630 2.3GHz DUAL

◇  DRAM: 64GB

◇ Jaringan: Ikatan 2-port 10Gb sfp+

◇ Disk: 1TB untuk sistem

◇  ESXi 6.5

Jaringan: Sakelar 10GbE

Tanda Acuan pada Berbagai Penyiapan

Untuk menandai acuan kinerja cadangan dari berbagai repositori cadangan, kami menyiapkan tes dengan repositori cadangan yang berbeda dan tiga sumber cadangan.

Sumber cadangan yang kami gunakan untuk tes adalah volume berbasis SSD SATA pada server, VM Windows dari Hyper-V, dan VM CentOS 7 dan VM Windows dari VMWare.

(1) Cadangkan volume pada Drive SSD

Tabel 1. Cadangkan volume dari server dengan SSD SATA.

Tabel 2.

Catatan: Tingkat Tulis Data Rata-rata dihitung dengan membagi Data yang Ditransfer dengan Durasi. Tingkat ini mewakili beban kerja klaster Ceph dalam pekerjaan backup ini.

(2)Backup sebuah VM Windows 10 di Hyper-V pada HDD

Dalam benchmark ini, kami mencadangkan instansi Hyper-V yang disimpan di hard disk SATA. Laju pemrosesan pekerjaan-pekerjaan ini mencapai batas atas bandwidth HDD. Kita juga dapat menemukan bottleneck di sumber karena beban mereka sibuk selama 99% dari durasi pekerjaan. Klaster Ceph, target, beban kerja dari pekerjaan backup Veeam ringan. Klaster Ceph hanya sibuk pada 6% hingga 1% dari waktu kerja.

Dibandingkan dengan benchmark sebelumnya, tingkat pemrosesan dari backup VM jauh lebih rendah dibandingkan dengan backup SSD.Ini terutama karena data VM disimpan di hard drive.

Tabel 3.

Tabel 4. Cadangkan gambar mesin virtual pada HDD SATA3

Catatan: Tingkat Tulis Data Rata-rata dihitung dengan membagi Data yang Ditransfer dengan Durasi. Tingkat ini mewakili beban kerja klaster Ceph dalam pekerjaan backup ini.

(3)Cadangkan Mesin Virtual pada ESXi di HDD

Uji coba ini mencadangkan mesin virtual CentOS 7 dan Windows 10 yang berjalan pada HDD host VMWare ESXi 6.5 ke repositori yang didukung oleh Ceph RBD dengan perlindungan kode erasure 4+2.

Tabel 5.

Tabel 6.

Catatan: Tingkat Tulis Data Rata-rata dihitung dengan membagi Data yang Ditransfer dengan Durasi. Tingkat ini mewakili beban kerja klaster Ceph dalam pekerjaan backup ini.

Kesimpulan

Menurut hasil uji, Ceph RBD dan CephFS memiliki performa yang serupa. Ini sesuai dengan pengalaman kami mengenai benchmark kinerja RBD dan CephFS. Membandingkan karakteristik CephFS dan RBD, keduanya memiliki kelebihan dan kekurangan masing-masing. Jika Anda perlu mendeploy beberapa server repositori, Anda harus membuat gambar RBD untuk setiap server repositori cadangan karena Anda hanya dapat melakukan mount Ceph RBD pada satu host. Dibandingkan dengan CephFS, penggunaan RBD lebih sederhana karena tidak memerlukan server metadata. Kita harus menetapkan ukuran kapasitas RBD saat dibuat, jadi Anda harus mengubah ukurannya saat Anda membutuhkan lebih banyak ruang.

Jika Anda menggunakan CephFS sebagai repositori, Anda harus mendeploy setidaknya satu metadata server (MDS) di dalam klaster Ceph. Kami juga membutuhkan standby metadata server untuk ketersediaan tinggi. Dibandingkan dengan Ceph RBD, Anda tidak perlu memberikan kuota pada sistem file. Jadi, Anda dapat memperlakukan CephFS sebagai kolam penyimpanan yang tidak terbatas.

Dalam demonstrasi kasus penggunaan ini, tes kami hanya mencadangkan satu VM dalam setiap pekerjaan pencadangan. Berdasarkan laporan tes di atas, kami mengetahui bahwa tingkat penulisan data rata-rata terkait dengan tingkat pemrosesan dan efisiensi deduplikasi dan kompresi data. Disk sumber yang lebih cepat mengurangi durasi pekerjaan pencadangan dan menghasilkan tingkat pemrosesan yang lebih cepat. Tergantung pada infrastruktur pengguna, pengguna dapat menerapkan beberapa pekerjaan simultan untuk mencadangkan objek yang berbeda secara bersamaan. Penyimpanan Ceph sangat baik dalam mendukung beberapa pekerjaan simultan.

Sebuah klaster Ceph OSD HDD 20x yang didukung oleh 3x Ambedded Mars 400 dapat menawarkan throughput tulis agregat hingga 700MB/s ke dalam pool kode erasure 4+2. Mendeploy beberapa pekerjaan backup saat ini memberikan manfaat dalam mengurangi durasi backup secara keseluruhan. Kinerja maksimum dari sebuah klaster Ceph hampir proporsional secara linier dengan jumlah total drive disk dalam klaster.

Dalam kasus penggunaan ini, kami tidak menguji menggunakan penyimpanan objek S3 sebagai repositori cadangan. Penyimpanan objek S3 dapat digunakan sebagai tier kapasitas dalam repositori cadangan Veeam Scale-Out dan repositori arsip target untuk pencadangan NAS. Anda dapat dengan mudah mengatur gateway RADOS dan membuat pengguna penyimpanan objek dengan mudah menggunakan manajer UVS Ambedded, antarmuka web manajemen ceph.