Niezawodna sieć jako podstawa bezpieczeństwa opartego na Disaster Recovery

Obecnie coraz więcej klientów oczekuje dostępu do usług IT przez całą dobę. To nakłada na działy IT nowe obowiązki. Jednym z nich jest zapewnienie nieprzerwanego działania aplikacji biznesowych. Wymóg ten musi być spełniony, pomimo potencjalnych awarii technicznych czy zdarzeń losowych. Niektóre z nich mogą doprowadzić do wyłączenia podstawowego centrum danych. Warto wówczas mieć możliwość przełączenia się do ośrodka Disaster Recovery połączonego z głównym za pomocą szybkiej i niezawodnej sieci telekomunikacyjnej. Jak to zrobić?

Jednym ze sposobów jest budowa lub wynajęcie zapasowego ośrodka przetwarzania danych. Przejmie on wówczas świadczenie usług IT. Aby jednak nastąpiło to niezauważalnie dla użytkowników aplikacji biznesowych, podstawowe i zapasowe centrum danych musi być połączone szybką, niezawodną i dedykowaną siecią telekomunikacyjną. Zapewnienie ciągłości działania systemów IT i odtwarzanie ich po awarii wiąże się nierozerwalnie z transmisją danych.

Sieć, która połączy dwa centra danych

Przy budowie systemów, które zagwarantują wykorzystanie rezerwowego ośrodka do celów Disaster Recovery¹ – odtwarzania systemów IT po awarii – należy uwzględnić potrzeby firmy oraz możliwości i ograniczenia stosowanej technologii.

Jeśli biznes wymaga dostępu do danych i ciągłej dostępności usług, warto zbudować środowisko z replikacją synchroniczną i klastrem geograficznym. Transakcje w takim systemie są zatwierdzane jednocześnie w bazach danych w obu ośrodkach. Oba ośrodki muszą być połączone siecią SAN i WAN. W ten sposób można spełnić wymogi przełączenia przetwarzania pomiędzy centrami danych bez widocznej dla użytkowników przerwy. Można też równoważyć obciążenia w przypadku zwiększonej liczby transakcji. Do każdego z ośrodków mogą być doprowadzone dwa niezależne łącza – np. oparte o światłowody lub radiolinie.

Jeśli wymagania nie są tak rygorystyczne, można wykorzystać mechanizm replikacji maszyn wirtualnych do zapasowego ośrodka przetwarzania danych. Po awarii wystarczy uruchomić maszyny wirtualne w rezerwowym centrum danych i w ten sposób zapewnić ciągłość działania. Przełączenie do zapasowego ośrodka może odbyć się też automatycznie. Przy najmniejszych wymaganiach wystarczy asynchroniczna replikacja do zapasowego ośrodka np. przez sieć VPN opartą o MPLS realizowane przez operatora. W przypadku większych centrów danych niezbędne będzie wprowadzenie reguł QoS (Quality-of-Service), aby zapewnić nieprzerwany ruch związany z pracą krytycznych aplikacji.

Zapewnienie wymiany danych pomiędzy aplikacjami

Dzisiejsze aplikacje mocno polegają na komunikacji między maszynami wirtualnymi. Aby ułatwić tę wymianę danych, podczas projektowania sieci łączącej centra przetwarzania danych można przyjąć dwie strategie. Po pierwsze, sieć w ośrodku rezerwowym może mieć tę samą adresację prywatną co w centrum podstawowym. Utrzymanie tej samej puli adresacji po obu stronach staje się atrakcyjną opcją, jeśli można rozciągnąć podsieć w warstwie drugiej ² pomiędzy lokalizacjami. Wówczas proces odtworzenia odbywać się będzie szybciej i sprawniej. Po awarii wystarczy uruchomić tę samą maszynę wirtualną w drugim ośrodku przy tych samych ustawieniach IP. Sieć wykorzystująca połączenie w warstwie drugiej automatycznie zadba o kierowanie ruchu do właściwego ośrodka. Wadą takiego rozwiązania jest podatność na problemy sieciowe spowodowane ogromną liczbą pakietów typu broadcast, których nie można izolować. Niekiedy rozciągniętej podsieci nie można też zastosować ze względu na ograniczenia dostawcy środowiska, zwłaszcza oferujących usługi cloud computing.

Alternatywą dla rozszerzenia sieci na oba ośrodki jest przenoszenie tej samej adresacji między ośrodkami. W tym modelu wszystkie maszyny wirtualne zachowują własne adresy IP, ale w momencie przełączenia zmieniają się reguły routingu pomiędzy ośrodkami. Wymaga to skoordynowania działań, w których – wraz z uruchomieniem maszyn wirtualnych – następują zmiany we wszystkich routerach, które są związane z komunikacją do i z danej podsieci. Zmiany te można zautomatyzować za pomocą sieci definiowanej programowo SDN (Software-Defined-Network).

Ostatni model zakłada budowę środowiska w ten sposób, aby – w momencie przełączenia do drugiego ośrodka – zmieniły się wpisy w DNS lub adresy IP maszyn wirtualnych. Zmiana wpisów w DNS jest stosunkowo prosta w realizacji, ale uzależnia pracę całego środowiska od poprawnego działania serwera tej usługi. Z kolei zmiana adresów IP w maszynach wirtualnych jest najbardziej wymagająca. Proces przełączenia wymaga dobrego zaplanowania. Dzięki temu nie są jednak potrzebne żadne zmiany w sieci.

Pamiętajmy

Odpowiednio dobrana usługa telekomunikacyjna i jej parametry umożliwiają zapewnienie ciągłości działania aplikacji biznesowych zarówno dla klientów wewnętrznych, jak i zewnętrznych. Każdy przestój w dzisiejszym świecie cyfrowej transformacji przedsiębiorstw generuje coraz większe dla nich straty.

¹Procedury Disaster Recovery to procesy, polityki i procedury związane z wznowieniem lub utrzymywaniem infrastruktury teleinformatycznej, krytycznej dla organizacji, po wystąpieniu katastrofy naturalnej lub wywołanej przez człowieka. W praktyce mówi się o tym najczęściej w kontekście dużych awarii, takich jak te dotyczące całego centrum danych. Aby im zapobiec, buduje się zapasowe centrum danych, które w razie awarii przejmuje rolę podstawowego centrum danych. Każde z nich połączone powinno być wydajną siecią telekomunikacyjną. Disaster Recovery jest częścią procesu planowania ciągłości działania BCP (Business Continuity Planning).

²Warstwa druga sieci to tzw. warstwa łącza danych. Przechodzą przez nią wszystkie dane, które w sieci lokalnej są przesyłane przez urządzenia w warstwie fizycznej. W praktyce oznacza to, że pomiędzy lokalizacjami zostaje zestawiony tunel tworzący most, przez który można przesłać każdą informację warstwy łącza danych. Urządzenia połączone tunelem w warstwie drugiej łączą się tak samo, jakby były dołączone do tej samej sieci lokalnej.