De verhuizing

De OBA website kreeg het steeds zwaarder : meer content op de voorpagina, meer leden, meer plugins.
De eerste problemen ontstonden door het gebruik van de feedwordpress plugin; een feed kan een zeer groot bestand zijn, en de feed-cache legde een groot beslag op het geheugen.
Vooral op het moment dat je een beheer-actie uitvoert op een CMS, leg heb je extra geheugen nodig. We zijn overgestapt op PuSH om dat probleem het hoofd te bieden, en om de “gebruikersbeleving” meer real-time te laten zijn. Het was een simpel idee, maar de uitwerking van PuSH heeft een paar grijze haren opgeleverd. Veel mensen bleken als een verslaafde op de “publish” knop te hameren, tientallen keren achter elkaar. Sommige websites lijken te stotteren; ze versturen van elk nieuw bericht meerdere kopieen. Met name Blogspot is daar goed in : PuSH verwacht 1 bericht van ongeveer 4 kilobytes. Blogspot stuurt soms 5 identieke berichten van 110 kilobytes tegelijk. PHP blijkt over een aantal rottige eigenschappen te beschikken, waar ik als voormalig C en Cobol programmeur vroeger helemaal geen last van had. Je kan een lock zetten, maar een PHP script is geen proces, dus een ander script liep gewoon door alsof er geen lock bestond.
Het volgende probleem was, dat de mails aan de abonnees vaker niet dan wel verstuurd werden. Ook dat werd waarschijnlijk veroorzaakt door een gebrek aan geheugen en door timeouts. Ons “shared hosting” pakket bood gewoon niet genoeg ruimte om alles te doen wat we wilden. Op 1 oktober zou het contract met de huidige hoster aflopen, en hoewel het om een slechts een paar tientjes ging, hadden we ons voorgenomen om voor die tijd te verhuizen naar een andere hoster.
Het punt was, dat we meer geheugen nodig hadden, en daar kon je niet aan komen bij een shared host. Diskspace krijg je overal genoeg, en aan de datalimiet kom je ook niet, maar OBA had meer processing-power nodig. Door het bezit van een eigen server wist ik al dat alle problemen met scripts zijn terug te voeren op zulke beperkingen.
Maar ja, die server die de hele dag en nacht aan staat, kost energie, en hij raakt een keer versleten. Met een eigen server heb je meer mogelijkheden dan bij een shared host. Sommige shared hosts zijn zo beperkt, dat de nieuwste wordpress versie er niet eens op draait. De meeste webshops zullen echter geen eigen server onder de toonbank hebben staan. Het aanbod van hosting bedrijven is enorm. Ina deed wat onderzoek naar klanttevredenheid en prijs/kwaliteit en kwam met een voorstel. Ik prikte het apparaat dat ons uit de brand zou kunnen helpen, gebaseerd op de kosten en de specificaties. We nemen een VPS; een virtual private server. Daar kunnen we meerdere domeinen op zetten. We doen zelf het beheer, en we kiezen voor Ubuntu Linux, want daar ken ik de weg in. En zo geschiedde. De eerste 2 weken na het nemen van het abonnement heb ik nog weinig kunnen doen, omdat de bestande PuSH software veel aandacht kostte, maar toen stond binnen een paar dagen alle software er op. ( moeilijkheden : de plugin die de database-backup moest maken werkte niet goed. Geen enkele backup-plugin had gewerkt, want de bug zit in MySQL zelf. Ik heb een workaround gefabriekt ) De nieuwe plek had een eigen ip-nummer en alle software, maar geen domeinnaam, want die wees nog naar de oude plek. Ik instrueerde apache om ook naar de domeinnaam zonder www te luisteren. Zo kon ik met een regeltje in de hosts file van mijn eigen computer de nieuwe site bereiken, en de oude, naast elkaar. Al snel leken ze zo veel op elkaar, dat we een waarschuwing op de nieuwe voorpagina moesten plaatsen : “Let op, dit is de nieuwe site !” Ina schreef de tekst die de gebruikers te zien zouden krijgen als de verhuizng gereed was. We hadden met opzet de gebruikers niet van tevoren geïnformeerd, omdat het slechte voorbeeld van weblog.nl iedereen in de gordijnen zou hebben gejaagd.
De ervaring die ik opgedaan had met mijn eigen server bleek goud waard te zijn. Foutmelding ? O ja, hier staat het. Dit zijn de commando’s om die nieuwe module te installeren : knip – plak – klaar.
We zijn eigenlijk wel klaar om te verhuizen, schreef ik optimistisch aan Ina, toen de bestaande berichten gekopieerd waren en elk nieuw bericht dubbel verstuurd werd. Het dubbel versturen leverde veel hoofdpijn op. Het kwam allemaal wel aan, maar je moest het naderhand corrigeren. Een paar minuten later stuurde ze het token al. Dat is snel 😮
Wat moet ik invullen bij DNS servers ? De nieuwe provider is niet zo sterk in documenteren, maar heeft wel een gebruikersvereniging waar erg veel informatie wordt uitgewisseld. Die vraag was al een keer beantwoord. Het bleek dat je pas toegang kreeg tot je nieuwe DNS servers, na het afronden van de bestelling van het product “verhuizing”. Ik rekende er op dat in de loop van de komende dagen er een moment zou komen dat de verhuizing werd uitgevoerd. Ik laad nu die backup, dan doe ik dat de komende dagen nog een paar keer, en intussen zal ik zorgen dat die synchronisatie wat soepeler verloopt, dacht ik.

