Information ausblenden
Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm

Probleme mit SQL Server 2008 in Failover Cluster

Dieses Thema im Forum "Microsoft SQL Server" wurde erstellt von a.karls, 11 Oktober 2013.

  1. a.karls

    a.karls Benutzer

    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
     
  2. ukulele

    ukulele Datenbank-Guru

    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?
     
  3. a.karls

    a.karls Benutzer

    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
     
  4. ukulele

    ukulele Datenbank-Guru

    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.
     
  5. a.karls

    a.karls Benutzer

    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".
     
  6. a.karls

    a.karls Benutzer

  7. a.karls

    a.karls Benutzer

    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?
     
  8. a.karls

    a.karls Benutzer

    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...
     
  9. ukulele

    ukulele Datenbank-Guru

    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.
     
  10. a.karls

    a.karls Benutzer

    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
     
  11. ukulele

    ukulele Datenbank-Guru

    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.
     
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden