Artykuł sponsorowany

Środowisko zapasowe w chmurze AWS – jak i za ile

Redakcja Antyweb
1

Część organizacji i firm potrzebuje zapewnienia ciągłości działania swoich procesów w sytuacjach nieszczęśliwych zdarzeń – wywołanych czy to przez naturę, czy przez człowieka (disaster recovery – DR). W tym celu prowadzone są analizy ryzyk i przygotowywane plany ciągłości działania. Temat ten w ostatnim czasie zyskał na znaczeniu i dlatego postanowiliśmy zwrócić Waszą uwagę na chmurę publiczną AWS jako lokalizację dla środowiska zapasowego.

Autorem wpisu jest Piotr Boetzel, AWS Partner Solutions Architect

Warto spróbować w chmurze

Z tej perspektywy chmura publiczna ma szereg zalet. Po pierwsze, płaci się tylko za używane zasoby bez konieczności rezerwacji. W praktyce oznacza to, że w sytuacji normalnego działania systemów przeważnie ponosi się koszty jedynie przechowywania danych replikowanych do chmury. Przy czym sam transfer danych do chmury jest darmowy – chyba że zdecydujemy się na połączenie VPN lub bezpośrednie połączenie fizyczne od jednego z regionów.

Kolejny i nieco powiązany z tym aspekt to możliwość przeprowadzenia testów odtwarzania po awarii. Takie ćwiczenie zajmuje zwykle jeden do kilku dni, podczas których uruchamiane są serwery i aplikacje w lokalizacji zapasowej, a następnie wyłączane. W przypadku chmury publicznej zapłacimy tylko za faktyczny czas działania maszyn i usług. Dodatkowo mamy możliwość przeprowadzanie takiego testu bez wpływu na działanie aplikacji produkcyjnych – wszystko może odbyć się w odseparowanym środowisku.

Dodatkowo dla zespołów nieposiadających jeszcze doświadczenia z chmurą publiczną jest to okazja do poznania tej technologii i zdobycia doświadczenia w bezpiecznych warunkach. Docelowo potrzebujemy uzyskać pewne i stabilne środowisko zapasowe, ale na etap jego budowy można wykorzystać do lepszego poznania usług AWS i zdobycia praktycznego doświadczenia. Przez pracowników może to być postrzegane jako szansa na rozwój i zdobycie nowych umiejętności a przez firmę jako zwiększenie zadowolenia pracowników i utrzymania ich w dłuższej perspektywie.

W chmurze Amazon Web Services (AWS) mamy możliwość tworzenia infrastuktury w sposób automatyczny – za pomocą wcześniej zdefiniowanych skryptów i wzorców systemów. Zapewnia to szybkie uruchomienie nawet bardzo złożonego środowiska. Dodatkowo procedura jest powatarzalna i znacznie redukuje ryzyko wystąpienia błędów ludzkich przy konfiguracji. Co w sytuacji awarii i działania pod presją czasu jest dodatkową korzyścią.

Projektując środowisko zapasowe niezbędne jest przekonanie, że systemy powierzamy w „pewne ręce”. Dla AWS bezpieczeństwo i prywatność powierzonych przez klientów danych mają najwyższy priorytet. Firma przechodzi cyklicznie audyty i uzyskuje certyfikacje w tym obszarze. Raporty z audytów oraz certyfikaty są publikowane i dostępne dla klientów, aby mogli sami się z nimi zapoznać i przedstawić audytorom lub regulatorom.

Kategorie rozwiązań DR

W AWS przyjmujemy umownie 3 kategorie rozwiązań DR ze względu na szybkość przywracania aplikacji i powiązany koszt.

  • Pilot light – replikacja danych – zapas gotowy, ale wyłączony
  • Warm standby – pilot w zapasie – ciepły zapas – rezerwa aktywna, ale o ograniczonej wydajności
  • Hot-standby – gorący zapas – środowisko gotowe na produkcyjny ruch, ale nie obsługujące go w normalnych okolicznościach.

W graficznym ujęciu przedstawia to rys. 1. Dla porównania umieszczone jest na nim też rozwiązanie z wykorzystaniem kopii zapasowych (backup & restore) mimo, że nie należy stricte do kategorii DR.

Rysunek 1. Kategorie rozwiązań DR ze względu na czas przywrócenia działania i koszt. RTO - Recovery Time Objective, RPO - Recovery Point Objective.

W efekcie analizy ryzyka, potrzeb biznesowych i budżetu następuje wybór jednej z powyższych kategorii. Następnym krokiem jest zaprojektowanie architektury rozwiązania z wykorzystaniem konkretnych usług.

