När servrar är nere kan det leda till avbrott i dina affärsmål och resultera i förlust av intäkter. Till exempel kanske ett flygbolag inte kan boka flyg till kunder om instanser och databaser inte är tillgängliga. System kan misslyckas av en mängd olika anledningar, såsom brand, mänskliga fel, datorfel, diskfel och programmeringsfel.
För att undvika störningar och säkerställa att det finns kontinuitet i företagstjänster är det extremt viktigt att ha strategier för hög tillgänglighet (HA) och katastrofåterställning (DR). HA och DR diskuteras ofta tillsammans. HA är måna om att minska serverns driftstopp så mycket som möjligt, men eftersom inget system är perfekt fokuserar DR på processen att använda backupmediet för att återställa förlorad data i händelse av att databassystemet skulle gå ner.
AlwaysOn är en varumärkes-/marknadsföringsterm som använts sedan SQL Server 2012 för att beskriva Microsofts förbättrade HADR-funktioner. Innan AlwaysOn stödde databasmotorn andra, inbyggda proprietära lösningar, såsom databasspegling, failover-kluster och loggsändning. Men var och en av dessa tekniker kom med fördelar och begränsningar. Ofta, beroende på dess mål, var en organisation tvungen att kombinera flera metoder för att uppnå en önskvärd HADR-strategi.
AlwaysOn-funktioner introducerades så att du inte behöver ta itu med extra tid och resurser för att implementera och införa komplexitet i driftsättningen för att ta hänsyn till både server- och databasredundans, stöta på problem med skalning eller ha standby-hårdvara som inte används effektivt. Dessa funktioner kombinerar bekvämt många av de gamla metoderna och förbättrar områden där de misslyckades. För att verkligen förstå värdet av AlwaysOn-erbjudanden är det viktigt att se över de ursprungliga grundläggande koncepten för hur databasmotorn säkerställde systemets HADR tidigare.
Databasspegling
Databasredundans kan åstadkommas genom spegling. Du kan till exempel ha en intäktsgenererande, front-end klientapp som låter elever beställa läroböcker online. En kund väljer sitt köp och förfrågningar görs mot PsychologyBooks-databasen på baksidan. I händelse av en katastrof som gör PsychologyBooks-databasen otillgänglig, kommer studenten inte att kunna slutföra sin beställning.
För att undvika denna störning kan du ha en huvudinstans utplacerad i produktionen som innehåller PsychologyBooks-databasen och ha en extra kopia av den PsychologyBooks-databasen på en speglad server i vänteläge. Klientappar kan återansluta till den speglade kopian istället för att uppleva avbrott och behöva vänta på att återställningen ska avslutas på den primära. Kopian håller jämna steg med ändringarna som gjorts på originalet genom att ta emot transaktionsloggar och sedan göra om de registrerade ändringarna.
Speglingssessioner kan fungera i olika lägen beroende på prestanda eller högsäkerhetsmotivering. Lämpligen stöds automatisk failover när speglingssessionen körs i synkront läge med hög säkerhet och kvorumkonsensus upprättas med närvaro av en valfri vittnesserver.
Trots fördelarna med spegling kommer den till kort eftersom den bara ger databasredundans, inte serverredundans. Det betyder att om den primära serverinstansen går ner kommer båda instanserna att gå ner, och det spelar ingen roll att det finns en extra kopia av data på databasnivå. Vänteläget stöder inte användaroperationer, och ögonblicksbilder skulle behövas för att få en skrivskyddad kopia av data på den speglade instansen. Databasen är skyddad, men objekten på servernivå, som serverrollmedlemskap, inloggningsinformation och agentjobb, är det inte.
Till exempel, om det fanns ett stort marknadsföringsteam och varje medlem hade sin egen inloggning, skulle de behöva gå igenom processen att återskapa inloggningar för varje person på nytt. När failover inträffar sker det på en oberoende databas och inte som en grupp.
Failover Clustering
Failover-klustring erbjuder redundans på instansnivå och ger skydd mot maskinvaru- och operativsystemfel. Säg till exempel att en nod i Queen Anne brinner och orsakar ett utrustningsfel. Hela instansen – som inkluderar objekt på instansnivå, såsom inloggningar eller specifika jobb som skapades för att utföra specifika uppgifter – kommer att skyddas och kan automatiskt starta om på en annan nod som tillhör klustret. Klientappar och -tjänster kommer att fortsätta att vara tillgängliga för kunder.
Ovanstående scenario fungerar eftersom lagring delas mellan redundanta fysiska servrar i en Windows Server Failover Cluster-grupp (WSFC). Både OS och SQL Server fungerar tillsammans så att endast en nod äger WSFC-resursgruppen åt gången.
Tyvärr, med en gemensam lagring, ger denna lösning inte den databasredundans som den tidigare speglingsstrategin gav. Att ha en delad lagring innebär risk eftersom det resulterar i en enda punkt av fel. Till exempel kan de externa diskarna innehålla den enda kopian av den viktiga PsychologyBooks-databasen och trots att instansen misslyckades till Ballard-noden, skulle det fortfarande uppstå avbrott i affärsmålen om den enda lagringskomponenten äventyras. Failover-klustring föreslår också begränsningar i termer av skalbarhet eftersom klientappar inte kan hantera en växande mängd arbete som expanderar längre än klustret.
Loggleverans
En annan metod för att uppnå databasredundans är genom loggsändning. Transaktionsloggar säkerhetskopieras på den primära servern och skickas till en eller flera sekundära servrar för att återställas. Till skillnad från spegling kan den eller de sekundära databaserna vara kvalificerade för skrivskyddad aktivitet, och loggsändningsfrekvensen kan konfigureras för olika intervall. Det finns en prestandafördel i scenarier där sekundära databaser inte nödvändigtvis behöver vara synkroniserade med den primära databasen i realtid.
Att till exempel köra en statistisk sammanfattningsrapport i slutet av natten för att se vilka psykologiböcker som säljs under dagen kräver inte att kopisdatabasen är exakt synkroniserad med den primära databasen. Läsintensiv aktivitet placerar lås på databasobjekt och kan driva upp väntetiderna. Att köra rapportering på en sekundär server skulle därför avlasta arbetsbelastningen på den primära intäktsgenererande servern.
Nackdelen är att loggsändning inte stöder automatisk failover. Därför, om källservern misslyckas, måste databasen återställas manuellt. Liksom spegling ger loggsändning inte serverredundans och är en lösning på databasnivå.
Förstå AlwaysOn
Gamla tekniker har var och en sina fördelar och avvägningar. Men att implementera en skräddarsydd HADR-lösning kan snabbt bli komplicerat och kräva mer hantering eftersom dessa olika strategier är godtyckligt blandade och matchade för att möta affärsbehov. Därför introducerades AlwaysOn-funktionerna och ger en förbättrad, redan kombinerad version av tidigare strategier.
SQL Server erbjuder två funktioner:AlwaysOn Availability Groups (AG) och AlwaysOn Failover Cluster Instances (FCI). Båda kräver att Windows Server Failover Clustering (WSFC) implementeras.
En AG är en grupp databaser som kommer att failover tillsammans. Du behöver flera redundanta fysiska noder med en SQL Server-instans installerad på var och en av noderna för att vara värd för tillgänglighetsreplikerna. Varje replik måste vara på en annan nod i samma WSFC. I schemat ovan är den primära repliken värd på Nod 01, och alla andra sekundära repliker är kvalificerade för failover när WSFC känner av att det finns ett problem.
Sättet som de sekundära replikerna förblir synkroniserade med de primära är genom att skicka transaktionsloggar och göra om ändringarna. AG stöder både asynkront och synkront commit-läge. Den primära repliken är kvalificerad för läsning och skrivning, medan de sekundära replikerna är berättigade att endast läsa. Säkerhetskopiering kan utföras på den sekundära platsen.
Det finns genast fördelar med AlwaysOn AG. Minns från tidigare att några av bristerna med databasspegling är att en databas endast kan speglas till en sekundär server och att varje databas speglas oberoende av varandra när failover inträffar. Med AG görs databaser överflödiga på många ställen, till exempel Nod 02, Nod 03, Nod 04 och Nod 05 i exemplet ovan. Databastillgänglighetsstöd tillåter upp till nio tillgänglighetsrepliker.
Dessutom skulle loggsändning vara nödvändig för att få skrivskyddad data på den sekundära servern. Men med AG redovisas redan skrivskyddad data. Läsintensiva aktiviteter såsom rapportering kan utföras på vilken som helst av de sekundära replikerna. Observera också att det inte finns en delad lagringsbegränsning.
AG kan dock kombineras med AlwaysOn FCI för att tillåta serverredundans. En FCI-instans kan användas för att vara värd för tillgänglighetsreplikerna så att objekt på servernivå som inloggningar och agentjobb också kan skyddas. Detta tillvägagångssätt kräver delad lagring. Emellertid kommer olägenheter som att behöva utföra omkonfigurationer för klientapparna att elimineras.