Hallo, Habr-lêzers! It ûnderwerp fan dit artikel sil de ymplemintaasje wêze fan ark foar rampherstel yn AERODISK Engine-opslachsystemen. Yn it earstoan woene wy yn ien artikel skriuwe oer beide ark: replikaasje en metrocluster, mar spitigernôch die it artikel te lang, dus wy ferdielden it artikel yn twa dielen. Litte wy gean fan ienfâldich nei kompleks. Yn dit artikel sille wy syngroane replikaasje ynstelle en testen - wy sille ien datasintrum falle, en ek it kommunikaasjekanaal tusken de datasintra brekke en sjen wat der bart.
Us klanten stelle ús faak ferskate fragen oer replikaasje, dus foardat jo trochgean mei it ynstellen en testen fan de ymplemintaasje fan replika's, sille wy jo in bytsje fertelle oer wat replikaasje yn opslach is.
In bytsje teory
Replikaasje yn opslachsystemen is in kontinu proses fan it garandearjen fan gegevensidentiteit op ferskate opslachsystemen tagelyk. Technysk wurdt replikaasje op twa manieren dien.
Syngroane replikaasje - dit is it kopiearjen fan gegevens fan it haadopslachsysteem nei de reservekopy, folge troch ferplichte befêstiging fan beide opslachsystemen dat de gegevens binne opnommen en befêstige. It is nei befêstiging oan beide kanten (beide opslach systemen) dat de gegevens wurde beskôge opnommen en kin wurde wurke mei. Dit soarget foar garandearre gegevensidentiteit op alle opslachsystemen dy't dielnimme oan 'e replika.
De foardielen fan dizze metoade:
- Gegevens binne altyd identyk op alle opslachsystemen
Cons:
- Hege kosten fan 'e oplossing (snelle kommunikaasjekanalen, djoere glêstried, lange-wave transceivers, ensfh.)
- Ofstânsbeperkingen (binnen ferskate tsientallen kilometers)
- D'r is gjin beskerming tsjin korrupsje fan logyske gegevens (as gegevens beskeadige binne (mei opsetsin of tafallich) op it haadopslachsysteem, sil it automatysk en direkt beskeadige wurde op 'e reservekopy, om't de gegevens altyd identyk binne (dat is de paradoks)
Asynchronous replikaasje - dit is ek it kopiearjen fan gegevens fan it haadopslachsysteem nei de reservekopy, mar mei in bepaalde fertraging en sûnder de needsaak om it skriuwen oan 'e oare kant te befêstigjen. Jo kinne direkt wurkje mei gegevens nei it opnimmen fan it nei it haadopslachsysteem, en op it backup-opslachsysteem sille de gegevens nei in skoftke beskikber wêze. De identiteit fan de gegevens yn dit gefal is fansels hielendal net garandearre. De gegevens op it backup-opslachsysteem binne altyd in bytsje "yn it ferline."
Foardielen fan asynchrone replikaasje:
- Leechkosten oplossing (elke kommunikaasjekanalen, optyk opsjoneel)
- Gjin ôfstân beheiningen
- Op it reservekopy-opslachsysteem wurde gegevens net minder as se beskeadige binne op 'e wichtichste (op syn minst in skoft); as de gegevens skansearre wurde, kinne jo de replika altyd stopje om gegevenskorrupsje op it reservekopy-opslachsysteem te foarkommen
Cons:
- Gegevens yn ferskate datasintra binne altyd net identyk
Sa hinget de kar fan replikaasjemodus ôf fan bedriuwsdoelen. As it foar jo kritysk is dat it reservekopydatasintrum krekt deselde gegevens befettet as it haaddatasintrum (dat wol sizze, saaklike eask foar RPO = 0), dan moatte jo it jild forkeare en de beheiningen fan in syngroane opsette. replika. En as de fertraging yn 'e gegevenstastân akseptabel is of d'r gewoan gjin jild is, dan moatte jo perfoarst de asynchrone metoade brûke.
Lit ús ek apart markearje sa'n modus (mear krekter, in topology) as in metrocluster. Yn metrocluster-modus wurdt syngroane replikaasje brûkt, mar, yn tsjinstelling ta in gewoane replika, lit in metrocluster beide opslachsystemen yn aktive modus operearje. Dy. jo hawwe gjin skieding tusken aktive en standby datasintra. Applikaasjes wurkje tagelyk mei twa opslachsystemen, dy't fysyk yn ferskate datasintra lizze. Downtimes by ûngelokken yn sa'n topology binne tige lyts (RTO, meast minuten). Yn dit artikel sille wy ús ymplemintaasje fan 'e metrocluster net beskôgje, om't dit in heul grut en romhertich ûnderwerp is, dus wy sille der in apart folgjende artikel oan wije, yn ferfolch op dit.
Ek, heul faak, as wy prate oer replikaasje mei opslachsystemen, hawwe in protte minsken in ridlike fraach: > "In protte applikaasjes hawwe har eigen replikaasje-ark, wêrom brûke replikaasje op opslachsystemen? Is it better of slimmer?
D'r is hjir gjin dúdlik antwurd, dus hjir binne de arguminten FOR en CONS:
Arguminten FOAR opslachreplikaasje:
- Ienfâld fan 'e oplossing. Mei ien ark kinne jo jo hiele dataset replikearje, nettsjinsteande ladingstype en applikaasje. As jo in replika fan applikaasjes brûke, moatte jo elke applikaasje apart konfigurearje. As d'r mear as 2 binne, dan is dit ekstreem arbeidsintensyf en djoer (applikaasje-replikaasje fereasket normaal in aparte en net fergese lisinsje foar elke applikaasje. Mar mear oer dat hjirûnder).
- Jo kinne alles replikearje - elke applikaasje, elke gegevens - en it sil altyd konsekwint wêze. In protte (de measte) applikaasjes hawwe gjin replikaasjemooglikheden, en replika's fan it opslachsysteem binne de ienige manier om beskerming te jaan tsjin rampen.
- D'r is gjin needsaak om te folle te beteljen foar funksjonaliteit foar replikaasje fan applikaasjes. As regel, it is net goedkeap, krekt as lisinsjes foar in opslach systeem replika. Mar jo moatte ien kear betelje foar in lisinsje foar opslachreplikaasje, en in lisinsje foar replika fan tapassing moat wurde kocht foar elke applikaasje apart. As d'r in protte fan sokke applikaasjes binne, dan kostet it in moaie penny en de kosten fan lisinsjes foar opslachreplikaasje wurde in drip yn 'e oseaan.
Arguminten TEGEN opslachreplikaasje:
- Replika fia applikaasjes hat mear funksjonaliteit út it eachpunt fan 'e applikaasjes sels, de applikaasje wit har gegevens better (fansels), dus d'r binne mear opsjes om mei har te wurkjen.
- Fabrikanten fan guon applikaasjes garandearje de konsistinsje fan har gegevens net as replikaasje wurdt dien mei helpmiddels fan tredden. *
* - kontroversjele proefskrift. Bygelyks, in bekende DBMS-fabrikant hat offisjeel ferklearre foar in heul lange tiid dat har DBMS allinich normaal kin wurde replikearre mei har middels, en de rest fan 'e replikaasje (ynklusyf opslachsystemen) is "net wier." Mar it libben hat bliken dien dat dit net sa is. Meast wierskynlik (mar dit is net wis) is dit gewoan net de earlikste besykjen om mear lisinsjes te ferkeapjen oan klanten.
As gefolch, yn 'e measte gefallen is replikaasje fan it opslachsysteem better, om't Dit is in ienfâldiger en minder djoere opsje, mar d'r binne komplekse gefallen as spesifike applikaasjefunksjonaliteit nedich is, en it is nedich om te wurkjen mei replikaasje op applikaasjenivo.
Dien mei teory, no praktyk
Wy sille de replika yn ús laboratoarium konfigurearje. Yn laboratoariumbetingsten emulearren wy twa datasintra (yn feite, twa neistlizzende rekken dy't yn ferskate gebouwen like te wêzen). De stand bestiet út twa Engine N2 opslachsystemen, dy't mei elkoar ferbûn binne troch optyske kabels. In fysike tsjinner mei Windows Server 2016 is ferbûn mei beide opslachsystemen mei 10Gb Ethernet. De stand is frij simpel, mar dit feroaret de essinsje net.
Skematysk sjocht it der sa út:
Logysk is replikaasje as folget organisearre:
Litte wy no sjen nei de replikaasjefunksjonaliteit dy't wy no hawwe.
Twa modi wurde stipe: asynchrone en syngroane. It is logysk dat de syngroane modus wurdt beheind troch ôfstân en kommunikaasje kanaal. Benammen syngroane modus fereasket it brûken fan glêstried as de natuerkunde en 10 Gigabit Ethernet (of heger).
De stipe ôfstân foar syngroane replikaasje is 40 kilometer, de fertragingswearde fan it optyske kanaal tusken datasintra is oant 2 millisekonden. Yn 't algemien sil it wurkje mei grutte fertragingen, mar dan sille d'r sterke fertragingen wêze by it opnimmen (wat ek logysk is), dus as jo syngroane replikaasje plannen tusken datasintra, moatte jo de kwaliteit fan' e optyk en de fertragingen kontrolearje.
De easken foar asynchrone replikaasje binne net sa serieus. Mear krekter, se binne der hielendal net. Elke wurkjende Ethernet-ferbining sil dwaan.
Op it stuit stipet it opslachsysteem AERODISK ENGINE replikaasje foar blokapparaten (LUN's) fia it Ethernet-protokol (oer koper as optysk). Foar projekten wêrby't replikaasje troch in SAN-stof oer Fibre Channel fereaske is, foegje wy op it stuit in passende oplossing ta, mar it is noch net klear, dus yn ús gefal allinich Ethernet.
Replikaasje kin wurkje tusken alle opslachsystemen fan ENGINE-searjes (N1, N2, N4) fan juniorsystemen oant âldere en oarsom.
De funksjonaliteit fan beide replikaasjemodi is folslein identyk. Hjirûnder binne mear details oer wat beskikber is:
- Replikaasje "ien op ien" of "ien op ien", dat is de klassike ferzje mei twa datasintra, de haad en de reservekopy
- Replikaasje is "ien nei in protte" of "ien nei in protte", d.w.s. ien LUN kin wurde replicated nei ferskate opslach systemen tagelyk
- Aktivearje, deaktivearje en "omkear" replikaasje respektivelik om de rjochting fan replikaasje yn te skeakeljen, út te skeakeljen of te feroarjen
- Replikaasje is beskikber foar sawol RDG (Raid Distributed Group) as DDP (Dynamic Disk Pool) pools. LUN's fan in RDG-pool kinne lykwols allinich wurde replikearre nei in oare RDG. Itselde mei DDP.
D'r binne folle mear lytse funksjes, mar d'r is gjin bepaald punt yn 'e list se; wy sille se neame as wy ynstelle.
Replikaasje ynstelle
It opsetproses is frij ienfâldich en bestiet út trije stadia.
- Netwurk konfiguraasje
- Opslach opset
- Regels ynstelle (ferbinings) en mapping
In wichtich punt by it opsetten fan replikaasje is dat de earste twa stadia moatte wurde werhelle op it opslachsysteem op ôfstân, de tredde etappe - allinich op 'e wichtichste.
It ynstellen fan netwurk boarnen
De earste stap is om de netwurkpoarten te konfigurearjen wêrmei replikaasjeferkear sil wurde oerdroegen. Om dit te dwaan, moatte jo de havens ynskeakelje en har IP-adressen ynstelle yn 'e seksje Front-end adapters.
Hjirnei moatte wy in swimbad meitsje (yn ús gefal RDG) en in firtuele IP foar replikaasje (VIP). VIP is in driuwend IP-adres dat is bûn oan twa "fysike" adressen fan opslachkontrôles (de havens dy't wy krekt konfigureare). Dit sil de wichtichste replikaasje-ynterface wêze. Jo kinne ek operearje net mei in VIP, mar mei in VLAN, as jo moatte wurkje mei tagged ferkear.
It proses fan it meitsjen fan in VIP foar in replika is net folle oars as it meitsjen fan in VIP foar I / O (NFS, SMB, iSCSI). Yn dit gefal meitsje wy in gewoane VIP (sûnder VLAN), mar wês der wis fan dat it is foar replikaasje (sûnder dizze oanwizer kinne wy net VIP tafoegje oan 'e regel yn' e folgjende stap).
De VIP moat yn itselde subnet wêze as de IP-poarten dêr't it tusken driuwt.
Wy werhelje dizze ynstellingen op in opslachsysteem op ôfstân, mei in oare IP, fansels.
VIP's fan ferskate opslachsystemen kinne yn ferskate subnets wêze, it wichtichste is dat d'r routing is tusken har. Yn ús gefal is dit foarbyld krekt te sjen (192.168.3.XX en 192.168.2.XX)
Dit foltôget de tarieding fan it netwurkdiel.
It ynstellen fan opslach
It ynstellen fan opslach foar in replika ferskilt fan gewoanlik allinich yn dat wy de mapping dogge fia in spesjaal menu "Replication Mapping". Oars is alles itselde as mei de normale opset. No, yn oarder.
Yn it earder oanmakke pool R02 moatte jo in LUN meitsje. Litte wy it oanmeitsje en it LUN1 neame.
Wy moatte ek deselde LUN meitsje op in opslachsysteem op ôfstân fan identike grutte. Wy meitsje. Om betizing te foarkommen, lit ús de ôfstân LUN LUN1R neame
As wy in LUN moasten nimme dy't al bestiet, dan moatte wy by it ynstellen fan de replika dizze produktive LUN fan 'e host ûntkoppelje, en gewoan in lege LUN fan identike grutte meitsje op it opslachsysteem op ôfstân.
De opslach opset is foltôge, litte wy trochgean nei it meitsjen fan in replikaasjeregel.
It ynstellen fan replikaasjeregels of replikaasjekeppelings
Nei it meitsjen fan LUN's op it opslachsysteem, dat op it stuit de primêre sil wêze, konfigurearje wy de replikaasjeregel LUN1 op opslachsysteem 1 nei LUN1R op opslachsysteem 2.
De ynstelling wurdt makke yn it menu "Remote replikaasje".
Litte wy in regel meitsje. Om dit te dwaan, moatte jo de ûntfanger fan 'e replika opjaan. Dêr sette wy ek de namme fan 'e ferbining en it type replikaasje yn (syngroane of asynchrone).
Yn it fjild "systemen op ôfstân" foegje wy ús opslachsysteem2 ta. Om ta te foegjen, moatte jo de management IP-opslachsystemen (MGR) brûke en de namme fan 'e LUN op ôfstân wêryn wy replikaasje sille útfiere (yn ús gefal, LUN1R). Kontrolearje IP's binne allinich nedich op it poadium fan it tafoegjen fan in ferbining; replikaasjeferkear sil net fia har wurde ferstjoerd; de earder konfigureare VIP sil hjirfoar brûkt wurde.
Al op dit poadium kinne wy mear dan ien systeem op ôfstân tafoegje foar de "ien oant folle" topology: klikje op de knop "knooppunt taheakje", lykas yn 'e ôfbylding hjirûnder.
Yn ús gefal is d'r mar ien systeem op ôfstân, dus wy beheine ús hjir ta.
De regel is klear. Tink derom dat it automatysk wurdt tafoege oan alle replikaasje-dielnimmers (yn ús gefal binne d'r twa). Jo kinne safolle regels oanmeitsje as jo wolle, foar elk oantal LUN's en yn elke rjochting. Bygelyks, om de lading te balansearjen, kinne wy in diel fan 'e LUN's replikearje fan opslachsysteem 1 nei opslachsysteem 2, en it oare diel, krekt oarsom, fan opslachsysteem 2 nei opslachsysteem 1.
Opslachsysteem 1. Fuort nei skepping begûn syngronisaasje.
Opslachsysteem 2. Wy sjogge deselde regel, mar syngronisaasje is al einige.
LUN1 op opslachsysteem 1 is yn 'e primêre rol, dat is, it is aktyf. LUN1R op opslachsysteem 2 is yn 'e rol fan Secondary, dat is, it is op standby yn gefal opslachsysteem 1 mislearret.
No kinne wy ús LUN ferbine mei de host.
Wy sille ferbine fia iSCSI, hoewol't it kin ek dien wurde fia FC. It ynstellen fan mapping fia iSCSI LUN yn in replika is praktysk net oars as it gewoane senario, dus wy sille dit hjir net yn detail beskôgje. As der wat is, wurdt dit proses beskreaun yn it artikel "".
It ienige ferskil is dat wy mapping meitsje yn it menu "Replication Mapping".
Wy sette mapping op en joegen de LUN oan de host. De gasthear seach de LUN.
Wy formatearje it yn in lokaal bestânsysteem.
Dat is it, de opset is kompleet. Tests komme folgjende.
Testing
Wy sille trije haadsenario's testen.
- Reguliere rolwikseling Sekundêr > Primêr. Regelmjittich wikseljen fan rol is nedich yn it gefal dat wy bygelyks wat previntive operaasjes moatte útfiere yn it haaddatasintrum en yn dizze tiid, om de gegevens beskikber te wêzen, drage wy de lading oer nei it reservekopydatasintrum.
- Emergency role switching Secondary> Primary (datacenter failure). Dit is it wichtichste senario wêrfoar replikaasje bestiet, wat kin helpe oerlibjen fan in folsleine datacenterfal sûnder it bedriuw foar in langere perioade te stopjen.
- Ferdieling fan kommunikaasjekanalen tusken datasintra. Kontrolearje it juste gedrach fan twa opslachsystemen yn betingsten dêr't om ien of oare reden it kommunikaasjekanaal tusken de datasintra net beskikber is (bygelyks in graafmachine groeven op it ferkearde plak en bruts de tsjustere optyk).
Earst sille wy begjinne mei it skriuwen fan gegevens nei ús LUN (triemmen skriuwe mei willekeurige gegevens). Wy sjogge daliks dat it kommunikaasjekanaal tusken de opslachsystemen brûkt wurdt. Dit is maklik te begripen as jo de ladingskontrôle iepenje fan 'e havens dy't ferantwurdlik binne foar replikaasje.
Beide opslachsystemen hawwe no "nuttige" gegevens, wy kinne de test begjinne.
Foar it gefal, litte wy nei de hash-summen fan ien fan 'e bestannen sjen en se opskriuwe.
Regelmjittige rolwikseling
De wurking fan it wikseljen fan rollen (feroarje de rjochting fan replikaasje) kin dien wurde mei elk opslachsysteem, mar jo moatte noch nei beide gean, om't jo mapping op Primêr moatte útskeakelje en it ynskeakelje op Secondary (dat Primary sil wurde ).
Miskien komt der no in ridlike fraach op: wêrom dit net automatisearje? It antwurd is: it is ienfâldich, replikaasje is in ienfâldich middel fan rampbestendigens, allinich basearre op hânmjittige operaasjes. Om dizze operaasjes te automatisearjen is d'r in metrocluster-modus; it is folslein automatisearre, mar syn konfiguraasje is folle komplisearre. Wy sille skriuwe oer it opsetten fan in metrocluster yn it folgjende artikel.
Op it haadopslachsysteem skeakelje wy mapping út om te soargjen dat de opname stopt.
Selektearje dan op ien fan 'e opslachsystemen (it makket net út, op' e haad of reservekopy) yn it menu "Remote replikaasje" ús ferbining REPL1 en klikje op "Role feroarje".
Nei in pear sekonden wurdt LUN1R (backup opslachsysteem) Primêr.
Wy map LUN1R mei opslachsysteem2.
Hjirnei wurdt ús E: drive automatysk oan 'e host hechte, allinich dizze kear is it "oankommen" fan LUN1R.
Foar it gefal fergelykje wy de hash-summen.
Identyk. Test trochjûn.
Failover. Data sintrum flater
Op it stuit, de wichtichste opslach systeem nei reguliere switching is respektivelik opslach systeem 2 en LUN1R. Om in ûngelok te emulearjen, sille wy de stroom útsette op beide opslachkontrôles2.
Der is gjin tagong mear ta.
Litte wy sjen wat der bart op opslachsysteem 1 (de reservekopy op it stuit).
Wy sjogge dat de Primary LUN (LUN1R) net beskikber is. In flaterberjocht ferskynde yn 'e logs, yn it ynformaasjepaniel, en ek yn' e replikaasjeregel sels. Dêrtroch binne gegevens fan 'e host op it stuit net beskikber.
Feroarje de rol fan LUN1 yn Primêr.
Ik bin dwaande mei mapping nei de host.
Soargje derfoar dat drive E ferskynt op 'e host.
Wy kontrolearje de hash.
Alles is ynoarder. It opslachsysteem oerlibbe mei súkses de fal fan it datasintrum, dat aktyf wie. De ûngefear tiid dy't wy bestege oan it ferbinen fan 'e replikaasje "omkearing" en it ferbinen fan de LUN fan it reservekopydatasintrum wie sawat 3 minuten. It is dúdlik dat yn echte produksje alles folle yngewikkelder is, en neist aksjes mei opslachsystemen moatte jo folle mear operaasjes útfiere op it netwurk, op hosts, yn applikaasjes. En yn it libben sil dizze perioade folle langer duorje.
Hjir soe ik graach skriuwe dat alles, de test is mei súkses foltôge, mar litte wy net haasten. De wichtichste opslach systeem is "liggen", wy witte dat doe't it "fal", wie it yn de primêre rol. Wat bart der as it ynienen oangiet? D'r sille twa primêre rollen wêze, wat lyk oan datakorrupsje? Litte wy it no kontrolearje.
Litte wy ynienen it ûnderlizzende opslachsysteem ynskeakelje.
It laden foar in pear minuten en dan werom nei tsjinst nei in koarte syngronisaasje, mar yn 'e rol fan Secondary.
Alles goed. Split-brain barde net. Wy tochten oer dit, en altyd nei in fal komt it opslachsysteem ta de rol fan Secondary, nettsjinsteande hokker rol it wie yn "yn it libben." No kinne wy seker sizze dat de test foar mislearring fan datasintrum suksesfol wie.
Mislearjen fan kommunikaasjekanalen tusken datasintra
De wichtichste taak fan dizze test is om te soargjen dat it opslachsysteem net raar begjint te hanneljen as it tydlik kommunikaasjekanalen ferliest tusken twa opslachsystemen en dan wer ferskynt.
Sa. Wy skiede de triedden tusken de opslachsystemen (lit ús yntinke dat se waarden groeven troch in graafmachine).
Op primêr sjogge wy dat der gjin ferbining is mei Secondary.
Op Secondary sjogge wy dat der gjin ferbining is mei Primary.
Alles wurket goed, en wy bliuwe te skriuwen gegevens nei de wichtichste opslach systeem, dat is, se wurde garandearre te wêzen oars as de reservekopy ien, dat is, se hawwe "skieden".
Yn in pear minuten "reparearje" wy it kommunikaasjekanaal. Sadree't de opslachsystemen inoar sjogge, wurdt gegevenssyngronisaasje automatysk aktivearre. Fan de behearder is hjir neat nedich.
Nei in skoftke is syngronisaasje foltôge.
De ferbining waard hersteld, it ferlies fan kommunikaasjekanalen feroarsake gjin needsituaasjes, en nei it ynskeakeljen fûn syngronisaasje automatysk plak.
befinings
Wy analysearren de teory - wat is nedich en wêrom, wêr binne de foardielen en wêr binne de neidielen. Dan sette wy syngroane replikaasje op tusken twa opslachsystemen.
Folgjende waarden basistests útfierd foar normale skeakeljen, mislearjen fan datasintrum en mislearjen fan kommunikaasjekanaal. Yn alle gefallen wurke it opslachsysteem goed. D'r is gjin gegevensferlies en bestjoerlike operaasjes wurde op in minimum hâlden foar in hânmjittich senario.
Folgjende kear sille wy komplisearje de situaasje en sjen litte hoe't al dizze logika wurket yn in automatisearre metrocluster yn aktyf-aktive modus, dat is, as beide opslach systemen binne primêr, en it gedrach yn gefal fan opslach systeem flaters is folslein automatisearre.
Skriuw asjebleaft opmerkingen, wy sille bliid wêze om goede krityk en praktysk advys te ûntfangen.
Oant de oare kear.
Boarne: www.habr.com