Aanpak migratie van webapplicaties

[Standeman]

We zijn van plan om ons SaaS platform, c.q. webapps, te gaan over te gaan heven naar een nieuwe machines van een andere hoster. Nu is het probleem alleen dat onze applicaties zo'n beetje 24/7 gebruikt worden en dus ook in de lucht moeten zijn. Downtime van maximaal een uur is nog wel op te vangen, maar langer moet het niet worden want dan gaat klanten (terecht!) klagen.

Nu moeten we nog met de nieuwe hoster om de tafel gaan zitten om een plan te bedenken, maar aangezien ik wel een beetje beslagen ten ijs wil komen zit ik al wel te brainstormen over hoe we dit gaan aanpakken met zo min mogelijk downtime.

Het probleem zit 'm met name in de URL's en hoe lang het duurt voordat de DNS records bijgewerkt zijn wanneer ik de IP's verander. Dit is natuurlijk niet instant, maar kan per, door de klant, gebruikte DNS server afhangen wanneer men naar het nieuwe IP adres gerouteerd wordt.

Het plan wat ik nu heb is als volgt:

De nieuwe machine wordt gewoon ingericht zoals de bedoeling is met onze webapps en mysql database met het verschil dat ik de database via SSH wil laten repliceren met de oude machine. Wanneer ik dan de IP's van de DNS records vervang zal gedurende 8 uur clients of op de oude machine terecht komen of op de nieuwe machine, maar wel met dezelfde data.
Wanneer er geen requests meer op de oude omgeving binnenkomen, kan ik er vanuit gaan dat alle DNS records zijn bijgewerkt en wordt de oude omgeving de nek omgedraaid.

Aangezien ik een slechts een simpele developer ben en zeker geen netwerk-guru zat ik me af te vragen of dit plan levensvatbaar is of dat er veel betere wijze zijn om een dergelijke migratie uit te voeren?

[jvanhambelgium]

Dit plan is zeer zeker levensvatbaar en zowat een standaard denk ik voor migraties zoals deze.
Zorg inderdaad voor een "parallele" setup bij je nieuwe hoster en zorg dat je DB zo "synchroon" mogelijk raakt. (kleine delta)
We kennen natuurlijk niet alle details rond de complexiteit van de web-app + DB-interactie, dat dient mischien nog wat extra aandacht.

[Standeman]

jvanhambelgium schreef op woensdag 06 juni 2012 @ 10:15:
Dit plan is zeer zeker levensvatbaar en zowat een standaard denk ik voor migraties zoals deze.
Zorg inderdaad voor een "parallele" setup bij je nieuwe hoster en zorg dat je DB zo "synchroon" mogelijk raakt. (kleine delta)
We kennen natuurlijk niet alle details rond de complexiteit van de web-app + DB-interactie, dat dient mischien nog wat extra aandacht.

Tja het grootste nadeel wat ik nu heb is dat op de oude omgeving nog met MySQL 4.1 gewerkt wordt en op de nieuwe MySQL 5.5. Volgens de documentatie moet het lukken als van de oude 4.1 versie de master maak.

[CyBeR]

Je wilt dus master-master replicatie opzetten voor die paar uur dat je potentieel twee omgevingen tegelijk hebt? Of is je applicatie read-only?

Ik zou zelf vanaf de ene naar de andere omgeving proxy'en voor zo lang als dat duurt, zodat je altijd maar een live-omgeving hebt. En vervolgens die omschakeltijd zo kort mogelijk maken door ruim vantevoren (bijvoorbeeld nu) de ttl op je dns te verlagen.

[F_J_K]

Klinkt inderdaad helemaal niet raar.

Maar inderdaad hangt het wel een beetje af van in hoeverre de state belangrijk is. Bijvoorbeeld als twee verschillende clients verschillende ideeen over welk IP adres moet worden benaderd, maar gebruik willen maken van dezelfde data.

