Hallo, Habr-lesers! Die onderwerp van hierdie artikel is die implementering van rampherstelnutsgoed in AERODISK Engine-bergingstelsels. Aanvanklik wou ons in een artikel oor beide instrumente skryf: replikasie en metrocluster, maar ongelukkig het die artikel te lank geblyk te wees, daarom het ons die artikel in twee dele verdeel. Kom ons gaan van eenvoudig na kompleks. In hierdie artikel sal ons sinchroniese replikasie opstel en toets - ons sal een datasentrum laat vaar, en ook die kommunikasiekanaal tussen die datasentrums breek en kyk wat gebeur.
Ons kliënte vra ons dikwels verskeie vrae oor replikasie, dus voordat ons verder gaan met die opstel en toets van die implementering van replikas, sal ons jou 'n bietjie vertel oor wat replikasie in berging is.
'N bietjie teorie
Replikasie in bergingstelsels is 'n deurlopende proses om data-identiteit op verskeie bergingstelsels gelyktydig te verseker. Tegnies word replikasie op twee maniere bewerkstellig.
Sinchroniese replikasie – dit is die kopiëring van data vanaf die hoofbergingstelsel na die rugsteunstelsel, gevolg deur verpligte bevestiging van beide bergingstelsels dat die data aangeteken en bevestig is. Dit is na bevestiging aan beide kante (albei stoorstelsels) dat die data as aangeteken beskou word en mee gewerk kan word. Dit verseker gewaarborgde data-identiteit op alle bergingstelsels wat aan die replika deelneem.
Die voordele van hierdie metode:
- Data is altyd identies op alle bergingstelsels
Nadele:
- Hoë koste van die oplossing (vinnige kommunikasiekanale, duur optiese vesel, langgolf-ontvangers, ens.)
- Afstandbeperkings (binne etlike tientalle kilometers)
- Daar is geen beskerming teen logiese data-korrupsie nie (as data op die hoofbergingstelsel (opsetlik of per ongeluk) beskadig word, sal dit outomaties en onmiddellik op die rugsteun een beskadig word, aangesien die data altyd identies is (dit is die paradoks)
Asinchroniese replikasie – dit is ook die kopiëring van data van die hoofbergingstelsel na die rugsteunstelsel, maar met 'n sekere vertraging en sonder dat dit nodig is om die skryf aan die ander kant te bevestig. Jy kan dadelik met data werk nadat jy dit na die hoofbergingstelsel opgeneem het, en op die rugsteunbergingstelsel sal die data na 'n geruime tyd beskikbaar wees. Die identiteit van die data in hierdie geval is natuurlik glad nie verseker nie. Die data op die rugsteunbergingstelsel is altyd 'n bietjie "in die verlede."
Voordele van asinchroniese replikasie:
- Laekoste-oplossing (enige kommunikasiekanale, optika opsioneel)
- Geen afstandbeperkings nie
- Op die rugsteunbergingstelsel gaan data nie agteruit as dit op die hoof een beskadig word nie (ten minste vir 'n geruime tyd); as die data korrup raak, kan jy altyd die replika stop om datakorrupsie op die rugsteunbergingstelsel te voorkom
Nadele:
- Data in verskillende datasentrums is altyd nie identies nie
Die keuse van replikasiemodus hang dus af van besigheidsdoelwitte. As dit vir jou van kritieke belang is dat die rugsteundatasentrum presies dieselfde data as die hoofdatasentrum bevat (d.w.s. besigheidsvereiste vir RPO = 0), dan sal jy die kontant moet opdok en die beperkings van 'n sinchroniese replika. En as die vertraging in die datatoestand aanvaarbaar is of daar eenvoudig geen geld is nie, moet u beslis die asynchrone metode gebruik.
Laat ons ook so 'n modus (meer presies 'n topologie) as 'n metrocluster uitlig. In metrocluster-modus word sinchroniese replikasie gebruik, maar, anders as 'n gewone replika, laat 'n metrocluster beide bergingstelsels toe om in aktiewe modus te werk. Dié. jy het nie 'n skeiding tussen aktiewe en bystand-datasentrums nie. Toepassings werk gelyktydig met twee stoorstelsels, wat fisies in verskillende datasentrums geleë is. Stilstandtyd tydens ongelukke in so 'n topologie is baie klein (RTO, gewoonlik minute). In hierdie artikel sal ons nie ons implementering van die metrocluster oorweeg nie, aangesien dit 'n baie groot en ruim onderwerp is, daarom sal ons 'n aparte, volgende artikel daaraan wy, in voortsetting van hierdie een.
Ook, baie dikwels, wanneer ons praat oor replikasie deur gebruik te maak van bergingstelsels, het baie mense 'n redelike vraag: > "Baie toepassings het hul eie replikasie-instrumente, hoekom gebruik replikasie op stoorstelsels? Is dit beter of slegter?
Daar is geen duidelike antwoord hier nie, so hier is die argumente VIR en nadele:
Argumente VIR stoorreplikasie:
- Eenvoud van die oplossing. Met een instrument kan jy jou hele datastel herhaal, ongeag die tipe vrag en toepassing. As jy 'n replika van toepassings gebruik, sal u elke toepassing afsonderlik moet opstel. As daar meer as 2 van hulle is, dan is dit uiters arbeidsintensief en duur (aansoekreplikasie vereis gewoonlik 'n aparte en nie gratis lisensie vir elke aansoek nie. Maar meer daaroor hieronder).
- Jy kan enigiets herhaal - enige toepassing, enige data - en dit sal altyd konsekwent wees. Baie (meeste) toepassings het nie replikasievermoëns nie, en replikas van die bergingstelsel is die enigste manier om beskerming teen rampe te bied.
- Dit is nie nodig om te veel te betaal vir toepassingsreplikasie-funksionaliteit nie. As 'n reël is dit nie goedkoop nie, net soos lisensies vir 'n replika van 'n stoorstelsel. Maar jy moet een keer vir 'n lisensie vir bergingsreplikasie betaal, en 'n lisensie vir toepassingsreplika moet afsonderlik vir elke toepassing gekoop word. As daar baie sulke toepassings is, kos dit 'n mooi sent en die koste van lisensies vir stoorreplikasie word 'n druppel in die emmer.
Argumente TEEEN stoorreplikasie:
- Replika deur toepassings het meer funksionaliteit vanuit die oogpunt van die toepassings self, die toepassing ken sy data beter (natuurlik), so daar is meer opsies om daarmee te werk.
- Vervaardigers van sommige toepassings waarborg nie die konsekwentheid van hul data as replikasie met behulp van derdeparty-nutsgoed gedoen word nie. *
* - kontroversiële tesis. Byvoorbeeld, 'n bekende DBMS-vervaardiger verklaar al 'n baie lang tyd amptelik dat hul DBMS slegs normaalweg met hul middele gerepliseer kan word, en die res van die replikasie (insluitend bergingstelsels) is "nie waar nie." Maar die lewe het gewys dat dit nie so is nie. Heel waarskynlik (maar dit is nie seker nie) is dit eenvoudig nie die eerlikste poging om meer lisensies aan kliënte te verkoop nie.
As gevolg hiervan is replikasie van die stoorstelsel in die meeste gevalle beter, want Dit is 'n eenvoudiger en goedkoper opsie, maar daar is komplekse gevalle wanneer spesifieke toepassingsfunksionaliteit benodig word, en dit is nodig om met toepassingsvlakreplikasie te werk.
Klaar met teorie, oefen nou
Ons sal die replika in ons laboratorium opstel. In laboratoriumtoestande het ons twee datasentrums nagevolg (in werklikheid twee aangrensende rakke wat in verskillende geboue gelyk het). Die staanplek bestaan uit twee Engine N2-bergingstelsels, wat met optiese kabels aan mekaar verbind is. 'n Fisiese bediener wat Windows Server 2016 gebruik, is met 10 Gb Ethernet aan beide bergingstelsels gekoppel. Die staander is redelik eenvoudig, maar dit verander nie die essensie nie.
Skematies lyk dit so:
Logies is replikasie soos volg georganiseer:
Kom ons kyk nou na die replikasie-funksionaliteit wat ons nou het.
Twee modusse word ondersteun: asinchronies en sinchronies. Dit is logies dat die sinchrone modus beperk word deur afstand en kommunikasiekanaal. In die besonder, sinchroniese modus vereis die gebruik van vesel as die fisika en 10 Gigabit Ethernet (of hoër).
Die ondersteunde afstand vir sinchroniese replikasie is 40 kilometer, die vertragingswaarde van die optiese kanaal tussen datasentrums is tot 2 millisekondes. Oor die algemeen sal dit met groot vertragings werk, maar dan sal daar sterk verlangsamings wees tydens opname (wat ook logies is), so as jy sinchroniese replikasie tussen datasentrums beplan, moet jy die kwaliteit van die optika en die vertragings nagaan.
Die vereistes vir asinchroniese replikasie is nie so ernstig nie. Meer presies, hulle is glad nie daar nie. Enige werkende Ethernet-verbinding sal doen.
Tans ondersteun die AERODISK ENGINE-bergingstelsel replikasie vir bloktoestelle (LUN's) via die Ethernet-protokol (oor koper of opties). Vir projekte waar replikasie deur 'n SAN-stof oor Fibre Channel vereis word, voeg ons tans 'n gepaste oplossing by, maar dit is nog nie gereed nie, so in ons geval, slegs Ethernet.
Replikasie kan werk tussen enige ENGINE-reeks bergingstelsels (N1, N2, N4) van junior stelsels tot ouer stelsels en omgekeerd.
Die funksionaliteit van beide replikasiemodusse is heeltemal identies. Hieronder is meer besonderhede oor wat beskikbaar is:
- Replikasie "een tot een" of "een tot een", dit wil sê die klassieke weergawe met twee datasentrums, die hoof en die rugsteun
- Replikasie is "een tot baie" of "een tot baie", m.a.w. een LUN kan gelyktydig na verskeie bergingstelsels gerepliseer word
- Aktiveer, deaktiveer en "omkeer" replikasie onderskeidelik om die rigting van replikasie te aktiveer, deaktiveer of te verander
- Replikasie is beskikbaar vir beide RDG (Raid Distributed Group) en DDP (Dynamic Disk Pool) poele. LUN's van 'n RDG-poel kan egter slegs na 'n ander RDG gerepliseer word. Dieselfde met DDP.
Daar is baie meer klein kenmerke, maar daar is geen spesifieke punt om hulle te lys nie; ons sal hulle noem soos ons opstel.
Stel replikasie op
Die opstelproses is redelik eenvoudig en bestaan uit drie fases.
- Netwerkkonfigurasie
- Berging opstelling
- Die opstel van reëls (verbindings) en kartering
'n Belangrike punt in die opstel van replikasie is dat die eerste twee stadiums herhaal moet word op die afgeleë bergingstelsel, die derde stadium - slegs op die hoof een.
Opstel van netwerkhulpbronne
Die eerste stap is om die netwerkpoorte op te stel waardeur replikasieverkeer oorgedra sal word. Om dit te kan doen, moet jy die poorte aktiveer en hul IP-adresse in die Voorkant-adapters-afdeling stel.
Hierna moet ons 'n poel (in ons geval RDG) en 'n virtuele IP vir replikasie (VIP) skep. VIP is 'n drywende IP-adres wat gekoppel is aan twee "fisiese" adresse van stoorbeheerders (die poorte wat ons pas gekonfigureer het). Dit sal die hoofreplikasie-koppelvlak wees. Jy kan ook nie met 'n VIP werk nie, maar met 'n VLAN, as jy met gemerkte verkeer moet werk.
Die proses om 'n VIP vir 'n replika te skep, verskil nie veel van die skep van 'n VIP vir I/O (NFS, SMB, iSCSI). In hierdie geval skep ons 'n gewone VIP (sonder VLAN), maar wees seker om aan te dui dat dit vir replikasie is (sonder hierdie wyser sal ons nie VIP by die reël in die volgende stap kan voeg nie).
Die VIP moet in dieselfde subnet wees as die IP-poorte waartussen dit dryf.
Ons herhaal hierdie instellings op 'n afgeleë bergingstelsel, met 'n ander IP, natuurlik.
BBP's van verskillende bergingstelsels kan in verskillende subnette wees, die belangrikste ding is dat daar 'n roete tussen hulle is. In ons geval word hierdie voorbeeld presies getoon (192.168.3.XX en 192.168.2.XX)
Dit voltooi die voorbereiding van die netwerkdeel.
Stel berging op
Die opstel van berging vir 'n replika verskil slegs van gewoonlik deurdat ons die kartering doen deur 'n spesiale spyskaart "Replication Mapping". Andersins is alles dieselfde as met die normale opstelling. Nou, in volgorde.
In die voorheen geskepde poel R02, moet jy 'n LUN skep. Kom ons skep dit en noem dit LUN1.
Ons moet ook dieselfde LUN op 'n afgeleë bergingstelsel van identiese grootte skep. Ons skep. Om verwarring te voorkom, kom ons bel die afgeleë LUN LUN1R
As ons 'n LUN moes neem wat reeds bestaan, sal ons, terwyl ons die replika opstel, hierdie produktiewe LUN van die gasheer moet ontkoppel, en eenvoudig 'n leë LUN van identiese grootte op die afgeleë bergingstelsel moet skep.
Die bergingopstelling is voltooi, kom ons gaan voort met die skep van 'n replikasiereël.
Opstel van replikasiereëls of replikasieskakels
Nadat ons LUN's op die bergingstelsel geskep het, wat op die oomblik die primêre een sal wees, konfigureer ons die replikasiereël LUN1 op stoorstelsel 1 na LUN1R op stoorstelsel 2.
Die instelling word gemaak in die "Remote replikasie"-kieslys
Kom ons skep 'n reël. Om dit te doen, moet jy die ontvanger van die replika spesifiseer. Daar stel ons ook die naam van die verbinding en die tipe replikasie (sinchronies of asinchronies) in.
In die "afgeleë stelsels"-veld voeg ons ons bergingstelsel2 by. Om by te voeg, moet jy die bestuur IP-bergingstelsels (MGR) en die naam van die afgeleë LUN gebruik waarin ons replikasie sal uitvoer (in ons geval, LUN1R). Beheer-IP's word slegs benodig in die stadium van die byvoeging van 'n verbinding; replikasieverkeer sal nie daardeur oorgedra word nie; die voorheen gekonfigureerde VIP sal hiervoor gebruik word.
Reeds op hierdie stadium kan ons meer as een afgeleë stelsel byvoeg vir die "een tot baie" topologie: klik die "voeg node by" knoppie, soos in die figuur hieronder.
In ons geval is daar net een afgeleë stelsel, so ons beperk onsself hiertoe.
Die reël is gereed. Neem asseblief kennis dat dit outomaties bygevoeg word op alle replikasie-deelnemers (in ons geval is daar twee van hulle). Jy kan soveel sulke reëls skep as wat jy wil, vir enige aantal LUN's en in enige rigting. Byvoorbeeld, om die las te balanseer, kan ons 'n deel van die LUN's van bergingstelsel 1 na bergingstelsel 2 repliseer, en die ander deel, inteendeel, van bergingstelsel 2 na bergingstelsel 1.
Bergingstelsel 1. Onmiddellik na die skepping het sinchronisasie begin.
Bergingstelsel 2. Ons sien dieselfde reël, maar sinchronisasie is reeds beëindig.
LUN1 op stoorstelsel 1 is in die Primêre rol, dit wil sê, dit is aktief. LUN1R op stoorstelsel 2 is in die rol van Sekondêr, dit wil sê, dit is op bystand ingeval stoorstelsel 1 misluk.
Nou kan ons ons LUN aan die gasheer koppel.
Ons sal via iSCSI verbind, hoewel dit ook via FC gedoen kan word. Die opstel van kartering via iSCSI LUN in 'n replika verskil feitlik nie van die gewone scenario nie, so ons sal dit nie hier in detail oorweeg nie. As daar iets is, word hierdie proses beskryf in die artikel "".
Die enigste verskil is dat ons kartering in die "Replication Mapping"-kieslys skep
Ons het kartering opgestel en die LUN aan die gasheer gegee. Die gasheer het die LUN gesien.
Ons formateer dit in 'n plaaslike lêerstelsel.
Dit is dit, die opstelling is voltooi. Toetse sal volgende kom.
toets
Ons sal drie hoofscenario's toets.
- Gereelde rolwisseling Sekondêr > Primêr. Gereelde rolwisseling is nodig indien ons byvoorbeeld 'n paar voorkomende bewerkings in die hoofdatasentrum moet uitvoer en gedurende hierdie tyd, sodat die data beskikbaar kan wees, dra ons die las oor na die rugsteundatasentrum.
- Noodrolwisseling Sekondêr > Primêr (datasentrummislukking). Dit is die hoofscenario waarvoor replikasie bestaan, wat kan help om 'n volledige datasentrumfout te oorleef sonder om die maatskappy vir 'n lang tydperk te stop.
- Ontbinding van kommunikasiekanale tussen datasentrums. Kontroleer die korrekte gedrag van twee stoorstelsels in toestande waar die kommunikasiekanaal tussen die datasentrums om een of ander rede nie beskikbaar is nie (byvoorbeeld, 'n graafmasjien het op die verkeerde plek gegrawe en die donker optika gebreek).
Eerstens sal ons begin om data na ons LUN te skryf (skryf lêers met ewekansige data). Ons sien dadelik dat die kommunikasiekanaal tussen die stoorstelsels benut word. Dit is maklik om te verstaan as u die lasmonitering van die poorte wat vir replikasie verantwoordelik is, oopmaak.
Beide bergingstelsels het nou "nuttige" data, ons kan die toets begin.
Net vir ingeval, kom ons kyk na die hash-somme van een van die lêers en skryf dit neer.
Gereelde rolwisseling
Die werking van omskakeling van rolle (verandering van die rigting van replikasie) kan met enige bergingstelsel gedoen word, maar jy sal steeds na albei moet gaan, aangesien jy kartering op Primêr sal moet deaktiveer en dit op Sekondêr (wat Primêr sal word) moet aktiveer ).
Miskien ontstaan 'n redelike vraag nou: hoekom dit nie outomatiseer nie? Die antwoord is: dit is eenvoudig, replikasie is 'n eenvoudige manier van rampveerkragtigheid, wat uitsluitlik op handbewerkings gebaseer is. Om hierdie bedrywighede te outomatiseer, is daar 'n metrocluster-modus; dit is ten volle outomaties, maar die konfigurasie daarvan is baie meer ingewikkeld. Ons sal in die volgende artikel oor die opstel van 'n metrocluster skryf.
Op die hoofbergingstelsel deaktiveer ons kartering om te verseker dat opname stop.
Kies dan op een van die bergingstelsels (dit maak nie saak nie, op die hoof- of rugsteun) in die "Remote replikasie"-kieslys, ons verbinding REPL1 en klik "Verander rol".
Na 'n paar sekondes word LUN1R (rugsteunbergingstelsel) Primêr.
Ons karteer LUN1R met stoorstelsel2.
Hierna word ons E:-stasie outomaties aan die gasheer gekoppel, maar hierdie keer het dit vanaf LUN1R “aangekom”.
Net vir ingeval, ons vergelyk die hash-somme.
Identies. Toets geslaag.
Failover. Datasentrum mislukking
Op die oomblik is die hoofbergingstelsel na gereelde oorskakeling onderskeidelik stoorstelsel 2 en LUN1R. Om 'n ongeluk na te boots, sal ons die krag op beide bergingbeheerders2 afskakel.
Daar is nie meer toegang daartoe nie.
Kom ons kyk wat gebeur op bergingstelsel 1 (die rugsteun een op die oomblik).
Ons sien dat die Primêre LUN (LUN1R) nie beskikbaar is nie. 'n Foutboodskap het in die logs, in die inligtingspaneel en ook in die replikasiereël self verskyn. Gevolglik is data van die gasheer tans nie beskikbaar nie.
Verander die rol van LUN1 na Primêr.
Ek doen kartering aan die gasheer.
Maak seker dat ry E op die gasheer verskyn.
Ons kontroleer die hash.
Alles is reg. Die bergingstelsel het die val van die datasentrum, wat aktief was, suksesvol oorleef. Die benaderde tyd wat ons spandeer het om die replikasie "omkeer" te koppel en die LUN vanaf die rugsteundatasentrum te koppel, was ongeveer 3 minute. Dit is duidelik dat alles in werklike produksie baie meer ingewikkeld is, en benewens aksies met bergingstelsels, moet jy baie meer bewerkings op die netwerk, op gashere, in toepassings uitvoer. En in die lewe sal hierdie tydperk baie langer wees.
Hier wil ek graag skryf dat alles, die toets suksesvol afgehandel is, maar laat ons nie jaag nie. Die hoofbergingstelsel “lieg”, ons weet dat toe dit “geval” het, dit in die Primêre rol was. Wat gebeur as dit skielik aanskakel? Daar sal twee primêre rolle wees, wat gelykstaande is aan datakorrupsie? Kom ons kyk dit nou.
Kom ons skakel skielik die onderliggende bergingstelsel aan.
Dit laai vir 'n paar minute en keer dan terug na diens na 'n kort sinchronisasie, maar in die rol van Sekondêr.
Alles in orde. Gesplete brein het nie gebeur nie. Ons het hieroor gedink, en altyd na 'n val styg die bergingstelsel na die rol van Sekondêr, ongeag watter rol dit in "tydens die lewe" was. Nou kan ons verseker sê dat die datasentrum mislukkingstoets suksesvol was.
Mislukking van kommunikasiekanale tussen datasentrums
Die hooftaak van hierdie toets is om seker te maak dat die stoorstelsel nie vreemd begin optree as dit tydelik kommunikasiekanale tussen twee stoorstelsels verloor en dan weer verskyn nie.
Dus. Ons ontkoppel die drade tussen die stoorstelsels (kom ons stel ons voor dat dit deur 'n graafmachine gegrawe is).
Op Primêr sien ons dat daar geen verband met Sekondêr is nie.
Op Sekondêr sien ons dat daar geen verband met Primêr is nie.
Alles werk goed, en ons gaan voort om data na die hoofbergingstelsel te skryf, dit wil sê, dit is gewaarborg om anders te wees as die rugsteun een, dit wil sê, hulle het "geskei".
Binne 'n paar minute "herstel" ons die kommunikasiekanaal. Sodra die bergingstelsels mekaar sien, word datasinchronisasie outomaties geaktiveer. Niks word hier van die administrateur vereis nie.
Na 'n rukkie is sinchronisasie voltooi.
Die verbinding is herstel, die verlies van kommunikasiekanale het geen noodsituasies veroorsaak nie, en nadat dit aangeskakel is, het sinchronisasie outomaties plaasgevind.
Bevindinge
Ons het die teorie ontleed - wat is nodig en hoekom, waar is die voordele en waar is die nadele. Dan stel ons sinchrone replikasie tussen twee stoorstelsels op.
Vervolgens is basiese toetse uitgevoer vir normale skakeling, datasentrummislukking en kommunikasiekanaalmislukking. In alle gevalle het die bergingstelsel goed gewerk. Daar is geen dataverlies nie en administratiewe bedrywighede word tot 'n minimum beperk vir 'n handmatige scenario.
Volgende keer sal ons die situasie kompliseer en wys hoe al hierdie logika werk in 'n outomatiese metrocluster in aktief-aktiewe modus, dit wil sê wanneer beide bergingstelsels primêr is, en die gedrag in geval van stoorstelselfoute ten volle geoutomatiseer is.
Skryf asseblief kommentaar, ons sal bly wees om goeie kritiek en praktiese raad te ontvang.
Tot volgende keer.
Bron: will.com