Aug 07, 2017, updated at 08:27:38 (UTC)

1610

Fallover mit Linux

Guten Tag zusammen,
ich habe Provat ein kleines Projekt und finde leider nicht Online.
Folgender aufbau:
1x Hyper-V Host in Rechenzentrum A
1x Hyper-V Host in Rechenzentrum B
1x eine Debian 9 VM in Rechenzentrum C
jede der Server ist mit 1 GBits/sec angebunden ins Internet.
Es herrschen keine lokalen Verbindungen bzw ein VPN zwischen den einzelnen Servern.
Die Hyper-V Hosts gehen über einen Virtuellen Router ins Internet.(Je Hyper-V Host ein Router)

Folgendes Möchte ich versuchen:

(das ist nicht teil der Frage sondern nur zum besser vorstellen)
Hyper-V A und Hyper-V B sollen über das Microsoft VPN System ein Cluster Bilden.

(jetzt zum teil meiner Frage)
Auf dem Cluster werden verschiedene Dienste laufen die mit verschiedenen Ports ins Internet freigegeben sind.
Nun möchte ich das wenn ich Meine-Domain.de eingebe diese Adresse auf Virtuelle Linux Maschine weist.

Diese soll dann folgendes entscheiden:
Wenn Hyper-V Host A nicht erreichbar dann nehme Hyper-V Host B.

Wichtig hierbei ist das es auf reinem Linux laufen muss. Also ich habe keine Möglichkeit zB ein Sophos UTM Iso zu installieren.
(Debian, Ubuntu, Arch,... geht alles.)

Da es ein Hobby Projekt ist bitte keine Diskussion warum das alles

Gerne aber Verbesserungsvorschläge.

LG Dev

Please also mark the comments that contributed to the solution of the article

Content-Key: 345584

Url: https://administrator.de/contentid/345584

Printed on: April 23, 2024 at 20:04 o'clock

20 Comments

Latest comment

Hi,
um es mal auf den Kern zu bringen:
Du hast 2 Hyper-V im Cluster, jeder davon befindet sich in einem anderen Netzwerksegment.
In diesem Cluster läuft eine VM. Ich nehme an, mit automatischem Failover. Also wenn Hyper-V A down, dann soll die VM auf Hyper-V B starten?
Und das Problem ist, dass die IP-Adresse der VM nicht in beiden Segmenten erreichbar ist?
Oder hast Du 2 VM, je eine auf einem Hyper-V, jede eine passende IP-Adresse zum jeweiligen Segment, und je nachdem, welche davon online ist, soll der Zugriff auf die betreffende VM erfolgen?

E.

Meine Kernfrage ist:
Wie richte ich auf dieser VM, die nicht lokal mit den Hyper-Vs verbunden ist, ein Fallover ein.
Ich hatte mir vorgestellt das wenn eine zB Ping Verbindung für 10min abbricht dann automatisch geswitcht wird.
Wie gesagt bessere Vorschläge sind erwünscht.

Wenn Pinge = geht
leite den Trafik an Hyper-V A
Sonst
leite den Trafik an Hyper-V B

Zitat von @Devlorx:
Ich hatte mir vorgestellt das wenn eine zB Ping Verbindung für 10min abbricht dann automatisch geswitcht wird.

Moin
Vermutlich meinst du etwas in diese Richtung? > https://de.wikipedia.org/wiki/Heartbeat_(Informatik)

VG
Ashnod

Moin,

normalerweise man bei solchen Failover-Systeme jedem System seine eigen IP-Adresse und zusätzlich eine IP-Adresse für die Dienste, die per fauilover zu übernehmen sind, zu, die dann per failover von einem zum anderen migriert wird. Das macht das failover-System von sich aus. Da braucht man keinen "Schiedsrichter", der dann "umleiten" muß.

lks

normalerweise man bei solchen Failover-Systeme jedem System seine eigen IP-Adresse und zusätzlich eine IP-Adresse für die Dienste, die per fauilover zu übernehmen sind, zu, die dann per failover von einem zum anderen migriert wird. Das macht das failover-System von sich aus. Da braucht man keinen "Schiedsrichter", der dann "umleiten" muß.

Das funktioniert aber nur dann, wenn das Segment (VLAN) an beiden Hyper-V verfügbar ist. Und bei verschiedenen Standorten müsste man also zuerst ein VLAN haben, welches an beiden Standorten verfügbar ist. Und da bin ich raus: Keine Ahnung ob man sowas über VPN biegen kann.

bei solchen Failover-Systeme jedem System seine eigen IP-Adresse und zusätzlich eine IP-Adresse für die Dienste

