Motor AERODISK: odpornost na nesreče. 2. del. Metrocluster

Pozdravljeni, bralci Habra! V zadnjem članku smo govorili o enostavnem sredstvu za obnovitev po katastrofi v pomnilniških sistemih AERODISK ENGINE – replikaciji. V tem članku se bomo poglobili v bolj zapleteno in zanimivo temo - metrocluster, to je sredstvo za avtomatizirano zaščito dveh podatkovnih centrov pred nesrečami, ki podatkovnim centrom omogoča delovanje v načinu aktivno-aktivno. Povedali vam bomo, pokazali, zlomili in popravili.

Kot ponavadi najprej teorija

Metrocluster je grozd, razporejen na več lokacijah znotraj mesta ali regije. Beseda "grozd" nam jasno namiguje, da je kompleks avtomatiziran, to pomeni, da preklapljanje vozlišč gruče v primeru okvar poteka samodejno.

Tu je glavna razlika med metroclusterjem in rednim podvajanjem. Avtomatizacija delovanja. To pomeni, da bo sistem za shranjevanje v primeru določenih incidentov (odpoved podatkovnega centra, pokvarjeni kanali itd.) neodvisno izvedel potrebna dejanja, da ohrani razpoložljivost podatkov. Pri uporabi navadnih replik skrbnik ta dejanja v celoti ali delno izvede ročno.

Kaj počne?

Glavni cilj, ki si ga stranke prizadevajo pri uporabi določenih implementacij metroclustra, je minimiziranje RTO (Recovery Time Objective). To pomeni, da čim bolj skrajšate čas obnovitve storitev IT po okvari. Če uporabljate redno replikacijo, bo čas obnovitve vedno daljši od časa obnovitve z metroclusterjem. Zakaj? Zelo preprosto. Administrator mora biti za svojo mizo in ročno preklopiti replikacijo, metrocluster pa to naredi samodejno.

Če nimate predanega dežurnega skrbnika, ki ne spi, ne je, ne kadi in ne zboli ter 24 ur na dan bdi nad stanjem skladiščnega sistema, potem ni mogoče zagotoviti, da bo skrbnik biti na voljo za ročno preklapljanje med napako.

Skladno s tem bo RTO v odsotnosti metroclusterja ali nesmrtnega skrbnika 99. stopnje skrbniške službe enak vsoti preklopnega časa vseh sistemov in največjega časa, po katerem je zagotovljeno, da skrbnik začne delati s sistemi za shranjevanje in sorodnimi sistemi.

Tako pridemo do očitnega zaključka, da je treba metrocluster uporabiti, če so zahteve za RTO minute, ne ure ali dnevi.To je, ko mora IT-oddelek podjetju v primeru najhujše okvare podatkovnega centra zagotoviti čas. obnoviti dostop do storitev IT v nekaj minutah ali celo sekundah.

Kako deluje?

Na nižji ravni metrocluster uporablja mehanizem za sinhrono podvajanje podatkov, ki smo ga opisali v prejšnjem članku (glej. povezava). Ker je replikacija sinhrona, so zahteve zanjo ustrezne oziroma:

• optična vlakna kot fizika, 10 gigabitni ethernet (ali višji);
• razdalja med podatkovnimi centri ni večja od 40 kilometrov;
• zakasnitev optičnega kanala med podatkovnimi centri (med sistemi za shranjevanje) je do 5 milisekund (optimalno 2).

Vse te zahteve so svetovalne narave, to pomeni, da bo metrocluster deloval tudi, če te zahteve niso izpolnjene, vendar moramo razumeti, da so posledice neupoštevanja teh zahtev enake upočasnitvi delovanja obeh sistemov za shranjevanje v metrocluster.

Torej, sinhrona replika se uporablja za prenos podatkov med sistemi za shranjevanje in kako se replike samodejno preklapljajo in, kar je najpomembnejše, kako se izogniti razcepljenim možganom? Za to se na višji ravni uporablja dodatna entiteta - arbiter.

