Probleme mit SQL Server 2008 in Failover Cluster

Hallo allerseits,
ich habe hier ein interessantes und zugleich ziemlich nerviges Problem mit einem SQL-Failover-Cluster. Ich hoffe, hier vielleicht noch den einen oder anderen Tipp zu bekommen, denn ich bin mittlerweile wirklich ratlos.
Zum Setup:

zwei Windows Server 2008 R2 mit Cluster Services, somit zwei Knoten, Active / Passive Cluster
SQL Server 2008 R2, Version 10.50.4000
zwei Instanzen, MSSQL-extern und MSSQL-intern\FA
zusätzlich NSClient++ und MSDTC als Clusterdienste

Netzwerk:
10.58.68.17/24 (nsc-service.fa.de) - NSClient++ Monitoring Service für diesen Cluster
10.58.68.19/24 (mssql-extern.fa.de) - SQL Server Failover IP für Default Instanz: mssql-extern
10.58.68.20/24 (mssql-intern.fa.de) - SQL Server Failover IP für FA Instanz: mssql-intern\fa
10.58.68.21/24 (mssql-cluster.fa.de) - Microsoft Cluster Dienste
10.58.68.26/24 (mssql-DTC Service) - DTC Interconnect
10.58.68.23/24 (mssql01-1.fa.de) - Host RZ
172.16.1.23/24 (mssql01-1.fa.de) - Host Storage
10.58.68.24/24 (mssql01-2.fa.de) - Host RZ
172.16.1.24/24 (mssql01-2.fa.de) - Host Storage

Problem:
Verschiebe ich beide Instanzen von Knoten 1 auf Knoten 2, dann sind die Datenbanken der Instanz mssql-extern sofort wieder erreichbar, die Instanzen von mssql-intern\fa nicht
Verschiebe ich nur die Instanz mssql-intern\fa auf Knoten 2, funktioniert diese auf Anhieb
Verschiebe ich die Instanz mssql-extern dann auch auf Knoten 2, dann funktioniert die Instanz mssql-extern, aber mssql-intern\fa nicht mehr
Lasse ich mssql-extern auf Knoten 1 und mssql-intern\fa auf Knoten 2, dann läuft das für ca 1 Stunde sauber, danach stirbt die Netzwerkverbindung vom Management Interface auf Knoten 1. Die virtuellen Adressen funktionieren weiter, aber die Management IP 10.58.68.23 ist nicht mehr erreichbar durch Nagios oder ICMP. Das Problem lässt sich nur durch einen Neustart beheben. Nach dem Neustart ist aber die Instanz mssql-intern\fa auf Knoten 2 nicht mehr erreichbar, also muss alles wieder auf den ersten Knoten.

Lösungsansätze:
alle notwendigen Dienste nach diversen Verschiebungen neu gestartet
NIC auf Knoten 1 nach Ausfall deaktivert, wieder aktiviert
Netzwerk Monitoring laufen lassen, keine Fehler zu finden

Gedanken:
Scheinbar verklemmt sich die Instanz mssql-intern\fa, sobald die andere Instanz auf Knoten 2 mitläuft, auf dem ersten Knoten stellt dies jedoch kein Problem dar. MAC-Binding oder Cache Probleme schliesse ich aus, da es sich ja bei den Instanznamen und virtuelle Interfaces bzw DNS handelt
Der Ansatz, das Knoten 1 so eine Art Master-Rolle spielt konnte ich durch Tests auch "eigentlich" ausschliessen

Nächste Schritte:
Entweder das Problem lösen oder zum Test alle Datenbanken in eine Instanz stecken, sinnvollerweise in die mssql-extern, denn diese lässt sich ja beliebig verschieben. Wenn das nichts hilft, dann müsste ich wohl oder übel den Cluster auflösen und zwei Standalone System bauen, das möchte ich aber eigentlich verhindern.

Jede Hilfe ist willkommen…

---------------------------------------------------------------

English Version (sorry for translation errors ):

Hi everyone,
i´m facing an interesting but also really stressy situation with a SQL-Failover-Cluster. Maybe someone can help me out or give some useful tip.
Setup:

two Windows Server 2008 R2 with Cluster Services, two nodes, Active / Passive Cluster
SQL Server 2008 R2, Version 10.50.4000
two Instances, MSSQL-extern and MSSQL-intern\FA
in addition NSClient++ and MSDTC as Clusterservices

Network:
10.58.68.17/24 (nsc-service.fa.de) - NSClient++ Monitoring Service
10.58.68.19/24 (mssql-extern.fa.de) - SQL Server Failover IP Default Instanz: mssql-extern
10.58.68.20/24 (mssql-intern.fa.de) - SQL Server Failover IP FA Instanz: mssql-intern\fa
10.58.68.21/24 (mssql-cluster.fa.de) - Microsoft Cluster Services
10.58.68.26/24 (mssql-DTC Service) - DTC Interconnect
10.58.68.23/24 (mssql01-1.fa.de) - Host RZ
172.16.1.23/24 (mssql01-1.fa.de) - Host Storage
10.58.68.24/24 (mssql01-2.fa.de) - Host RZ
172.16.1.24/24 (mssql01-2.fa.de) - Host Storage

