Domino 9 und frühere Versionen > ND9: Administration & Userprobleme
Cluster von 4 Domino Mail-Servern mit Mailfailover
HeLotes:
Hallo,
ich möchte ein Cluster einrichten mit 4 Domino Mail-Servern und Mailfailover.
Alle Server sind in unterschiedlichen notes named networks und in unterschiedlichen Ländern die miteinander über VPN Tunnel verbunden sind.
Die Server sollten weiterhin in unterschiedlichen notes named networks bleiben, da ich das Mailrouting über Verbindungsdokumente steuern muss.
Server_DE Notes Network DETCP
Server_FR Notes Network FRTCP
Server_UK Notes Network UKTCP
Server_CH Notes Network CHTCP
Der Hauptserver ist Server_DE, welcher alle 500 Maildatenbanken als Replik aller anderen Standorte auch lokal hat.
Server_FR mit 200 lokalen Maildatenbanken, Server_UK mit 200 Maildatenbanke und Server_CH mit 100 Maildatenbanken.
Dieser Server_DE soll einspringen wenn irgend ein Server bzw. auch die Internetleitung in einem anderen Standort ausfällt.
D.h. Server_DE sollte dann die eingehenden Mails empfangen.
Mir geht es hier nur um Mailfailover. Kein Cluster von Anwendungen oder HTTP Task.
Jetzt funktioniert aber ein Cluster und Mailfailover nur wenn alle beteiligten Server im selben notes named network sind.
Was kann ich hier machen, dass das trotzdem funktioniert?
Meine Idee war nun auf Server_DE folgende Notes Network Ports einzurichten.
Port Protocol Notes Network Net Address Enabled
TCPIP TCP DETCP 162.1.1.1 Enabled
TCPIP TCP FRTCP 162.1.1.2 Enabled
TCPIP TCP UKTCP 162.1.1.3 Enabled
TCPIP TCP CHTCP 162.1.1.4 Enabled
Vermutlich brauche ich dann 4 Netzwerkkarten in Server_DE?
Dann sind zwar nicht alle Clustermember im gleichen notes named network, aber jeder Clustermember hat einen anderen Clustermember im gleichen notes named network.
Ist so eine Konfiguration mögich und funktioniert das auch?
Gruß, Helmut
CarstenH:
--- Zitat ---Die Server sollten weiterhin in unterschiedlichen notes named networks bleiben, da ich das Mailrouting über Verbindungsdokumente steuern muss.
--- Ende Zitat ---
Das widerspricht der folgenden Konfiguration:
--- Zitat ---jeder Clustermember hat einen anderen Clustermember im gleichen notes named network
--- Ende Zitat ---
Sobald Server über NNNs eine Verbindung zum Ziel finden sind Mailrouting-Verbindungsdokumente unzulässig/unsupported.
Die Server (bzw. der Router) ist dabei clever genug seine Routingtabellen entsprechend umzubauen sobald er über die NNN zum Ziel findet, egal ob es jetzt eins zum Clustern oder mehrere NNNs sind.
Aber: sobald man trotzdem Verbindungsdokumente einrichtet werden diese tatsächlich auch benutzt. Allerdings dann auch für die Verbindungsaufnahme zum Mailfailover - kann ich aus (leidvoller) Erfahrung bestätigen. Die Fehlersuche hat mich mal einige Stunden gekostet. Allerdings würde ich mich dennoch nicht drauf verlassen, wie gesagt handelt es sich hier um eine unzulässige Konfiguration und niemand weiß ob sich das System in allen (evtl. kommenden) Versionen immer noch so verhält.
Und: durch die Cluster würden auch Clients, die ihren Server nicht finden, versuchen über das WAN auf den Cluster zuzugreifen (was man natürlich unterbinden kann, sorgt aber potentiell für Sanduhren und Fehlermeldungen beim Nutzer).
--- Zitat ---brauche ich dann 4 Netzwerkkarten in Server_DE?
--- Ende Zitat ---
Nein, man kann mehrere IP's an eine Karte binden. Mehrere Karten machen nur dann Sinn wenn der zu erwartende Traffic die Leitung auch ausnutzt - was bei WAN-Verbindungen eher nicht zu erwarten ist.
Carsten
Ralf_B:
Hallo Helmut,
wenn es nur um Mailrouting failover geht und nicht um ein DB failover....
Und die Server sind nicht im selben NNN....
Dann solltest Du das ohne Cluster über die Routingkosten in den Verbindungsdokumenten doch hinbekommen.
Die Routongtabelle nimmt immer den günstigsten Weg.
Wenn der Server nicht erreichbar ist wird der teurere genommen.
Ich hoffe das hilft Dir weiter.
Oder habe ich das falsch verstanden?
Gruss
Ralf
ronka:
Ich frage mal anders herum...
Was möchtest du erreichen ?
a) das die NOTES Clients ihren ausgehenden email IMMER an einen der 4 Mailserver abgeben können ?
b) das EINGEHENDEN (also externe) emails immer angenommen werden ?
Für a) Brauchst du "nur" ein Cluster, in welches die Clients über ihren Cluster.ncf den erreichbarkeit der einzelne Server dokumentieren.
Für b) brauchst du MX Records in den DNS systemen, und hat NICHTS mit Cluster oder mit Domino zu tun. Allerdings muss dann jeder Domino Server sich für ALLE Domains zuständig fühlen (Global Domain Dokument Alias namen).
Bei a) hast du dann aber das problem das wenn Server X nicht erreicht werden kann, weil der WAN Leitung down ist, das die Clients von dort ebenso nicht zu den (andere) Server kommen, wenn alle in einem Standort sind.
Bei b) müssen alle server quasi wissen wo die Emails abgeliefert werden sollten (information befindet sich im Personen dokument), und wenn Server X down oder nicht erreichbar ist, wird es SO LANGE über ALLE andere servern versucht zu zu stellen bis 48 Stunden vorbei sind, und erst DANN geht das email zurück zum Absender als nicht zustellbar. Das wird unter umständen also vor dessen auslieferung schon mit einen Maximum HUB Count als solches gekennzeichnet.
Beispiel Server A, B und C können einander sehen und haben alle ein verbindungsdokument zu X, A versucht es so lange bis die kosten über B geringer sind. Dann geht das email von A nach B und versucht B server X zu erreichen. Da das WAN zu X weg ist, wird der es genau so wenig schaffen. Entweder geht das email danach zurück nach A oder über C nochmal das gleiche. Und das bis 25 mal Server gewechselt würde-
Dieses letzte ist was CarstenH meint mit schwer diagnostisierbar. Ich habe das in der vergangenheit schon MEHRFACH lösen müssen, und das Kostet VIEL Zeit und unter umständen gehen emails dabei verloren (kommen NICHT an beim Empfänger - und geben ein schlechts bild der Organisation des Empfängers ab).
Weitere nachteile die in diesen Situation aufkommen ist das ein Cluster einen PUSH replication betreibt, und alle Änderungen an gemeinsamen Datenbanken an alle andere Cluster partner (versucht) zu schicken. Wenn also einen WAN leitung einen beschränkte kapazität HATTE, dann wird der durch ein solche schritt weiter eingeschränkt.
Dazu wenn der Cluster Push technologie nicht ankommt (weil WAN weg) dann bleibt dieses aktiv und wird weiterhin gefüllt mit Push werten. Bis zum speicher voll, und damit zur lasten des Performance des Lokalen Servers.
Diesen Push funktion ersetzt NICHT den normale Replicator, und muss unbedingt getrennt zusätzlich mittels verbindungsdokument gemacht werden.
HeLotes:
--- Zitat von: ronka am 03.10.18 - 00:39:50 ---Ich frage mal anders herum...
Was möchtest du erreichen ?
In rot meine Antworten
Wenn der Mailhomeserver nicht erreichbar ist, dann sollte ein Clustermitglied die Mails in dessen lokale Maildatenbanken der User zustellen.
a) das die NOTES Clients ihren ausgehenden email IMMER an einen der 4 Mailserver abgeben können ?
b) das EINGEHENDEN (also externe) emails immer angenommen werden ?
Für a) Brauchst du "nur" ein Cluster, in welches die Clients über ihren Cluster.ncf den erreichbarkeit der einzelne Server dokumentieren.
Für b) brauchst du MX Records in den DNS systemen, und hat NICHTS mit Cluster oder mit Domino zu tun. Allerdings muss dann jeder Domino Server sich für ALLE Domains zuständig fühlen (Global Domain Dokument Alias namen).
Bei a) hast du dann aber das problem das wenn Server X nicht erreicht werden kann, weil der WAN Leitung down ist, das die Clients von dort ebenso nicht zu den (andere) Server kommen, wenn alle in einem Standort sind.
Unsere Mailserver halten die Mails aber nicht 48 Stunden zurück, sondern es kommt schon nach ein paar Minuten ein Maximum Hub Count Meldung.
Das sollte doch über Configuration Document und Transfer Controls einstellbar sein.
Maximum hop count = 25
Initial transfer retry interval = 10 Minuten
Das sollten doch die Einstellungen dazu sein, oder?
Bei b) müssen alle server quasi wissen wo die Emails abgeliefert werden sollten (information befindet sich im Personen dokument), und wenn Server X down oder nicht erreichbar ist, wird es SO LANGE über ALLE andere servern versucht zu zu stellen bis 48 Stunden vorbei sind, und erst DANN geht das email zurück zum Absender als nicht zustellbar. Das wird unter umständen also vor dessen auslieferung schon mit einen Maximum HUB Count als solches gekennzeichnet.
Beispiel Server A, B und C können einander sehen und haben alle ein verbindungsdokument zu X, A versucht es so lange bis die kosten über B geringer sind. Dann geht das email von A nach B und versucht B server X zu erreichen. Da das WAN zu X weg ist, wird der es genau so wenig schaffen. Entweder geht das email danach zurück nach A oder über C nochmal das gleiche. Und das bis 25 mal Server gewechselt würde-
Dieses letzte ist was CarstenH meint mit schwer diagnostisierbar. Ich habe das in der vergangenheit schon MEHRFACH lösen müssen, und das Kostet VIEL Zeit und unter umständen gehen emails dabei verloren (kommen NICHT an beim Empfänger - und geben ein schlechts bild der Organisation des Empfängers ab).
Weitere nachteile die in diesen Situation aufkommen ist das ein Cluster einen PUSH replication betreibt, und alle Änderungen an gemeinsamen Datenbanken an alle andere Cluster partner (versucht) zu schicken. Wenn also einen WAN leitung einen beschränkte kapazität HATTE, dann wird der durch ein solche schritt weiter eingeschränkt.
Dazu wenn der Cluster Push technologie nicht ankommt (weil WAN weg) dann bleibt dieses aktiv und wird weiterhin gefüllt mit Push werten. Bis zum speicher voll, und damit zur lasten des Performance des Lokalen Servers.
Diesen Push funktion ersetzt NICHT den normale Replicator, und muss unbedingt getrennt zusätzlich mittels verbindungsdokument gemacht werden.
--- Ende Zitat ---
Navigation
[0] Themen-Index
[#] Nächste Seite
Zur normalen Ansicht wechseln