Tillförlitlighet i Azure Spring Apps
Den här artikeln innehåller detaljerad information om regional återhämtning med tillgänglighetszoner och haveriberedskap mellan regioner och stöd för affärskontinuitet för Azure Spring Apps.
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 Spring Apps stöder zonredundans. När du skapar en Azure Spring Apps-tjänstinstans med zonredundans aktiverad distribuerar Azure Spring Apps automatiskt grundläggande resurser över logiska delar av den underliggande Azure-infrastrukturen. Den underliggande beräkningsresursen distribuerar virtuella datorer över alla tillgänglighetszoner för att säkerställa möjligheten att beräkna. Den underliggande lagringsresursen replikerar data mellan tillgänglighetszoner för att hålla den tillgänglig även om det uppstår datacenterfel. Den här distributionen ger en högre tillgänglighetsnivå och skyddar mot maskinvarufel eller planerade underhållshändelser.
Förutsättningar
Zonredundans är inte tillgängligt i Basic-planen.
Azure Spring Apps stöder tillgänglighetszoner i följande regioner:
- Australien, östra
- Brasilien, södra
- Kanada, centrala
- Central US
- Asien, östra
- East US
- USA, östra 2
- Frankrike, centrala
- Tyskland, västra centrala
- Europa, norra
- Japan, östra
- Sydkorea, centrala
- Sydafrika, norra
- USA, södra centrala
- Sydostasien
- Storbritannien, södra
- Europa, västra
- USA, västra 2
- USA, västra 3
Skapa en Azure Spring Apps-instans med tillgänglighetszoner aktiverade
Kommentar
Du kan endast aktivera zonredundans när du skapar din Azure Spring Apps-tjänstinstans. Du kan inte ändra egenskapen zonredundans när du har skapat den.
Du kan aktivera zonredundans i Azure Spring Apps med hjälp av Azure CLI eller Azure-portalen.
Om du vill skapa en tjänst i Azure Spring Apps med zonredundans aktiverad med hjälp av Azure CLI tar du med parametern --zone-redundant när du skapar din tjänst, som du ser i följande exempel:
az spring create \
--resource-group <your-resource-group-name> \
--name <your-Azure-Spring-Apps-instance-name> \
--location <location> \
--zone-redundant true
Aktivera din egen resurs med tillgänglighetszoner aktiverade
Du kan aktivera din egen resurs i Azure Spring Apps, till exempel din egen beständiga lagring. Du måste dock se till att aktivera zonredundans för din resurs. Mer information finns i Så här aktiverar du din egen beständiga lagring i Azure Spring Apps.
Zon-ned-upplevelse
När en appinstans misslyckas eftersom den finns på en VM-nod i en misslyckad zon skapar Azure Spring Apps en ny appinstans för den misslyckade appen på en annan vm-nod i en annan tillgänglighetszon. Användare kan uppleva ett kort avbrott under den här tiden. Ingen användaråtgärd krävs och den påverkade Azure Spring Apps-instansen återställs av tjänsten.
Prissättning
Det finns ingen extra kostnad i samband med aktivering av zonredundans. Du behöver bara betala för Standard- eller Enterprise-planen, som krävs för att aktivera zonredundans.
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.
Azure Spring Apps-tjänsten tillhandahåller inte geo-haveriberedskap, men noggrann planering kan hjälpa dig att skydda dig från driftstopp.
Distribuera dina program i Azure Spring Apps till flera regioner för att säkerställa hög tillgänglighet och skydd mot katastrofer. Azure tillhandahåller en lista över kopplade regioner så att du kan planera appdistributionerna i enlighet med detta.
Tänk på följande viktiga faktorer när du utformar din arkitektur:
- Regional tillgänglighet. För att minimera nätverksfördröjningen och överföringstiden väljer du en region som stöder zonredundans i Azure Spring Apps eller ett geografiskt område nära dina användare.
- Länkade Azure-regioner. Om du vill säkerställa samordnade plattformsuppdateringar och prioriterade återställningsåtgärder om det behövs väljer du länkade regioner inom ditt valda geografiska område.
- Tjänsttillgänglighet. Bestäm om dina kopplade regioner ska köras varm/varm, varm/varm eller varm/kall.
Använda Azure Traffic Manager för att dirigera trafik
Azure Traffic Manager tillhandahåller DNS-baserad trafikbelastningsutjämning och kan distribuera nätverkstrafik över flera regioner. Använd Azure Traffic Manager för att dirigera kunder till den närmaste Azure Spring Apps-tjänstinstansen. För bästa prestanda och redundans dirigerar du all programtrafik via Azure Traffic Manager innan du skickar den till din Azure Spring Apps-tjänstinstans. Mer information finns i Vad är Traffic Manager?
Om du har program i Azure Spring Apps som körs i flera regioner kan Azure Traffic Manager styra trafikflödet till dina program i varje region. Definiera en Azure Traffic Manager-slutpunkt för varje tjänstinstans med instansens IP-adress. Du bör ansluta till ett DNS-namn för Azure Traffic Manager som pekar på Azure Spring Apps-tjänstinstansen. Azure Traffic Manager-belastningen balanserar trafik över de definierade slutpunkterna. Om en katastrof drabbar ett datacenter dirigerar Azure Traffic Manager trafik från regionen till dess par, vilket säkerställer tjänstkontinuitet.
Använd följande steg för att skapa en Azure Traffic Manager-instans för Azure Spring Apps-instanser:
Skapa Azure Spring Apps-instanser i två olika regioner. Du kan till exempel skapa tjänstinstanser i USA, östra och Europa, västra, enligt följande tabell. Varje instans fungerar som en primär slutpunkt och redundansslutpunkt för trafik.
Servicenamn Plats Program service-sample-a USA, östra gateway/auth-service/account-service service-sample-b Västeuropa gateway/auth-service/account-service Konfigurera en anpassad domän för tjänstinstanserna. Mer information finns i Självstudie: Mappa en befintlig anpassad domän till Azure Spring Apps. När installationen har slutförts binder båda tjänstinstanserna till samma anpassade domän, till exempel
bcdr-test.contoso.com.Skapa en trafikhanterare och två slutpunkter. Anvisningar finns i Snabbstart: Skapa en Traffic Manager-profil med hjälp av Azure-portalen, som skapar följande Traffic Manager-profil:
- Traffic Manager DNS-namn:
http://asa-bcdr.trafficmanager.net - Slutpunktsprofiler:
Profile Typ Mål Prioritet Inställningar för anpassat sidhuvud Slutpunkt A-profil Extern slutpunkt service-sample-a.azuremicroservices.io1 host: bcdr-test.contoso.comSlutpunkt B-profil Extern slutpunkt service-sample-b.azuremicroservices.io2 host: bcdr-test.contoso.com- Traffic Manager DNS-namn:
Skapa en CNAME-post i en DNS-zon som liknar följande exempel:
bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net.
Miljön har nu konfigurerats. Om du använde exempelvärdena i de länkade artiklarna bör du kunna komma åt appen med hjälp av https://bcdr-test.contoso.com.
Använda Azure Front Door och Azure Application Gateway för att dirigera trafik
Azure Front Door är en global, skalbar startpunkt som använder Microsofts globala gränsnätverk för att skapa snabba, säkra och mycket skalbara webbprogram. Azure Front Door tillhandahåller samma redundans och routning för flera geografiska områden till den närmaste regionen som Azure Traffic Manager. Azure Front Door innehåller även avancerade funktioner som TLS-protokollavslut, bearbetning av programskikt och brandvägg för webbprogram (WAF). Mer information finns i Vad är Azure Front Door?
Följande diagram visar arkitekturen för en redundans för flera regioner, en virtuell nätverksintegrerad Azure Spring Apps-tjänstinstans. Diagrammet visar rätt omvänd proxykonfiguration för Application Gateway och Front Door med en anpassad domän. Den här arkitekturen baseras på scenariot som beskrivs i Exponera program med TLS från slutpunkt till slutpunkt i ett virtuellt nätverk. Den här metoden kombinerar två Application-Gateway-integrerade Azure Spring Apps-instanser för virtuell nätverksinmatning till en geo-redundant instans.
