SQL Database op 2 verschillende servers

[Sunfalls]

Mijn vraag
Mijn vraag is of iemand een idee heeft om het volgende op te lossen:
Wij draaien een sql database op een DBserver waar windows server 2012 op draait.
Alle programma's die verbinding maken met de database zijn door ons zelf gebouwd.
Als er nu windows updates zijn voor de DBserver of er moet onderhoud aan gepleegd worden ervaren de interne users en externe bestelklanten hier enorme hinder van.

Ik ben dus eigenlijk op zoek naar een manier om een soort van 2e DBserver01 te maken waar ik een directe kopie van de sql database heb.
Als ik dus onderhoud moet doen aan de huidige DBserver dat de andere server het naadloos over kan nemen zonder hinder van gebruikers.
Of als ik op de nieuwe DBserver01 eerst test of de updates goed werken en daarna de huidige DBserver kan patchen.

Samenvatting. Ik ben dus op zoek naar een oplossing om de sql database op 2 vm's te laten draaien waarbij de 1 dus stil mag staan en niets doet maar wel op het moment van switchen alle data ter beschikking heeft zonder dat de gebruiker daar last van heeft.

Relevante software en hardware die ik gebruik
Windows server 2012
SQL server 2010
Microsoft SQL Server Management Studio
VMware vSphere Client version 6.5.0.13000

Wat ik al gevonden of geprobeerd heb
Eigenlijk nog niets omdat ik niet zo goed weet waar ik moet zoeken.

[MAX3400]

Je hebt drie mogelijkheden in volgorde van "lastiger" in te richten op Windows & SQL niveau.

Mirror / Always On / Cluster

Neemt niet weg dat je verplicht bent om je licenties zeeeer goed te bekijken; grote kans dat een cluster je zomaar 12K aan CPU-licenses gaat kosten.

/edit: Bedenk me net dat je eventueel ook kan kijken naar VMware VM Fault Tolerance (is een feature die ook binnen je VMware licensing moet vallen) maar eigenlijk moet je dit niet inzetten voor "updating" maar voor "host defects".

[ Voor 29% gewijzigd door MAX3400 op 28-02-2018 10:44 ]

[idef1x]

Zoiets als : https://docs.microsoft.co...er-failover-cluster-setup

1e hit in google

[RobIII]

Sunfalls schreef op woensdag 28 februari 2018 @ 10:41:
Eigenlijk nog niets omdat ik niet zo goed weet waar ik moet zoeken.

Doe eens gek...

Hou je portemonnee maar bij de hand trouwens. Of je moet gaan kijken naar replication; dat kan zelfs met de Express edities.

Sunfalls schreef op woensdag 28 februari 2018 @ 10:41:
SQL server 2010

Die bestaat niet

[ Voor 57% gewijzigd door RobIII op 28-02-2018 10:47 ]

[MAX3400]

Trouwens, even nog gekker gedacht; een mirror is geen goed idee omdat je bij onderhoud je DNS-records (waarschijnlijk) handmatig moet omzetten omdat je anders een round-robin verhaal krijgt naar je instance-naam.

Vergeet ook niet te controleren of jouw applicaties, je ODBC-koppelingen alsmede je transaction logging wel "HA aware" zijn; zo ken ik een leverancier waarbij mirroring wel ondersteund is maar de applicatie op hostname verbindt. Kan je bij elke update algemene downtime afkondigen voor die applicatie of je DNS aanpassen.

[Denarius]

Wat je zoekt is failover cluster of een availability group.

https://docs.microsoft.co...ability-groups-sql-server

Edit:
Overigens is dit pas vanaf sql2012 geregeld.
Alles ouder dan 2012 heeft geen failover mogelijkheden voor zover ik weet.

[ Voor 24% gewijzigd door Denarius op 28-02-2018 10:50 ]

[Sunfalls]

RobIII schreef op woensdag 28 februari 2018 @ 10:43:
[...]

Doe eens gek...

Hou je portemonnee maar bij de hand trouwens. Of je moet gaan kijken naar replication; dat kan zelfs met de Express edities.


[...]

Die bestaat niet

Ik wist niet goed waar ik op moest zoeken.

Maar ben dankbaar voor jullie antwoorden. Ik ga ermee spelen en kijken of het lukt.

[MAX3400]

Denarius schreef op woensdag 28 februari 2018 @ 10:47:

Overigens is dit pas vanaf sql2012 geregeld.
Alles ouder dan 2012 heeft geen failover mogelijkheden voor zover ik weet.

Ik heb hier een SQL2008 mirror-group staan en ooit bij een grote meubelfabrikant een 4-node SQL cluster ingericht met SQL2008. Volgens mij kon je zelfs op SQL2005 een cluster inrichten.

