Helo, baru-baru ini saya menemui masalah menarik: menyediakan storan untuk menyandarkan sejumlah besar peranti blok.
Setiap minggu kami membuat sandaran semua mesin maya dalam awan kami, jadi kami perlu dapat mengekalkan beribu-ribu sandaran dan melakukannya secepat dan seefisien mungkin.
Malangnya, konfigurasi standard RAID5, RAID6 dalam kes ini, kami tidak akan dibenarkan berbuat demikian, kerana proses pemulihan pada cakera besar seperti kami akan memakan masa yang lama dan kemungkinan besar tidak akan berakhir.
Mari lihat apakah alternatif yang ada:
β Sama seperti RAID5, RAID6, tetapi dengan tahap pariti boleh dikonfigurasikan. Dalam kes ini, tempahan dilakukan bukan blok demi blok, tetapi untuk setiap objek secara berasingan. Cara paling mudah untuk mencuba pengekodan pemadaman ialah mengembangkan .
ialah ciri ZFS yang belum dikeluarkan pada masa ini. Tidak seperti RAIDZ, DRAID mempunyai blok pariti teragih dan, semasa pemulihan, menggunakan semua cakera tatasusunan sekaligus, yang menjadikannya lebih mampu untuk bertahan daripada kegagalan cakera dan pulih lebih cepat selepas kegagalan.
Pelayan tersedia Fujitsu Primergy RX300 S7 dengan pemproses Intel Xeon CPU E5-2650L 0 @ 1.80GHz, sembilan batang RAM Samsung DDR3-1333 8Gb PC3L-10600R ECC Berdaftar (M393B1K70DH0-YH9), rak cakera Supermicro SuperChassis 847E26-RJBOD1, disambungkan melalui Pengembang Dwi LSI SAS2X36 dan 45 cakera Seagage ST6000NM0115-1YZ110 pada 6TB semua orang.
Sebelum kita memutuskan apa-apa, kita perlu menguji semuanya dengan betul.
Untuk melakukan ini, saya menyediakan dan menguji pelbagai konfigurasi. Untuk melakukan ini, saya menggunakan minio, yang bertindak sebagai bahagian belakang S3 dan melancarkannya dalam mod yang berbeza dengan bilangan sasaran yang berbeza.
Pada asasnya, kes minio telah diuji dalam memadamkan pengekodan vs serbuan perisian dengan bilangan cakera dan pariti cakera yang sama, dan ini ialah: RAID6, RAIDZ2 dan DRAID2.
Untuk rujukan: apabila anda melancarkan minio dengan hanya satu sasaran, minio berfungsi dalam mod get laluan S3, menyampaikan sistem fail tempatan anda dalam bentuk storan S3. Jika anda melancarkan minio yang menyatakan beberapa sasaran, mod Pemadaman Pengekodan akan dihidupkan secara automatik, yang akan menyebarkan data antara sasaran anda sambil memberikan toleransi kesalahan.
Secara lalai, minio membahagikan sasaran kepada kumpulan 16 cakera, dengan 2 pariti setiap kumpulan. Itu. Dua cakera boleh gagal pada masa yang sama tanpa kehilangan data.
Untuk menguji prestasi, saya menggunakan 16 cakera bersaiz 6TB setiap satu dan menulis objek kecil bersaiz 1MB padanya, ini paling tepat menggambarkan beban masa depan kami, kerana semua alat sandaran moden membahagikan data kepada blok beberapa megabait dan menulisnya dengan cara ini.
Untuk menjalankan penanda aras, kami menggunakan utiliti s3bench, dilancarkan pada pelayan jauh dan menghantar berpuluh-puluh ribu objek sedemikian ke minio dalam ratusan utas. Selepas itu saya cuba meminta mereka kembali dengan cara yang sama.
Keputusan penanda aras ditunjukkan dalam jadual berikut:
Seperti yang dapat kita lihat, minio dalam mod pengekodan pemadamannya sendiri menunjukkan prestasi yang lebih teruk dalam penulisan berbanding minio yang dijalankan di atas perisian RAID6, RAIDZ2 dan DRAID2 dalam konfigurasi yang sama.
Secara berasingan saya uji minio pada ext4 vs XFS. Yang menghairankan, untuk jenis beban kerja saya, XFS ternyata lebih perlahan daripada ext4.
Dalam kumpulan pertama ujian, Mdadm menunjukkan keunggulan berbanding ZFS, tetapi kemudiannya bahawa anda boleh meningkatkan prestasi ZFS dengan menetapkan pilihan berikut:
xattr=sa atime=off recordsize=1Mdan selepas itu ujian dengan ZFS menjadi lebih baik.
Anda juga boleh ambil perhatian bahawa DRAID tidak memberikan banyak keuntungan prestasi berbanding RAIDZ, tetapi secara teori ia sepatutnya lebih selamat.
Dalam dua ujian terakhir, saya juga cuba memindahkan metadata (khas) dan ZIL (log) ke cermin dari SSD. Tetapi mengalih keluar metadata tidak memberikan banyak keuntungan dalam kelajuan rakaman, dan apabila mengeluarkan ZIL, my memukul siling dengan penggunaan 100%, jadi saya menganggap ujian ini gagal. Saya tidak mengecualikan bahawa jika saya mempunyai pemacu SSD yang lebih pantas, maka mungkin ini dapat meningkatkan hasil saya dengan ketara, tetapi, malangnya, saya tidak memilikinya.
Pada akhirnya, saya memutuskan untuk menggunakan DRAID dan walaupun status betanya, ia adalah penyelesaian storan yang paling pantas dan paling cekap dalam kes kami.
Saya mencipta DRAID2 mudah dalam konfigurasi dengan tiga kumpulan dan dua alat ganti yang diedarkan:
# 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 errorsOkey, kami telah menyelesaikan storan, sekarang mari kita bincangkan tentang perkara yang akan kami sandarkan. Di sini saya ingin segera bercakap tentang tiga penyelesaian yang saya berjaya cuba, dan ini adalah:
- garpu , penyelesaian khusus untuk sandaran peranti blok, mempunyai integrasi yang ketat dengan Ceph. Boleh mengambil perbezaan antara syot kilat dan membentuk sandaran tambahan daripadanya. Menyokong sejumlah besar bahagian belakang storan, termasuk tempatan dan S3. Memerlukan pangkalan data yang berasingan untuk menyimpan jadual cincang deduplikasi. Kelemahan: ditulis dalam python, mempunyai cli yang sedikit tidak responsif.
- garpu , alat sandaran yang telah lama diketahui dan terbukti, boleh membuat sandaran data dan menyahduplikasinya dengan baik. Mampu menyimpan sandaran secara tempatan dan ke pelayan jauh melalui scp. Boleh membuat sandaran menyekat peranti jika dilancarkan dengan bendera --special, salah satu kelemahan: apabila membuat sandaran, repositori disekat sepenuhnya, jadi disyorkan untuk membuat repositori berasingan untuk setiap mesin maya, pada dasarnya ini tidak menjadi masalah, mujurlah ia dibuat dengan sangat mudah.
ialah projek yang sedang dibangunkan secara aktif, ditulis dalam go, agak pantas dan menyokong sejumlah besar bahagian belakang storan, termasuk storan tempatan, scp, S3 dan banyak lagi. Secara berasingan, saya ingin ambil perhatian bahawa terdapat yang dicipta khas untuk restic, yang membolehkan anda mengeksport storan dengan cepat untuk digunakan dari jauh. Daripada semua di atas, saya paling suka. Boleh backup dari stdin. Ia hampir tidak mempunyai kelemahan yang ketara, tetapi terdapat beberapa ciri:
-
Pertama, saya cuba menggunakannya dalam mod repositori umum untuk semua mesin maya (seperti Benji) dan ia juga berfungsi dengan baik, tetapi operasi pemulihan mengambil masa yang sangat lama, kerana... Setiap kali sebelum memulihkan, restic cuba membaca metadata semua sandaran. Masalah ini mudah diselesaikan, seperti borg, dengan mencipta repositori berasingan untuk setiap mesin maya. Pendekatan ini telah terbukti sangat berkesan untuk menguruskan sandaran juga. Repositori yang berasingan boleh mempunyai kata laluan yang berasingan untuk mengakses data, dan kami juga tidak perlu takut bahawa repo global mungkin rosak. Anda boleh menghasilkan repositori baharu semudah dalam sandaran borg.
Walau apa pun, penyahduplikasian dilakukan hanya relatif kepada versi sandaran sebelumnya; sandaran sebelumnya ditentukan oleh laluan untuk sandaran yang ditentukan, jadi jika anda menyandarkan objek berbeza dari stdin ke repositori biasa, jangan lupa untuk menentukan pilihan
--stdin-filename, atau nyatakan pilihan secara eksplisit setiap kali--parent.
-
Kedua, pemulihan kepada stdout mengambil masa lebih lama daripada pemulihan kepada sistem fail kerana sifatnya yang selari. Pada masa hadapan, kami merancang untuk menambah sokongan yang lebih rapat untuk sandaran untuk peranti blok.
-
Ketiga, pada masa ini disyorkan untuk digunakan , kerana versi 0.9.6 mempunyai pepijat dengan pemulihan fail besar yang lama.
Untuk menguji keberkesanan sandaran dan kelajuan menulis / memulihkan daripada sandaran, saya mencipta repositori berasingan dan cuba membuat sandaran imej kecil mesin maya (21 GB). Dua sandaran dilakukan tanpa menukar asal, menggunakan setiap penyelesaian yang disenaraikan untuk menyemak seberapa cepat/lambat data yang dinyahduplikasi disalin.
Seperti yang kita dapat lihat, Borg Backup mempunyai nisbah kecekapan sandaran awal yang terbaik, tetapi lebih rendah dari segi kelajuan menulis dan memulihkan.
Restic ternyata lebih pantas daripada Benji Backup, tetapi ia mengambil masa yang lebih lama untuk memulihkan ke stdout, dan, malangnya, ia belum tahu cara menulis terus ke peranti blok.
Selepas menimbang semua kebaikan dan keburukan, saya memutuskan untuk menyelesaikannya berehat Ρ pelayan rehat sebagai penyelesaian sandaran yang paling mudah dan menjanjikan.
Dalam siaran skrin ini anda boleh melihat bagaimana saluran 10-gigabit digunakan sepenuhnya semasa beberapa operasi sandaran berjalan serentak. Perlu diingat bahawa kitar semula cakera tidak meningkat melebihi 30%.
Saya lebih gembira dengan penyelesaian yang saya terima!
Sumber: www.habr.com