[MS Sql 2008] opbouwen van een HA cluster

[Anoniem: 342596]

De laatste tijd krijg ik als beheerder steeds meer klachten dat één van onze sql servers (ms sql 2008) tegen zijn limiet aan zit.
Nou is hardware niet het probleem, het is een redelijk nieuwe server. De volgende stap wordt dan een cluster bouwen. Momenteel draait de server in een windows failover cluster zodat bij uitval na 20 seconden een tweede server up is, en de taken overneemt. Het voordeel hiervan is dat applicaties maar naar 1 ip adres hoeven te koppelen.

Nou ben ik op zoek naar een methode om een sql cluster te bouwen van deze omgeving. Op zich niet zo 'n probleem zij het niet dat een van de applicaties maar naar 1 ip adres kan connecten (maakt geen gebruik van de microsoft connectors )

Weet iemand wat de beste methode kan zijn om de preformance te vergroten, en tegelijk een HA opstelling te bouwen? als ik de downtime die er nu is bij een failover nog verder kan verklijnen dan is dat altijd meegenomen

Ik weet dat MS sql server 2008 ook in hele grote omgevingen wordt gebruikt. Hoe zijn deze clusters opgezet kwa architectuur? ik kan hier weinig concreets over vinden

[downtime]

Nou zijn databases niet echt mijn vak, al heb ik er wel regelmatig mee te maken, maar ik zou eerst eens naar de bestaande spullen gaan kijken. Waarom zit die server aan zijn limiet? In veel gevallen heeft dat namelijk meer met slechte optimalisatie v.d. database (geen goede indexen, dat soort zaken) te maken dan met hardware. Een beetje moderne server zit namelijk niet zomaar aan z'n limiet.

[jvanhambelgium]

Er is zoveeel over te vinden ; begin hier alvast http://www.microsoft.com/...us/high-availability.aspx

Nu is de klacht "de sql server zit tegen z'n limiet" niet bepaald de meest objectieve.
Welke metingen en analyses heb je al gedaan om te besluiten dat er niet meer uit te halen valt...

Om de performance te vergroten kan je natuurlijk meer hardware ertegenaan gooien ; memory, cpu en i/o
Of je kan beginnnen uitpluizen wat er in de db's kan gedaan worden om de performance te verbeteren, maar dit vergt nauwe samenwerking met app-ontwikkelaars natuurlijk. Een luizige,inefficiente query schrijven kan iedereen wel, tot in het extreme optimaliseren van deze dingen is een ander paar mouwen...

Als je met clustering begint is het allemaal een stukje ingewikkelder...

[Anoniem: 342596]

Ik geef eerlijk toe dat applicatie perfect is maar aanpassen is niet te doen. Het is helaas geen zelfbouw-software en de fabriekant wil niet echt meewerken.

Ik heb niet het gevoel dat de query's heel in-efficient zijn, maar dat het volume gewoon te groot begint te worden.
We beschikken nu over een zware SAN en dat scheelt heel veel. nu de sql server laag nog "opwaarderen"

Microsoft heeft de volgende oplossingen:

* Database Mirroring (helaas kan de applicatie maar met1 ip adres connecten, dus dat wordt lastig)
* Log Shipping (hiermee kunnen we read acties lostrekken van de write acties, hier gaan we naar kijken)
* Failover Clustering (hebben we nu draaien, maar geeft 1 actieve en 1 pasieve server, nog geen preformance winst, wel een HA oplossing hoewel de "schakeltijd" eigenlijk nog te hoog is)
* Peer-to-Peer Replication (hier moet ik nog naar gaan kijken, maar ik ben bang dat het 1 ip adres probleem weer gaat spelen).

Momenteel zit ik te denken aan een opstelling van 2 failover clusters die in een database mirror draaien maar of dat de beste manier is weet ik niet zeker.

[SpamLame]

Maar als nu 1 cluster uitvalt kan je een ip app nog niks aanvangen.

Bij webframs zie je regelmatig een loadbalancer ervoor zitten, wellicht dat dit ook mogelijk is voor databases?

[Ethirty]

Misschien dat je hier nog wat uit kan halen?
http://www.microsoft.com/...us/performance-scale.aspx

Voor zover mijn kennis van databases gaat zet je eerder een beest van een machine neer dan een 'performance' cluster. Zeker als je een vendor heb die niet meewerkt kan je alleen maar 'opschalen' en niet 'uitschalen' (slecht vertaald, ik weet zo even niet hoe je scale out goed vertaald)

Als de hardware écht snel genoeg is kan je wellicht iets met "Optimize hardware usage by supporting multiple Database Engine instances and Analysis Services instances on a single server"

Maar je zegt niks over de huidige server. Alleen dat hij recent is. Single socket met 4GB of een quad-socket 6-core met 96GB intern maakt voor een zware DB nogal wat uit. Zijn de database en de logs op aparte fysieke disksets ondergebracht en kan elk van die disksets de IO halen die gevraagd wordt? Logs wil je op R1 of R1+0, de database(s) op R5.

