Hetzner umzug auf neuen Server IPs umleiten

Mordor

Mordor

Registered User
Hallo zusammen,
wir sind gerade dabei einen unserer EX4 auf einen EX40 zu migrieren. Der EX4 hat ein 16er Subnetz inne, welches auf den neuen EX40 umziehen soll. Nur leider ist es Hetzner nicht mögliche, das Subnetz in der Nacht umzuziehen.

Warum muss das Subnetz in der Nacht umziehen?
Es laufen auf dem EX4 mehrere Mailsysteme mit relativ großen Mailstores. Das Problem ist, dass ich nach dem Umschalten des Subnetzes die Mailfolder ein letztes Mal Syncen muss. Dies dauert jedoch ein bzw. zwei Stunden. Die hätte zur Folge, dass unsere Kunden ab 16:30 Uhr (das ist der spätest mögliche Termin für das Umschalten bei Hetzner) keine Mails für mehrere Stunden empfangen können und auch nicht versenden können.

Da mittlerweile relativ viele Domains auf die einzelnen Mailsysteme zeigen und auch eine virtualisierte Webmaschine mit mehreren Domain hier laufen, wollten wir eben das komplette Subnetz umziehen.

Jetzt ist die Frage ob es eine Möglichkeit gibt, dass wir und vorrübergehend für den EX40 ein weiteres Subnetz schalten lassen, und die IPs in der Nacht nach dem Sync vom EX4 auf das neue Subnetz des EX40 umleiten lassen. Wenn dann alle Maschinen sauber migriert sind, kann dann am nächsten Tag das alte Subnetz mit umziehen.

Nach was für einer lösung suche ich da?
 
Du könntest per iptables und IPsec jede einzelne IP auf den neuen Server leiten und dort nutzen. Anschließend stellst du gemütlich tagsüber die IPs um.
 
Das würde aber heißen, ich muss mir erst ne VPN-Schichte basteln, was wiederum Last auf dem alten System erzeugen würde. Genau das wollte ich vermeiden, denn der Umzug findet mit unter deshalb statt, weil das System teilweise hohe Last verursacht.

Ich bin mittlerweile auf iptables und NAT gestossen, und stell mir die Frage, ob das mit nur einem Netzwerkinterface funktionieren könnte.
 
Klappt mit NAT ohne Probleme und verursacht auch nicht wirklich Load auf dem alten System. Wir bieten NAT Tunnel zum Schutz vor DDoS an und haben auch Kunden, welche diesen verwenden, um bspw. komplette Exchange Server zu schützen. Hier ein Beispiel entsprechender NAT Regeln für iptables:

Code: 
iptables -t nat -A PREROUTING -p tcp -d $src_ip --destination-port 25 -j DNAT --to-destination $dst_ip:25
iptables -t nat -A POSTROUTING -p tcp --dst $dst_ip --dport 25 -j SNAT --to-source $src_ip
iptables -A FORWARD -p tcp -d $dst_ip --dport 25 -j ACCEPT
iptables -A FORWARD -p tcp -s $src_ip --dport 25 -j ACCEPT
Und ja, das funktioniert auch mit nur einem NIC, da die Regeln nur auf src und dst IPs zutreffen und nicht etwa auf ein Interface.
 
Das hilft mir weiter. Also benötige ich ein Übergangssubnetz auf der neuen Maschine, und kann dann die IPs für die einzelnen open-VZ Container durchreichen.
 
So, und warum bekomme ich jetzt vom Hetzner Support ne Mail, dass sie nicht verstehen was wir vor haben. ;-)
 
Wie genau hast du's denen denn erklärt? Wir möchten die Mailserver Ports vom alten Server und deinen aktuellen IPs per NAT auf den neuen Server mit anderen IPs weiterleiten, während die aktuellen IPs auf beiden Servern konfiguriert sind. Sobald das Subnet dann auf den neuen Server "verschoben" wurde, kann man das vom alten Server entfernen und die IPs sollten sofort ohne Downtime/Sync/NAT online sein.
 
