Checkliste für Resilienz für bestimmte Azure-Dienste

  • Artikel

Bei der Resilienz (Robustheit) geht es um die Möglichkeit, nach Ausfällen für ein System eine Wiederherstellung durchzuführen und die Betriebsbereitschaft sicherzustellen. Jede Technologie verfügt über ihre eigenen speziellen Fehlermodi, die Sie beim Entwerfen und Implementieren Ihrer Anwendung berücksichtigen müssen. Verwenden Sie diese Checkliste, um die Resilienzaspekte für bestimmte Azure-Dienste zu überprüfen. Weitere Informationen zum Entwerfen resilienter Anwendungen finden Sie unter Entwerfen zuverlässiger Azure-Anwendungen.

App Service

Verwenden Sie den Standard- oder Premium-Tarif. Diese Tarife unterstützen Stagingslots und automatisierte Sicherungen. Weitere Informationen hierzu finden Sie unter Azure App Service-Pläne – Detaillierte Übersicht.

Vermeiden Sie zentrales Hoch- oder Herunterskalieren. Wählen Sie stattdessen einen Tarif und eine Instanzgröße aus, der bzw. die Ihre Leistungsanforderungen unter typischer Last erfüllt, und skalieren Sie die Instanzen auf, um Änderungen beim Datenverkehrsvolumen zu bewältigen. Durch zentrales Hoch- oder Herunterskalieren kann ein Neustart der Anwendung ausgelöst werden.

Speichern Sie die Konfiguration als App-Einstellungen. Verwenden Sie App-Einstellungen, um die Konfigurationseinstellungen als App-Einstellungen zu speichern. Definieren Sie die Einstellungen in den Resource Manager-Vorlagen oder mithilfe von PowerShell, sodass Sie sie als Teil einer automatisierten Bereitstellung/Aktualisierung anwenden können, um die Zuverlässigkeit zu erhöhen. Weitere Informationen finden Sie unter Konfigurieren von Web-Apps in Azure App Service.

Erstellen Sie separate App Service-Pläne für die Produktion und für Tests. Verwenden Sie keine Slots Ihrer Produktionsbereitstellung zu Testzwecken. Alle Apps in einem App Service-Plan nutzen die gleichen VM-Instanzen. Wenn Sie Produktions- und Testbereitstellungen in den gleichen Plan aufnehmen, kann sich dies negativ auf die Produktionsbereitstellung auswirken. Auslastungstests können z.B. den aktiven Produktionsstandort beeinträchtigen. Indem Sie Testbereitstellungen in einen separaten Plan aufnehmen, isolieren Sie sie von der Produktionsversion.

Trennen Sie Web-Apps von Web-APIs. Wenn zu Ihrer Lösung ein Web-Front-End und eine Web-API gehören, sollten Sie sie in getrennte App Service-Apps aufnehmen. Dieser Entwurf erleichtert es, die Lösung nach Workloads zu zerlegen. Sie können dann die Web-App und die API in separaten App Service-Plänen ausführen, sodass sie unabhängig skaliert werden können. Wenn Sie diesen Grad an Skalierbarkeit anfänglich nicht benötigen, können Sie die Apps im gleichen Plan bereitstellen und sie später bei Bedarf in separate Pläne verschieben.

Stellen Sie zonenredundante App Service-Pläne bereit. In unterstützten Regionen können App Service-Pläne zonenredundant bereitgestellt werden, d. h. die Instanzen werden automatisch auf Verfügbarkeitszonen verteilt. App Service teilt den Datenverkehr automatisch zwischen den Zonen auf und sorgt für ein Failover, wenn eine Zone ausfällt. Weitere Informationen finden Sie unter Migrieren von App Service zur Unterstützung von Verfügbarkeitszonen.

Vermeiden Sie die Verwendung der App Service-Sicherungsfunktion, um Azure SQL-Datenbanken zu sichern. Verwenden Sie stattdessen automatisierte SQL-Datenbanksicherungen. Bei der App Service-Sicherung wird die Datenbank in eine SQL-BACPAC-Datei exportiert, und dies kostet DTUs.