Usługi pomocne przy budowie rozwiązania DR

Środowisko awaryjne zawsze będzie zbudowane z wykorzystaniem typowych usług (przechowywanie danych, dyski i maszyny wirtualne, usługi sieciowe) oraz specjalistycznych. Amazon Web Services udostępnia między innymi następujące mechanizmy:

- AWS Storage Gateway – to usługa umożliwiająca podłączenie chmurowych zasobów dyskowych do systemów użytkowanych lokalnie. Element „gateway” umieszczony w lokalnym środowisku udostępnia np. lokalnym serwerom dyski za pomocą protokołu iSCSI, a dane replikowane są do usługi chmurowej. Wspierane są także protokoły plikowe NFS i SMB. Możliwe jest wykorzystanie tej usługi jako wirtualnej biblioteki taśmowej na potrzeby systemu do wykonywania kopii zapasowych. W ten sposób można potraktować chmurę jako dodatkowy zewnętrzny magazyn danych (off-site storage).

Rysunek 2. Diagram ilustrujący możliwości AWS Storage Gateway. S3 - Simple Storage Service – usługa przechowywania danych w formie obiektowej.

- AWS Elastic Disaster Recovery – to usługa, która umożliwia uruchomienie środowiska zapasowego w sytuacji awarii na bazie najświeższych danych. Opiera się na replikacji danych na bieżąco do dysków w chmurze AWS. Gdy zajdzie konieczność uruchomienia środowiska awaryjnego, to uruchamiane są maszyny wirtualne z dyskami, na których znajdują się aktualne dane.

Rysunek 3 Architektura rozwiązania AWS Elastic Disaster Recovery Service (DRS).

- AWS CloudFormation – to usługa, dzięki której można zuatomatyzować tworzenie całego środowiska dla aplikacji w chmurze AWS – Infrastructure as Code. Nawet bardzo złożone środowisko awaryjne może powstać na żądanie wg wcześniej przygotowanej konfiguracji.

- AWS DataSync – to usługa przesyłu danych online, która upraszcza, automatyzuje i przyspiesza przenoszenie danych z tradycyjnych serwerowni do chmury AWS, a także pomiędzy usługami w ramach AWS. DataSync może kopiować dane pomiędzy serwerami plików wykorzystującymi SMB lub NFS, innymi magazynami danych obiektowych, a także usługami AWS Snowcone, S3, EFS oraz Amazon FSx for Windows.

To tylko kilka wybranych przykładów usług najczęściej wykorzystywanych. W sytuacji gdy dane środowisko lub aplikacja mają szczególne wymagania bądź ograniczenia docelowe rozwiązanie projektują architekci z wykorzystaniem większej liczby technologii.

Ransomware i czynnik ludzki

Jedną z przyczyn możliwych katastrof, wymagających przełączenia na środowisko zapasowe jest czynnik ludzki. A w tej kategorii mieszczą się zagrożenia typu ransomware i wymagają one specjalnego podejścia. Przy projektowaniu rozwiązania trzeba koniecznie uwzględnić fakt, że kopie zapasowe albo replikowane dyski mogą być zaszyfrowane, a co za tym idzie, bezużyteczne do uruchomienia środowiska awaryjnego. Podobna sytuacja będzie miała miejsce, gdy użytkownik zmodyfikuje dane tak, że staną się błędne. Użytkownik może być autoryzowany bądź nie i może działać w złej woli lub po prostu się pomylić. Reakcję na tego typu zagrożenia trzeba zaplanować w specjalny sposób i z pomocą mogą przyjść następujące mechanizmy z portfolio AWS:

  • snapshot dysku – zapisanie zawartości dysku do pliku i przechowanie do jako obiektu, z którego można dysk odtworzyć,
  • wersjonowanie obiektów (S3 versioning) – automatyczne zachowywanie poprzednich wersji obiektu w momencie, gdy wprowadzane są zmiany, dające możliwość odtworzenia obiektu po skasowaniu,
  • odtworzenie bazy danych „point in time” – w usłudze zarządzanych baz danych (Amazon Relational Database Service) przy domyślnych ustawieniach możliwe jest przywrócenie instancji do danego momentu w czasie (z dokładnością do 5 minut),
  • „zapieczętowanie” obiektu (S3 Object Lock) – zablokowanie możliwości edycji i usunięcia obiektu,
  • „zapieczętowanie” archiwum (Glacier Valut Lock) – można użyć tego mechanizmu m.in. do zablokowania możliwości edycji i usunięcia archiwum.

