Disaster Resilient Cloud: Hvernig það virkar

Hæ Habr!

Eftir áramótafríið endurræstum við hamfaraheldu skýi sem byggir á tveimur síðum. Í dag munum við segja þér hvernig það virkar og sýna hvað verður um sýndarvélar viðskiptavinar þegar einstakir þættir þyrpingarinnar bila og öll vefsvæðið hrynur (spilla - allt er í lagi með þær).

Disaster Resilient Cloud: Hvernig það virkar
Hamfaraþolið skýjageymslukerfi á OST síðunni.

Hvað er inni

Undir hettunni er þyrpingin með Cisco UCS netþjóna með VMware ESXi hypervisor, tvö INFINIDAT InfiniBox F2240 geymslukerfi, Cisco Nexus netbúnað, auk Brocade SAN rofa. Þyrpingin skiptist í tvær síður - OST og NORD, þ.e.a.s. hver gagnaver er með eins búnaðarsett. Reyndar er þetta það sem gerir það hamfaraþolið.

Innan einnar síðu eru helstu þættirnir einnig afritaðir (hýsingar, SAN rofar, netkerfi).
Þessir tveir staðir eru tengdir með sérstökum ljósleiðaraleiðum, einnig fráteknum.

Nokkur orð um geymslukerfi. Við smíðuðum fyrstu útgáfuna af hamfaraheldu skýi á NetApp. Hér völdum við INFINIDAT og hér er ástæðan:

  • Active-Active afritunarvalkostur. Það gerir sýndarvélinni kleift að vera starfhæfur jafnvel þótt eitt af geymslukerfunum bili algjörlega. Ég skal segja þér meira um afritun síðar.
  • Þrír diskastýringar til að auka bilanaþol kerfisins. Venjulega eru þær tvær.
  • Tilbúin lausn. Við fengum forsamsettan rekki sem þarf bara að tengja við netið og stilla.
  • Athyglisverð tækniaðstoð. Verkfræðingar INFINIDAT greina stöðugt geymslukerfisskrár og atburði, setja upp nýjar fastbúnaðarútgáfur og aðstoða við uppsetningu.

Hér eru nokkrar myndir frá upptökunni:

Disaster Resilient Cloud: Hvernig það virkar

Disaster Resilient Cloud: Hvernig það virkar

Hvernig það virkar

Skýið er nú þegar bilunarþolið innra með sér. Það verndar viðskiptavininn gegn stakum vélbúnaðar- og hugbúnaðarbilunum. Hamfaraþolinn mun hjálpa til við að verjast stórfelldum bilunum á einni síðu: til dæmis bilun í geymslukerfi (eða SDS þyrping, sem gerist nokkuð oft 🙂), stórfelldar villur í geymsluneti osfrv. Jæja, og síðast en ekki síst: slíkt ský bjargar þegar heil síða verður óaðgengileg vegna elds, myrkvunar, yfirtöku árásarmanna eða lendingar geimvera.

Í öllum þessum tilvikum halda sýndarvélar viðskiptavinarins áfram að virka og hér er ástæðan.

Klasahönnunin er hönnuð þannig að hvaða ESXi gestgjafi sem er með sýndarvélar viðskiptavinar geta nálgast hvaða geymslukerfi sem er. Ef geymslukerfið á OST-síðunni bilar munu sýndarvélarnar halda áfram að virka: vélarnar sem þær keyra á munu fá aðgang að geymslukerfinu á NORD fyrir gögn.

Disaster Resilient Cloud: Hvernig það virkar
Svona lítur tengingarmyndin í klasa út.

Þetta er mögulegt vegna þess að Inter-Switch Link er stilltur á milli SAN-efna þessara tveggja staða: Fabric A OST SAN rofinn er tengdur Fabric A NORD SAN rofanum og á sama hátt fyrir Fabric B SAN rofana.

Jæja, svo að allar þessar ranghala SAN verksmiðjur séu skynsamlegar, Active-Active afritun er stillt á milli geymslukerfanna tveggja: upplýsingar eru næstum samtímis skrifaðar á staðbundið og fjargeymslukerfi, RPO = 0. Það kemur í ljós að upprunalegu gögnin eru geymd á einu geymslukerfi og eftirmynd þeirra er geymd á hinu. Gögn eru afrituð á stigi geymslumagns og VM gögnin (diska þess, stillingarskrá, skiptaskrá osfrv.) eru geymd á þeim.

ESXi gestgjafinn sér aðalmagnið og eftirmynd þess sem eitt disktæki (geymslutæki). Það eru 24 slóðir frá ESXi vélinni til hvers diskstækis:

12 slóðir tengja það við staðbundið geymslukerfi (ákjósanlegar leiðir) og hinar 12 við fjargeymslukerfið (ekki ákjósanlegar leiðir). Í venjulegum aðstæðum hefur ESXi aðgang að gögnum á staðbundnu geymslukerfi með því að nota „ákjósanlegar“ slóðir. Þegar þetta geymslukerfi bilar missir ESXi ákjósanlegustu slóðir og skiptir yfir í „óhagkvæmar“. Svona lítur þetta út á skýringarmyndinni.

Disaster Resilient Cloud: Hvernig það virkar
Áætlun um hamfaraheldan klasa.

