Nameserver, Redundanz und Caching

[Philipp Hasenfratz]

Halihallo Forumer

Es liegen mir noch einige Fragen bezüglich DNS-Konfiguration und -
eigenschaften auf der Zunge, welche ich gerne an euch gerichtet
hätte:

MX MailExchanger:
Um die Redundanz in Sache E-Mails zu verbessern, kann man für eine
Domain zwei oder mehr MX-Records erstellen, die auf unterschiedliche
Rechner leiten. Falls einer davon ausfällt, wird der Nächste (nach
Priorität) verwendet.

- was passiert eigentlich, wenn der Rechner mitten im Empfang
     einer E-Mail abstürtzt? - Bemerkt dies der entfernte SMTP-
     Server über z.B. Timeout (oder Socketabbruch) und sendet die E-
     Mail erneut an den zweiten/dritten Mail-Server? (rein
     interessenshalber)

ISP-Nameserver caching:
Wenn man einen eigenen Nameserver betreibt, kann man über den SOA-
Record die Refresh Zeit (bzw. die Expiry-Time) so einstellen, dass
die Änderung der NS-Konfiguration (fast) sofort aktiv wird. Nur
werden die NS-Daten von z.B. ISP-Nameservern aus Gründen der
Performance gecached. Die Verfallszeiten dieser
zwischengespeicherten NS-Daten sind natürlich von NS zu NS
unterschiedlich, aber was sind hier typische Werte? Gehört habe ich
von:

- nach ca. 1 Stunde sollten alle NS die aktuellen Daten haben.
   - Cacheverfallszeit wird von SOA-Record der Domain übernommen.

Primary-Nameserver, Secundary-Nameserver:
Ich versuche mal ganz am Anfang zu beginnen: Zu einer Domain gehören
(ein,) zwei oder mehr zuständige Nameserver. Diese sind in der Lage
die Hosts einer Domain einer oder mehreren IP's zuzuordnen.
Normalerweise gibt es pro Domain zwei Nameserver. Als Backup und
weitere Redundanz gibt es Secundary-Nameserver-Anbieter, welche den
dritten/vierten/... Nameserver zur Verfügung stellen. Diese
Secundary-Nameserver holen sich die Daten vom Primären-Nameserver
(Zonenwechsel?). Frage: Kann man auch drei/vier unterschiedlich
gehostete *Primäre*-Nameserver einer Domain zuordnen? - Das hatte
ich einmal versucht, aber dann war stets der alte Nameserver aktiv
und der Neue wollte einfach nicht zum Zuge kommen, obwohl ich bei
switch.ch die Reihenfolge entsprechend gesetzt habe (ist das nur bei
Switch so, oder gibt es hier ein allgemeines Problem, welches zu
beachten ist?).

Was bedeuten die „IN NS“-Records? – Festlegung der NS für einen
Host? – Denn die NS-Einträge für eine Domain liegen ja beim
Registrar und nicht auf dem eigenen NS, was soll also die NS-
Definition im NS?

Wie würdet Ihr vorgehen, wenn ein System mehrfach redundant ausgelegt
werden soll (ungeachtet der Datensynchronisation)? - Mehrere Server,
die auf denselben Hostnamen (virtual host) hören und falls einer
abrauscht, einfach die IP im NS geändert wird (so, dass sie auf einen
Rechner zeigt, der eben nicht offline ist). Das Problem sehe ich hier
schlicht in der Synchronisationszeit der NS-Server (insbesondere
die cachenden nichtautoritiven Nameserver zwischen Client und meinem
Nameserver).

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo Philipp!

Zu den Nameserver-Sachen kann ich nicht wirklich viel sagen, aber vielleicht zu der Hochverfügbarkeits-Geschichte:

Wie würdet Ihr vorgehen, wenn ein System mehrfach redundant ausgelegt
werden soll (ungeachtet der Datensynchronisation)? - Mehrere Server,
die auf denselben Hostnamen (virtual host) hören und falls einer
abrauscht, einfach die IP im NS geändert wird (so, dass sie auf einen
Rechner zeigt, der eben nicht offline ist). Das Problem sehe ich hier
schlicht in der Synchronisationszeit der NS-Server (insbesondere
die cachenden nichtautoritiven Nameserver zwischen Client und meinem
Nameserver).

Es gibt sicher viele Wege dies zu realisieren, die beiden Ansätze die mir am besten gefallen sind die folgenden:

1. Du kaufst Dir einen schönen teuren Loadbalancer (z.B. bei Deinem netten Cisco-Händler von nebenan ;-)), hinter dem dann X identische Server (Slaves) stehen. Allerdings musst Du dann dafür Sorge tragen, dass auf den einzelnen Servern kein "Zustand" zwischen den Requests behalten wird, denn es ist nicht gesagt dass der nächste Request auf demselben Slave landet (ich weiß dass manche Loadbalancer das sicherstellen können, es macht die ganze Geschichte allerdings deutlich unflexibler). Das heißt, so Sachen wie Datenbank, Sessions oder lokale Dateien müssen ausgelagert werden. Dann kann ruhig mal ein Server ausfallen, ohne dass man das von außen mitbekommt. Der Loadbalancer hat halt die einzige nach außen öffentliche IP, über den dann alle Requests laufen, die dann nach einem bestimmten Verfahren auf die Slaves verteilt werden.

2. Du hast 2 Server, von denen aber nur einer die tatsächliche Arbeit macht (Master) und der andere (Slave) diesen produktiven Server per Heartbeat überwacht. Sobald der Slave feststellt, dass der Master nicht mehr arbeitet, nimmt er per ARP dessen IP an, so dass neue Requests vom Switch auf den Slave geleitet werden, und dieser somit in kürzester Zeit zum Master wird. Das geht sehr schnell, und dauert nicht Stunden wie beim DNS, da es ja nur an dem Switch umgestellt werden muss, mit dem die beiden Server verbunden sind. Natürlich müssen die Daten auf beiden Maschinen synchronisiert sein. Allerdings ist sowas bei mietbaren Root-Servern normalerweise nicht möglich, da die Übernahme einer fremden IP aus Sicherheitsgründen zu einer automatischen Sperrung des entsprechenden Rechners führt. Das heißt man braucht in dem Netzwerk schon entsprechende Einflussmöglichkeiten.

Die 2. Methode eignet sich sehr gut, um z.B. im 1. Szenario einen dedizierten Datenbank-Server gegen Ausfall abzusichern. Sollte der Master-DB Server mal ausfallen, übernimmt der Slave-DB Server (auf den natürlich ständig die Daten gespiegelt wurden) die IP und Aufgabe des Masters. Natürlich kann man auch hier einen Load-Balancer einsetzen, allerdings nicht so effektiv, da vor allem Schreibzugriffe transaktionssicher synchronisiert werden müssen, aber man könnte z.B. Schreib-Zugriffe von Lese-Zugriffen trennen, und somit die Heartbeat-Methode nur für den einen Master-Server für Schreibzugriffe verwenden, und eine Farm von Slaves per Load-Balancer für Lese-Zugriffe zur Verfügung stellen, oder sogar auf jedem Web-Slave einen DB-Server für Lese-Zugriff installieren. Oder man verwendet entsprechende DB-Cluster aus dem Hause Oracle, IBM & Co. Es gibt zwar auch inzwischen Cluster-Lösungen für MySQL, allerdings habe ich davon noch nicht allzuviel gutes gehört ;-) Cluster haben aber immer den Nachteil, dass Schreibzugriffe ständig im gesamten Cluster synchronisiert werden müssen, was einen nicht zu unterschätzenden Overhead mit sich bringt. Allerdings muss man hier auch unterscheiden zwischen Ausfallsicherheit und Performance.

Es gibt viele größere PHP-Anwendungen die auf diese Weise funktionieren, teilweise mit >100 Slaves...

Siehe z.B. auch http://shiflett.org/archive/46 und http://talks.php.net/show/lt2004-lamp

Viele Grüße
Andreas

[Reiner]

Hallo Andreas,

1. Du kaufst Dir einen schönen teuren Loadbalancer (z.B. bei Deinem netten Cisco-Händler von nebenan ;-)), hinter dem dann X identische Server (Slaves) stehen. Allerdings musst Du dann dafür Sorge tragen, dass auf den einzelnen Servern kein "Zustand" zwischen den Requests behalten wird, denn es ist nicht gesagt dass der nächste Request auf demselben Slave landet (ich weiß dass manche Loadbalancer das sicherstellen können, es macht die ganze Geschichte allerdings deutlich unflexibler). Das heißt, so Sachen wie Datenbank, Sessions oder lokale Dateien müssen ausgelagert werden. Dann kann ruhig mal ein Server ausfallen, ohne dass man das von außen mitbekommt. Der Loadbalancer hat halt die einzige nach außen öffentliche IP, über den dann alle Requests laufen, die dann nach einem bestimmten Verfahren auf die Slaves verteilt werden.

das scheint mir nicht (unbedingt) notwendig.
Ich beschäftige mich gerade mit dem Thema und bin auf was sehr interessantes gestoßen, was ich gerade mit zwei MySQL über Replikation teste.
Das Teil, was ich meine nennt sich PEN - habe den Link jetzt gerade nicht, such mal mit Google "PEN Loadbalancer Linux" oder so.
Ist ca. 100kByte groß und funktioniert großartig.
Es macht den Krempel nach dem RoundRobin-Verfahren. Das Teil kostet NICHTS (GPL) und funktioniert einfach!
Gestoßen bin ich darauf mehr durch Zufall. In der neuen Linux-Magazin stand ein Artikel über Cluster mit MySql. Das interessiert mich gerade brennend. Aber leider ist das, was da angeboten wird, nicht wirklich bezahlbar (für mich). Die schon in MySQL eingebaute Clusterlösung braucht mehr Speicher (RAM-Lösung) als mancher Mensch an Festplattenplatz hat. Die andere Lösung ist nicht gerade preiswert (2TEuro pro CPU).

Ich tüftel gerade an einer Replikation. Habe mich damit 2 Tage beschäftigt: große Klasse.
Man muß nur beachten, daß ein Master zum schreiben sein soll, die Slaves sollten zum lesen gewählt werden.
Da kam PEN gerade recht. Es beherrscht alle Protokolle mit TCP, also auch den Datentranport der MySQL-Daten.
Wenn der Master jetzt ausfällt, kann man zwar nichts mehr eintragen, aber noch lesen.

Wie der Testaufbau hier aussieht, darf man gar keinem erzählen... haha
Mein Arbeitsrechner ist der Master, auf dem Boden liegt ein olles 800 MHz Laptop, daß über WLan als Slave fungiert.
Naja, ich glaube IBM und Mikrosoft sind in der Garage entstanden, oder? Meine ist hier
Wenn Du willst, kannste darauf gerne mal testen.