Das ist in der Regel aber dann immer in einer Layer 2 Domain, sprich in einem gemeinsamen IP Netzwerk. Geroutet geht das Failover und Replizieren m.E. nicht, da die Heartbeats immer nur im L2 laufen. Müsste ein HA Server Spezi mal beantworten.
Ist dem so muss der TO die Server im Backend mit einem L2 VPN Koppeln, sprich also L2TP oder OpenVPN im Bridging Mode etc.
Damit wäre dann eine Layer2 Kopplung der Server Standorte und damit dann eine Replizierung und ein Failover der beiden VM Server gewährleistet.
Bleibt dann noch die Internet Anbindung bzw. der redundante Zugriff von außen.
Idealerweise macht man das mit einer 2ten NIC, da die RZs ja vermutlich separate Internet Zugänge mit unterschiedlichen öffentlichen IPs haben.
Das löst man dann über einen DNS Server mit Balancing und Failover.
Solange beide Server aktiv sind beantwortet er wechselseitig Requests einmal mit der IP VM-A und mit der IP VM-B um auch die Last zu verteilen (Round Robin).
Denkbar sind hier auch Requests nach Geo IP, sprich der DNS beantwortet Requests je nach Nähe zum Client aber das ist erstmal egal und nebensächlich.
Fällt eine VM aus beantwortet der DNS Requests eben nur noch ausschliesslich mit der IP A oder IP B.
So sähe ein Standard Design aus.
Ist halt immer die Frage wie der TO das Netztechnisch designt oder designen will oder kann. Leider sind die Infos dazu recht oberflächlich so das man hier nur grobe Empfehlungen geben kann.

Moin ...

Gibt ja mehrer Varianten wie man das angehen kann ...

also eine IP unter der der Clusterverbund erreichbar ist ... und die Server mit eigener IP ... dürfte evtl. die Variante für den TO sein?

VG
Ashnod

also eine IP unter der der Clusterverbund erreichbar ist ... und die Server mit eigener IP ... dürfte evtl. die Variante für den TO sein?

Aber wie soll das gehen, wenn die Host an verschiedenen Standorten sind? Wie soll diese eine IP-Adresse des geclusterten Dienstes wahlweise an beiden Standorten erreichbar sein, wenn das über VPN gekoppelt ist?

Edit:
Wenn überhaupt, dann könnte ich mir das nur mit DHCP und dynamischen DNS vorstellen. Also diese eine VM hat keine feste IP-Adresse. Bei Ausfall von Hyper-A wird sie am Hyper-V B gestartet. Dort bekommt sie dann eine andere Adresse und registriert sich damit sofort im DNS. Zugriff auf die VM/die Dienste über FQDN.

Zitat von @emeriks:

also eine IP unter der der Clusterverbund erreichbar ist ... und die Server mit eigener IP ... dürfte evtl. die Variante für den TO sein?

Habe über wiegend versucht den TO zu verstehen

Die VM soll so wie ich es verstehe als Switch dienen ... damit wäre evtl. eine Clusterlösung in dieser Richtung gemeint ...

aber evtl. sagt der TO ja noch was dazu

VG
Ashnod

Aufbau der Hyper-V Hosts
Die Hardware Maschine hat eine eigene öffentliche IP Adresse. Er hostet natürlich verschiedene VMs auf Linux und Windows Basis. Außerdem hostet jeder Hyper-V einen Router. Dieser Router (Sophos UTM ) hat eine eigene Externe IP Adresse sowie ein Class C Netz der dieser per DHCP verteilt.
Somit geht der Hyper-V Host direkt ins Internet.
Die VMS gehen über den Router ins Internet.
Hyper-V Netzwerk und VM Netzwerk sind "Physikalisch" getrennt.

Hallo

ich möchte mein vorhaben mit einem Beispiel erklären:
Ich hoste auf einem der Hyper-V einen Apache2 Server. Dieser soll Hochverfügbar sein.
Das heißt ich erstelle ein Cluster mit einem zweiten hyper-V host. Dieser ist Georedundant.
Nun folgendes Problem. Ich habe bei Strato eine Domain-Name.de .
Es fällt nun der Hyper-V A aus. woher soll Strato jetzt wissen das nun Hyper-V B übernehmen soll.
Darum die Linux VM C, die an vorderster Front stehen soll, das heißt in Strato DNS stehen soll.
Diese VM soll dann entscheiden bzw erkenn welcher Server nun zu Verfügung steht.

Anbei habe ich meine Vision mal in Moderner Kunst verewigt ..^^

Host in Rechenzentrum A

und

Die Hardware Maschine hat eine eigene öffentliche IP Adresse.

Passt irgendwie nicht.

Mir fällt gerade auf: A, B, C ....

1x Hyper-V Host in Rechenzentrum A
1x Hyper-V Host in Rechenzentrum B
1x eine Debian 9 VM in Rechenzentrum C

C? Worauf läuft diese Debian VM?
und

Diese soll dann folgendes entscheiden:
Wenn Hyper-V Host A nicht erreichbar dann nehme Hyper-V Host B.