Führen Sie die Bereitstellung in einem Stagingslot durch. Erstellen Sie einen Bereitstellungsslot für das Staging. Stellen Sie Anwendungsupdates im Stagingslot bereit, und überprüfen Sie die Bereitstellung, bevor Sie sie in die Produktion übertragen. Dies reduziert die Wahrscheinlichkeit fehlerhafter Updates in der Produktion. Darüber hinaus wird sichergestellt, dass alle Instanzen vorbereitet sind, bevor sie in die Produktion übertragen werden. Viele Anwendungen weisen eine erhebliche Aufwärmdauer und Kaltstartzeit auf. Weitere Informationen finden Sie unter Einrichten von Stagingumgebungen für Web-Apps in Azure App Service.

Erstellen Sie einen Bereitstellungsslot, um die letzte als funktionierend bekannte (LKG) Bereitstellung zu speichern. Wenn Sie ein Update in der Produktion bereitstellen, verschieben Sie die vorherige Produktionsbereitstellung in den LKG-Slot. Dies erleichtert die Zurücksetzung einer fehlerhaften Bereitstellung. Wenn Sie später ein Problem feststellen, können Sie schnell die LKG-Version wiederherstellen. Weitere Informationen finden Sie unter Einfache Webanwendung.

Aktivieren Sie die Diagnoseprotokollierung, einschließlich der Anwendungsprotokollierung und der Webserverprotokollierung. Protokollierung ist wichtig für die Überwachung und die Diagnose. Weitere Informationen finden Sie unter Aktivieren der Diagnoseprotokollierung für Web-Apps in Azure App Service.

Speichern Sie Protokolle im Blobspeicher. Dies erleichtert das Erfassen und Analysieren der Daten.

Erstellen Sie ein separates Speicherkonto für Protokolle. Verwenden Sie nicht das gleiche Speicherkonto für Protokolle und Anwendungsdaten. Dadurch wird verhindert, dass die Protokollierung die Anwendungsleistung verringert.

Überwachen der Leistung Verwenden Sie einen Leistungsüberwachungsdienst wie New Relic oder Application Insights, um Leistung und Verhalten der Anwendung unter Last zu überwachen. Durch die Leistungsüberwachung erhalten Sie in Echtzeit Einblicke in die Anwendung. Dadurch können Sie Probleme diagnostizieren und eine Ursachenanalyse von Fehlern durchführen.

Azure Load Balancer

Wählen Sie die Standard-SKU aus. Load Balancer Standard bietet gegenüber der Basic-SKU eine höhere Zuverlässigkeit – durch Verfügbarkeitszonen und Zonenresilienz. Dies bedeutet, dass Ihr zonenredundanter Standard Load Balancer beim Ausfall einer Zone nicht betroffen ist. So ist sichergestellt, dass Ihre Bereitstellungen Zonenausfälle in einer Region überstehen. Darüber hinaus unterstützt Load Balancer Standard einen globalen Lastenausgleich, um sicherzustellen, dass Ihre Anwendung nicht von Regionsausfällen betroffen ist.

Stellen Sie mindestens zwei Instanzen bereit. Stellen Sie Azure Load Balancer mit mindestens zwei Instanzen im Back-End bereit. Wenn Sie nur eine einzige Instanz bereitstellen, kann ein Single Point of Failure entstehen. Im Hinblick auf eine Ausbaureserve sollten Sie Load Balancer mit Virtual Machine Scale Sets koppeln.

Verwenden Sie Ausgangsregeln. Ausgangsregeln stellen sicher, dass es nicht zu Verbindungsfehlern aufgrund einer Auslastung der Source Network Address Translation (SNAT)-Ports kommt. ERfahren Sie mehr über die ausgehende Konnektivität. Zwar tragen Ausgangsregeln zur Optimierung der Lösung für kleine bis mittlere Bereitstellungen bei, doch empfiehlt es sich trotzdem, für Produktionsworkloads Load Balancer Standard oder eine Subnetzbereitstellung mit VNet network address translation (NAT) zu koppeln.

Öffentliche Azure-IP-Adressen

Wählen Sie die Standard-SKU aus. Im Gegensatz zu grundlegenden öffentlichen IP-Adressen bieten standardmäßige öffentliche IP-Adressen Verfügbarkeitszonen und Zonenresilienz. Wenn Sie einen Dienst verwenden, der eine öffentliche IP-Adresse erfordert, wählen Sie eine zonenredundante öffentliche IP-Adresse aus. Führen Sie für vorhandene IP-Adressen ein Upgrade von „Basic“ auf „Standard“ durch, um von den Vorteilen einer Zonenredundanz standardmäßig zu profitieren.

