[Kaimane]

@nemix Jetzt bin ich allerdings auch verwirrt. Kennst du etwa eine super geheime Methode, wie man SSL ohne eine IPv4-Adresse je Zertifikat effektiv betreiben kann, die bisher vor dem Rest der Menschheit verschlossen war? Jeder Kunde kreuzigt dich doch sobald du SNI oder (fast noch schlimmer) SAN-Zertifikate benutzt.

SNI ist grundsätzlich eine gute Sache. Solange die User jedoch XP mit einem IE betreiben bzw. Microsoft für diese Kombination nicht nachbessert, ist SNI nicht die erste Wahl. Dann lieber klassisch eine IP pro Zertifikat.

Das Interface mit den HA IP-Adressen sollte nicht automatisch hochgefahren werden. Bedeutet, wenn der Host wieder hoch kommt, testet er mit dem Script ob ein Node mit der Adresse vorhanden ist, etwa mit Ping, in umfangreichen Setups auch gern mit einer API zum Remote Server. Schlägt der Test fehl, wird das Interface hochgefahren, wenn der Server verfügbar ist, bleibt das Device deaktiviert.

Genau. Die IPs, die von beiden Servern verwendet werden können, dürfen auf den Maschinen nicht automatisch hochgefahren werden.
Hier muss entweder vorher automatisiert geprüft werden, ob die IP "frei" ist (wie strex es beschreibt) oder man fährt die Interfaces nach einem Ausfall manuell wieder hoch, nachdem man sie auf dem anderen Server runtergefahren hat
Dann kann es technisch zu keinem Split-Brain kommen.

@strex: Danke für den arping Befehl.
Leider kann ich das alles noch nicht testen, da meine Server sich noch immer in der Warteschlange befinden

[strex]

...
Was mich sehr interessieren würde, ist ob ihr denkt das die beschriebene Lösung mit ifup + gratuitous arp ohne weitere Maßnahmen sicher stellen kann, dass es nicht zu einer Split-Brain-Situation kommt sobald der ausgefallene Node zurückkommt? Denn dann kan man sich die nächsten 3 Wochen ja damit beschäftigen Datenbanken zu mergen ...
...

Das Interface mit den HA IP-Adressen sollte nicht automatisch hochgefahren werden. Bedeutet, wenn der Host wieder hoch kommt, testet er mit dem Script ob ein Node mit der Adresse vorhanden ist, etwa mit Ping, in umfangreichen Setups auch gern mit einer API zum Remote Server. Schlägt der Test fehl, wird das Interface hochgefahren, wenn der Server verfügbar ist, bleibt das Device deaktiviert.

Wie gesagt, ist eine einfach Lösung um für wenig Geld ein HA Cluster aufzusetzen. Wenn man GlusterFS oder ähnliches einsetzt, bleibt der Datenbestand auch schön konsistent.

[S1lv3R]

Ja, hochgefahren dürfen die IPs nicht auf allen Servern sondern nur auf einem. Ober man das über eine Konfig mach oder über ifconfig oder ähnliches ist egal.

Erstmal: Das ist ein durchaus interessantes Thema, das mir auch öfters mal durch den Kopf geistert. Sozusagen poor-men's-webcluster mit zwei dedizierten Servern. Die Ausführungen bzgl. des VLANs finde ich auf jeden Fall sehr spannend.

Was mich sehr interessieren würde, ist ob ihr denkt das die beschriebene Lösung mit ifup + gratuitous arp ohne weitere Maßnahmen sicher stellen kann, dass es nicht zu einer Split-Brain-Situation kommt sobald der ausgefallene Node zurückkommt? Denn dann kan man sich die nächsten 3 Wochen ja damit beschäftigen Datenbanken zu mergen ...

@nemix Jetzt bin ich allerdings auch verwirrt. Kennst du etwa eine super geheime Methode, wie man SSL ohne eine IPv4-Adresse je Zertifikat effektiv betreiben kann, die bisher vor dem Rest der Menschheit verschlossen war? Jeder Kunde kreuzigt dich doch sobald du SNI oder (fast noch schlimmer) SAN-Zertifikate benutzt.

