Tillförlitlighet i Azure Container Apps

Den här artikeln beskriver tillförlitlighetsstöd i Azure Container Apps och beskriver både regional återhämtning med tillgänglighetszoner och återhämtning mellan regioner med haveriberedskap. En mer detaljerad översikt över tillförlitligheten i Azure finns i Azures tillförlitlighet.

Stöd för tillgänglighetszon

Azure-tillgänglighetszoner är minst tre fysiskt separata grupper av datacenter i varje Azure-region. Datacenter i varje zon är utrustade med oberoende infrastruktur för ström, kylning och nätverk. Om det uppstår ett fel i den lokala zonen är tillgänglighetszoner utformade så att regionala tjänster, kapacitet och hög tillgänglighet stöds av de återstående två zonerna om den ena zonen påverkas.

Fel kan vara allt från programvaru- och maskinvarufel till händelser som jordbävningar, översvämningar och bränder. Tolerans mot fel uppnås med redundans och logisk isolering av Azure-tjänster. Mer detaljerad information om tillgänglighetszoner i Azure finns i Regioner och tillgänglighetszoner.

Azure-tillgänglighetszoner-aktiverade tjänster är utformade för att ge rätt nivå av tillförlitlighet och flexibilitet. De kan konfigureras på två sätt. De kan vara antingen zonredundanta, med automatisk replikering mellan zoner eller zoninstanser, med instanser fästa på en specifik zon. Du kan också kombinera dessa metoder. Mer information om zon- och zonredundant arkitektur finns i Rekommendationer för användning av tillgänglighetszoner och regioner.

Azure Container Apps använder tillgänglighetszoner i regioner där de är tillgängliga för att ge hög tillgänglighetsskydd för dina program och data från datacenterfel.

Genom att aktivera containerappars zonredundansfunktion distribueras repliker automatiskt över zonerna i regionen. Trafiken belastningsutjämning mellan replikerna. Om ett zonfel inträffar dirigeras trafiken automatiskt till replikerna i de återstående zonerna.

Förutsättningar

Azure Container Apps har samma tillförlitlighetsstöd oavsett plantyp.

Azure Container Apps använder tillgänglighetszoner i regioner där de är tillgängliga. En lista över regioner som stöder tillgänglighetszoner finns i Tillgänglighetszonstjänst och regional support.

Förbättringar av serviceavtal

Det finns inga ökade serviceavtal för Azure Container Apps. Mer information om serviceavtal för Azure Container Apps finns i Service Level Agreement for Azure Container Apps (Servicenivåavtal för Azure Container Apps).

Skapa en resurs med tillgänglighetszonen aktiverad

Konfigurera zonredundans i din Container Apps-miljö

Om du vill dra nytta av tillgänglighetszoner måste du aktivera zonredundans när du skapar en Container Apps-miljö. Miljön måste innehålla ett virtuellt nätverk med ett tillgängligt undernät. För att säkerställa korrekt distribution av repliker anger du appens minsta antal repliker till tre.

Aktivera zonredundans via Azure-portalen

Så här skapar du en containerapp i en miljö med zonredundans aktiverad med hjälp av Azure-portalen:

1. Navigera till Azure-portalen.
2. Sök efter Container Apps i den översta sökrutan.
3. Välj ContainerAppar.
4. Välj Skapa ny i fältet Container Apps Environment (Miljö för containerappar) för att öppna panelen Skapa containerappars miljö .
5. Ange miljönamnet.
6. Välj Aktiverad för fältet Zonredundans .

Zonredundans kräver ett virtuellt nätverk med ett infrastrukturundernät. Du kan välja ett befintligt virtuellt nätverk eller skapa ett nytt. När du skapar ett nytt virtuellt nätverk kan du acceptera de värden som angetts för dig eller anpassa inställningarna.

1. Välj fliken Nätverk.
2. Om du vill tilldela ett anpassat virtuellt nätverksnamn väljer du Skapa nytt i fältet Virtuellt nätverk .
3. Om du vill tilldela ett namn på ett anpassat infrastrukturundernät väljer du Skapa nytt i fältet Infrastrukturundernät .
4. Du kan välja Intern eller Extern för den virtuella IP-adressen.
5. Välj Skapa.

Aktivera zonredundans med Azure CLI

Skapa ett virtuellt nätverks- och infrastrukturundernät som ska ingå i Container Apps-miljön.

När du använder dessa kommandon ersätter du <PLACEHOLDERS> med dina värden.

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

$SubnetArgs = @{
    Name = 'infrastructure-subnet'
    AddressPrefix = '10.0.0.0/21'
}
$subnet = New-AzVirtualNetworkSubnetConfig @SubnetArgs

$VnetArgs = @{
    Name = <VNetName>
    Location = <Location>
    ResourceGroupName = <ResourceGroupName>
    AddressPrefix = '10.0.0.0/16'
    Subnet = $subnet 
}
$vnet = New-AzVirtualNetwork @VnetArgs

Fråga sedan efter infrastrukturens undernäts-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:]'`

$InfrastructureSubnet=(Get-AzVirtualNetworkSubnetConfig -Name $SubnetArgs.Name -VirtualNetwork $vnet).Id

Skapa slutligen miljön med parametern --zone-redundant . Platsen måste vara samma plats som används när du skapar det virtuella nätverket.

az containerapp env create \
  --name <CONTAINER_APP_ENV_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --location "<LOCATION>" \
  --infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET \
  --zone-redundant

$WorkspaceArgs = @{
    Name = 'myworkspace'
    ResourceGroupName = <ResourceGroupName>
    Location = <Location>
    PublicNetworkAccessForIngestion = 'Enabled'
    PublicNetworkAccessForQuery = 'Enabled'
}
New-AzOperationalInsightsWorkspace @WorkspaceArgs
$WorkspaceId = (Get-AzOperationalInsightsWorkspace -ResourceGroupName <ResourceGroupName> -Name $WorkspaceArgs.Name).CustomerId
$WorkspaceSharedKey = (Get-AzOperationalInsightsWorkspaceSharedKey -ResourceGroupName <ResourceGroupName> -Name $WorkspaceArgs.Name).PrimarySharedKey

$EnvArgs = @{
    EnvName = <EnvironmentName>
    ResourceGroupName = <ResourceGroupName>
    Location = <Location>
    AppLogConfigurationDestination = "log-analytics"
    LogAnalyticConfigurationCustomerId = $WorkspaceId
    LogAnalyticConfigurationSharedKey = $WorkspaceSharedKey
    VnetConfigurationInfrastructureSubnetId = $InfrastructureSubnet
    VnetConfigurationInternal = $true
}
New-AzContainerAppManagedEnv @EnvArgs

Verifiera zonredundans med Azure CLI

az container app env show Använd kommandot för att kontrollera att zonredundans har aktiverats för containerappmiljön.

az containerapp env show \
  --name <CONTAINER_APP_ENV_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --subscription <SUBSCRIPTION_ID>

az containerapp env show `
  --name <CONTAINER_APP_ENV_NAME> `
  --resource-group <RESOURCE_GROUP_NAME> `
  --subscription <SUBSCRIPTION_ID>

Kommandot returnerar ett JSON-svar. Kontrollera att svaret innehåller "zoneRedundant": true.

Valv distributionstekniker

När du konfigurerar zonredundans i containerappen distribueras repliker automatiskt över zonerna i regionen. När replikerna har distribuerats lastbalanseras trafiken mellan dem. Om ett zonfel inträffar dirigeras trafiken automatiskt till replikerna i den återstående zonen.

Du bör fortfarande använda säkra distributionstekniker, till exempel blågrön distribution. Azure Container Apps tillhandahåller inte distribution eller uppgraderingar i en zon i taget.

Om du har aktiverat sessionstillhörighet och en zon slutar fungera dirigeras klienter för den zonen till nya repliker eftersom de tidigare replikerna inte längre är tillgängliga. Alla tillstånd som är associerade med de tidigare replikerna går förlorade.

Migrering av tillgänglighetszon

Om du vill dra nytta av tillgänglighetszoner aktiverar du zonredundans när du skapar Container Apps-miljön. Miljön måste innehålla ett virtuellt nätverk med ett tillgängligt undernät. Du kan inte migrera en befintlig Container Apps-miljö från stöd för otillgänglighetszon till stöd för tillgänglighetszoner.

Haveriberedskap och affärskontinuitet mellan regioner

Haveriberedskap handlar om att återställa från händelser med hög påverkan, till exempel naturkatastrofer eller misslyckade distributioner som resulterar i driftstopp och dataförlust. Oavsett orsak är den bästa lösningen för en katastrof en väldefinierad och testad DR-plan och en programdesign som aktivt stöder DR. Innan du börjar fundera på att skapa en haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.

När det gäller dr använder Microsoft modellen för delat ansvar. I en modell med delat ansvar ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Samtidigt replikerar många Azure-tjänster inte automatiskt data eller återgår från en misslyckad region för att korsreparera till en annan aktiverad region. För dessa tjänster ansvarar du för att konfigurera en haveriberedskapsplan som fungerar för din arbetsbelastning. De flesta tjänster som körs på PaaS-erbjudanden (Plattform som en tjänst) i Azure ger funktioner och vägledning för att stödja DR och du kan använda tjänstspecifika funktioner för att stödja snabb återställning för att utveckla din DR-plan.

I det osannolika händelse av ett fullständigt regionstopp har du möjlighet att använda någon av två strategier:

• Manuell återställning: Distribuera till en ny region manuellt eller vänta tills regionen har återställts och distribuera sedan om alla miljöer och appar manuellt.

• Elastisk återställning: Distribuera först dina containerappar i förväg till flera regioner. Använd sedan Azure Front Door eller Azure Traffic Manager för att hantera inkommande begäranden som pekar trafik till din primära region. Om ett avbrott skulle inträffa kan du sedan omdirigera trafik bort från den berörda regionen. Mer information finns i Replikering mellan regioner i Azure.

Mer vägledning

Följande resurser kan hjälpa dig att skapa en egen plan för haveriberedskap:

• Fel- och haveriberedskap för Azure-program
• Azure-återhämtning, tekniska riktlinjer

Nästa steg