Skalowalne, ekonomiczne odzyskiwanie po awarii w chmurze

W przypadku awarii ciągłość biznesowa może wymagać czegoś więcej niż tylko okresowych kopii zapasowych danych.

Pełne odzyskiwanie, które spełnia cele biznesowe dotyczące czasu odzyskiwania (RTO), musi również obejmować infrastrukturę, systemy operacyjne, aplikacje i konfiguracje używane do przetwarzania ich danych. 

Rosnące zagrożenia ze strony oprogramowania ransomware podkreślają potrzebę pełnego odzyskania danych do określonego momentu. W przypadku firm dotkniętych atakiem ransomware przywrócenie danych ze starej, być może ręcznej kopii zapasowej, nie będzie wystarczające.

Wcześniej firmy decydowały się na utworzenie oddzielnej, fizycznej infrastruktury odzyskiwania po awarii (DR). Jednak klienci zgłaszali, że może to ograniczać zarówno przestrzeń, jak i koszty, co wiąże się z nakładami kapitałowymi na sprzęt i urządzenia, które pozostają bezczynne, dopóki nie zostaną użyte. Infrastruktura wiąże się również z dodatkowymi kosztami związanymi z regularnymi przeglądami i konserwacją, zazwyczaj ręczną, aby upewnić się, że w razie potrzeby jest gotowa i zdolna do obsługi bieżącego obciążenia biznesowego, które mogło znacznie wzrosnąć od czasu początkowego udostępnienia. To również sprawia, że testowanie jest trudne i kosztowne.

W listopadzie AWS ogłosił wprowadzenie AWS Elastic Disaster Recovery (DRS), w pełni skalowalnej, ekonomicznej usługi odzyskiwania po awarii dla serwerów fizycznych, wirtualnych i chmurowych, opartej na CloudEndure Disaster Recovery.  DRS umożliwia klientom korzystanie z usługi AWS jako elastycznej lokalizacji odzyskiwania bez konieczności inwestowania w lokalną infrastrukturę DR, która pozostaje bezczynna do czasu, gdy jest potrzebna. Po włączeniu DRS utrzymuje stałą postawę replikacji systemów operacyjnych, aplikacji i baz danych. Pomaga to firmom osiągnąć cele punktów odzyskiwania (RPO- recovery point objectives) w sekundach i RTO (recovery time objectives) na poziomie minut po wystąpieniu awarii. Na przykład w przypadku ataków ransomware DRS umożliwia również przywrócenie do poprzedniego punktu w czasie.

DRS zapewnia odzyskiwanie, które skaluje się zgodnie z potrzebami, aby dopasować obecną konfigurację i nie wymaga żadnych czasochłonnych ręcznych procesów, aby utrzymać tę gotowość. Oferuje również możliwość wykonywania przywróceń testowych. Podobnie jak ważne jest, aby przetestować przywracanie danych z kopii zapasowych, tak sama ważna jest możliwość przeprowadzania ćwiczeń przywracania w opłacalny sposób bez wpływu na trwającą replikację lub działania użytkowników może dać pewność, że w razie potrzeby spełnione zostaną cele i oczekiwania klientów.

Elastic Disaster Recovery w użyciu

Po włączeniu DRS stale replikuje blokowe woluminy pamięci masowej z serwerów fizycznych, wirtualnych lub w chmurze, umożliwiając obsługę biznesowych RPO mierzonych w sekundach. Odzyskiwanie obejmuje aplikacje działające w infrastrukturze fizycznej, VMware vSphere, Microsoft Hyper-V oraz infrastrukturę chmury do AWS. Możesz odzyskać wszystkie swoje aplikacje i bazy danych, które działają w obsługiwanych systemach operacyjnych Windows i Linux, a DRS organizuje proces odzyskiwania dla Twoich serwerów w AWS, aby obsługiwać RTO mierzone w minutach.

Używając agenta, który instalujesz na swoich serwerach, DRS bezpiecznie replikuje dane do lokalizacji zapasowej w wybranym regionie na Twoim koncie AWS. Zmniejsza to koszty, korzystając z niedrogiej pamięci masowej i minimalnych zasobów obliczeniowych. W konsoli DRS możesz w razie potrzeby odzyskać instancje Amazon Elastic Compute Cloud (Amazon EC2) w innym regionie AWS. Dzięki automatycznym procedurom replikacji i odzyskiwania DRS możesz skonfigurować, przetestować i obsługiwać funkcje odzyskiwania po awarii za pomocą jednego procesu, bez konieczności posiadania specjalistycznych umiejętności.

