[colo] Hoe een aantal servers te verhuizen?

[kvdveer]

We zitten met een lastig probleem, onze huidige COLO heeft plotseling zijn prijzen meer dan verdubbeld, en kondigde aan dat hij de prijzen volgend jaar nog een keer zal verhogen.

Voor ons is een alternatief om (met een bevriend bedrijf) een half 19" rack te huren. Dan hebben we voldoende ruimte voor eventuele uitbreidingen. Het handige is iig dat we de servers ongeveer 5 meter moeten verhuizen. Op zich moet dat niet al te veel problemen opleveren.

Helaas veranderen onze IPadressen ook. Onze DNS-sen zijn grotendeels ondergebracht bij WideXs, waar we ze zelf via een scriptje kunnen aanpassen, helaas doet een DNS-je er een dag of wat over om het internet rond te gaan, en ik ben bang dat we daar optimaal last van gaan krijgen als we gaan verhuizen.

Hoe zorg ik er nou voor dat onze websites niet dagenlang onbereikbaar zijn als we de verhuizing uitvoeren?


(waarschijnlijk niet relevant, naar we draaien twee servers: Redhat ne Debian, bevriend bedrijf draait debian en winnt. Onze servers draaien allebei HTTP, FTP, SMTP en POP/IMAP)

[Verwijderd]

Kun je niet 2 tijdelijke servers gebruiken waar je een kopie van je website opzet.

Die hang je dan als oude webserver in je huidige rek. In de tussentijd kan je rustig de nieuwe server met nieuwe adressen in het nieuwe rek hangen..

[ Voor 0% gewijzigd door Verwijderd op 07-08-2002 15:44 . Reden: typo ]

[Koffie]

Zal wel aan mij liggen, maar een dag vind ik wel erg lang.
Als ik bij ZoneEdit mij IP adressen wijzig dan duurt dit in het meest erge gevaal een uurtje ofzo.

[Verwijderd]

Koffie schreef op 07 augustus 2002 @ 15:43:
Zal wel aan mij liggen, maar een dag vind ik wel erg lang.
Als ik bij ZoneEdit mij IP adressen wijzig dan duurt dit in het meest erge gevaal een uurtje ofzo.

Jep, maar voordat de rest van de wereld het weet .. daar gaat wel even overheen ...

[vandijk]

Je kan je servers verplaatsen, en dan 1 machine nog een paar dagen laten luisteren naar de oude ipadressen. Deze machine stel je dan zo in dat hij de request die hij ontvangt doorstuurd (proxy) naar de juiste machines.

Voor niet-webservers zou je kunnen kiezen voor port-forwarding

Welke provider gebruik je eigenlijk?

[Koffie]

Verwijderd schreef op 07 augustus 2002 @ 15:44:
[...]

Jep, maar voordat de rest van de wereld het weet .. daar gaat wel even overheen ...

Dat bedoelde ik ook.
DNS servers staan in USA , maar binnen een uur is het in NL bekend.

[elTigro881]

Ik heb laatst domeinnamen + hosting verhuisd van een gehuurde dedicated server naar een eigen colocated server . Doordat de oude server net bij het overzetten crashde, de oude provider erg traag reageerde en er een storing bij de SIDN was, zijn de .nl domeinnamen bijna een week onbereikbaar geweest

Een 7-stappenplan dat misschien helpt bij de verhuizing:

1) Stel beide servers in als relay mail server voor de ander (extra MX-record toevoegen aan de DNS), stel sendmail (of whatever) ook daarop in

2) plaats alle websites op beide machines, zorg dat alle requests naar de machine gaan die achterblijft

3) wacht een dag of twee

4) verplaats de eerste server

5) stel nu de hele handel andersom in

6) wacht weer een dag of twee

7) plaats de andere server ook over, zet de instellingen weer terug en het moet werken...

[TheGhostInc]

Niet moeilijk doen, als je om 4 uur 's middags je website down gooid, en vlak ervoor die scriptjes draaid, tegen de tijd dat je dan je servers hebt over gegooid is al 90% van alle mensen voorzien van de nieuwe IP's. Daarna wordt het nacht... dan zullen er dus toch al minder mensen op je website komen, en de volgende ochtend is iedereen weer blij.

Stel dat je een server extra gaat plaatsen, reken dan eens uit wat het je allemaal gaat kosten:
2de server (hoeft niet super duur te zijn), enkele uren config werk, nog meer uren test werk, en je hebt nog niet eens de garantie dat het vlekkeloos gaat.

Dan wordt de hele omzetting ineens 2x zo duur, en welke website mag nou *NOOIT* een paar uur down zijn, zelfs hotmail of google is soms niet bereikbaar.

In het ergste geval kun je altijd de IP's die je krijgt alvast doorspelen aan de mensen die er echt op moeten, en de rest heeft gewoon pech.

[Verwijderd]

Wij hebben onlangs ook zoiets dergelijks gedaan.

ff kort hoe wij het gedaan hebben:

- tweede machiene klaarzetten
- daar qmail zo instellen dat ie alle mail forward naar qmail op nieuw adres
- nameserver goed zetten op temp machiene met nieuwe ip's in
- op temp machiene port-forwarding instellen voor port 80 en 443 (21, ftp gaat niet)
- webserver vervangen door temp server, snel snel webserver verhuizen ... wij hadden een downtime van 15min (als hosting provider is dat aanvaardbaar vind ik, iedereen gaat wel eens down voor onderhoudswerken)
- webserver online gebracht op nieuwe ip's, daar ook alles aangepast naar nieuwe ip's
- zo hadden we een tijdje twee nameservers naast elk kaar draaien
- bij ons duurde het ongeveer 2dagen voor echt alle request rechtstreeks naar nieuwe ip gingen, meeste requests waren na enkele uren al rechtsreeks naar nieuwe ip

[Verwijderd]

Koffie schreef op 07 augustus 2002 @ 15:50:
[...]
Dat bedoelde ik ook.
DNS servers staan in USA , maar binnen een uur is het in NL bekend.

dat is heel erg provider afhankelijk

[Coen Rosdorff]

Zorg ruim voordat je gaat verhuizen ervoor dat de TTL van je dns-records op een uur staat ipv op een dag.

Als je dan de boel verplaatst hebt en de dns aanpast is het binnen een uur helemaal in orde.

[kvdveer]

little_soundman schreef op 08 augustus 2002 @ 01:36:
Zorg ruim voordat je gaat verhuizen ervoor dat de TTL van je dns-records op een uur staat ipv op een dag.

Als je dan de boel verplaatst hebt en de dns aanpast is het binnen een uur helemaal in orde.

Helaas heb ik bij widexs geen invloed op de ttl van mijn dns.

We hebben twee servers, die allebei overcapaciteit hebben.

Huidige plan van aanpak:


1 Verhuis alle websites naar server 2 (red hat), laat phpscripts hun sql bij server 1 (debian) vandaan halen. (sql.onsdomein.nl in /etc/hosts)
2 Stel portforwarding op server 1 (debian) (poorten SMTP, IMAP, POP, WWW) in als doorverwijzing naar server 2 (red hat).
3 Pas alle DNSsen aan.
4 Wacht een dag. (koffie, pizza, bier)
5 Verplaats de databases naar server 2 (red hat) en wijzig sql.onsdomein.nl in /etc/hosts
6 Ruk server 1 (Debian) uit het rek.
7 Vervang de oude potato installatie op server 1 (debian) door een kersverse woody.
8 Plaats server 1 (debian) in het nieuwe rek.
9 Verhuis de database naar server 1 (debian) . (weer /etc/hosts aanpassen)
10 Schakel alle uploadscripts uit. (stuk of 4, allemaal in admins)
11 Kopieer alle bestanden en scripts naar server 1 (debian) .
12 Pas alle DNSsen aan. (incl. MX)
13 Zet alle uploadscripts op server 1 (debian) weer aan.
14 Wacht een dag. (koffie, pizza, bier)
15 Verhuis ook server 2 (red hat) naar het nieuwe rek.


Gaat dat werken? (vooral die portforwarding) het zijn allebei 2.2 kernels.

[ Voor 0% gewijzigd door kvdveer op 09-08-2002 10:22 . Reden: de [number] tag is nog niet optimaal ]

[kvdveer]

BTW: We hosten bij luna.nl in Rotterdam.

[PROnline]

Weet niet 100% zeker of het werkt, maar in theorie klopt het volgens mij wel.
voeg alvast die nieuwe ip's toe aan de machines. Linux en windowsNT kunnen met meerdere ip-adressen werken. Dat weet ik wel. Zet vervolgens de DNS over op de nieuwe IP's. Wacht een aantal dagen dat de DNS wijziging over de hele wereld bekend is. Verplaats de machines en verwijder de oude ip-adressen.

[kvdveer]

PROnline schreef op 09 augustus 2002 @ 10:38:
Weet niet 100% zeker of het werkt, maar in theorie klopt het volgens mij wel.
voeg alvast die nieuwe ip's toe aan de machines. Linux en windowsNT kunnen met meerdere ip-adressen werken. Dat weet ik wel. Zet vervolgens de DNS over op de nieuwe IP's. Wacht een aantal dagen dat de DNS wijziging over de hele wereld bekend is. Verplaats de machines en verwijder de oude ip-adressen.

Hiervan willen we gebruik maken bij de verhuizing: Verhuis alle dnssen van domein x naar ipadres 217.77.130.1. Wacht een dag. Verwijder ipadres 217.77.130.1 op server 1, en voeg 'm toe aan server2. Verander DNS zodat 'ie naar server 2 verwijst...

Ik heb deze techniek nu eenmaal toegepast, en het werkt subliem. Aangezien we 4 "ongebruikte" ipadressen hebben, kunnen we 4 domeinen tegelijk verhuizen. IVM DNS traagheid duurt een verhuizing ongeveer een week. Om alle 26 domeinen te verhuizen hebben we dus ongeveer 2 maanden nodig.

