Pozdrav, čitatelji Habra! U prošlom članku govorili smo o jednostavnom načinu oporavka od katastrofe u AERODISK ENGINE sustavima za pohranu – replikaciji. U ovom ćemo članku zaroniti u složeniju i zanimljiviju temu - metrocluster, odnosno sredstvo automatizirane zaštite od katastrofe za dva podatkovna centra, omogućujući podatkovnim centrima da rade u aktivnom-aktivnom načinu rada. Reći ćemo vam, pokazati, razbiti i popraviti.
Kao i obično, prvo teorija
Metroklaster je klaster raširen na nekoliko lokacija unutar grada ili regije. Riječ "klaster" jasno nam daje naslutiti da je kompleks automatiziran, odnosno da se prebacivanje čvorova klastera u slučaju kvarova događa automatski.
Tu leži glavna razlika između metroklastera i regularne replikacije. Automatizacija operacija. Odnosno, u slučaju određenih incidenata (kvar podatkovnog centra, prekinuti kanali itd.), sustav za pohranu će samostalno izvršiti potrebne radnje kako bi održao dostupnost podataka. Kada koristite obične replike, ove radnje u cijelosti ili djelomično ručno izvodi administrator.
Što to učiniti?
Glavni cilj kojem korisnici teže kada koriste određene implementacije metroklastera je minimizirati RTO (Cilj vremena oporavka). Odnosno, smanjiti vrijeme oporavka IT usluga nakon kvara. Ako koristite redovitu replikaciju, vrijeme oporavka uvijek će biti dulje od vremena oporavka s metroklasterom. Zašto? Jako jednostavno. Administrator mora biti za svojim stolom i ručno prebacivati replikaciju, a metrocluster to radi automatski.
Ako nemate posvećenog administratora na dužnosti koji ne spava, ne jede, ne puši i ne razbolijeva se, a prati stanje skladišnog sustava 24 sata dnevno, onda nema načina da vam jamči da će administrator biti dostupan za ručno prebacivanje tijekom kvara.
Sukladno tome, RTO u nedostatku metroklastera ili besmrtnog administratora 99. razine administratorske službe bit će jednak zbroju vremena prebacivanja svih sustava i maksimalnog vremenskog razdoblja nakon kojeg je zajamčeno da će administrator početi raditi sa sustavima za pohranu i srodnim sustavima.
Dakle, dolazimo do očitog zaključka da se metrocluster treba koristiti ako su zahtjev za RTO minute, a ne sati ili dani. To jest, kada u slučaju najgoreg kvara podatkovnog centra, IT odjel mora osigurati poslovanju vrijeme za vraćanje pristupa IT uslugama u roku od nekoliko minuta ili čak sekundi.
Kako se to radi?
Na nižoj razini, metrocluster koristi mehanizam za sinkronu replikaciju podataka, koji smo opisali u prethodnom članku (vidi. ). Budući da je replikacija sinkrona, zahtjevi za nju su odgovarajući, odnosno:
- optičko vlakno kao fizika, 10 gigabitni Ethernet (ili viši);
- udaljenost između podatkovnih centara nije veća od 40 kilometara;
- Kašnjenje optičkog kanala između podatkovnih centara (između sustava za pohranu) je do 5 milisekundi (optimalno 2).
Svi ovi zahtjevi su savjetodavne prirode, odnosno metroklaster će raditi čak i ako ti zahtjevi nisu ispunjeni, ali moramo shvatiti da su posljedice nepoštivanja ovih zahtjeva jednake usporavanju rada oba sustava za pohranu u metrocluster.
Dakle, sinkrona replika se koristi za prijenos podataka između sustava za pohranu, i kako se replike automatski prebacuju i, što je najvažnije, kako izbjeći split-brain? Da bi se to postiglo, na višoj razini koristi se dodatni entitet - arbitar.
Kako radi i koja je njegova zadaća arbitar?
Arbitar je mali virtualni stroj ili hardverski klaster koji se mora pokrenuti na trećem mjestu (na primjer, u uredu) i omogućiti pristup sustavu za pohranu putem ICMP-a i SSH-a. Nakon pokretanja, arbitar bi trebao postaviti IP, a zatim sa strane pohrane naznačiti svoju adresu, plus adrese daljinskih upravljača koji sudjeluju u metroklasteru. Nakon toga sudac je spreman za rad.
Arbitar stalno nadzire sve sustave pohrane u metroclusteru i ako je određeni sustav pohrane nedostupan, nakon potvrde nedostupnosti od drugog člana klastera (jednog od “živih” sustava pohrane), odlučuje pokrenuti proceduru za prebacivanje pravila replikacije i mapiranje.
Vrlo važna točka. Arbitar se uvijek mora nalaziti na mjestu različitom od onih na kojima se nalaze sustavi pohrane, odnosno ne u podatkovnom centru 1, gdje je instaliran sustav pohrane 1, niti u podatkovnom centru 2, gdje je instaliran sustav pohrane 2.
Zašto? Jer samo tako arbitar, uz pomoć jednog od sačuvanih skladišnih sustava, može nedvosmisleno i točno utvrditi pad bilo kojeg od dva mjesta na kojima su postavljeni skladišni sustavi. Sve druge metode postavljanja suca mogu dovesti do podijeljenog mozga.
Uronimo sada u detalje rada arbitra.
Arbitar vodi nekoliko servisa koji stalno ispituju sve kontrolere pohrane. Ako se rezultat ankete razlikuje od prethodnog (dostupan/nedostupan), tada se bilježi u malu bazu podataka, koja također radi na arbitru.
Pogledajmo detaljnije logiku rada arbitra.
Korak 1: Utvrdite nedostupnost. Događaj kvara sustava za pohranu je izostanak pinga s oba kontrolera istog sustava za pohranu unutar 5 sekundi.
Korak 2. Pokrenite proceduru prebacivanja. Nakon što je arbitar shvatio da je jedan od sustava pohrane nedostupan, šalje zahtjev "živom" sustavu pohrane kako bi se uvjerio da je "mrtav" sustav pohrane stvarno mrtav.
Nakon primitka takve naredbe od suca, drugi (živi) sustav za pohranjivanje dodatno provjerava dostupnost palog prvog sustava za pohranjivanje i, ako ga nema, šalje arbitru potvrdu njegovog pogađanja. Sustav za pohranu doista nije dostupan.
Nakon primitka takve potvrde, arbitar pokreće udaljenu proceduru za prebacivanje replikacije i podizanje mapiranja na onim replikama koje su bile aktivne (primarne) na pokvarenom sustavu pohrane i šalje naredbu drugom sustavu pohrane da promijeni te replike iz sekundarnih u primarne i podići preslikavanje. Pa, drugi sustav za pohranu, u skladu s tim, izvodi ove postupke, a zatim omogućuje pristup izgubljenim LUN-ovima iz sebe.
Zašto je potrebna dodatna provjera? Za kvorum. To jest, većina od ukupnog neparnog (3) broja članova klastera mora potvrditi pad jednog od čvorova klastera. Tek tada će ova odluka biti definitivno ispravna. To je neophodno kako bi se izbjeglo pogrešno prebacivanje i, sukladno tome, podijeljeni mozak.
Vremenski korak 2 traje otprilike 5 - 10 sekundi, stoga će, uzimajući u obzir vrijeme potrebno za utvrđivanje nedostupnosti (5 sekundi), unutar 10 - 15 sekundi nakon nesreće, LUN-ovi iz pokvarenog sustava za pohranu biti automatski dostupni za rad s aktivnim sustav skladištenja.
Jasno je da, kako biste izbjegli gubitak veze s hostovima, također morate paziti da pravilno konfigurirate timeouts na hostovima. Preporučeno vrijeme čekanja je najmanje 30 sekundi. Ovo će spriječiti glavno računalo da prekine vezu sa sustavom za pohranu tijekom prebacivanja opterećenja u slučaju katastrofe i može osigurati da nema I/O prekida.
Čekaj malo, ispada da ako je sve tako dobro s metroclusterom, zašto nam uopće treba redovita replikacija?
U stvarnosti sve nije tako jednostavno.
Razmotrimo prednosti i nedostatke metroklastera
Dakle, shvatili smo da su očite prednosti metroklastera u usporedbi s konvencionalnom replikacijom:
- Potpuna automatizacija, koja osigurava minimalno vrijeme oporavka u slučaju katastrofe;
- To je sve :-).
A sada, pažnja, kontra:
- Cijena rješenja. Iako metrocluster u sustavima Aerodisk ne zahtijeva dodatno licenciranje (koristi se ista licenca kao i za repliku), cijena rješenja će ipak biti čak i viša od korištenja sinkrone replikacije. Morat ćete implementirati sve zahtjeve za sinkronu repliku, plus zahtjeve za metroklaster povezane s dodatnim prebacivanjem i dodatnim mjestom (pogledajte planiranje metroklastera);
- Složenost rješenja. Metrocluster je mnogo složeniji od obične replike, te zahtijeva puno više pažnje i truda za planiranje, konfiguraciju i dokumentaciju.
Eventualno. Metrocluster je svakako vrlo tehnološki napredno i dobro rješenje kada stvarno trebate osigurati RTO u sekundama ili minutama. Ali ako tog zadatka nema, a RTO u satima je OK za posao, onda nema smisla gađati vrapce iz topa. Dovoljna je uobičajena radničko-seljačka replikacija, jer će metro klaster uzrokovati dodatne troškove i kompliciranje IT infrastrukture.
Metrocluster planiranje
Ovaj odjeljak ne predstavlja sveobuhvatan vodič za projektiranje metroklastera, već samo pokazuje glavne smjernice koje bi trebalo razraditi ako odlučite izgraditi takav sustav. Stoga, kada zapravo implementirate metrocluster, svakako uključite proizvođača sustava za pohranu (odnosno nas) i druge povezane sustave za konzultacije.
Mjesta
Kao što je gore navedeno, metroklaster zahtijeva najmanje tri lokacije. Dva podatkovna centra u kojima će raditi sustavi za pohranu i povezani sustavi, kao i treća lokacija na kojoj će raditi arbitar.
Preporučena udaljenost između podatkovnih centara nije veća od 40 kilometara. Veća udaljenost vrlo je vjerojatno da će uzrokovati dodatna kašnjenja, koja su u slučaju metroklastera krajnje nepoželjna. Podsjetimo, kašnjenja bi trebala biti do 5 milisekundi, iako je poželjno da budu unutar 2 milisekunde.
Preporuča se provjeriti kašnjenja i tijekom procesa planiranja. Svaki više ili manje zreo pružatelj koji pruža optička vlakna između podatkovnih centara može vrlo brzo organizirati provjeru kvalitete.
Što se tiče kašnjenja pred arbitrom (odnosno između trećeg mjesta i prva dva), preporučeni prag kašnjenja je do 200 milisekundi, odnosno prikladna je redovita korporativna VPN veza preko Interneta.
Prebacivanje i umrežavanje
Za razliku od sheme replikacije, gdje je dovoljno povezati sustave za pohranu s različitih lokacija, shema metroclustera zahtijeva povezivanje hostova s oba sustava za pohranu na različitim mjestima. Da bi bilo jasnije koja je razlika, obje sheme su prikazane u nastavku.
Kao što se može vidjeti iz dijagrama, hostovi naše stranice 1 gledaju i sustav pohrane 1 i sustav pohrane 2. Također, naprotiv, hostovi stranice 2 gledaju i sustav pohrane 2 i sustav pohrane 1. To jest, svaki host vidi oba sustava za pohranu. To je preduvjet za rad metroklastera.
Naravno, nema potrebe povezivati svaki host optičkim kabelom s drugim podatkovnim centrom; nikakvi priključci ili kabeli neće biti dovoljni. Sve ove veze moraju se uspostaviti putem Ethernet 10G+ ili FibreChannel 8G+ preklopnika (FC služi samo za povezivanje hostova i sustava za pohranu za IO, replikacijski kanal trenutno je dostupan samo putem IP-a (Ethernet 10G+).
Sada nekoliko riječi o topologiji mreže. Važna točka je ispravna konfiguracija podmreža. Potrebno je odmah definirati nekoliko podmreža za sljedeće vrste prometa:
- Replikacijska podmreža preko koje će se podaci sinkronizirati između sustava za pohranu. Može ih biti nekoliko, u ovom slučaju nije bitno, sve ovisi o trenutnoj (već implementiranoj) topologiji mreže. Ako postoje dva od njih, onda očito usmjeravanje mora biti konfigurirano između njih;
- Podmreže za pohranu putem kojih će hostovi pristupati resursima za pohranu (ako je iSCSI). Trebala bi postojati jedna takva podmreža u svakom podatkovnom centru;
- Kontrolne podmreže, odnosno tri rutabilne podmreže na tri lokacije s kojih se upravlja sustavima za pohranu podataka, a tu se nalazi i arbitar.
Ovdje ne uzimamo u obzir podmreže za pristup resursima glavnog računala, jer one uvelike ovise o zadacima.
Odvajanje različitog prometa u različite podmreže je izuzetno važno (posebno je važno odvojiti repliku od I/O), jer ako sav promet pomiješate u jednu “debelu” podmrežu, tada će tim prometom biti nemoguće upravljati, a u uvjeti dvaju podatkovnih centara to još uvijek mogu uzrokovati različite mogućnosti mrežnog sudara. Nećemo duboko ulaziti u ovo pitanje u okviru ovog članka, jer o planiranju mreže rastegnute između podatkovnih centara možete pročitati na resursima proizvođača mrežne opreme, gdje je to vrlo detaljno opisano.
Konfiguracija arbitra
Arbitar mora omogućiti pristup svim upravljačkim sučeljima sustava za pohranu putem ICMP i SSH protokola. Također biste trebali razmišljati o sigurnosti arbitra. Ovdje postoji jedna nijansa.
Arbiter failover je vrlo poželjan, ali nije obavezan. Što se događa ako se sudac sruši u krivo vrijeme?
- Rad metroklastera u normalnom načinu rada neće se promijeniti, jer arbtir nema apsolutno nikakav utjecaj na rad metroklastera u normalnom načinu rada (njegova je zadaća pravodobno prebacivati opterećenje između podatkovnih centara)
- Štoviše, ako arbitar iz ovog ili onog razloga padne i "prespava" nesreću u podatkovnom centru, tada se neće dogoditi nikakvo prebacivanje, jer neće imati tko dati potrebne naredbe za prebacivanje i organizirati kvorum. U ovom slučaju, metrocluster će se pretvoriti u redovitu shemu s replikacijom, koja će se morati ručno prebaciti tijekom katastrofe, što će utjecati na RTO.
Što iz ovoga slijedi? Ako stvarno trebate osigurati minimalni RTO, morate osigurati da arbitar bude tolerantan na pogreške. Za to postoje dvije mogućnosti:
- Pokrenite virtualni stroj s arbitrom na hipervizoru otpornom na pogreške, srećom svi hipervizori za odrasle podržavaju toleranciju na pogreške;
- Ako ste na trećem mjestu (u konvencionalnom uredu) previše lijeni za instaliranje normalnog klastera, a nema postojećeg hipervozor klastera, onda smo osigurali hardversku verziju arbitra, koja je izrađena u 2U kutiji u kojoj su dva obična x-86 poslužitelji rade i koji mogu preživjeti lokalni kvar.
Toplo preporučamo da se osigura tolerancija na greške arbitra, unatoč činjenici da metrocluster to ne treba u normalnom načinu rada. Ali kao što pokazuju i teorija i praksa, ako izgradite doista pouzdanu infrastrukturu otpornu na katastrofe, onda je bolje igrati na sigurno. Bolje je zaštititi sebe i svoje poslovanje od "zakona podlosti", odnosno od kvara i arbitra i jednog od mjesta na kojima se nalazi sustav za pohranu.
Arhitektura rješenja
Uzimajući u obzir gore navedene zahtjeve, dobivamo sljedeću opću arhitekturu rješenja.
LUN-ovi trebaju biti ravnomjerno raspoređeni na dva mjesta kako bi se izbjeglo ozbiljno preopterećenje. U isto vrijeme, prilikom dimenzioniranja u oba podatkovna centra, trebali biste uključiti ne samo dvostruki volumen (što je neophodno za istovremeno pohranjivanje podataka na dva sustava za pohranu), već i dvostruku izvedbu u IOPS-u i MB/s kako biste spriječili degradaciju aplikacije u slučaj kvara jednog od podatkovnih centara ov.
Zasebno napominjemo da uz pravilan pristup dimenzioniranju (to jest, pod uvjetom da smo osigurali odgovarajuće gornje granice IOPS-a i MB/s, kao i potrebne CPU i RAM resurse), ako jedan od sustava za pohranu u metro klaster ne uspije, neće doći do ozbiljnog pada performansi pod uvjetima privremenog rada na jednom sustavu za pohranu.
To se objašnjava činjenicom da kada dvije stranice rade istovremeno, sinkrona replikacija "pojede" polovicu performansi pisanja, budući da se svaka transakcija mora pisati na dva sustava za pohranu (slično RAID-1/10). Dakle, ako jedan od sustava za pohranu zakaže, utjecaj replikacije privremeno (dok se pokvareni sustav za pohranu ne oporavi) nestaje i dobivamo dvostruko povećanje performansi pisanja. Nakon što se LUN-ovi pokvarenog sustava za pohranu ponovno pokrenu na radnom sustavu za pohranu, ovo dvostruko povećanje nestaje zbog činjenice da se opterećenje pojavljuje s LUN-ova drugog sustava za pohranu i vraćamo se na istu razinu performansi koju smo imali prije “pada”, ali samo u okviru jednog mjesta.
Uz pomoć kompetentnog dimenzioniranja možete osigurati uvjete pod kojima korisnici uopće neće osjetiti kvar cijelog sustava za pohranu. Ali ponavljamo još jednom, ovo zahtijeva vrlo pažljivo dimenzioniranje, za što nas, usput rečeno, možete besplatno kontaktirati :-).
Postavljanje metroklastera
Postavljanje metroklastera vrlo je slično postavljanju regularne replikacije koju smo opisali u . Stoga, usredotočimo se samo na razlike. Postavili smo klupu u laboratoriju temeljenu na gornjoj arhitekturi, samo u minimalnoj verziji: dva sustava za pohranu spojena preko 10G Etherneta, dva 10G preklopnika i jedan host koji kroz preklopnike gleda na oba sustava za pohranu s 10G portovima. Arbitar radi na virtualnom stroju.
Prilikom konfiguriranja virtualnih IP-ova (VIP-ova) za repliku, trebali biste odabrati vrstu VIP-a - za metrocluster.
Stvorili smo dvije replikacijske veze za dva LUN-a i distribuirali ih na dva sustava za pohranu: LUN TEST primarni na sustavu pohrane 1 (METRO veza), LUN TEST2 primarni za sustav pohrane 2 (METRO2 veza).
Za njih smo konfigurirali dva identična cilja (u našem slučaju iSCSI, ali FC je također podržan, logika postavljanja je ista).
Sustav pohrane1:
Sustav pohrane2:
Za replikacijske veze napravljena su mapiranja na svakom sustavu za pohranu.
Sustav pohrane1:
Sustav pohrane2:
Postavili smo multipath i predstavili ga domaćinu.
Postavljanje arbitra
Sa samim arbitrom ne morate ništa posebno raditi, samo ga trebate omogućiti na trećem mjestu, dati mu IP i konfigurirati pristup preko ICMP-a i SSH-a. Sama postavka se izvodi iz samih sustava za pohranu. U ovom slučaju, dovoljno je jednom konfigurirati arbitra na bilo kojem od kontrolera za pohranu u metroclusteru; ove postavke će se automatski distribuirati na sve kontrolere.
U odjeljku Remote replication>> Metrocluster (na bilo kojem kontroleru)>> gumb “Configure”.
Upisujemo IP arbitra, kao i upravljačka sučelja dva udaljena kontrolera za pohranu.
Nakon toga morate omogućiti sve usluge (gumb “Restart Everything”). Ako se u budućnosti ponovno konfiguriraju, usluge se moraju ponovno pokrenuti kako bi postavke stupile na snagu.
Provjeravamo rade li sve usluge.
Ovo dovršava postavljanje metroklastera.
Crash test
Crash test u našem će slučaju biti vrlo jednostavan i brz, budući da je funkcija replikacije (prebacivanje, dosljednost, itd.) razmatrana u . Stoga nam je za testiranje pouzdanosti metroklastera dovoljno provjeriti automatizaciju detekcije kvarova, preklapanje i odsutnost gubitaka snimanja (I/O stops).
Da bismo to učinili, emuliramo potpuni kvar jednog od sustava za pohranu fizičkim isključivanjem oba njegova kontrolera, nakon što smo prvo započeli kopiranje velike datoteke na LUN, koja mora biti aktivirana na drugom sustavu za pohranu.
Onemogućite jedan sustav za pohranu. Na drugom sustavu za pohranu vidimo upozorenja i poruke u zapisnicima da je veza sa susjednim sustavom izgubljena. Ako su konfigurirane obavijesti putem SMTP ili SNMP nadzora, administrator će primiti odgovarajuće obavijesti.
Točno 10 sekundi kasnije (vidljivo na obje snimke zaslona), METRO replikacijska veza (ona koja je bila primarna na neispravnom sustavu pohrane) automatski je postala primarna na radnom sustavu pohrane. Koristeći postojeće mapiranje, LUN TEST je ostao dostupan hostu, snimka je malo pala (unutar obećanih 10 posto), ali nije prekinuta.
Test je uspješno završen.
Ukratko
Trenutna implementacija metroklastera u sustavima za pohranu AERODISK Engine N-serije u potpunosti omogućuje rješavanje problema gdje je potrebno eliminirati ili minimizirati vrijeme zastoja IT usluga i osigurati njihov rad 24/7/365 uz minimalne troškove rada.
Možemo, naravno, reći da je sve ovo teorija, idealni laboratorijski uvjeti i tako dalje... ALI imamo niz implementiranih projekata u kojima smo implementirali funkcionalnost otpornosti na katastrofe, a sustavi rade savršeno. Jedan od naših prilično poznatih kupaca, koji koriste samo dva skladišna sustava u konfiguraciji otpornoj na katastrofe, već je pristao objaviti informacije o projektu, pa ćemo u sljedećem dijelu govoriti o borbenoj implementaciji.
Hvala, veselimo se produktivnoj raspravi.
Izvor: www.habr.com