Problem:
If i move both instances from node 1 to node 2, then instance mssql-extern is running fine, instance mssql-intern\fa doesn't
If i move only the instance mssql-intern\fa to node 2, then everything runs ok
if i also move the instance mssql-extern to node 2, then mssql-extern runs, mssql-intern\fa stops working
If i leave mssql-extern on node 1 and mssql-intern\fa on node 2, then everything runs fine for maybe one hour. After that, the network from the management on node 1 turns unaviable, the virtual ip´s from the instances stays up and running. Management isn´t reachable through nagios oder icmp. the Problem only solves, when node 1 is restarted. after the reboot from node 1 i have to migrate both instances back to node 1

Solutions:
restart all necessary services after some migrations
deactivate the NIC on node 1 after the failover
monitor the network and traffic, nothing useful found

Thoughts:
It seem, that the instance mssql-intern\fa is blocked after the migration from the instance mssql-extern to node 2. MAC-Binding or cache problems don´t seem to be the cause.
The theory, that node 1 is some sort of "master" in this setup has been dropped because there is no change in behavior after a restart from node 1 when the problem occurs.

Next steps:
Either fix the problem itself or put all database from instance mssql-intern\fa to mssql-extern and test again. Otherwise i would have to build a two standalone system setup, but that would then be the last option (and, for sure, not my preferred one)

Every hint is welcome

 

Ich hab eigentlich 0 Plan von der Materie da ich nie einen SQL Failover betrieben habe. Allerdings fallen mir zwei wesentliche Punkte auf:

1) Bestand das Problem schon immer (bzw. ist die Umgebug neu) oder reden wir hier über einen Fehler der bei einem bestehenden System auftritt?
2) Der Ausfall einer NIC in diesem Kontext ist mir suspekt. Kann es sich hierbei vieleicht um ein Netzwerk (zu 90% sowieso immer DNS) oder Hardwareproblem handeln? So wie ich das verstehe ist die Management IP eine Hardware Netzwerkkarte, kann man die eventuell mal wechseln?

 

zu a) die Umgebung ist neu und wurde vor ca einer Woche in Betrieb genommen. Tests wurden nur mit der EXTERN-Instanz vorgenommen, da ging / geht ja auch alles wunderbar
zu b) DNS haben wir bereits geprüft, hier scheint der Fehler nicht zu stecken. Die Karte ist eine Onboard NIC, daher ist tauschen nicht drin. Allerdings könnte man einen anderen Port am Server und / oder am Switch versuchen. Guter Hinweis. Allerdings glaube ich eher an einen Fehler in der Config des Failovers

 

Wie gesagt Failover habe ich nie bei SQL betrieben daher kann ich da leider nicht helfen und die Tatsache das es vorher aber noch nicht wie gedacht lauffähig war spricht auch für ein Comfig Problem.

 

die clustervalidierung meckert auch nicht groß rum, das einzige, was dem tool nicht gefällt ist ein unsignierter treiber für die ramdisk, die wir für tempdb betreiben. daran wird es wohl nicht liegen, denn ohne tempdb kein serverstart, und der klappt ja. ansonsten hab ich noch diese warnung:
Diese Ressource ist für die Ausführung in einem gesonderten Monitor konfiguriert. Standardmäßig werden Ressourcen für die Ausführung in einem freigegebenen Monitor konfiguriert. Diese Einstellung kann manuell geändert werden, um zu verhindern, dass sie andere Ressourcen beeinflusst oder von diesen beeinflusst wird. Sie kann auch automatisch vom Failovercluster festgelegt werden. Bei Fehlschlagen einer Ressource wird diese in einem gesonderten Monitor neu gestartet, um die Auswirkungen auf andere Ressourcen zu verringern, falls bei der Ressource erneut ein Fehler auftritt. Dieser Wert kann durch Öffnen der Ressourceneigenschaften und durch Klicken auf die Registerkarte für erweiterte Richtlinien geändert werden. Auf dieser Registerkarte befindet sich das Kontrollkästchen "Diese Ressource in einem eigenen Ressourcenmonitor ausführen".

 

http://social.technet.microsoft.com...sourcen-im-eigenen-ressourcenmonitor-ausfhren

das mit dem monitor scheint also ok zu sein..

 

Ich möchte heute ein kurzes Update zu dem Problemfall abgeben. Gestern Abend wurden noch einmal ausgiebige Tests durchgeführt, um das Problem weiter einzugrenzen. Getestet wurde unter anderem:
-DNS, ICMP, Portstatus vor, während und nach Failover auf beide Knoten > keine Auffälligkeiten, Maximal 2 Pakete Verlust
-Eventlogs vor, während und nach Failover > keine Fehler
-Cluster Validierung inkl. Datenträgern > keine Fehler
-Connect via TCP und NP > keine Änderung, Webanwendungen liefern Fehler 26 (ASP)
-Ändern der dynamischen TCP Ports für die Named Instance > keine Änderung
-Test auf offenen UDP Port 1434 mit portqry > Passt
-Rechte der Dienste und der Webanwendung geprüft > passen
-SQL Browser mehrmals neu gestartet > keine Änderung

