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.
Azure DNS zapewnia rozpoznawanie nazw przy użyciu infrastruktury Microsoft Azure. Ten artykuł koncentruje się na publicznych strefach DNS, które zwykle tworzysz dla domen, których jesteś właścicielem, i których używasz do publikowania rekordów dla aplikacji i usług dostępnych w Internecie. Nazwy hostów, które rozwiązujesz, są publicznie dostępnymi nazwami DNS, a rozwiązane adresy IP są zwykle publicznymi adresami IP osiągalnymi z Internetu.
Azure DNS to usługa nieregionowa, która nie jest powiązana z określoną strefą dostępności ani regionem Azure.
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 sposób reagowania Azure DNS stref publicznych na błędy przejściowe, awarie strefy dostępności, awarie całego regionu, awarie usług, zagrożenia bezpieczeństwa i błędy konfiguracji, awarie portalu i narzędzia do zarządzania oraz konserwacja usługi. W tym artykule opisano również sposób ochrony i przywracania konfiguracji strefy oraz objaśniono kluczowe wymagania umowy dotyczącej poziomu usług (SLA).
Zalecenia dotyczące wdrażania produkcyjnego pod kątem niezawodności
W przypadku wdrożeń produkcyjnych Azure DNS stref publicznych postępuj zgodnie z poniższymi zaleceniami, aby zwiększyć niezawodność:
Deleguj do wszystkich serwerów nazw: Azure DNS przypisuje cztery serwery nazw do każdej publicznej strefy DNS. Skonfiguruj delegowanie domeny, aby używać wszystkich czterech serwerów nazw. Ta konfiguracja zapewnia izolację błędów i jest wymagana do zakwalifikowania się do umowy SLA Azure DNS.
Skonfiguruj odpowiednie wartości TTL: Ustaw wartości czasu życia (TTL), które równoważą liczbę zapytań z szybkością, z jaką klienci otrzymują informacje o zmianach w rekordach. Niższe wartości TTL umożliwiają klientom szybsze otrzymywanie zmian, ale zwiększają liczbę zapytań. Wyższe wartości TTL zmniejszają liczbę zapytań, ale mogą opóźnić przełączenie awaryjne po zmianie rekordu.
Użyj rekordów aliasów dla obsługiwanych zasobów Azure:Rekordy aliasu automatycznie odzwierciedlają zmiany bazowego zasobu Azure podczas rozpoznawania nazw DNS i pomagają zapobiegać nieaktualnym rekordom DNS.
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 zawierająca zestawy rekordów DNS dla domeny. Zestaw rekordów kojarzy nazwę DNS z wartością, taką jak adres IP lub punkt końcowy. Nazwy rozpoznawane przez publiczną strefę DNS są dostępne za pośrednictwem Internetu.
Aby usługa Azure DNS była autorytatywna dla domeny, zdeleguj domenę do serwerów nazw, które platforma Azure przypisuje podczas tworzenia strefy. Po skonfigurowaniu delegacji utwórz zestawy rekordów dla typów rekordów DNS obsługiwanych przez usługę Azure DNS. Można również utworzyć rekordy aliasów, które odwołują się do zasobów platformy Azure, takich jak publiczne adresy IP, profile usługi Traffic Manager i punkty końcowe usługi Azure Front Door, dzięki czemu rekord DNS pozostaje zsynchronizowany z zasobem docelowym.
Podczas rozwiązywania nazw DNS rekursywne resolwery DNS podążają przez hierarchię DNS, aby dotrzeć do autorytatywnych serwerów nazw usługi Azure DNS dla danej strefy.
Important
Azure DNS rozpoznaje nazwy, ale nie monitoruje kondycji punktu końcowego ani nie kieruje ruchem aplikacji. 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 działa jako usługa nieregionowa i 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 BGP, automatycznie kierują przychodzące żądania rozwiązywania nazw DNS do najbliższej sprawnej infrastruktury Azure DNS.
Warstwa obsługi usługi Azure DNS działa w konfiguracji aktywna-aktywna w dwóch niezależnych stosach obsługi: jeden działa w systemie Linux, a drugi w systemie Windows. Te stosy nie mają kodu i nie mają bazowego sprzętu. Ponieważ są niezależne, usterka, luka w zabezpieczeniach lub awaria, która ma wpływ na jeden stos, nie ma wpływu na drugą. Ta niezależność zmniejsza ryzyko całkowitej awarii usługi spowodowanej pojedynczym punktem krytycznym i pomaga chronić przed niektórymi rodzajami podatności typu zero-day.
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ę zgodnie ze skonfigurowanym zachowaniem ponawiania prób DNS. Od 2 do 5 sekund zazwyczaj jest wystarczający limit czasu 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 niska, klienci muszą wysyłać więcej zapytań do usługi 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 publicznych 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
Strefy DNS są odporne na awarie regionów, ponieważ dane stref są globalnie dostępne i wdrożone w wielu regionach platformy Azure. Jeśli w regionie wystąpi awaria, zasoby wdrożone w tym regionie, takie jak sieci wirtualne i maszyny wirtualne, mogą być niedostępne, ale usługa Azure DNS nadal rozwiązuje rekordy w strefie.
Jeśli masz rozwiązanie, które musi przełączać się między wieloma regionami, takimi jak na potrzeby odzyskiwania po awarii, rozważ użycie Azure Traffic Manager lub Azure Front Door. Usługi te zapewniają możliwość automatycznego przełączenia awaryjnego, z której można skorzystać, jeśli region działa nieprawidłowo.
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 publicznych stref DNS, zobacz Zabezpieczanie wdrożenia Azure DNS oraz Ochrona stref i rekordów DNS.
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 problemy z inną infrastrukturą mogą zakłócać łączność z usługą Azure DNS.
Odporność usługi Azure DNS wynika częściowo z jej globalnie rozproszonej architektury warstwy obsługi typu active-active.
Używanie wielu serwerów nazw
Azure DNS przypisuje cztery serwery nazw do każdej publicznej strefy DNS. Podczas delegowania domeny skonfiguruj wszystkie cztery serwery nazw. Jeśli program rozpoznawania nazw nie może nawiązać połączenia z jednym serwerem nazw, może wysłać zapytanie do innego.
Monitorowanie przerw w działaniu usługi
Użyj Azure Service Health do monitorowania kondycji Azure DNS. Skonfiguruj alerty usługi Service Health , aby otrzymywać powiadomienia o zdarzeniach usługi.
Testowanie awarii usług
Azure Chaos Studio zapewnia błędy, które symulują błędy rozpoznawania nazw DNS z poziomu niektórych typów obciążeń testowych. Te błędy nie powodują awarii w Azure DNS. Agent Chaos Studio udostępnia błąd Awaria DNS, a AKS Chaos Mesh udostępnia funkcję DNS Chaos. Te błędy służą do testowania sposobu reagowania aplikacji i infrastruktury w przypadku niepowodzenia rozpoznawania nazw DNS, takich jak podczas częściowej awarii sieci.
Odporność na awarie narzędzi portalu i zarządzania
Jeśli zarządzasz publiczną strefą DNS w portalu Azure, przygotuj alternatywną ścieżkę zarządzania dla scenariuszy, w których nie można uzyskać dostępu do portalu, zwłaszcza jeśli może być konieczne ponowne skonfigurowanie strefy podczas awarii.
Jeśli portal Azure jest niedostępny, użyj Azure CLI, Azure PowerShell lub infrastruktury jako kodu (IaC), takiego jak Bicep lub Terraform, aby zarządzać publiczną strefą DNS. 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 punktu w czasie dla publicznych stref DNS.
Aby zachować pełną konfigurację zasobów Azure, zdefiniuj publiczne strefy DNS przy użyciu IaC, takich jak Bicep lub Terraform, i zapisz definicje w kontroli źródła. Okresowo przetestuj definicje, aby można było ich użyć do ponownego wdrożenia konfiguracji.
Jako dodatkową opcję odzyskiwania na poziomie rekordów, wyeksportuj plik strefy zgodny z BIND. Importowanie plików strefy ma ograniczenia i nie zachowuje każdego ustawienia zasobu specyficznego dla Azure, więc nie używaj wyeksportowanego pliku strefy jako jedynego artefaktu odzyskiwania. Przejrzyj udokumentowane ograniczenia importu i sprawdź rekordy po przywróceniu strefy.
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, o ile spełnione są pewne warunki. Warunki te obejmują wielokrotne ponawianie nieudanych żądań przez co najmniej 60 kolejnych sekund oraz używanie wszystkich serwerów nazw, które Azure DNS przypisuje do Twojej strefy. Zapoznaj się z dokumentem SLA, aby uzyskać szczegółowe warunki.