HA für Arme - switchen der Server bei Downtime

aria

aria

New Member
Hallo,

ich habe 2 synchrone Server. Um eine Quasi-HA zu erreichen dachte ich mir mit einem Script die Erreichbarkeit zu überprüfen und bei Nichterreichbarkeit die IP im DNS auf den 2. Server zu ändern. Aber das passiert ja nicht in Echtzeit, stimmts? Es muss ja nicht in Sekunden umswitchen aber wenn es innerhalb 2-3 Minuten möglich ist wäre das schon gut.

Die Server sind vserver. Synchron sind mysql durch master-master und ein Teil des Filesystems durch unison.

Ein 3. Server überwacht das, ist aber nicht seine Hauptaufgabe.

Hat jemand ein paar Idden oder Stichwörter ?

Danke

Aria
 
aria said:
ich habe 2 synchrone Server. Um eine Quasi-HA zu erreichen dachte ich mir mit einem Script die Erreichbarkeit zu überprüfen und bei Nichterreichbarkeit die IP im DNS auf den 2. Server zu ändern. Aber das passiert ja nicht in Echtzeit, stimmts? Es muss ja nicht in Sekunden umswitchen aber wenn es innerhalb 2-3 Minuten möglich ist wäre das schon gut.
Click to expand...

Ich würde einfach mal sagen, per Crontab könnte man das erste Script (ob die Server erreichbar sind) alle 2-3 Minuten abfragen lassen. Das Script stösst dann bei Nichterichbarkeit ein zweites Script an, welches den DNS Eintrag ändert.

Wie genau ich das machen würde, weiss ich so spontan auch nicht, aber ist nen kleiner Denkanstoss. :)
 
Stichwort: Failover-IP
Unter *BSD am Einfachsten per CARP umzusetzen.
Für HA auf Filesystemebene gibt es bei FreeBSD dann HAST.

Unter Linux muss man halt ordentlich Frickeln und mit sporadischen Problemen auf allen Ebenen leben.
 
Wäre es in diesem Fall nicht einfacher, permanent beide IPs in den A-/AAAA-Record der Domain aufzunehmen? Dann muss bei Nichterreichbarkeit des einen Servers der Client halt zusehen dass er den jeweils anderen Server kontaktiert, was aber vergleichsweise zuverlässig klappt.
Nachteil: Du hast natürlich auf beiden Servern gleichzeitig Zugriffe und musst das Dateisystem dadurch wirklich in Echtzeit synchron halten.
 
Lord Gurke said:
Client halt zusehen dass er den jeweils anderen Server kontaktiert, was aber vergleichsweise zuverlässig klappt
Click to expand...
Schön wärs. :rolleyes:
Nein, das klappt nicht zuverlässig. So gut wie kein Client sieht vor, dass er den nächsten A-Record nutzt, wenn der erste nicht funktioniert.

TTL der Sub-/Domain runtersetzen ist das einzige was man bei diesem wirren Konstrukt machen könnte.

Ansonsten wie Joe schon schrieb, wäre der vernünftigere Weg die IP mitzunehmen. Das kann aber auch unter Linux vernünftig funktionieren. ;)
Diese Möglichkeit wirst du aber nicht bei jedem Hosting Provider haben.
 
@gnx,
ja so habe ich mir das auch vorgestellt. Problem sehe ich darin das dns ja nicht gleich greifen wird. OK, mit TTL muss ich es noch ausprobieren

Muss nachfragen ob netcup FAilover-IP anbieten.

Noch eine Idee bezüglich DNS die aber sicher nicht RFC-konform ist

Was ist wenn ich Primary und Secondry DNS auf die beiden Server setze.
Wenn der erste nicht erreichbar ist wird auf dem zweiten angefragt. Jeder DNS Server hat aber einen anderen A Eintrag. Der PRimary auf sich selbst, der Secondary auf sich selbst und werden nicht synchroniesiert.

Somit zeigt der Secondary ( wenn Primary nicht erreichbar ist) auf sich selber und wenn Primary wieder verfügbar ist wieder Primary auf sich selber

Problem dabei: gecachte DNS-Einträge bzw. wird IMMER zuerst Primary und dann Secondary angefragt.
 
Firewire, was denkst du wie weit runter kann ich TTL setzen damit es nicht irgenwann ignoriert wird oder siehst du da keine Gefaht wenn ich es runter auf z.b 60 setze?
 
@Lord Gurke,

bei mysql vertraue ich auf die Synchronität, bei Unison ist es alle 5 Minuten aber 2-way. Müsste man testen. Oder schauen ob ClusterFS über IP einigermassen funktioniert
 
Rein theoretisch kannst du die TTL so niedrig setzen wie du willst. Die Denic wäre die einzige die IMHO ein unteres Limit von 180 Sekunden vorgibt.
Wie das bei anderen TLDs ist, kann man bei Bedarf beim zuständigen Registrar erfragen.