Check ook logfiles even of er niet ergens een grappenmaker is die het IP adres gebruikt ipv de domeinnaam. En evt. tijdelijk de TTL nog wat verlagen naar bijv 1 uur. De onderliggende vraag verandert er niet door, maar het gaat wat rapper.

Afhankelijk van hoeveel klanten je hebt en wat het technische niveau is van de klanten, wil je misschien ook vooraf helder aangeven dat en wanneer het gebeurt.

--

Zou je in theorie ook niet tijdelijk twee IP-adressen kunnen hebben op eenzelfde nieuwe server? En dan dus zeg een dag lang al het verkeer naar de nieuwe server laten routeren (of bijv via reverse proxy). Maar dat kan eengevalletje klok-klepel van mij zijn

edit:

Zegt spuit 11

[Standeman]

Even wat meer info over de omgeving:

De clients zijn voornamelijk apps die op telefoons / tablets draaien. De apps kunnen we niet zomaar updaten omdat de klant zelf bepaald welke versie e.d. op de telefoon staat. Gelukkig connecten ze allemaal via de beschikbare URL's met onze server. Verder is er nog een backoffice / management omgeving waar klanten de data kan beheren. Ik verwacht niet dat we problemen met de state zullen krijgen wanneer de DB's goed repliceren.

CyBeR schreef op woensdag 06 juni 2012 @ 10:22:
Je wilt dus master-master replicatie opzetten voor die paar uur dat je potentieel twee omgevingen tegelijk hebt? Of is je applicatie read-only?

Nee, zeker niet readonly. Maar het meeste gebeurt met transactieloze inserts.

Ik zou zelf vanaf de ene naar de andere omgeving proxy'en voor zo lang als dat duurt, zodat je altijd maar een live-omgeving hebt. En vervolgens die omschakeltijd zo kort mogelijk maken door ruim vantevoren (bijvoorbeeld nu) de ttl op je dns te verlagen.

hmmm, zou dat kunnen door request te redirecten met apache? Bijvoorbeeld in httpd.conf:

code:

Redirect permanent / http://nieuw.domain.com/

[B-Man]

Reverse proxy betekent dat je (bijvoorbeeld) je oude servers alle http requests zelf laat doorsturen naar de nieuwe omgeving. Of een request dan binnenkomt op de oude of nieuwe omgeving maakt niets uit (los van responsetijd, de omgeving die de reverse proxy draait zal een stuk trager zijn).

Zie http://httpd.apache.org/d.../mod_proxy.html#proxypass

[jvanhambelgium]

Zou je in theorie ook niet tijdelijk twee IP-adressen kunnen hebben op eenzelfde nieuwe server? En dan dus zeg een dag lang al het verkeer naar de nieuwe server laten routeren (of bijv via reverse proxy). Maar dat kan eengevalletje klok-klepel van mij zijn

Dat zal nooit werken. De TS gaat van Hoster A over naar Hoster B die elks hun eigen IP-ranges hebben. Je kan dus niet op een server zomaar een IP bijvoegen van een andere hoster. Internet zal die nooit kunnen bereiken en jij krijg geen info buitengestuurd...

[F_J_K]

jvanhambelgium schreef op woensdag 06 juni 2012 @ 12:38:
Dat zal nooit werken. De TS gaat van Hoster A over naar Hoster B die elks hun eigen IP-ranges hebben. Je kan dus niet op een server zomaar een IP bijvoegen van een andere hoster. Internet zal die nooit kunnen bereiken en jij krijg geen info buitengestuurd...

Iets dergelijks heb ik wel eens heel erg zijdelings meegemaakt (miljoenentraject, dan kan er vast meer ), maar heb de techniek toen niet meegekregen.

Tenminste via VPN zou het toch moeten kunnen? Je hebt sowieso natuurlijk wel de medewerking nodig van beide hosters. Maar proxy is eenvoudiger.

[jvanhambelgium]

Tja , mischien moet je het allemaal niet ingewikkelder maken ;

