Design för självåterställning

Designa programmet så att det återställer sig självt när fel uppstår

I ett distribuerat system måste fel förväntas inträffa. Det kan uppstå fel i maskinvaran. Nätverket kan drabbas av tillfälliga fel. Sällan kommer en hel tjänst, ett datacenter eller till och med En Azure-region att drabbas av störningar, men även de måste utformas för i din arbetsbelastningsarkitektur. Återhämtning och återställning bör åtgärdas tidigt i din arbetsbelastningsdesign.

Utforma därför ett program som är självåterställning när fel inträffar. Detta kräver ett angreppssätt med tre huvudlinjer:

• Identifiera fel.
• Hantera fel på ett konstruktivt sätt.
• Logga och övervaka fel för att ge driftinsikt.

Hur du svarar på en viss typ av fel beror på programmets tillgänglighetskrav. Om du till exempel behöver hög tillgänglighet kan du distribuera till flera tillgänglighetszoner i en region. För att undvika avbrott kan du automatiskt redundansväxla till en sekundär region under ett regionalt avbrott även om det är osannolikt att en hel Azure-region drabbas av störningar. Det medför dock en högre kostnad och potentiellt lägre prestanda än en distribution i en enda region.

Du ska inte heller bara tänka på stora händelser, t.ex. regionala strömavbrott, som oftast är ovanliga. Du bör fokusera minst lika mycket på hur du hanterar lokala, tillfälliga fel, till exempel fel vid anslutning till nätverket eller misslyckade databasanslutningar.

Rekommendationer

Använd frikopplade komponenter som kommunicerar asynkront. Helst är komponenterna frikopplade när det gäller tid och utrymme. Frikopplad i tid innebär att komponenter inte behöver finnas samtidigt för att kommunikationen ska vara möjlig. Frikopplat i rymden innebär att avsändaren och mottagaren inte behöver köras i samma process, men de kan där det är mer effektivt. Frikopplade komponenter använder helst händelser för att kommunicera med varandra. Detta hjälper till att minimera risken för sammanhängande fel.

Försök utföra misslyckade åtgärder igen. Tillfälliga fel kan inträffa på grund av tillfällig förlust av nätverksanslutning, en borttagen databasanslutning eller en tidsgräns när en tjänst är upptagen. Bygg in logik för omförsök i ditt program för att hantera tillfälliga fel. För många Azure-tjänster implementerar klient-SDK automatiska omförsök. Mer information finns i Tillfälliga felhantering och återförsöksmönstret.

Skydda misslyckade fjärrtjänster (kretsbrytare). Det är bra att försöka igen efter ett tillfälligt fel, men om felet kvarstår kan du få för många anrop till en tjänst som inte fungerar. Detta kan leda till sammanhängande fel när begäranden säkerhetskopieras. Använd kretsbrytarmönstret för att misslyckas snabbt (utan att göra fjärranropet) när en åtgärd sannolikt kommer att misslyckas.

Isolera kritiska resurser (vattentäta skott). Fel i ett delsystem kan ibland spridas. Detta kan inträffa om ett fel gör att vissa resurser, till exempel trådar eller socketar, inte frigörs i tid, vilket leder till resursöverbelastning. Undvik detta genom att använda mönstret Skott för att partitionera ett system i isolerade grupper så att ett fel i en partition inte hindrar hela systemet.

Utför belastningsutjämning. Program kan uppleva plötsliga trafiktoppar som kan överbelasta tjänster på serverdelen. Undvik detta genom att använda mönstret Köbaserad belastningsutjämning för att köa arbetsobjekt för att köra asynkront. Kön fungerar som en buffert som jämnar ut toppar i belastningen.

Redundansväxling. Om en instans inte går att nå, kan du redundansväxla till en annan instans. Placera flera instanser bakom en lastbalanserare eller Traffic Manager för saker som är tillståndslösa, som en webbserver. Använd repliker och redundansväxling för saker som lagrar tillstånd, t.ex. en databas. Beroende på datalagret och hur det replikeras kan programmet behöva hantera eventuell konsekvens.

