Hei Habr!
Uudenvuoden lomien jälkeen lanseerasimme uudelleen katastrofikestävän pilven, joka perustuu kahteen paikkaan. Tänään kerromme sinulle, kuinka se toimii, ja näytämme, mitä tapahtuu asiakasvirtuaalikoneille, kun klusterin yksittäiset elementit epäonnistuvat ja koko sivusto kaatuu (spoileri - kaikki on kunnossa niiden kanssa).
Katastrofinkestävä pilvitallennusjärjestelmä OST-sivustolla.
Mitä sisällä on
Konepellin alla klusterissa on Cisco UCS -palvelimia VMware ESXi -hypervisorilla, kaksi INFINIDAT InfiniBox F2240 -tallennusjärjestelmää, Cisco Nexus -verkkolaitteet sekä Brocade SAN -kytkimet. Klusteri on jaettu kahteen paikkaan - OST ja NORD, eli jokaisessa konesalissa on identtiset laitteet. Itse asiassa tämä tekee siitä katastrofikestävän.
Yhdessä sivustossa pääelementit ovat myös päällekkäisiä (isännät, SAN-kytkimet, verkko).
Nämä kaksi paikkaa on yhdistetty erillisillä valokuitureiteillä, jotka myös varatut.
Muutama sana säilytysjärjestelmistä. Rakensimme ensimmäisen version katastrofikestävästä pilvestä NetAppiin. Tässä valitsimme INFINIDATin, ja tässä on syy:
- Aktiivinen-aktiivinen replikointivaihtoehto. Sen avulla virtuaalikone pysyy toimintakunnossa, vaikka jokin tallennusjärjestelmistä epäonnistuisi kokonaan. Kerron sinulle lisää replikaatiosta myöhemmin.
- Kolme levyohjainta järjestelmän vikasietoisuuden lisäämiseksi. Yleensä niitä on kaksi.
- Valmis ratkaisu. Saimme valmiiksi kootun telineen, joka pitää vain liittää verkkoon ja konfiguroida.
- Huomaavainen tekninen tuki. INFINIDAT-insinöörit analysoivat jatkuvasti tallennusjärjestelmän lokeja ja tapahtumia, asentavat uusia laiteohjelmistoversioita ja auttavat määrityksessä.
Tässä kuvia pakkauksen purkamisesta:
Miten se toimii
Pilvi on jo itsessään vikasietoinen. Se suojaa asiakasta yksittäisiltä laitteisto- ja ohjelmistovikoilta. Katastrofinkestävä auttaa suojaamaan massiivisia vikoja vastaan yhden sivuston sisällä: esimerkiksi tallennusjärjestelmän (tai SDS-klusterin, jota tapahtuu melko usein 🙂), suurilta virheiltä tallennusverkossa jne. No, ja mikä tärkeintä: tällainen pilvi säästää, kun koko sivusto on saavuttamattomissa tulipalon, sähkökatkon, raider-vallankaappauksen tai muukalaisten laskeutumisen vuoksi.
Kaikissa näissä tapauksissa asiakkaan virtuaalikoneet jatkavat toimintaansa, ja tässä on syy.
Klusterimalli on suunniteltu siten, että mikä tahansa ESXi-isäntä, jossa on asiakkaan virtuaalikoneita, voi käyttää mitä tahansa kahdesta tallennusjärjestelmästä. Jos OST-sivuston tallennusjärjestelmä epäonnistuu, virtuaalikoneet jatkavat toimintaansa: isännät, joissa niitä käytetään, käyttävät NORDin tallennusjärjestelmää dataa varten.
Tältä klusterin kytkentäkaavio näyttää.
Tämä on mahdollista johtuen siitä, että kahden paikan SAN-kankaiden välille on määritetty Inter-Switch Link: Fabric A OST SAN -kytkin on kytketty Fabric A NORD SAN -kytkimeen ja vastaavasti Fabric B SAN -kytkimiin.
No, jotta kaikki nämä SAN-tehtaiden monimutkaisuudet olisivat järkeviä, Active-Active replikointi on määritetty kahden tallennusjärjestelmän välille: tiedot kirjoitetaan lähes samanaikaisesti paikalliseen ja etätallennusjärjestelmään, RPO = 0. Osoittautuu, että alkuperäiset tiedot on tallennettu yhteen tallennusjärjestelmään ja sen kopio on tallennettu toiseen. Tiedot kopioidaan tallennustaltioiden tasolla, ja VM-tiedot (sen levyt, asetustiedosto, swap-tiedosto jne.) tallennetaan niille.
ESXi-isäntä näkee ensisijaisen taltion ja sen replikan yhtenä levylaitteena (tallennuslaitteena). ESXi-isännästä kuhunkin levylaitteeseen on 24 polkua:
12 polkua yhdistää sen paikalliseen tallennusjärjestelmään (optimaaliset polut) ja loput 12 etätallennusjärjestelmää (ei-optimaaliset polut). Normaalissa tilanteessa ESXi käyttää paikallisen tallennusjärjestelmän tietoja "optimaalisia" polkuja käyttäen. Kun tämä tallennusjärjestelmä epäonnistuu, ESXi menettää optimaaliset polut ja vaihtaa "ei-optimaalisiin". Tältä se näyttää kaaviossa.
Katastrofikestävän klusterin kaava.
Kaikki asiakasverkot on yhdistetty molempiin kohteisiin yhteisen verkkorakenteen kautta. Jokaisella sivustolla on Provider Edge (PE), johon asiakkaan verkot päätetään. PE:t yhdistyvät yhteiseksi klusteriksi. Jos PE epäonnistuu yhdessä paikassa, kaikki liikenne ohjataan toiseen sivustoon. Tämän ansiosta ilman PE:tä jääneet sivuston virtuaalikoneet pysyvät verkon kautta asiakkaan käytettävissä.
Katsotaan nyt, mitä tapahtuu asiakasvirtuaalikoneille erilaisten vikojen aikana. Aloitetaan kevyimmistä vaihtoehdoista ja lopetetaan vakavimpaan - koko sivuston epäonnistumiseen. Esimerkeissä pääalusta on OST ja varmuuskopioalusta datakopioineen on NORD.
Mitä tapahtuu asiakkaan virtuaalikoneelle, jos...
Replikointilinkki epäonnistuu. Replikointi kahden sivuston tallennusjärjestelmien välillä pysähtyy.
ESXi toimii vain paikallisten levylaitteiden kanssa (optimaalisten polkujen kautta).
Virtuaalikoneet jatkavat toimintaansa.
ISL (Inter-Switch Link) katkeaa. Epätodennäköinen tapahtuma. Ellei joku hullu kaivinkone kaivaa useita optisia reittejä kerralla, jotka kulkevat itsenäisiä reittejä ja tuodaan työmaille eri tulojen kautta. Mutta joka tapauksessa. Tässä tapauksessa ESXi-isännät menettävät puolet poluista ja voivat käyttää vain paikallisia tallennusjärjestelmiään. Kopioita kerätään, mutta isännät eivät voi käyttää niitä.
Virtuaalikoneet toimivat normaalisti.
SAN-kytkin epäonnistuu yhdessä sivustoista. ESXi-isännät menettävät osan polkuista tallennusjärjestelmään. Tässä tapauksessa sen sivuston isännät, jossa vaihto epäonnistui, toimivat vain yhden HBA:n kautta.
Virtuaalikoneet jatkavat toimintaansa normaalisti.
Kaikki yhden sivuston SAN-kytkimet epäonnistuvat. Oletetaan, että tällainen katastrofi tapahtui OST-sivustolla. Tässä tapauksessa tämän sivuston ESXi-isännät menettävät kaikki polut levylaitteisiinsa. Vakiomuotoinen VMware vSphere HA -mekanismi tulee käyttöön: se käynnistää uudelleen kaikki NORDin OST-sivuston virtuaalikoneet enintään 140 sekunnissa.
NORD-sivuston isännillä toimivat virtuaalikoneet toimivat normaalisti.
ESXi-isäntä epäonnistuu yhdessä sivustossa. Tässä vSphere HA -mekanismi toimii taas: epäonnistuneen isäntäkoneen virtuaalikoneet käynnistetään uudelleen muissa isännissä - samassa tai etäsivustossa. Virtuaalikoneen uudelleenkäynnistysaika on enintään 1 minuutti.
Jos kaikki OST-sivuston ESXi-isännät epäonnistuvat, vaihtoehtoja ei ole: VM:t käynnistetään uudelleen toisessa. Uudelleenkäynnistysaika on sama.
Varastointijärjestelmä epäonnistuu yhdessä paikassa. Oletetaan, että tallennusjärjestelmä epäonnistuu OST-sivustossa. Sitten OST-sivuston ESXi-isännät siirtyvät työskentelemään tallennuskopioiden kanssa NORDissa. Kun epäonnistunut tallennusjärjestelmä palaa palveluun, pakotettu replikointi tapahtuu ja ESXi OST -isännät alkavat jälleen käyttää paikallista tallennusjärjestelmää.
Virtuaalikoneet ovat toimineet normaalisti koko tämän ajan.
Yksi sivustoista epäonnistuu. Tässä tapauksessa kaikki virtuaalikoneet käynnistetään uudelleen varmuuskopiointisivustolla vSphere HA -mekanismin kautta. VM:n uudelleenkäynnistysaika on 140 sekuntia. Tässä tapauksessa kaikki virtuaalikoneen verkkoasetukset tallennetaan, ja se on edelleen asiakkaan käytettävissä verkon kautta.
Varmuuskopiointipaikan koneiden uudelleenkäynnistyksen sujuvuuden varmistamiseksi jokainen sivusto on vain puoliksi täynnä. Toinen puolisko on varaus siltä varalta, että kaikki virtuaalikoneet siirtyvät toisesta, vaurioituneesta sivustosta.
Katastrofin kestävä pilvi, joka perustuu kahteen palvelinkeskukseen, suojaa tällaisilta häiriöiltä.
Tämä ilo ei ole halpa, koska pääresurssien lisäksi tarvitaan varaus toiselle sivustolle. Siksi liiketoimintakriittiset palvelut sijoitetaan sellaiseen pilveen, jonka pitkäaikainen seisokki aiheuttaa suuria taloudellisia ja mainetappioita tai jos tietojärjestelmään kohdistuu viranomaisilta tai yrityksen sisäisiltä määräyksiltä katastrofikestävyysvaatimuksia.
Lähteet:
Lähde: will.com