Neu an der Situation ist, dass die Datenbanken der Default Instance zwar alle erreichbar sind, aber die Performance teilweise in den Keller geht. Das ändert sich nur, wenn ich auf dem Passiven Clusterknoten den SQL Browser beende.
Ebenfalls nur ist, dass die Datenbanken auf der Named Instance nun ebenfalls größtenteils erreichbar sind, lediglich eine ältere Anwendung, die explizit auf den Native Client angewiesen ist, kann nach wie vor nicht angesprochen werden, egal ob via TCP oder NP.

Die Situation mit dem "Split Brain", also eine Instanz auf Knoten 1 und die andere auf Knoten 2 können wir meiner Ansicht nach streichen, denn dieses Szenario war eh nie so vorgesehen, des Weiteren macht das auch keinen Sinn, denn das Quorum ist immer nur an einem der beiden Server verbunden.

Die Frage ist also nun: Was ist an dem zweiten Knoten so anders als an dem ersten?

 

Nachdem wir dieses Wochenende weiter Tests vorgenommen haben, möchte ich hier
einen aktuellen Status mitteilen:
Grundsätzlich hat sich an dem Verhalten nichts geändert, jedoch haben wir eine
genauere Fehlerkonstellation herausgefunden. Verschieben der Instanzen
zwischen den beiden Knoten verursacht keine Fehler. Die Änderung der MAC wird
sauber per GARP über den Coreswitch und den Router kommuniziert, Switch und
Router erneuern ihre ARP-Caches, die Änderung der MAC kommt auf auf dem
Weberver der Problem-Applikation an. Somit können wir ARP ausschliessen, dies
war in den letzten Tagen unser Hauptverdächtiger. Die Probleme entstehen erst,
wenn einer der beiden Knoten neu gestartet (Windows komplett, wie es bei
Windows Updates der Fall wäre) wird. Die Änderung des aktiven Knotens wird
kommuniziert, die ARP Tabellen werden geändert, aber die
Verbindungsperformance bricht in dem Moment ein, wenn sich der neu gestartete
Knoten im Cluster "zurück meldet". Datenpakete kommen an, allerdings mit einer
extremen Verzögerung. Dabei handelt es sich aber zunächst einmal nicht um ein
generelles Problem mit der Erreichbarkeit der Hosts, ICMP, iPerf etc liefern
vernünftige Werte, allerdings sieht man bei einer Analyse des TCP Streams, das
die Zeit, die ab dem Moment des initialen TCP Paketes zum SQL Server vergeht,
um Welten gegenüber einer funktionierenden Konfiguration abweicht. Bei einer
lauffähigen Version benötigen wir für die Anmeldung an der Applikation etwas
mehr als 1 Sekunde. Funktioniert das Setup nicht, so läuft die Applikation
nach 30 Sekunden auf einen Timeout. Auch die Menge der übermittelten Daten
macht im "kaputten" Zustand nur ein knappes drittel der Menge aus, welche
ansonsten innerhalb der ersten Sekunde übertragen wird. Dieses Verhalten ist
besonders extrem in Verbindung mit dem Native Client. Andere Anwendungen
öffnen zwar die Verbindung zur DB, allerdings auch meßbar langsamer. Dieses
Verhalten ist allerdings kein Dauerzustand, nach einigen Stunden (!)
normalisiert sich das ganze wieder.
Nun ist es ja so, dass wir auf einem physikalischen Interface vier VIPs und
eine "echte" IP gebunden haben. Ich habe bei der Recherche bereits etliche
Topics gefunden, die ein ähnliches Verhalten im Bezug auf MS Cluster und /
oder Hyper V beschreiben. In manchen Fällen scheint das ein Hardware Problem
zu sein, in anderen Fällen scheint das Problem in direktem Zusammenhang mit
diversen Einstellungen (TCP Offloading…) zu stehen...

 

Wenn dir das hilft, du tust mir leid Nicht das ich nicht auch schon scheiss Probleme hatte aber sowas ist ätzend. Habt ihr schon probiert die Umgebnung komplett neu aufzusetzen?

Nicht jede Netzwerkkarte kann TCP Offloading, kann eure das? Habe mich noch nicht zu sehr damit befasst aber für unser iSCSI haben wir Offload-fähige Netzwerkkarten. Allerdings nutzen wir VMware, kein Hyper-V.

 

Danke für die Kondulenz Neu aufgezogen haben wirs noch nicht, aber wenn das so weitergeht, dann werd ich das wohl machen. Offloading können die Karten wohl.. Wir verwenden gar kein Hyper V, mir war dieses Thema nur in dem Zusammenhang aufgefallen. Bei uns ist auch ausschliesslich VMWare im Einsatz, der SQL Cluster ist halt Blech. Evtl bau ich mir das ganze in VMWare mal nach

 

Unsere DBs sind bis auf eine nicht groß genug um dafür extra Hardware aufzustellen. Interessieren würd es mich trotzdem ob die als Hardware überhaupt signifikant schneller sind als VMs. Zum Nachbau und Test sollte es allemal taugen.