Stappenplan verhuizing van hosting

[bartbh]

Op dit moment neem ik een resellerpakket af, echter wil gaan verhuizen naar een VPS. Om de tijd waarop de websites down zijn tot een minimum te beperken, heb ik onderstaand stappenplan opgesteld met wat tips die ik her en der op het internet heb gevonden. Mijn plan is om de sites op een rustige nacht over te zetten.

Ik verhuis van directadmin naar directadmin, dus dat scheelt al erg veel in het overzetten van de accounts. Echter zou onderstaande aanpak in mijn inzien ook opgaan voor eventuele andere verhuizingen.

0. Een backup van alle klanten/gebruikers importeren op de VPS om zo de div. websites te kunnen testen op compatibiliteit. Daarnaast de klanten op de hoogte stellen van de verhuizing.

1. Een of enkele dagen voor de verhuizing de TTL van de DNS-records zo laag mogelijk zetten. (laagste wat in mijn controlepaneel mogelijk is, is 900 / 15min)
2. Mail, apache etc. op de VPS stoppen.
3. DNS wijzigingen doorvoeren, dus verwijzen naar nieuwe IP-adres.
4. Minimaal de TTL-tijd wachten, zodat al het verkeer nu naar het nieuwe IP-adres zou moeten gaan.
5. Alle gebruikersaccounts op de reselleraccount backuppen.
6. De backups op de VPS importeren.
7. Mail, apache etc. op de VPS weer online brengen.
8. Alles testen en de TTL weer omhoog brengen naar 3600

Heeft iemand hier nog op- of aanmerkingen op, of zaken die ik misschien beter op een andere manier kan regelen, dan hoor ik dat graag

[Workaholic]

Ik mis de nieuwe server verdere optimaliseren (beveiliging/settings). Kijk bijvoorbeeld is naar configserver firewall&security plugin. Zorg ook dat je hem goed dicht getimmerd hebt + juiste settings voor php etc.
Wijzigen van standaard poorten is ook een goede tip. (directadmin https / ssh)

Ook een tip om in directadmin je dns te gaan gebruiken als je dat nog niet doet. Zo kun je direct dns wijzigingen daar maken ipv via je hoster. Ook kunnen klanten direct subdomeinen maken etc.

Als de sites voornamelijk statische content hebben kun je de sites gewoon door laten draaien op de oude server. Dan zijn ze zelfs in het geval van dns problemen nog bereikbaar.

directadmin -> directadmin is peanuts. userback-up download--> upload userback-up. Klaar.

Gebruik verder de SIDN domein en mxtoolbox check voor je dns en mail settings. Zorg dat deze goed staan anders heb je problemen met je mail bezorging (of mail van klanten komen in de spam folders van diverse providers). Ik heb bij een migratie overigens altijd relay/forwarder mail servers gebruikt die de mail tijdelijk vast houden om te voorkomen dat mail op de oude server terecht komt wegens dns problemen.

[ Voor 26% gewijzigd door Workaholic op 17-04-2012 08:51 ]

[bartbh]

Wat algemene beveiligingszaken heb ik inderdaad niet genoemd, maar wel meegenomen. Installatie van CSF, geen root-inlog SSH, webmail subdomein met SSL-certificaat, directadmin met SSL-certificaat etc, mod_ruid2, server signature uit etc.

Ik maak bewust geen gebruik van de DNS van de directadmin, aangezien bij uitval van de server de DNS-records dan ook niet meer te raadplegen zijn. Het aanmaken van subdomeinen is geen probleem, aangezien elk domein een wilcard record en dus alle subdomeinen sowieso automatisch bij de server uitkomen.

De feitelijke verhuizing van DA -> DA is inderdaad een eitje. Gaat mij er vooral ook om, om het met een zo minimaal mogelijke downtime te doen zonder dat er bijvoorbeeld mail gemist wordt.

Wat versta je onder relay/forwarder mail servers als ik vragen mag?

[fds]