Die 2. Methode eignet sich sehr gut, um z.B. im 1. Szenario einen dedizierten Datenbank-Server gegen Ausfall abzusichern. Sollte der Master-DB Server mal ausfallen, übernimmt der Slave-DB Server (auf den natürlich ständig die Daten gespiegelt wurden) die IP und Aufgabe des Masters. Natürlich kann man auch hier einen Load-Balancer einsetzen, allerdings nicht so effektiv, da vor allem Schreibzugriffe transaktionssicher synchronisiert werden müssen, aber man könnte z.B. Schreib-Zugriffe von Lese-Zugriffen trennen, und somit die Heartbeat-Methode nur für den einen Master-Server für Schreibzugriffe verwenden, und eine Farm von Slaves per Load-Balancer für Lese-Zugriffe zur Verfügung stellen, oder sogar auf jedem Web-Slave einen DB-Server für Lese-Zugriff installieren. Oder man verwendet entsprechende DB-Cluster aus dem Hause Oracle, IBM & Co. Es gibt zwar auch inzwischen Cluster-Lösungen für MySQL, allerdings habe ich davon noch nicht allzuviel gutes gehört ;-)[...]

Grunz...das habe ich erst jetzt gelesen.
Aber ich kann das mit meinem Tüftelaufbau bestätigen.
Funktioniert Klasse. Wenn man also ein paar alte Rechner rumstehen hat, bekommt man sicherlich ein kleines Rechenzentrum zusammen. Das Problem ist nur, falls das online auch funktionieren soll, irgendwann die DSL-Leitung.

Gruß
Reiner

[Andreas Korthaus]

Hallo Reiner!

1. Du kaufst Dir einen schönen teuren Loadbalancer [...]

das scheint mir nicht (unbedingt) notwendig.
Ich beschäftige mich gerade mit dem Thema und bin auf was sehr interessantes gestoßen, was ich gerade mit zwei MySQL über Replikation teste.
Das Teil, was ich meine nennt sich PEN - habe den Link jetzt gerade nicht, such mal mit Google "PEN Loadbalancer Linux" oder so.
Ist ca. 100kByte groß und funktioniert großartig.
Es macht den Krempel nach dem RoundRobin-Verfahren. Das Teil kostet NICHTS (GPL) und funktioniert einfach!

Ja klar, ist ne schöne Software. Man muss sich halt fragen was man erreichen will. Ich persönlich mag allerdings nicht den Gedanken einfache x86 Hardware als Loadbalancer einzusetzen, da ein Loadbalancer normalerweise einen "Single Point of Failure" (SPF) darstellt, und entsprechend ausfallsicher oder besser redundant ausgelegt sein sollte. Wie gesagt ist ein Hardware-Loadbalancer allerdings ein teurer Spaß und man muss sehen ob man das braucht. Wenn es nur um Lastverteilung geht, hilft vielleicht schon ein einfaches DNS Round-Robin Verfahren. Das sollte in gewissem Maße auch gegen Ausfallsicherheit helfen, man könnte ja wenn ein Server ausfällt, dessen IP vorübergehend von einem anderen System übernehmen lassen (wenn entsprechend ausgelegt), und gleichzeitig die IP aus dem DNS nehmen.
Auf der anderen Seite - solange der "PEN-Server" nicht ausfällt ist das natürlich ne feine Sache.

Womit ich zur Zeit teste ist lighttpd, der gleichzeitig als Webserver und Loadbalancer für FastCGI-Prozesse (stinknormale PHP-Scripte) fungiert, die auf eigenen, dedizierten Servern laufen (Kommunikation per FastCGI-Protokoll über TCP/IP).

Ich tüftel gerade an einer Replikation. Habe mich damit 2 Tage beschäftigt: große Klasse.

Ja, Master->Slave Replikation ist ne recht effiziente Sache, erhöht die Ausfallsicherheit und Performance deutlich was lesende Zugriffe angeht, der Master-Server wird allerdings zum SPF und kann auch nicht unendlich mitwachsen...

Da kam PEN gerade recht. Es beherrscht alle Protokolle mit TCP, also auch den Datentranport der MySQL-Daten.

Wozu benutzt Du denn PEN jetzt konkret?

Wenn der Master jetzt ausfällt, kann man zwar nichts mehr eintragen, aber noch lesen.

Dafür brauchst Du einen "Backup-Master" der ggfs. automatisiert einspringt ;-)

Naja, ich glaube IBM und Mikrosoft sind in der Garage entstanden, oder?

Ja, aber damals probierte auch noch nicht jeder 2. Garagenbesitzer ein 2. IBM-Imperium aufzuziehen... ;-)

Meine ist hier
Wenn Du willst, kannste darauf gerne mal testen.

Was kann ich da denn testen?

Grüße
Andreas

[Reiner]

Hi,

1. Du kaufst Dir einen schönen teuren Loadbalancer [...]

das scheint mir nicht (unbedingt) notwendig.
Ich beschäftige mich gerade mit dem Thema und bin auf was sehr interessantes gestoßen, was ich gerade mit zwei MySQL über Replikation teste.
Das Teil, was ich meine nennt sich PEN - habe den Link jetzt gerade nicht, such mal mit Google "PEN Loadbalancer Linux" oder so.
Ist ca. 100kByte groß und funktioniert großartig.
Es macht den Krempel nach dem RoundRobin-Verfahren. Das Teil kostet NICHTS (GPL) und funktioniert einfach!

Ja klar, ist ne schöne Software. Man muss sich halt fragen was man erreichen will. Ich persönlich mag allerdings nicht den Gedanken einfache x86 Hardware als Loadbalancer einzusetzen, da ein Loadbalancer normalerweise einen "Single Point of Failure" (SPF) darstellt, und entsprechend ausfallsicher oder besser redundant ausgelegt sein sollte. Wie gesagt ist ein Hardware-Loadbalancer allerdings ein teurer Spaß und man muss sehen ob man das braucht. Wenn es nur um Lastverteilung geht, hilft vielleicht schon ein einfaches DNS Round-Robin Verfahren. Das sollte in gewissem Maße auch gegen Ausfallsicherheit helfen, man könnte ja wenn ein Server ausfällt, dessen IP vorübergehend von einem anderen System übernehmen lassen (wenn entsprechend ausgelegt), und gleichzeitig die IP aus dem DNS nehmen.
Auf der anderen Seite - solange der "PEN-Server" nicht ausfällt ist das natürlich ne feine Sache.

»»

zwei Pen Server fallen vielleicht noch weniger aus:
http://siag.nu/pen/vrrpd-linux.shtml :-))

Womit ich zur Zeit teste ist lighttpd, der gleichzeitig als Webserver und Loadbalancer für FastCGI-Prozesse (stinknormale PHP-Scripte) fungiert, die auf eigenen, dedizierten Servern laufen (Kommunikation per FastCGI-Protokoll über TCP/IP).

Naja, FastCGI ist sicherlich gegenüber "normalen" CGI nicht immer so "fast"! Besonders bei großen Scripten macht es oft kaum Sinn.

Ich tüftel gerade an einer Replikation. Habe mich damit 2 Tage beschäftigt: große Klasse.

Ja, Master->Slave Replikation ist ne recht effiziente Sache, erhöht die Ausfallsicherheit und Performance deutlich was lesende Zugriffe angeht, der Master-Server wird allerdings zum SPF und kann auch nicht unendlich mitwachsen...

Der muß halt anders ausgelegt sein, möglichst auch kaum lesend beackert werden. In meinem Fall auch "ok", wenn er ausfällt. Das Suchformular funktioniert dennoch.

Da kam PEN gerade recht. Es beherrscht alle Protokolle mit TCP, also auch den Datentranport der MySQL-Daten.
Wozu benutzt Du denn PEN jetzt konkret?

Im Moment ist auf meinem Arbeitsrechner der Webserver. Die Scripte unterscheiden, ob Sie schreibend (Zugriff auf Master) oder lesend (Zugriff auf "Cluster") arbeiten. Im PEN-Verbund sind die beiden MySQL-Server.

Genauer:

I) Arbeitsrechner=Webserver=DB-Master=Loadbalancer(PEN)
II) Laptop=DB-Slave

Wenn der Master jetzt ausfällt, kann man zwar nichts mehr eintragen, aber noch lesen.
Dafür brauchst Du einen "Backup-Master" der ggfs. automatisiert einspringt ;-)

Nee, für diesen ersten Schritt noch nicht. Aber man kann auch mit einem Trick so eine Art Master-Master-Replikation machen. Dabei sind einige Dinge zu beachten, geht aber!

Meine ist hier
Wenn Du willst, kannste darauf gerne mal testen.
Was kann ich da denn testen?

Entweder testen, ob das Suchfeld (links in Navigation) wirklich schnell Ergebnisse bringt. Das Problem ist, daß Du das alleine gar nicht testen kannst. Es müßten mehrere unterschiedliche Clients sein, die automatisch auf die beiden Rechner verteilt werden. Das Ergebnis kannst Du aber wiederum auch gar nicht beurteilen, aber ich, indem ich in die PEN-Logs reinschaue.

Oder einfach anmelden ("bestellen").
Du bekommst einen Account (per Mail) zugewiesen. Wie man das Suchformular benutzt, steht auf der Seite "Beispiele".
Wichtig sind zwei Dinge:

• ID auf den Dir zugemailten Wert setzen (Server-ID). Der Wert 17 ist nur ein Beispiel.
• Das Formular statt auf www.w3sitesearch.de... auf http://netp.ath.cx.... abschießen! Das ist eben mein Entwicklungssystem. Wenn Du das nicht machst, bekommst Du aber wahrscheinlich eine Fehlermeldung, weil die Server-ID auf dem anderen System unbekannt ist.

Gruß
Reiner

[Andreas Korthaus]

Hallo!

Womit ich zur Zeit teste ist lighttpd, der gleichzeitig als Webserver und Loadbalancer für FastCGI-Prozesse (stinknormale PHP-Scripte) fungiert, die auf eigenen, dedizierten Servern laufen (Kommunikation per FastCGI-Protokoll über TCP/IP).

Naja, FastCGI ist sicherlich gegenüber "normalen" CGI nicht immer so "fast"! Besonders bei großen Scripten macht es oft kaum Sinn.

Hm? Bei CGI wird bei jedem Request der Interpreter neu gestartet... , bei FastCGI läuft der Interpreter ständig. Das bringt ne ganze Menge!

