Tere, Habr'i lugejad! Eelmises artiklis rääkisime lihtsatest katastroofialgatustest AERODISK ENGINE salvestussüsteemides – replikatsioonist. Selles artiklis süveneme keerukamasse ja huvitavasse teemasse – metroklaster, see tähendab automatiseeritud katastroofikaitse vahend kahtest andmekeskusest, mis võimaldab andmekeskustel töötada aktiivselt. Räägime, näitame, katki teeme ja parandame.
Nagu tavaliselt, alustame teooriast.
Metroklaster on klaster, mis on hajutatud mitmesse asukohta linnas või piirkonnas. Sõna 'klaster' vihjab selgelt sellele, et kompleks on automatiseeritud, st klastrite sõlmede vahetus häire korral (failover) toimub automaatselt.
Siin peitubki peamine erinevus metroklastri ja tavalise replikatsiooni vahel. Operatsioonide automatiseerimine. See tähendab, et erinevate probleemide (andmekeskuse rike, kanalite katkestamine jne) korral täidab salvestussüsteem iseseisvalt vajalikud toimingud andmete kättesaadavuse säilitamiseks. Tavaliste replikatsioonide korral täidab need toimingud täielikult või osaliselt administraator käsitsi.
Miks seda on vaja?
Peamine eesmärk, mida kliendid püüavad saavutada metroklastri erinevate rakenduste kasutamisel, on RTO (Taastusaegaeesmärk) minimeerimine. See tähendab, et minimeeritakse IT-teenuste taastamise aega pärast riket. Tavalise replikatsiooni korral on taastamisaeg alati pikem kui metroklastri korral. Miks? Väga lihtsalt. Administraator peab olema töökohal ja vahetama replikatsiooni käsitsi, samas kui metroklaster teeb seda automaatselt.
Kui teil pole pühendunud öise administraatori, kes ei maga, ei söö, ei suitseta ega haigestu, vaid jälgib 24/7 salvestussüsteemi seisundit, siis ei ole võimalik tagada, et administraator on saadaval käsitsi vahetamiseks rikke ajal.
Seetõttu on RTO metroklastri puudumisel või 99. taseme öise teenistuse administraatori puudumisel võrdne kogu süsteemide vahetamise aja ja maksimaalse ajavahemiku summaga, mille jooksul administraator garanteeritult alustab töötamist salvestussüsteemi ja sellega seotud süsteemidega.
Seega jõuame ilmsele järeldusele, et metrokloonitakse tuleks kasutada siis, kui RTO nõuded on minutid, mitte tunnid või päevad. See tähendab, et kõige hullemal juhul, kui andmesidekeskus (ЦОД) kukub kokku, peab IT-osakond tagama ettevõttele juurdepääsu taastamise IT-teenustele minuutes, isegi sekundites.
Kuidas see töötab?
Madalal tasemel kasutab metrokloonitakse andmete sünkroonimise replikatsiooni mehhanismi, mida oleme kirjeldanud eelnevas artiklis (vt. ). Kuna replikatsioon on sünkroonne, siis on ka sellele vastavad nõudmised, täpsemalt:
- kiudoptiline kommunikatsioon füüsikaks, 10 gigabiti Ethernet (või kõrgem);
- vahemaa andmesidekeskuste vahel ei tohi ületada 40 kilomeetrit;
- kiudoptilise kanali viivituse vahel andmesidekeskuste (HDD-de) vahel kuni 5 millisekundit (optimaalselt 2).
Kõik need nõuded on soovituslikud, see tähendab, et metrokloonitakse töötab isegi siis, kui neid nõudeid ei järgita, kuid tuleb mõista, et nende nõuete mittejärgimise tagajärjed on võrdsed mõlema HDD töö aeglustumisega metrokloonitakse.
Seega, andmete edastamiseks HDD-de vahel kasutatakse sünkroonset replikatsiooni. Kuidas replikatsioonid automaatselt lülitatakse ja, mis kõige tähtsam, kuidas vältida split-brain'i? Selle jaoks on ülemisel tasandil lisatud täiendav üksus — arbiter.
Kuidas arbiter töötab ja mis on tema ülesanne?
Arbiter on väike virtuaalmasin või riistvaraklaster, mille tuleb käivitada kolmandas asukohas (nt kontoris) ja tagada ligipääs HDD-dele ICMP ja SSH kaudu. Pärast käivitamist peaks arbiter määrama IP-aadressi, seejärel tuleb HDD-de poolt määrata tema aadress, pluss eemaldate kontrollerite aadressid, mis osalevad metrokloonitakse. Seejärel on arbiter tööks valmis.
Arbiter jälgib pidevalt kõiki HDD-sid metrokloonitakse ja juhul, kui mõni süsteem on kättesaamatu, teeb ta, pärast kinnitusest teise klastri liikmelt (ühe 'elus' HDD) otsuse lülitamise replikatsiooni reeglite protseduuri ja kaardistamise kohta.
Äärmiselt oluline hetk. Arbiter peab alati asuma asukohas, mis on erinev tugevusest (HDD-dest), see tähendab, et ei tohi olla andmesidekeskuses 1, kus on HDD 1, ega andmesidekeskuses 2, kus asub HDD 2.
Miks? Sest ainult nii suudab arbitraaž, kasutades ühte ellujäänud andmesalvestusseadet, üheselt ja veatult määrata, kas kaks platvormi, kus asuvad andmesalvestusseadmed, on langenud. Igasugused muud viigid arbitraaži paigutamiseks võivad viia split-brain olukorrani.
Nüüd sukeldume arbitraaži töödetailidesse
Arbitraazis on käivitunud mitmed teenused, mis pidevalt küsivad kõiki andmesalvestusseadmete kontrollerite kohta. Kui küsitluse tulemus erineb eelnevast (saadaval / mitte saadaval), siis selle teave salvestatakse väikesse andmebaasi, mis töötab samuti arbitraažis.
Vaatame arbitraaži töölogi lähemalt.
Samm 1. Kättesaamatuse määramine. Andmesalvestusseadmest tingitud rikke signaaliks on pingeseansi puudumine mõlemalt andmesalvestusseadmest viie sekundi jooksul.
Samm 2. Ülemineku protseduuri käivitamine. Pärast seda, kui arbitraaž mõistis, et üks andmesalvestusseade on kättesaamatuks muutunud, saadab ta päringu "elavale" andmesalvestusseadmele, et veenduda, et "surnud" andmesalvestusseade on tõeliselt kadunud.
Pärast sellist käsu saamist arbitraažist kontrollib teine (elav) andmesalvestusseade täiendavalt, kas esimene andmesalvestusseade on tõeliselt kättesaamatu ja kui see pole saadaval, saadab arbitraažile kinnituse oma kahtluses. Andmesalvestusseade on tõeliselt kättesaamatu.
Pärast sellise kinnituse saamist käivitab arbitraaž kauglepingute ülemineku ja mappimise tõstmise aktiivsete replikate seas, mis olid langenud andmesalvestusseadmest, ning saadab käsu teisele andmesalvestusseadmest teha need replikad sekundaarsetest primaarseteks ja tõsta mappimine. Teine andmesalvestusseade täidab vastavaid protseduure, pärast mida tagab ta juurdepääsu kadunud LUN-idele.
Miks on vajalik täiendav kontroll? Kvoorumi jaoks. See tähendab, et enamiku kolmest (3) klastreis osalevast arvust peab kinnitama ühe klastrisõlme kukkumise. Ainult siis on see otsus tõeliselt õigustatud. See on vajalik, et vältida vale üleminekut ja vastavalt split-brain olukorda.
Samm 2 kestab umbes 5–10 sekundit, seega, arvestades aega, mis on vajalik kättesaamatuse määramiseks (5 sekundit), on pärast äpardust LUN-id koos langenud andmesalvestusseadmest automaatselt 10–15 sekundi jooksul elavale andmesalvestusseadmest tööks saadaval.
On selge, et selleks, et vältida ühenduse katkemist hostidega, tuleb samuti hoolitseda ajutiste seadete õige konfiguratsiooni eest hostides. Soovitatav ajutine väärtus on vähemalt 30 sekundit. See ei lase hostil katkestada ühendust andmesalvestussüsteemiga koormuse ülemineku ajal avariide tõttu ning tagab sisendi ja väljundi katkemise puudumise.
Oota, kui metrokleusteriga on kõik nii hästi, siis miks on üldse vajalik tavaline replikatsioon?
Tegelikult ei ole kõik nii lihtne.
Vaatame metrokleusteri plusse ja miinuseid
Nii et me oleme aru saanud, et ilmselged plusid metrokleusteri võrreldes tavapärase replikatsiooniga on:
- Täielik automatiseerimine, mis tagab minimaalsete taastumisaegade katastroofi korral;
- Ja see on kõik :-).
Ja nüüd, tähelepanu, miinused:
- Lahenduse hind. Kuigi metrokleuster Aerodiski süsteemides ei vaja täiendavat litsentsimist (kasutatakse sama litsentsi, mis replikatsiooni puhul), on lahenduse hind siiski kõrgem kui sünkroonses replikatsioonis. Peab rakendama kõiki nõudeid sünkroonse replikatsiooni jaoks, pluss metrokleusteri nõuded, mis on seotud täiendava lülitamise ja täiendava platvormiga (vt. metrokleusteri planeerimine);
- Lahenduse keerukus. Metrokleuster on oluliselt keerukam kui tavaline replikatsioon ning nõuab palju suuremat tähelepanu ja töökoormust planeerimiseks, seadistamiseks ja dokumenteerimiseks.
Kokkuvõtteks. Metrokleuster on kindlasti väga tehnoloogiline ja hea lahendus, kui on tõeliselt vaja tagada RTO sekundite või minutite jooksul. Aga kui sellist ülesannet pole, ja RTO tundide jooksul on äri jaoks OK, siis pole mõtet püssist varblasi lasta. Piisab tavalisest töö- ja talureplikatsioonist, kuna metrokleuster toob kaasa lisakulusid ja keerukuse IT-infrastruktuuris.
Metrokleusteri planeerimine
See osa ei pretendeeri olema ammendav juhend metrokleusteri projekteerimiseks, vaid näitab vaid põhivaldkondi, mida tuleks läbi töötada, kui otsustate sellist süsteemi ehitada. Seega kaasake metrokleusteri reaalsel rakendamisel kindlasti konsultatsioonide jaoks andmesalvestitootja (st meid) ja teisi seotud süsteeme.
Platvormid
Nagu eespool mainitud, vajab metrokluster vähemalt kolme asukohta. Kaks andmekeskust, kus töötavad salvestusseadmed ja sellega seotud süsteemid, ning kolmas asukoht, kus töötab arbitraaz.
Soovitatav kaugus andmekeskuste vahel on mitte rohkem kui 40 kilomeetrit. Suurem kaugus tõenäoliselt tekitab täiendavaid viivitusi, mis on metroklusteris äärmiselt soovimatud. Tuletame meelde, et viivitused peaksid olema kuni 5 millisekundit, kuigi on soovitatav jääda 2 millisekundi piiresse.
Viivitusi soovitatakse kontrollida ka planeerimise käigus. Iga vähemalt veidi kogenud teenusepakkuja, kes pakub kiudkaabliühendust andmekeskuste vahel, suudab kvaliteetse kontrolli korraldada üsna kiiresti.
Mis puudutab viivitusi arbitraazi (st kolmanda asukoha ja kahe esimese vahel), siis soovitatav viivituste lävi on kuni 200 millisekundit, seega sobib tavaline ettevõtte VPN-ühendus Interneti-ühenduse peal.
Lülitamine ja võrk
Erinevalt replikatsiooniskeemist, kus piisab, kui ühendada erinevatelt asukohtadelt salvestusseadmed, nõuab metroklustrite skeem, et hostid oleks ühendatud mõlema salvestusseadmisega erinevates asukohtades. Selle erinevuse mõistmiseks on mõlemad skeemid allpool toodud.
Nagu skeemist näha, vaatavad asukoha 1 hostid nii salvestusseadmisse 1 kui ka salvestusseadmisse 2. Samuti vaatavad asukoha 2 hostid nii salvestusseadmisse 2 kui ka salvestusseadmisse 1. See tähendab, et iga host näeb mõlemaid salvestusseadmeid. See on metroklustrite toimimise kohustuslik tingimus.
Muidugi pole vaja iga hosti tõmmata optilise kaabli kaudu teise andmekeskusesse, mingid portid ja kaablid ei piisaks. Kõik need ühendused peavad toimuma Ethernet 10G+ või FibreChannel 8G+ lülitite kaudu (FC ainult hostide ja salvestusseadmete ühendamiseks IO jaoks, replikatsioonikanal on praegu kättesaadav ainult IP (Ethernet 10G+) kaudu.
Nüüd paar sõna võrgu topoloogiast. Oluline punkt on alamvõrkude õige konfigureerimine. Tuleb kohe määratleda mitmed alamvõrgud järgmist tüüpi liikluseks:
- Replikatsiooni alamvõrk, mille kaudu sünkroniseeritakse andmed salvestusseadmete vahel. Neid võib olla mitu, antud juhul pole vahet, kõik sõltub praegusest (juba ellu viidud) võrgu topoloogiast. Kui kaks, siis peab ilmselgelt olema nende vahel marsruutimine seadistatud.
- Andmesalvestuse alamsüsteemid, mille kaudu hostid pääsevad SХD ressurssidele (kui see on iSCSI). Igas andmekeskuses peaks olema üks selline alamvõrk;
- Haldusvõrgud, see tähendab kolm marsruutitavat alamvõrku kolmes asukohas, kust hallatakse SХD-d, samuti asub seal arbiter.
Hostide ressursside juurde pääsemiseks vajalikud alamvõrgud me ei käsitle, kuna need sõltuvad tugevalt ülesannetest.
Erineva liikluse jagamine erinevatesse alamvõrkudesse on äärmiselt oluline (eriti oluline on eraldada replikatsioon sisend-/väljundliiklusest), kuna kui segada kogu liiklus ühte "paksu" alamvõrku, siis selle liikluse juhtimine muutub võimatuks, ja kahe andmekeskuse korral võib see isegi põhjustada erinevaid võrgu kokkupõrkeid. Sellesse küsimusse me selle artikli raames sügavale ei lasku, kuna pikendatud andmekeskuste vahelise võrgu planeerimise kohta on palju teavet võrguhardware tootjate ressurssides.
Arbitraari konfiguratsioon
Arbiter peab tagama juurdepääsu kõigile SХD haldamise liidestele protokollide ICMP ja SSH kaudu. Samuti tasub mõelda arbitraari töökatkestamatusele. Siin on üks nüanss.
Arbitraari töökatkestamatuse tagamine on soovitatav, kuid mitte kohustuslik. Mis juhtub, kui arbiter ei jõua õigel ajal kokku kukkuda?
- Metroklastri tavapärane töö ei muutu, kuna arbitraar ei mõjuta metroklastri töötamist üldse (tema ülesanne on õigeaegselt koormust andmekeskuste vahel vahetada).
- Kuid kui arbiter mingil põhjusel kukub ja "magab" andmekeskuse rikke üle, siis ei toimu mingit vahetust, kuna ei ole kedagi, kes edastaks vajalikud käsklused vahetamiseks ja korraldaks kvoorumi. Sel juhul muutub metrokluster tavaliseks replikatsiooniskeemiks, mida tuleb katastroofi ajal käsitsi vahetada, mis mõjutab RTO-d.
Mida sellest järeldub? Kui on tõeliselt vajalik saavutada minimaalne RTO näitaja, tuleb tagada arbitraari töökatkestamatus. Selleks on kaks varianti:
- Käivitada virtuaalmasin arbiteriga töökatkestamatul hüpervisoril, kuna kõik täiskasvanud hüpervisorid toetavad töökatkestamatust;
- Kui kolmandal platvormil (tinglikus kontoris) ei viitsita korralikku klastrit paigutada ning olemasolevat hüpervoleklastrit ei ole, oleme ette näinud riistvaralise arbiitrivariandi, mis on valmistatud 2U kasti, milles töötavad kaks tavalist x86 serverit ja mis suudab taluda lokaalse rikke.
Soovitame tungivalt tagada arbiitri töökindluse, hoolimata sellest, et tavapärastes tingimustes pole see metroklastrile vajalik. Kuid nagu näitab nii teooria kui ka praktika, on tõeliselt usaldusväärse katastroofitõrje infrastruktuuri ülesehitamisel parem tagada end riskide vastu. Paremini kaitsta end ja äri «halva seaduse» eest, see tähendab samaaegselt arbiitri ja ühe väljakuga, kus on andmeserver, rikke eest.
Lahenduse arhitektuur
Arvestades ülaltoodud nõudeid, saame järgmise üldise lahenduse arhitektuuri.
LUN-id tuleks ühtlaselt jaotada kahe väljakuna, et vältida tugevat ülekoormust. Samuti tuleb mõlemates andmekeskustes arvestada mitte ainult topeltmahtu (mis on vajalik andmete samaaegseks hoidmiseks kahel andmeserveril), vaid ka topelt jõudlust IOPS ja MB/s, et vältida rakenduste halbade tulemuste tekkimist ühe andmekeskuse rikke korral.
Eraldi tasub märkida, et korraliku paigutuse puhul (see tähendab, et oleme ette näinud vajalikud IOPS ja MB/s ülemised piirded, samuti vajalikud CPU ja RAM ressursid) ei esine metroklastris ühe andmeserveri rikke korral tõsiseid jõudluse langusi, kui töötatakse ajutiselt ühe andmeserveriga.
See tuleneb sellest, et töötades samaaegselt kahe väljakuga, tarbib toimiv sünkroonne replikatsioon kirjutamisel poole jõudlusest, kuna iga tehing tuleb salvestada kahele andmeserverile (sarnaselt RAID-1/10). Nii et kui üks andmeserveritest ebaõnnestub, kaob replikatsiooni mõju ajutiselt (kuni katkine andmeserver taas käivitub) ja saame kahekordse tõusu kirjutamise jõudluses. Pärast seda, kui ebaõnnestunud andmeserveri LUN-id on töötava andmeserveri peale käivitatud, kaob see kahekordne tõus, kuna koormus tõuseb teiselt andmeserverilt, ja naaseme sellele jõudlustasemele, mis meil oli enne «kukkumist», kuid ainult ühe väljakuga.
Töötava suuruse määramise abil saab luua tingimused, kus kasutajad ei tunne üldse, et kogu andmesalvestus (SxD) on välja langenud. Kuid korratakse, see nõuab väga hoolikat suuruse määramist, mille osas võiks meie poole tasuta pöörduda :-).
Metrokliendi seadistamine
Metrokliendi seadistamine on väga sarnane tavalise replikatsiooni seadistamisega, mida oleme kirjeldanud . Seetõttu keskendume ainult erinevustele. Seadsime laboris ülesande, mis põhines eespool toodud arhitektuuril, ainult minimaalsetes tingimustes: kaks andmesalvestust, ühendatud 10G Ethernetiga, kaks 10G lülitit ja üks host, mis vaatab mõleidsse SxD-d 10G portide kaudu. Arbitraaž töötab virtuaalmasinas.
Virtuaalsete IP-de (VIP) seadistamisel repliikide jaoks tuleks valida VIP tüüp – metrokliendi jaoks.
Loomiseks on kaks replikatsiooniühendust kahe LUN-i jaoks ja need on jaotatud kahe andmesalvestuse vahel: LUN TEST Primary SxD1-le (ühendus METRO), LUN TEST2 Primary SxD2-le (ühendus METRO2).
Nende jaoks seadistasime kaks identset sihtpunkti (meie puhul iSCSI, kuid toetatakse ka FC-d, seadistamise loogika on sama).
SxD1:
SxD2:
Replikatsiooniühenduste jaoks tegime igas SxD-s mappimised.
SxD1:
SxD2:
Seadistasime multipathi ja esitlesime seda hostis.
Seadistame arbitraazi
Arbitraažiga ei pea eriti midagi tegema, tuleb lihtsalt see kolmandas asukohas sisse lülitada, määrata talle IP ja seadistada sellele juurdepääs ICMP ja SSH kaudu. Seadistamine toimub siiski andmesalvestustelt. Arbitraazi seadistus tuleb teha ainult üks kord mõnel SxD-kontrolleril metrokliendis, need seaded levivad automaatselt kõigile kontrolleritele.
Jaotises Kaugreplikatsioon >> Metrokliendi seadistus (kõigil kontrolleritel) >> nupp „Seadista”.
Sisestame arbitraazi IP ja kahe kontrolleri haldusliidese IP-d kaugemas andmesalvestuses.
Seejärel tuleb kõik teenused sisse lülitada (nupp „Taaskäivita kõik”). Tulevikus seadistamise korral tuleb teenuseid kindlasti taas käivitada, et seaded jõustuksid.
Kontrollime, et kõik teenused on aktiivsed.
Sellega on metrokliendi seadistamine lõpule viidud.
Krahhi test
Meie puhul on krahhi test piisavalt lihtne ja kiire, kuna replikatsiooni funktsiooni (üleminek, järjepidevus jne) on arutatud . Seetõttu, et katsetada metroklasteri usaldusväärsust, piisab meil autopealne avariide tuvastamise automatiseerimise, lülitamisprotsessi ja kirjutamise katkestuste puudumise kontrollimiseks.
Selleks simuleerime ühe salvestusseadmest (SХД) täieliku rikke, välja lülitades füüsiliselt mõlemad selle kontrollerid ja alustades varem suure faili kopeerimist LUN-ile, mis peaks aktiveeruma teisel SХД-l.
Lülitame välja ühe SХД. Teisel SХД-l näeme teateid ja logisid, milles teavitavad, et side naaber süsteemiga on kadunud. Kui on seadistatud SMTP või SNMP teavitused, saadab süsteem administraatorile vastavad teated.
Täpselt 10 sekundi pärast (nagu on nähtav mõlemal ekraanipildil) muutus METRO replikatsiooni side (see, mis oli algse SХД peamine) automaatselt peamiseks töötaval SХД-l. Kasutades olemasolevat kaartimist, jäi LUN TEST hostile kergesti kätte saadavaks, kirjutamise kiirus langes natuke (lubatud 10 protsendi piires), kuid ei katkenud.
Test lõppes edukalt.
Kokkuvõtteks
Praegune metroklaster AERODISK Engine N-seeria salvestussüsteemides võimaldab täielikult lahendada ülesandeid, kus on vajalik kõrvaldada või vähendada IT-teenuste seisakuaega ja tagada nende toimimine 24/7/365 minimaalsete tööjõukuludega.
Seda võib muidugi öelda, et kõik see on teooria, ideaalsed laboritingimused jne… KUID meil on rida ellu viidud projekte, kus oleme rakendanud katastroofivastase funktsionaalsuse, ja süsteemid toimivad suurepäraselt. Üks meie üsna tuntud kliendist, kus kasutatakse just kahte SХД-d katastroofikindlas konfiguratsioonis, on juba andnud nõusoleku projekti kohta info avaldamiseks, seetõttu räägime järgmises osas lahingu kasutusele võtmisest.
Aitäh, ootame produktiivset arutelu.
Allikas: habr.com
