Dann hast du etwas falsch gemacht. Nativ laufender MTA kann sich auf eine IP oder eine virtuelle NIC binden (eth0.1) - mit Containern muss dann das NAT richtig eingestellt werden, ggf. muss eine andere Routingtabelle eingesetzt werden.
Diese Antwort ist korrekt. Man muß unter Docker wirklich mit NAT arbeiten. War mir zu blöd, das zu dokumentieren - nutze nun das primäre interface.
Irgendwo war jemand über das Standardgateway der Failover IP verwirrt.
Wenn man über die IP Adresse in's Internet möchte, muss man natürlich auch das Standardgateway von dem des primären Interfaces auf das der Failover Adresse umstellen, und das im SCP neben der Failover Adresse genannte Gateway nutzen.
Das hat überhaupt nicht geklappt. Danach ging gar nix mehr.
Jetzt, mit dem Standardgateway und der failover einfach als zusätzliche IP (ohne das gateway zu ändern) scheint es zu funktionieren (rein wie raus)
Hay,
Jetzt, mit dem Standardgateway und der failover einfach als zusätzliche IP (ohne das gateway zu ändern) scheint es zu funktionieren (rein wie raus)
ja jetzt. Sobald das Routing über die normale IP kaputt geht, geht es nicht mehr. Dass es bei Dir nicht funktioniert hat, liegt daran, dass Dein eingehender Traffic über die normale IP hineinkam und dann zum neuen Standardgateway der Failover herausgeschickt wurde -> K@O5.
Ein paar kleine Regeln:
1) Ein System soll (= fast so stark wie "darf") nur EIN Standardgateway haben, weil über dieses Interace jeder Traffic geschickt wird, der nicht zum eigenen Netzwerk (also IP & Netmask) gehört.
2) Für die Failover-IP sollte man ein weiteres eigenes Netzwerkinterface hinzufügen, nicht als zusätzliche IP auf das normale Interface
3) Im Failoverfall muss man das Standardgateway von dem normalen Interface wegnehmen und das Gateway der Failover-IP wird das neue Standardgatewy
Korrektur: Achso - fast vergessen. Man müss natürlich dafür sorgen, dass dann der eingehende Traffic dann natürlich über die Failover läuft, d.h. DNS muss richtig eingestellt sein und die Dienste müssen auf der Failover aktiv werden. Die Failover-IP wird dann gewissermaßen zum "Bypass" und die eigentlich normale IP wird nicht mehr benutzt, sondern der Server darf grundsätzlich nur auf der Failover laufen. Der Server, an den übergeben werden soll, natürlich auch.
Ist nicht so einfach zu schreiben... hoffentlich es wird verstanden...
CU, Peter
Bei statischer Konfiguration ist dem standardmäßig keine Route außerhalb des eigenen Subnetzes bekannt, oder meinst du etwas anderes?
Naja das Standardgateway sollte auch bei statischer Config für die primäre IP gesetzt werden.
Die zustätzliche IP kann dann als eth0.1 konfiguriert werden - da braucht man dann kein zweites Gateway eingegen. IPv4 Forward muss dann natürlich angeschaltet sein.
3) Im Failoverfall muss man das Standardgateway von dem normalen Interface wegnehmen und das Gateway der Failover-IP wird das neue Standardgatewy
Bis dahin: ja. Aber bei Punkt 3 bekomme ich gerade Falten im Gesicht.
Das ist für mich nicht schlüssig.
Leider habe ich viel zu wenig Ahnung davon, um das sauber zu konfigurieren.
Ich hatte bisher immer nur einzelne, voneinander unabhängig Server mit Standard-Netzwerkkonfiguration. In das Thema musste ich mich also nie einarbeiten.
Hay,
Bis dahin: ja. Aber bei Punkt 3 bekomme ich gerade Falten im Gesicht.
Das ist für mich nicht schlüssig.
habs ja auch schon korrigiert direkt nach dem Abschicken, während Du Deine Falten bekommen hast 
CU, Peter
Hay,
um dem eins draufzusetzen... (jedenfalls habe ich so gearbeitet bei HA-Plattformen, die ich betreut habe, ist allerdings auch schon 20 Jahre her)
Normalerweise richtet man dann noch ein zusätzliches VPN nur zwischen den Servern ein, über welches das Umswitchen koordiniert wird, sowie für den Synch untereinander... Failover im aktiven Betrieb ohne nennenswerte Auswirkungen ist eine Dr*cksau. Vor allem müssten theoretisch alle Anwendungen dann noch stateless laufen können, d.h. nichts mit "PHP Sessions".
CU, Peter
Wenn ich das alles so lesen, dann werde ich das auf meinen Produktivsystemen sicher nicht implementieren.
Da erscheint es mich sicherer, es so zu lassen, wie ich es bisher handhabe;
Ich krieg ne eMail, wenn der Hauptserver down ist und stelle dann einfach schnell A und AAAA in der DNS um. (Dann klappt es auch mit ipv6 
)
(Meine TTLs sind eh entsprechend kurz und ein bissel downtime müssen die Nutzer halt aushalten 
)
EDIT:
Hmmm... Gibt es nicht auch eine API für DNS hier?
Hay,
Hmmm... Gibt es nicht auch eine API für DNS hier?
ja gibt es. Hat mir sehr geholfen, als ich 100 Domains von einem auf den anderen Server umgezogen habe - alle IPs (auch in SPF usw) in einem Rutsch auf die neue IP umgestellt...
CU, Peter
Wäre es dann nicht viel einfacher (wenn auch nicht schneller) bei einem Ausfall einfach die DNS-Records per Script umzustellen?
Hätte da jemand evtl. mal ein paar Beispielskripte?
Hay,
Wäre es dann nicht viel einfacher (wenn auch nicht schneller) bei einem Ausfall einfach die DNS-Records per Script umzustellen?
einfacher ja - die Zeiten der "weltweiten" Umstellung sind aber nicht zuverlässig vorhersagbar, auch wenn Deine TTL niedrig eingestellt ist, gibt es immer mal ein paar T-Online DNS Server, die sich weigern und stur auf ihr Caching beharren (schon mehrmals erlebt).
(Weil die memories von damals™ gerade wieder hochkommen, wie wir das aufgebaut haben: Wir hatten vorne dran noch zwei Alteon Loadbalancer, der die failover-IP aufgefangen haben*), erst dann ging es auf den Cluster dahinter, auf dem die Dienste liefen - wenn also ein Server mit einem Dienst wegbrach, hat der vom Loadbalancer einfach keinen Traffic mehr bekommen - der dann natürlich in einem eigenen Netz geroutet wurde, da waren keine öffentlichen IPs mehr im Spiel)
(Erg. 2: Da bin ich mir jetzt nicht sicher, aber die Loadbalancer waren jeweils an andere Prover angeschlossen, die Failover war provider independent und irgendwas schaltete das Routing mit BGP um... die passende Gehirnwindung dazu finde ich aber wirklich nicht mehr)
CU, Peter
Erscheint mir aber - für mich persönlich - immer noch besser als die beiden Alternativen (Entweder gar kein Failover oder ein echtes Failover, das aufgrund meiner mangelnden Kompetenz in Netzwerkdingen schon ohne Ausfall unzuverlässig arbeitet 
)
Außerdem bräuchte ich dann ja eigentlich noch ein ipv6-Failoversubnetz.
Ist mir alles zu viel des Guten. (Da passt die Aufwand/Nutzen-Relation für mich nicht mehr)
Ich hab das ganze Thema Failover IP über Keepalived abgehandelt, was sich um die Verwaltung kümmert und einfach still und leise auf dem System einfach läuft. Das schiebt dann per Bash Skript die Failover IPs zwischen den Nodes.
Die Idee mit DNS Records hin und her schieben scheitert halt an der von CmdrXay genannten Problematik. Das kannst du umgehen indem du bspw einen lokalen Resolver betreibst wie Unbound und dort als Upstream für deine Domäne deine Nameserver angibst.
Außerdem bräuchte ich dann ja eigentlich noch ein ipv6-Failoversubnetz.
Nicht unbedingt. Du kannst auch einfach für deine Seiten nur den A Record anlegen und dann das mit IPv6 sparen. Die Server selbst kannst natürlich trotzdem über IPv6 erreichen.
Services -> A Record Failover IP
Nodes -> A/ AAAA Record auf die jeweilige Server IP
Naja das Standardgateway sollte auch bei statischer Config für die primäre IP gesetzt werden.
Die zustätzliche IP kann dann als eth0.1 konfiguriert werden - da braucht man dann kein zweites Gateway eingegen. IPv4 Forward muss dann natürlich angeschaltet sein.
Achso, ich meinte nicht, dass ein zweites Gateway eingerichtet werden soll - sondern dass man es ggf. mit dem der zweiten Adresse ersetzen muss (sofern die zweite Adresse nicht über den selben Router geroutet ist), wenn man über sein eth0.1 mit ausgehender Adresse in das Internet fahren möchte.
Hallo,
bei meinem MQTT Server klappt das mit der Failover IP super.
Ich schwenke die halt händisch, weil das nicht so kritisch ist.
Dennoch kein Problem der ist sofort auf dem neuen Server zu erreichen.
Mail ist halt immer etwas komplizierter.
Gruß Eckhard
So hielt mich mein Kollege immer, wenn ich ankam: "Kann ich dich für diesen wundervollen 10 Mbit Ethernet Hub begeistern? Sogar mit Blinklämpchen und Netzgerät!"
Genau so einer hängt jetzt als staubiges Relay im Wachtelstall und verrichtet geräuschlos seine Arbeit. Die guten alten 12V Netzteile sind meistens auch um einiges besser was heute so produziert wird und wenn es wirklich total unbrauchbar wird, zerlege ich das Zeug und gebe es entweder beim Recycler oder Recyclinghof ab.
Hat Dein Kollege den Hub noch?
P.S.
Wer es nicht glaubt warum man sowas Wertstoffe nennt ... hier mal ein Beleg aus 2014:
2014-10-31_Recycling_Abgabe.jpg
Hay,
Die guten alten 12V Netzteile sind meistens auch um einiges besser
Schon wieder getriggert... ich habe jedes Steckernetzteil aufgehoben (5V bis 32V)... zwei große Kisten voll Steckernetzeile... nächste Wegwerfrunde incoming... das Image vrom Ersatzteilmessie muss ich doch noch irgendwie wegbekommen...
But something magical happened...
CU, Peter
hab mir direkt das neue 22.04 installiert. läuft gut! wird in 2-3 wochen auf allen produktionsservern zum einsatz kommen
hab mir direkt das neue 22.04 installiert. läuft gut! wird in 2-3 wochen auf allen produktionsservern zum einsatz kommen
Aber: Nächtliches Update nicht vergessen…
Welcome to the support channel for pre-release versions of Ubuntu. Beware these are unstable and will probably break your computer | Current dev version: Jammy Jellyfish (22.04) | Schedule: https://ubottu.com/y/jj | Testing: http://iso.qa.ubuntu.com/qatracker (Downloading often? See https://ubottu.com/y/zsync) | For support of released versions, see #ubuntu
[21.04.22 18:00:04] <ueberall> !isitout
[21.04.22 18:00:04] <ubottu> Nooope! Ubuntu 22.04 LTS is not released yet, but you are welcome to anticipate it in #ubuntu-release-party