none
Probleme mit SQL-Server im Failover Cluster RRS feed

  • Allgemeine Diskussion

  • 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
    Freitag, 11. Oktober 2013 10:42

Alle Antworten

  • Das klingt ja ein wenig nach einem Fehler in der Konfiguration irgendwo.

    Was sagen denn die Logs aus? Cluster Log, Windows-Log, SQL Server Log...

    Das sollte man alles mal durchsehen und alles was dort an Fehlern erscheint eliminieren - ganz allgemein ausgedrückt.


    Andreas Wolter | Microsoft Certified Master SQL Server

    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com | www.SarpedonQualityLab.com

    Freitag, 11. Oktober 2013 13:41
  • Das klingt ja ein wenig nach einem Fehler in der Konfiguration irgendwo.

    Was sagen denn die Logs aus? Cluster Log, Windows-Log, SQL Server Log...

    Das sollte man alles mal durchsehen und alles was dort an Fehlern erscheint eliminieren - ganz allgemein ausgedrückt.



    Werde ich heute nochmal alles prüfen, danke
    Montag, 14. Oktober 2013 06:38
  • Das klingt ja ein wenig nach einem Fehler in der Konfiguration irgendwo.

    Was sagen denn die Logs aus? Cluster Log, Windows-Log, SQL Server Log...

    Das sollte man alles mal durchsehen und alles was dort an Fehlern erscheint eliminieren - ganz allgemein ausgedrückt.



    Werde ich heute nochmal alles prüfen, danke

    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? 
    Dienstag, 15. Oktober 2013 08:12
  • ...


    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? 


    Hallo

    also wie ein Browser-Dienst die Performance beeinflussen soll, ist mir ebenfalls schleierhaft, zumal auf dem falschen Knoten..

    Hier wäre aber vielleicht gar eine Netzwerk-Trace mal interessant, ob da etwas falsch umgeleitet wird.

    Die Aussage, "denn das Quorum ist immer nur an einem der beiden Server verbunden. " verstehe ich so nicht

    Aber die grundsätzliche Frage ist schon richtig: was ist genau wie eingerichtet, und worin unterscheidet es sich.

    Ich fürchte aber, abseits von einem Glückstreffer, lässt sich das nicht über ein Forum Fern-Abnalysieren, dazu müsste man schon wirklich draufschauen.


    Andreas Wolter | Microsoft Certified Master SQL Server

    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com | www.SarpedonQualityLab.com

    Dienstag, 15. Oktober 2013 15:53
  • 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...
    Montag, 21. Oktober 2013 09:15