Öll net viðskiptavina eru tengd við báðar síðurnar í gegnum sameiginlegt netkerfi. Hver síða rekur Provider Edge (PE), þar sem netkerfi viðskiptavinarins er hætt. PE eru sameinuð í sameiginlegan klasa. Ef PE bilar á einum stað er allri umferð vísað á aðra síðuna. Þökk sé þessu eru sýndarvélar frá síðunni sem eru eftir án PE áfram aðgengilegar fyrir viðskiptavininn yfir netið.

Við skulum nú sjá hvað verður um sýndarvélar viðskiptavinar við ýmsar bilanir. Við skulum byrja á léttustu valkostunum og enda á þeim alvarlegustu - bilun á öllu síðunni. Í dæmunum verður aðalvettvangurinn OST og afritunarvettvangurinn, með eftirmyndum gagna, verður NORD.

Hvað verður um sýndarvél viðskiptavinarins ef...

Afritunartengill mistekst. Afritun milli geymslukerfa þessara tveggja stöðva hættir.
ESXi mun aðeins virka með staðbundnum diskatækjum (með bestu slóðum).
Sýndarvélar halda áfram að virka.

Disaster Resilient Cloud: Hvernig það virkar

ISL (Inter-Switch Link) bilar. Málið er ólíklegt. Nema einhver brjáluð gröfa grafi upp nokkrar sjónleiðir í einu, sem keyra á sjálfstæðum leiðum og eru fluttar á staðina í gegnum mismunandi inntak. En allavega. Í þessu tilviki missa ESXi gestgjafar helming slóðanna og geta aðeins nálgast staðbundin geymslukerfi sín. Eftirlíkingum er safnað, en gestgjafar munu ekki hafa aðgang að þeim.

Sýndarvélar virka venjulega.

Disaster Resilient Cloud: Hvernig það virkar

SAN rofinn bilar á einni af síðunum. ESXi gestgjafar missa nokkrar af leiðunum að geymslukerfinu. Í þessu tilviki munu vélar á staðnum þar sem rofinn mistókst aðeins virka í gegnum einn af HBA-tækjum sínum.

Sýndarvélarnar halda áfram að starfa eðlilega.

Disaster Resilient Cloud: Hvernig það virkar

Allir SAN rofar á einni af síðunum mistakast. Segjum að slík hörmung hafi átt sér stað á OST síðunni. Í þessu tilviki munu ESXi gestgjafar á þessari síðu missa allar slóðir að diskbúnaði sínum. Hið staðlaða VMware vSphere HA vélbúnaður kemur við sögu: hann mun endurræsa allar sýndarvélar OST-síðunnar í NORD á að hámarki 140 sekúndum.

Sýndarvélar sem keyra á NORD vefþjónum virka venjulega.

Disaster Resilient Cloud: Hvernig það virkar

ESXi gestgjafi bilar á einni síðu. Hér virkar vSphere HA vélbúnaðurinn aftur: sýndarvélar frá bilaða vélinni eru endurræstar á öðrum vélum - á sama eða fjarlægu vefsvæði. Endurræsingartími sýndarvélarinnar er allt að 1 mínúta.

Ef allir ESXi vélar á OST síðunni mistakast eru engir möguleikar: VM eru endurræst á öðrum. Endurræsingartími er sá sami.

Disaster Resilient Cloud: Hvernig það virkar

Geymslukerfið bilar á einum stað. Segjum að geymslukerfið bili á OST síðunni. Þá skipta ESXi gestgjafar OST síðunnar yfir í að vinna með geymslu eftirlíkingar í NORD. Eftir að bilaða geymslukerfið fer aftur í notkun mun þvinguð afritun eiga sér stað og ESXi OST vélar munu aftur byrja að fá aðgang að staðbundnu geymslukerfinu.

Sýndarvélar hafa virkað eðlilega allan þennan tíma.

Disaster Resilient Cloud: Hvernig það virkar

Ein af síðunum bilar. Í þessu tilviki verða allar sýndarvélar endurræstar á afritunarsíðunni í gegnum vSphere HA vélbúnaðinn. Endurræsingartími VM er 140 sekúndur. Í þessu tilviki verða allar netstillingar sýndarvélarinnar vistaðar og þær eru áfram aðgengilegar viðskiptavinum yfir netið.

Til að tryggja að endurræsing véla á varasíðunni gangi snurðulaust fyrir sig er hver síða aðeins hálffull. Seinni helmingurinn er varasjóður ef allar sýndarvélar færast frá seinni, skemmda staðnum.

Disaster Resilient Cloud: Hvernig það virkar

Hamfaraþolið ský byggt á tveimur gagnaverum verndar gegn slíkum bilunum.

Þessi ánægja er ekki ódýr, þar sem, auk helstu auðlinda, þarf varasjóð á annarri síðu. Þess vegna er viðskiptaþörf þjónusta sett í slíkt ský, þar sem langtíma niðritími sem veldur miklu fjárhagslegu og orðspori tapi, eða ef upplýsingakerfið er háð hörmungarþolskröfum frá eftirlitsaðilum eða innri reglugerðum fyrirtækisins.

Heimildir:

  1. www.infinidat.com/sites/default/files/resource-pdfs/DS-INFBOX-190331-US_0.pdf
  2. support.infinidat.com/hc/en-us/articles/207057109-InfiniBox-best-practices-guides

Heimild: www.habr.com

Bæta við athugasemd