Cześć, Habr!
Po noworocznych świętach uruchomiliśmy ponownie chmurę odporną na awarie opartą na dwóch lokalizacjach. Dziś opowiemy, jak to działa i pokażemy, co się dzieje z wirtualnymi maszynami klientów w przypadku awarii poszczególnych elementów klastra i upadku całej lokalizacji (spoiler – wszystko jest w porządku).
Macierz dyskowa chmury odpornej na awarie w lokalizacji OST.
Co w środku
Pod maską klastra znajdują się serwery Cisco UCS z hipernadzorcą VMware ESXi, dwie macierze INFINIDAT InfiniBox F2240, sprzęt sieciowy Cisco Nexus oraz przełączniki SAN Brocade. Klastr jest podzielony na dwie lokalizacje – OST i NORD, tj. w każdym centrum danych znajduje się identyczny zestaw sprzętu. To właśnie czyni go odpornym na awarie.
W ramach jednej lokalizacji kluczowe elementy są również zduplikowane (hosty, przełączniki SAN, sieć).
Dwie lokalizacje są połączone dedykowanymi światłowodowymi trasami, które także są zarezerwowane.
Kilka słów o macierzy dyskowej. Pierwszą wersję chmury odpornej na awarie budowaliśmy na NetApp. Tutaj wybraliśmy INFINIDAT, i oto dlaczego:
- Opcja replikacji Active-Active. Pozwala to wirtualnej maszynie pozostać w stanie operacyjnym nawet w przypadku całkowitej awarii jednej z macierzy. O replikacji opowiem więcej później.
- Trzy kontrolery dysków dla zwiększenia odporności systemu. Zwykle są dwa.
- Gotowe rozwiązanie. Do nas przyjechała już złożona szafa, którą wystarczy podłączyć do sieci i skonfigurować.
- Uważne wsparcie techniczne. Inżynierowie INFINIDAT nieustannie analizują logi i zdarzenia macierzy, instalują nowe wersje oprogramowania, pomagają w konfiguracji.
Oto kilka zdjęć z unpacking’u:
Jak to działa
Chmura jest już odporna na awarie wewnętrznie. Chroni klienta przed pojedynczymi awariami sprzętowymi i programowymi. Chmura odporna na katastrofy pomoże chronić przed masowymi awariami w obrębie jednej lokalizacji: na przykład awaria macierzy (lub klastra SDS, co zdarza się niejednokrotnie 🙂), masowe błędy w sieci storage i inne. I najważniejsze: taka chmura ratuje, gdy cała lokalizacja staje się niedostępna z powodu pożaru, blackout'u, przejęcia przez najeźdźców, czy lądowania kosmitów.
Wszystkie te przypadki sprawiają, że wirtualne maszyny klientów kontynuują pracę, i oto dlaczego.
Schemat klastra jest zorganizowany w taki sposób, że każdy host ESXi z wirtualnymi maszynami klientów może uzyskać dostęp do jednej z dwóch macierzy dyskowych. Jeśli macierz na platformie OST ulegnie awarii, wirtualne maszyny będą kontynuować działanie: hosty, na których one działają, będą uzyskiwać dane z macierzy na NORD.
Tak wygląda schemat podłączenia w klastrze.
Jest to możliwe dzięki temu, że między fabrykami SAN dwóch lokalizacji skonfigurowano Inter-Switch Link: przełącznik SAN Fabric A OST jest połączony z przełącznikiem SAN Fabric A NORD, w podobny sposób dla przełączników SAN Fabric B.
Aby te złożone układy fabryk SAN miały sens, między dwiema macierzami skonfigurowana jest replikacja Active-Active: informacje są praktycznie jednocześnie zapisywane na lokalnej i zdalnej macierzy, RPO=0. Oznacza to, że na jednej macierzy przechowywana jest oryginalna wersja danych, a na drugiej – jej replika. Dane są replikowane na poziomie wolumenów macierzy, a na nich przechowywane są dane VM (jej dyski, plik konfiguracyjny, plik swap itp.).
Host ESXi widzi główny wolumen i jego replikę jako jedno urządzenie dyskowe (Storage Device). Z hosta ESXi do każdego urządzenia dyskowego prowadzi 24 ścieżki:
12 ścieżek łączy go z lokalną macierzą (optymalne ścieżki), a pozostałe 12 – z zdalną (nieoptymalne ścieżki). W normalnej sytuacji ESXi uzyskuje dostęp do danych na lokalnej macierzy, korzystając z 'optymalnych' ścieżek. W przypadku awarii tej macierzy ESXi traci optymalne ścieżki i przełącza się na 'nieoptymalne'. Tak to wygląda na schemacie.
Schemat klastra odpornego na awarie.
Wszystkie sieci klientów są podłączone do obu lokalizacji za pośrednictwem wspólnej fabryki sieciowej. Na każdej lokalizacji działa Provider Edge (PE), na którym kończą się sieci klientów. PE są połączone w zintegrowany klaster. W przypadku awarii PE na jednej lokalizacji cały ruch jest przekierowywany na drugą lokalizację. Dzięki temu wirtualne maszyny z lokalizacji pozbawionej PE pozostają dostępne w sieci dla klientów.
Przyjrzyjmy się teraz, co będzie się działo z wirtualnymi maszynami klienta w przypadku różnych awarii. Zacznijmy od najłagodniejszych scenariuszy i zakończmy najpoważniejszym – awarią całej lokalizacji. W przykładach główną lokalizacją będzie OST, a zapasową, z replikami danych, – NORD.
Co dzieje się z wirtualną maszyną klienta, jeśli…
Zawiedzie połączenie replikacji. Replikacja między macierzami dwóch lokalizacji zostaje przerwana.
ESXi będzie działać tylko z lokalnymi urządzeniami dyskowymi (po optymalnych ścieżkach).
Maszyny wirtualne nadal działają.
Występuje przerwanie ISL (Inter-Switch Link). Sytuacja mało prawdopodobna. Chyba że jakiś szalony koparka przekopie od razu kilka torów optycznych, które przebiegają niezależnymi trasami i są podłączone do miejsc przez różne wejścia. Mimo wszystko. W tym przypadku hosty ESXi tracą połowę ścieżek i mogą uzyskiwać dostęp tylko do swoich lokalnych pamięci masowych. Repliki są zbierane, ale hosty nie będą mogły się do nich odwoływać.
Maszyny wirtualne działają prawidłowo.
Zawodzi przełącznik SAN w jednym z miejsc. Hosty ESXi tracą część ścieżek do pamięci masowych. W tym przypadku hosty w miejscu, gdzie zawiódł przełącznik, będą działać tylko przez jeden swój HBA.
Maszyny wirtualne w tym czasie nadal działają prawidłowo.
Zawodzą wszystkie przełączniki SAN w jednym z miejsc. Załóżmy, że taka awaria miała miejsce w miejscu OST. W takim przypadku hosty ESXi w tym miejscu stracą wszystkie ścieżki do swoich urządzeń dyskowych. Wkracza standardowy mechanizm VMware vSphere HA: uruchomi on ponownie wszystkie maszyny wirtualne w miejscu OST w NORDzie maksymalnie w ciągu 140 sekund.
Maszyny wirtualne działające na hostach w miejscu NORD działają prawidłowo.
Zawodzi host ESXi w jednym z miejsc. Tutaj ponownie działa mechanizm vSphere HA: maszyny wirtualne z uszkodzonego hosta są uruchamiane ponownie na innych hostach – w tym samym lub w zdalnym miejscu. Czas ponownego uruchomienia maszyny wirtualnej – do 1 minuty.
Jeśli zawodzą wszystkie hosty ESXi w miejscu OST, w tym przypadku nie ma opcji: VM są uruchamiane ponownie w innym miejscu. Czas ponownego uruchomienia jest taki sam.
Zawodzi pamięć masowa w jednym z miejsc. Załóżmy, że zawiodła pamięć masowa w miejscu OST. W takim przypadku hosty ESXi w miejscu OST przełączają się na pracę z replikami pamięci masowej w NORDzie. Po przywróceniu uszkodzonej pamięci masowej do użytku dojdzie do wymuszonej replikacji, hosty ESXi OST ponownie zaczną korzystać z lokalnej pamięci masowej.
Maszyny wirtualne przez cały ten czas działają prawidłowo.
Zawodzi jeden z miejsc. W takim przypadku wszystkie maszyny wirtualne będą uruchamiane ponownie w rezerwowym miejscu za pomocą mechanizmu vSphere HA. Czas ponownego uruchomienia VM wynosi 140 sekund. Przy tym wszystkie ustawienia sieciowe maszyny wirtualnej pozostaną zachowane, a ona będzie nadal dostępna dla klienta w sieci.
Aby restart maszyn na zapasowej stronie przebiegł bezproblemowo, każda lokalizacja jest wypełniona tylko w połowie. Druga połowa to rezerwa na wypadek przeniesienia wszystkich maszyn wirtualnych z drugiej, poszkodowanej lokalizacji.
Takie awarie chroni chmurowe rozwiązanie odporne na katastrofy oparte na dwóch centrach danych.
To przyjemność, która nie jest tania, ponieważ, oprócz podstawowych zasobów, potrzebna jest rezerwa na drugiej stronie. Dlatego w takiej chmurze umieszcza się krytyczne usługi biznesowe, których długi przestój może powodować znaczne straty finansowe i reputacyjne, lub jeśli system informacyjny musi spełniać wymagania dotyczące odporności na katastrofy określone przez przepisy regulacyjne lub wewnętrzne regulacje firmy.
Źródła:
Źródło: habr.com
