Haverier och feltolerans
I vardagen brukar vi tala ganska allmänt om orsakerna till att system havererar. Problem, fel, haveri, bugg och defekt – dessa termer brukar användas på samma sätt. I datacenter bör IT-personal alltid skilja mellan dessa ord och använda rätt term för rätt företeelse. Här är en exakt definition av de termer som är relevanta för diskussioner kring feltolerans:
En bugg är en avvikelse i utformningen av ett system som gör att dess beteende varierar konsekvent utifrån dess krav eller förväntningar. På ett sätt kan detta utgöra ett misslyckande hos system eller programvara att uppfylla förväntningarna, men en bugg är inte ett haveri i systemet. I själva verket härrör många buggar från system som fungerar exakt som de har utformats, vilket skiljer sig från avsikten. Nyckelordet här är "konsekvent". En buggs beteende kan återskapas i alla systeminstanser. Felsökning (buggsökning) handlar om att göra om systemet för att avlägsna buggar.
Ett fel är en avvikelse i ett system som gör att det beter sig i motsats till dess design eller att det helt slutar fungera. I det här fallet är det kanske inte något snett med systemets design, men det fungerar kanske inte korrekt i en implementering eller instans av den designen. Problem leder till beteenden som inte kan förväntas reproduceras i någon annan instans av systemet. Åtgärden för att eliminera problem kallas reparation. Systemproblem kan uppstå på ett av tre sätt:
Ett permanent problem är ett avbrott i ett system vars orsak inte kan åtgärdas utan fullständigt utbyte av den felaktiga komponenten
Ett tillfälligt problem är en tillfällig, men ofta upprepad, systemstörning vars orsak kan repareras eller åtgärdas på plats eller som kanske upphör utan åtgärd
Ett återkommande problem är en tillfällig systemstörning som vanligtvis är återkommande. Det orsakas av degradering eller felaktig design av en komponent och kan leda till ett permanent problem om det inte korrigeras.
Ett haveri är en fullständig kollaps av hela systemet eller delar av det. Detta beror ofta på ett fel som inte har korrigerats. I det här fallet är felet orsaken, och haveriet är följden. Ett feltolerant (FT) system är ett system som fungerar som förväntat, eller enligt förväntningarna i ett serviceavtal (SLA), under negativa omständigheter och därmed undviker haveri när det uppstår fel.
En defekt är en avvikelse i tillverkningen av en maskinvarukomponent eller instansieringen av en programvarukomponent som leder till ett fel i driften och sannolikt haveri i det system som implementerar komponenten. Sådana avvikelser kan bara åtgärdas genom ersättning.
Ett problem är resultatet av en åtgärd som producerar ett oönskat eller felaktigt resultat. I en databehandlingsenhet kan ett problem tyda på en bugg i designen eller ett fel i implementeringen, och det kan vara en effektiv indikator på ett kommande haveri.
Underhåll av feltoleranta system kräver en IT-specialist, administratör eller operatör som förstår dessa begrepp och skillnaderna mellan dem. En plattform för molnbaserad databehandling är per definition ett feltolerant system. Den har utformats och skapats för att hantera fel och arbetar på att undvika tjänsthaveri. Från ett tekniskt perspektiv är denna motståndskraft det som begreppet ”moln” handlar om. När telefonteknikerna först använde en molnfigur i sina systemdiagram representerade den komponenter i nätverket som inte behövde ses eller förstås, men vars servicenivåer var tillförlitliga nog att de inte behövde ingå i diagrammet – de kunde täckas av ett moln.
När ett informationssystem, till exempel ett företags IT-nätverk, kontaktar en offentlig molnplattform har plattformen en skyldighet att bete sig som ett FT-system. Däremot kan det inte göra det system kommunicerar med det mer feltolerant än det redan är. Feltolerans är inte immunitet, och är inte heller en garanti mot förekomst av fel i ett system. Än viktigare är att ett FT-system inte nödvändigt är felfritt. Snarare handlar feltolerans om förmågan hos ett system att förväntade upprätthålla förväntade servicenivåer när fel uppstår.
Syftet med alla informationssystem är att automatisera de funktioner som använder information. Själva feltoleransen kan bara automatiseras till en viss grad. I sin ursprungliga form som ARPANET hade Internet feltolerans som ett av huvudmålen. Vid en katastrof kan digitala kommunikationer omdirigeras för att kringgå ett system vars adress inte längre kan nås. Internet är dock inte någon självunderhållande maskin – det gäller alla informationssystem.
Alla informationssystem kräver kontinuerligt mänskligt arbete för att uppnå och underhålla servicemålen. De bästa systemen gör mänsklig inblandning och reparationer enkla, omedelbara och planerade.
Feltolerans på molnplattformar
Tidiga molntjänstplattformar var snällt uttryckt mindre feltoleranta än vad arkitekterna avsåg. Till exempel visade sig möjligheten för en kund att överetablera resurser för tjänster såsom flera databasinstanser eller duplicerade cacheminnen vara ineffektiv vid otillräcklig övervakning, vilket ibland ledde till att säkerhetskopior eller repliker blev otillgängliga vid katastrofer. Dessutom går överetablering tvärt emot en av de grundläggande principerna i molnaffärsmodellen: att endast betala för de resurser som behövs. Organisationer kan inte spara driftskostnader om de hyr extra VM-instanser ifall den primära virtuella datorn slutar fungera.
FT-system möjliggör redundans, men på ett smart och dynamiskt sätt. Det justerar utefter aktuellt behov och gränserna för resurstillgänglighet. I klient/server-modellens tidsålder säkerhetskopierades regelbundet hela servrar, inklusive både lokal datalagring och nätverkets lagringsvolymer som de var kopplade till. ”Säkerhetskopiera allt” blev till en egen företagsregel. När offentliga molntjänster blev både prisvärda och praktiska började organisationer använda dem för att "säkerhetskopiera allt". Med tiden kom de att inse att molnet kunde göra mer än att vidmakthålla de gamla metoderna. Molnplattformar kunde utformas med feltolerans redan från början i stället för att göras feltoleranta efter implementeringen.
Reaktiva tekniker
Oavsett hur noggrant ett system utformas beror största delen av dess feltolerans på hur väl systemet och dem som hanterar det reagerar på det första tecknet på fel. Här följer några av de reaktiva tekniker som organisationer använder för att åtgärda fel när de uppstår.
Icke-förebyggande jobbmigrering
Tekniken med icke-förebyggande jobbmigrering ser till att värden för en arbetsbelastning som verkar ha drabbats av ett fel inte tilldelas uppgiften att vara värt för samma arbetsbelastning. Detta skyddar ”jobbet” men kan hindra systemet från att samla in upprepade förekomster av ett problem som tecken på ett fel, vilket annars skulle göra det enklare att spåra genom en gediget loggad väg.
Uppgiftsreplikering
Många distribuerade informationssystem kör flera instanser (eller repliker för Kubernetes-orkestrering) av en uppgift samtidigt. System för principbaserad hantering kan anpassas till att replikera en uppgift om det finns ett bevisat eller misstänkt systemfel.
Kontrollpunkter och återställningspunkter
Den enklaste formen av kontrollpunkter och återställningspunkter handlar om att ta ögonblicksbilder av systemet vid olika tidpunkter och låta administratörer ”återställa” till en viss tidpunkt om det blir nödvändigt att återställa systemet. Den här strategin blir mer komplicerad när det förekommer transaktioner – till exempel när ett program utför två eller fler åtgärder på en databas som måste lyckas eller misslyckas som en enhet (en ”transaktion”). Ett vanligt exempel är ett program som krediterar pengar från ett konto och samtidigt debiterar det från ett annat. Dessa åtgärder måste lyckas eller misslyckas som en enhet så att finansiella tillgångar inte skapas eller förstörs.
I ett återställningssystem med transaktionskontrollpunkter lagras anropsbara poster av transaktioner i minnet i ett processträd. Vid vissa tillfällen under en transaktion replikeras och lagras de minnesresurser som används i en återställningspool. Om logganalys tyder på ett fel som kan bero på programvara förgrenas processträdet, transaktionstillståndet flyttas tillbaka till en tidigare tidpunkt och försök görs med en ny transaktion. Om den nya transaktionen ger bättre resultat än den felaktiga (till exempel om ett problemkorrigeringstest blir godkänt) rensas den gamla processgrenen, och en ny gren följs därefter i trädet. Tekniker kallar detta för ett kontextbyte.1
I en avancerad version av den här metoden implementeras ett spårningssystem i processträdet. När ett problem uppstår igen kan systemet gå bakåt i processen och spåra orsaken till problemet. Sedan kan det välja en lämplig återställningspunkt, eller ”räddningspunkt”, före den tidpunkt då problemet utlöstes.[2]
En annan implementering, som kallas SGuard, skapades av forskare vid University of Washington och Microsoft Research för feltolerant bearbetning av stora dataströmmar. SGuard använder Hadoop Distributed File System (HDFS) för att schemalägga samtidig skrivning av flera ögonblicksbilder av dataströmmar under bearbetningen. Dessa ögonblicksbilder delas in i mindre delar vid behov, som i sin tur delar in strömbearbetning i mindre segment. Kontrollpunkter lagras i HDFS. Systemet har den fördel att det upprätthåller ett register över strömmande datatransaktioner samt flera fungerande repliker av strömmande data på starkt distribuerade platser. Det krävs avsevärt förberedande arbete för att implementera SGuard, men det anses ändå vara en reaktiv feltoleransteknik eftersom dess huvudåtgärd utlöses som svar på en felhändelse.3
Proaktiva tekniker
En proaktiv FT-teknik vidtas innan fel upptäcks. Den syftar till att vara förebyggande, men i dess moderna implementering blir detta snarare en metod än ett mantra. Här är några av de tekniker som för närvarande används av moderna molnplattformar.
Resursreplikering
Nyckeln till en effektiv strategi för resursreplikering kanske inte bara är att "säkerhetskopiera allt". En systemanalytiker bör kunna fastställa vilka resurser i ett system (till exempel en databasmotor, webbserver eller virtuell nätverksrouter) som kan återställas efter en felhändelse och vilka som kan vara oåterkalleliga. Smart replikering är kanske den första försvarslinjen i ett feltolerant system.
Det finns fyra vanliga strategier som används för att implementera resursreplikering. Alla dessa visas i bild 1:
Aktiv replikering – alla replikerade resurser är aktiva samtidigt, och alla upprätthåller oberoende sina egna tillstånd, det vill säga lokala data som gör att de fungerar. Den här egenskaper innebär att en klients begäranden tas emot av alla replikerade resurser i en klass och att alla resurser bearbetar ett svar. Däremot är det svaret från den utsedda primära resursen i den klassen som levereras till klienten. Om en resurs misslyckas, inklusive den primära noden, utses en annan nod till efterföljare. Det här systemet kräver att bearbetningen mellan den primära noden och repliknoden är deterministisk – att den sker tillsammans och enligt ett fast schema.
Halvaktiv replikering – halvaktiv replikering likar aktiv replikering. Skillnaden är att repliknoder kan bearbeta begärande icke-deterministiskt, det vill säga inte tillsammans med den primära noden. Utdata från de sekundära resurserna ignoreras och loggas, och de är redo att växla över så snart ett haveri i den primära resursen inträffar.
Passiv replikering – endast den primära resursnoden bearbetar begäranden medan de andra (replikerna) upprätthåller tillståndet och väntar på att utses till primära om ett haveri inträffar. Den primära resurs som klienten är i kontakt med skickar eventuella tillståndsändringar till alla repliker. Alla original och repliker som tillhör en klass anses vara ”medlemmar” i en grupp, och en medlem kan uteslutas från gruppen om den verkar ha misslyckats (även om den i själva verket inte misslyckades). Svarstider eller degradering av tjänstkvaliteten (QoS, Quality of Service) kan ske under ett haveri, men passiv replikering förbrukar färre resurser under normal drift.
Halvpassiv replikering – den här metoden har samma relationsmönster som för passiv replikering, förutom att det inte finns någon permanent primär resurs. I stället ges rollen koordinator till varje resurs i turordning. Koordinationen av turordning avgörs av en tokensändningsmodell som kallas paradigmet för roterande koordinator.
Bild 1: Klientnoder, primära noder och repliknoder i ett replikerat informationssystem.
Belastningsutjämning
Lastbalanserare fördelar begäranden från olika klienter till flera servrar som kör samma program, vilket fördelar arbetsbelastningen och minskar bördan för systemkomponenter. En positiv bieffekt av lastbalanserare är att vissa automatiskt dirigerar bort trafik från servrar som inte svarar och därmed minskar risken för haverier. I mer moderna varianter där programvaran utformats att distribueras på en molnplattform (till exempel mikrotjänster) delas arbetsbelastningar in bland separata funktioner. Dessa funktioner distribueras i sin tur bland processorer på serversidan med målet att uppnå en jämn fördelning och måttliga förbrukningsnivåer.
Virtualisering (huvudkomponenten i molnbaserad databehandling) möjliggör mer jämnt fördelade arbetsbelastningar bland processorer genom att göra dem portabla, så att de kan flyttas till den fysiska processor som använder dem optimalt. Containerisering förbättrar den här tekniken genom att skilja virtualiserade arbetsbelastningar från processorer så att de finns i servernoden med det operativsystem som är mest lämpat för dem. Den här principen är viktig för orkestrering av arbetsbelastningar, vilket demonstreras av system såsom Kubernetes.
Föryngring och omkonfiguration
I informationssystem där instanser av programvara distribueras under längre tidsperioder kan det bli nödvändigt att starta om den programvaran. Vissa tidigare molnplattformar försökte samla servicenivåer för programvaruinstanser över tid för att avgöra när omstart krävs, men senare varianter använder den enklare metoden att schemalägga periodiska omstarter. Under dessa omstartsfaser kan konfigurationsfiler för omstart automatiskt justeras utefter föränderliga systemförhållanden eller för att förebygga potentiellt haveri efter starten.
Förebyggande migrering
När virtualisering först blev vanligt i datacenter föreslogs förebyggande migrering som en metod för att jämna ut bördan på servermaskinvara genom att rotera tilldelningar av arbetsbelastningar till processorer, till exempel enligt principen om turordning. Molnplattformar omdistribuerar arbetsbelastningar i den virtuella infrastrukturen ofta nog att den här metoden i stort sett inte längre är nödvändig. På senare tid har det här ämnet dock börjat dyka upp i diskussioner när det gäller artificiellt intelligenta metoder som förutser börda från arbetsbelastningar i mångsidiga informationssystem. Sådana system skulle kunna skapa sina egna regler för att dirigera de viktigare arbetsbelastningarna bort från servernoder som förutses ha en stor sannolikhet att drabbas av haveri.
Självläkning
I ett starkt distribuerat informationssystem, till exempel ett nätverk för innehållsleverans (CDN) eller en plattform för sociala medier, kan funktionerna för enskilda servrar vara spridda över flera adresser, ofta på olika platser eller i olika datacenter. Självläkande nätverk avsöker de olika anslutningarna regelbundet (som en plattform för prestandahantering) för trafikflöden och responsivitet. När det sker en felmatchning av prestanda kan routrar styra bort begäranden från misstänkta komponenter och så småningom stoppa trafikflödet genom de komponenterna. Sedan kan driftstatusen för den komponenten testas efter tecken på problem. Komponenten kan därefter startas om så att det framgår om beteendet fortsätter. Den återgår endast till aktiv status om diagnostiken inte visar sannolikhet för ett fel. Den här typen av automatiserad transaktionsbaserad responsivitet är ett modernt exempel på självläkning i starkt distribuerade datacenter.4
Byteshandelsbaserad processchemaläggning
En molnplattform (vilket inbegriper tjänster som baseras på offentligt moln men även lokal infrastruktur) har en unik förmåga att rapportera sin egen status. När Amazon började implementera en reviderad SaaS-modell år 2009 tog deras tekniker fram ett begrepp som kallas punktinstansschemaläggning. I det här systemet kommunicerar ett system å kundens vägnar resurskraven för ett visst jobb och sänder ut en typ av begäran på bud, specifikt från servernoder på molnplattformen. Varje nod rapporterar sin egen förmåga att uppfylla kraven i budet vad gäller tid och förbrukade resurser. Det billigaste budet vinner kontraktet och utses till punktinstans (SI, Spot Instance) för jobbet. Den här schemaläggningsmetoden är för närvarande ett alternativ för Amazon Elastic Compute Cloud.5
Referenser
Ioana, Cristescu. A Record-and-Replay Fault Tolerant System for Multithreading Applications. Technical University of Cluj Napoca. http://scholar.harvard.edu/files/cristescu/files/paper.pdf.
Sidiroglou, Stelios, et al.FÖRSÄKRA: Automatisk programvara självåterställning med hjälp av räddningspunkter. Columbia University, 2009.
Kwon Yong-Chul, et al. Feltolerant dataströmbearbetning med hjälp av ett distribuerat, replikerat filsystem. Association for Computing Machinery, 2008. https://db.cs.washington.edu/projects/moirae/moirae-vldb08.pdf.
Yang, Chen. Kontrollpunkt och återställning av mikrotjänsten i Docker-containrar. School of Information Security Engineering, Shanghai Jiao Tong University, Kina, 2015. https://download.atlantis-press.com/article/25844460.pdf.
Amazon Web Services, Inc. Spot Instance Requests Amazon, 2020. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html.