SQL Server 2008 Cluster

[LangerSN 10]

Hallo zusammen,

wie schon aus einer vorherigen Lizenzfrage ersichtlich sind wir in der Planung eines SQL Server. Aus Gründen der Hochverfügbarkeit ist nun ein Cluster mit SAN im Gespräch.

 

Gibt der SQL Server 2008 mit Windows Server 2008 eigentlich mehr Clusterfunktionalität als nur ein Failover Clustering?

 

Kann ich bei einem SQL Server 2008 Cluster eine Datenbank Instanz auf dem 1 Knoten laufen lassen und 1 Datenbank Instanz auf dem anderen Knoten oder ist der Komplette Clusterdienst die geclusterte Ressource die zur gleichen Zeit nur auf 1 Knoten laufen kann?

 

Danke für Eure Hilfe im Voraus.

[Lian 2.421]

Hallo,

 

Windows Cluster gibt es in zwei Ausführungen: HPC (High Performance Computing) mit dem Windows HPC Server, ehemals Compute Cluster Server: Windows HPC: Home Page

Und WSFC (Windows Server Failover Cluster), ehemals MSCS, mit dem Windows Server in den Enterprise Editionen.

Gibt der SQL Server 2008 mit Windows Server 2008 eigentlich mehr Clusterfunktionalität als nur ein Failover Clustering?

Gerade bei Windows Server 2008 hat sich beim Clustering viel getan, welche Funktionalität fehlt Dir denn?

 

Du sprichst den Aktiv/Passiv-Betrieb an. Aktiv/Aktiv ist generell nicht sonderlich empfehlenswert, da im Fehlerfall der dann aktive Node zwei Lastern schultern muss.

Bei Mehr-Node Clustern kann man problemlos Aktiv/Aktiv/(...)/Passiv Setups realisieren, solange man an die Hardware-Ressourcen denkt.

 

Zu dem Thema SQL Clustering kann ich folgende Tipps empfehlen:

Cluadmin.de: Top Tips for SQL Server Clustering

Cluadmin.de: Clustered SQL Server do’s, don’ts, and basic warnings

[LangerSN 10]

Mir fehlt eigentlich nichts. Ich bin gerade dabei die Gedanken zu sammeln wie so ein SQL Cluster bei uns laufen könnte. Geplant sind 2 Knoten mit SQL Server 2008 Standard als 1 Prozessor Lizenz. Nun stellt sich nachher für uns die Frage ob wie den SQL Cluster im Aktiv/Passiv Betrieb betreiben oder den SQL Cluster mit Aktiv/Aktiv Betrieb. Ich gehe jetzt mal davon aus das im Aktiv/Aktiv Betrieb der eine Server eine Datenbankinstanz hat und der andere Server eine andere Datenbank Instanz aber jeder für sich separat arbeitet. Oder sehe ich das falsch. Im Falle von einem Failover würde die eine Datenbank vom anderen Knoten mit übernommen werden und dann dort sozusagen laufen bis der andere Knoten seinen Betrieb wieder aufnimmt. Ist das so korrekt oder nicht realisierbar.

[NilsK 2.934]

Moin,

 

evtl. ist auch das Database Mirroring interessant für euch. Potenziell kommt es ohne SAN aus und erlaub kürzere Umschaltzeiten als ein Cluster. Allerdings sind einige Bedingungen in der Umgebung nötig und einige Einschränkungen zu beachten.

 

Deine zuletzt genannten Überlegungen treffen zu, allerdings wäre in einem Aktiv/Aktiv-Szenario neben der Last im Failover-Fall einiges zu beachten. Daher rät man im Allgemeinen eher davon ab.

 

Wichtig ist, dass ihr genau eure Anforderungen definiert und erst danach eine Lösung entwerft, ggf. mit einem erfahrenen Berater. Zu den Anforderungen gehören tolerierbare Ausfallzeit/Wiederanlaufzeit, tolerierbarer Datenverlust, tolerierbare Einschränkungen im Notbetrieb (z.B. längere Antwortzeiten, nicht alle Arbeitsplätze voll arbeitsfähig usw.), Budget.

 

