Zwei Routen zum selben Server - Dynamic IP Frage

Hallo,

ich habe einen Server in einer Location stehen, die relativ schlechte Verbindungen hat und KEINE feste IP.

Nun habe ich ZWEI dynamische Adressen eingerichtet, die beide auf denselben Server zeigen. Einmal via DynDns und einmal über No-IP.

Frage:

Wie kann ich meinen anderen Servern beibiegen, dass sie zuerst die eine und wenn die nicht geht, die andere DNS benutzen sollen.

Ich brauche dazu wohl zwei Connections, nur: wie priorisiere ich die?

Thanx
Jürgen

Ach ja, und für Clients stellt sich diese Frage natürlich auch.

Das Thema ist, dass ich auf diesem server keine Routings habe und das Routing daher disabled ist.

Wirken sich die Routing Costs auch auf die Replikation aus?

Und auch dann, wenn Routing ausgeschaltet ist?

Thx

Erstmal Danke für Deine Hilfe.

Das mit der Zeitlichen Reihenfolge werde ich mal ausprobieren.

Allerdings wird's nicht lange dauern, bis IBM/Lotus ne Version bringt, wo die intern benutzte Ansicht dann nach irgendeinem anderen Wert zuerst sortiert ist, und dann war's das wieder.

We will see.

Ich lasse den Beitrag mal noch offen, vielleicht gibt's ja doch ne andere Lösung?

Zum Thema schleschte Anbindung:

Das Ding steht in Spanien in einem Bereich, den man "vergessenes Land" nennen könnte. (regelmässiger) Stromausfall, bei Regen auch schon 10-20 mal am Tag, über mehrere Minuten ist so ziemlich das kleinste Problem.

Warum weiss ich nicht, aber manchmal sind auch einfach Netzsegmente nicht erreichbar. Es kommt also z.B. vor, dass DynDns einfach nicht erreichbar ist. Punkt.

Deshalb habe ich zwei DynDns Provider benutzt. Damit ist - nach bisheriger Erfahrung - immer wenigstens einer der Einträge aktuell.

Nun muss ich den Server, der dorthin "connected" dazu bringen, beide DNS Einträge auszuprobieren. Klappt der erste - prima. Wenn nicht, soll einfach die zweite IP vom zweiten DNS Provider genommen werden.

Alles ziemlich unverständlich für deutsche Verhältnisse. Aber hier gehen die Uhren eben anders. Strom, Wasser, Internet - nicht immer so verfügbar wie man das annehmen würde. Ich bin schon stolz, ne doppelte ISDN Geschwindigkeit zu haben ("ADSL Rural") - viele Nachbarn haben noch immer Funktelefone (riesen Apparate an der Wand, im Haus dann Kabel) mit Hall ohne Ende. Da geht, was EDV anbetrifft, schlicht nix. Die fahren regelmässig in die nächste Stadt ind Internet-Cafe.

Das einzige was mich daran wirklich stört ist, dass hier EU Gelder ohne Ende vergaben wurden, aber das ist ne andere Sache.

Indes: Mein Problem bleibt.

Na ja: Dass ich auf ein Produkt von einem Ami gesetzt hab, ist natürlich mein Fehler. Die können sowas schon gar nicht nachvollziehen. Obwohl ich kaum ein (zivilisiertes) Land kenne, das mehr Funklöcher und ne beschissenere Handy-Abdeckung hat als die USA.

Was? Achso ja. Die sind ja nicht zivilisiert.

Mein Problem bleibt trotzdem ...

Ja, das stimmt. Ich lasse teilweise auch in diese Richtung replizieren.

Mir dient halt die Replikation aus Deutschland (und von anderswo in der Welt) auch ein Stück weit als "Heartbeat". Findet eine Replikation nicht statt, lasse ich mir einen Fehler schicken und weiss dann, dass da was im Argen liegt. Das kann dann Internet sein, oder auch mal eine abgerauchte Kiste.