1. Oude server backuppen
2. TTL van de DNS laagzetten
3. Domeinen met databases kopieren naar de nieuwe locatie en uittesten via tijdelijke DNS namen
4. Toegang voor klanten op de oude server blokkeren
5. E-mail op de nieuwe server regelen en e-mail van de oude server laten relayen naar de nieuwe
Doe dit per domein en controleer telkens of de e-mail op de nieuwe server goed verwerkt wordt
6. De laatste stap, 2 dagen na stap 2: domeinen, databases en e-mail nu echt verplaatsen
Eerst website op oude locatie offline zetten, de boel verplaatsen en alle DNS records omleggen
Toegang voor klanten op de nieuwe server activeren
Doe dit alles per domein en blijf telkens goed controleren!
7. TTL van de DNS terugzetten op 1 dag

Dus eerst de nieuwe server inrichten met een kopie van de oude en goed testen: website, database, e-mail, klantentoegang. Dit moet allemaal goed ingericht zijn voordat je gaat verhuizen, zodat je tijdens de verhuizing niet tegen problemen aanloopt met de nieuwe server. Je kan dit doen terwijl je tot 2 dagen moet wachten tot de TTL van de DNS verlaagd is.

Stap 6 zorgt voor korte downtime van sites en is dus een klusje voor 's nachts en/of in het weekend.

Indien klanten een statische site hebben (geen schrijfacties naar b.v. database), dan kan je de site verplaatsen, zonder de oude offline te halen. Er is dan geen downtime.
Je moet wel 100% zeker weten dat men op de oude site geen transacties meer doet tijdens de verplaatsing en het omleggen van de DNS!

[ Voor 0% gewijzigd door fds op 23-04-2012 16:13 . Reden: Stap 6 zorgt voor kort downtime, niet 7 ]

[bartbh]

Een volledige backup van alle gebruikers heb ik op dit moment al draaiende op de nieuwe server. Via het aanpassen van mijn HOSTS file test ik inderdaad of de website etc. correct functioneren. Zelfde geldt ook voor email etc.

Het forwarden van de mail kan ik helaas niet regelen op de server, aangezien ik daar nog op reseller niveau zit en dus niet alle inkomende mail kan forwarden naar de nieuwe server.

Stap 6 (5&6 bij mij) kost inderdaad tijd, en zal ik dus ook een nachtje in het weekend voor op moeten offeren.

[mrFoce]

Geloof dat het meeste wel besproken is, maar ik zou dit doen (kleine afwijking m.b.t. naast bovenstaande).

Na initiele configuratie van je VPS zet je de database connectie open voor IP verbindingen vanaf je huidige host;
Upload de databases van je huidige host naar VPS en configureer de sites om met de nieuwe database te verbinden;
Zet de DNS om wanneer alles gemigreerd is. Dit levert 0 downtime op omdat je oude host en nieuwe host naar dezelfde database wijzen;
Na een paar dagen zeg je de oude host compleet op (o.i.d.);

