Zuverlässigkeit in Azure DNS

Dieser Artikel enthält ausführliche Informationen zur regionsübergreifenden Notfallwiederherstellung und zur Unterstützung der Geschäftskontinuität für Azure DNS.

Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität

Bei der Notfallwiederherstellung (DR) geht es um die Wiederherstellung nach Ereignissen mit schwerwiegenden Auswirkungen, z. B. Naturkatastrophen oder fehlerhaften Bereitstellungen, die zu Downtime und Datenverlust führen. Unabhängig von der Ursache ist das beste Mittel gegen einen Notfall ein gut definierter und getesteter Notfallplan und ein Anwendungsdesign, die Notfallwiederherstellung aktiv unterstützt. Bevor Sie mit der Erstellung Ihres Notfallwiederherstellungsplans beginnen, lesen Sie die Empfehlungen zum Entwerfen einer Notfallwiederherstellungsstrategie.

Bei DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In einem Modell der gemeinsamen Verantwortung stellt Microsoft sicher, dass die grundlegenden Infrastruktur- und Plattformdienste verfügbar sind. Gleichzeitig replizieren viele Azure-Dienste nicht automatisch Daten oder greifen automatisch auf eine ausgefallene Region zurück, um eine regionsübergreifende Replikation in eine andere aktivierte Region durchzuführen. Für diese Dienste sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die auf Azure Platform as a Service (PaaS)-Angeboten laufen, bieten Funktionen und Anleitungen zur Unterstützung von Notfallwiederherstellung und Sie können dienstspezifische Funktionen zur Unterstützung einer schnellen Wiederherstellung nutzen, um Ihren Notfallwiederherstellungsplan zu entwickeln.

Die Azure DNS Failover-Lösung für Notfallwiederherstellung verwendet den Standard-DNS-Mechanismus für den Failover zum Sicherungsstandort. Die manuelle Option über Azure DNS funktioniert am besten in Verbindung mit dem „verzögert betriebsbereit“-Modus oder dem Steuerlicht-Ansatz.

Da sich der DNS-Server außerhalb der Failover- oder Notfallzone befindet, ist er gegen Downtime isoliert. Sie können ein einfaches Failover-Szenario entwerfen, solange der Betreiber während des Notfalls über eine Netzwerkverbindung verfügt und die Umschaltung vornehmen kann. Wenn es sich um eine skriptgesteuerte Lösung handelt, müssen Sie sicherstellen, dass der Server oder Dienst, auf dem das Skript ausgeführt wird, ebenfalls gegen das Problem isoliert ist, das die Produktionsumgebung betrifft. Außerdem verhindert eine niedrige TTL für die Zone, dass der Resolver über lange Zeiträume hinweg zwischenspeichert, sodass der Kunde innerhalb der RTO auf die Website zugreifen kann. Für den Standby-Modus „verzögert betriebsbereit“ oder den Modus mit „Steuerlicht“ sollte aufgrund des Vorwärmens und anderer administrativer Aktivitäten vor dem Spiegeln genug Zeit eingeplant werden.

Hinweis

Die private Azure-DNS-Zone unterstützt die DNS-Auflösung zwischen virtuellen Netzwerken in Azure-Regionen, auch ohne explizites Peering der virtuellen Netzwerke. Allerdings müssen alle virtuellen Netzwerke mit der privaten DNS-Zone verbunden sein.

Informationen zum Erstellen einer privaten Azure-DNS-Zone mithilfe des Azure-Portals finden Sie in der Schnellstartanleitung: Erstellen einer privaten Azure-DNS-Zone mithilfe des Azure-Portals.

Informationen zum Erstellen eines Azure DNS Private Resolver mithilfe des Azure-Portals finden Sie in der Schnellstartanleitung: Erstellen eines Azure DNS Private Resolvers mithilfe des Azure-Portals.

Notfallwiederherstellung für mehrere Regionen

Es gibt zwei technische Aspekte, die bei der Einrichtung Ihrer Notfallwiederherstellungs-Architektur berücksichtigt werden müssen:

• Verwenden eines Bereitstellungsmechanismus zum Replizieren von Instanzen, Daten und Konfigurationen zwischen primären und Standbyumgebungen. Diese Art der Notfallwiederherstellung kann nativ über Azure Site Recovery erfolgen, siehe hierzu Azure Site Recovery-Dokumentation über Anwendungen/Dienste von Microsoft Azure-Partnern wie Veritas oder NetApp.

