Udostępnij za pośrednictwem

Replikacja geograficzna w usłudze Azure Database for PostgreSQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Replikę do odczytu można utworzyć w tym samym regionie co serwer podstawowy lub w innym regionie geograficznym. Replikacja geograficzna może być przydatna w scenariuszach, takich jak planowanie odzyskiwania po awarii lub przybliżanie danych do użytkowników.

Serwer podstawowy może znajdować się w dowolnym regionie serwera elastycznego usługi Azure Database for PostgreSQL. Serwer podstawowy może również mieć repliki w dowolnym regionie globalnym platformy Azure, który obsługuje serwer elastyczny usługi Azure Database for PostgreSQL. Ponadto obsługujemy również specjalne regiony platformy Azure Government i platformę Microsoft Azure obsługiwane przez firmę 21Vianet.

Sparowane regiony na potrzeby odzyskiwania po awarii

Chociaż tworzenie replik w dowolnym obsługiwanym regionie jest możliwe, istnieją istotne korzyści wynikające z wybierania replik w sparowanych regionach, zwłaszcza w przypadku tworzenia architektury na potrzeby odzyskiwania po awarii:

  • Sekwencja odzyskiwania regionów: w przypadku awarii obejmującej cały obszar geograficzny odzyskiwanie jednego regionu z każdego sparowanego zestawu jest priorytetowe, dzięki czemu aplikacje w sparowanych regionach zawsze mają przyspieszony region na potrzeby odzyskiwania.

  • Aktualizacja sekwencka: aktualizacje sparowanych regionów są rozłożone chronologicznie, co minimalizuje ryzyko przestoju w przypadku problemów związanych z aktualizacjami.

  • Izolacja fizyczna: minimalna odległość 300 mil jest utrzymywana między centrami danych w sparowanych regionach, co zmniejsza ryzyko jednoczesnej awarii ze względu na znaczące zdarzenia.

  • Miejsce przechowywania danych: z kilkoma wyjątkami regiony w sparowanym zestawie znajdują się w tej samej lokalizacji geograficznej, co spełnia wymagania dotyczące rezydencji danych.

  • Wydajność: Chociaż sparowane regiony zwykle oferują małe opóźnienie sieci, zwiększenie ułatwień dostępu do danych i środowiska użytkownika może nie zawsze być regionami o najniższym opóźnieniu bezwzględnym. Jeśli głównym celem jest udostępnianie danych bliżej użytkownikom, a nie priorytetowego odzyskiwania po awarii, kluczowe znaczenie ma ocena wszystkich dostępnych regionów pod kątem opóźnień. W niektórych przypadkach region nie sparowany może wykazywać najmniejsze opóźnienie. Aby uzyskać kompleksową wiedzę, możesz zapoznać się z danymi dotyczącymi opóźnienia rundy platformy Azure, aby dokonać świadomego wyboru.

Aby lepiej zrozumieć zalety sparowanych regionów, zapoznaj się z dokumentacją platformy Azure dotyczącą replikacji między regionami.

Awarie regionalne i odzyskiwanie

Obiekty platformy Azure w różnych regionach zostały zaprojektowane tak, aby były wysoce niezawodne. Jednak w rzadkich okolicznościach cały region może stać się niedostępny ze względu na przyczyny, od awarii sieci do poważnych scenariuszy, takich jak klęski żywiołowe. Możliwości platformy Azure umożliwiają tworzenie aplikacji rozproszonych w wielu regionach, zapewniając, że awaria w jednym regionie nie ma wpływu na inne.

Przygotowanie do katastrof regionalnych

