Hej Habr!
Nakon novogodišnjih praznika, ponovo smo pokrenuli cloud otporan na katastrofe baziran na dvije lokacije. Danas ćemo vam reći kako to radi i pokazati šta se dešava sa klijentskim virtuelnim mašinama kada pojedini elementi klastera pokvare i cijela stranica se sruši (spojler – s njima je sve u redu).
Sistem za skladištenje u oblaku otporan na katastrofe na OST lokaciji.
Šta je unutra
Ispod haube, klaster ima Cisco UCS servere sa VMware ESXi hipervizorom, dva INFINIDAT InfiniBox F2240 sistema za skladištenje, Cisco Nexus mrežnu opremu, kao i Brocade SAN prekidače. Klaster je podijeljen na dvije lokacije - OST i NORD, odnosno svaki data centar ima identičan set opreme. Zapravo, to je ono što ga čini otpornim na katastrofe.
Unutar jedne lokacije, glavni elementi su također duplicirani (hostovi, SAN prekidači, umrežavanje).
Dvije lokacije su povezane namjenskim optičkim rutama, također rezerviranim.
Nekoliko riječi o sistemima za skladištenje. Na NetApp smo napravili prvu verziju oblaka otpornog na katastrofe. Ovdje smo odabrali INFINIDAT, a evo i zašto:
- Opcija aktivno-aktivno replikacije. Omogućava da virtuelna mašina ostane u funkciji čak i ako jedan od sistema za skladištenje potpuno pokvari. Kasnije ću vam reći više o replikaciji.
- Tri disk kontrolera za povećanje tolerancije sistema na greške. Obično su dva.
- Gotovo rješenje. Dobili smo unaprijed montiran rack koji samo treba spojiti na mrežu i konfigurirati.
- Pažljiva tehnička podrška. INFINIDAT inženjeri konstantno analiziraju evidencije i događaje sistema za skladištenje podataka, instaliraju nove verzije firmvera i pomažu u konfiguraciji.
Evo nekoliko fotografija sa raspakivanja:
Kako to funkcioniše
Oblak je već u sebi tolerantan na greške. Štiti klijenta od pojedinačnih hardverskih i softverskih kvarova. Otporan na katastrofe pomoći će u zaštiti od masivnih kvarova unutar jedne stranice: na primjer, kvar sistema za pohranu podataka (ili SDS klastera, što se događa prilično često 🙂), velike greške u mreži za pohranu itd. Pa, i što je najvažnije: takav oblak spašava kada cijela lokacija postane nedostupna zbog požara, zamračenja, raiderskog preuzimanja ili sletanja vanzemaljaca.
U svim ovim slučajevima, klijentske virtuelne mašine nastavljaju da rade, a evo zašto.
Dizajn klastera je dizajniran tako da svaki ESXi host sa klijentskim virtuelnim mašinama može da pristupi bilo kom od dva sistema skladištenja. Ako sistem za skladištenje na OST lokaciji pokvari, virtuelne mašine će nastaviti da rade: hostovi na kojima rade pristupiće sistemu za skladištenje podataka na NORD-u.
Ovako izgleda dijagram povezivanja u klasteru.
Ovo je moguće zbog činjenice da je inter-switch link konfigurisan između SAN tkanina na dve lokacije: Fabric A OST SAN prekidač je povezan sa Fabric A NORD SAN prekidačem, i slično za Fabric B SAN prekidače.
Pa, da bi sve ove zamršenosti SAN fabrika imale smisla, aktivno-aktivna replikacija je konfigurisana između dva sistema skladištenja: informacije se skoro istovremeno upisuju u lokalni i udaljeni sistem skladištenja, RPO = 0. Ispostavilo se da su originalni podaci pohranjeni na jednom sistemu za skladištenje, a njihova replika na drugom. Podaci se repliciraju na nivou volumena skladišta, a podaci VM (njezini diskovi, konfiguracijski fajl, swap datoteka, itd.) se pohranjuju na njima.
ESXi host vidi primarni volumen i njegovu repliku kao jedan disk uređaj (Storage Device). Postoje 24 puta od ESXi hosta do svakog disk uređaja:
12 putanja ga povezuje sa lokalnim sistemom skladištenja (optimalne staze), a preostalih 12 sa udaljenim sistemom skladištenja (neoptimalne staze). U normalnoj situaciji, ESXi pristupa podacima na lokalnom sistemu skladištenja koristeći “optimalne” putanje. Kada ovaj sistem za skladištenje pokvari, ESXi gubi optimalne putanje i prelazi na one „neoptimalne“. Ovako to izgleda na dijagramu.
Shema klastera otpornog na katastrofe.
Sve klijentske mreže su povezane na obje lokacije preko zajedničkog mrežnog tkiva. Svaka stranica pokreće Provider Edge (PE), na kojoj se završavaju mreže klijenta. JP su ujedinjene u zajednički klaster. Ako PE ne uspije na jednoj lokaciji, sav promet se preusmjerava na drugu lokaciju. Zahvaljujući tome, virtuelne mašine sa sajta koje su ostale bez PE ostaju dostupne klijentu preko mreže.
Hajde sada da vidimo šta će se desiti sa klijentskim virtuelnim mašinama tokom raznih kvarova. Počnimo s najlakšim opcijama i završimo s najozbiljnijim - neuspjehom cijele stranice. U primjerima, glavna platforma će biti OST, a rezervna platforma, sa replikama podataka, će biti NORD.
Šta se dešava sa klijentskom virtuelnom mašinom ako...
Veza za replikaciju ne uspijeva. Replikacija između sistema za skladištenje dve lokacije se zaustavlja.
ESXi će raditi samo sa lokalnim disk uređajima (putem optimalnih putanja).
Virtuelne mašine nastavljaju da rade.
ISL (Inter-Switch Link) se prekida. Slučaj je malo verovatan. Osim ako neki ludi bager ne iskopa nekoliko optičkih ruta odjednom, koje se kreću na nezavisnim rutama i dovode se na lokacije kroz različite ulaze. Ali svejedno. U ovom slučaju, ESXi hostovi gube polovinu putanja i mogu pristupiti samo svojim lokalnim sistemima za pohranu. Replike se prikupljaju, ali domaćini im neće moći pristupiti.
Virtuelne mašine rade normalno.
SAN prekidač ne radi na jednoj od lokacija. ESXi hostovi gube neke od puteva do sistema za skladištenje. U ovom slučaju, domaćini na lokaciji na kojoj je došlo do kvara radit će samo preko jednog od svojih HBA.
Virtuelne mašine nastavljaju da rade normalno.
Svi SAN prekidači na jednoj od lokacija ne rade. Recimo da se takva katastrofa dogodila na OST stranici. U ovom slučaju, ESXi domaćini na ovoj stranici će izgubiti sve putanje do svojih disk uređaja. Standardni VMware vSphere HA mehanizam stupa na snagu: on će ponovo pokrenuti sve virtuelne mašine OST stranice u NORD-u za maksimalno 140 sekundi.
Virtuelne mašine koje rade na hostovima NORD sajtova rade normalno.
ESXi host ne radi na jednoj lokaciji. Ovdje vSphere HA mehanizam ponovo radi: virtuelne mašine sa neuspelog hosta se ponovo pokreću na drugim hostovima - na istoj ili udaljenoj lokaciji. Vrijeme ponovnog pokretanja virtuelne mašine je do 1 minute.
Ako svi ESXi hostovi na OST lokaciji ne uspiju, nema opcija: VM se ponovo pokreću na drugom. Vrijeme ponovnog pokretanja je isto.
Sistem za skladištenje pokvari na jednom mestu. Recimo da sistem za skladištenje ne radi na OST lokaciji. Zatim se ESXi domaćini OST lokacije prebacuju na rad sa replikama skladišta u NORD-u. Nakon što se neuspjeli sistem pohrane vrati u rad, doći će do prisilne replikacije i ESXi OST hostovi će ponovo početi pristupati lokalnom sistemu za pohranu.
Virtuelne mašine su radile normalno sve ovo vreme.
Jedna od lokacija ne uspijeva. U ovom slučaju, sve virtuelne mašine će se ponovo pokrenuti na stranici rezervne kopije putem vSphere HA mehanizma. Vrijeme ponovnog pokretanja VM-a je 140 sekundi. U tom slučaju, sve mrežne postavke virtuelne mašine će biti sačuvane i ona ostaje dostupna klijentu preko mreže.
Da bi se osiguralo da ponovno pokretanje mašina na web lokaciji za rezervnu kopiju prođe glatko, svaka lokacija je samo do pola puna. Druga polovina je rezerva u slučaju da se sve virtuelne mašine presele sa druge, oštećene lokacije.
Oblak otporan na katastrofe baziran na dva data centra štiti od takvih kvarova.
Ovo zadovoljstvo nije jeftino, jer je, pored glavnih resursa, potrebna rezerva na drugom mjestu. Stoga se usluge kritične za poslovanje postavljaju u takav oblak, čiji dugoročni zastoji izazivaju velike finansijske i reputacijske gubitke, ili ako je informacioni sistem podložan zahtjevima regulatora ili internih propisa kompanije za otpornost na katastrofe.
Izvori:
izvor: www.habr.com