Hej Habra!
Po świętach noworocznych ponownie uruchomiliśmy chmurę odporną na katastrofy w oparciu o dwie witryny. Dziś opowiemy jak to działa i pokażemy co dzieje się z klienckimi maszynami wirtualnymi, gdy zawiodą poszczególne elementy klastra i zawiesza się cała witryna (spoiler – wszystko z nimi jest w porządku).
Odporny na awarie system przechowywania w chmurze w witrynie OST.
Co jest w środku
Pod maską klastra znajdują się serwery Cisco UCS z hypervisorem VMware ESXi, dwa systemy pamięci masowej INFINIDAT InfiniBox F2240, sprzęt sieciowy Cisco Nexus, a także przełączniki Brocade SAN. Klaster podzielony jest na dwie placówki – OST i NORD, co oznacza, że każde centrum danych posiada identyczny zestaw sprzętu. Właściwie to właśnie to czyni go odpornym na katastrofy.
W obrębie jednej lokalizacji zduplikowane są także główne elementy (hosty, przełączniki SAN, sieć).
Obie lokalizacje są połączone wydzielonymi trasami światłowodowymi, również zarezerwowanymi.
Kilka słów o systemach przechowywania. Zbudowaliśmy pierwszą wersję chmury odpornej na katastrofy na platformie NetApp. Tutaj wybraliśmy INFINIDAT i oto dlaczego:
- Opcja replikacji typu Active-Active. Dzięki temu maszyna wirtualna może działać nawet w przypadku całkowitej awarii jednego z systemów przechowywania danych. Później opowiem więcej o replikacji.
- Trzy kontrolery dysków zwiększające odporność systemu na awarie. Zwykle są dwa.
- Gotowe rozwiązanie. Otrzymaliśmy wstępnie zmontowany stojak, który wystarczy podłączyć do sieci i skonfigurować.
- Uważne wsparcie techniczne. Inżynierowie INFINIDAT na bieżąco analizują logi i zdarzenia systemu pamięci masowej, instalują nowe wersje oprogramowania sprzętowego i pomagają w konfiguracji.
Oto kilka zdjęć z rozpakowywania:
Jak działa
Chmura sama w sobie jest już odporna na awarie. Chroni klienta przed pojedynczymi awariami sprzętu i oprogramowania. Odporność na awarie pomoże zabezpieczyć się przed masowymi awariami w obrębie jednej lokalizacji: na przykład awarią systemu przechowywania danych (lub klastra SDS, co zdarza się dość często 🙂), masowymi błędami w sieci magazynowania itp. No i co najważniejsze: taka chmura oszczędza, gdy cała witryna stanie się niedostępna z powodu pożaru, awarii prądu, przejęcia przez najeźdźców lub lądowania kosmitów.
We wszystkich tych przypadkach klienckie maszyny wirtualne nadal działają i oto dlaczego.
Projekt klastra został zaprojektowany w taki sposób, aby każdy host ESXi z klienckimi maszynami wirtualnymi mógł uzyskać dostęp do dowolnego z dwóch systemów pamięci masowej. Jeśli system przechowywania w witrynie OST ulegnie awarii, maszyny wirtualne będą nadal działać: hosty, na których działają, uzyskają dostęp do systemu przechowywania w NORD w celu uzyskania danych.
Tak wygląda schemat połączeń w klastrze.
Jest to możliwe dzięki skonfigurowaniu łącza między przełącznikami pomiędzy sieciami SAN obu lokalizacji: przełącznik Fabric A OST SAN jest podłączony do przełącznika Fabric A NORD SAN i analogicznie w przypadku przełączników Fabric B SAN.
Cóż, aby wszystkie te zawiłości fabryk SAN miały sens, replikacja typu Active-Active jest skonfigurowana pomiędzy dwoma systemami pamięci masowej: informacje są prawie jednocześnie zapisywane w lokalnym i zdalnym systemie pamięci masowej, RPO = 0. Okazuje się, że oryginalne dane przechowywane są w jednym systemie przechowywania, a ich replika w drugim. Dane są replikowane na poziomie woluminów pamięci masowej, na których przechowywane są dane maszyny wirtualnej (jej dyski, plik konfiguracyjny, plik wymiany itp.).
Host ESXi widzi wolumin podstawowy i jego replikę jako jedno urządzenie dyskowe (urządzenie pamięci masowej). Istnieją 24 ścieżki z hosta ESXi do każdego urządzenia dyskowego:
12 ścieżek łączy go z lokalnym systemem przechowywania (ścieżki optymalne), a pozostałych 12 z systemem zdalnym (ścieżki nieoptymalne). W normalnej sytuacji ESXi uzyskuje dostęp do danych w lokalnym systemie pamięci masowej przy użyciu „optymalnych” ścieżek. Kiedy ten system pamięci masowej ulegnie awarii, ESXi traci optymalne ścieżki i przełącza się na „nieoptymalne”. Tak to wygląda na schemacie.
Schemat klastra odpornego na katastrofy.
Wszystkie sieci klienckie są połączone z obiema lokalizacjami za pośrednictwem wspólnej struktury sieciowej. W każdej lokacji działa dostawca Edge (PE), na którym kończą się sieci klienta. PE są zjednoczone we wspólnym klastrze. Jeżeli PE ulegnie awarii w jednej lokacji, cały ruch zostanie przekierowany do drugiej lokacji. Dzięki temu maszyny wirtualne z lokalizacji pozostawionej bez PE pozostają dostępne przez sieć dla klienta.
Zobaczmy teraz, co stanie się z klienckimi maszynami wirtualnymi podczas różnych awarii. Zacznijmy od najlżejszych opcji, a zakończmy najpoważniejszym - awarią całej witryny. W przykładach platformą główną będzie OST, a platformą zapasową z replikami danych będzie NORD.
Co stanie się z maszyną wirtualną klienta, jeśli...
Połączenie replikacyjne nie działa. Replikacja między systemami pamięci masowej w obu lokalizacjach zostaje zatrzymana.
ESXi będzie działać tylko z lokalnymi urządzeniami dyskowymi (poprzez optymalne ścieżki).
Maszyny wirtualne nadal działają.
Awaria łącza ISL (Inter-Switch Link). Sprawa jest mało prawdopodobna. Chyba, że jakaś szalona koparka wykopie na raz kilka tras optycznych, które biegną niezależnymi trasami i dowożone są na miejsce różnymi wejściami. Ale w każdym razie. W takim przypadku hosty ESXi tracą połowę ścieżek i mogą uzyskać dostęp tylko do swoich lokalnych systemów pamięci masowej. Repliki są gromadzone, ale hosty nie będą miały do nich dostępu.
Maszyny wirtualne działają normalnie.
Przełącznik SAN ulega awarii w jednej z lokalizacji. Hosty ESXi tracą część ścieżek do systemu pamięci masowej. W takim przypadku hosty w lokalizacji, w której nastąpiła awaria przełącznika, będą działać tylko za pośrednictwem jednej ze swoich kart HBA.
Maszyny wirtualne nadal działają normalnie.
Wszystkie przełączniki SAN w jednej z lokalizacji ulegają awarii. Załóżmy, że taka katastrofa wydarzyła się na stronie OST. W takim przypadku hosty ESXi w tej witrynie utracą wszystkie ścieżki do swoich urządzeń dyskowych. W grę wchodzi standardowy mechanizm VMware vSphere HA: zrestartuje wszystkie maszyny wirtualne witryny OST w NORD w maksymalnie 140 sekund.
Maszyny wirtualne działające na hostach lokalizacji NORD działają normalnie.
Host ESXi ulega awarii w jednej lokacji. Tutaj ponownie działa mechanizm vSphere HA: maszyny wirtualne z uszkodzonego hosta są restartowane na innych hostach - w tej samej lub zdalnej lokalizacji. Czas ponownego uruchomienia maszyny wirtualnej wynosi do 1 minuty.
Jeśli wszystkie hosty ESXi w witrynie OST zawiodą, nie ma innego wyjścia: maszyny wirtualne zostaną ponownie uruchomione na innym. Czas ponownego uruchomienia jest taki sam.
System przechowywania danych ulega awarii w jednym miejscu. Załóżmy, że system pamięci masowej ulega awarii w witrynie OST. Następnie hosty ESXi witryny OST przechodzą na pracę z replikami pamięci masowej w NORD. Gdy uszkodzony system pamięci masowej powróci do działania, nastąpi wymuszona replikacja, a hosty ESXi OST ponownie zaczną uzyskiwać dostęp do lokalnego systemu pamięci masowej.
Maszyny wirtualne przez cały ten czas działały normalnie.
Jedna z witryn nie działa. W takim przypadku wszystkie maszyny wirtualne zostaną zrestartowane w witrynie kopii zapasowej poprzez mechanizm vSphere HA. Czas ponownego uruchomienia maszyny wirtualnej wynosi 140 sekund. W takim przypadku wszystkie ustawienia sieciowe maszyny wirtualnej zostaną zapisane i pozostanie ona dostępna dla klienta przez sieć.
Aby mieć pewność, że ponowne uruchomienie maszyn w lokalizacji kopii zapasowych przebiegnie bezproblemowo, każda witryna jest zapełniona tylko w połowie. Druga połowa to rezerwa na wypadek przeniesienia wszystkich maszyn wirtualnych z drugiej, uszkodzonej witryny.
Przed takimi awariami chroni odporna na awarie chmura oparta na dwóch centrach danych.
Ta przyjemność nie jest tania, ponieważ oprócz głównych zasobów na drugiej stronie potrzebna jest rezerwa. Dlatego w takiej chmurze umieszczane są usługi krytyczne dla biznesu, których długotrwały przestój powoduje duże straty finansowe i reputacyjne, lub jeśli system informatyczny podlega wymogom odporności na awarie określonymi przez organy regulacyjne lub wewnętrzne regulacje firmy.
Źródła:
Źródło: www.habr.com