1// Zorg voor de nieuwe webserver bij de nieuwe hoster B en koppel die gewoon met de huidige productie-database bij hoster A (performantie zal mogelijks wat "minder" zijn door meer delay

2// Pas DNS aan zodat je stilletjes aan (TTL) nieuwe requests zie binnenkomen bij hoster B en wacht dan nog zeker 24 uur oid.

3// Breng de site gewoon in z'n geheel "down" en copy de DB-files van hoster A -> hoster B over je SSH-verbinding en kick alles weer op gang.Aanpassen van de applicatie om nu naar de "locale" DB te wijzen ipv de remote DB bij hoster A. . "outage" moet op deze manier toch ook wel kort zijn niet ?

Het is toch geen bank hé ? Wat downtime moet kunnen ;-)

[jvanhambelgium]

F_J_K schreef op woensdag 06 juni 2012 @ 12:44:
[...]
Tenminste via VPN zou het toch moeten kunnen? Je hebt sowieso natuurlijk wel de medewerking nodig van beide hosters. Maar proxy is eenvoudiger.

Tja, als je met VPN-constructies / tunneling begint te stoeien is er inderdaad weer veel mogelijk, maar je maakt dan alles ook wel een stuk complexer in geval van troubleshooting ;-)

[F_J_K]

Gegeven het gebrek aan state is het allemaal een stuk minder spannend, het hier serieus overwegen lijkt me inderdaad niet nodig maar ik was nu zelf even nieuwsgierig

[CyBeR]

Standeman schreef op woensdag 06 juni 2012 @ 10:35:

Nee, zeker niet readonly. Maar het meeste gebeurt met transactieloze inserts.

Wel of geen transacties maakt niet zoveel uit. Als je met twee databases gaat werken, en je doet in beide inserts heb je later een enorme kliederboel om uit te zoeken, tenzij je twee kanten op repliceert.

hmmm, zou dat kunnen door request te redirecten met apache? Bijvoorbeeld in httpd.conf:

code:

Redirect permanent / http://nieuw.domain.com/

Dat is een redirect. Dat werkt wellicht ook, dat ligt aan je app. Maar ik bedoelde een reverse proxy: je client stuurt dan een request naar de oude server, en die stuurt 't door naar de nieuwe. Dat kan met mod_rewrite of mod_proxy en dan ProxyPassReverse (zeg ik uit m'n hoofd-- ik doe altijd mod_rewrite.)

Als je proxiet heb je trouwens twee mogelijkheden:
• Je proxiet van de oude omgeving naar de nieuwe; dus je zet DNS om naar de nieuwe omgeving en clients komen, bij gebrek aan dns cache, daar uit. Clients met cache komen bij de oude omgeving uit en worden doorgeproxiet.
• Je proxiet van de nieuwe naar de oude omgeving, totdat je de omzetting wilt doen. Dit kun je wat ruimer vantevoren doen, zodat alle clients bij je nieuwe omgeving uitkomen en daar geproxiet worden. Eenmaal klaar om de omzetting te doen gooi je de site even down, kopieer je je database, en zet je de site weer up zonder de proxy-rule. (De site down is zodat er terwijl je kopieert geen inserts gebeuren-- dat is sowieso verstandig op dat moment, ongeacht wat je doet.)

[Remco]

Je zou ter voorbereiding ook je TTL van je DNS records naar beneden bij kunnen stellen. B.v. naar een paar minuten. Dit zorgt ervoor dat de nieuwe URL's wat sneller worden geresolved.

[DukeBox]

Zoals CyBeR al aangeeft zou ik het ook middels een reverse proxy doen. DNS laten verwijzen naar reverse proxy, de reverse proxy laten wijzen naar de oude omgeving. Dan rustig de data omzetten en vervolgens de reverse proxy omzetten naar de nieuwe (meteen een snelle roll back indien het niet werkt). Wanneer alles goed is kan je de DNS weer direct laten wijzen naar de nieuwe locatie.

