Klaster VPS – czy można zbudować go z kilku serwerów wirtualnych?

Tak, z kilku serwerów VPS można zbudować klaster, w którym poszczególne maszyny wspólnie obsługują stronę, aplikację albo wybrane usługi. Możemy rozdzielić między nie ruch użytkowników, kod aplikacji, bazę danych, pliki, pamięć cache i zadania wykonywane w tle. Nie wystarczy jednak zamówić kilku VPS-ów i zainstalować na nich tego samego oprogramowania. Serwery trzeba połączyć, przypisać im role oraz ustalić, w jaki sposób będą wymieniały dane i reagowały na awarie. Istotne są także monitoring, tworzenie kopii zapasowych i sposób kierowania ruchu. Dopiero cały ten układ możemy nazywać sprawnie działającym klastrem VPS.

Klaster nie musi przy tym oznaczać pełnej odporności na awarie. Możemy zbudować go wyłącznie w celu zwiększenia wydajności, pozostawiając w systemie elementy, których zatrzymanie wyłączy całą usługę.

• Czy z kilku VPS-ów można zbudować jeden klaster?
• Jak działa klaster VPS i co można rozdzielić między serwery?
• Czy klaster VPS zapewnia wysoką dostępność?
• Replikacja, backup i monitoring klastra
• Kiedy warto zbudować klaster z kilku VPS-ów?
• Jak zaplanować budowę klastra VPS?

Kilka serwerów VPS może utworzyć klaster, ale jego możliwości zależą od zaprojektowanej architektury. Większa liczba maszyn nie gwarantuje automatycznie wysokiej dostępności ani bezpieczeństwa danych.

Podstawą klastra są niezależne maszyny z dostępem administracyjnym i zasobami dopasowanymi do wykonywanych zadań. Zobacz dostępne serwery VPS z wirtualizacją KVM, dyskami SSD NVMe oraz możliwością rozbudowy CPU, RAM i przestrzeni dyskowej.

Czy z kilku VPS-ów można zbudować jeden klaster?

Serwery VPS mogą działać jak niezależne węzły jednego systemu, mimo że każdy z nich ma własny system operacyjny, adres IP, pamięć RAM i przydzieloną moc procesora. Jeden VPS może przyjmować ruch użytkowników, dwa kolejne obsługiwać aplikację, a następny przechowywać bazę danych. Jeżeli aplikacja wykonuje dużo zadań w tle, możemy przeznaczyć dla nich jeszcze jedną maszynę. W takim układzie rozbudowa nie musi oznaczać wymiany całego serwera na mocniejszy. Dodajemy kolejne węzły albo zwiększamy zasoby tylko tam, gdzie są rzeczywiście potrzebne. Takie podejście nazywamy skalowaniem poziomym, ponieważ zwiększamy liczbę maszyn zamiast rozbudowywać wyłącznie jeden serwer.

Nie każdy system rozłożony na kilka VPS-ów jest jednak klastrem w ścisłym znaczeniu. Jeśli przeniesiemy bazę danych na oddzielny serwer, ale wszystkie elementy nadal zależą od jej dostępności, otrzymujemy przede wszystkim rozdzieloną architekturę. Klaster zaczyna przynosić dodatkowe korzyści wtedy, gdy węzły potrafią współdzielić zadania, zastępować się albo przejmować ruch po wykryciu problemu.

Cena pojedynczego taniego VPS-a ułatwia rozpoczęcie takiego projektu, lecz koszt całego środowiska obejmuje również konfigurację, administrację i monitoring. Im więcej zależności wprowadzimy, tym więcej elementów trzeba będzie później aktualizować i kontrolować.

Jak działa klaster VPS i co można rozdzielić między serwery?