Siehe Vergleich zu Apache + mod_php: http://www.incremental.de/talks/phpconf-2003-tuning/image.25.html

Da kam PEN gerade recht. Es beherrscht alle Protokolle mit TCP, also auch den Datentranport der MySQL-Daten.
Wozu benutzt Du denn PEN jetzt konkret?

Im Moment ist auf meinem Arbeitsrechner der Webserver. Die Scripte unterscheiden, ob Sie schreibend (Zugriff auf Master) oder lesend (Zugriff auf "Cluster") arbeiten. Im PEN-Verbund sind die beiden MySQL-Server.

Genauer:

I) Arbeitsrechner=Webserver=DB-Master=Loadbalancer(PEN)
II) Laptop=DB-Slave

Hm, aber welche Aufgabe hat denn jetzt der Loadbalancer? Wozwischen soll der denn "balancen"? Für MySQL-Lesezugriffe, auf I und II? Oder nur für einen Slave? Ist vielleicht schon etwas spät für mich... ;-)

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

1. Du kaufst Dir einen schönen teuren Loadbalancer (z.B. bei Deinem netten Cisco-Händler von nebenan ;-)), hinter dem dann X identische Server (Slaves) stehen. Allerdings musst Du dann dafür Sorge tragen, dass auf den einzelnen Servern kein "Zustand" zwischen den Requests behalten wird, denn es ist nicht gesagt dass der nächste Request auf demselben Slave landet (ich weiß dass manche Loadbalancer das sicherstellen können, es macht die ganze Geschichte allerdings deutlich unflexibler). Das heißt, so Sachen wie Datenbank, Sessions oder lokale Dateien müssen ausgelagert werden. Dann kann ruhig mal ein Server ausfallen, ohne dass man das von außen mitbekommt. Der Loadbalancer hat halt die einzige nach außen öffentliche IP, über den dann alle Requests laufen, die dann nach einem bestimmten Verfahren auf die Slaves verteilt werden.

Das hatte ich schon seit jeher als langfristige Möglichkeit in
Betracht gezogen. Im Moment ist ein Loadbalancer jedoch nicht
aktuell. Für mich steht jedoch fest, dass dies die beste,
skalierbarste und variabelste Lösung wäre.

2. Du hast 2 Server, von denen aber nur einer die tatsächliche Arbeit macht (Master) und der andere (Slave) diesen produktiven Server per Heartbeat überwacht. Sobald der Slave feststellt, dass der Master nicht mehr arbeitet, nimmt er per ARP dessen IP an, so dass neue Requests vom Switch auf den Slave geleitet werden, und dieser somit in kürzester Zeit zum Master wird.

Das wäre also von der Vorgehensweise genau dasselbe wie eine NS-
Änderung aufgrund Failover-Erkennung (sobald ein Server ausfällt,
wird die IP zur Domain auf den Slave geändert). Nur, dass deine
Lösung natürlich nahezu Realtime ist (was natürlich sehr schön ist).

Allerdings ist sowas bei mietbaren Root-Servern normalerweise nicht möglich, da die Übernahme einer fremden IP aus Sicherheitsgründen zu einer automatischen Sperrung des entsprechenden Rechners führt. Das heißt man braucht in dem Netzwerk schon entsprechende Einflussmöglichkeiten.

Genau hier ist mein Problem, ansonsten würde ich nicht mit NS-
Konfigurationen rumbasteln :-)

Die 2. Methode eignet sich sehr gut, um z.B. im 1. Szenario einen dedizierten Datenbank-Server gegen Ausfall abzusichern. Sollte der Master-DB Server mal ausfallen, übernimmt der Slave-DB Server (auf den natürlich ständig die Daten gespiegelt wurden) die IP und Aufgabe des Masters. Natürlich kann man auch hier einen Load-Balancer einsetzen, allerdings nicht so effektiv, da vor allem Schreibzugriffe transaktionssicher synchronisiert werden müssen, aber man könnte z.B. Schreib-Zugriffe von Lese-Zugriffen trennen, und somit die Heartbeat-Methode nur für den einen Master-Server für Schreibzugriffe verwenden, und eine Farm von Slaves per Load-Balancer für Lese-Zugriffe zur Verfügung stellen, oder sogar auf jedem Web-Slave einen DB-Server für Lese-Zugriff installieren. Oder man verwendet entsprechende DB-Cluster aus dem Hause Oracle, IBM & Co. Es gibt zwar auch inzwischen Cluster-Lösungen für MySQL, allerdings habe ich davon noch nicht allzuviel gutes gehört ;-) Cluster haben aber immer den Nachteil, dass Schreibzugriffe ständig im gesamten Cluster synchronisiert werden müssen, was einen nicht zu unterschätzenden Overhead mit sich bringt. Allerdings muss man hier auch unterscheiden zwischen Ausfallsicherheit und Performance.

Gute Überlegungen. Ich hatte jedoch nicht im Sinne ein
hochverfügbares, verteiltes Informationssystem aufzubauen, sondern
einfach Ausfälle und Nichtverfügbarkeit der Server (falls dann mal
ein Server abrauscht) auf ein verträgliches Minimum zu reduzieren :-)
Also die Ausfälle zu reduzieren ist schwierig, denn Technik und
Hardware bleiben Technik und Hardware, aber durch Redundanzen (und
sei es nur eine zweifache) können Ausfallszeiten überbrückt werden.

Nur um mein Ziel noch etwas konkreter zu formulieren:
Es geht nicht darum gar keine Ausfallszeiten zu haben, sondern bei
einem Rechnerausfall, dessen Behebung mehrere Stunden oder Tage
in Anspruch nehmen kann, auf ein Zweit- oder Dritt-System welchseln
zu können. Für mich ist eine Unerreichbarkeit des Servers von 1
Stunde innerhalb akzeptabler Parameter. Über Änderung der NS-
Konfiguration liesse sich dies hoffentlich sicherstellen. Mehr dazu
kommt bestimmt noch in der Antwort zu Sven.

Viele Grüsse und Danke!

Philipp

[Andreas Korthaus]

Hi Philipp!

Das hatte ich schon seit jeher als langfristige Möglichkeit in
Betracht gezogen. Im Moment ist ein Loadbalancer jedoch nicht
aktuell. Für mich steht jedoch fest, dass dies die beste,
skalierbarste und variabelste Lösung wäre.

Vor allem auch sehr ausfallsicher, gibts auch redundant...

[Heartbeat...]

Das wäre also von der Vorgehensweise genau dasselbe wie eine NS-
Änderung aufgrund Failover-Erkennung (sobald ein Server ausfällt,
wird die IP zur Domain auf den Slave geändert). Nur, dass deine
Lösung natürlich nahezu Realtime ist (was natürlich sehr schön ist).

Ja, ist zudem sehr verbreitet und funktioniert vollkommen automatisiert.

Das heißt man braucht in dem Netzwerk schon entsprechende Einflussmöglichkeiten.

Genau hier ist mein Problem, ansonsten würde ich nicht mit NS-
Konfigurationen rumbasteln :-)

Das dumme bei DNS ist halt, dass Du keinen Einfluss auf den vom Client verwendeten DNS-Server hast. Du hast halt eine große Bandbreite, beim einen geht es in wenigen Minuten, beim nächsten erst in zig Stunden...

Es geht nicht darum gar keine Ausfallszeiten zu haben, sondern bei
einem Rechnerausfall, dessen Behebung mehrere Stunden oder Tage
in Anspruch nehmen kann, auf ein Zweit- oder Dritt-System welchseln
zu können. Für mich ist eine Unerreichbarkeit des Servers von 1
Stunde innerhalb akzeptabler Parameter.

Das kann Dir bei Abhhängigkeit vom DNS aber niemand garantieren!

Über Änderung der NS-
Konfiguration liesse sich dies hoffentlich sicherstellen.

In meinen Augen lässte es sich nur "empfehlen", aber mangels Einfluss eben nicht "garantieren".

Wenn ich das richtig verstehe geht es Dir nur um einen einzelnen Server, ja? In meinen Augen wäre es das beste sich einen Provider zu suchen, der das erlaubt was Du konkret benötigst, um unabhängig vom DNS eine IP auf einen anderen Server zu "schieben". Wie gesagt ist das bei Co-Location oft möglich (Server leasen ist gar nicht so viel teuerer als mieten - bis auf die Vertragslaufzeit...), aber auch für Mietserver ist sowas bei machen flexibleren Providern möglich. Es wird in jedem Fall teurer sein als Billigst-Mietserver, aber ich denke es sollte überschaubar bleiben. Du wärst die DNS-Probleme los und könntest in wenigen Sekunden umschalten, sogar automatisiert. So würde sich die Downtime jedenfalls drastisch reduzieren.

Ein Load-Balancer würde natürlich auch gegen das DNS-Problem helfen, da Du ja hinter dem Load-Balancere machen kannst was Du willst - da hast Du volle Kontrolle.

Sachen wie PEN bringen Dir in diesem Fall IMO nichts, weil Du so den SPF nur vom einen auf ein zusätzliches System verschiebst, und am Ende dasselbe Problem hast, nur noch einen zusätzlichen Server brauchst (Redundanz des x86 Loadbalancers). Dazu kommt dass Du das eigentliche System ja auch noch redundant auslegen musst um einen Ausfall zu  überbrücken (das ist ja der eigentliche Sinn der Sache gewesen...), wären dann also schon 2 Systeme extra ;-) Gut, man kann natürlich auch nur ein System als Standby-System verwenden, welches dann entweder bei Deinem Server, oder beim Load-Balancer einspringt, wenns Probleme gibt.

Mit nem Hardware-Loadbalancer (kannst Du bei einigen Provider übrigens auch mieten) bräuchtest Du dann eben noch die 2 Systeme dahinter (entweder können die parallel laufen, oder eben bei Ausfall System1 durch System2 ersetzen).

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

[Heartbeat...]
Das wäre also von der Vorgehensweise genau dasselbe wie eine NS-
Änderung aufgrund Failover-Erkennung (sobald ein Server ausfällt,
wird die IP zur Domain auf den Slave geändert). Nur, dass deine
Lösung natürlich nahezu Realtime ist (was natürlich sehr schön ist).
Ja, ist zudem sehr verbreitet und funktioniert vollkommen automatisiert.

Wie du meiner Antwort zu Sven entnehmen kannst, tendiere ich zu
einer Lösung wie du sie vorschlägst.

