Paul Stevens - Case Study: Zero-Downtime Plone Hosting

Meer info: Nederlandse Plone gebruikersdag 2012.

Paul Stevens werkt bij NFG.

Voor RIPE hebben we een Plone site gemaakt. Eis was dat deze website nooit down mag. Specifiek: 99,99 procent uptime. De capaciteit om websiteverkeer aan te kunnen moet hoog genoeg zijn, zodat de website snel is. De website moet ook niet tijdelijk onbereikbaar zijn in verband met onderhoud.

Vroeger was een website simpelweg een paar plaatjes en statische html. Dat is makkelijk in de lucht te houden. Plone is een complete applicatieserver. Wat je meestal doet is dat je een webserver hebt (Apache, nginx) die met de Plone applicatieserver praat. Schaling wordt dan lastig, want Plone kan minder verzoeken aan dan een webserver die alleen statische content serveert.

In ieder geval moet je ZEO gebruiken, zodat je de Plone scheidt van de database met de inhoud. Je kan varnish tussen de webserver en Plone zetten, zodat varnish vaak opgevraagde pagina's of onderdelen die vrijwel nooit veranderen, kan onthouden en kan aanbieden zonder via Plone te hoeven gaan. Zo kan je er lagen tussen blijven schuiven. De bottleneck blijft Plone. Zo schaal je verticaal op.

Je kan ook horizontaal opschalen: je zet meerdere Plone instanties naast elkaar. Dan kan je de eerste Plone herstarten met nieuwe code, dan de tweede, enzovoorts. Rolling upgrades noemen we dat. Dan blijft de gebruiker de website zien.

Maar: varnish weet niet dat die eerste Plone eventjes niet beschikbaar is. Dan zet je HA-Proxy erin. Die houdt dat bij en kan helpen bij sticky sessions.

Dan heb je nog steeds een single point of failure, één plek waar het mis kan gaan. Dat is in dit geval vooral de ZODB database. We zijn MySQL gaan gebruiken met RelStorage om de Plone database in op te slaan. MySQL hebben we in een cluster gezet, zodat er meerdere databaseservers zijn. We hebben performancetests gedaan en MySQL kwam er tot onze verbazing beter uit dan PostgreSQL.

Dan moet je nog zorgen dat niet alle verzoeken bij één webserver met zijn achterliggende varnish en HA-Proxy terechtkomen. Dus die opzet verdubbel je. De HA-Proxies kunnen, middels een cloudcomputing opzet van RIPE zelf, bij alle Plone instanties. De twee stacks draaien op verschillende locaties, in Amsterdam en Almere.

Daarboven zit dan een load balancer, maar die is de verantwoordelijkheid van de klant. Daarnaast hebben we ook bewakingssystemen die in de gaten houden of alles nog draait. Je moet ook regelen dat er iemand is die reageert als er problemen zijn, die 24 uur per dag in kan grijpen.

Sindsdien hebben we nooit de site uit de lucht hoeven halen. Er zijn wel storingen geweest, maar dat lag aan hardwareproblemen, zoals harde schijven en netwerkverbindingen.

We hebben het hier over een miljoen unieke bezoekers per maand.

Plone was eerder in beeld geweest bij RIPE, maar een interne Javaclub was er in eerste instantie mee aan de slag gegaan met een eigen systeem. Dat ging niet goed en uiteindelijk is toch weer voor Plone gekozen.