Kaixo Habr irakurleok! Azken artikuluan, AERODISK ENGINE biltegiratze sistemetan hondamendiak berreskuratzeko baliabide sinple bati buruz hitz egin dugu: erreplikazioa. Artikulu honetan, gai konplexuago eta interesgarriago batean murgilduko gara: metrokluster bat, hau da, bi datu-zentroentzako hondamendien babeserako tresna automatizatu bat, datu-zentroek modu aktibo-aktiboan lan egitea ahalbidetzen duena. Kontatu, erakutsi, hautsi eta konponduko dugu.
Ohi bezala, teoriaren hasieran
Metrokluster bat hiri edo barruti bateko hainbat gunetan banatutako multzoa da. "Kluster" hitzak argi eta garbi adierazten digu konplexua automatizatuta dagoela, hau da, hutsegiteen kasuan kluster-nodoen aldaketa automatikoki gertatzen da (failover).
Hor dago metrokluster baten eta erreplikazio erregularraren arteko desberdintasun nagusia. Eragiketen automatizazioa. Hau da, gorabehera jakin batzuk gertatuz gero (datu-zentroaren hutsegitea, kanalen haustura, etab.), biltegiratze-sistemak modu independentean egingo ditu beharrezko ekintzak datuen erabilgarritasuna mantentzeko. Erreplika arruntak erabiltzean, ekintza hauek eskuz burutzen ditu administratzaileak osorik edo partzialki.
Zer egiten du?
Metrocluster inplementazio jakin batzuk erabiltzen dituzten bezeroek lortu duten helburu nagusia RTO (Recovery Time Objective) minimizatzea da. Hau da, hutsegite baten ondoren IT zerbitzuen berreskuratze denbora minimizatzea. Ohiko erreplikazioa erabiltzen baduzu, berreskuratzeko denbora beti izango da metroko kluster batekin berreskuratzeko denbora baino handiagoa. Zergatik? Oso sinplea. Administratzaileak lantokian egon behar du eta eskuz aldatu erreplikazioa, metroko klusterrak automatikoki egiten duen bitartean.
Ez baduzu lo egiten, jaten, erretzen edo gaixotzen ez den ardurapeko administratzailerik, baina biltegiratze sistemaren egoera eguneko 24 orduz begiratzen badu, ez dago administratzaileak bermatuko duenik. hutsegite batean eskuz aldatzeko erabilgarri egon.
Horrenbestez, RTO metro-klusterrik edo administratzaileen betebehar-zerbitzuaren 99. mailako administratzaile hilezkorrik ez dagoenean, sistema guztien aldaketa-denboraren eta administratzaileak bermatzen duen gehienezko denboraren batura berdina izango da. biltegiratze sistemarekin eta erlazionatutako sistemekin lanean hastea.
Horrela, metrokluster-a erabili behar dela ondorioztatuko dugu, RTO-ren eskakizuna minutuak badira, ez orduak edo egunak badira.Hau da, datu-zentroaren erorketa larriena gertatuz gero, informatika sailak eman behar duenean. negozioa denborarekin IT zerbitzuetarako sarbidea berrezartzeko minutu batzuetan edo segundotan.
Nola funtzionatzen du?
Beheko mailan, metroklusterrak aurreko artikuluan (ikus behean) deskribatu genuen datuen erreplikazio sinkronoaren mekanismoa erabiltzen du. ). Erreplikazioa sinkronoa denez, horretarako baldintzak egokiak dira, edo hobeto esanda:
- zuntza fisika gisa, 10 gigabit ethernet (edo handiagoa);
- datu-zentroen arteko distantzia ez da 40 kilometro baino gehiagokoa;
- Datu-zentroen arteko kanal optikoko atzerapena (biltegiratze sistemen artean) 5 milisegundoraino (optimoan 2).
Baldintza hauek guztiak aholkularitza izaera dute, hau da, metroko klusterrak funtzionatuko du baldintza horiek betetzen ez badira ere, baina ulertu behar da baldintza horiek ez betetzearen ondorioak bi biltegiratze sistemen funtzionamendua moteltzearen parekoak direla. metro klusterrean.
Beraz, erreplika sinkronoa erabiltzen da biltegiratze sistemen artean datuak transferitzeko, baina nola aldatzen dira automatikoki erreplikak eta, batez ere, nola saihestu garuna zatitua? Horretarako, goiko mailan, entitate osagarri bat erabiltzen da: arbitroa.
Nola funtzionatzen du arbitro batek eta zein da bere zeregina?
Arbitroa makina birtual txiki bat edo hardware-kluster bat da, hirugarren gune batean (adibidez, bulego batean) abiarazi behar dena eta ICMP eta SSH bidez biltegiratzeko sarbidea ematen duena. Hasi ondoren, arbitroak IP-a ezarri behar du, eta gero bere helbidea zehaztu behar du biltegiratze aldetik, gehi metroko klusterrean parte hartzen duten urruneko kontrolagailuen helbideak. Horren ostean, epailea joateko prest dago.
Arbitroak etengabe kontrolatzen ditu metroko klusterreko biltegiratze-sistema guztiak, eta biltegiratze-sistema jakin bat erabilgarri ez badago, beste klusterreko kide batek (zuzeneko" biltegiratze-sistemetako bat) erabilgarritasunik ez dagoela berretsi ondoren, prozedura hastea erabakitzen du. erreplikazio-arauak eta mapak aldatzea.
Oso puntu garrantzitsua. Arbitroa beti egon behar da biltegiratze-sistemak dauden tokitik desberdina den gune batean, hau da, ez DPC 1-en, 1. biltegiratzea dagoen tokian, ez DPC 2-an, 2. biltegia instalatuta dagoenean.
Zergatik? Modu honetan bakarrik arbitroak, bizirik dauden biltegiratze-sistemetako baten laguntzaz, anbiguotasunik gabe eta zehatz-mehatz zehaztu dezake biltegiratze-sistemak instalatuta dauden bi guneetako edozeinen erorketa. Arbitro bat jartzeko beste edozein moduk zatiketa-garuna eragin dezake.
Orain murgil ditzagun arbitroaren lanaren xehetasunetan.
Biltegiratze-kontrolagailu guztiak etengabe galdetzen dituzten arbitroan hainbat zerbitzu exekutatzen ari dira. Inkestaren emaitza aurrekoaren desberdina bada (eskuragarri/ez dago), orduan arbitroan ere lan egiten duen datu-base txiki batean idazten da.
Kontuan izan arbitroaren logika zehatzago.
1. urratsa. Erabilgarritasuna zehaztea. Biltegiratze sistemaren hutsegite bat adierazten duen gertaera bat biltegiratze sistema bereko bi kontrolagailuetatik ping-a ez izatea da 5 segundoz.
2. urratsa. Aldaketa prozedura abiaraztea. Arbitroa biltegiratze-sistemetako bat erabilgarri ez dagoela konturatu ondoren, eskaera bat bidaltzen du "zuzeneko" biltegiratze sistemara, "hildako" biltegiratze sistema benetan hilda dagoela ziurtatzeko.
Arbitroaren agindu hori jaso ondoren, bigarren (zuzeneko) biltegiratze-sistemak gainera eroritako lehen biltegiratze-sistemaren erabilgarritasuna egiaztatzen du eta, hor ez badago, bere asmakizunaren berrespena bidaltzen dio arbitroari. SHD, hain zuzen ere, ez dago eskuragarri.
Berrespen hori jaso ondoren, arbitroak urruneko prozedura bat abiarazten du erreplika aldatzeko eta mapeoa igotzeko eroritako biltegiratze sisteman aktibo (lehen) zeuden errepliketan, eta komando bat bidaltzen du bigarren biltegiratze sistemara, erreplika horiek bigarren mailako izatetik lehenera egiteko. eta mapea igo. Bada, bigarren biltegiratze-sistemak, hurrenez hurren, prozedura hauek egiten ditu, eta ondoren, galdutako LUNetarako sarbidea ematen du.
Zergatik behar da egiaztapen gehigarria? Quorumerako. Hau da, kluster-ko kideen kopuru bakoiti osoaren (3) gehienek kluster-nodoetako baten erorketa baieztatu behar dute. Orduan bakarrik izango da erabaki hau guztiz zuzena. Hau beharrezkoa da aldaketa okerrak saihesteko eta, horren ondorioz, garuna zatitua saihesteko.
2. urratsak 5-10 segundo inguru behar ditu, beraz, erabilgarritasuna zehazteko behar den denbora (5 segundo) kontuan hartuta, huts egin eta 10-15 segundotan, eroritako biltegiratze sistema duten LUNak automatikoki erabilgarri egongo dira zuzenekoarekin lan egiteko. biltegiratzea.
Argi dago ostalariekin deskonexioa saihesteko, ostalarien denbora-muga zuzena ere zaindu behar duzula. Gomendatutako denbora-muga gutxienez 30 segundokoa da. Honek ostalariak biltegiratze-konexioa kentzea galarazten du hutsegite-karga batean zehar eta I/O etenik ez dagoela bermatu dezake.
Itxaron segundo bat, metroko klusterrekin dena ondo badago, zergatik behar dugu erreprodukzio erregularra?
Izan ere, dena ez da hain erraza.
Kontuan hartu metroklusterren alde onak eta txarrak
Beraz, konturatu ginen metroklusterren abantaila nabariak ohiko erreplikazioarekin alderatuta:
- Automatizazio osoa, hondamendia gertatuz gero berreskuratzeko denbora minimoa bermatuz;
- Eta kitto :-).
Eta orain, arreta, txarrak:
- Irtenbide kostua. Aerodisk sistemetako metroklusterrak lizentzia gehigarririk behar ez badu ere (erreplikaren lizentzia bera erabiltzen da), konponbidearen kostua oraindik ere handiagoa izango da erreplikazio sinkronikoa erabiltzea baino. Erreplika sinkrono baterako eskakizun guztiak ezarri beharko dituzu, gehi aldakuntza gehigarriarekin eta gune gehigarriarekin lotutako metro-klusterraren eskakizunak (ikus metro-kluster plangintza);
- Erabakiaren konplexutasuna. Metrokluster bat ohiko erreplika bat baino askoz konplexuagoa da, eta askoz arreta eta ahalegin handiagoa eskatzen du planifikatzeko, konfiguratzeko eta dokumentatzeko.
Azkenean. Metrocluster, zalantzarik gabe, oso irtenbide teknologiko eta ona da RTO segundo edo minututan eman behar duzunean. Baina horrelako zereginik ez badago eta RTO orduetan ondo badago negozioetarako, orduan ez du zentzurik txolarreak kanoi batetik tiro egiteak. Ohiko langile-nekazari errepikapena nahikoa da, metroaren klusterrak kostu gehigarriak eta informatika azpiegituraren konplikazioak eragingo baititu.
Metroen kluster plangintza
Atal honek ez du metroko kluster diseinuari buruzko tutorial integrala denik, baina sistema hori eraikitzea erabakitzen baduzu landu beharreko ildo nagusiak soilik erakusten ditu. Hori dela eta, metro-klusterren benetako ezarpenean, ziurtatu biltegiratze-sistemaren fabrikatzaileak (hau da, gu) eta erlazionatutako beste sistema batzuk kontsultatzeko inplikatzea.
Guneak
Goian esan bezala, metro kluster batek gutxienez hiru gune behar ditu. Bi datu-zentro, non biltegiratze-sistemek eta erlazionatutako sistemak funtzionatuko duten, baita hirugarren gune bat, non arbitroak lan egingo duen.
Datu-zentroen arteko distantzia gomendatua ez da 40 kilometro baino gehiagokoa. Distantzia handiagoak litekeena da atzerapen gehigarriak sortzea, eta hori oso desiragarriak dira metro kluster baten kasuan. Gogoratu atzerapenak 5 milisegundorainokoak izan behar direla, nahiz eta 2 barruan mantentzea komeni den.
Plangintza-prozesuan atzerapenak ere egiaztatzea gomendatzen da. Datu-zentroen artean zuntza eskaintzen duen hornitzaile gehiago edo gutxiago helduek kalitate egiaztapena nahiko azkar antola dezakete.
Arbitroaren atzerapenei dagokienez (hau da, hirugarren gunearen eta lehenengo bien artean), gomendatutako atzerapen-atalasea 200 milisegundorainokoa da, hau da, Internet bidezko VPN korporatiboko ohiko konexio batek balioko du.
Aldaketa eta sarea
Erreplikazio-eskeman ez bezala, non nahikoa den biltegiratze-sistemak gune ezberdinetatik konektatzea, metroko kluster eskemak ostalariak bi biltegiratze-sistemetara konektatzea eskatzen du gune ezberdinetan. Desberdintasuna zein den argitzeko, bi eskemak zerrendatzen dira jarraian.
Diagraman ikus dezakezun bezala, 1. guneko ostalariak 1. biltegiratze sistemari eta 2. biltegiratze sistemari begira ditugu. Gainera, aitzitik, 2. guneko ostalariek 2. biltegiratze sistema eta 1. biltegiratze sistemari begiratzen dituzte. Hau da, ostalari bakoitzak bi biltegiratze sistemak ikusten ditu. Hori ezinbesteko baldintza da metrokluster funtzionatzeko.
Noski, ez dago ostalari bakoitza kable optiko batekin beste datu-zentro batera eraman beharrik, ez da portu eta kable nahikorik egongo. Konexio hauek guztiak Ethernet 10G+ edo FibreChannel 8G+ etengailuen bidez egin behar dira (FC soilik ostalariak konektatzeko eta IOrako biltegiratzeko, erreplikazio-kanala IP bidez soilik dago eskuragarri (Ethernet 10G+).
Orain sarearen topologiari buruzko hitz batzuk. Puntu garrantzitsu bat azpisareen konfigurazio zuzena da. Berehala hainbat azpisare definitu behar dituzu trafiko mota hauetarako:
- Erreplikatzeko azpisarea, zeinaren gainean datuak biltegiratze sistemen artean sinkronizatuko diren. Hainbat izan daitezke, kasu honetan ez du axola, dena egungo (dagoeneko inplementatutako) sarearen topologiaren araberakoa da. Bi badira, bistan denez, haien arteko bideratzea konfiguratu behar da;
- Ostalariak biltegiratze-baliabideetara sartuko diren biltegiratze azpisareak (iSCSI bada). Datu-zentro bakoitzean horrelako azpisare bat egon beharko litzateke;
- Kontrolatu azpisareak, hau da, biltegiratzea kudeatzen den hiru gunetako hiru azpisare bideragarri, eta arbitroa ere bertan kokatzen da.
Ez ditugu hemen ostalari-baliabideetara sartzeko azpisarerik kontuan hartzen, zereginen menpekotasun handia baitute.
Trafiko desberdinak azpisare desberdinetan bereiztea oso garrantzitsua da (bereziki garrantzitsua da erreplika I/O-tik bereiztea), zeren trafiko guztia azpisare "lodi" batean nahasten baduzu, trafiko hori ezinezkoa izango da kudeatzea, eta bi datu-zentroen baldintzek sareko talka-aukera desberdinak eragin ditzakete. Ez gara gai honetan asko murgilduko artikulu honen esparruan, sareko ekipoen fabrikatzaileen baliabideen datu-zentroen artean hedatutako sare baten plangintzari buruz irakur dezakezulako, non hori xehetasun handiz deskribatzen den.
Arbitroaren konfigurazioa
Arbitroak biltegiratze sistemaren kontrol interfaze guztietarako sarbidea eman behar du ICMP eta SSH protokoloen bidez. Arbitroaren akatsen tolerantziaz ere pentsatu beharko zenuke. Hemen ñabardura bat dago.
Arbiter hutsegitea oso desiragarria da, baina ez da beharrezkoa. Eta zer gertatzen da arbitroa une okerrean huts egiten badu?
- Metroklusterren funtzionamendua ohiko moduan ez da aldatuko, zeren arbtirrek ez du inola ere eragiten metroko klusterraren funtzionamenduan modu normalean (bere zeregina datu-zentroen artean karga denboran aldatzea da)
- Aldi berean, arbitroa arrazoi bategatik edo besteagatik erori eta datu-zentroan istripua "lo egiten" badu, ez da aldaketarik gertatuko, ez baita inor egongo beharrezko aldatzeko aginduak emateko eta quoruma antolatzeko. Kasu honetan, metroko klusterra erreplikazio erregular eskema bihurtuko da, hondamendi batean eskuz aldatu beharko duena, eta horrek RTOri eragingo dio.
Zer ateratzen da honetatik? Benetan RTO minimo bat eman behar baduzu, arbitroaren akatsen tolerantzia ziurtatu behar duzu. Horretarako bi aukera daude:
- Exekutatu makina birtual bat arbitro batekin akats-tolerantzia hipervisor batean, helduen hipervisor guztiek akats-tolerantzia onartzen baitute;
- Hirugarren gunean (baldintzadun bulego batean) kluster normal bat instalatzea alferra bada eta hiperbissoreen multzorik ez badago, orduan arbitroaren hardware bertsioa eman dugu, 2U kutxa batean egina, eta bertan bi x-86 zerbitzari arruntek funtzionatzen dute eta tokiko hutsegite batetik iraun dezaketenak.
Biziki gomendatzen dugu arbitroaren akatsen tolerantzia ziurtatzea, metroko klusterrak modu normalean behar ez duen arren. Baina teoriak eta praktikak erakusten duten moduan, hondamendiei aurre egiteko azpiegitura benetan fidagarria eraikitzen baduzu, hobe da seguru jokatzea. Hobe da zeure burua eta zure negozioa babestea "malkeriaren legetik", hau da, arbitroaren eta biltegiratze sistema dagoen guneetako baten hutsegitetik.
Irtenbideen arkitektura
Goiko baldintzak kontuan hartuta, honako soluzio-arkitektura orokorra lortuko dugu.
LUNak uniformeki banatu behar dira bi guneetan pilaketa larria saihesteko. Aldi berean, bi datu-zentroetan dimentsionatzerakoan, bolumenaren bikoitza ez ezik (beharrezkoa da datuak bi biltegiratze-sistemetan aldi berean gordetzeko), baizik eta IOPS eta MB / s-tan errendimendu bikoitza ere eman behar da saihesteko. aplikazioen degradazioa datu-zentroren baten hutsegitearen kasuan - ov.
Bereizita, dimentsionatzeko ikuspegi egokiarekin (hau da, IOPS eta MB / s-en goiko muga egokiak aurreikusi baditugu, baita beharrezkoak diren CPU eta RAM baliabideak ere), biltegiratze-sistemetako bat bada. Metro-klusterrak huts egiten du, ez da errendimendu-behera larririk izango biltegiratze-sistema batean behin-behineko lanetan.
Hau da, bi gune aldi berean lan egiten duten baldintzetan, erreplikazio sinkronoa exekutatzen dela idazketa-errendimenduaren erdia "jaten" dela, transakzio bakoitza bi biltegiratze-sistemetan idatzi behar baita (RAID-1 / 10-ren antzekoa). Beraz, biltegiratze-sistemetako batek huts egiten badu, erreplikaren eragina aldi baterako (huts egin duen biltegiratze-sistema igo arte) desagertzen da eta idazketa-errendimendua bikoiztu egiten da. Huts egindako biltegiratze-sistemaren LUNak laneko biltegiratze-sisteman berrabiarazi ondoren, bikoiztutako igoera hau desagertu egiten da beste biltegiratze-sistema bateko LUN-etatik karga bat dagoelako, eta aurretik genuen errendimendu-maila berera itzultzen gara. “erortzea”, baina plataforma beraren barruan bakarrik.
Tamainamendu eskudunaren laguntzaz, erabiltzaileek biltegiratze sistema osoaren porrota batere sentituko ez duten baldintzak eskain daitezke. Baina, berriro ere, horrek oso kontu handiz neurtzea eskatzen du, eta, bide batez, doan jar zaitezke gurekin harremanetan :-).
Metro-kluster bat konfiguratzea
Metro-kluster bat konfiguratzea erreprodukzio erregularra ezartzearen oso antzekoa da, bertan deskribatu duguna . Beraz, zentra gaitezen desberdintasunetan. Goiko arkitekturan oinarritutako banku bat ezarri dugu laborategian, gutxieneko bertsioan bakarrik: 10G Ethernet bidez elkarri konektatutako bi biltegiratze sistema, 10G bi etengailu eta 10G ataka duten bi biltegiratze sistemetara etengailuetatik begiratzen duen ostalari bat. Arbitroa makina birtual batean exekutatzen da.
Erreplika baterako IP birtuala (VIP) konfiguratzean, VIP mota hautatu behar duzu - metro-kluster baterako.
Bi LUNentzako bi erreplika-esteka sortu eta bi biltegiratze-sistematan banatu ditu: LUN TEST Primarioa biltegian1 (METRO konexioa), LUN TEST2 Primaria biltegiratzeko2 (METRO2 konexioa).
Horientzat, bi helburu berdin konfiguratu ditugu (gure kasuan, iSCSI, baina FC ere onartzen da, konfigurazio logika berdina da).
biltegiratzea 1:
biltegiratzea 2:
Erreplika esteketarako, biltegiratze-sistema bakoitzean mapak egin ziren.
biltegiratzea 1:
biltegiratzea 2:
Multipath konfiguratu genuen eta ostalariari aurkeztu genion.
Arbitro bat eratzea
Ez duzu ezer berezirik egin behar arbitroarekin berarekin, hirugarren gunean aktibatu, bere IP ezarri eta ICMP eta SSH bidez sarbidea konfiguratu besterik ez duzu behar. Konfigurazioa bera biltegiratze-sistemetatik egiten da. Aldi berean, nahikoa da arbitroa behin konfiguratzea metroko klusterreko edozein biltegiratze-kontrolagailuetan, ezarpen hauek automatikoki banatuko dira kontrolagailu guztietara.
Urruneko Erreplika>> Metrocluster (edozein kontrolagailutan)>> Konfiguratu botoia atalean.
Arbitroaren IPa sartzen dugu, baita urrutiko biltegiratze-kontrolagailuen kontrol-interfazeak ere.
Horren ondoren, zerbitzu guztiak gaitu behar dituzu (botoia "Berrabiarazi dena"). Etorkizunean birkonfiguratzen baduzu, zerbitzuak berrabiarazi beharko dira ezarpenak indarrean egon daitezen.
Zerbitzu guztiak martxan daudela egiaztatzen dugu.
Horrek metrocluster konfigurazioa osatzen du.
Crash proba
Gure kasuan hutsegite-proba nahiko sinplea eta azkarra izango da, erreplikatzeko funtzionaltasuna (aldaketa, koherentzia, etab.) kontuan hartu baita. . Hori dela eta, metroko klusterraren fidagarritasuna probatzeko, nahikoa da istripuen detekzioaren, kommutazioaren eta idazketa-galeren (I/O geldialdiak) automatizazioa egiaztatzea.
Horretarako, biltegiratze-sistemetako baten hutsegite osoa emulatzen dugu bere bi kontrolagailu fisikoki itzaliz, fitxategi handi bat LUN batera kopiatzen hasi ondoren, beste biltegiratze sistema batean aktibatu beharko litzatekeena.
Desgaitu biltegiratze sistema bat. Bigarren biltegiratze sisteman, aldameneko sistemarekin konexioa desagertu dela dioten erregistroetan alertak eta mezuak ikusten ditugu. SMTP edo SNMP monitorizazio bidezko jakinarazpenak konfiguratzen badira, jakinarazpen egokiak administratzaileari bidaliko zaizkio.
Zehazki 10 segundo geroago (bi pantaila-argazkietan ikusten dena), METRO-ren erreplikazio-esteka (erortutako biltegiratze-sisteman Nagusia zena) automatikoki bihurtu zen lehen mailakoa laneko biltegiratze-sisteman. Lehendik zegoen mapa erabiliz, LUN TEST ostalariaren eskura egon zen, grabazioa pixka bat murgildu zen (agindutako ehuneko 10aren barruan), baina ez zen gelditu.
Proba behar bezala amaitu da.
Laburbilduz
AERODISK Engine N serieko biltegiratze sistemetan metroklusterren egungo ezarpenak informatika zerbitzuen geldialdi-denbora ezabatu edo gutxitu behar duzun arazoak konpon ditzakezu eta haien funtzionamendua 24/7/365 moduan bermatu behar duzu lan kostu minimoarekin.
Esan dezakezu, noski, hori guztia teoria dela, laborategiko baldintza idealak, eta abar... BAINA hondamendiak berreskuratzeko funtzionaltasuna ezarri genuen hainbat proiektu inplementatu ditugu, eta sistemak primeran funtzionatzen du. Gure bezero nahiko ezagunetako batek, non bi biltegiratze sistema soilik erabiltzen diren hondamendiei aurre egiteko konfigurazio batean, dagoeneko onartu du proiektuari buruzko informazioa argitaratzea, beraz, hurrengo zatian borrokaren ezarpenari buruz hitz egingo dugu.
Eskerrik asko, eztabaida emankor baten zain.
Iturria: www.habr.com