IP nummer meenemen naar nieuw datacenter

[Verwijderd]

Binnenkort mag ik een windows server gaan verhuizen van datacenter A naar datacenter B. Op deze server staan een paar honderd domeinen, geregistreerd via verschillende partijen, dus de kans dat er iets "achterblijft" is vrij groot. Ik zit er dan ook aan te denken om tijdelijk het oude ipnummer "mee te nemen" en de Windows server "virtuele multihoming" te geven.

De opties die ik heb bedacht:
port forwarding
via xinetd, iptables, of 1 van de vele andere oplossingen.
voordelen:

• makkelijk te doen

nadelen:

• herschrijft source ip, niet veilig, dus niet toegestaan. (o.a. smtp moet doorgestuurd worden, ip herschrijven breekt spamfilters)

routing over een tunnel
[router-van-datacenter-A]---[tunnel-peer-A]====vpn====[tunnel-peer-B]-----[windows machine]
Maak een ipip/gre/openvpn tunnel met 2 tijdelijke linux machines. Stel in de router op datacenter A in dat het ip via tunnel machine A loopt, stel op tunnel machine A in dat het verkeer via tunnel machine B loopt en stel op B in dat hij het verkeer op eth0 moet routeren.
nadelen:

• toegang tot router op datacenter A nodig, dus niet mogelijk
• windows moet assymetric routing kunnen, maar dat denk ik wel
• assymetric routing moet mogelijk zijn in datacenter B (geen anti-spoofing regels)

Zonder toegang tot de router op datacenter A, zal er een machine nodig zijn die antwoordt op ARP requests van de router van datacenter A. De machine moet óf echt aanwezig zijn, óf z'n aanwezigheid moet via poisoning of bridging virtueel ingesteld worden.

bridge tussen de datacenters
[router-van-datacenter-A]---[tunnel-peer-A]====vpn====[tunnel-peer-B]-----[windows machine]
Plaats in beide datacenters een tijdelijke Linux machine die aan beide kanten de eth0 bridged met een openvpn tunnel. (ipip en gre kan je niet in een bridge koppelen). De windows machine heeft 2 ipnummers op z'n "eth0", waardoor zowel naar het nieuwe als het oude ip wordt geluisterd.
voordelen:

• met ebtables redelijk te beveiligen
• transparant voor de windows server

nadelen:

• windows moet assymetric routing kunnen, maar dat denk ik wel
• assymetric routing moet mogelijk zijn in datacenter B (geen anti-spoofing regels)
• ebtables moet goed ingesteld worden, anders zou het storing kunnen veroorzaken
• ... (mis ik nog iets?)

Een bridge lijkt op dit moment de meest logische oplossing. Ik heb een en ander al thuis getest, maar een aantal dingen (met name assymetric routing) is niet zomaar even thuis te testen.

Andere methodes?
Heeft er iemand ervaring met het tijdelijk meenemen van ipnummers naar een ander datacenter? Andere methodes die ik nog niet bedacht had?

[CyBeR]

Is 't dezelfde provider in een ander datacenter? Zo ja, grote kans dat zij je hiermee wel kunnen helpen.

[Verwijderd]

CyBeR schreef op zondag 27 september 2009 @ 15:12:
Is 't dezelfde provider in een ander datacenter? Zo ja, grote kans dat zij je hiermee wel kunnen helpen.

Thanx voor de suggestie, maar het is niet dezelfde provider, helaas. Ik verwacht ook niet al te veel kennis op dit gebied van "datacenter A", zij zijn feitelijk ook alleen maar reseller van een andere partij...

[Boudewijn]

Volgens mij moet je gewoon echt alles overzetten.... via DNS.

[leuk_he]

Boudewijn schreef op zondag 27 september 2009 @ 15:47:
Volgens mij moet je gewoon echt alles overzetten.... via DNS.

In theorie, ja. Maar paar honderd partijen hebben altijd wle een paar rotte appels er tussen die op ip nummer ipv dns werken.

