Salam, Habr oxucuları! Bu məqalənin mövzusu AERODISK Mühərrik saxlama sistemlərində fəlakətin bərpası vasitələrinin tətbiqi olacaqdır. Əvvəlcə hər iki alət haqqında bir məqalədə yazmaq istədik: replikasiya və metroklaster, lakin təəssüf ki, məqalə çox uzun olduğu üçün məqaləni iki hissəyə ayırdıq. Sadədən mürəkkəbə keçək. Bu yazıda biz sinxron replikasiyanı quracağıq və sınaqdan keçirəcəyik - bir məlumat mərkəzini atacağıq, həmçinin məlumat mərkəzləri arasındakı əlaqə kanalını qıracağıq və nə baş verdiyini görəcəyik.
Müştərilərimiz tez-tez bizə replikasiya ilə bağlı müxtəlif suallar verirlər, buna görə də replikaların qurulmasına və həyata keçirilməsini sınaqdan keçirməyə keçməzdən əvvəl sizə yaddaşda replikasiyanın nə olduğu haqqında bir az məlumat verəcəyik.
Bir az nəzəriyyə
Saxlama sistemlərində təkrarlama eyni vaxtda bir neçə saxlama sistemində verilənlərin eyniliyini təmin edən davamlı prosesdir. Texniki olaraq, təkrarlama iki yolla həyata keçirilir.
Sinxron replikasiya – bu, məlumatların əsas saxlama sistemindən ehtiyat nüsxəyə köçürülməsi, ardınca isə hər iki saxlama sistemindən məlumatların qeydə alındığı və təsdiqlənməsinin məcburi təsdiqi. Məhz hər iki tərəfdən (hər iki saxlama sistemində) təsdiqləndikdən sonra məlumat qeydə alınmış sayılır və onunla işləmək olar. Bu, replikada iştirak edən bütün saxlama sistemlərində zəmanətli məlumat şəxsiyyətini təmin edir.
Bu metodun üstünlükləri:
- Bütün saxlama sistemlərində məlumatlar həmişə eynidır
Eksiler:
- Həllin yüksək qiyməti (sürətli rabitə kanalları, bahalı optik lif, uzun dalğalı ötürücülər və s.)
- Məsafə məhdudiyyətləri (bir neçə on kilometr ərzində)
- Məntiqi məlumatların korlanmasına qarşı heç bir qorunma yoxdur (əgər verilənlər əsas yaddaş sistemində (qəsdən və ya təsadüfən) pozulubsa, o, avtomatik olaraq və ehtiyat nüsxədə dərhal korlanacaq, çünki məlumatlar həmişə eynidır (bu paradoksdur)
Asinxron replikasiya – bu həm də məlumatların əsas yaddaş sistemindən ehtiyat nüsxəyə köçürülməsidir, lakin müəyyən gecikmə ilə və digər tərəfdən yazının təsdiqlənməsinə ehtiyac olmadan. Siz məlumatı əsas yaddaş sisteminə qeyd etdikdən sonra dərhal işləyə bilərsiniz və ehtiyat saxlama sistemində məlumatlar bir müddət sonra mövcud olacaq. Bu vəziyyətdə məlumatların eyniliyi, əlbəttə ki, heç bir şəkildə təmin edilmir. Ehtiyat saxlama sistemindəki məlumatlar həmişə bir az "keçmişdə" qalır.
Asinxron replikasiyanın üstünlükləri:
- Aşağı qiymətli həll (istənilən rabitə kanalları, optika isteğe bağlıdır)
- Məsafə məhdudiyyəti yoxdur
- Ehtiyat saxlama sistemində məlumat əsas sistemdə zədələnərsə (ən azı bir müddət) pisləşmir; məlumat xarab olarsa, ehtiyat nüsxə saxlama sistemində məlumatların pozulmasının qarşısını almaq üçün hər zaman replikanı dayandıra bilərsiniz.
Eksiler:
- Fərqli məlumat mərkəzlərindəki məlumatlar həmişə eyni deyil
Beləliklə, təkrarlama rejiminin seçimi biznes məqsədlərindən asılıdır. Ehtiyat məlumat mərkəzinin əsas məlumat mərkəzi ilə eyni məlumatları ehtiva etməsi sizin üçün vacibdirsə (yəni, RPO üçün biznes tələbi = 0), onda siz nağd pulu çıxarmalı və sinxronizasiyanın məhdudiyyətlərinə dözməli olacaqsınız. replika. Məlumat vəziyyətində gecikmə məqbuldursa və ya sadəcə pul yoxdursa, o zaman asinxron metoddan mütləq istifadə etməlisiniz.
Metroklaster kimi belə bir rejimi (daha doğrusu, topologiyanı) ayrıca vurğulayaq. Metroklaster rejimində sinxron replikasiya istifadə olunur, lakin adi replikadan fərqli olaraq, metroklaster hər iki saxlama sisteminə aktiv rejimdə işləməyə imkan verir. Bunlar. aktiv və gözləmə rejimində olan məlumat mərkəzləri arasında fərqiniz yoxdur. Tətbiqlər fiziki olaraq müxtəlif məlumat mərkəzlərində yerləşən iki saxlama sistemi ilə eyni vaxtda işləyir. Belə bir topologiyada qəzalar zamanı dayanmalar çox azdır (RTO, adətən dəqiqələr). Bu yazıda biz metroklasterin tətbiqini nəzərdən keçirməyəcəyik, çünki bu, çox geniş və əhatəli mövzudur, buna görə də bunun davamında ayrıca, növbəti məqaləni ona həsr edəcəyik.
Həmçinin, çox vaxt, biz saxlama sistemlərindən istifadə edərək replikasiya haqqında danışarkən, bir çox insanın ağlabatan sualı olur: > “Bir çox proqramların öz replikasiya vasitələri var, niyə saxlama sistemlərində replikasiyadan istifadə olunur? Daha yaxşıdır, yoxsa daha pis?
Burada aydın cavab yoxdur, buna görə də burada ÜÇÜN və ƏSAS arqumentlər var:
Yaddaşın təkrarlanması üçün arqumentlər:
- Həllin sadəliyi. Bir alətlə yük növündən və tətbiqindən asılı olmayaraq bütün məlumat dəstinizi təkrarlaya bilərsiniz. Tətbiqlərdən replika istifadə etsəniz, hər bir tətbiqi ayrıca konfiqurasiya etməli olacaqsınız. Əgər bunlardan 2-dən çoxu varsa, bu, son dərəcə əmək tələb edir və baha başa gəlir (tətbiqlərin təkrarlanması adətən hər bir proqram üçün ayrıca və pulsuz olmayan lisenziya tələb edir. Amma bu barədə aşağıda daha çox məlumat verilir).
- Siz hər şeyi təkrarlaya bilərsiniz - istənilən proqram, istənilən məlumat - və o, həmişə ardıcıl olacaq. Bir çox (əksər) proqramların təkrarlama imkanları yoxdur və yaddaş sistemindən olan replikalar fəlakətlərdən qorunmağın yeganə yoludur.
- Tətbiqin təkrarlanması funksionallığı üçün artıq ödəniş etməyə ehtiyac yoxdur. Bir qayda olaraq, replika saxlama sistemi üçün lisenziyalar kimi ucuz deyil. Lakin siz saxlama replikasiyası üçün lisenziyanı bir dəfə ödəməlisiniz və proqram replikası üçün lisenziya hər bir proqram üçün ayrıca alınmalıdır. Bu cür proqramlar çoxdursa, bu, olduqca qəpik-quruşa başa gəlir və saxlama replikasiyası üçün lisenziyaların dəyəri okeanda bir damla olur.
Yaddaş replikasiyasına qarşı arqumentlər:
- Tətbiqlər vasitəsilə replika proqramların özləri nöqteyi-nəzərindən daha çox funksionallığa malikdir, proqram öz məlumatlarını daha yaxşı bilir (açıq-aydın), buna görə də onlarla işləmək üçün daha çox seçim var.
- Bəzi proqramların istehsalçıları replikasiya üçüncü tərəf alətlərindən istifadə edilməklə həyata keçirilirsə, onların məlumatlarının ardıcıllığına zəmanət vermirlər. *
* - mübahisəli tezis. Məsələn, tanınmış DBMS istehsalçısı çox uzun müddətdir ki, onların DBMS-lərinin yalnız öz vasitələrindən istifadə etməklə normal surətdə təkrarlana biləcəyini və replikasiyanın qalan hissəsinin (saxlama sistemləri də daxil olmaqla) “doğru olmadığını” rəsmi olaraq bəyan edir. Amma həyat göstərdi ki, belə deyil. Çox güman ki (lakin bu dəqiq deyil) bu, sadəcə olaraq müştərilərə daha çox lisenziya satmaq üçün ən dürüst cəhd deyil.
Nəticədə, əksər hallarda, saxlama sistemindən replikasiya daha yaxşıdır, çünki Bu, daha sadə və daha az bahalı seçimdir, lakin xüsusi proqram funksionallığına ehtiyac duyulan mürəkkəb hallar var və proqram səviyyəsində replikasiya ilə işləmək lazımdır.
Nəzəriyyə bitdi, indi praktika
Replikanı laboratoriyamızda konfiqurasiya edəcəyik. Laboratoriya şəraitində iki məlumat mərkəzini təqlid etdik (əslində fərqli binalarda görünən iki bitişik raf). Stend bir-birinə optik kabellərlə birləşdirilən iki Mühərrik N2 saxlama sistemindən ibarətdir. Windows Server 2016 ilə işləyən fiziki server 10Gb Ethernet istifadə edərək hər iki saxlama sisteminə qoşulur. Stend olduqca sadədir, lakin bu mahiyyəti dəyişmir.
Sxematik olaraq belə görünür:
Məntiqi olaraq, təkrarlama aşağıdakı kimi təşkil edilir:
İndi bizdə olan replikasiya funksiyasına baxaq.
İki rejim dəstəklənir: asinxron və sinxron. Sinxron rejimin məsafə və rabitə kanalı ilə məhdudlaşması məntiqlidir. Xüsusilə, sinxron rejim fizika və 10 Gigabit Ethernet (və ya daha yüksək) kimi lifdən istifadəni tələb edir.
Sinxron replikasiya üçün dəstəklənən məsafə 40 kilometr, məlumat mərkəzləri arasında optik kanalın gecikmə dəyəri 2 millisaniyəyə qədərdir. Ümumiyyətlə, o, böyük gecikmələrlə işləyəcək, lakin sonra qeyd zamanı güclü ləngimələr olacaq (bu da məntiqlidir), ona görə də məlumat mərkəzləri arasında sinxron replikasiyanı planlaşdırırsınızsa, optikanın keyfiyyətini və gecikmələri yoxlamalısınız.
Asinxron replikasiya üçün tələblər o qədər də ciddi deyil. Daha doğrusu, onlar ümumiyyətlə yoxdur. İstənilən işləyən Ethernet bağlantısı olacaq.
Hal-hazırda, AERODISK ENGINE saxlama sistemi Ethernet protokolu (mis və ya optik üzərində) vasitəsilə blok cihazları (LUN) üçün replikasiyanı dəstəkləyir. Fiber Kanal üzərindən SAN toxuması vasitəsilə təkrarlamanın tələb olunduğu layihələr üçün biz hazırda müvafiq həlli əlavə edirik, lakin o, hələ hazır deyil, belə ki, bizim vəziyyətimizdə yalnız Ethernet.
Replikasiya hər hansı ENGINE seriyalı saxlama sistemləri (N1, N2, N4) arasında kiçik sistemlərdən köhnə sistemlərə və əksinə işləyə bilər.
Hər iki təkrarlama rejiminin funksionallığı tamamilə eynidır. Aşağıda mövcud olanlar haqqında daha ətraflı məlumat verilmişdir:
- Replikasiya "birə bir" və ya "birə bir", yəni iki məlumat mərkəzi olan klassik versiya, əsas və ehtiyat nüsxə
- Replikasiya “bir çoxa” və ya “bir çoxa”, yəni. bir LUN eyni anda bir neçə saxlama sisteminə təkrarlana bilər
- Replikasiyanın istiqamətini aktivləşdirmək, söndürmək və ya dəyişmək üçün müvafiq olaraq replikasiyanı aktivləşdirin, deaktiv edin və “əks” edin
- Replikasiya həm RDG (Raid Paylanmış Qrup) həm də DDP (Dynamic Disk Pool) hovuzları üçün əlçatandır. Bununla belə, RDG hovuzunun LUN-ları yalnız başqa RDG-yə təkrarlana bilər. DDP ilə eyni.
Daha çox kiçik xüsusiyyətlər var, lakin onları sadalamaqda xüsusi bir məqam yoxdur, biz onları qurarkən qeyd edəcəyik.
Replikasiyanın qurulması
Quraşdırma prosesi olduqca sadədir və üç mərhələdən ibarətdir.
- Şəbəkə konfiqurasiyası
- Yaddaş quraşdırma
- Qaydaların (əlaqələrin) qurulması və xəritələşdirilməsi
Replikasiyanın qurulmasında vacib bir məqam ondan ibarətdir ki, ilk iki mərhələ uzaq yaddaş sistemində, üçüncü mərhələ - yalnız əsasda təkrarlanmalıdır.
Şəbəkə resurslarının qurulması
İlk addım replikasiya trafikinin ötürüləcəyi şəbəkə portlarını konfiqurasiya etməkdir. Bunu etmək üçün siz portları işə salmalı və Front-end adapterləri bölməsində onların IP ünvanlarını təyin etməlisiniz.
Bundan sonra bir hovuz (bizim vəziyyətimizdə RDG) və replikasiya üçün virtual IP (VIP) yaratmalıyıq. VIP yaddaş nəzarətçilərinin iki “fiziki” ünvanına (indicə konfiqurasiya etdiyimiz portlar) bağlı olan üzən IP ünvanıdır. Bu, əsas təkrarlama interfeysi olacaq. Siz həmçinin VIP ilə deyil, VLAN ilə işləyə bilərsiniz, əgər etiketlənmiş trafiklə işləmək lazımdırsa.
Replika üçün VIP yaratmaq prosesi I/O (NFS, SMB, iSCSI) üçün VIP yaratmaqdan çox da fərqlənmir. Bu halda, biz adi VIP yaradırıq (VLAN olmadan), lakin onun replikasiya üçün olduğunu göstərməyi unutmayın (bu göstərici olmadan biz növbəti addımda qaydaya VIP əlavə edə bilməyəcəyik).
VIP, arasında üzdüyü IP portları ilə eyni alt şəbəkədə olmalıdır.
Bu parametrləri, əlbəttə ki, fərqli bir IP ilə uzaq bir yaddaş sistemində təkrar edirik.
Fərqli saxlama sistemlərindən olan VIP-lər müxtəlif alt şəbəkələrdə ola bilər, əsas odur ki, onlar arasında marşrutlaşdırma var. Bizim vəziyyətimizdə bu nümunə tam olaraq göstərilmişdir (192.168.3.XX və 192.168.2.XX)
Bu, şəbəkə hissəsinin hazırlanmasını tamamlayır.
Yaddaş qurulur
Replika üçün yaddaşın qurulması adi haldan yalnız ona görə fərqlənir ki, biz “Replikasiya Xəritəçəkmə” xüsusi menyusu vasitəsilə xəritələşdirməni edirik. Əks təqdirdə, hər şey adi quraşdırma ilə eynidır. İndi, qaydasında.
Əvvəllər yaradılmış hovuz R02-də LUN yaratmalısınız. Gəlin onu yaradaq və LUN1 adlandıraq.
Eyni ölçülü uzaq yaddaş sistemində eyni LUN-u yaratmalıyıq. Biz yaradırıq. Qarışıqlığın qarşısını almaq üçün uzaqdan LUN LUN1R-ə zəng edək
Əgər artıq mövcud olan LUN-u götürməli olsaq, replikanı qurarkən bu məhsuldar LUN-u hostdan ayırmalı və sadəcə uzaq yaddaş sistemində eyni ölçülü boş LUN yaratmalıyıq.
Yaddaşın quraşdırılması tamamlandı, replikasiya qaydasının yaradılmasına keçək.
Replikasiya qaydaları və ya replika keçidlərinin qurulması
Hazırda əsas olacaq yaddaş sistemində LUN-lar yaratdıqdan sonra biz 1-ci yaddaş sistemində LUN1 təkrarlama qaydasını 1-ci yaddaş sistemində LUN2R-ə konfiqurasiya edirik.
Parametr "Uzaqdan təkrarlama" menyusunda edilir
Gəlin bir qayda yaradaq. Bunun üçün replikanın alıcısını göstərməlisiniz. Orada biz həmçinin əlaqənin adını və replikasiya növünü (sinxron və ya asinxron) təyin etdik.
“Uzaqdan sistemlər” sahəsində biz yaddaş sistemimizi2 əlavə edirik. Əlavə etmək üçün idarəetmə IP saxlama sistemlərindən (MGR) və replikasiyanı həyata keçirəcəyimiz uzaq LUN-un adından istifadə etməlisiniz (bizim vəziyyətimizdə LUN1R). Nəzarət IP-ləri yalnız əlaqə əlavə etmə mərhələsində lazımdır; replikasiya trafiki onlar vasitəsilə ötürülməyəcək, bunun üçün əvvəllər konfiqurasiya edilmiş VIP istifadə ediləcək.
Artıq bu mərhələdə biz “birdən çox” topologiyası üçün birdən çox uzaq sistem əlavə edə bilərik: aşağıdakı şəkildəki kimi “qovşaq əlavə et” düyməsini klikləyin.
Bizim vəziyyətimizdə yalnız bir uzaq sistem var, buna görə də özümüzü bununla məhdudlaşdırırıq.
Qayda hazırdır. Nəzərə alın ki, o, bütün təkrarlama iştirakçılarına avtomatik olaraq əlavə olunur (bizim vəziyyətimizdə onlardan ikisi var). İstənilən sayda LUN-lar üçün və istənilən istiqamətdə istədiyiniz qədər belə qaydalar yarada bilərsiniz. Məsələn, yükü tarazlaşdırmaq üçün LUN-ların bir hissəsini saxlama sistemindən 1-dən saxlama sisteminə, digər hissəsini isə əksinə, saxlama sistemindən 2-dən saxlama sisteminə 2-ə qədər təkrarlaya bilərik.
Saxlama sistemi 1. Yaradıldıqdan dərhal sonra sinxronizasiya başladı.
Saxlama sistemi 2. Eyni qaydanı görürük, lakin sinxronizasiya artıq başa çatıb.
1 saxlama sistemindəki LUN1 Əsas roldadır, yəni aktivdir. 1-ci saxlama sistemindəki LUN2R İkinci dərəcəli rolundadır, yəni yaddaş sistemi 1 uğursuz olarsa, gözləmə rejimindədir.
İndi LUN-umuzu hosta bağlaya bilərik.
Biz iSCSI vasitəsilə qoşulacağıq, baxmayaraq ki, bu, FC vasitəsilə də edilə bilər. Replikada iSCSI LUN vasitəsilə xəritəçəkmənin qurulması praktiki olaraq adi ssenaridən fərqlənmir, ona görə də biz bunu burada ətraflı nəzərdən keçirməyəcəyik. Əgər bir şey varsa, bu proses məqalədə təsvir edilmişdir ".
Yeganə fərq odur ki, biz “Replikasiya Xəritəçəkmə” menyusunda xəritə yaratırıq
Xəritəçəkmə qurduq və LUN-u ev sahibinə verdik. Ev sahibi LUN-u gördü.
Biz onu yerli fayl sisteminə formatlayırıq.
Budur, quraşdırma tamamlandı. Növbəti sınaqlar gələcək.
Test
Üç əsas ssenarini sınaqdan keçirəcəyik.
- Müntəzəm rol dəyişdirmə İkincil > Əsas. Məsələn, əsas məlumat mərkəzində bəzi profilaktik əməliyyatları yerinə yetirməli olduğumuz halda müntəzəm rolun dəyişdirilməsi lazımdır və bu müddət ərzində məlumatların mövcud olması üçün yükü ehtiyat məlumat mərkəzinə köçürürük.
- Fövqəladə rolun dəyişdirilməsi İkincil > Əsas (məlumat mərkəzinin nasazlığı). Bu, şirkətin uzun müddət dayanmadan tam məlumat mərkəzinin nasazlığından sağ çıxmağa kömək edə bilən replikasiyanın mövcud olduğu əsas ssenaridir.
- Məlumat mərkəzləri arasında rabitə kanallarının parçalanması. Nədənsə məlumat mərkəzləri arasında əlaqə kanalının mövcud olmadığı şəraitdə iki saxlama sisteminin düzgün davranışının yoxlanılması (məsələn, ekskavator yanlış yerdə qazılıb və qaranlıq optikanı sındırıb).
Əvvəlcə LUN-umuza məlumat yazmağa başlayacağıq (təsadüfi məlumatlarla faylların yazılması). Dərhal görürük ki, saxlama sistemləri arasında rabitə kanalı istifadə olunur. Replikasiyadan məsul olan portların yük monitorinqini açsanız, bunu başa düşmək asandır.
Hər iki saxlama sistemində indi "faydalı" məlumatlar var, biz testə başlaya bilərik.
Hər ehtimala qarşı, fayllardan birinin hash cəminə baxaq və onları yazaq.
Daimi rol dəyişdirmə
Rolların dəyişdirilməsi əməliyyatı (replikasiya istiqamətinin dəyişdirilməsi) istənilən yaddaş sistemi ilə həyata keçirilə bilər, lakin siz yenə də hər ikisinə keçməli olacaqsınız, çünki siz Əsasda xəritələşdirməni söndürməli və onu İkincildə aktiv etməlisiniz (bu, Əsas olacaq). ).
Bəlkə də indi ağlabatan sual yaranır: niyə bunu avtomatlaşdırmırıq? Cavab belədir: bu sadədir, təkrarlama yalnız əl əməliyyatlarına əsaslanan fəlakətlərə davamlılığın sadə vasitəsidir. Bu əməliyyatları avtomatlaşdırmaq üçün metroklaster rejimi mövcuddur, o, tam avtomatlaşdırılmışdır, lakin onun konfiqurasiyası daha mürəkkəbdir. Metroklasterin qurulması haqqında növbəti yazıda yazacağıq.
Əsas yaddaş sistemində qeydin dayanmasını təmin etmək üçün xəritələşdirməni söndürürük.
Sonra yaddaş sistemlərindən birində (əsas və ya ehtiyat nüsxədə fərq etməz) "Uzaqdan təkrarlama" menyusunda REPL1 əlaqəmizi seçin və "Rolu dəyişdir" düyməsini basın.
Bir neçə saniyədən sonra LUN1R (ehtiyat saxlama sistemi) Əsas olur.
LUN1R-nin yaddaş sistemi2 ilə xəritəsini çəkirik.
Bundan sonra, E: diskimiz avtomatik olaraq hosta qoşulur, yalnız bu dəfə LUN1R-dən "gəldi".
Hər halda, hash məbləğlərini müqayisə edirik.
Eynilə. Test keçdi.
Failover. Məlumat mərkəzinin nasazlığı
Hazırda müntəzəm keçiddən sonra əsas yaddaş sistemi müvafiq olaraq 2 və LUN1R saxlama sistemidir. Qəzaya oxşamaq üçün hər iki yaddaş nəzarətçisində enerjini söndürəcəyik2.
Artıq ona giriş yoxdur.
Gəlin 1-ci yaddaş sistemində (hazırda ehtiyat sistem) nə baş verdiyinə baxaq.
Biz görürük ki, Əsas LUN (LUN1R) əlçatmazdır. Günlüklərdə, məlumat panelində, həmçinin təkrarlama qaydasının özündə bir səhv mesajı göründü. Müvafiq olaraq, ev sahibinin məlumatları hazırda əlçatan deyil.
LUN1 rolunu Əsas olaraq dəyişdirin.
Mən ev sahibi ilə xəritə çəkirəm.
E sürücüsünün hostda göründüyünə əmin olun.
Haşı yoxlayırıq.
Hər şey yaxşıdır. Saxlama sistemi aktiv olan məlumat mərkəzinin yıxılmasından uğurla xilas oldu. Replikasiyanın “reversalını” birləşdirməyə və LUN-u ehtiyat məlumat mərkəzindən birləşdirməyə sərf etdiyimiz təxmini vaxt təxminən 3 dəqiqə idi. Aydındır ki, real istehsalda hər şey daha mürəkkəbdir və saxlama sistemləri ilə hərəkətlərə əlavə olaraq, şəbəkədə, hostlarda, tətbiqlərdə daha çox əməliyyatlar yerinə yetirməlisiniz. Və həyatda bu müddət daha uzun olacaq.
Burada yazmaq istərdim ki, hər şey, test uğurla başa çatdı, amma tələsməyək. Əsas saxlama sistemi "yalan danışır", biz bilirik ki, o, "yıxılanda" Əsas rolda idi. Birdən işə düşsə nə olar? Məlumatların pozulmasına bərabər olan iki Əsas rol olacaq? İndi yoxlayaq.
Gəlin birdən əsas saxlama sistemini işə salaq.
Bir neçə dəqiqə yüklənir və sonra qısa sinxronizasiyadan sonra xidmətə qayıdır, lakin İkincil rolunda.
Hər şey qaydasındadır. Split beyin baş vermədi. Biz bu barədə düşündük və hər zaman yıxıldıqdan sonra saxlama sistemi “həyat boyu” hansı rolda olmasından asılı olmayaraq, İkinci dərəcəli rola yüksəlir. İndi əminliklə deyə bilərik ki, məlumat mərkəzinin uğursuzluq sınağı uğurla keçdi.
Məlumat mərkəzləri arasında rabitə kanallarının nasazlığı
Bu testin əsas vəzifəsi saxlama sisteminin iki saxlama sistemi arasında əlaqə kanallarını müvəqqəti itirdiyi və sonra yenidən göründüyü təqdirdə qəribə davranmağa başlamadığından əmin olmaqdır.
Belə ki. Saxlama sistemləri arasında telləri ayırırıq (təsəvvür edək ki, onlar ekskavator tərəfindən qazılıb).
İbtidai sinifdə ikinci ilə heç bir əlaqənin olmadığını görürük.
İkinci dərəcəlidə görürük ki, İbtidai ilə heç bir əlaqə yoxdur.
Hər şey yaxşı işləyir və biz əsas saxlama sisteminə məlumat yazmağa davam edirik, yəni onların ehtiyat nüsxədən fərqli olacağına zəmanət verilir, yəni "ayrılmışdır".
Bir neçə dəqiqədən sonra rabitə kanalını "təmir edirik". Saxlama sistemləri bir-birini görən kimi məlumatların sinxronizasiyası avtomatik olaraq aktivləşdirilir. Burada administratordan heç nə tələb olunmur.
Bir müddət sonra sinxronizasiya tamamlanır.
Bağlantı bərpa edildi, rabitə kanallarının itməsi heç bir fövqəladə vəziyyət yaratmadı və işə salındıqdan sonra avtomatik sinxronizasiya baş verdi.
Tapıntılar
Nəzəriyyəni təhlil etdik - nəyə ehtiyac var və nə üçün, müsbət tərəflər və mənfi cəhətlər haradadır. Sonra iki saxlama sistemi arasında sinxron replikasiya qurduq.
Sonra, normal keçid, məlumat mərkəzinin nasazlığı və rabitə kanalının nasazlığı üçün əsas testlər aparıldı. Bütün hallarda saxlama sistemi yaxşı işləyirdi. Məlumat itkisi yoxdur və manuel ssenari üçün inzibati əməliyyatlar minimuma endirilir.
Növbəti dəfə biz vəziyyəti çətinləşdirəcəyik və bütün bu məntiqin avtomatlaşdırılmış metroklasterdə aktiv-aktiv rejimdə necə işlədiyini göstərəcəyik, yəni hər iki saxlama sistemi birincil olduqda və saxlama sisteminin nasazlığı zamanı davranış tam avtomatlaşdırılmışdır.
Zəhmət olmasa şərhlər yazın, biz sağlam tənqid və praktiki məsləhət almaqdan şad olarıq.
Növbəti dəfəyə qədər.
Mənbə: www.habr.com