Priorisierung bei Cluster-Failover

    Hallo all zusammen.


    Ich habe da ein schönes Problem bei einem Cluster-Konzept.
    Vielleicht weiss da ja jemand Rat:


    Ich habe 4 Domino6.5.3 Server. Alle Server befinden sich in einem Cluster und halten alle die selben Mail-Datenbanken von Usern.


    Jetzt befinden sich diese 4 Server aber in 2 Rechenzetren:


    [RZ1]
    DominoRZ1_1 <-LAN-> DominoRZ1_2


    <----WAN---->
    [RZ2]
    DominoRZ2_1 <-LAN-> DominoRZ2_2


    Es gibt User, die vorzugsweise in RZ1 arbeiten (Terminal-Server) und User die vorzugsweise ind RZ2 arbeiten.


    Wenn jetzt der DominoRZ1_1 ausfällt möchte ich gerne verhindern, dass User des RZ1 auf auf RZ2 ausweichen, es sei denn, dass DominoRZ1_2 auch ausfällt.


    Das selbe natürlich für einen Ausfall des DominoRZ2_1.


    Ich möchte quasi den jeweiligen 2er-Servern der RZ's (DominoRZ1_2 und DominoRZ2_2) einen höheren Verfügbarkeitsindex gegenüber denen des anderen RZ's geben.


    Ich habe daran gedacht ein wenig an der NOTES.INI zu schrauben in Sachen Server_TransInfo_Range. Mir ist aber nicht ganz klar in wie fern.


    Vielleicht hat da ja einer von euch eine Anregung für mich!

    Wenn man die Routing-Costs der Verbindungsdokumente unterschiedlich einstuft, also
    RZ1_1 <-> RZ1_2: 1
    RZ2_1 <-> RZ2_2: 1
    RZ2_1 <-> RZ1_1: 4
    sollten bereits die Routing-Tables dafür sorgen, daß die "besser" verfügbaren Server als Failover genommen werden.

    Ist das wirklich so?


    Ich dachte immer, dass die Routing-Kosten der Verbindungsdok. sich nur auf das Mail-Routing, bzw. das Mail-Routing-Failover bei Clustern bezieht.
    Und nicht auf das Failover eines DB-Zugriffs eines Users auf einen Cluster-Partner.


    Wär aber toll wenn das so klappt!


    Hat da jemand eine Bestätigung?

    Also, die Routing-Costs in den Verbinungseinstellungen haben nach meiner Erfahrung KEINEN Einfluß auf die CLusterfailover reigenfolge. Es ist ja auch nicht einmal notwendig, von jedem Server auf jeden anderen Verbindungsdokumente zu haben (hat man in einer typischen Hub/Spoke Topologie sowieso nicht)


    Meines Erachtes ist die Reihenfolge der Server in der lokalen CLUSTER.NCF des CLients hierfür verantwortlich. Das wiederum würde allerdings bedeuten, dass man als Admin so ohne weiteres keinen Einfluss darauf ausüben kann, wohin welcher Clients "failovert".