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
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 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.