DRS zapewnia elastyczność w zakresie płacenia za godzinę, bez konieczności zawierania długoterminowej umowy lub określonej liczby serwerów, co jest zaletą w porównaniu z rozwiązaniami typu on-premise lub centrum danych do odzyskiwania danych. DRS nalicza opłaty godzinowe, na zasadzie „pay-as-you-go”. Szczegółowe informacje na temat cen można znaleźć na stronie produktu.

Zapoznanie z Elastic Disaster Recovery

Aby skonfigurować odzyskiwanie po awarii dla naszych zasobów, najpierw musimy skonfigurować domyślne ustawienia replikacji. Jak wspomnieliśmy wcześniej, DRS może być używany z serwerami fizycznymi, wirtualnymi i chmurowymi. W tym poście zamierzamy użyć kolekcji instancji EC2 jako naszych serwerów źródłowych do odzyskiwania po awarii.

Ze strony głównej konsoli DRS, pokazanej wcześniej, wybranie opcji Set default replication setting powoduje przejście do kreatora krótkiej inicjalizacji. W kreatorze najpierw musimy wybrać podsieć Amazon Virtual Private Cloud (VPC), która będzie używana do fazy staging. Ta podsieć nie musi znajdować się w tej samej sieci VPC, co nasze zasoby, ale musimy wybrać taką, która nie jest prywatna ani zablokowana dla świata. Poniżej wybraliśmy podsieć z naszego domyślnego VPC w naszym regionie. Możemy również zmienić typ instancji używanej dla instancji replikacji. W tym przypadku zdecydowaliśmy się zachować sugerowaną wartość domyślną i kliknęliśmy Next, aby kontynuować.

Na kolejnych dwóch stronach również zostawiliśmy niezmienione ustawienia domyślne. W Volumes and security groups kreator sugeruje, abyśmy używali uniwersalnego typu SSD (gp3) Amazon Elastic Block Store (EBS) i korzystali z grupy bezpieczeństwa dostarczanej przez DRS. Na stronie Additional settings page możemy wybrać użycie prywatnego adresu IP do replikacji danych zamiast routingu przez publiczny Internet i ustawić okres przechowywania snapshot’ów, który domyślnie wynosi siedem dni. Klikając przycisk Next po raz ostatni, przechodzimy do strony Review and create kreatora. Wybranie opcji Create default kończy proces konfigurowania naszych domyślnych ustawień replikacji.

Po sfinalizowaniu ustawień replikacji (możemy je później edytować, z menu Actions na stronie konsoli Source servers), nadszedł czas na skonfigurowanie naszych serwerów. Mamy uruchomioną flotę testową w EC2, która obejmuje dwie instancje Windows Server 2019 i trzy instancje Amazon Linux 2. DRS User Guide zawiera pełne instrukcje, jak uzyskać i skonfigurować agenta na każdym typie serwera, więc nie będziemy ich tu opisywać. Gdy uruchamiamy i konfigurujemy agenta na każdej z naszych instancji serwera, lista Source servers jest automatycznie aktualizowana, aby uwzględnić nowy serwer źródłowy. W tym widoku podsumowano stan początkowej synchronizacji oraz przyszły stan replikacji i odzyskiwania każdego serwera źródłowego.

Wybranie wpisu nazwy hosta(hostname entry) na liście przenosi nas do strony szczegółów. Tutaj możemy wyświetlić pulpit nawigacyjny odzyskiwania, informacje o serwerze bazowym, ustawienia dysku (w tym możliwość zmiany typu dysku tymczasowego z domyślnego typu gp3 wybranego przez kreatora inicjalizacji lub cokolwiek wybierzesz podczas konfiguracji) i ustawienia uruchamiania, pokazane poniżej, które zarządzają instancją odzyskiwania, która zostanie utworzona, jeśli zdecydujemy się zainicjować testowe lub rzeczywiste zadanie odzyskiwania.

