Zuverlässigkeit in Azure Container Apps Sandboxes

Azure Container Apps Sandboxen bieten isolierte Umgebungen zum Ausführen von Code. Jeder Sandkasten wird in einem einfachen virtuellen Computer (MicroVM) ausgeführt, der in weniger als einer Sekunde gestartet wird und den In-Memory-Zustand beim Anhalten beibehalten kann. Der Dienst unterstützt die Zuverlässigkeit von Sandkastenworkloads durch Funktionen, die Sie konfigurieren und funktionen, die die Plattform in Ihrem Auftrag verwaltet.

Wenn Sie Azure verwenden, ist Zuverlässigkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.

In diesem Artikel wird beschrieben, wie Container Apps-Sandboxes gegenüber vorübergehenden Fehlern, Ausfällen von Verfügbarkeitszonen, regionsweiten Ausfällen und Wartungsarbeiten an Diensten widerstandsfähig gemacht werden können. Darüber hinaus werden Sicherungs- und Wiederherstellungsoptionen sowie wichtige Informationen zur Vereinbarung auf Servicelevel (SERVICE Level Agreement, SLA) beschrieben.

Empfehlungen für die Produktionsimplementierung für Zuverlässigkeit

Für Produktionsarbeitslasten empfehlen wir Folgendes:

  • Speichern Sie dauerhafte Daten außerhalb des Sandkastenspeichers, und wählen Sie eine Speicherredundanzoption aus, die Ihren Wiederherstellungszielen entspricht. Verwenden Sie Sandbox-Volumes für Daten, die erhalten bleiben müssen, wenn eine Sandbox beendet wird. Verwenden Sie für die Resilienz eines regionsweiten Fehlers einen externen Datenspeicher, der Daten in eine andere Region repliziert.

    Wenn Sie Azure Blob Storage verwenden, repliziert georedundanter Speicher (GRS) Daten in eine gekoppelte Region. Stellen Sie für nicht gekoppelte Regionen separate Speicherkonten bereit, und konfigurieren Sie eine unterstützte Replikationsmethode, z. B. die Objektreplikation für Blockblobs. Weitere Informationen finden Sie unter benutzerdefinierte Multiregionslösungen für Azure Blob Storage.

  • Stellen Sie separate Sandkastengruppen in mehreren Regionen bereit, wenn Ihr Uptime-Ziel nicht von einer Bereitstellung mit einer Region erfüllt werden kann. Weitere Informationen finden Sie unter Ausfallsicherheit für regionsweite Fehler.

Übersicht über die Zuverlässigkeitsarchitektur

In diesem Abschnitt werden einige der wichtigen Aspekte der Funktionsweise des Diensts beschrieben, die aus Zuverlässigkeitsperspektive am relevantesten sind. Im Abschnitt wird die logische Architektur vorgestellt, die einige der Ressourcen und Features enthält, die Sie bereitstellen und verwenden. Außerdem wird die physische Architektur erläutert, die Details zur Funktionsweise des Diensts unter den Deckeln bereitstellt.

Logische Architektur

Azure Container Apps bietet unterschiedliche Computeoptionen für Apps, Aufträge, dynamische Sitzungen und Sandkasten. Sandkastengruppen erfordern keine Container-Apps-Umgebung. Ausführliche Informationen zur Zuverlässigkeit anderer Container-Apps-Komponenten finden Sie unter Zuverlässigkeit in Azure Container Apps.

