Exchange 2000 Cluster Networkfailure

1. offizieller Beitrag
    • Offizieller Beitrag

    Hallo Forumfreunde,


    Mir ist folgendes aufgefallen. Wenn ich bei einem Knoten eines Exchange 2000 (sp3, Hotfixrollup März 2003) den Netzwerkstecker ziehe, failt der Virtuellen Exchange Server gegen allen Erwartungen nicht over. Die IP-Address Resource geht auf status "Failed" alle andere Ressource stürzen ein nach 'm Ander ab aber erst nach za. 6-8 Minuten gubt's dann endlich einen Failover. Das Problem tritt reproduzierbar auf mehrere Systeme auf.
    Mach ich dasselbe bei einem nicht-Exchange Cluster (selbst nur bei der Quorumgruppe) dann fail die Gruppe innerhalb einige Sekunden zum anderen Knoten over.
    Ik denke, dieses Verhalten wird irgendwie vom EXRES.DLL hervorgerufen.
    Kennt jemand das Problem bezw. kennt jemand 'ne Lösung?


    Cheers,
    Jack

    • Offizieller Beitrag

    Moin Jack,


    das letzte Exchange 2000 Cluster welches ich unter meinen Fingern hatte war ein zwei Node Cluster mit SP3 und dem post-SP3 rollup aus April 2004. (KB836488)
    Unter diesem Softwarestand hatten wir den von Dir beschriebenen Fehler nicht, da wir ebenfalls auf diese Art einen Failover getestet hatten.
    Solltest Du recht haben und es liegt an der ?exres.dll? würde ich Dir ein post-SP3 rollup empfehlen. Allerdings würde ich direkt auf das von August 2004 einsetzen, da hierbei der Fehler mit den Öffentlichen Ordnern behoben ist. (KB870540)
    Bei allen rollups für Exchange 2003 SP3 im Jahre 2004 wurde immer eine neue Version der ?exres.dll? mit aufgerollt. Vielleicht hilft es ja. :)


    Gruss
    Heinz

    • Offizieller Beitrag

    Hallo Jack,


    Hatte mal ein ähnliches Problem bei einem normalen 2Node Cluster.


    Wie sind denn die beiden (oder mehr) Netzwerkkarten konfiguriert?


    Macht das Primäre LAN (User) auch Clustertransporte?
    Wie ist das Backbone eingestellt?


    Auf welche IP-Adressen sind die Exchange-Dienste gebunden?
    (Alle verfügbaren oder ausgewählt)


    Ich habe zwar keine grossen Erfahrungen mit E2K im Cluster, aber vielleicht hilfts ja trotzdem :D


    mfg aus Bremen


    Norbert
    :-x

    • Offizieller Beitrag

    Hi Norb,


    Danke für die Antwort..
    Alle Netzwerkeinstellungen sind wie von Microsoft empfohlen konfiguriert.... Damit können die Knoten auch über's Public LAN mit einander reden...
    Die Exchange Dienste laufen über die jeweiligen Virtual Server IP Adresse....


    Ich glaube, es muss sich hier um etwas grundsätzliches handeln, da ich auf 2 Cluster das gleiche Effect habe. Allerdings meine ich mich zu errinnern, dass dieses Problem beim Aufsetzen der Cluster (das war in 2003, mit MSX 2000 SP2) währende die Verfügbarkeitstests nicht auftratt..


    Grs.
    Jack

    • Offizieller Beitrag

    Hallo Jack,


    noch´n paar Fragen:


    Gibt es Fehler/Warnungen beim Fail im Ereignisprotokoll?
    Wenn ja, welche?


    Guck dir doch mal die Abhängigkeiten von den Diensten an, alles korrekt?


    Hatte mal Ein Prob mit einem SQL2000 auf einem 2Node Cluster, lag in der verfügbarkeit der IP-Adresse.


    Hat das Install auch dem 2ten Knoten mit installiert?
    Hatte schon Installationen, wo es beim ersten mal nicht so wollte, ein anderes mal musste das Setup auf der zweiten Maschine nochmal angeschubst werden, hat dann den ersten(primären) Knoten gefunden.


    bis denne aus Bremen,


    mfg
    Norbert

    • Offizieller Beitrag

    Hi Nobby,


    Alle Einstellungen sind korrekt normalerweise laufen die beiden Knoten auch zuverlässig.


    Ich habe das Problem im Labor genau nachgestellt. Netzwerkkarte weg -> IP-Ressource failed aber kein Failover...


    Wenn ich das gleiche versuche mit dem Knoten worauf die Quotumgruppe lauft funktioniert alles einwandfrei.
    Ich verstehe nicht warum es nur mit dem Exchange Cluster nicht funktioniert..
    Beim "initiate failure" das gleiche effekt. IP Adresse geht auf failed aber kein Failover. Die andere Ressource gehen nach und nach auf failed und erst nach 5 - 10 Minuten findet das Failover statt..


    Hat jemand vielleicht einen Testcluster wo er das problem nachstellen kann?

    • Offizieller Beitrag

    Hallo Forumfreunde,


    ich habe eine Aussage von Microsoft bekommen: Es handelt sich hier um ein "normales" verhalten von Exchange.


    Microsoft sagt hierzu:


    Aufgrund der darin ersichtlichen Zeisprünge von jeweils ca. 3 Minuten konnte die Problemstellung auf das Verhalten von Echxange zurückgeführt werden.


    Exchange versucht zum Schliessen der Datenbanken etc. den Global Catalog auf dem DC zu Connecten. Da dies aufgrund der Verbindungsunterbrechung des Public LANs jedoch nicht möglich ist, wird hier auf den Timeout gewartet (180 Sekunden).


    Es existierte schon eine frühere Anfrage bei Microsoft. Hierzu die Englische Text:


    Solution: In this scenario, the first cluster resource failing is the IP address. As the network cable is unplugged the resource can not come back online and therefore a failover of the Exchange Virtual Server group is initiated. This means the Exchange resources are taken offline automatically. I n this scenario, where there is no GC/DC access available at all, the Exchange Information Store, Message Transfer Agent and System Attendant processes sequentially try to cleanly get their open threads closed, also the ones handling tasks where GC/DC access was involved. There´s a retry mechanism in place to overcome possible short network glitches. Obviously in this case with an unplugged network cable retries are not of any help. It comes then finally to the resource timeouts which are 3 minutes for the resources in question. This means, in this case a complete failover does require at le ast 10 minutes, but it could be a few minutes more depending on the exact status the cluster and Exchange was at the time the network cable was unplugged. It´s actually nothing wrong here. There are good reasons why it is like that.


    Im Grunde bleibt uns also keine andere Möglichkeit als damit zu leben. 10 Minuten ausfall ist meistens noch vertretbar und, Exchange 2003 scheint sich etwas anders zu verhalten (andere Ressourcenabhängigkeiten) und dadurch etwas schneller zu schalten (3 Minuten).


    Alternativ wäre es möglich Network Teaming einzusetzten, aber damit gab es im Cluster schon öfters Probleme.


    Also,


    case closed.


    Cheers,
    Jack