Tere, Habri lugejad! Viimases artiklis rääkisime lihtsast katastroofi taastamise vahendist AERODISK ENGINE salvestussüsteemides - replikatsioonist. Selles artiklis sukeldume keerukamasse ja huvitavamasse teemasse - metroklastrisse, st kahe andmekeskuse automatiseeritud katastroofikaitsevahendisse, mis võimaldab andmekeskustel töötada aktiivses-aktiivses režiimis. Me ütleme teile, näitame teile, lõhume selle ja parandame selle.
Nagu tavaliselt, kõigepealt teooria
Metroklaster on klaster, mis on jaotatud ühes linnas või piirkonnas mitmes kohas. Sõna "klaster" vihjab meile selgelt, et kompleks on automatiseeritud, st klastri sõlmede vahetamine rikete korral toimub automaatselt.
Siin peitub peamine erinevus metroklastri ja tavalise replikatsiooni vahel. Toimingute automatiseerimine. See tähendab, et teatud intsidentide korral (andmekeskuse rike, kanalite purunemine jne) teeb salvestussüsteem iseseisvalt vajalikud toimingud andmete kättesaadavuse säilitamiseks. Tavaliste koopiate kasutamisel teeb need toimingud täielikult või osaliselt käsitsi administraator.
Mida ta teeb?
Peamine eesmärk, mida kliendid teatud metroklastri rakendusi kasutades taotlevad, on minimeerida RTO (taasteaja eesmärk). See tähendab, et minimeerida IT-teenuste taastumisaega pärast riket. Kui kasutate tavalist replikatsiooni, on taastumisaeg alati pikem kui metroklastri taasteaeg. Miks? Väga lihtne. Administraator peab olema oma laua taga ja vahetama replikatsiooni käsitsi ning metrocluster teeb seda automaatselt.
Kui teil ei ole valves spetsiaalset administraatorit, kes ei maga, ei söö, ei suitseta ega jää haigeks ning jälgib salvestussüsteemi olekut 24 tundi ööpäevas, siis ei saa kuidagi garanteerida, et administraator olema rikke ajal käsitsi ümberlülitamiseks saadaval.
Sellest lähtuvalt võrdub RTO administraatoriteenistuse 99. taseme metroklastri või surematu administraatori puudumisel kõigi süsteemide lülitusaegade ja maksimaalse ajavahemiku summaga, mille möödudes on administraatoril garanteeritud tööle asumine. salvestussüsteemide ja nendega seotud süsteemidega.
Seega jõuame ilmselgele järeldusele, et metroklastrit tuleks kasutada siis, kui RTO nõue on minutid, mitte tunnid või päevad ehk siis kui kõige hullema andmekeskuse rikke korral peab IT-osakond andma ettevõttele aega. IT-teenustele juurdepääsu taastamiseks minutite või isegi sekunditega.
Kuidas see toimib?
Madalamal tasemel kasutab metroklaster andmete sünkroonse replikatsiooni mehhanismi, mida kirjeldasime eelmises artiklis (vt. ). Kuna replikatsioon on sünkroonne, on sellele esitatavad nõuded vastavad või õigemini:
- optiline fiiber kui füüsika, 10 gigabit Ethernet (või kõrgem);
- andmekeskuste vaheline kaugus ei ületa 40 kilomeetrit;
- optilise kanali viivitus andmekeskuste vahel (salvestussüsteemide vahel) on kuni 5 millisekundit (optimaalselt 2).
Kõik need nõuded on oma olemuselt soovituslikud, see tähendab, et metroklaster töötab ka siis, kui neid nõudeid ei täideta, kuid peame mõistma, et nende nõuete mittejärgimise tagajärjed on võrdsed mõlema salvestussüsteemi töö aeglustumisega. metroklaster.
Niisiis, sünkroonset koopiat kasutatakse andmete edastamiseks salvestussüsteemide vahel ja kuidas koopiad automaatselt ümber lülituvad ja mis kõige tähtsam, kuidas vältida aju lõhenemist? Selleks kasutatakse kõrgemal tasemel täiendavat üksust - vahekohtunikku.
Kuidas vahekohtunik töötab ja mis on tema ülesanne?
Vahekohtunik on väike virtuaalne masin või riistvaraklaster, mis tuleb käivitada kolmandal saidil (näiteks kontoris) ja mis võimaldab juurdepääsu salvestussüsteemile ICMP ja SSH kaudu. Pärast käivitamist peaks vahekohtunik määrama IP-aadressi ja seejärel salvestuspoolelt märkima selle aadressi ning metroklastris osalevate kaugjuhtimispultide aadressid. Pärast seda on kohtunik töövalmis.
Vahekohtunik jälgib pidevalt kõiki metroklastri salvestussüsteeme ja kui konkreetne salvestussüsteem pole saadaval, otsustab ta pärast kättesaamatuse kinnitamist mõnelt teiselt klastri liikmelt (üks "reaalajas" salvestussüsteemidest) käivitada replikatsioonireeglite vahetamise protseduuri. ja kaardistamine.
Väga oluline punkt. Vahekohtunik peab alati asuma kohas, mis erineb salvestussüsteemide asukohast, st mitte andmekeskuses 1, kuhu on paigaldatud salvestussüsteem 1, ega andmekeskuses 2, kuhu on paigaldatud salvestussüsteem 2.
Miks? Sest ainult nii saab vahekohtunik ühe säilinud salvestussüsteemi abil üheselt ja täpselt kindlaks teha kahe salvestussüsteemi paigaldamise paiga kukkumise. Kõik muud vahekohtuniku määramise meetodid võivad põhjustada aju lõhenemist.
Sukeldume nüüd vahekohtuniku töö üksikasjadesse.
Vahekohtunik juhib mitmeid teenuseid, mis küsitlevad pidevalt kõiki salvestuskontrollereid. Kui küsitluse tulemus erineb eelmisest (kättesaadav/pole), siis salvestatakse see väikesesse andmebaasi, mis töötab ka vahekohtunikul.
Vaatame vahekohtuniku töö loogikat lähemalt.
1. samm: määrake kättesaamatus. Salvestussüsteemi tõrkesündmus on pingi puudumine sama salvestussüsteemi mõlemalt kontrollerilt 5 sekundi jooksul.
Samm 2. Käivitage lülitusprotseduur. Pärast seda, kui vahekohtunik on aru saanud, et üks salvestussüsteemidest pole saadaval, saadab ta päringu "elavale" salvestussüsteemile, et veenduda, et "surnud" salvestussüsteem on tõesti surnud.
Pärast vahekohtunikult sellise käsu saamist kontrollib teine (aktiivne) salvestussüsteem täiendavalt mahakukkunud esimese salvestussüsteemi saadavust ja kui seda seal pole, saadab kohtunikule kinnituse oma oletuse kohta. Salvestussüsteem pole tõepoolest saadaval.
Pärast sellise kinnituse saamist käivitab vahekohtunik kaugprotseduuri replikatsiooni ümberlülitamiseks ja kaardistamise tõstmiseks nendel koopiatel, mis olid aktiivsed (esmased) langenud salvestussüsteemis, ning saadab teisele salvestussüsteemile käsu muuta need koopiad teisestest primaarseteks ja tõsta kaardistamist. Noh, teine salvestussüsteem teostab neid protseduure ja annab seejärel juurdepääsu kadunud LUN-idele.
Miks on vaja täiendavat kontrolli? Kvoorumi jaoks. See tähendab, et suurem osa klastri liikmete paaritust (3) koguarvust peab kinnitama ühe klastri sõlme langemist. Alles siis on see otsus kindlasti õige. See on vajalik, et vältida ekslikku ümberlülitamist ja sellest tulenevalt aju lõhenemist.
Ajasamm 2 võtab aega ligikaudu 5–10 sekundit, seega, võttes arvesse kättesaamatuse kindlakstegemiseks kuluvat aega (5 sekundit), on 10–15 sekundi jooksul pärast õnnetust allakukkunud salvestussüsteemi LUN-id automaatselt saadaval töötamiseks pinge all. salvestussüsteem.
On selge, et hostidega ühenduste kaotamise vältimiseks peate hoolitsema ka hostide ajalõppude õige konfigureerimise eest. Soovitatav aeg on vähemalt 30 sekundit. See takistab hostil katastroofi korral koormuse ümberlülitamise ajal ühendust salvestussüsteemiga katkestamast ja võib tagada sisend-/väljundkatkestuste puudumise.
Oota hetk, selgub, et kui metroklastriga on kõik nii hästi, siis milleks meil üldse regulaarset replikatsiooni vaja on?
Tegelikkuses pole kõik nii lihtne.
Vaatleme metroklastri plusse ja miinuseid
Niisiis mõistsime, et metroklastri ilmsed eelised võrreldes tavapärase replikatsiooniga on järgmised:
- Täielik automatiseerimine, tagades katastroofi korral minimaalse taastumisaja;
- See on kõik :-).
Ja nüüd, tähelepanu, miinused:
- Lahenduse maksumus. Kuigi Aerodiski süsteemide metrocluster ei vaja täiendavat litsentsimist (kasutatakse sama litsentsi, mis koopia puhul), on lahenduse maksumus siiski isegi suurem kui sünkroonse replikatsiooni kasutamine. Peate rakendama kõik sünkroonse koopia nõuded, pluss täiendava ümberlülitamise ja täiendava saidiga seotud metroklastri nõuded (vt metroklastri planeerimist);
- Lahenduse keerukus. Metroklaster on palju keerulisem kui tavaline koopia ning nõuab palju rohkem tähelepanu ja pingutusi planeerimiseks, konfigureerimiseks ja dokumenteerimiseks.
Lõpuks. Metrocluster on kindlasti tehnoloogiliselt väga arenenud ja hea lahendus, kui teil on tõesti vaja RTO-d pakkuda sekundite või minutitega. Aga kui sellist ülesannet pole ja RTO tundides on asjaajamiseks OK, siis pole mõtet kahurist varblasi tulistada. Piisab tavalisest töölise-talupoeg replikatsioonist, kuna metrooklaster tekitab lisakulusid ja IT-infrastruktuuri keerukust.
Metroklastri planeerimine
See jaotis ei pretendeeri metroklastri kavandamise põhjalikuks juhendiks, vaid näitab ainult peamisi suundi, mis tuleks välja töötada, kui otsustate sellise süsteemi ehitada. Seetõttu tuleb metroklastri tegelikul juurutamisel kindlasti kaasata konsultatsioonidele salvestussüsteemi tootja (see tähendab meie) ja muud seotud süsteemid.
Toimumiskohad
Nagu eespool öeldud, vajab metroklaster vähemalt kolme saiti. Kaks andmekeskust, kus töötavad salvestussüsteemid ja nendega seotud süsteemid, ning kolmas koht, kus töötab vahekohtunik.
Soovitatav andmekeskuste vaheline kaugus ei ole suurem kui 40 kilomeetrit. Suurem vahemaa põhjustab suure tõenäosusega täiendavaid viivitusi, mis metroklastri puhul on äärmiselt ebasoovitavad. Tuletame meelde, et viivitused peaksid olema kuni 5 millisekundit, kuigi soovitav on neid hoida 2 millisekundi piires.
Soovitatav on kontrollida viivitusi ka planeerimise käigus. Iga enam-vähem küps pakkuja, kes pakub andmekeskuste vahel optilist kiudu, suudab kvaliteedikontrolli üsna kiiresti korraldada.
Mis puudutab viivitusi vahekohtuniku ees (st kolmanda saidi ja esimese kahe vahel), on soovitatav viivituslävi kuni 200 millisekundit, see tähendab, et sobib tavaline ettevõtte VPN-ühendus Interneti kaudu.
Lülitumine ja võrgundus
Erinevalt replikatsiooniskeemist, kus piisab erinevate saitide salvestussüsteemide ühendamisest, nõuab metroklastri skeem hostide ühendamist mõlema salvestussüsteemiga erinevates kohtades. Et oleks selgem, milles seisneb erinevus, on allpool näidatud mõlemad skeemid.
Nagu diagrammil näha, vaatavad meie saidi 1 hostid nii salvestussüsteemi 1 kui ka salvestussüsteemi 2. Vastupidi, saidi 2 hostid vaatavad nii salvestussüsteemi 2 kui ka salvestussüsteemi 1. See tähendab, et iga host näeb mõlemat salvestussüsteemi. See on metroklastri toimimise eelduseks.
Loomulikult pole vaja iga hosti optilise juhtmega ühendada teise andmekeskusega, ei piisa ühestki pordist ega juhtmest. Kõik need ühendused tuleb teha Ethernet 10G+ või FibreChannel 8G+ lülitite kaudu (FC on mõeldud ainult hostide ja salvestussüsteemide ühendamiseks IO jaoks, replikatsioonikanal on hetkel saadaval ainult IP kaudu (Ethernet 10G+).
Nüüd paar sõna võrgu topoloogiast. Oluline punkt on alamvõrkude õige konfigureerimine. Järgmist tüüpi liikluse jaoks on vaja kohe määratleda mitu alamvõrku:
- Replikatsiooni alamvõrk, mille kaudu andmeid salvestussüsteemide vahel sünkroonitakse. Neid võib olla mitu, antud juhul pole vahet, kõik sõltub praegusest (juba juurutatud) võrgutopoloogiast. Kui neid on kaks, siis ilmselgelt tuleb nende vahel konfigureerida marsruutimine;
- Salvestusvõrgu alamvõrgud, mille kaudu hostid pääsevad juurde salvestusressurssidele (kui see on iSCSI). Igas andmekeskuses peaks olema üks selline alamvõrk;
- Juhtige alamvõrke, st kolme marsruutitavat alamvõrku kolmel saidil, kust salvestussüsteeme hallatakse, ja seal asub ka vahekohtunik.
Me ei arvesta siin hostiressurssidele juurdepääsuks alamvõrke, kuna need sõltuvad suuresti ülesannetest.
Erinevate liikluste eraldamine erinevatesse alamvõrkudesse on äärmiselt oluline (eriti oluline on eraldada replika I/O-st), sest kui segada kogu liiklus ühte “paksu” alamvõrku, siis on seda liiklust võimatu hallata. kahe andmekeskuse tingimustes võib see siiski põhjustada erinevaid võrgu kokkupõrke võimalusi. Sellesse teemasse me selle artikli raames sügavalt ei süvene, kuna andmekeskuste vahel venitatud võrgu planeerimise kohta saate lugeda võrguseadmete tootjate ressursside kohta, kus seda on väga üksikasjalikult kirjeldatud.
Vahekohtuniku konfiguratsioon
Vahekohtunik peab võimaldama juurdepääsu kõikidele salvestussüsteemi haldusliidestele ICMP ja SSH protokollide kaudu. Samuti peaksite mõtlema vahekohtuniku tõrketurvalisusele. Siin on nüanss.
Vahekohtuniku tõrkevahetus on väga soovitav, kuid mitte nõutav. Mis juhtub, kui kohtunik kukub valel ajal?
- Metroklastri töö tavarežiimis ei muutu, sest arbtir ei mõjuta absoluutselt metroklastri tööd tavarežiimis (selle ülesanne on andmekeskuste vahel õigeaegselt koormust vahetada)
- Veelgi enam, kui vahekohtunik ühel või teisel põhjusel kukub ja andmekeskuses avarii “magab maha”, siis ümberlülitamist ei toimu, sest pole kedagi, kes vajalikke lülituskäsklusi jagaks ja kvoorumi korraldaks. Sel juhul muutub metroklaster tavaliseks replikatsiooniga skeemiks, mida tuleb katastroofi ajal käsitsi ümber lülitada, mis mõjutab RTO-d.
Mis sellest järeldub? Kui teil on tõesti vaja tagada minimaalne RTO, peate tagama, et vahekohtunik oleks tõrketaluv. Selleks on kaks võimalust:
- Käivitage tõrketaluvusega hüperviisori vahekohtunikuga virtuaalmasin, õnneks toetavad kõik täiskasvanud hüperviisorid veataluvust;
- Kui kolmandas kohas (tavalises kontoris) olete tavalise klastri installimiseks liiga laisk ja hüpervozori klastrit pole olemas, siis oleme pakkunud arbiteri riistvaraversiooni, mis on valmistatud 2U karbis, milles on kaks tavalist klastrit. x-86 serverid töötavad ja suudavad kohaliku rikke üle elada.
Soovitame tungivalt tagada vahekohtuniku veataluvus, hoolimata sellest, et metroklaster seda tavarežiimis ei vaja. Kuid nagu näitavad nii teooria kui praktika, kui ehitate tõeliselt usaldusväärse katastroofikindla infrastruktuuri, on parem seda ohutult mängida. Parem on kaitsta ennast ja oma ettevõtet "aladuse seaduse" eest, see tähendab nii vahekohtuniku kui ka ühe salvestussüsteemi asukoha rikke eest.
Lahenduse arhitektuur
Arvestades ülaltoodud nõudeid, saame järgmise üldise lahenduse arhitektuuri.
LUN-id tuleks suure ülekoormuse vältimiseks jaotada ühtlaselt kahe saidi vahel. Samal ajal tuleks mõlemas andmekeskuses suuruse määramisel kaasata mitte ainult topeltmaht (mis on vajalik andmete samaaegseks salvestamiseks kahele salvestussüsteemile), vaid ka topeltjõudlus IOPS-is ja MB/s, et vältida rakenduse halvenemist ühe andmekeskuse rikke korral ov.
Eraldi märgime, et õige lähenemisega suuruse määramisele (st eeldusel, et oleme esitanud õiged IOPS-i ja MB/s ülempiirid, samuti vajalikud CPU ja RAM-i ressursid), kui üks salvestussüsteemidest metroo klaster ebaõnnestub, ei toimu jõudluse tõsist langust ühe salvestussüsteemi ajutise töö tingimustes.
Seda seletatakse asjaoluga, et kui kaks saiti töötavad samaaegselt, "sööb" sünkroonne replikatsioon poole kirjutusjõudlusest, kuna iga tehing tuleb kirjutada kahte salvestussüsteemi (sarnaselt RAID-1/10-ga). Seega, kui üks salvestussüsteemidest ebaõnnestub, kaob ajutiselt (kuni ebaõnnestunud salvestussüsteem taastub) replikatsiooni mõju ja kirjutamisjõudlus suureneb kahekordselt. Pärast ebaõnnestunud salvestussüsteemi LUN-ide taaskäivitamist töötavas salvestussüsteemis kaob see kahekordne suurenemine, kuna koormus ilmub teise salvestussüsteemi LUN-idest ja me naaseme samale jõudluse tasemele, mis meil oli enne "kukkuda", kuid ainult ühe saidi raames.
Pädeva suuruse abil saate tagada tingimused, mille korral kasutajad ei tunne üldse kogu salvestussüsteemi riket. Kuid kordame veel kord, see nõuab väga hoolikat suuruse määramist, mille jaoks, muide, võite meiega ühendust võtta tasuta :-).
Metroklastri seadistamine
Metroklastri seadistamine on väga sarnane tavalise replikatsiooni seadistamisega, mida kirjeldasime artiklis . Seetõttu keskendugem ainult erinevustele. Panime laborisse pingi ülaltoodud arhitektuuri põhjal, ainult minimaalses versioonis: kaks 10G Etherneti kaudu ühendatud salvestussüsteemi, kaks 10G lülitit ja üks host, mis vaatab läbi lülitite mõlemas 10G pordiga salvestussüsteemis. Vahekohtunik töötab virtuaalmasinas.
Virtuaalsete IP-de (VIP-de) konfigureerimisel koopia jaoks peaksite valima VIP-tüübi – metroklastri jaoks.
Lõime kahe LUN-i jaoks kaks replikatsioonilinki ja jaotasime need kahe salvestussüsteemi vahel: LUN TEST Esmane salvestussüsteemis 1 (METRO link), LUN TEST2 Esmane salvestussüsteemi 2 jaoks (METRO2 link).
Nende jaoks konfigureerisime kaks identset sihtmärki (meie puhul iSCSI, kuid toetatud on ka FC, häälestusloogika on sama).
Salvestussüsteem1:
Salvestussüsteem2:
Replikatsiooniühenduste jaoks tehti vastendused igas salvestussüsteemis.
Salvestussüsteem1:
Salvestussüsteem2:
Seadistasime mitme tee ja esitasime selle hostile.
Vahekohtuniku moodustamine
Arbiteri endaga ei pea te midagi erilist tegema; peate selle lihtsalt kolmandal saidil lubama, andma sellele IP ja konfigureerima sellele juurdepääsu ICMP ja SSH kaudu. Seadistamine ise toimub salvestussüsteemidest endist. Sel juhul piisab, kui konfigureerida vahekohtunik üks kord mis tahes salvestuskontrolleris metroklastris; need sätted jagatakse automaatselt kõigile kontrolleritele.
Jaotises Remote replikatsioon>> Metrocluster (mis tahes kontrolleril)>> nuppu "Seadista".
Sisestame vahekohtuniku IP, samuti kahe kaugmälupuldi juhtimisliidesed.
Pärast seda peate lubama kõik teenused (nupp "Taaskäivita kõik"). Kui konfigureeritakse tulevikus uuesti, tuleb seadete jõustumiseks teenused taaskäivitada.
Kontrollime, kas kõik teenused töötavad.
See lõpetab metroklastri seadistamise.
Kokkupõrke test
Krahhitest saab meie puhul olema üsna lihtne ja kiire, kuna replikatsiooni funktsionaalsust (lülitamine, järjepidevus jne) arutati aastal . Seetõttu piisab metroklastri töökindluse testimiseks, kui kontrollime rikete tuvastamise, ümberlülitamise automatiseerimist ja salvestuskadude (I/O-peatuste) puudumist.
Selleks emuleerime ühe salvestussüsteemi täielikku riket, lülitades mõlemad selle kontrollerid füüsiliselt välja, olles esmalt alustanud suure faili kopeerimist LUN-i, mis tuleb teises salvestussüsteemis aktiveerida.
Keela üks salvestussüsteem. Teisel salvestussüsteemil näeme logides hoiatusi ja teateid, et ühendus naabersüsteemiga on katkenud. Kui teated SMTP või SNMP jälgimise kaudu on konfigureeritud, saab administraator vastavaid teateid.
Täpselt 10 sekundit hiljem (nähtav mõlemal ekraanipildil) muutus METRO replikatsiooniühendus (see, mis ebaõnnestunud salvestussüsteemis oli esmane) automaatselt töötava salvestussüsteemi esmaseks. Kasutades olemasolevat kaardistamist, jäi LUN TEST peremehele kättesaadavaks, salvestus langes veidi (lubatud 10 protsendi piiresse), kuid ei katkenud.
Test edukalt läbitud.
Kokkuvõtteks
Metroklastri praegune juurutamine AERODISK Engine N-seeria salvestussüsteemides võimaldab täielikult lahendada probleeme, kus on vaja kõrvaldada või minimeerida IT-teenuste seisakuid ning tagada nende töö 24/7/365 minimaalsete tööjõukuludega.
Võime muidugi öelda, et see kõik on teooria, ideaalsed laboritingimused ja nii edasi... AGA meil on mitmeid teostatud projekte, milles oleme rakendanud katastroofikindluse funktsionaalsust ja süsteemid töötavad ideaalselt. Üks meie üsna tuntud klient, kes kasutab katastroofikindlas konfiguratsioonis vaid kahte salvestussüsteemi, on juba nõustunud projekti kohta info avaldamisega, nii et järgmises osas räägime lahinguteostusest.
Aitäh, ootame tulemuslikku arutelu.
Allikas: www.habr.com