Coloserver verhuizen, hoe zorgen voor weinig downtime

[SA007]

Ik heb een bericht gekregen dat mijn coloserver ermee ophoudt.
Nu moet ik de server dus verhuizen en krijg ik een ander ip adres.

Dat andere ip-adres is erg lastig, houdt namelijk in dat ik naast het fysiek verhuizen van de server tegelijk ook bij een stuk of 15 domeinen de instellingen moet veranderen, de meeste niet onder mijn eigen beheer.

Nu zit ik te denken aan de volgende opties:
- Alle domeinen tijdelijk via een CNAME aan een centraal domein te hangen, maar dit kan volgens mij niet zoals ik verwacht, bijv het TransIP dns paneel laat me dit niet instellen.
- Voor alle domeinen een centrale nameserver instellen en die veranderen, weet nog zonet niet of alle domeinregisars je een eigen NS in laten stellen..
- Zien te plannen dat iedereen op hetzelfde moment online is en dan de server verhuizen (natuurlijk bijna onmogelijk).

Ik heb nog wel een 'reserve' server, ik zou ook tijdelijk een proxy-constructie maken, maar denk dat dit meer problemen geeft dan het oplost.

[sanzut]

Hele lage TTL instellen, 3 dagen voor verhuizing. Echt iets van een minuut ofzo. Dan kan je na de fysieke verhuizing de DNS wijzigen, dan ben je bijna direct weer bereikbaar.

[SA007]

Lage ttl lijkt me logisch, maar volgens mij heb je het punt gemist dat ik een stuk of 15 domeinen heb die bijna allemaal bij andere mensen vandaan komen en ik dus niet zelf ze ff allemaal langs kan lopen.

Anders was het geen probleem geweest, even een kwartiertje rondklikken.
Maar heb al geluk als ik iedereen in dezelfde week kan bereiken, laat staan in hetzelfde uur.

[DJSmiley]

Heb je een machine over die krachtig genoeg is?

Zo ja, dan kun je misschien de huidige doos kunnen virtualiseren en virtueel draaien (esxi, desnoods vmware workstation oid) en de fysieke bak verhuizen. Daarna de sites verhuizen en langzaam van de oude wegmigreren

Mogelijk kun je iom je hoster zelfs even tijdelijk een desktopdoos neergooien voor dit doel in het rack.

Extreem lompe manier: machine omgooien naar nieuwe IP's en op de huidige lokatie een router neergooien en de bestaande IP's doorrouteren naar de nieuwe lokatie over een vpn tunnel

Afhankelijk van de gebruikte router zal het wel traag(/trager) worden, maar blijft t spul wel bereikbaar

Maar wat moet er verhuisd worden? Blijf je bij dezelfde coloboer of ga je naar een compleet andere? In het geval van 1 kunnen mogelijk je IP adressen gewoon meeverhuisd worden naar een ander DC.

[ Voor 40% gewijzigd door DJSmiley op 02-01-2012 22:16 ]

[AndriesLouw]

Het instellen van een andere nameserver bij alle domeinnamen zou ik niet direct aanraden, dit i.v.m. gluerecords die gewoon hardcoded het IP vasthouden.

Een CNAME is mogelijk, maar let er op dat dit niet voor alles kan. Zo kun je geen (of is het niet aangeraden om) CNAME's in te stellen voor MX/NS/PTR/SRV-records. Daarnaast kun je geen CNAME instellen op het hoofddomein, enkel op subdomeinen (een CNAME voor www.example.com kan wel, maar niet eentje voor example.com).

Natuurlijk zul je de TTL van alle domeinnamen gewoon moeten verlagen, minimaal een dag voor de verhuizing, eventueel kun je nog nadenken over het tunnelen (desnoods via een VPN) van je oude IP naar je nieuwe IP, hiervoor zul je dus wel een extra (VPN-)server nodig hebben.

Mijn tip: Probeer de boel te verhuizen op een rustige dag/tijdstip, zorg ervoor dat je voorbereid bent op problemen (bijv. uitval van een hardeschijf, doordat de server even uit moest), en als je niet zeker bent of je server het overleeft, verhuis dan op een dag/tijdstip dat je bij je leverancier kunt aankloppen voor reserve onderdelen (dus niet zaterdagnacht om 05:00 uur de boel verkassen). Communicatie naar je klanten/relaties is natuurlijk het allerbelangrijkste, laat ze weten wat er gebeurt.

