Pozdrav, čitaoci Habra! U prošlom članku smo govorili o jednostavnom načinu oporavka od katastrofe u AERODISK ENGINE sistemima za pohranu - replikaciji. U ovom članku ćemo zaroniti u složeniju i zanimljiviju temu - metroklaster, odnosno sredstvo automatizirane zaštite od katastrofe za dva podatkovna centra, koje omogućava rad centara podataka u aktivno-aktivnom načinu rada. Reći ćemo vam, pokazati, razbiti i popraviti.
Kao i obično, prvo teorija
Metroklaster je klaster raspoređen na nekoliko lokacija unutar grada ili regije. Riječ “klaster” jasno nam nagovještava 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, pokvareni kanali, itd.), sistem za skladištenje će samostalno izvršiti potrebne radnje kako bi održao dostupnost podataka. Kada koristite obične replike, ove radnje u potpunosti ili djelimično izvodi administrator.
Što on radi?
Glavni cilj koji korisnici teže kada koriste određene implementacije metroklastera je minimiziranje RTO (Recovery Time Objective). Odnosno, da se smanji vrijeme oporavka IT usluga nakon kvara. Ako koristite redovnu replikaciju, vrijeme oporavka će uvijek biti duže od vremena oporavka kod metroklastera. Zašto? Veoma jednostavno. Administrator mora biti za svojim stolom i ručno prebaciti replikaciju, a metroklaster to radi automatski.
Ako nemate dežurnog dežurnog administratora koji ne spava, ne jede, ne puši, ne razboli se i 24 sata dnevno prati stanje skladišnog sistema, onda ne postoji način da se garantuje da će administrator biti dostupan za ručno prebacivanje tokom kvara.
Shodno tome, RTO u odsustvu metroklastera ili besmrtnog administratora 99. nivoa dežurne službe administratora će biti jednak zbiru vremena uključivanja svih sistema i maksimalnog vremenskog perioda nakon kojeg administrator garantuje početak rada sa sistemima za skladištenje i povezanim sistemima.
Dakle, dolazimo do očiglednog zaključka da metroklaster treba koristiti ako su zahtjevi za RTO minuti, a ne sati ili dani, odnosno kada u slučaju najgoreg kvara podatkovnog centra IT odjel mora poslovanju osigurati vrijeme za vraćanje pristupa IT uslugama u roku od nekoliko minuta ili čak sekundi.
Как это работает?
Na nižem nivou, metroklaster koristi mehanizam za sinkronu replikaciju podataka, koji smo opisali u prethodnom članku (vidi. ). Budući da je replikacija sinhrona, zahtjevi za nju su odgovarajući, odnosno:
- optičko vlakno kao fizika, 10 gigabitni Ethernet (ili više);
- udaljenost između data centara nije veća od 40 kilometara;
- Kašnjenje optičkog kanala između centara podataka (između sistema za skladištenje) je do 5 milisekundi (optimalno 2).
Svi ovi zahtjevi su savjetodavne prirode, odnosno metroklaster će raditi i ako ovi zahtjevi nisu ispunjeni, ali moramo razumjeti da su posljedice nepoštovanja ovih zahtjeva jednake usporavanju rada oba sistema skladištenja u metroklastera.
Dakle, sinhrona replika se koristi za prijenos podataka između sustava za pohranu, a kako se replike automatski mijenjaju i, što je najvažnije, kako izbjeći podijeljeni mozak? Za to se na višem nivou koristi dodatni entitet - arbitar.
Kako arbitar radi i koji je njegov zadatak?
Arbitar je mala virtuelna mašina ili hardverski klaster koji se mora pokrenuti na trećem mestu (na primer, u kancelariji) i obezbediti pristup sistemu za skladištenje preko ICMP i SSH. Nakon pokretanja, arbitar treba postaviti IP, a zatim sa strane skladišta navesti njegovu adresu, plus adrese daljinskih upravljača koji učestvuju u metroklasteru. Nakon toga, sudija je spreman za rad.
Arbitar stalno prati sve skladišne sisteme u metroklasteru i ako je određeni sistem skladištenja nedostupan, nakon potvrde nedostupnosti od drugog člana klastera (jedan od „živih“ sistema za skladištenje), odlučuje da pokrene proceduru za prebacivanje pravila replikacije. i mapiranje.
Veoma važna tačka. Arbitar mora uvijek biti lociran na mjestu različitom od onih na kojima se nalaze sistemi za skladištenje podataka, odnosno ni u data centru 1, gde je instaliran sistem za skladištenje podataka 1, niti u data centru 2, gde je instaliran sistem za skladištenje podataka 2.
Zašto? Jer to je jedini način na koji arbitar, uz pomoć jednog od sačuvanih sistema za skladištenje podataka, može nedvosmisleno i tačno utvrditi pad bilo koje od dve lokacije na kojima su sistemi za skladištenje instalirani. Bilo koji drugi način postavljanja arbitra može dovesti do podjele mozga.
Sada zaronimo u detalje rada arbitra.
Arbitar pokreće nekoliko servisa koji stalno ispituju sve kontrolere memorije. Ako se rezultat ankete razlikuje od prethodnog (dostupan/nedostupan), onda se on snima u malu bazu podataka, koja takođe radi na arbitru.
Pogledajmo detaljnije logiku rada arbitra.
Korak 1: Utvrdite nedostupnost. Događaj kvara sistema za skladištenje je odsustvo pinga od oba kontrolera istog sistema skladištenja u roku od 5 sekundi.
Korak 2. Pokrenite proceduru prebacivanja. Nakon što arbitar shvati da je jedan od sistema za skladištenje nedostupan, on šalje zahtev „živom” sistemu skladištenja kako bi se uverio da je „mrtvi” sistem skladištenja zaista mrtav.
Nakon što dobije takvu komandu od arbitra, drugi (živi) sistem skladištenja dodatno provjerava dostupnost palog prvog skladišnog sistema i, ako ga nema, šalje potvrdu arbitru svoje nagađanja. Sistem za skladištenje je zaista nedostupan.
Nakon što primi takvu potvrdu, arbitar pokreće udaljenu proceduru za prebacivanje replikacije i podizanje mapiranja na one replike koje su bile aktivne (primarne) na palom sistemu skladištenja i šalje komandu drugom sistemu za skladištenje da promeni ove replike iz sekundarnih u primarne i mapiranje podizanja. Pa, drugi sistem skladištenja, u skladu s tim, izvodi ove procedure, a zatim obezbeđuje pristup izgubljenim LUN-ovima iz sebe.
Zašto je potrebna dodatna verifikacija? Za kvorum. To jest, većina 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, shodno tome, podijeljeni mozak.
Vremenski korak 2 traje otprilike 5 - 10 sekundi, tako da će, uzimajući u obzir vrijeme potrebno za utvrđivanje nedostupnosti (5 sekundi), unutar 10 - 15 sekundi nakon nesreće, LUN-ovi iz palog skladišnog sistema automatski biti dostupni za rad sa uživo sistem skladištenja.
Jasno je da kako biste izbjegli gubljenje veze s hostovima, također morate voditi računa o pravilnom konfigurisanju timeouta na hostovima. Preporučeno vremensko ograničenje je najmanje 30 sekundi. Ovo će spriječiti host da prekine vezu sa sistemom za skladištenje tokom 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 metroklasterom, zašto nam je uopće potrebna redovna replikacija?
U stvarnosti, nije sve tako jednostavno.
Razmotrimo prednosti i nedostatke metroklastera
Dakle, shvatili smo da su očigledne prednosti metroklastera u odnosu na konvencionalnu replikaciju:
- Potpuna automatizacija, osiguravajući minimalno vrijeme oporavka u slučaju katastrofe;
- To je sve :-).
A sada, pažnja, nedostaci:
- Trošak rješenja. Iako metroklaster u Aerodisk sistemima ne zahtijeva dodatno licenciranje (koristi se ista licenca kao i za repliku), cijena rješenja će i dalje biti veća od korištenja sinhrone replikacije. Morat ćete implementirati sve zahtjeve za sinhronu repliku, plus zahtjeve za metroklaster povezane s dodatnim prebacivanjem i dodatnim mjestom (pogledajte planiranje metroklastera);
- Složenost rješenja. Metroklaster je mnogo složeniji od obične replike i zahtijeva mnogo više pažnje i truda za planiranje, konfiguraciju i dokumentaciju.
Na kraju. Metrocluster je svakako vrlo tehnološki napredno i dobro rješenje kada zaista trebate dati RTO za nekoliko sekundi ili minuta. Ali ako nema tog zadatka, a RTO u satima je OK za posao, onda nema smisla gađati vrapce iz topa. Dovoljna je uobičajena radnička-seljačka replikacija, jer će metro klaster uzrokovati dodatne troškove i kompliciranje IT infrastrukture.
Planiranje metroklastera
Ovaj odeljak ne tvrdi da je sveobuhvatan vodič za projektovanje metroklastera, već samo pokazuje glavne pravce koje treba razraditi ako odlučite da izgradite takav sistem. Stoga, kada stvarno implementirate metroklaster, obavezno uključite proizvođača sistema za skladištenje (to jest, nas) i druge povezane sisteme za konsultacije.
Mesta
Kao što je gore navedeno, metroklaster zahtijeva najmanje tri lokacije. Dva data centra u kojima će raditi sistemi za skladištenje podataka i povezani sistemi, kao i treća lokacija na kojoj će raditi arbitar.
Preporučena udaljenost između data centara nije veća od 40 kilometara. Veća udaljenost može uzrokovati dodatna kašnjenja, koja su u slučaju metroklastera izuzetno nepoželjna. Podsjetimo, kašnjenja bi trebala biti do 5 milisekundi, iako je preporučljivo zadržati ih unutar 2.
Preporučljivo je provjeriti kašnjenja i tokom procesa planiranja. Svaki više ili manje zreo provajder koji obezbeđuje optičko vlakno između centara podataka može vrlo brzo da organizuje proveru kvaliteta.
Što se tiče kašnjenja pred arbitrom (odnosno između trećeg sajta i prva dva), preporučeni prag kašnjenja je do 200 milisekundi, odnosno prikladna je obična korporativna VPN veza preko Interneta.
Prebacivanje i umrežavanje
Za razliku od šeme replikacije, gde je dovoljno povezati sisteme za skladištenje sa različitih lokacija, šema metroklastera zahteva povezivanje hostova sa oba sistema skladištenja na različitim lokacijama. Da bi bilo jasnije u čemu je razlika, obje sheme su prikazane u nastavku.
Kao što se može vidjeti iz dijagrama, naši hostovi na lokaciji 1 gledaju i sistem za skladištenje 1 i sistem skladištenja 2. Takođe, naprotiv, hostovi lokacije 2 gledaju i sistem skladištenja 2 i sistem skladištenja 1. Odnosno, svaki domaćin vidi oba sistema skladištenja. Ovo je preduslov za rad metroklastera.
Naravno, nema potrebe za povezivanjem svakog hosta optičkim kablom na drugi data centar; neće biti dovoljni nikakvi portovi ili kablovi. Sve ove veze moraju biti napravljene preko Ethernet 10G+ ili FibreChannel 8G+ prekidača (FC je samo za povezivanje hostova i sistema za skladištenje za IO, kanal za replikaciju je trenutno dostupan samo preko IP-a (Ethernet 10G+).
Sada nekoliko riječi o topologiji mreže. Važna tačka je ispravna konfiguracija podmreža. Potrebno je odmah definisati nekoliko podmreža za sledeće vrste saobraćaja:
- Podmreža za replikaciju 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 ih ima dva, očito se rutiranje mora konfigurirati između njih;
- Podmreže za skladištenje preko kojih će hostovi pristupati resursima za skladištenje (ako je iSCSI). Trebalo bi da postoji jedna takva podmreža u svakom data centru;
- Kontrolne podmreže, odnosno tri rutabilne podmreže na tri lokacije sa kojih se upravlja sistemima za skladištenje podataka, a tu se nalazi i arbitar.
Ovdje ne razmatramo podmreže za pristup resursima hosta, budući da one u velikoj mjeri zavise od zadataka.
Odvajanje različitog saobraćaja u različite podmreže je izuzetno važno (posebno je važno odvojiti repliku od I/O), jer ako pomešate sav saobraćaj u jednu „debelu“ podmrežu, tada će tim saobraćajem biti nemoguće upravljati, a uvjeti dvaju podatkovnih centara to i dalje može uzrokovati različite opcije kolizije mreže. Nećemo se upuštati duboko u ovo pitanje u okviru ovog članka, jer o planiranju mreže razvučene između centara podataka 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 interfejsima sistema za skladištenje preko ICMP i SSH protokola. Trebalo bi razmišljati i o sigurnosti arbitra. Ovdje postoji nijansa.
Arbiter failover je veoma poželjan, ali nije obavezan. Šta se dešava ako se sudija sruši u pogrešno vreme?
- Rad metroklastera u normalnom režimu neće se promeniti, jer arbtir nema apsolutno nikakav utjecaj na rad metroklastera u normalnom načinu rada (njegov zadatak je da blagovremeno prebaci opterećenje između podatkovnih centara)
- Štaviše, ako arbitar iz ovog ili onog razloga padne i „prespava“ nesreću u data centru, onda neće doći do prebacivanja, jer neće imati ko da daje potrebne komande za prebacivanje i organizuje kvorum. U ovom slučaju, metroklaster će se pretvoriti u redovnu šemu sa replikacijom, koja će se morati ručno prebaciti tokom katastrofe, što će uticati na RTO.
Šta iz ovoga slijedi? Ako zaista trebate osigurati minimalni RTO, morate osigurati da je arbitar tolerantan na greške. Za ovo postoje dvije opcije:
- Pokrenite virtuelnu mašinu sa arbitrom na hipervizoru otpornom na greške, na sreću svi hipervizori za odrasle podržavaju toleranciju grešaka;
- Ako ste na trećem mjestu (u konvencionalnoj kancelariji) previše lijeni da instalirate normalan klaster, a ne postoji klaster hipervozora, onda smo obezbijedili hardversku verziju arbitra koji je napravljen u kutiji od 2U u kojoj se nalaze dva obična x-86 serveri rade i koji mogu preživjeti lokalni kvar.
Toplo preporučujemo da se osigura tolerancija grešaka arbitra, uprkos činjenici da metroklaster ne treba u normalnom režimu. Ali kao što pokazuju i teorija i praksa, ako izgradite zaista pouzdanu infrastrukturu otpornu na katastrofe, onda je bolje igrati na sigurno. Bolje je zaštititi sebe i svoje poslovanje od „zakona podlosti“, odnosno od propusta i arbitra i jednog od mjesta gdje se nalazi sistem za skladištenje podataka.
Arhitektura rješenja
Uzimajući u obzir gore navedene zahtjeve, dobijamo sljedeću opštu arhitekturu rješenja.
LUN-ovi bi trebali biti ravnomjerno raspoređeni na dvije lokacije kako bi se izbjeglo ozbiljno preopterećenje. Istovremeno, prilikom dimenzionisanja u oba data centra, treba uključiti ne samo dupli volumen (koji je neophodan za istovremeno skladištenje podataka na dva sistema za skladištenje), već i dvostruke performanse u IOPS i MB/s kako bi se sprečila degradacija aplikacije u slučaj kvara jednog od data centara.
Posebno napominjemo da uz pravilan pristup dimenzionisanju (odnosno, pod uslovom da smo obezbedili odgovarajuće gornje granice IOPS i MB/s, kao i neophodne CPU i RAM resurse), ako jedan od sistema za skladištenje podataka u metro klaster pokvari, neće doći do ozbiljnog pada performansi pod uslovima privremenog rada na jednom sistemu skladištenja.
Ovo se objašnjava činjenicom da kada dvije lokacije rade istovremeno, sinhrona replikacija „jede“ polovinu performansi pisanja, budući da svaka transakcija mora biti zapisana u dva sistema za skladištenje (slično RAID-1/10). Dakle, ako jedan od sistema za skladištenje pokvari, uticaj replikacije privremeno (dok se neuspeli sistem skladištenja ne oporavi) nestaje i dobijamo dvostruko povećanje performansi pisanja. Nakon što se LUN-ovi neispravnog skladišnog sistema ponovo pokrenu na radnom sistemu za skladištenje podataka, ovo dvostruko povećanje nestaje zbog činjenice da se javlja opterećenje sa LUN-ova drugog sistema za skladištenje i vraćamo se na isti nivo performansi koji smo imali pre „pada“, ali samo u okviru jednog sajta.
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 koje nas, inače, možete besplatno kontaktirati :-).
Postavljanje metroklastera
Postavljanje metroklastera je vrlo slično postavljanju regularne replikacije, što smo opisali u . Zato se fokusirajmo samo na razlike. Postavili smo klupu u laboratoriju baziranu na gornjoj arhitekturi, samo u minimalnoj verziji: dva sistema za skladištenje podataka povezana preko 10G Etherneta, dva 10G switch-a i jedan host koji gleda kroz prekidače na oba sistema za skladištenje podataka sa 10G portovima. Arbitar radi na virtuelnoj mašini.
Kada konfigurišete virtuelne IP adrese (VIP) za repliku, trebalo bi da izaberete VIP tip - za metroklaster.
Napravili smo dve veze za replikaciju za dva LUN-a i distribuirali ih na dva sistema skladištenja: LUN TEST Primarni na sistemu skladištenja 1 (METRO veza), LUN TEST2 Primarni za sistem skladištenja 2 (METRO2 veza).
Za njih smo konfigurisali dva identična cilja (u našem slučaju iSCSI, ali je podržan i FC, logika podešavanja je ista).
Sistem pohrane 1:
Sistem pohrane 2:
Za veze replikacije, mapiranja su napravljena na svakom sistemu za skladištenje.
Sistem pohrane 1:
Sistem pohrane 2:
Postavili smo multipath i predstavili ga domaćinu.
Postavljanje arbitra
Ne morate ništa posebno raditi sa samim arbitrom, samo ga trebate omogućiti na trećoj stranici, dati mu IP i konfigurirati pristup preko ICMP-a i SSH-a. Samo podešavanje se vrši iz samih sistema za skladištenje podataka. U ovom slučaju, dovoljno je jednom konfigurirati arbitar na bilo kojem od kontrolera za skladištenje u metroklasteru; ove postavke će se automatski distribuirati na sve kontrolere.
U odjeljku Udaljena replikacija>> Metrocluster (na bilo kojem kontroleru)>> dugme “Konfiguriraj”.
Unosimo IP arbitra, kao i kontrolna sučelja dva daljinska kontrolera skladištenja.
Nakon toga morate omogućiti sve usluge (dugme „Ponovo pokreni sve“). Ako se u budućnosti ponovo konfigurišu, usluge se moraju ponovo pokrenuti da bi postavke stupile na snagu.
Provjeravamo da li sve usluge rade.
Ovo završava postavljanje metroklastera.
Test sudara
Crash test u našem slučaju će biti prilično jednostavan i brz, budući da je funkcionalnost replikacije (prebacivanje, konzistentnost, itd.) razmatrana u . Stoga je za testiranje pouzdanosti metroklastera dovoljno da provjerimo automatizaciju detekcije kvarova, komutacije i odsustva gubitaka pri snimanju (I/O zaustavljanja).
Da bismo to uradili, emuliramo potpuni otkaz jednog od sistema za skladištenje tako što ćemo fizički isključiti oba njegova kontrolera, nakon što smo prvo počeli da kopiramo veliki fajl na LUN, koji se mora aktivirati na drugom sistemu za skladištenje.
Onemogućite jedan sistem skladištenja. Na drugom sistemu skladištenja vidimo upozorenja i poruke u logovima da je veza sa susjednim sistemom izgubljena. Ako se konfiguriraju obavijesti putem SMTP ili SNMP nadzora, administrator će primati odgovarajuća obavještenja.
Tačno 10 sekundi kasnije (vidljivo na oba snimka ekrana), METRO replikacijska veza (ona koja je bila primarna na neispravnom sistemu skladištenja) automatski je postala primarna na radnom sistemu za skladištenje. Koristeći postojeće mapiranje, LUN TEST je ostao dostupan hostu, snimanje je malo palo (unutar obećanih 10 posto), ali nije prekinuto.
Test je uspješno završen.
Sumiranje
Trenutna implementacija metroklastera u sisteme skladištenja AERODISK Engine N-serije u potpunosti omogućava rješavanje problema gdje je potrebno eliminirati ili minimizirati zastoje IT usluga i osigurati njihov rad 24/7/365 uz minimalne troškove rada.
Možemo reći, naravno, da je sve ovo teorija, idealni laboratorijski uslovi i tako dalje... ALI imamo niz implementiranih projekata u kojima smo implementirali funkcionalnost otpornosti na katastrofe, a sistemi rade savršeno. Jedan od naših prilično poznatih kupaca, koji koristi samo dva sistema za pohranu podataka u konfiguraciji otpornoj na katastrofe, već je pristao da objavi informacije o projektu, pa ćemo u narednom dijelu govoriti o borbenoj implementaciji.
Hvala, radujemo se produktivnoj diskusiji.
izvor: www.habr.com