Een paar uur later verschenen er foutmeldingen in de log. PuSH kon geen contact meer krijgen met de oude website. Hij probeert dat 7 keer. Heel simpel stuurde hij van alles een kopie naar de nieuwe website, dus kregen we alles daar in 7-voud. Daar had ik nog wat aan willen doen.
De oude site gaf een foutmelding : database onbereikbaar, stond er in grote letters op het scherm. Nu al ????
Op de nieuwe site had iemand een reactie achtergelaten.
??????????
Dat betekent dat in delen van het land de nieuwe site al te zien is !
Terwijl PuSH bleef proberen de oude site te bereiken.
Dit is dus het enige dat fout gegaan is aan de verhuizing.
Het had naadloos moeten gaan, maar omdat de directory “wordpress” niet meer voorkomt in de nieuwe situatie, was de URL veranderd.
Ik paste het adres aan met een SQL update, en hij ging gewoon door ???
Tussen PHP en MySQL zit kennelijk een soort cache. Mijn webserver geherstart, en bingo, nu liep alles goed.
Er was wel wat handwerk nodig om de voorpagina weer in orde de krijgen. Plaatjes en berichten waren elkaar kwijt, de update van de reacties kon nog niet uitgevoerd worden, omdat de ID’s van de oude en de nieuwe berichten niet identiek waren. Vanaf het moment dat PuSH de nieuwe site als zijn primaire doel zag, was dat probleem opgelost.
De komende tijd gaan we nog meer zaken verhuizen. PuSH is nu een 2-server oplossing, waarbij de communicatie tussen die 2 de achilleshiel bleek te zijn. Straks wordt alles geïntegreerd. We gaan onze eigen blogjes ook zelf hosten. En we gaan OBA nog groter, mooier en beter maken, maar daarover in de toekomst meer.

Hoe het niet moet

Big Bang scenario bij automatiseringsprojecten

Is meestal geen goed idee.
Ja, het is de goedkoopste manier, en als alles goed gaat, merkt niemand er wat van.
Een geleidelijke migratie duurt langer, kost meer, en levert je heel lang negatieve aandacht op.
Maar er zitten zodanige risico’s aan, dat een bedrijf dat zijn geld verdient aan een dienst waarvoor de computer essentieel is, er niet over zou peinzen om dit scenario te volgen.

Sanoma adverteert er niet mee, maar bloggen is niet “business-critical”, de dienst mag best een paar dagen onderbroken worden.
Dat de planning van 2 dagen niet haalbaar was, wist men op het hoofdkantoor ook wel. Als adverteren je business is, weet je ook wel dat je de zaken zo rooskleurig mogelijk moet voorstellen.
Het wordt een volle week, dat lijkt men op de automatiseringsafdeling te hebben berekend.
Je weet wel wat er gebeurt als je zegt dat het een maand kost, en meer geld kost dan het bedrijf in 2 jaar opbrengt.
Weg baan.
Dus de automatiseringsafdeling loog tegen het hoofdkantoor, en het hoofdkantoor loog tegen de klanten, en zo werd een maand 2 dagen.

Hoe zou een grote bank dit aanpakken ?
Ze zouden het nieuwe systeem bouwen en testen.
Dan zouden ze alle statische gegevens uit het oude systeem kopieren naar het nieuwe.
Daarnaast zouden ze een tijdelijk testsysteem maken.
Ze zouden alle invoer van het oude systeem dupliceren naar het nieuwe, en het tijdelijke testsysteem zou de uitvoer van het oude en het nieuwe systeem met elkaar vergelijken.
Het klinkt misschien belachelijk complex, maar dit was een praktijkvoorbeeld van een bank waar ik gewerkt heb.
Van die migratie heeft nooit iemand wat gemerkt, wel heeft het veel geld gekost.

De “amateurclub” OBA heeft in de eerste plaats wel respect voor gebruikers en werkt in de tweede plaats niet met big-bang scenario’s.
We gaan van iets dat werkt, naar iets dat goed werkt, en van daar naar iets dat beter werkt, enz.
Het is niet zo dat Sanoma dat niet had kunnen doen, omdat ze groter zijn.
Ze hadden gedurende een half jaar extra servercapaciteit kunnen huren, en een paar goede programmeurs.
De technologie die OBA gebruikt ( PuSH ) is heel geschikt om het ene CMS te vullen met de content van het andere.
De reden dat ze toch gekozen hebben voor het big bang scenario is een simpele : Sanoma is een worstfabriek. De klanten zijn de adverteerders. De bloggers zijn de koeien.
De automatiseerders zullen flink hebben moeten onderhandelen om 8 jaar oude blogjes te bewaren (bejaarde koeien die niets opleveren).

Posted

23/09/2011

Wordpress

beheerder

Tags:

migratie, OBA, VPS

De verhuizing

Comments

114 responses to “De verhuizing”

Leave a Reply