Bu not, ehtiyat nüsxə haqqında dövrü tamamlayır. Bu yazıda, ehtiyat nüsxə üçün rahat olan xüsusi serverin (və ya VPS) məntiqi təşkilatından danışılacaq və qəza hallarında serverin ehtiyat nüsxədən sürətli bərpa variantı təklif ediləcək.
Məlumatlar
Xüsusi serverlər adətən, birinci səviyyə RAID arrayını (kopyalanma) təşkil etmək üçün minimum iki sərt diskə malikdir. Bu, bir disk sıradan çıxdıqda serverin fəaliyyətini davam etdirmək üçün lazımdır. Əgər bu adi bir xüsusi serverdirsə, ayrı bir hardware RAID kontrolleri ola bilər, SSD-də aktiv ön yaddaş texnologiyası ilə, beləliklə adi sərt disklərə əlavə olaraq bir və ya daha çox SSD qoşula bilər. Bəzi hallarda, yalnız SATADOM (kiçik disklər, konstruktiv olaraq — SATA portuna qoşulan flash sürücü) olan xüsusi serverlər təklif olunur, yaxud xüsusi daxili portda qoşulan adi bir kiçik (8-16 Gb) flash sürücü, məlumatlar isə ayrılmış saxlama şəbəkəsi (Ethernet 10G, FC və s.) ilə qoşulmuş SÇD-dən alınacaq. Bəzi xüsusi serverlər, birbaşa SÇD-dən yüklənir. Belə variantları nəzərdən keçirmək istəmirəm, çünki bu hallarda serverin ehtiyat nüsxəsi tapşırığı, adətən SÇD-ni idarə edən mütəxəssisə keçir, orada müxtəlif brend texnologiyaları ilə vəziyyət görüntülərinin yaradılması, daxili deduplication və digər administratorun rahatlıqları var ki, bunlar da bu dövrün əvvəlki hissələrində müzakirə edilmişdir. Xüsusi serverin disk arrayının həcmi qoşulmuş disk sayına və həcminə görə bir neçə on terabayta çata bilər. VPS halında isə həcmlər daha modestdir: adətən 100 Gb-dan çox olmur (amma daha da çox ola bilər), və belə VPS-lərin tarifləri bu eyni providerin ən ucuz xüsusi serverlərindən daha baha ola bilər. VPS-də adətən bir disk olur, çünki altında SÇD (və ya nəsə hiper konvergent) olacaqdır. Bəzən VPS-də fərqli məqsədlər üçün fərqli xüsusiyyətlərə malik bir neçə disk olur:
- kiçik sistem disk — əməliyyat sisteminin quraşdırılması üçün;
- böyük disk — istifadəçi məlumatlarının saxlanması.
Sistem yeniləndikdə idarəetmə paneli ilə istifadəçi məlumatlarının olduğu disk silinmir, ancaq sistem diski tamamilə yenidən yazılır. Həmçinin, VPS ilə bağlı olaraq, provayder VPS (ya da diskin) vəziyyətini çəkən bir düyməni təklif edə bilər, lakin öz əməliyyat sisteminizi quraşdırdığınızda və ya VPS daxilində lazımi xidməti aktivləşdirməyi unutduğunuzda, məlumatların bir hissəsi hələ də itirilə bilər. Bu düyməni əlavə olaraq, çox vaxt məhdud olan məlumat saxlama xidməti təklif olunur. Adətən bu, FTP və ya SFTP protokolu ilə giriş imkanı olan bir hesabdır, bəzən SSH ilə birlikdə, kəsilmiş shell (məsələn, rbash) ilə, ya da authorized_keys (ForcedCommand vasitəsilə) ilə əmr icrası məhdudiyyəti ilə verilir.
Təchiz olunmuş server iki 1 Gbit/s sürətində şəbəkəyə qoşulub, bəzən bu, 10 Gbit/s sürətində olan kartlar da ola bilər. VPS-lərdə şəbəkə interfeysi əsasən bir dənədir. Ən çox data mərkəzləri data mərkəzi daxilində şəbəkə sürətini məhdudlaşdırmır, lakin internetə giriş sürətini məhdudlaşdırır.
Belə təchiz olunmuş serverin və ya VPS-in tipik yükü veb server, verilənlər bazası, tətbiq serveridir. Bəzi hallarda, veb server və ya verilənlər bazası üçün müxtəlif əlavə köməkçi xidmətlər quraşdırıla bilər: axtarış mühərriki, poçt sistemi və s.
Ehtiyat nüsxələrinin saxlanması üçün xüsusi hazırlanmış server istifadə olunur, bununla bağlı daha ətraflı məlumat veriləcək.
Disk sisteminin məntiqi təşkili
Əgər RAID nəzarətçisi varsa, ya da bu bir disklə VPSdirsə və disk alt sisteminin işləməsi ilə bağlı xüsusi tələblər yoxdursa (məsələn, verilənlər bazası üçün ayrı, sürətli disk) – bütün boş sahə belə bölünür: bir bölmə yaradılır, onun üstündə LVM həcmi qruplaşdırılır, burada bir neçə həcmlər yaradılır: 2 kiçik, eyni ölçüdə, kök fayl sistemi kimi istifadə olunur (yeniləmələr zamanı sürətli geri dönmə imkanı üçün sırayla dəyişdirilir, bu fikri Calculate Linux distrosundan götürülüb), bir daha isə dəyişdirmə bölməsi üçün, qalan boş sahə isə tam konteynerlər, virtual maşınlar üçün disk, /home-da (hər hesab üçün öz fayl sistemi) fayl sistemləri, tətbiq konteynerləri üçün fayl sistemləri kimi istifadə olunan kiçik həcmlərə bölünür.
Vacib qeyd: həcmlər tam müstəqil olmalıdır, yəni bir-birinə və ya kök fayl sisteminə asılı olmamalıdır. Virtual maşınlar və ya konteynerlər üçün bu, avtomatik olaraq yerinə yetirilir. Əgər tətbiq konteynerləri və ya ev kataloqları varsa — veb serverin konfiqurasiya fayllarını və digər xidmətləri bir-birindən ayırmaq barədə düşünmək lazımdır ki, həcmlər arasında asılılıqları minimuma endirək. Məsələn, hər veb sayt öz istifadəçisindən işləyir, saytın konfiqurasiya faylları istifadəçinin ev kataloqunda yerləşir, veb serverin konfiqurasiya fayllarında saytların konfiqurasiya faylları /etc/nginx/conf.d/ yolu ilə deyil, məsələn, /home/ yolu ilə daxil edilir..conf, amma, məsələn, /home//configs/nginx/*.conf
Bir neçə disk varsa — proqramlı RAID massivi yaratmaq mümkündür (əgər ehtiyac və imkan varsa, onun SSD-də ön yaddaşını tənzimləmək olar), onun üstündə isə yuxarıda təqdim olunan qaydalara uyğun LVM mənzərəsini qurmaq olar. Bu halda ZFS və ya BtrFS istifadə etmək də mümkündür, amma burada bir neçə dəfə düşünmək lazımdır: bunlar resurslara daha ciddi yanaşma tələb edir, həm də ZFS Linux nüvəsi ilə birlikdə gəlmir.
İstifadə olunan sxemədən asılı olmayaraq, həmişə disk üzərində dəyişikliklərin yazma sürətini əvvəlcədən qiymətləndirmək və sonra şəkil yedəkləri yaratmaq üçün ayrılmış boş yerin ölçüsünü hesablamaq lazımdır. Məsələn, əgər serverimiz məlumatları saniyədə 10 megabayt sürəti ilə yazacaqsa və bütün məlumatlar üçün massiv 10 terabaytdırsa — sinxronizasiya vaxtı bir günə (22 saat — belə bir həcmi 1gbit/s şəbəkədən ötürmək 22 saat çəkəcək) çata bilər — təxminən 800 gigabayt ayrılmalıdır. Həqiqətəndə rəqəm daha az olacaq, onu rahatlıqla lojiq həcmlərin sayına bölə bilərsiniz.
Ehtiyat nüsxə saxlamaq üçün server qurğusu
Ehtiyat nüsxə saxlamaq üçün serverin əsas fərqi — böyük, ucuz və nisbətən yavaş disklərdir. Müasir HDD-lər artıq bir diskdə 10TB sərhədini keçdiyindən — mütləq təsdiq edilən fayl sistemləri və ya RAID ilə istifadə olunmalıdır, çünki massiv qurarkən və ya fayl sistemini bərpa edərkən (bir neçə gün ərzində!) ikinci disk artan yük səbəbindən sıradan çıxa bilər. 1TB tutumlu diskdə bu o qədər də hiss olunmurdu. İzah etməyi asanlaşdırmaq üçün disklərin ölçülərini iki eyni ölçüdə hissəyə bölünməsi (yenə də məsələn, LVM vasitəsilə) nəzərdə tutulur:
- serverlərdə istifadə edilən həcmlər, istifadəçi məlumatlarını saxlamaq üçün (bura yoxlama məqsədilə ən son yaradılmış ehtiyat nüsxəsi qurulacaq);
- həcmlər, BorgBackup-an ötürüləcək məlumatların ehtiyat nüsxələri olaraq istifadə edilir.
İşleyiş prensibi, her bir sunucu için ayrı hacimler oluşturulmasıdır, bunlar BorgBackup depolarıdır ve bu depolara aktif sunuculardan veri gidecektir. Depolar yalnızca ekleme modunda çalıştığı için veri silinmesi mümkün değildir; ayrıca deduplikasyon ve depoların eski yedeklerden düzenli olarak temizlenmesi sayesinde (yıllık kopyalar, son bir yıl için aylık kopyalar, son bir ay için haftalık kopyalar, son bir hafta için günlük kopyalar, gerekirse son gün için saatlik kopyalar: toplamda 24 + 7 + 4 + 12 + yıllık — her bir sunucu için yaklaşık 50 kopya) sağlanır.
BorgBackup depolarında yalnızca ekleme modunu etkinleştirmez, bunun yerine .ssh/authorized_keys içinde yaklaşık şu şekilde bir ForcedCommand kullanılır:
from="sunucu adresi",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/sunucu_adı/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......Belirtilen yolda, işlemci parametreleriyle birlikte ikili dosyayı çalıştırmanın yanı sıra, veri alımı tamamlandıktan sonra yedek geri yükleme sürecini de başlatan bir sarmalayıcı betik bulunur. Bu sarmalayıcı betik, ilgili depo ile birlikte bir işaret dosyası oluşturur. Veri yükleme sürecinin tamamlanmasının ardından, yapılan son yedek otomatik olarak ilgili mantıksal hacme geri yüklenir.
Bu yapı, zaman zaman gereksiz yedekleri temizlemeye olanak tanır ve aktif sunucuların yedekleme sunucusunda herhangi bir şeyi silmelerine engel olur.
Yedekleme süreci
Yedeklemenin başlatıcısı, kendisi olan özel sunucu veya VPS'tir; bu tür bir yapı, bu sunucu tarafından yedekleme süreci üzerinde daha fazla kontrol sağlar. İlk olarak, aktif kök dosya sisteminin durumu bir anlık görüntü (snapshot) alınarak yedekleme sunucusuna BorgBackup ile yüklenir. Veri alımı tamamlandıktan sonra anlık görüntü çıkarılır ve silinir.
Her bir web sitesi için küçük bir veritabanı (1 GB'a kadar) olması durumunda, veritabanının bir yedeği alınır ve bu yedek ilgili mantıksal hacme, diğer verilere erişiminin web sunucusu üzerinden mümkün olamayacak şekilde saklanır. Ancak veritabanları büyükse, verileri 'çok sıcak' bir şekilde almanın yöntemlerinin ayarlanması gerekir; örneğin, MySQL için xtrabackup kullanmak veya PostgreSQL’de archive_command ile WAL'ı çalıştırmak gibi. Bu durumda veritabanı, web siteleri verilerinden ayrı olarak geri yüklenir.
Əgər konteynerlər və ya virtual maşınlar istifadə olunursa, qemu-guest-agent, CRIU və ya digər lazımi texnologiyalar konfiqurasiya edilməlidir. Digər hallarda əlavə konfiqurasiyalara çox vaxt ehtiyac olmur — sadəcə, kök fayl sisteminin vəziyyət şəkli ilə eynilə işlənəcək loqikal həcmlərin şəkillərini yaradın. Məlumatlar alındıqdan sonra şəkillər silinir.
Daha sonra iş, ehtiyat nüsxələrinin saxlandığı serverdə davam edir:
- hər bir repositoriyada son yaradılmış ehtiyat nüsxəsi yoxlanılır,
- məlumatların alınması prosesinin başa çatdığını göstərən qeyd faylının mövcudluğu yoxlanılır,
- müvafiq lokal həcmlə məlumatların bərpa edilməsi həyata keçirilir,
- qeyd faylı silinir
Serverin işlək vəziyyətinin bərpası prosesi
Əgər əsas server sıradan çıxırsa, onu müəyyən bir standart imic ilə yüklənən analoji ayrılmış server işə düşür. Yükləmə ehtimal ki, şəbəkə vasitəsilə həyata keçiriləcək, lakin serveri konfiqurasiya edən Mərkəzi Ofis əməkdaşları bu standart imici dərhal disklərdən birinə köçürə bilər. Yükləmə yaddaşa baş verir, bundan sonra bərpa prosesi başlayır:
- ölmüş serverin kök fayl sistemini əhatə edən blok cihazına iscsinbd və ya digər bənzər loqikal həcm protokolu vasitəsilə qoşulma üçün sorğu göndərilir; kök fayl sistemi kiçik olmalıdır — bu mərhələ bir neçə dəqiqə ərzində tamamlanmalıdır. Yükləyici də bərpa olunur;
- lokal loqikal həcmlərin strukturu bərpa edilir, ehtiyat nüsxə serverindən loqikal həcmlər dm_clone nüvəsi modulu vasitəsilə qoşulur: məlumatların bərpası başlayır və dəyişikliklər dərhal lokal disklərə yazılır.
- bütün mövcud fiziki disklərlə konteyner işə salınır — serverin işlək vəziyyəti tamamilə bərpa olunur, lakin azalmış məhsuldarlıqla;
- məlumatların sinxronizasiyası başa çatdıqdan sonra, ehtiyat nüsxə serverindən loqikal həcmlər ayrılır, konteyner bağlanır, server yenidən başlatılır;
Yenidən başlandıqdan sonra server, ehtiyat nüsxənin yaradıldığı ankı bütün məlumatları və eyni zamanda bərpa prosesi zamanı həyata keçirilən bütün dəyişiklikləri ehtiva edəcək.
Digər məqalələr
Ehtiyat nüsxə, hissə 7: Nəticələr
Təklif olunan variantı şərhlərdə müzakirə etməyə dəvət edirəm, diqqətiniz üçün təşəkkür edirəm!
Mənbə: habr.com