Application Gateway

Stellen Sie mindestens zwei Instanzen bereit. Stellen Sie Application Gateway mit mindestens zwei Instanzen bereit. Eine einzelne Instanz ist ein Single Point of Failure. Verwenden Sie zwei oder mehr Instanzen für Redundanz und Skalierbarkeit. Um sich für die Vereinbarung zum Servicelevel (SLA) zu qualifizieren, müssen Sie zwei oder mehr mittelgroße oder größere Instanzen bereitstellen.

Azure Cosmos DB

Konfigurieren Sie Zonenredundanz. Wenn Sie Zonenredundanz nutzen, repliziert Azure Cosmos DB alle Schreibvorgänge synchron über Verfügbarkeitszonen hinweg. Bei einem Zonenausfall wird automatisch ein Failover durchgeführt. Weitere Informationen finden Sie unter Erzielen von Hochverfügbarkeit mit Azure Cosmos DB.

Replizieren Sie die Datenbank zwischen Regionen. Azure Cosmos DB ermöglicht Ihnen die Zuordnung einer beliebigen Anzahl von Azure-Regionen zu einem Azure Cosmos DB-Datenbankkonto. Eine Azure Cosmos DB-Datenbank kann eine Schreibregion und mehrere Leseregionen aufweisen. Bei einem Fehler in der Schreibregion können Sie ein anderes Replikat für Lesezugriff verwenden. Das Client-SDK verarbeitet dies automatisch. Sie können auch ein Failover der Schreibregion auf eine andere Region ausführen. Weitere Informationen finden Sie unter Wie werden Daten mit Azure Cosmos DB global verteilt?.

Event Hubs

Verwenden Sie Prüfpunkte. Ein Ereignisconsumer sollte seine aktuelle Position in vordefinierten Intervallen in einen beständigen Speicher schreiben. Falls für den Consumer ein Fehler auftritt (z.B. ein Absturz des Consumers oder Ausfall des Hosts), kann eine neue Instanz das Lesen des Datenstroms dann ab der zuletzt aufgezeichneten Position fortsetzen. Weitere Informationen finden Sie unter Ereignisconsumer.

Regeln Sie den Umgang mit doppelten Nachrichten. Wenn ein Ereignisconsumer ausfällt, wird die Nachrichtenverarbeitung ab dem letzten aufgezeichneten Prüfpunkt fortgesetzt. Alle Nachrichten, die nach dem letzten Prüfpunkt bereits verarbeitet wurden, werden erneut verarbeitet. Aus diesem Grund muss Ihre Logik für die Nachrichtenverarbeitung idempotent sein, oder die Anwendung muss eine Deduplizierung von Nachrichten durchführen können.

Behandeln Sie Ausnahmen. Ein Ereignisconsumer verarbeitet einen Batch mit Nachrichten normalerweise in einer Schleife. Es ist ratsam, Ausnahmen in dieser Verarbeitungsschleife zu verarbeiten, damit kein gesamter Batch mit Nachrichten verloren geht, wenn eine einzelne Nachricht eine Ausnahme verursacht.

Verwenden Sie eine Warteschlange für unzustellbare Nachrichten. Wenn die Verarbeitung einer Nachricht zu einem nicht vorübergehenden Fehler führt, sollten Sie die Nachricht in eine Warteschlange für unzustellbare Nachrichten einreihen, damit Sie den Status nachverfolgen können. Je nach Szenario können Sie versuchen, die Nachricht später noch einmal zu verarbeiten, eine kompensierende Transaktion anzuwenden oder eine andere Aktion durchzuführen. Beachten Sie, dass Event Hubs nicht über eine integrierte Funktionalität für Warteschlangen für unzustellbare Nachrichten verfügt. Sie können Azure Queue Storage oder Service Bus verwenden, um eine Warteschlange für unzustellbare Nachrichten zu implementieren, oder Azure Functions oder einen anderen Mechanismus für die Ereignisverarbeitung nutzen.

