Verfügbarkeit und Resilienz¶
Was mit Integrations-Workloads passiert, wenn eine Availability Zone ausfällt, von welchen Azure-Services sie abhängen und welche Verfügbarkeit du von den Mustern erwarten kannst, die du baust. Diese Seite fasst die Verfügbarkeitsanalyse des Referenz- designs zusammen (eine Region, Januar 2026). Nutze sie, um deine Integration zu entwerfen und realistische Ziele zu setzen.
Referenzanalyse, kein Versprechen
Die Zahlen sind theoretisch und aus den Verfügbarkeitszusagen berechnet, die Microsoft veröffentlicht. Sie ändern sich, wenn Microsoft sie ändert oder wenn deine Konfiguration vom Referenzdesign abweicht. Die tatsächliche Verfügbarkeit ist typischerweise höher. Sie sind nicht die Service Levels deiner Vereinbarung. Prüfe die Microsoft-Zahlen erneut, bevor du sie in einer Zusage verwendest.
Zusammenfassung¶
| Bereich | Status im Referenzdesign |
|---|---|
| Landing-zone-Komponenten (Virtual WAN, DNS Resolver, Firewall, Application Gateway, Key Vault, spoke Storage) | Zonenredundant, wenn konfiguriert. Ein spoke Storage Account ist standardmäßig lokal redundant, wenn keine Redundanz konfiguriert ist. Der Management Storage Account der Plattform ist lokal redundant, was keine Laufzeitabhängigkeit ist. |
| Service Bus, Event Hubs | Standardmäßig zonenredundant |
| Container Apps environment | Zonenredundanz standardmäßig an, wenn nicht gesetzt |
| Function-App-Plan | Zone Balancing wird für die Pläne Elastic Premium, Flex Consumption und Premium automatisch aktiviert. Die Worker-Anzahl ist standardmäßig 2. |
| Logic-App-Plan | Zone-balanced mit den Workflow-Plangrößen (WS1, WS2, WS3) |
| Logic-App-Storage | Der Storage Account, der mit der Logic App deployt wird, ist standardmäßig zonenredundant |
| Container Registry | Zonenredundanz ist ausgeschaltet. Der Ausfall der Zone mit der Registry kann Image Pulls blockieren. |
Fällt eine einzelne Zone aus, arbeiten die zonenredundanten Komponenten weiter. Die Schwachstelle ist die Container Registry, die Container Apps und Container Jobs betrifft.
Laufzeitabhängigkeiten¶
| Integrationskomponente | Storage | Key Vault | Container Registry | Application Insights | Log Analytics |
|---|---|---|---|---|---|
| Logic App | Kritisch (eigener Account) | Optional (Secrets) | Nicht kritisch | Nicht kritisch | |
| Function App | Kritisch (spoke-Account) | Kritisch (Secrets) | Nicht kritisch | Nicht kritisch | |
| Container App | Kritisch (Datenzugriff) | Kritisch (Secrets) | Kritisch (Image Pull) | Nicht kritisch | Nicht kritisch |
| Container Job | Kritisch (Event-Trigger) | Kritisch (Secrets) | Kritisch (Image Pull) | Nicht kritisch | Nicht kritisch |
| API Management | Keine | Optional (Zertifikate, Secrets) | Nicht kritisch | Nicht kritisch | |
| Data Factory | Kritisch (Datenquelle und -senke) | Kritisch (Linked Services) | Nicht kritisch | Nicht kritisch |
Kritisch: Die Komponente fällt aus, wenn die Abhängigkeit nicht verfügbar ist. Optional: Funktioniert mit eingeschränkter Leistung. Nicht kritisch: Nur die Observability ist beeinträchtigt.
Zusammengesetzte Verfügbarkeit pro Muster¶
Ein Muster hängt von einer Kette von Services ab. Die zusammengesetzte Verfügbarkeit ist das Produkt der Verfügbarkeit jedes Services in der Kette, einschließlich der landing-zone-Services (Virtual WAN, private DNS, Firewall, Application Gateway) und der oben genannten kritischen Abhängigkeiten.
| Integrationsmuster | Zusammengesetzte Verfügbarkeit | Monatliches Downtime-Budget |
|---|---|---|
| REST API auf einer Function App | 99,67% | etwa 2,4 Stunden |
| REST API auf einer Logic App | 99,62% | etwa 2,8 Stunden |
| REST API auf einer Container App | 99,57% | etwa 3,1 Stunden |
| Ereignisgesteuerte Verarbeitung mit einer Function App | 99,76% | etwa 1,8 Stunden |
| Verarbeitung von Service-Bus-Queue-Nachrichten mit einem Container Job | 99,57% | etwa 3,1 Stunden |
| Data-Factory-ETL | 99,72% | etwa 2,0 Stunden |
Jeder zusätzliche Service in der Kette senkt die zusammengesetzte Zahl.
Empfehlungen¶
Die Analyse nennt diese Maßnahmen, geordnet nach Nutzen im Verhältnis zum Aufwand:
- Aktiviere Zonenredundanz auf der Container Registry. Sie entfernt die Registry als limitierenden Faktor des Container-App- Musters. Es ist eine Konfigurationsänderung mit mäßig höheren Kosten.
- Prüfe die Redundanz des Management Storage Accounts der Plattform und stufe ihn hoch, wenn Datenverlust relevant wäre.
- Reduziere Abhängigkeiten in deinem Design. Cache Werte, um Key-Vault-Aufrufe zu begrenzen, und poole Verbindungen, um Storage-Operationen zu begrenzen.
- Wiederhole. Nutze Retries mit Back-off. Service-Bus-Clients haben Retry eingebaut. Für HTTP-Aufrufe nutze eine Resilience-Bibliothek.
- Nutze die höheren Tiers, wo eine bessere Garantie zählt, zum Beispiel Premium für Event Hubs und Service Bus.
Multi-Region¶
Eine zweite Region ist eine strategische Entscheidung, kein Default. In der Analyse treten regionale Ausfälle in der Region etwa einmal pro Jahr auf und dauern etwa sechs Stunden. Multi-Region-Designs sind komplex (Active-Passive oder Active-Active) und kosten ungefähr das 1,5- bis 2-Fache. Mehrere Services haben eingebaute Optionen (Storage mit Read-Access Geo-Zone-Redundancy, automatische Replikation von Key Vault, Geo-Replikation von Service Bus und Event Hubs auf Premium, Geo-Replikation der Registry auf Premium), aber selbst mit allen verbessern sich die zusammengesetzten Zahlen in der Analyse nur leicht. Für die meisten Integrations-Workloads liefert ein zonenredundantes Single-Region-Deployment mit guter Retry-Logik und Graceful Degradation ausreichend Verfügbarkeit für die Kosten. Erwäge Multi-Region für geschäftskritische Workloads, die mehr als etwa 99,9% brauchen. Es ist außerdem keine Option, wenn die landing zone nur in einer Region läuft.
Disaster Recovery¶
Die Plattform folgt der MCP: eine Region, Availability Zones und Neu-Deployment aus dem Code in einer anderen Region. Das Referenz- design nennt ein Recovery Time Objective von 24 Stunden und ein Recovery Point Objective von 48 Stunden, die sich einhalten lassen, weil sich die Plattform und Workloads, die nur Plattform-modules nutzen, innerhalb von Stunden neu deployen lassen. Beide Werte werden pro Plattform festgelegt (Architektur).
Backup¶
Die Integration Platform selbst speichert keine Daten dauerhaft, und ihre Konfiguration ist Code in einem Git-Repository. Deine Integrationen können State speichern, zum Beispiel halten Function Apps und Logic Apps State in einem Storage Account. Das Backup davon ist deine Entscheidung: entweder spezifisch für deinen Workload oder Teil einer Backup-Lösung für alle Workloads auf der Plattform. Eine Backup-Lösung für Workloads ist standardmäßig nicht Teil der MCP landing zone.
Was du als Workload-Team tun kannst¶
- Wähle die Redundanz der Pläne und Replicas, die du konfigurierst: Replicas einer Container App, Instanzen eines Logic-App-Plans. Halte bei einem zone-balanced Plan die minimale Instanzanzahl auf einem Vielfachen der Zonenzahl der Region.
- Entwirf für die Abhängigkeitskette: Wisse, welche Services dein Muster braucht.
- Ergänze Retries und einen Health Check in deiner Integration.
- Entscheide, was einen regionalen Ausfall überstehen muss, und sag es deinem Plattform-Team früh (Deinen Workload betreiben).