[elTigro881]

PROnline schreef op 09 augustus 2002 @ 10:38:
Weet niet 100% zeker of het werkt, maar in theorie klopt het volgens mij wel.
voeg alvast die nieuwe ip's toe aan de machines. Linux en windowsNT kunnen met meerdere ip-adressen werken. Dat weet ik wel. Zet vervolgens de DNS over op de nieuwe IP's. Wacht een aantal dagen dat de DNS wijziging over de hele wereld bekend is. Verplaats de machines en verwijder de oude ip-adressen.

Dit gaat denk ik niet werken...
Dat zou betekenen dat je ook jouw pc thuis kan laten draaien op een ip-adres dat je niet gebruikt...
Een server zit achter een router, die ingesteld is voor een bepaalde ip-range, en zomaar overzetten naar een andere router gaat dus *niet* werken

[kvdveer]

We gaan niet verhuizen naar een andere colo... We blijven in dezelfde ip-range... (217.77.x.x) De fysieke verhuizing is ongeveer 5 meter, maar mogelijk is het zelfs maar 30 cm.

Ik hoop heel stiekum dat we onze oude ip-adressen nog even een maandje kunnen gebruiken, dat zou het een en ander nog een stuk eenvoudiger maken. routeringstechnisch moet het niet al te moeilijk zijn, aangezien dat serverhok volgens mij niet verder is onderverdeeld. Alleen is het zo dat bij ons abonement we een 'eigen' range ipadressen krijgen, en we de oude ipadressen terug moeten geven...

[kvdveer]

elTigro schreef op 09 augustus 2002 @ 15:08:
[...]

Dit gaat denk ik niet werken...
Dat zou betekenen dat je ook jouw pc thuis kan laten draaien op een ip-adres dat je niet gebruikt...
Een server zit achter een router, die ingesteld is voor een bepaalde ip-range, en zomaar overzetten naar een andere router gaat dus *niet* werken

Kun je dit eens uitleggen?

Mijn idee van portforwarding is als volgt (correct me if i'm wrong):

Client verstuurt een IP-pakketje: client:1024-> server1:80
Een router plaatst het pakketje op het segment waar Server 1 zit
Server 1 verstuurt dit pakketje opnieuw: server1:1024 -> server2:80
Een router plaatst het pakketje op het segment waar Server 2 zit
Server 2 ontangt het pakketje en reageert: server2:80 -> server1:1024
Een router plaatst het pakketje op het segment waar Server 1 zit
Server 1 verstuurt dit pakketje opnieuw: server1:80 -> client:1024
Een router plaatst het pakketje op het segment waar Client zit.
Client ontvangt dit pakketje.

Ik zie hier nergens een situatie die een router niet zou lusten... Alle pakketjes zijn geldig. Alleen Server2 denkt dat 'ie zit te praten met Server1 ipv Client.

edit:

Ik bedenk me nu dat dit effect waarschijnlijk transparant proxying heet, en niet portforwarding. Hoe portforwarding dan werkt weet ik niet, moet daarvoor Server2 Server1 toevallig als primary gateway hebben?

[elTigro881]

kvdveer schreef op 09 augustus 2002 @ 16:43:
[...]

Kun je dit eens uitleggen?

Mijn idee van portforwarding is als volgt (correct me if i'm wrong):

[...]

Ik zie hier nergens een situatie die een router niet zou lusten... Alle pakketjes zijn geldig. Alleen Server2 denkt dat 'ie zit te praten met Server1 ipv Client.

Waar ik op reageerde was het simpelweg overzetten van IP-adressen, dat gaat niet zomaar werken, dan moet je toch echt de router configureren. De situatie die jij schetst gaat denk ik wel werken.
'Gewoon' IP-adressen overzetten niet. In jouw situatie blijf je nog steeds met twee servers werken.

[Fish]

Zorg dat je servers NU al, naar beide (oud en nieuwe) adressen tegelijk luisteren

(dat kan onder NT,en vast ook onder linux zeker)

zet een dag later je dns om

en klaar

[kvdveer]

fish schreef op 09 augustus 2002 @ 23:17:
Zorg dat je servers NU al, naar beide (oud en nieuwe) adressen tegelijk luisteren

(dat kan onder NT,en vast ook onder linux zeker)

zet een dag later je dns om

en klaar

Zoals in de post boven je is beschreven, gaat dat niet werken, aangezien we dan wèl met een routeringsprobleem zitten. (IP-spoofing protection)

[elevator]

de oplosing van little_soundman om de TTL lager zetten is de meest handige, ook al als er onverhoopt iets mis mocht gaan met de nieuwe locatie. Ik zou zeggen neem even contact op met WideXS - die zullen vast wel tijdelijk de TTL van je domainen lager willen zetten als je even uitlegt wat je van plan bent.