Constant zijn wij bezig met het up-to-date houden van het Online Werkplek platform. Denk hierbij aan het updaten van Windows, applicaties en vervangen van verouderde hardware. Nu was één van onze Microsoft SQL servers ook aan de beurt. We wilden graag van diverse losse SQL Servers naar een Microsoft SQL Server Cluster. Op die manier kunnen we de redundantie bieden zoals bij de rest van onze omgeving ook het geval is. Hierdoor kunnen bedrijfskritische applicaties, zoals bijvoorbeeld IBM Cognos BI, altijd door blijven draaien!
Licentie model
Voor het hoog beschikbaar maken van SQL servers zijn er meerdere mogelijk heden, welke ook anders werken en waar ook andere kosten aan verbonden zitten.
Always On Availability Groups
Always On Availability Groups zijn groepen waarin databases één of meerdere replica’s kunnen hebben welke op verschillende SQL servers staan. Het repliceren kan synchroon of asynchroon waardoor deze optie erg geschikt zou zijn voor disaster recovery. Always On Availability groups maken geen gebruik van shared storage, omdat elke server met een replica de data van de SQL Database lokaal opslaat. Om gebruik te maken van deze functionaliteit is een SQL Server Enterprise licentie nodig, wat natuurlijk extra kosten met zich mee brengt.
Failover Clustering Active/Passive
In de licentie van SQL Server Standard zit het recht om gebruik te maken van een failover cluster. Dit failover cluster moet zo zijn geconfigureerd dat één machine active moet zijn en de andere passive. Op die manier kan met de Standard licentie toch een hoge beschikbaarheid gerealiseerd worden. Zo’n SQL Server Cluster werkt verder precies hetzelfde als een ander Windows Failover Cluster. De databases staan op shared storage en bij een failover wordt alleen de database functionaliteit actief op de andere node.
Licentie technisch is dit daarom de meest voordelige optie, als de extra features van Always On Availability Groups niet nodig zijn.
Inrichting SQL Server Cluster
Vanwege kosten en de gewenste functionaliteit hebben we gekozen voor een SQL Cluster op basis van Failover Clustering. Bij de inrichting hadden we nog een extra uitdaging, omdat ons Online Werkplek platform een multi-tenant omgeving is, waarbij duidelijke scheiding per klant geregeld is. Het is voor een klant onmogelijk om bij de gegevens een andere klant van ons terecht te komen.
Iedere klant heeft in onze omgeving een eigen SQL Instance, waarbij voor iedere instance eigen volumes gemaakt waren. Verder is er ook per klant vaak nog een scheiding tussen productie en test databases. Nu is de limiet van 24 driveletters gewoon nog aanwezig in Windows, waardoor we moesten kijken naar alternatieven om verder te kunnen opschalen.
Mountpoints i.p.v. driveletters
Op de SQL Server die uitgefaseerd moest worden waren nog maar 2 vrije driveletters over waardoor we geen nieuwe SQL Server instances meer konden aanmaken. In de nieuwe omgeving hebben we daarom gekozen om gebruik te maken van volume mount points. Op die manier kunnen we het SQL Server Cluster verder uitbreiden mits onze hardware dit toestaat en de performance van de huidige SQL instances niet aangetast wordt.
Elke SQL instance heeft nu toegang tot één eigen drive letter met daarin een aantal volumes gekoppeld. In theorie zouden we hierdoor 24 SQL instances kunnen draaien per SQL Server Cluster. Dit was met de oude configuratie niet mogelijk. Dit ziet er nu als volgt uit:
In deze driveletter zijn vervolgens drie volumes gekoppeld.
Hierdoor gebruiken we per instance dus maar één driveletter in plaats van drie en kunnen we gewoon nog uitbreiden. Dit is ook een door Microsoft ondersteunde configuratie.