Microsoft heeft met SQL Server 2012 een flink aantal concurrerende wijzigingen en vernieuwingen doorgevoerd. Alles is hierbij gericht op het ondersteunen van grote Enterprise omgevingen. Zo is er op het business Intelligence vlak is er veel nieuws, net als bij disaster recovery waar deze blog over gaat.

Microsoft heeft met SQL Server 2012 een flink aantal concurrerende wijzigingen en vernieuwingen doorgevoerd. Alles is hierbij gericht op het ondersteunen van grote Enterprise omgevingen. Zo is er op het business Intelligence vlak is er veel nieuws, net als bij disaster recovery waar deze blog over gaat.
Wat kan er allemaal stuk?
Er kan van alles misgaan met je database. Gelukkig komt het niet vaak voor, maar toch.. Laten we vooral kijken naar de hardware. Voor fouten in de data zelf hebben we namelijk de database back-ups en vaak komt zoiets door een fout in de software of door een menselijke fout. Dit kan zelfs SQL Server niet verhelpen.
Allereerst kan je dataopslag-medium (de disk) stuk gaan. We zullen de data dus ergens dubbel moeten opslaan op een tweede disk. Ook kan je server uit de lucht zijn, om wat voor reden dan ook, dus daar zullen we ook een back-up voor moeten regelen. En eventueel zou je gehele datacentrum eruit kunnen liggen. Ook hier zijn verschillende mogelijkheden voor te bedenken, van een stroomstoring tot een overstroming. Dus eigenlijk (als we het echt goed willen aanpakken en het nodig is natuurlijk) moeten we ook over verschillende locaties beschikken met verschillende servers en actuele kopieën van de data! Als dat nog niet voldoende blijkt te zijn, dan hebben we waarschijnlijk belangrijkere zaken aan ons hoofd dan onze data. Het is per slot van rekening 2012, dus de kans zit er (volgens de Mayaís) wel dik in natuurlijk .
SQL Server 2012
Je redding (toch?)
SQL Server beschikt natuurlijk al over een aantal mogelijkheden om te anticiperen op dergelijke situaties. Daar zitten wel enkele minpunten aan.
  • Logshipping. Feitelijk maak je om de x tijd een transactionlog back-up die met een job naar een andere server gekopieerd wordt en daar gerestored wordt. Goedkoop en simpel, maar als er iets mis gaat dan ben je wel alle data kwijt vanaf het moment van de laatste back-up tot het moment dat het fout ging. Tevens is het handwerk om de back-up server in een bruikbare staat te krijgen. Als deze server in de lucht is, dan moeten alle applicaties nog weten dat ze naar de nieuwe server moeten gaan voor hun data. Die SLA kun je dus wel op je buik schrijven.
  • Mirroring. Bij mirroring worden alle transacties op de primaire server ook direct doorgevoerd op de secondaire server. Hierdoor heb je, afhankelijk van je instelling, geen of bijna geen kans op dataverlies. Maar ook hier zit je met het probleem dat de applicaties naar een andere server moeten gaan voor de data en dat gaat meestal niet automatisch. Een ander nadeel is dat je een tweede server hebt staan, met actuele data maar dit is weggegooide energie. Je kunt de server namelijk niet gebruiken zolang de primaire server gewoon werkt. Eigenlijk zou je deze server dus willen gebruiken om bijvoorbeeld rapporten op de draaien.
  • SQL Clustering. Bij deze oplossing installeer je een SQL cluster op een Windows cluster. Er is dan een dure shared-storage oplossing nodig waarop centraal de data wordt opgeslagen. De nodes in het SQL cluster gebruiken beide deze data, maar mocht er een server uitvallen, dan neemt de andere automatisch de taak over. En omdat het Windows cluster een virtuele naam heeft kunnen de applicaties nog steeds bij deze virtuele server terecht voor hun data. Het is een prima oplossing voor een server die eruit ligt, maar wel erg prijzig. Daarbij is de data maar op 1 locatie opgeslagen (waarschijnlijk in de storage wel dubbel opgeslagen, maar toch).
De oplossing in SQL 2012: Availability groups
Tot zover alle problemen, nu is het tijd voor de SQL 2012 oplossing: “Always on Availability groups”. Bij het bepalen van Failover wordt er voortaan gebruik gemaakt van Windows Server Failover clustering (WSFC). In SQL server kun je aangeven welke servers er meedoen in de Availability group en het WSFC controleert de werking van het systeem en bepaalt wanneer er een failover plaats moet vinden. Dat gebeurt dan op server (instance) niveau en dus niet langer op database niveau.
Daarnaast is het mogelijk om meer dan 2 server mee te laten doen. Zo kun je tot 4 servers aan elkaar gelijk laten lopen. Deze servers kunnen als “read-only” worden ingesteld zodat je ze kunt gebruiken om de data uit te lezen. Op deze manier zijn de servers dus ook nog productief! Applicaties kunnen de virtuele-servercluster naam gebruiken om naartoe te connecten. Dus als er een failover plaatsvindt, dan hoeft er aan de applicaties niets te worden aangepast. Het blijft echter wel mogelijk om naar een specifieke server te connecten zodat je bijvoorbeeld op een readonly-server je rapporten kunt laten generen.
Het is ook mogelijk gemaakt om servers buiten je eigen subnet toe te voegen, bijvoorbeeld op een andere locatie. Voorheen was dit niet, of nauwelijks haalbaar.
Net als bij mirroring kun je aangeven of je er zeker van wilt zijn dat er geen enkele data verdwenen mag zijn, of dat je toch meer de voorkeur geeft aan de performance. In het eerste geval moet de transactie eerst worden weggeschreven naar een secundaire server alvorens deze doorgevoerd mag worden op de primaire server. Zeker met servers op andere locaties kan dit nogal vertragend werken. Daarom kun je per server instellen of deze synchroon of asynchroon werkt.
Hieronder zie je een schematische weergaven van een dergelijke oplossing. 2 servers op de hoofdlocatie die synchroon werken en een extra server op een andere locatie die asynchroon zou kunnen worden ingericht. En dit geheel vormt dan je Availabititygroup.
SQL Server 2012
Overigens moet ik zeggen dat ook de tooling goed in orde is. De wizards om het geheel te configureren zijn overzichtelijk en geven duidelijke feedback. Daarnaast is er een dashboard waarin je precies ziet hoe het staat met je availability group en waarin je eventueel failover kunt testen.
Conclusie
Goedkoper dan SQL Server clustering en veel betere mogelijkheden voor automatische failover. Neem daarbij de voordelen van bruikbare secudaire servers en het geheel klinkt als een winnaar! Het is nog wel even afwachten hoe het precies gaat met bijvoorbeeld de licenties. Voor niets gaat de zon op en bruikbare servers betekent namelijk waarschijnlijk ook “betalen”. Zie voor meer informatie http://msdn.microsoft.com/en-us/library/ms190202(v=sql.110).aspx Uiteraard zal ik jullie ook via dit blog op de hoogte houden van de mogelijkheden en ontwikkelingen omtrent SQL Server 2012.