Projektowanie klastra zaczynamy od rozpisania funkcji pełnionych obecnie przez jeden serwer. Typowa aplikacja odbiera zapytania użytkowników, wykonuje kod, pobiera dane z bazy, korzysta z pamięci podręcznej, zapisuje pliki i uruchamia zadania w tle. Wszystkie te operacje mogą działać na jednej maszynie, dopóki jej zasoby są wystarczające. Przy większym ruchu zaczynamy rozdzielać najbardziej obciążające lub krytyczne elementy. Nie musimy przy tym od razu tworzyć rozbudowanej infrastruktury z kilkunastu węzłów.

Przed serwerami aplikacji najczęściej umieszczamy load balancer. To on decyduje, do którego węzła trafi kolejne zapytanie. Może rozdzielać ruch kolejno, uwzględniać liczbę aktywnych połączeń albo kierować większą część zapytań do mocniejszej maszyny. Jeżeli wykryje, że jeden serwer nie odpowiada, przestaje wysyłać do niego nowych użytkowników.

Nie będziemy tutaj ponownie szczegółowo opisywać algorytmów równoważenia ruchu oraz różnic między load balancingiem na warstwie L4 i L7. Te zagadnienia omawiamy szerzej w osobnym poradniku o działaniu load balancera. Dla klastra VPS ważne jest to, że kilka węzłów aplikacyjnych potrzebuje wspólnego punktu wejścia i mechanizmu oceniającego ich dostępność.

Trzeba też rozwiązać problem plików i sesji. Jeżeli użytkownik prześle zdjęcie na pierwszy VPS, plik powinien być widoczny również wtedy, gdy następne żądanie trafi do drugiej maszyny. Podobnie wygląda sytuacja z koszykiem w sklepie lub zalogowaną sesją. Dane przechowywane wyłącznie lokalnie sprawiają, że każdy węzeł zaczyna widzieć inny stan aplikacji. Rozwiązaniem jest wspólny magazyn plików, zewnętrzna pamięć obiektowa, współdzielony system plików albo odpowiednio zaplanowana synchronizacja. Sesje można przechowywać w centralnej usłudze, np. Redis, zamiast na lokalnym dysku konkretnego VPS-a.

Czy klaster VPS zapewnia wysoką dostępność?

Niestety nie. Klaster nie zawsze oznacza wysoką dostępność. Możemy uruchomić pięć serwerów aplikacji, ale pozostawić jedną bazę danych, jeden load balancer i jeden magazyn plików. Taki system obsłuży większy ruch, jednak awaria dowolnego z tych pojedynczych elementów może zatrzymać całą usługę.

Element, od którego zależy działanie systemu i który nie ma gotowego zastępstwa, określamy jako pojedynczy punkt awarii, czyli Single Point of Failure. Jeżeli naszym celem jest rzeczywista odporność na awarie, musimy przeanalizować całą drogę zapytania: od DNS i load balancera, przez aplikację, aż po bazę oraz pliki. Każdy krytyczny element powinien mieć przygotowany mechanizm przejęcia jego zadań.

Właśnie tym różni się zwykły klaster zwiększający wydajność od środowiska zapewniającego High Availability.

Szczególnej uwagi wymaga baza danych. Nie wystarczy skopiować jej na drugi VPS, ponieważ kolejne zmiany muszą trafiać do odpowiednich węzłów we właściwej kolejności. W replikacji synchronicznej serwer główny czeka na potwierdzenie zapisu przez określony serwer zapasowy. Ogranicza to ryzyko utraty zatwierdzonych danych, ale wydłuża wykonanie operacji. Przy replikacji asynchronicznej główny serwer nie czeka na natychmiastowe potwierdzenie, dzięki czemu zapis jest szybszy, lecz replika przez pewien czas pozostaje w tyle. Nagła awaria może wtedy oznaczać utratę ostatnich zmian albo wyświetlenie nieaktualnych informacji po przełączeniu ruchu.

Opóźnienia pomiędzy serwerami wpływają więc nie tylko na szybkość strony. Mogą decydować o sposobie replikacji i zachowaniu całej aplikacji. Węzły bazy danych warto umieszczać w tej samej lokalizacji lub w sieci zapewniającej niskie i stabilne opóźnienia. Łączenie przypadkowych VPS-ów z odległych centrów danych nie stworzy automatycznie lepszego klastra.