Houd er rekening mee dat de enrypyslag van vpn redelijk cpu intensief is bij grote hoeveelheden data.

bridge klink mij het meest logische.

[jvanhambelgium]

Boudewijn schreef op zondag 27 september 2009 @ 15:47:
Volgens mij moet je gewoon echt alles overzetten.... via DNS.

Inderdaad, als je een servermigratie doet moet je maar goed plannen en voorbereiden ! Geen excuus!
Doe het ineens goed, probeer alles deftig af te dekken, laat alvast DNS TTL's dalen tot vb minder als 1 uur etc. Jij kan perfect op voorhand effe opzoeken welke domeinen/forwards er eventueel hardlinked staan en de nodige contacten verzamelen.

Was is de toegestane "downtime" ? Hoe business-kritisch is hetgeen er op die server draait ? Hoe minder downtime toegestaan is des te strakker het coordineren zal moeten (met de authoritive dns verantwoordelijken)

[Erik Jan]

Gaat het alleen maar over websites (HTTP dus)? Dan neem je in datacenter-A toch een goedkoop dedicated pakketje met behoud van dat IP en stel je een reverse proxy in? Kan je ook mooi loggen welke domeinen nog omgezet moeten worden.

[Verwijderd]

Allemaal dank voor de suggesties. Ik ga morgen maar eens even spelen met de bridge oplossing die ik zelf voorstelde. Heb ondertussen wat manuals over veilig bridgen via ebtables doorgelezen, en ik kan daar geen problemen in vinden.

Boudewijn schreef op zondag 27 september 2009 @ 15:47:
Volgens mij moet je gewoon echt alles overzetten.... via DNS.

Dat is ook de bedoeling. Alleen niet minuut 1.

leuk_he schreef op zondag 27 september 2009 @ 17:51:
[...]
Houd er rekening mee dat de enrypyslag van vpn redelijk cpu intensief is bij grote hoeveelheden data.

Thanx voor de suggestie. Op zich hoeft het niet cpu intensief te zijn: openvpn kan namelijk ook encryptie-loos werken. Niet veilig, maar ook niet onveiliger dan de HTTP die toch al unencrypted over het lijntje loopt.

jvanhambelgium schreef op zondag 27 september 2009 @ 18:04:
Inderdaad, als je een servermigratie doet moet je maar goed plannen en voorbereiden ! Geen excuus!
[...]
Was is de toegestane "downtime" ?

Het is absoluut onmogelijk om 100 partijen allemaal 's nachts om exact dezelfde tijd hun DNS te laten omzetten, zelfs met 3 jaar voorbereiding. Nog los daarvan zijn er gewoon providers die de TTL gewoon negeren.

Ik heb trouwens het verhaal geschreven met "1 server" in de hoofdrol, dat had ik gedaan om het makkelijk te houden. Het gaat in de praktijk om 6 servers.

De toegestane downtime moet echt minimaal zijn. Meer dan een uur is voor 1 van de servers onacceptabel. Met een reistijd tussen DC-A en DC-B van een half uur is het krap, maar te doen.

Erik Jan schreef op zondag 27 september 2009 @ 18:05:
Gaat het alleen maar over websites (HTTP dus)? Dan neem je in datacenter-A toch een goedkoop dedicated pakketje met behoud van dat IP en stel je een reverse proxy in? Kan je ook mooi loggen welke domeinen nog omgezet moeten worden.

Nee, het gaat ook om andere protocollen. Maar hoe dan ook, reverse proxies wijzigen het ip adres, tenzij je daar weer mpaf/rpaf modules bij installeert (voor apache, voor andere diensten zijn er vast andere modules).

[Verwijderd]

De toegestane downtime moet echt minimaal zijn. Meer dan een uur is voor 1 van de servers onacceptabel. Met een reistijd tussen DC-A en DC-B van een half uur is het krap, maar te doen.

Als een uur maximaal acceptabel is en je een half uur reistijd hebt (uitbouwen inladen uitladen inbouwen meegerekend??) dan zou ik het niet aandurven om die maximale downtijd bij de verhuizing te garanderen.

