Storage voor webhosting verandert snel

Jaren geleden, toen ik in de webhosting-business begon, was er vlak voor mijn start voor een grote klant een keuze gemaakt voor toenmalige hosting infrastructuur. File servers (NFS) met daarvoor een aantal webservers. Het hele netwerk zou FreeBSD gaan draaien om op die manier meer uptime, schaalbaarheid en uitbreidbaarheid te kunnen bieden. FastCGI werd degelijk geïmplementeerd zodat we total package isolation konden toepassen (iets wat we tot op de dag van vandaag nog steeds in elk hostingplatform toepassen).

Storage-leveranciers
Toen we op een gegeven moment een tweetal fileservers hadden met een slordige 25 miljoen bestanden en het met rsync 2,5 dag kostte om te gaan bepalen wat hij moest synchroniseren (om zodra het proces echt begon al weer hopeloos achter te lopen), werd het tijd voor iets anders. We zijn destijds gaan praten met de bij ons bekende storage-leveranciers. Na een eerste selectieronde zaten we met EMC aan tafel en we spraken met NetApp. Beide hadden een interessante propositie, qua performance deden ze nauwelijks voor elkaar onder. Uiteindelijk hebben we voor EMC gekozen. Een goede naam, wereldmarktleider op het gebied van storage en vanaf dag één duidelijk een partij met veel kennis van zaken.

Veel disken
De EMC NS352 werd geleverd, de hostingpakketten werden gemigreerd en het NFS gedeelte draaide rock solid op een aantal fibre channel disken. Dit ging acht maanden goed en toen merkten we dat we meer performance nodig hadden. En dit was het moment dat je weet, waarom je met een degelijke storage leverancier in zee bent gegaan. Waar we vroeger aan de slag moesten met rsync, pakket voor pakket migreren, konden we nu een block level replicatie aanzetten naar nieuwe disken en een nachtmoment kiezen om te migreren naar meer nieuwe 15k fibre channel disken. Downtime is minimaal (een minuut of tien) en vervolgens heb je weer meer performance. Er wordt enorm veel geroepen in storageland: honderdduizenden IOPS, cache, 4Gbit, 8Gbit, maar voor een mail- of webomgeving van een hosting provider, met een sustained load van vele duizenden IO-operaties per seconde – die allemaal klein zijn en ook nog eens op willekeurige plekken op het file system langskomen – heb je gewoon veel disken nodig: spindles. Iedere disk kan een vast aantal, maximale IO’s aan, dus meer IO nodig, betekent meer disken.

Win-win-win
Dit principe hanteren we nog steeds, zo ook in maart van dit jaar. Migratie nummer vier inmiddels. Van een NS352 naar een CX4-240 met een Celerra NS-42G, naar een CX4-480 met meer disken en een zwaardere gateway (Celerra NS-G8) en naar een nieuwe EMC VNX Unified, met FastCache. Tientallen FC-disken (niet voor de opslag, wel voor de IO) per file system, met daarboven enkele honderden gigabytes aan “FastCache”. Een EFD (Enterprise Flash Drive, duur woord voor SSD) laag die boven je storage-apparaat als read en write cache fungeert. Gevolg: op dag één na implementatie al lovende berichten van klanten. Latency omlaag, throughput omhoog. Door de EFD’s minder belasting op de FC disken, wat weer betekent dat daar meer IO overblijft voor de andere webservers. Win-win-win.

Snelle technische veranderingen
Het is een veranderende tijd in hostingland. 25 miljoen bestanden vier jaar geleden zijn er inmiddels bijna 200 miljoen. Dankzij block replicatie (we hebben geografisch redundante storage voor onze hostingplatformen) kunnen we dit soort aantallen files nog managen. Hier kun je niet meer file-based operaties op los laten. Scale out NAS architecturen kunnen natuurlijk ook (Isilon, GlusterFS) maar het gaat om zo weinig data, zulke kleine files, dat zoiets zonde is van de disken. Vandaag de dag installeer je een website om hem vervolgens aan te passen, in plaats van een website te ontwerpen en te uploaden. WordPress, Joomla, Drupal, Magento, allemaal functioneel prachtige pakketten, maar nachtmerries voor de infra-beheerders. Het stelt enorme eisen aan je infrastructuur, heel veel disk IO, CPU kracht en memory (de meeste pakketten draaien niet lekker met minder dan 64MB APC/eAccelerator op-code cache per pakket). Dan heb je per 1000 hostingpakketten toch zo’n 64GB memory nodig.

Flinke stappen
We zijn heel druk met de optimalisatie van hostingplatformen. PHP 5.3 voegt veel toe, maar lang niet iedereen is er klaar voor. APC levert veel snelheidswinst op, maar vereist andere infrastructuur. Varnish laat je website pas echt vliegen, maar vereist toch wel kennis van de backend applicatie of website (niet echt geschikt voor shared hosting). MySQL wordt niet altijd goed geoptimaliseerd, dat is de reden dat we er voor gekozen hebben om nieuwe MySQL-clusters uit te rusten met FusioIO-kaarten. Absolute top performance voor databases (tienduizenden IOP/sec in een paar honderd GB). We hebben de afgelopen maanden al flinke stappen gezet op het gebied van hosting en gaan daar gestaag mee door. Ik zal jullie zo nu en dan op de hoogte houden en wat vertellen over wat we allemaal tegenkomen!



Ruben van der Zwan
is mede-eigenaar van Amsio en is sinds 2005 actief in de hostingindustrie. Hij is bij Amsio verantwoordelijk voor het technische gedeelte van het bedrijf en houdt zich vooral bezig met nieuwe concepten en oplossingen.

Dit artikel verscheen op 19 juni 2012 op de blog van Amsio en is met toestemming overgenomen op deze website.

Over Ruben van der Zwan

Laatste artikelen