Halo, baru-baru ini saya menemukan masalah menarik: menyiapkan penyimpanan untuk mencadangkan sejumlah besar perangkat blok.
Setiap minggu kami mencadangkan semua mesin virtual di cloud kami, jadi kami harus mampu memelihara ribuan cadangan dan melakukannya secepat dan seefisien mungkin.
Sayangnya, konfigurasi standar RAID5, RAID6 dalam hal ini, kami tidak akan diizinkan melakukan ini, karena proses pemulihan pada disk sebesar milik kami akan sangat lama dan kemungkinan besar tidak akan pernah berakhir.
Mari kita lihat alternatif apa saja yang ada:
β Mirip dengan RAID5, RAID6, tetapi dengan tingkat paritas yang dapat dikonfigurasi. Dalam hal ini, reservasi dilakukan bukan blok demi blok, tetapi untuk setiap objek secara terpisah. Cara termudah untuk mencoba pengkodean penghapusan adalah dengan memperluas .
adalah fitur ZFS yang saat ini belum dirilis. Tidak seperti RAIDZ, DRAID memiliki blok paritas terdistribusi dan, selama pemulihan, menggunakan semua disk dalam array sekaligus, yang membuatnya lebih mampu bertahan dari kegagalan disk dan pulih lebih cepat setelah kegagalan.
Server tersedia Fujitsu Primergy RX300 S7 dengan prosesor CPU Intel Xeon E5-2650L 0 @ 1.80GHz, sembilan batang RAM Samsung DDR3-1333 8Gb PC3L-10600R ECC Terdaftar (M393B1K70DH0-YH9), rak disk Supermikro SuperChassis 847E26-RJBOD1, terhubung melalui Ekspander LSI SAS2X36 Ganda dan 45 disc Seagage ST6000NM0115-1YZ110 pada 6TB semuanya.
Sebelum kita memutuskan apa pun, pertama-tama kita perlu menguji semuanya dengan benar.
Untuk melakukan ini, saya menyiapkan dan menguji berbagai konfigurasi. Untuk melakukan ini, saya menggunakan minio, yang bertindak sebagai backend S3 dan meluncurkannya dalam mode berbeda dengan jumlah target berbeda.
Pada dasarnya, kasus minio diuji dalam pengkodean penghapusan vs serangan perangkat lunak dengan jumlah disk dan paritas disk yang sama, yaitu: RAID6, RAIDZ2 dan DRAID2.
Sebagai referensi: ketika Anda meluncurkan minio hanya dengan satu target, minio bekerja dalam mode gateway S3, mengirimkan sistem file lokal Anda dalam bentuk penyimpanan S3. Jika Anda meluncurkan minio dengan menentukan beberapa target, mode Erasure Coding akan otomatis aktif, yang akan menyebarkan data di antara target Anda sambil memberikan toleransi kesalahan.
Secara default, minio membagi target menjadi grup yang terdiri dari 16 disk, dengan 2 paritas per grup. Itu. Dua disk bisa gagal secara bersamaan tanpa kehilangan data.
Untuk menguji kinerja, saya menggunakan 16 disk masing-masing 6TB dan menulis objek kecil berukuran 1MB ke dalamnya, ini paling akurat menggambarkan beban masa depan kita, karena semua alat pencadangan modern membagi data menjadi blok-blok beberapa megabita dan menulisnya dengan cara ini.
Untuk melakukan benchmark, kami menggunakan utilitas s3bench, diluncurkan pada server jarak jauh dan mengirimkan puluhan ribu objek tersebut ke minio dalam ratusan thread. Setelah itu saya mencoba memintanya kembali dengan cara yang sama.
Hasil benchmarknya terlihat pada tabel berikut:
Seperti yang bisa kita lihat, minio dalam mode pengkodean penghapusannya memiliki kinerja penulisan yang jauh lebih buruk daripada minio yang berjalan di atas perangkat lunak RAID6, RAIDZ2, dan DRAID2 dalam konfigurasi yang sama.
Secara terpisah saya uji minio pada ext4 vs XFS. Anehnya, untuk jenis beban kerja saya, XFS ternyata jauh lebih lambat dibandingkan ext4.
Pada pengujian gelombang pertama, Mdadm menunjukkan keunggulan dibandingkan ZFS, tetapi kemudian bahwa Anda dapat meningkatkan kinerja ZFS dengan mengatur opsi berikut:
xattr=sa atime=off recordsize=1Mdan setelah itu pengujian dengan ZFS menjadi jauh lebih baik.
Anda juga dapat mencatat bahwa DRAID tidak memberikan banyak peningkatan kinerja dibandingkan RAIDZ, namun secara teori seharusnya lebih aman.
Dalam dua pengujian terakhir, saya juga mencoba mentransfer metadata (khusus) dan ZIL (log) ke mirror dari SSD. Namun menghapus metadata tidak memberikan banyak peningkatan dalam kecepatan perekaman, dan saat menghapus ZIL, saya mencapai batas tertinggi dengan pemanfaatan 100%, jadi saya menganggap tes ini gagal. Saya tidak mengecualikan bahwa jika saya memiliki drive SSD yang lebih cepat, mungkin ini dapat meningkatkan hasil saya secara signifikan, tetapi sayangnya, saya tidak memilikinya.
Pada akhirnya, saya memutuskan untuk menggunakan DRAID dan meskipun berstatus 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 membereskan penyimpanannya, sekarang mari kita bicara tentang apa yang akan kita cadangankan. Disini saya ingin langsung membahas tentang tiga solusi yang berhasil saya coba, yaitu:
- garpu , solusi khusus untuk cadangan perangkat blok, memiliki integrasi erat dengan Ceph. Dapat mengambil perbedaan antar snapshot dan membentuk cadangan tambahan dari snapshot tersebut. Mendukung sejumlah besar backend penyimpanan, termasuk lokal dan S3. Membutuhkan database terpisah untuk menyimpan tabel hash deduplikasi. Kekurangan: ditulis dengan python, memiliki cli yang sedikit tidak responsif.
- garpu , alat pencadangan yang sudah lama dikenal dan terbukti, dapat mencadangkan data dan menghapus duplikatnya dengan baik. Mampu menyimpan backup baik secara lokal maupun ke server jauh melalui scp. Dapat mencadangkan perangkat blok jika diluncurkan dengan bendera --special, salah satu kekurangannya: saat membuat cadangan, repositori diblokir sepenuhnya, jadi disarankan untuk membuat repositori terpisah untuk setiap mesin virtual, pada prinsipnya ini tidak menjadi masalah, untungnya dibuat dengan sangat mudah.
adalah proyek yang aktif berkembang, ditulis dalam go, cukup cepat dan mendukung sejumlah besar backend penyimpanan, termasuk penyimpanan lokal, scp, S3, dan banyak lagi. Secara terpisah, saya ingin mencatat bahwa ada yang dibuat khusus untuk istirahat, yang memungkinkan Anda mengekspor penyimpanan dengan cepat untuk digunakan dari jarak jauh. Dari semua hal di atas, saya paling menyukainya. Dapat membuat cadangan dari stdin. Hampir tidak ada kekurangan yang nyata, tetapi ada beberapa fitur:
-
Pertama, saya mencoba menggunakannya dalam mode repositori umum untuk semua mesin virtual (seperti Benji) dan bahkan bekerja dengan cukup baik, tetapi operasi pemulihan memakan waktu yang sangat lama, karena... Setiap kali sebelum memulihkan, restic mencoba membaca metadata semua cadangan. Masalah ini mudah diselesaikan, seperti halnya borg, dengan membuat repositori terpisah untuk setiap mesin virtual. Pendekatan ini juga terbukti sangat efektif untuk mengelola cadangan. Repositori terpisah dapat memiliki kata sandi terpisah untuk mengakses data, dan kita juga tidak perlu takut bahwa repo global akan rusak. Anda dapat membuat repositori baru semudah di cadangan borg.
Bagaimanapun, deduplikasi hanya dilakukan 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 pilihan
--stdin-filename, atau tentukan opsi secara eksplisit setiap saat--parent.
-
Kedua, pemulihan ke stdout membutuhkan waktu lebih lama daripada pemulihan ke sistem file karena sifatnya yang paralel. Di masa depan, kami berencana untuk menambahkan lebih banyak dukungan untuk pencadangan untuk perangkat blok.
-
Ketiga, saat ini disarankan untuk digunakan , Karena versi 0.9.6 memiliki bug dengan pemulihan file besar yang lama.
Untuk menguji efektivitas pencadangan dan kecepatan menulis/memulihkan dari cadangan, saya membuat repositori terpisah dan mencoba membuat cadangan image kecil dari mesin virtual (21 GB). Dua pencadangan dilakukan tanpa mengubah yang asli, menggunakan masing-masing solusi yang tercantum untuk memeriksa seberapa cepat/lambat penyalinan data yang dihapus duplikatnya.
Seperti yang bisa kita lihat, Borg Backup memiliki rasio efisiensi pencadangan awal terbaik, namun lebih rendah dalam hal kecepatan tulis dan pemulihan.
Restic ternyata lebih cepat daripada Benji Backup, tetapi membutuhkan waktu lebih lama untuk memulihkan ke stdout, dan sayangnya, ia belum dapat menulis langsung ke perangkat blok.
Setelah mempertimbangkan semua pro dan kontra, saya memutuskan untuk menyetujuinya istirahat Ρ server istirahat sebagai solusi pencadangan yang paling nyaman dan menjanjikan.
Dalam screencast ini Anda dapat melihat bagaimana saluran 10 gigabit digunakan sepenuhnya selama beberapa operasi pencadangan yang berjalan secara bersamaan. Perlu dicatat bahwa daur ulang disk tidak melebihi 30%.
Saya sangat senang dengan solusi yang saya terima!
Sumber: www.habr.com