Nowość – twórz migawki spójne z aplikacją za pomocą Amazon Data Lifecycle Manager i niestandardowych skryptów

29 lutego 2024

Amazon Data Lifecycle Manager obsługuje teraz użycie skryptów przed migawką i po migawce, osadzonych w dokumentach AWS Systems Manager. Możesz użyć tych skryptów, aby upewnić się, że migawki Amazon Elastic Block Store (Amazon EBS) utworzone przez Data Lifecycle Manager są spójne z aplikacją.

Skrypty mogą wstrzymywać i wznawiać operacje I/O, opróżniać buforowane dane do woluminów EBS i tak dalej. W ramach tej premiery twórcy publikują również zestaw szczegółowych artykułów na blogu, które pokazują, jak używać tej funkcji z samodzielnie zarządzanymi relacyjnymi bazami danych i usługą Windows Volume Shadow Copy Service (VSS).

Data Lifecycle Manager (DLM) Recap

W skrócie: Data Lifecycle Manager pomaga zautomatyzować tworzenie, przechowywanie i usuwanie migawek woluminów Amazon EBS. Po wykonaniu wymaganych kroków, takich jak podłączenie instancji EC2 do AWS Systems Manager, skonfigurowanie roli IAM dla DLM i oznaczenie dokumentów SSM, wystarczy utworzyć politykę cyklu życia i wskazać (za pomocą tagów) odpowiednią instancję Amazon Elastic Compute Cloud (Amazon EC2), ustawić model przechowywania i pozwolić DLM zająć się resztą. Zasady określają, kiedy mają być uruchamiane, co ma być uwzględniane w kopii zapasowej i jak długo muszą być przechowywane migawki. Aby zapoznać się z pełnym opisem DLM, przeczytaj artykuł na blogu z 2018 r., New – Lifecycle Management for Amazon EBS Snapshots.

Application Consistent Snapshots

Migawki EBS są spójne pod kątem awarii, co oznacza, że reprezentują stan powiązanego woluminu EBS w momencie utworzenia migawki. Jest to wystarczające w przypadku wielu typów aplikacji, także tych, które nie wykorzystują migawek do przechwytywania stanu aktywnej relacyjnej bazy danych. Aby wykonać migawkę spójną z aplikacją, należy wziąć pod uwagę transakcje oczekujące (czekające na ich zakończenie lub powodujące ich awarię), chwilowo wstrzymać dalsze operacje zapisu, wykonać migawkę, a następnie wznowić normalne działanie.

I tu właśnie pojawia się dzisiejsza premiera. DLM ma teraz możliwość poinformowania instancji o konieczności przygotowania kopii zapasowej spójnej z aplikacją. Skrypt poprzedzający migawkę może zarządzać transakcjami oczekującymi, opróżniać dane z pamięci do pamięci trwałej, zamrażać system plików, a nawet zatrzymywać aplikację lub bazę danych. Następnie skrypt po wykonaniu migawki może przywrócić aplikację lub bazę danych do życia, ponownie załadować pamięć podręczną z pamięci trwałej, „odmrozić” system plików i tak dalej.

Oprócz podstawowej obsługi niestandardowych skryptów, możesz także użyć tej funkcji do zautomatyzowania tworzenia migawek VSS Backup:

Nowość – twórz migawki spójne z aplikacją za pomocą Amazon Data Lifecycle Manager i niestandardowych skryptów

Pre and Post Scripts

Nowe skrypty dotyczą zasad DLM dla instancji. Załóżmy, że stworzono politykę odwołującą się do dokumentów SSM ze skryptami przed i po migawce i że dotyczy ona pojedynczej instancji. Oto, co się stanie, jeśli zasada zostanie uruchomiona zgodnie z harmonogramem:

  1. Skrypt poprzedzający migawkę jest uruchamiany z dokumentu SSM.
  2. Uruchamiane jest każde polecenie w skrypcie i rejestrowany jest status na poziomie skryptu (powodzenie lub niepowodzenie). Jeśli opcja ta jest włączona w zasadach, DLM będzie ponawiać próby wykonania nieudanych skryptów.
  3. Inicjowane są wielowoluminowe migawki EBS dla woluminów EBS podłączonych do instancji, z dalszą kontrolą poprzez politykę.
  4. Z dokumentu SSM uruchamiany jest skrypt post-snapshot,
  5. Uruchamiane jest każde polecenie w skrypcie i rejestrowany jest status na poziomie skryptu (powodzenie lub niepowodzenie).

Nowe skrypty dotyczą zasad DLM dla instancji. Załóżmy, że stworzono politykę odwołującą się do dokumentów SSM ze skryptami przed i po migawce i że dotyczy ona pojedynczej instancji.