Konfigurieren Sie Zonenredundanz. Wenn Zonenredundanz für Ihren Namespace aktiviert ist, repliziert Event Hubs automatisch Änderungen zwischen mehreren Verfügbarkeitszonen. Wenn eine Verfügbarkeitszone ausfällt, wird automatisch ein Failover durchgeführt. Weitere Informationen finden Sie unter Verfügbarkeitszonen.

Implementieren Sie die Notfallwiederherstellung (DR) per Failover zu einem sekundären Event Hubs-Namespace. Weitere Informationen finden Sie unter Georedundante Notfallwiederherstellung in Azure Event Hubs.

Azure Cache for Redis

Konfigurieren Sie Zonenredundanz. Wenn Zonenredundanz für Ihren Cache aktiviert ist, verteilt Azure Cache for Redis die VMs, die Ihren Cache hosten, auf mehrere Verfügbarkeitszonen. Zonenredundanz bietet Hochverfügbarkeit und Fehlertoleranz bei einem Ausfall des Rechenzentrums. Weitere Informationen finden Sie unter Aktivieren der Zonenredundanz für Azure Cache for Redis.

Konfigurieren der Georeplikation. Die Georeplikation bietet einen Mechanismus zum Verknüpfen von zwei Azure Cache for Redis-Instanzen im Premium-Tarif. In den primären Cache geschriebene Daten werden in einen sekundären schreibgeschützten Cache repliziert. Weitere Informationen finden Sie unter Konfigurieren der Georeplikation für Azure Cache for Redis.

Konfigurieren der Redis-Datenpersistenz. Mithilfe der Redis-Persistenz können Sie die in Redis gespeicherten Daten dauerhaft speichern. Sie können zudem Momentaufnahmen erstellen und die Daten sichern, die Sie dann im Fall eines Hardwarefehlers laden können. Weitere Informationen finden Sie unter Konfigurieren von Datenpersistenz für Azure Cache for Redis vom Typ „Premium“.

Wenn Sie Azure Cache for Redis als temporären Zwischenspeicher für Daten und nicht als permanenten Speicher verwenden, sind diese Empfehlungen möglicherweise nicht relevant.

Stellen Sie mehr als ein Replikat bereit. Verwenden Sie mindestens zwei Replikate für hohe Verfügbarkeit für Lesezugriff oder drei für hohe Verfügbarkeit für Lese-/Schreibzugriff.

Verwenden Sie Zonenredundanz. Sie können Cognitive Search-Replikate über mehrere Verfügbarkeitszonen hinweg bereitstellen. Auf diese Weise bleibt Ihr Dienst auch bei Rechenzentrumsausfällen betriebsbereit. Weitere Informationen finden Sie unter Zuverlässigkeit in Azure Cognitive Search.

Konfigurieren Sie Indexer für Bereitstellungen in mehreren Regionen. Für eine Bereitstellung in mehreren Regionen sollten Sie die Optionen für Kontinuität bei der Indizierung in Betracht ziehen.

  • Wenn die Datenquelle georepliziert wird, sollten Sie im Allgemeinen die Indexer der einzelnen regionalen Azure Cognitive Search-Dienste auf das eigene lokale Datenquellenreplikat verweisen. Dieser Ansatz wird jedoch für große Datasets, die in Azure SQL-Datenbank gespeichert sind, nicht empfohlen. Der Grund dafür ist, dass Azure Cognitive Search nur für primäre Replikate, nicht aber für sekundäre SQL-Datenbankreplikate eine inkrementelle Indizierung durchführen kann. Verweisen Sie stattdessen alle Indexer auf das primäre Replikat. Verweisen Sie den Azure Cognitive Search-Indexer nach einem Failover auf das neue primäre Replikat.

  • Wenn die Datenquelle nicht georepliziert wird, verweisen Sie mehrere Indexer auf die gleiche Datenquelle, damit Azure Cognitive Search-Dienste in mehreren Regionen kontinuierlich und unabhängig die Datenquelle indizieren. Weitere Informationen finden Sie unter Überlegungen zur Leistung und Optimierung von Azure Search.

Service Bus

Verwendung des Premium-Tarifs für Produktionsworkloads: Service Bus Premium-Messaging verfügt über dedizierte und reservierte Verarbeitungsressourcen sowie über Speicherkapazität zur Unterstützung der Vorhersagbarkeit von Leistung und Durchsatz. Mit dem Tarif für Premium-Messaging haben Sie außerdem Zugriff auf neue Features, die zunächst nur für Premium-Kunden verfügbar sind. Sie können die Anzahl von Messagingeinheiten basierend auf den erwarteten Workloads festlegen.