In die andere Richtung ist das (glaube ich) schwieriger.

Und eine saubere DynDns brauche ich ohnehin, wegen Remote Admin.

Stimmt, dass ich die Admin Sachen manuell aufrufe.

Aber auch da ist es halt umständlich, die Connection dokumente auf inaktiv bzw aktiv zu setzen, ins besondere wenn man per Passthru arbeitet (weil man das eben eigentlich nicht alle mehrfach pflegen will).

Und mit dem "leichter", eine Panne zu melden habe ich gemeint: Es ist auf dem Server der anruft, leichter einen Event zu definieren (hat nicht geklappt") als einen, der sagt "anderes System hat sich soundsolange nicht gemeldet".

Ich hatte ja auch eigentlich gehofft, dass sowas "triviales" wie zwei oder drei Connection Dokumente zum selben Server abgeblidet sei und ich's einfach nicht weiss ...

Zu meinen "besten" Zeiten (was das Know-How um Notes/Domino) anbetrifft, haben wir mal für die Bank of Boston eine Hochverfügbarkeitslösung gebaut, da war sowas ähnliches vorgesehen. Ich weiss bloss nicht mehr, wie wir das angestellt haben. Dort waren DEC Alpha Server auf Win2000 Ebene gekreuzt UND Notes auf Notes Ebene, sodass ich dann 2x2 Verbindungsmöglichkeiten ergaben.

Mmmmh. Ist zu lange her.

Ciao

Clustering ist der technische Begriff für das, was wir gemacht haben.

Wir hatten aber auch das IP routing ausfallsicher gestaltet und eben genau diese verschiedenen Routen implementiert.

Trivial finde ich das Problem deshalb, weil es vom algorithmus lediglich einer vorgeschalteten Instanz bedarf, die schlicht die verschiedenen Connection Dokumente sequenziell abarbeiten muss. Die vorgefundene Adresse oder DNS-Name kann dann ganz regulär wie heute schon abgearbeitet werden. Ist ein Connection failure entdeckt, geht's zum nächsten Connection Dokument, und aufgegeben wird erst, wenn alle abgearbeitet sind und nirgends ein Connect zustande kommt.

Im Vergleich zu den bereits implementierten NRPC etc. ist das ganz sicher trivial.

Ich frage mich gerade, wie das wohl ist, wenn ein Domino Server mehrere NC's hat. Dann hat er ja auchmehre IP-Adressen, unter denen er erreichbar ist (wenn ich das nicht OS Ebene zum Clustering nutze und keine Partitionned Server fahre [was auch noch ne Variante wäre]).

Irgendwie sagt mir mein Gefühl, dass es möglich sein muss, ein und den selben Server über zwei oder mehrere verschiedene Wege erreichen zu können ...

Ich reserache mal weiter.

Na ja, so ganz überzeugt bin ich noch nicht, was die zusätzliche Hardware angeht.

Wie ich schon geschrieben habe, ist es ja grundsätzlich so, dass Domino alles hat. Er müsste nur mehrere connection documents auswerten, wenn eine Verbindung nicht successful ist.

Im Prinzip so, wie das auch das mailrouting macht mit den "costs" - wenn ich mich recht erinnere probiert Domino da ja alle durch, bis die mail übertragen ist.

Wenn man z.B. beim "replicate" einfach satt dem Servernamen auch ein Connection Dokument angeben könnte, wär's schon erledigt, denn dann könnte das per Macro erledigt werden.

Und mit zusätzlicher Hardware oder Software, hmmm. Die müsste dann ja auch mit Domino kommunizieren, denn auf der (falschen) IP, die ein DYNDNS Provider zurück schickt hängt ja potenziell ein PC, nur eben wahrscheinlich kein Domino Server und schon gar nicht der erwartete.

Erst dieser Connect liefert ja das Ergebnis, dass nun die nächste DYNDNS adresse zu probieren ist.