Cluster Failover bei Ressourcenfehler

Alle Antworten

• 

  

  0

  Anmelden

  Hi Sven,

  kannst du bitte prüfen ob bei der "test" network name ressource, alle beiden Knoten als "possible owner" gelistet ist?

  "..... Status "Offline". Der Datenträger blieb "Online"...."

  Meiner persönlichen Meinung nach, ist das ist auch korrekt so, da du immer noch eine FC Verbindung zum SAN hast, hat die LUN generell keine Fehler und da Sie auch keine Abhängigkeit "unter" sich, welche Sie in den Status "offline" ziehen könnte, geht der Status "online" in Ordnung ;-)

  "....Nun hätte ich erwartet, dass der Cluster aufgrund des Fehlers nach einiger Zeit versucht auf den anderen Node zu schwenken. Leider geschieht gar nichts.
  Wird so ein Fall prinzipiell nicht abgefangen oder habe ich etwas falsch/nicht konfiguriert ?...."

  hier sollte ein failover der ressource passieren, wenn richtig konfiguriert :-) habe es gerade nochmal getestet und sobald die "public" NIC offline ist, erkennt der cluster service dies und initiert den Failover. falls du das allerdings einigemale hintereinander getestet hast, solltest du dabei auf die werte "restart periods" achten!

  Zudem kannst du dir einen "cluster" Log erstellen lassen (cluster log /gen), hier solltest du detailliert sehen, was genau in der Zeit passiert, wenn du die NIC in den Status "disabled" setzt (cluster log auf beiden seiten erstellen lassen!). NETFT sollte dir hier sehr detaillierte Infos geben können....

  PS: ...verzeih mir das "denglisch" im deutschen Forum aber arbeite hauptsächlich mit englischem OS ....

  Gruß

  Ramazan

  Montag, 5. Juli 2010 21:33

  Antworten

  |

  Zitieren

  Moderator
• 

  

  0

  Anmelden

  Noch eine Ergänzung zu Ramzan und Deinem Posting von meiner Seite:

  Wäre der Possible Owner falsch konfiguriert dürfte ein manueller Failover (verschieben der Gruppe) ebenfalls nicht funktionieren!

  Gibt es im Cluster auf den Knoten noch weitere NICs?

  Ich vermute, dass hier ggf. ein Bug vorliegt - genaueres kann ich aber erst nach durchsicht der Cluster Logs sagen. Kannst Du uns/mir diese zur Verfügung stellen. GGf. über Deinen Live Account freigeben? Optimal wäre gleich ein kompletter MPS Report - bzw. auf jeden Fall die Cluster Logs.

  // ** aus einem anderen Posting

  Auf folgende Dinge ausführen:

  1. Eingabeaufforderung mit erweiterten Rechten starten
  2. Nochmals die Clustergruppe verschieben (siehe oben)
  3. Dann bitte ein Cluster Log erstellen lassen cluster log /gen /span:10 /level:5
  4. Nochmals einen Cluster Validation Report laufen lassen
  5. Danach folgendes Verzeichnis C:\Windows\Cluster\Reports packen
  6. Zum Schluss deinen MPS Report (x64) laufen lassen und dort zusätzlich die Option "Server Components" aktivieren. Hier der Download Link http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0#filelist
  7. Den MPS Report läßt Du auf den anderen Knoten ebenfalls laufen

  Das gezippte Report Verzeichnis, und die Reports brauche ich dann ... ich frage mich gerade wie wir das am einfachsten machen. Hast Du sowas wie ein SkyDrive in Windows Live auf das Du mich berechtigungen könntest um die Sachen runter zu laden?

  ** //

  Viele Grüße, Bernd Pfann [Microsoft]

  ---

  This posting is provided "AS IS" with no warranties, and confers no rights.

  Dienstag, 6. Juli 2010 03:39

  Antworten

  |

  Zitieren

  Moderator
