Halló, Habr lesendur! Í síðustu grein ræddum við um einfalda leið til að endurheimta hörmungar í AERODISK ENGINE geymslukerfum - afritun. Í þessari grein munum við kafa inn í flóknara og áhugaverðara efni - Metrocluster, það er leið til sjálfvirkrar hamfaraverndar fyrir tvær gagnaver, sem gerir gagnaverum kleift að starfa í virkum virkum ham. Við munum segja þér það, sýna þér, brjóta það og laga það.
Eins og venjulega, kenning fyrst
Metrocluster er þyrping sem dreifist yfir nokkra staði innan borgar eða svæðis. Orðið „þyrping“ gefur okkur greinilega vísbendingu um að flókið sé sjálfvirkt, það er að skipta um þyrpingahnúta ef bilanir eiga sér stað sjálfkrafa.
Þetta er þar sem aðalmunurinn á Metrocluster og venjulegri afritun liggur. Sjálfvirkni í rekstri. Það er að segja, ef tiltekin atvik verða (bilun í gagnaveri, bilaðar rásir osfrv.), mun geymslukerfið sjálfstætt framkvæma nauðsynlegar aðgerðir til að viðhalda aðgengi gagna. Þegar venjulegar eftirmyndir eru notaðar eru þessar aðgerðir framkvæmdar handvirkt að hluta eða öllu leyti af stjórnanda.
Hvað þýðir það að gera?
Meginmarkmiðið sem viðskiptavinir sækjast eftir þegar þeir nota ákveðnar Metrocluster útfærslur er að lágmarka RTO (Recovery Time Objective). Það er að segja að lágmarka endurheimtartíma upplýsingatækniþjónustu eftir bilun. Ef þú notar venjulega afritun verður batatíminn alltaf lengri en batatíminn með metróþyrpingu. Hvers vegna? Mjög einfalt. Stjórnandinn verður að vera við skrifborðið sitt og skipta um afritun handvirkt og Metrocluster gerir þetta sjálfkrafa.
Ef þú ert ekki með sérstakan stjórnanda á vakt sem sefur ekki, borðar ekki, reykir ekki eða veikist og fylgist með ástandi geymslukerfisins allan sólarhringinn, þá er engin leið að tryggja að stjórnandinn muni vera tiltæk fyrir handvirka skiptingu meðan á bilun stendur.
Í samræmi við það mun RTO í fjarveru Metrocluster eða ódauðlegan stjórnanda á 99. stigi vaktþjónustu stjórnanda vera jöfn summan af skiptitíma allra kerfa og hámarkstíma eftir sem stjórnandi er tryggður að byrja að vinna með geymslukerfum og tengdum kerfum.
Þannig komumst við að þeirri augljósu niðurstöðu að nota ætti metróþyrpinguna ef krafan um RTO er mínútur, ekki klukkustundir eða dagar. Það er þegar í verstu bilun í gagnaveri verður upplýsingatæknideild að útvega fyrirtækinu tíma til að endurheimta aðgang að upplýsingatækniþjónustu innan nokkurra mínútna, eða jafnvel sekúndna.
Hvernig virkar það?
Á neðra stigi notar Metrocluster vélbúnaður fyrir samstillta afritun gagna, sem við lýstum í fyrri grein (sjá. ). Þar sem afritun er samstillt eru kröfurnar fyrir hana samsvarandi, eða öllu heldur:
- ljósleiðarar sem eðlisfræði, 10 gígabit Ethernet (eða hærra);
- fjarlægðin milli gagnavera er ekki meira en 40 kílómetrar;
- töf á sjónrásum milli gagnavera (milli geymslukerfa) er allt að 5 millisekúndur (best 2).
Allar þessar kröfur eru í eðli sínu ráðgefandi, það er að segja að metróþyrpingin mun virka jafnvel þó að þessar kröfur séu ekki uppfylltar, en við verðum að skilja að afleiðingar þess að ekki sé farið að þessum kröfum jafngilda því að rekstur beggja geymslukerfa hægist á. metróþyrpingin.
Svo er samstillt eftirlíking notuð til að flytja gögn á milli geymslukerfa og hvernig skipta eftirlíkingar sjálfkrafa og, síðast en ekki síst, hvernig á að forðast skiptan heila? Til að gera þetta, á hærra stigi, er viðbótareining notuð - gerðarmaður.
Hvernig starfar gerðarmaður og hvert er verkefni hans?
Dómarinn er lítil sýndarvél eða vélbúnaðarklasi sem verður að ræsa á þriðju síðu (til dæmis á skrifstofu) og veita aðgang að geymslukerfinu í gegnum ICMP og SSH. Eftir ræsingu ætti dómarinn að stilla IP og síðan frá geymsluhliðinni tilgreina heimilisfang þess, auk heimilisföng fjarstýringa sem taka þátt í Metrocluster. Eftir þetta er dómarinn tilbúinn til starfa.
Dómarinn fylgist stöðugt með öllum geymslukerfum í stórþyrpingunni og ef tiltekið geymslukerfi er ekki tiltækt, eftir að hafa staðfest að annar meðlimur klasans sé ekki tiltækur (eitt af „lifandi“ geymslukerfum), ákveður hann að hefja aðferðina til að skipta um afritunarreglur og kortlagningu.
Mjög mikilvægt atriði. Gerðardómari verður alltaf að vera staðsettur á öðrum stað en þeim sem geymslukerfin eru staðsett á, það er hvorki í gagnaveri 1, þar sem geymslukerfi 1 er uppsett, né í gagnaveri 2, þar sem geymslukerfi 2 er uppsett.
Hvers vegna? Vegna þess að þetta er eina leiðin sem gerðarmaður getur, með hjálp eins af eftirlifandi geymslukerfum, á ótvíræðan og nákvæman hátt ákvarðað fall einhverra tveggja staða þar sem geymslukerfin eru sett upp. Allar aðrar aðferðir við að setja dómara geta leitt til klofna heila.
Nú skulum við kafa ofan í smáatriðin í starfi gerðardómsmannsins.
Dómarinn rekur nokkrar þjónustur sem skoða stöðugt alla geymslustýringa. Ef niðurstaða skoðanakönnunar er frábrugðin þeirri fyrri (tiltæk/ótiltæk), þá er hún skráð í lítinn gagnagrunn, sem virkar einnig á úrskurðaraðila.
Við skulum skoða rökfræði vinnu gerðardómsmannsins nánar.
Skref 1: Ákvarða óaðgengi. Bilunartilvik í geymslukerfi er skortur á ping frá báðum stjórnendum sama geymslukerfis innan 5 sekúndna.
Skref 2. Byrjaðu skiptiferlið. Eftir að dómarinn hefur áttað sig á því að eitt af geymslukerfunum er ekki tiltækt sendir hann beiðni til „lifandi“ geymslukerfisins til að ganga úr skugga um að „dauðu“ geymslukerfið sé raunverulega dautt.
Eftir að hafa fengið slíka skipun frá úrskurðaraðilanum, athugar annað (lifandi) geymslukerfið að auki hvort hið fallna fyrsta geymslukerfi sé tiltækt og, ef það er ekki til staðar, sendir það staðfestingu til úrskurðaraðila um ágiskun sína. Geymslukerfið er örugglega ekki tiltækt.
Eftir að hafa fengið slíka staðfestingu, ræsir dómarinn fjarstýringu til að skipta um afritun og hækka kortlagningu á þeim eftirmyndum sem voru virkar (aðal) á fallna geymslukerfinu, og sendir skipun til annars geymslukerfisins um að breyta þessum eftirmyndum úr auka- í aðal- og hækka kortlagningu. Jæja, annað geymslukerfið framkvæmir í samræmi við það þessar aðgerðir og veitir síðan aðgang að týndu LUN frá sjálfu sér.
Hvers vegna er þörf á frekari sannprófun? Fyrir ályktun. Það er, meirihluti af heildar staka (3) fjölda klasameðlima verður að staðfesta fall eins af klasahnútunum. Aðeins þá verður þessi ákvörðun örugglega rétt. Þetta er nauðsynlegt til að forðast rangar skiptingar og þar af leiðandi klofna heila.
Tímaskref 2 tekur um það bil 5 - 10 sekúndur, þannig, að teknu tilliti til þess tíma sem þarf til að ákvarða óaðgengi (5 sekúndur), innan 10 - 15 sekúndna eftir slysið, verða LUN frá fallnu geymslukerfinu sjálfkrafa tiltæk til að vinna með lifandi geymslukerfi.
Það er ljóst að til að forðast að missa tengingar við hýsingaraðila þarftu líka að gæta þess að stilla tímamörk rétt á hýsingunum. Ráðlagður tími er að minnsta kosti 30 sekúndur. Þetta kemur í veg fyrir að gestgjafinn rjúfi tenginguna við geymslukerfið meðan á álagsskiptum stendur ef hamfarir verða og getur tryggt að engar I/O truflanir séu.
Bíddu aðeins, það kemur í ljós að ef allt er svona gott með metróþyrpinguna, hvers vegna þurfum við þá yfirleitt reglulega afritun?
Í raun og veru er allt ekki svo einfalt.
Við skulum íhuga kosti og galla Metrocluster
Svo komumst við að því að augljósir kostir Metrocluster samanborið við hefðbundna afritun eru:
- Full sjálfvirkni, sem tryggir lágmarks batatíma ef hamfarir verða;
- Það er allt og sumt :-).
Og nú, athygli, gallarnir:
- Kostnaður við lausn. Þrátt fyrir að metróþyrpingin í Aerodisk kerfum þurfi ekki viðbótarleyfi (sama leyfi er notað og fyrir eftirmyndina) verður kostnaðurinn við lausnina enn meiri en að nota samstillta afritun. Þú þarft að innleiða allar kröfur fyrir samstillta eftirmynd, auk kröfurnar fyrir stórþyrpinguna sem tengist viðbótarskipti og viðbótarsvæði (sjá skipulagning stórþyrpingar);
- Flækjustig lausnarinnar. Metroþyrpingin er miklu flóknari en venjuleg eftirmynd og krefst miklu meiri athygli og fyrirhafnar við skipulagningu, uppsetningu og skjöl.
Að lokum. Metrocluster er vissulega mjög tæknilega háþróuð og góð lausn þegar þú þarft virkilega að útvega RTO á nokkrum sekúndum eða mínútum. En ef það er ekkert slíkt verkefni, og RTO í klukkustundum er í lagi fyrir viðskipti, þá þýðir ekkert að skjóta spörva úr fallbyssu. Venjuleg afritun verkamanna og bænda er nægjanleg, þar sem neðanjarðarþyrping mun valda aukakostnaði og flækju í upplýsingatækniinnviðum.
Metrocluster skipulagning
Þessi kafli segist ekki vera ítarleg leiðarvísir um hönnun stórþyrpinga, heldur sýnir aðeins helstu leiðbeiningar sem ætti að vinna ef þú ákveður að byggja slíkt kerfi. Þess vegna, þegar þú innleiðir metróþyrping í raun, vertu viss um að taka þátt í geymslukerfisframleiðandanum (þ.e. okkur) og öðrum tengdum kerfum til samráðs.
Staðir
Eins og fram kemur hér að ofan, þarf stórþyrping að lágmarki þrjár staði. Tvö gagnaver þar sem geymslukerfi og tengd kerfi verða starfrækt, auk þriðju síðunnar þar sem gerðarmaður mun starfa.
Ráðlögð fjarlægð milli gagnavera er ekki meira en 40 kílómetrar. Stærri vegalengd er mjög líkleg til að valda frekari töfum, sem þegar um stórþyrping er að ræða eru afar óæskilegar. Minnum á að tafir ættu að vera allt að 5 millisekúndur, þó ráðlegt sé að halda þeim innan 2.
Mælt er með því að athuga tafir einnig á meðan á skipulagsferlinu stendur. Sérhver meira og minna þroskaður veitandi sem útvegar ljósleiðara á milli gagnavera getur skipulagt gæðaeftirlit nokkuð fljótt.
Hvað varðar tafir fyrir gerðardómara (þ.e. á milli þriðju síðunnar og þeirra fyrstu tveggja), þá er ráðlagður tafaþröskuldur allt að 200 millisekúndur, það er að segja að venjuleg VPN-tenging fyrirtækja í gegnum internetið hentar.
Skipti og netkerfi
Ólíkt afritunarkerfinu, þar sem nóg er að tengja geymslukerfi frá mismunandi stöðum, krefst Metrocluster kerfisins að gestgjafar séu tengdir við bæði geymslukerfin á mismunandi stöðum. Til að gera það skýrara hver munurinn er eru bæði kerfin sýnd hér að neðan.
Eins og sést á skýringarmyndinni skoða gestgjafar síðu 1 bæði geymslukerfi 1 og geymslukerfi 2. Einnig, þvert á móti, skoða gestgjafar síðu 2 bæði geymslukerfi 2 og geymslukerfi 1. Það er, hver gestgjafi sér bæði geymslukerfin. Þetta er forsenda fyrir rekstri stórklasans.
Auðvitað er engin þörf á að tengja hvern gestgjafa með ljóssnúru við aðra gagnaver; engin tengi eða snúrur duga. Allar þessar tengingar verða að vera í gegnum Ethernet 10G+ eða FibreChannel 8G+ rofa (FC er aðeins til að tengja vélar og geymslukerfi fyrir IO, afritunarrásin er sem stendur aðeins tiltæk í gegnum IP (Ethernet 10G+).
Nú nokkur orð um svæðisfræði netkerfisins. Mikilvægt atriði er rétt uppsetning undirneta. Nauðsynlegt er að skilgreina strax nokkur undirnet fyrir eftirfarandi tegundir umferðar:
- Undirnet afritunar sem gögn verða samstillt á milli geymslukerfa. Það geta verið nokkrir af þeim, í þessu tilfelli skiptir það ekki máli, það veltur allt á núverandi (þegar innleitt) netkerfi. Ef þeir eru tveir, þá verður augljóslega að stilla leið á milli þeirra;
- Geymsluundirnet þar sem vélar munu fá aðgang að geymsluauðlindum (ef það er iSCSI). Það ætti að vera eitt slíkt undirnet í hverju gagnaveri;
- Stjórna undirnetum, það er þremur leiðanlegum undirnetum á þremur stöðum sem geymslukerfum er stýrt frá, og þar er einnig úrskurðaraðilinn staðsettur.
Við lítum ekki á undirnet fyrir aðgang að hýsingarauðlindum hér, þar sem þau eru mjög háð verkefnum.
Að aðskilja mismunandi umferð í mismunandi undirnet er afar mikilvægt (sérstaklega mikilvægt er að aðgreina eftirmyndina frá I/O), því ef þú blandar allri umferð í eitt „þykkt“ undirnet, þá verður ómögulegt að stjórna þessari umferð, og í aðstæður tveggja gagnavera getur þetta samt valdið mismunandi netárekstri. Við munum ekki kafa djúpt í þetta mál innan ramma þessarar greinar, þar sem þú getur lesið um skipulagningu nets sem teygt er á milli gagnavera á auðlindum netbúnaðarframleiðenda, þar sem þessu er lýst í smáatriðum.
Gerðardómsstillingar
Dómarinn verður að veita aðgang að öllum stjórnunarviðmótum geymslukerfisins í gegnum ICMP og SSH samskiptareglur. Þú ættir líka að hugsa um bilunaröryggi dómarans. Hér er blæbrigði.
Arbiter failover er mjög æskilegt, en ekki krafist. Hvað gerist ef dómarinn hrynur á röngum tíma?
- Rekstur Metrocluster í venjulegum ham mun ekki breytast, vegna þess arbtir hefur nákvæmlega engin áhrif á rekstur Metrocluster í venjulegum ham (verkefni þess er að skipta álagi á milli gagnavera tímanlega)
- Þar að auki, ef dómarinn af einni eða annarri ástæðu dettur og „sefur í gegnum“ slys í gagnaverinu, þá mun engin skipting eiga sér stað, vegna þess að það verður enginn til að gefa nauðsynlegar skiptingarskipanir og skipuleggja ályktun. Í þessu tilviki mun metróþyrpingin breytast í venjulegt kerfi með afritun, sem verður að skipta handvirkt á meðan á hörmung stendur, sem mun hafa áhrif á RTO.
Hvað leiðir af þessu? Ef þú þarft virkilega að tryggja lágmarks RTO þarftu að tryggja að gerðarmaðurinn sé bilunarþolinn. Það eru tveir valkostir fyrir þetta:
- Ræstu sýndarvél með úrskurðaraðila á bilunarþolnum hypervisor, sem betur fer styðja allir fullorðnir hypervisorar bilanaþol;
- Ef þú ert of latur á þriðju staðnum (á hefðbundinni skrifstofu) til að setja upp venjulegan klasa og það er enginn fyrirliggjandi hypervozor klasi, þá höfum við útvegað vélbúnaðarútgáfu af úrskurðarmanninum, sem er gerð í 2U kassa þar sem tveir venjulegir x-86 netþjónar virka og geta lifað staðbundna bilun af.
Við mælum eindregið með því að tryggja bilanaþol úrskurðarmannsins, þrátt fyrir að metróþyrpingin þurfi það ekki í venjulegri stillingu. En eins og bæði kenningin og framkvæmdin sýna, ef þú byggir upp sannarlega áreiðanlega hörmungarþéttan innviði, þá er betra að spila það öruggt. Það er betra að vernda sjálfan þig og fyrirtæki þitt gegn „lögmáli illsku“, það er að segja gegn bilun bæði gerðardómsmannsins og einnar af þeim stöðum þar sem geymslukerfið er staðsett.
Lausnararkitektúr
Miðað við kröfurnar hér að ofan fáum við eftirfarandi almenna lausnararkitektúr.
LUN ætti að vera jafnt dreift á tvo staði til að forðast alvarlega ofhleðslu. Á sama tíma, þegar þú stærðir í báðum gagnaverum, ættir þú ekki aðeins að taka með tvöfalt rúmmál (sem er nauðsynlegt til að geyma gögn samtímis á tveimur geymslukerfum), heldur einnig tvöfalda afköst í IOPS og MB/s til að koma í veg fyrir niðurbrot forrita í ef bilun verður í einu af gagnaverunum ov.
Sérstaklega tökum við fram að með réttri nálgun við stærðarstærð (þ.e. að því gefnu að við höfum útvegað rétt efri mörk IOPS og MB/s, auk nauðsynlegra örgjörva og vinnsluminni), ef eitt af geymslukerfum í Metro þyrping mistekst, það verður ekki alvarleg lækkun á frammistöðu við aðstæður tímabundið starf á einu geymslukerfi.
Þetta skýrist af þeirri staðreynd að þegar tvær síður eru í gangi samtímis, „borðar“ samstillt afritun helminginn af skrifafköstum, þar sem hver færslu verður að skrifa á tvö geymslukerfi (svipað og RAID-1/10). Þannig að ef eitt af geymslukerfunum bilar hverfa áhrif afritunar tímabundið (þar til bilaða geymslukerfið batnar) og við fáum tvöfalda aukningu á skrifafköstum. Eftir að LUNs bilaða geymslukerfisins eru endurræst á virka geymslukerfinu hverfur þessi tvöföldun aukning vegna þess að álag kemur frá LUNs hins geymslukerfisins og við förum aftur í sama afköst og við höfðum áður en „fall“, en aðeins innan ramma einnar síðu.
Með hjálp hæfrar stærðargreiningar geturðu tryggt aðstæður þar sem notendur munu alls ekki finna fyrir bilun í heilu geymslukerfi. En við endurtökum enn og aftur, þetta krefst mjög varkárrar stærðar, sem þú getur haft samband við okkur ókeypis :-).
Að setja upp Metrocluster
Að setja upp stórþyrping er mjög svipað því að setja upp venjulega afritun, sem við lýstum í . Þess vegna skulum við einblína aðeins á muninn. Við settum upp bekk á rannsóknarstofunni byggt á arkitektúrnum hér að ofan, aðeins í lágmarksútgáfu: tvö geymslukerfi tengd í gegnum 10G Ethernet, tvo 10G rofa og einn gestgjafi sem lítur í gegnum rofana á bæði geymslukerfin með 10G tengi. Dómarinn keyrir á sýndarvél.
Þegar þú stillir sýndar-IP (VIP) fyrir eftirmynd ættirðu að velja VIP-gerðina - fyrir stórþyrping.
Við bjuggum til tvo afritunartengla fyrir tvö LUN og dreifðum þeim á tvö geymslukerfi: LUN TEST Primary á geymslukerfi 1 (METRO hlekkur), LUN TEST2 Primary fyrir geymslukerfi 2 (METRO2 hlekkur).
Fyrir þá stilltum við tvö eins markmið (í okkar tilfelli iSCSI, en FC er líka studd, uppsetningarrökfræðin er sú sama).
Geymslukerfi 1:
Geymslukerfi 2:
Fyrir afritunartengingar voru gerðar kortlagningar á hverju geymslukerfi.
Geymslukerfi 1:
Geymslukerfi 2:
Við settum upp multipath og kynntum það fyrir gestgjafanum.
Að setja upp gerðardómara
Þú þarft ekki að gera neitt sérstakt við úrskurðarmanninn sjálfan; þú þarft bara að virkja hann á þriðju síðunni, gefa honum IP og stilla aðgang að honum í gegnum ICMP og SSH. Uppsetningin sjálf er framkvæmd úr geymslukerfunum sjálfum. Í þessu tilviki er nóg að stilla úrskurðarmanninn einu sinni á einhverjum af geymslustýringum í metróþyrpunni; þessar stillingar verða sjálfkrafa dreift til allra stjórnenda.
Í hlutanum Fjarafritun>> Metrocluster (á hvaða stýri sem er) >> hnappinn „Stilla“.
Við sláum inn IP gerðardómarans, sem og stjórnviðmót tveggja fjarstýringa.
Eftir þetta þarftu að virkja alla þjónustu (hnappurinn „Endurræstu allt“). Ef endurstillt er í framtíðinni verður að endurræsa þjónustu til að stillingarnar taki gildi.
Við athugum hvort öll þjónusta sé í gangi.
Þetta lýkur uppsetningu Metrocluster.
Hrunpróf
Árekstursprófið í okkar tilviki verður frekar einfalt og hratt þar sem fjallað var um afritunarvirkni (rofa, samkvæmni osfrv.) . Þess vegna, til að prófa áreiðanleika metróþyrpingarinnar, er nóg fyrir okkur að athuga sjálfvirkni bilunarskynjunar, skipta og fjarveru skráningartaps (I/O stöðva).
Til að gera þetta líkjum við eftir algjörri bilun í öðru geymslukerfunum með því að slökkva líkamlega á báðum stýrikerfum þess, eftir að hafa byrjað að afrita stóra skrá yfir á LUN, sem verður að virkja á hinu geymslukerfinu.
Slökktu á einu geymslukerfi. Á öðru geymslukerfinu sjáum við tilkynningar og skilaboð í loggunum um að tengingin við nágrannakerfið hafi rofnað. Ef tilkynningar í gegnum SMTP eða SNMP vöktun eru stilltar mun stjórnandinn fá samsvarandi tilkynningar.
Nákvæmlega 10 sekúndum síðar (sýnilegt á báðum skjámyndum) varð METRO afritunartengingin (sú sem var Primary á bilaða geymslukerfinu) sjálfkrafa að Primary á virka geymslukerfinu. Með því að nota núverandi kortlagningu var LUN TEST áfram í boði fyrir gestgjafann, upptakan dýfði aðeins (innan 10 prósenta sem lofað var), en var ekki rofin.
Prófinu lauk með góðum árangri.
Samantekt
Núverandi útfærsla á metróþyrpingunni í AERODISK Engine N-röð geymslukerfum gerir að fullu kleift að leysa vandamál þar sem nauðsynlegt er að útrýma eða lágmarka niður í miðbæ fyrir upplýsingatækniþjónustu og tryggja rekstur þeirra 24/7/365 með lágmarks launakostnaði.
Við getum auðvitað sagt að allt sé þetta kenning, kjöraðstæður á rannsóknarstofu og svo framvegis... EN við erum með fjölda útfærðra verkefna þar sem við höfum innleitt hörmungarþolsvirkni og kerfin virka fullkomlega. Einn af nokkuð þekktum viðskiptavinum okkar, sem notar aðeins tvö geymslukerfi í hamfaraheldri uppsetningu, hefur þegar samþykkt að birta upplýsingar um verkefnið, svo í næsta hluta munum við tala um bardagaútfærsluna.
Þakka þér, við hlökkum til árangursríkrar umræðu.
Heimild: www.habr.com