Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Prywatne strefy DNS platformy Azure zapewniają bezpieczne rozwiązywanie nazw w sieciach wirtualnych platformy Azure. Można określić zakres prywatnych stref DNS do co najmniej jednej sieci wirtualnej, a organizacje zazwyczaj używają ich do aplikacji wewnętrznych. Nazwy hostów, które rozwiązujesz, to lokalne nazwy DNS, które nie są publicznie dostępne przez internet. Rozwiązane adresy IP są często prywatnymi adresami IP, które nie są dostępne z Internetu. Azure DNS to usługa globalna, która nie jest powiązana z żadną określoną strefą dostępności ani pojedynczym regionem.
W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Microsoft oferuje szereg funkcjonalności wspierających odporność i odzyskiwanie. Odpowiadasz za zrozumienie, jak te możliwości działają w ramach wszystkich używanych usług oraz za wybór tych, które są potrzebne do osiągnięcia Twoich celów biznesowych i celów dotyczących niezawodności.
W tym artykule opisano, jak zapewnić odporność Azure DNS stref prywatnych na różne potencjalne awarie i problemy, w tym błędy przejściowe i awarie całego regionu. Zawiera również kluczowe informacje dotyczące umowy dotyczącej poziomu usług (SLA) Azure DNS stref prywatnych.
Zalecenia dotyczące wdrażania produkcyjnego pod kątem niezawodności
W przypadku obciążeń produkcyjnych zalecamy wykonanie następujących zaleceń:
Skonfiguruj odpowiednie wartości czasu życia: Ustaw wartości czasu życia (TTL), które stanowią kompromis między wydajnością a czasem przywracania. Niższe wartości TTL umożliwiają szybsze przełączenie awaryjne, ale zwiększają liczbę zapytań. Rozważmy 300 sekund (5 minut) jako punkt wyjścia dla obciążeń produkcyjnych.
Fragmentowanie dużych stref DNS: Jeśli masz dużą strefę DNS, rozważ podzielenie strefy na fragmenty , aby zwiększyć ogólną niezawodność i wydajność operacyjną.
Omówienie architektury niezawodności
W tej sekcji opisano niektóre ważne aspekty działania usługi, które są najbardziej istotne z perspektywy niezawodności. W sekcji przedstawiono architekturę logiczną, która zawiera niektóre z zasobów i funkcji wdrażanych i używanych. Omówiono również architekturę fizyczną, która zawiera szczegółowe informacje na temat działania usługi za kulisami.
Architektura logiczna
Wdrażany zasób podstawowy to strefa, która reprezentuje zestaw rekordów DNS mapujących nazwy hostów (nazwy domen) na adresy IP. Nazwy hostów rozpoznawane przez strefę są zwykle lokalnymi nazwami DNS, które nie są publicznie dostępne za pośrednictwem Internetu.
Prywatne strefy DNS są tworzone jako zasoby autonomiczne i łączą je z określonymi sieciami wirtualnymi, tworząc łącza sieci wirtualnej. Gdy żądania DNS pochodzą z klientów w tych sieciach wirtualnych, prywatne strefy DNS uczestniczą w procesie rozpoznawania. Możesz ręcznie utworzyć wpisy w strefie DNS lub skonfigurować automatyczne wyrejestrowanie maszyn wirtualnych w linkach sieci wirtualnej. Prywatne strefy Azure DNS obsługują rozwiązywanie nazw DNS między sieciami wirtualnymi w różnych regionach platformy Azure, nawet bez jawnej konfiguracji komunikacji równorzędnej między sieciami wirtualnymi. Jednak wszystkie sieci wirtualne muszą być połączone z prywatną strefą DNS.
Proces rozpoznawania nazw DNS obejmuje wiele składników, w tym rozpoznawania nazw DNS i warstw pośrednich, które przetwarzają żądania przed dotarciem do autorytatywnych serwerów DNS. Strefy prywatne używają tych samych protokołów DNS i zachowań co strefy publiczne, w tym wartości czasu wygaśnięcia i mechanizmów buforowania.
Important
Niezawodność ogólnego rozwiązania zależy od konfiguracji zasobów, do których odnoszą się rekordy DNS, takich jak maszyny wirtualne i moduły równoważenia obciążenia.
Ten artykuł nie obejmuje tych zasobów, ale ich konfiguracje dostępności mają bezpośredni wpływ na odporność aplikacji. Zapoznaj się z przewodnikami dotyczącymi niezawodności usług platformy Azure w rozwiązaniu, aby dowiedzieć się, jak każda usługa spełnia wymagania dotyczące niezawodności.
Architektura fizyczna
Azure DNS jest usługą inną niż regionalna. Microsoft wdraża swoją infrastrukturę w wielu strefach dostępności w wielu regionach Azure na całym świecie. Ten projekt umożliwia Azure DNS zachowanie odporności podczas awarii strefy dostępności lub regionu, ponieważ infrastruktura w innej strefie lub regionie nadal odpowiada na żądania rozwiązywania problemów.
Globalne protokoły internetowe, takie jak Anycast, DNS i Border Gateway Protocol (BGP), automatycznie kierują przychodzące żądania rozwiązywania nazw DNS do najbliższej sprawnej infrastruktury Azure DNS.
Odporność na błędy przejściowe
Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.
Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.
Azure DNS obsługuje błędy przejściowe za pośrednictwem globalnej infrastruktury DNS.
Jeśli podczas rozpoznawania nazw DNS wystąpi błąd przejściowy, klient lub program rozpoznawania pośredniego powinien ponowić próbę żądania. Odpowiednio skonfiguruj wartości limitu czasu. Limit czasu od 2 do 5 sekund jest zwykle wystarczający dla klienta DNS.
Czas wygaśnięcia każdego rekordu DNS ma również wpływ na sposób, w jaki rozwiązanie obsługuje błędy. Jeśli wartość TTL jest bardzo mała, klienci wysyłają więcej żądań do Azure DNS, co zwiększa prawdopodobieństwo wystąpienia przejściowych błędów. Jeśli wartość TTL jest bardzo wysoka, w przypadku rzeczywistej awarii serwera zaplecza, która wymaga przekierowania ruchu na inny adres IP, klienci mogą doświadczać opóźnień w przełączeniu awaryjnym do czasu wygaśnięcia TTL. Starannie skonfiguruj ustawienia TTL, aby zrównoważyć dostępność, latencję oraz szybkość reakcji.
Odporność na błędy strefy dostępności
Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.
Azure DNS działa jako usługa nieregionowa. Microsoft dystrybuuje swoją infrastrukturę w wielu strefach dostępności w wielu regionach Azure i replikuje zmiany w prywatnych strefach DNS w tej infrastrukturze. Nie wybierasz stref dostępności ani nie konfigurujesz nadmiarowości strefy. Podczas awarii strefy dostępności infrastruktura w innej strefie lub regionie nadal odpowiada na żądania rozwiązywania problemów.
Jeśli zasób wdrożony w jednej strefie dostępności, taki jak maszyna wirtualna, stanie się niedostępny podczas awarii strefy, Azure DNS nadal zwraca skonfigurowany adres IP zasobu, ponieważ nie monitoruje kondycji punktu końcowego. Jeśli przełączysz w tryb failover do zasobu w strefie w dobrej kondycji, odpowiadasz za aktualizowanie rekordu DNS, tak aby klienci używali zasobu w dobrej kondycji. Alternatywnie umieść zasoby za modułem równoważenia obciążenia nadmiarowym strefowo, który kieruje ruch do maszyn wirtualnych w sprawnych strefach.
Odporność na awarie całego regionu
Azure DNS strefy prywatne są odporne na awarie regionów, ponieważ dane strefy są globalnie dostępne. Jeśli region ma awarię, jej sieci wirtualne i zasoby, takie jak maszyny wirtualne, mogą być niedostępne, ale rozpoznawanie nazw nadal działa.
W poniższym przykładzie pokazano, jak dane strefy prywatnej pozostają dostępne w wielu regionach. Strefa azure.contoso.com prywatna jest połączona z sieciami wirtualnymi w trzech regionach: region A, region B i region C. Automatyczne wyrejestrowanie jest włączone w regionach A i B. Na diagramie przedstawiono region A, w którym wystąpiła awaria:
Załóżmy, że tymczasowa awaria występuje w regionie A. Maszyny wirtualne w regionach B i C mogą nadal wysyłać zapytania o nazwy DNS w strefie prywatnej, w tym nazwy, które są autoregisterowane z regionu A. Mogą nadal rozpoznawać adres IP maszyny WIRTUALNEJ VM1 w regionie A, mimo że maszyna WIRTUALNa VM1 nie jest dostępna. Przerwa w działaniu usługi w regionie A nie ma wpływu na rozpoznawanie nazw w innych regionach.
W poprzednim przykładzie nie przedstawiono scenariusza odtwarzania po awarii, w którym rozwiązanie jest przełączane awaryjnie na zastępczą maszynę wirtualną VM1 w innym regionie. Jednak ze względu na to, że strefy prywatne są globalne, można ponownie utworzyć maszynę wirtualną VM1 w sieci wirtualnej innego regionu, aby przejąć obciążenie.
Jeśli tworzysz sieci wirtualne i zasoby sieciowe w wielu regionach, musisz zaplanować i wdrożyć strategię wieloregionową dla aplikacji wymagających przejścia w tryb failover między regionami.
Odporność na zagrożenia bezpieczeństwa i błędną konfigurację
Ataki zabezpieczeń i błędy konfiguracji są dwoma najważniejszymi zagrożeniami dotyczącymi niezawodności stref DNS. Kilka klas ataków jest wymierzonych konkretnie w rozwiązywanie nazw DNS, a przypadkowa błędna konfiguracja może równie poważnie zakłócić działanie obciążeń roboczych.
Aby uzyskać kompleksowe wskazówki dotyczące zabezpieczeń specyficzne dla prywatnych stref DNS, zobacz Ochrona prywatnych stref DNS i rekordów.
Odporność na awarie usług
Azure DNS to wysoce odporna usługa z umową SLA gwarantującą dostępność 100%, gdy aplikacja spełnia określone warunki. Awarie usług są bardzo nietypowe, ale problemy z siecią lub inną infrastrukturą mogą zakłócać łączność z usługą Azure DNS.
Monitorowanie przerw w działaniu usługi
Microsoft nie powiadamia cię automatycznie, gdy region nie działa. Można jednak użyć Azure Service Health, aby zrozumieć ogólną kondycję usługi, w tym awarie regionów, i skonfigurować alerty Service Health w celu powiadomienia o problemach.
Testowanie awarii usług
Azure Chaos Studio udostępnia zestaw błędów do symulowania problemów z rozpoznawaniem nazw DNS. Na przykład agent Chaos Studio udostępnia typ błędu DNS, a Azure Kubernetes Service (AKS) Chaos Mesh zapewnia możliwość chaosu DNS. Tych typów błędów można użyć do przetestowania sposobu reagowania aplikacji i infrastruktury, gdy żądania rozpoznawania nazw DNS kończą się niepowodzeniem, co może wystąpić podczas częściowej awarii sieci.
Odporność na awarie narzędzi portalu i zarządzania
Jeśli zarządzasz strefą DNS w portalu Azure, przygotuj się do scenariuszy, w których nie możesz uzyskać do niej dostępu, zwłaszcza jeśli musisz ponownie skonfigurować strefę DNS podczas awarii platformy.
Do wdrażania Azure DNS stref prywatnych i zarządzania nimi można użyć różnych narzędzi. Dowiedz się, jak zarządzać strefą prywatną przy użyciu Azure CLI lub Azure PowerShell. Alternatywnie użyj infrastruktury jako kodu (IaC), takiego jak Bicep lub Terraform, aby wdrożyć i skonfigurować strefę prywatną. Te narzędzia pozostają operacyjne, nawet jeśli portal Azure działa w trybie ograniczonej funkcjonalności.
Tworzenie kopii zapasowej i przywracanie
Azure DNS jest usługą bezstanową. Nie zapewnia zarządzanych kopii zapasowych ani przywracania do określonego momentu dla prywatnych stref DNS.
Aby zachować pełną konfigurację zasobów Azure, zdefiniuj prywatne strefy DNS przy użyciu IaC, takich jak Bicep lub Terraform, i zapisz definicje w kontroli źródła. Okresowo testuj definicje, aby można było ich użyć do ponownego wdrożenia konfiguracji.
Odporność usługi na prace konserwacyjne
Firma Microsoft regularnie stosuje aktualizacje usług i wykonuje inną konserwację. Platforma Azure automatycznie obsługuje te działania, zapewniając bezproblemową i przejrzystą konserwację. Podczas zdarzeń konserwacji nie przewiduje się przestoju, chyba że poinformowano Cię o zaplanowanej konserwacji Azure Service Health.
Umowa dotycząca poziomu usług
Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.
Azure DNS zapewnia umowę SLA dotyczącą dostępności 100% dla prawidłowych odpowiedzi na zapytania DNS w przypadku spełnienia określonych warunków. Te warunki obejmują ponawianie nieudanych żądań przez co najmniej 60 kolejnych sekund. Zapoznaj się z dokumentem SLA, aby uzyskać szczegółowe warunki.