W wielu firmach jeden fizyczny serwer przez lata staje się centrum działania: przechowuje pliki, bazę programu księgowego, system sprzedaży, wydruki, aplikacje branżowe i kopie danych. Dopóki działa, nikt nie liczy kosztu ryzyka. Problem zaczyna się wtedy, gdy awaria sprzętu zatrzymuje jednocześnie kilka procesów biznesowych.
W artykule
Pojedynczy punkt awarii to nie tylko serwer
Pojedynczym punktem awarii może być fizyczny host, macierz, przełącznik, łącze internetowe, zasilanie, konto administratora, repozytorium backupu albo osoba, która jako jedyna zna procedurę uruchomienia systemu. Dojrzała infrastruktura nie polega na tym, że „nic się nie zepsuje”, ale na tym, że awaria jednego elementu nie zatrzyma firmy na nieokreślony czas.
Odporność środowiska na przestój
Wykres pokazuje orientacyjny wzrost odporności infrastruktury wraz z dołożeniem kolejnych warstw: wirtualizacji, backupu, wysokiej dostępności i procedury odtworzenia.
To nie jest ocena konkretnego produktu. Najważniejsza jest spójność projektu: storage, sieć, backup, monitoring i regularne testy.
Wirtualizacja ułatwia podział systemów
Dobrze zaprojektowana wirtualizacja pozwala oddzielić usługi, które wcześniej żyły na jednym systemie operacyjnym. Osobna maszyna dla księgowości, osobna dla aplikacji magazynowej, osobna dla usług plikowych i osobna dla kontrolera domeny ułatwiają backup, aktualizacje i odtworzenie. Awaria jednej maszyny logicznej nie musi oznaczać problemu całego środowiska.
| Model | Zalety | Ograniczenia | Dla kogo |
|---|---|---|---|
| Jeden host wirtualizacji | Porządek, łatwiejszy backup maszyn, lepsze wykorzystanie sprzętu. | Host nadal jest pojedynczym punktem awarii. | Małe firmy z akceptowalnym krótkim przestojem. |
| Dwa hosty + replikacja | Możliwość uruchomienia usług na drugim hoście. | Wymaga procedury przełączenia i testów. | Firmy z systemami krytycznymi, ale bez potrzeby pełnego klastra. |
| Klaster HA | Automatyczne przełączenie maszyn przy awarii hosta. | Wymaga dobrego storage, sieci i monitoringu. | Organizacje z niską tolerancją na przestój. |
| DR poza lokalizacją | Ochrona przed awarią miejsca, pożarem, zalaniem, dłuższym brakiem zasilania. | Wyższy koszt, konieczne testy i priorytety uruchamiania. | Firmy, dla których lokalna awaria nie może zatrzymać sprzedaży lub obsługi klienta. |
RTO i RPO trzeba przypisać do usług, nie do serwera
Serwer fizyczny jest tylko nośnikiem. Decyzje biznesowe powinny dotyczyć usług: księgowości, dokumentów, systemu zamówień, poczty, aplikacji produkcyjnej. Każda z nich może mieć inne RTO i RPO. Niektóre trzeba uruchomić w pierwszej godzinie, inne mogą poczekać do następnego dnia.
Najczęstsze błędy projektowe
Pierwszy błąd to wiara, że sama wirtualizacja rozwiązuje problem awarii. Drugi to backup przechowywany na tym samym storage, który obsługuje produkcję. Trzeci to brak monitoringu wolnego miejsca, błędów dysków, zadań backupu i obciążenia. Czwarty to brak dokumentacji: administrator wie, co zrobić, ale firma nie ma zapisanej procedury.
Minimum techniczne
- Backup maszyn wirtualnych poza głównym hostem.
- Monitoring stanu hostów, storage i zadań kopii.
- Oddzielne konta administracyjne.
- Procedura startu usług w kolejności priorytetów.
Minimum organizacyjne
- Lista właścicieli systemów.
- Opis akceptowalnego przestoju.
- Kontakt do dostawców aplikacji.
- Test odtworzenia przynajmniej raz w roku.
HA nie chroni przed błędem logicznym
Jeżeli użytkownik usunie dane, aplikacja uszkodzi bazę albo ransomware zaszyfruje pliki, klaster może bardzo sprawnie utrzymywać dostęp do uszkodzonego stanu. Do takich zdarzeń potrzebny jest backup punktów w czasie.
Wnioski dla firmy
Wirtualizacja ma największą wartość, gdy jest częścią planu ciągłości działania. Najpierw trzeba wiedzieć, które usługi są krytyczne, potem dobrać architekturę i backup, a na końcu cyklicznie sprawdzać, czy środowisko da się odtworzyć. Dobrze zaprojektowany system nie obiecuje braku awarii. Obiecuje, że awaria ma scenariusz.
Serwer przestaje być pojedynczym punktem awarii dopiero wtedy, gdy awaria sprzętu, błąd człowieka i uszkodzenie danych mają osobne scenariusze reakcji.
Źródła i punkty odniesienia:
- NIST SP 800-34 Rev. 1 - Contingency Planning Guide - planowanie odtwarzania systemów i priorytetów ciągłości działania po awarii.
- CSIRT GOV - najlepsze praktyki obsługi incydentu - polski poradnik dotyczący zabezpieczania danych i przywracania działania po incydencie.