Betrouwbaarheid in Azure Container Apps
In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure Container Apps beschreven en wordt zowel regionale tolerantie behandeld als beschikbaarheidszones en tolerantie tussen regio's met herstel na noodgevallen. Zie Azure-betrouwbaarheid voor een gedetailleerder overzicht van betrouwbaarheid in Azure.
Ondersteuning voor beschikbaarheidszone
Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.
Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.
Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor meer informatie over zone-redundante versus zone-redundante architectuur voor het gebruik van beschikbaarheidszones en regio's.
Azure Container Apps maakt gebruik van beschikbaarheidszones in regio's waar ze beschikbaar zijn om beveiliging met hoge beschikbaarheid te bieden voor uw toepassingen en gegevens uit datacenterfouten.
Door de zoneredundantiefunctie van Container Apps in te schakelen, worden replica's automatisch verdeeld over de zones in de regio. Verkeer wordt verdeeld over de replica's. Als er een zonestoring optreedt, wordt verkeer automatisch doorgestuurd naar de replica's in de resterende zones.
Notitie
Er worden geen extra kosten in rekening gebracht voor het inschakelen van zoneredundantie, maar biedt alleen voordelen wanneer u 2 of meer replica's hebt, waarbij 3 of meer ideaal zijn omdat de meeste regio's die zoneredundantie ondersteunen, drie zones hebben.
Vereisten
Azure Container Apps biedt dezelfde betrouwbaarheidsondersteuning, ongeacht uw abonnementstype.
Azure Container Apps maakt gebruik van beschikbaarheidszones in regio's waar ze beschikbaar zijn. Zie Beschikbaarheidszoneservice en regionale ondersteuning voor een lijst met regio's die beschikbaarheidszones ondersteunen.
SLA-verbeteringen
Er zijn geen verhoogde SLA's voor Azure Container Apps. Zie Service Level Agreement voor Azure Container Apps voor Azure Container Apps voor meer informatie over de SLA's van Azure Container Apps.
Een resource maken waarvoor beschikbaarheidszone is ingeschakeld
Zoneredundantie instellen in uw Container Apps-omgeving
Als u wilt profiteren van beschikbaarheidszones, moet u zoneredundantie inschakelen wanneer u een Container Apps-omgeving maakt. De omgeving moet een virtueel netwerk met een beschikbaar subnet bevatten. Als u de juiste distributie van replica's wilt garanderen, stelt u het minimumaantal replica's van uw app in op drie.
Zoneredundantie inschakelen via Azure Portal
Een container-app maken in een omgeving waarvoor zoneredundantie is ingeschakeld met behulp van Azure Portal:
- Ga naar de Azure Portal.
- Zoek naar Container Apps in het bovenste zoekvak.
- Selecteer Container Apps.
- Selecteer Nieuw maken in het veld Container Apps Environment om het deelvenster Container Apps-omgeving maken te openen.
- Voer de naam van de omgeving in.
- Selecteer Ingeschakeld voor het veld Zoneredundantie .
Zoneredundantie vereist een virtueel netwerk met een infrastructuursubnet. U kunt een bestaand virtueel netwerk kiezen of een nieuw netwerk maken. Wanneer u een nieuw virtueel netwerk maakt, kunt u de waarden accepteren die u hebt opgegeven of de instellingen aanpassen.
- Selecteer het tabblad Netwerken.
- Als u een aangepaste naam voor een virtueel netwerk wilt toewijzen, selecteert u Nieuw maken in het veld Virtueel netwerk .
- Als u een aangepaste infrastructuursubnetnaam wilt toewijzen, selecteert u Nieuw maken in het veld Infrastructuursubnet .
- U kunt Intern of Extern selecteren voor het virtuele IP-adres.
- Selecteer Maken.
Zoneredundantie inschakelen met de Azure CLI
Maak een subnet voor een virtueel netwerk en infrastructuur dat moet worden opgenomen in de Container Apps-omgeving.
Wanneer u deze opdrachten gebruikt, vervangt u de <PLACEHOLDERS> waarden.
Notitie
Voor de omgeving Alleen verbruik is een toegewezen subnet met een CIDR-bereik van /23 of groter vereist. Voor de omgeving met workloadprofielen is een toegewezen subnet met een CIDR-bereik van /27 of groter vereist. Zie het overzicht van de netwerkarchitectuur voor meer informatie over de grootte van subnetten.
az network vnet create \
--resource-group <RESOURCE_GROUP_NAME> \
--name <VNET_NAME> \
--location <LOCATION> \
--address-prefix 10.0.0.0/16
az network vnet subnet create \
--resource-group <RESOURCE_GROUP_NAME> \
--vnet-name <VNET_NAME> \
--name infrastructure \
--address-prefixes 10.0.0.0/21
Voer vervolgens een query uit voor de infrastructuursubnet-id.
INFRASTRUCTURE_SUBNET=`az network vnet subnet show --resource-group <RESOURCE_GROUP_NAME> --vnet-name <VNET_NAME> --name infrastructure --query "id" -o tsv | tr -d '[:space:]'`
Maak ten slotte de omgeving met de --zone-redundant parameter. De locatie moet dezelfde locatie zijn die wordt gebruikt bij het maken van het virtuele netwerk.
az containerapp env create \
--name <CONTAINER_APP_ENV_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--location "<LOCATION>" \
--infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET \
--zone-redundant
Zoneredundantie controleren met de Azure CLI
Notitie
In Azure Portal wordt niet weergegeven of zoneredundantie is ingeschakeld.
Gebruik de az container app env show opdracht om te controleren of zoneredundantie is ingeschakeld voor uw Container Apps-omgeving.
az containerapp env show \
--name <CONTAINER_APP_ENV_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--subscription <SUBSCRIPTION_ID>
De opdracht retourneert een JSON-antwoord. Controleer of het antwoord bevat "zoneRedundant": true.
Veilige implementatietechnieken
Wanneer u zoneredundantie instelt in uw container-app, worden replica's automatisch verdeeld over de zones in de regio. Nadat de replica's zijn gedistribueerd, wordt het verkeer verdeeld over deze replica's. Als er een zonestoring optreedt, wordt verkeer automatisch gerouteerd naar de replica's in de resterende zone.
U moet nog steeds veilige implementatietechnieken gebruiken, zoals blauwgroene implementatie. Azure Container Apps biedt geen implementatie of upgrades in één zone per keer.
Als u sessieaffiniteit hebt ingeschakeld en een zone uitvalt, worden clients voor die zone doorgestuurd naar nieuwe replica's omdat de vorige replica's niet meer beschikbaar zijn. Elke status die aan de vorige replica's is gekoppeld, gaat verloren.
Migratie van beschikbaarheidszone
Als u wilt profiteren van beschikbaarheidszones, schakelt u zoneredundantie in terwijl u de Container Apps-omgeving maakt. De omgeving moet een virtueel netwerk met een beschikbaar subnet bevatten. U kunt een bestaande Container Apps-omgeving niet migreren van ondersteuning voor niet-beschikbaarheidszones naar ondersteuning voor beschikbaarheidszones.
Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's
Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie Aanbevelingen voordat u nadenkt over het maken van uw plan voor herstel na noodgevallen.
Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.
In het onwaarschijnlijke geval van een storing in een volledige regio hebt u de mogelijkheid om een van de twee strategieën te gebruiken:
Handmatig herstel: implementeer handmatig naar een nieuwe regio of wacht tot de regio is hersteld en implementeer vervolgens handmatig alle omgevingen en apps.
Tolerant herstel: implementeer eerst uw container-apps vooraf in meerdere regio's. Gebruik vervolgens Azure Front Door of Azure Traffic Manager om binnenkomende aanvragen te verwerken, zodat verkeer naar uw primaire regio wordt doorgestuurd. Als er vervolgens een storing optreedt, kunt u verkeer omleiden van de betreffende regio. Zie Replicatie tussen regio's in Azure voor meer informatie.
Notitie
Ongeacht welke strategie u kiest, moet u ervoor zorgen dat uw implementatieconfiguratiebestanden zich in broncodebeheer bevinden, zodat u deze eenvoudig opnieuw kunt implementeren, indien nodig.
Meer richtlijnen
Met de volgende resources kunt u uw eigen noodherstelplan maken:
- Herstel na fouten en noodgevallen voor Azure-toepassingen
- Technische richtlijnen voor flexibiliteit van Azure