Hai, saya baru-baru ini menemukan tugas yang menarik: menyiapkan penyimpanan untuk mencadangkan sejumlah besar perangkat blok.
Kami mencadangkan semua mesin virtual di cloud kami setiap minggu, jadi kami harus mampu mengelola ribuan cadangan secepat dan seefisien mungkin.
Sayangnya, konfigurasi standar RAID5, RAID6 Dalam kasus ini, mereka tidak akan mau melakukannya karena proses pemulihan pada disk sebesar milik kami akan sangat lama dan kemungkinan besar tidak akan pernah berakhir.
Mari kita pertimbangkan apa saja alternatif yang ada:
— Mirip dengan RAID5 dan RAID6, tetapi dengan tingkat paritas yang dapat dikonfigurasi. Dalam hal ini, redundansi dilakukan bukan per blok, melainkan per objek. Cara paling sederhana untuk mencoba pengkodean penghapusan adalah dengan menerapkan .
— Ini adalah fitur ZFS yang saat ini belum dirilis. Tidak seperti RAIDZ, DRAID memiliki blok paritas terdistribusi dan memanfaatkan semua disk dalam array selama pemulihan, membuatnya lebih tangguh terhadap kegagalan disk dan pulih lebih cepat setelah terjadi kerusakan.
Ada server yang tersedia Fujitsu Primergy RX300 S7 dengan prosesor Prosesor Intel Xeon E5-2650L 0 @ 1.80GHz, sembilan modul RAM Samsung DDR3-1333 8Gb PC3L-10600R ECC Terdaftar (M393B1K70DH0-YH9), rak cakram Supermicro SuperChassis 847E26-RJBOD1, terhubung melalui Ekspander LSI SAS2X36 Ganda dan 45 cakram Seagage ST6000NM0115-1YZ110 pada 6TB semuanya.
Sebelum kita memutuskan sesuatu, pertama-tama kita perlu menguji semuanya dengan benar.
Untuk melakukan ini, saya menyiapkan dan menguji berbagai konfigurasi. Untuk ini, saya menggunakan minio, yang bertindak sebagai backend S3 dan menjalankannya dalam berbagai mode dengan jumlah target yang berbeda-beda.
Kasus minio terutama diuji dalam pengkodean penghapusan vs. raid perangkat lunak dengan jumlah disk dan disk paritas yang sama, yaitu: RAID6, RAIDZ2 dan DRAID2.
Sebagai referensi: ketika Anda menjalankan minio hanya dengan satu target, minio beroperasi dalam mode gateway S3, yang menjadikan sistem berkas lokal Anda sebagai penyimpanan S3. Jika Anda menjalankan minio dengan beberapa target, mode Erasure Coding akan otomatis diaktifkan, yang akan menyebarkan data ke seluruh target Anda, sehingga memberikan toleransi kesalahan.
Secara default, minio membagi target ke dalam kelompok-kelompok yang terdiri dari 16 disk, dengan dua disk paritas per kelompok. Ini berarti dua disk dapat gagal secara bersamaan tanpa kehilangan data.
Untuk pengujian kinerja, saya menggunakan 16 disk, masing-masing berkapasitas 6 TB, dan menuliskan objek kecil berukuran 1 MB ke dalamnya. Hal ini secara akurat menggambarkan beban kerja kami di masa mendatang, karena semua alat pencadangan modern membagi data ke dalam blok-blok berukuran beberapa megabita dan menuliskannya dengan cara tersebut.
Untuk melakukan benchmark, utilitas s3bench dijalankan di server jarak jauh, mengirimkan puluhan ribu objek tersebut ke minio melalui ratusan thread. Kemudian, utilitas tersebut mencoba meminta objek tersebut kembali dengan cara yang sama.
Hasil benchmark ditunjukkan pada tabel berikut:
Seperti yang dapat kita lihat, minio dalam mode pengkodean penghapusan asli berkinerja jauh lebih buruk pada penulisan daripada minio yang berjalan di atas perangkat lunak RAID6, RAIDZ2, dan DRAID2 dalam konfigurasi yang sama.
Secara terpisah saya Saya menguji minio di ext4 vs. XFS. Anehnya, untuk jenis beban kerja saya, XFS ternyata jauh lebih lambat daripada ext4.
Pada batch pengujian pertama Mdadm menunjukkan keunggulan atas ZFS, tetapi kemudian , bahwa Anda dapat meningkatkan kinerja ZFS dengan menetapkan opsi berikut:
xattr=sa atime=off recordsize=1Mdan setelah itu pengujian dengan ZFS menjadi jauh lebih baik.
Anda juga dapat melihat bahwa DRAID tidak memberikan peningkatan kinerja yang signifikan atas RAIDZ, tetapi secara teori seharusnya jauh lebih aman.
Dalam dua pengujian terakhir, saya juga mencoba memindahkan metadata (khusus) dan ZIL (log) ke mirror SSD. Namun, pemindahan metadata tersebut tidak memberikan banyak manfaat pada kecepatan tulis, dan pemindahan ZIL mengakibatkan Kami mencapai batas utilisasi 100%, jadi saya menganggap pengujian ini gagal. Saya tidak menutup kemungkinan jika saya memiliki drive SSD yang lebih cepat, hasilnya mungkin akan meningkat secara signifikan, tetapi sayangnya, saya tidak memilikinya.
Pada akhirnya, saya memutuskan untuk berhenti menggunakan DRAID dan meskipun statusnya beta, ini adalah solusi penyimpanan tercepat dan paling efisien dalam kasus kami.
Saya membuat DRAID2 sederhana dalam konfigurasi dengan tiga grup dan dua suku cadang terdistribusi:
# zpool status data
pool: data
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
draid2:3g:2s-0 ONLINE 0 0 0
sdy ONLINE 0 0 0
sdam ONLINE 0 0 0
sdf ONLINE 0 0 0
sdau ONLINE 0 0 0
sdab ONLINE 0 0 0
sdo ONLINE 0 0 0
sdw ONLINE 0 0 0
sdak ONLINE 0 0 0
sdd ONLINE 0 0 0
sdas ONLINE 0 0 0
sdm ONLINE 0 0 0
sdu ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdk ONLINE 0 0 0
sds ONLINE 0 0 0
sdag ONLINE 0 0 0
sdi ONLINE 0 0 0
sdq ONLINE 0 0 0
sdae ONLINE 0 0 0
sdz ONLINE 0 0 0
sdan ONLINE 0 0 0
sdg ONLINE 0 0 0
sdac ONLINE 0 0 0
sdx ONLINE 0 0 0
sdal ONLINE 0 0 0
sde ONLINE 0 0 0
sdat ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdn ONLINE 0 0 0
sdv ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdc ONLINE 0 0 0
sdar ONLINE 0 0 0
sdl ONLINE 0 0 0
sdt ONLINE 0 0 0
sdah ONLINE 0 0 0
sdap ONLINE 0 0 0
sdj ONLINE 0 0 0
sdr ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdao ONLINE 0 0 0
sdh ONLINE 0 0 0
sdp ONLINE 0 0 0
sdad ONLINE 0 0 0
spares
s0-draid2:3g:2s-0 AVAIL
s1-draid2:3g:2s-0 AVAIL
errors: No known data errorsOke, kita sudah membahas penyimpanan, sekarang mari kita bahas solusi pencadangan. Saya ingin berbagi tiga solusi yang sudah saya coba:
- garpu , solusi pencadangan perangkat blok khusus, memiliki integrasi yang erat dengan Ceph. Solusi ini dapat mengekstrak diff antar snapshot dan membuat cadangan inkremental darinya. Mendukung berbagai backend penyimpanan, termasuk lokal dan S3. Membutuhkan database terpisah untuk menyimpan tabel hash deduplikasi. Kekurangan: Ditulis dengan Python dan memiliki CLI yang agak kurang responsif.
- garpu , alat pencadangan yang telah lama dikenal dan terbukti, dapat mencadangkan data dan mendeduplikasinya dengan baik. Alat ini dapat menyimpan cadangan baik secara lokal maupun ke server jarak jauh melalui scp. Alat ini dapat mencadangkan perangkat blok jika dijalankan dengan tanda . --specialKekurangannya, saat membuat cadangan, repositori terkunci sepenuhnya, jadi disarankan untuk membuat repositori terpisah untuk setiap mesin virtual. Hal ini tidak menjadi masalah, karena pembuatannya mudah.
— sebuah proyek yang sedang dikembangkan secara aktif, ditulis dalam bahasa Go, cukup cepat dan mendukung banyak backend penyimpanan, termasuk penyimpanan lokal, scp, S3, dan banyak lagi. Perlu dicatat juga bahwa ada fitur yang dibuat khusus untuk restic, yang memungkinkan ekspor penyimpanan tercepat untuk penggunaan jarak jauh. Dari semua yang disebutkan di atas, saya paling suka yang ini. Dapat dicadangkan dari stdin. Hampir tidak ada kekurangan yang terlihat, tetapi ada beberapa keanehan:
Pertama, saya mencoba menggunakannya sebagai repositori bersama untuk semua VM (seperti Benji), dan berfungsi dengan baik, tetapi operasi pemulihan membutuhkan waktu yang sangat lama karena Restic mencoba membaca metadata semua cadangan sebelum setiap pemulihan. Masalah ini mudah diatasi, seperti halnya dengan Borg, dengan membuat repositori terpisah untuk setiap VM. Pendekatan ini juga terbukti sangat efektif untuk manajemen cadangan. Repositori terpisah dapat memiliki kata sandi terpisah untuk mengakses data, dan kita tidak perlu khawatir repositori global akan rusak. Membuat repositori baru sama mudahnya dengan cadangan Borg.
Bagaimanapun, deduplikasi dilakukan hanya relatif terhadap versi cadangan sebelumnya, cadangan sebelumnya ditentukan oleh jalur untuk cadangan yang ditentukan, jadi jika Anda mencadangkan objek yang berbeda dari stdin ke repositori umum, jangan lupa untuk menentukan opsi
--stdin-filename, atau secara eksplisit menentukan opsi setiap kali--parent.
Kedua, pemulihan ke stdout membutuhkan waktu yang jauh lebih lama daripada pemulihan ke sistem berkas karena sifatnya yang paralel. Ke depannya, kami berencana untuk menambahkan dukungan yang lebih ketat untuk pencadangan perangkat blok.
Ketiga, saat ini direkomendasikan untuk menggunakan , karena versi 0.9.6 memiliki bug dengan pemulihan file besar yang lama.
Untuk menguji efisiensi pencadangan dan kecepatan pencadangan/pemulihan, saya membuat repositori terpisah dan mencoba mencadangkan citra mesin virtual kecil (21 GB). Saya melakukan dua pencadangan tanpa mengubah citra aslinya, menggunakan masing-masing solusi yang tercantum, untuk menguji seberapa cepat/lambat data yang dideduplikasi disalin.
Seperti yang dapat kita lihat, Borg Backup memiliki rasio efisiensi pencadangan awal terbaik, tetapi kalah dalam hal kecepatan tulis dan pemulihan.
Restic ternyata lebih cepat daripada Benji Backup, tetapi butuh waktu lebih lama untuk memulihkan ke stdout, dan sayangnya, belum bisa menulis langsung ke perangkat blok.
Setelah mempertimbangkan semua pro dan kontra, saya memutuskan untuk memutuskan istirahat с server istirahat sebagai solusi cadangan yang paling nyaman dan menjanjikan.
Dalam rekaman layar ini, Anda dapat melihat bagaimana kanal 10 Gigabit dimanfaatkan sepenuhnya oleh beberapa operasi pencadangan yang berjalan secara bersamaan. Perlu dicatat bahwa utilisasi disk tidak melebihi 30%.
Saya lebih dari puas dengan keputusan yang saya terima!
Sumber: www.habr.com