W przypadku ryzyk związanych z działalnością człowieka i ransomware także konieczna jest analiza i zaprojektowanie docelowego rozwiązania z gotowych elementów. Lub włączenie odpowiednich mechanizmów na platformie AWS.

Szacunkowe koszty

Dla oszacowania kosztów rozwiązania DR w AWS przyjmijmy 2 scenariusze.

Scenariusz A

Środowisko w lokalnej serwerowni składa się 20 serwerów (4 rdzenie, 16 GB RAM każdy) i 1000 TB przestrzeni dyskowej w sumie. Skonfigurowane jest przesyłanie raz dziennie obrazów dysków (snapshot) do chmury AWS do Irlandii. Przechowywane jest 5 ostatnich obrazów. Co miesiąc odtwarzane jest (przesyłane z chmury do serwerowni lokalnej) 200 GB danych. Koszt miesięczny takiego rozwiązania to 140 USD netto. Szczegółowe wyliczenia z założeniami [1].

Testowe uruchomienie tych 20 serwerów (instancja m6a.xlarge, system Linux) z dyskami i usługami sieciowymi na 8 godzin wiąże się z kosztem 33 USD netto. Szczegółowe wyliczenia z założeniami [2].

Scenariusz B

Środowisko w lokalnej serwerowni składa się ze 100 serwerów, 200 dysków o łącznej wielkości 30 TB i zmiennością danych 3.3% dziennie. Skonfigurowane jest przechowywanie snapshotów dysków z ostatnich 7 dni. Wykorzystywana jest replikacja na bieżąco za pomocą usługi AWS Elastic Disaster Recovery do AWS do Irlandii. Koszt miesięczny takiej konfiguracji to w przybliżeniu 6400 USD netto.

Przykładowe uruchomienie 100 serwerów w AWS na 8 godzin na potrzeby testów DR to koszt około 120 USD netto. Szczegółowe wyliczenia z założeniami [3].

Z tych przykładów widać jasno, że koszty są znacznie mniejsze niż w przypadku konieczności utrzymywania serwerowni zapasowej, w której trzeba płacić za przestrzeń oraz zakup odpowiedniego sprzętu. Dodatkowo AWS zapewnia elastyczność używanych zasobów – w każdej chwili można zmniejszyć bądź zwiększyć liczbę replikowanych dysków, ilość danych czy liczbę maszyn wirtualnych. Wygodna i unikalna jest także możliwość wykonania niewielkim kosztem w testów odtworzenia w dowolnej chwili.

Podsumowanie

Chmura publiczna AWS ma szereg zalet jako rozwiązanie DR. Przede wszystkim elastyczność, która przekłada się na niskie koszty w sytuacji normalnej pracy środowiska podstawowego, a jednocześnie możliwość wykonywania cyklicznych kosztów przełączania. Dodatkowo dostępne jest szereg gotowych usług, które właśnie do tego zostały zaprojektowane (jak Elastic Disaster Recovery) oraz generycznych (jak Storage Gaterway czy Data Sync), których można użyć jak „klocków” do budowy rozwiązania na konkretne potrzeby.

W przypadku, gdy aplikacje mają szczególne potrzeby w kwestii licencjonowania czy umiejscowienia danych, to wymagane jest specjalne podejścia, ale istnieją narzędzia mogące pomóc w takiej sytuacji.

Należy pamiętać też o tym, że AWS posiada szereg partnerów na polskim rynku, którzy mają kompetencje i doświadczenie w migracji do chmury i uruchamianiu środowisk zapasowych. Szereg firm w Polsce przeniosła już swoje systemy do chmury AWS. Są wśród nich reprezentanci różnych branż: brainly (szkolenia), domiporta (nieruchomości) czy onet.pl (grupa medialna) oraz LOT. Aby przeczytać o tym więcej kilknij w linki poniżej artykułu.

Referencje:

  1. https://calculator.aws/#/estimate?id=949a5ed52f577ca5cfa76620b539f7af2d3155dd
  2. https://calculator.aws/#/estimate?id=829f7b8c0e3fc1000adf9fae8f31430cc8530e9a
  3. https://aws.amazon.com/disaster-recovery/pricing/?nc=sn&loc=2
  4. https://aws.amazon.com/solutions/case-studies/brainly-case-study/
  5. https://aws.amazon.com/partners/success/domiporta-unity-group/
  6. https://www.youtube.com/watch?v=-In222w4B_Y
  7. https://www.aboutamazon.pl/wiadomosci/technologie/polski-biznes-w-chmurze

-

Wpis powstał przy współpracy z AWS

Hej, jesteśmy na Google News - Obserwuj to, co ważne w techu