Ik ben bang dat je niet ontkomt aan het opnieuw instellen van de 15 domeinnamen, hoe tijdrovend dat ook mag zijn.

[sanzut]

en als je je klanten vandaag informeert dat ze over 2 weken op vrijdagmiddag tussen 14 en 15 uur bereikbaar moeten zijn, dan is dat waarschijnlijk wel te regelen.
Mocht downtime voor hen onacceptabel zijn, moeten ze de inloggegevens maar doorgeven voor het inlogpanel, dan regel je het gewoon ff zelf.

[Gomez12]

Wat is de termijn voor de verhuizing? En valt er nog iets te regelen met je huidige colocatie?

Mits voldoende tijd (en bereidwilligheid colocater) zou ik het in 2'en hakken.
1 : Huidige server fysiek verhuizen en via vpn door laten lopen op het oude + nieuwe ip-adres
2 : x tijd daarna vpn stopzetten

1 doen op een rustig maintenance tijdstip, 2 kan je op elk gewenst tijdstip doen.

Na 1 kunnen je klanten oud en nieuw ip-adres gebruiken dus hebben alle tijd om het zelf te regelen (zolang het maar voor de deadline van 2 is)

Qua vpn-server kun je eigenlijk vanalles neerzetten, vanaf iets geregeld door de hoster tot een oude bak die je nog ergens hebt liggen.

Planmatig zou ik zeggen :
2 weken voor stap 1 alle klanten informeren.
2 weken na stap 1 stap 2 doorzetten en vpn-server uitknallen.
2 weken na stap 2 pas de fysieke vpn-server weghalen (voor het geval er ergens nog iets vergeten was etc)

[SA007]

AndriesLouw schreef op maandag 02 januari 2012 @ 23:10:
Het instellen van een andere nameserver bij alle domeinnamen zou ik niet direct aanraden, dit i.v.m. gluerecords die gewoon hardcoded het IP vasthouden.

Een CNAME is mogelijk, maar let er op dat dit niet voor alles kan. Zo kun je geen (of is het niet aangeraden om) CNAME's in te stellen voor MX/NS/PTR/SRV-records. Daarnaast kun je geen CNAME instellen op het hoofddomein, enkel op subdomeinen (een CNAME voor www.example.com kan wel, maar niet eentje voor example.com).

Natuurlijk zul je de TTL van alle domeinnamen gewoon moeten verlagen, minimaal een dag voor de verhuizing, eventueel kun je nog nadenken over het tunnelen (desnoods via een VPN) van je oude IP naar je nieuwe IP, hiervoor zul je dus wel een extra (VPN-)server nodig hebben.

Mijn tip: Probeer de boel te verhuizen op een rustige dag/tijdstip, zorg ervoor dat je voorbereid bent op problemen (bijv. uitval van een hardeschijf, doordat de server even uit moest), en als je niet zeker bent of je server het overleeft, verhuis dan op een dag/tijdstip dat je bij je leverancier kunt aankloppen voor reserve onderdelen (dus niet zaterdagnacht om 05:00 uur de boel verkassen). Communicatie naar je klanten/relaties is natuurlijk het allerbelangrijkste, laat ze weten wat er gebeurt.

Ik ben bang dat je niet ontkomt aan het opnieuw instellen van de 15 domeinnamen, hoe tijdrovend dat ook mag zijn.

toon volledige bericht

Ok, nameservers leek me sowieso al teveel gedoe, vooral omdat de nodige domeinboeren moeilijk doen over eigen nameservers.

CNAME, kan dat nou wel of niet, uit je verhaal blijkt het ook maar half, als het domein zelf geen CNAME ken geven is het toch niet mogelijk om domeinen aan elkaar te hangen?


@iedereen
Ik ga in ieder geval eens navragen of de oude provider bereid is om een VPN op te zetten hiervoor.
Kan altijd mijn spare server ertussen gooien of een router oid, maar dat is een hoop extra gedoe en moelijk vooraf te testen.
VPN lijkt zover in ieder geval verreweg de beste optie.

@andere vragen:
Ik ga over naar een compleet andere coloprovider, in een andere stad, dus ip houden is geen optie.
De huidige provider stopt er compleet mee aan het eind van de maand.