Wat betreft TTL naar beneden zetten, dat helpt soms maar meestal wordt dit door tussenliggende DNS cache servers genegeerd. Wat vaker helpt is een nieuwe en de oude A(AAA) aanmaken en de originele DNS als CNAME laten wijzen naar het oude of nieuwe A(AAA) record. CNAME's worden vaak niet gecached.

[ Voor 28% gewijzigd door DukeBox op 06-06-2012 16:41 ]

[CyBeR]

DukeBox schreef op woensdag 06 juni 2012 @ 16:38:
Wat betreft TTL naar beneden zetten, dat helpt soms maar meestal wordt dit door tussenliggende DNS cache servers genegeerd.

Het wordt wel eens genegeerd, dus je kunt er niet van uitgaan dat 't goed gaat. Maar 'meestal' gaat me te ver.

[Freeaqingme]

jvanhambelgium schreef op woensdag 06 juni 2012 @ 12:38:
[...]


Dat zal nooit werken. De TS gaat van Hoster A over naar Hoster B die elks hun eigen IP-ranges hebben. Je kan dus niet op een server zomaar een IP bijvoegen van een andere hoster. Internet zal die nooit kunnen bereiken en jij krijg geen info buitengestuurd...

Zoek even op BGP. Bij wat grotere projecten is het niet heel vreemd dat de klant zelf zijn ip-range aanlevert, en dat de hoster deze enkel hoeft te configureren. Zeker als het om ipv4-PI (place independent) ranges gaat komt dit veel voor.

[jvanhambelgium]

Freeaqingme schreef op woensdag 06 juni 2012 @ 17:01:
[...]


Zoek even op BGP. Bij wat grotere projecten is het niet heel vreemd dat de klant zelf zijn ip-range aanlevert, en dat de hoster deze enkel hoeft te configureren. Zeker als het om ipv4-PI (place independent) ranges gaat komt dit veel voor.

BGP ken ik nog wel een beetje hoor. Als ik de TS zo hoor spreken gaat het hier over 1 max 2 servertjes (al dan niet virtueel) die van hosterA -> hosterB moeten. Die servertjes/VPS'je zitten netjes in een blokje van de hoster en zijn niet porteerbaar naar de concurrent ;-)


btw,

PI = Provider Indepedent
PA = Provider Aggregable

[vliegjong]

Een Reverse proxy idd op de huidige locatie en dan een andere forward maken tijdens replicatie.
Verder een F5 LTM kan je ook heel mooi helpen...

[AndriesLouw]

TTL van je DNS omlaag zetten, en dan inderdaad of tijdelijk een reverse proxy gebruiken, zodat je in een keer alle gebruikers kunt schakelen naar het nieuwe platform, of het nieuwe platform op de database van de oude tijdelijk laten draaien (of andersom). Let er wel op dat op een externe database draaien behoorlijk traag kan zijn i.v.m. de latency voor elke query.

Het live repliceren van databases heb ik niet al te beste ervaringen mee, helemaal het gebruik van auto-increment ID's waardoor toevallig op beide masters een rij met hetzelfde ID wordt ingeschoten, en je hele synchronisatie vastloopt, is een groot euvel in MySQL.

Desnoods gewoon de oude omgeving read-only maken, dit melden aan de gebruiker wanneer hij op de oude omgeving zit, en afwachten wanneer de TTL afloopt.

[Rolfie]

Ga soms gewoon voor het KISS Principe.

TTL van te voren aanpassen. DNS record aanpassen naar de nieuwe server, en op je oude server een tijdelijke pagina neer zetten dat de site wegens migratie uit de lucht is.
Kost je maximaal 24 uur als niet alle DNS servers de TTL handhaven.
Bij goede voorbereiding is dit toch de gemakkelijkste.

Vrijdag nacht starten, max zaterdag volledig live.

Reverse proxy kan ook, maar kost allemaal veel meer tijd en je zal het goed moeten testen.