De performance problemen die ik tot nu toe getackeled heb met SQL waren zonder uitzondering eigenlijk altijd de disks het probleem (hoewel veel kleinschaliger als jij beschrijft).

Ook nog wel een interessante link: Top SQL Server 2005 Performance Issues for OLTP Applications
Aan het design zelf kan je weinig doen, maar er worden genoeg handvatten aangereikt voor een goede bepaling waar nu je bottleneck in zit. Meten is weten

[ Voor 14% gewijzigd door Ethirty op 29-01-2010 01:02 ]

[Gomez12]

Anoniem: 342596 schreef op donderdag 28 januari 2010 @ 23:11:
Ik geef eerlijk toe dat applicatie perfect is maar aanpassen is niet te doen. Het is helaas geen zelfbouw-software en de fabriekant wil niet echt meewerken.

Ik heb niet het gevoel dat de query's heel in-efficient zijn, maar dat het volume gewoon te groot begint te worden.
We beschikken nu over een zware SAN en dat scheelt heel veel. nu de sql server laag nog "opwaarderen"

Gevoelsmatig zou ik toch eerst bij je fabrikant / leverancier aankloppen.

Het volume is zelden te groot voor een dbase, het wordt nooit in zijn volledigheid aangesproken.
Ik kende redelijk wat TB omgevingen waar er slechts 512 MB daadwerkelijk gebruikt werd door de dbase zelf, de rest was allemaal aanhangende info die niet meetelde in de zoekquery's / koppelquery's etc. Maar enkel eenmalig aangesproken werd als de info op het scherm getoond werd...

Vergelijk het maar met een TB filesysteem waarop je een willekeurig bestand wil openen, dat maakt ook niet uit hoe vol die zit. Je hebt een File Allocation Table die daadwerkelijk snel moet zijn ( en die in het geval van een dbase iets uitgebreider is, maar veelal nog steeds klein qua grootte ) maar daarna merk je er niets meer van...

Momenteel zit ik te denken aan een opstelling van 2 failover clusters die in een database mirror draaien maar of dat de beste manier is weet ik niet zeker.

Zelf zou ik gewoon minimaal naar de fabrikant toestappen om dat ene ip-adres om te laten zetten naar een FQDN, dat biedt al meer speelruimte.

Nu zit je enkel te werken in de marge

[jvanhambelgium]

Beschrijf jullie netwerk eens ? Zijn het klachten van LAN gebruikers of zitten jullie ook met remote sites waarop deze applicatie moet werken ?

En .. wat zijn nu de specs van die server eigenlijk ? Is het een 2 CPU machines of een 8 CPU machine ?
4GB RAM of 64GB RAM ?

Is de db-server eerder een OLTP of meer een DSS systeem ? Beide soorten op 1 machine is sowieso geen goed idee....

[ Voor 46% gewijzigd door jvanhambelgium op 29-01-2010 07:28 ]

[Oogje]

Ethirty schreef op vrijdag 29 januari 2010 @ 00:25:
Misschien dat je hier nog wat uit kan halen?
http://www.microsoft.com/...us/performance-scale.aspx

Voor zover mijn kennis van databases gaat zet je eerder een beest van een machine neer dan een 'performance' cluster. Zeker als je een vendor heb die niet meewerkt kan je alleen maar 'opschalen' en niet 'uitschalen' (slecht vertaald, ik weet zo even niet hoe je scale out goed vertaald)

Als de hardware écht snel genoeg is kan je wellicht iets met "Optimize hardware usage by supporting multiple Database Engine instances and Analysis Services instances on a single server"

Maar je zegt niks over de huidige server. Alleen dat hij recent is. Single socket met 4GB of een quad-socket 6-core met 96GB intern maakt voor een zware DB nogal wat uit. Zijn de database en de logs op aparte fysieke disksets ondergebracht en kan elk van die disksets de IO halen die gevraagd wordt? Logs wil je op R1 of R1+0, de database(s) op R5.

De performance problemen die ik tot nu toe getackeled heb met SQL waren zonder uitzondering eigenlijk altijd de disks het probleem (hoewel veel kleinschaliger als jij beschrijft).

Ook nog wel een interessante link: Top SQL Server 2005 Performance Issues for OLTP Applications
Aan het design zelf kan je weinig doen, maar er worden genoeg handvatten aangereikt voor een goede bepaling waar nu je bottleneck in zit. Meten is weten

Ben het hier helemaal mee eens. Vooral icm het genoemde SAN zou ik eerst eens gaan kijken hoe het zit met de IO-performance. In de praktijk al eens gezien met een query dat het verschil tussen: "kwak maar ergens op het SAN" en "laten we eens goed kijken hoe we dat doen (eigen diskset/LUN oid...ben niet helemaal thuis in SANs)" betekende dat de query nog maar 5 minuten duurde ipv 45 minuten.

[pistole]