Umgang mit doppelten Nachrichten: Wenn für einen Herausgeber sofort nach dem Senden einer Nachricht ein Fehler auftritt oder es zu Netzwerk- oder Systemproblemen kommt, wird die Zustellung der Nachricht ggf. nicht aufgezeichnet, sodass sie unter Umständen zweimal an das System gesendet wird. Dieses Problem kann für Service Bus gelöst werden, indem die Duplikaterkennung aktiviert wird. Weitere Informationen finden Sie unter Duplikaterkennung.

Umgang mit Ausnahmen: Messaging-APIs generieren Ausnahmen, wenn ein Benutzerfehler, Konfigurationsfehler oder anderer Fehler auftritt. Im Clientcode (Absender und Empfänger) sollten diese Ausnahmen per Code verarbeitet werden. Dies ist besonders bei der Batchverarbeitung wichtig, bei der die Verarbeitung von Ausnahmen genutzt werden kann, um zu vermeiden, dass ein gesamter Batch mit Nachrichten verloren geht. Weitere Informationen finden Sie unter Service Bus-Messagingausnahmen.

Wiederholungsrichtlinie: Mit Service Bus können Sie die beste Wiederholungsrichtlinie für Ihre Anwendungen auswählen. Bei der Standardrichtlinie sind maximal neun Wiederholungsversuche zulässig, und die Wartezeit beträgt 30 Sekunden. Diese Werte können aber angepasst werden. Weitere Informationen finden Sie unter Wiederholungsrichtlinie – Service Bus.

Verwendung einer Warteschlange für unzustellbare Nachrichten: Wenn eine Nachricht auch nach mehreren Wiederholungsversuchen nicht verarbeitet oder an einen Empfänger zugestellt werden kann, wird sie in eine Warteschlange für unzustellbare Nachrichten verschoben. Implementieren Sie einen Prozess zum Lesen von Nachrichten aus der Warteschlange für unzustellbare Nachrichten, Durchführen einer Überprüfung und Beheben des Problems. Je nach Szenario können Sie einen Wiederholungsversuch mit der unveränderten Nachricht durchführen, vor der Wiederholung zuerst Änderungen vornehmen oder die Nachricht verwerfen. Weitere Informationen finden Sie unter Übersicht über Service Bus-Warteschlangen für unzustellbare Nachrichten.

Verwenden Sie Zonenredundanz. Wenn Zonenredundanz für Ihren Namespace aktiviert ist, repliziert Service Bus automatisch Änderungen zwischen mehreren Verfügbarkeitszonen. Wenn eine Verfügbarkeitszone ausfällt, wird automatisch ein Failover durchgeführt. Weitere Informationen finden Sie unter Best Practices zum Schützen von Anwendungen vor Service Bus-Ausfällen und Notfällen.

Verwendung der georedundanten Notfallwiederherstellung: Mit der georedundanten Notfallwiederherstellung wird sichergestellt, dass die Verarbeitung der Daten auch in einer anderen Region bzw. einem anderen Rechenzentrum weiterhin funktioniert, wenn aufgrund einer Katastrophe eines gesamte Azure-Region bzw. ein Rechenzentrum ausfällt. Weitere Informationen finden Sie unter Georedundante Notfallwiederherstellung in Azure Service Bus.

Storage

Verwenden Sie zonenredundanten Speicher (ZRS). Zonenredundanter Speicher (ZRS): Die Daten werden synchron über drei Azure-Verfügbarkeitszonen hinweg in der primären Region kopiert. Wenn eine Verfügbarkeitszone ausfällt, führt Azure Storage automatisch ein Failover auf eine andere Zone durch. Weitere Informationen finden Sie unter Azure Storage-Redundanz.

