usługi

Jak zapewnić bezpieczeństwo danych w chmurze dzięki regionom i subregionom

Czy jesteś przygotowany(-a) na awarię, która unieruchomi Twoje centrum danych? A na to, że z dnia na dzień ruch w Twoim serwisie wzrośnie kilkukrotnie? To właśnie w takich sytuacjach przydają się regiony w chmurze, czyli odseparowane geograficznie centra danych. Dowiedz się, w jaki sposób zadbać o zapasowe środowisko lub usługi online wysokiej dostępności w oparciu o rozproszenie geograficzne.

Choć chmura wydaje się czymś wirtualnym, to w rzeczywistości posiada normalne geograficzne lokalizacje. To rozproszona sieć serwerów, z których każdy znajduje się fizycznie w budynku usługodawcy.

Dostawcy chmurowi dbają o wysokie bezpieczeństwo usług i zapewniają szereg zabezpieczeń na poziomie lokalizacji, sprzętu i oprogramowania, dlatego chmura jest znacznie lepiej zabezpieczona od lokalnej infrastruktury.

Jednak żadna technologia nie zapewnia 100% odporności na awarie, np. spowodowane katastrofą czy cyberatakiem. Dlatego tworząc środowisko IT, warto zaprojektować je w oparciu o regiony, aby w pełni korzystać z zalet chmury.

Regiony i niezależność geograficzna

Region jest to odseparowana geograficznie część infrastruktury, w której znajdują się urządzenia chmury publicznej i na który składa się najczęściej jedno lub więcej centrów danych. Najlepiej, gdy centra danych nie są położone w tej samej sferze sejsmicznej czy zalewowej, aby dana katastrofa nie zniszczyła kilku ośrodków.

Każdy region tworzą inne urządzenia i połączenia sieciowe, niepowiązane ze sobą. Dzięki temu awaria jednego z regionów nie wpływa na drugi. W Oktawave zapewniamy dwa regiony dostępności zbudowane w oparciu o trzy centra danych (dwa w Warszawie, jedno w Krakowie).

Bardzo istotne jest, aby operatorzy telekomunikacyjni, którzy zapewniają łączność do oddzielnych centrów danych, również byli różni. Jeśli jeden operator będzie obsługiwał kilka centrów danych i wystąpi u niego problem, to istnieje ryzyko, że wpłynie to na więcej niż jeden region.

Korzyści z regionu odczujemy więc wówczas, jeśli będzie on całkowicie odizolowanym i niezależnym elementem ekosystemu.

Subregiony i niezależność sprzętowa

Warto pamiętać, że nie zawsze awaria musi dotyczyć całego ośrodka danych, a jedynie poszczególnych jego komponentów. Dlatego też region może składać się z kilku subregionów (osobnych szaf, pomieszczeń lub budynków w tej samej lokalizacji), z których każdy stanowi oddzielną strefę dostępności. Na przykład AWS ma jedną lokalizację podzieloną na trzy strefy dostępności (Avaliability Zone).

Z kolei w każdym regionie i każdym centrum danych Oktawave, dysponujemy jednym budynkiem, ale mamy wiele różnych "szaf", w których znajdują się niezależne i kompletne stosy urządzeń. Dzięki temu potrafimy błyskawiczne skierować ruch do sprawnego urządzenia, gdy jakaś część centrum danych ulegnie awarii. Mamy pełną świadomość, że projektując infrastrukturę, warto wykorzystać subregiony, aby zapewnić sobie niezależność sprzętową.

Jak wykorzystać regiony i subregiony?

Podejście do regionów oraz subregionów i ich wykorzystania może być różne. Wyróżnia się trzy główne modele wdrożenia:

  • Active-Active

Możemy uruchamiać aplikacje w dwóch regionach jednocześnie, online. Wtedy mówimy o środowisku wysokiej dostępności (High Availability) rozdzielonym na dwa ośrodki danych. System dynamicznego sterowania ruchem (np. Oktawave Traffic Manager) zapewnia przełączanie pomiędzy ośrodkami rozproszonymi geograficznie, gdy jeden z nich ulegnie awarii.

Dzięki takiemu rozwiązaniu zyskujemy nie tylko bezpieczeństwo, ale również wzrost wydajności i skalowalności. Każdy ośrodek można oddzielnie skalować, co może mieć szczególne znaczenie w sytuacji, w której kierujemy użytkowników do bliższego ośrodka przetwarzania danych. Dzięki takiemu zaprojektowaniu usług skracamy czas dostępu i poprawiamy satysfakcję naszych klientów.

  • Active-Backup