Alle klanten op 1 moment online is nagenoeg onmogelijk, zelfs bijvoorbeeld in een weekend.
Ik moet zeker alle domeinen opnieuw in (laten) stellen, maar dit allemaal op 1 moment is logistiek practisch onmogelijk.

[Gomez12]

SA007 schreef op dinsdag 03 januari 2012 @ 20:58:
[...]
De huidige provider stopt er compleet mee aan het eind van de maand.

Duikel je contract eens op? Want dit lijkt me wel heel erg kort dag.

[SA007]

Gomez12 schreef op dinsdag 03 januari 2012 @ 21:03:
[...]

Duikel je contract eens op? Want dit lijkt me wel heel erg kort dag.

Hij heeft zich aan zijn opzegtermijn gehouden, ik weet het al iets langer.
Heb alleen tot nu geen tijd gehad het echt te gaan verhuizen.

[Gomez12]

SA007 schreef op dinsdag 03 januari 2012 @ 21:08:
[...]


Hij heeft zich aan zijn opzegtermijn gehouden, ik weet het al iets langer.
Heb alleen tot nu geen tijd gehad het echt te gaan verhuizen.

Tja, niet echt 1 van de slimste acties dan. Je had minimaal een mailtje van te voren eruit kunnen sturen zonder exacte data etc.

Nu is het redelijk kort dag allemaal om op te zetten en te communiceren.

Ik zou in ieder geval nu alvast een voorlopig mailtje eruit doen naar je klanten ipv dat je het pas stuurt als je het definitief uitgewerkt hebt en dan te horen krijgt dat klant x voor 3 weken op vakantie is.

[Gillie]

En tijdelijk een VPS regelen?

Als je de VPS als een 'redundante mirror' maakt zien de klanten het verschil niet en kan je huidige colo en VPS parallel draaien. Beide zal je moeten instellen als DNS entry. Zeg maar 1+1 protectie, een telecom term.

Voor je huidige colo ophoud, zorg je dat deze uit de DNS is verwijderd en de TTL 'nul' is.

Erna heb je alle tijd om de fysieke server naar de nieuwe colo te verhuizen. Waarna je de boel van de nieuwe colo en VPS de DNS entries van beide toevoegd.

Na tijdje parallel te hebben gedraaid en tevreden ben, VPS DNS verwijzingen weghalen en voilà alles netjes en nagenoeg zonder downtime verhuist.

Nadeel je moet twee keer verhuizen en is wat omslachtig met DNS instellingen. Eventueel kan je korte TTL instellen. En afhankelijk wat je kan afstemmen/onderhandelen kosten voor een VPS.

[--MeAngry--]

Alle oplossing die geboden worden voor vervanging bij de huidige colo gaan niet helpen als de hele colo er mee ophoud.

Wat wij in dit soort gevallen doen is, en dit is ons al vaker voor gekomen, de klanten inderdaad vantevoren informeren over wanneer er een IP-change zal plaatsvinden, en dat ze op die datum, op dat tijdstip het IP in hun DNS moeten wijzigen. Doen ze dit niet, dan ligt hun site plat en hadden ze hun domein maar bij ons moeten stallen, of naar ons DNS moeten verwijzen.

Heel bot misschien, maar soms kun je niet anders. En als een klant zijn eigen DNS regelt moet die gewoon weten dat dit soort dingen kunnen gebeuren, vaak zijn dit ook de klanten met een eigen IT afdeling en is er dus geen enkel probleem.
Daarnaast worden onze klanten hiervan ook nog op de hoogte gebracht voordat ze hosting bij ons afnemen voor een site die ze bij ons hebben laten maken.

[SA007]

@Gomez: het is geen probleem om in een week tijd iedereen een keer instellingen te laten veranderen, alleen tegelijk is zo goed als onmogelijk.
En ze weten ook dat het eraan komt, probeer nu uit te vinden hoe ik het kan dan met zo min mogelijk uptime.

@Gillie:
I betrek er liever niet nog een provider bij, dan ben ik eerst een tijd bezig om die VPS in te richten, daarna alles 2 verhuizen, dan heb ik liever de downtime, ik heb geen contracten naar mijn klanten verder hoor

@--MeAngry--: Dat werkt inderdaad prima als het bedrijven zijn die mensen hebben die er verstand van hebben, maar dat ligt vaak niet zo simpel als het particulieren zijn, daarom wil ik het zo bouwen dat er niet 1 punt is waar vanaf alles simultaan omgezet moet worden.

