Tweakers' serverpark anno 2013

We proberen onze servers vlot te vervangen. Dat betekent niet dat ze altijd precies drie jaar na aanschaf worden ingeruild, maar dat is wel waar we ons op richten. Een enkele keer komt het beter uit om een server wat eerder te vervangen, zodat we bijvoorbeeld een nieuwe aanpak voor een bepaalde service kunnen uitwerken.

Ook dit jaar gaan we weer flink wat vervangen. Het belangrijkste is de centrale storage. Het liefst zouden we een omgeving opzetten met multi-master-replicatie, zodat er naar een willekeurige fileserver in een van de beide locaties geschreven kan worden en de clients transparant omgezet kunnen worden bij problemen.

In de praktijk blijkt dat dit soort systemen erg zeldzaam is. Zelfs ruim boven ons budget is het nog niet gebruikelijk dat fileservers elkaar via een tcp/ip-netwerk actueel kunnen houden. Het is meestal één kant op, in een variant op een master-slave-opstelling. Omdat het systeem voor ons niet alleen storage moet bieden, maar ook beheersbaar en flexibel moet zijn, gaan we hier waarschijnlijk weer simpelweg aan de slag met ZFS. Op welk besturingssysteem of welke appliance dat dan komt, weten we nog niet. Het liefst wordt dat natuurlijk Linux, maar helaas is ZFS op Linux geen officieel ondersteund bestandssysteem. Dat maakt de combinatie daardoor automatisch een minder goed recept voor stabiliteit en continuïteit.

Naast de storage staan er nog diverse servers op de agenda om vervangen te worden. Daaronder bevinden zich de 'slave' MySQL-server, de VM-hosts en de videowebservers. Aangezien die in hun huidige vorm vrij goed werken, zullen dat domweg varianten op dezelfde soort server zijn. Alleen dan uiteraard drie jaar nieuwer.

Op het gebied van software willen we ook nog verder met nieuwe versies en zullen we diverse aspecten tunen. Zo wordt het https-verkeer nu direct naar Apache verzonden. Dat is zonde, want daardoor wordt Varnish overgeslagen. Aangezien onze loadbalancers ook zelf https kunnen 'terminaten', gaan we onderzoeken hoe we dat het efficiëntst kunnen inzetten. Helaas is dat typisch een wijziging die simpel lijkt, maar in de praktijk allerlei haken en ogen met zich meebrengt. Op het moment van schrijven wordt dit daarom alleen nog voor tweakimg.net gedaan.

Zoals eerder gemeld willen we onderzoeken waarom MongoDB relatief slecht met de hoeveelheid queries en updates overweg kan. Wellicht is een nieuwere versie beter of stappen we over op een van de alternatieven. Vooral Redis lijkt een goede kandidaat. Verder moeten we nog hard aan de slag om al onze oude code na te pluizen op compatibiliteit met PHP 5.4 en 5.5.