Op bovenstaande manier is de database altijd up 2 date (toegegeven, misschien iets langzamer gedurende migratie omdat het de data over een TCP connectie stuurt). Let zelf even op of je dat via SSL wilt laten lopen of niet (http://dev.mysql.com/doc/...n/secure-connections.html).
Nadat de migratie is afgerond en de DNS is ge-update, kan je die remote connecties weer uitschakelen indien gewenst.

[bartbh]

De database is dan inderdaad wel up-to-date, maar met bestanden en email loop je nog steeds kans op fouten. Dus die optie zal niet mijn voorkeur hebben, bovendien zou ik dan van alle websites ook de mysql host aan moeten passen.

Beter lijkt het mij om de sites op de oude hosts uit te schakelen (suspend in Directadmin), met een aangepast melding. Zo krijgen de mensen waarvan de DNS-records heel langzaam worden bijgewerkt, een melding te zien met daarop uitgelegd waarom ze dit te zien krijgen.

Op deze manier is de kans op dataverlies volgens mij het kleinst. Wel heb je dan enige downtime, maar dat liever dan dataverlies.

[mrFoce]

bartbh schreef op maandag 23 april 2012 @ 18:48:
De database is dan inderdaad wel up-to-date, maar met bestanden en email loop je nog steeds kans op fouten. Dus die optie zal niet mijn voorkeur hebben, bovendien zou ik dan van alle websites ook de mysql host aan moeten passen.

Beter lijkt het mij om de sites op de oude hosts uit te schakelen (suspend in Directadmin), met een aangepast melding. Zo krijgen de mensen waarvan de DNS-records heel langzaam worden bijgewerkt, een melding te zien met daarop uitgelegd waarom ze dit te zien krijgen.

Op deze manier is de kans op dataverlies volgens mij het kleinst. Wel heb je dan enige downtime, maar dat liever dan dataverlies.

Ja, het ligt een beetje aan je huidige set-up. Als je database niet op localhost stond, is het erg eenvoudig. Als alles naar 'localhost' connect, dan wordt het wat lastiger. E-mail e.d. is inderdaad lastig als je dit ook zelf host en niet extern onderbrengt. Hoe je dat synchroniseerd verschilt per e-mailserver.

[fds]

mrFoce schreef op maandag 23 april 2012 @ 18:23:
Geloof dat het meeste wel besproken is, maar ik zou dit doen (kleine afwijking m.b.t. naast bovenstaande).

Na initiele configuratie van je VPS zet je de database connectie open voor IP verbindingen vanaf je huidige host;
Upload de databases van je huidige host naar VPS en configureer de sites om met de nieuwe database te verbinden;

Leuk bedacht maar kan/mag/wil je zomaar de site van een klant wijzigen?
Daarnaast ga je niet zomaar MySQL over het internet gooien, zonder extra beveiligingen.

Een SSL tunnel tussen de 2 servers leggen is nog wel een optie.
MySQL kan je er veilig doorheen laten gaan en met de juiste instellingen hoef je aan de sites van klanten helemaal niets te wijzigen! Je hebt dan wel wat vertragingen in de database verbinding, maar tijdelijk gedurende de verhuizing is dat wel te doen.

De vraag is of je veel (down)tijd wint. Je moet namelijk ALLE database tegelijk verhuizen, wat waarschijnlijk meer tijd kost dan een los domein in zijn geheel te verhuizen.
Ook krijg je extra rompslomp met account management en mogelijk problemen als men geen localhost, maar de domeinnaam gebruikt voor de MySQL verbinding.

[mrFoce]

fds schreef op maandag 23 april 2012 @ 21:13:
[...]


Leuk bedacht maar kan/mag/wil je zomaar de site van een klant wijzigen?
Daarnaast ga je niet zomaar MySQL over het internet gooien, zonder extra beveiligingen.

Een SSL tunnel tussen de 2 servers leggen is nog wel een optie.
MySQL kan je er veilig doorheen laten gaan en met de juiste instellingen hoef je aan de sites van klanten helemaal niets te wijzigen! Je hebt dan wel wat vertragingen in de database verbinding, maar tijdelijk gedurende de verhuizing is dat wel te doen.
...

Grappig dat je mijn post gedeeltelijk quote en het stuk waarin ik zeg

Op bovenstaande manier is de database altijd up 2 date (toegegeven, misschien iets langzamer gedurende migratie omdat het de data over een TCP connectie stuurt). Let zelf even op of je dat via SSL wilt laten lopen of niet (http://dev.mysql.com/doc/...n/secure-connections.html).
Nadat de migratie is afgerond en de DNS is ge-update, kan je die remote connecties weer uitschakelen indien gewenst.
voor het gemak vergeet maar vervolgens wel komt met: je gaat het niet zomaar over het internet gooien

Daarnaast geef ik later toe dat het misschien per host verschilt, maar ik ken een hoop host die tegenwoordig alle databases extern hebben staan en dan is het zeer eenvoudig om de host file op die machine om te zetten naar een andere locatie. Been there, done that.

[ Voor 9% gewijzigd door mrFoce op 24-04-2012 03:47 ]

[bartbh]

De websites zijn allemaal bij mij in beheer, dus dat is in dit geval het punt niet. Wel is het zo dat ik het voordeel er op dit moment niet van in zie, zeker aangezien de meeste databases relatief klein zijn vergeleken met de emailinbox en overige bestanden. Ik heb alle gebruikers al eens gebackupt en overgezet, en daarmee verwacht ik binnen een uur alles overgezet te kunnen hebben.

Dus dan ga ik liever voor een downtime in een nacht in het weekend, dan eventuele kansen op dataverlies. Dus gebruiker gaat dan 1 op 1 over, hetgeen met directadmin eenvoudig te realiseren is.

In ieder geval wel bedankt voor het meedenken Meer opmerkingen zijn uiteraard nog welkom, want voorlopig zet ik ze nog niet over.