Salam Habr oxucuları! Son məqalədə biz AERODISK ENGINE saxlama sistemlərində fəlakətin bərpası üçün sadə bir vasitə - replikasiya haqqında danışdıq. Bu yazıda biz daha mürəkkəb və maraqlı bir mövzuya - metroklasterə, yəni məlumat mərkəzlərinin aktiv-aktiv rejimdə işləməsinə imkan verən iki məlumat mərkəzi üçün avtomatik fəlakətdən mühafizə vasitəsinə keçəcəyik. Deyəcəyik, göstərəcəyik, qıracağıq və düzəldəcəyik.
Həmişə olduğu kimi, nəzəriyyənin əvvəlində
Metroklaster bir şəhər və ya rayon daxilində bir neçə sahəyə yerləşdirilmiş çoxluqdur. “Klaster” sözü bizə aydın şəkildə işarə edir ki, kompleks avtomatlaşdırılıb, yəni nasazlıqlar (failover) zamanı klaster qovşaqlarının kommutasiyası avtomatik baş verir.
Metroklaster ilə müntəzəm replikasiya arasındakı əsas fərq buradadır. Əməliyyatların avtomatlaşdırılması. Yəni, müəyyən insidentlər (data mərkəzinin sıradan çıxması, kanalların qırılması və s.) baş verdikdə, məlumatların əlçatanlığını saxlamaq üçün yaddaş sistemi müstəqil şəkildə lazımi hərəkətləri yerinə yetirəcək. Adi replikalardan istifadə edərkən, bu hərəkətlər administrator tərəfindən tamamilə və ya qismən əl ilə həyata keçirilir.
O nə edir?
Müəyyən metrocluster tətbiqetmələrindən istifadə edən müştərilərin qarşısına qoyduğu əsas məqsəd RTO-nu (Bərpa Zamanı Məqsədi) minimuma endirməkdir. Yəni uğursuzluqdan sonra İT xidmətlərinin bərpa müddətini minimuma endirmək. Əgər siz adi replikasiyadan istifadə edirsinizsə, onda bərpa müddəti həmişə metro klasteri ilə bərpa müddətindən çox olacaq. Niyə? Çox sadə. İnzibatçı iş yerində olmalı və replikasiyanı əl ilə dəyişməlidir, metro klaster isə bunu avtomatik edir.
Əgər yatmayan, yemək yeməyən, siqaret çəkməyən və ya xəstələnən, lakin günün 24 saatı saxlama sisteminin vəziyyətinə baxan xüsusi növbətçi administratorunuz yoxdursa, o zaman idarəçinin nasazlıq zamanı əllə keçid üçün mövcud olmalıdır.
Müvafiq olaraq, RTO metro klasteri və ya inzibatçıların növbətçi xidmətinin 99-cu səviyyəsinin ölməz bir idarəçisi olmadıqda, bütün sistemlərin keçid vaxtının cəminə və inzibatçıya zəmanət verildiyi maksimum müddətə bərabər olacaqdır. saxlama sistemi və əlaqəli sistemlərlə işləməyə başlayın.
Beləliklə, aydın bir nəticəyə gəlirik ki, RTO tələbi saatlar və ya günlər deyil, dəqiqələrdirsə, metroklasterdən istifadə edilməlidir.Yəni, məlumat mərkəzinin ən dəhşətli düşməsi halında, İT şöbəsi məlumat verməlidir. dəqiqələr və hətta saniyələr ərzində İT xidmətlərinə çıxışı bərpa etmək üçün vaxtla biznes.
Necə işləyir?
Aşağı səviyyədə, metroklaster əvvəlki məqalədə təsvir etdiyimiz sinxron məlumatların təkrarlanması mexanizmindən istifadə edir (aşağıya baxın). ). Replikasiya sinxron olduğundan, ona olan tələblər uyğundur, daha doğrusu:
- fizika kimi lif, 10 gigabit ethernet (və ya daha yüksək);
- məlumat mərkəzləri arasındakı məsafə 40 kilometrdən çox deyil;
- məlumat mərkəzləri arasında (saxlama sistemləri arasında) 5 millisaniyəyə qədər (optimal olaraq 2) optik kanal gecikməsi.
Bütün bu tələblər məsləhət xarakteri daşıyır, yəni bu tələblər yerinə yetirilməsə belə, metro klasteri işləyəcək, lakin başa düşmək lazımdır ki, bu tələblərə əməl edilməməsinin nəticələri hər iki saxlama sisteminin işini ləngitməyə bərabərdir. metro klasterində.
Beləliklə, yaddaş sistemləri arasında məlumat ötürmək üçün sinxron replikadan istifadə olunur, lakin replikalar avtomatik olaraq necə dəyişir və ən əsası, bölünmüş beyindən necə qaçınmaq olar? Bunun üçün yuxarıdakı səviyyədə əlavə bir qurumdan - arbitrdən istifadə olunur.
Arbitr necə işləyir və onun vəzifəsi nədir?
Arbitr üçüncü saytda (məsələn, ofisdə) işə salınmalı və ICMP və SSH vasitəsilə yaddaşa girişi təmin edən kiçik virtual maşın və ya aparat klasteridir. Başladıqdan sonra arbitr IP-ni təyin etməli və sonra saxlama tərəfdən ünvanını, üstəlik metro klasterində iştirak edən uzaqdan idarəedicilərin ünvanlarını göstərməlidir. Bundan sonra hakim getməyə hazırdır.
Arbitr daimi olaraq metro klasterindəki bütün saxlama sistemlərinə nəzarət edir və müəyyən bir saxlama sistemi mövcud olmadıqda, digər klaster üzvündən (“canlı” saxlama sistemlərindən biri) mövcud olmadığını təsdiqlədikdən sonra o, məlumatların saxlanması üçün prosedura başlamaq qərarına gəlir. replikasiya qaydalarının dəyişdirilməsi və xəritəçəkmə.
Çox vacib bir məqam. Arbitr həmişə saxlama sistemlərinin yerləşdiyi ərazidən fərqli yerdə yerləşməlidir, yəni nə anbar 1-in yerləşdiyi DPC 1-də, nə də saxlama 2-nin quraşdırıldığı DPC 2-də.
Niyə? Çünki yalnız bu yolla arbitr sağ qalmış saxlama sistemlərindən birinin köməyi ilə saxlama sistemlərinin quraşdırıldığı iki saytdan hər hansı birinin düşməsini birmənalı və dəqiq müəyyən edə bilər. Arbitr təyin etməyin hər hansı başqa yolu beyinin bölünməsinə səbəb ola bilər.
İndi arbitrin işinin təfərrüatlarına nəzər salaq.
Bütün saxlama nəzarətçilərini daim sorğulayan arbitrdə bir neçə xidmət işləyir. Əgər sorğunun nəticəsi əvvəlkindən fərqlidirsə (mövcud/əlçatmaz), o zaman o, arbitrdə də işləyən kiçik verilənlər bazasına yazılır.
Arbitrin məntiqini daha ətraflı nəzərdən keçirin.
Addım 1. Əlçatmazlığın müəyyən edilməsi. Yaddaş sisteminin nasazlığını göstərən hadisə eyni saxlama sisteminin hər iki nəzarətçisindən 5 saniyə ərzində ping-in olmamasıdır.
Addım 2. Kommutasiya prosedurunun başlanması. Arbitr saxlama sistemlərindən birinin əlçatmaz olduğunu başa düşdükdən sonra "ölü" saxlama sisteminin həqiqətən ölü olduğuna əmin olmaq üçün "canlı" saxlama sisteminə sorğu göndərir.
Arbitrdən belə bir əmr aldıqdan sonra ikinci (canlı) saxlama sistemi əlavə olaraq düşmüş birinci saxlama sisteminin mövcudluğunu yoxlayır və əgər yoxsa, arbitra öz təxmininin təsdiqini göndərir. SHD, həqiqətən, mövcud deyil.
Belə təsdiqi aldıqdan sonra arbitr düşmüş yaddaş sistemində aktiv (əsas) olan replikalarda replikasiyanın dəyişdirilməsi və xəritələşdirmənin artırılması üçün uzaqdan prosedura başlayır və bu replikaları ikincildən birinciliyə çevirmək üçün ikinci yaddaş sisteminə əmr göndərir. və xəritələşdirməni qaldırın. Yaxşı, ikinci saxlama sistemi, müvafiq olaraq, bu prosedurları yerinə yetirir, bundan sonra itirilmiş LUN-lara özündən çıxışı təmin edir.
Nə üçün əlavə yoxlama lazımdır? Kvorum üçün. Yəni, klaster üzvlərinin ümumi tək (3) sayının əksəriyyəti klaster qovşaqlarından birinin düşməsini təsdiq etməlidir. Yalnız bundan sonra bu qərar tam olaraq doğru olacaq. Bu, səhv keçiddən və müvafiq olaraq bölünmüş beyindən qaçınmaq üçün lazımdır.
2-ci addım təxminən 5-10 saniyə vaxt aparır, beləliklə, əlçatmazlığı müəyyən etmək üçün tələb olunan vaxtı (5 saniyə) nəzərə alaraq, uğursuzluqdan sonra 10-15 saniyə ərzində düşmüş saxlama sistemi olan LUN-lar canlı ilə işləmək üçün avtomatik olaraq əlçatan olacaq. saxlama.
Aydındır ki, hostlarla əlaqəni kəsməmək üçün hostlarda fasilələrin düzgün qurulmasına da diqqət yetirməlisiniz. Tövsiyə olunan fasilə ən azı 30 saniyədir. Bu, yüklənmə zamanı hostun yaddaşla əlaqəni kəsməsinin qarşısını alır və heç bir I/O kəsilməsinin olmamasını təmin edə bilər.
Bir saniyə gözləyin, belə çıxır ki, metro klasterində hər şey qaydasındadırsa, ümumiyyətlə, müntəzəm təkrarlamaya nə ehtiyacımız var?
Əslində hər şey o qədər də sadə deyil.
Metroclusterin müsbət və mənfi cəhətlərini nəzərdən keçirin
Beləliklə, biz anladıq ki, metroklasterin adi replikasiya ilə müqayisədə aşkar üstünlükləri bunlardır:
- Fəlakət zamanı minimum bərpa müddətini təmin edən tam avtomatlaşdırma;
- Və bu qədər :-).
İndi diqqət, mənfi cəhətlər:
- Həll dəyəri. Aerodisk sistemlərindəki metroklaster əlavə lisenziyalaşdırma tələb etməsə də (replika üçün olduğu kimi eyni lisenziya istifadə olunur), həllin qiyməti yenə də sinxron replikasiyadan daha yüksək olacaq. Siz sinxron replika üçün bütün tələbləri, üstəlik əlavə keçid və əlavə saytla əlaqəli metro klasterinə olan tələbləri yerinə yetirməli olacaqsınız (metro klasterinin planlaşdırılmasına baxın);
- Qərarın mürəkkəbliyi. Metroklaster adi replikadan qat-qat mürəkkəbdir və planlaşdırmaq, konfiqurasiya etmək və sənədləşdirmək üçün daha çox diqqət və səy tələb edir.
Nəhayət. Metrocluster, şübhəsiz ki, RTO-nu saniyələr və ya dəqiqələr ərzində təmin etməli olduğunuz zaman çox texnoloji və yaxşı bir həlldir. Ancaq belə bir tapşırıq yoxdursa və saatlarla RTO iş üçün uyğundursa, o zaman topdan sərçə atmağın mənası yoxdur. Adi fəhlə-kəndli replikasiyası kifayətdir, çünki metro klasteri əlavə xərclərə və İT infrastrukturunun çətinləşməsinə səbəb olacaq.
Metro klasterinin planlaşdırılması
Bu bölmə metro klasterinin dizaynı ilə bağlı hərtərəfli dərslik kimi nəzərdə tutulmur, ancaq belə bir sistem qurmaq qərarına gəldiyiniz halda işlənib hazırlanmalı olan əsas istiqamətləri göstərir. Buna görə də, metro klasterinin real tətbiqi zamanı saxlama sisteminin istehsalçısını (yəni bizi) və digər əlaqəli sistemləri məsləhətləşməyə cəlb etməyinizə əmin olun.
Platformalar
Yuxarıda qeyd edildiyi kimi, bir metro klasteri minimum üç sahə tələb edir. Saxlama sistemləri və əlaqəli sistemlərin işləyəcəyi iki məlumat mərkəzi, habelə arbitrin işləyəcəyi üçüncü sayt.
Məlumat mərkəzləri arasında tövsiyə olunan məsafə 40 kilometrdən çox deyil. Daha böyük məsafənin əlavə gecikmələrə səbəb olma ehtimalı yüksəkdir, bu isə metro klasteri vəziyyətində çox arzuolunmazdır. Xatırladaq ki, gecikmələr 5 millisaniyəyə qədər olmalıdır, baxmayaraq ki, 2 müddətində saxlamaq arzu edilir.
Planlaşdırma zamanı gecikmələrin də yoxlanılması tövsiyə olunur. Məlumat mərkəzləri arasında lif təmin edən hər hansı bir az və ya çox böyüklər üçün provayder keyfiyyət yoxlamasını olduqca tez təşkil edə bilər.
Arbitraj üçün gecikmələrə gəldikdə (yəni üçüncü saytla ilk ikisi arasında), tövsiyə olunan gecikmə həddi 200 millisaniyəyə qədərdir, yəni İnternet üzərindən müntəzəm korporativ VPN bağlantısı təmin edəcəkdir.
Kommutasiya və şəbəkə
Müxtəlif saytlardan saxlama sistemlərini birləşdirməyin kifayət olduğu replikasiya sxemindən fərqli olaraq, metro klaster sxemi müxtəlif saytlardakı hər iki saxlama sisteminə hostların qoşulmasını tələb edir. Fərqin nə olduğunu aydınlaşdırmaq üçün hər iki sxem aşağıda verilmişdir.
Diaqramdan göründüyü kimi, bizdə həm saxlama sistemi 1, həm də saxlama sistemi 1-yə baxan sayt 2 hostları var. Həmçinin, əksinə, sayt 2 hostları həm saxlama sistemi 2, həm də saxlama sistemi 1-ə baxır. Yəni hər bir host hər iki saxlama sistemini görür. Bu, metroklasterin fəaliyyəti üçün ilkin şərtdir.
Əlbəttə ki, hər bir ev sahibini optik şnur ilə başqa bir məlumat mərkəzinə çəkməyə ehtiyac yoxdur, kifayət qədər port və şnur olmayacaq. Bütün bu bağlantılar Ethernet 10G+ və ya FibreChannel 8G+ açarları vasitəsilə həyata keçirilməlidir (FC yalnız hostları birləşdirmək və IO üçün yaddaş üçün, replikasiya kanalı hazırda yalnız IP (Ethernet 10G+) üzərindən mövcuddur).
İndi şəbəkə topologiyası haqqında bir neçə söz. Əhəmiyyətli bir məqam alt şəbəkələrin düzgün konfiqurasiyasıdır. Aşağıdakı trafik növləri üçün dərhal bir neçə alt şəbəkə müəyyən etməlisiniz:
- Məlumatların saxlama sistemləri arasında sinxronlaşdırılacağı təkrarlama üçün alt şəbəkə. Onlardan bir neçəsi ola bilər, bu halda fərq etməz, hamısı cari (artıq həyata keçirilmiş) şəbəkə topologiyasından asılıdır. Onlardan ikisi varsa, açıq şəkildə onların arasında marşrut konfiqurasiya edilməlidir;
- Hostların saxlama resurslarına daxil olacağı yaddaş alt şəbəkələri (əgər bu, iSCSI-dirsə). Hər bir məlumat mərkəzində belə bir alt şəbəkə olmalıdır;
- Nəzarət alt şəbəkələri, yəni yaddaşın idarə olunduğu üç saytda üç yönləndirilə bilən alt şəbəkə və arbitr də orada yerləşir.
Burada host resurslarına daxil olmaq üçün alt şəbəkələri nəzərdən keçirmirik, çünki onlar tapşırıqlardan çox asılıdır.
Fərqli trafiki müxtəlif alt şəbəkələrə ayırmaq son dərəcə vacibdir (replikanı I / O-dan ayırmaq xüsusilə vacibdir), çünki bütün trafiki bir "qalın" alt şəbəkəyə qarışdırsanız, bu trafiki idarə etmək mümkün olmayacaq və iki məlumat mərkəzinin şərtləri bu hələ də müxtəlif şəbəkə toqquşma seçimlərinə səbəb ola bilər. Bu məqalə çərçivəsində bu məsələni dərindən araşdırmayacağıq, çünki məlumat mərkəzləri arasında şəbəkə avadanlığı istehsalçılarının resurslarında uzanan bir şəbəkənin planlaşdırılması haqqında oxuya bilərsiniz, burada bu çox ətraflı təsvir edilmişdir.
Arbitr Konfiqurasiyası
Arbitr ICMP və SSH protokolları vasitəsilə saxlama sisteminin bütün idarəetmə interfeyslərinə çıxışı təmin etməlidir. Arbitrin günaha dözümlülüyü haqqında da düşünməlisiniz. Burada bir nüans var.
Arbitrajın dəyişdirilməsi çox arzuolunandır, lakin tələb olunmur. Və arbitr səhv zamanda qəzaya uğrayarsa nə olar?
- Metroklasterin normal rejimdə işləməsi dəyişməyəcək, çünki arbtir heç bir şəkildə metro klasterinin normal rejimdə işləməsinə təsir göstərmir (onun vəzifəsi məlumat mərkəzləri arasında yükü vaxtında dəyişdirməkdir)
- Eyni zamanda, əgər arbitr bu və ya digər səbəbdən yıxılıb qəzanı data-mərkəzdə “yatıb”sa, o zaman keçid baş verməyəcək, çünki lazımi keçid komandalarını verəcək və kvorum təşkil edəcək heç kim olmayacaq. Bu halda, metro klasteri RTO-ya təsir edəcək fəlakət zamanı əl ilə dəyişdirilməli olan müntəzəm təkrarlama sxeminə çevriləcəkdir.
Bundan nə çıxır? Əgər həqiqətən minimum RTO təmin etməlisinizsə, arbitrin səhvlərə dözümlülüyünü təmin etməlisiniz. Bunun üçün iki seçim var:
- Bütün yetkin hipervizorlar nasazlığa dözümlülüyünü dəstəklədiyi üçün xətaya dözümlü hipervizorda arbitrlə virtual maşını işə salın;
- Əgər üçüncü saytda (şərti ofisdə) normal klaster quraşdırmaq çox tənbəldirsə və hipervizorların mövcud klasteri yoxdursa, onda biz 2U qutuda hazırlanmış arbitrin aparat versiyasını təqdim etmişik. adi x-86 serverləri işləyir və yerli uğursuzluğa tab gətirə bilir.
Metro klasterinin normal rejimdə buna ehtiyacı olmamasına baxmayaraq, arbitrin səhvlərə dözümlülüyünü təmin etməyinizi şiddətlə tövsiyə edirik. Ancaq həm nəzəriyyə, həm də təcrübənin göstərdiyi kimi, əgər siz həqiqətən etibarlı fəlakətə davamlı infrastruktur qurursunuzsa, onda onu təhlükəsiz oynamaq daha yaxşıdır. Özünüzü və biznesinizi "alçaqlıq qanunu"ndan, yəni həm arbitr, həm də saxlama sisteminin yerləşdiyi saytlardan birinin uğursuzluğundan qorumaq daha yaxşıdır.
Həll arxitekturası
Yuxarıdakı tələbləri nəzərə alaraq, aşağıdakı ümumi həll arxitekturasını əldə edirik.
Şiddətli tıxacın qarşısını almaq üçün LUN-lar iki sahəyə bərabər paylanmalıdır. Eyni zamanda, hər iki məlumat mərkəzində ölçülər təyin edərkən, qarşısını almaq üçün yalnız ikiqat həcmi (məlumatları iki saxlama sistemində eyni vaxtda saxlamaq üçün zəruri olan) deyil, həm də IOPS və MB / s-də ikiqat performans təmin etmək lazımdır. məlumat mərkəzlərindən birinin sıradan çıxması halında tətbiqlərin deqradasiyası - ov.
Ayrı-ayrılıqda qeyd edirik ki, ölçüyə düzgün yanaşma ilə (yəni IOPS və MB / s-nin müvafiq yuxarı hədlərini, həmçinin lazımi CPU və RAM resurslarını təmin etmək şərti ilə) saxlama sistemlərindən biri metro klasteri uğursuz olarsa, bir saxlama sistemində müvəqqəti iş şəraitində ciddi performans azalması olmayacaq.
Bu, eyni vaxtda işləyən iki sayt şəraitində sinxron replikasiyanın işləməsinin yazma performansının yarısını "yeməsi" ilə izah olunur, çünki hər bir əməliyyat iki saxlama sisteminə yazılmalıdır (RAID-1 / 10-a bənzər). Belə ki, yaddaş sistemlərindən biri sıradan çıxsa, müvəqqəti olaraq replikasiya effekti (uğursuz saxlama sistemi yüksələnə qədər) yox olur və biz yazma performansında ikiqat artım əldə edirik. Uğursuz saxlama sisteminin LUN-ları işləyən yaddaş sistemində yenidən işə salındıqdan sonra, bu ikiqat artım başqa bir saxlama sisteminin LUN-larından yük olması səbəbindən yox olur və biz əvvəlki performans səviyyəsinə qayıdırıq. "düşmək", ancaq eyni platforma daxilində.
Səlahiyyətli ölçülərin köməyi ilə istifadəçilərin bütün saxlama sisteminin nasazlığını hiss etməyəcəyi şərtləri təmin etmək mümkündür. Ancaq bir daha qeyd edirəm ki, bu, çox diqqətli ölçü tələb edir, yeri gəlmişkən, bizimlə pulsuz əlaqə saxlaya bilərsiniz :-).
Metro klasterinin qurulması
Metro klasterinin qurulması, təsvir etdiyimiz müntəzəm təkrarlamanın qurulmasına çox bənzəyir . Beləliklə, gəlin yalnız fərqlərə diqqət yetirək. Laboratoriyada yuxarıdakı arxitektura əsasında yalnız minimum versiyada bir dəzgah qurduq: 10G Ethernet vasitəsilə bir-birinə qoşulmuş iki saxlama sistemi, iki 10G açarı və 10G portlu hər iki saxlama sisteminə keçidlər vasitəsilə baxan bir host. Arbitr virtual maşında işləyir.
Replika üçün virtual IP (VIP) konfiqurasiya edərkən, metro klasteri üçün VIP növünü seçməlisiniz.
İki LUN üçün iki təkrarlama linki yaratdı və onları iki saxlama sistemi üzərində payladı: LUN TEST Primary on storage1 (METRO bağlantısı), LUN TEST2 Primary for storage2 (METRO2 bağlantısı).
Onlar üçün iki eyni hədəfi konfiqurasiya etdik (bizim vəziyyətimizdə iSCSI, lakin FC də dəstəklənir, konfiqurasiya məntiqi eynidir).
saxlama 1:
saxlama 2:
Replikasiya bağlantıları üçün hər bir saxlama sistemində xəritələr tərtib edilmişdir.
saxlama 1:
saxlama 2:
Multipath qurduq və ev sahibinə təqdim etdik.
Hakim təyin etmək
Arbitrin özü ilə xüsusi bir şey etmək lazım deyil, sadəcə onu üçüncü saytda yandırmaq, IP-ni təyin etmək və ICMP və SSH vasitəsilə ona girişi konfiqurasiya etmək lazımdır. Konfiqurasiya özü saxlama sistemlərinin özlərindən həyata keçirilir. Eyni zamanda, metro klasterindəki saxlama nəzarətçilərindən hər hansı birində arbitri bir dəfə konfiqurasiya etmək kifayətdir, bu parametrlər avtomatik olaraq bütün kontrollerlərə paylanacaq.
Uzaqdan Replikasiya >> Metrocluster (hər hansı nəzarətçidə)>> Konfiqurasiya düyməsi altında.
Arbitrin IP-sini, həmçinin iki uzaqdan saxlama nəzarətçisinin idarəetmə interfeyslərini daxil edirik.
Bundan sonra bütün xidmətləri aktivləşdirməlisiniz ("Hər şeyi yenidən başladın" düyməsi). Gələcəkdə yenidən konfiqurasiya etsəniz, parametrlərin qüvvəyə minməsi üçün xidmətlər yenidən işə salınmalıdır.
Bütün xidmətlərin işlədiyini yoxlayırıq.
Bu, metroklasterin qurulmasını tamamlayır.
Qəza testi
Bizim vəziyyətimizdə qəza testi olduqca sadə və sürətli olacaq, çünki təkrarlama funksionallığı (keçid, ardıcıllıq və s.) . Buna görə də, metro klasterinin etibarlılığını yoxlamaq üçün bizə qəzaların aşkarlanması, kommutasiya və yazma itkilərinin (giriş/çıxış dayanacaqlarının) olmamasının avtomatlaşdırılmasını yoxlamaq kifayətdir.
Bunu etmək üçün, böyük bir faylı başqa bir yaddaş sistemində aktivləşdirilməli olan LUN-a köçürməyə başladıqdan sonra hər iki nəzarətçini fiziki olaraq söndürməklə yaddaş sistemlərindən birinin tam uğursuzluğunu təqlid edirik.
Bir saxlama sistemini söndürün. İkinci saxlama sistemində biz qeydlərdə qonşu sistemlə əlaqənin itdiyi barədə xəbərdarlıq və mesajları görürük. SMTP və ya SNMP monitorinqi vasitəsilə bildirişlər konfiqurasiya edilirsə, müvafiq bildirişlər administratora göndəriləcək.
Düz 10 saniyə sonra (hər iki ekran görüntüsündə görünür), METRO replikasiya əlaqəsi (yıxılan yaddaş sistemində Əsas olan) avtomatik olaraq işləyən yaddaş sistemində Əsas oldu. Mövcud xəritələşdirmədən istifadə edərək, LUN TEST ev sahibi üçün əlçatan qaldı, qeyd bir az azaldı (vəd edilən 10 faiz daxilində), lakin dayanmadı.
Test uğurla başa çatdı.
Yekunlaşdırma
AERODISK Engine N seriyalı saxlama sistemlərində metroklasterin hazırkı tətbiqi İT xidmətlərinin dayanma müddətini aradan qaldırmaq və ya minimuma endirmək və minimal əmək xərcləri ilə 24/7/365 rejimində işləməsini təmin etmək lazım olan problemləri tam həll etməyə imkan verir.
Əlbəttə, deyə bilərsiniz ki, bütün bunlar nəzəriyyədir, ideal laboratoriya şəraitidir və sair... AMMA bizim bir sıra həyata keçirilən layihələrimiz var ki, orada fəlakətin bərpası funksiyasını həyata keçirmişik və sistemlər mükəmməl işləyir. Fəlakətə dözümlü konfiqurasiyada cəmi iki saxlama sisteminin istifadə olunduğu kifayət qədər tanınmış müştərilərimizdən biri artıq layihə haqqında məlumat dərc etməyə razılıq verib, ona görə də növbəti hissədə döyüş tətbiqi haqqında danışacağıq.
Təşəkkür edirəm, məhsuldar müzakirə gözləyirik.
Mənbə: www.habr.com