Always On bij SQL Server is een ingebouwde technologie voor hoge beschikbaarheid en disaster recovery waarmee één of meerdere databases automatisch worden gerepliceerd naar een of meer secundaire servers. Bij een storing of gepland onderhoud schakelt SQL Server automatisch over naar een secundaire replica, zodat applicaties beschikbaar blijven. In dit artikel worden de meest gestelde vragen over Always On Availability Groups beantwoord, van de werking in de praktijk tot de keuze tussen on-premises en Azure.
Hoe werkt Always On in de praktijk?
Always On werkt door een Availability Group te configureren: een logische groep van databases die samen worden gerepliceerd van een primaire replica naar een of meer secundaire replica’s. De primaire replica verwerkt alle schrijfbewerkingen en stuurt transactielogboekgegevens door naar de secundaire replica’s. Bij een failover neemt een secundaire replica de rol van primaire over, idealiter zonder dataverlies.
In de praktijk zijn er een aantal componenten die samenwerken:
- Windows Server Failover Cluster (WSFC): Always On maakt gebruik van een onderliggend clusteringmechanisme om de gezondheid van de nodes te bewaken en failovers te coördineren.
- Availability Group Listener: Een virtueel netwerkeindpunt waarmee applicaties altijd verbinding maken, ongeacht welke node momenteel de primaire is. Applicaties merken een failover hierdoor nauwelijks.
- Leesbare secundaire replica’s: Secundaire replica’s kunnen worden geconfigureerd voor leesverkeer, zodat rapportage en zware query’s de primaire server niet belasten.
De transactielogboeken worden continu doorgestuurd en toegepast op de secundaire replica’s. Dit maakt Always On wezenlijk anders dan een periodieke back-upstrategie: de secundaire server is op elk moment klaar om het werk over te nemen.
Wat is het verschil tussen synchrone en asynchrone replicatie?
Bij synchrone replicatie bevestigt de primaire replica een transactie pas nadat de secundaire replica de wijziging ook heeft vastgelegd. Bij asynchrone replicatie bevestigt de primaire de transactie direct, zonder te wachten op de secundaire. Het kernverschil zit in de afweging tussen dataverlies en prestaties.
Synchrone replicatie
Synchrone modus garandeert nul dataverlies bij een failover, omdat beide replica’s altijd identiek zijn op het moment van overschakelen. Dit is de juiste keuze voor kritische productieomgevingen waarbij elk verloren record onaanvaardbaar is. Het nadeel is dat latentie op de netwerkverbinding tussen de nodes direct de schrijfprestaties van de primaire server beïnvloedt. Synchrone replicatie werkt daarom het best binnen hetzelfde datacenter of op een verbinding met lage latentie.
Asynchrone replicatie
Asynchrone modus heeft vrijwel geen invloed op de schrijfprestaties van de primaire server, maar accepteert een zekere hoeveelheid potentieel dataverlies bij een onverwachte storing. Dit maakt het geschikt voor geografisch verspreide omgevingen, zoals een secundaire replica in een ander datacenter voor disaster recovery. In de praktijk combineren organisaties beide modi: een synchrone replica lokaal voor hoge beschikbaarheid en een asynchrone replica op afstand voor herstel na een calamiteit.
Wat is het verschil tussen Always On en database mirroring?
Database mirroring is een verouderde technologie die werkt op het niveau van één individuele database, terwijl Always On Availability Groups meerdere databases als één eenheid beheren en aanzienlijk meer flexibiliteit bieden. Microsoft heeft database mirroring officieel als deprecated aangemerkt en raadt het gebruik ervan sterk af.
De belangrijkste verschillen op een rij:
- Schaal: Mirroring ondersteunt slechts één secundaire server per database. Always On ondersteunt tot acht secundaire replica’s per groep.
- Leesbare secundaire replica’s: Bij mirroring is de mirror-database volledig ontoegankelijk voor leesverkeer. Bij Always On kunnen secundaire replica’s worden opengesteld voor rapportage en back-ups.
- Groepsbeheer: Mirroring werkt per database afzonderlijk. Always On behandelt een groep databases als één geheel, zodat een failover alle databases tegelijk overschakelt.
- Clusterintegratie: Always On is diep geïntegreerd met Windows Server Failover Clustering, wat automatische detectie van storingen en gecoördineerde failovers mogelijk maakt.
Voor elke omgeving die nog database mirroring gebruikt, is migratie naar Always On de logische volgende stap om toekomstbestendig te blijven.
Wanneer is Always On de juiste keuze voor jouw omgeving?
Always On bij SQL Server is de juiste keuze wanneer downtime directe bedrijfsschade oplevert, wanneer dataverlies onaanvaardbaar is, of wanneer de organisatie wettelijke verplichtingen heeft rondom beschikbaarheid en hersteltijden. Voor omgevingen met lage kritikaliteit en een beperkt budget kan een eenvoudigere back-upstrategie volstaan.
Concrete situaties waarin Always On de voorkeur verdient:
- Productieomgevingen die 24/7 bereikbaar moeten zijn, zoals webshops, ERP-systemen of klantportalen
- Organisaties die een Recovery Time Objective (RTO) van minuten in plaats van uren nastreven
- Omgevingen waar geplande onderhoudswerkzaamheden zonder zichtbare downtime moeten plaatsvinden
- Situaties waarbij leesintensieve rapportage de primaire productieserver belast en ontlast moet worden
- Bedrijven die aan geografische spreiding doen voor disaster recovery
Organisaties die hun data-architectuur professioneel willen inrichten, overwegen Always On vrijwel altijd als onderdeel van een bredere beschikbaarheidsstrategie.
Wat zijn de meest voorkomende problemen met Always On?
De meest voorkomende problemen met Always On zijn synchronisatievertragingen tussen replica’s, misconfiguratie van de Listener, en clusteringproblemen die leiden tot onverwachte failovers. Veel van deze problemen ontstaan niet door de technologie zelf, maar door een gebrekkige initiële configuratie of onvoldoende netwerkvoorbereiding.
Veelvoorkomende knelpunten in de praktijk:
- Hoge synchronisatievertraging (lag): Wanneer de secundaire replica de primaire niet bijhoudt, groeit de hersteltijd bij een failover. Dit wijst vaak op onvoldoende netwerkbandbreedte of een te hoge schrijflast op de primaire server.
- Quorum-verlies in het cluster: Bij een onjuiste quorumconfiguratie kan het cluster besluiten geen failover uit te voeren, terwijl de primaire server wel degelijk onbereikbaar is.
- Listener-problemen: Applicaties die de Listener omzeilen en rechtstreeks verbinding maken met een servernaam, verliezen de verbinding bij een failover. Dit is een configuratiefout aan de applicatiekant.
- Verweesde back-upjobs: Na een failover draaien back-upjobs mogelijk nog steeds op de oude primaire, die nu een secundaire is. Back-upscripts moeten rolbewust zijn.
- Certificaat- en machtigingsproblemen: Onjuiste servicecertificaten of ontbrekende machtigingen op de endpoint-poorten blokkeren replicatie zonder duidelijke foutmelding.
Hoe verschilt Always On in Azure SQL van on-premises SQL Server?
In Azure SQL is hoge beschikbaarheid ingebouwd en volledig beheerd door Microsoft, waardoor je Always On Availability Groups niet zelf hoeft te configureren. Bij on-premises SQL Server ben je zelf verantwoordelijk voor het opzetten en onderhouden van het cluster, de replica’s en de netwerkconfiguratie. Het principe is vergelijkbaar, maar de operationele verantwoordelijkheid verschilt fundamenteel.
Concrete verschillen:
- Beheer: Azure SQL Database en Azure SQL Managed Instance bieden ingebouwde redundantie via automatisch beheerde replica’s. On-premises vereist handmatige configuratie van WSFC, replica’s en Listeners.
- Zichtbaarheid: In Azure is de onderliggende infrastructuur van de hoge beschikbaarheid grotendeels onzichtbaar. On-premises heb je volledige controle en inzicht in elke laag van de configuratie.
- Geo-redundantie: Azure biedt ingebouwde geo-replicatie via Active Geo-Replication of Failover Groups. On-premises vereist een apart datacenter en handmatige asynchrone replicatieconfiguratie.
- Kosten: On-premises vereist een investering in extra hardware voor elke replica. In Azure betaal je voor de servicetier die de gewenste beschikbaarheidsklasse biedt.
Voor organisaties die overwegen te migreren van on-premises SQL Server naar Azure, is het belangrijk te begrijpen dat de vertrouwde Always On-concepten in Azure worden vervangen door platformbeheerde equivalenten. De onderliggende logica van primaire en secundaire replica’s blijft herkenbaar, maar de configuratielaag verdwijnt grotendeels.
Hoe helpt Brander Company bij SQL Server hoge beschikbaarheid
Wij helpen organisaties bij het ontwerpen, implementeren en beheren van robuuste Always On-omgevingen die aansluiten op de specifieke eisen van hun bedrijf. Of het nu gaat om een eerste opzet, een migratie van database mirroring, of het oplossen van bestaande synchronisatieproblemen: we nemen verantwoordelijkheid voor het gehele traject.
Wat we concreet bieden:
- Analyse van de huidige databaseomgeving en beschikbaarheidsvereisten
- Ontwerp en implementatie van Always On Availability Groups, inclusief clusteringconfiguratie en Listener-inrichting
- Keuze en configuratie van synchrone en asynchrone replicatie op basis van jouw RTO- en RPO-doelstellingen
- Migratie van verouderde oplossingen zoals database mirroring naar Always On
- Monitoring, proactief beheer en periodieke failovertests om de configuratie betrouwbaar te houden
Wil je weten welke Always On-configuratie past bij jouw omgeving? Neem contact op en we denken graag met je mee.
Frequently Asked Questions
Hoeveel secundaire replica's heb ik minimaal nodig voor een betrouwbare Always On-omgeving?
Voor een basisopzet met hoge beschikbaarheid volstaat één synchrone secundaire replica binnen hetzelfde datacenter. Voor een robuustere strategie die ook disaster recovery dekt, is een combinatie van één synchrone lokale replica en één asynchrone replica op een andere locatie de meest gangbare aanpak. Houd er rekening mee dat elke extra replica ook extra licentie- en hardwarekosten met zich meebrengt.
Wat zijn de RTO en RPO die ik realistisch kan verwachten met Always On?
Met een correct geconfigureerde synchrone Always On-omgeving is een Recovery Point Objective (RPO) van nul haalbaar, wat betekent dat er geen dataverlies optreedt bij een failover. De Recovery Time Objective (RTO) ligt bij een automatische failover doorgaans tussen de 20 en 60 seconden, afhankelijk van de clusterdetectietijd en de applicatieherverbindingslogica. Bij asynchrone replicatie naar een DR-locatie is de RPO afhankelijk van de hoeveelheid niet-gesynchroniseerde transacties op het moment van de storing.
Welke SQL Server-editie heb ik nodig om Always On te gebruiken?
Always On Availability Groups zijn beschikbaar vanaf SQL Server 2012 en vereisen minimaal de Standard Edition, maar met beperkingen: de Standard Edition ondersteunt slechts twee replica’s en een beperkte subset van functies. Voor de volledige functionaliteit, waaronder tot acht secundaire replica’s en leesbare secundaire replica’s, is de Enterprise Edition vereist. Controleer altijd de Microsoft-licentiedocumentatie voor jouw specifieke SQL Server-versie, omdat de licentieregels per versie kunnen verschillen.
Hoe test ik of mijn Always On-configuratie daadwerkelijk werkt zonder productierisico?
De veiligste manier is het uitvoeren van een geplande handmatige failover in een onderhoudsvenster, waarbij je de primaire rol bewust overdraagt aan een secundaire replica en vervolgens terugschakelt. Controleer hierbij of applicaties automatisch herverbinden via de Listener, of back-upjobs correct overschakelen naar de nieuwe primaire, en of er geen dataverlies is opgetreden. Plan dit soort failovertests minimaal twee keer per jaar in als vast onderdeel van je beschikbaarheidsstrategie, zodat je zeker weet dat de configuratie bij een echte storing ook daadwerkelijk functioneert.
Kan ik Always On gebruiken in combinatie met mijn bestaande back-upstrategie?
Ja, maar back-upscripts moeten rolbewust worden gemaakt zodat ze altijd draaien op de juiste replica. Volledige back-ups worden typisch uitgevoerd op de primaire replica, terwijl logback-ups en differentiële back-ups ook op een leesbare secundaire replica kunnen worden uitgevoerd om de primaire te ontlasten. SQL Server Agent-jobs die back-ups uitvoeren, moeten na elke failover opnieuw worden geëvalueerd, of je gebruikt een script dat de huidige primaire replica automatisch detecteert voordat de back-up wordt gestart.
Wat moet ik regelen aan de applicatiekant om optimaal gebruik te maken van Always On?
De belangrijkste aanpassing aan de applicatiekant is dat alle verbindingsstrings uitsluitend de Availability Group Listener als hostnaam gebruiken, nooit de directe servernaam. Voeg daarnaast de parameter MultiSubnetFailover=True toe aan de verbindingsstring om snellere herverbinding bij een failover te garanderen. Voor applicaties die leesintensieve queries uitvoeren, kun je een aparte verbindingsstring configureren met ApplicationIntent=ReadOnly, zodat die queries automatisch worden doorgestuurd naar een secundaire replica.
Is Always On ook geschikt voor kleinere organisaties, of is het alleen weggelegd voor grote ondernemingen?
Always On is technisch gezien schaalbaar voor organisaties van elke omvang, maar de afweging zit in de kosten en de beheerscapaciteit. Een kleine organisatie met één kritische productiedatabase kan al baat hebben bij een eenvoudige twee-node Always On-configuratie, mits de hardware en SQL Server Enterprise-licenties budgettair haalbaar zijn. Voor kleinere omgevingen waarbij de kosten van een volledige Always On-opzet niet opwegen tegen het risico, kan een combinatie van SQL Server Standard met een beperkte AG-configuratie of een goed ingerichte back-up- en herstelstrategie een realistischer alternatief zijn.
Related Articles
- Hoe werkt een failover-omgeving in de praktijk?
- Wat is het verband tussen data analyse tools en datavisualisatie?
- Wat is Power BI en hoe past het binnen business intelligence?
- Welke taken heeft een database administrator?
- Hoeveel soorten SQL zijn er in een DBMS?
This content was generated with the help of AI — it may contain mistakes