Przygotowanie do potencjalnych awarii regionalnych ma kluczowe znaczenie dla zapewnienia nieprzerwanego działania aplikacji i usług. Jeśli rozważasz niezawodny plan awaryjny dla wystąpienia elastycznego serwera usługi Azure Database for PostgreSQL, oto najważniejsze kroki i zagadnienia:

  1. Ustanowienie repliki do odczytu replikowanej geograficznie: ważne jest, aby replika do odczytu została skonfigurowana w oddzielnym regionie od podstawowego. Zapewnia to ciągłość w przypadku wystąpienia awarii w regionie podstawowym.
  2. Upewnij się, że symetria serwera: akcja "podwyższanie poziomu do serwera podstawowego" jest najbardziej zalecana do obsługi awarii regionalnych, ale jest dostarczana z wymaganiami dotyczącymi symetrii serwera. Oznacza to, że zarówno serwery podstawowe, jak i repliki muszą mieć identyczne konfiguracje określonych ustawień. Zalety korzystania z tej akcji obejmują:
    • Nie trzeba modyfikować parametry połączenia aplikacji, jeśli używasz wirtualnych punktów końcowych.
    • Zapewnia ona bezproblemowy proces odzyskiwania, w którym po powrocie regionu, którego dotyczy problem, oryginalny serwer podstawowy automatycznie wznawia swoją funkcję, ale w nowej roli repliki.
  3. Konfigurowanie wirtualnych punktów końcowych: wirtualne punkty końcowe umożliwiają płynne przejście aplikacji do innego regionu, jeśli wystąpi awaria. Eliminują one konieczność wprowadzania zmian w parametry połączenia aplikacji.
  4. Skonfiguruj replikę do odczytu: nie wszystkie ustawienia z serwera podstawowego są replikowane do repliki do odczytu. Należy upewnić się, że wszystkie niezbędne konfiguracje i funkcje (na przykład PgBouncer) są odpowiednio skonfigurowane w repliki do odczytu. Aby uzyskać więcej informacji, zobacz sekcję Zarządzanie konfiguracją.
  5. Przygotowanie do wysokiej dostępności: jeśli konfiguracja wymaga wysokiej dostępności, nie zostanie ona automatycznie włączona w promowanej repliki. Przygotuj się do aktywowania go po podwyższeniu poziomu. Rozważ zautomatyzowanie tego kroku, aby zminimalizować przestoje.
  6. Regularne testowanie: Regularnie symuluj regionalne scenariusze awarii, aby zweryfikować istniejące progi, cele i konfiguracje. Upewnij się, że aplikacja reaguje zgodnie z oczekiwaniami podczas tych scenariuszy testowych.
  7. Postępuj zgodnie z ogólnymi wskazówkami platformy Azure: Platforma Azure udostępnia kompleksowe wskazówki dotyczące niezawodności i gotowości po awarii. Bardzo korzystne jest zapoznanie się z tymi zasobami i zintegrowanie najlepszych rozwiązań z planem gotowości.

Proaktywne i przygotowując się z wyprzedzeniem do regionalnych awarii zapewniają odporność i niezawodność aplikacji i danych.

Awarie wpływają na umowę SLA

Jeśli długotrwała awaria z serwerem elastycznym usługi Azure Database for PostgreSQL w określonym regionie, który zagraża umowie dotyczącej poziomu usług (SLA) aplikacji, pamiętaj, że obie akcje omówione poniżej nie są sterowane usługami. Interwencja użytkownika jest wymagana dla obu tych elementów. Najlepszym rozwiązaniem jest zautomatyzowanie całego procesu tak bardzo, jak to możliwe i posiadanie niezawodnego monitorowania. Aby uzyskać więcej informacji o tym, jakie informacje są udostępniane podczas awarii, zobacz stronę Awaria usługi. Tylko wymuszone podwyższenie poziomu jest możliwe w scenariuszu w dół regionu, co oznacza, że ilość utraty danych jest w przybliżeniu równa bieżącemu opóźnieniu między repliką a podstawową. W związku z tym kluczowe znaczenie ma monitorowanie opóźnienia. Rozważ następujące kroki:

Podwyższanie poziomu do serwera podstawowego

Ta opcja nie będzie wymagać aktualizacji parametry połączenia w aplikacji, pod warunkiem, że wirtualne punkty końcowe są skonfigurowane. Po aktywowaniu punkt końcowy modułu zapisywania zmieni punkt końcowy na nowy podstawowy w innym regionie, a kolumna stanu replikacji w witrynie Azure Portal wyświetli komunikat "Reconfiguring". Po przywróceniu regionu, którego dotyczy problem, były serwer podstawowy zostanie automatycznie wznowiony, ale teraz w roli repliki.

Podwyższ poziom do niezależnego serwera i usuń z replikacji

W takim przypadku jest to jedyna realna opcja. Po podwyższeniu poziomu serwera należy zaktualizować parametry połączenia aplikacji. Po przywróceniu oryginalnego regionu stary podstawowy może zostać ponownie aktywny. Upewnij się, że można go usunąć, aby uniknąć ponoszenia niepotrzebnych kosztów. Jeśli chcesz zachować poprzednią topologię, utwórz ponownie replikę do odczytu.

Powiązana zawartość