• 

  

  0

  Anmelden

  Hallo,

  Possible Owner sind beide Clusternodes.
  An Netzwerkkarten haben wir (jeweils auf beiden Nodes):

  1 * Dual Port onboard
  1 * Dual Port Karte
  
  Wir haben 1 Port der onboard als Heartbeat verwendet. Den anderen plus einen Port der Karte als Team über das HP Network Configuration Utility definiert. Hierbei ist jeder Port des Teams auf einem anderen Switch. Das Team soll für den öffentlichen Traffic sein.
  Den übrig gebliebenen Port haben wir deaktiviert.
  
  Heute haben wir das Ganze noch einmal versucht. Beim ersten Mal hat es (warum auch immer) geklappt, bei den weiteren Versuchen nicht mehr.
  Ausserdem legt der Cluster sporadisch ein seltsames Verhalten an den Tag. Wenn wir nach der Simulation eines kompletten Team-Ausfalls die Kabel wieder einstecken, sehen wir unter "Netzwerke" das sowohl der öffentliche Adapter vom ersten Node als auch vom zweiten Node Fehler wirft. Die Meldung in der Ereignisanzeige sagt etwas von "partitioniertem Netzwerk". Erst ein Deaktivieren und wieder Aktivieren des Team-Adapters auf dem "ausgefallenen" Node behebt das Problem.
  
  Wir haben jetzt die Reports und den MPS Report nach deiner Anleitung erstellt und bei mir auf das SkyDrive gelegt. Wir müssten nur noch wissen welchem Account wir es freigeben sollen.

  MfG

  Sven 

  Dienstag, 6. Juli 2010 09:44

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hallo Sven

  Wenn es beim ersten mal funktioniert hat und danach nicht mehr dann liegt das am Zähler! Der steht auf "Maximum failures in the specified period:1" und die "Period" selbst ist 6h.

  Das mit dem Netzwerk schaue ich mir an.

  Viele Grüße, Bernd Pfann [Microsoft]

  ---

  This posting is provided "AS IS" with no warranties, and confers no rights.

  • Bearbeitet Bernd PfannMicrosoft employee, Moderator Dienstag, 6. Juli 2010 12:47

  Dienstag, 6. Juli 2010 11:37

  Antworten

  |

  Zitieren

  Moderator
• 

  

  0

  Anmelden

  Hallo,

  die Berechtigungen sind gesetzt. Dateien liegen im Ordner "Cluster" bereit.

  mfg

  Sven

  • Bearbeitet Bernd PfannMicrosoft employee, Moderator Dienstag, 6. Juli 2010 14:21 Mail-Adrsse rausgenommen

  Dienstag, 6. Juli 2010 12:36

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hi Bernd, Hi Sven,

  das mit dem ersten erfolgreichen Failover hatte ich wohl überlesen, somit ist das Thema "possible owners" nicht valide. Da der Bernd bereits dieses Problem analysiert, will ich mich hier erstmal "gemütlich" zurücklehnen :-) ....

  trotzdessen würden mich aber auch die Cluster Logs + MPS reports hierzu interessieren. Könntest du mir diese ebenfalls zur Verfügung stellen?

  Danke und Gruß

  Ramazan

  Dienstag, 6. Juli 2010 18:24

  Antworten

  |

  Zitieren

  Moderator
