Hallo Habr-lêzers! Yn it lêste artikel hawwe wy it oer in ienfâldige middel fan rampherstel yn AERODISK ENGINE opslachsystemen - replikaasje. Yn dit artikel sille wy dûke yn in komplekser en nijsgjirriger ûnderwerp - in metrocluster, dat is in automatisearre ark foar rampbeskerming foar twa datasintra wêrtroch datasintra yn aktyf-aktive modus kinne wurkje. Wy sille fertelle, sjen litte, brekke en reparearje.
As gewoanlik, oan it begjin fan 'e teory
In metrocluster is in kluster dat op ferskate plakken binnen in stêd of wyk ferdield is. It wurd "kluster" jout ús dúdlik oan dat it kompleks automatisearre is, dat is, it wikseljen fan klusterknooppunten yn gefal fan mislearrings (failover) komt automatysk foar.
Dit is wêr't it wichtichste ferskil tusken in metrocluster en reguliere replikaasje leit. Automatisearring fan operaasjes. Dat is, yn it gefal fan bepaalde ynsidinten (falen fan it datasintrum, brekken fan kanalen, ensfh.), It opslachsysteem sil selsstannich de nedige aksjes útfiere om de beskikberens fan gegevens te behâlden. By it brûken fan reguliere replika's wurde dizze aksjes hielendal of foar in part mei de hân útfierd troch de behearder.
Wat docht it?
It haaddoel neistribbe troch klanten mei help fan bepaalde metrocluster-ymplemintaasjes is om RTO (Recovery Time Objective) te minimalisearjen. Dat is, om de hersteltiid fan IT-tsjinsten nei in mislearring te minimalisearjen. As jo konvinsjonele replikaasje brûke, dan sil de hersteltiid altyd grutter wêze dan de hersteltiid mei in metrokluster. Wêrom? Hiel ienfâldich. De behearder moat op it wurkplak wêze en replikaasje manuell wikselje, wylst it metrokluster dit automatysk docht.
As jo gjin tawijd plichtbehearder hawwe dy't net sliept, net ite, net smoke of siik wurde, mar 24 oeren deis sjocht nei de steat fan it opslachsysteem, dan is d'r gjin manier om te garandearjen dat de behearder sil beskikber wêze foar hânmjittich wikseljen by in flater.
Dêrnjonken sil RTO by it ûntbrekken fan in metrokluster as in ûnstjerlike admin fan it 99e nivo fan 'e tsjinst fan behearders lykweardich wêze oan' e som fan 'e wikseltiid fan alle systemen en de maksimale tiid wêrnei't de behearder garandearre wurdt begjinne te wurkjen mei it opslachsysteem en besibbe systemen.
Sa komme wy ta de foar de hân lizzende konklúzje dat it metrocluster brûkt wurde moat as de eask foar RTO minuten is, net oeren of dagen, dat wol sizze wannear't, yn it gefal fan de skriklikste fal fan it datasintrum, de IT-ôfdieling foarsjen moat it bedriuw mei tiid om tagong ta IT-tsjinsten binnen minuten of sels sekonden te herstellen.
Hoe wurket it?
Op it legere nivo brûkt de metrocluster it syngroane gegevensreplikaasjemeganisme dat wy beskreaun hawwe yn it foarige artikel (sjoch hjirûnder). ). Om't replikaasje syngroan is, binne de easken dêrfoar passend, of leaver:
- fiber as natuerkunde, 10 gigabit ethernet (of heger);
- de ôfstân tusken datasintra is net mear as 40 kilometer;
- optyske kanaal fertraging tusken data sintra (tusken opslach systemen) oant 5 millisekonden (optimaal 2).
Al dizze easken binne advisearjend fan aard, dat is, it metrokluster sil wurkje sels as dizze easken net foldien wurde, mar it moat begrepen wurde dat de gefolgen fan it net neilibjen fan dizze easken gelyk binne oan it fertrage fan de wurking fan beide opslachsystemen yn de metro kluster.
Dat, in syngroane replika wurdt brûkt om gegevens oer te dragen tusken opslachsystemen, mar hoe wikselje replika's automatysk en, it wichtichste, hoe split-brain te foarkommen? Om dit te dwaan, op it boppesteande nivo wurdt in ekstra entiteit brûkt - de arbiter.
Hoe wurket in arbiter en wat is syn taak?
De arbiter is in lytse firtuele masine as in hardware kluster dat moat wurde lansearre op in tredde side (bygelyks, yn in kantoar) en jouwe tagong ta opslach fia ICMP en SSH. Nei it starten moat de skiedsrjochter it IP ynstelle, en dan it adres opjaan fan 'e opslachkant, plus de adressen fan' e ôfstânkontrôles dy't dielnimme oan it metrokluster. Dêrnei is de skiedsrjochter klear om te gean.
De arbiter kontrolearret konstant alle opslachsystemen yn it metrokluster, en yn it gefal dat in bepaald opslachsysteem net beskikber is, nei befêstiging fan 'e net-beskikberens fan in oar klusterlid (ien fan 'e "live" opslachsystemen), beslút hy de proseduere te begjinnen foar wikseljen fan replikaasjeregels en mapping.
In tige wichtich punt. De arbiter moat altyd lizze op in plak oars as dy dêr't de opslachsystemen sitte, dat wol sizze noch yn DPC 1, dêr't opslach 1 leit, noch yn DPC 2, dêr't opslach 2 ynstallearre is.
Wêrom? Want allinnich op dizze manier kin de skiedsrjochter, mei help fan ien fan 'e oerbleaune opslachsystemen, de fal fan ien fan' e twa siden wêr't de opslachsystemen ynstalleare binne, unambiguous en sekuer bepale. Elke oare manier om in arbitrator te pleatsen kin resultearje yn in split-brain.
No litte wy dûke yn 'e details fan' e taak fan 'e arbiter.
Ferskate tsjinsten rinne op 'e arbiter dy't konstant alle opslachkontrôles ûndersiket. As it resultaat fan 'e peiling ferskilt fan' e foarige (beskikber/net beskikber), dan wurdt it skreaun nei in lytse databank dy't ek wurket op 'e arbiter.
Besjoch de logika fan 'e arbiter yn mear detail.
Stap 1. Bepaling fan ûnbeskikberens. In evenemint dat in mislearring fan in opslachsysteem sinjalearret is it ûntbrekken fan in ping fan beide controllers fan itselde opslachsysteem foar 5 sekonden.
Stap 2. It wikseljen proseduere begjinne. Nei't de arbiter realisearre dat ien fan 'e opslachsystemen net beskikber is, stjoert hy in fersyk nei it "live" opslachsysteem om te soargjen dat it "deade" opslachsysteem echt dea is.
Nei it ûntfangen fan sa'n kommando fan 'e arbiter, kontrolearret it twadde (live) opslachsysteem ek de beskikberens fan it fallen earste opslachsysteem en, as net, stjoert de arbitrator befêstiging fan syn rieden. SHD, yndie, is net beskikber.
Nei it ûntfangen fan sa'n befêstiging, begjint de arbitrator in proseduere op ôfstân foar it wikseljen fan replikaasje en it ferheegjen fan de mapping op dy replika's dy't aktyf wiene (primêr) op it fallen opslachsysteem, en stjoert in kommando nei it twadde opslachsysteem om dizze replika's fan sekundêr nei primêr te meitsjen en ferheegje de mapping. No, respektivelik it twadde opslachsysteem fiert dizze prosedueres, wêrnei't it tagong jout ta de ferlerne LUN's fan himsels.
Wêrom is ekstra ferifikaasje nedich? Foar kworum. Dat is, de mearderheid fan it totale ûneven (3) oantal kluster leden moat befêstigje de fal fan ien fan de kluster knopen. Allinne dan sil dit beslút krekt rjocht wêze. Dit is nedich om ferkeard wikseljen en, sadwaande, split-brain te foarkommen.
Stap 2 duorret sa'n 5-10 sekonden yn 'e tiid, dus, rekken hâldend mei de tiid dy't nedich is om de ûnbeskikberens te bepalen (5 sekonden), binnen 10-15 sekonden nei it mislearjen, sille LUN's mei in fallen opslachsysteem automatysk beskikber wêze foar wurkjen mei live opslach.
It is dúdlik dat om ûntbining mei hosts te foarkommen, jo ek moatte soargje foar de juste ynstelling fan timeouts op 'e hosts. De oanrikkemandearre timeout is op syn minst 30 sekonden. Dit foarkomt dat de host de ferbining mei de opslach sakke by in failover-load en kin derfoar soargje dat der gjin I/O-ûnderbrekking is.
Wachtsje in twadde, it docht bliken dat as alles goed is mei it metrokluster, wêrom hawwe wy dan überhaupt reguliere replikaasje nedich?
Yn feite is alles net sa ienfâldich.
Tink oan de foar- en neidielen fan 'e metrocluster
Dat, wy realisearren dat de foar de hân lizzende foardielen fan 'e metrocluster yn ferliking mei konvinsjonele replikaasje binne:
- Folsleine automatisearring, soargje foar minimale hersteltiid yn gefal fan in ramp;
- En dat is it :-).
En no, oandacht, neidielen:
- Oplossingskosten. Hoewol it metrocluster yn Aerodisk-systemen gjin ekstra lisinsje fereasket (deselde lisinsje wurdt brûkt as foar de replika), sille de kosten fan 'e oplossing noch heger wêze as it brûken fan syngroane replikaasje. Jo moatte útfiere alle easken foar in syngroane replika, plus de easken foar de metro kluster ferbûn mei ekstra switching en ekstra site (sjoch metro kluster planning);
- De kompleksiteit fan it beslút. In metrocluster is folle komplekser as in gewoane replika, en fereasket folle mear oandacht en ynspanning om te plannen, konfigurearje en dokumintearje.
Úteinlik. Metrocluster is grif in hiel technologyske en goede oplossing as jo echt moatte foarsjen RTO yn sekonden of minuten. Mar as d'r gjin sa'n taak is, en RTO yn oeren is OK foar bedriuw, dan makket it gjin sin om sparrows út in kanon te sjitten. De gewoane replikaasje fan arbeiders en boeren is genôch, om't it metrokluster ekstra kosten en komplikaasje fan 'e IT-ynfrastruktuer sil feroarsaakje.
Metro kluster planning
Dizze seksje docht net foar as in wiidweidich tutorial oer ûntwerp fan metrokluster, mar lit allinich de haadrjochtingen sjen dy't moatte wurde útwurke as jo beslute om sa'n systeem te bouwen. Dêrom, yn 'e eigentlike ymplemintaasje fan' e metro-kluster, moatte jo der wis fan wêze dat de fabrikant fan it opslachsysteem (dat is ús) en oare relatearre systemen foar oerlis belûke.
Venues
Lykas hjirboppe oanjûn, fereasket in metrokluster in minimum fan trije plakken. Twa datasintra, wêr't opslachsystemen en relatearre systemen sille wurkje, lykas in tredde side, wêr't de arbiter sil wurkje.
De rekommandearre ôfstân tusken datasintra is net mear as 40 kilometer. In gruttere ôfstân soarget nei alle gedachten foar ekstra fertraging, dy't yn it gefal fan in metrokluster tige net winske binne. Tink derom dat fertragingen oant 5 millisekonden moatte wêze, hoewol it winsklik is om binnen 2 te hâlden.
Fertragingen wurde ek oanrikkemandearre om te kontrolearjen tidens it planningproses. Elke min of mear folwoeksen provider dy't glêstried leveret tusken datasintra kin frij fluch in kwaliteitskontrôle organisearje.
Wat de fertragingen oan 'e arbitrator oanbelanget (dat is tusken de tredde side en de earste twa), is de oanrikkemandearre fertragingsdrompel oant 200 millisekonden, dat is, in gewoane bedriuws VPN-ferbining oer it ynternet sil dwaan.
Switching en netwurk
Oars as it replikaasjeskema, wêr't it genôch is om opslachsystemen fan ferskate siden te ferbinen, fereasket it metroklusterskema it ferbinen fan hosts oan beide opslachsystemen op ferskate siden. Om dúdliker te meitsjen wat it ferskil is, wurde beide regelingen hjirûnder neamd.
Sa't jo sjen kinne út it diagram, hawwe wy side 1-hosts dy't sawol opslach 1 as opslach 2 sjogge. Dat is, elke host sjocht beide opslachsystemen. Dit is in betingst foar de eksploitaasje fan it metrokluster.
Fansels is it net nedich om elke host mei in optysk snoer nei in oar datasintrum te lûken, d'r sille net genôch havens en koarden wêze. Al dizze ferbinings moatte wurde makke fia Ethernet 10G + of FibreChannel 8G + switches (FC allinnich foar ferbinen hosts en opslach foar IO, it replikaasje kanaal is op it stuit allinnich beskikber oer IP (Ethernet 10G +).
No in pear wurden oer de netwurktopology. In wichtich punt is de juste konfiguraasje fan subnets. Jo moatte fuortendaliks ferskate subnets definiearje foar de folgjende soarten ferkear:
- Subnet foar replikaasje, oer hokker gegevens sille wurde syngronisearre tusken opslachsystemen. D'r kinne ferskate fan har wêze, yn dit gefal makket it net út, it hinget allegear ôf fan 'e hjoeddeistige (al ymplementearre) netwurktopology. As d'r twa binne, dan moat fansels routing tusken har konfigureare wurde;
- Opslach subnets troch hokker hosts tagong krije ta opslachboarnen (as it iSCSI is). Der moat ien sa'n subnet yn elk datasintrum wêze;
- Kontrôle subnets, dat is, trije routable subnets op trije siden dêr't opslach wurdt beheard, en de arbiter is ek leit dêr.
Wy beskôgje gjin subnetten foar tagong ta hostboarnen hjir, om't se tige ôfhinklik binne fan taken.
It skieden fan ferskate ferkear yn ferskate subnetten is ekstreem wichtich (it is foaral wichtich om de replika te skieden fan 'e I / O), want as jo al it ferkear mingje yn ien "dikke" subnet, dan sil dit ferkear ûnmooglik wêze om te behearjen, en yn de betingsten fan twa datasintra dit kin noch feroarsaakje ferskate netwurk botsing opsjes. Wy sille net djip yn dizze kwestje yn it ramt fan dit artikel ferdjipje, om't jo kinne lêze oer it plannen fan in netwurk spand tusken datasintra op 'e boarnen fan fabrikanten fan netwurkapparatuer, wêr't dit yn detail beskreaun wurdt.
Arbiter Konfiguraasje
De arbitrator moat tagong jaan ta alle kontrôleynterfaces fan it opslachsysteem fia ICMP- en SSH-protokollen. Jo moatte ek tinke oer de skuldtolerânsje fan 'e arbiter. Hjir is in nuânse.
Arbiter failover is heul winsklik, mar net fereaske. En wat bart der as de arbiter op it ferkearde momint crasht?
- De wurking fan 'e metrocluster yn' e normale modus sil net feroarje, om't arbtir hat gjin ynfloed op de wurking fan 'e metrocluster yn' e normale modus hielendal (har taak is om de lading tusken datasintra yn 'e tiid te wikseljen)
- Tagelyk, as de skiedsrjochter foar ien of oare reden falt en "sliept" it ûngelok yn it datasintrum, dan sil gjin wikseling foarkomme, om't d'r gjinien sil wêze om de nedige wikselkommando's te jaan en in kworum te organisearjen. Yn dit gefal sil it metrokluster feroarje yn in reguliere replikaasjeskema, dy't by in ramp mei de hân skeakele wurde moatte, wat RTO sil beynfloedzje.
Wat folget hjirút? As jo echt moatte foarsjen in minimum RTO, Jo moatte soargje foar de skuld tolerânsje fan de arbitrator. D'r binne twa opsjes foar dit:
- Run in firtuele masine mei in arbiter op in skuld-tolerante hypervisor, sûnt alle folwoeksen hypervisors stipet skuld-tolerânsje;
- As it op 'e tredde side (yn in betingst kantoar) te lui is om in normaal kluster te ynstallearjen en d'r is gjin besteande kluster fan hypervisors, dan hawwe wy in hardwareferzje fan' e arbiter levere, dy't makke is yn in 2U-doaze, wêryn twa gewoane x-86-tsjinners wurkje en dy't in lokale mislearring kinne oerlibje.
Wy riede sterk oan dat jo soargje foar de skuld tolerânsje fan 'e arbiter, nettsjinsteande it feit dat de metro kluster net nedich is yn normale modus. Mar lykas sawol teory as praktyk sjen litte, as jo in wirklik betroubere ramp-tolerante ynfrastruktuer bouwe, dan is it better om it feilich te spyljen. It is better om josels en jo bedriuw te beskermjen fan 'e "wet fan gemienens", dat is, fan it mislearjen fan sawol de arbiter as ien fan 'e siden wêr't it opslachsysteem leit.
Solution arsjitektuer
Sjoen de boppesteande easken krije wy de folgjende algemiene oplossingsarsjitektuer.
LUN's moatte lykwichtich ferdield wurde oer de twa siden om swiere oerlêst te foarkommen. Tagelyk, by it oanpassen fan grutte yn beide datasintra, is it needsaaklik om net allinich dûbel it folume te leverjen (wat nedich is om gegevens tagelyk op twa opslachsystemen op te slaan), mar ek dûbele prestaasjes yn IOPS en MB / s om foar te kommen degradaasje fan applikaasjes yn gefal fan in mislearring fan ien fan 'e datasintra - ov.
Apart merken wy op dat mei de juste oanpak fan grutte (dat is, op betingst dat wy foarsjoen hawwe foar de juste boppegrins fan IOPS en MB / s, lykas ek de nedige CPU- en RAM-boarnen), as ien fan 'e opslachsystemen yn de metro kluster mislearret, der sil gjin serieuze prestaasjes drop yn betingsten tydlik wurk op ien opslach systeem.
Dit wurdt ferklearre troch it feit dat yn betingsten fan twa siden dy't tagelyk wurkje, syngroane replikaasje "eet" de helte fan 'e skriuwprestaasjes, om't elke transaksje skreaun wurde moat nei twa opslachsystemen (lykas RAID-1 / 10). Dus, as ien fan 'e opslachsystemen mislearret, ferdwynt it effekt fan replikaasje tydlik (oant it mislearre opslachsysteem opkomt), en wy krije in dûbele ferheging fan skriuwprestaasjes. Nei't de LUN's fan it mislearre opslachsysteem opnij starte op it wurkjende opslachsysteem, ferdwynt dizze dûbele ferheging fanwege it feit dat d'r in lading is fan 'e LUN's fan in oar opslachsysteem, en wy geane werom nei itselde nivo fan prestaasjes dat wy hiene foar de "fal", mar allinnich binnen itselde platfoarm.
Mei help fan foechhawwende sizing is it mooglik om betingsten te leverjen wêryn brûkers it mislearjen fan it heule opslachsysteem hielendal net fiele. Mar dit freget noch ien kear in heul soarchfâldige maat, dy't jo trouwens fergees kontakt mei ús opnimme kinne :-).
It opsetten fan in metro kluster
It ynstellen fan in metrokluster is heul gelyk oan it ynstellen fan reguliere replikaasje, dy't wy beskreaun yn . Lit ús dus gewoan rjochtsje op de ferskillen. Wy sette in bank yn it laboratoarium op basearre op de arsjitektuer hjirboppe, allinich yn 'e minimale ferzje: twa opslachsystemen ferbûn fia 10G Ethernet oan elkoar, twa 10G-skeakels en ien host dy't troch de skeakels sjocht nei beide opslachsystemen mei 10G-poarten. De arbitrator rint op in firtuele masine.
By it konfigurearjen fan firtuele IP (VIP) foar in replika, moatte jo it VIP-type selektearje - foar in metrokluster.
Twa replikaasjekeppelings makke foar twa LUN's en ferdield oer twa opslachsystemen: LUN TEST Primêr op opslach1 (METRO-ferbining), LUN TEST2 Primêr foar opslach2 (METRO2-ferbining).
Foar harren konfigurearre wy twa identike doelen (yn ús gefal, iSCSI, mar FC wurdt ek stipe, de konfiguraasje logika is itselde).
opslach1:
opslach2:
Foar replikaasjekeppelings waarden mappings makke op elk opslachsysteem.
opslach1:
opslach2:
Wy sette multipath en presintearre it oan de host.
It ynstellen fan in arbiter
Jo moatte neat spesjaal dwaan mei de arbiter sels, jo moatte it gewoan op 'e tredde side ynskeakelje, har IP ynstelle en tagong ta it konfigurearje fia ICMP en SSH. De konfiguraasje sels wurdt útfierd fanút de opslachsystemen sels. Tagelyk is it genôch om de arbiter ien kear te konfigurearjen op ien fan 'e opslachkontrôles yn' e metro-kluster, dizze ynstellings wurde automatysk ferspraat oan alle controllers.
Under Remote Replication >> Metrocluster (op elke controller) >> Konfigurearje knop.
Wy ynfiere it IP fan 'e arbiter, lykas de kontrôle-ynterfaces fan' e twa opslachkontrôles op ôfstân.
Dêrnei moatte jo alle tsjinsten ynskeakelje (knop "Alles opnij starte"). As jo yn 'e takomst opnij konfigurearje, moatte de tsjinsten opnij starte wurde foar de ynstellingen om effekt te nimmen.
Wy kontrolearje dat alle tsjinsten rinne.
Dit foltôget de opset fan 'e metrocluster.
Crash test
De crashtest yn ús gefal sil frij ienfâldich en fluch wêze, om't de replikaasjefunksjonaliteit (wikselje, konsistinsje, ensfh.) . Dêrom, om de betrouberens fan 'e metro-kluster te testen, is it genôch foar ús om de automatisearring fan ûngelokdeteksje, skeakeljen en it ûntbrekken fan skriuwferlies te kontrolearjen (I / O-stops).
Om dit te dwaan, emulearje wy in folsleine mislearring fan ien fan 'e opslachsystemen troch fysyk de beide controllers út te skeakeljen, nei it begjinnen fan it kopiearjen fan in grut bestân nei in LUN, dat moat wurde aktivearre op in oar opslachsysteem.
Skeakelje ien opslachsysteem út. Op it twadde opslachsysteem sjogge wy warskôgings en berjochten yn 'e logs dat de ferbining mei it oanbuorjende systeem ferdwûn is. As notifikaasjes fia SMTP- of SNMP-monitoring binne konfigureare, dan wurde de passende notifikaasjes nei de behearder stjoerd.
Krekt 10 sekonden letter (sjoen yn beide skermôfbyldings), waard de METRO-replikaasje-keppeling (dejinge dy't Primêr wie op it fallen opslachsysteem) automatysk Primêr op it wurkjende opslachsysteem. Mei help fan de besteande mapping bleau LUN TEST beskikber foar de host, de opname dipped in bytsje (binnen de taseine 10 prosint), mar stoppe net.
De test is mei súkses foltôge.
Omheech op
De hjoeddeistige ymplemintaasje fan 'e metrocluster yn' e opslachsystemen fan 'e AERODISK Engine N-rige kinne jo folslein oplosse problemen wêr't jo de downtime fan IT-tsjinsten moatte eliminearje of minimalisearje en har wurking yn 24/7/365-modus soargje mei minimale arbeidskosten.
Jo kinne fansels sizze dat dit alles teory is, ideale laboratoariumbetingsten, ensafuorthinne ... MAAR wy hawwe in oantal ympleminteare projekten wêryn wy de funksjonaliteit foar rampherstel ymplementearre hawwe, en de systemen wurkje perfekt. Ien fan ús frij bekende klanten, dêr't mar twa opslach systemen wurde brûkt yn in ramp-tolerante konfiguraasje, hat al ôfpraat te publisearjen ynformaasje oer it projekt, dus yn it folgjende diel sille wy prate oer bestriding ymplemintaasje.
Tank, sjoch út nei in produktive diskusje.
Boarne: www.habr.com