Schaalbaarheid & high-availability websites

De basis

Het is heel makkelijk om maar aan één woord te denken: opschalen. Is “iets” traag; zet er meer resources tegenaan. Het lastigste is om na te denken over de concrete bottlenecks en inherent de correcte oplossing hiervoor. Opschalen is iets wat altijd wel mogelijk is maar niet per definitie het meeste rendement geeft. Vaak is dit maar een tijdelijke oplossing. Eenmaal begonnen aan het constant opschalen, kan er voor zorgen dat je op een gegeven moment het plafond bereikt en vervolgens geen kant meer op kan. Uiteraard zijn er dan nog wel opties, maar die zullen niet meer soepel te implementeren zijn.

Scaling-up

Scaling-up oftewel opschalen, is iets wat relatief vaak gebeurt. De reden is vrij simpel: het is gemakkelijk. Er zijn voldoende argumenten te bedenken waarom opschalen een logische stap is.

Een website die een gestage groei ervaart heeft er soms behoefte aan om eens in een bepaalde periode in capaciteit te groeien om zo te voldoen aan de “nieuwe eisen” van de huidige situatie. In dit geval upgraden wij de dedicated server van 2 cpu’s naar bijvoorbeeld 3 of 4 cpu’s. Dat biedt weer voldoende flexibiliteit voor een geruime periode.

Het belangrijkste is dat er een analyse is geweest over waarom een upgrade/wijziging nodig is. Indien het een extreme groei is die zich ook zal doorzetten is een opschaling van de capaciteit geen structurele oplossing. Indien er nieuwe functionaliteiten zijn geïmplementeerd in de website kan het voorkomen dat dit relatief zware processen zijn waardoor er een logische verklaring is dat er meer resources nodig zijn.

Wij monitoren standaard al onze websites en servers en houden hier ook het CPU, memory en disk -gebruik in de gaten. Zodoende kunnen wij proactief reageren om bottlenecks in de groei te voorkomen. Daarbij komt het voordeel van “de cloud” aan bod. Het is relatief makkelijk om zonder vergaande migratiestappen een bestaande web-server een upgrade te geven. Afhankelijk van de drukte op de “node” (fysieke server stack) is een upgrade te realiseren in 1 á 15 minuten.

‍

Scaling-out

Wanneer je horizontaal gaat opschalen pak je niet de directe server aan om deze te vergroten maar pak je het dus breder aan. In dit geval voeg je een extra server toe om bepaalde processen over te nemen. Echter kan de server ook “meewerken” met andere servers om processen te verwerken.

Het hoofddoel is om te zorgen dat de huidige server weer ontlast wordt van alle processen. Zodoende kan er een identieke web-server opgezet worden. Middels een load balancer wordt het verkeer verdeeld over de nu 2 aanwezige servers. Dit stuk is vrijwel oneindig te herhalen indien hier behoefte aan is. Een andere optie is om diverse processen van elkaar te gaan scheiden. Normaliter staat de database inclusief webserver op een dedicated server. Bij veel database requests kan het voordelig worden om de database te scheiden van de web-server. Een database heeft veel behoefte aan geheugen terwijl een webserver (apache en php) bijvoorbeeld meer behoefte aan de CPU hebben. Uiteindelijk kan het voorkomen dat diverse processen elkaar in de weg zitten. Bij een dedicated setup kan de volledige server beter benut worden omdat geen rekening met andere processen gehouden hoeft te worden.

Failover & redundantie

Een bijkomend voordeel van een goede basisstructuur middels het horizontaal schalen is de mogelijkheid tot failovers en een stukje redundantie. Afhankelijk van de totale setup is het goed mogelijk dat één of meerdere servers “mogen” uitvallen, zonder dat dit invloed heeft op de bereikbaarheid van de website of applicatie. Het verkeer zal worden herleid naar de servers die nog wel bereikbaar zijn.

In de basis gaat dit dan om de web-servers aangezien dit een relatieve standaard opzet is in het horizontaal schalen. Zodoende draaien er bijvoorbeeld drie web-servers waarbij er essentie twee mogen uitvallen om nog steeds online te zijn. Dit is verder uitbreidbaar door een zogeheten “master-slave” setup voor de database.

De master database wordt standaard gebruikt, maar hij zal de data met een kleine vertraging ook verspreiden naar een andere database (of meerdere). In het geval van uitval van de master database zal de “slave” de nieuwe master worden.

Met name bij databases kan een potentiële downtime lang zijn als er sprake is van corrupte data of een crash. Het restoren van een database is geen probleem omdat wij middels het gebruik van een zogeheten objectstore backups kunnen terughalen met diverse retenties. De downtime zit hem dan voornamelijk in de tijd die benodigd is om de database te restoren, iets wat soms enkele uren kan duren bij grote datasets.

Middels een master-slave setup kan de downtime tot een minimum gebracht worden en biedt daarbij ruimte om de ‘failed’ database te herstellen zonder dat je hier iets van merkt.