Når servere er nede, kan det føre til afbrydelser af dine forretningsmål og resultere i tab af omsætning. For eksempel kan et flyselskab muligvis ikke bestille flyrejser til kunder, hvis instanser og databaser ikke er tilgængelige. Systemer kan fejle af en række forskellige årsager, såsom brand, menneskelige fejl, computerfejl, diskfejl og programmeringsfejl.
For at undgå forstyrrelser og sikre, at der er kontinuitet i virksomhedsservices, er det ekstremt vigtigt at have strategier for høj tilgængelighed (HA) og disaster recovery (DR) på plads. HA og DR diskuteres ofte sammen. HA er optaget af at reducere servernes nedetid så meget som muligt, men fordi intet system er perfekt, fokuserer DR på processen med at bruge backupmediet til at gendanne tabte data i tilfælde af, at databasesystemet går ned.
AlwaysOn er et brand-/markedsføringsbegreb, der er brugt siden SQL Server 2012 til at beskrive Microsofts forbedrede HADR-funktioner. Før AlwaysOn understøttede databasemotoren andre, indbyggede proprietære løsninger, såsom databasespejling, failover-klynge og logforsendelse. Men hver af disse teknikker kom med fordele og begrænsninger. Ofte, afhængigt af dens mål, skulle en organisation kombinere flere metoder sammen for at opnå en ønskværdig HADR-strategi.
AlwaysOn-funktioner blev introduceret, så du ikke behøver at beskæftige dig med ekstra tid og ressourcer til at implementere og introducere kompleksitet i implementeringen for at tage højde for både server- og databaseredundans, støde på problemer med skalering eller have standby-hardware, der ikke bliver brugt effektivt. Disse funktioner blander bekvemt mange af de gamle praksisser sammen og forbedrer områder, hvor de kom til kort. For virkelig at forstå værdien af AlwaysOn-tilbud, er det vigtigt at gense de oprindelige grundlæggende koncepter for, hvordan databasemotoren sikrede systemets HADR tidligere.
Databasespejling
Databaseredundans kan opnås gennem spejling. For eksempel kan du have en indtægtsgenererende, front-end klient-app, der giver eleverne mulighed for at bestille lærebøger online. En kunde vælger sit køb, og anmodninger fremsættes mod PsychologyBooks-databasen på bagsiden. I tilfælde af en katastrofe, der gør PsychologyBooks-databasen utilgængelig, vil den studerende ikke være i stand til at gennemføre sin ordre.
For at undgå denne afbrydelse kan du have en hovedinstans udrullet i produktionen, der indeholder PsychologyBooks-databasen, og have en ekstra kopi af denne PsychologyBooks-database på en spejlet server på standby. Klientapps kan genoprette forbindelsen til den spejlede kopi i stedet for at opleve afbrydelse og skulle vente på, at gendannelsen afsluttes på den primære. Kopien følger ændringerne på originalen ved at modtage transaktionslogfiler og derefter gentage de registrerede ændringer.
Spejlingssessioner kan fungere i forskellige tilstande afhængigt af ydeevne eller høje sikkerhedsbegrundelser. Bekvemt understøttes automatisk failover, når spejlingssessionen drives i højsikkerhedssynkron tilstand, og der er etableret kvorumkonsensus med tilstedeværelsen af en valgfri vidneserver.
På trods af fordelene ved spejling, kommer det til kort, fordi det kun giver databaseredundans, ikke serverredundans. Det betyder, at hvis den primære serverforekomst går ned, vil begge forekomster gå ned, og det betyder ikke noget, at der er en ekstra kopi af dataene på databaseniveau. Standbyen understøtter ikke brugerhandlinger, og snapshots ville være nødvendige for at få en skrivebeskyttet kopi af dataene på den spejlede forekomst. Databasen er beskyttet, men objekterne på serverniveau, såsom serverrollemedlemskab, loginoplysninger og agentjob, er det ikke.
For eksempel, hvis der var et stort marketingteam, og hvert medlem havde deres eget login, skulle de gennemgå processen med at genskabe logins for hver person igen. Når failover forekommer, er det på en uafhængig databasebasis og ikke som en gruppe.
Failover Clustering
Failover-clustering tilbyder redundans på instansniveau og giver beskyttelse mod hardware- og operativsystemfejl. Lad os f.eks. sige, at en knude i Dronning Anne brænder og forårsager en udstyrsfejl. Hele instansen – som inkluderer objekter på instansniveau, såsom logins eller specifikke job, der blev oprettet for at udføre specifikke opgaver – vil blive beskyttet og kan automatisk genstarte på en anden node, der tilhører klyngen. Klientapps og -tjenester vil fortsat være tilgængelige for kunder.
Ovenstående scenarie fungerer, fordi lageret deles mellem redundante fysiske servere i en Windows Server Failover Cluster-gruppe (WSFC). Både OS og SQL Server arbejder sammen, så kun én node ejer WSFC-ressourcegruppen ad gangen.
Med et fælles lager giver denne løsning desværre ikke den databaseredundans, som den tidligere spejlingsstrategi gav. At have et delt lager introducerer risiko, fordi det resulterer i et enkelt fejlpunkt. For eksempel kan de eksterne diske indeholde den eneste kopi af den vigtige PsychologyBooks-database, og på trods af, at instansen mislykkedes til Ballard-noden, ville der stadig være afbrydelse af forretningsmål, hvis den eneste lagerkomponent blev kompromitteret. Failover-klynge foreslår også begrænsninger med hensyn til skalerbarhed, fordi klientapps ikke er i stand til at håndtere en voksende mængde arbejde, der udvider sig længere end klyngen.
Logforsendelse
En anden metode til at opnå databaseredundans er gennem logforsendelse. Transaktionslogfiler sikkerhedskopieres på den primære server og sendes til en eller flere sekundære servere for at blive gendannet. I modsætning til spejling kan den eller de sekundære databaser være kvalificerede til skrivebeskyttet aktivitet, og logforsendelsesfrekvensen kan konfigureres til forskellige intervaller. Der er en ydeevnefordel i scenarier, hvor sekundære databaser ikke nødvendigvis behøver at være synkroniseret med den primære database i realtid.
For eksempel at køre en statistisk oversigtsrapport sidst på natten for at se, hvilke psykologibøger der sælges i løbet af dagen, kræver det ikke, at kopidatabasen er nøjagtigt synkroniseret med den primære database. Læse-intensiv aktivitet placerer låse på databaseobjekter og kan øge ventetider. Derfor vil kørsel af rapportering på en sekundær server aflaste arbejdsbelastningen på den primære indtægtsgenererende server.
Ulempen er, at logforsendelse ikke understøtter automatisk failover. Derfor, hvis kildeserveren fejler, skal databasen gendannes manuelt. Ligesom spejling giver logforsendelse ikke serverredundans og er en løsning på databaseniveau.
Forstå AlwaysOn
Gamle teknologier har hver deres fordele og afvejninger. Men implementering af en tilpasset HADR-løsning kan hurtigt blive kompliceret og kræve mere styring, da disse forskellige strategier blandes vilkårligt og matches sammen for at imødekomme forretningsbehov. Derfor blev AlwaysOn-funktionerne introduceret og giver en forbedret, allerede kombineret version af tidligere strategier.
SQL Server tilbyder to funktioner:AlwaysOn Availability Groups (AG) og AlwaysOn Failover Cluster Instances (FCI). Begge kræver Windows Server Failover Clustering (WSFC) for at blive implementeret.
En AG er en gruppe af databaser, der vil failover sammen. Du skal bruge flere redundante fysiske noder med en SQL Server-instans installeret på hver af noderne for at være vært for tilgængelighedsreplikaerne. Hver replika skal være på en anden node af den samme WSFC. I skemaet ovenfor er den primære replika hostet på Node 01, og alle de andre sekundære replikaer er kvalificerede til failover, når WSFC registrerer, at der er et problem.
Måden de sekundære replikaer forbliver synkroniserede med de primære er ved at sende transaktionslogfiler og gentage ændringerne. AG understøtter både asynkron og synkron commit-tilstand. Den primære replika er kvalificeret til læsning og skrivning, hvorimod de sekundære replikaer er kvalificeret til læsning. Sikkerhedskopier kan udføres på den sekundære placering.
Umiddelbart er der fordele med AlwaysOn AG. Husk fra tidligere, at nogle af fejlene ved databasespejling er, at en database kun kan spejles til én sekundær server, og at hver database spejles uafhængigt, når der opstår failover. Med AG bliver databaser gjort overflødige mange steder, såsom Node 02, Node 03, Node 04 og Node 05 i eksemplet ovenfor. Understøttelse af databasetilgængelighed tillader op til ni tilgængelighedsreplikaer.
Desuden ville logforsendelse være nødvendig for at opnå skrivebeskyttede data på den sekundære server. Men med AG er der allerede taget højde for skrivebeskyttede data. Læse-intensive aktiviteter såsom rapportering kan udføres på enhver af de sekundære replikaer. Bemærk også, at der ikke er en delt lagerbegrænsning.
AG kan dog kombineres med AlwaysOn FCI for at tillade serverredundans. En FCI-instans kan bruges til at være vært for tilgængelighedsreplikaerne, så objekter på serverniveau, såsom logins og agentjob, også kan beskyttes. Denne tilgang vil kræve delt opbevaring. Ulejligheder, såsom at skulle udføre omkonfigurationer for klientapps, vil dog blive elimineret.