Polityka zawiera opcje umożliwiające kontrolę nad działaniami podejmowanymi (ponowna próba, kontynuacja lub pominięcie) w przypadku przekroczenia limitu czasu działania któregoś ze skryptów lub niepowodzenia. Status jest rejestrowany, publikowane są metryki Amazon CloudWatch, emitowane są zdarzenia Amazon EventBridge, a status jest również kodowany w tagach, które są automatycznie przypisywane do każdej migawki.

Skrypty poprzedzające migawkę i następujące po niej mogą wykonywać dowolne akcje dozwolone w dokumencie poleceń: uruchamianie skryptów powłoki, uruchamianie skryptów PowerShell i tak dalej. Akcje muszą zostać zakończone w ramach limitu czasu określonego w polityce, z dopuszczalnym zakresem od 10 sekund do 120 sekund.

Rozpoczynanie

Aby zbudować solidną parę skryptów, będziesz musiał szczegółowo zrozumieć swoją aplikację lub bazę danych. Oprócz obsługi „happy path”, gdy wszystko pójdzie dobrze, Twoje skrypty muszą zaplanować kilka scenariuszy niepowodzeń. Na przykład skrypt poprzedzający wykonanie migawki powinien rozdzielić zadanie w tle, które będzie służyć jako zabezpieczenie w przypadku, gdy skrypt wykonywany po migawce nie będzie działał zgodnie z oczekiwaniami. Każdy skrypt musi zwracać kod na poziomie „shell-level”, jak opisano tutaj.

Po napisaniu i przetestowaniu skryptów oraz spakowaniu ich jako dokumentów SSM otwórz stronę Data Lifecycle Manager w konsoli EC2, wybierz EBS snapshot policy i kliknij Next step:

Amazon CloudWatch

Cel to wszystkie instancje oznaczone Mode of Production. Użyj domyślnej roli IAM (jeśli używasz innej roli, musi ona umożliwiać dostęp do SSM), pozostaw resztę wartości bez zmian i kontynuuj:

Cel to wszystkie instancje oznaczone Mode of Production. Użyj domyślnej roli IAM (jeśli używasz innej roli, musi ona umożliwiać dostęp do SSM), pozostaw resztę wartości bez zmian i kontynuuj:

Na następnej stronie przewiń do Pre and post scripts i rozwiń sekcję. Kliknij Enable pre and post scripts, wybierz Custom SSM document, a następnie z menu wybierz swój dokument SSM. Ustaw opcje limitu czasu i ponawiania prób oraz wybierz opcję domyślnej kopii zapasowej spójnej z awarią, na wypadek gdy jeden z Twoich skryptów zawiedzie. Kliknij Review policy, dokonaj ostatniej kontroli i wybierz Create policy na następującej stronie:

Na następnej stronie przewiń do Pre and post scripts i rozwiń sekcję. Kliknij Enable pre and post scripts, wybierz Custom SSM document, a następnie z menu wybierz swój dokument SSM. Ustaw opcje limitu czasu i ponawiania prób oraz wybierz opcję domyślnej kopii zapasowej spójnej z awarią, na wypadek gdy jeden z Twoich skryptów zawiedzie. Kliknij Review policy, dokonaj ostatniej kontroli i wybierz Create policy na następującej stronie:

Twoja polityka została utworzona i zacznie obowiązywać od razu. Po przynajmniej jednokrotnym uruchomieniu możesz sprawdzić metryki CloudWatch pod kątem uruchomień, zakończeń i błędów:

Twoja polityka została utworzona i zacznie obowiązywać od razu. Po przynajmniej jednokrotnym uruchomieniu możesz sprawdzić metryki CloudWatch pod kątem uruchomień, zakończeń i błędów:

Dodatkowa lektura

Oto pierwsze szczegółowe artykuły na blogu, który obiecano wcześniej:

Twórcy wkrótce zaktualizują powyższą listę, gdy kolejne artykuły zostaną opublikowane.

Możesz także zapoznać się z dokumentacją, aby uzyskać więcej informacji.

Poniżej znajdziesz video, które mogą okazać się pomocne:

źródło: AWS

Case Studies
Referencje

Hostersi wsparli nas na każdym etapie projektowania i budowy infrastruktury. Finansowanie, które pomogli pozyskać nam od AWS, pozwoliło przetestować szereg różnych rozwiązań i wybrać konfigurację, która najlepiej odpowiada potrzebom naszej aplikacji. Hostersi stworzyli dla nas infrastrukturę „szytą na miarę”, którą dzięki programowi wsparcia startupów, pozyskaliśmy niemal bezkosztowo.

Wojciech Mróz
CEO & Co-founder Pagaspot
W skrócie o nas
Specjalizujemy się w dostarczaniu rozwiązań IT w obszarach projektowania infrastruktury serwerowej, wdrażania chmury obliczeniowej, opieki administracyjnej i bezpieczeństwa danych.