I den verkliga världen kan det finnas situationer då en nedgång i prestanda för dina servrar kan inträffa på grund av händelser, från en plötslig spik i trafiken kan leda till ett plötsligt strömavbrott. Det kan vara mycket värre och dina servrar kan lamslås – oavsett om dina applikationer finns i molnet eller på en fysisk maskin. Sådana situationer är oundvikliga. Men i stället för att hoppas på att det inte ska inträffa är det du faktiskt bör göra att växla upp så att dina system inte drabbas av fel.
Svaret på problemet är att använda konfigurationen eller arkitekturen för hög tillgänglighet (High Availability (HA)). Arkitektur för hög tillgänglighet är ett tillvägagångssätt för att definiera komponenter, moduler eller implementering av tjänster i ett system som säkerställer optimal driftsprestanda, även vid hög belastning. Även om det inte finns några fasta regler för att implementera HA-system finns det i allmänhet några goda rutiner som man måste följa så att man får ut det mesta av de minsta resurserna.
Varför behöver du det?
Låt oss definiera stilleståndstid innan vi går vidare. Nedtid är den tidsperiod då ditt system (eller nätverk) inte är tillgängligt för användning eller inte svarar. Driftstopp kan orsaka ett företag stora förluster, eftersom alla deras tjänster sätts på undantag när deras system är nere. I augusti 2013 låg Amazon nere i 15 minuter (både webb- och mobiltjänster) och förlorade till slut över 66 000 dollar per minut. Det är enorma siffror, även för ett företag av Amazons storlek.
Det finns två typer av driftstopp – planerade och oplanerade. En planerad driftstopp är ett resultat av underhåll, vilket är oundvikligt. Detta inkluderar applicering av patchar, uppdatering av mjukvara eller till och med ändringar i databasschemat. Ett oplanerat driftstopp orsakas däremot av en oförutsedd händelse, t.ex. maskinvaru- eller programvarufel. Detta kan ske på grund av strömavbrott eller fel på en komponent. Planerade driftsstopp är i allmänhet uteslutna från beräkningar av prestanda.
Det främsta målet med att implementera högtillgänglighetsarkitektur är att se till att ditt system eller program är konfigurerat för att hantera olika belastningar och olika fel med minimal eller ingen driftsstopp. Det finns flera komponenter som hjälper dig att uppnå detta, och vi kommer att diskutera dem kort.
Hur mäts tillgänglighet?
Organisationer som planerar att fullt ut utnyttja en molninfrastruktur måste också kunna uppfylla kraven på tillgänglighet dygnet runt. Tillgängligheten kan mätas som den procentuella andelen tid som systemen är tillgängliga.
x = (n – y) * 100/n
Varvid n är det totala antalet minuter under en kalendermånad och y är det totala antalet minuter som tjänsten är otillgänglig under den givna kalendermånaden. Med hög tillgänglighet avses helt enkelt en komponent eller ett system som är kontinuerligt funktionsdugligt under en önskvärd lång tidsperiod. Den allmänt accepterade men nästan omöjliga standarden för tillgänglighet för en produkt eller ett system kallas ”fem nior” (99,999 procent). Hög tillgänglighet är ett krav för alla företag som vill skydda sin verksamhet mot de risker som ett systemavbrott medför. Dessa risker kan leda till miljontals dollar i intäktsförluster.
Är det verkligen värt pengarna?
Det faktum att en högtillgänglighetsarkitektur ger högre prestanda är okej, men det har också en stor kostnad. Du måste fråga dig själv om du tycker att beslutet är motiverat ur ekonomisk synvinkel.
Det måste fattas ett beslut om huruvida den extra drifttiden verkligen är värd den summa pengar som måste satsas på den. Du måste fråga dig själv hur skadlig potentiell stilleståndstid kan vara för ditt företag och hur viktiga dina tjänster är för att driva ditt företag.
Hur uppnår vi det?
När du nu har bestämt dig för att gå med på det, låt oss diskutera sätten att genomföra det. Att lägga till fler komponenter till ett system hjälper inte till att göra det stabilare och uppnå hög tillgänglighet, vilket inte är intuitivt. Det kan faktiskt leda till motsatsen eftersom fler komponenter ökar sannolikheten för fel. Moderna konstruktioner gör det möjligt att fördela arbetsbelastningen på flera instanser, t.ex. ett nätverk eller ett kluster, vilket bidrar till att optimera resursanvändningen, maximera produktionen, minimera svarstiderna och undvika överbelastning av något system i den process som kallas lastbalansering. Det innebär också att man byter till en reservresurs som en server, en komponent eller ett nätverk vid fel på en aktiv resurs, så kallade Failover-system.
Användning av flera applikationsservrar:
Föreställ dig att du har en enda server för att återge dina tjänster och att en plötslig ökning av trafiken leder till att den misslyckas (eller kraschar). I en sådan situation kan inga fler förfrågningar behandlas tills servern startas om, vilket leder till driftstopp.
Den uppenbara lösningen här är att distribuera din applikation över flera servrar. Du måste fördela belastningen mellan alla dessa, så att ingen av dem blir överbelastad och resultatet blir optimalt. Du kan också distribuera delar av din applikation på olika servrar. Det kan till exempel finnas en separat server för hantering av e-post eller en separat server för behandling av statiska filer som bilder (som ett Content Delivery Network).
Skalering av databaser:
Databaser är det mest populära och kanske ett av de mest konceptuellt enkla sätten att spara användardata. Man måste komma ihåg att databaser är lika viktiga för dina tjänster som dina applikationsservrar. Databaser körs på separata servrar (som Amazon RDS) och är också utsatta för krascher. Vad som är värre är att krascher i databaser kan leda till förlust av användardata, vilket kan visa sig vara kostsamt.
Redundans är en process som skapar system med hög tillgänglighet genom att uppnå upptäckbarhet av fel och undvika fel av gemensam orsak. Detta kan uppnås genom att upprätthålla slavar som kan träda in om huvudservern kraschar. Ett annat intressant koncept för skalning av databaser är sharding. En shard är en horisontell partition i en databas, där rader av samma tabell som sedan körs på en separat server.
Diversifierade geografiska platser:
Skalering av dina applikationer och sedan dina databaser är ett riktigt stort steg framåt, men vad händer om alla servrar finns på samma fysiska plats och något fruktansvärt, som en naturkatastrof, drabbar datacentret där dina servrar finns? Detta kan leda till potentiellt enorma driftstopp.
Det är därför absolut nödvändigt att du har dina servrar på olika platser. De flesta moderna webbtjänster gör det möjligt för dig att välja den geografiska placeringen av dina servrar. Du bör välja klokt för att se till att dina servrar är fördelade över hela världen och inte lokaliserade till ett område.
I det här inlägget har jag försökt att beröra de grundläggande idéerna som bildar idén om högtillgänglighetsarkitektur. I den slutliga analysen är det uppenbart att inget enskilt system kan lösa alla problem. Därför måste man bedöma sin situation noggrant och bestämma sig för vilka alternativ som passar bäst. Vi hoppas att detta introducerade dig till världen av högtillgänglighetsarkitektur och hjälpte dig att bestämma hur du ska gå tillväga för att uppnå detta för dig själv.
Vad är de bästa metoderna?
För att stävja systemfel och hålla både planerade och oplanerade stilleståndstider i schack är användningen av en högtillgänglighetsarkitektur (HA-arkitektur) starkt rekommenderad, särskilt för verksamhetskritiska tillämpningar. Tillgänglighetsexperter insisterar på att för att ett system ska vara högtillgängligt måste dess delar vara väl utformade och rigoröst testade. Det kan vara svårt att utforma och genomföra en högtillgänglighetsarkitektur med tanke på det stora utbudet av mjukvaru-, hårdvaru- och installationsalternativ. En framgångsrik insats börjar dock vanligtvis med tydligt definierade och heltäckande förståeliga verksamhetskrav. Den valda arkitekturen bör kunna uppfylla de önskade nivåerna av säkerhet, skalbarhet, prestanda och tillgänglighet.
Det enda sättet att garantera att beräkningsmiljöer har en önskvärd nivå av driftskontinuitet under produktionstid är att utforma dem med hög tillgänglighet. Förutom att utforma arkitekturen på rätt sätt kan företag hålla viktiga applikationer online genom att följa de rekommenderade bästa metoderna för hög tillgänglighet.
- Säkerhetskopiering, återställning och replikering av data
Kännetecknet för en bra dataskyddsplan som skyddar mot systemfel är en bra strategi för säkerhetskopiering och återställning. Värdefulla data bör aldrig lagras utan ordentliga säkerhetskopior, replikering eller möjlighet att återskapa data. Varje datacenter bör planera för dataförlust eller korruption i förväg. Datafel kan skapa problem med kundautentisering, skada finansiella konton och därefter affärsverksamhetens trovärdighet. Den rekommenderade strategin för att upprätthålla dataintegriteten är att skapa en fullständig säkerhetskopia av den primära databasen och sedan stegvis testa källservern för att upptäcka dataskador. Att skapa fullständiga säkerhetskopior är en viktig förutsättning för att kunna återhämta sig från katastrofala systemfel.
- Clustering
Även med den högsta kvaliteten på programvaruteknik är alla applikationstjänster tvungna att misslyckas vid någon tidpunkt. Hög tillgänglighet handlar om att leverera programtjänster oavsett fel. Clustering kan ge omedelbar failover-applikationstjänster i händelse av ett fel. En applikationstjänst som är ”klustermedveten” kan kalla resurser från flera servrar; den faller tillbaka till en sekundär server om huvudservern går offline. Ett kluster med hög tillgänglighet omfattar flera noder som delar information via delade dataminnesnät. Detta innebär att en nod kan kopplas bort eller stängas av från nätverket och resten av klustret fortsätter att fungera normalt, så länge som minst en enda nod är fullt fungerande. Varje nod kan uppgraderas individuellt och anslutas igen medan klustret fungerar. Den höga kostnaden för att köpa ytterligare hårdvara för att implementera ett kluster kan mildras genom att inrätta ett virtualiserat kluster som utnyttjar de tillgängliga hårdvaruresurserna.
- Nätverkslastbalansering
Lastbalansering är ett effektivt sätt att öka tillgängligheten för kritiska webbaserade applikationer. När instanser med serverfel upptäcks ersätts de sömlöst när trafiken automatiskt omfördelas till servrar som fortfarande är igång. Lastbalansering leder inte bara till hög tillgänglighet utan underlättar också inkrementell skalbarhet. Lastbalansering i nätverket kan åstadkommas med hjälp av antingen en ”pull”- eller en ”push”-modell. Det underlättar högre nivåer av feltolerans inom tjänstetillämpningar.
- Fail Over Solutions
Högtillgänglighetsarkitektur består traditionellt sett av en uppsättning löst kopplade servrar som har failover-funktioner. Failover är i princip ett reservdriftsläge där funktionerna hos en systemkomponent övertas av ett sekundärt system i händelse av att det primära systemet går offline, antingen på grund av fel eller planerad driftstopp. Ett ”kallt övergående” inträffar när den sekundära servern startas först efter att den primära har stängts av helt och hållet. En ”hot failover” inträffar när alla servrar är igång samtidigt och belastningen riktas helt och hållet mot en enda server vid varje given tidpunkt. I båda scenarierna överförs uppgifterna automatiskt till en reservsystemkomponent så att processen förblir så smidig som möjligt för slutanvändaren. Failover kan hanteras via DNS, i en välkontrollerad miljö.
- Geografisk redundans
Georedundans är den enda försvarslinjen när det gäller att förhindra tjänstebortfall vid katastrofala händelser, t.ex. naturkatastrofer som orsakar systemavbrott. Precis som i fallet med geo-replikering placeras flera servrar på geografiskt skilda platser. Platserna bör vara globalt fördelade och inte lokaliserade till ett visst område. Det är viktigt att köra oberoende applikationsstackar på var och en av platserna, så att om det uppstår ett fel på en plats kan den andra fortsätta att fungera. Helst ska dessa platser vara helt oberoende av varandra.
- Planera för fel
Trots det faktum att tillämpningen av de bästa metoderna för hög tillgänglighet i huvudsak är att planera för fel; det finns andra åtgärder som en organisation kan vidta för att öka sin beredskap i händelse av ett systemfel som leder till driftstopp. Organisationer bör spara data om fel eller resursförbrukning som kan användas för att isolera problem och analysera trender. Dessa uppgifter kan endast samlas in genom kontinuerlig övervakning av den operativa arbetsbelastningen. En helpdesk för återhämtning kan inrättas för att samla in probleminformation, upprätta problemhistorik och påbörja omedelbara problemlösningar. En återhämtningsplan bör inte bara vara väldokumenterad utan också testas regelbundet för att säkerställa att den är praktisk vid oplanerade avbrott. Personalens utbildning i tillgänglighetsteknik kommer att förbättra deras färdigheter när det gäller att utforma, installera och underhålla arkitekturer med hög tillgänglighet. Säkerhetsprinciper bör också införas för att minska antalet systemavbrott på grund av säkerhetsöverträdelser.
Exempel: Följande diagram förklarar hur FileCloud-servrar kan konfigureras för hög tillgänglighet för att förbättra tjänsternas tillförlitlighet och minska stilleståndstiden. Klicka här för mer information.