Osobnym zagadnieniem jest automatyczne przełączenie usług. Sam fakt posiadania repliki nie oznacza, że aplikacja zacznie z niej korzystać po awarii serwera głównego. Potrzebny jest mechanizm wykrywania problemu, wskazania nowego węzła głównego i skierowania do niego zapytań. Źle zaprojektowane automatyczne przełączenie potrafi doprowadzić do sytuacji, w której dwa serwery jednocześnie uznają się za główne i przyjmują sprzeczne zmiany.

Replikacja, backup i monitoring klastra

Replikacja pomaga utrzymać dostępność aktualnych danych, ale nie zastępuje kopii zapasowej. Jeżeli administrator przypadkowo usunie tabelę, aplikacja nadpisze pliki błędną wersją albo ransomware zaszyfruje dane, ta sama zmiana może zostać szybko powielona na pozostałych węzłach. Replika będzie wtedy równie aktualna i równie uszkodzona jak źródło. Backup zachowuje wcześniejsze punkty w czasie i pozwala wrócić do stanu sprzed błędu. W dobrze zabezpieczonym klastrze wykorzystujemy więc zarówno replikację, jak i niezależne kopie przechowywane poza głównym środowiskiem. Samo wykonywanie backupu nie wystarcza — trzeba również sprawdzać, czy da się z niego odtworzyć aplikację wraz z konfiguracją.

• To jest kluczowe: replikacja podtrzymuje działanie, a backup umożliwia odzyskanie danych.

Przy kilku VPS-ach rośnie również znaczenie monitoringu. Nie wystarczy sprawdzać wykorzystania procesora, pamięci RAM i miejsca na dysku. Musimy wiedzieć, czy wszystkie węzły odpowiadają, czy load balancer prawidłowo rozdziela ruch, jak duże jest opóźnienie replikacji, czy kolejki zadań są wykonywane oraz kiedy zakończył się ostatni poprawny backup. Jeden serwer aplikacji może nie działać przez kilka dni, podczas gdy użytkownicy nie zauważą problemu, ponieważ pozostałe maszyny nadal obsługują ruch. Brak alarmu oznacza jednak utratę części zapasu wydajności i odporności na kolejną awarię.

Do zbierania danych i wysyłania powiadomień możemy wykorzystać między innymi Zabbix. System monitorujący powinien pracować niezależnie od infrastruktury, którą kontroluje. Jeżeli umieścimy go wyłącznie wewnątrz klastra, awaria całego środowiska wyłączy jednocześnie monitoring i powiadomienia.

W większym środowisku przydaje się także automatyzacja konfiguracji. Ręczne instalowanie aplikacji i wprowadzanie zmian na każdym VPS-ie zwiększa ryzyko, że poszczególne węzły zaczną się od siebie różnić. Kontenery ułatwiają uruchamianie tej samej wersji aplikacji na wielu maszynach, ale nie oznacza to, że od razu potrzebujemy rozbudowanej platformy orkiestracyjnej. Więcej o tym rozwiązaniu przeczytasz w artykule wyjaśniającym, do czego służą Docker i Kubernetes.

Kiedy warto zbudować klaster z kilku VPS-ów?

Budowa klastra ma sens wtedy, gdy rozwiązuje konkretny problem biznesowy lub techniczny. Jedna aplikacja potrzebuje większej wydajności, inna musi działać również podczas aktualizacji, a w kolejnym przypadku najważniejsza będzie możliwość szybkiego przejęcia ruchu po awarii. Nie powinniśmy zaczynać od pytania, ile serwerów kupić. Najpierw ustalamy, czego brakuje obecnemu środowisku i jaki czas przerwy jesteśmy w stanie zaakceptować. Sprawdzamy też, który element naprawdę stanowi wąskie gardło. Dodanie kolejnych serwerów WWW nie pomoże, jeśli aplikację spowalniają błędne zapytania do jednej przeciążonej bazy danych.