Grüße,
S1lv3R

[strex]

Ja, hochgefahren dürfen die IPs nicht auf allen Servern sondern nur auf einem. Ober man das über eine Konfig mach oder über ifconfig oder ähnliches ist egal.

Gracious ARP würde ich folgend versenden:

arping -c 4 -A -I {interface zum VLAN} {IP-Adresse} 
(e.g. arping -c 4 -A -I eth1.2000 1.2.3.4)

[Kaimane]

Es muss nur sichergestellt sein, dass nicht die IP auf beiden Servern aktiv ist, sonst kommt es zu dummen Problemen.

Aktiv bedeutet, das Interface darf nicht auf beiden Servern "hochgefahren", aber die Konfiguration als solches darf auf beiden vorhanden sein?
Kurze Frage noch zum gratuitous arp:

arping -U -I eth0.xxxx.y zzz.zzz.zzz.zzz

Wobei

• xxxx das VLan ist
• y Interface-ID
• zzz die Failover IP aus dem Ripe-Block

Passt das so?

[strex]

Ja das ist korrekt, die Interface Konfiguration ist abhängig vom genutzten OS. Es muss nur sichergestellt sein, dass nicht die IP auf beiden Servern aktiv ist, sonst kommt es zu dummen Problemen.

[Kaimane]

Lässt sich eigentlich recht einfach lösen. vRack mit Ripe Block bestellen. Zwei Server hinzufügen. Auf beiden ein Script (Bash, Perl, php,..) entwickeln, dass gegenseitig prüft ob der andere noch aktiv ist (eventuell nur ein master/slave setup). Das kann auf ping oder sonst was geschehen und muss nicht aufwendig sein. Ist das nicht der Fall, ein Interface hochfahren mit der IP (e.g ifup eth0:1..), die überwacht wurde. Dann einen gracious arp versenden, damit der Router die neue MAC kennt und es läuft. Wenn kein gracious arp, dann das Interface mit derselben MAC hochfahren. Ein paar Pakete gehen verloren aber sollte für den Einsatz reichen.

Vielen Dank für den Ansatz, strex.
Dann hab ich ja viel zu kompliziert gedacht (Heartbeat, Pacemaker, etc.)

