Pozdravljeni, bralci Habra! Tema tega članka bo implementacija orodij za obnovitev po katastrofi v sistemih za shranjevanje AERODISK Engine. Sprva smo želeli v enem članku pisati o obeh orodjih: replikaciji in metroclusterju, vendar se je članek žal izkazal za predolg, zato smo članek razdelili na dva dela. Pojdimo od preprostega k zapletenemu. V tem članku bomo nastavili in preizkusili sinhrono replikacijo – izpustili bomo en podatkovni center, prekinili pa bomo tudi komunikacijski kanal med podatkovnimi centri in videli, kaj se bo zgodilo.
Naše stranke nam pogosto postavljajo različna vprašanja o replikaciji, zato vam bomo, preden preidemo na nastavitev in testiranje implementacije replik, povedali nekaj o tem, kaj je replikacija v skladišču.
Malo teorije
Replikacija v sistemih za shranjevanje je neprekinjen proces zagotavljanja istovetnosti podatkov na več sistemih za shranjevanje hkrati. Tehnično se replikacija izvede na dva načina.
Sinhrono podvajanje – to je kopiranje podatkov iz glavnega pomnilniškega sistema v rezervnega, čemur sledi obvezna potrditev iz obeh pomnilniških sistemov, da so podatki zabeleženi in potrjeni. Podatki se štejejo za zabeležene in se z njimi lahko dela po potrditvi na obeh straneh (obeh sistemih za shranjevanje). To zagotavlja zajamčeno identiteto podatkov na vseh sistemih za shranjevanje, ki sodelujejo v repliki.
Prednosti te metode:
- Podatki so vedno enaki na vseh sistemih za shranjevanje
Cons:
- Visoki stroški rešitve (hitri komunikacijski kanali, draga optična vlakna, dolgovalovni sprejemniki ipd.)
- Omejitve razdalje (znotraj več deset kilometrov)
- Ni zaščite pred logičnimi poškodbami podatkov (če so podatki poškodovani (namenoma ali po nesreči) na glavnem pomnilniškem sistemu, se bodo samodejno in takoj poškodovali na rezervnem, saj so podatki vedno enaki (to je paradoks)
Asinhrono podvajanje – to je tudi kopiranje podatkov iz glavnega pomnilniškega sistema v rezervnega, vendar z določenim zamikom in brez potrditve zapisa na drugi strani. S podatki lahko delate takoj po zapisu v glavni pomnilniški sistem, na rezervnem pomnilniškem sistemu pa bodo podatki na voljo čez nekaj časa. Identiteta podatkov v tem primeru seveda sploh ni zagotovljena. Podatki v sistemu za shranjevanje varnostnih kopij so vedno malo »v preteklosti«.
Prednosti asinhronega podvajanja:
- Nizkocenovna rešitev (poljubni komunikacijski kanali, optika po izbiri)
- Brez omejitev razdalje
- Na rezervnem pomnilniškem sistemu se podatki ne pokvarijo, če so poškodovani na glavnem (vsaj za nekaj časa); če se podatki poškodujejo, lahko repliko vedno zaustavite, da preprečite poškodbe podatkov na rezervnem pomnilniškem sistemu
Cons:
- Podatki v različnih podatkovnih centrih niso vedno enaki
Tako je izbira načina replikacije odvisna od poslovnih ciljev. Če je za vas ključnega pomena, da rezervni podatkovni center vsebuje popolnoma enake podatke kot glavni podatkovni center (tj. poslovna zahteva za RPO = 0), potem boste morali odšteti denar in se sprijazniti z omejitvami sinhronega replika. In če je zamuda v stanju podatkov sprejemljiva ali preprosto ni denarja, potem morate vsekakor uporabiti asinhrono metodo.
Ločeno izpostavimo tudi tak način (natančneje topologijo) kot metrocluster. V načinu metrocluster se uporablja sinhrona replikacija, vendar za razliko od navadne replike metrocluster omogoča, da oba sistema za shranjevanje delujeta v aktivnem načinu. Tisti. nimate ločitve med aktivnimi in pripravljenimi podatkovnimi centri. Aplikacije delujejo hkrati z dvema sistemoma za shranjevanje, ki sta fizično locirana v različnih podatkovnih centrih. Časi izpadov med nesrečami v taki topologiji so zelo majhni (RTO, običajno minute). V tem članku ne bomo obravnavali naše implementacije metroclustra, ker je to zelo obsežna in obsežna tema, zato ji bomo posvetili ločen, naslednji članek, v nadaljevanju tega.
Prav tako se zelo pogosto, ko govorimo o podvajanju z uporabo sistemov za shranjevanje, veliko ljudi razumno vpraša: > »Veliko aplikacij ima lastna orodja za podvajanje, zakaj uporabljati podvajanje v sistemih za shranjevanje? Je bolje ali slabše?
Tukaj ni jasnega odgovora, zato so tukaj argumenti ZA in PROTI:
Argumenti ZA replikacijo shranjevanja:
- Enostavnost rešitve. Z enim orodjem lahko posnemate celoten nabor podatkov, ne glede na vrsto obremenitve in aplikacijo. Če uporabljate repliko iz aplikacij, boste morali konfigurirati vsako aplikacijo posebej. Če sta več kot 2, potem je to izjemno delovno intenzivno in drago (replikacija aplikacije običajno zahteva ločeno in ne brezplačno licenco za vsako aplikacijo. A več o tem spodaj).
- Posnemite lahko karkoli - katero koli aplikacijo, kateri koli podatek - in vedno bo dosledno. Veliko (večina) aplikacij nima zmožnosti replikacije in replike iz sistema za shranjevanje so edini način za zagotavljanje zaščite pred katastrofami.
- Funkcionalnosti replikacije aplikacij ni treba preplačati. Praviloma ni poceni, tako kot licence za repliko pomnilniškega sistema. Toda licenco za replikacijo pomnilnika morate plačati enkrat, licenco za repliko aplikacije pa je treba kupiti za vsako aplikacijo posebej. Če je takšnih aplikacij veliko, potem stane precej peni in stroški licenc za replikacijo pomnilnika postanejo kaplja v vedro.
Argumenti PROTI podvajanju shranjevanja:
- Replika preko aplikacij ima več funkcionalnosti z vidika samih aplikacij, aplikacija bolje pozna svoje podatke (očitno), zato je več možnosti za delo z njimi.
- Proizvajalci nekaterih aplikacij ne jamčijo za doslednost svojih podatkov, če je podvajanje izvedeno z orodji tretjih oseb. *
* - kontroverzna teza. Na primer, znani proizvajalec DBMS že zelo dolgo uradno izjavlja, da je njihov DBMS mogoče normalno replicirati le z njihovimi sredstvi, ostalo podvajanje (vključno s sistemi za shranjevanje) pa "ne drži". Toda življenje je pokazalo, da temu ni tako. Najverjetneje (vendar to ni gotovo) to preprosto ni najbolj pošten poskus, da bi strankam prodali več licenc.
Posledično je v večini primerov podvajanje iz sistema za shranjevanje boljše, ker To je enostavnejša in cenejša možnost, vendar obstajajo zapleteni primeri, ko je potrebna posebna funkcionalnost aplikacije in je treba delati s podvajanjem na ravni aplikacije.
Končano s teorijo, zdaj praksa
Repliko bomo konfigurirali v našem laboratoriju. V laboratorijskih pogojih smo emulirali dva podatkovna centra (v resnici dva sosednja regala, ki sta na videz v različnih zgradbah). Stojalo sestavljata dva sistema za shranjevanje Engine N2, ki sta med seboj povezana z optičnimi kabli. Fizični strežnik z operacijskim sistemom Windows Server 2016 je povezan z obema sistemoma za shranjevanje prek 10 Gb Etherneta. Stojalo je precej preprosto, a to ne spremeni bistva.
Shematično je videti takole:
Logično je replikacija organizirana na naslednji način:
Zdaj pa si poglejmo funkcijo replikacije, ki jo imamo zdaj.
Podprta sta dva načina: asinhroni in sinhroni. Logično je, da je sinhroni način omejen z razdaljo in komunikacijskim kanalom. Zlasti sinhroni način zahteva uporabo optičnih vlaken kot fizike in 10 Gigabit Ethernet (ali več).
Podprta razdalja za sinhrono replikacijo je 40 kilometrov, vrednost zakasnitve optičnega kanala med podatkovnimi centri je do 2 milisekundi. Na splošno bo delovalo z velikimi zakasnitvami, potem pa bodo med snemanjem močne upočasnitve (kar je tudi logično), tako da, če načrtujete sinhrono replikacijo med podatkovnimi centri, preverite kakovost optike in zakasnitve.
Zahteve za asinhrono podvajanje niso tako resne. Natančneje, sploh jih ni. Vsaka delujoča povezava Ethernet bo zadostovala.
Trenutno sistem za shranjevanje AERODISK ENGINE podpira replikacijo za blokovne naprave (LUN) prek protokola Ethernet (po bakreni ali optični povezavi). Za projekte, kjer je potrebna replikacija preko SAN fabric over Fibre Channel, trenutno dodajamo ustrezno rešitev, ki pa še ni pripravljena, torej v našem primeru samo Ethernet.
Replikacija lahko deluje med vsemi sistemi za shranjevanje serije ENGINE (N1, N2, N4) od mlajših sistemov do starejših in obratno.
Funkcionalnost obeh načinov replikacije je popolnoma enaka. Spodaj je več podrobnosti o tem, kaj je na voljo:
- Replikacija »ena na ena« ali »ena na ena«, torej klasična različica z dvema podatkovnima središčema, glavnim in rezervnim
- Replikacija je »ena proti mnogim« ali »ena proti mnogim«, tj. en LUN je mogoče podvojiti na več sistemov za shranjevanje hkrati
- Aktivirajte, deaktivirajte in »obrnite« replikacijo, da omogočite, onemogočite ali spremenite smer replikacije
- Podvajanje je na voljo za področja RDG (Raid Distributed Group) in DDP (Dynamic Disk Pool). Vendar pa je LUN-e področja RDG mogoče podvojiti le v drug RDG. Enako z DDP.
Obstaja veliko več majhnih funkcij, vendar jih nima posebnega smisla naštevati; omenili jih bomo med nastavitvijo.
Nastavitev replikacije
Postopek namestitve je precej preprost in je sestavljen iz treh stopenj.
- Nastavitev omrežja
- Nastavitev shranjevanja
- Nastavitev pravil (povezav) in preslikav
Pomembna točka pri nastavitvi replikacije je, da je treba prvi dve stopnji ponoviti na oddaljenem sistemu za shranjevanje, tretjo stopnjo - samo na glavnem.
Nastavitev omrežnih virov
Prvi korak je konfiguracija omrežnih vrat, prek katerih se bo prenašal promet podvajanja. Če želite to narediti, morate omogočiti vrata in nastaviti njihove naslove IP v razdelku Front-end adapterji.
Po tem moramo ustvariti bazen (v našem primeru RDG) in virtualni IP za replikacijo (VIP). VIP je plavajoči naslov IP, ki je povezan z dvema "fizičnima" naslovoma krmilnikov za shranjevanje (vrata, ki smo jih pravkar konfigurirali). To bo glavni vmesnik za replikacijo. Prav tako lahko delujete ne z VIP, ampak z VLAN, če morate delati z označenim prometom.
Postopek ustvarjanja VIP za repliko se ne razlikuje veliko od ustvarjanja VIP za V/I (NFS, SMB, iSCSI). V tem primeru ustvarimo običajni VIP (brez VLAN), vendar ne pozabite označiti, da je za replikacijo (brez tega kazalca v naslednjem koraku ne bomo mogli dodati VIP-ja pravilu).
VIP mora biti v istem podomrežju kot vrata IP, med katerimi lebdi.
Te nastavitve ponovimo na oddaljenem sistemu za shranjevanje, seveda z drugim IP-jem.
VIP-ji iz različnih sistemov za shranjevanje so lahko v različnih podomrežjih, glavna stvar je, da med njimi obstaja usmerjanje. V našem primeru je ta primer natančno prikazan (192.168.3.XX in 192.168.2.XX)
S tem je priprava omrežnega dela zaključena.
Nastavitev shrambe
Nastavitev pomnilnika za repliko se od običajne razlikuje le po tem, da preslikavo opravimo preko posebnega menija “Preslikava replikacije”. Sicer je vse enako kot pri običajni nastavitvi. Zdaj pa po vrsti.
V predhodno ustvarjenem področju R02 morate ustvariti LUN. Ustvarimo ga in ga poimenujmo LUN1.
Prav tako moramo ustvariti enak LUN na oddaljenem pomnilniškem sistemu enake velikosti. Mi ustvarjamo. Da ne bo zmede, pokličimo oddaljeni LUN LUN1R
Če bi morali vzeti LUN, ki že obstaja, bi morali med nastavitvijo replike odklopiti ta produktivni LUN iz gostitelja in preprosto ustvariti prazen LUN enake velikosti na oddaljenem sistemu za shranjevanje.
Nastavitev pomnilnika je končana, pojdimo na ustvarjanje pravila podvajanja.
Nastavitev pravil podvajanja ali povezav podvajanja
Po izdelavi LUN-ov na pomnilniškem sistemu, ki bo trenutno primarni, konfiguriramo replikacijsko pravilo LUN1 na pomnilniškem sistemu 1 na LUN1R na pomnilniškem sistemu 2.
Nastavitev se izvede v meniju “Remote replication”.
Ustvarimo pravilo. Če želite to narediti, morate določiti prejemnika replike. Tam nastavimo tudi ime povezave in vrsto replikacije (sinhrono ali asinhrono).
V polje “oddaljeni sistemi” dodamo naš sistem za shranjevanje2. Za dodajanje morate uporabiti upravljanje sistemov za shranjevanje IP (MGR) in ime oddaljenega LUN-a, v katerega bomo izvajali replikacijo (v našem primeru LUN1R). Nadzorni IP-ji so potrebni samo na stopnji dodajanja povezave; prek njih se ne bo prenašal promet replikacije, za to bo uporabljen predhodno konfiguriran VIP.
Že na tej stopnji lahko dodamo več kot en oddaljeni sistem za topologijo "ena proti več": kliknite gumb "dodaj vozlišče", kot je prikazano na spodnji sliki.
V našem primeru je samo en daljinski sistem, zato se omejimo na to.
Pravilo je pripravljeno. Upoštevajte, da se samodejno doda vsem udeležencem replikacije (v našem primeru sta dva). Ustvarite lahko poljubno število takih pravil za poljubno število LUN-ov in v kateri koli smeri. Na primer, za uravnoteženje obremenitve lahko repliciramo del LUN-ov iz sistema za shranjevanje 1 v sistem za shranjevanje 2, drugi del pa, nasprotno, iz sistema za shranjevanje 2 v sistem za shranjevanje 1.
Sistem za shranjevanje 1. Takoj po ustvarjanju se je začela sinhronizacija.
Sistem za shranjevanje 2. Vidimo isto pravilo, vendar se je sinhronizacija že končala.
LUN1 v pomnilniškem sistemu 1 ima primarno vlogo, kar pomeni, da je aktiven. LUN1R na pomnilniškem sistemu 2 je v vlogi sekundarja, to pomeni, da je v stanju pripravljenosti, če pomnilniški sistem 1 odpove.
Zdaj lahko naš LUN povežemo z gostiteljem.
Povezali se bomo preko iSCSI, lahko pa tudi preko FC. Nastavitev preslikave prek iSCSI LUN v replici se praktično ne razlikuje od običajnega scenarija, zato tega tukaj ne bomo podrobno obravnavali. Če kaj, je ta postopek opisan v članku "".
Edina razlika je v tem, da preslikavo ustvarimo v meniju »Preslikava replikacije«.
Nastavili smo preslikavo in gostitelju dali LUN. Gostitelj je videl LUN.
Formatiramo ga v lokalni datotečni sistem.
To je to, nastavitev je končana. Sledijo testi.
Testiranje
Preizkusili bomo tri glavne scenarije.
- Redno menjavanje vlog Sekundarni > Primarni. Redno menjavanje vlog je potrebno, če na primer moramo opraviti nekaj preventivnih operacij v glavnem podatkovnem centru in v tem času, da so podatki na voljo, prenesemo obremenitev na rezervni podatkovni center.
- Zamenjava vlog v sili Sekundarni > Primarni (napaka podatkovnega centra). To je glavni scenarij, za katerega obstaja replikacija, ki lahko pomaga preživeti popolno okvaro podatkovnega centra, ne da bi podjetje ustavilo za daljše obdobje.
- Razpad komunikacijskih kanalov med podatkovnimi centri. Preverjanje pravilnega obnašanja dveh sistemov za shranjevanje v pogojih, ko iz nekega razloga komunikacijski kanal med podatkovnima centrima ni na voljo (na primer bager je kopal na napačnem mestu in zlomil temno optiko).
Najprej bomo začeli pisati podatke v naš LUN (zapisati datoteke z naključnimi podatki). Takoj vidimo, da je komunikacijski kanal med sistemi za shranjevanje izkoriščen. To je enostavno razumeti, če odprete nadzor obremenitve vrat, ki so odgovorna za replikacijo.
Oba sistema za shranjevanje imata zdaj "uporabne" podatke, lahko začnemo s testom.
Za vsak slučaj poglejmo zgoščene vsote ene od datotek in jih zapišimo.
Redno menjavanje vlog
Operacijo preklapljanja vlog (spreminjanje smeri replikacije) lahko izvedete s katerim koli sistemom za shranjevanje, vendar boste vseeno morali iti na oba, saj boste morali onemogočiti preslikavo na primarnem in omogočiti na sekundarnem (ki bo postal primarni ).
Morda se zdaj pojavi razumno vprašanje: zakaj ne bi tega avtomatizirali? Odgovor je: preprosto je, replikacija je preprosto sredstvo odpornosti na nesreče, ki temelji izključno na ročnih operacijah. Za avtomatizacijo teh operacij obstaja način metrocluster; je popolnoma avtomatiziran, vendar je njegova konfiguracija veliko bolj zapletena. O postavitvi metroclustra bomo pisali v naslednjem članku.
V glavnem sistemu za shranjevanje onemogočimo preslikavo, da zagotovimo, da se snemanje ustavi.
Nato na enem od sistemov za shranjevanje (ni pomembno, na glavnem ali rezervnem) v meniju »Oddaljena replikacija« izberite našo povezavo REPL1 in kliknite »Spremeni vlogo«.
Po nekaj sekundah LUN1R (rezervni sistem za shranjevanje) postane primarni.
Preslikamo LUN1R s sistemom za shranjevanje2.
Po tem se naš pogon E: samodejno priključi na gostitelja, le da je tokrat »prispel« iz LUN1R.
Za vsak slučaj primerjamo zgoščene vsote.
Enako. Test opravljen.
Failover. Okvara podatkovnega centra
Trenutno je glavni sistem za shranjevanje po rednem preklopu sistem za shranjevanje 2 oziroma LUN1R. Za posnemanje nesreče bomo izklopili napajanje obeh krmilnikov za shranjevanje2.
Ni več dostopa do njega.
Poglejmo, kaj se dogaja na pomnilniškem sistemu 1 (trenutno rezervnem).
Vidimo, da primarni LUN (LUN1R) ni na voljo. Sporočilo o napaki se je pojavilo v dnevnikih, na informacijski plošči in tudi v samem pravilu replikacije. V skladu s tem podatki iz gostitelja trenutno niso na voljo.
Spremenite vlogo LUN1 v Primarno.
Delam preslikavo na gostitelja.
Prepričajte se, da je pogon E prikazan na gostitelju.
Preverimo hash.
Vse je vredu. Shranjevalni sistem je uspešno prestal padec podatkovnega centra, ki je bil aktiven. Približen čas, ki smo ga porabili za povezovanje »obrata« replikacije in povezovanje LUN-a iz rezervnega podatkovnega centra, je bil približno 3 minute. Jasno je, da je v resnični proizvodnji vse veliko bolj zapleteno in poleg dejanj s sistemi za shranjevanje morate izvesti veliko več operacij v omrežju, na gostiteljih, v aplikacijah. In v življenju bo to obdobje veliko daljše.
Tukaj bi rad napisal, da je vse, test je bil uspešno opravljen, vendar ne hitimo. Glavni sistem za shranjevanje "leži", vemo, da ko je "padel", je bil v vlogi Primary. Kaj se zgodi, če se nenadoma vklopi? Obstajata dve glavni vlogi, kar je enako poškodovanju podatkov? Preverimo zdaj.
Nenadoma vklopimo osnovni sistem za shranjevanje.
Nalaga se nekaj minut, nato pa se po kratki sinhronizaciji vrne v storitev, vendar v vlogi sekundarja.
Vse v redu. Razcepljeni možgani se niso zgodili. Razmišljali smo o tem in vedno po padcu se sistem za shranjevanje dvigne v vlogo sekundarnega, ne glede na to, kakšno vlogo je imel »v življenju«. Zdaj lahko z gotovostjo trdimo, da je bil test napak podatkovnega centra uspešen.
Izpad komunikacijskih kanalov med podatkovnimi centri
Glavna naloga tega preizkusa je zagotoviti, da se sistem za shranjevanje ne začne čudno obnašati, če začasno izgubi komunikacijske kanale med dvema sistemoma za shranjevanje in se nato znova pojavi.
torej. Odklopimo žice med sistemi za shranjevanje (predstavljajmo si, da jih je izkopal bager).
Na primarnem vidimo, da ni povezave s sekundarnim.
Na sekundarnem vidimo, da ni povezave s primarnim.
Vse deluje v redu in še naprej pišemo podatke v glavni sistem za shranjevanje, to pomeni, da se zajamčeno razlikujejo od varnostnega, to je, da so se "ločili".
V nekaj minutah “popravimo” komunikacijski kanal. Takoj, ko se sistema za shranjevanje vidita, se samodejno aktivira sinhronizacija podatkov. Od administratorja tukaj ni potrebno ničesar.
Po določenem času je sinhronizacija končana.
Povezava je bila obnovljena, izguba komunikacijskih kanalov ni povzročila izrednih situacij, po vklopu pa je sinhronizacija potekala samodejno.
Ugotovitve
Analizirali smo teorijo - kaj je potrebno in zakaj, kje so prednosti in kje slabosti. Nato vzpostavimo sinhrono replikacijo med dvema sistemoma za shranjevanje.
Nato so bili izvedeni osnovni testi za normalno preklapljanje, okvaro podatkovnega centra in okvaro komunikacijskega kanala. V vseh primerih je sistem za shranjevanje dobro deloval. Pri ročnem scenariju ni izgube podatkov in administrativne operacije so čim manjše.
Naslednjič bomo zapletli situacijo in pokazali, kako vsa ta logika deluje v avtomatiziranem metroclusterju v aktivno-aktivnem načinu, to je, ko sta oba sistema za shranjevanje primarna in je vedenje v primeru okvar sistema za shranjevanje popolnoma avtomatizirano.
Napišite komentarje, veseli bomo tehtnih kritik in praktičnih nasvetov.
Do naslednjič.
Vir: www.habr.com