Konfigurieren Sie bei Verwendung von Georedundanz den Lesezugriff. Wenn Sie eine Architektur mit mehreren Regionen verwenden, verwenden Sie eine geeignete Speicherebene für globale Redundanz. Mit georedundantem Speicher mit Lesezugriff (RA-GRS) oder geozonenredundantem Speicher mit Lesezugriff (RA-GZRS) werden Ihre Daten in eine sekundäre Region repliziert. RA-GRS verwendet lokal redundanten Speicher (LRS) in der primären Region, während RA-GZRS zonenredundanten Speicher (ZRS) in der primären Region verwendet. Beide Konfigurationen bieten schreibgeschützten Zugriff auf Ihre Daten in der sekundären Region. Wenn in der primären Region der Speicher ausfällt, kann die Anwendung die Daten aus der sekundären Region lesen, wenn Sie sie unter Einbeziehung dieser Möglichkeit entworfen haben. Weitere Informationen finden Sie unter Azure Storage-Redundanz.

Verwenden Sie verwaltete Datenträger für VM-Datenträger. Verwaltete Datenträger ermöglichen eine höhere Zuverlässigkeit für VMs in einer Verfügbarkeitsgruppe, da die Datenträger ausreichend voneinander isoliert sind, um Single Points of Failure zu vermeiden. Zudem gelten für verwaltete Datenträger keine IOPS-Grenzwerte von VHDs, die in einem Speicherkonto erstellt wurden. Weitere Informationen finden Sie unter Verwalten der Verfügbarkeit virtueller Windows-Computer in Azure.

Erstellen Sie für Queue Storage eine Sicherungswarteschlange in einer anderen Region. Für Queue Storage hat ein schreibgeschütztes Replikat nur eingeschränkten Nutzen, da Sie Elemente nicht in die Warteschlange stellen oder daraus entfernen können. Erstellen Sie stattdessen eine Sicherungswarteschlange in einem Speicherkonto in einer anderen Region. Kommt es zu einem Azure Storage-Ausfall, kann die Anwendung die Sicherungswarteschlange verwenden, bis die primäre Region wieder verfügbar ist. Auf diese Weise kann die Anwendung während des Ausfalls damit fortfahren, neue Anforderungen zu verarbeiten.

SQL-Datenbank

Verwenden Sie den Standard- oder Premium-Tarif. Diese Tarife bieten einen längeren Zeitraum für die Point-in-Time-Wiederherstellung (35 Tage). Weitere Informationen finden Sie unter SQL-Datenbankoptionen und -leistung.

Aktivieren Sie die SQL-Datenbanküberwachung. Die Überwachung kann verwendet werden, um böswillige Angriffe oder Benutzerfehler zu diagnostizieren. Weitere Informationen finden Sie unter Erste Schritte mit der SQL-Datenbanküberwachung.

Verwenden Sie die aktive Georeplikation, um ein lesbares sekundäres Replikat in einer anderen Region zu erstellen. Falls Ihre primäre Datenbank ausfällt oder einfach offline geschaltet werden muss, können Sie ein manuelles Failover auf die sekundäre Datenbank ausführen. Bis Sie ein Failover ausführen, bleibt die sekundäre Datenbank schreibgeschützt. Weitere Informationen finden Sie unter Aktive Georeplikation in Azure SQL-Datenbank.

Verwenden Sie Sharding. Erwägen Sie die Verwendung von Sharding, um die Datenbank horizontal zu partitionieren. Sharding kann Fehlerisolation bereitstellen. Weitere Informationen finden Sie unter Horizontales Hochskalieren mit Azure SQL-Datenbank.

Verwenden Sie die Point-in-Time-Wiederherstellung für eine Wiederherstellung nach einem menschlichen Fehler. Mit der Point-in-Time-Wiederherstellung wird Ihre Datenbank zu einem früheren Zeitpunkt wiederhergestellt. Weitere Informationen finden Sie unter Wiederherstellen einer Azure SQL-Datenbank mit automatisierten Datenbanksicherungen.

Verwenden Sie die Geowiederherstellung für die Wiederherstellung nach einem Dienstausfall. Mit der Geowiederherstellung wird eine Datenbank auf der Basis einer georedundanten Sicherung wiederhergestellt. Weitere Informationen finden Sie unter Wiederherstellen einer Azure SQL-Datenbank mit automatisierten Datenbanksicherungen.

Azure Synapse Analytics

Deaktivieren Sie die Geosicherung nicht. Azure Synapse Analytics erstellt standardmäßig alle 24 Stunden eine vollständige Sicherung Ihrer Daten für die Notfallwiederherstellung in Dedicated SQL-Pool. Die Deaktivierung dieser Funktion wird nicht empfohlen. Weitere Informationen finden Sie unter Sicherung und Wiederherstellung in Azure SQL Data Warehouse.