Praktisch heißt das also, dass ich auf beiden Servern in der /etc/network/interfaces alle benötigten IPs (von Server A und B) aus dem Ripe Block wie beschrieben (http://hilfe.ovh.de/RipeVrack#link4) konfiguriere (inkl. route und rule pro IP) und nur die Interfaces auf dem jeweiligen Server hochfahre, die auch für diesen benötigt werden.
Die anderen Interfaces sind zwar konfiguriert, aber down, damit der jeweils andere Server sie verwenden kann.

Fällt nun Server A aus, reicht auf Server B also ein simples ifup auf die jeweiligen Interfaces / IPs von Server A aus, um diese zu übernehmen.
Ein anschließendes "gracious arp" rundet die Sache dann ab.

Hab ich das so richtig verstanden?
Bitte korrigieren, falls es doch anders ist

Nochmals Danke strex!

[strex]

...
Wie löst ihr das?
Arbeitet ihr in einem solchen Fall mit Heartbeat / Pacemaker?

Wäre über Lösungsansätze dankbar.

Lässt sich eigentlich recht einfach lösen. vRack mit Ripe Block bestellen. Zwei Server hinzufügen. Auf beiden ein Script (Bash, Perl, php,..) entwickeln, dass gegenseitig prüft ob der andere noch aktiv ist (eventuell nur ein master/slave setup). Das kann auf ping oder sonst was geschehen und muss nicht aufwendig sein. Ist das nicht der Fall, ein Interface hochfahren mit der IP (e.g ifup eth0:1..), die überwacht wurde. Dann einen gracious arp versenden, damit der Router die neue MAC kennt und es läuft. Wenn kein gracious arp, dann das Interface mit derselben MAC hochfahren. Ein paar Pakete gehen verloren aber sollte für den Einsatz reichen.

[Kaimane]

@nemix: Grundsätzlich hast du recht. Kann man auch alles hier (http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI) und hier (http://de.wikipedia.org/wiki/Server_Name_Indication) nachlesen.

Das lässt sich auch alles genauso umsetzen wie du sagst, dann benötigt man nur eine Failover IP pro Server und alles ist gut. Das wäre der Weg.

Nur was ist mit alten Browsern und Betriebssystemen, die das erweiterte SSL-Protokoll nicht verstehen? Unter anderem ist das bei Windows XP der Fall. Windows XP wird noch von 20% der Deutschen (Stand: 09/2012) verwendet.
Sollen die "ausgesperrt" werden?

Ich lasse mich gerne davon überzeugen, dass es nicht so ist.
Freue mich über Antwort.

=== EDIT ===
Ich muss mich korrigieren.
Es ist kein globales XP Problem. Nur der Internet Explorer (alle Versionen) auf Windows XP "kennt" SNI nicht. Firefox, Chrome, etc. auf XP ist kein Problem. Hier funktioniert SNI. Aber dennoch gibt es immer noch genug User im Web, die mit einem Internet Explorer und Windows XP arbeiten.

Von daher ist SNI immer noch eine suboptimale Lösung ... Auch wenn "nur" User mit XP und IE "ausgesperrt" werden. Wobei ausgesperrt nicht im wortwörtlichen Sinne zu verstehen ist.

[nemix]

Zwei Server, mehrere IPs pro Server (SSL-Zertifikate)

Wie wäre es auf das Gebastel verzichten und Apache/IIS richtig konfigurieren? Für SSL brauch man nicht mehr mehrere IP Adressen .

Ansonsten würde ich dir zu den Cloud Angeboten raten.

[Kaimane]

Über SOAP läuft das Switchen der Failover IPs sehr gut. Allerdings kann man maximal 3 Failover IPs pro Server setzen (Quelle: OVH Support).
Hat man also auf Server A zwei Failover IPs und auf Server B ebenfalls zwei Failover IPs, kann eine der vier IPs im Failover-Fall nicht auf den anderen Server "umgezogen" werden.

Aus diesem Grund macht ein RIPE-Block auf einem VRack mehr Sinn, wenn im Ganzen mehr als drei IPs auf einen Server zeigen sollen.

Genau vor dieser Situation stehe ich gerade.
Zwei Server, mehrere IPs pro Server (SSL-Zertifikate).
Anders als bei klassischen Failover IPs dürfen die IPs aus dem vRack RIPE-Block nicht zur gleichen Zeit auf beiden Server bekannt sein (IP-Adressen Konflikt).

Da ich ohne VMWare, Load Balancer, etc. auskommen möchte, ist der einzige Weg, dass die beiden Server sich ständig gegenseitig überprüfen und im Falle einer Nichterreichbarkeit eines Servers die IPs vom anderen Server auf sich routen.

Wie löst ihr das?
Arbeitet ihr in einem solchen Fall mit Heartbeat / Pacemaker?

Wäre über Lösungsansätze dankbar.

[chi]

Hallo,

Ich hatte mal einen Cluster am laufen.
Als Basis kam Proxmox 1.9 zum Einsatz.

Geclustert wurde ein OpenVZ Container -> DRBD, Heartbeat.
Address switching improvisiert über die SoAPI nach dieser Anleitung:

http://blog.guiguiabloc.fr/index.php/tag/ovh/page/2/

Die Configs habe ich leider nicht mehr da und auswendig auf die schnelle.

Lies es dir mal durch - Letztes Drittel der Seite.

Mit Heartbeat wurden die Scripte ausgeführt und auf den jeweiligen Server geswitcht.

[dotbizz]

Außerdem dürfte die private Cloud eine gute Alternative darstellen -> http://www.ovh.de/private_cloud/

Allerdings bin ich dann automatisch an VMware gebunden und die Kosten übersteigen die der "Strex-Lösung"

[strex]

Er kann das auch mit der SOAP (http://www.ovh.com/soapi/de/) selbst basteln. Das vRack mit eigener Testverfahen ist aber die Beste Lösung.

[mathias]

Hallo,

nur kurz ergänzend zu unserem Telefonat
Die Loadbalancing-IP ist für neue Server bzw. die Server in den neuen Rechenzentren nicht mehr verfügbar.
Das VRack erkennt nicht den Zustand oder die Auslastung einer Maschine. Die Basis für die Erstellung einer eigenen Infrastruktur bietet es trotzdem.

Außerdem dürfte die private Cloud eine gute Alternative darstellen -> http://www.ovh.de/private_cloud/

Mathias

[strex]

OVH sagt: "Damit ginge es nicht !" und ich bin leicht verwirrt.

Du kannst zwei 1 GBit/s Server in das vRack einfügen. Da fügst du diesem Szenario noch einen Storage Server hinzu. Beide Nodes greifen auf den Storage Server zu. Damit dieser wirklich HA anbieten kann, muss dieser Redundant ausgeführt sein. Mindestmenge an Server in diesem Szenario sind als 4x 1 Gbit/s Server.

Wenn das alles steht, die Storage Server an die Nodes gebunden sind, kannst du ein IP Subnet bestellen und dieses auf das vRack routen lassen. Sobald es dann im vRack ist, können beide Server das Subnet gleichzeitig nutzen. Jetzt musst du nur noch VMWare konfigurieren, dass die Nodes prüft, ob ein Ausfall besteht und dann die andere Maschine hochfährt.

Das Ganze wird aber das Budget sprengen, da für HA mit automatic switching wohl eine Lizenz benötigt.

Fertig Scripte gibt´s nicht.

[dotbizz]

Entweder über die API zum Wechsel der Failover IP.

Meine Coder-Kenntnisse lassen das nicht zu. Kann jemand ein lauffähiges Script zur Verfügung stellen ?

Danke vorab

[dotbizz]

Was aber viel schöner ist, ein vRack.

OVH sagt: "Damit ginge es nicht !" und ich bin leicht verwirrt.

[strex]

Entweder über die API zum Wechsel der Failover IP. Was aber viel schöner ist, ein vRack. Das solltest du aber beim studieren der Webseite von OVH schon gelesen haben.

[dotbizz]

Hallo,
ich möchte 2 EG-Server mit Proxmox oder VMWare im High Availability Cluster betreiben. Server installieren und konfigurieren soweit alles kein Problem. Die Host-IP´s der beiden Server werden von OVH vergeben.
Meine RIPE-IP´ kann ich nun einem (!) der beiden Server zuordnen. Ebenso die Zuordnung ist die MAC-Adressen die zum Beispiel für eine Proxmox VM Zuordnung seitens OVH benötige, da sonst der OVH-Switch zumacht.
IP/MAC-Adresse hängen aber nun an diesem einen Server! Nun muss aber beim Ausfall und somit wechsel des Servers wegen Ausfalls genau diese IP der VM auf den anderen Server zeigen.

Nun aber zur Problemstellung.
Wie schaffe ich einen IP/MAC-wechsel ??? - NEIN nicht manuell
Lösung wäre ist ein IP-Balancing - klar!.
Das "Tool" Loadbalancing-IP im OVH Manager wird nicht mehr von OVH bedient. Alternative II wäre eine CISCO Load-Balancer (Bei 1Gbit Anbindung für schlaffe 2500 €/mtl. nicht wirklich die Wahl der Stunde).

Wie schaffen es gleichgesinnte dieses Problem zu beherschen ?
Bin für jede Anregung dankbar, die mein Budget nicht sprengen.

Gruß