Bok, Habr!
Nakon novogodišnjih praznika ponovno smo pokrenuli katastrofno otporniji oblak na bazi dvije lokacije. Danas ćemo objasniti kako je to organizirano i pokazati što se događa s virtualnim strojevima klijenata u slučaju kvara pojedinih elemenata klastera i pada cijele lokacije (spoiler – sve je u redu).
Skladište podataka katastrofno otpornog oblaka na lokaciji OST.
Što se nalazi unutra
Ispod haube klastera su Cisco UCS poslužitelji s hipervizorom VMware ESXi, dva skladišta podataka INFINIDAT InfiniBox F2240, mrežna oprema Cisco Nexus, kao i SAN preklopnici Brocade. Klaster je raspoređen na dvije lokacije – OST i NORD, tj. u svakom datacentru identičan skup opreme. To ga čini katastrofno otpornim.
Unutar jedne lokacije glavni elementi su također duplicirani (hostovi, SAN preklopnici, mreža).
Dvije lokacije su spojene zasebnim optičkim vlaknima koja su također rezervirana.
Malo o skladištu podataka. Prvu verziju katastrofno otpornog oblaka gradili smo na NetApp-u. Ovdje smo odabrali INFINIDAT, i evo zašto:
- Opcija Active-Active replikacije. Omogućuje virtualnom stroju da ostane operativan čak i prilikom potpunog kvara jednog od skladišta podataka. O replikaciji ću detaljnije govoriti kasnije.
- Tri kontrolera diska za povećanje otpornosti sustava. Obično ih je dva.
- Gotovo rješenje. Došla nam je već sastavljena količina koju trebamo samo spojiti na mrežu i konfigurirati.
- Pažljiva tehnička podrška. INFINIDAT inženjeri kontinuirano analiziraju logove i događaje skladišta podataka, postavljaju nove verzije firmware-a i pomažu pri konfiguraciji.
Evo malo slika s unpacking-a:
Kako radi
Oblak je već interno otporniji. Štiti klijenta od pojedinačnih hardverskih i softverskih kvarova. Katastrofno otporniji oblak pomoći će zaštititi se od masovnih kvarova unutar jedne lokacije: na primjer, kvar Skladišta podataka (ili SDS klastera, što se često događa 🙂), masovne greške u mreži za pohranu i slično. A najvažnije: takav oblak spašava kada cijela lokacija postane nedostupna zbog požara, nestanka struje, otmice od strane pljačkaša, ili invazije vanzemaljaca.
U svim tim slučajevima virtualni strojevi klijenata nastavljaju raditi, i evo zašto.
Shema klastera je osmišljena tako da svaki ESXi host s klijentskim virtualnim mašinama može pristupiti bilo kojoj od dva SAN-a. Ako SAN na OSS stranici ne uspije, virtualne mašine će nastaviti raditi: hostovi na kojima rade će pristupati podacima s SAN-a na NORD-u.
Ovako izgleda shema povezivanja u klasteru.
To je moguće zahvaljujući tome što je između SAN-fabrika dviju lokacija postavljen Inter-Switch Link: SAN prekidač Fabric A OST je povezan s SAN prekidačem Fabric A NORD, slično za SAN prekidače Fabric B.
A kako bi sve ove složene SAN fabrike imale smisla, između dva SAN-a postavljena je Active-Active replikacija: informacije se gotovo istovremeno zapisuju na lokalni i udaljeni SAN, RPO=0. Tako se dobiva da na jednom SAN-u leži izvor podataka, a na drugom – njihova replikacija. Podaci se repliciraju na razini volumena SAN-a, a već na njima se pohranjuju podaci VMs (njihovi diskovi, konfiguracijska datoteka, swap datoteka itd.).
ESXi host vidi glavni volumen i njegovu replikaciju kao jedno diskovno uređaj (Storage Device). Od ESXi hosta do svakog diskovnog uređaja ide 24 puta:
12 puteva povezuje ga s lokalnim SAN-om (optimalni putevi), a preostalih 12 – s udaljenim (neoptimalni putevi). U redovnim okolnostima, ESXi pristupa podacima na lokalnom SAN-u koristeći “optimalne” puteve. Kada ovaj SAN ne uspije, ESXi gubi optimalne puteve i prebacuje se na “neoptimalne”. Ovako to izgleda na shemi.
Shema klastera otpornog na katastrofe.
Sve klijentske mreže su povezane na obje lokacije kroz zajedničku mrežnu fabriku. Na svakoj lokaciji radi Provider Edge (PE), na kojem se terminiraju klijentske mreže. PE su objedinjeni u zajednički klaster. U slučaju kvara PE-a na jednoj lokaciji, sav promet se preusmjerava na drugu lokaciju. Zbog toga, virtualne mašine s lokacije koja ostaje bez PE-a ostaju dostupne putem mreže za klijenta.
Sada ćemo pogledati što će se dogoditi s virtualnim mašinama klijenta pri različitim kvarovima. Započnimo s najlakšim mogućim situacijama i završimo s najozbiljnijim – slabljenjem cijele lokacije. U primjerima će glavna lokacija biti OST, a rezervna, s replikama podataka, – NORD.
Što se događa s virtualnom mašinom klijenta ako…
Ne uspije Replication Link. Replikacija između SAN-a dviju lokacija prestaje.
ESXi će raditi samo s lokalnim diskovnim uređajima (preko optimalnih putanja).
Virtualne mašine nastavljaju raditi.
Dogodi se prekid ISL (Inter-Switch Link). Ovo je malo vjerovatno. Osim ako neki lud exkavator ne iskopava nekoliko optičkih trase koje prolaze neovisnim rutama i dovedene su na lokacije preko različitih priključaka. Ipak. U tom slučaju, ESXi hostovi gube polovicu putanja i mogu pristupati samo svojim lokalnim SAN. Replike se prikupljaju, ali hostovi im ne mogu pristupiti.
Virtualne mašine rade normalno.
SAN switch otkazuje na jednoj od lokacija. ESXi hostovi gube dio putanja prema SAN-u. U ovom slučaju, hostovi na lokaciji gdje je switch otkazao, radit će samo preko jednog svog HBA.
Virtualne mašine u ovom slučaju nastavljaju raditi normalno.
Svi SAN switch-evi otkazuju na jednoj od lokacija. Pretpostavimo da se ovakva nesreća dogodila na lokaciji OST. U tom slučaju, ESXi hostovi na toj lokaciji će izgubiti sve putanje prema svojim diskovnim uređajima. U igru ulazi standardni mehanizam VMware vSphere HA: ponovo će pokrenuti sve virtualne mašine na lokaciji OST u NORD-u u maksimalno 140 sekundi.
Virtualne mašine koje rade na hostovima lokacije NORD rade normalno.
ESXi host otkazuje na jednoj lokaciji. Ovdje opet radi mehanizam vSphere HA: virtualne mašine sa neispravnog hosta se ponovo pokreću na drugim hostovima – na istoj ili udaljenoj lokaciji. Vreme ponovnog pokretanja virtualne mašine je do 1 minute.
Ako otkažu svi ESXi hostovi lokacije OST, tu više nema opcija: VM se ponovo pokreću na drugoj. Vreme ponovnog pokretanja je isto.
SAN otkazuje na jednoj lokaciji. Pretpostavimo da je SAN otkazao na lokaciji OST. Tada ESXi hostovi lokacije OST prebacuju se na rad s replikama SAN-a u NORD-u. Nakon što se neispravni SAN vrati u rad, doći će do prisilne replikacije, a ESXi hostovi OST ponovo će početi pristupati lokalnom SAN-u.
Virtualne mašine sve ovo vreme rade normalno.
Jedna od lokacija otkazuje. U tom slučaju, sve virtualne mašine će se ponovo pokretati na rezervnoj lokaciji putem mehanizma vSphere HA. Vreme ponovnog pokretanja VM-a je 140 sekundi. Pri tome će sve mrežne postavke virtualne mašine ostati sačuvane, a ona će ostati dostupna klijentu putem mreže.
Kako bi ponovno pokretanje virtuelnih mašina na rezervnoj lokaciji prošlo bez problema, svaka lokacija je ispunjena samo napola. Druga polovica je rezervna u slučaju premještanja svih virtuelnih mašina sa druge, pogođene, lokacije.
To su vrste kvarova koje štiti katastrofalno otporno oblak zasnovan na dva data centra.
Ovo zadovoljstvo nije jeftino, jer pored osnovnih resursa, treba imati rezervu na drugoj lokaciji. Zbog toga se u takvom oblaku smještaju poslovno kritične usluge, čije dugotrajno zastoje donose velike finansijske i reputacione gubitke, ili ako se prema informacionom sistemu postavljaju zahtjevi za katastrofalnom otpornošću od strane regulatora ili unutarnjih pravila kompanije.
Izvori:
Izvor: habr.com