Es geht nicht darum gar keine Ausfallszeiten zu haben, sondern bei
einem Rechnerausfall, dessen Behebung mehrere Stunden oder Tage
in Anspruch nehmen kann, auf ein Zweit- oder Dritt-System welchseln
zu können. Für mich ist eine Unerreichbarkeit des Servers von 1
Stunde innerhalb akzeptabler Parameter.
Das kann Dir bei Abhhängigkeit vom DNS aber niemand garantieren!

Richtig :-(

Über Änderung der NS-
Konfiguration liesse sich dies hoffentlich sicherstellen.
In meinen Augen lässte es sich nur "empfehlen", aber mangels Einfluss eben nicht "garantieren".

Wenn ich das richtig verstehe geht es Dir nur um einen einzelnen Server, ja? In meinen Augen wäre es das beste sich einen Provider zu suchen, der das erlaubt was Du konkret benötigst, um unabhängig vom DNS eine IP auf einen anderen Server zu "schieben". Wie gesagt ist das bei Co-Location oft möglich (Server leasen ist gar nicht so viel teuerer als mieten - bis auf die Vertragslaufzeit...), aber auch für Mietserver ist sowas bei machen flexibleren Providern möglich. Es wird in jedem Fall teurer sein als Billigst-Mietserver, aber ich denke es sollte überschaubar bleiben. Du wärst die DNS-Probleme los und könntest in wenigen Sekunden umschalten, sogar automatisiert. So würde sich die Downtime jedenfalls drastisch reduzieren.

Eine Frage: Wenn die zwei Server auf getrennten Netzwerken geschaltet
sind, funktioniert ARP nicht mehr, oder? - Es wäre für mich eben
zudem ein Wunsch, dass die Server in verschiedenen Serverzentren
gehostet sind.
Kennst du derartige Anbieter? - Falls dir ohne zu suchen gerade einer
einfällt, wäre das für mich sehr hilfreich.

Ein Load-Balancer würde natürlich auch gegen das DNS-Problem helfen, da Du ja hinter dem Load-Balancere machen kannst was Du willst - da hast Du volle Kontrolle.

Richtig, das lohnt sich dann, wenn der Traffic entsprechend
steigt und die Performance auch eine Rolle spielt. Ohne diese
Prämissen haben für mich zwei oder mehr Server mit "ARP-Redundanz"
genau die gleiche Wirkung zu niedrigeren Kosten, oder habe ich hier
etwas nicht beachtet?

Sachen wie PEN bringen Dir in diesem Fall IMO nichts, weil Du so den SPF nur vom einen auf ein zusätzliches System verschiebst, und am Ende dasselbe Problem hast, nur noch einen zusätzlichen Server brauchst (Redundanz des x86 Loadbalancers). Dazu kommt dass Du das eigentliche System ja auch noch redundant auslegen musst um einen Ausfall zu  überbrücken (das ist ja der eigentliche Sinn der Sache gewesen...), wären dann also schon 2 Systeme extra ;-)

ACK.

Viele Grüsse und Danke

Philipp

[Andreas Korthaus]

Hallo Philipp!

Eine Frage: Wenn die zwei Server auf getrennten Netzwerken geschaltet
sind, funktioniert ARP nicht mehr, oder?

Nein. Das ARP-Protokoll funktioniert nur im LAN, es wird nicht geroutet. Es ist möglich dass es theoretisch geht (Proxy ARP oder sowas), aber vermutlich nicht sonderlich praktikabel. Vor allem stellt das noch erheblich höhere Anforderungen an die Infrastruktur der beteiligten Provider, da sie dann ja auch in ein fremdes Netz routen müssten, und das auf Deinen spontanen Wunsch hin...

• Es wäre für mich eben
  zudem ein Wunsch, dass die Server in verschiedenen Serverzentren
  gehostet sind.

Warum? Wegen der besseren Ausfallsicherheit? Wie soll das gehen? Das wäre entweder per DNS möglich, oder per Loadbalancer. Ersteres hat die Nachteile wie bereits diskutiert, letzteres hat den Nachteil dass wenn zufällig das LAN mit dem Loadbalancer ausfällt, dass es Dir dann nichts bringt einen Server in einem anderen Rechenzentrum stehen zu haben - den kennt ja niemand direkt.
Ich würde erstmal mit einem Anbieter in einem LAN anfangen ;-)

Kennst du derartige Anbieter? - Falls dir ohne zu suchen gerade einer
einfällt, wäre das für mich sehr hilfreich.

Einige Sachen kannst Du bei Hosteurope oder dem SELFHTML-Hosting-Sponsor Verio machen, mit anderen habe ich keine Erfahrung. Wie gesagt, bei Co-Location werden die Anbieter meist flexibler. Bei Hosteurope kannst Du z.B. auch einen eigenen managed Switch mieten, auch zusammen mit Miet-Servern oder Co-Location. Aber wie gesagt - ganz billig ist der Spaß nicht ;-)

[Load-Balancer]
Richtig, das lohnt sich dann, wenn der Traffic entsprechend
steigt und die Performance auch eine Rolle spielt. Ohne diese
Prämissen haben für mich zwei oder mehr Server mit "ARP-Redundanz"
genau die gleiche Wirkung zu niedrigeren Kosten, oder habe ich hier
etwas nicht beachtet?

Doch, so würde ich es auch sehen.

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

• Es wäre für mich eben
  zudem ein Wunsch, dass die Server in verschiedenen Serverzentren
  gehostet sind.
  Warum? Wegen der besseren Ausfallsicherheit? Wie soll das gehen? Das wäre entweder per DNS möglich, oder per Loadbalancer. Ersteres hat die Nachteile wie bereits diskutiert, letzteres hat den Nachteil dass wenn zufällig das LAN mit dem Loadbalancer ausfällt, dass es Dir dann nichts bringt einen Server in einem anderen Rechenzentrum stehen zu haben - den kennt ja niemand direkt.
  Ich würde erstmal mit einem Anbieter in einem LAN anfangen ;-)

Versteh mich nicht falsch. Mir geht es nur mal darum alle
Möglichkeiten in Betracht zu ziehen. Ich falle nie mit der Tür ins
Haus :-)

Kennst du derartige Anbieter? - Falls dir ohne zu suchen gerade einer
einfällt, wäre das für mich sehr hilfreich.
Einige Sachen kannst Du bei Hosteurope oder dem SELFHTML-Hosting-Sponsor Verio machen, mit anderen habe ich keine Erfahrung. Wie gesagt, bei Co-Location werden die Anbieter meist flexibler. Bei Hosteurope kannst Du z.B. auch einen eigenen managed Switch mieten, auch zusammen mit Miet-Servern oder Co-Location. Aber wie gesagt - ganz billig ist der Spaß nicht ;-)

Danke für die Tipps.

[Load-Balancer]
Richtig, das lohnt sich dann, wenn der Traffic entsprechend
steigt und die Performance auch eine Rolle spielt. Ohne diese
Prämissen haben für mich zwei oder mehr Server mit "ARP-Redundanz"
genau die gleiche Wirkung zu niedrigeren Kosten, oder habe ich hier
etwas nicht beachtet?
Doch, so würde ich es auch sehen.

Das klingt doch schon wie eine gute Leistung zu vergleichsweise
kleinem Preis.

Viele Grüsse

Philipp

[Sven Rautenberg]

Moin!

MX MailExchanger:
Um die Redundanz in Sache E-Mails zu verbessern, kann man für eine
Domain zwei oder mehr MX-Records erstellen, die auf unterschiedliche
Rechner leiten. Falls einer davon ausfällt, wird der Nächste (nach
Priorität) verwendet.

Es ist hierbei allerdings extrem wichtig, dass sämtliche beteiligten Mailserver vernünftig konfiguriert sind. Am allerwichtigsten: Alle müssen wissen, für welche Mailaccounts sie Mails annehmen (und später dann an den Hauptserver weiterleiten) dürfen, und welche Mailadressen ungültig sind. Server, die sämtliche Mails akzeptieren und erst beim endgültigen Auslieferungsversuch an den primären Mailserver feststellen, dass die Adressen ungültig ist, sind gezwungen, eine Unzustellbarkeitsnachricht an den angeblichen Sender zurückzuschicken. Solche Nachrichten braucht aber kein Mensch.

- was passiert eigentlich, wenn der Rechner mitten im Empfang
     einer E-Mail abstürtzt? - Bemerkt dies der entfernte SMTP-
     Server über z.B. Timeout (oder Socketabbruch) und sendet die E-
     Mail erneut an den zweiten/dritten Mail-Server? (rein
     interessenshalber)

Ein guter Mailserver macht sowas. Erst wenn der empfangende Mailserver die Bestätigung zurückgeliefert hat, dass alle Daten korrekt empfangen wurden, sollte die Mail aus der Warteschlange entfernt werden.

Die Verfallszeiten dieser
zwischengespeicherten NS-Daten sind natürlich von NS zu NS
unterschiedlich, aber was sind hier typische Werte?

Zum Beispiel:
@ IN SOA ns1.first-ns.de. postmaster.robot.first-ns.de. (
 2000091604   ; Serial
 14400        ; Refresh
 1800         ; Retry
 604800       ; Expire
 86400  )     ; Minimum

Ansonsten orientieren sich die Werte einfach an den Erfordernissen.

- nach ca. 1 Stunde sollten alle NS die aktuellen Daten haben.
   - Cacheverfallszeit wird von SOA-Record der Domain übernommen.

Die Nameserver haben sich mit der Verfallszeit eigentlich nach der SOA-Angabe zu richten. Aber natürlich kann man sich im privaten Bereich selbst was schnitzen - nur beim Anbieten öffentlicher Nameserver macht sich das nicht unbedingt so gut.

Frage: Kann man auch drei/vier unterschiedlich
gehostete *Primäre*-Nameserver einer Domain zuordnen?

Was die Beantwortung von DNS-Anfragen aus dem Internet angeht, gibt es nur Nameserver ohne Unterschied. Jeder macht dasselbe.

Die Unterscheidung nach erster/zweiter/dritter ist eine rein zählende.

Aber "hinter den Kulissen" gibts natürlich schon Unterschiede. Der primäre Nameserver kriegt normalerweise als einziger manuell die Änderungen konfiguriert, alle sekundären Nameserver erhalten die Veränderungen dann vom primären Nameserver. Dazu gibts im DNS-Protokoll (genauer beim Zonentransfer) die Möglichkeit, alle sekundären Nameserver aktiv von der Änderung zu unterrichten - ansonsten fragen die mit Ablauf der Gültigkeitszeit beim primären Nameserver einfach die Zone neu ab.

Dieses DNS-Protokoll ist aber nicht unbedingt optimal für die Aufgabe. Die Transfermenge wird nicht komprimiert, etc. Deshalb ist es auch problemlos möglich, einfach die Zonenkonfigurationsdatei z.B. per rsync zwischen den Nameservern auszutauschen und dann im Prinzip zwei primäre Nameserver zu betreiben.

Das hatte
ich einmal versucht, aber dann war stets der alte Nameserver aktiv
und der Neue wollte einfach nicht zum Zuge kommen, obwohl ich bei
switch.ch die Reihenfolge entsprechend gesetzt habe

Definiere "zum Zuge kommen"? Wie hast du das festgestellt? Wenn mehr als ein Nameserver definiert ist, wird beim Auflösen eines Namens ein beliebiger Nameserver benutzt - die müssen ja alle gleichwertige, authoritative Informationen über die Zone ausliefern, also muß es egal sein, wen man fragt.

Was bedeuten die „IN NS“-Records? – Festlegung der NS für einen
Host? – Denn die NS-Einträge für eine Domain liegen ja beim
Registrar und nicht auf dem eigenen NS, was soll also die NS-
Definition im NS?

Das ist das sogenannte "glue". Indem man der Zone mitgibt, welche Nameserver für die Zone zuständig sind, kann bei DNS-Anfragen nach der Zone diese Information ebenfalls mitgegeben werden. Damit werden Deadlocks (um die IP vom Nameserver rauszufinden, muß ich die IP vom Nameserver rausfinden...) und unnötige zusätzliche DNS-Anfragen verhindert.

Das Problem sehe ich hier
schlicht in der Synchronisationszeit der NS-Server

Dieses Problem ist per DNS nicht lösbar.

- Sven Rautenberg

[Philipp Hasenfratz]

Halihallo Sven

MX MailExchanger:
Um die Redundanz in Sache E-Mails zu verbessern, kann man für eine
Domain zwei oder mehr MX-Records erstellen, die auf unterschiedliche
Rechner leiten. Falls einer davon ausfällt, wird der Nächste (nach
Priorität) verwendet.

Es ist hierbei allerdings extrem wichtig, dass sämtliche beteiligten Mailserver vernünftig konfiguriert sind. Am allerwichtigsten: Alle müssen wissen, für welche Mailaccounts sie Mails annehmen (und später dann an den Hauptserver weiterleiten) dürfen, und welche Mailadressen ungültig sind. Server, die sämtliche Mails akzeptieren und erst beim endgültigen Auslieferungsversuch an den primären Mailserver feststellen, dass die Adressen ungültig ist, sind gezwungen, eine Unzustellbarkeitsnachricht an den angeblichen Sender zurückzuschicken. Solche Nachrichten braucht aber kein Mensch.

Danke für den Hinweis. Eventuell mache ich nichteinmal eine
Weiterleitung an den Hauptserver, sondern rufe die Mails einfach von
jedem Mailserver ab (bzw. einfach dann, wenn mal ein Ausfall wäre).

- nach ca. 1 Stunde sollten alle NS die aktuellen Daten haben.
   - Cacheverfallszeit wird von SOA-Record der Domain übernommen.

Die Nameserver haben sich mit der Verfallszeit eigentlich nach der SOA-Angabe zu richten. Aber natürlich kann man sich im privaten Bereich selbst was schnitzen - nur beim Anbieten öffentlicher Nameserver macht sich das nicht unbedingt so gut.

Jetzt habe ich dich nicht verstanden. Mit öffentlichen Nameserver
meinst du zum Beispiel die cachenden ISP-Nameserver der
Internetzugangsprovider, oder? - Du meinst, dass sich diese nicht
nach den SOA der eigenen Nameserver richten, sondern einfach
staatisch eine konstante Refreshzeit festlegen?

Das hatte
ich einmal versucht, aber dann war stets der alte Nameserver aktiv
und der Neue wollte einfach nicht zum Zuge kommen, obwohl ich bei
switch.ch die Reihenfolge entsprechend gesetzt habe

Definiere "zum Zuge kommen"? Wie hast du das festgestellt?

Ganz einfach, die alten zwei Nameserver zeigten auf einen Webspace
mit Inhalt X, die neuen Nameserver zeigen auf einen anderen Webspace
mit Inhalt Y. Selbst nach eintragen der Reihenfolge NS_neu1; NS_neu2;
NS_alt1;NS_alt2 bei switch.ch wurde mir nach mehreren Tagen der
Inhalt X angezeigt (obwohl bereits längst die neuen zwei NS aktiv
geworden sein sollten). Erst nach entfernen der NS_alt1 und NS_alt2
bekam ich nach einiger Zeit den Inhalt Y zu sehen.

Wenn mehr als ein Nameserver definiert ist, wird beim Auflösen eines Namens ein beliebiger Nameserver benutzt - die müssen ja alle gleichwertige, authoritative Informationen über die Zone ausliefern, also muß es egal sein, wen man fragt.

Ist es nicht so, dass zuerst der primäre Nameserver gefragt wird und
erst bei Nichterhalt der Antwort der sekundäre Nameserver (usw.)
gefragt wird? Oder anders gefragt: Gibt es Clients, die den
Nameserver durch eine Art Round-Roubin auswählen (also eben
irgendeinen)? - Das wäre für mich ebenfalls wichtig zu wissen, denn
ich kann nicht alle Nameserver mit denselben Daten füllen (was
auch nicht weiter schlimm ist, denn normalerweise sind die zwei
ersten Nameserver nie offline und wenn sie doch einmal offline sind,
kommt eben eine Art Backup-Nameserver zum Einsatz, der auf einen
Fallback-Server zeigt).

Was bedeuten die „IN NS“-Records? – Festlegung der NS für einen
Host? – Denn die NS-Einträge für eine Domain liegen ja beim
Registrar und nicht auf dem eigenen NS, was soll also die NS-
Definition im NS?

Das ist das sogenannte "glue". Indem man der Zone mitgibt, welche Nameserver für die Zone zuständig sind, kann bei DNS-Anfragen nach der Zone diese Information ebenfalls mitgegeben werden. Damit werden Deadlocks (um die IP vom Nameserver rauszufinden, muß ich die IP vom Nameserver rausfinden...) und unnötige zusätzliche DNS-Anfragen verhindert.

Oh. Danke!

Viele Grüsse und Danke!

Philipp

[Vinzenz]

Hallo Philipp,

Ist es nicht so, dass zuerst der primäre Nameserver gefragt wird und
erst bei Nichterhalt der Antwort der sekundäre Nameserver (usw.)
gefragt wird? Oder anders gefragt: Gibt es Clients, die den
Nameserver durch eine Art Round-Roubin auswählen (also eben
irgendeinen)? - Das wäre für mich ebenfalls wichtig zu wissen, denn
ich kann nicht alle Nameserver mit denselben Daten füllen (was
auch nicht weiter schlimm ist, denn normalerweise sind die zwei
ersten Nameserver nie offline und wenn sie doch einmal offline sind,
kommt eben eine Art Backup-Nameserver zum Einsatz, der auf einen
Fallback-Server zeigt).

Du weißt, dass es sehr sinnvoll ist, einen NS _außerhalb_ der eigenen
Domain zu haben, siehe das DNS-Howto http://www.tldp.org/HOWTO/DNS-HOWTO-7.html#ss7.4 von Nicolai Langfeldt?

Freundliche Grüsse,

Vinzenz

[Sven Rautenberg]

Moin!

Danke für den Hinweis. Eventuell mache ich nichteinmal eine
Weiterleitung an den Hauptserver, sondern rufe die Mails einfach von
jedem Mailserver ab (bzw. einfach dann, wenn mal ein Ausfall wäre).

Dann wären die MXe alle mit derselben Priorität anzugeben - hätte auch den Vorteil, dass sich dann der Traffic verteilen würde - aber ich glaube nicht, dass das bei dir SO arg ist, oder?

Es ist von der Einfachheit her wirklich schöner, die sekundären Mailserver so zu konfigurieren, dass sie die Mails an den primären Server weiterleiten. Dann mußt du dort nämlich keinen POP3 oder IMAP Server installieren und brauchst auch nicht zwei oder drei Logins zu definieren.

Jetzt habe ich dich nicht verstanden. Mit öffentlichen Nameserver
meinst du zum Beispiel die cachenden ISP-Nameserver der
Internetzugangsprovider, oder?

Richtig.

Du meinst, dass sich diese nicht
nach den SOA der eigenen Nameserver richten, sondern einfach
staatisch eine konstante Refreshzeit festlegen?

Nein, umgekehrt. Solche Server sollen sich ja gerade nach der SOA-TTL richten. Was du zuhause mit einem ansonsten für niemanden erreichbaren Nameserver machst, ist dir überlassen - aber üblicherweise würdest du dort auch nur ein klassisches DNS-Serverpaket installieren (also BIND, djbdns,...), und die verhalten sich eben auch zuhause "normal", beachten also die Cachingzeiten. Schließlich werden die nicht gewürfelt, sondern haben schon manchmal ihren Sinn. dyndns-Adressen beispielsweise sind absichtlich nur 10 Minuten gültig. Wäre blöd, wenn man die durch Eigeninitiative plötzlich vier Stunden gültig machen würde.

Definiere "zum Zuge kommen"? Wie hast du das festgestellt?

Ganz einfach, die alten zwei Nameserver zeigten auf einen Webspace
mit Inhalt X, die neuen Nameserver zeigen auf einen anderen Webspace
mit Inhalt Y. Selbst nach eintragen der Reihenfolge NS_neu1; NS_neu2;
NS_alt1;NS_alt2 bei switch.ch wurde mir nach mehreren Tagen der
Inhalt X angezeigt (obwohl bereits längst die neuen zwei NS aktiv
geworden sein sollten). Erst nach entfernen der NS_alt1 und NS_alt2
bekam ich nach einiger Zeit den Inhalt Y zu sehen.

Das ist alles andere als ein Beweis. Die Reihenfolge der Nameserver ist irrelevant. Mit Pech haben die deinem Browser zugeordneten Nameserver zwar registriert, dass da zwei neue Nameserver befragbar wären, haben aber trotzdem weiterhin die alten Nameserver gefragt. Wie gesagt: Es gibt für fragende DNS-Server keine primären oder sekundären Nameserver, sondern einfach nur "angegebene Nameserver", die gefälligst zuständig sein sollen.

Welcher Nameserver gefragt wird, ist beim allerersten Zugriff zufällig. Mehrere nachfolgende Zugriffe könnten sich aber (es hängt vom fragenden Nameserver ab) an der Antwortzeit eines Nameservers orientieren. Beim Überschreiten einer gewissen Schranke wird dann einfach mal ein anderer Server gefragt. Auf diese Weise wird tendentiell immer der Server gefragt, der - abhängig von der Netztopologie - die schnellste Antwort liefert. Und das scheint bei dir eben immer der mit den alten Daten zu sein.