Sunfalls schreef op woensdag 28 februari 2018 @ 10:55:
[...]

Maar ben dankbaar voor jullie antwoorden. Ik ga ermee spelen en kijken of het lukt.

Hopelijk bedoel je onderzoeken, documenteren, OTA inrichten en dan pas in produktie zetten? Zodra je eenmaal de "wizard" failover of cluster begint, kan je bijna niet meer terug. Lijkt me onwenselijk in een single-node SQL instance zoals je die nu hebt staan.

[ Voor 35% gewijzigd door MAX3400 op 28-02-2018 10:59 ]

[Denarius]

MAX3400 schreef op woensdag 28 februari 2018 @ 10:58:
[...]

Ik heb hier een SQL2008 mirror-group staan en ooit bij een grote meubelfabrikant een 4-node SQL cluster ingericht met SQL2008. Volgens mij kon je zelfs op SQL2005 een cluster inrichten.


[...]

Hopelijk bedoel je onderzoeken, documenteren, OTA inrichten en dan pas in produktie zetten? Zodra je eenmaal de "wizard" failover of cluster begint, kan je bijna niet meer terug. Lijkt me onwenselijk in een single-node SQL instance zoals je die nu hebt staan.

Je hebt soort van gelijk.
Database mirrors is vanaf 2008 beschikbaar.
Availability groups is vanaf 2012.

Ik zal ook even een link plaatsen voor een database mirror.

https://docs.microsoft.co...base-mirroring-sql-server

Ik zou inderdaad eerst in een test omgeving goed testen etc.
Dit moet je niet mee gaan prutsen in een live omgeving!

[ Voor 6% gewijzigd door Denarius op 28-02-2018 11:14 ]

[Rolfie]

Sunfalls schreef op woensdag 28 februari 2018 @ 10:41:
Samenvatting. Ik ben dus op zoek naar een oplossing om de sql database op 2 vm's te laten draaien waarbij de 1 dus stil mag staan en niets doet maar wel op het moment van switchen alle data ter beschikking heeft zonder dat de gebruiker daar last van heeft.

Relevante software en hardware die ik gebruik
Windows server 2012
SQL server 2010
Microsoft SQL Server Management Studio
VMware vSphere Client version 6.5.0.13000

SQL2010 heb ik nog niet voorbij zien komen. Waarschijnlijk een foutje....

Maar je wilt SQL dus draaien op vmware, is dit icm DRS of HA? Of dit draai je al? Check je licentie hiervoor even dubbel. Dit kan namelijk nog wel eens lastig zijn.

Daarnaast.... Je gebruikt het icm met een Internet koppeling, dus waarschijnlijk zit je al vast aan een processor licentie. En op virtuele kan dit helemaal prijzig zijn of worden icm SA.

Het kan wel eens een stuk goedkoper zijn, om 2 fysieke server icm 4CORE CPU's met de hoogste frequentie te nemen vanuit Licentie oogpunt. Dit heeft ons namelijk een flinke hoeveelheid geld bespaard. Ik geloof iets van 20-30K.

[CMD-Snake]

Denarius schreef op woensdag 28 februari 2018 @ 10:47:
Wat je zoekt is failover cluster of een availability group.

https://docs.microsoft.co...ability-groups-sql-server

Edit:
Overigens is dit pas vanaf sql2012 geregeld.
Alles ouder dan 2012 heeft geen failover mogelijkheden voor zover ik weet.

Let wel op dat tot en met SQL Server 2014 je de Enterprise Edition moet gebruiken om een availability group te kunnen gebruiken. Vanaf SQL Server 2016 met SP1 kan je in de Standard Edition een basic availability group maken. Daar zitten wel beperkingen aan dus lees je goed in of dit bij je eisen past. Het is wel goedkoper dan twee keer een Enterprise Edition moeten kopen.

Indien je een kopie van je database wil hebben kan je ook log shipping gebruiken. Dit is een goedkope manier om een cold standby te hebben en dit werkt ook met de Standard Edition. Log shipping biedt geen automatische failover, je zal zelf de nodige aanpassingen moeten doen aan applicaties om de kopie database te gebruiken.

Mirroring raad ik af. Alleen in SQL Server 2005 was dit een feature, daarna meteen deprecated. Het is lastig om in te richten en niet bepaald stabiel. Dat is ook de reden waarom deze feature zo snel weer teruggetrokken werd.

[Henkje.doc]

De grootste beperking met SQL 201Standard en Availability Groups is dat je per Availability Group slechts 1 database kan opnemen..
Zaken zoals een synchrone replica zit er wel in, alleen wel beperkt tot het aantal nodes/servers. Daarnaast moet je je afvragen of bij Always On je een secondary replica wil hebben.