Doe ook eens wat performance counters? Queries per seconde, full scans, index searches, etc. Neem vooral ook de disk queue mee in je metingen.

Meer zware hardware is vaak maar een lapmiddel.

[Harrie666]

Een aantal dingen die van belang zijn. Hoe realtime zijn je verwerkingen en hoeveel write query's worden er gedaan per seconde / minuut.

Anders zou je database realtime kunnen repliceren naar een 2de of 3de en dan met een loadbalancer de query's verdelen tussen die 2 of 3. zeker als het veel read query's betreft is dit vaak een behoorlijke performance winst.

Als het alleen maar write query's zijn dan moet je wel opletten dat er geen corruptie gaat optreden als per ongeluk 2 write query's tegelijk gedaan worden op 2 berschillende DB servers.

Verder is het vaak dat meer schijven een oplossing is. Ook met een SAN,

Als dit ik jou situatie een optie is dan zou je 2 SQL servers kunnen Clusteren Active/Passive en dat 2 keer. Die 2 Clusters kun je dan load balancen. Als dan 1 machine down gaat neemt de passive node het over, tijdens die failover zal de loadbalancer alles naar de nog actieve cluster doorgooien tot de passieve node weer actief is en dan wordt er weer verdeeld. GEEN downtime alleen een vertraging.

Nogmaals het is uiteraard van belang op welke manier zaken worden weggeschreven en over de aantallen en kansen op corruptie / Dubbele ID's en overige zeer vervelende zaken en vooral de impact mocht dat gebeuren.

Voor dat laatste ben je waarschijnlijk toch wer afhankelijk van de maker van de applicatie.

[DamadmOO]

We kunnen wel een berg suggesties erin gooien maar laten we maar eens bij het begin beginnen. Hetgeen hiervoor nodig is zijn de volgende gegevens:

Server hardware
- CPU
- Disk
- Memory
Netwerk architectuur
- Segmentatie
- Aantal hops tussen client en server
Performance counters(Max, Min, Avg van minstens 15 minuten met 'performance problemen')
- % CPU
- Pages / Sec
- Page life expectancy
- Context Switches
- Batch Requests / Sec
- SQL Compilations / Sec
- SQL Re-Compilations / Sec

Verder natuurlijk ook de gedraaide service packs en welke opties er aanstaan in je SQL server.Dit geeft meestal een redelijk beeld van waar het probleem waarschijnlijk zit. Daarna kan je altijd nog data uit je DMV's gaan halen of Profiler gebruiken. Maar vooral de tweede geeft je alleen een slechtere performance als je geen idee hebt waar het probleem zich ergens afspeelt.

Verder zijn er een redelijk aantal manieren om een HA cluster op te zetten (en de meeste zijn hierboven al genoemd), maar de complexiteit van de meeste oplossingen en de kans op data corruptie in geval van het verkeerd opzetten zijn in een aantal gevallen gewoon te groot. En die zijn allebei altijd te groot als de kans dat het daadwerkelijke probleem opgelost wordt erg klein is.

[Anoniem: 342596]

bedankt voor alle reacties

Ik heb het probleem nog eens besproken met de collega's en een voorstel zoals Harrie666 geeft met 2 clusters en een loadbalancer lijkt me nu de beste oplossing.

Ik heb een tijdje terug een mysql cluster opgezet, en daarmee kan je met 2 servers en één monitor server een ha cluster bouwen (redelijk eenvoudig zelfs...). Dit is dan een active/active opstelling en voor zover ik heb kunnen testen is er bijna geen downtime bij het uitvallen van 1 server. ik dacht dat dit met microsoft sql zo ook zou moeten kunnen, maar het is blijbaar toch iets lastiger.

Komende week gaan de software ontwikkelaars een inventarisatie maken van read acties die we op een apparte server kunnen laten afhandelen, dat scheelt al weer iets

Daarnaast wil men dat ik eerst de uptime verhoog van de sql omgeving. Een failover van de failover cluster duurt maar een seconde of 20 maar dat vinden ze te lang (althans de software gaat over z'n nek. vraag me niet welke prutser die software heeft gemaakt maar helaas moet ik ermaar me leren leven...)

Komende week ga ik maar eens flink meten waar de problemen zitten, tenminste als ze me genoeg tijd gunnen de boodschap dat het niet "even een paar server erbij gooien" is, is aangekomen

[Oogje]

Maar....zit die server nou tegen z'n limiet?

[Anoniem: 349056]

Ooit al eens gekeken naar MS Network Load Balacing.

Dan kan je 60 machines met 1 ip laten werken.

1 server als master instellen met replication naar de 2de. Tussen die servers een NLB zetten en hoppa.

[Zwelgje]

Anoniem: 349056 schreef op zondag 07 maart 2010 @ 17:10:
Ooit al eens gekeken naar MS Network Load Balacing.

Dan kan je 60 machines met 1 ip laten werken.

1 server als master instellen met replication naar de 2de. Tussen die servers een NLB zetten en hoppa.

32 nodes in 2008