Wichtig ist ebenfalls die Frage, gegen welche Schäden ihr euch denn absichern wollt, denn ein Cluster hilft euch nur bei einer kleinen Teilmenge typischer Schadensfälle. Ihr braucht also auch ein passendes Recovery-Konzept. Und die technisch-organisatorische Umgebung muss stimmen (z.B. ausreichende Redundanz in angrenzenden Bereichen, Notfallkonzepte, Wiederanlaufplan).

 

Gruß, Nils

[Lian 2.421]

Ich gehe jetzt mal davon aus das im Aktiv/Aktiv Betrieb der eine Server eine Datenbankinstanz hat und der andere Server eine andere Datenbank Instanz aber jeder für sich separat arbeitet.

Korrekt

[LangerSN 10]

Das ist mir schon klar das der Cluster mir nur im Failover weiter hilft. Welche Technologien setzt man denn noch weiterhin ein um zum Beispiel den Arbeitsspeicher zu kopieren. Im Falle eines Ausfalls von einem Knoten und noch nicht zu Ende geführten Transaktionen würden ja Daten verloren gehen. Wären dies zusätzliche Technologien die ich bei einem MSSQL Server abdecken kann?

[Lian 2.421]

Im Falle eines Ausfalls von einem Knoten und noch nicht zu Ende geführten Transaktionen würden ja Daten verloren gehen. Wären dies zusätzliche Technologien die ich bei einem MSSQL Server abdecken kann?

Nicht wirklich, bei TSQL ist eine Transaktionssicherheit gewährleistet, es ist dann Sache der Applikation sauber und durchweg TSQL Kommandos zu verwenden für schreibende Zugriffe auf die DB.

Natürlich kann es dennoch zu einem Disasterfall kommen, bei dem ein Datenverlust auftritt...

[LangerSN 10]

Wofür steht denn nun wieder TSQL? Kann das auch mit einem MSSQL Server verwendet werden?

[Lian 2.421]

Das 'T' steht für "Transact"-SQL: MSDN: Transact-SQL-Referenz (Datenbankmodul)

[NilsK 2.934]

Moin,

 

das ist so auch nicht ganz richtig.

 

Den Arbeitsspeicher kannst du nicht synchronisieren. Das wäre bei einem System, das für Höchstleistung geeignet ist (wie SQL Server) auch kaum sinnvoll machbar.

 

Das Transaktionsproblem besteht aber nicht. Jede Transaktion, die an SQL Server gesendet wird, wird im Transaction Log protokolliert, bevor SQL Server sie ausführt. Nach einem Server-Ausfall werden alle abgeschlossenen Transaktionen, deren Daten noch nicht in der Datenbank stehen, in diese kopiert (Rollforward) und alle nicht abgeschlossenen Transaktionen gelöscht (Rollback). Da letztere aber auch gegenüber dem Client nicht bestätigt wurden, gibt es auf diese Weise keinen Datenverlust.* Erst nach diesem Vorgang geht die Datenbank online. (Das ist auch der Grund für einen evtl- längeren Failover-Vorgang; zu kontrollieren im Eventlog.)

 

Mit T-SQL (als Sprache) hat das recht wenig zu tun. Applikationen können sich nicht an der Transaktionssteuerung vorbeimogeln, egal ob sie T-SQL sprechen (was fast alle tun) oder per .NET mit dem Server kommunizieren (was in den meisten Fällen auch auf eine T-SQL-Ansprache hinausläuft).

 

* Es sei denn, der Ausfall betrifft auch das Storage-System und beschädigt geschriebene Daten. (Das ist einer der Fälle, die Lian meinte.)

 

Ein paar Hintergründe findest du hier:

http://www.faq-o-matic.net/2009/03/20/warum-muss-eine-datenbank-zum-backup-konsistent-sein/

 

Und noch einmal die eindringliche Warnung: Die Fragen, die du stellst, sind nachvollziehbar und okay, aber sie deuten darauf hin, dass ihr bei dem Aufbau eines Hochverfügbarkeitssystems für SQL Server Unterstützung braucht. Klärt eure Anforderungen auf der geschäftlichen Ebene, bevor ihr Systementscheidungen trefft!

 

Gruß, Nils

[LukasB 10]