[Gomez12]

Je kan natuurlijk wel ietwat klantvriendelijker optreden door de eerder genoemde suggesties te volgen en een overgangstijd te bieden waarin oud(via vpn) en nieuw ip werken.

Het probleem gaat enkel tijd worden. Big-bang mededelingen zijn niet erg als ze ruim tijdig aangekondigd zijn (4 weken van tevoren is wmb niet echt tijdig) en als je "echte klanten" hebt

@SA007 dan zou ik gewoon provider opbellen voor mogelijkheden vpn en dan asap de server verhuizen en vpn opzetten. Vanaf vpn-moment hebben je klanten alle tijd om het te veranderen (het werkt alletwee)

[SA007]

Ik zet nu ook in op VPN, heb bij de huidige provider de vraag liggen of hun dat kunnen regelen.

Anders hang ik zelf wat hardware in plaats van mijn server, maar dat vergt weer extra instelwerk en moet ik die vpn hardware ook weer op gaan halen achteraf.

[DJSmiley]

Kun je geen dealtje maken met de 'nieuwe' partij? Als ik ff zo snel zie gaat het om Grafix, en ik meen dat A2B die ip ranges in beheer neemt/overneemt of whatever.

Als je in 1 van hun DC's ergens 1U kunt regelen voor een maand of 1-2 dan kun je daar een vpn doos neergooien en t omrouteren naar de nieuwe lokatie. Dan heb je iig wat meer lucht om rustig alles om te zetten.

Maar wat zijn de specs van je spare server? Als die identiek is (of makkelijk identiek te maken is) dan kun je die spare ook inzetten op de nieuwe lokatie en dan alles over gaan zetten. Dan zit je nog wel met het offline gaan van je huidge lokatie, maar dat heb je bij een VPN oplossing ook. Als die IP's er gewoon keihard uitgaan houd het op...

[ Voor 31% gewijzigd door DJSmiley op 03-01-2012 21:49 ]

[Gomez12]

Moet je alleen nog wel even rekening houden met dat je via vpn 2 ip's overal voor moet toestaan. Als je vhosts hebt etc dan moet je die aan 2 ip's hangen. Mysql-Server etc.

Big-bang is veelal search-replace, dit is ietwat anders

Het is niet het einde van de wereld, maar het is wel ietwat anders dan de meeste tuts die je op inet vindt.

@Gillie, dat wil je niet hebben. Proxy is veelal voor 1 doel bestemd, dan heb je ergens een klant die net een ander dingetje gebruikt en dan moet je daar weer iets anders voor regelen (bijv een klant die mail laat afleveren). Dual-ip draaien is redelijk simpel en transparant en werkt in principe overal voor.

[ Voor 47% gewijzigd door Gomez12 op 03-01-2012 21:52 ]

[Gillie]

Je zou ook iets kunnen doen met een proxy?

De DNS om laten zetten naar de nieuwe lokatie en hier tijdelijk een proxy door laten sturen naar het oude adres.

Netto heb je alleen de downtime op het moment dat je fysiek de server verhuist.

[SA007]

@DJSmiley:
Hij hangt nu inderdaad in een DC van grafix, maar denk niet dat hij daar blijft. Imho is de locatie niet echt relevant. Het zou handig zijn als de verhuizing in 1 gebouw blijft, maar zeker niet nodig.

Als je een redelijk goedkope coloprovider in hun datacenter in capelle weet houdt ik me aanbevolen.

@Gomez12: Dat is geen probleem.

@Gillie: Daar komt een VPN effectief op neer, alleen wat transpanter en werkt ook voor != http.

[DiedX]

Gillie schreef op dinsdag 03 januari 2012 @ 21:50:
Je zou ook iets kunnen doen met een proxy?

De DNS om laten zetten naar de nieuwe lokatie en hier tijdelijk een proxy door laten sturen naar het oude adres.

Netto heb je alleen de downtime op het moment dat je fysiek de server verhuist.

Ik zet in op ha-proxy op een VPS. Dan krijg je de mogelijkheid om HA-Proxy verbindingen te laten proxyen naar twee IP's. 1 van de IP's zal tegelijkertijd op zijn natuurlijk.

Als jij iets van een VPS regelt, dan wil ik wel eens kijken of het werkt.

