Dela via


Tillförlitlighet i Azure Operator Nexus

Viktigt!

Den här funktionen finns i förhandsgranskning. Förhandsversioner är tillgängliga för dig under förutsättning att du godkänner de kompletterande användningsvillkoren.

Den här artikeln beskriver tillförlitlighetsstöd i Azure Operator Nexus och beskriver intraregional återhämtning med tillgänglighetszoner. En mer detaljerad översikt över tillförlitligheten i Azure finns i Azures tillförlitlighet.

Stöd för tillgänglighetszon

Tillgänglighetszoner är fysiskt separata grupper av datacenter i varje Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Mer information om tillgänglighetszoner i Azure finns i Vad är tillgänglighetszoner?.

Azure Operator Nexus erbjuder tillgänglighetszonredundanta distributioner som standard. Operatorn Nexus-komponenter, till exempel Cluster Manager och Network Fabric Controller, distribueras alla i ett AkS-kluster (Azure Kubernetes Service) som är aktiverat med tillgänglighetszoner. Andra tjänstberoenden, till exempel Lagringskontotjänst och KeyVault, konfigureras också med tillgänglighetszonredundans.

Kommentar

Operatorn Nexus On-Premises-instans implementerar en design med flera rack som ger fysisk redundans på alla nivåer i stacken. Varje rack är utformat som en feldomän eller Nexus-zon. Kundarbetsbelastningar kan distribueras över flera rack/noder, vilket i huvudsak ger en liknande zonupplevelse med flera tillgängligheter.

Azure-tillgänglighetszons-down-upplevelse

I ett scenario med zonen ned tillgänglighet fortsätter API-anropen mot klustret och resursprovidrar att fungera utan avbrott. Det skulle inte påverka de lokala klientarbetsbelastningar som körs för närvarande eller möjligheten att skapa nya klientarbetsbelastningar. Ingen dataförlust bör heller inträffa, eftersom motståndskraften hos Operator Nexus och andra resurstyper säkerställs.

Stöd för redundans för Azure-tillgänglighetszoner

Om det uppstår ett fel i tillgänglighetszonen är återanslutningen till en annan Azure-tillgänglighetszon automatisk och kräver ingen interaktion från användaren.

Tillgänglighet för distributioner av Operator Nexus-instanser

Att säkerställa tillgänglighet i Distributioner av Azure Operator Nexus-arbetsbelastningar är ett delat ansvar. Som du angav i föregående avsnitt distribueras de AkS-baserade resurserna för operatorn Nexus med redundans i tillgänglighetszonen. I det här avsnittet överväger vi metodtips för lokal arbetsbelastningstillgänglighet.

I allmänhet uppnås tillgänglighetsmål genom lokala och geo-redundanta distributioner.

Nexus-zon: en mekanism för redundans för lokal arbetsbelastning

Lokala Operator Nexus-instanser består av en design med flera rack som ger fysisk redundans på alla nivåer i stacken. Varje rack betecknas som en feldomän och kan därför konfigureras som en Nexus-zon där dessa zoner kan och helst bör användas för lokala redundanta arbetsbelastningsdistributioner.

Nexus-instans: en mekanism för geo-arbetsbelastningsredundans

Lokala Nexus-instanser finns i en specifik Azure-region. Som tidigare nämnts distribueras de använda Azure-tjänsterna och Nexus-resurserna i flera tillgänglighetszoner i den Azure-regionen.

Nexus-instanser som är geografiskt distribuerade, dvs. inte i samma operatörsdatacenter (kanske inte ens samma geografiska region), och som finns i olika Azure-regioner , bör användas för att redundant distribuera arbetsbelastningar för geo-redundans.

Varning

Att distribuera arbetsbelastningar på till exempel två geografiskt distribuerade Nexus-instanser är inte tillräckligt för att uppnå verklig geo-redundans om inte de geo-redundanta Nexus-instanserna finns i olika Azure-regioner.

Om det är osannolikt att en Azure-region blir otillgänglig blir Även Azure-tjänsterna och Nexus-resurserna i den regionen otillgängliga. Även om detta inte påverkar körning av arbetsbelastningar förhindrar det funktioner som att starta nya arbetsbelastningar, analyser osv.

Flera Nexus-instanser på samma geo-plats

Det finns scenarier där flera Nexus-instanser måste distribueras på samma geografiska plats. Geo-redundans för arbetsbelastningar uppnås uppenbarligen inte genom att distribuera arbetsbelastningar på Nexus-instanser på samma geografiska plats.

Ett övervägande när det gäller att utforma för tillförlitlighet, förutom tillgänglighet, är återhämtning och möjligheten att återställa från fel. Återställning från fel och möjligheten att uppfylla mål för återställningstid kräver att vi begränsar "blast" eller effektradien för fel. I scenariot där flera Nexus-instanser distribueras på samma geo-plats kräver elastisk design att dessa Nexus-instanser finns i olika Azure-regioner. När en Azure-region misslyckas begränsas dess påverkan därför till en Nexus-instans.

Nästa steg