Onderwerp: Verhuizing - Plan van aanpak?

Ik ben benieuwd hoe andere bedrijven hun verhuizingen hebben gedaan en wat hierbij kwam kijken, wat de struikelblokken waren.

Wij gaan onze servers verhuizen van rack naar een nieuwe provider, ik wil dan ook weten of er mensen zijn die een document hebben van hoe ze hun verhuizing gedaan hebben en hoe het verliep.

DNS ttl aanpassen naar 100 seconden, alle servers eruit halen behalve je secundairy dns, die laten hangen, alle domeinen op secundairy aanpassen naar nieuwe webserver IP, alles verhuizen, servers ophangen, primary dns weer online zetten op nieuwe IP. primary en sec. dns laten syncen, en week later je secundairy dns verhuizen (indien nodig).

Korte samenvatting

De verhuizing zelf is het probleem niet, kwestie van servers oppakken, vervoeren en in het nieuwe rack ophangen.

De grootste uitdaging zit hem in het snel weer online zijn op nieuwe IPAdressen. Om dit snel regelen moet je werken met mirrorservers die je tijdelijk opzet op de oude locatie. Deze servers bevatten _alle_ oude IPadressen en alle domeinen die je hebt. Je zorgt er voor dat je tijdens de verhuizing de mirrorserver online gooit en deze alle nieuwe ipadressen al in zijn configuraties heeft, dus dat dze alles direct omzet naar het nieuwe IP.

Zorg wel dat de TTL waarde van alle dnssystemen zijn terug gebracht tot maximaal 10 minuten (600 sec).

Zodra alle servers op de nieuwe locatie staan en de mirrorserver draait in het oude netwerk heb je een downtime die enkel uitgaat van de tijd die je kwijt bent aan het verschuiven van de apparatuur. Alle websites moeten dan op de nieuwe locatie direct weer werken. Let wel dat je uiteraard alle IPAdressen op de servers moet aanpassen!

Je kunt na de verhuizing beginnen met het aanpassen van de nameservers op de nieuwe IPAdressen.

Dit is hoe wij verhuizingen plannen en eigenlijk geen last meer hebben van grote downtimes.

ps. een tweede DNS server in een ander netwerk does the trick, maar helaas draaien veel domeinen van klanten niet op onze DNSservers, vandaar dat de mirrorserver bijna 100% werkt.

---
Ooit heb ik een kleine uitleg geschreven voor klanten die wel met een redundante DNS werkten maar ook weer veel klanten en resellers hadden die dus weer gebruik maakten van 'e'en enkele dns, dus de mirroserver kwam hier goed van pas:

Werkt met BIND:
http://linuxs.nl/mirror.txt

Je kan ook een proxy-like-service achterlaten op de oude locatie (rinetd is hier bvb handig voor) die alle verkeer correct doorstuurt naar de nieuwe IP's. Werkt niet voor alles, maar web en mail zijn bvb zo perfect op te lossen.

Ik zat zelf te denken om op de nieuwe locatie vast een machine te hangen, als mirror DNS, en daar eerst alles goed te configureren. Dan lijkt het me een kwestie van de DNS aanpassen voordat ik de server oppak, server slepen en ophangen en klaar.

Oorspronkelijk geplaatst door CharlieRoot

Ik zat zelf te denken om op de nieuwe locatie vast een machine te hangen, als mirror DNS, en daar eerst alles goed te configureren. Dan lijkt het me een kwestie van de DNS aanpassen voordat ik de server oppak, server slepen en ophangen en klaar.

Vergeet het IP aanpassen niet. De totale downtime kun je verder beperken door vooraf alle nieuwe IP adressen als extra IP toe te voegen en op de nieuwe locatie de oude IPs te verwijderen. Het is niet optimaal/netjes, maar het werkt wel (scheeld je toch weer enige downtime door het configureren van IP adressen).

Misschien een idee om zelf een plan van aanpak te bedenken en dan hier vragen welke dingen er volgens de WHTers nog missen ;-)

Waarom niet eerst op een andere locatie een server hangen voor je dns. Dat moet je toch hebben.. als je daar ook fallback voor de e-mail op draai dan loopt dat in principe geen enkele vertraging op.

TTL verlagen hoeft niet altijd te werken..

Een plan van aanpak hangt af van een aantal factoren die voor een aantal bedrijven anders kunnen zijn. 1, 10 of 500 servers maakt een verschil.. net zoals het aantal mensen wat ingezet kan gaan worden en het tijdspad. Moet het over een week, een maand of over een half jaar gebeuren..

Ik vind wonko zijn tip wel handig om 1 oude server met rinetd alles te laten redirecten wat nog naar oude ip gaat. Heb je nooit dns caching probleempjes.

Denk eraan dat rinetd enkel TCP doet, geen udp, en je dus geen afhandeling van bvb DNS kan doen (tenzij die dns dan terug op tcp werkt).

Belangrijk: Zorg voor extra schijven in de periode na de verhuizing.

Daarnaast laat de machines eerst goed afkoelen voordat je ze uit het rack trekt...

Oorspronkelijk geplaatst door almar

Belangrijk: Daarnaast laat de machines eerst goed afkoelen voordat je ze uit het rack trekt...

Vertel mij maar eens waar je deze wijsheid vandaan haalt, chips en condensatoren gaan niet stuk door ze te bewegen enkel wanneer deze doorbranden. Maar zijn ze niet doorgebrand voor het uitschakellen is er niks aan de hand.

Wat blijft er over naast de voeding en kast? De hardeschijven, de arm van de schijf gaat netjes op een idle plek wanneer de schijf uitgeschakeld is. Alleen bij het ruig behandellen van je server (dan heb ik het over het overgooien) dan gaat zulke hardware stuk.


Servers kunnen dus direct na het afsluiten in de auto worden geplaatst, wel even een doekje eromheen (oeps word die dan weer warm? NEE) voor de gebruikers krasjes want dit is wel altijd zonde..


PS. Dit lijkt een beetje op het fabeltje van, computer 1 min uit, voor deze opnieuw te starten

Het materiaal waarvan chips zijn gemaakt is kwetsbaarder wanneer dit verwarmd wordt. Daarnaast zijn plotselinge temperatuur verschillen schadelijk.

Hou er wel rekening mee dat ventilatoren niet altijd even goed reageren als ze een keer uit zijn gezet.
Als je een beetje voorzichtig met de servers omspring en na het uitschakelen even laat hangen gaan schijven e.d. eigenlijk altijd wel goed.

Ik zou voor om het even welke verhuizing wel altijd voor voldoende reserveonderdelen zorgen. En natuurlijk een goede gecontroleerde backup

Backups en reserve onderdelen spreken voor zich, maar na uitschakeling van de server en deze zoemt niet meer kan deze gewoon netjes overgeplaatst worden.

Altijd opletten per server met terug zetten of ze goed functioneren maar tijden laten afkoelen..