Die wichtigsten Ressourcen in Container-Apps-Sandboxes sind:

  • Sandkastengruppe: Eine Sandkastengruppe ist die regionale Verwaltungsgrenze der obersten Ebene für Sandkasten und verwendet den Microsoft.App/sandboxGroups Ressourcentyp. Alle Sandboxes, Disk-Images, Snapshots, Volumes und vertraulichen Konfigurationswerte (Secrets) sind einer Sandbox-Gruppe zugeordnet.

  • Sandbox: Jede Sandbox ist eine leichtgewichtige, isolierte MicroVM, die auf Basis eines Disk-Images oder Snapshots läuft und über eine eigene CPU, eigenen Arbeitsspeicher, einen lokalen Datenträger und eine eigene Netzwerkisolation verfügt.

    Ein Festplattenabbild ist ein OCI-Container-Image der Open Container Initiative, das zur Verwendung als Sandbox-Root-Dateisystem umgewandelt wurde.

    Eine Momentaufnahme ist eine zeitpunktgenaue Erfassung des vollständigen Zustands einer Sandbox, die unabhängig von der Quell-Sandbox bestehen bleibt.

    Der Zustand einer Sandbox kann entweder in Ausführung oder angehalten sein. Wenn ein Sandkasten entweder automatisch oder auf Anforderung beendet wird, gibt er seine Computeressourcen frei. Der Speichermodus behält das vollständige Speicherimage und den lokalen Datenträger des Sandkastens bei. Der Datenträgermodus behält nur den lokalen Datenträger bei, sodass microVM und seine Prozesse neu gestartet werden, wenn Sie die Sandbox fortsetzen.

  • Volumes: Der lokale Datenträger gehört zu einer einzelnen Sandbox. Ein Sandkastenvolume stellt beständigen Speicher bereit, der unabhängig von einer einzelnen Sandbox vorhanden ist. Sie können Azure Blob Storage-Volumes gleichzeitig in mehrere Sandboxes einbinden, während Datenträger-Volumes auf Basis von Azure Disk Storage jeweils nur in eine Sandbox gleichzeitig eingebunden werden können. Der Sicherungsspeicherdienst bestimmt die Haltbarkeits- und Wiederherstellungsoptionen für Volumedaten.

Weitere Informationen zur Sandkastenarchitektur und -ressourcen finden Sie unter Azure Container Apps Übersicht über Sandboxes.

Physische Architektur

Sandboxes werden auf mehreren unabhängigen Computeclustern ausgeführt, die von Microsoft betrieben werden. Sie sind für die Konfiguration der Sandbox-Gruppen, Sandboxes und anderen Ressourcen verantwortlich, die Sie bereitstellen. Microsoft ist für die Clusterbereitstellung, Konfiguration, Kapazitätsverwaltung, Integritätsüberwachung und Wartung verantwortlich. Sie können die Cluster nicht auswählen, bereitstellen, konfigurieren oder verwalten. Der Dienst stellt neue Sandboxes bereit, startet angehaltene Sandboxes auf gesunden Clustern neu und leitet Platzierungen an ungesunden Clustern vorbei.

Microsoft verwaltet redundante Zustandsspeicher für die Dienstkonfiguration, Sandkastenmetadaten und Artefakte wie Datenträgerimages und Momentaufnahmen.

Resilienz für vorübergehende Fehler

Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können, in der Regel durch Wiederholen betroffener Anforderungen.

Alle in der Cloud gehosteten Anwendungen sollten die Anleitung zur vorübergehenden Fehlerbehandlung von Azure befolgen, wenn sie mit cloudgehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zum Umgang mit vorübergehenden Fehlern.

Wenn Sie Container-Apps-Sandboxes verwenden, sollten Sie vorübergehende Fehler in den folgenden Teilen Ihrer Lösung berücksichtigen:

  • Sandbox-Verwaltungsvorgänge: Wenn Ihre Automatisierung Sandbox-Gruppen, Sandboxes oder zugehörige Ressourcen verwaltet, wiederholen Sie Anfragen, die aufgrund vorübergehender Fehler fehlschlagen, und verwenden Sie exponentielles Backoff. Beschränken Sie die Anzahl der Wiederholungsversuche, und wiederholen Sie nur Vorgänge, die sicher wiederholt werden können.

  • Code, der in einer Sandbox ausgeführt wird: Implementieren Sie vorübergehende Fehlerbehandlung für Aufrufe an externe APIs, Datenbanken und andere Dienste. Folgen Sie den Wiederholungsanleitungen für jede Abhängigkeit, da Wiederholungsverhalten und Vorgänge, die sicher zu wiederholen sind, je nach Dienst variieren.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

