SQL Ausfallsicherheit gewährleisten

[SQLnoob 0]

Hallo Community,

 

ich hab da mal ne Frage die ich mir selber nicht ganz beantworten kann bzw. nicht ganz sicher bin.

In Sachen SQL bin ich noch etwas unbedarft deshalb habt nachsicht  ;)

 

 

Es geht um folgendes:

 

Wir haben einen SQL Server im Internet stehen, wo Kundendaten drauf liegen.

 

Der soll nun

--> ausfallsicher   UND

--> Hochverfügbar UND

--> Updatebar ohne Ausfall sein. (DB Updates + MS Updates)

 

 

Also im Grunde alles in Einem.

 

Ich stelle mir hier zwei Cluster vor, die sich untereinander replizieren.

 

--> also zwei SQL Server + 1 DB Server

                                                                     --> Peer to Peer Replikation zwischen den Servern

--> also zwei SQL Server + 1 DB Server

 

Bei Einem Update stoppe / kappe ich die Replikation, Update den ersten Cluster --> starte die Replikation, lasse Replizieren und kappe erneut um den Zweiten Cluster zum updaten um dann wieder zu starten.

 

Ergo alles ist auf dem neuesten Stand

 

Die dazu benötigten Enterprise Lizenzen sind alle vorhanden. Das ist nicht das Problem.

 

Meien Fragen nun:

Ist das der Richtige Weg bzw. Vorgehensweise?

Macht mir das die Replikation auf dauer mit? das Starten und Stoppen ?

Ist das Modell denn an sich richtig?

 

Wie löst man das in größeren Firmen?

 

 

Ich hoffe mal auf ein paar gute Vorschläge oder auch konstuktive Kritik, falls ich hier etwas falsch oder zu doof denke.

 

[Dukel 436]

Hast du dir schonmal das SQL Always On angeschaut? Das kann synchron (für HA) und Asynchron (für DR) synchronisieren.

Das mit den Updates musst du dir aber selbst anschauen.

 

EDIT:

https://msdn.microsoft.com/en-us/library/dn178483(v=sql.120).aspx

bearbeitet 3. April 2018 von Dukel

[NilsK 2.781]

Moin,

 

vor 32 Minuten schrieb SQLnoob:

 

Wir haben einen SQL Server im Internet stehen, wo Kundendaten drauf liegen.

 

was genau heißt hier "im Internet stehen"?

 

Ansonsten lässt sich deine Frage nicht vollständig beantworten. "Ausfallsicherheit" und "Hochverfügbarkeit" sind aus Systemsicht identisch. Dafür stehen verschiedene Techniken zur Verfügung, die häufigsten sind ein "herkömmlicher" Failovercluster und Always-on-Verfügbarkeitsgruppen.

 

Was die Updatefähigkeit angeht, wird man u.U. viel tiefer in die Applikationslogik einsteigen müssen. Die Updates des Betriebssystems und des SQL Servers lassen sich in aller Regel über das Clusterkonstrukt ohne Downtime für die Anwender durchführen. Die Datenbank-Updates haben aber mit der zugreifenden Applikation zu tun. Ob und ggf. wie man da mit Replikationsmechanismen arbeiten könnte, lässt sich ohne Einbindung der Applikationsentwickler nicht beantworten - das kann ein dickeres Brett sein.

 

Spätestens hier ist es also relevant, die Anforderungen genau zu definieren. Und, da du selbst angibst, von der Materie wenig Kenntnis zu haben: Holt euch Unterstützung.

 

Gruß, Nils

 

[SQLnoob 0]

@Dukel

Also ich hab mir das mit dem Alway On schon durchgelesen.

 

Hab das aber wieder evrworfen, weil hier keine Live Migration der Daten stattfinden konnte die dann auf beiden Seiten Verfügbar wären.

Ist aber richtig, in genau dieser Situation brauche ich keinen aktiven zweiten Standort.

Vielleicht sollte ich nochmals konkret lesen.

 

@NilsK

"Im Internet stehen" heisst, dass unsere Kunden mit dem Forfront damit arbeiten. Deswegen ist er auch immer wichtiger. Die VM haben wir bei einem Hoster gemietet.

 

Da ich selber hier auch einige Cluster am laufen habe, weiss ich wie ich damit umzugehen habe. Funktioniert auch alles super. Meine Peer to Peer Repli hat ja nach etwas hin und her testen auch funktioniert.

Ich war mir jedoch einfach beim wirklich produktiven SQL nicht sicher. Deswegen kamen ja meien Fragen hier.

 

Die Applikation ist von unseren Entwicklern programmiert also scheitert es daran schon mal gar nicht. Und eien Peer to Peer Replikation wird ja schon sauber unterstützt (Ist ja eh MS Sache)

 

-->

ergo habe ich beschlossen auf deinen Rat zu hören.

Ich werde das von einem Externen machen lassen da es doch sehr geschäftskritisch ist und ich mich (noch) zu wenig damit auseinander gesetzt habe. Was soll ein Sysadmin noch alles wissen  :)

 

Trotzdem Danke für die Anregung und Hilfestellungen

bearbeitet 3. April 2018 von SQLnoob