Niezawodność w usłudze Azure DNS

Ten artykuł zawiera szczegółowe informacje na temat odzyskiwania po awarii między regionami i obsługi ciągłości działania dla usługi Azure DNS.

Odzyskiwanie po awarii między regionami i ciągłość działania

Odzyskiwanie po awarii (DR) odnosi się do praktyk używanych przez organizacje do odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Przed rozpoczęciem tworzenia planu odzyskiwania po awarii zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.

W przypadku DR firma Microsoft używa modelu wspólnej odpowiedzialności . W tym modelu firma Microsoft zapewnia dostępność podstawowej infrastruktury i usług platformy. Jednak wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego włączonego regionu. W przypadku tych usług odpowiadasz za skonfigurowanie planu odzyskiwania po awarii, który jest odpowiedni dla Twojego obciążenia. Większość usług oferty platformy Azure jako usługa (PaaS) udostępnia funkcje i wskazówki wspierające DR. Możesz użyć funkcji specyficznych dla usługi, aby wspierać szybkie odzyskiwanie i ułatwić opracowanie planu odzyskiwania po awarii.

Rozwiązanie trybu failover usługi Azure DNS na potrzeby odzyskiwania po awarii używa standardowego mechanizmu DNS do przełączania w tryb failover do lokacji kopii zapasowej. Opcja ręczna za pośrednictwem usługi Azure DNS działa najlepiej, gdy jest używana w połączeniu z zimnym trybem wstrzymania lub podejściem pilotażowym.

Ponieważ serwer DNS znajduje się poza trybem failover lub strefą awarii, jest izolowany przed każdym przestojem. Możesz zaprojektować prosty scenariusz awaryjny, o ile operator ma łączność sieciową podczas awaryjnej sytuacji i może dokonać przełączenia. Jeśli rozwiązanie jest skryptowe, należy upewnić się, że serwer lub usługa, na której jest uruchomiony skrypt, jest również odizolowana od problemu wpływającego na środowisko produkcyjne. Ponadto niski TTL dla strefy uniemożliwia buforowanie przez resolver przez długie okresy czasu, dzięki czemu klient może uzyskać dostęp do witryny w ramach określonego RTO. W przypadku trybu zimnej rezerwy i światła kontrolnego, ponieważ może być wymagane wykonanie wstępnych działań administracyjnych, należy również dać wystarczająco dużo czasu przed przełączeniem.

Aby dowiedzieć się, jak utworzyć prywatną strefę DNS platformy Azure przy użyciu witryny Azure Portal, zobacz Szybki start: tworzenie prywatnej strefy DNS platformy Azure przy użyciu witryny Azure Portal.

Aby utworzyć prywatny program rozpoznawania nazw dns platformy Azure przy użyciu witryny Azure Portal, zobacz Szybki start: tworzenie prywatnego rozpoznawania nazw usługi Azure DNS przy użyciu witryny Azure Portal.

Odzyskiwanie po awarii w lokalizacji geograficznej obejmującej wiele regionów

Istnieją dwa aspekty techniczne dotyczące konfigurowania architektury odzyskiwania po awarii:

• Używanie mechanizmu wdrażania do replikowania wystąpień, danych i konfiguracji między środowiskami podstawowymi i rezerwowymi. Tego typu odzyskiwanie po awarii można wykonać natywnie za pośrednictwem usługiAzure Site Recovery. Zobacz dokumentację usługi Azure Site Recovery za pośrednictwem urządzeń/usług partnerskich platformy Microsoft Azure, takich jak Veritas lub NetApp.

• Opracowanie rozwiązania do przekierowywania ruchu sieciowego/internetowego z lokacji głównej do lokacji rezerwowej. Ten typ odzyskiwania po awarii można osiągnąć za pośrednictwem usług Azure DNS, Azure Traffic Manager(DNS) lub globalnych modułów równoważenia obciążenia innych firm.

Ten artykuł koncentruje się specjalnie na planowaniu odzyskiwania po awarii usługi Azure DNS.

Konfigurowanie odzyskiwania po awarii i wykrywania awarii