[SA007]

DiedX: met een VPS zit je met 2 verhuizingen, das gewoon teveel gedoe.

Ik heb van mijn provider gehoord dat hij geen VPS voor me kan regelen, dan doe ik dat zelf maar.

Ik ga mijn oude servertje eens voorzien van een verse install en kijken of ik VPN online kan krijgen.

[moppentappers]

Als je de IP adressen op de nieuwe locatie al weet kun je dat IP adres gebruiken als 2e nameserver, op het moment dat je dan over bent is je 1e name server niet meer bereikbaar en wordt die gebruikt voor het resolven van de namen. Vervolgens moet je als je dan daadwerkelijk over bent die 1e name server ook weer even goed instellen natuurlijk, maar dan ben je klaar.

[Bl@ckbird]

In plaats van een VPN, zou je ook naar LISP kunnen kijken. Dit is een nieuwe routing architectuur waarmee je de locatie van het IP adres kan scheiden. Wat use cases zijn o.a.:
- Multihoming
- IPv6 transitie
- IP / VM portability --> Case wat voor jou interessant is.

Dit scheelt de overhead / performance dip die je met een VPN zou hebben.

Wat linkjes:
http://lisp4.cisco.com/lisp_over.html
http://lisp4.cisco.com/LISP_Overview.pdf
Wikipedia: Locator/Identifier Separation Protocol
http://www.openlisp.com

[menace9]

Je kan in plaats van een vpn, ook een linux server opzetten en met behulp van rinetd de poorten die je nodig hebt, doorsturen.
Nadeel hieraan is dat al je verkeer van je ipadres van je oude colo komt, maar als dat geen probleem is, kan je het heel makkelijk oplossen.

- zet een linux server op met rinetd welke alle nodige poorten doorstuurt naar je nieuwe adres
- hang je echte server in de nieuwe colo
- iedereen die de dns nog niet aangepast heeft, gaat naar de oude colo en wordt daar doorgestuurd naar de nieuwe colo
- in de logfiles kan je zien welk verkeer nog via de oude colo loopt, en dus nog geen DNS aangepast heeft.

Zodra er geen verkeer meer komt van je oude colo, zijn alle dns aanpassingen gedaan en kan je de tijdelijke server weghalen

[DiedX]

menace9 schreef op vrijdag 06 januari 2012 @ 00:33:
Je kan in plaats van een vpn, ook een linux server opzetten en met behulp van rinetd de poorten die je nodig hebt, doorsturen.
Nadeel hieraan is dat al je verkeer van je ipadres van je oude colo komt, maar als dat geen probleem is, kan je het heel makkelijk oplossen.

- zet een linux server op met rinetd welke alle nodige poorten doorstuurt naar je nieuwe adres
- hang je echte server in de nieuwe colo
- iedereen die de dns nog niet aangepast heeft, gaat naar de oude colo en wordt daar doorgestuurd naar de nieuwe colo
- in de logfiles kan je zien welk verkeer nog via de oude colo loopt, en dus nog geen DNS aangepast heeft.

Zodra er geen verkeer meer komt van je oude colo, zijn alle dns aanpassingen gedaan en kan je de tijdelijke server weghalen

Dit is eigenlijk de volledige uitleg van mijn idee, maar dan niet met rinetd, maar met haproxy. Haproxy heeft als voordeel dat hij zelf bijhoudt welke servers bereikbaar zijn.

Dus:

* Je zet HA-Proxy op met 1 IP, en twee "backend" servers
* Je wijzigt de DNS naar het tijdelijke IP van HA-Proxy
* HA-Proxy checkt elke zoveel seconden welke servers bereikbaar zijn
* Bezoeker komt, HA-Proxy stuurt de request door naar een van de servers die bereikbaar zijn. Alleen: dat zal er maar 1 zijn (oud IP of nieuw IP!).
* Zodra de server live is op de nieuwe colo zet je de DNS wederom, maar nu naar nieuw IP.

Klaar.

[VisionMaster]

sanzut schreef op maandag 02 januari 2012 @ 21:32:
Hele lage TTL instellen, 3 dagen voor verhuizing. Echt iets van een minuut ofzo. Dan kan je na de fysieke verhuizing de DNS wijzigen, dan ben je bijna direct weer bereikbaar.