Container-Apps-Sandboxes unterstützen für eine Sandkastengruppe weder die Bereitstellung in eine bestimmte Verfügbarkeitszone noch Zonenredundanz. Um Ihre Workload gegen Ausfälle von Verfügbarkeitszonen resilient zu machen, stellen Sie separate Sandkastengruppen in mehreren Regionen bereit. Weitere Informationen finden Sie unter Ausfallsicherheit für regionsweite Fehler.

Widerstandsfähigkeit bei regionalen Ausfällen

Container Apps Sandboxes ist ein Dienst in nur einer Region. Wenn die Region nicht mehr verfügbar ist, sind auch Ihre Sandboxgruppen und die darin enthaltenen Sandboxes nicht mehr verfügbar. Der Dienst repliziert keine Sandkastengruppen oder Sandboxes regionenübergreifend, und er führt nicht automatisch ein Failover in eine andere Region durch. Sie können jedoch separate Sandkastengruppen in mehreren Regionen bereitstellen. Sie sind dafür verantwortlich, Abhängigkeiten in jeder Region bereitzustellen und die Verteilung der Workloads sowie das Failover zu verwalten. Weitere Informationen finden Sie unter Benutzerdefinierte Multiregion-Lösungen zur Resilienz.

Während eines regionsweiten Ausfalls können Statusinformationen verloren gehen, die nur im Arbeitsspeicher einer laufenden Sandbox gehalten werden. Sandkastengruppen, Sandkastenelemente und vom Dienst verwaltete Artefakte in der betroffenen Region bleiben bis zur Wiederherstellung der Region nicht verfügbar.

Sandkastenvolumes bieten Speicher, der über den Lebenszyklus einer einzelnen Sandbox hinaus besteht. Bei einem regionsweiten Ausfall hängen die Volumenverfügbarkeit und -wiederherstellung vom Sicherungsspeicherdienst und deren Konfiguration ab. Container-Apps-Sandboxes bieten keine regionsübergreifende Replikation oder Failover für Volumedaten. Stattdessen stellt der Sicherungsspeicherdienst diese Funktionen bereit, wenn diese konfiguriert sind. Informationen zu Azure Blob Storage Volumes finden Sie beispielsweise unter Zuverlässigkeit in Azure Blob Storage.

Benutzerdefinierte Multiregion-Lösungen für Resilienz

Azure Container Apps Sandboxes koordiniert weder regionenübergreifende Bereitstellungen noch repliziert es Sandboxgruppen, Sandboxes oder die zugehörigen Ressourcen zwischen Regionen. Um eine benutzerdefinierte Multiregion-Lösung zu erstellen, haben Sie die folgenden Aufgaben:

  • Regionale Bereitstellungen und Abhängigkeiten: Stellen Sie eine separate Sandkastengruppe in jeder Region bereit, die Sie verwenden möchten. Halten Sie Konfiguration, Datenträgerimages, geheime Schlüssel und andere Abhängigkeiten in den einzelnen Regionen zur Verfügung.

  • Fehlererkennung und Workloadwiederherstellung: Konfigurieren Sie Ihre Anwendungs- oder Orchestrierungsebene, um zu erkennen, wann eine Region nicht verfügbar ist, leiten Sie die Verarbeitung von Sandkastenerstellung und Arbeitsauslastung in einen fehlerfreien Bereich ein, und bestimmen Sie, wie unterbrochene Arbeit neu gestartet werden soll.

  • Datenverkehrsweiterleitung: Wenn Clients eine Verbindung über regionsspezifische Endpunkte herstellen, die Ihre Anwendung verfügbar macht, verwenden Sie einen globalen Lastenausgleichsdienst, z. B. Azure Front Door oder Azure Traffic Manager, um den Datenverkehr an einen fehlerfreien Endpunkt weiterzuleiten.

  • Datenreplikation und Wiederherstellung: Speichern Sie jeden Zustand, der nach einem Failover erforderlich ist, in einem externen Datenspeicher, der die regionenübergreifende Replikation und Wiederherstellung unterstützt. Wenn ein Sicherungsspeicherdienst eine regionsübergreifende Replikation für Volumedaten bereitstellt, bestimmt dieser Dienst das Replikations- und Failoververhalten. Azure Container Apps Sandboxes replizieren Volumedaten nicht zwischen Regionen und führen dafür auch kein Failover durch.

