Google ACE: Niezawodność, kopie zapasowe i odtwarzanie po awarii — Przewodnik do nauki

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Część Google Associate Cloud Engineer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Niezawodność, kopie zapasowe i odtwarzanie po awarii w Google Cloud wymagają świadomego projektowania z uwzględnieniem domen awarii, mechanizmów ochrony danych, zarządzania ruchem i gotowości operacyjnej. Ta sekcja wyjaśnia, jak strukturyzować usługi w różnych strefach i regionach, jak chronić i przywracać dane stanowe oraz jak weryfikować cele odtwarzania za pomocą zdyscyplinowanych runbooków i ciągłego testowania odporności. Przedstawia również kompromisy w strategii DR oraz planowanie pojemności, aby zapewnić, że platforma może zostać odtworzona w ramach zdefiniowanych celów czasu odtwarzania (RTO) i punktu odtwarzania (RPO).

Domeny awarii i projektowanie regionalne

• Strefy, regiony i usługi wieloregionalne

  • Strefy to najmniejsze niezależne domeny awarii. Pojedyncza awaria strefy nie powinna zakłócić działania usługi regionalnej.
  • Regiony grupują niezależne strefy za pomocą połączeń o niskim opóźnieniu. Architektury regionalne są odporne na awarie strefowe, ale niekoniecznie na pełne awarie regionalne.
  • Usługi wieloregionalne replikują dane między regionami, chroniąc przed utratą regionu kosztem wyższych opłat i potencjalnie wyższego opóźnienia zapisu.
  • Zasada projektowa: unikaj pojedynczych punktów awarii w najmniejszej domenie awarii, która ma dla Ciebie znaczenie. Jeśli Twoje RTO/RPO wymaga odporności na awarię strefy, wdróż zasoby w co najmniej dwóch strefach. Aby zapewnić odporność na poziomie regionu, wdróż aktywne komponenty w wielu regionach lub korzystaj z usług wieloregionalnych.

• Managed instance groups (MIG) i samonaprawa

  • Preferuj regionalne grupy MIG, aby dystrybuować instancje między strefami w jednym regionie. Łagodzi to skutki awarii strefowych bez potrzeby stosowania oddzielnych narzędzi.
  • Sprawdzanie stanu (health checks) przez load balancer usuwa niesprawne maszyny wirtualne z ruchu. Automatyczna naprawa (autohealing) w MIG zastępuje niesprawne lub niereagujące maszyny wirtualne. Używaj obu mechanizmów.
  • Używaj sprawdzania stanu na poziomie aplikacji (HTTP(S) health checks), które weryfikują punkty końcowe gotowości (readiness endpoints) i zależności. Sprawdzanie TCP weryfikuje jedynie osiągalność portu.
  • Tryb awarii spowodowany błędną konfiguracją automatycznej naprawy: użycie wyłącznie sprawdzania stanu przez load balancer blokuje ruch do uszkodzonej instancji, ale jej nie odtwarza. Skonfiguruj własne sprawdzanie stanu dla grupy MIG w celu zastępowania instancji oraz ustaw początkowe opóźnienie, aby uniknąć przedwczesnych restartów podczas uruchamiania.

Przykład:

• Utwórz sprawdzanie stanu aplikacji z 10-sekundowymi interwałami i 3 progami niesprawności, aby uruchomić samonaprawę po ok. 30 sekundach: gcloud compute health-checks create http hc-app
  –check-interval=10s –timeout=5s
  –unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz

• Podłącz sprawdzanie stanu do regionalnej grupy MIG w celu automatycznej naprawy: gcloud compute instance-groups managed update my-rmig
  –region=us-central1 –health-check=hc-app –initial-delay=60

• Kwestie związane z architekturą wieloregionalną

  • Usługa Global external HTTP(S) Load Balancing obsługuje backendy w wielu regionach z automatycznym przełączaniem awaryjnym (failover) opartym na sprawdzaniu stanu.
  • Synchronizacja stanu między regionami jest kluczowym kompromisem. Przepustowość w trybie aktywny-aktywny jest wysoka, ale należy zaprojektować spójność danych i rozwiązywanie konfliktów. Tryb aktywny-pasywny jest prostszy, ale charakteryzuje się wolniejszym przełączaniem awaryjnym i potencjalnie większym RPO.

