Hög tillgänglighet för Service Anslut or
Tjänst Anslut eller stöder Azure-tillgänglighetszoner som hjälper dig att uppnå återhämtning och tillförlitlighet för dina affärskritiska arbetsbelastningar. Målet med arkitekturen för hög tillgänglighet i Service Anslut eller är att garantera att dina tjänstanslutningar är igång och körs minst 99,9 % av tiden, så att du inte behöver oroa dig för effekterna av potentiella underhållsåtgärder och avbrott. Tjänsten Anslut eller är utformad för att ge stöd med hög tillgänglighet för alla typer av program som du kör i Azure.
Användare kan distribuera Azure-beräkningstjänster mellan tillgänglighetszoner i många regioner. Tjänst Anslut eller är en tilläggsresursprovider till dessa beräkningstjänster. När du skapar en tjänstanslutning i en beräkningstjänst med tillgänglighetszoner aktiverade konfigurerar Azure också automatiskt motsvarande tillgänglighetszon för tjänstanslutning för din tjänstanslutning. Microsoft ansvarar för att konfigurera tillgänglighetszoner och haveriberedskap för dina tjänstanslutningar.
Zonredundans i Service Anslut or
Tjänst Anslut eller är en Azure-tilläggsresursprovider. Den utökar Azure App Service, Azure Spring Apps och Azure Container Apps. När du skapar en ny tjänstanslutning i en av dessa beräkningstjänster med Service Anslut eller etableras en anslutningsresurs som en del av den överordnade beräkningstjänsten på den översta nivån.
Om du vill aktivera zonredundans för anslutningen måste du aktivera zonredundans för beräkningstjänsten. När beräkningstjänsten har konfigurerats med zonredundans blir även tjänstanslutningarna automatiskt zonredundanta. Om du till exempel har en apptjänst med zonredundans aktiverad sprider plattformen automatiskt dina App Service-instanser över tre zoner i den valda regionen. När du skapar en tjänstanslutning i den här apptjänsten med Service Anslut or skapas även tjänstanslutningsresursen automatiskt i de tre motsvarande zonerna i den valda regionen. Trafiken dirigeras till alla tillgängliga anslutningsresurser. När en zon går ner identifierar plattformen förlorade instanser, försöker automatiskt hitta nya ersättningsinstanser och sprider trafiken efter behov.
Kommentar
För att skapa, uppdatera, verifiera och lista tjänstanslutningar anropar Service Anslut eller API:er från en beräkningstjänst och en måltjänst. Eftersom Service Anslut or förlitar sig på svaren från både beräkningstjänsten och måltjänsten kanske begäranden till Service Anslut eller i ett zon-down-scenario inte lyckas om måltjänsten inte kan nås. Den här begränsningen gäller för App Service, Azure Container Apps och Azure Spring Apps.
Så här skapar du en zonredundant tjänstanslutning med Service Anslut eller
Följ anvisningarna nedan för att skapa en zonredundant tjänstanslutning i App Service med hjälp av Azure CLI eller Azure-portalen. Samma process kan användas för att skapa en zonredundant anslutning för Azure Spring Apps och Azure Container Apps-beräkningstjänster.
Om du vill aktivera zonredundans för en tjänstanslutning med hjälp av Azure CLI börjar du med att skapa en zonredundant App Service.
Skapa en App Service-plan och inkludera en
--zone-redundantparameter. Du kan också inkludera parametern--number-of-workersför att ange kapacitet. Läs mer i Distribuera en zonredundant App Service.az appservice plan create --resource-group MyResourceGroup --name MyPlan --zone-redundant --number-of-workers 6Skapa ett program i App Service och en anslutning till ditt Blob Storage-konto eller en annan måltjänst som du väljer.
az webapp create --name MyApp --plan MyPlan resource-group MyResourceGroup az webapp connection create storage-blob
När du har aktiverat zonredundans för Din App Service är tjänstanslutningen också zonredundant.
Dricks
Vi rekommenderar att du aktiverar zonredundans för måltjänsten. I ett zon-ned-scenario sprids trafiken till anslutningen automatiskt till andra zoner. Men att skapa, validera och uppdatera anslutningar förlitar sig på hanterings-API:er från måltjänsten. Om en måltjänst inte stöder zonredundans eller inte har zonredundans aktiverad misslyckas dessa åtgärder.
Förstå haveriberedskap och återhämtning i Service Anslut or
Haveriberedskap är processen för att återställa programfunktioner efter en oåterkallelig förlust.
I molnet bekräftar vi i förväg att fel säkert kommer att inträffa. Målet är att minimera effekten av en enda komponent som havererar snarare än att förhindra fel helt och hållet. Om det uppstår ett haveri redundansväxlar Service Anslut eller till den kopplade regionen. Kunder behöver inte göra något om avbrottet bestäms/deklareras av Service Anslut eller-teamet.
Vi använder termerna RTO (Mål för återställningstid) för att ange tiden mellan början av ett avbrott som påverkar Service Anslut or och återställningen till full tillgänglighet. Vi använder RPO (Mål för återställningspunkt) för att ange tiden mellan den senaste åtgärden korrekt återställd och tidpunkten för starten av det avbrott som påverkar Service Anslut or. Förväntat och maximalt RPO är 24 timmar och RTO är 24 timmar.
Åtgärder mot Tjänst Anslut eller kan misslyckas under haveritiden innan redundansväxlingen sker. När redundansväxlingen är klar återställs data och kunden behöver inte vidta några åtgärder.
Service Connector hanterar affärskontinuitet och haveriberedskap (BCRD) för lagring och beräkning. Plattformen strävar efter att ha så minimal påverkan som möjligt vid problem med lagring/beräkning, i alla regioner. Designen för dataskiktet prioriterar tillgänglighet framför svarstid i händelse av en katastrof , vilket innebär att om en region slutar fungera försöker Service Anslut eller att hantera slutanvändarbegäran från den kopplade regionen.
Under redundansåtgärden hanterar Service Anslut eller DNS-ommappningen till de tillgängliga regionerna. Alla data och åtgärder från kundvyn fungerar som vanligt efter redundansväxlingen. Tjänstens Anslut eller ändrar sin DNS om ungefär en timme. Det skulle ta längre tid att utföra en manuell redundansväxling. Eftersom Service Anslut or är en resursprovider som bygger på andra Azure-tjänster beror den faktiska tiden på redundanstiden för de underliggande tjänsterna.
Stöd för haveriberedskapsregion
Tjänst Anslut eller stöder för närvarande följande regionpar. I händelse av ett avbrott i den primära regionen startar redundans till den sekundära regionen automatiskt.
| Primär | Sekundära |
|---|---|
| USA, östra 2 (EUAP) | East US |
| USA, västra centrala | USA, västra centrala 2 |
| Europa, västra | Europa, norra |
| Europa, norra | Europa, västra |
| East US | USA, västra 2 |
| USA, västra 2 | East US |
Redundans mellan regioner
Microsoft ansvarar för att hantera redundans mellan regioner. Tjänst Anslut eller kör hälsokontroller var 10:e minut och regionala redundans identifieras och hanteras i serverdelen för Tjänst Anslut eller. Redundansväxlingsprocessen kräver inga ändringar i kundens program eller beräkningstjänstkonfigurationer. Tjänst Anslut eller använder en aktiv-passiv klusterkonfiguration med automatisk redundans. Efter en haveriberedskap kan kunderna använda de fullständiga funktioner som tillhandahålls av Service Anslut or.
Hälsokontrollen som körs var 10:e minut simulerar användarbeteendet genom att skapa, validera och uppdatera anslutningar till måltjänster i var och en av de beräkningstjänster som stöds av Service Anslut or. Microsoft börjar analysera och starta en tjänst Anslut eller redundansväxling om vi uppfyller något av följande villkor:
- Tjänstens hälsokontroll misslyckas tre gånger i rad
- Tjänst Anslut eller beroende tjänster deklarerar ett avbrott
- Kunder rapporterar ett regionstopp
Begäranden till tjänstanslutningar påverkas under en redundansväxling. När redundansväxlingen är klar återställs tjänstanslutningsdata. Du kan kontrollera statussidan för Azure för att kontrollera statusen för alla Azure-tjänster.
Nästa steg
Gå till konceptartikeln nedan om du vill veta mer om Service Anslut or.