Tere, Habr'i lugejad! Selle artikli teemaks on AERODISK Engine'i hoonete katastroofikindluse rakendamine. Algul tahtsime kirjutada mõlema abinõu kohta ühes artiklis: replikatsiooni ja metroklastrit, kuid kahjuks osutus artikkel liiga suureks, seega jagasime selle kaheks osaks. Alustame lihtsast keerulisse. Selles artiklis seadistame ja testime sünkroonset replikatsiooni – kukutame ühe andmekeskuse ja katkestame sidekanali andmekeskuste vahel ning vaatame, mis sellest saab.
Meie kliendid küsivad meilt sageli erinevaid küsimusi replikatsiooni kohta, seega enne seadistamise ja replikatsioonide testimise juurde minekut räägime veidi sellest, mis on replikatsioon andmesalvestuse süsteemides.
Natuke teooriat
Replikatsioon andmesalvestuse süsteemides on pidev protsess, millega tagatakse andmete ühtsus samaaegselt mitmes andmesalvestuse süsteemis. Tehniliselt viiakse replikatsioon läbi kahe meetodiga.
Sünkroonne replikatsioon – see on andmete kopeerimine peamisest andmesalvestusest varukoopiale, millele järgneb kohustuslik mõlema andmesalvestuse kinnitamine, et andmed on salvestatud ja kinnitatud. Just pärast kahest küljest (mõlemast andmesalvestusest) kinnitamist peetakse andmeid salvestatuks ja nendega saab töötada. Nii tagatakse andmete garanteeritud identiteet kõigis andmesalvestustes, mis osalevad replikatsioonis.
Selle meetodi eelised:
- Andmed on alati identsed kõigis andmesalvestustes
Miinused:
- Lahenduse kõrge hind (kiired suhtluskanalid, kallis optiline kiud, pika lainepikkusega saatjad jne.)
- Kauguse piirangud (mõned tosin kilomeetrit)
- Puudub kaitse loogilise andmekahjustuse eest (kui andmed rikutakse (teadlikult või juhuslikult) peamises andmesalvestuses, siis rikutakse need automaatselt ja kohe ka varukoopias, kuna andmed on alati identsed (selline paradoks))
Asünkroonne replikatsioon – see on ka andmete kopeerimine peamisel andmesalvestil varundus- ja sellele vajaliku kinnitamise ilma teatud viivitusega. Andmetega saab töötada kohe pärast kirjutamist peamisele andmesalvestile, varukoopiatel on andmed varsti pärast kirjutamist saadaval. Andmete identiteet sellisel juhul, nagu arvatud, ei ole kunagi tagatud. Andmed varukoopiatel on alati veidi "minevikus".
Asünkroonse replikatsiooni eelised:
- Madal lahenduse hind (igal kommunikatsioonikanalil, optika on valikuline)
- Pole kauguse piiranguid
- Varukoopiatel andmed ei riku, kui peamisel andmesalvestil need rikutakse (vähemalt teatud aja jooksul), kui andmed on rikutud, saab alati replika peatada, et vältida andmete kahjustumist varukoopiatel.
Miinused:
- Andmed erinevates andmekeskustes ei ole kunagi identsed.
Seega, replikatsiooni režiimi valik sõltub ettevõtte vajadustest. Kui on kriitiline, et varukoopia andmekeskuses oleksid täpselt samad andmed nagu peamises (st äri nõue RPO=0), siis tuleb investeerida ja leppida kokku sünkroonse replikatsiooni piirangute järgimisega. Kui andmete oleku viivitus on lubatud või lihtsalt ei ole raha, siis tuleks kindlasti kasutada asünkroonsed meetodit.
Eraldi tuletame meelde sellist režiimi (täpsemalt juba topoloogiat) nagu metroklasster. Metroklassteri režiimis kasutatakse sünkroonset replikatsiooni, kuid erinevalt tavalisest replikatsioonist võimaldab metroklasster mõlemal tõukeraudade andmetöötlussüsteemil töötada aktiivses režiimis. See tähendab, et teil ei ole jagunemist aktiivseks ja varu andmekeskusteks. Rakendused töötavad samal ajal kahe tõukeraudade süsteemiga, mis asuvad füüsiliselt erinevates andmekeskustes. Avarii korral on sellel topoloogial väga lühikesed seisakud (RTO, tavaliselt minutid). Selles artiklis me ei käsitle meie metroklastri realiseerimist, kuna see on väga suur ja mahukas teema, millele pühendame eraldi järgmise artikli.
Sageli, kui räägime andmete replikatsioonist salvestussüsteemide kaudu, tekib paljudele õigustatud küsimus: > „Paljude rakenduste puhul on olemas oma replikatsiooni vahendid, miks siis kasutada salvestussüsteemide replikatsiooni? Kas see on parem või halvem?“
Siin ei ole üheselt mõistetavat vastust, seega toome välja argumendid EESTI ja VASTU:
Argumendid salvestussüsteemide replikatsiooni poolt:
- Lahenduse lihtsus. Ühe vahendiga saate replitseerida kogu andmekogu, sõltumata koormuse ja rakenduste tüübist. Kui kasutada rakenduste replikatsiooni, tuleb iga rakendus eraldi seadistada. Kui neid on rohkem kui kaks, on see äärmiselt aeganõudev ja kallis (rakenduste replikatsioon nõuab tavaliselt iga rakenduse jaoks eraldi ja tasulist litsentsi. Kuid sellest allpool).
- Saate replitseerida kõike – kõiki rakendusi, kõiki andmeid – ja need on alati konsistentne. Paljud (enamiku) rakenduste puhul ei ole replikatsioonivahendeid ning salvestussüsteemide replikatsioon on ainus võimalus tagada katastroofide eest kaitse.
- Ärge makske liigset hinda rakenduste repo kloonimise funktsionaalsuse eest. Üldiselt on see üsna kallis, nagu ka andmehoidla klooni litsentsid. Kuid andmehoidla kloonimise litsentsi tuleb maksta korra, samas kui rakenduste klooni litsents tuleb osta iga rakenduse kohta eraldi. Kui selliseid rakendusi on palju, siis see võib osutuda kulukaks ja andmehoidla kloonimise litsentside hind näib kuu jooksul pisikese tilgana.
Argumendid SÜSTEEMIDE REPLIKATSIOONI VASTU:
- Rakenduste kaudu kloonimine pakub rohkem funktsioone iseenda andmete haldamise osas, rakendusel on parem teadlikkus oma andmetest (mis on ilmselge), seega on selle kasutamiseks rohkem võimalusi.
- Mõnede rakenduste tootjad ei garanteeri andmete järjepidevust, kui kasutavad kolmandate osapoolte kloonimist.*
* - vaieldav väide. Näiteks pikka aega väitis tuntud andmebaasitootja ametlikult, et nende andmebaas suudab korralikult kloonida ainult nende enda meetoditega ning muu kloonimine (sealhulgas andmehoidlate) pole "tõeline". Kuid elu on näidanud, et see pole tõsi. Tõenäoliselt (kuigi see pole kindel) on see lihtsalt ebaaus katse müüa klientidele veel litsentse.
Lõppkokkuvõttes on enamikul juhtudel salvestussüsteemi replikatsioon parem, kuna see on lihtsam ja odavam variant, kuid on keerukamaid juhtumeid, kus vajalik on spetsiaalne rakenduste funktsionaalsus ning tuleb töötada just rakenduste taseme replikatsiooniga.
Teooriaga oleme lõpetanud, nüüd praktika
Replika seadistame meie laboris. Laboritingimustes oleme emuleerinud kahte andmekeskust (tegelikult kaks lähestikku asuvat riiulit, mis näevad välja nagu erinevates hoonetes). Stand koosneb kahest salvestussüsteemist Engine N2, mis on omavahel ühendatud optiliste kaablitega. Mõlema salvestussüsteemiga on ühendatud füüsiline server, millel on Windows Server 2016, kasutades 10Gb Ethernetit. Stand on üsna lihtne, kuid see ei muuda asja sisu.
Diagrammil näeb see välja nii:
Loogiliselt on replikatsioon korraldatud järgmiselt:
Nüüd vaatame üle replikatsiooni funktsionaalsed võimalused, mis meil praegu on.
Toetatakse kahte režiimi: asünkroonset ja sünkroonset. Loomulikult on sünkroonne režiim piiratud kauguse ja sidekanaliga. Eelkõige nõuab sünkroonne režiim, et kasutataks kiudoptilist kaabli füüsikat ja 10 gigabitist Ethernetit (või kõrgemat).
Sünkrooni replikatsiooni toetatud vahemaa on 40 kilomeetrit, optilise kanali latentsuse väärtus andmekeskuste vahel kuni 2 millisekundit. Tegelikult töötab see ka suuremate latentsustega, kuid siis esinevad kirjutamisel tõsised viivitused (mis on samuti loogiline), seetõttu, kui plaanite sünkroonset replikatsiooni andmekeskuste vahel, tuleks kontrollida optika kvaliteeti ja latentsust.
Asünkroonse replikatsiooni nõuded ei ole nii ranged. Täpsemalt öeldes, neid pole üldse. Sobib iga toimiv Ethernetiühendus.
Praegusel hetkel toetab AERODISK ENGINE andmekogude replikatsiooni plokkseadmestike (LUNide) jaoks Etherneti protokolli kaudu (kas läbipaistva või optilise kaabli kaudu). Projektide puhul, kus on hädasti vajalik replikatsioon SAN-lüliti kaudu Fibre Channeli kaudu, kirjutame praegu vastavat lahendust, kuid see ei ole veel valmis, seega meie olukorras – ainult Ethernet.
Replikatsioon võib toimida mis tahes ENGINE-seeria andmekogude (N1, N2, N4) vahel, alustavatest süsteemidest vanemate ja vastupidi.
Mõlema replikatsioonirežiimi funktsionaalsus on täielikult identne. Allpool on rohkem teavet selle kohta, mis seal on:
- Replikatsioon «one to one» või «üks ühele», st klassikaline variant kahe ANDMEKESKUSE vahel, põhiseade ja varu.
- Replikatsioon «one to many», st üks LUN saab reprodutseerida mitmesse andmesalvestusse korraga.
- Replikatsiooni aktiveerimine, deaktiveerimine ja suuna muutmine, vastavalt replikatsiooni sisselülitamiseks, 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-i saab regruppida ainult teise RDG-sse. DDP on samasugune.
On veel palju väikeseid eripärasid, kuid nende loetlemine ei ole mõtet, mainime neid seadistamise käigus.
Replikatsiooni seadistamine
Seadistusprotsess on piisavalt lihtne ja koosneb kolmest etapist.
- Võrgu seadistamine
- Salvestuse seadistamine
- Reeglite (seoste) ja kaardistamise seadistamine
Oluline punkt replikatsiooni seadistamisel on see, et esimesed kaks etappi tuleb korrata kaugemas andmesalvestuses, kolmas etapp – ainult peamises.
Võrguressursside seadistamine
Esimesena tuleb seadistada võrguportid, mille kaudu replikatsiooni liiklus edastatakse. Selleks tuleb portid sisse lülitada ja neile määrata IP-aadressid Front-end adaptrite lõigus.
Seejärel peame looma koose (meie puhul RDG) ja virtuaalse IP aadressi replikatsiooni jaoks (VIP). VIP on ujuv IP-aadress, mis on seotud kahe „füüsilise” aadressiga andmesalvestuse kontrollerites (portides, mida just seadistasime). Ta on peamine replikatsiooni liides. Samuti võib kasutada VLAN-i, kui on vaja töötada märgistatud liiklusega.
VIP-i loomise protsess replikatsiooni jaoks ei erine oluliselt VIP-i loomisest sisend-/väljuvedamise (NFS, SMB, iSCSI) jaoks. Antud juhul loome lihtsalt VIP-i (ilma VLAN-ita), kuid peame kindlasti märkima, et see on replikatsiooni jaoks (ilma selle näidata ei saa me VIP-i järgmises etapis reeglisse lisada).
VIP peab olema samas alamvõrgus kui portide IP aadressid, mille vahel ta „ujuv” on.
Korrake neid seadeid kaugel andmesalvestuses teise IP-aadressiga, loomulikult.
Erinevatel andmesalvestustel olevad VIP-id võivad olla erinevates alamvõrkudes, oluline on, et nende vahel oleks marsruutimine. Meie puhul ongi see näide (192.168.3.XX ja 192.168.2.XX) see.
Sellega on võrguseadistamine lõpetatud.
Seame salvestusi üles.
Kloonimisülesande salvestamine erineb tavalisest ainult sellega, et kaartide loomise teeme läbi erilise menüü „Kloonimise kaart”. Muus osas on kõik sama nagu tavalisel seadistamisel. Siin on see järjekorras.
Varasemalt loodud R02 grupis tuleb luua LUN. Loome selle, nimetame LUN1.
Peame looma identse LUN-i ka kaugseadmest, mille maht on sama. Loome selle. Segaduse vältimiseks nimetame kaug-LUN-i LUN1R.
Kui peaksime võtma LUN-i, mis juba eksisteerib, siis kloonimise seadistamise ajal tuleks see tootmis-LUN võõrustajalt eemaldada ning kaugseadmest luua lihtsalt tühi LUN sama mahuga.
Salvestamise seadistamine on lõpetatud, liikume edasi kloonimisreegli loomisele.
Kloonimisreeglite või kinnituste seadistamine
Pärast LUN-ide loomist seadmes, mis on praegu põhiseade (Primary), seadistame LUN1 kloonimisreegle LUN1R peal LUN2-s.
Seadistamine toimub menüüs „Kaugkloonimine”
Loome reegli. Selleks peame näitama klooni saajat. Seal seame ka ühenduse nime ja kloonimise tüübi (sünkrone või asünkroniseeritud).
Väljas „eemaldatud süsteemid“ lisame meie SCD2. Lisamiseks tuleb kasutada SCD juhtimis-IP-d (MGR) ja eemalduse LUNi nime, kuhu me teostame replikatsiooni (meie juhul LUN1R). Juhtimis-IP-d on vajalikud ainult seose lisamise etapil, replikatsiooni liiklus nende kaudu ei liigu, selleks kasutatakse varem konfigureeritud VIP-i.
Juba sel etapil saame lisada rohkem kui ühe eemalduse süsteemi „üks-ühele” topoloogias: vajutame nuppu „lisa sõlm”, nagu alloleval joonisel.
Meie puhul on eemalduse süsteem üks, seega piirdume sellega.
Reegel on valmis. Pange tähele, et see lisatakse automaatselt kõigile replikatsiooniosalistele (meie juhul neid on kaks). Selliseid reegleid saab luua nii palju kui soovite, igasuguste LUN-ide ja igas suunas. Näiteks saame koormuse tasakaalustamiseks osa LUN-idest replitseerida SCD1-lt SCD2-le ja teise osa vastupidises suunas – SCD2-lt SCD1-le.
SCD1. Kohe pärast loomist algas sünkroniseerimine.
SCD2. Näeme sama reeglit, kuid sünkroniseerimine on juba lõpetatud.
LUN1 SCSI1-l on Primary rollis, see tähendab, et see on aktiivne. LUN1R SCSI2-l on Secondary rollis, see tähendab, et see on alaliselt varuks, et asendada SCSI1, kui see ebaõnnestub.
Nüüd saame meie LUN-i hostiga ühendada.
Teeme ühenduse iSCSI kaudu, kuigi see on võimalik ka FC kaudu. iSCSI LUN-i kaardistamise seadistamine replikatsioonis ei erine oluliselt tavalistest stsenaariumitest, seega ei käsitle me seda siin põhjalikult. Kui vaja, on see protsess kirjeldatud artiklis «».
Ainus erinevus on see, et kaardistamine luuakse „Replikatsiooni kaardistamise” menüü kaudu
Oleme kaardistamise seadistanud ja andnud LUN-i hostile. Host näeb LUN-i.
Formaatime selle kohalikuks failisüsteemiks.
Kõik, seadistus on lõpetatud. Edasi tulevad testid.
Testimine
Testime kolme põhistsenaariumi.
- Tavaline rollide vahetus Secondary > Primary. Tavaline rollide vahetus on vajalik juhul, kui meil on vaja näiteks peamise andmekeskuse puhul teha mõningaid ennetavaid toiminguid. Sel ajal, et andmed oleksid kergesti kättesaadavad, suuname koormuse varu andmekeskusesse.
- Hädaolukordade rollide vahetamine Secondary > Primary (andmekeskuse rike). See on peamine stsenaarium, mille tõttu replikatsioon eksisteerib, mis aitab ellu jääda täieliku andmekeskuse rikke korral, peatamata ettevõtte tegevust pikema aja vältel.
- Andmekeskuste vaheliste sidekanalite katkestamine. Kahte salvestusseadet käitatakse olukordades, kus sidekanal andmekeskuste vahel on mingitel põhjustel kättesaamatud (näiteks ekskavaator kaevas valesti ja katkestas tumeda optika).
Käivitame andmete kirjutamise meie LUN-ile (kirjutame faile juhuslike andmetega). Vahetult jälgime, kuidas võrguühendus kahe salvestusseadmest koormustel kuvatakse. Seda on lihtne mõista, kui avada portide koormuse jälgimisaken, mis vastutab replikatsiooni eest.
Molemates salvestusseadmetes on nüüd „kasulikud“ andmed, saame testi alustada.
Iga juhuks vaatame ühe faili räsikoodi ja salvestame selle.
Tavapärane rollide vahetamine
Rollide vahetamise operatsiooni (replikatsiooni suuna muutmise) võib teha igasuguste salvestusseadmetega, kuid tuleb siiski minna mõlemasse, kuna Primaarse seadme puhul tuleb katkestada mappimine, ja Sekundaarse seadme (mis muutub Primaarseks) korral tuleb seda aktiveerida.
Võib-olla tekib kohe mõte: miks mitte seda automatiseerida? Vastame: see on lihtne, replikatsioon on lihtne katastroofikindluse meetod, mis põhineb täielikult käsitöö protseduuridel. Nende protseduuride automatiseerimiseks on olemas metroklastri režiim, mis on täielikult automatiseeritud, kuid selle seadistamine on oluliselt keerulisem. Metroklastri seadistamisest kirjutame järgmiseks artiklis.
Peamise andmesalvestussüsteemi puhul kaotame kaardistamise, et tagada kirjutuse peatumine.
Siis ühe andmesalvestussüsteemi (ei ole oluline, kas peamise või reservi puhul) menüüs „Kaugreplikatsioon“ valime meie side REPL1 ja vajutame „Muuda rolli“.
Mõne sekundi pärast saab LUN1R (reservi andmesalvestussüsteem) Peamiseks.
Teeme LUN1R kaardistamise andmesalvestussüsteemiga 2.
Pärast seda kinnitub meie E: ketas automaatselt hostile, kuid seekord on see „lennanud“ LUN1R-st.
Igal juhul võrreldame häälsummasid.
Kujutame ette. Test läbitud.
Hädaolukord. Andmekeskuse rike
Hetkel on peamine andmesalvestussüsteem pärast plaanipärast vahetust andmesalvestussüsteem 2 ja LUN1R. Häda simuleerimiseks lülitame välja toite mõlema andmesalvestussüsteemi 2 kontrollereid.
Ligipääsu ei ole enam.
Vaata, mis toimub SxD 1 (hetkel varundatud).
Näeme, et Primary LUN (LUN1R) ei ole saadaval. Logidest, teabepaneelist ja replikatsioonireeglist on ilmunud veateade. Vastavalt sellele ei ole andmed hostist hetkel kättesaadavad.
Muudame LUN1 rolli Primaarseks.
Teeme hostile kaardistamise.
Veendume, et ketas E on hostis ilmunud.
Kontrollime ristit.
Kõik on korras. Andmeside keskuse (DC) häire, mis oli aktiivne, on SxD edukalt üle elanud. Umbes 3 minuti jooksul, mis kulus replikatsiooni „pöörde“ ja LUN-i hädavarustamisest tõstmisele, oli mõningaid toimetusi tarvis tegeleda. Selge on, et reaalses tootmises on kõik palju keerulisem ja lisaks SxD-ga istumisele on vaja tegeleda ka paljude teiste protsessidega võrgus, hostides, rakendustes. Elus on see ajavahemik oluliselt pikem.
Siia tahaks kirjutada, et kõik, test on edukalt lõpetatud, kuid ei kiirusta. Peamine SxD on „maas“, me teame, et kui see „langes“, siis oli see Primaarse rollis. Mis juhtub, kui see äkki jälle sisse lülitatakse? Oleks kaks Primaarset rolli, mis tähendab andmete kahjustamist. Praegu kontrollime.
Läheme äkki sisse lülitama maas olevat SxD-d.
See laadib paar minutit ja pärast seda naaseb see tööle lühikese sünkroniseerimise järel, kuid juba Secondary rollis.
Kõik on korras. Split-brain ei juhtunud. Mõtlesime sellele ja alati pärast HDFS-i kokkuvarisemist tõuseb see üles Secondary rollis, sõltumata sellest, millises rollis see oli 'elus'. Nüüd võib kindlasti öelda, et andmekeskuse rike läbis testi edukalt.
Sidekaotused andmekeskuste vahel
Selle testi peamine eesmärk on veenduda, et HDFS ei hakkaks kummalisi asju tegema, kui tal ajutiselt kaovad sidekanalid kahe HDFS-i vahel, ning siis taastuvad.
Nii. Lülitame kaablid välja HDFS-ist (kujutame ette, et kaevur kaevas need läbi).
Primary-l näeme, et kommunikatsioon Secondary-ga on kadunud.
Secondary-l näeme, et kommunikatsioon Primary-ga on kadunud.
Kõik töötab normaalselt ja jätkame andmete kirjutamist põhivahendisse, see tähendab, et need varukoopiaga garantii alusel erinevad, ehk 'lahknevad'.
Mõne minuti pärast 'parandame' sidekanali. Niipea kui HDFS-id üksteist näevad, aktiveerub automaatselt andmete sünkroniseerimine. Administratorilt ei ole siin midagi vajalik.
Mõne aja pärast sünkroniseerimine lõppeb.
Ühendus on taastatud, häirete tõttu kanaleid ei katkenud ning pärast sisselülitamist toimus automaatne sünkroonimine.
Järeldused
Me käsitlesime teooriat – mida ja miks on vajalik, kus on plussid ja kus miinused. Seejärel seadistasime sünkroonse replikatsiooni kahe andmesalvestussüsteemi vahel.
Seejärel viidi läbi põhikatsed tavapärase vahetuse, andmekeskuse rikke ja sidekanalite katkestamise korral. Kõigil juhtudel töötas andmesalvestussüsteem hästi. Andmeid ei kaotatud, haldusoperatsioonide hulk on minimaalne käsitsi stsenaariumi jaoks.
Järgmisel korral raskendame olukorda ja näitame, kuidas kogu see loogika töötab automatiseeritud metroklastri active-active režiimis, st kui mõlemad andmesalvestussüsteemid on peamised ning andmesalvestussüsteemide rikke käitlemine on täielikult automatiseeritud.
Palun kirjutage kommentaare, me hindame konstruktiivset kriitikat ja kasulikke nõuandeid.
Kuni järgmise korrani.
Allikas: habr.com
