locked
Nur halbes NLB mit UAG ... RRS feed

  • Frage

  • Hallo zusammen,

    ich habe zwei UAGs (Patch SP1 Update 1 mit TMG SP2) zu einem Array verbunden und NLB für den Portaltrunk aktiviert. In der Konsole sieht auch alles gut aus.

    Folgende NLB-Test habe ich gemacht:

    Client meldet sich am Portal an und landet auf UAG2 ...
    UAG 2 wird runtergefahren ...
    Client bekommt eine neue Anmeldemaske und landet auf UAG1 ...

    So sollte es eigentlich sein. Aber beim Test des umgekehrten Weges passiert folgendes:

    Client meldet sich am Portal an und landet auf UAG1 (Array Manager)
    UAG 1 wird runtergefahren
    Client bekommt Fehlerseite Status 500 Server error ....

    NLB-Mode Unicast und Multicat ... ergebnis ist gleich

    Kennt jemand das Problem ?


    Viele Grüße Carsten

    Dienstag, 27. März 2012 09:44

Antworten

  • Hallo Zusammen,

    nach weiteren Tests würde ich es auch auf ein Timing Problem schieben. Ich habe die Tests mit dem Herunterfahren wiederholt und zwischen den Test ca. eine Stunde gewartet. Egal welches UAG runtergefahren wurde, die Übernahme des anderen UAGs hat immer sauber funktioniert.

    Also meine Empfehlung:

    1. Test Nic deaktivieren

    Hier wird einfach auf dem UAG die externe NIC deaktiviert. Wenn das zweite UAG übernommen hat, kann die NIC wieder aktiviert werden. Danach kann auf dem zweite UAG die NIC deaktiviert werden. Das funktioniert sofort.

    2. Test Runterfahren

    Hier wird UAG1 runter gefahren und UAG 2 übernimmt. Danach wird UAG 1 wieder gestartet. Jetzt sollten man den UAGs zeit lassen ;) Danach kann man UAG 2 runterfahren und UAG1 übernimmt.

    Die Wahrscheinlichkeit, das ein ausgefallenes UAG so schnell wieder verfügbar ist und dafür das zweite Ausfällt dürfte relativ gering sein ;)

    FAZIT:
    Die Redundanz im Echtbetrieb verhält sich genau so wie sie es auch soll !!!


    Viele Grüße Carsten

    • Als Antwort markiert Wolverine74 Dienstag, 10. April 2012 09:10
    Dienstag, 10. April 2012 09:09

Alle Antworten

  • Hi,

    kannst Du den UAG Web Monitor auf UAG1 starten oder kommt da auch ein HTTP 500 Error? Wenn ja, vermute ich ein Problem mit dem IIS


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

    Mittwoch, 28. März 2012 05:02
  • Hi Marc,

    Fehlanzeige .... IIS geht. Ich hab die Test in unterschiedlichen Formen mal durchgespielt. Wenn ich einen Netzwerkausfall simmuliere in dem ich die externe Karte deaktiviere, verhält sich alles so, wie es soll.

    Ich habe es auch nach dem NIC-Test hinbekommen, das UAG1 runterfähret und UAG2 sauber übernimmt. Ich vermute schon fast, das es keinen Fehler gitb sonder der Test selbst der Fehler ist. Evt. darf man nicht einen Server beenden wieder hoch fahren und dan den zweite Server beenden. (auch wenn ich vor dem beenden immer geprüft habe ob alle dienste laufen, die konfigs gesynct sind und im webmonitor der uag-status grün ist). Ich vermute man muss zwischen den neustart mehr Zeit lassen .... Ich lasse das ganze mal im Lab nachstellen. Mal sehen ob wir das Verhalten reprodozieren können.


    Viele Grüße Carsten

    Mittwoch, 28. März 2012 06:26
  • Hi Alex,

    kann man so noch nicht sagen. Also Grundsätzlich funktioniert es. Es scheint ein Problem zu sein, wenn man den Abstand zwischen den Neustarts relativ kurz hat. Ich warte aber noch auf ein Bestätigung vom Hertseller. Wenn die das gleiche ergibt, ist es eigentlich kein Fehler ....

    Sobald ich die Info hab, poste ich sie und markiere die Antwort ;)


    Viele Grüße Carsten

    Mittwoch, 4. April 2012 19:09
  • Hallo Carsten,

    Ich habe die Szenarien in unserem Testlab durchgetestet:

    UAG Array:

                    UAG1 à Master

                    UAG2 à Slave

    Getestete Szenarien:

    1.

    Client-Verbindung auf UAG1 à externes Netzwerkinterface UAG1 disabled à Login Form zu UAG2

    Netzwerkinterface UAG1 enabled

    Client-Verbindung auf UAG2 à externes Netzwerkinterface UAG2 disabled à Login Form zu UAG1

    2.

    Szenario 1 umgekehrt.

    3.

    Client-Verbindung auf UAG1 à shutdown UAG1 à Login Form zu UAG2

    Startup UAG1

    Client-Verbindung auf UAG2 à shtudown UAG2 à Login Form zu UAG1

    4.

    Szenario 3 umgekehrt.

    Leider kann ich das beschriebene Verhalten nicht nachvollziehen.

    Bei meinen Tests hat der andere Knoten immer klaglos übernommen.

    Vielleicht war es wirklich eine Timing Geschichte, dass der frisch gestartete Knoten noch nicht die gesamte Konfig geladen hat.

    lg und ein schönes Osterwochenende,

    Markus


    SecureGUARD GmbH ( http://www.secureguard.at )

    Freitag, 6. April 2012 09:12
  • Hallo Zusammen,

    nach weiteren Tests würde ich es auch auf ein Timing Problem schieben. Ich habe die Tests mit dem Herunterfahren wiederholt und zwischen den Test ca. eine Stunde gewartet. Egal welches UAG runtergefahren wurde, die Übernahme des anderen UAGs hat immer sauber funktioniert.

    Also meine Empfehlung:

    1. Test Nic deaktivieren

    Hier wird einfach auf dem UAG die externe NIC deaktiviert. Wenn das zweite UAG übernommen hat, kann die NIC wieder aktiviert werden. Danach kann auf dem zweite UAG die NIC deaktiviert werden. Das funktioniert sofort.

    2. Test Runterfahren

    Hier wird UAG1 runter gefahren und UAG 2 übernimmt. Danach wird UAG 1 wieder gestartet. Jetzt sollten man den UAGs zeit lassen ;) Danach kann man UAG 2 runterfahren und UAG1 übernimmt.

    Die Wahrscheinlichkeit, das ein ausgefallenes UAG so schnell wieder verfügbar ist und dafür das zweite Ausfällt dürfte relativ gering sein ;)

    FAZIT:
    Die Redundanz im Echtbetrieb verhält sich genau so wie sie es auch soll !!!


    Viele Grüße Carsten

    • Als Antwort markiert Wolverine74 Dienstag, 10. April 2012 09:10
    Dienstag, 10. April 2012 09:09