• Entwickeln einer Lösung zum Umleiten von Netzwerkdaten-/Webdatenverkehr vom primären Standort zum Standbystandort. Diese Art von Notfallwiederherstellung kann über Azure DNS, Azure Traffic Manager (DNS) oder globale Lastenausgleichsmodule von Drittanbietern erreicht werden.

Dieser Artikel konzentriert sich speziell auf die Planung der Azure DNS-Notfallwiederherstellung.

Einrichten der Notfallwiederherstellung und Ausfallerkennung

Die Azure DNS-Lösung für manuelles Failover für die Notfallwiederherstellung verwendet den Standard-DNS-Mechanismus für ein Failover zum Sicherungsstandort. Die manuelle Option über Azure DNS funktioniert am besten in Kombination mit dem Ansatz Standbymodus „Verzögert betriebsbereit“ oder dem Ansatz mit Steuerlicht.

Abbildung – Manuelles Failover mit Azure DNS

Die Annahmen für die Lösung sind:

• Sowohl primäre als auch sekundäre Endpunkte haben statische IP-Adressen, die sich selten ändern. Für den primären Standort wird z.B. die IP 100.168.124.44 und für den sekundären Standort die IP 100.168.124.43 verwendet.
• Für beide Standorte gibt es ist eine Azure DNS-Zone. Für den primären Standort ist der Endpunkt prod.contoso.com und für den Sicherungsstandort dr.contoso.com. Außerdem gibt es einen DNS-Eintrag für die Hauptanwendung mit der Bezeichnung www.contoso.com.
• Die TTL entspricht der in der Organisation festgelegten RTO-SLA oder liegt darunter. Wenn ein Unternehmen beispielsweise die RTO für die Reaktion der Anwendung auf einen Notfall auf 60 Minuten setzt, dann sollte die TTL weniger als 60 Minuten betragen, am besten je niedriger, desto besser. Sie können Azure DNS wie folgt für manuelles Failover einrichten:
  • Erstellen einer DNS-Zone
  • Erstellen von DNS-Zoneneinträgen
  • Aktualisieren des CNAME-Eintrags

1. Erstellen Sie eine DNS-Zone (z.B. www.contoso.com), wie unten gezeigt:

   

   Abbildung – Erstellen einer DNS-Zone in Azure

2. Erstellen Sie innerhalb dieser Zone drei Einträge (zum Beispiel: www.contoso.com, prod.contoso.com und dr.consoto.com), wie unten gezeigt.

   

   Abbildung – Erstellen von DNS-Zoneneinträgen in Azure

   In diesem Szenario hast der Standort www.contoso.com eine TTL von 30 Minuten, was unter der angegebenen RTO liegt, und zeigt auf den Produktionsstandort prod.contoso.com. Diese Konfiguration wird im normalen Geschäftsbetrieb verwendet. Die TTL von prod.contoso.com und dr.contoso.com wurde auf 300 Sekunden oder 5 Minuten festgelegt. Sie können einen Azure-Überwachungsdienst (z. B. Azure Monitor oder Azure App Insights) oder beliebige Partnerüberwachungslösungen wie Dynatrace verwenden. Sie können sogar selbstentwickelte Lösungen nutzen, mit denen Fehler auf der Ebene der Anwendung oder der virtuellen Infrastruktur überwacht oder erkannt werden können.

3. Sobald ein Fehler erkannt wird, ändern Sie den Wert des Eintrags auf dr.contoso.com, wie unten gezeigt:

   

   Abbildung – Aktualisieren des CNAME-Eintrags in Azure

   Innerhalb von 30 Minuten, in denen die meisten Resolver die zwischengespeicherten Zonendatei aktualisieren wird, werden alle Abfragen an www.contoso.com zu dr.contoso.com umgeleitet. Sie können auch den folgenden Azure CLI-Befehl ausführen, um den CNAME-Wert zu ändern:

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

   Dieser Schritt kann manuell oder per Automatisierung ausgeführt werden. Dies ist über die Konsole oder anhand von Azure CLI möglich. Es können das Azure SDK und die API verwendet werden, um die CNAME-Aktualisierung zu automatisieren, damit kein manueller Eingriff erforderlich ist. Die Automatisierung kann über Azure-Funktionen oder eine Überwachungsanwendung eines Dritten oder auch lokal erstellt werden.

Nächste Schritte

• Zuverlässigkeit in Azure
• Weitere Informationen zu Azure Traffic Manager.
• Weitere Informationen zu Azure DNS.