Twój serwer to pojedynczy punkt awarii — kiedy firma naprawdę potrzebuje drugiego
Profesjonalne centrum danych potrafi zrobić bardzo dużo, żeby Twój sprzęt nigdy nie stracił zasilania ani łącza. Czego nie zrobi — to zduplikować za Ciebie aplikacji. Jeśli cała usługa stoi na jednej maszynie, to ta maszyna jest pojedynczym punktem awarii, niezależnie od tego, jak dobrze zbudowana jest serwerownia wokół niej.
To rozróżnienie ginie w rozmowach o infrastrukturze zaskakująco często. Dział IT czyta w ofercie o gwarantowanym zasilaniu i wsparciu technicznym, po czym zakłada, że dostawca „ma to ogarnięte". Ma — ale tylko do gniazda w szafie.
SLA to gwarancja naprawy, a nie gwarancja ciągłości
Warto przeczytać zapis SLA dosłownie. W ofercie serwerów dedykowanych SDC zobowiązujemy się, że zgodnie z umową SLA uszkodzony element lub cały serwer zostanie wymieniony do 6 godzin. To bardzo konkretne zobowiązanie sprzętowe — i jednocześnie jasna informacja, czego nie obiecuje: nie obiecuje, że Twoja aplikacja nie zniknie z internetu na te kilka godzin.
Gwarancja naprawy odpowiada na pytanie „jak szybko sprzęt wróci do życia". Gwarancja ciągłości odpowiada na pytanie „czy klient w ogóle zauważy awarię". Drugą z nich buduje się po stronie architektury, nie po stronie umowy.
Praktyczny wniosek jest prosty: policz, ile kosztuje Twoją firmę kilka godzin niedostępności sklepu, systemu zamówień albo API dla partnerów. Jeżeli ta kwota jest wyższa niż roczny koszt drugiej maszyny — decyzja właściwie już zapadła.
Redundancja centrum danych kończy się na gnieździe zasilania
Po stronie infrastruktury robimy pełen zakres tego, co da się zrobić poniżej warstwy Twojego systemu. W kolokacji zapewniamy gwarantowane, dwutorowe zasilanie, podtrzymanie z UPS-ów i agregatu prądotwórczego, klimatyzację precyzyjną, łącza dostępowe od różnych operatorów, ochronę anty-DDoS oraz monitoring i wsparcie techniczne w trybie 24/7/365. Szerzej opisaliśmy to we wpisie o niezawodności data center.
Zwróć uwagę, gdzie przebiega granica. Dwutorowe zasilanie ma sens tylko wtedy, gdy Twój serwer ma dwa zasilacze i faktycznie korzysta z obu torów. Łącza od kilku operatorów chronią przed awarią transmisji, ale nie przed zawieszeniem się Twojego hypervisora. Redundancja jest warstwowa i działa dokładnie do tej warstwy, na której się kończy.
Gdzie naprawdę siedzą pojedyncze punkty awarii
Zanim zaczniesz kupować sprzęt, zrób inwentaryzację. W typowej firmowej architekturze pojedyncze punkty awarii układają się mniej więcej tak:
- Dysk — chroniony przez RAID, ale RAID to nie backup i nie ratuje przed skasowaniem danych ani przed ransomware. Pisaliśmy o tym w tekście o backupie odpornym na ransomware.
- Zasilacz — redundantny tylko wtedy, gdy serwer ma dwa i szafa daje dwa niezależne tory.
- Cały serwer — płyta główna, kontroler RAID czy pamięć nie mają wewnętrznej redundancji. Tu kończy się ochrona sprzętowa, a zaczyna SLA na wymianę.
- Baza danych — najczęściej pomijany punkt awarii. Nawet przy dwóch serwerach aplikacyjnych jedna baza potrafi położyć całość.
- DNS i adresacja — jeśli przełączenie ruchu wymaga zmiany rekordu z długim TTL, realny czas powrotu wydłuża się o ten TTL.
- Człowiek — jedna osoba, która wie, jak przełączyć system, jest takim samym pojedynczym punktem awarii jak jeden dysk.
Trzy poziomy dostępności — i ich realny koszt
Nie każda firma potrzebuje klastra. Wybór sprowadza się do świadomej decyzji, na którym poziomie chcesz być.
Poziom 1 — jeden serwer plus backup poza lokalizacją. Czas powrotu liczony w godzinach, bo trzeba odtworzyć dane na nowym sprzęcie. Wystarcza dla systemów wewnętrznych, których kilkugodzinny przestój jest kłopotem, ale nie katastrofą. Warunek: backup musi być w drugiej lokalizacji i regularnie testowany — omawialiśmy to przy okazji disaster recovery.
Poziom 2 — druga maszyna jako rezerwa z replikacją. Drugi serwer stoi gotowy, dane replikują się na bieżąco, przełączenie jest ręczne albo półautomatyczne. Czas powrotu spada do minut. To zwykle najlepszy stosunek kosztu do efektu dla średnich firm.
Poziom 3 — klaster active-active z równoważeniem ruchu. Oba węzły pracują jednocześnie, awaria jednego jest niewidoczna dla użytkownika. Cena: podwojony sprzęt, replikacja synchroniczna, wyraźnie wyższa złożoność operacyjna i konieczność regularnego testowania przełączeń. Uzasadniony tam, gdzie minuta przestoju realnie kosztuje.
Detal, który upraszcza przełączenie: adresacja IP
Jest w naszej ofercie szczegół, który przy budowie rezerwy ma większe znaczenie, niż się wydaje: dodatkowe adresy IP są przypisane do klienta, a nie do konkretnej usługi. W praktyce oznacza to, że adres, pod którym działa Twoja aplikacja, może zostać przepięty na drugą maszynę — bez czekania na propagację zmian w DNS-ie i bez liczenia na krótki TTL.
Do tego dochodzi komunikacja między węzłami. Replikacja bazy czy synchronizacja plików nie powinny wychodzić do publicznego internetu — sposób ułożenia takiej sieci wewnętrznej między serwerami opisaliśmy osobno.
Pięć pytań przed zakupem drugiego serwera
- Ile godzin przestoju wytrzymamy? To Twoje RTO. Bez tej liczby cała dyskusja jest teoretyczna.
- Ile danych możemy stracić? To RPO. Backup nocny oznacza akceptację utraty całego dnia pracy.
- Kto i jak wykonuje przełączenie? Procedura musi być spisana i wykonalna przez więcej niż jedną osobę.
- Kiedy ostatnio testowaliśmy odtworzenie? Nieprzetestowana rezerwa to założenie, nie zabezpieczenie.
- Czy nasza umowa i SLA odpowiadają tym wymaganiom? Pomocna jest tu checklista umowy i SLA.
Podsumowanie
Redundancja infrastruktury i redundancja usługi to dwie osobne warstwy odpowiedzialności. Centrum danych bierze na siebie zasilanie, chłodzenie, łącza i wymianę sprzętu w terminie zapisanym w umowie. Decyzja, czy Twoja aplikacja przetrwa awarię pojedynczej maszyny bez przestoju, należy do Ciebie — i sprowadza się do jednej liczby: kosztu godziny niedostępności.
Jeśli chcesz przeliczyć swój scenariusz, zestawić drugi węzeł albo omówić architekturę rezerwy, sprawdź nasze serwery dedykowane i kolokację, a po dobór konkretnej konfiguracji napisz do nas.
FAQ – najczęściej zadawane pytania o wysoką dostępność serwera
Czym różni się wysoka dostępność od disaster recovery?
Wysoka dostępność ma nie dopuścić do przestoju przy awarii pojedynczego elementu — działa w czasie rzeczywistym i zwykle w jednej lokalizacji. Disaster recovery to plan powrotu po zdarzeniu, które objęło całe środowisko, i opiera się na kopii w drugiej lokalizacji. HA skraca czas niedostępności, DR ratuje dane.
Czy RAID wystarczy zamiast drugiego serwera?
Nie. RAID zabezpiecza wyłącznie przed awarią dysku i nie chroni przed uszkodzeniem płyty głównej, kontrolera czy pamięci ani przed błędem administratora lub zaszyfrowaniem danych. To ochrona jednej warstwy, nie całej maszyny — RAID i rezerwa sprzętowa rozwiązują dwa różne problemy.
Czy drugi serwer musi być identyczny z pierwszym?
Nie musi, ale powinien udźwignąć produkcyjne obciążenie i mieć zgodną konfigurację systemu. Węzeł zapasowy o niższej wydajności bywa rozsądnym kompromisem, jeśli firma świadomie akceptuje wolniejsze działanie w czasie awarii. Kluczowa jest zgodność wersji oprogramowania i sposobu przechowywania danych.
Co daje dwutorowe zasilanie, jeśli mam jeden serwer?
Chroni przed awarią jednego toru zasilania w serwerowni, ale tylko wtedy, gdy sam serwer ma dwa zasilacze podłączone do obu torów. Przy maszynie z jednym zasilaczem redundancja infrastruktury nie przełoży się na dostępność Twojej usługi — dlatego warto sprawdzić to już na etapie doboru sprzętu.
Od czego zacząć, jeśli dziś mamy jeden serwer i backup?
Od wyznaczenia RTO i RPO, czyli akceptowalnego czasu przestoju i akceptowalnej utraty danych. Dopiero te dwie liczby pokazują, czy wystarczy poprawić testowanie backupu, czy trzeba dokupić węzeł zapasowy z replikacją. Bez nich łatwo przepłacić za architekturę, której firma nie potrzebuje.
Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu Sprint Data Center. Grafika ilustracyjna została wygenerowana przez AI.