Beschikbaarheid en weerbaarheid¶
Wat er met integratieworkloads gebeurt als een availability zone uitvalt, van welke Azure-services ze afhankelijk zijn en welke beschikbaarheid je mag verwachten van de patronen die je bouwt. Deze pagina vat de beschikbaarheidsanalyse van het referentie- ontwerp samen (één regio, januari 2026). Gebruik haar om je integratie te ontwerpen en realistische doelen te stellen.
Referentieanalyse, geen belofte
De cijfers zijn theoretisch, berekend uit de beschikbaarheidstoezeggingen die Microsoft publiceert. Ze veranderen als Microsoft ze wijzigt of als jouw configuratie afwijkt van het referentieontwerp. De werkelijke beschikbaarheid is doorgaans hoger. Het zijn niet de servicelevels van jouw overeenkomst. Controleer de Microsoft-cijfers opnieuw voordat je ze in een toezegging gebruikt.
Samenvatting¶
| Gebied | Status in het referentieontwerp |
|---|---|
| Landing zone-componenten (virtual WAN, DNS resolver, firewall, application gateway, Key Vault, spoke storage) | Zone-redundant als geconfigureerd. Een spoke storage account gebruikt standaard lokaal redundante opslag als er geen redundantie is geconfigureerd. Het management storage account van het platform is lokaal redundant, wat geen runtime-afhankelijkheid is. |
| Service Bus, Event Hubs | Standaard zone-redundant |
| Container Apps-omgeving | Zone redundancy staat standaard aan als het niet is ingesteld |
| Function App-plan | Zone balancing wordt automatisch ingeschakeld voor de elastic premium-, Flex Consumption- en premium-plannen. Het aantal workers is standaard 2. |
| Logic App-plan | Zone-balanced met de workflowplangroottes (WS1, WS2, WS3) |
| Logic App-opslag | Het storage account dat met de Logic App wordt uitgerold, is standaard zone-redundante opslag |
| Container registry | Zone redundancy staat uit. Een storing in de zone met de registry kan het ophalen van images blokkeren. |
Bij een storing van één zone blijven de zone-redundante componenten werken. De zwakke plek is de container registry, die Container Apps en Container Jobs raakt.
Runtime-afhankelijkheden¶
| Integratiecomponent | Storage | Key Vault | Container registry | Application Insights | Log Analytics |
|---|---|---|---|---|---|
| Logic App | Kritiek (eigen account) | Optioneel (secrets) | Niet kritiek | Niet kritiek | |
| Function App | Kritiek (spoke-account) | Kritiek (secrets) | Niet kritiek | Niet kritiek | |
| Container App | Kritiek (datatoegang) | Kritiek (secrets) | Kritiek (image pull) | Niet kritiek | Niet kritiek |
| Container Job | Kritiek (event triggers) | Kritiek (secrets) | Kritiek (image pull) | Niet kritiek | Niet kritiek |
| API Management | Geen | Optioneel (certificaten, secrets) | Niet kritiek | Niet kritiek | |
| Data Factory | Kritiek (databron en sink) | Kritiek (linked services) | Niet kritiek | Niet kritiek |
Kritiek: de component faalt als de afhankelijkheid niet beschikbaar is. Optioneel: werkt met verminderde functionaliteit. Niet kritiek: alleen de observability is verminderd.
Samengestelde beschikbaarheid per patroon¶
Een patroon hangt af van een keten van services. De samengestelde beschikbaarheid is het product van de beschikbaarheid van elke service in de keten, inclusief de landing zone-services (virtual WAN, private DNS, firewall, application gateway) en de kritieke afhankelijkheden hierboven.
| Integratiepatroon | Samengestelde beschikbaarheid | Maandelijks downtimebudget |
|---|---|---|
| REST API op een Function App | 99,67% | ongeveer 2,4 uur |
| REST API op een Logic App | 99,62% | ongeveer 2,8 uur |
| REST API op een Container App | 99,57% | ongeveer 3,1 uur |
| Event-driven verwerking met een Function App | 99,76% | ongeveer 1,8 uur |
| Verwerking van Service Bus-queueberichten met een Container Job | 99,57% | ongeveer 3,1 uur |
| Data Factory ETL | 99,72% | ongeveer 2,0 uur |
Elke extra service in de keten verlaagt het samengestelde cijfer.
Aanbevelingen¶
De analyse noemt deze acties, op volgorde van waarde ten opzichte van inspanning:
- Schakel zone redundancy in op de container registry. Daarmee is de registry niet langer de beperkende factor van het Container App- patroon. Het is een configuratiewijziging met een bescheiden kostenstijging.
- Controleer de redundantie van het management storage account van het platform en upgrade het als dataverlies ertoe zou doen.
- Beperk afhankelijkheden in je ontwerp. Cache waarden om Key Vault-aanroepen te beperken, gebruik connection pooling om storage-operaties te beperken.
- Probeer opnieuw. Gebruik retries met back-off. Service Bus-clients hebben retry ingebouwd. Gebruik voor HTTP-aanroepen een resilience-bibliotheek.
- Gebruik de hogere tiers waar een betere garantie ertoe doet, bijvoorbeeld Premium voor Event Hubs en Service Bus.
Multi-region¶
Een tweede regio is een strategische beslissing, geen standaard. In de analyse komen regionale storingen in de regio ongeveer eens per jaar voor en duren ze ongeveer zes uur. Multi-regionale ontwerpen zijn complex (active-passive of active-active) en kosten ongeveer 1,5 tot 2 keer zoveel. Meerdere services hebben ingebouwde opties (storage met read-access geo-zone-redundancy, automatische replicatie van Key Vault, geo-replicatie van Service Bus en Event Hubs op Premium, geo-replicatie van de registry op Premium), maar zelfs met al die opties verbeteren de samengestelde cijfers in de analyse maar weinig. Voor de meeste integratieworkloads geeft een zone-redundante deployment in één regio met goede retrylogica en graceful degradation genoeg beschikbaarheid voor de kosten. Overweeg multi-region voor bedrijfskritieke workloads die meer dan ongeveer 99,9% nodig hebben. Het is ook geen optie als de landing zone in slechts één regio draait.
Disaster recovery¶
Het platform volgt het MCP: één regio, availability zones en herdeployment vanuit code in een andere regio. Het referentie- ontwerp noemt een recovery time objective van 24 uur en een recovery point objective van 48 uur, wat haalbaar is omdat het platform en workloads die alleen platformmodules gebruiken binnen uren opnieuw kunnen worden uitgerold. Beide waarden worden per platform ingesteld (Architectuur).
Back-up¶
Het Integration Platform zelf slaat geen data permanent op en zijn configuratie is code in een Git-repository. Je integraties kunnen wel state opslaan, bijvoorbeeld Function Apps en Logic Apps bewaren state in een storage account. Back-up daarvan is jouw beslissing: ofwel specifiek voor je workload, ofwel onderdeel van een back-upoplossing voor alle workloads op het platform. Een back-upoplossing voor workloads maakt standaard geen deel uit van de MCP landing zone.
Wat je als workload team kunt doen¶
- Kies de redundantie van de plannen en replicas die je configureert: replicas van een Container App, instances van een Logic App-plan. Houd bij een zone-balanced plan het minimale aantal instances een veelvoud van het aantal zones in de regio.
- Ontwerp voor de afhankelijkheidsketen: weet welke services je patroon nodig heeft.
- Voeg retries en een health check toe aan je integratie.
- Bepaal wat een regionale storing moet overleven en vertel het je platformteam vroeg (Je workload beheren).