SQL Server auf einem virtuellen Computer

Sichern Sie die Datenbank. Wenn Sie bereits Azure Backup zum Sichern Ihrer VMs verwenden, erwägen Sie die Nutzung von Azure Backup für SQL Server-Workloads mit DPM. Bei dieser Vorgehensweise gibt es eine Sicherungsadministratorrolle für die Organisation und ein einheitliches Wiederherstellungsverfahren für VMs und SQL Server. Verwenden Sie andernfalls die verwaltete SQL Server-Sicherung in Microsoft Azure.

Traffic Manager

Führen Sie manuelle Failbacks aus. Führen Sie nach einem Traffic Manager-Failover ein manuelles Failback und kein automatische Failback aus. Überprüfen Sie vor einem Failback, ob alle Subsysteme der Anwendung fehlerfrei sind. Andernfalls könnte eine Situation eintreten, bei der die Anwendung zwischen den Rechenzentren hin und her wechselt. Weitere Informationen finden Sie unter Ausführen von VMs in mehreren Regionen für Hochverfügbarkeit.

Erstellen Sie einen Endpunkt für Integritätstests. Erstellen Sie einen benutzerdefinierten Endpunkt, der die Gesamtintegrität der Anwendung angibt. Dies ermöglicht Traffic Manager, ein Failover auszuführen, wenn ein kritischer Pfad und nicht nur das Front-End ausfällt. Der Endpunkt sollte einen HTTP-Fehlercode zurückgeben, wenn eine kritische Abhängigkeit fehlerhaft oder nicht erreichbar ist. Melden Sie jedoch keine Fehler für nicht kritische Dienste. Andernfalls könnte der Integritätstest ein Failover auslösen, wenn es nicht erforderlich ist, und falsch positive Ergebnisse erstellen. Weitere Informationen finden Sie unter Traffic Manager-Endpunktüberwachung und -failover.

Virtual Machines

Vermeiden Sie es, eine Produktionsworkload auf einer einzigen VM auszuführen. Die Bereitstellung einer einzigen VM ist bei geplanten oder ungeplanten Wartungen nicht zuverlässig. Nehmen Sie stattdessen mehrere VMs in eine Verfügbarkeitsgruppe oder eine VM-Skalierungsgruppe auf, der sie einen Lastenausgleich vorschalten.

Geben Sie bei der Bereitstellung der VM eine Verfügbarkeitsgruppe an. Derzeit gibt es keine Möglichkeit, einer Verfügbarkeitsgruppe nach dem Bereitstellen der VM eine VM hinzuzufügen. Sie müssen beim Hinzufügen einer neuen VM zu einer vorhandenen Verfügbarkeitsgruppe eine NIC für die VM erstellen und die NIC dem Back-End-Adresspool des Lastenausgleichs hinzufügen. Andernfalls leitet der Lastenausgleich den Netzwerkdatenverkehr nicht an die VM weiter.

Nehmen Sie jede Logikschicht in eine separate Verfügbarkeitsgruppe auf. Fügen Sie in einer Anwendung mit n-Schichten VMs aus verschiedenen Schichten nicht in die gleiche Verfügbarkeitsgruppe ein. VMs in einer Verfügbarkeitsgruppe werden über Fehlerdomänen (FDs) und Updatedomänen (UD) verteilt. Um den Redundanzvorteil von FDs und UDs nutzen zu können, muss jedoch jede VM in der Verfügbarkeitsgruppe die gleichen Clientanforderungen verarbeiten können.

Replizieren Sie virtuelle Computer mithilfe von Azure Site Recovery. Wenn Sie virtuelle Azure-Computer mit Site Recovery replizieren, werden kontinuierlich alle VM-Datenträger asynchron in der Zielregion repliziert. Die Wiederherstellungspunkte werden im Abstand von wenigen Minuten erstellt. Dadurch erzielen Sie einen RPO-Wert (Recovery Point Objective) von wenigen Minuten. Sie können beliebig viele Notfallwiederherstellungsübungen durchführen, ohne die Produktionsanwendung oder die laufende Replikation zu beeinträchtigen. Weitere Informationen finden Sie unter Durchführen eines Notfallwiederherstellungsverfahrens in Azure.