Ochrona danych: Bazy danych, pamięć masowa i zasoby obliczeniowe

• Wysoka dostępność i repliki Cloud SQL
  • Konfiguracja wysokiej dostępności umieszcza instancję rezerwową (standby) w innej strefie z replikacją synchroniczną. Automatyczne przełączanie awaryjne (failover) następuje w przypadku awarii instancji podstawowej. RTO wynosi zazwyczaj kilka minut; RPO ≈ 0 w obrębie regionu, ale należy uwzględnić transakcje w toku.
  • Repliki do odczytu odciążają instancję główną od zapytań odczytu i mogą być międzyregionalne na potrzeby DR (Disaster Recovery). Działają asynchronicznie; należy spodziewać się opóźnień w replikacji i niezerowego RPO.
  • Kopie zapasowe i PITR
    • Włącz zautomatyzowane kopie zapasowe i przywracanie do punktu w czasie (point-in-time recovery). Dla MySQL włącz logowanie binarne; dla PostgreSQL włącz retencję PITR.
    • Proces przywracania: w przypadku uszkodzenia danych lub błędu użytkownika, przywróć dane do nowej instancji na określony znacznik czasu, przekieruj aplikacje lub repliki do przywróconej instancji i zweryfikuj dane.
  • Tryby awarii i kompromisy
    • Wysoka dostępność (HA) nie chroni przed logicznym uszkodzeniem danych; robią to kopie zapasowe i PITR.
    • Repliki międzyregionalne chronią przed utratą regionu, ale mogą mieć opóźnienia; przetestuj swoje akceptowalne RPO.

Przykład:

• Włącz logowanie binarne (MySQL) i zautomatyzowane kopie zapasowe:

undefined

• Migawki dysków trwałych (PD) i obrazy maszyn
  • Migawki PD to przyrostowe, spójne na poziomie awarii (crash-consistent) kopie zapasowe dysków. Ich lokalizacja przechowywania jest konfigurowalna i mogą być używane do tworzenia nowych dysków w dowolnej strefie w ramach zakresu lokalizacji migawki.
  • Aby uzyskać kopie zapasowe spójne na poziomie aplikacji, należy wyciszyć (quiesce) system plików i aplikację lub skoordynować tworzenie migawek z mechanizmami tworzenia kopii zapasowych specyficznymi dla bazy danych.
  • Obrazy maszyn (Machine images) przechwytują dyski i metadane instancji (dyski rozruchowe, dołączone dyski, właściwości instancji). Używaj obrazów maszyn do szybszego odzyskiwania floty lub klonowania konfiguracji “złotego serwera”.
  • Zasady harmonogramu migawek automatyzują tworzenie kopii zapasowych; wymuszają retencję; odpowiednio oznaczaj krytyczne dyski.
  • Proces przywracania: utwórz dysk z migawki, dołącz go do nowej instancji, zaktualizuj skrypty startowe i konta usług, a następnie zweryfikuj integralność aplikacji przed ponownym skierowaniem na nią ruchu.

Przykład:

• Utwórz migawkę i przywróć ją na nowy dysk:

undefined

• Replikacja, wersjonowanie i retencja w Cloud Storage
  • Wybór klasy pamięci masowej: Standard dla gorących danych; Nearline dla rzadkiego dostępu (raz w miesiącu); Coldline dla dostępu kwartalnego (zalecane dla kopii zapasowych i DR); Archive dla danych długoterminowych, rzadko używanych.
  • Zasobniki (buckets) typu Regional, Dual-Region i Multi-Region oferują trwałość dzięki replikacji. Dual-Region z replikacją turbo może ograniczyć RPO replikacji dla nowo zapisanych obiektów; Multi-Region oferuje szeroką odporność geograficzną.
  • Wersjonowanie obiektów chroni przed przypadkowymi usunięciami i nadpisaniami, przechowując nieaktualne wersje. Połącz je z zasadami retencji i blokadą zasobnika (bucket lock), aby wymusić retencję typu WORM (Write Once, Read Many).
  • Ochrona przed przypadkowym usunięciem: włącz wersjonowanie obiektów, użyj zasad retencji z blokadą, zaimplementuj blokady oparte na zdarzeniach (event-based holds) dla wymogów prawnych lub etapów przetwarzania, ogranicz uprawnienia do usuwania za pomocą IAM i jednolitego dostępu na poziomie zasobnika. Do zewnętrznego, ograniczonego czasowo dostępu używaj podpisanych adresów URL (signed URLs) ze ścisłymi terminami wygaśnięcia.