Wenn du tatsächlich wissen willst, was switch.ch in der ch-Zone eingetragen hat, wirst du dich zwangsläufig mit nslookup, dig oder dnsq(r) beschäftigen müssen und die authoritativen Nameserver direkt befragen (andernfalls kriegst du nur die zeitverzögerte Antwort vom cachenden DNS deines Providers.

Ist es nicht so, dass zuerst der primäre Nameserver gefragt wird und
erst bei Nichterhalt der Antwort der sekundäre Nameserver (usw.)
gefragt wird?

Nein. Es gibt keinen "primären" Nameserver, weil es keinerlei Information im DNS gibt, der einen Server als "primär" kennzeichnen kann. Oder gibst du im Zonefile
IN PNS primary.domain.tld.
IN SNS secondary.backup.tld
ein? Wohl eher nicht, die Dinger heißen alle "NS", sind also alle gleichwertig zu behandeln - sollen ja schließlich auch komplett identische Informationen ausspucken.

Oder anders gefragt: Gibt es Clients, die den
Nameserver durch eine Art Round-Roubin auswählen (also eben
irgendeinen)? - Das wäre für mich ebenfalls wichtig zu wissen, denn
ich kann nicht alle Nameserver mit denselben Daten füllen (was
auch nicht weiter schlimm ist, denn normalerweise sind die zwei
ersten Nameserver nie offline und wenn sie doch einmal offline sind,
kommt eben eine Art Backup-Nameserver zum Einsatz, der auf einen
Fallback-Server zeigt).

Warum geht das nicht? Das ist doch eigentlich der Sinn der Sache: Alle Nameserver, die authoritativ für eine Domain sind, sollen die identischen Informationen haben.

Dein Szenario ist natürlich spezieller: Zwei identische Webserver mit unterschiedlichen IPs sollen gegenseitig füreinander einspringen. Aber wie ich schon sagte: Das kannst du nicht per DNS regeln, mindestens dauert das viel zu lange, bis sich damit was verändert.

Du kannst die beiden IPs, die für den einen Namen gelten sollen, beide im Zonefile verewigen und dann auf alle Nameserver überspielen. Dann die benutzte IP zufällig ausgesucht und dadurch die Last ungefähr 1:1 verteilt. Ist aber auch nicht das, was Ausfallsicherheit bringt, denn wenn der eine Server weg ist, bleibt er das für alle Besucher, die dessen IP mitgeteilt bekamen. Oder es gibt so lustige Effekte wie "mal geht es, mal geht es nicht".

- Sven Rautenberg

[Philipp Hasenfratz]

Halihallo Sven

Danke für den Hinweis. Eventuell mache ich nichteinmal eine
Weiterleitung an den Hauptserver, sondern rufe die Mails einfach von
jedem Mailserver ab (bzw. einfach dann, wenn mal ein Ausfall wäre).

Dann wären die MXe alle mit derselben Priorität anzugeben - hätte auch den Vorteil, dass sich dann der Traffic verteilen würde - aber ich glaube nicht, dass das bei dir SO arg ist, oder?

Nein, der Mailtraffic ist gering. Es geht wirklich nur um eine
Lösung, falls der Hauptserver einmal offline wäre.
Es geht mir primär um Verfügbarkeit, nicht um Performance.

Es ist von der Einfachheit her wirklich schöner, die sekundären Mailserver so zu konfigurieren, dass sie die Mails an den primären Server weiterleiten. Dann mußt du dort nämlich keinen POP3 oder IMAP Server installieren und brauchst auch nicht zwei oder drei Logins zu definieren.

Stimmt.

Du meinst, dass sich diese nicht
nach den SOA der eigenen Nameserver richten, sondern einfach
staatisch eine konstante Refreshzeit festlegen?

Nein, umgekehrt. Solche Server sollen sich ja gerade nach der SOA-TTL richten. Was du zuhause mit einem ansonsten für niemanden erreichbaren Nameserver machst, ist dir überlassen - aber üblicherweise würdest du dort auch nur ein klassisches DNS-Serverpaket installieren (also BIND, djbdns,...), und die verhalten sich eben auch zuhause "normal", beachten also die Cachingzeiten. Schließlich werden die nicht gewürfelt, sondern haben schon manchmal ihren Sinn. dyndns-Adressen beispielsweise sind absichtlich nur 10 Minuten gültig. Wäre blöd, wenn man die durch Eigeninitiative plötzlich vier Stunden gültig machen würde.

OK, danke.

Definiere "zum Zuge kommen"? Wie hast du das festgestellt?

Ganz einfach, die alten zwei Nameserver zeigten auf einen Webspace
mit Inhalt X, die neuen Nameserver zeigen auf einen anderen Webspace
mit Inhalt Y. Selbst nach eintragen der Reihenfolge NS_neu1; NS_neu2;
NS_alt1;NS_alt2 bei switch.ch wurde mir nach mehreren Tagen der
Inhalt X angezeigt (obwohl bereits längst die neuen zwei NS aktiv
geworden sein sollten). Erst nach entfernen der NS_alt1 und NS_alt2
bekam ich nach einiger Zeit den Inhalt Y zu sehen.

Das ist alles andere als ein Beweis. Die Reihenfolge der Nameserver ist irrelevant. Mit Pech haben die deinem Browser zugeordneten Nameserver zwar registriert, dass da zwei neue Nameserver befragbar wären, haben aber trotzdem weiterhin die alten Nameserver gefragt. Wie gesagt: Es gibt für fragende DNS-Server keine primären oder sekundären Nameserver, sondern einfach nur "angegebene Nameserver", die gefälligst zuständig sein sollen.

Welcher Nameserver gefragt wird, ist beim allerersten Zugriff zufällig. Mehrere nachfolgende Zugriffe könnten sich aber (es hängt vom fragenden Nameserver ab) an der Antwortzeit eines Nameservers orientieren. Beim Überschreiten einer gewissen Schranke wird dann einfach mal ein anderer Server gefragt. Auf diese Weise wird tendentiell immer der Server gefragt, der - abhängig von der Netztopologie - die schnellste Antwort liefert. Und das scheint bei dir eben immer der mit den alten Daten zu sein.

Das sind für mich sehr wertfolle Informationen. Vielen Dank.
Somit hat sich mein Problem insofern gelöst, dass ich durch Andreas
und Deine Antworten zur Schlussfolgerung gelangt bin, dass die DNS
Lösung (mindestens) unzureichend bis schlecht ist.

Dein Szenario ist natürlich spezieller: Zwei identische Webserver mit unterschiedlichen IPs sollen gegenseitig füreinander einspringen. Aber wie ich schon sagte: Das kannst du nicht per DNS regeln, mindestens dauert das viel zu lange, bis sich damit was verändert.

Das sehe ich ein. Andreas Lösung wäre hier dann anzuwenden. Reiners
Vorschlag einer softwaretechnischen Lösung wäre zwar sehr schön,
jedoch muss ich hier Andreas recht geben, dass auch der Server der
den LoadBalancer (z.B. PEN) betreibt ein "Single Point of Failure"
ist und genau dies will ich ja verhindern.

Du kannst die beiden IPs, die für den einen Namen gelten sollen, beide im Zonefile verewigen und dann auf alle Nameserver überspielen. Dann die benutzte IP zufällig ausgesucht und dadurch die Last ungefähr 1:1 verteilt. Ist aber auch nicht das, was Ausfallsicherheit bringt, denn wenn der eine Server weg ist, bleibt er das für alle Besucher, die dessen IP mitgeteilt bekamen. Oder es gibt so lustige Effekte wie "mal geht es, mal geht es nicht".

Richtig. Ich wäre nicht so vorgegangen, denn RoundRoubin ist eher
eine performancetechnische Massnahme und dient der Redundanz wirklich
nicht. Es sei denn, man würde ein Programm schreiben (Failover-
Monitor), welches einen abgestürzten Rechner identifiziert und dann
die dynamisch den entsprechenden A-Record entfernt. Aber wie du
richtig sagst, es wird in einem "Blinker-Betrieb" (für eine gewisse
Zeit) enden.

Viele Grüsse und Danke

Philipp

[Sven Rautenberg]

Moin!

Dann wären die MXe alle mit derselben Priorität anzugeben - hätte auch den Vorteil, dass sich dann der Traffic verteilen würde - aber ich glaube nicht, dass das bei dir SO arg ist, oder?

Nein, der Mailtraffic ist gering. Es geht wirklich nur um eine
Lösung, falls der Hauptserver einmal offline wäre.
Es geht mir primär um Verfügbarkeit, nicht um Performance.

Es gibt eigentlich nur zwei typische Szenarien (abgesehen vielleicht von endlich vielen Speziallösungen in Sondefällen):
1. Zwei oder mehr MXe mit unterschiedlicher Priorität, alle mit höherer Prio liefern ihre Mails letztendlich zu dem primären MX mit kleinster Priorität - wenn der down ist, dann eben später.
2. Zwei oder mehr MXe mit gleicher Priorität - das dient dann zur Verteilung des Traffics, und die hereinkommenden Mails werden dann in der Regel irgendwie (versteckt und geheim im internen Netz) weitergeleitet zu den Mailboxservern, damit man sie mit POP3 oder IMAP abholen kann.

Szenario 2 trifft bei dir nicht zu, weil es kein "innen" gibt, sondern der Mailserver auch selbst die POP3-Mailbox anbietet. Bei zwei identisch priorisierten Mailservern gäbe es zwei Mailboxen, die man separat abfragen müßte. Außerdem wäre bei diesem Szenario nicht unbedingt gesagt, dass Mails, die an den dummerweise ausgefallenen Mailserver gehen sollen, dann alternativ an den nicht ausgefallenen Mailserver gleicher Priorität gehen. Je nachdem, wie MTas gestrickt sind, nehmen die vielleicht einfach nur einen der jeweiligen Prioritätsstufe. Bei Mißerfolg und dem Fehlen einer höheren Priorität wird vielleicht einfach mit der Auslieferung gewartet.

Bleibt also Szenario 1: Du hast einen Sekundären Mailserver, der die Mails für dich annimmt, falls der primäre Mailserver ausgefallen ist.

Dann frage ich dich aber einfach mal: Warum? Sämtliche Mailserver dieser Welt haben eine Mailwarteschlange, in der Mails bis zu 7 Tage lang aufbewahrt werden, ehe sie als endgültig unzustellbar an den Sender zurück gehen. Wenn dein primärer Mailserver also ausfällt, dann würde...

...ohne sekundären Mailserver die Auslieferung der Mails an dich in den Warteschlangen der sendenden Mailserver steckenbleiben und nach Wiederverfügbarkeit deines primären Mailservers nachgeholt. Eventuell erhalten Sender schon nach 4 Stunden (Standard bei Sendmail) eine Nachricht, dass die Mail immer noch nicht ausgeliefert werden konnte.

...mit sekundärem Mailserver die Auslieferung der Mails an diesen natürlich erfolgreich stattfinden, aber der sekundäre Mailserver seinerseits würde eine Warteschlange mit Mails anlegen, die alle darauf warten, an den primären Mailserver weitergeleitet zu werden. Solange der also offline ist, hat sich qualitativ nichts geändert. Im Gegenteil: Die Mailserver der Sender haben zuerst mal ein Erfolgserlebnis zu melden: Erfolgreich die Mail ausgeliefert - zwar nicht an den primären MX, aber das muß ja nicht zwingend böse sein, kurzfristige Nichterreichbarkeit kann ja viele Gründe haben. Dein sekundärer MX wird nun seinerseits bis zu 7 Tage warten (sofern du das nicht länger oder kürzer einstellst) und versuchen, die Mail weiterzuleiten - und beim Fehlschlagen dann eine Nichtzustellbarkeitsnachricht zurückschicken.

Allerdings: Wer es nicht schafft, innerhalb von 7 Tagen für seinen ausgefallenen Mailserver Ersatz zu beschaffen bzw. eine Alternativlösung einzurichten, der sollte vielleicht seine generelle Teilnahme am Mailverkehr überdenken. :)

