Pozdrav, čitaoci Habra! Tema ovog članka će biti implementacija alata za oporavak od katastrofe u AERODISK Engine sistemima za skladištenje podataka. U početku smo htjeli u jednom članku pisati o oba alata: replikaciji i metroklasteru, ali se, nažalost, pokazalo da je članak predugačak, pa smo ga podijelili na dva dijela. Idemo od jednostavnog ka složenom. U ovom članku ćemo postaviti i testirati sinkronu replikaciju - izbacit ćemo jedan podatkovni centar, a također ćemo prekinuti komunikacijski kanal između podatkovnih centara i vidjeti što će se dogoditi.
Naši korisnici nam često postavljaju razna pitanja o replikaciji, pa ćemo vam prije nego što pređemo na postavljanje i testiranje implementacije replika reći nešto o tome što je replikacija u skladištu.
Malo teorije
Replikacija u sistemima za skladištenje je kontinuirani proces obezbeđivanja identiteta podataka na nekoliko sistema skladištenja istovremeno. Tehnički, replikacija se ostvaruje na dva načina.
Sinhrona replikacija – ovo je kopiranje podataka iz glavnog skladišnog sistema u rezervni, nakon čega slijedi obavezna potvrda oba sistema za skladištenje da su podaci snimljeni i potvrđeni. Nakon potvrde sa obe strane (oba sistema skladištenja) podaci se smatraju snimljenim i sa njima se može raditi. Ovo osigurava zagarantovani identitet podataka na svim sistemima skladištenja koji učestvuju u replici.
Prednosti ove metode:
- Podaci su uvijek identični na svim sistemima za pohranu podataka
Cons:
- Visoka cijena rješenja (brzi komunikacijski kanali, skupa optička vlakna, dugovalni primopredajnici, itd.)
- Ograničenja udaljenosti (unutar nekoliko desetina kilometara)
- Ne postoji zaštita od logičkog oštećenja podataka (ako su podaci oštećeni (namjerno ili slučajno) na glavnom sistemu za pohranu, automatski će se odmah oštetiti na sigurnosnom, jer su podaci uvijek identični (to je paradoks)
Asinhrona replikacija – ovo je takođe kopiranje podataka iz glavnog skladišnog sistema u rezervni, ali sa određenim zakašnjenjem i bez potrebe za potvrdom upisa na drugoj strani. Sa podacima možete raditi odmah nakon što ih snimite u glavni sistem za skladištenje podataka, a na sistemu rezervne kopije podaci će biti dostupni nakon nekog vremena. Identitet podataka u ovom slučaju, naravno, uopće nije osiguran. Podaci na sistemu za pohranu rezervnih kopija uvijek su malo "u prošlosti".
Prednosti asinhrone replikacije:
- Rješenje s niskim troškovima (bilo koji kanali komunikacije, opcionalna optika)
- Nema ograničenja udaljenosti
- Na sistemu za pohranu rezervnih kopija podaci se ne pogoršavaju ako se oštete na glavnom (barem neko vrijeme); ako se podaci oštete, uvijek možete zaustaviti repliku kako biste spriječili oštećenje podataka na sistemu za pohranu rezervnih kopija
Cons:
- Podaci u različitim data centrima nisu uvijek identični
Dakle, izbor načina replikacije zavisi od poslovnih ciljeva. Ako je za vas ključno da rezervni podatkovni centar sadrži potpuno iste podatke kao i glavni podatkovni centar (tj. poslovni zahtjev za RPO = 0), tada ćete morati izdvojiti novac i podnijeti ograničenja sinkronog replika. A ako je kašnjenje u stanju podataka prihvatljivo ili jednostavno nema novca, onda svakako trebate koristiti asinkronu metodu.
Takođe posebno istaknemo takav mod (tačnije, topologiju) kao metroklaster. U metroklaster modu se koristi sinhrona replikacija, ali, za razliku od obične replike, metroklaster dozvoljava oba sistema za skladištenje da rade u aktivnom režimu. One. nemate razdvajanje između aktivnih i standby data centara. Aplikacije rade istovremeno sa dva sistema za skladištenje podataka, koji se fizički nalaze u različitim data centrima. Zastoji tokom nezgoda u takvoj topologiji su vrlo mali (RTO, obično minuti). U ovom članku nećemo razmatrati našu implementaciju metroklastera, jer je ovo vrlo velika i obimna tema, pa ćemo joj posvetiti poseban, sljedeći članak, u nastavku ovog.
Takođe, vrlo često, kada govorimo o replikaciji pomoću sistema skladištenja, mnogi ljudi imaju razumno pitanje: > „Mnoge aplikacije imaju svoje alate za replikaciju, zašto koristiti replikaciju na sistemima za skladištenje? Da li je bolje ili gore?
Ovdje nema jasnog odgovora, pa evo argumenata ZA i PROTIV:
Argumenti ZA replikaciju pohrane:
- Jednostavnost rješenja. S jednim alatom možete replicirati cijeli skup podataka, bez obzira na vrstu opterećenja i primjenu. Ako koristite repliku iz aplikacija, morat ćete konfigurirati svaku aplikaciju zasebno. Ako ih ima više od 2, onda je ovo izuzetno radno intenzivno i skupo (replikacija aplikacije obično zahtijeva posebnu, a ne besplatnu licencu za svaku aplikaciju. Ali o tome više u nastavku).
- Možete replicirati bilo šta - bilo koju aplikaciju, bilo koje podatke - i uvijek će biti dosljedno. Mnoge (većina) aplikacija nemaju mogućnosti replikacije, a replike iz sistema za skladištenje su jedini način da se obezbedi zaštita od katastrofa.
- Nema potrebe preplaćivati za funkcionalnost replikacije aplikacije. Po pravilu nije jeftin, baš kao i licence za repliku sistema za skladištenje podataka. Ali licencu za replikaciju skladišta morate platiti jednom, a licencu za repliku aplikacije potrebno je kupiti za svaku aplikaciju posebno. Ako ima puno takvih aplikacija, onda to košta prilično peni, a cijena licenci za replikaciju pohrane postaje kap u kantici.
Argumenti PROTIV replikacije pohrane:
- Replika kroz aplikacije ima više funkcionalnosti sa stanovišta samih aplikacija, aplikacija bolje poznaje svoje podatke (očigledno), tako da postoji više opcija za rad sa njima.
- Proizvođači nekih aplikacija ne garantuju konzistentnost svojih podataka ako se replikacija vrši pomoću alata treće strane. *
* - kontroverzna teza. Na primjer, poznati proizvođač DBMS-a već duže vrijeme službeno izjavljuje da se njihov DBMS može normalno replicirati samo pomoću njihovih sredstava, a ostatak replikacije (uključujući sisteme za pohranu podataka) “nije istina”. Ali život je pokazao da to nije tako. Najvjerovatnije (ali to nije sigurno) ovo jednostavno nije najpošteniji pokušaj prodaje više licenci kupcima.
Kao rezultat toga, u većini slučajeva, replikacija iz sistema za skladištenje je bolja, jer Ovo je jednostavnija i jeftinija opcija, ali postoje složeni slučajevi kada je potrebna specifična funkcionalnost aplikacije i potrebno je raditi s replikacijom na razini aplikacije.
Gotovo sa teorijom, sada praksa
Konfigurisaćemo repliku u našoj laboratoriji. U laboratorijskim uslovima emulirali smo dva data centra (u stvari, dva susedna stalka koja su izgledala kao da su u različitim zgradama). Stalak se sastoji od dva sistema za skladištenje motora N2, koji su međusobno povezani optičkim kablovima. Fizički server sa operativnim sistemom Windows Server 2016 povezan je na oba sistema skladištenja koristeći 10Gb Ethernet. Stalak je prilično jednostavan, ali to ne mijenja suštinu.
Šematski to izgleda ovako:
Logično, replikacija je organizirana na sljedeći način:
Pogledajmo sada funkcionalnost replikacije koju sada imamo.
Podržana su dva načina rada: asinhroni i sinhroni. Logično je da je sinhroni način rada ograničen udaljenosti i komunikacijskim kanalom. Konkretno, sinhroni način rada zahtijeva korištenje vlakana kao fizike i 10 Gigabit Ethernet (ili više).
Podržana udaljenost za sinhronu replikaciju je 40 kilometara, vrijednost kašnjenja optičkog kanala između podatkovnih centara je do 2 milisekundi. Općenito, radit će s velikim kašnjenjima, ali će tada doći do velikih usporavanja prilikom snimanja (što je i logično), pa ako planirate sinhronu replikaciju između data centara, provjerite kvalitet optike i kašnjenja.
Zahtjevi za asinhronu replikaciju nisu tako ozbiljni. Tačnije, njih uopšte nema. Bilo koja ispravna Ethernet veza će biti dovoljna.
Trenutno, AERODISK ENGINE sistem skladištenja podržava replikaciju za blok uređaje (LUN-ove) preko Ethernet protokola (preko bakra ili optičkog). Za projekte gdje je potrebna replikacija kroz SAN tkaninu preko Fibre Channel-a, trenutno dodajemo odgovarajuće rješenje, ali ono još nije spremno, tako da u našem slučaju samo Ethernet.
Replikacija može raditi između bilo kojeg sistema za skladištenje serije ENGINE (N1, N2, N4) od mlađih sistema do starijih i obrnuto.
Funkcionalnost oba načina replikacije je potpuno identična. Ispod je više detalja o tome šta je dostupno:
- Replikacija „jedan na jedan“ ili „jedan na jedan“, odnosno klasična verzija sa dva data centra, glavnim i rezervnim
- Replikacija je „jedan prema više“ ili „jedan prema mnogima“, tj. jedan LUN se može replicirati na nekoliko sistema skladištenja odjednom
- Aktivirajte, deaktivirajte i "obrnite" replikaciju, respektivno, da omogućite, onemogućite ili promijenite smjer replikacije
- Replikacija je dostupna za RDG (Raid Distributed Group) i DDP (Dynamic Disk Pool) spremišta. Međutim, LUN-ovi RDG spremišta mogu se replicirati samo na drugi RDG. Isto i sa DDP-om.
Ima još mnogo malih karakteristika, ali nema smisla nabrajati ih; mi ćemo ih spominjati kako budemo postavljali.
Postavljanje replikacije
Proces podešavanja je prilično jednostavan i sastoji se od tri faze.
- Konfiguracija mreže
- Podešavanje pohrane
- Postavljanje pravila (veza) i mapiranje
Važna tačka u postavljanju replikacije je da se prve dvije faze trebaju ponoviti na udaljenom sistemu za skladištenje, a treća faza - samo na glavnom.
Postavljanje mrežnih resursa
Prvi korak je konfiguracija mrežnih portova kroz koje će se prenositi promet replikacije. Da biste to učinili, morate omogućiti portove i postaviti njihove IP adrese u odjeljku Front-end adapteri.
Nakon toga trebamo kreirati bazen (u našem slučaju RDG) i virtuelnu IP adresu za replikaciju (VIP). VIP je plutajuća IP adresa koja je vezana za dvije “fizičke” adrese kontrolera skladišta (portovi koje smo upravo konfigurirali). Ovo će biti glavni interfejs za replikaciju. Takođe možete da radite ne sa VIP, već sa VLAN-om, ako treba da radite sa označenim saobraćajem.
Proces kreiranja VIP-a za repliku se ne razlikuje mnogo od kreiranja VIP-a za I/O (NFS, SMB, iSCSI). U ovom slučaju kreiramo običan VIP (bez VLAN-a), ali obavezno naznačite da je za replikaciju (bez ovog pokazivača nećemo moći dodati VIP pravilu u sljedećem koraku).
VIP mora biti u istoj podmreži kao i IP portovi između kojih pluta.
Ponavljamo ove postavke na udaljenom sistemu za pohranu, s drugom IP-om, naravno.
VIP-ovi iz različitih sistema skladištenja mogu biti u različitim podmrežama, glavna stvar je da postoji rutiranje između njih. U našem slučaju, ovaj primjer je tačno prikazan (192.168.3.XX i 192.168.2.XX)
Ovim je završena priprema mrežnog dijela.
Postavljanje pohrane
Podešavanje memorije za repliku razlikuje se od uobičajenog samo po tome što mapiranje vršimo preko posebnog menija „Mapiranje replikacije“. Inače je sve isto kao i kod normalnog podešavanja. Sada, redom.
U prethodno kreiranom spremištu R02, trebate kreirati LUN. Kreirajmo ga i nazovimo ga LUN1.
Takođe moramo da kreiramo isti LUN na udaljenom sistemu za skladištenje identične veličine. Mi stvaramo. Da ne bi bilo zabune, nazovimo daljinski LUN LUN1R
Ako je potrebno da uzmemo LUN koji već postoji, onda bismo, dok postavljamo repliku, morali da isključimo ovaj produktivni LUN sa hosta i jednostavno kreiramo prazan LUN identične veličine na sistemu za udaljeno skladištenje.
Postavljanje pohrane je završeno, idemo dalje na kreiranje pravila replikacije.
Postavljanje pravila replikacije ili veza za replikaciju
Nakon kreiranja LUN-ova na sistemu skladištenja, koji će u ovom trenutku biti primarni, konfigurišemo pravilo replikacije LUN1 na sistemu skladištenja 1 na LUN1R na sistemu skladištenja 2.
Podešavanje se vrši u meniju „Udaljena replikacija“.
Kreirajmo pravilo. Da biste to učinili, morate navesti primatelja replike. Tu također postavljamo naziv veze i tip replikacije (sinhrona ili asinhrona).
U polje „udaljeni sistemi“ dodajemo naš sistem skladištenja2. Za dodavanje, potrebno je da koristite upravljačke IP sisteme za skladištenje (MGR) i ime udaljenog LUN-a u koji ćemo izvršiti replikaciju (u našem slučaju LUN1R). Kontrolni IP-ovi su potrebni samo u fazi dodavanja veze; preko njih se neće prenositi promet replikacije, za to će se koristiti prethodno konfigurirani VIP.
Već u ovoj fazi možemo dodati više od jednog udaljenog sistema za topologiju „jedan prema više“: kliknite na dugme „dodaj čvor“, kao na slici ispod.
U našem slučaju postoji samo jedan udaljeni sistem, pa se ograničavamo na ovo.
Pravilo je spremno. Imajte na umu da se automatski dodaje svim učesnicima replikacije (u našem slučaju ih ima dva). Možete kreirati onoliko takvih pravila koliko želite, za bilo koji broj LUN-ova iu bilo kojem smjeru. Na primjer, da bismo izbalansirali opterećenje, možemo replicirati dio LUN-ova iz sistema za skladištenje 1 u sistem skladištenja 2, a drugi deo, naprotiv, iz sistema skladištenja 2 u sistem skladištenja 1.
Sistem skladištenja1. Odmah nakon kreiranja, počela je sinhronizacija.
Sistem za skladištenje2. Vidimo isto pravilo, ali sinhronizacija je već završena.
LUN1 na sistemu skladištenja 1 je u primarnoj ulozi, odnosno aktivan je. LUN1R na sistemu skladištenja 2 je u ulozi sekundarnog, odnosno u stanju pripravnosti u slučaju kvara sistema za skladištenje 1.
Sada možemo povezati naš LUN sa hostom.
Povezićemo se preko iSCSI, mada se to može uraditi i preko FC-a. Podešavanje mapiranja putem iSCSI LUN-a u replici se praktično ne razlikuje od uobičajenog scenarija, tako da ovo ovdje nećemo detaljno razmatrati. Ako ništa drugo, ovaj proces je opisan u članku “".
Jedina razlika je u tome što kreiramo mapiranje u meniju “Replication Mapping”.
Postavili smo mapiranje i dali LUN domaćinu. Domaćin je vidio LUN.
Formatiramo ga u lokalni sistem datoteka.
To je to, podešavanje je završeno. Sledeće će doći testovi.
Testiranje
Mi ćemo testirati tri glavna scenarija.
- Redovna zamjena uloga Sekundarni > Primarni. Redovno mijenjanje uloga je potrebno u slučaju da, na primjer, moramo obaviti neke preventivne operacije u glavnom podatkovnom centru i za to vrijeme, da bi podaci bili dostupni, prebacimo opterećenje na backup data centar.
- Zamjena uloga u hitnim slučajevima Sekundarni > Primarni (kvar podatkovnog centra). Ovo je glavni scenario za koji postoji replikacija, koja može pomoći da se preživi potpuni kvar podatkovnog centra bez zaustavljanja kompanije na duži period.
- Prekid komunikacionih kanala između data centara. Provera ispravnog ponašanja dva sistema za skladištenje podataka u uslovima kada je iz nekog razloga komunikacioni kanal između data centara nedostupan (na primer, bager je kopao na pogrešnom mestu i razbio tamnu optiku).
Prvo, počet ćemo pisati podatke u naš LUN (pisanje datoteka sa slučajnim podacima). Odmah vidimo da se koristi komunikacioni kanal između sistema za skladištenje podataka. Ovo je lako razumjeti ako otvorite praćenje opterećenja portova koji su odgovorni za replikaciju.
Oba sistema za skladištenje sada imaju "korisne" podatke, možemo započeti test.
Za svaki slučaj, pogledajmo heš sume jednog od fajlova i zapišemo ih.
Redovna zamjena uloga
Operacija prebacivanja uloga (promjena smjera replikacije) može se obaviti sa bilo kojim sistemom za pohranu, ali ćete i dalje morati ići na oba, budući da ćete morati onemogućiti mapiranje na primarnom, a omogućiti ga na sekundarnom (koji će postati primarni ).
Možda se sada postavlja razumno pitanje: zašto ovo ne automatizirati? Odgovor je: jednostavno je, replikacija je jednostavno sredstvo otpornosti na katastrofe, zasnovano isključivo na ručnim operacijama. Za automatizaciju ovih operacija postoji metroklaster mod, potpuno je automatiziran, ali je njegova konfiguracija mnogo složenija. O postavljanju metroklastera ćemo pisati u sljedećem članku.
Na glavnom sistemu skladištenja onemogućavamo mapiranje kako bismo osigurali da se snimanje zaustavi.
Zatim na jednom od sustava za pohranu (nevažno, na glavnom ili rezervnom) u izborniku "Udaljena replikacija" odaberite našu vezu REPL1 i kliknite "Promijeni ulogu".
Nakon nekoliko sekundi, LUN1R (sistem za pohranu rezervnih kopija) postaje primarni.
Mapiramo LUN1R sa sistemom skladištenja2.
Nakon ovoga, naš E: drajv je automatski priključen na host, samo što je ovaj put „stigao“ sa LUN1R.
Za svaki slučaj, poredimo hash sume.
Identično. Test je prošao.
Failover. Greška data centra
U ovom trenutku, glavni sistem skladištenja nakon redovnog prebacivanja je sistem skladištenja 2 i LUN1R, respektivno. Da bismo oponašali nesreću, isključit ćemo napajanje na oba kontrolera skladištenja2.
Nema više pristupa tome.
Hajde da vidimo šta se dešava na sistemu skladištenja 1 (u ovom trenutku rezervnom).
Vidimo da primarni LUN (LUN1R) nije dostupan. Poruka o grešci pojavila se u evidenciji, na informativnoj tabli, kao iu samom pravilu replikacije. Prema tome, podaci sa hosta trenutno nisu dostupni.
Promijenite ulogu LUN1 u Primary.
Radim mapiranje na hostu.
Uvjerite se da se disk E pojavljuje na hostu.
Provjeravamo heš.
Sve je uredu. Sistem za skladištenje podataka je uspešno preživeo pad data centra koji je bio aktivan. Približno vrijeme koje smo potrošili na povezivanje replikacijskog "preokreta" i povezivanje LUN-a iz backup data centra bilo je oko 3 minute. Jasno je da je u stvarnoj proizvodnji sve mnogo komplikovanije, a pored radnji sa sistemima za skladištenje, potrebno je izvršiti još mnogo operacija na mreži, na hostovima, u aplikacijama. A u životu će ovaj vremenski period biti mnogo duži.
Ovdje bih htio napisati da je sve, test je uspješno obavljen, ali nemojmo žuriti. Glavni sistem za skladištenje "leži", znamo da je kada je "pao" bio u Primarnoj ulozi. Šta se dešava ako se iznenada uključi? Postojaće dvije Primarne uloge, što je jednako korupciji podataka? Hajde da to sada proverimo.
Hajde da odjednom uključimo osnovni sistem za skladištenje podataka.
Učitava se nekoliko minuta, a zatim se vraća u rad nakon kratke sinhronizacije, ali u ulozi sekundarnog.
Sve OK. Razdvajanje mozga se nije dogodilo. Razmišljali smo o ovome, i uvijek nakon pada sistem za skladištenje se uzdiže do uloge Sekundarne, bez obzira u kojoj je ulozi bio „tokom života“. Sada sa sigurnošću možemo reći da je test greške data centra bio uspješan.
Kvar komunikacijskih kanala između data centara
Glavni zadatak ovog testa je da se uveri da sistem za skladištenje ne počne da se ponaša čudno ako privremeno izgubi komunikacione kanale između dva sistema za skladištenje, a zatim se ponovo pojavi.
Dakle. Odspojimo žice između sistema za skladištenje (zamislimo da ih je iskopao bager).
Na Primarnom vidimo da nema veze sa Secondary.
Na Sekundarni vidimo da nema veze sa Primarnom.
Sve radi u redu, a mi nastavljamo da upisujemo podatke u glavni sistem za pohranu, to jest, oni se garantovano razlikuju od rezervnog, odnosno "razdvojili su se".
Za nekoliko minuta "popravljamo" komunikacijski kanal. Čim se sistemi za skladištenje vide, sinhronizacija podataka se automatski aktivira. Ovdje se ništa ne traži od administratora.
Nakon nekog vremena, sinhronizacija je završena.
Veza je obnovljena, gubitak komunikacijskih kanala nije izazvao nikakve vanredne situacije, a nakon uključivanja, sinhronizacija se odvijala automatski.
nalazi
Analizirali smo teoriju – šta je potrebno i zašto, gde su prednosti, a gde mane. Zatim smo postavili sinhronu replikaciju između dva sistema skladištenja.
Zatim su izvršena osnovna testiranja za normalno prebacivanje, kvar podatkovnog centra i kvar komunikacionog kanala. U svim slučajevima, sistem skladištenja je dobro funkcionisao. Nema gubitka podataka i administrativne operacije su svedene na minimum za ručni scenario.
Sljedeći put ćemo zakomplikovati situaciju i pokazati kako funkcionira sva ova logika u automatiziranom metroklasteru u aktivno-aktivnom modu, odnosno kada su oba sustava skladištenja primarna, a ponašanje u slučaju kvarova sustava skladištenja je potpuno automatizirano.
Napišite komentare, bit će nam drago da dobijemo razumne kritike i praktične savjete.
Do sljedećeg puta.
izvor: www.habr.com