Klaster wysokiej dostępności
Twoje usługi działają dalej, gdy serwer ulega awarii.
Budujemy klastry wysokiej dostępności (HA) na Proxmox VE, Hyper-V, SUSE Virtualization i XCP-ng, które wykrywają awarie węzłów i automatycznie restartują Twoje maszyny wirtualne.
-
Automatyczne przełączanie awaryjne i powrót po awarii -
Ciągła replikacja maszyn wirtualnych -
Rozproszona pamięć masowa z Ceph -
Wykrywanie awarii w kilka sekund -
Monitorowanie stanu węzłów i alertowanie
Brak pojedynczego punktu awarii
Zweryfikowanoprzełączenie awaryjne
Minutydo regeneracji
Odporny na utratęwęzła
Co daje klaster HA
Klaster wysokiej dostępności utrzymuje działanie usług podczas awarii sprzętu, okien serwisowych, a nawet awarii regionalnych. Oto, co oznacza to w praktyce.
-
Minimalny czas przestoju
Czytaj więcej MniejGdy węzeł ulegnie awarii, jego maszyny wirtualne są w ciągu kilku minut uruchamiane ponownie na sprawnych węzłach – bez konieczności ręcznej interwencji. Węzły są aktualizowane pojedynczo, a maszyny wirtualne migrują na żywo na inne węzły, dzięki czemu konserwacja nie oznacza już okna niedostępności.
-
Bezpieczeństwo danych
Czytaj więcej MniejDane maszyn wirtualnych są stale replikowane między węzłami lub przechowywane w rozproszonej pamięci masowej, takiej jak Ceph. Utrata jednego dysku, jednego węzła lub jednej ścieżki sieciowej nie powoduje wyłączenia dostępu do danych.
-
Przewidywalny powrót do zdrowia
Czytaj więcej MniejCele dotyczące czasu odtwarzania i punktu odtwarzania są uzgadniane na etapie projektowania – a następnie weryfikowane w testach przełączenia awaryjnego, zamiast pozostawać wyłącznie na papierze. Gdy uszkodzony węzeł wraca do działania, obciążenia są przenoszone z powrotem w uporządkowany sposób.
-
Wybór platformy
Czytaj więcej MniejBudujemy klastry HA na Proxmox VE, Microsoft Hyper-V, SUSE Virtualization i XCP-ng. Każda platforma ma własny stos replikacji i zarządzania – wybieramy tę, którą Twoi inżynierowie będą faktycznie komfortowo administrować.
-
Nieprzerwany wzrost
Czytaj więcej MniejPojemność zwiększa się poprzez dodawanie węzłów do klastra, a obciążenia są między nimi równoważone – nowe węzły dołączają, podczas gdy usługi nadal działają. Maszyny wirtualne są rozmieszczane między węzłami na podstawie rzeczywistego obciążenia, co pozwala utrzymać stałe czasy odpowiedzi.
-
Przejrzyste koszty
Czytaj więcej MniejProxmox VE i XCP-ng obejmują HA bez dodatkowych kosztów licencyjnych – płacisz za sprzęt i konfigurację, a nie za licencje klastra na każdy węzeł. Platformy komercyjne są również obsługiwane, jeśli są zgodne z posiadanymi licencjami.
Obciążenia, które uzasadniają zastosowanie klastra HA
- Bazy danych i kolejki komunikatów
- Systemy e-commerce i płatności
- Platformy SaaS i portale klienta
- ERP, CRM i aplikacje o krytycznym znaczeniu dla biznesu
- Opieka zdrowotna i systemy regulowane
- Usługi strumieniowania i czasu rzeczywistego
- Usługi plików i magazynowania
- VoIP i platformy komunikacyjne
Klaster HA pod klucz – od projektu po
zweryfikowane przełączenie awaryjne
-
1
Ocena i projektowanie
Identyfikujemy Twoje krytyczne aplikacje, dopuszczalny czas przestoju oraz cele odzyskiwania. Audytujemy istniejący sprzęt, sieć i pamięć masową. Na tej podstawie projektujemy klaster – liczbę węzłów, układ pamięci masowej oraz logikę przełączania awaryjnego – tak, aby spełnić te cele.
-
2
Konfiguracja węzła i sieci
Konfigurujemy serwery jako węzły klastra z redundantnymi połączeniami międzywęzłowymi. Adresy IP przełączania awaryjnego oraz redundancja sieci są konfigurowane i weryfikowane. Współdzielona lub rozproszona pamięć masowa jest wdrażana w celu zapewnienia redundancji danych.
-
3
Konfiguracja klastra
Instalujemy i konfigurujemy usługi klastrowe w Proxmox VE, Microsoft Hyper-V, SUSE Virtualization lub XCP-ng. Zasoby klastra – wirtualne adresy IP, pamięć masowa i zasoby obliczeniowe – są definiowane i priorytetyzowane. Reguły automatycznego przełączania awaryjnego i powrotu po awarii są konfigurowane dla każdego obciążenia.
-
4
Testowanie przełączania awaryjnego
Symulujemy awarie węzłów i weryfikujemy, czy maszyny wirtualne uruchamiają się ponownie tam, gdzie powinny, w uzgodnionym czasie. Wydajność pod obciążeniem podczas przełączania awaryjnego jest mierzona, a nie zakładana. Testowane jest również odzyskiwanie po awariach pamięci masowej i sieci.
-
5
Monitorowanie i konserwacja
Monitorowanie śledzi stan węzłów, status replikacji oraz kworum klastra. Alerty są uruchamiane w przypadku zdarzeń krytycznych – utraty węzła, pogorszonej replikacji, wyczerpania zasobów. Zaplanowana konserwacja utrzymuje stabilność klastra bez przerywania działania usług.
-
6
Bieżące wsparcie
Nasi inżynierowie pozostają dostępni w celu rozwiązywania problemów oraz wprowadzania zmian w konfiguracji. Aktualizacje i uaktualnienia stosujemy węzeł po węźle, bez przestojów klastra.
Najczęściej zadawane pytania
-
Jak szybko w rzeczywistości następuje przełączenie awaryjne?
W większości konfiguracji HA maszyna wirtualna z uszkodzonego węzła uruchamia się ponownie na sprawnym węźle w ciągu od jednej do pięciu minut – dokładny czas zależy od platformy, pamięci masowej oraz tego, jak szybko uruchamia się system operacyjny gościa. W przypadku planowanych zdarzeń migracja na żywo przenosi maszyny wirtualne bez żadnej przerwy. Jeśli nawet minuta to zbyt długo, zobacz poniżej pytanie dotyczące odporności na awarie.
-
Ile serwerów potrzebuję do klastra HA?
Trzy węzły to praktyczne minimum – klaster potrzebuje większości głosów (kworum), aby zdecydować, które węzły są sprawne, i uniknąć sytuacji split-brain. Konfiguracja z dwoma węzłami jest możliwa przy użyciu zewnętrznego urządzenia kworum, ale zalecamy konfigurację z trzema lub większą liczbą węzłów.
-
Czy wszystkie cztery hiperwizory obsługują wysoką dostępność?
Tak. Proxmox VE ma wbudowany menedżer HA, Microsoft Hyper-V korzysta z klastrowania pracy awaryjnej Windows Server, SUSE Virtualization oferuje HA od razu po instalacji, a XCP-ng zapewnia je za pośrednictwem swojego stosu zarządzania. Zasady są takie same – różnią się narzędzia, które dopasowujemy do Twojego zespołu.
-
Jakiej pamięci masowej wymaga klaster HA?
Przełączanie awaryjne działa tylko wtedy, gdy każdy węzeł ma dostęp do danych VM, dlatego klaster potrzebuje współdzielonej lub rozproszonej pamięci masowej – na przykład Ceph, replikowanych wolumenów albo zewnętrznego systemu pamięci masowej. Same dyski lokalne nie wystarczą; warstwę pamięci masowej projektujemy razem z klastrem.
-
Czy klaster HA chroni mnie przed utratą danych?
HA chroni dostępność, a nie historię – jeśli dane zostaną uszkodzone lub usunięte, replikacja wiernie skopiuje szkody na każdy węzeł. Dlatego kopie zapasowe pozostają obowiązkowe obok każdego klastra. To, ile najnowszych danych może zostać utraconych podczas przełączenia awaryjnego, zależy od tego, czy replikacja jest synchroniczna, czy asynchroniczna, a my ustawiamy to zgodnie z Twoim celem punktu odzyskiwania.
-
Czy użytkownicy zauważą coś podczas przełączenia awaryjnego?
W przypadku zdarzeń planowanych – konserwacji, równoważenia obciążenia – maszyny wirtualne są przenoszone między węzłami na żywo, a użytkownicy niczego nie zauważają. W przypadku nieplanowanej awarii węzła dotknięte nią maszyny wirtualne uruchamiają się ponownie na innym węźle, więc aktywne sesje na tych maszynach są na krótko przerywane, a następnie wznawiane. Dobrze zaprojektowane aplikacje łączą się ponownie automatycznie, a dla większości użytkowników wygląda to jak ponowne załadowanie strony.
-
Jaka jest różnica między wysoką dostępnością a odpornością na awarie?
Wysoka dostępność uruchamia ponownie dotknięte awarią maszyny wirtualne na innym węźle – występuje krótka przerwa. Odporność na awarie utrzymuje działające lustrzane odbicie uruchomionej maszyny, więc awaria węzła nie powoduje żadnej przerwy – kosztem mniej więcej podwojenia zasobów. Większości obciążeń wystarcza HA; odporność na awarie jest zarezerwowana dla nielicznych, które nie mogą tolerować nawet sekund przestoju.
-
Czy moje aplikacje wymagają zmian, aby działać w klastrze wysokiej dostępności?
Zazwyczaj nie – HA na poziomie maszyny wirtualnej jest transparentna dla aplikacji działających wewnątrz. W przypadku baz danych i innych usług stanowych można dodać replikację na poziomie aplikacji ponad HA klastra, aby uzyskać jeszcze lepsze gwarancje odtwarzania, ale jest to opcja, a nie wymóg.