Przykład cyklu życia obiektu, który przenosi go do Coldline po 90 dniach i usuwa po 365 dniach:

• lifecycle.json

undefined

• Zastosuj:

undefined

Odporność ruchu, pojemności i zależności

• Failover DNS i zarządzanie ruchem

  • Dla usług dostępnych z internetu preferuj globalny zewnętrzny HTTP(S) Load Balancing; wykorzystuje on adresy IP anycast i wykonuje przełączanie awaryjne (failover) między regionami w oparciu o kontrolę kondycji.
  • Dla usług prywatnych używaj wewnętrznych load balancerów HTTP(S) lub TCP/UDP. Projektuj z myślą o niezależności strefowej z wieloma backendami.
  • Kompromisy związane z DNS TTL: niskie wartości TTL umożliwiają szybszy failover, ale zwiększają obciążenie zapytań i mogą być ignorowane przez niektóre resolwery z powodu ich mechanizmów buforowania (cache). Failover load balancera oparty na kontroli kondycji jest szybszy i bardziej deterministyczny niż failover oparty wyłącznie na DNS.
  • Zasady DNS typu weighted (ważone) lub failover mogą być płaszczyzną sterowania ostatniej szansy przy ewakuacji regionu, ale polegają na wygaśnięciu pamięci podręcznej (cache).

• Planowanie pojemności i projektowanie limitów (quota)

  • Zidentyfikuj minimalną sprawną pojemność dla każdej strefy i regionu. Zastosuj bufory zapasowe (headroom) na potrzeby przełączania awaryjnego (pojemność w modelu „strefa N+1”).
  • Używaj rezerwacji regionalnych dla krytycznych typów maszyn Compute Engine, aby zagwarantować pojemność podczas zdarzeń skalowania lub przełączania awaryjnego.
  • Przygotuj z wyprzedzeniem adresy IP, reguły przekierowania (forwarding rules), pojemność Cloud NAT, mechanizmy śledzenia połączeń i certyfikaty SSL, aby uniknąć opóźnień płaszczyzny sterowania podczas odzyskiwania.
  • Wnioskuj o zwiększenie limitów (quota) z dużym wyprzedzeniem; zweryfikuj limity w regionach zapasowych i dla wszystkich zależności (np. liczba instancji Cloud SQL na region, liczba reguł przekierowania na VPC, przepustowość Pub/Sub, QPS dla Cloud KMS).
  • Kwestie związane z autoskalowaniem: skonfiguruj okresy oczekiwania (cooldowns), w razie potrzeby autoskalowanie predykcyjne, i ustaw granice minimalne/maksymalne, aby zachować dokładnie jedną instancję, jeśli jest to wymagane przez politykę.

• Odporność na awarie zależności

  • Zidentyfikuj usługi nadrzędne (upstream) i podrzędne (downstream). Dla każdej z nich zdefiniuj zachowanie w przypadku awarii i mechanizmy zapasowe: buforowaną konfigurację, tryby ograniczonej funkcjonalności, wyłączniki bezpieczeństwa (circuit breakers), kolejki z tematami ‘dead-letter’ oraz mechanizmy ‘backpressure’ (przeciwciśnienia).
  • Zweryfikuj zakresy uprawnień IAM i kont usług w regionach odzyskiwania. Brakujące role często powodują ciche awarie podczas zdarzeń DR.
  • Klucze szyfrujące: upewnij się, że repliki kluczy Cloud KMS lub klucze wieloregionalne są zgodne z lokalizacją danych. Zaplanuj lokalność pęku kluczy (key-ring) i uprawnienia IAM w regionach zapasowych.

Operacje zapewniające odporność i ciągłe doskonalenie

