Hey Habr!
Yeni il tətillərindən sonra iki sayta əsaslanan fəlakətə davamlı buludu yenidən işə saldıq. Bu gün biz sizə bunun necə işlədiyini izah edəcəyik və klasterin ayrı-ayrı elementləri sıradan çıxdıqda və bütün sayt qəzaya uğradıqda müştəri virtual maşınlarına nə baş verdiyini göstərəcəyik (spoiler – onlarla hər şey qaydasındadır).
OST saytında fəlakətə davamlı bulud saxlama sistemi.
İçəridə nə var
Başlıq altında klasterdə VMware ESXi hipervizoru olan Cisco UCS serverləri, iki INFINIDAT InfiniBox F2240 saxlama sistemi, Cisco Nexus şəbəkə avadanlığı, həmçinin Brocade SAN açarları var. Klaster iki sayta bölünür - OST və NORD, yəni hər bir məlumat mərkəzində eyni avadanlıq dəsti var. Əslində onu fəlakətə davamlı edən də budur.
Bir sayt daxilində əsas elementlər də təkrarlanır (hostlar, SAN keçidləri, şəbəkə).
İki sayt xüsusi fiber-optik marşrutlarla birləşdirilir, həmçinin qorunur.
Saxlama sistemləri haqqında bir neçə söz. Biz NetApp-da fəlakətə davamlı buludun ilk versiyasını yaratdıq. Burada INFINIDAT-ı seçdik və bunun səbəbi:
- Aktiv-Aktiv replikasiya seçimi. Saxlama sistemlərindən biri tamamilə sıradan çıxsa belə, virtual maşının işləməsinə imkan verir. Replikasiya haqqında daha sonra sizə məlumat verəcəyəm.
- Sistem nasazlığına dözümlülüyünü artırmaq üçün üç disk nəzarətçisi. Adətən iki olur.
- Hazır həll. Biz sadəcə şəbəkəyə qoşulmalı və konfiqurasiya edilməli olan əvvəlcədən yığılmış rəf aldıq.
- Diqqətli texniki dəstək. INFINIDAT mühəndisləri daim yaddaş sistemi qeydlərini və hadisələrini təhlil edir, yeni proqram təminatı versiyalarını quraşdırır və konfiqurasiyaya kömək edir.
Qablaşdırmadan bəzi fotoları təqdim edirik:
Nasıl çalışır
Bulud artıq öz daxilində xətaya dözümlüdür. Müştərini tək aparat və proqram təminatının nasazlığından qoruyur. Fəlakətə davamlı bir sayt daxilində kütləvi nasazlıqlardan qorunmağa kömək edəcək: məsələn, bir saxlama sisteminin nasazlığı (və ya tez-tez baş verən SDS klasteri 🙂), saxlama şəbəkəsindəki kütləvi səhvlər və s. Yaxşı və ən əsası: belə bir bulud, yanğın, söndürmə, basqınçıların ələ keçirilməsi və ya yadplanetlilərin enişi səbəbindən bütün sayt əlçatmaz olduqda qənaət edir.
Bütün bu hallarda müştəri virtual maşınları işləməyə davam edir və bunun səbəbi budur.
Klaster dizaynı elə qurulub ki, müştəri virtual maşınları olan istənilən ESXi host iki saxlama sistemindən hər hansı birinə daxil ola bilsin. OST saytında saxlama sistemi uğursuz olarsa, virtual maşınlar işləməyə davam edəcək: onların işlədiyi hostlar məlumat üçün NORD-da saxlama sisteminə daxil olacaqlar.
Klasterdəki əlaqə diaqramı belə görünür.
Bu, iki saytın SAN parçaları arasında Inter-Switch Linkin konfiqurasiya edilməsinə görə mümkündür: Fabric A OST SAN açarı Fabric A NORD SAN keçidinə və eynilə Fabric B SAN açarlarına qoşulub.
Yaxşı, SAN fabriklərinin bütün bu incəliklərinin məna kəsb etməsi üçün Aktiv-Aktiv replikasiya iki saxlama sistemi arasında konfiqurasiya edilir: məlumat demək olar ki, eyni vaxtda yerli və uzaq yaddaş sistemlərinə yazılır, RPO = 0. Belə çıxır ki, ilkin məlumatlar bir yaddaş sistemində, onun replikası isə digərində saxlanılır. Məlumat saxlama həcmləri səviyyəsində təkrarlanır və VM məlumatları (onun diskləri, konfiqurasiya faylı, dəyişdirmə faylı və s.) onlarda saxlanılır.
ESXi host əsas həcmi və onun replikasını bir disk cihazı (Storage Device) kimi görür. ESXi hostundan hər bir disk cihazına 24 yol var:
12 yol onu yerli yaddaş sisteminə (optimal yollar), qalan 12 yol isə uzaq yaddaş sisteminə (optimal olmayan yollar) birləşdirir. Normal vəziyyətdə, ESXi “optimal” yollardan istifadə edərək yerli yaddaş sistemindəki məlumatlara daxil olur. Bu saxlama sistemi uğursuz olduqda, ESXi optimal yolları itirir və "optimal olmayan" yollara keçir. Diaqramda belə görünür.
Fəlakətə davamlı klasterin sxemi.
Bütün müştəri şəbəkələri hər iki sayta ümumi şəbəkə quruluşu vasitəsilə qoşulur. Hər bir sayt müştəri şəbəkələrinin bağlandığı Provayder Edge (PE) işlədir. PE-lər ümumi bir çoxluqda birləşdirilir. PE bir saytda uğursuz olarsa, bütün trafik ikinci sayta yönləndirilir. Bunun sayəsində PE-siz qalan saytdan virtual maşınlar şəbəkə üzərindən müştəri üçün əlçatan qalır.
İndi müxtəlif uğursuzluqlar zamanı müştəri virtual maşınlarına nə olacağını görək. Ən yüngül variantlardan başlayaq və ən ciddisi ilə bitirək - bütün saytın uğursuzluğu. Nümunələrdə əsas platforma OST olacaq və məlumat replikaları ilə ehtiyat platforma NORD olacaq.
Əgər...
Replikasiya Linki uğursuz oldu. İki saytın saxlama sistemləri arasında təkrarlama dayanır.
ESXi yalnız yerli disk cihazları ilə işləyəcək (optimal yollar vasitəsilə).
Virtual maşınlar işləməyə davam edir.
ISL (İnter-Switch Link) pozulur. Dava çətin ki. Əgər hansısa çılğın ekskavator müstəqil marşrutlarla işləyən və müxtəlif girişlər vasitəsilə sahələrə gətirilən bir neçə optik marşrutu bir anda qazmasa. Lakin hər halda. Bu halda, ESXi hostları yolların yarısını itirir və yalnız yerli yaddaş sistemlərinə daxil ola bilirlər. Replikalar toplanır, lakin hostlar onlara daxil ola bilməyəcək.
Virtual maşınlar normal işləyir.
Saytlardan birində SAN keçidi uğursuz oldu. ESXi hostları saxlama sisteminə gedən bəzi yolları itirir. Bu halda, keçidin uğursuz olduğu saytdakı hostlar yalnız HBA-larından biri ilə işləyəcəklər.
Virtual maşınlar normal işləməyə davam edir.
Saytlardan birində bütün SAN açarları uğursuz olur. Tutaq ki, OST saytında belə bir fəlakət baş verdi. Bu halda, bu saytdakı ESXi hostları disk cihazlarına gedən bütün yolları itirəcək. Standart VMware vSphere HA mexanizmi işə düşür: o, NORD-da OST saytının bütün virtual maşınlarını maksimum 140 saniyə ərzində yenidən işə salacaq.
NORD sayt hostlarında işləyən virtual maşınlar normal işləyir.
ESXi hostu bir saytda uğursuz olur. Burada vSphere HA mexanizmi yenidən işləyir: uğursuz hostdan virtual maşınlar digər hostlarda - eyni və ya uzaq saytda yenidən işə salınır. Virtual maşının yenidən başlama vaxtı 1 dəqiqəyə qədərdir.
OST saytındakı bütün ESXi hostları uğursuz olarsa, heç bir seçim yoxdur: VM-lər başqa birində yenidən işə salınır. Yenidən başlama vaxtı eynidir.
Saxlama sistemi bir saytda uğursuz olur. Deyək ki, saxlama sistemi OST saytında uğursuz oldu. Sonra OST saytının ESXi hostları NORD-da saxlama replikaları ilə işləməyə keçirlər. Uğursuz saxlama sistemi xidmətə qayıtdıqdan sonra məcburi təkrarlama baş verəcək və ESXi OST hostları yenidən yerli yaddaş sisteminə daxil olmağa başlayacaq.
Virtual maşınlar bütün bu müddət ərzində normal işləyir.
Saytlardan biri uğursuz oldu. Bu halda, bütün virtual maşınlar vSphere HA mexanizmi vasitəsilə ehtiyat saytda yenidən işə salınacaq. VM-nin yenidən başlama vaxtı 140 saniyədir. Bu halda, virtual maşının bütün şəbəkə parametrləri saxlanacaq və o, şəbəkə üzərindən müştəri üçün əlçatan qalır.
Ehtiyat saytda maşınların yenidən işə salınmasının rəvan getməsini təmin etmək üçün hər bir sayt yalnız yarısı doludur. İkinci yarı, bütün virtual maşınların ikinci, zədələnmiş saytdan hərəkət etməsi halında ehtiyatdır.
İki məlumat mərkəzinə əsaslanan fəlakətə davamlı bulud bu cür uğursuzluqlardan qoruyur.
Bu zövq ucuz deyil, çünki əsas resurslara əlavə olaraq ikinci saytda ehtiyat lazımdır. Buna görə də, biznes üçün kritik xidmətlər belə bir buludda yerləşdirilir, uzunmüddətli fasilələr böyük maliyyə və reputasiya itkilərinə səbəb olur və ya məlumat sistemi tənzimləyicilərin və ya şirkət daxili qaydaların fəlakətlərə davamlılıq tələblərinə tabedir.
Mənbə:
Mənbə: www.habr.com