Verhuizen van site naar nieuwe server
De configuraties van de servers zullen verder gelijk zijn, dus de sites zullen direct moeten werken op de nieuwe server, en ook het controlpanel (DirectAdmin) is hetzelfde. Domeinen blijven bij de huidige registrar staan.
Voor het gemak (goede tip voor anderen) zet ik nog even een extra regel in een HTML-comment op mijn site waarin staat op welke server die draait. (lang leve $_SERVER['SERVER_ADDR'])
Stap 1) Nieuwe server gereed maken qua configuratie (PHP versies, error reporting etc)
Stap 2) Een snapshot maken van een lege maar geïnstalleerde server
Stap 3) Testrun draaien door alle domains vanuit DirectAdmin over te kopiëren en even te timen hoelang dat duurt.
Stap 4) Een paar testdomeinen aan een paar sites koppelen om te kijken of alles technisch goed functioneert en dit even een paar dagen in de gaten houden.
Stap 5) Als alles werkt de snapshot terug plaatsen zodat de geïnstalleerde server weer leeg is.
------- De migratie begint, spanning stijgt, koffiezetapparaat draait op volle toeren --------
Stap 6) Alles overzetten via DirectAdmin naar de nieuwe server. Niks meer doen aan onderhoud op de sites op deze oude server.
Stap 7) DNS en MX-records bij registrar omzetten naar nieuwe IP met lage TLL-waarde.
Stap 8) Paar dagen later: Oude server afkoppelen.
**Profit ??**
Is dit een puik stappenplan? En mis ik misschien nog iets?
En hoe groot is de kans dat met een lage TLL-waarde in de DNS over de hele wereld het nieuwe IP-adres in de DNS opgepikt wordt?
Gewijzigd op 21/12/2021 12:08:29 door - Ariën -
En een welkomsbericht op de nieuwe site.
Gewoon, om jezelf in te dekken.
En maak backup van FTP en database.
Op de nieuwe site komt wel een HTML-comment te staan, maar ik hoop dat een lage TLL in de DNS vrij snel de nieuwe IP-adres herkend wordt?
Tja, als mijn database ook op een losse server draaide, dan was het nog makkelijker ... :P
Gebruikers die na de migratie nog naar de oude server worden gestuurd (ivm DNS cache) en daar iets gaan doen waarbij data in de database wordt geschreven zien deze data uiteindelijk niet terug als ze de volgende keer naar de nieuwe server worden gestuurd. Je zult op de oude server dan een soort "read only" modus aan moeten zetten (wel kijken, niet aanpassen - bijvoorbeeld door gewoon de login pagina uit te schakelen + uitleg).
Die TTL wordt bij elke request naar mijn site dus opgehaald door de DNS? Kan het kwaad als je die na een paar dagen niet terugzet op een korte tijd van bijv. 5 minuten?
Gelukkig is het een nieuwssite en geen site met user-generated content, dus die read-only zal wel meevallen. Ik moet alleen even aan mijn team uitleggen dat ze dit weekend maar even vrij moeten nemen ;-)
Gewijzigd op 21/12/2021 13:37:30 door - Ariën -
- Ariën - op 21/12/2021 12:34:25:
Die melding dat er een verhuizing komt ga ik zeker doen. En verder maak ik zeker een backup (gebeurt elke nacht overigens)
Maak in ieder geval (mocht je dat niet doen) handmatig een back-up van je public_html map en van je database. Sla die LOKAAL op, dus niet ergens op een server, maar gewoon op je eigen computer thuis.
Stel je domein/vhost alvast in op de nieuwe server en kopieer de hele bende (je bestanden en DB daar naartoe).
Rename de index op je oude server naar index_old.php. Maak een nieuwe index.php aan met daarin:
<p>Wegens onderhoud tijdelijk even niet bereikbaar. We zijn heel snel weer terug.</p>
(Hierdoor is de oude site niet meer bereikbaar en kan er niks gewijzigd worden, maar mocht er iets mis gaan kun je de site binnen een minuut weer online zetten door index.php te renamen naar index_temp.php en index_old.php te renamen naar index.php.)
Pas je lokale hosts file aan en stel die zo in dat jouw website naar de nieuwe server verwijst. Nu kun je zien en controleren of alles werkt op de nieuwe server terwijl de rest van de wereld gewoon de onderhoudsmelding te zien krijgt. Als alles naar behoren werkt, pas je je hosts file weer aan zodat je zelf ook de onderhoudsmelding te zien krijgt. Vervolgens je DNS aanpassen en laten verwijzen naar de nieuwe server. Merk op, tegenwoordig kunnen die verwijzingen heel snel worden doorgevoerd. Kan zomaar zijn dat dat al binnen 1 minuut is.
Succes.
Gewijzigd op 21/12/2021 15:29:02 door Ozzie PHP
- Ariën - op 21/12/2021 13:35:22:
Die TTL wordt bij elke request naar mijn site dus opgehaald door de DNS? Kan het kwaad als je die na een paar dagen niet terugzet op een korte tijd van bijv. 5 minuten?
- Bezoeker wil naar jouw site = toetst domeinnaam in.
- PC kent domeinnaam nog niet; vraagt bij DNS op (en die weer bij provider, enz).
- DNS geeft antwoord (IP-adres), en geeft ook TTL mee = "dit antwoord mag je voor deze periode (opnieuw) gebruiken" = voorlopig niet meer opnieuw opvragen
(de TTL wordt dus niet bij elke page view teruggestuurd, maar alleen bij "eenmalige" DNS request)
Stel dat je TTL op 24 uur staat, dan wordt de domeinnaam pas na 24 uur weer opnieuw opgevraagd. Voor je verhuizing zet je de TTL dus op 10 minuten ofzo, waardoor de DNS dus al na 10 minuten opnieuw moeten worden geresolved. Een evt. IP-adres wijziging komt daardoor dan snel bij de gebruikers (niet pas na 24 uur) = ze gaan snel over naar de nieuwe server.
Op het moment dat je het IP-adres in de DNS hebt gewijzigd kun je de TTL dus weer op 24 uur zetten, omdat zodra een gebruiker (na 10 minuten) de DNS weer raadpleegt ie het nieuwe IP-adres als antwoord krijgt, en daar dus voorlopig wel weer 24 uur mee vooruit kan.
Bijvoorbeeld www9.mijnsite.nl (waarbij 9 dan voor mij verwijst naar server9)
Die DNS entry kun je al ruim van de voren invoeren in je DNS server. En kun je ook gebruiken voor je testen of het werkt.
Komt een bezoeker na de verhuizing en omzetting van de DNS alsnog op de oude locatie van www.mijnsite.nl, dan is kennelijk nog niet zijn DNS cache bijgewerkt.
Je kunt hem dan doorverwijzen naar www9.mijnsite.nl
Je moet dan alleen wel zorgen dat er op de nieuwe server niet een script actief is dat zorgt dat alle verkeer wordt doorverwijzen naar www.mijnsite.nl. Of dat je in elk geval daar bij opneemt dat www9.mijnsite.nl daar een uitzondering op is.
Je hebt dan weliswaar even (een paar dagen) een site die onder 2 namen te vinden is, wat SEO technisch vast niet goed is, maar dat is dan maar voor die paar dagen.
Daarnaast zijn er nog wat van die "alternate" tags die je op kunt nemen.
Afhankelijk van het soort site kun je daarmee je downtime voor gebruikers beperken.
Gaat het om de site van de dierenwinkel om de hoek, dan is dat minder kritisch dan als het om een portal gaat waar een bedrijf zijn order-administratie op voert.
Gelukkig heb ik een testdomein en testsite die representatief is met mijn productie. Dus daar kan ik goed uittesten of de migratie werkt.
Gewijzigd op 23/12/2021 13:03:35 door - Ariën -
- Ariën - op 23/12/2021 13:00:56:
Na kerst ga ik de server aanschaffen ...
Aanschaffen of huren?
Komende week ga ik even lekker verder configureren en uittesten, en een testrun doen voor het overzetten van mijn data (hele admin-reseller map uit de /home).
Gewijzigd op 30/12/2021 01:40:30 door - Ariën -
Gezien ik een representatieve testsite van mijn site heb draaien heb ik besloten om die eerst te migreren. Dan weet ik precies of de migratie lukt. Dat ga ik komende week doen op de wijze die ik net aanhaalde. DirectAdmin biedt er goede mogelijkheden voor.
Uiteraard voer ik dit in een weekend uit waarbij het lekker rustig is, en bouw ik een regeltje in mijn site die aangeeft op welke server het staat. Ik heb elke server die ik heb een eigen nummer gegeven, dus ik kan straks in de HTML zo zien op welke server de site staat op het moment dat de DNS-wijziging plaats vindt. ;-)
Voordelen vergeleken met voorheen:
- Ik kan via VNC zien wat de server voor output op het scherm toont en deze ook overnemen. Handig als ik mij via bijvoorbeeld SSH buitensluit.
- Extra geheugen: Nu 4 GB waarmee ik ook composer kan gebruiken.
- Een hoop backups van mijn VPS.
Gewijzigd op 14/01/2022 14:25:25 door - Ariën -
Die zetten een site in seconden over. En met de juiste parameters staan ook direct de rechten goed.
Wel moet je dat ssh toegang hebben, maar zo te lezen heb je dat ook.
Rsync geeft ook de mogelijkheid om een site nog een keer te repliceren op een later moment, waarbij ook verwijderde bestanden op de kopielocatie verwijderd worden.
Ik gebruik dat in een cronjob om een aantal "sites" op een andere server gelijk te houden, zodat er in geval van nood een live kopie is om op verder te kunnen werken.
De bijbehorende database gaat via replication.
Dit kwam ik ergens tegen en ga ik dus gebruiken komende week.
Code (php)
1
rsync -auv -e "ssh -p 2233" /home/admin/admin_backups [email protected]:/home/admin/admin_backups/ --no-perms --no-owner --no-group --no-times
Het komt erop neer dat DirectAdmin de sites zelf al op verzoek inpakt. Op de andere server is het een kwestie van uitpakken.
De database is gewoon een kwestie van dumpen en importeren. Het is even jammer dat deze niet apart is, maar de migratie gebeurt toch op een rustig moment, is niet verschrikkelijk groot, en er is geen sprake van user-generated content waardoor de data dus niet zal afwijken op beide locaties.
Gewijzigd op 14/01/2022 15:51:50 door - Ariën -
Enige puntje was dat MariaDB op de nieuwe server te strict stond ingesteld, maar dat is ook opgelost.
Dit topic is gesloten.