Rozwiązanie ręcznego przełączania awaryjnego usługi Azure DNS na potrzeby odzyskiwania po awarii wykorzystuje standardowy mechanizm DNS do awaryjnego przełączania do lokacji zapasowej. Opcja ręczna za pośrednictwem usługi Azure DNS działa najlepiej, gdy jest używana w połączeniu z zimnym trybem wstrzymania lub podejściem pilotażowym.

Rysunek — ręczne przechodzenie w tryb failover przy użyciu usługi Azure DNS

Założenia dotyczące rozwiązania to:

• Oba podstawowe i pomocnicze punkty końcowe mają statyczne adresy IP, które nie zmieniają się często. Przyjmijmy, że w głównej lokalizacji adres IP to 100.168.124.44, a adres IP dodatkowej lokalizacji to 100.168.124.43.
• Strefa DNS platformy Azure istnieje zarówno dla lokacji głównej, jak i dodatkowej. Załóżmy, że dla głównej strony adres końcowy to prod.contoso.com, a dla zapasowej strony to dr.contoso.com. Istnieje również rekord DNS dla głównej aplikacji znanej jako www.contoso.com.
• Czas wygaśnięcia jest równy lub niższy od Celu Czasu Odzyskiwania (RTO) określonego w umowie SLA ustawionej w organizacji. Jeśli na przykład przedsiębiorstwo ustawia czas odbudowy (RTO) dla odpowiedzi na awarię aplikacji na 60 minut, czas do wygaśnięcia (TTL) powinien być krótszy niż 60 minut, najlepiej, aby był jak najkrótszy. Usługę Azure DNS można skonfigurować do ręcznego przejścia w tryb failover w następujący sposób:
  • Tworzenie strefy DNS
  • Tworzenie rekordów strefy DNS
  • Aktualizowanie rekordu CNAME

1. Utwórz strefę DNS (na przykład www.contoso.com), jak pokazano poniżej:

   

   Rysunek — tworzenie strefy DNS na platformie Azure

2. W tej strefie utwórz trzy rekordy (na przykład — www.contoso.com, prod.contoso.com i dr.contoso.com), jak pokazano poniżej.

   

   Rysunek — tworzenie rekordów strefy DNS na platformie Azure

   W tym scenariuszu strona www.contoso.com ma czas życia (TTL) wynoszący 30 minut, co jest znacznie poniżej określonego celu czasowego odzyskiwania (RTO) i kieruje na stronę produkcyjną prod.contoso.com. Ta konfiguracja obowiązuje podczas normalnych operacji biznesowych. Czas wygaśnięcia prod.contoso.com i dr.contoso.com został ustawiony na 300 sekund lub 5 minut. Możesz użyć usługi monitorowania platformy Azure, takiej jak Azure Monitor lub aplikacja systemu Azure Insights, lub dowolnych rozwiązań do monitorowania partnerów, takich jak Dynatrace. Można nawet używać własnych rozwiązań, które mogą monitorować lub wykrywać błędy na poziomie aplikacji lub infrastruktury wirtualnej.

3. Po wykryciu błędu zmień wartość rekordu, aby wskazywała dr.contoso.com, jak pokazano poniżej:

   

   Rysunek — aktualizowanie rekordu CNAME na platformie Azure

   W ciągu 30 minut, podczas których większość serwerów DNS odświeży buforowany plik strefy, każde zapytanie do www.contoso.com zostanie przekierowane do dr.contoso.com. Możesz również uruchomić następujące polecenie interfejsu wiersza polecenia platformy Azure, aby zmienić wartość CNAME:

     az network dns record-set cname set-record \
     --resource-group 123 \
     --zone-name contoso.com \
     --record-set-name www \
     --cname dr.contoso.com
   

   Ten krok można wykonać ręcznie lub za pomocą automatyzacji. Można to zrobić ręcznie za pomocą konsoli lub interfejsu wiersza polecenia platformy Azure. Za pomocą zestawu Azure SDK i interfejsu API można zautomatyzować aktualizację CNAME, aby nie była wymagana interwencja ręczna. Automatyzację można utworzyć za pomocą funkcji platformy Azure lub w aplikacji do monitorowania innej firmy, a nawet ze środowiska lokalnego.

Następne kroki

• Niezawodność na platformie Azure
• Dowiedz się więcej o usłudze Azure Traffic Manager.
• Dowiedz się więcej o usłudze Azure DNS.