Podobnie jak w przypadku kopii zapasowych danych, w przypadku których dobrą praktyką jest okresowe sprawdzanie, czy kopie zapasowe rzeczywiście mogą być użyte do przywracania danych, zalecamy podobną praktykę dotyczącą odzyskiwania po awarii. Tak więc, mając wszystkie nasze serwery skonfigurowane i w pełni zreplikowane, zdecydowliśmy się rozpocząć ćwiczenie odzyskiwania do punktu w czasie (PIT-point-in-time) dla dwóch naszych serwerów. Na tych instancjach, po wstępnej replikacji, zainstalowaliśmy dodatkowe oprogramowanie. W naszym scenariuszu być może ta instalacja nie przeszła pomyślnie lub padliśmy ofiarą ataku ransomware. Tak czy inaczej, chcieliśmy wiedzieć i mieć pewność, że w razie potrzeby możemy odzyskać nasze serwery.

Na liście Source servers wybraliśmy dwa zmodyfikowane serwery i z menu rozwijanego Initiate recovery job wybraliśmy Initiate drill. Następnie możemy wybrać interesujący nas PIT odzyskiwania. Ten widok jest domyślnie ustawiony na Any, co oznacza, że wyświetla wszystkie migawki odzyskiwania PIT dla wybranych serwerów. Możemy też wybrać filtrowanie do All, co oznacza, że zostaną wyświetlone tylko migawki PIT, które mają zastosowanie do wszystkich wybranych serwerów. Wybierając All, wybraliśmy czas tuż po zakończeniu instalacji dodatkowego oprogramowania na instancjach i kliknęliśmy Initiate drill.

Wróciliśmy do listy Source server, która pokazuje stan w miarę postępu odzyskiwania. Jednak my przełączyliśmy się na widok Recovery job history, aby uzyskać więcej szczegółów.

Klikając identyfikator zadania (job ID), możemy przejść dalej, aby wyświetlić stronę ze szczegółami serwerów źródłowych zaangażowanych w odzyskiwanie (i przejść dalej dla każdego z nich), a także w ogólne logi zadania odzyskiwania.

Uwaga – podczas ćwiczenia lub rzeczywistego odzyskiwania, jeśli przejdziesz do konsoli EC2, zauważysz jedną lub więcej dodatkowych instancji, uruchomionych przez DRS, działających na Twoim koncie (oprócz serwera replikacji). Te tymczasowe instancje, nazwane AWS Elastic Disaster Recovery Conversion Server, są używane do przetwarzania migawek PIT na rzeczywiste instancje odzyskiwania i zostaną usunięte po zakończeniu zadania.

Po zakończeniu odzyskiwania widzimy dwie nowe instancje w naszym środowisku EC2. Są one w stanie zgodnym z wybranym przez nas odzyskiwaniem do określonego momentu i korzystają z typów instancji wybranych wcześniej w kreatorze inicjalizacji DRS. Możemy się z nimi połączyć, aby sprawdzić, czy ćwiczenie odzyskiwania działało zgodnie z oczekiwaniami przed ich zakończeniem. Gdyby to było prawdziwe odzyskiwanie, mielibyśmy możliwość usunięcia oryginalnych instancji w celu zastąpienia ich wersjami odzyskiwania lub wykonania wszelkich innych zadań niezbędnych do zakończenia odzyskiwania po awarii w naszej firmie.

Dostępność Disaster Recovery Environment

AWS Elastic Disaster Recovery jest ogólnie dostępne we wschodnich stanach USA (północna Wirginia), wschodnich stanach USA (Ohio), zachodnich stanach USA (Oregon), regionie Azji i Pacyfiku (Singapur), regionie Azji i Pacyfiku (Sydney), regionie Azji i Pacyfiku (Tokio), Europie ( Regiony: Frankfurt), Europa (Irlandia) i Europa (Londyn). Zapoznaj się z instrukcjami User Guide AWS Elastic Disaster Recovery, aby uzyskać więcej informacji na temat konfiguracji i działania, i zacznij korzystać z DRS, aby wyeliminować bezczynne zasoby lokalizacji DR, korzystać z płatności zgodnie z rzeczywistym użyciem i uprościć wdrożenia, aby poprawić cele odzyskiwania po awarii.

źródło: AWS