Ich fürchte, ich habe das Szenario falsch verstanden. Sorry ...

Die Debian VM soll als Witness für die Hyper-V's laufen ...?

Zitat von @Devlorx:
Dieser soll Hochverfügbar sein.

Ich gebe es zu, darauf hatte ich schon gewartet

Diese VM soll dann entscheiden bzw erkenn welcher Server nun zu Verfügung steht.

Mit dem Hochverfügbar ist das so eine Sache. Was ist wenn deine Debian VM oder die Verbindung zu dieser hinkt?

Im wesentlichen stellst du dich damit kein Stück besser.

Ashnod

Die VM C ist ein bei Contabo gemietete VM.
Das mit dem Hyper-V ist so:
Die Hyper-V haben eine Eigene Öffentliche IP Adresse. Diese benötigen Sie auch das ich diese von extern administrieren kann. Außerdem habe ich für den Virtuellen Router eine Extra Externe Adresse da ich bei Hyper-V leider keine Möglichkeit habe zu bridgen.

und was ein Witness ist muss ich zu meiner Schande gestehen weis ich leider nicht. Habe auch in Google bis auf eine Band nichts gefunden :P

Zitat von @emeriks:

Wie soll diese eine IP-Adresse des geclusterten Dienstes wahlweise an beiden Standorten erreichbar sein, wenn das über VPN gekoppelt ist?

L2-VPN , wie von dieversen Kollegen schon angedeutet.

Man könnte natürlich auch den Diensten eine IO-Subnet zuweisem und dann per Routing-Protokoll im Failover-Fall die Routen "umbiegen".

lks

L2-VPN , wie von dieversen Kollegen schon angedeutet.

Man könnte natürlich auch den Diensten eine IO-Subnet zuweisem und dann per Routing-Protokoll im Failover-Fall die Routen "umbiegen".

OK, danke.

Darum habe ich auch keinen 3. Root Server genommen sondern eine VM. Diese sind schon Hochverfügbar. Aber darum geht es auch nicht. Ich will nur schauen wie das alles Funktioniert und keine Produktive Hochverfügbarkeit aufbauen.

Wenn du aber einen Besseren Vorschlag hast kannst du Ihnen gerne teilen.

Zitat von @Devlorx:
Darum habe ich auch keinen 3. Root Server genommen sondern eine VM. Diese sind schon Hochverfügbar. Aber darum geht es auch nicht. Ich will nur schauen wie das alles Funktioniert und keine Produktive Hochverfügbarkeit aufbauen.
Wenn du aber einen Besseren Vorschlag hast kannst du Ihnen gerne teilen.

Die diversen Denkmodelle zu den Themen Failover, LoadBalancing und HA, insbesondere den Ideen das in unterschiedlichen Rechenzentren zu verteilen habe ich mir schon mal angetan. Diese kann man recht gut organisieren. Schwieriger wird der Punkt die Synchronisation/Replikation der Rechner über eine einzelne Leitung zu schleifen auf der auch noch der externe Traffic läuft.

Ein ähnliches Modell was ich bei dir erahnen kann, habe ich in den frühen 2000ern mit dem Stand der Technik von damals umgesetzt.
Datt war nicht lustig und der Aufwand samt gefrickel war einfach zu hoch.
Die Hauptgefahr besteht darin, das man sich an das Gefrickel auch nach einem Jahr oder noch länger gut erinnern muss, wenn sich Änderungen ergeben und sich im Prinzip in seine eigenen Aufzeichnungen erneut einarbeiten muss, wenn das nicht grade tägliches Brot ist.

Der Vorschlag von @aqui ist jetzt auch nicht die 10 Minuten fettich Variante (Auch wenn er das anders sehen mag

), kommt der Lösung für dich aber vermutlich am nächsten.

VG
Ashnod

Zitat von @Devlorx:

Diese VM soll dann entscheiden bzw erkenn welcher Server nun zu Verfügung steht.

Du kannst den Linux Proxy-Server Squid als Failover-Dienst installieren. Bei Google solltest Du auch genügend Beispiele finden. Squid verteilt dann die eingehenden Anfragen automatich auf die Dienste (VMs) die online sind.

Wenn Du bei Strato bist, kannst Du auch die "fertige" Failover-Lösung buchen...

MfG

http://www.squid-cache.org/

http://www.drdobbs.com/implementing-web-server-load-balancing-f/1991021 ...

https://www.strato.de/faq/article/48/So-richten-Sie-das-Feature-ClusterI ...

Clustering mit Linux von Dr. Andreas Müller:

http://failover.othello.ch/linux-clustering-paper.pdf

@ashnod @runasservice @aqui
ich werde die angegebenen Lösungen ausprobieren.
Vielen dank an alle fürs Antworten

Und nein eine fertig Lösung von strato kommt nicht in Frage

German Question Linux

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments

Wireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments