Bu qeyd ehtiyatla bağlı dövrü tamamlayır. O, ehtiyat nüsxə üçün əlverişli olan xüsusi serverin (və ya VPS) məntiqi təşkilini müzakirə edəcək, həmçinin fəlakət zamanı çox dayanmadan serveri ehtiyat nüsxədən tez bərpa etmək variantını təklif edəcək.
Xam data
Xüsusi bir serverdə çox vaxt birinci səviyyəli RAID massivini (güzgü) təşkil etməyə xidmət edən ən azı iki sabit disk var. Bu, bir disk uğursuz olarsa, serveri işləməyə davam etmək üçün lazımdır. Əgər bu, adi xüsusi serverdirsə, SSD-də aktiv keşləmə texnologiyasına malik ayrıca aparat RAID nəzarətçisi ola bilər ki, adi sabit disklərə əlavə olaraq bir və ya daha çox SSD qoşula bilsin. Bəzən xüsusi serverlər təklif olunur ki, burada yeganə lokal disklər SATADOM (kiçik disklər, struktur olaraq SATA portuna qoşulmuş fləş sürücü) və ya hətta xüsusi daxili porta qoşulmuş adi kiçik (8-16 GB) fləş disk və məlumatlar xüsusi saxlama şəbəkəsi (Ethernet 10G, FC və s.) vasitəsilə qoşulmuş saxlama sistemindən götürülür və birbaşa saxlama sistemindən yüklənən xüsusi serverlər var. Mən bu cür variantları nəzərdən keçirməyəcəyəm, çünki belə hallarda serverin ehtiyat nüsxəsini çıxarmaq vəzifəsi saxlama sisteminə nəzarət edən mütəxəssisə rəvan keçir; adətən anlıq görüntülər yaratmaq üçün müxtəlif mülkiyyət texnologiyaları, quraşdırılmış təkmilləşdirmə və sistem administratorunun digər sevincləri var. , bu seriyanın əvvəlki hissələrində müzakirə edilmişdir. Xüsusi serverin disk massivinin həcmi serverə qoşulmuş disklərin sayı və ölçüsündən asılı olaraq bir neçə onlarla terabata çata bilər. VPS vəziyyətində həcmlər daha təvazökardır: adətən 100 GB-dan çox deyil (lakin daha çox var) və belə VPS üçün tariflər asanlıqla eyni hosterdən ən ucuz ayrılmış serverlərdən daha baha ola bilər. VPS-də çox vaxt bir disk olur, çünki onun altında saxlama sistemi (və ya hiperkonversiya edilmiş bir şey) olacaqdır. Bəzən VPS müxtəlif məqsədlər üçün fərqli xüsusiyyətlərə malik bir neçə diskə malikdir:
- kiçik sistem - əməliyyat sisteminin quraşdırılması üçün;
- böyük - istifadəçi məlumatlarının saxlanması.
İdarəetmə panelindən istifadə edərək sistemi yenidən quraşdırdığınız zaman istifadəçi məlumatları olan diskin üzərinə yazılmır, lakin sistem diski tamamilə doldurulur. Həmçinin, VPS vəziyyətində hoster VPS (və ya disk) vəziyyətinin şəklini çəkən düyməni təklif edə bilər, lakin siz öz əməliyyat sisteminizi quraşdırırsınızsa və ya VPS daxilində istədiyiniz xidməti aktivləşdirməyi unutsanız, bəziləri məlumatların hələ də itirilə bilər. Düyməyə əlavə olaraq, adətən məlumat saxlama xidməti təklif olunur, əksər hallarda çox məhduddur. Tipik olaraq, bu, FTP və ya SFTP vasitəsilə, bəzən SSH ilə birlikdə, soyulmuş qabıqlı (məsələn, rbash) və ya səlahiyyətli_açarlar vasitəsilə (ForcedCommand vasitəsilə) əmrlərin işləməsinə məhdudiyyət olan hesabdır.
Xüsusi server şəbəkəyə 1 Gbit / s sürəti olan iki portla qoşulur, bəzən bunlar 10 Gb / s sürəti olan kartlar ola bilər. VPS ən çox bir şəbəkə interfeysinə malikdir. Çox vaxt məlumat mərkəzləri məlumat mərkəzi daxilində şəbəkə sürətini məhdudlaşdırmır, lakin İnternetə çıxış sürətini məhdudlaşdırır.
Belə bir xüsusi serverin və ya VPS-nin tipik yükü veb server, verilənlər bazası və proqram serveridir. Bəzən veb server və ya verilənlər bazası daxil olmaqla müxtəlif əlavə köməkçi xidmətlər quraşdırıla bilər: axtarış sistemi, poçt sistemi və s.
Xüsusi hazırlanmış server ehtiyat nüsxələrin saxlanması üçün bir yer kimi çıxış edir, bu barədə daha sonra daha ətraflı yazacağıq.
Disk sisteminin məntiqi təşkili
Bir RAID nəzarətçiniz və ya bir diskli VPS varsa və disk alt sisteminin işləməsi üçün xüsusi üstünlüklər yoxdursa (məsələn, verilənlər bazası üçün ayrıca sürətli disk), bütün boş yer aşağıdakı kimi bölünür: bir bölmə yaradılır və onun üstündə LVM həcm qrupu yaradılır, içərisində bir neçə cild yaradılır: kök fayl sistemi kimi istifadə olunan eyni ölçülü 2 kiçik cild (tez geri qaytarma imkanı üçün yeniləmələr zamanı bir-bir dəyişdirilir, ideyası Calculate Linux paylanmasından götürülüb), başqa biri dəyişdirmə bölməsi üçündür, qalan boş yer kiçik həcmlərə bölünür, tam hüquqlu konteynerlər, virtual maşınlar üçün disklər, fayl üçün kök fayl sistemi kimi istifadə olunur. /home-dakı hesablar üçün sistemlər (hər hesabın öz fayl sistemi var), tətbiq konteynerləri üçün fayl sistemləri.
Vacib qeyd: həcmlər tamamilə öz-özünə olmalıdır, yəni. bir-birindən və ya kök fayl sistemindən asılı olmamalıdır. Virtual maşınlar və ya konteynerlər vəziyyətində bu nöqtə avtomatik olaraq müşahidə olunur. Bunlar proqram konteynerləri və ya ev qovluqlarıdırsa, həcmlər arasında asılılıqları mümkün qədər aradan qaldıracaq şəkildə veb serverin və digər xidmətlərin konfiqurasiya fayllarını ayırmaq barədə düşünməlisiniz. Məsələn, hər bir sayt öz istifadəçisindən işləyir, sayt konfiqurasiya faylları istifadəçinin ev kataloqundadır, veb server parametrlərində, sayt konfiqurasiya faylları /etc/nginx/conf.d/ vasitəsilə daxil edilmir..conf və məsələn, /home//configs/nginx/*.conf
Bir neçə disk varsa, RAID proqram massivi yarada bilərsiniz (və ehtiyac və imkan varsa, SSD-də onun keşini konfiqurasiya edə bilərsiniz), bunun üzərinə yuxarıda təklif olunan qaydalara uyğun olaraq LVM qura bilərsiniz. Həm də bu vəziyyətdə ZFS və ya BtrFS-dən istifadə edə bilərsiniz, lakin bu barədə iki dəfə düşünməlisiniz: hər ikisi resurslara daha ciddi yanaşma tələb edir və bundan əlavə, ZFS Linux nüvəsinə daxil edilmir.
İstifadə olunan sxemdən asılı olmayaraq, həmişə disklərə dəyişikliklərin yazılmasının təxmini sürətini əvvəlcədən hesablamağa və sonra anlıq görüntülər yaratmaq üçün ayrılacaq boş yerin miqdarını hesablamağa dəyər. Məsələn, əgər serverimiz məlumatları saniyədə 10 meqabayt sürətlə yazırsa və bütün məlumat massivinin ölçüsü 10 terabaytdırsa - sinxronizasiya müddəti bir günə çata bilər (22 saat - belə bir həcm bu qədər ötürüləcəkdir. şəbəkə üzərində 1 Gbps) - təxminən 800 GB rezerv etməyə dəyər. Əslində, rəqəm daha kiçik olacaq, onu məntiqi həcmlərin sayına təhlükəsiz şəkildə bölmək olar.
Yaddaş server cihazının ehtiyat nüsxəsi
Ehtiyat nüsxələri saxlamaq üçün server arasındakı əsas fərq onun böyük, ucuz və nisbətən yavaş diskləridir. Müasir HDD-lər artıq bir diskdə 10TB zolağı keçdiyi üçün, fayl sistemlərindən və ya yoxlama məbləğləri ilə RAID-dən istifadə etmək lazımdır, çünki massivin yenidən qurulması və ya fayl sisteminin bərpası zamanı (bir neçə gün!) ikinci disk uğursuz ola bilər. artan yükə. 1TB-a qədər tutumlu disklərdə bu o qədər də həssas deyildi. Təsvirin sadəliyi üçün disk sahəsinin təxminən bərabər ölçülü iki hissəyə bölündüyünü güman edirəm (yenidən, məsələn, LVM istifadə edərək):
- istifadəçi məlumatlarını saxlamaq üçün istifadə olunan serverlərə uyğun gələn həcmlər (sonuncu ehtiyat nüsxə yoxlanılmaq üçün onlarda yerləşdiriləcək);
- BorgBackup depoları kimi istifadə olunan həcmlər (yedekləmələr üçün məlumatlar birbaşa buraya gedəcək).
Əməliyyat prinsipi ondan ibarətdir ki, döyüş serverlərindən gələn məlumatların gedəcəyi BorgBackup anbarları üçün hər bir server üçün ayrıca həcmlər yaradılır. Repozitoriyalar yalnız əlavə rejimində işləyir ki, bu da məlumatların qəsdən silinməsi ehtimalını aradan qaldırır və depoların köhnə ehtiyat nüsxələrindən təkrarlanması və vaxtaşırı təmizlənməsi (illik nüsxələr qalır, keçən il üçün hər ay, son bir ay üçün həftəlik, keçən həftə, ola bilsin, xüsusi hallarda - son gün üçün saatlıq: cəmi 24 + 7 + 4 + 12 + illik - hər server üçün təxminən 50 nüsxə).
BorgBackup repozitoriyaları yalnız əlavə rejimini aktivləşdirmir; bunun əvəzinə, .ssh/authorized_keys-də ForcedCommand bu kimi bir şey istifadə olunur:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......Göstərilən yol borg-un üstündə bir sarğı skripti ehtiva edir, bu, parametrlərlə binar sistemi işə salmaqla yanaşı, əlavə olaraq məlumatlar silindikdən sonra ehtiyat nüsxəni bərpa etmək prosesinə başlayır. Bunun üçün sarğı skripti müvafiq deponun yanında etiket faylı yaradır. Son edilən ehtiyat nüsxə məlumatların doldurulması prosesi başa çatdıqdan sonra avtomatik olaraq müvafiq məntiqi həcmə bərpa olunur.
Bu dizayn sizə lazımsız ehtiyat nüsxələrini vaxtaşırı təmizləməyə imkan verir, həmçinin döyüş serverlərinin ehtiyat saxlama serverindəki hər hansı bir şeyi silməsinin qarşısını alır.
Yedəkləmə Prosesi
Yedəkləmənin təşəbbüskarı xüsusi server və ya VPS-in özüdür, çünki bu sxem bu server tərəfindən ehtiyat nüsxə prosesi üzərində daha çox nəzarət imkanı verir. Birincisi, BorgBackup istifadə edərək ehtiyat saxlama serverinə quraşdırılan və yüklənən aktiv kök fayl sisteminin vəziyyətinin bir görüntüsü alınır. Məlumatların tutulması tamamlandıqdan sonra snapshot çıxarılır və silinir.
Kiçik bir verilənlər bazası varsa (hər sayt üçün 1 GB-a qədər), eyni sayt üçün məlumatların qalan hissəsinin yerləşdiyi müvafiq məntiqi həcmdə saxlanılan verilənlər bazası tullantısı hazırlanır, lakin zibil veb server vasitəsilə əldə edilə bilməz. Verilənlər bazaları böyükdürsə, məsələn, MySQL üçün xtrabackup istifadə edərək, “qaynar” məlumatların silinməsini konfiqurasiya etməlisiniz və ya PostgreSQL-də archive_command ilə WAL ilə işləməlisiniz. Bu halda verilənlər bazası sayt məlumatlarından ayrı olaraq bərpa olunacaq.
Konteynerlər və ya virtual maşınlar istifadə olunursa, siz qemu-guest-agent, CRIU və ya digər zəruri texnologiyaları konfiqurasiya etməlisiniz. Digər hallarda, əlavə parametrlər çox vaxt lazım deyil - biz sadəcə məntiqi həcmlərin şəkillərini yaradırıq, daha sonra kök fayl sisteminin vəziyyətinin görüntüsü ilə eyni şəkildə işlənir. Məlumatlar çəkildikdən sonra şəkillər silinir.
Əlavə iş ehtiyat saxlama serverində aparılır:
- hər bir depoda edilən son ehtiyat nüsxəsi yoxlanılır,
- məlumat toplama prosesinin başa çatdığını göstərən işarə faylının olması yoxlanılır,
- məlumat müvafiq yerli həcmə qədər genişləndirilir,
- etiket faylı silinir
Server bərpa prosesi
Əsas server ölürsə, o zaman bəzi standart görüntüdən yüklənən oxşar xüsusi server işə salınır. Çox güman ki, yükləmə şəbəkə üzərindən baş verəcək, lakin serveri quran məlumat mərkəzinin texniki işçisi bu standart şəkli dərhal disklərdən birinə köçürə bilər. Yükləmə RAM-a baş verir, bundan sonra bərpa prosesi başlayır:
- iscsinbd və ya digər oxşar protokol vasitəsilə ölmüş serverin kök fayl sistemini ehtiva edən məntiqi həcmə blok qurğunun əlavə edilməsi üçün sorğu verilir; Kök fayl sistemi kiçik olmalıdır, bu addım bir neçə dəqiqə ərzində tamamlanmalıdır. Yükləyici də bərpa olunur;
- yerli məntiqi həcmlərin strukturu yenidən yaradılır, məntiqi həcmlər dm_clone kernel modulundan istifadə edərək ehtiyat serverdən əlavə olunur: məlumatların bərpası başlayır və dəyişikliklər dərhal yerli disklərə yazılır.
- bütün mövcud fiziki disklərlə konteyner işə salınır - serverin funksionallığı tam bərpa olunur, lakin performansı azalır;
- məlumatların sinxronizasiyası başa çatdıqdan sonra ehtiyat serverdən məntiqi həcmlər ayrılır, konteyner söndürülür və server yenidən işə salınır;
Yenidən başladıqdan sonra server ehtiyat nüsxəsinin yaradılması zamanı orada olan bütün məlumatlara sahib olacaq və bərpa prosesi zamanı edilən bütün dəyişiklikləri də əhatə edəcək.
Serialdakı digər məqalələr
Yedək Hissə 7: Nəticələr
Sizi şərhlərdə təklif olunan variantı müzakirə etməyə dəvət edirəm, diqqətinizə görə təşəkkür edirəm!
Mənbə: www.habr.com