Klaster VPS warto rozważyć, gdy:

• aplikacja obsługuje rosnący albo mocno zmienny ruch;
• chcemy niezależnie skalować aplikację, bazę danych i zadania w tle;
• prowadzimy sklep, system rezerwacyjny, SaaS lub usługę działającą przez całą dobę;
• aktualizacje powinny odbywać się bez całkowitego wyłączania aplikacji;
• koszt przerwy uzasadnia utrzymywanie dodatkowych węzłów;
• jeden duży serwer staje się trudny lub kosztowny w dalszej rozbudowie.

Klaster nie będzie natomiast najlepszą odpowiedzią dla każdego projektu. Niewielka strona firmowa, blog lub prosty sklep często będzie działać stabilniej na jednym odpowiednio dobranym VPS-ie. Takie środowisko łatwiej zabezpieczyć, aktualizować, monitorować i odtworzyć. Zanim zwiększymy liczbę serwerów, warto zoptymalizować kod, bazę danych, cache oraz konfigurację już używanej maszyny. Często jest to tańsze i skuteczniejsze niż budowanie rozproszonego systemu.

Więcej serwerów oznacza nie tylko większą wydajność, ale również więcej aktualizacji, logów, reguł sieciowych, zależności i potencjalnych błędów.

Jak zaplanować budowę klastra VPS?

Planowanie zaczynamy od narysowania obecnej architektury i wskazania elementów niezbędnych do działania usługi. Następnie określamy, które z nich chcemy skalować, a które muszą mieć gotowe zastępstwo na wypadek awarii. Ustalamy miejsce przechowywania plików, sesji oraz danych aplikacji. Trzeba również zdecydować, jak będzie działało wykrywanie awarii i przełączanie ruchu. Dopiero po wykonaniu tej analizy dobieramy liczbę VPS-ów oraz zasoby CPU, RAM i przestrzeni dyskowej.

Przed uruchomieniem środowiska odpowiedzmy na kilka pytań:

• Co jest obecnie wąskim gardłem aplikacji?
• Czy zależy nam głównie na wydajności, czy również na wysokiej dostępności?
• Gdzie będą przechowywane pliki i sesje użytkowników?
• Jak będzie działać baza danych oraz jej replikacja?
• Co przejmie ruch po awarii load balancera?
• Jak wykryjemy awarię pojedynczego węzła?
• Gdzie znajdą się kopie zapasowe i jak odtworzymy z nich środowisko?
• Czy potrafimy ponownie utworzyć konfigurację utraconego VPS-a?

Na początek możemy rozdzielić aplikację i bazę danych albo uruchomić dwa węzły aplikacyjne za load balancerem. Taki układ pozwala zdobyć doświadczenie bez tworzenia od razu rozbudowanej infrastruktury. Kolejne elementy dodajemy wtedy, gdy wynika to z pomiarów, wymagań dostępności albo rozwoju projektu.

Dobierając pakiety VPS, nie musimy wybierać identycznej konfiguracji dla każdego węzła. Serwery aplikacji mogą potrzebować większej mocy CPU, baza danych większej ilości RAM i szybkiego dysku, a load balancer znacznie mniejszych zasobów. Liczy się rola konkretnej maszyny w całym systemie.

Najważniejszy wniosek: z kilku serwerów wirtualnych możemy zbudować wydajny klaster VPS, ale jego jakość zależy od architektury, a nie od samej liczby maszyn. Jeśli nie rozwiążemy kwestii bazy danych, plików, sesji, monitoringu i backupu, zwiększymy złożoność systemu bez uzyskania oczekiwanej odporności na awarie.

Przeczytaj również: co to jest load balancer, jak działa High Availability, jaki rodzaj backupu wybrać, jak działa monitoring Zabbix oraz do czego służą Docker i Kubernetes.