Kako deluje arbiter in kaj je njegova naloga?

Razsodnik je majhen virtualni stroj ali gruča strojne opreme, ki jo je treba zagnati na tretji strani (na primer v pisarni) in omogočiti dostop do sistema za shranjevanje prek ICMP in SSH. Po zagonu mora razsodnik nastaviti IP, nato pa s strani pomnilnika navesti svoj naslov in naslove oddaljenih krmilnikov, ki sodelujejo v metroclusterju. Po tem je sodnik pripravljen za delo.

Razsodnik stalno spremlja vse pomnilniške sisteme v metroclustru in če določen pomnilniški sistem ni na voljo, se po potrditvi nerazpoložljivosti s strani drugega člana grozda (enega od “živih” pomnilniških sistemov) odloči sprožiti postopek za preklop pravil replikacije. in kartiranje.

Zelo pomembna točka. Arbiter se mora vedno nahajati na lokaciji, ki ni tista, na kateri so nameščeni sistemi za shranjevanje, to je niti v podatkovnem centru 1, kjer je nameščen sistem za shranjevanje 1, niti v podatkovnem centru 2, kjer je nameščen sistem za shranjevanje 2.

Zakaj? Kajti le tako lahko arbiter s pomočjo enega od ohranjenih skladiščnih sistemov nedvoumno in natančno ugotovi padec katere koli od obeh lokacij, kjer sta nameščena skladiščna sistema. Vse druge metode postavljanja razsodnika lahko povzročijo razcepljene možgane.

Zdaj pa se poglobimo v podrobnosti dela arbitra.

Razsodnik vodi več storitev, ki nenehno preverjajo vse krmilnike pomnilnika. Če se rezultat ankete razlikuje od prejšnjega (na voljo/nedosegljiv), potem se zabeleži v majhno bazo podatkov, ki deluje tudi na razsodniku.

Poglejmo si podrobneje logiko dela arbitra.

1. korak: Ugotovite nedosegljivost. Dogodek okvare sistema za shranjevanje je odsotnost pinga z obeh krmilnikov istega sistema za shranjevanje v 5 sekundah.

Korak 2. Zaženite postopek preklopa. Ko razsodnik ugotovi, da eden od pomnilniških sistemov ni na voljo, pošlje zahtevo »živemu« pomnilniškemu sistemu, da se prepriča, ali je »mrtvi« pomnilniški sistem res mrtev.

Po prejemu takega ukaza od razsodnika drugi (živi) shranjevalni sistem dodatno preveri razpoložljivost padlega prvega shranjevalnega sistema in, če ga ni, pošlje razsodniku potrditev njegovega ugibanja. Sistem za shranjevanje dejansko ni na voljo.

Po prejemu take potrditve razsodnik sproži oddaljeni postopek za preklapljanje replikacije in dvigovanje preslikave na tistih replikah, ki so bile aktivne (primarne) v okvarjenem pomnilniškem sistemu, in pošlje ukaz drugemu pomnilniškemu sistemu, da spremeni te replike iz sekundarnih v primarne in povečati preslikavo. No, drugi sistem za shranjevanje v skladu s tem izvede te postopke in nato sam zagotovi dostop do izgubljenih LUN-ov.

Zakaj je potrebno dodatno preverjanje? Za sklepčnost. To pomeni, da mora večina skupnega lihega (3) števila članov gruče potrditi padec enega od vozlišč gruče. Le tako bo ta odločitev zagotovo pravilna. To je potrebno, da se izognemo napačnemu preklopu in posledično razdeljenim možganom.

Časovni korak 2 traja približno 5 - 10 sekund, zato bodo ob upoštevanju časa, potrebnega za določitev nerazpoložljivosti (5 sekund), v 10 - 15 sekundah po nesreči LUN-i iz padlega sistema za shranjevanje samodejno na voljo za delo z živo sistem za shranjevanje.