Wählen Sie die richtige VM-Größe basierend auf den Leistungsanforderungen aus. Beginnen Sie beim Verlagern einer vorhandenen Workload in Azure mit der VM-Größe, die Ihren lokalen Servern am ehesten entspricht. Messen Sie dann die Leistung Ihrer tatsächlichen Workload hinsichtlich CPU, Arbeitsspeicher und Datenträger-IOPS, und passen Sie die Größe bei Bedarf an. Dadurch wird sichergestellt, dass sich die Anwendung in einer Cloudumgebung wie erwartet verhält. Wenn Sie mehrere NICs benötigen, beachten Sie zudem den NIC-Grenzwert für jede Größe.

Verwenden Sie verwaltete Datenträger für VHDs. Verwaltete Datenträger ermöglichen eine höhere Zuverlässigkeit für VMs in einer Verfügbarkeitsgruppe, da die Datenträger ausreichend voneinander isoliert sind, um Single Points of Failure zu vermeiden. Zudem gelten für verwaltete Datenträger keine IOPS-Grenzwerte von VHDs, die in einem Speicherkonto erstellt wurden. Weitere Informationen finden Sie unter Verwalten der Verfügbarkeit virtueller Windows-Computer in Azure.

Installieren Sie Anwendungen auf einem Datenträger für Daten und nicht auf dem Datenträger für das Betriebssystem. Andernfalls kann der Grenzwert für die Datenträgergröße erreicht werden.

Verwenden Sie Azure Backup zum Sichern von VMs. Sicherungen schützen vor versehentlichen Datenverlusten. Weitere Informationen finden Sie unter Schützen von Azure-VMs mit einem Recovery Services-Tresor.

Aktivieren von Diagnoseprotokollen Fügen Sie grundlegende Integritätsmetriken, Infrastrukturprotokolle und Startdiagnosen hinzu. Startdiagnosen dienen dazu, einen Fehler beim Startvorgang zu untersuchen, wenn sich Ihre VM in einem nicht startfähigen Zustand befindet. Weitere Informationen finden Sie unter Übersicht über Azure-Diagnoseprotokolle.

Konfigurieren Sie Azure Monitor. Weitere Informationen zum Erfassen und Analysieren von Überwachungsdaten von virtuellen Azure-Computern, einschließlich des Gastbetriebssystems und der darin ausgeführten Workloads, finden Sie unter Azure Monitor und Schnellstart: Azure Monitor.

Virtual Network

Um öffentliche IP-Adressen zuzulassen oder zu blockieren, fügen Sie dem Subnetz eine Netzwerksicherheitsgruppe hinzu. Blockieren Sie den Zugriff von böswilligen Benutzern, oder lassen Sie nur Benutzer, die über Zugriffsberechtigungen verfügen, auf die Anwendung zugreifen.

Erstellen Sie einen benutzerdefinierten Integritätstest. Integritätstests durch den Lastenausgleich können für HTTP oder TCP durchgeführt werden. Wenn eine VM auf einem HTTP-Server ausgeführt wird, ist der HTTP-Test ein besserer Indikator für den Integritätsstatus als ein TCP-Test. Verwenden Sie für einen HTTP-Test einen benutzerdefinierten Endpunkt, der die Gesamtintegrität der Anwendung meldet, einschließlich aller kritischen Abhängigkeiten. Weitere Informationen finden Sie unter Übersicht über Azure Load Balancer.

Blockieren Sie den Integritätstest nicht. Der Integritätstests durch den Lastenausgleich wird von einer bekannten IP-Adresse (168.63.129.16) gesendet. Blockieren Sie den Datenverkehr zu oder von dieser IP-Adresse nicht in Firewallrichtlinien oder in NSG-Regeln (Netzwerksicherheitsgruppe). Wenn der Integritätstest blockiert wird, wird die VM vom Lastenausgleich aus der Rotation entfernt.

Aktivieren Sie die Protokollierung für den Lastenausgleich. Die Protokolle zeigen, wie viele VMs am Back-End aufgrund fehlerhafter Testantworten keinen Netzwerkdatenverkehr empfangen. Weitere Informationen finden Sie unter Protokollanalysen für Azure Load Balancer.