Cloud systemen moeten een gegarandeerde uptime leveren terwijl ze constant onder vuur liggen

Een publicatie van: dhr ing Robin Louwerse

In mijn cariere van 30 jaar in ICT systemen heb ik al wel eens wat voorbij zien komen. In 1995 kwam Internet in een stroomversnelling. Websites werden knapper, en systemen moesten meer kunnen leveren. Mijn eerste ervaring met een datacenter systeem was toen wij in 1997 een co-located server in de cloud hingen bij NS. Meteen was het raak, de hele dag ging het maar door met brute-force aanvallen op delen van de infrastructuur. Waarom? Niemand die het weet, want er was zeker toen nog niets te halen. Blijkbaar was er een UPC rack element dat stond te propageren dat het systeem in het netwerk zat. Een joch van 14 kon toen al de handleiding van dat systeem ergens online vinden, en het systeem was nog niet zo sterk beveiligd als de huidige systemen.

We hebben na drie dagen de boel weer opgehaald. Wat een ellende. Maar cloud is wel gebleven en we zijn ook daar verder in gegroeid.

Tegenwoordig hebben we cloud systemen in datacentra als AWS, Azure of Google. Ook de Internet gerelateerde datacentra zijn steeds beter geworden. Ook TransIP bijvoorbeeld heeft al mogelijkheden voor infrastructurele voorzieningen.

Een serversysteem kennen we wel. Dat was meestal zo'n lawaai machine die ergens in de meterkast stond. Dat is in de loop van de jaren, met oog op meer systemen per vierkante meter gegroeid naar "rackmount" systemen. Rackmount systemen gaan uit van een standaard hoogtemaat van "u". Een simpele server was beschikbaar vanaf 1u. Dat is 1 strookje server in een serverkast waar soms wel 32u in ging. Het maximale aantal is dan 32 systemen in 1 serverkast. Dat is een hoop processorkracht per vierkante meter. Vaak moest in diezelfde kast ook andere netwerkapparatuur. Denk aan een noodstroom voorziening in de vorm van een UPS, een netwerk schakelapparaat als switch en een legbord die transformeerde tot een beeldscherm met toetsenbord en muis.

Een kleine aanvulling op de continu diensten was de hot-swap harddsk. Geniaal bedacht. De server diende niet meer opnieuw opgestart te worden om een nieuwe hardisk aan te brengen. En met nuttige oplossingen als striping (RAID configuraties) was het mogelijk om data te regenereren als er onverhoopt een disk kapot was gegaan.

Waar de systeembeheerder nog wel even aan diende te denken is dat verschillende schijven verschillende performance hebben, en dat schijven uit dezelfde batch na verloop van de levensduur rond dezelfde tijd stuk gaan. Maar interne monitoring van de harddisk geeft via een lampje aan dat de schijf "foutjes" gaat maken en dat het tijd is voor vervanging.

Maar vierkante meters in een datacentrum zijn duur. Dus moesten er betere oplossingen komen om de serverkracht te verhogen en de continuiteit te borgen. Een mooie oplossing voor voor een aantal online wereldese uitdagingen was dan ook het "Blade" systeem. Een blade systeem is een infrastructurele oplossing om meerdere blades aan te verbinden. Je kon simpelweg een computer blade toevoegen, een disk blade en ga maar door aan mogelijkheden. Uiteraard zetten we dan alle processorkracht in een rack voor processoren, de memory bij elkaar en dan dus aparte racks voor storage en switching.

Voor volcontinu diensten konden we naast schijven mirroren, schrijven in RAID configuraties, ook systemen mirroren. Een complete server kon dan gesynchroniseerd worden met een andere server om zo de data te borgen.

Daarnaast is het omgaan met deze hele knappe machines veranderd. Hardware is knapper en knapper en kan veel meer dan mensen kunnen vragen. Tijd dus om een computer systeem in stukjes te knippen met virtualisatie. Een virtueel systeem is een "computer" op een stukje van de hardware. We noemen dat een instance. Een instance kan dus zelf een compleet operating system hebben, met eigen software en toepassing. En al deze high tech oplossingen van rackmount, redundancy en virtualisaties komen samen in wat we nou cloud noemen.

Dat lijkt dan voorbij voor de hardware, we krijgen steeds meer op steeds minder meters. Dan hebben we alles gedaan toch? Maar nee. Het gaat hier om volcontinu diensten. Het kan natuurlijk zijn dat er zich een grotere calamiteit voordoet. Een calamiteit waarbij een datacentre getroffen wordt door een ramp. Dan is het natuurlijk fijn om de data ook via mirrored systemen in andere datacentra te clonen. Zo zijn er dus ook voorzieningen om data te mirroren naar andere datacenta, wereldwijd!

Dan terug naar het systeem zelf. Want hoe zorg je ervoor dat een zwaarbelast systeem "up" blijft. De simpelste vorm was altijd om een systeem te overdimensioneren. Maar dat is tegelijk een beetje dom. Want via die virtualisaties kunnen we een zo klein mogelijke instance maken waar het systeem op draait. De onbelaste load moet natuurlijk rond de 5 tot 10% blijven, maar we gaan een instance opschalen op het moment dat instance 1 boven de 50% belasting komt. Die tweede instance moet dan via een load balancer verbonden worden zodat het geheel 1 systeem lijkt voor de buitenwereld.

AWS noemt dat autoscaling groups. Een load-balancer met daaronder kleine instances, die opschalen als de vraag toeneemt. Voor een grote drukkerij heb ik autoscaling groups toegepast. De kosten voor maandelijkse hosting zijn daarmee gehalveerd!

Heeft u vragen over data diensten, hosting of datacentra? Ik kom graag met u in contact.