Jasno je, da morate za preprečitev izgube povezav z gostitelji poskrbeti tudi za pravilno konfiguracijo časovnih omejitev na gostiteljih. Priporočena časovna omejitev je vsaj 30 sekund. To bo gostitelju preprečilo prekinitev povezave s sistemom za shranjevanje med preklapljanjem obremenitve v primeru katastrofe in lahko zagotovi, da ni prekinitev V/I.

Čakaj malo, izkazalo se je, da če je z metroclusterjem vse tako dobro, zakaj sploh potrebujemo redno replikacijo?

V resnici vse ni tako preprosto.

Razmislimo o prednostih in slabostih metroclustra

Tako smo ugotovili, da so očitne prednosti metroclustra v primerjavi s konvencionalno replikacijo:

• Popolna avtomatizacija, ki zagotavlja minimalen čas okrevanja v primeru katastrofe;
• To je vse :-).

In zdaj, pozor, slabosti:

• Cena rešitve. Čeprav metrocluster v sistemih Aerodisk ne zahteva dodatnega licenciranja (uporablja se enaka licenca kot za repliko), bo cena rešitve še vedno celo višja od uporabe sinhrone replikacije. Izvesti boste morali vse zahteve za sinhrono repliko ter zahteve za metrocluster, povezane z dodatnim preklopom in dodatnim mestom (glejte načrtovanje metroclustra);
• Kompleksnost rešitve. Metrocluster je veliko bolj kompleksen kot običajna replika in zahteva veliko več pozornosti in truda pri načrtovanju, konfiguraciji in dokumentaciji.

Končno. Metrocluster je vsekakor zelo tehnološko napredna in dobra rešitev, ko morate resnično zagotoviti RTO v nekaj sekundah ali minutah. Če pa te naloge ni in je RTO v urah OK za posel, potem nima smisla streljati vrabcev iz topa. Zadostuje običajna delavsko-kmečka replikacija, saj bo metro grozd povzročil dodatne stroške in zaplet IT infrastrukture.

Metrocluster načrtovanje

Ta razdelek ne trdi, da je izčrpen vodnik za načrtovanje metroclustra, ampak prikazuje le glavne smeri, ki jih je treba obdelati, če se odločite zgraditi tak sistem. Zato pri dejanski implementaciji metroclustra obvezno vključite proizvajalca sistemov za shranjevanje (to je nas) in druge povezane sisteme za posvetovanje.

Prizorišča

Kot je navedeno zgoraj, metrocluster zahteva najmanj tri lokacije. Dva podatkovna centra, kjer bodo delovali sistemi za shranjevanje in sorodni sistemi, ter tretja lokacija, kjer bo deloval arbiter.

Priporočena razdalja med podatkovnimi centri ni večja od 40 kilometrov. Večja razdalja bo zelo verjetno povzročila dodatne zamude, ki so v primeru metroclusterja skrajno nezaželene. Naj vas spomnimo, da naj bodo zakasnitve največ 5 milisekund, vendar je priporočljivo, da so znotraj 2 milisekund.

Priporočljivo je, da zamude preverite tudi med postopkom načrtovanja. Vsak bolj ali manj zrel ponudnik, ki zagotavlja optična vlakna med podatkovnimi centri, lahko precej hitro organizira preverjanje kakovosti.

Kar zadeva zamude pred arbitrom (torej med tretjim mestom in prvima dvema), je priporočeni prag zamude do 200 milisekund, torej je primerna običajna korporativna povezava VPN prek interneta.

Preklapljanje in mreženje

Za razliko od replikacijske sheme, kjer je dovolj, da povežete sisteme za shranjevanje iz različnih lokacij, shema metrocluster zahteva povezovanje gostiteljev z obema sistemoma za shranjevanje na različnih mestih. Da bo bolj jasno, kakšna je razlika, sta spodaj prikazani obe shemi.