Es macht jedenfalls keinerlei Unterschied, ob du einen sekundären MX hast, oder nicht: Solange der primäre MX offline ist, kriegst du keine Mails mehr. Wenn er schnell genug wieder online ist, kriegst du alle Mails, die in irgendwelchen Warteschlangen hängen, noch ausgeliefert. Alternativ kannst du natürlich auch einen Ersatzserver herbeischaffen und übergangsweise dessen Namen als primären MX verbreiten. Egal, ob du einen sekundären MX hast oder nicht: Auch dann werden die Mails in den Warteschlangen so nach und nach eintrudeln.

Wie erwähnt: Ein sekundärer MX muß heute leider mehr sein, als nur ein schlichter Forwarding-Slave für deine Maildomain. Spam-Versender zielen teilweise absichtlich auf die sekundären MX, weil dort die Wahrscheinlichkeit für eine Existenzprüfung der Mailbox geringer ist und die Mails erstmal komplett akzeptiert werden. Das bringt wiederum eine höhere Sendequote, gegenüber dem Kunden (der den Auftrag zum Spammen gab) ein Argument für mehr "erfolgreich abgeschickte Mails", und hat eben den entscheidenden Nachteil, dass nachträglich generierte Unzustellbarkeitsnachrichten garantiert den unschuldigen Inhaber der gefälschten Absenderadresse treffen.

Insofern verdoppelt ein sekundärer MX einfach erstmal deinen administrativen Aufwand, ohne tatsächlich irgendwie sinnvolle Zusatzarbeit zu leisten. Ist jedenfalls meine Praxiserfahrung. Natürlich kannst du argumentieren, dass du bei einem sekundären MX quasi den potentiellen neuen primären MX schon aktiv auf Standby laufen hast oder zumindest hilfsweise einen Blick in die Queue werfen könntest, ob irgendwelche wirklich wichtigen Mails reingekommen sind.

Andererseits: Wenn du dir Gedanken über Ausfallsicherheit eines Serverdienstes machst (in diesem Fall Mail), dann aber nicht in der Lage wärst, innerhalb von 7 Tagen einen ausgefallenen Server wieder in Betrieb zu setzen bzw. Ersatz dafür zu beschaffen, solltest du dir eher keine Gedanken um Ausfallsicherheit machen - oder zu einem Provider wechseln, der sowas leisten kann. :)

Das sehe ich ein. Andreas Lösung wäre hier dann anzuwenden. Reiners
Vorschlag einer softwaretechnischen Lösung wäre zwar sehr schön,
jedoch muss ich hier Andreas recht geben, dass auch der Server der
den LoadBalancer (z.B. PEN) betreibt ein "Single Point of Failure"
ist und genau dies will ich ja verhindern.

Klar ist es blöd, sich erst aufwendig zwei statt einen Server hinzustellen, dann aber an der Nichtverfügbarkeit des EINEN Loadbalancers zu scheitern. Logische Konsequenz: Der Loadbalancer muß auch redundant ausgelegt werden. Auf IP-, ARP- und Ethernet-Ebene kann man da sicher nette Dinge drehen - das ist dann aber explizit eine entsprechende Sonderlösung mit entsprechenden Kosten für Hardware und Administration, und garantiert nicht zum Taschengeldtarif zu kriegen.

Ist leider so: Mit normalem Kostenaufwand kriegst du nur relativ leicht erreichbare durchschnittliche Uptimes von 99,9% (8 3/4 Stunden Ausfall im Jahr) oder weniger (je nachdem, was dein Provider für den normalen Kunden so anbietet). Je mehr Neunen aber als Nachkommastellen hinten dranhängen sollen, desto teurer wird es. 99,9999% Verfügbarkeit entsprächen im Jahr durchschnittlich etwas mehr als 31 Sekunden Ausfallzeit des Systems - das wird man wahrscheinlich garnicht bemerken.

- Sven Rautenberg

[Philipp Hasenfratz]

Halihallo Sven

Bleibt also Szenario 1: Du hast einen Sekundären Mailserver, der die Mails für dich annimmt, falls der primäre Mailserver ausgefallen ist.
Dann frage ich dich aber einfach mal: Warum? Sämtliche Mailserver dieser Welt haben eine Mailwarteschlange, in der Mails bis zu 7 Tage lang aufbewahrt werden, ehe sie als endgültig unzustellbar an den Sender zurück gehen. Wenn dein primärer Mailserver also ausfällt, dann würde...

Richtig. Soweit ich informiert bin, nehmen die Retry-Versuche stetig
ab. Beim Nichterreichen des Mailservers wird nach einer Stunde, dann
nach 5 Stunden, dann nach einem Tag, dann nach drei Tagen noch einmal
versucht. Bei einer Ausfallszeit von meinetwegen 8 Stunden ist das
nicht weiter arg, da die Mails dann nach spätestens 24 Stunden
(geraten) bei mir eintreffen. Bei dem unwahrscheinlichen
Vorfall, dass der Server für ein oder mehrere Tage offline ist,
geschieht die Auslieferung leider sehr viel später und genau dies
soll verhindert werden. Jede Mail muss innerhalb von 24 Stunden
100%-ig ankommen. Und dies ohne Benachrichtigung an den Sendenden.

Deswegen wählte ich das Szenario 2, welches du beschrieben hast. Zwei
oder mehr Mailserver mit unterschiedlicher Priorität.

...ohne sekundären Mailserver die Auslieferung der Mails an dich in den Warteschlangen der sendenden Mailserver steckenbleiben und nach Wiederverfügbarkeit deines primären Mailservers nachgeholt.

Nur ist die Zeit für die Mailauslieferung x mal länger ist, als die
Ausfallszeit des Servers, da die Zeit für die Auslieferung der Retry-
Zeit/2 + Serverausfallszeit beträgt.

Eventuell erhalten Sender schon nach 4 Stunden (Standard bei Sendmail) eine Nachricht, dass die Mail immer noch nicht ausgeliefert werden konnte.

... was natürlich keinen sehr guten Eindruck macht und deshalb
vermieden werden soll.

...mit sekundärem Mailserver die Auslieferung der Mails an diesen natürlich erfolgreich stattfinden, aber der sekundäre Mailserver seinerseits würde eine Warteschlange mit Mails anlegen, die alle darauf warten, an den primären Mailserver weitergeleitet zu werden. Solange der also offline ist, hat sich qualitativ nichts geändert.

Da bin ich anderer Meinung. Die Mail ist aus der Sicht des Sendenden
erfolgreich versendet worden und auf meiner Seite (ich weiss ja,
wenn der Server ausgefallen ist), könnte ich die Mails direkt vom
sekundären Mailserver abhohlen. So entsteht keine Ausfallszeit für
die Bearbeitung der Mails, selbst bei einem Ausfall des primären
Servers.

Allerdings: Wer es nicht schafft, innerhalb von 7 Tagen für seinen ausgefallenen Mailserver Ersatz zu beschaffen bzw. eine Alternativlösung einzurichten, der sollte vielleicht seine generelle Teilnahme am Mailverkehr überdenken. :)

Keine Einwände :-)
Oder vielleicht einer: Selbst bei diesem unwahrscheinlichen Szenario
(selbst 3 Tage halte ich für inakzeptabel) wäre die Verfügbarkeit
der elektronischen Post und somit der Geschäftsprozesse
gewährleistet.

Es macht jedenfalls keinerlei Unterschied, ob du einen sekundären MX hast, oder nicht: Solange der primäre MX offline ist, kriegst du keine Mails mehr.

Doch, das würde ich. Wenn es wichtig ist, kann ich die Mails direkt
vom sekundären Server abholen (meinetwegen jedes "POP-Postfach"
für jeden Server separat, wie auch schon vorgeschlagen).

Gott sei Dank passiert dies "nie".

Insofern verdoppelt ein sekundärer MX einfach erstmal deinen administrativen Aufwand, ohne tatsächlich irgendwie sinnvolle Zusatzarbeit zu leisten. Ist jedenfalls meine Praxiserfahrung. Natürlich kannst du argumentieren, dass du bei einem sekundären MX quasi den potentiellen neuen primären MX schon aktiv auf Standby laufen hast oder zumindest hilfsweise einen Blick in die Queue werfen könntest, ob irgendwelche wirklich wichtigen Mails reingekommen sind.

Da der Aufwand für mich vergleichsweise gering ist, halte ich dies
doch für eine gute Zeitinvestition. Genauso verstehe ich auch deine
Argumente und danke dafür.

Andererseits: Wenn du dir Gedanken über Ausfallsicherheit eines Serverdienstes machst (in diesem Fall Mail), dann aber nicht in der Lage wärst, innerhalb von 7 Tagen einen ausgefallenen Server wieder in Betrieb zu setzen bzw. Ersatz dafür zu beschaffen, solltest du dir eher keine Gedanken um Ausfallsicherheit machen - oder zu einem Provider wechseln, der sowas leisten kann. :)