• 

  

  0

  Anmelden

  Hallo Sven

  Das der Failover nicht geklappt hat liegt in der vermuteten Ursache, dass der Failure Count überschritten war:

  Not failing over group GalarTest, failoverCount 5, failover threshold 4294967295

  00000dec.0000037c::2010/07/06-06:25:38.340 INFO [RES] IP Address <IP-Adresse 192.168.8.5>: Online thread running.
  00000dec.0000037c::2010/07/06-06:25:38.344 INFO [RES] IP Address <IP-Adresse 192.168.8.5>: Checking for network match: network masks 00FFFFFF=000000FF and addresses 0508A8C0^0000000A, role 1.
  00000dec.0000037c::2010/07/06-06:25:38.345 INFO [RES] IP Address <IP-Adresse 192.168.8.5>: Checking for network match: network masks 00FFFFFF=00FFFFFF and addresses 0508A8C0^0008A8C0, role 3.
  00000dec.0000037c::2010/07/06-06:25:38.349 INFO [RES] IP Address <IP-Adresse 192.168.8.5>: Online: Registered notification for netinterface 8c929aca-4ebd-4887-a696-7c29fa876ba4.
  00000dec.0000037c::2010/07/06-06:25:38.349 ERR  [RES] IP Address <IP-Adresse 192.168.8.5>: NetInterface 8c929aca-4ebd-4887-a696-7c29fa876ba4 has failed.
  00000dec.0000037c::2010/07/06-06:25:38.349 ERR  [RHS] Online for resource IP-Adresse 192.168.8.5 failed.
  00000694.00000f34::2010/07/06-06:25:38.349 WARN [RCM] HandleMonitorReply: ONLINERESOURCE for 'IP-Adresse 192.168.8.5', gen(14) result 5018.
  00000694.00000f34::2010/07/06-06:25:38.349 INFO [RCM] TransitionToState(IP-Adresse 192.168.8.5) OnlinePending-->ProcessingFailure.
  00000694.00000f34::2010/07/06-06:25:38.349 ERR  [RCM] rcm::RcmResource::HandleFailure: (IP-Adresse 192.168.8.5)
  00000694.00000f34::2010/07/06-06:25:38.349 INFO [RCM] resource IP-Adresse 192.168.8.5: failure count: 4, restartAction: 2.
  00000694.00000f34::2010/07/06-06:25:38.350 INFO [RCM] TransitionToState(IP-Adresse 192.168.8.5) ProcessingFailure-->[WaitingToTerminate to Failed].
  00000694.00000f34::2010/07/06-06:25:38.350 INFO [RCM] TransitionToState(IP-Adresse 192.168.8.5) [WaitingToTerminate to Failed]-->[Terminating to Failed].
  00000694.00000f34::2010/07/06-06:25:38.350 INFO [RCM] Resource IP-Adresse 192.168.8.5 is causing group GalarTest to failover. Posting worker thread.
  00000dec.000013b8::2010/07/06-06:25:38.350 INFO [RES] IP Address <IP-Adresse 192.168.8.5>: Terminating resource...
  00000dec.000013b8::2010/07/06-06:25:38.350 INFO [RES] IP Address <IP-Adresse 192.168.8.5>: Resource is already offline.
  00000694.00000158::2010/07/06-06:25:38.350 INFO [RCM] rcm::RcmGroup::Failover: (GalarTest)
  00000694.00000f34::2010/07/06-06:25:38.350 INFO [RCM] TransitionToState(GalarTest) WaitingToComeOnline-->OfflineDueToProvider.
  00000694.00001074::2010/07/06-06:25:38.350 INFO [RCM] HandleMonitorReply: TERMINATERESOURCE for 'IP-Adresse 192.168.8.5', gen(15) result 0.
  00000694.00001074::2010/07/06-06:25:38.350 INFO [RCM] TransitionToState(IP-Adresse 192.168.8.5) [Terminating to Failed]-->Failed.
  00000694.00001074::2010/07/06-06:25:38.350 INFO [RCM] rcm::RcmGroup::UpdateStateIfChanged: (GalarTest, Pending --> Failed)
  00000694.00000158::2010/07/06-06:25:38.370 WARN [RCM] Not failing over group GalarTest, failoverCount 5, failover threshold 4294967295, nodeAvailCount 1.
  00000694.00000158::2010/07/06-06:25:38.370 INFO [RCM] Will retry online of IP-Adresse 192.168.8.5 in 3600000 milliseconds.
  00000694.00001074::2010/07/06-06:25:38.855 DBG  [NETFTAPI] NsiDeleteInstance für fe80::5efe:192.168.8.2 erhalten.
  00000694.00001074::2010/07/06-06:25:38.856 WARN [NETFTAPI] Fehler beim Abfragen der Parameter für fe80::5efe:192.168.8.2 (Status 80070490)
  00000694.00001074::2010/07/06-06:25:38.856 DBG  [NETFTAPI] NetftLocalAdd -Ereignis für fe80::5efe:192.168.8.2 signalisiert.
  00000694.00001074::2010/07/06-06:25:38.862 WARN [NETFTAPI] Fehler beim Abfragen der Parameter für fe80::5efe:192.168.8.2 (Status 80070490)
  00000694.00001074::2010/07/06-06:25:38.862 DBG  [NETFTAPI] NetftLocalRemove -Ereignis für fe80::5efe:192.168.8.2 signalisiert.
  00000694.000006b0::2010/07/06-06:25:40.972 INFO [IM] Leader got report <class mscs::InterfaceReport>

  Zum 2ten Problem / Phänomen dem Netzwerk nach dem Stecken des Kabels habe ich keine konkreten Anhaltspunkte gefunden. Prüfe hier mal ob über die Cluster.exe ebenfalls eine Meldung bzgl. einer Partitionierung erfolgt:

  Einfach dazu auf einem Knoten: cluster . net  eingeben

  Dann sollte eine Ausgabe in dieser Art erscheinen:

  D:\LOBs\ResourceLoaderx64-00>cluster . net
  Listing status for all available networks:

  Network                                  Status
  ---------------------------------------- -----------
  Cluster Network 2                        Up
  Cluster Network 1                        Up
  
  Vom Prinzip her würde ich sagen, dass der Check der Netzwerke fehl schlägt und deswegen "partitioniert" angezeigt wird. Ich hatte das Problem mal mit geteamten Adaptern. Kannst Du das mal mit dem Heartbeat probieren - der ist ja ungeteamt.

  Viele Grüße, Bernd Pfann [Microsoft]

   

  ---

  This posting is provided "AS IS" with no warranties, and confers no rights.

  • Als Antwort markiert Bernd PfannMicrosoft employee, Moderator Donnerstag, 8. Juli 2010 10:08

  Mittwoch, 7. Juli 2010 10:27

  Antworten

  |

  Zitieren

  Moderator
