Spis treści
Kolokacja infrastruktury krytycznej wymaga czegoś więcej niż zapewnienia miejsca dla serwerów dedykowanych. Liczy się zdolność do utrzymania kluczowych usług podczas awarii zasilania, problemów z łącznością, uszkodzeń urządzeń czy konieczności wykonania prac serwisowych. Standard ISO 22301 określa ramy zarządzania ciągłością działania, natomiast solidne Data Center realizuje je poprzez odpowiednią architekturę infrastruktury, procedury, umowy i regularne testy. Z tego artykułu dowiesz się, jak znaleźć sprawdzone centrum danych, w którym możesz bezpiecznie umieścić swoje serwery. Dowiesz się, jak oceniać je pod kątem ciągłości działania, na co zwrócić uwagę w SLA i umowie kolokacyjnej oraz jak powiązać redundancję infrastruktury z wymaganiami RTO i RPO.
Co znaczy „ciągłość działania” w kolokacji serwerów?
W kontekście kolokacji ciągłość działania oznacza zdolność do utrzymania usług IT na wymaganym poziomie mimo wystąpienia zakłóceń. Nie chodzi wyłącznie o to, aby serwer pozostał włączony. Istotne jest zachowanie na wysokim poziomie całego łańcucha zależności, a więc:
- zasilania,
- chłodzenia,
- sieci,
- urządzeń infrastruktury,
- systemów bezpieczeństwa,
- procedur obsługi awarii.
Dlatego ocena konkretnego Data Center nie powinna ograniczać się wyłącznie do deklarowanej dostępności. Trzeba sprawdzić, co stanie się w konkretnym scenariuszu awaryjnym. Czy awaria jednego toru zasilania powoduje przerwę? Czy urządzenia sieciowe mają niezależne ścieżki? Czy prace serwisowe można wykonać bez wyłączania infrastruktury? Jak szybko operator reaguje na problem? To tylko przykłady pytań, na które należy znaleźć odpowiedzi podczas oceny wybranego centrum danych.
W tym miejscu pojawiają się dwa podstawowe parametry ciągłości działania. RTO (Recovery Time Objective) określa maksymalny akceptowalny czas przywrócenia usługi, natomiast RPO (Recovery Point Objective) wskazuje, jak daleko wstecz może sięgać punkt odzyskanych danych. Ich wartości powinny wynikać z wymagań konkretnej organizacji i usług, a nie z samego faktu korzystania z kolokacji.
Standard ISO 22301 – wymagania wobec Data Center
ISO 22301 jest standardem dotyczącym systemu zarządzania ciągłością działania, a nie instrukcją budowy Data Center. Organizacja wykorzystująca tę normę identyfikuje zagrożenia, analizuje wpływ zakłóceń na działalność, określa wymagania dotyczące ciągłości i przygotowuje procedury reagowania oraz odtwarzania.
Ma to istotne znaczenie przy wyborze operatora kolokacyjnego. Samo zastosowanie zasilania N+1 czy dwóch niezależnych łączy nie oznacza automatycznie zgodności z ISO 22301. Ocena powinna obejmować zarówno infrastrukturę techniczną, jak i sposób zarządzania ryzykiem, procedury awaryjne, kompetencje personelu oraz testowanie przyjętych rozwiązań.
Aktualną opublikowaną wersją normy pozostaje ISO 22301:2019 wraz z późniejszą zmianą z 2024 roku. Jednocześnie trwają prace nad kolejnym wydaniem standardu. Przy audycie lub postępowaniu zakupowym warto więc sprawdzić dokładnie zakres certyfikacji operatora, a nie tylko sam fakt posiadania certyfikatu.
SLA, Tier i odporność infrastruktury IT w praktyce
SLA określa warunki świadczenia usługi między operatorem Data Center a Klientem. W przypadku kolokacji powinno obejmować nie tylko deklarowaną dostępność, lecz także parametry zasilania, łączności, czas reakcji na zgłoszenia, zasady prowadzenia prac serwisowych oraz sposób postępowania w przypadku awarii.
Drugim często przywoływanym pojęciem jest Tier. Klasyfikacja Uptime Institute opisuje poziom odporności infrastruktury obiektu, ale Tier nie jest odpowiednikiem ISO 22301. Norma dotycząca ciągłości działania obejmuje znacznie szerszy obszar zarządzania organizacją i ryzykiem.
Podobnie nie należy utożsamiać oznaczeń N+1 i 2N z konkretnym poziomem Tier. N+1 oznacza obecność dodatkowego elementu ponad minimalną liczbę potrzebną do obsługi obciążenia. W architekturze 2N funkcjonują dwa niezależne zestawy infrastruktury o wymaganej wydajności. Dopiero analiza całej architektury pozwala ocenić, jak zachowa się obiekt podczas awarii lub konserwacji.
Zapisy umowy kolokacji kluczowe dla ciągłości działania infrastruktury krytycznej
Dla ciągłości działania równie ważna, jak infrastruktura jest sama umowa. To ona określa, jakie parametry operator faktycznie zobowiązuje się zapewnić i jakie procedury obowiązują w sytuacji awaryjnej.
W dokumentacji dostarczonej przez Data Center warto zweryfikować przede wszystkim:
- gwarantowany poziom dostępności,
- parametry zasilania,
- zasady utrzymania łączy,
- czas reakcji i eskalacji zgłoszeń,
- warunki prowadzenia prac planowych.
Istotne są również zasady dostępu do infrastruktury, obsługi awarii poza standardowymi godzinami pracy oraz odpowiedzialności za poszczególne elementy środowiska. Umowa powinna też określać procedury na wypadek zakończenia współpracy. W przypadku infrastruktury krytycznej możliwość kontrolowanego przeniesienia serwerów i usług jest istotnym elementem odporności operacyjnej, podobnie jak możliwość ich utrzymania podczas standardowych prac serwisowych.
Zależności Data Center od zewnętrznych dostawców – energia, łączność i serwis
Nawet dobrze zaprojektowane Data Center pozostaje częścią większego ekosystemu. Dostęp do energii elektrycznej zależy od infrastruktury zewnętrznej, podobnie jak połączenia z operatorami telekomunikacyjnymi. Z tego powodu analiza ciągłości działania powinna obejmować również zależności znajdujące się poza samym obiektem.
W przypadku zasilania znaczenie ma nie tylko liczba UPS-ów czy agregatów, lecz także sposób doprowadzenia energii, rozdział obciążenia oraz możliwość utrzymania infrastruktury podczas awarii pojedynczego elementu. W przypadku połączeń sieciowych liczy się różnorodność tras i operatorów. Dwa połączenia prowadzące fizycznie tą samą trasą nie zapewniają takiej samej odporności jak rzeczywiście niezależne ścieżki.
Warto również sprawdzić model obsługi technicznej. Przy infrastrukturze krytycznej czas potrzebny na dotarcie do serwera, wymianę komponentu czy wykonanie czynności na miejscu może bezpośrednio wpływać na rzeczywisty czas odtworzenia usługi.
Architektura redundancji pod RTO/RPO – czym powinna się cechować?
Redundancja powinna wynikać z wymagań biznesowych, zamiast stanowić cel sam w sobie, co jest często popełnianym błędem. Jeżeli usługa wymaga bardzo krótkiego RTO, architektura musi umożliwiać szybkie przełączenie na sprawny element bez ręcznego odtwarzania całego środowiska. Przy wymagającym RPO kluczowe stają się natomiast mechanizmy replikacji i możliwość odzyskania danych z odpowiednio aktualnego punktu.
W zasilaniu konfiguracja N+1 zapewnia dodatkowy element, który może przejąć obciążenie w przypadku awarii jednego komponentu. 2N idzie dalej, ponieważ zakłada dwa niezależne zestawy infrastruktury o pełnej wymaganej wydajności. W praktyce trzeba jednak sprawdzić, czy niezależność obejmuje również rozdzielnie, trasy kablowe i punkty zasilania serwerów.
Podobnie należy analizować sieć. Dwa łącza od różnych operatorów są wartościowe wtedy, gdy zapewniają rzeczywiście różne drogi transmisji. Przy bardziej wymagających środowiskach, istotne stają się także redundancja urządzeń sieciowych, niezależne sesje routingu oraz automatyczne przełączanie ruchu.
Z kolei chłodzenie powinno być projektowane tak, aby awaria pojedynczego elementu nie powodowała utraty wymaganych warunków pracy. Ważna jest także możliwość wykonania konserwacji bez zatrzymywania systemów. W przeciwnym razie planowy serwis sam staje się źródłem ryzyka.
Przy usługach o bardzo wysokich wymaganiach dostępności sama redundancja lokalna może być niewystarczająca. Wtedy stosuje się redundancję geograficzną, czyli rozdzielenie infrastruktury pomiędzy niezależne lokalizacje. Replikacja danych i usług pozwala przygotować środowisko, które może przejąć obsługę w przypadku niedostępności podstawowego obiektu.
Testy DR/BCP prowadzone pod okiem zarządcy Data Center – na czym polegają?
Dokumentacja procedury awaryjnej nie potwierdza jeszcze skuteczności jej działania w krytycznych momentach. Dlatego istotnym elementem zarządzania ciągłością działania infrastruktury IT przy kolokacji powinny być testy BCP i DR. W ich trakcie sprawdza się zachowanie infrastruktury w kontrolowanych warunkach.
Test może obejmować między innymi takie scenariusze, jak:
- utrata podstawowego zasilania,
- niedostępność jednego toru sieciowego,
- awaria ważnego urządzenia infrastrukturalnego,
- przełączenie usług do zapasowej lokalizacji.
W testach powinien uczestniczyć operator Data Center. Pozwala to zweryfikować, czy rzeczywiste działania tej firmy odpowiadają zapisom SLA i procedurom zgodnie ze standardem ISO 22301. Po zakończeniu testu należy udokumentować wyniki, problemy i zaproponowane działania korygujące.
Jak zmierzyć realne RTO i RPO w kolokacji serwerów
RTO należy mierzyć od momentu wystąpienia zdarzenia powodującego niedostępność usługi do chwili jej rzeczywistego przywrócenia. Nie zawsze będzie to moment uruchomienia serwera. Jeżeli aplikacja wymaga uruchomienia baz danych, usług zależnych, konfiguracji sieci lub weryfikacji danych, wszystkie te etapy powinny zostać uwzględnione.
RPO również należy oceniać na poziomie konkretnej usługi. Sam fakt wykonywania kopii zapasowych nie oznacza jeszcze osiągnięcia określonego RPO. Liczy się rzeczywisty punkt, z którego dane można odzyskać i przywrócić do działania.
Dlatego podczas testów warto rejestrować czasy poszczególnych etapów: wykrycia awarii, podjęcia działania, przełączenia infrastruktury, uruchomienia usług oraz potwierdzenia ich poprawnego działania. Pozwala to porównać założenia zapisane w BCP i SLA z rzeczywistym przebiegiem zdarzenia.
Co powinna zawierać lista kontrolna audytu ISO 22301 dla Data Center
Przed wyborem operatora Data Center warto przeprowadzić własną ocenę jego infrastruktury IT i związanej z nim dokumentacji. Lista kontrolna powinna obejmować minimum następujące punkty.
- Zakres certyfikacji ISO 22301 i jego aktualność.
- Analizę ryzyka oraz procedury gwarantujące ciągłość działania w razie sytuacji krytycznej.
- Architekturę zasilania i sposób jej redundancji.
- Niezależność połączeń telekomunikacyjnych.
- Redundancję chłodzenia.
- Zakres oraz parametry SLA.
- Zasady prowadzenia prac planowych.
- Wyniki testów BCP/DR i sposób dokumentowania ich rezultatów.
- Zależności od dostawców zewnętrznych oraz procedury na wypadek ich niedostępności.
Taka lista pozwala uniknąć sytuacji, w której decyzja o wyborze opierać się będzie wyłącznie na deklarowanej dostępności lub klasie infrastruktury. W przypadku infrastruktury krytycznej należy ocenić cały proces: od wykrycia awarii, przez reakcję operatora, aż po przywrócenie usługi i danych.
Jakie Data Center do kolokacji wybrać pod standard ISO 22301?
Jeśli szukasz solidnego, polskiego centrum danych stosującego standard ISO 22301, już dziś skorzystaj z naszej oferty. Sprint Data Center wykorzystuje wszystkie rozwiązania istotne z punktu widzenia ciągłości działania. W naszym obiekcie mamy m.in. redundantne chłodzenie, zasilanie z niezależnych źródeł, całodobowy monitoring oraz ochronę fizyczną. Korzystamy przy tym z połączeń sieciowych od różnych operatorów oraz zapewniamy wsparcie techniczne przez całą dobę i 365 dni w roku. Do tego stosujemy wiele sprawdzonych procedur gwarantujących wysoki poziom ciągłości działania infrastruktury IT w razie wystąpienia różnych zagrożeń.
Jeśli więc interesuje Cię kolokacja serwerów i potrzebujesz solidnego partnera, skontaktuj się z nami już dziś. Możesz u nas również kupić wysokiej klasy serwery dedykowane pod różne systemy operacyjne – zapewniamy profesjonalne wsparcie w doborze ich konfiguracji.
FAQ – odpowiedzi na często zadawane pytania
1. Czy certyfikat ISO 22301 oznacza, że Data Center nie będzie miało awarii?
Nie. ISO 22301 dotyczy zarządzania ciągłością działania i przygotowania organizacji na zakłócenia. Nie eliminuje ryzyka awarii, lecz pomaga je identyfikować i przygotować sposób reagowania.
2. Czy ISO 22301 jest tym samym co Tier III lub Tier IV?
Nie. ISO 22301 dotyczy systemu zarządzania ciągłością działania, natomiast klasyfikacja Tier odnosi się do konkretnych cech infrastruktury IT w Data Center.
3. Czy operator kolokacji może zagwarantować wymagane RTO?
Tylko w zakresie zależnym od jego usług i zapisów umowy. RTO całej aplikacji obejmuje również systemy, dane i procedury znajdujące się po stronie klienta Data Center.
4. Jak często należy testować procedury BCP i DR?
Częstotliwość powinna wynikać z analizy ryzyka, wymagań organizacji i przyjętych procedur. Istotne jest regularne sprawdzanie scenariuszy, które mogą realnie zagrozić ciągłości działania usług.