Sichern und Wiederherstellen

Verwenden Sie keinen Sandkastenspeicher oder lokalen Datenträger als dauerhaften Datenspeicher. Durch das Anhalten eines Sandkastens bleibt der lokale Datenträger erhalten, und im Speichermodus bleibt der Speicherzustand erhalten. Sie können auch Momentaufnahmen erstellen, die unabhängig von der Quell-Sandbox beibehalten werden. Angehaltener Zustand und Snapshots bleiben auf die regionale Sandbox-Gruppe beschränkt und sind keine regionenübergreifenden Backups.

Verwenden Sie ein Sandkastenvolume für Daten, die über den Lebenszyklus einer einzelnen Sandbox hinaus bestehen müssen. Der Sicherungsspeicherdienst und seine Konfiguration bestimmen die Sicherungs- und Wiederherstellungsfunktionen für Volumedaten. Für externe Datenspeicher, die Sie verwalten, sind Sie für die Konfiguration der Sicherung und der regionsübergreifenden Wiederherstellung verantwortlich, um Ihre Haltbarkeits- und Wiederherstellungsziele zu erfüllen.

Um Ihre Sandbox-Bereitstellung nach einer versehentlichen Löschung oder einem regionsweiten Ausfall neu zu erstellen, speichern Sie die Konfiguration Ihrer Sandboxgruppe in versionskontrollierten Infrastructure-as-Code-Vorlagen wie Bicep oder Terraform. Bewahren Sie Ihre Quelldatenträgerimages in einer Registrierung auf, die Ihre Wiederherstellungsanforderungen erfüllt.

Resilienz gegenüber Wartungsarbeiten an Diensten

Microsoft wendet regelmäßig Dienstupdates an und führt andere Wartungen durch. Die Azure Plattform übernimmt diese Aktivitäten automatisch, um sicherzustellen, dass die Wartung nahtlos und transparent für Sie ist. Bei Wartungsvorgängen können Sie kurze Unterbrechungen beobachten. Diese Unterbrechungen dauern in der Regel einige Sekunden. Stellen Sie sicher, dass Clientanwendungen so konfiguriert sind, dass vorübergehende Fehler behandelt werden, damit sie für kurze Unterbrechungen ausfallsicher sind.

Wenn Wartungsarbeiten eine laufende Sandbox beeinträchtigen, bewahrt die Plattform ihren Zustand, verschiebt die Sandbox auf funktionsfähige Rechenkapazität und nimmt sie automatisch wieder auf. Für Sandkasten, die den Speichermodus verwenden, behält die Plattform Arbeitsspeicher und lokalen Datenträgerzustand bei. Bei Sandkasten, die den Datenträgermodus verwenden, behält die Plattform nur den lokalen Datenträgerstatus bei.

Service-Level-Vereinbarung

Azure Container Apps Sandboxes bietet keine Dienstgütevereinbarung zur Verfügbarkeit (Service Level Agreement, SLA). Speicherdienste, die Ihren Sandbox-Volumes und den von Ihrer Lösung verwendeten externen Datenspeichern zugrunde liegen, könnten separaten SLAs unterliegen. Weitere Informationen finden Sie unter Service Level Agreements for Online Services.

Verwandte Inhalte

  • Last updated on