• 

  

  0

  Anmelden

  Hallo,

  das mit dem Count stimmte. Wir haben ihn mal testweise auf 100 hochgesetzt und schon schwenkte das Ganze munter hin und her.

  Das das Netzwerkproblem an den geteamten Adaptern liegt hatten wir auch schon vermutet. Der Heartbeat-Adapter funktioniert nämlich nach einem Abziehen und Wiederaufstecken des Kabels einwandfrei. Allerdings scheint auch das Problem mit dem "partioniertem Netzwerk" nur immer temporär zu sein. Heute hatten wir diese Meldung zwar wieder einige Male bei den Tests aber nach ca. 10-30 Sekunden werden alle Adapter wieder Aktiv. Ausserdem ist ein Ping auf die Adressen der geteamten Adapter auch während der Fehler-Phase möglich. Er scheint nur ein wenig zu brauchen um alles wieder als aktiv zu erkennen.

  Soweit sieht es also jetzt ganz gut aus.

  Vielen Dank für die super Unterstützung.

  MfG

  Sven

  Mittwoch, 7. Juli 2010 14:33

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hallo Sven

  Bzgl. des Teamings kann durchaus ein "Refresh" Problem im GUI vorliegen. Sobald das Netzwerk wieder aktiv ist führt der Cluster seine Tests durch, parallel baut such das Team wieder zusammen und so kann es durchaus zu einer Überschneidung kommen....

  Falls es wirklich zu Problemen kommen sollte einfach mal bei HP nachfragen und hier nochmals posten....

  Weiterhin viel Erfolg mit dem Cluster!

  Viele Grüße Bernd Pfann [Microsoft]

  ---

  This posting is provided "AS IS" with no warranties, and confers no rights.

  Donnerstag, 8. Juli 2010 10:05

  Antworten

  |

  Zitieren

  Moderator