Tere, Habri lugejad! Selle artikli teemaks on katastroofi taastamise tööriistade rakendamine AERODISK Engine'i salvestussüsteemides. Algselt tahtsime ühes artiklis kirjutada mõlemast tööriistast: replikatsioonist ja metroklastrist, kuid kahjuks osutus artikkel liiga pikaks, mistõttu jagasime artikli kaheks osaks. Liigume lihtsast keeruliseni. Selles artiklis seadistame ja testime sünkroonset replikatsiooni – loobume ühe andmekeskusest, samuti katkestame andmekeskuste vahelise sidekanali ja vaatame, mis juhtub.
Meie kliendid küsivad meilt sageli erinevaid küsimusi replikatsiooni kohta, nii et enne kui liigume edasi koopiate seadistamise ja juurutamise testimise juurde, räägime teile veidi, mis on replikatsioon salvestusruumis.
Natuke teooriat
Salvestussüsteemides replikatsioon on pidev protsess andmete identiteedi tagamiseks samaaegselt mitmes salvestussüsteemis. Tehniliselt toimub replikatsioon kahel viisil.
Sünkroonne replikatsioon – see on andmete kopeerimine põhisalvestussüsteemist varusüsteemi, millele järgneb mõlema salvestussüsteemi kohustuslik kinnitus, et andmed on salvestatud ja kinnitatud. Pärast mõlemapoolset kinnitust (mõlemad salvestussüsteemid) loetakse andmed salvestatuks ja nendega saab töötada. See tagab garanteeritud andmete identiteedi kõigis koopias osalevates salvestussüsteemides.
Selle meetodi eelised:
- Andmed on kõikides salvestussüsteemides alati identsed
miinuseid:
- Lahenduse kõrge hind (kiired sidekanalid, kallis optiline fiiber, pikalainelised transiiverid jne)
- Distantsipiirangud (mõnekümne kilomeetri raadiuses)
- Loogiliste andmete riknemise vastu puudub kaitse (kui andmed rikutakse (tahtlikult või kogemata) põhisalvestussüsteemis, rikutakse need automaatselt ja koheselt ka varusüsteemis, kuna andmed on alati identsed (see on paradoks)
Asünkroonne replikatsioon – see on ka andmete kopeerimine põhimälusüsteemist varusüsteemi, kuid teatud viivitusega ja ilma vajaduseta teisele poole kirjutamist kinnitada. Saate andmetega töötada kohe pärast nende salvestamist põhisalvestussüsteemi ja varusalvestussüsteemis on andmed saadaval mõne aja pärast. Andmete identsus pole sel juhul muidugi sugugi tagatud. Varundussalvestussüsteemi andmed on alati veidi "minevikus".
Asünkroonse replikatsiooni plussid:
- Odav lahendus (kõik sidekanalid, optika valikuline)
- Vahemaa piiranguid pole
- Varusalvestussüsteemis andmed ei halvene, kui need on kahjustatud põhisüsteemis (vähemalt mõnda aega); kui andmed rikutakse, saate alati peatada koopia, et vältida andmete rikkumist varusalvestussüsteemis.
miinuseid:
- Erinevates andmekeskustes olevad andmed ei ole alati identsed
Seega sõltub replikatsioonirežiimi valik ärieesmärkidest. Kui teie jaoks on ülioluline, et varuandmekeskus sisaldaks täpselt samu andmeid kui põhiandmekeskus (st ärinõue RPO jaoks = 0), siis peate raha välja võtma ja leppima sünkroonse andmekeskuse piirangutega. koopia. Ja kui andmete oleku viivitus on vastuvõetav või lihtsalt raha pole, peate kindlasti kasutama asünkroonset meetodit.
Toome eraldi välja ka sellise režiimi (täpsemalt topoloogia) nagu metroklaster. Metroklastri režiimis kasutatakse sünkroonset replikatsiooni, kuid erinevalt tavalisest koopiast võimaldab metroklaster mõlemal salvestussüsteemil töötada aktiivses režiimis. Need. teil pole aktiivset ja ooterežiimi andmekeskust eraldatud. Rakendused töötavad samaaegselt kahe salvestussüsteemiga, mis asuvad füüsiliselt erinevates andmekeskustes. Sellise topoloogia korral on õnnetuste ajal seisakud väga väikesed (RTO, tavaliselt minutid). Selles artiklis me ei käsitle metroklastri rakendamist, kuna see on väga mahukas ja mahukas teema, seega pühendame sellele järgmise artikli jätkuks eraldi.
Samuti tekib väga sageli salvestussüsteemide abil replikatsioonist rääkides paljudel põhjendatud küsimus: > „Paljudel rakendustel on oma replikatsioonitööriistad, miks kasutada replikatsiooni salvestussüsteemides? Kas see on parem või halvem?
Siin ei ole selget vastust, nii et siin on argumendid POOLT ja miinused:
Argumendid salvestusruumi replikatsiooni KOHTA:
- Lahenduse lihtsus. Ühe tööriistaga saate kopeerida kogu andmestiku, olenemata laadimise tüübist ja rakendusest. Kui kasutate rakenduste koopiat, peate iga rakenduse eraldi konfigureerima. Kui neid on rohkem kui 2, siis on see äärmiselt töömahukas ja kulukas (rakenduse replikatsiooniks on tavaliselt vaja iga rakenduse jaoks eraldi ja mitte tasuta litsentsi. Aga sellest allpool).
- Saate paljundada kõike – mis tahes rakendust, mis tahes andmeid – ja see on alati järjepidev. Paljudel (enamikul) rakendustel pole replikatsioonivõimalusi ja salvestussüsteemi koopiad on ainus viis katastroofide eest kaitsta.
- Rakenduse replikatsioonifunktsioonide eest pole vaja üle maksta. Reeglina pole see odav, nagu ka salvestussüsteemi koopia litsentsid. Kuid salvestusruumi replikatsiooni litsentsi eest tuleb maksta üks kord ja rakenduse koopia litsents tuleb osta iga rakenduse jaoks eraldi. Kui selliseid rakendusi on palju, siis maksab see päris senti ja salvestusruumi replikatsiooni litsentside maksumus muutub tilgaks.
Argumendid salvestusruumi replikatsiooni VASTU:
- Replica läbi rakenduste omab rohkem funktsionaalsust rakenduste endi seisukohalt, rakendus teab oma andmeid paremini (ilmselgelt), seega on nendega töötamiseks rohkem võimalusi.
- Mõnede rakenduste tootjad ei garanteeri oma andmete järjepidevust, kui replikatsiooni tehakse kolmanda osapoole tööriistu kasutades. *
* - vastuoluline väitekiri. Näiteks on tuntud DBMS-i tootja juba väga pikka aega ametlikult deklareerinud, et nende DBMS-i saab tavapäraselt paljundada ainult nende vahenditega ja ülejäänud replikatsiooni osa (sealhulgas salvestussüsteemid) ei vasta tõele. Kuid elu on näidanud, et see pole nii. Tõenäoliselt (kuid see pole kindel) pole see lihtsalt kõige ausam katse müüa klientidele rohkem litsentse.
Selle tulemusena on enamikul juhtudel replikatsioon salvestussüsteemist parem, kuna See on lihtsam ja odavam variant, kuid on keerulisi juhtumeid, kui on vaja spetsiifilist rakenduse funktsionaalsust ja on vaja töötada rakenduse tasemel replikatsiooniga.
Teooria tehtud, nüüd praktika
Konfigureerime koopia oma laboris. Laboratoorsetes tingimustes emuleerisime kahte andmekeskust (tegelikult kahte kõrvuti asuvat riiulit, mis tundusid olevat erinevates hoonetes). Stend koosneb kahest Engine N2 salvestussüsteemist, mis on omavahel ühendatud optiliste kaablitega. Windows Server 2016 töötav füüsiline server on ühendatud mõlema salvestussüsteemiga, kasutades 10 Gb Etherneti. Stend on üsna lihtne, kuid see ei muuda olemust.
Skemaatiliselt näeb see välja selline:
Loogiliselt on replikatsioon korraldatud järgmiselt:
Vaatame nüüd replikatsioonifunktsioone, mis meil praegu on.
Toetatud on kaks režiimi: asünkroonne ja sünkroonne. On loogiline, et sünkroonrežiim on piiratud vahemaa ja sidekanaliga. Eelkõige nõuab sünkroonrežiim kiudoptilist kasutamist füüsikana ja 10 Gigabit Etherneti (või kõrgemat).
Sünkroonse replikatsiooni toetatud kaugus on 40 kilomeetrit, andmekeskuste vahelise optilise kanali viivitusväärtus on kuni 2 millisekundit. Üldiselt töötab see suurte viivitustega, kuid siis on salvestamise ajal tugev aeglustumine (mis on ka loogiline), nii et kui plaanite sünkroonset replikatsiooni andmekeskuste vahel, peaksite kontrollima optika kvaliteeti ja viiteid.
Asünkroonse replikatsiooni nõuded pole nii tõsised. Täpsemalt pole neid seal üldse. Iga töötav Etherneti ühendus sobib.
Praegu toetab AERODISK ENGINE salvestussüsteem plokkseadmete (LUN-ide) replikatsiooni Etherneti protokolli kaudu (üle vase või optilise). Projektide jaoks, kus on vajalik replikatsioon SAN-kanga kaudu Fibre Channeli kaudu, lisame praegu sobiva lahenduse, kuid see pole veel valmis, seega meie puhul ainult Ethernet.
Replikatsioon võib töötada mis tahes ENGINE-seeria salvestussüsteemide vahel (N1, N2, N4) alates noorematest süsteemidest kuni vanemateni ja vastupidi.
Mõlema replikatsioonirežiimi funktsionaalsus on täiesti identne. Allpool on üksikasjalikum teave saadaoleva kohta:
- Replikatsioon "üks ühele" või "üks ühele", see tähendab klassikaline versioon kahe andmekeskusega, põhi- ja varunduskeskusega
- Replikatsioon on “üks paljudele” või “üks paljudele”, st. ühte LUN-i saab korrata mitmesse salvestussüsteemi korraga
- Replikatsiooni aktiveerimiseks, deaktiveerimiseks ja ümberpööramiseks vastavalt, et lubada, keelata või muuta replikatsiooni suunda
- Replikatsioon on saadaval nii RDG (Raid Distributed Group) kui ka DDP (Dynamic Disk Pool) kogumite jaoks. RDG-kogumi LUN-e saab aga kopeerida ainult teise RDG-sse. Sama ka DDP-ga.
Väikesi funktsioone on palju rohkem, kuid nende loetlemisel pole erilist mõtet; me mainime neid seadistamisel.
Replikatsiooni seadistamine
Seadistamisprotsess on üsna lihtne ja koosneb kolmest etapist.
- Võrgu konfiguratsioon
- Salvestusruumi seadistamine
- Reeglite (ühenduste) seadistamine ja kaardistamine
Replikatsiooni seadistamise oluline punkt on see, et kahte esimest etappi tuleks korrata kaugsalvestussüsteemis, kolmandat etappi - ainult põhisüsteemis.
Võrguressursside seadistamine
Esimene samm on võrgupordi konfigureerimine, mille kaudu replikatsiooniliiklus edastatakse. Selleks peate pordid lubama ja määrama nende IP-aadressid jaotises Esiotsa adapterid.
Pärast seda peame looma basseini (meie puhul RDG) ja replikatsiooni virtuaalse IP (VIP). VIP on ujuv IP-aadress, mis on seotud salvestuskontrollerite kahe "füüsilise" aadressiga (pordid, mille me just konfigureerisime). See on peamine replikatsiooniliides. Saate töötada ka mitte VIP-iga, vaid VLAN-iga, kui peate töötama märgistatud liiklusega.
Replika VIP-i loomise protsess ei erine palju I/O jaoks (NFS, SMB, iSCSI) VIP-i loomisest. Sel juhul loome tavalise VIP-i (ilma VLAN-ita), kuid märkige kindlasti, et see on replikatsiooni jaoks (ilma selle osutita ei saa me järgmises etapis VIP-i reeglisse lisada).
VIP peab asuma samas alamvõrgus kui IP-pordid, mille vahel see hõljub.
Kordame neid sätteid kaugsalvestussüsteemis, loomulikult erineva IP-ga.
VIP-id erinevatest salvestussüsteemidest võivad olla erinevates alamvõrkudes, peaasi, et nende vahel oleks marsruutimine. Meie puhul on see näide täpselt näidatud (192.168.3.XX ja 192.168.2.XX)
See lõpetab võrguosa ettevalmistamise.
Salvestusruumi seadistamine
Replica salvestusruumi seadistamine erineb tavapärasest ainult selle poolest, et teeme kaardistamise spetsiaalse menüü “Replication Mapping” kaudu. Muidu on kõik sama, mis tavalise seadistuse puhul. Nüüd järjekorras.
Varem loodud kogumis R02 peate looma LUN-i. Loome selle ja nimetame selle LUN1-ks.
Samuti peame looma sama LUN-i identse suurusega kaugsalvestussüsteemis. Meie loome. Segaduste vältimiseks kutsume kaugjuhtimispuldi LUN LUN1R
Kui meil on vaja võtta juba olemasolev LUN, siis peaksime koopia seadistamise ajal selle produktiivse LUN-i hostist lahti ühendama ja looma kaugsalvestussüsteemis lihtsalt identse suurusega tühja LUN-i.
Salvestusseadistus on lõpetatud, jätkame replikatsioonireegli loomisega.
Replikatsioonireeglite või replikatsioonilinkide seadistamine
Pärast LUN-ide loomist salvestussüsteemis, mis on hetkel esmane, konfigureerime replikatsioonireegli LUN1 salvestussüsteemis 1 kuni LUN1R-i salvestussüsteemis 2.
Seade tehakse menüüs "Kaugreplikatsioon".
Loome reegli. Selleks peate määrama koopia saaja. Seal määrame ka ühenduse nime ja replikatsiooni tüübi (sünkroonne või asünkroonne).
Väljale "kaugsüsteemid" lisame oma salvestussüsteemi2. Lisamiseks peate kasutama haldus-IP-salvestussüsteeme (MGR) ja kaug-LUN-i nime, millesse replikatsiooni teostame (meie puhul LUN1R). Juhtimise IP-sid on vaja ainult ühenduse lisamise etapis, nende kaudu replikatsiooniliiklust ei edastata, selleks kasutatakse eelnevalt konfigureeritud VIP-i.
Juba selles etapis saame topoloogia "üks paljudele" jaoks lisada rohkem kui ühe kaugsüsteemi: klõpsake nuppu "Lisa sõlm", nagu alloleval joonisel.
Meie puhul on ainult üks kaugsüsteem, seega piirdume sellega.
Reegel on valmis. Pange tähele, et see lisatakse automaatselt kõigile replikatsioonis osalejatele (meie puhul on neid kaks). Saate luua nii palju selliseid reegleid kui soovite, mis tahes arvu LUN-ide jaoks ja mis tahes suunas. Näiteks võime koormuse tasakaalustamiseks kopeerida osa LUN-idest salvestussüsteemist 1 salvestussüsteemist 2 ja teise osa, vastupidi, salvestussüsteemist 2 salvestussüsteemi 1.
Salvestussüsteem 1. Kohe pärast loomist algas sünkroonimine.
Salvestussüsteem 2. Näeme sama reeglit, kuid sünkroonimine on juba lõppenud.
LUN1 salvestussüsteemis 1 on esmases rollis, see tähendab, et see on aktiivne. Salvestussüsteemi 1 LUN2R on sekundaarse rollis, see tähendab, et see on ooterežiimis juhuks, kui salvestussüsteem 1 peaks rikki minema.
Nüüd saame ühendada oma LUN-i hostiga.
Ühendame iSCSI kaudu, kuigi seda saab teha ka FC kaudu. ISCSI LUN-i kaudu kaardistamise seadistamine koopias ei erine praktiliselt tavapärasest stsenaariumist, seega me seda siin üksikasjalikult ei käsitle. Kui midagi, siis seda protsessi kirjeldatakse artiklis "'.
Ainus erinevus on see, et me loome kaardistamise menüüs "Replication Mapping".
Panime paika kaardistamise ja andsime LUN-i hostile. Peremees nägi LUN-i.
Vormindame selle kohalikku failisüsteemi.
See on kõik, seadistamine on lõpetatud. Katsed tulevad järgmisena.
Katsetamine
Testime kolme peamist stsenaariumi.
- Regulaarne rollivahetus Sekundaarne > Esmane. Regulaarne rollivahetus on vajalik juhuks, kui peame näiteks põhiandmekeskuses tegema ennetavaid toiminguid ja selle aja jooksul, et andmed oleksid kättesaadavad, kanname koormuse varuandmekeskusesse.
- Hädaolukorra rollivahetus Sekundaarne > Esmane (andmekeskuse rike). See on peamine stsenaarium, mille jaoks on olemas replikatsioon, mis võib aidata üle elada andmekeskuse täieliku rikke ilma ettevõtet pikemaks ajaks peatamata.
- Sidekanalite jaotus andmekeskuste vahel. Kahe salvestussüsteemi õige käitumise kontrollimine tingimustes, kus andmekeskuste vaheline sidekanal mingil põhjusel puudub (näiteks ekskavaator kaevas valesse kohta ja lõhkus tumeda optika).
Esiteks hakkame oma LUN-i andmeid kirjutama (juhuslike andmetega failide kirjutamine). Näeme kohe, et salvestussüsteemide vahelist sidekanalit kasutatakse. Seda on lihtne mõista, kui avate replikatsiooni eest vastutavate portide koormuse jälgimise.
Mõlemal salvestussüsteemil on nüüd "kasulikud" andmed, saame testiga alustada.
Vaatame igaks juhuks mõne faili räsisummasid ja paneme need kirja.
Regulaarne rollivahetus
Rollide vahetamist (replikatsiooni suuna muutmist) saab teha mis tahes salvestussüsteemiga, kuid peate siiski kasutama mõlemat, kuna peate esmasel puhul kaardistamise keelama ja teiseses (millest saab esmane) lubama. ).
Võib-olla tekib nüüd mõistlik küsimus: miks mitte seda automatiseerida? Vastus on: see on lihtne, replikatsioon on lihtne katastroofidele vastupidavuse vahend, mis põhineb ainult käsitsi toimingutel. Nende toimingute automatiseerimiseks on olemas metroklastri režiim, see on täielikult automatiseeritud, kuid selle konfigureerimine on palju keerulisem. Metroklastri loomisest kirjutame järgmises artiklis.
Põhisalvestussüsteemis keelame kaardistamise, et tagada salvestamise peatumine.
Seejärel valige ühes salvestussüsteemis (pole oluline, kas põhi- või varukoopias) menüüs „Kaugreplikatsioon” meie ühendus REPL1 ja klõpsake nuppu „Muuda rolli”.
Mõne sekundi pärast muutub LUN1R (varusalvestussüsteem) esmaseks.
Kaardistame LUN1R salvestussüsteemiga2.
Pärast seda ühendatakse meie E: draiv automaatselt hostiga, ainult seekord "saabus" see LUN1R-st.
Igaks juhuks võrdleme räsisummasid.
Identselt. Test läbitud.
Ebaõnnestumine. Andmekeskuse rike
Hetkel on põhiliseks salvestussüsteemiks peale tavalist ümberlülitamist vastavalt salvestussüsteem 2 ja LUN1R. Õnnetuse jäljendamiseks lülitame mõlema mälupuldi2 toite välja.
Sellele pole enam juurdepääsu.
Vaatame, mis toimub salvestussüsteemis 1 (praegu varusüsteem).
Näeme, et esmane LUN (LUN1R) pole saadaval. Logidesse, teabepaneelile ja ka replikatsioonireeglile ilmus veateade. Seetõttu pole hosti andmed praegu saadaval.
Muutke LUN1 rolliks esmane.
Tegelen kaardistamisega peremehele.
Veenduge, et hostile ilmuks draiv E.
Kontrollime räsi.
Kõik on korras. Salvestussüsteem elas edukalt üle aktiivse andmekeskuse kukkumise. Ligikaudne aeg, mille kulutasime replikatsiooni "pööramiseks" ja LUN-i ühendamiseks varuandmekeskusest, oli umbes 3 minutit. On selge, et reaalses tootmises on kõik palju keerulisem ja lisaks salvestussüsteemidega toimingutele peate tegema palju rohkem toiminguid võrgus, hostides, rakendustes. Ja elus on see aeg palju pikem.
Siin tahaksin kirjutada, et kõik, test on edukalt läbitud, kuid ärgem kiirustagem. Peamine salvestussüsteem "valeb", me teame, et kui see "kukkus", oli see esmases rollis. Mis juhtub, kui see äkki lülitub sisse? Seal on kaks peamist rolli, mis võrdub andmete rikkumisega? Kontrollime seda kohe.
Lülitagem järsku sisse aluseks olev salvestussüsteem.
See laadib mõne minuti ja naaseb seejärel pärast lühikest sünkroonimist teenindusse, kuid teisese funktsioonina.
Kõik OK. Aju lõhenenud ei juhtunud. Mõtlesime sellele ja alati pärast kukkumist tõuseb salvestussüsteem Sekundaarse rolli, olenemata sellest, mis rolli see "elu jooksul" mängis. Nüüd võime kindlalt väita, et andmekeskuse rikketest oli edukas.
Andmekeskuste vaheliste sidekanalite rike
Selle testi põhiülesanne on veenduda, et salvestussüsteem ei hakkaks imelikult käituma, kui see ajutiselt kahe salvestussüsteemi vahelised sidekanalid kaotab ja seejärel uuesti ilmub.
Niisiis. Ühendame lahti hoiusüsteemide vahelised juhtmed (kujutame ette, et need kaevas ekskavaator).
Põhikoolis näeme, et sekundaarkooliga puudub seos.
Teises õppeastmes näeme, et põhikooliga puudub seos.
Kõik töötab hästi ja jätkame andmete kirjutamist põhisalvestussüsteemi, see tähendab, et need erinevad tagavarasüsteemist, see tähendab, et need on "eraldunud".
Mõne minuti pärast "remondime" sidekanali. Niipea, kui salvestussüsteemid üksteist näevad, aktiveeritakse andmete sünkroonimine automaatselt. Siin ei nõuta administraatorilt midagi.
Mõne aja pärast on sünkroonimine lõpule viidud.
Ühendus taastus, sidekanalite kadumine eriolukordi ei põhjustanud ning peale sisselülitamist toimus sünkroniseerimine automaatselt.
Järeldused
Analüüsisime teooriat – mida ja miks on vaja, kus on plussid ja kus miinused. Seejärel seadistame sünkroonse replikatsiooni kahe salvestussüsteemi vahel.
Järgmisena viidi läbi põhitestid normaalse kommutatsiooni, andmekeskuse rikke ja sidekanali rikke kohta. Kõigil juhtudel töötas salvestussüsteem hästi. Andmete kadu ei toimu ja haldustoimingud on käsitsi stsenaariumi puhul minimaalsed.
Järgmisel korral teeme olukorra keerulisemaks ja näitame, kuidas kogu see loogika töötab automatiseeritud metroklastris aktiivne-aktiivne režiimis ehk siis, kui mõlemad salvestussüsteemid on primaarsed ja käitumine salvestussüsteemi rikete korral on täielikult automatiseeritud.
Kirjutage kommentaare, võtame hea meelega vastu mõistlikku kriitikat ja praktilisi nõuandeid.
Järgmise korrani.
Allikas: www.habr.com