Es zieht ja ein komplettes 16er Subnetz nach der Migration um. Ich glaub denen war nicht bewusst, dass wir hier 2TB Daten nicht mal schnell in fünf Minuten Syncen . Vorallem ist das System ja auf dem neuen Server nach der 12 Std. Migration nicht mehr aktuell und muss nachgesynct werden, was nochmal ca. 4 Stunden sind, denn Rsync muss ja die 2TB durchgucken ob da was neues dazu gekommen ist.

Und nachdem wir das ohne Downtime haben möchten, gehts eben ned ohne Umleitung. So in der Art wurde das auch komuniziert.
 
Mit einem Failover-Subnetz (gibt es bei Hetzner) wäre das nicht passiert...

Ich nehme an ihr müsst die IPs behalten weil ihr sonst allen Kunden DNS-Änderungen zumuten müsstet...

Der Trick mit DNAT plust SNAT über IPTables klappt wunderbar, was euch bleibt ist die Rsync-Lücke.

Hier kann man sich ggf. mit lsyncd abhelfen, da dieser nach dem ersten rsync über inotify-Watches dann nur noch die Änderungen abgleicht.

Vorgehen wäre also:

lsyncd anschmeissen, ersten vollen rsync abwarten
lsyncd läuft, beide Server sind (nahezu) synchron
Dienst auf Quellserver abschalten, die letzten lsyncd-Änderungen abwarten
iptables-Umleitung aktivieren

Damit ist die Downtime minimal, weniger geht in dem Setup dann nicht mehr.
 
Wenn ein kurzer Ausfall hinnehmbar ist und die Server im gleichen RZ stehen, könnt ihr auch einfach die Festplatten umbauen lassen. So etwas bietet Hetzner an.
 
Ich hätte auch den Festplattenumbau empfohlen. So wie du schreibst gibt es ja nur ein Last- und kein Platzproblem.

Ob du dann lokal die Festplatte noch mal spiegelst oder nicht wäre dann ggf. wurscht.

Das wäre meine erste Wahl.
 
Der Festplattenubau fällt aus, da im alten System ein Software-RAID 1 gelaufen ist, und im neuen System ein Hardware-RAID 5 mit vier Platten läuft weil wohl irgendwann auch der Platz zu wenig werden wird. Außerdem Migrieren wir von Open-VZ zu Proxmox, was wohl eher das kleiner Problem gewesen wäre beim Festplattentausch.

Ich hätte auch kein Problem, wenn die Systeme in der Nacht mal für zwei oder drei Stunden nicht erreichbar sind. Die Mails werden ja dann zugestellt, sobald der Server wieder online ist. Und drei Stunden sind hier nicht das Problem. Aber Nachdem Hetzner spätestens um 16:00 Uhr umstellen kann, und bei den Meisten Kunden aber bis 20:00 gearbeitet wird, ist das eher ein Problem. In der Früh umstellen halte ich für nicht gut, denn dann muss ich mich drauf verlassen, dass die System zu 100%laufen. Deshalb würde ich gerne in der Nacht umstellen, dann hat man evtl auch noch mal ein oder zwei Stunden Zeit, um auftauchende Fehler zu bereinigen.

Ich werde jetzt die Methode mit NAT lsyncd anwenden. Als test werde ich heute Nacht ne kleine Webmaschine von uns selbst umziehen, und testen auf welche Probleme ich stoße. Das ist nur ein Bugtrackingsystem, wenn das mal ne Zeit offline ist, rennt mir zumindest kein Kunde die Bude ein.
 
Irgendwie steh ich grad auf dem Schlau.

Wenn ich es mit dem Regelwerk von oben versuche:
Code: 
iptables -t nat -A PREROUTING -p tcp -d $src_ip --destination-port 25 -j DNAT --to-destination $dst_ip:80
iptables -t nat -A POSTROUTING -p tcp --dst $dst_ip --dport 80 -j SNAT --to-source $src_ip
iptables -A FORWARD -p tcp -d $dst_ip --dport 80 -j ACCEPT
iptables -A FORWARD -p tcp -s $src_ip --dport 80 -j ACCEPT
Dann passiert garnichts, und die Anfragen laufen ins Nirvana.

