Tere, Habr'i lugejad! Selle artikli teemaks on AERODISK Engine'i andmete katastroofikindluse rakendamise vahendid. Alguses soovisime kirjutada ühe artikli mõlema vahendi kohta: replikatsiooni ja metroklastrite, kuid kahjuks osutus artikkel liiga pikaks, seega jagasime selle kaheks osaks. Liikume lihtsast keerulisse. Selles artiklis seadistame ja testime sünkroonset replikatsiooni – kukutame ühe andmekeskuse ja katkestame andmekeskuste vahelise ühenduse ning vaatame, mis juhtub.
Meie kliendid küsivad meilt sageli erinevaid küsimusi replikatsiooni kohta, seega enne seadistamise ja replikatsiooni tõhusaimise katsetamise juurde asumist räägime natuke sellest, mis on replikatsioon andmesalvestussüsteemides.
Veidi teooriat
Replikatsioon andmesalvestussüsteemides on pidev protsess, mis tagab andmete identiteedi samal ajal mitmes andmesalvestussüsteemis. Tehniliselt tehakse replikatsiooni kahte meetodit pidi.
Sünkroonne replikatsioon on andmete kopeerimine põhja andmesalvestussüsteemist varu andmesalvestussüsteemi, millele järgneb mõlema andmesalvestussüsteemi kohustuslik kinnitamine, et andmed on salvestatud ja kinnitatud. Just pärast mõlema poole kinnitamist (kõikidest andmesalvestussüsteemidest) loetakse andmed salvestatuks ja nendega saab töötada. Nii tagatakse andmete garanteeritud identiteet kõigis replikatsioonis osalevates andmesalvestussüsteemides.
Selle meetodi positiivne külg:
- Andmed on alati kõikides andmesalvestussüsteemides identsed
Miinused:
- Lahenduse kõrge hind (kiired sideteed, kallis kiudoptiline kaabel, pikalaine transiidid jne)
- Kauguspiirangud (mitu kümmet kilomeetrit)
- Puudub kaitse andmete loogilise rikete eest (kui andmed rikutakse (teadlikult või juhuslikult) põhja andmesalvestussüsteemis, siis muutuvad need automaatselt ja koheselt rikutuks varu andmesalvestussüsteemis, kuna andmed on alati identsed (selline paradoks))
Asünkroonne replikatsioon on samuti andmete kopeerimine põhja andmesalvestussüsteemist varu andmesalvestussüsteemi, kuid määratud viivitusega ja ilma vajaduseta kinnitada salvestamist teisel poolel. Andmetega saab töötada kohe pärast salvestamist põhja andmesalvestussüsteemis, samas kui varu andmesalvestussüsteemis saavad andmed kätte mõne aja pärast. Andmete identiteeti ei ole sel juhul ilmselgelt tagatud. Andmed varu andmesalvestussüsteemis on alati natuke "minevikus."
Asünkroonse replikatsiooni positiivne külg:
- Madala lahenduse hind (igal suhtlemisviisil, optika on valikuline)
- Ei ole kauguse piiranguid
- Andmed varukoopias ei hävine, kui neid CDO peal on rikutud (minimaalselt teatud aja jooksul), kui andmed on rikutud, saab alati peatada replika, et vältida andmete hävimist varukoopias
Miinused:
- Andmed erinevates andmekeskustes ei ole kunagi identsed
Seega sõltub replikeerimise režiimi valik äriülesannetest. Kui on kriitiline, et varukoopias oleksid täpselt samad andmed nagu põhikoopias (st äri RPO=0 nõue), pead sa rohkem kulutama ja leppima sünkroonse replika piirangutega. Kui andmete oleku viivitus on lubatud või lihtsalt pole raha, tuleks kindlasti kasutada asünkroonset meetodit.
Eraldi toome välja sellise režiimi (täpsemalt topoloogia), nagu metrokliuster. Metrokliusteri režiimis kasutatakse sünkroonset replikeerimist, kuid erinevalt tavalisest replikast võimaldab metrokliuster mõlemal CDO-l töötada aktiivses režiimis. St. sul ei ole eraldatust aktiivsete ja varukoopiate vahel. Rakendused töötavad samaaegselt kahe CDO-ga, mis asuvad füüsiliselt erinevates andmekeskustes. Süsteemihäired sellises topoloogias on väga lühikesed (RTO, tavaliselt minutid). Selles artiklis me ei käsitle meie metrokliustrite rakendust, kuna see on väga suur ja mahukas teema, millele pühendame eraldi, järgmise artikli.
Samuti tekib tihti, kui räägime CDO-replikatsioonist, paljusid õigustatud küsimusi: > „Paljudel rakendustel on oma replikeerimise vahendid, miks kasutada CDO-replikatsiooni? Kas see on parem või halvem?“
Siin ei ole ühtset vastust, seega toome välja argumendid poolt ja vastu:
Argumendid CDO-replikatsiooni kasuks:
- Lahenduse lihtsus. Ühe vahendiga saad replitseerida kogu andmekogumi, sõltumata koormuse liigist ja rakendustest. Kui kasutada rakenduste replikatsiooni, tuleb iga rakendus eraldi seadistada. Kui neid on rohkem kui 2, on see äärmiselt töömahukas ja kallis (rakenduste replikatsioon nõuab enamasti iga rakenduse jaoks eraldi ja tasulist litsentsi. Kuid sellest allpool).
- Saame replitada kõike – mis tahes rakendusi, mis tahes andmeid – ja need on alati järjepidevad. Paljud (enamus) rakendused ei oma replikatsioonivahendeid, ja repliigid salvestusvõrgu poolest on ainus viis katastroofikindluse tagamiseks.
- Ei ole vaja üle maksta rakenduste replikatsiooni funktsionaalsuse eest. Reeglina on see üsna kallis, nagu ka salvestusvõrgu repliikide litsentsid. Kuid salvestusvõrgu replikatsiooni litsentsi eest tuleb maksta vaid kord, samas kui rakenduste repliikide litsents tuleb osta iga rakenduse jaoks eraldi. Kui selliseid rakendusi on palju, tähendab see suurt kulu ja salvestusvõrgu replikatsiooni litsentside hind on tilk meres.
ARGUMENDID VASTU salvestusvõrgu replikatsioonile:
- Rakenduste replikatsioonil on rohkem funktsionaalsust rakenduste enda vaatenurgast, rakendus tunneb oma andmeid paremini (mis on ilmselge), seetõttu on nende töötlemiseks rohkem võimalusi.
- Mõned rakenduste tootjad ei garanteeri oma andmete järjepidevust, kui neid replitseeritakse kolmandate osapoolte vahenditega.*
* - vaieldav väide. Näiteks tuntud andmebaasisüsteemide tootja teatas pikka aega ametlikult, et nende andmebaasisüsteem suudab korralikult replitseerida vaid nende vahenditega, ja muu replikatsioon (sealhulgas salvestusvõrgust) on "vale". Kuid elu on näidanud, et see ei ole tõsi. Tõenäoliselt, (kuigi see ei ole kindel) on see lihtsalt mitte kõige ausam katse müüa klientidele veel litsentse.
Kokkuvõttes on enamikul juhtudel salvestusvõrgu replikatsioon parem, kuna see on lihtsam ja odavam variant, kuid on keerulisi juhtumeid, kus on vajalik rakenduste spetsiifiline funktsionaalsus ja tuleb töötada just rakenduste tasemel replikatsiooniga.
Teooria on läbi, nüüd praktikasse.
Seame repliigi üles meie laboris. Laboritingimustes emuleerisime kahte andmekeskust (tõeliselt on need kaks kõrvuti asetsevat riiulit, mis justkui asuvad erinevates hoonetes). Stand koosneb kahest salvestusvõrgust Engine N2, mis on omavahel ühendatud kiudoptiliste kaablitega. Kumbagi salvestusvõrku on ühendatud füüsiline server, millel on Windows Server 2016 operatsioonisüsteem, kasutades 10Gb Ethernet'i. Stand on üsna simple, kuid see ei muuda asja sisu.
Skeemiliselt näeb see välja järgmiselt:
Loogiliselt on replikatsioon korraldatud järgmiselt:
Nüüd vaatame üle replikatsiooni funktsionaalsused, mis meil praegu olemas on.
Toetatakse kahte režiimi: asünkroonne ja sünkroonne. Loomulikult on sünkroonne režiim piiratud kauguse ja suhtluskanali poolt. Eelkõige on sünkroosse režiimi jaoks vajalik kasutada optilise kiu füüsikat ning 10 gigabitti Ethernetit (või kõrgemat).
Sünkroonse replikatsiooni toetatud kaugus on 40 kilomeetrit, optika kanalite latentsuse väärtus kahe andmekeskuse vahel kuni 2 millisekundit. Tegelikult töötab see ka suuremate latentsustega, kuid siis esinevad salvestamisel suured viivitused (mis on samuti mõistetav), seega kui plaanite sünkroonset replikatsiooni andmekeskuste vahel, tuleks kontrollida optika kvaliteeti ja latentsust.
Asünkroonse replikatsiooni nõuded ei ole nii rangad. Täpsemalt, neid pole üldse. Sobib iga toimiv Etherneti ühendus.
Praegu toetab AERODISK ENGINE mäluseadmiste (LUN-ide) replikatsiooni Ethernetprotokolli kaudu (kas metalli või optika kaudu). Projektide jaoks, kus on hädavajalik replikatsioon SAN-fabrikast läbi Fibre Channel'i, töötame praegu välja vastava lahenduse, kuid selle valmimiseni toetame ainult Ethernetit.
Replikatsioon võib töötada kõikide ENGINE seeria mäluseadmiste (N1, N2, N4) vahel, alustades madalamatest süsteemidest ja liikudes kõrgemate suunas ja vastupidi.
Mõlema replikatsioonirežiimi funktsionaalsus on täiesti identne. Allpool on selle kohta rohkem informatsiooni:
- Replikatsioon "one to one" ehk "üks ühele", st klassikaline variant kahe andmekeskuse vahel, põhja- ja varundsüsteemi vahel.
- Replikatsioon "one to many" ehk "üks paljudele", st üks LUN saab replikeerida mitmesse mälusüsteemi korraga.
- Replikatsiooni aktiveerimine, deaktiveerimine ja "tagasi pööramine", vastavalt replikatsiooni sisse- ja väljalülitamiseks või suuna muutmiseks.
- Replikatsioon on saadaval nii RDG (Raid Distributed Group) basseinide kui ka DDP (Dynamic Disk Pool) jaoks. RDG basseini LUN-e saab replikeerida ainult teise RDG-sse. DDP puhul tõestatakse sama.
On veel palju väikseid eripärasid, kuid nende loetlemisel pole mõtet, räägime neist replikatsiooni seadistamise käigus.
Replikatsiooni seadistamine
Seadistusprotsess on piisavalt lihtne ja koosneb kolmest etapist.
- Võrgu seadistamine
- Salvestuse seadistamine
- Reeglite (seoste) ja mappimise seadmine
Oluline punkt replikatsiooni seadistamisel on see, et esimesed kaks etappi tuleb korrata eemal oleval mäluseadmest, kolmas etapp - ainult põhiseadmest.
Võrgurikkelte seadistamine
Esimene samm on seadistada võrguporte, mille kaudu edastatakse replikatsiooni liiklus. Selleks tuleb portid sisse lülitada ja neile määrata IP-aadressid Front-end adapterites jaotises.
Pärast seda peame looma basseini (meie juhul RDG) ja virtuaalse IP replikatsiooni jaoks (VIP). VIP on ujuv IP-aadress, mis on seotud kahe „füüsilise” aadressiga SAn kontrollerite (portide, mida just seadistasime) vahel. See saab olema peamine replikatsiooni liides. Samuti on võimalik kasutada VLAN-i, kui tuleb töötada märgistatud liiklusega.
VIP loomise protsess replikatsiooni jaoks ei erine palju VIP loomise protsessist sisendi- ja väljundite jaoks (NFS, SMB, iSCSI). VIP, mida me sel juhul loome, on tavaline (ilma VLAN-ita), kuid kindlasti peame märkima, et see on replikatsiooni jaoks (ilma selle näitajata ei saa me VIP-d järgmise sammu reeglisse lisada).
VIP peab olema kindlasti samas alamvõrgus, mis IP-portide vahel, mille vahel ta "ujuv" on.
Korrake neid seadistusi kaug-SAn-is, teise IP-aadressiga, muidugi.
Erinevatest SAn-idest tulenevad VIP-id võivad olla erinevates alamvõrkudes, peamine on see, et nende vahel oleks marsruutimine. Meie puhul on just selline näide (192.168.3.XX ja 192.168.2.XX).
Selleks on võrguosa ettevalmistamine lõpetatud.
Seadistame salvestust
Salvestuse seadistamine replikatsiooni jaoks erineb tavalisest ainult sellega, et kaardistamine toimub spetsiaalses menüüs "Replikatsiooni kaardistamine". Muus osas on kõik sama, mis tavalise seadistamisega. Edasi liikudes.
Varakult loodud basseinis R02 tuleb luua LUN. Loome selle, nimetame LUN1.
Samuti peame looma sama LUN-i kaug-SAn-is sama mahuga. Loome selle. Kassi segaduse vältimiseks nimetame kaug-LUN-i LUN1R.
Kui peaksime võtma LUN-i, mis juba eksisteerib, siis replikatsiooni seadistamise ajal oleks vaja see tootmis-LUN hostilt lahti monteerida ja kaug-SAn-is lihtsalt luua tühi LUN sama mahuga.
Salvestuse seadistamine on lõpetatud, liigume replikatsiooni reegli loomise juurde.
Replikatsiooni reeglite või replikatsiooni seoste seadistamine
Pärast LUN-ide loomist SAn-is, mis on sel hetkel peamine (Primary), seadistame replikatsiooni reegli LUN1 SAn-is 1 LUN1R SAn-is 2.
Seadistamine toimub menüüs "Kaug-replikatsioon".
Loome reegel. Selleks tuleb näidata replikatsiooni saajat. Seal määrame ka ühenduse nime ja replikatsiooni tüübi (sünkroonne või asünkroonne).
Väljal „kaug-süsteemid“ lisame meie SХД2. Lisamiseks tuleb kasutada SХД juhtimis-IP-aadresse (MGR) ja kaug-LUNi nime, kuhu me replikatsiooni sooritame (meie juhul LUN1R). Juhtimis-IP-d on vajalikud ainult ühenduse lisamise ajal, replikatsiooni liiklus ei edastata nende kaudu, selleks kasutatakse varasemalt konfigureeritud VIP-i.
Juba sel etapil saame lisada rohkem kui ühe kaug-süsteemi topoloogiale „üks palju”: vajutame nuppu „Lisa sõlm”, nagu on näidatud alloleval joonisel.
Meie juhul on kaug-süsteem üks, seega piirdume sellega.
Reegel on valmis. Pange tähele, et see lisatakse automaatselt kõikidele replikatsiooni osalejatele (meie puhul on neid kaks). Selliseid reegleid saab luua piiramatult, mis tahes arvu LUN-ide jaoks ja igas suunas. Näiteks saame koormuse tasakaalustamiseks osa LUN-e replitseerida SХД1-lt SХД2-le ja teist osa vastupidi – SХД2-lt SХД1-le.
SХД1. Koheselt pärast loomist algas sünkroniseerimine.
SХД2. Näeme sama reeglit, kuid sünkroniseerimine on juba lõppenud.
LUN1 SХД1-lt on põhirollis, st see on aktiivne. LUN1R SХД2-lt on sekundaarses rollis, st see on ooterežiimil, juhuks kui SХД1 tõrjub.
Nüüd saame meie LUN-i hostiga ühendada.
Teeme ühenduse iSCSI kaudu, kuigi saab teha ka FC kaudu. iSCSI LUN-i replikatsiooni kaardistamine ei erine oluliselt tavapärasest stsenaariumist, seega ei käsitle seda siin detailselt. Kui on vajadus, on see protsess kirjas artiklis „».
Ainus erinevus on see, et kaardistame menüüs „Replikatsiooni kaardistamine”
Oleme seadistanud kaardistamise, andnud LUN-i hostile. Host nägi LUN-i.
Formateerime selle kohalikuks failisüsteemiks.
Kõik, seadistamine on lõpetatud. Edasi tulevad testid.
Testimine
Testime kolme peamist stsenaariumi.
- Normaalne rollide vahetus Secondary > Primary. Normaalne rollide vahetus on vajalik juhul, kui näiteks põhikeskuses tuleb teha hooldustöid ja selle aja jooksul, et andmed oleksid saadaval, suuname koormuse varu keskusesse.
- Hädaolukord: Secondary > Primary rollide vahetus (andmekeskuse rike). See on peamine stsenaarium, milleks replikatsioon on loodud, mis aitab taluda täielikku andmekeskuse rikete, katkestamata ettevõtte tegevust pikaks ajaks.
- Sidekanalite katkestamine andmekeskuste vahel. Kontrollime kahe andmesalvestusüsteemi õiget käitumist olukordades, kui sidekanal kahe andmekeskuse vahel on mingil põhjusel puudulik (näiteks ekskavaator kaevas vales kohas ja lõhkus optilist kaablit).
Alustame oma andmete kirjutamisega meie LUN-ile (kirjutame faile suvaliste andmetega). Vahetult vaatame, kuidas sidekanal andmesalvestussüsteemide vahel töötab. Seda on lihtne mõista, kui avada sadamate koormuse jälgimine, mis vastutab replikatsiooni eest.
Nüüd on mõlemas andmesalvestusüsteemis "kasulikud" andmed, saame testi alustada.
Igaks juhuks vaatame ühe faili hash-summasid ja kirja paneme.
Tavapärane rollide vahetus
Rollide vahetamine (replikatsiooni suuna muutmine) on võimalik teostada ükskõik millise andmesalvestusüsteemi kaudu, kuid tuleb siiski minna mõlemasse, kuna Primaarset peab kartma katkestama ja Sekundaarset (mis muutub Primaarseks) sisse lülitama.
Võib tekkida põhjendatud küsimus: miks seda automatiseerida ei võiks? Vastame: kõik on lihtne, replikatsioon on lihtne katastroofikindluse abinõu, mis põhineb täielikult käsitsi toimingutel. nende toimingute automatiseerimise jaoks on olemas metroklasside režiim, mis on täielikult automatiseeritud, kuid tema seadistus on oluliselt keerulisem. Metroklasside seadistamise kohta kirjutame järgmisel artiklis.
Peamises andmesalvestusüsteemis katkestame kaardistamise, et kirjutamine oleks täielikult peatatud.
Siis ühel andmesalvestussüsteemil (pole vahet, kas peamine või varu) menüüs "Kaugreplikatsioon" valime meie ühenduse REPL1 ja vajutame "Muuda rolli".
Mõne sekundi pärast muutub LUN1R (varu andmesalvestussüsteem) Primaarseks.
Teeme LUN1R kaardistamise andmesalvestussüsteemiga 2.
Pärast seda ühendatakse hostil automaatselt meie kõvaketas E:, seekord on see "tulnud" LUN1R-st.
Igaks juhuks võrdleme hash-summasid.
Identselt. Test on läbitud.
Hädaolukorra vahetus. Andmekeskuse rike
Praegu on peamine andmesalvestusüsteem pärast tavapärast vahetust andmesalvestussüsteem 2 ja LUN1R, vastavalt. Rikkest simuleerimiseks katkestame toite mõlemas andmesalvestusüsteemi kontrolleris.
Sellele enam ei pääse.
Vaata, mis toimub SCSI 1 (praegu varu).
Näeme, et Primary LUN (LUN1R) ei ole saadaval. Logides ja teabe paneelis ilmus vea teade, samuti replikatsiooni reeglis. Seetõttu ei ole andmed hetkel hostilt saadaval.
Muudame LUN1 rolli Primaryks.
Teeme kaardistamise hostile.
Veenduge, et ketas E oleks hostil olemas.
Kontrollime ruttu.
Kõik on korras. Aktiivse andmekeskuse rike, mis juhtus, SCSI talletus talus edukalt. Umbes 3-minutiline aeg, mille kulutasime replikatsiooni 'keeramise' ühendamiseks ja LUNi ühendamiseks varu andmekeskusest. On arusaadav, et reaalsetes tootmistingimustes on kõik palju keerulisem ja lisaks SCSI-le tuleb teha veel palju toiminguid võrgus, hostides ja rakendustes. Ja see ajavahemik on elus oluliselt pikem.
Siin tahaksime kirjutada, et kõik, test on edukalt lõpetatud, kuid ei kiirusta. Peamine SCSI 'on maas', me teame, et kui ta 'kukub', oli ta rollis Primary. Mis juhtub, kui ta äkki uuesti sisse lülitub? Oleks kaks Primary rolli, mis võrduks andmete rikkumisega? Kontrollime kohe.
Läheme ootamatult sisse lülitama maas olevat SCSI-d.
See laadib paar minutit ja seejärel naaseb teenus pärast lühikest sünkroniseerimist, kuid nüüd Secondary rollis.
Kõik on korras. Split-brain ei toimunud. Me mõtlesime sellele ja alati pärast SCSI langust tõuseb see Secondary rollis, sõltumata sellest, millises rollis ta 'elus' oli. Nüüd on kindlasti võimalik öelda, et andmekeskuse rikke test läks edukalt läbi.
Sidekanalite rike andmekeskuste vahel
Selle testi peamine ülesanne on veenduda, et SCSI ei hakka kummaliselt käituma, kui sidekanalid kahe SCSI vahel ajutiselt kaovad, ja seejärel ilmuvad tagasi.
Nii. Lülitame juhtmed välja SCSI vahel (kujutame ette, et need kaevas ekskavaator).
Peamisel näeme, et ühtegi ühendust Secondaryga pole.
Secondaryl näeme, et ühtegi ühendust Primaryga pole.
Kõik töötab normaalselt ja jätkame andmete kirjutamist põhikettale, st need on juba garanteeritult erinevad varukettast, seega 'on lahku läinud'.
Mõne minuti pärast 'parandame' sidekanali. Niipea, kui SCSI üksteist näevad, aktiveeritakse automaatselt andmete sünkroniseerimine. Siin ei nõuta administraatorilt midagi.
Mõne aja pärast sünkroniseerimine lõpeb.
Ühendus on taastatud, ei tekinud mitte mingeid erakorralisi olukordi, sidekanalite katkestused ei tekitanud probleeme, ja pärast sisselülitamist toimus automaatne sünkroniseerimine.
Järeldused
Me käsitlesime teooriat – mida ja miks on vaja, kus on plussid ja kus miinused. Seejärel seadistasime kahe andmesalvestussüsteemi vahel sünkroonse replikatsiooni.
Seejärel tehti põhikatseid tavapärase vahetamise, andmekeskuse rikke ja sidekanalite katkestamise kohta. Kõigil juhtudel toimis andmesalvestussüsteem hästi. Andmete kaotust ei olnud, haldusoperatsioonid olid käsitsi stsenaariumi jaoks minimaalsetes mõõtmetes.
Järgmisel korral keerame olukorra keerulisemaks ja näitame, kuidas kogu see loogika töötab automatiseeritud metroklastris active-active režiimis, see tähendab, et mõlemad andmesalvestussüsteemid on peamised ja andmesalvestussüsteemi rikke korral on käitumine täielikult automatiseeritud.
Palun kirjutage kommentaare, oleme tänulikud konstruktiivse kriitika ja asjalike nõuannete eest.
Kohtumiseni.
Allikas: habr.com