Wie in Fragen der Sicherheit, so gilt auch hier: Ein System ist genau
so stark, wie sein schwächstes Glied. Du kannst dir vorstellen, dass
ich bemüht bin alle ggf. vorhandenen schwachen Glieder durch starke
zu ersetzen.

Ist leider so: Mit normalem Kostenaufwand kriegst du nur relativ leicht erreichbare durchschnittliche Uptimes von 99,9% (8 3/4 Stunden Ausfall im Jahr) oder weniger (je nachdem, was dein Provider für den normalen Kunden so anbietet). Je mehr Neunen aber als Nachkommastellen hinten dranhängen sollen, desto teurer wird es. 99,9999% Verfügbarkeit entsprächen im Jahr durchschnittlich etwas mehr als 31 Sekunden Ausfallzeit des Systems - das wird man wahrscheinlich garnicht bemerken.

So ganz nach der Regel, dass für jede zusätzliche 9 als
Nachkommastelle die Kosten exponentiell steigen. Tja.

Viele Grüsse und Danke

Philipp

[Sven Rautenberg]

Moin!

Richtig. Soweit ich informiert bin, nehmen die Retry-Versuche stetig
ab. Beim Nichterreichen des Mailservers wird nach einer Stunde, dann
nach 5 Stunden, dann nach einem Tag, dann nach drei Tagen noch einmal
versucht.

Das stimmt so nicht, die Zeiten hängen definitiv von der Konfiguration des Mailservers ab. Postfix beispielsweise läßt eine minimale und maximale Wartezeit für den nächsten Versuch definieren, die Standardwerte sind 1000 und 4000 Sekunden (16,6 Minuten bis 66,6 Minuten).

Bei einer Ausfallszeit von meinetwegen 8 Stunden ist das
nicht weiter arg, da die Mails dann nach spätestens 24 Stunden
(geraten) bei mir eintreffen.

Wenn die Administratoren der sendenden Server es ihren eigenen Kunden zumuten wollen, bei einem Fehlversuch erst nach einer Stunde neu zu probieren, und später dann im Tagesabstand, dann ist das eben so - kann aber nicht dein Problem sein.

Bei dem unwahrscheinlichen
Vorfall, dass der Server für ein oder mehrere Tage offline ist,
geschieht die Auslieferung leider sehr viel später und genau dies
soll verhindert werden. Jede Mail muss innerhalb von 24 Stunden
100%-ig ankommen. Und dies ohne Benachrichtigung an den Sendenden.

Wie gesagt: Vernünftige Konfiguration des sendenden Mailservers (auf den du keinen Einfluß hast) hilft.

Deine Forderung "muß in 24 Stunden ankommen" ist ja aber ohnehin nicht zu erfüllen, wenn dein eigener Mailserver länger als 24 Stunden ausfällt. :)

Eventuell erhalten Sender schon nach 4 Stunden (Standard bei Sendmail) eine Nachricht, dass die Mail immer noch nicht ausgeliefert werden konnte.

... was natürlich keinen sehr guten Eindruck macht und deshalb
vermieden werden soll.

Im Gegenteil, man ist dann wenigsten informiert, dass der Empfänger noch gar nicht reagiert haben kann.

Es macht jedenfalls keinerlei Unterschied, ob du einen sekundären MX hast, oder nicht: Solange der primäre MX offline ist, kriegst du keine Mails mehr.

Doch, das würde ich. Wenn es wichtig ist, kann ich die Mails direkt
vom sekundären Server abholen (meinetwegen jedes "POP-Postfach"
für jeden Server separat, wie auch schon vorgeschlagen).

Ok, Überraschung: Dein sekundärer MX steht im gleichen Rechenzentrum und ist wegen Stromausfall auch nicht mehr erreichbar. :)

Gott sei Dank passiert dies "nie".

Eben.

Insofern verdoppelt ein sekundärer MX einfach erstmal deinen administrativen Aufwand, ohne tatsächlich irgendwie sinnvolle Zusatzarbeit zu leisten. Ist jedenfalls meine Praxiserfahrung. Natürlich kannst du argumentieren, dass du bei einem sekundären MX quasi den potentiellen neuen primären MX schon aktiv auf Standby laufen hast oder zumindest hilfsweise einen Blick in die Queue werfen könntest, ob irgendwelche wirklich wichtigen Mails reingekommen sind.

Da der Aufwand für mich vergleichsweise gering ist, halte ich dies
doch für eine gute Zeitinvestition. Genauso verstehe ich auch deine
Argumente und danke dafür.

Wie bei allen guten Servern, die mit Linux und einem vernünftigen Mail-Daemon laufen, ist _natürlich_ der administrative Aufwand gering.

Aber wie erwähnt: Auch der sekundäre MX muß über alle Abwehrmaßnahmen gegenüber unerwünschten Mails verfügen, ansonsten bounct er sich (und andere) tot. Die Double-Bounces kriegt dann übrigens dein Postmaster-Account alle ab. :)

- Sven Rautenberg

[Philipp Hasenfratz]

Halihallo Sven

Das stimmt so nicht, die Zeiten hängen definitiv von der Konfiguration des Mailservers ab. Postfix beispielsweise läßt eine minimale und maximale Wartezeit für den nächsten Versuch definieren, die Standardwerte sind 1000 und 4000 Sekunden (16,6 Minuten bis 66,6 Minuten).

Interessant, das heisst, dass bei wohl den meisten Mailservern
spätestens jede Stunde erneut versucht wird.

Bei einer Ausfallszeit von meinetwegen 8 Stunden ist das
nicht weiter arg, da die Mails dann nach spätestens 24 Stunden
(geraten) bei mir eintreffen.

Wenn die Administratoren der sendenden Server es ihren eigenen Kunden zumuten wollen, bei einem Fehlversuch erst nach einer Stunde neu zu probieren, und später dann im Tagesabstand, dann ist das eben so - kann aber nicht dein Problem sein.

Natürlich ist es mein Problem, wenn ich ein Serversystem aufsetzen
muss, wo jede Mail in spätestens 24 Stunden ankommt. Aber dies lässt
sich genauso einfach realisieren: zwei oder mehr Mailserver.

Eventuell erhalten Sender schon nach 4 Stunden (Standard bei Sendmail) eine Nachricht, dass die Mail immer noch nicht ausgeliefert werden konnte.

... was natürlich keinen sehr guten Eindruck macht und deshalb
vermieden werden soll.

Im Gegenteil, man ist dann wenigsten informiert, dass der Empfänger noch gar nicht reagiert haben kann.

Nun, da differiert meine Aufgabenstellung von deiner Meinung, der ich
prinzipiell gar nicht wiederspreche.

Es macht jedenfalls keinerlei Unterschied, ob du einen sekundären MX hast, oder nicht: Solange der primäre MX offline ist, kriegst du keine Mails mehr.

Doch, das würde ich. Wenn es wichtig ist, kann ich die Mails direkt
vom sekundären Server abholen (meinetwegen jedes "POP-Postfach"
für jeden Server separat, wie auch schon vorgeschlagen).

Ok, Überraschung: Dein sekundärer MX steht im gleichen Rechenzentrum und ist wegen Stromausfall auch nicht mehr erreichbar. :)

https://forum.selfhtml.org/?t=100946&m=620866, genau deswegen wünschte ich eine global
verteilte Lösung :-)

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo Philipp!

Ok, Überraschung: Dein sekundärer MX steht im gleichen Rechenzentrum und ist wegen Stromausfall auch nicht mehr erreichbar. :)

https://forum.selfhtml.org/?t=100946&m=620866, genau deswegen wünschte ich eine global
verteilte Lösung :-)

Das was ich beschrieben habe bezog sicher eher auf verteilte Webserver oder Datenbank-Server, mir war nicht so klar dass es Dir explizit um Mailserver ging. Mailserver haben ja den riesigen Vorteil dass es für einen Hostnamen alternative Vorschläge im DNS geben kann, aber AFAIK ist das eine Ausnahme. Das macht es natürlich sehr leicht Mailserver in verschiedenen Netzen zu platzieren. Das ist auch sicherlich sinnvoll. Genauso wie man Nameserver selbst in verschiedenen Netzen haben sollte ;-)

Bei Webservern ist das aber wie gesagt etwas schwieriger, da ein Client hier per DNS immer nur genau eine IP bekommt, und die Webseite dann dort abruft. Wenn der Server aber down ist, bekommt der Benutzer eine Fehlermeldung. Und dank des Caching im DNS kann das je nach verwendeten Nameservern ne ganze Zeit dauern im DNS einen Hostnamen auf eine andere IP umzulenken, wie hier ja ausführlich besprochen wurde. Wenn ein Mailserver dagegen nicht erreichbar ist, kann ein alternativer Mailserver verwendet werden, mit anderer IP - sofern das im Nameserver entsprechend konfiguriert ist.

Entsprechend steht man bei der Verteilung von Webservern vor größeren Problemen als bei Mailservern.

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

https://forum.selfhtml.org/?t=100946&m=620866, genau deswegen wünschte ich eine global
verteilte Lösung :-)

Das was ich beschrieben habe bezog sicher eher auf verteilte Webserver oder Datenbank-Server, mir war nicht so klar dass es Dir explizit um Mailserver ging.

Mir ging es um beide Kontexte, also auch um verteilte Webserver
(sogar primär), du hast mich schon richtig verstanden. Nur, habe ich
dann mit Sven lange über Mailserver gesprochen, wohingegen wir lange
über Webserver gesprochen haben; insofern habe ich jetzt Ahnung von
beidem: Ziel erreicht :-)

Mailserver haben ja den riesigen Vorteil dass es für einen Hostnamen alternative Vorschläge im DNS geben kann, aber AFAIK ist das eine Ausnahme.

Richtig, es kann mehrere MX-Records pro Domain geben, welche dann je
nach Priorität und Verfügbarkeit verwendet werden.

Das macht es natürlich sehr leicht Mailserver in verschiedenen Netzen zu platzieren. Das ist auch sicherlich sinnvoll. Genauso wie man Nameserver selbst in verschiedenen Netzen haben sollte ;-)

Genau dies wollte ich erreichen, nur, dass ich damit ein Problem
eben nicht lösen kann: Zwei Webserver "realtime" zu switchen.

Entsprechend steht man bei der Verteilung von Webservern vor größeren Problemen als bei Mailservern.

Ja, die Verteilung der Mailserver in verschiedene Rechenzentren ist
einfach. Bei Webservern ist dies, hm, "fast" unmöglich. Zumindest
zeihe ich aufgrund eurer der Postings diesen Schluss.

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo Forumer

Danke für das Aufzeigen guter Lösungen und für die Erklärungen!

Viele Grüsse

Philipp