none
Clusterservice stürzt auf einem Knoten ab und der Knoten wird dem Cluster verwiesen RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ich habe einen 3-Knoten Failover Cluster auf Basis von Windows Server 2008 R2 SP1 Enterprise.

    Die Quorum Konfiguration ist Node Majority.

    Hier ist es jetzt schon drei mal vorgekommen, dass der Clusterservice abgestürzt und der Knoten daraufhin dem Cluster verwiesen wurde.

    Im Clusterlog sehe ich unmittelbar vor dem Crash folgenden Eintrag:

    ERR    mscs::GumAgent::ExecuteQueuedUpdate: ERROR_FILE_NOT_FOUND(2)' because of 'OpenSubKey( name, access, key, NOTHROW() )'(Resources\[...]\Parameters\Printers\<Printername>)

    Es scheint also irgend etwas mit Druckern zu tun zu haben. Im Cluster gibt es auch eine Print-Server Ressource, welche jedoch nicht auf dem betroffenen Knoten aktiv war. Mir fällt dazu nichts ein und finden kann ich auch nichts.  Jemand eine Idee?

    Gruß


    Freitag, 21. Dezember 2012 09:07
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Sorry für die spate Meldung - bin gerade etwas beschäftigt.

    Aus den Clusterlogs kann man nicht wirklich viel heraus lessen. Vom Verhalten her sieht es so aus, als ob bevor der von Dir oben beschriebene Event gelogged wurde ein Netzwerkproblem vorhanden war und ein Update der lokalen ClusterDB nicht geklappt hat - darauf hin ist der Knoten aus dem Cluster geflogen.

    Generell sei zu Druckern im Cluster angemerkt, dass wir dieses Modell mit 2012 nicht mehr fortführen und die Bereitstellung von Druckern in einer VM auf einem Cluster empfehlen. Der 2012er Cluster kann dann den Printservice innerhalb dieser VM überwachen.

    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    Donnerstag, 10. Januar 2013 20:35
    |
    Moderator

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo jufexe

    Ohne Validation Report und Cluster.Logs läßt sich hier nicht viel sagen... Kannst Du uns das mal über z.B. Skydrive zur Verfügung stellen? Das Logfile muss explizit über cluster.exe log /gen .... erstellt werden.

    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    Freitag, 21. Dezember 2012 13:25
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    hier die entsprechenden Logfiles.

    http://sdrv.ms/UC2C3M

    Gruß

    Montag, 7. Januar 2013 09:31
    |
  • Question
    Anmelden
    0
    Anmelden

    Danke und noch ein gutes Neues Jahr.

    Hast Du mir auch noch den Validation Report?

    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    Dienstag, 8. Januar 2013 09:24
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Hier noch der Validation Report

    http://sdrv.ms/UFDg8T

    Dir auch ein gutes neues Jahr.

    Dienstag, 8. Januar 2013 13:34
    |
  • Question
    Anmelden
    0
    Anmelden

    Wenn ich den Report und die Logs richtig interpretiere, dann hat jeder Knoten 2 Netzwerk Adapter. Über einen Adapter wird der "public" Traffic geroutet und über den 2ten Adapter scheint der Heartbeat zu laufen. Kannst Du mal prüfen ob am 2ten Adapter auch der "Client for Microsoft Networks" aktiv ist und dazu noch das "File und Printer Sharing for Microsoft Networks" ?

    Dazu mal ein IPconfig /all von einem Knoten.

    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    Dienstag, 8. Januar 2013 22:37
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Richtig, jeder Knoten hat 2 Netzwerk Adapter. Über das eine Netz (NETWORK21) läuft das komplette Client-Geschäft, über das andere (NETWORK21-BB) läuft der Traffic für das Backup der Knoten und Clusterressourcen. Heartbeats laufen über beide Netze.  Bei beiden Netzen ist die Option "Allow clients to connect through this network" aktiviert, da sonst das Backup nicht funktioniert. Clients können jedoch nicht auf Adressen des NETWORK21-BB zugreifen, da es dort keine physische Verbindung gibt.

    Auf allen Knoten ist beim zweiten Adapter sowohl der "Client for Microsoft Networks" als auch das "File und Printer Sharing for Microsoft Networks" aktiv.

    Hier die Ausgabe vom IPconfig:

    C:\Windows\system32>ipconfig /all

    Windows IP Configuration

       Host Name . . . . . . . . . . . . : Node03
       Primary Dns Suffix  . . . . . . . : domain.local
       Node Type . . . . . . . . . . . . : Hybrid
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : domain.local

    Ethernet adapter Local Area Connection* 9:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft Failover Cluster Virtual Adapter
       Physical Address. . . . . . . . . : 02-21-5E-30-CB-B8
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::89ad:b82f:f4d1:c58f%16(Preferred)
       IPv4 Address. . . . . . . . . . . : 169.254.3.37(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.0.0
       Default Gateway . . . . . . . . . :
       DHCPv6 IAID . . . . . . . . . . . : 251797854
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-15-E5-2F-41-00-21-5E-30-CB-B8

       DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                           fec0:0:0:ffff::2%1
                                           fec0:0:0:ffff::3%1
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Ethernet adapter NETWORK21:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Broadcom BCM5708S NetXtreme II GigE (NDIS VBD Client) #2
       Physical Address. . . . . . . . . : 00-21-5E-30-CB-B6
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv4 Address. . . . . . . . . . . : 192.168.1.130(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       IPv4 Address. . . . . . . . . . . : 192.168.1.134(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       IPv4 Address. . . . . . . . . . . : 192.168.1.135(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . : 192.168.1.111
       DNS Servers . . . . . . . . . . . : 192.168.1.161
                                           192.168.1.162
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Ethernet adapter NETWORK21-BB:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Broadcom BCM5708S NetXtreme II GigE (NDIS VBD Client)
       Physical Address. . . . . . . . . : 00-21-5E-30-CB-B8
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv4 Address. . . . . . . . . . . : 192.168.232.130(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . :
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Tunnel adapter isatap.{FF2B930E-7458-41FB-81F2-291C795740E2}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter isatap.{2D6E8709-0705-45F2-A925-77952DD82123}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter isatap.{0F3D5763-C315-47B2-A815-EF2ED0EE94AF}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Mittwoch, 9. Januar 2013 07:06
    |
  • Question
    Anmelden
    0
    Anmelden

    Sorry für die spate Meldung - bin gerade etwas beschäftigt.

    Aus den Clusterlogs kann man nicht wirklich viel heraus lessen. Vom Verhalten her sieht es so aus, als ob bevor der von Dir oben beschriebene Event gelogged wurde ein Netzwerkproblem vorhanden war und ein Update der lokalen ClusterDB nicht geklappt hat - darauf hin ist der Knoten aus dem Cluster geflogen.

    Generell sei zu Druckern im Cluster angemerkt, dass wir dieses Modell mit 2012 nicht mehr fortführen und die Bereitstellung von Druckern in einer VM auf einem Cluster empfehlen. Der 2012er Cluster kann dann den Printservice innerhalb dieser VM überwachen.

    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    Donnerstag, 10. Januar 2013 20:35
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Danke für die Analyse.

    Für mich sah es auch nach einem Netzwerkproblem aus, jedoch konnte ich dort ebenfalls nichts ungewöhnliches Feststellen.

    Das Problem ist nun seit einiger Zeit nicht mehr aufgetreten. Ich werde also weiter abwarten müssen.

    Danke auch für die Info mit dem 2012er Cluster.

    Gruß

    Freitag, 11. Januar 2013 06:31
    |