Kot je razvidno iz diagrama, naši gostitelji spletnega mesta 1 gledajo tako na sistem za shranjevanje 1 kot na sistem za shranjevanje 2. Nasprotno pa gostitelji na spletnem mestu 2 gledajo tako na sistem za shranjevanje 2 kot na sistem za shranjevanje 1. To pomeni, da vsak gostitelj vidi oba sistema za shranjevanje. To je predpogoj za delovanje metroclustra.

Seveda ni treba vsakega gostitelja povezovati z optičnim kablom v drug podatkovni center; nobena vrata ali kabli ne bodo dovolj. Vse te povezave morajo biti vzpostavljene prek stikal Ethernet 10G+ ali FibreChannel 8G+ (FC je samo za povezovanje gostiteljev in sistemov za shranjevanje za IO, replikacijski kanal je trenutno na voljo samo prek IP (Ethernet 10G+).

Zdaj pa nekaj besed o topologiji omrežja. Pomembna točka je pravilna konfiguracija podomrežij. Takoj je potrebno določiti več podomrežij za naslednje vrste prometa:

• Replikacijsko podomrežje, prek katerega se bodo podatki sinhronizirali med sistemi za shranjevanje. Lahko jih je več, v tem primeru ni pomembno, vse je odvisno od trenutne (že implementirane) topologije omrežja. Če sta dva od njih, potem mora biti usmerjanje očitno konfigurirano med njima;
• Podomrežja za shranjevanje, prek katerih bodo gostitelji dostopali do virov za shranjevanje (če je iSCSI). V vsakem podatkovnem centru bi moralo biti eno takšno podomrežje;
• Nadzorna podomrežja, to so tri usmerljiva podomrežja na treh lokacijah, iz katerih se upravljajo sistemi za shranjevanje, tam pa se nahaja tudi arbiter.

Tukaj ne upoštevamo podomrežij za dostop do gostiteljskih virov, saj so zelo odvisna od nalog.

Ločevanje različnega prometa v različna podomrežja je izjemno pomembno (predvsem je pomembno ločiti repliko od V/I), saj če ves promet zmešate v eno »debelo« podomrežje, potem bo ta promet nemogoče obvladovati in v razmerah dveh podatkovnih centrov lahko to še vedno povzroči različne možnosti omrežnih trkov. V okviru tega članka se ne bomo poglabljali v to vprašanje, saj lahko o načrtovanju omrežja, raztegnjenega med podatkovnimi centri, preberete v virih proizvajalcev omrežne opreme, kjer je to zelo podrobno opisano.

Konfiguracija razsodnika

Razsodnik mora zagotoviti dostop do vseh upravljavskih vmesnikov pomnilniškega sistema preko protokolov ICMP in SSH. Pomisliti morate tudi na varnost razsodnika. Tukaj je odtenek.

Arbiter failover je zelo zaželen, vendar ni obvezen. Kaj se zgodi, če se sodnik zruši ob nepravem času?

• Delovanje metroclustra v običajnem načinu se ne bo spremenilo, ker arbtir popolnoma ne vpliva na delovanje metroclustra v običajnem načinu (njegova naloga je pravočasno preklapljanje obremenitve med podatkovnimi centri)
• Poleg tega, če razsodnik iz enega ali drugega razloga pade in "prespi" nesrečo v podatkovnem centru, potem ne bo prišlo do zamenjave, ker ne bo nikogar, ki bi dal potrebne ukaze za preklapljanje in organiziral kvorum. V tem primeru se bo metrocluster spremenil v običajno shemo z replikacijo, ki jo bo treba med katastrofo preklopiti ročno, kar bo vplivalo na RTO.

Kaj iz tega sledi? Če res morate zagotoviti minimalni RTO, morate zagotoviti, da je razsodnik odporen na napake. Za to sta na voljo dve možnosti:

• Zaženite virtualni stroj z razsodnikom na hipervizorju, ki je odporen na napake, na srečo vsi hipervizorji za odrasle podpirajo toleranco na napake;
• Če ste na tretjem mestu (v klasični pisarni) preleni za namestitev običajne gruče in ni obstoječe gruče hipervozor, potem smo zagotovili strojno različico razsodnika, ki je izdelan v škatli 2U, v kateri sta dva navadna strežniki x-86 delujejo in lahko preživijo lokalno okvaro.

Močno priporočamo, da zagotovite toleranco napak razsodnika, kljub dejstvu, da je metrocluster v običajnem načinu ne potrebuje. Toda kot kažeta tako teorija kot praksa, je bolje igrati varno, če zgradite resnično zanesljivo infrastrukturo, odporno na nesreče. Bolje je zaščititi sebe in svoje podjetje pred "zakonom zlobnosti", to je pred neuspehom arbitra in enega od mest, kjer se nahaja sistem za shranjevanje.

Arhitektura rešitve

Ob upoštevanju zgornjih zahtev dobimo naslednjo splošno arhitekturo rešitve.

LUN-ji morajo biti enakomerno porazdeljeni po dveh mestih, da se izognete resni preobremenitvi. Hkrati morate pri dimenzioniranju v obeh podatkovnih centrih vključiti ne le dvojni volumen (kar je potrebno za hkratno shranjevanje podatkov v dveh sistemih za shranjevanje), temveč tudi dvojno zmogljivost v IOPS in MB/s, da preprečite degradacijo aplikacije v primeru okvare enega od podatkovnih centrov ov.

Ločeno ugotavljamo, da s pravilnim pristopom k dimenzioniranju (to je pod pogojem, da smo zagotovili ustrezne zgornje meje IOPS in MB/s ter potrebna sredstva CPU in RAM), če eden od sistemov za shranjevanje v metro grozd odpove, ne bo resnega padca zmogljivosti pod pogoji začasnega dela na enem sistemu za shranjevanje.

To je razloženo z dejstvom, da ko dve strani delujeta hkrati, sinhrona replikacija "poje" polovico zmogljivosti pisanja, saj mora biti vsaka transakcija zapisana v dva sistema za shranjevanje (podobno kot RAID-1/10). Torej, če eden od pomnilniških sistemov odpove, vpliv replikacije začasno (dokler se okvarjeni pomnilniški sistem ne obnovi) izgine in dobimo dvakratno povečanje zmogljivosti zapisovanja. Ko se LUN-i okvarjenega pomnilniškega sistema znova zaženejo na delujočem pomnilniškem sistemu, to dvakratno povečanje izgine zaradi dejstva, da se pojavi obremenitev iz LUN-ov drugega pomnilniškega sistema, in vrnemo se na enako raven zmogljivosti, kot smo jo imeli pred »padec«, vendar le v okviru enega mesta.

S pomočjo kompetentnega dimenzioniranja lahko zagotovite pogoje, v katerih uporabniki sploh ne bodo čutili okvare celotnega sistema za shranjevanje. A ponavljamo še enkrat, to zahteva zelo skrbno dimenzioniranje, za kar nas mimogrede lahko brezplačno kontaktirate :-).

Postavitev metroclustra

Nastavitev metroclustra je zelo podobna nastavitvi običajne replikacije, ki smo jo opisali v prejšnji članek. Zato se osredotočimo le na razlike. V laboratoriju smo postavili klop na osnovi zgornje arhitekture, le v minimalni izvedbi: dva sistema za shranjevanje, povezana preko 10G Etherneta, dve stikali 10G in en host, ki skozi stikala gleda na oba sistema za shranjevanje z 10G priključki. Razsodnik deluje na virtualnem stroju.

Ko konfigurirate navidezne IP-je (VIP-je) za repliko, morate izbrati vrsto VIP - za metrocluster.

Ustvarili smo dve replikacijski povezavi za dva LUN-a in ju razdelili v dva sistema za shranjevanje: LUN TEST Primary na sistemu za shranjevanje 1 (povezava METRO), LUN TEST2 Primary za sistem za shranjevanje 2 (povezava METRO2).

Zanje smo konfigurirali dva enaka cilja (v našem primeru iSCSI, vendar je podprt tudi FC, logika nastavitve je enaka).

Sistem za shranjevanje1:

Sistem za shranjevanje2:

Za replikacijske povezave so bile narejene preslikave na vsakem sistemu za shranjevanje.

Sistem za shranjevanje1:

Sistem za shranjevanje2:

Nastavili smo multipath in ga predstavili gostitelju.

Postavitev arbitra

S samim razsodnikom vam ni treba narediti nič posebnega, le omogočiti ga morate na tretjem mestu, mu dodeliti IP in konfigurirati dostop do njega prek ICMP in SSH. Sama nastavitev se izvaja iz samih sistemov za shranjevanje. V tem primeru je dovolj, da arbiter konfigurirate enkrat na katerem koli krmilniku pomnilnika v metroclustru; te nastavitve bodo samodejno razdeljene na vse krmilnike.

V razdelku Oddaljena replikacija >> Metrocluster (na katerem koli krmilniku) >> gumb »Konfiguriraj«.

Vnesemo IP razsodnika ter krmilna vmesnika dveh daljinskih krmilnikov za shranjevanje.

Po tem morate omogočiti vse storitve (gumb »Znova zaženi vse«). Če bodo v prihodnosti znova konfigurirane, je treba storitve znova zagnati, da bodo nastavitve začele veljati.

Preverimo, ali vse storitve delujejo.

S tem je nastavitev metroclustra končana.

Crash test

Preizkus trka v našem primeru bo precej preprost in hiter, saj je bila funkcija replikacije (preklapljanje, doslednost itd.) obravnavana v zadnji članek. Zato je za preizkus zanesljivosti metroclustra dovolj, da preverimo avtomatizacijo zaznavanja okvar, preklopov in odsotnosti zapisovalnih izgub (I/O stop).

Da bi to naredili, emuliramo popolno odpoved enega od pomnilniških sistemov tako, da fizično izklopimo oba njegova krmilnika, pri čemer najprej začnemo kopirati veliko datoteko v LUN, ki mora biti aktivirana na drugem pomnilniškem sistemu.

Onemogočite en sistem za shranjevanje. Na drugem sistemu za shranjevanje vidimo v dnevnikih opozorila in sporočila, da je bila povezava s sosednjim sistemom izgubljena. Če je konfigurirano obveščanje prek SMTP ali SNMP nadzora, bo skrbnik prejel ustrezna obvestila.

Točno 10 sekund pozneje (vidno na obeh posnetkih zaslona) je povezava METRO replikacije (tista, ki je bila primarna na okvarjenem sistemu za shranjevanje) samodejno postala primarna na delujočem sistemu za shranjevanje. Z uporabo obstoječega preslikave je LUN TEST ostal na voljo gostitelju, snemanje je nekoliko padlo (znotraj obljubljenih 10 odstotkov), vendar ni bilo prekinjeno.

Test uspešno zaključen.

Povzemanje

Trenutna implementacija metroclustra v sistemih za shranjevanje podatkov AERODISK Engine N-series v celoti omogoča reševanje problemov, kjer je treba odpraviti ali minimizirati izpade IT storitev in zagotoviti njihovo delovanje 24/7/365 z minimalnimi stroški dela.

Seveda lahko rečemo, da je vse to teorija, idealni laboratorijski pogoji in tako naprej ... VENDAR imamo številne izvedene projekte, v katerih smo implementirali funkcionalnost odpornosti na nesreče in sistemi delujejo odlično. Eden od naših dokaj znanih kupcev, ki uporablja le dva sistema za shranjevanje v konfiguraciji, odporni proti katastrofam, se je že strinjal z objavo informacij o projektu, zato bomo v naslednjem delu govorili o bojni izvedbi.

Hvala, veselimo se produktivne razprave.

Vir: www.habr.com