Allen,

Wat bepaalt je keuze voor een specifieke cluster topology behalve dan kosten besparing?
Is efficiency iets anders dan kosten besparing?

Waar gaat voor de meeste van jullie de voorkeur naar uit en waarom?

Single-Instance (oud Active/passive)

Multi-Instance (N+1 / N+m)

Waar moet rekening mee gehouden worden bij je keuze?

Een persoonlijke voorkeur van mij en graag hoor ik of dit terecht is:

SQL 2008 Single-Instance clusters, waarom:

- Ten opzichte van SQL2000 / 2005 is de installatie veranderd. Voorbeeld: ik wil 6 instances hosten. In een N+1 (4node) moet ik dan 24 installaties uitvoeren. Maar ook als ik updates krijg moet ik 24 updates uitvoeren. Een single instance cluster moet ik 6 clusters inrichten (12 nodes) voor installatie en updates zijn dit 12 installaties.

- Bij een single instance hoef ik geen verdere rekening te houden met Dynamic Memory mapping

- Bij een single instance hoef ik geen verdere rekeing te houden met CPU verdeling voor mijn instance

- Single instance is eenvoudiger in beheer / onderhoud

- Single instance geeft een meer gescheiden omgeving waardoor een betere afstemming te bereiken is met mijn eind gebruikers in het kader vaN SP installaties ed.

- Tegen single instance, minder failover mogelijkheden

- Meer omgevingen?

Je hebt gelijk. Hier dan wat meer functionele danwel technische aspecten.

Je geeft aan dat je bij een single instance geen rekening hoeft te houden met memory mapping. Maar in hoeverre is dit niet waar voor een multiinstance cluster. Als je meer nodes hebt dan instances en iedere node, onder normale omstandigheden, een eigen instance heeft, in hoeverre moet je je dan druk maken om memory mapping. Ditzelfde gaat op voor de CPU.

Eigenlijk moet je kijken naar waarom je een cluster wilt. Wat hoop je met het cluster te bereiken en wat heb je daarvoor nodig. Wil je een calamiteit kunnen opvangen en wil je daarna weer terug naar de oorspronkelijke situatie. Dan zou een passieve node per instance misschien overdreven zijn. Als je weet dat 95% van de tijd iedere instance op een eigen node zal draaien en er 5% van de tijd een mogelijkheid bestaat dat enkele instances wellicht op dezelfde node staan, staat dat dan in verhouding tot de hardware investering.

Instances zijn juist bedoeld als mogelijkheid om scheiding aan te brengen tussen SQL installaties. Je kan SP updates uitvoeren zonder andere instances hierbij te raken. Door iedere omgeving te isoleren in zijn eigen cluster doe je afbreuk aan de functionaliteit van een instance. Je zal mogelijk wel last hebben van reboots maar je kan natuurlijk meerdere SQL en servicepack versies op één server hebben draaien. Het enige dat clustering toevoegt is een stukje hardware redudancy.

Een groot gedeelte hangt ook af van het budget. 6 single instance clusters of een 8-node multi instance cluster met 6 instances maakt een verschil in aantal servers, warmte produktie, stroom verbruik etc. Ook in het geval van het beheer moet je in het ene geval 12 servers beheren, ieder koppel met een eigen cluster configuratie en ook 12x een OS updaten/patchen. In het andere geval zijn dat al 4 servers minder en is het één cluster dat je moet beheren, ipv 6.

Het beheer van SQL zal niet veel verschillen. In beide gevallen heb je 6 instances. Voor SQL zal het daarom weinig uitmaken. Je zal echt moeten afwegen of het wel nodig is om zoveel passieve servers in te zetten voor mogelijke downtime. In de praktijk zien wij dat de servers alleen maar downtime hebben bij het patchen. Dit gebeurt gecontroleerd dus dan kun je de passieve node upgraden, een instance verplaatsen naar die node dan die node upgraden en dan de volgende instance verplaatsen naar die node etc. etc. Dan blijf je altijd een passieve node houden, hij verschilt echter steeds.

Hou er ook rekening mee dat er een licentie voorwaarde is die voorschrijft dat je niet hoeft te betalen voor de passieve node zolang deze maar passief is bij een processor licentie. Technisch gesproken moet je altijd een fail-back doen binnen een bepaalde tijd.