Salam, mən bu yaxınlarda maraqlı bir problemlə qarşılaşdım: çoxlu sayda blok cihazlarının ehtiyat nüsxəsini çıxarmaq üçün yaddaşın qurulması.
Hər həftə buludumuzdakı bütün virtual maşınların ehtiyat nüsxəsini çıxarırıq, buna görə də minlərlə ehtiyat nüsxəsini saxlamağı və bunu mümkün qədər tez və səmərəli şəkildə etməyi bacarmalıyıq.
Təəssüf ki, standart konfiqurasiyalar RAID5, RAID6 bu halda, biz bunu etməyə icazə verməyəcəyik, çünki bizim kimi böyük disklərdə bərpa prosesi ağrılı şəkildə uzun olacaq və çox güman ki, heç vaxt bitməyəcək.
Hansı alternativlərin olduğuna baxaq:
— RAID5, RAID6 ilə oxşar, lakin konfiqurasiya edilə bilən paritet səviyyəsi ilə. Bu zaman rezervasiya blok-blok yox, hər bir obyekt üçün ayrıca həyata keçirilir. Kodlaşdırmanı silməyə cəhd etməyin ən asan yolu genişləndirməkdir .
hazırda yayımlanmamış ZFS xüsusiyyətidir. RAIDZ-dən fərqli olaraq, DRAID paylanmış paritet blokuna malikdir və bərpa zamanı massivin bütün disklərini bir anda istifadə edir ki, bu da onu disk nasazlıqlarına daha yaxşı dözmək və uğursuzluqdan sonra daha tez bərpa etmək imkanı verir.
Server mövcuddur Fujitsu Primergy RX300 S7 prosessorla Intel Xeon CPU E5-2650L 0 @ 1.80GHz, doqquz RAM çubuq Samsung DDR3-1333 8Gb PC3L-10600R ECC Qeydiyyatlı (M393B1K70DH0-YH9), disk rəfi Supermicro SuperChasssis 847E26-RJBOD1, vasitəsilə bağlanır İkili LSI SAS2X36 Genişləndirici və 45 disk Seagage ST6000NM0115-1YZ110 haqqında 6TB hər kəs.
Bir şeyə qərar verməzdən əvvəl hər şeyi düzgün sınaqdan keçirməliyik.
Bunun üçün müxtəlif konfiqurasiyalar hazırladım və sınaqdan keçirdim. Bunun üçün mən S3 backend kimi çıxış edən və müxtəlif sayda hədəflərlə müxtəlif rejimlərdə işə salan miniodan istifadə etdim.
Əsasən, minio qutu eyni sayda disk və disklərin pariteti ilə silmə kodlaşdırmasına qarşı proqram basqında sınaqdan keçirilmişdir və bunlar: RAID6, RAIDZ2 və DRAID2.
İstinad üçün: minionu yalnız bir hədəflə işə saldığınız zaman minio S3 şlüz rejimində işləyir və yerli fayl sisteminizi S3 yaddaşı şəklində çatdırır. Bir neçə hədəfi göstərərək minio-nu işə salsanız, Silinmə Kodlaşdırma rejimi avtomatik olaraq işə düşəcək, bu da xətaya dözümlülük təmin etməklə, məlumatları hədəfləriniz arasında yayacaq.
Varsayılan olaraq, minio hədəfləri qrup başına 16 paritet olmaqla 2 diskdən ibarət qruplara bölür. Bunlar. Məlumatları itirmədən iki disk eyni anda sıradan çıxa bilər.
Performansı yoxlamaq üçün hər biri 16TB olan 6 diskdən istifadə etdim və onların üzərinə 1MB ölçülü kiçik obyektlər yazdım, bu, gələcək yükümüzü ən dəqiq şəkildə təsvir etdi, çünki bütün müasir ehtiyat alətləri məlumatları bir neçə meqabaytlıq bloklara bölür və bu şəkildə yazır.
Testi aparmaq üçün biz uzaq serverdə işə salınan və yüzlərlə ipdə on minlərlə belə obyekti minio-ya göndərən s3bench yardım proqramından istifadə etdik. Bundan sonra mən də eyni şəkildə onları geri tələb etməyə çalışdım.
Benchmark nəticələri aşağıdakı cədvəldə göstərilir:
Gördüyümüz kimi, minio öz silmə kodlaşdırma rejimində eyni konfiqurasiyada RAID6, RAIDZ2 və DRAID2 proqram təminatı üzərində işləyən minio ilə müqayisədə yazmaqda əhəmiyyətli dərəcədə pis işləyir.
Məni ayrı ext4 və XFS-də minionu sınayın. Təəccüblüdür ki, mənim iş yüküm üçün XFS ext4-dən xeyli yavaş oldu.
Testlərin ilk partiyasında Mdadm ZFS-dən üstünlüyünü göstərdi, lakin sonra aşağıdakı seçimləri təyin etməklə ZFS performansını yaxşılaşdıra bilərsiniz:
xattr=sa atime=off recordsize=1Mvə bundan sonra ZFS ilə testlər daha yaxşı oldu.
Siz həmçinin qeyd edə bilərsiniz ki, DRAID RAIDZ-dən çox performans artımı təmin etmir, lakin nəzəri cəhətdən daha təhlükəsiz olmalıdır.
Son iki testdə mən də metadata (xüsusi) və ZIL (log) SSD-dən güzgüyə köçürməyə çalışdım. Lakin metadataların silinməsi qeyd sürətində çox qazanc vermədi və ZIL-i çıxararkən mənim 100% istifadə ilə tavana vurun, buna görə də bu testi uğursuz hesab edirəm. İstisna etmirəm ki, daha sürətli SSD disklərim olsaydı, bəlkə bu, nəticələrimi xeyli yaxşılaşdıra bilərdi, amma təəssüf ki, məndə yox idi.
Sonda mən DRAID-dən istifadə etmək qərarına gəldim və beta statusuna baxmayaraq, bu, bizim vəziyyətimizdə ən sürətli və ən səmərəli saxlama həllidir.
Mən üç qrup və iki paylanmış ehtiyat hissələri olan konfiqurasiyada sadə DRAID2 yaratdım:
# 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 errorsYaxşı, yaddaşı sıraladıq, indi nə yedəkləyəcəyimiz barədə danışaq. Burada dərhal cəhd edə bildiyim üç həll yolu haqqında danışmaq istərdim və bunlar:
- çəngəl , blok cihaz ehtiyat nüsxəsi üçün xüsusi həll, Ceph ilə sıx inteqrasiyaya malikdir. Ani görüntülər arasında fərqlər götürə və onlardan artan ehtiyat nüsxəsini yarada bilər. Həm yerli, həm də S3 daxil olmaqla çoxlu sayda saxlama arxa ucunu dəstəkləyir. Təkrarlanan hash cədvəlini saxlamaq üçün ayrıca verilənlər bazası tələb olunur. Minuslardan: python ilə yazılmışdır, bir az cavabsız bir cli var.
- çəngəl , çoxdan tanınan və sübut edilmiş ehtiyat aləti məlumatların ehtiyat nüsxəsini çıxara və yaxşıca təkmilləşdirə bilər. Həm yerli, həm də scp vasitəsilə uzaq serverə ehtiyat nüsxələrini saxlaya bilir. Bayraqla işə salındıqda cihazları bloklaya bilər --special, mənfi cəhətlərdən biri: ehtiyat nüsxə yaratarkən, depo tamamilə bloklanır, buna görə də hər bir virtual maşın üçün ayrıca bir depo yaratmaq tövsiyə olunur, prinsipcə bu problem deyil, xoşbəxtlikdən onlar çox asanlıqla yaradılır.
aktiv şəkildə inkişaf edən layihədir, go rejimində yazılmışdır, kifayət qədər sürətlidir və yerli yaddaş, scp, S3 və sair daxil olmaqla çoxlu sayda saxlama arxa ucunu dəstəkləyir. Ayrı-ayrılıqda qeyd etmək istərdim ki, xüsusi yaradılmışdır uzaqdan istifadə üçün yaddaşı tez ixrac etməyə imkan verən restic üçün. Yuxarıda göstərilənlərin hamısından ən çox xoşuma gəldi. stdin-dən ehtiyat nüsxə çıxara bilər. Onun demək olar ki, nəzərəçarpacaq çatışmazlıqları yoxdur, lakin bir neçə xüsusiyyət var:
-
Birincisi, mən onu bütün virtual maşınlar üçün (Benji kimi) ümumi depo rejimində istifadə etməyə çalışdım və hətta kifayət qədər yaxşı işlədi, lakin bərpa əməliyyatları çox uzun çəkdi, çünki... Hər dəfə bərpa etməzdən əvvəl restic bütün ehtiyat nüsxələrinin metadatasını oxumağa çalışır. Bu problem, borgda olduğu kimi, hər bir virtual maşın üçün ayrıca repozitoriya yaratmaqla asanlıqla həll edildi. Bu yanaşma ehtiyat nüsxələri idarə etmək üçün də çox təsirli olduğunu sübut etdi. Ayrı-ayrı depolar məlumatlara daxil olmaq üçün ayrıca parola malik ola bilər və qlobal repo-nun hər hansı bir şəkildə poza biləcəyindən qorxmaq lazım deyil. Borg ehtiyat nüsxəsində olduğu kimi asanlıqla yeni depolar yarada bilərsiniz.
Hər halda, təkmilləşdirmə yalnız ehtiyat nüsxəsinin əvvəlki versiyasına nisbətən həyata keçirilir, əvvəlki ehtiyat nüsxə müəyyən edilmiş ehtiyat nüsxəsinin yolu ilə müəyyən edilir, buna görə də stdin-dən ümumi depoya müxtəlif obyektlərin ehtiyat nüsxəsini çıxarırsınızsa, onu göstərməyi unutmayın; seçim
--stdin-filename, və ya hər dəfə seçimi açıq şəkildə göstərin--parent.
-
İkincisi, stdout-un bərpası paralel xarakterinə görə fayl sisteminin bərpasından daha uzun çəkir. Gələcəkdə blok qurğular üçün ehtiyat nüsxələri üçün daha yaxın dəstək əlavə etməyi planlaşdırırıq.
-
Üçüncüsü, hazırda istifadə etmək tövsiyə olunur , çünki versiya 0.9.6 böyük faylların uzun bərpası ilə bir səhv var.
Ehtiyat nüsxənin effektivliyini və ehtiyat nüsxədən yazma/bərpa sürətini yoxlamaq üçün ayrıca bir repozitoriya yaratdım və virtual maşının kiçik bir görüntüsünü (21 GB) yedəkləməyə çalışdım. Təkrarlanan məlumatların nə qədər sürətli/yavaş kopyalandığını yoxlamaq üçün sadalanan həllərin hər birindən istifadə edərək, orijinalı dəyişdirmədən iki ehtiyat nüsxəsi həyata keçirildi.
Gördüyümüz kimi, Borg Backup ən yaxşı ilkin ehtiyat səmərəlilik nisbətinə malikdir, lakin həm yazma, həm də bərpa sürəti baxımından aşağıdır.
Restic-in Benji Backup-dan daha sürətli olduğu ortaya çıxdı, lakin stdout-a bərpa etmək daha uzun çəkir və təəssüf ki, blok cihazına birbaşa necə yazacağını hələ bilmir.
Bütün müsbət və mənfi cəhətləri ölçdükdən sonra qərara gəldim istirahət с istirahət serveri ən rahat və perspektivli ehtiyat həlli kimi.
Bu ekran görüntüsündə siz eyni vaxtda işləyən bir neçə ehtiyat əməliyyatı zamanı 10 giqabitlik kanalın necə tamamilə istifadə edildiyini görə bilərsiniz. Qeyd etmək lazımdır ki, disklərin təkrar emalı 30% -dən yuxarı qalxmır.
Aldığım həlldən çox məmnun oldum!
Mənbə: www.habr.com