Mit T-SQL (als Sprache) hat das recht wenig zu tun. Applikationen können sich nicht an der Transaktionssteuerung vorbeimogeln

 

Wobei man hierzu noch sagen muss das mit Autocommit in einer falsch programmierten Applikation die Datenbank nachher logisch (d.h. auf Applikations-Ebene, nicht auf SQL-Server Ebene) korrupt sein kann, bzw. Geschäftsprozesse nur halb gelaufen sind aber als "komplett" markiert sind.

 

Leider gibt es sehr viele Software auf dem Markt die nicht richtig entwickelt wurde. Der Preis sagt dabei leider überhaupt nichts aus, auch bei Namhaften Herstellern kann dies vorkommen, speziell wenn Anpassungen für euch durchgeführt wurden.

[Lian 2.421]

Bei einem teuren Unterbau mit aufwendiger Architektur sollte man auch die Applikation(en) genau beleuchten.

Wobei man hierzu noch sagen muss das mit Autocommit in einer falsch programmierten Applikation die Datenbank nachher logisch (d.h. auf Applikations-Ebene, nicht auf SQL-Server Ebene) korrupt sein kann, bzw. Geschäftsprozesse nur halb gelaufen sind aber als "komplett" markiert sind.

Genau das meinte ich.

COMMIT TRANSACTION (Transact-SQL)

[LangerSN 10]

Hallo zusammen und vielen Dank für die vielen Antworten am Freitag,

ich hoffe noch auf ein paar Informationen in der neuen Woche zu folgender Frage.

 

Welche Vorkehrungen müsste ich treffen um den Datenverlust im Falle eines Failovers gegen 0 zufahren? Wenn ich das so wie in den ersten Beiträgen geschrieben habe nur Clustern würde, dann wären die Informationen aus dem Arbeitsspeicher des Aktiven Notes ja verloren.

 

Bringt mir an dieser Stelle eine Spiegelung des SQL Servers vielleicht wirklich mehr nutzen? Dann würden ja die Datenbestände zweimal vorhanden sein. Was ist mit den Daten aus dem Arbeitsspeicher.

 

Wie würde das Failover in einem solchen Fall aussehen?

 

Mit T-SQL müssten dann unsere Entwickler arbeiten. Die Anwendung die wir mit dem SQL Server nutzen wollen wird selbst programmiert.

[NilsK 2.934]

Moin,

 

Wobei man hierzu noch sagen muss das mit Autocommit in einer falsch programmierten Applikation die Datenbank nachher logisch (d.h. auf Applikations-Ebene, nicht auf SQL-Server Ebene) korrupt sein kann, bzw. Geschäftsprozesse nur halb gelaufen sind aber als "komplett" markiert sind.

 

Bei einem teuren Unterbau mit aufwendiger Architektur sollte man auch die Applikation(en) genau beleuchten.

 

völlig richtig. Das sind dann einige der Fälle, in denen ein Cluster überhaupt nichts bringt. Das liegt dann in der Hand des Applikationsentwicklers und ist keine Schwäche der Transaktionssteuerung des SQL Server.

 

Gruß, Nils

[NilsK 2.934]

Moin,

 

Welche Vorkehrungen müsste ich treffen um den Datenverlust im Falle eines Failovers gegen 0 zufahren? Wenn ich das so wie in den ersten Beiträgen geschrieben habe nur Clustern würde, dann wären die Informationen aus dem Arbeitsspeicher des Aktiven Notes ja verloren.

 

wie schon geschrieben: Datenverlust aus dem nicht versorgten RAM kann nicht auftreten, wenn es um einen Serverfehler geht. Genau dafür ist ja das Transaktionsprotokoll da. Nur wenn der Server und das Log-Volume gleichzeitig kaputtgingen, träte Datenverlust auf. Um dieses Risiko zu mindern, setzt man auf ein entsprechend abgesichertes Storage-System.

 

Mit T-SQL müssten dann unsere Entwickler arbeiten. Die Anwendung die wir mit dem SQL Server nutzen wollen wird selbst programmiert.

 

Dann sollten sich eure Entwickler rechtzeitig und ausführlich genug damit beschäftigen, denn erfahrungsgemäß ist sehr oft die Applikation verantwortlich für Probleme.

 

Gruß, Nils