• RTO, RPO, plany odzyskiwania i runbooki

  • RTO (Recovery Time Objective) określa, jak szybko usługa musi zostać wznowiona; RPO (Recovery Point Objective) definiuje dopuszczalną utratę danych. Wartości te należy wyznaczyć na podstawie analizy wpływu na biznes (business impact analysis).
  • Przypisz każdy komponent systemu do konkretnych mechanizmów spełniających RTO/RPO: wysoka dostępność (HA) dla awarii strefowych, replikacja międzyregionalna dla awarii regionalnych, kopie zapasowe na wypadek uszkodzenia danych oraz klasa pamięci masowej/replikacja dla zapewnienia trwałości.
  • Utrzymuj runbooki: precyzyjne kroki, polecenia, dostęp do poświadczeń, kontrole poprawności działania i drzewa decyzyjne. Przechowuj je w repozytorium z kontrolą wersji i dostępu oraz regularnie przećwicz.
  • Walidacja odzyskiwania: planuj ćwiczenia w celu pomiaru rzeczywistego RTO/RPO, weryfikacji integralności danych i zbierania działań usprawniających. Testuj zarówno przywracanie o małym zakresie (tabela, dysk), jak i pełne odzyskiwanie ośrodka.

• Strategie DR i kompromisy

  • Active-active: wszystkie regiony obsługują ruch; minimalne RTO i niskie RPO, jeśli synchronizacja danych jest poprawnie zaprojektowana. Wyższa złożoność i koszt; wymaga rozwiązywania konfliktów i globalnego równoważenia obciążenia.
  • Active-passive: region podstawowy jest aktywny; region zapasowy jest w stanie gotowości (warm) i odbiera replikowane dane. Umiarkowany koszt; RTO od minut do dziesiątek minut; niezerowe RPO w zależności od replikacji.
  • Pilot-light: w regionie zapasowym działają minimalne krytyczne usługi (replikacja bazy danych, minimalny ślad aplikacji). RTO rzędu godzin; efektywne kosztowo; wymaga starannej orkiestracji w celu skalowania zasobów obliczeniowych podczas failoveru.
  • Cold-standby: infrastruktura zdefiniowana jako kod, ale nieuruchomiona. RTO rzędu dni; najniższy koszt; ryzyko niespodzianek związanych z dryfem konfiguracji, limitami (quotas) i brakiem dostępności zasobów.

• Testowanie chaosu (Chaos testing) i symulacje awarii

  • Regularnie symuluj awarie instancji, zawieszenia procesów, błędy kontroli stanu, zapełnienie dysku i awarie zależności. Używaj narzędzi lub skryptów do zamykania instancji, blokowania ruchu wychodzącego do backendów lub wprowadzania opóźnień na warstwie proxy.
  • Weryfikuj autoleczenie MIG i usuwanie instancji przez LB poprzez celowe powodowanie awarii endpointu kontroli stanu. Potwierdź zachowanie mechanizmu zastępowania instancji i czasy odzyskiwania.
  • Ćwicz ewakuację regionalną: wyłączaj backendy w jednym regionie, obserwuj failover globalnego load balancera i weryfikuj zależności stanowe w regionie zapasowym.
  • Ciągłe doskonalenie: rejestruj metryki takie jak średni czas do wykrycia (MTTD), czas przełączenia awaryjnego (failover time) i utrata danych podczas testów. Priorytetyzuj poprawki, które redukują RTO/RPO i eliminują kroki manualne.

Praktyczny scenariusz problemowy

Firma Brightlane Retail prowadzi platformę e-commerce w regionie us-central1 z rygorystycznymi wymogami dostępności i czterogodzinnym RPO dla danych zamówień. Kierownictwo wymaga przetrwania awarii strefowej bez przestojów oraz awarii regionalnej z minimalnym wpływem na klientów.

Podejście:

1. Wdrożenie regionalnej grupy MIG z autoleczeniem HTTP i globalnym HTTP(S) Load Balancer
   • Uzasadnienie: Regionalna grupa MIG rozkłada instancje pomiędzy strefy, a kontrole stanu HTTP na poziomie aplikacji umożliwiają samonaprawę po trzech nieudanych próbach co 10 sekund. Globalny load balancer automatycznie usuwa niesprawne maszyny wirtualne i przełącza ruch do sprawnych stref.
   • Polecenia:

undefined

undefined

2. Włączenie wysokiej dostępności (HA) dla Cloud SQL z repliką do odczytu w innym regionie i PITR
   • Uzasadnienie: Regionalna wysoka dostępność (HA) zapewnia przetrwanie awarii strefowej dzięki automatycznemu failoverowi. Replika do odczytu w us-east1 zapewnia regionalne odzyskiwanie po awarii (DR) z niezerowym, ale ograniczonym RPO. Włączenie PITR (logi binarne dla MySQL) pozwala na radzenie sobie z logicznym uszkodzeniem danych poprzez umożliwienie przywrócenia do określonego punktu w czasie.
   • Polecenia:

undefined

undefined

3. Ochrona zasobów obiektowych za pomocą Dual-Region Cloud Storage i polityk cyklu życia

   • Uzasadnienie: Obrazy produktów i zasoby statyczne są przechowywane w buckecie typu dual-region w celu zapewnienia odporności regionalnej. Przejścia w cyklu życia przenoszą starsze artefakty do klasy Coldline w celu optymalizacji kosztów, a wersjonowanie wraz z politykami retencji zapobiegają przypadkowemu usunięciu krytycznych zasobów.
   • Kroki: Włącz wersjonowanie obiektów (Object Versioning), ustaw 30-dniową politykę retencji dla krytycznych bucketów i zastosuj reguły cyklu życia, aby przenieść niekrytyczne artefakty kompilacji do klasy Coldline po 90 dniach i usunąć je po roku.

4. Zaplanuj tworzenie migawek (snapshots) dysków PD i twórz obrazy maszyn dla usług stanowych

   • Uzasadnienie: Przyrostowe migawki dysków VM zapewniają szybkie opcje przywracania spójnego na poziomie awarii (crash-consistent). Obrazy maszyn przechowują konfigurację rozruchową i systemową, aby przyspieszyć odtwarzanie serwerów aplikacji podczas failoveru regionalnego. Harmonogramy migawek zapewniają spójne, oparte na politykach tworzenie kopii zapasowych.
   • Polecenia:

undefined

undefined

undefined

5. Zdefiniuj RTO/RPO i skodyfikuj runbooki DR oraz IaC

   • Uzasadnienie: Ustaw RTO na poziomie usługi na 15 minut dla warstwy web/API i czterogodzinne RPO dla zamówień. Runbooki określają procedury przełączania ruchu (failover), promowanie repliki do odczytu Cloud SQL, plany awaryjne dla DNS i kroki weryfikacyjne. Infrastruktura jako kod (Terraform/Deployment Manager) zapewnia deterministyczne odtwarzanie i redukuje błędy manualne.

6. Zapewnij pojemność i limity (quotas) w regionie zapasowym

   • Uzasadnienie: Utwórz rezerwacje dla krytycznych typów maszyn wirtualnych, wstępnie przygotuj zapasowy backend dla load balancera, certyfikaty SSL, pojemność NAT i zweryfikuj limity (quotas) dla Compute, SQL, reguł przekierowania i KMS w regionie us-east1. Zapobiega to wyczerpaniu zasobów podczas failoveru.

7. Weryfikuj odzyskiwanie poprzez ćwiczenia chaosu i dokumentuj usprawnienia

   • Uzasadnienie: Kwartalne ćwiczenia awarii strefowych weryfikują zachowanie MIG i LB; półroczna ewakuacja regionalna obejmuje promowanie repliki do odczytu w us-east1, skierowanie globalnego LB na backendy w us-east1 i pomiar RTO/RPO. Wnioski z ćwiczeń napędzają usprawnienia, takie jak redukcja kroków manualnych czy zwiększenie pojemności repliki.

Postępując zgodnie z tymi krokami, Brightlane Retail osiąga strefową wysoką dostępność z automatycznym samoleczeniem oraz regionalną gotowość do odzyskiwania po awarii (DR) z zdefiniowanymi i przetestowanymi runbookami, zapewniając, że dane zamówień spełniają czterogodzinne RPO, a usługi aplikacyjne są odzyskiwane w ramach docelowych wartości RTO.

← Bezpieczeństwo · Wszystkie domeny · Zarządzanie kosztami →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Google →