Also hab ich mich im Netz mal auf die Suche gemacht und das hier ausprobiert:
Code: 
iptables -t nat -A PREROUTING -p tcp –dport [AnkunftsPORT]-j DNAT –to-destination [ZielIP]:[ZielPORT]
iptables -t nat -A POSTROUTING -p tcp –dport [AnkunftsPORT] -j MASQUERADE
Alles gut und schön, die Anfrage für Port 80 wird auch weiter geleitet. Jedoch antwortet der Apache, dass er die URL nicht kennt. Ändere ich die Apache IP auf das Übergangssubnetz, geht das alles auch. Nur mit der alten/neuen IP die der Server später bekommen soll, gehts eben nicht.

Wo liegt da mein Fehler?
 
Hier noch mal ein Nachtrag:
Am Apache kommt auf der neuen VM nichts an. Bei den Forwardregeln in Iptables sehe ich, dass Pakete zur neuen VM hingeschickt werden, jedoch nichts zurück kommt.

In der nat-Tabelle werden nahezu die gleiche Anzahl Pakete für DNAT und SNAT verzeichnet.

Mehr weitere Infos hab ich grad nicht.
 
Funktionieren sollten meine NAT-Regeln ohne Probleme. Wenn sie "nichts tun" --> sysctl -w net.ipv4.ip_forward=1 (wie remote_mind schon erwähnt hat, sehe ich gerade)
 
Die sysctl.conf sieht so aus:
Code: 
#net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.ip_forward=1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.eth0.proxy_arp=1
Sollte also passen.

Vielleicht liegts auch irgendwie an der restlichen conf. hier noch mal wies augebaut ist:

Host 1, hier liegen mehrere Open-VZ Container. Nehmen wir mal an, Host 1 hat die IP 1.1.1.1
Host 2, hier sollen die Open-VZ Container hin. Nehmen wir mal an, der hat die IP 2.2.2.2

Jetzt möchte ich von Host 1 den Container 1 umziehen. auf Host 2. Im Host 1 hat dieser die IP 11.11.11.11 im Host 2 die IP 21.21.21.21

vzdump durchlaufen lassen, nen Restore auf Host 2, Container läuft, und bekommt zum einen die IP 11.11.11.11 und 21.21.21.21.

Auf Host 1 direkt hab ich dann folgende IpTables Regeln erstellt:
Code: 
iptables -t nat -A PREROUTING -p tcp -d 11.11.11.11 --destination-port 80 -j DNAT --to-destination $21.21.21.21:80
iptables -t nat -A POSTROUTING -p tcp --dst 21.21.21.21 --dport 80 -j SNAT --to-source 11.11.11.11
iptables -A FORWARD -p tcp -d 21.21.21.21 --dport 80 -j ACCEPT
iptables -A FORWARD -p tcp -s 11.11.11.11 --dport 80 -j ACCEPT

Dabei kann ich sehen, dass in der normale IpTables Tabelle keine Pakete verarbeitet werden. Unter der nat-Tabelle bekommt nur DNAT Pakete, SNAT nicht.
 
Die Regeln sollten so passen. Du könntest die iptables Regeln mal direkt innerhalb des Containers verwenden - vielleicht klappt's dann. Ansonsten noch mal manuell "sysctl -w net.ipv4.ip_forward=1" ausführen und/oder diesen Eintrag ganz unten in die sysctl.conf setzen (ich hab's schon erlebt, dass diese Einstellung von nachfolgenden "überschrieben" wurde).

[...] --to-destination $21.21.21.21:80

Ich denke mal das war nur in deinem Beitrag hier ein Tippfehler?
 
You must log in or register to reply here.
Back
Top