Kompensera för misslyckade transaktioner. Undvik i allmänhet distribuerade transaktioner, eftersom de kräver samordning över tjänster och resurser. Skapa i stället en åtgärd från mindre enskilda transaktioner. Om åtgärden misslyckas halvvägs använder du kompenserande transaktioner för att ångra eventuella steg som redan slutförts.

Kontrollpunkt för långvariga transaktioner. Kontrollpunkter kan tillhandahålla återhämtningskapacitet om en tidskrävande åtgärd misslyckas. När åtgärden startar om (om den till exempel övertas av en annan virtuell dator), kan den återupptas från den senaste kontrollpunkten. Överväg att implementera en mekanism som registrerar tillståndsinformation om uppgiften med jämna mellanrum och spara det här tillståndet i varaktig lagring som kan nås av alla instanser av processen som kör uppgiften. På så sätt kan arbetet som den utförde återupptas från den senaste kontrollpunkten med hjälp av en annan instans om processen stängs av. Det finns bibliotek som tillhandahåller den här funktionen, till exempel NServiceBus och MassTransit. De bevarar transparent tillstånd, där intervallen är anpassade till bearbetningen av meddelanden från köer i Azure Service Bus.

Försämra på ett smidigt sätt och håll dig responsiv under fel. Ibland kan du inte undvika ett problem, men du kan tillhandahålla nedsatt funktionalitet som fortfarande är användbar. Tänk dig ett program som visar en katalog med böcker. Om programmet inte kan hämta miniatyrbilden för omslaget kan det visas en platshållarbild istället. Hela delsystem kanske är icke-kritiska för programmet. På en e-handelswebbplats är det till exempel troligtvis mindre viktigt att visa produktrekommendationer än att bearbeta beställningar.

Begränsa klienter. Ibland skapar ett litet antal användare hög belastning som kan minska programmets tillgänglighet för andra användare. I så fall kan du begränsa klienten under en viss tidsperiod. Se begränsningsmönstret.

Blockera obehöriga. Bara för att du begränsar en klient, innebär det inte att klienten handlade illvilligt. Det betyder bara att klienten har överskridit sin kvot av tjänsten. Men om en klient upprepade gånger överskrider sin kvot eller på annat sätt handlar felaktigt, kan du behöva blockera dem. Definiera en out-of-band-process för användaren att begära att blockeringen hävs.

Använd val av ledare. När du vill samordna en aktivitet använder du Val av ledare för att välja en koordinator. På så sätt är koordinatorn inte en enskild felpunkt. Om koordinatorn misslyckas, väljs en ny. Överväg att använda ett standardprogram, till exempel Zookeeper, i stället för att implementera en algoritm för val av ledare från grunden.

Testa med felinmatning. Alltför ofta testas rätt väg, men inte fel väg. Ett system kan användas i produktion under lång tid innan en felaktighet inträffar. Använd felinmatning för att testa elasticiteten i systemet vid fel, antingen genom att utlösa faktiska fel eller genom att simulera dem.

Omfatta kaostekniker. Chaos Engineering utökar begreppet felinmatning genom att slumpmässigt mata in fel eller onormala förhållanden i produktionsinstanser.

Använd tillgänglighetszoner. Många Azure-regioner tillhandahåller tillgänglighetszoner, som är isolerade uppsättningar med datacenter i regionen. Vissa Azure-tjänster kan distribueras zonindelat, vilket säkerställer att de placeras i en specifik zon och kan bidra till att minska svarstiden vid kommunikation mellan komponenter i samma arbetsbelastning. Alternativt kan vissa tjänster distribueras med zonredundans, vilket innebär att Azure automatiskt replikerar resursen mellan zoner för hög tillgänglighet. Överväg vilken metod som ger den bästa uppsättningen kompromisser för din lösning. Mer information om hur du utformar din lösning för att använda tillgänglighetszoner och regioner finns i Rekommendationer för användning av tillgänglighetszoner och regioner.

En strukturerad metod för att göra dina program självåterställning finns i Designa tillförlitliga program för Azure.