Strategia tworzenia kopii zapasowych Amazon EC2

Mam kilka konfiguracji serwera WWW / serwera DB za pomocą EC2 Amazon. Obecnie biorę codzienne migawki wszystkich moich dysków systemowych i EBS, które zawierają wszystkie moje pliki aplikacji, pliki DB, kod źródłowy i kopie zapasowe DB. Mam aplikację konsoli, która uruchamia tworzenie kopii zapasowych zgodnie z harmonogramem. Moje obrazy są obrazami EBS.

Pracuję nad zadaniem, które upuści moje migawki po tylu dniach. Wydaje mi się, że moje pytanie brzmi: czy powinienem / mogę również zaplanować pełne zadanie związane z obrazem / EBS? W ten sposób, jeśli serwer ulegnie awarii lub jest uszkodzony, mogę po prostu uruchomić najnowszy obraz, a następnie zastosować najnowszą migawkę.

Pracując nad strategią tworzenia kopii zapasowych, używam Jungle Disc do tworzenia kopii zapasowych dysków z danymi.

Moje rekomendacje:

1. Zawsze dokumentuj i / lub skryptuj konfigurację każdej nowej instancji, aby móc odtworzyć instalację oprogramowania i konfigurację systemu w przypadku utraty instancji. Sprawdź to, uruchamiając nową instancję i postępując zgodnie z procedurą. Możesz użyć niestandardowego, prywatnego interfejsu AMI, jeśli instalacja zajmuje dużo czasu i musisz szybko uruchomić instancje, ale ten interfejs AMI powinien zostać zbudowany przy użyciu udokumentowanej i / lub skryptowej procedury.

2. Przechowuj ważne dane na osobnych woluminach EBS, a nie na głównym woluminie EBS. Ma to wiele zalet, w tym ułatwia przenoszenie danych do nowych instancji (np. W oparciu o różne AMI) i ułatwia uzyskanie kopii danych w innych instancjach (np. Z migawkami i nowymi woluminami).

3. Twórz regularne migawki woluminów danych EBS. Jeśli to możliwe / odpowiednie, użyj narzędzia takiego jak moja migawka spójna ec2, aby zwiększyć szanse na zrobienie migawki spójnego systemu plików / bazy danych. Wykonaj kopię zapasową danych poza AWS / EC2, ponieważ samo twoje konto AWS jest pojedynczym punktem awarii.

4. Od czasu do czasu twórz migawki głównego woluminu EBS w ważnych instancjach. Chociaż może to pomóc w przypadku awarii wolumenu instancji lub EBS, ta część nie jest tak krytyczna z powodu powyższych punktów 1 i 2. Głównym powodem, dla którego to robię, jest to, że tworzenie migawek zmniejsza ryzyko awarii samego głównego wolumenu EBS.

Częstotliwość awarii woluminu EBS jest bezpośrednio związana z liczbą bloków, które zostały zmodyfikowane w tym woluminie od czasu ostatniej migawki EBS.

Czy powinienem / mogę również zaplanować kompletne zadanie image / EBS?

tak, jest wskazane. Pewnego razu mnie to uratowało, ponieważ musiałem zresetować wiele razy z powodu problemów z jądrem, dopóki dysk rozruchowy nie był już czytelny i po prostu uruchomiłem się z najnowszej migawki.

Jeśli jesteś zainteresowany, napisałem klasę Java, aby wykonać migawkę wszystkich podłączonych woluminów EBS, a także usunąć je po pewnym czasie. Obecnie wykonuję kopię zapasową co tydzień, a po dwóch tygodniach odrzucam trzecią kopię zapasową.

https://github.com/stivlo/obliquid-cp/blob/master/src/main/java/org/obliquid/sherd/runner/RequestSnapshots.java

Wykonuje tylko jedną akcję na uruchomienie, taką jak wykonanie lub usunięcie migawki, ponieważ ma być umieszczany w cronie co godzinę, aby uniknąć przeciążenia dziesiątkami migawek w tym samym czasie, na wypadek, gdybyś miał dużo EBS jak ja.

Stosujemy prostą, ale potężną strategię tworzenia kopii zapasowych: utwórz nowe AMI na podstawie uruchamiania instancji EC2 EBS dwa razy dziennie i usuń „stare” AMI. Poprzez API (CreateImage) możesz ustawić flagę nie restartuj instancji podczas tworzenia nowego AMI lub, jeśli używasz raidu programowego - ssh do instancji przed wywołaniem interfejsu API CreateIImage i zamrażania systemu plików z „fsfreeze” w najpopularniejszych systemach plików w nowych jądrach lub xfs_freeze jeśli używasz starszego jądra i XFS.

Utworzona „kopia zapasowa” AMI zapamiętuje wszystkie podłączone do oryginalnych działających dysków EBS instancji (poprzez łącza do utworzonych migawek), a w przypadku raidów programowych z wieloma dyskami pozwala przywrócić nowe wystąpienie w dowolnej AZ za pomocą jednego wywołania API lub przez Internet -berło.