Even een news flash, niet iedere DNS hoster honoreert de DNS TTLs tot op de minuut. Google is bijvoorbeeld enorm snel, maar de Telfort DNS-en worden niet vlotter dan een uur of half uur. En zo zijn er nog wel een hele zooi services die niet vlotter de informatie invalideren.

[ Voor 8% gewijzigd door VisionMaster op 06-01-2012 22:50 ]

[Paul]

Die mensen hebben dan gewoon een half uur pech Je kunt niet alle non-compliant brakke meuk van een ander oplossen; je kunt enkel zorgen dat het voor zoveel mogelijk mensen (mensen die (/wiens provider) zich wel aan de standaarden houdt) zo kort mogelijk duurt

[VisionMaster]

Paul schreef op vrijdag 06 januari 2012 @ 22:58:
Die mensen hebben dan gewoon een half uur pech Je kunt niet alle non-compliant brakke meuk van een ander oplossen; je kunt enkel zorgen dat het voor zoveel mogelijk mensen (mensen die (/wiens provider) zich wel aan de standaarden houdt) zo kort mogelijk duurt

Tja, dit is slechts praktisch voorbeeld uit eigen ervaring. Ik zou gewoon niet vertrouwen op die methode. Er zijn genoeg devices, services en browsers die DNS queries cachen. En in het slechtste geval is de TTL verandert door de DNS service die je aanspreekt. Te snelle DNS updates zijn ook niet gunstig voor de DNS infra als geheel, vandaar ook de mogelijkheid tot een ondergrens.

Al eens DNS entries en/of virtual host entries verandert en getest met Chrome? Ik wens je succes. Het vechten tegen nog valide caches is soms spannend en niet gebruikersvriendelijk.

Anyway, kies wat je wilt. Maar enkel en alleen je DNS TTL op 'hele kort' zetten maakt je niet direct vrolijk en hebben zo zijn neveneffecten.

In de wijze woorden van een mijn software docent van jaaaarrrren terug: "Geloof mij niet, tik het in"

[SA007]

Ik heb weer 's tijd om hiermee verder te gaan.

Van wat ik zie:
rinetd, klinkt heel leuk, maar kan alleen tcp, heb ook spul op udp zitten.
HA-proxy is nog beperkter op dat punt, die kan alleen http.

Ben nu iig nog bezig met de server inrichten (tijdgebrek...)

[Paul]

VisionMaster schreef op zaterdag 07 januari 2012 @ 15:52:
Anyway, kies wat je wilt. Maar enkel en alleen je DNS TTL op 'hele kort' zetten maakt je niet direct vrolijk en hebben zo zijn neveneffecten.

I know En toch... Wij zetten het vaak bij (verwachte) changes op 5 minuten en melden tegen de klant dat dit 'best effort' is omdat niet alles en iedereen zich daar aan houdt.

Daar houdt het voor ons echt op, zeker als het oude ip niet meer bereikbaar is of net wat. Bij een normale verhuizing houden we de service echt nog wel een tijd (dagen/weken) up op het oude ip, maar soms kan dat gewoon niet en hebben sommige mensen even pech

[Ebais]

Als het een ip adres van het voormalige Grafix is, is het het handigste om even met A2B Internet contact op te nemen, aangezien er voldoende partijen die shared colo bieden in Capelle.

Desnoods neem je een direct shared colo contract by Datahouse in Capelle.

Dan kan je gewoon je ip meeverhuiizen en blijven gebruiken.

[SA007]

Ondertussen is de server verhuisd, heb nu een oud servertje in capelle hangen die alles doorstuurt naar het nieuwe DC.

Dit werkt prima, al is het maar voor een weekje

[moppentappers]

En waarmee heb je die doorsturing geregeld?

[SA007]

Een beetje lelijk.

Ik had openvpn opgezet en in de testsetup werkte dat prima.
Maar toen ik het ging plaatsen ging dat opeens hard stuk op subnet masks...

Heb met ssh alle tcp poorten geforward en maar geaccepteerd dat de udp diensten dan maar down zijn tot de dns geregeld is. gelukkig zit daar niks tussen wat ik niet zelf kon overzetten, dus veel extra downtime heeft daar niet ingezeten.
Ben alleen wel tot 1 uur 's nachts in het DC bezig geweest met instellen...

Ga er zelf verder geen tijd meer insteken, over een dag of 4 gaat de oude locatie plat en er is nu niets down.