1 Miljoen websites achter een DirectAdmin server, zou dit lukken? Wij spelen al enige tijd met de vraag of het mogelijk is een platform te bouwen dat webhosting doet op basis van DirectAdmin, maar wel volledig werkt op het Cloud principe. Niet “Cloud” als sales term, maar volgens het "pets vs cattle" principe. Eenvoudig en moeiteloos instances kunnen bijplaatsen waar nodig zodat het oneindig schaalbaar kan zijn en daardoor HA verkrijgen op de software laag.
Met dit in het achterhoofd zijn wij gestart met het bedenken van een proefopstelling. Hoewel DirectAdmin niet ontworpen is voor deze toepassingen, bleek het al snel dat de meeste zaken wel realiseerbaar waren. DirectAdmin heeft namelijk de mogelijkheid om voor alle acties in het panel bepaalde pre en post scripts aan te roepen.
DNS is op zich een van de eenvoudigste onderdelen om schaalbaar te maken. Via een post script ontvangen wij alle updates die er gebeuren aan de DNS instellingen en is het enkel nog een punt van replicatie. Hier werd enkele malen rsync aangeraden wat op zich een mogelijkheid is. Nu leek ons de overhead hiervan iets te groot en lijkt het ons beter om gebruik te maken van een queue (RabbitMQ) om alle slaves een update te bezorgen van de zones.
Web engine zelf is al iets complexer. Echter zit in de huidige versie van CustomBuild van DirectAdmin de optie om Apache in combinatie van Nginx te gebruiken. Dit maakt alles ineens al een stuk schaalbaarder, echter moeten de configs overal gelijk zijn en de configs de Ips van alle web instances bevatten. Daarnaast moet de webdata overal beschikbaar zijn en liefst ook consistent. De configs kunnen eventueel via rsync opgezet worden of via distributed storage als GlusterFS. De voordelen van rsync is dat wanneer 1 host offline gaat, de configs gewoon beschikbaar zijn op de andere. Met als nadeel dat er gemakkelijk race conditions kunnen ontstaan waarbij configs niet op alle plaatsen dezelfde zijn. GlusterFS daarentegen werkt met locking waardoor dit niet het geval is. GlusterFS lijkt hier daardoor de beste optie. Andere opties zijn GFS2 (zelfde voor en nadelen als GlusterFS) en een NFS storage wat weer een SPOF kan zijn voor de cluster.
Voor de clustering van een website zien wij 3 belangrijke punten.
1) De diskruimte van de website zelf. Bij GlusterFS en GFS2 is er de bedenking of de performantie voldoende is. Daarnaast is het niet mogelijk om met quotas te werken bij GlusterFS en dit lijkt ook het geval te zijn bij NFS storage.
2) Session storage: Sessies zijn kleine bestanden die meestal in de tijdelijke storage (/tmp) van een server staan. Dit is wellicht iets dat iedereen weet, echter iets wat vaak niet voldoende bij stil word gestaan. Een reactie als: “we gooien die op de shared storage en dan zijn die sessies overal beschikbaar” lukt voor een klein platform met weinig bezoekers. Echter is zoiets dodelijk voor de performance van bijvoorbeeld een GlusterFS. Deze zijn namelijk nogal gevoelig aan veel kleine files. Alternatieven hier zijn memcached of mijn favoriet, een redis cluster. Probleem hier is dat ik hier enkele bedenkingen heb naar security toe. Deze sessies mogen natuurlijk niet toegankelijk zijn voor andere klanten.
3) MySQL is via Galera eenvoudig HA op te zetten. Echter heeft deze opstelling veel impact op de performantie en kan dit wel de onverwachte showstopper zijn voor zeer groot platform als men spreekt over miljoenen websites.
Mail, HA Directadmin en FTP is momenteel nog out of scope omdat dit geen rechtstreekse impact heeft naar de klanten toe op vlak van bereikbaarheid van hun website. Mail lijkt op zich eenvoudig schaalbaar, al is hier de storage weer de moeilijkste factor.
Vragen en bedenkingen zijn zeer welkom!