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 dotyczy 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. Zanim zaczniesz myśleć o tworzeniu planu odzyskiwania po awarii, zobacz Rekomendacje na potrzeby projektowania strategii odzyskiwania po awarii.

Jeśli chodzi o odzyskiwanie po awarii, firma Microsoft korzysta z modelu wspólnej odpowiedzialności. W modelu wspólnej odpowiedzialności firma Microsoft zapewnia dostępność infrastruktury bazowej i usług platformy. Jednocześnie 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 regionu z włączoną obsługą. W przypadku tych usług ponosisz odpowiedzialność za skonfigurowanie planu odzyskiwania po awarii, który działa dla obciążenia. Większość usług uruchamianych na platformie Azure jako usługa (PaaS) oferuje funkcje i wskazówki dotyczące obsługi odzyskiwania po awarii. Funkcje specyficzne dla usługi umożliwiają szybkie odzyskiwanie w celu ułatwienia opracowania 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 trybu failover, o ile operator ma łączność sieciową podczas awarii i może przerzucić. 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 czas wygaśnięcia dla strefy uniemożliwia buforowanie funkcji rozpoznawania nazw w długich okresach czasu, dzięki czemu klient może uzyskać dostęp do witryny w ramach celu czasu odzyskiwania. W przypadku zimnej rezerwy i światła pilotażowego, ponieważ niektóre wstępne i inne działania administracyjne mogą być wymagane, należy również dać wystarczająco dużo czasu przed dokonaniem przerzucania.

Uwaga

Prywatna strefa DNS platformy Azure obsługuje rozpoznawanie nazw DNS między sieciami wirtualnymi w różnych regionach platformy Azure, nawet bez jawnego komunikacji równorzędnej sieci wirtualnych. Jednak wszystkie sieci wirtualne muszą być połączone z prywatną strefą DNS.

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 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.

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. Załóżmy, że w lokacji głównej adres IP to 100.168.124.44, a adres IP lokacji dodatkowej to 100.168.124.43.
• Strefa DNS platformy Azure istnieje zarówno dla lokacji głównej, jak i dodatkowej. Załóżmy, że w lokacji głównej punkt końcowy jest prod.contoso.com, a lokacja kopii zapasowej jest 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 umowy SLA czasu odzyskiwania ustawionego w organizacji. Jeśli na przykład przedsiębiorstwo ustawia cel czasu odzyskiwania odpowiedzi na awarię aplikacji na wartość 60 minut, czas wygaśnięcia powinien być krótszy niż 60 minut, najlepiej im lepiej. 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.consoto.com), jak pokazano poniżej.

   

   Rysunek — tworzenie rekordów strefy DNS na platformie Azure

   W tym scenariuszu lokacja, www.contoso.com ma czas wygaśnięcia 30 minut, który jest nieco poniżej określonego celu czasu odzyskiwania i wskazuje na lokację produkcyjną prod.contoso.com. Ta konfiguracja jest w trakcie 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 Szczegółowe informacje, lub dowolnych rozwiązań do monitorowania partnerów, takich jak Dynatrace. Można nawet używać rozwiązań dla dorosłych w domu, 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ść funkcji rozpoznawania nazw 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.