Jednak nie zawsze aplikacja musi działać non stop online z dwóch regionów. Drugi region możemy wykorzystać jako centrum zapasowego przetwarzania danych (Disaster Recovery Center), w którym przechowujemy kopię zapasową infrastruktury. DRC przejmuje rolę podstawowego ośrodka danych w razie klęski żywiołowej czy cyberataku. Dzięki narzędziom do automatyzacji, DRC może zostać włączone bez zwłoki i samodzielnie przejąć ruch.

Poważne awarie w środowisku chmurowym są niezwykle rzadkie, ale gdy już się zdarzają potrafią być dotkliwe w skutkach. Wówczas nawet kopia zapasowa systemu (backup) nie uratuje sytuacji, gdyż nie będzie na czym jej uruchomić. Zapasowa lokalizacja zapewnia firmie możliwość kontynuowania działalności, dopóki nie stanie się bezpieczne wznowienie pracy w jej zwykłej lokalizacji lub nowej stałej lokalizacji.

  • Active-Standby

Drugi region (lub subregion) może posłużyć też do przechowywania części infrastruktury w trybie pasywnym, tzw. Hot Standby. Oznacza to, że przetrzymujemy tam usługi w stanie wygaszenia lub działania na minimalnym poziomie. W razie awarii możesz z nich szybko podnieść aplikację.

Rzadko mamy do czynienia z sytuacją, kiedy zostaje unieruchomiony cały region, zazwyczaj awarii ulegają poszczególne elementy infrastruktury. Dzięki przechowywaniu backupu w subregionie, nie musimy się przełączać na zapasowe data center. Taka infrastruktura wymaga oczywiście odpowiedniej higieny pracy. Projektując takie pasywne środowisko, musimy zadbać o cykliczne testy, regularnie sprawdzać czy jest gotowe do przyjęcia ruchu.

Czytaj również: Dlaczego wozimy ze sobą koło zapasowe, a nie korzystamy z Disaster Recovery Center? >>

Który model wdrożenia wybrać?

Jakie podejście będzie najlepsze dla Twojego biznesu? O tym najlepiej zdecydować, biorąc pod uwagę dwa kryteria: wskaźnik punktu odzyskiwania (RPO) i wskaźnik docelowego czasu odzyskiwania (RTO). RPO (Recovery Point Objective) określa na jaki wolumen utraty danych sobie pozwalamy. Z kolei RTO (Recovery Time Objective) określa na ile czasu akceptujemy niedostępność usług.

Jeśli jeden ośrodek przestanie być aktywny, a synchronizacja odbywa się co 4h i postawienie nowego środowiska zajmie kolejne 4h, to oznacza, że utracimy dane z 8h pracy. Pytanie, czy możemy sobie pozwolić na taki przestój? Większość organizacji nie może zaakceptować tak długiego unieruchomienia, dlatego powinny zadbać o stworzenie odpowiedniego środowiska IT z wykorzystaniem rozproszonych geograficznie regionów.

Regiony i subregiony są ważnym elementem Business Continuity Plan (Planu Ciągłości Działania), czyli planu wznowienia działania po katastrofie. Umożliwią nie tylko stworzenie systemu wysokiej dostępności (HA), ale i centrum awaryjnego (DRC). Taka architektura pozwoli nam błyskawicznie przełączyć ruch do działających serwerów, nawet jeśli całe środowisko IT padnie.

I choć sytuacja to może nigdy nie nastąpić w historii Twojej firmy, to koszty utrzymywania takiej zapasowej architektury są nieporównywalnie niższe niż ewentualne koszty usuwania skutków katastrofy i utraty danych. Regiony i subregiony dają nie tylko bezcenny spokój, ale zwiększają wydajność i skalowalność biznesu, pozwalając na jego nieograniczony rozwój.

Jeśli chcesz dowiedzieć się więcej o korzyściach, jakie stwarzają regiony i subregiony, skontaktuj się z nami. Oktawave zapewnia zespół o multicloudowych kompetencjach, który może zaprojektować i wdrożyć Cloud Disaster Recovery Plan niezależnie od tego, z jakiej chmury korzystasz.

Wykorzystując własną chmurę lub partnerską (AWS, Google Cloud, Azure), pomożemy Ci zbudować środowisko wysokiej dostępności, zapewniające sprawne zarządzanie ruchem i nieprzerwane działanie.