Wenn entgegen der RFC die TTL von anderen Resolvern ignoriert wird, wird sie immer ignoriert. Egal auf welchen Wert du sie setzt. Mir ist in den letzten Monaten aber kein einziger Resolver untergekommen, der sich nicht dran gehalten hätte.

Bedenke, dass du mit so extrem niedrigen TTLs auch Risiken eingehst. Fallen die Nameserver aus, cachen die Resolver die Domain auch nur paar Minuten. Danach ist Feierabend. ;)
 
TTL runtersetzen und dann rumskripten ist schon recht krank.

Wenn dir dein Hoster die Moeglichkeit einer Failover-IP gibt, laesst sich sowas mit einem klassischen Pacemaker/Corosync Setup loesen.

Solltest du im internen Netz zwischen deinen Knoten keine Multicasts absetzen duerfen, musst du heartbeat als Cluster Messaging Layer hernehmen, klappt genauso gut.

MySQL Master/Master? Setzt du Galera ein?

Wenn du wirklich active/active fahren musst/willst, halte ich unison als Mittel der Wahl fuer eher ungeeignet. DRBD koennte dir hier bessere Dienste erweisen.
 
Dante, es ist ja auch HA für Arme. Sollte es wirklich gutes und sicheres HA sein würde man da auch nicht so rumscripten sondern dafür auch den Preis zahlen.
Master/Master ist ohne zusätliche Software realisiert.
Active/active wäre schon nötig. Muss mir da deinen Vorschlag ansehen

Ja, es ist eine Bastelei. Aber das ist ja das schöne an Linux und überhaupt an Systemadministration. Probieren und lernen und wenn es nicht geht anders probieren.
 
Du könntest auch Services wie tzoha.com oder dnsmadeeasy.com verwenden, diese DNS-Provider bieten die von dir gewünschte Failover-Funktion. Sollte eine bessere Lösung sein, als selbst daran herumzuscripten. Eine Failover-IP wäre natürlich auch eine (ggf. bessere) Alternative.
 
HA (egal wie primitiv/komplex) und Bastelei schliessen sich gegenseitig aus, denn HA bedingt auch Datensicherheit und Letztere ist bei Bastelei nicht gegeben.

Bin schon gespannt, wann Dir die Bastelei das erste Mal um die Ohren fliegt und wieviele Daten Du dabei verlieren wirst.

BTW: Mit vServern ist HA nicht möglich...
 
a) hat der OP das Produkt nicht und b) ist das keine Lösung innerhalb von vServern sondern ausserhalb und somit durch meine vorige Aussage abgedeckt ;)
 
HA funktioniert unter Linux zuverlässig wenn man weiß was zu tun ist.

Hat sowas überhaupt schonmal jemand von euch ohne SPOF gemacht ?

Ich meine komplett richtig mit zwei Umspannwerken im Datacenter, red Netzzteilen an beide Umspannwerke angeschlossen, zwei Switches, zwei Routern? Und ja man kann spasseshalber irgendwas ausmachen, interessiert die Anlage nicht wirklich.

http://linux-vserver.org/Getting_high_with_lenny

Läuft seit 2009 produktiv bei einem Globalplayer im Fahrzeugzubehör-Business. Selbst das dist-upgrade auf Squeeze geht lecker mit einem Failover und hatte glaube ich 9 oder 10 Pings Downtime.

Das reicht dem Konzern lang der darüber etwas über 100 Mio pro Jahr schiebt.

Think about it.
 
DjTom-i said:
Hat sowas überhaupt schonmal jemand von euch ohne SPOF gemacht?
Click to expand...

Nicht im Datacenter, aber an zwei Standorten einer Firma (zwischen denen zum Glück reichlich Glas liegt) und einer Oracle-Datenbank (WaWi) auf SLES. SPOF ist eher die WaWi bzw. der Müll, den die Anwender da machen. Die HA-Lösung tut einfach und hat auch schon mehrere (geplante und ungeplante) Ausfälle überlebt.
Nur DRBD ist manchmal recht zickig beim automatischen Wiederaufbau der Spegelung, das kann man dann aber von Hand anstoßen.
 
Also ich habe da, nachdem ich das Namespace Script gefixed habe keinerlei Probleme. Es ist für mich eine verlässliche Sache und bei keinem der regelmäßigen Failover Tests gab es Probleme. Das System ist robust. Selbstverständlich sichern wir die Daten außerhalb des HA-Clusters - neben den Entwicklungsservern - nochmal separat.

Ich muß auch dazu sagen das ich HA über zwei Standorte hinweg nicht empfehlen würde (Stichwort: Split-Brain). Da ist mir das in der Tat zu wackelig alles.
 
infinitnet said:
Du könntest auch Services wie tzoha.com oder dnsmadeeasy.com verwenden, diese DNS-Provider bieten die von dir gewünschte Failover-Funktion. Sollte eine bessere Lösung sein, als selbst daran herumzuscripten. Eine Failover-IP wäre natürlich auch eine (ggf. bessere) Alternative.
Click to expand...

Ja ist die bessere Lösung

Vielen Dank !!!
 
You must log in or register to reply here.
Back
Top