Het zal geld kosten maar ik zou dan opteren voor een 2e server die volledig hetzelfde is en opgetuigd is in DC-B (met alle extra problemen van routering en DNS van dien). OF de klanten aangeven dat er meer tijd nodig is voor de verhuizing.

Op de manier zoals je voorstelt lijkt het me niet realistisch om minder dan een uur downtijd te garanderen.

[jvanhambelgium]

Technisch zal zo'n bridged setup wel werken, indien de applicaties op de hiermee overweg kunnen. Je zal inderdaad ook assymetrie hebben indien je in multihoming werkt.
Mischien ook eerst wat testen of de performantie goed is en geen impact heeft op de applicaties.

Ik vind de vooropgestelde downtime van 1 uur wel weinig, er zijn dan 6 servers te doen + reistijd etc.


Trouwens, ik weet niet met welke datacenters jij werkt, maar wij zouden nooit accepteren dat onze IP space buiten onze perimeter (her)gebruikt zou worden in combinatie met een link tussen de 2. Dus zo'n spielerij als bridged extensies in een datacenter van de concurrent met onze IP's zijn no-go. Eerst effe samenzitten met engineering om te bestuderen wat de opties zijn ;-)

Een prima bypass van een security perimeter! Ga je even wat ethernet-frames bridgen over een getunnelde ip-link naar een andere locatie.

Ik ken natuurlijk de details niet, welk soort contracten je hebt, welk soort datacenter-diensten je afneemt etc.

[Verwijderd]

Is het geen optie om een tweede webserver te kopen, en die op de nieuwe locatie te plaatsen? Je kan de sites dan op je gemakje stuk voor stuk overzetten

Misschien een beetje duurder, maar wel makkelijker

[Verwijderd]

Hmm, misschien is 1 uur niet realistisch voor 6 servers. Maar als ik 2 servers (de belangrijkste 2) binnen een uur weer up heb, is het goed. De andere 4 zijn toch kleine shared hosting servertjes.

jvanhambelgium schreef op zondag 27 september 2009 @ 23:08:
Technisch zal zo'n bridged setup wel werken, indien de applicaties op de hiermee overweg kunnen. Je zal inderdaad ook assymetrie hebben indien je in multihoming werkt.
Mischien ook eerst wat testen of de performantie goed is en geen impact heeft op de applicaties.

Ik verwacht tijdens de verhuizing 90% van het verkeer naar DC-B te kunnen omzetten. Dit zou eigenlijk het vangnet zijn voor de laatste 10%.

Trouwens, ik weet niet met welke datacenters jij werkt, maar wij zouden nooit accepteren dat onze IP space buiten onze perimeter (her)gebruikt zou worden in combinatie met een link tussen de 2. Dus zo'n spielerij als bridged extensies in een datacenter van de concurrent met onze IP's zijn no-go. Eerst effe samenzitten met engineering om te bestuderen wat de opties zijn ;-)

Hm, goed punt. Alleen heeft DC-A niet zoveel netwerk-kennis in huis omdat het zelf ook alleen maar een reseller is. Denk dat ik straks nog maar even belletje er aan waag, en als het niet lukt, dan gaan we eerst maar eens de bridged oplossing in de praktijk testen...

[analog_]

VPN tunnel opzetten en vervolgens ervoor zorgen dat alle traffiek over de tunnel loopt, niks asymetrische routing Dan test je de nieuwe locatie met een minder belangrijke server (qua downtime) om de tunnel te testen en daarna verhuis je die kritische server midden in de nacht.

[CyBeR]

Asymmetrie is niet boeiend. Wel boeiend is dat als je 't volledig terug VPN't dat je dan op twee plekken betaalt voor je verkeer. Het komt niet vaak voor dat colo-netwerken uitgaande filters hebben op IP space, dus je kunt waarschijnlijk prima gewoon je oude IP's gebruiken om verkeer mee te versturen in je nieuwe DC. Retourverkeer moet dan inderdaad wel via je tunnel.