Dat klinkt namelijk erg mooi, maar het kan in sommige gevallen locks veroorzaken (want ook een select/read is een lock).

Als ik de case van de topic starter lees zou ik zelf uitkomen op replicatie.
Wat normaal gesproken kan helpen in de beslissing, is of de data direct en actueel moet zijn, en altijd te benaderen moet zijn.

Als de data vanuit beide kanten ook muteerbaar moet zijn dan krijg je een andere uitdaging. Ja dit kan met Merge replicatie, maar levert wel weer andere uitdagingen aan.
Vaak zie ik replicatie gebruikt worden voor een database die tbv reporting wordt gebruikt. Dus geen mutaties, maar alleen selects.

[Sunfalls]

Het gaat er meer om dat als er aan de ene kant een server geboot moet worden vanwege onderhoudt dat een andere server met dezelfde informatie klaar staat, die dan ook gemuteerd en bijgewerkt kan worden en dat zodra server 1 weer klaar is met booten en weer up en running is, het weer over kan nemen met alle informatie inclusief wat er op de andere server bewerkt is.

[Henkje.doc]

Sunfalls schreef op vrijdag 13 april 2018 @ 08:02:
Het gaat er meer om dat als er aan de ene kant een server geboot moet worden vanwege onderhoudt dat een andere server met dezelfde informatie klaar staat, die dan ook gemuteerd en bijgewerkt kan worden en dat zodra server 1 weer klaar is met booten en weer up en running is, het weer over kan nemen met alle informatie inclusief wat er op de andere server bewerkt is.

Ok dan is het afhankelijk van het soort storage wat je beschikbaar hebt.

Failoverclusterig als je SAN storage hebt wat meegaat zodra je je clusterresourcea overfailen naar de andere node.

Always on kan ook. Je kan dan zelfs lokale storage gebruiken, want iedere node heeft zijn eigen storage. Eigenlijk is always on clustering, maar dan op de SQL laag i.p.v. op OS laag.

Beide zorgen ervoor dat na het vrijspelen van een node je zonder problemen kunt rebooten.

[Evilslayer]

Wat mag het gaan kosten?
Hebben jullie een inhouse DBA die kan bijspringen bij problemen/troubleshooting? Het introduceren van een manier om de beschikbaarheid te verhogen is één iets, het onderhouden is een tweede.

Of als ik op de nieuwe DBserver01 eerst test of de updates goed werken en daarna de huidige DBserver kan patchen.

Hier dient een test/acceptatieomgeving voor en ga je absoluut niet doen op de productieserver. Eenmaal je de geteste updates in productie brengt zou je al quasi zeker moeten zijn dat ze gaan werken.

Als ik dus onderhoud moet doen aan de huidige DBserver dat de andere server het naadloos over kan nemen zonder hinder van gebruikers.

100% garantie is er ook bij bevoorbeeld AlwaysOn niet. Er is een heel korte downtime (secondenwerk) bij het overfalen van node1 naar node2. In de realiteit merken de meeste applicaties dit niet/nauwelijks, maar 100% gegarandeerd is dit zeker niet.

Vergeet niet dat AlwaysOn Availability Groups database level replicatie uitvoeren. Alle zaken gedefineerd op insance niveau (logins, linked servers, agent jobs, ...) moet je zelf gaan repliceren.Wanneer AlwaysOn zou geintroduceerd worden kan de huidige stand alone SQL installatie gebruikt worden.

Als aanvulling op wat hierboven gesteld wordt:

• VMWare Fault Tolerance zal dezelfde machine repliceren naar andere vmware host. Kan je niet meteen gebruiken als hot-standby node voor patching. FT stelt ook serieuze eisen aan het onderliggende netwerk (10GBit aangeraden) & supporteert max 4 cores per VM.
• Failover clustering kan ook, mits je de storage aan beide nodes kunt presenteren. Afhankelijk van de mogelijkheden van de SAN kan je dit op verschillende manieren doen. Eventueel kan je zelfs clustered shared volumes gebruiken. Op elk gegeven moment zal maximaal 1 node schrijftoegang krijgen tot de desbetreffende storage. Bij een failover krijgt de andere node toegang tot deze disks. Hou er rekening mee dat om een SQL Failover Clustered Instance te gebruiken je SQL op een bepaalde manier moet installeren. De bestaande instance converteren naar een FCI instance kan niet.
• SQL Server Replicatie heeft bij mijn weten geen failover mogelijkheden, die moet je dan zelf in de applicatie gaan inbouwen.