Container hosting: je eigen resources voor meer performance en veiligheid!

Zoals je wellicht eerder hebt gelezen, is Antagonist druk bezig met het de overgang naar een nieuw superplatform. Dit is niet één ding, maar bestaat uit meerdere facetten. Een nieuw netwerk, de nieuwste servers en andere nieuwe hardware, het gebruik van DNSSEC, de beste tools voor serverbeheer en nog veel meer. Al deze aspecten samen vormt de krachtbron voor snelle, stabiele en veilige webhosting. Zodat wij de beste gebruikservaring en hoogste performance voor jouw website kunnen bieden.

Container hosting: het nieuwe superplatform van Antagonist

Al eerder gaven we een tipje van de sluier over een nieuwe vorm van veilige webhosting die we met de introductie van ons nieuwe platform in gebruik hebben genomen. In dit artikel wil ik daarover graag wat meer vertellen. Mijn collega Sander had het in een zijn artikel over de evolutie van shared webhosting, tot het punt waar wij nu zijn aangekomen: containerisatie. Shared is niet meer shared, want iedereen krijgt z’n eigen container. Een server zo ingericht dat iedereen ‘bij elkaar woonde’ is niet meer. Nu krijgt iedereen z’n eigen ‘luxe appartement’. In hostingtermen heet dat containerisatie. Op een server krijgt elke gebruiker z’n eigen container en daarmee dus meer privacy, veiligheid en performance.

“The whole is greater than the sum of its parts”

Naast voordelen als veiligheid, eigen processen, unieke instellingen en zelf je PHP-versie kiezen, is er nog een ander héél groot voordeel. Elke container krijgt namelijk zijn eigen resources (CPU, IO en RAM) toegewezen. Op deze manier heeft het gebruik van één container geen invloed op andere gebruikers van de server. Een stuk stabieler en betrouwbaarder dus. In dit artikel ga ik je laten zien wat de verschillende onderdelen zijn, waarop resources ingedeeld worden. Wat de oorzaak en het gevolg ervan is, en hoe je inzicht krijgt in je gebruik.

Ik ga het woord ‘container’ vaak noemen. Maar wat is dat nou precies? Met een container bedoel ik alles wat er op een hostingaccount draait: websites, e-mail, FTP, cronjobs, etc.

Hoe zie ik mijn gebruik en waar moet ik op letten?

Voordat we diep de techniek in duiken, ga ik eerst kort uitleggen waar je het huidige en historische gebruik van je container kunt vinden. Tevens geef ik aan wat de belangrijke punten zijn waarop je moet letten. Om bij deze statistieken te komen log je in op DirectAdmin en klik je op ‘Resource usage’.

Container hosting: resource usage in DirectAdmin

Je krijgt gelijk een beknopte melding te zien, die aangeeft of je wel of geen performance problemen hebt gehad. Klik op ‘Details’.

Container hosting: CloudLinux details

Je krijgt nu het overzicht van de afgelopen 24 uur te zien. Dit kun je wijzigen als je dat wilt.

Container hosting: resource usage details

De container die je hier ziet, heeft geen problemen. Dit kan ik opmaken uit het volgende.

  1. Er zijn geen ‘Faults’ geweest.
  2. Er zijn bijna geen ‘Processes’ in gebruik.
  3. Er zijn ruim voldoende ‘Entry Processes’ beschikbaar

Een voorbeeld van een container die wél problemen geeft, laat ik hieronder zien. De problemen die hier komen omdat er teveel CPU wordt gebruikt.

Container hosting: resource usage details not good

De website in deze container heeft rond 17:06 uur problemen vertoont. Dit komt waarschijnlijk door het 100% gebruiken van de beschikbare I/O.  Hierdoor stapelen processen op en ga je vervolgens meer geheugen (pMEM) gebruiken. Vervolgens zijn alle processen in de webserver in gebruik en krijg je Entry Processes (EP) fouten.

Een niet juist werkende container herken je aan een van de volgende punten.

  • Er worden ‘Faults’ (fouten) gegenereerd. Dit is bijna altijd het gevolg van:
    • 100% CPU-gebruik;
    • 100% I/O-gebruik (Input / Output);
    • 100% pMEM-gebruik (geheugen).

Hieronder ga ik je uitleggen wat het nut is van alle losse onderdelen en hoe ze samenwerken. Op deze manier hoop ik, dat je meer inzicht krijgt in de oorzaak van een probleem en de gevolgen ervan.

Container hosting, de onderdelen afzonderlijk

Voordat we gaan kijken, hoe limieten worden opgelegd aan containers (accounts of websites), is het goed om te weten welk onderdeel waarvoor verantwoordelijk is. Alle onderdelen zijn in principe op te delen in twee categorieën. Deze zal ik eerst uitleggen.

#1 Verwerkingssnelheid

Dit is een limiet op hoe snel een aanvraag verwerkt wordt. Je kunt nooit over deze limiet heen gaan. Als je op het maximum zit, dan worden aanvragen simpelweg trager verwerkt. Dit maximum deel je dus met alle processen of aanvragen in je container. Dit is bijvoorbeeld het aantal GHz van de CPU of de bandbreedte naar de disks in MB per seconde.

#2 Aantallen

Dit is een limiet op hoeveel je ergens van mag gebruiken. Ga je hier overheen, dan levert dit een fout op. Als je dit soort fouten krijgt, dan betekent dit (bijna) altijd dat processen opstapelen, omdat ze niet snel genoeg verwerkt worden. Dit komt vaak door het gebruik van een ‘slechte of trage’ code. Denk hierbij aan een brakke plug-in voor WordPress. Een voorbeeld van een limiet is de hoeveelheid geheugen die je kunt gebruiken of het maximum aantal gelijktijdige processen.

Limieten container hosting

Nu je de hoofdcategorieën weet, kan ik de afzonderlijke onderdelen verder uitleggen en opdelen in één van deze twee. Voor het gemak heb ik per stuk een korte uitleg gegeven over wat het is en wat het doet.

CPU-limiet

De CPU is het werkpaard van een server. Alles wat een server doet, wordt berekend in deze processor. De afkorting CPU staat dan ook voor Central Processing Unit. De snelheid van een processor wordt uitgedrukt in GHz (gigahertz). Als gebruiker van een server krijgt je container een deel van deze GHz toegewezen. Dit kan bijvoorbeeld 2 GHz van de totale beschikbare 20 GHz zijn.

De CPU-limiet valt in de categorie ‘verwerkingssnelheid’. Wanneer je het maximum CPU gebruikt worden aanvragen/processen trager verwerkt, dit komt omdat het gelijk verdeelt wordt. De kans is groot dat hierdoor het aantal gelijktijdige processen opstapelt en de nProc teller oploopt (hier lees je straks meer over).

vMEM- en pMEM-limiet

Deze twee termen worden gebruikt om de hoeveelheid beschikbaar geheugen voor je container aan te geven. Dit drukken we uit in MB (megabytes). Er zit een klein, maar belangrijk verschil tussen vMEM en pMEM.

  • vMEM is het virtuele geheugen, dit is het fysieke en swap-geheugen bij elkaar opgeteld.
  • pMEM is het fysieke geheugen, RAM dus. RAM is retesnel, swap niet.

Wij limiteren alleen op pMEM, dus RAM. Dit vinden we eerlijker. Geheugen dat uit swap komt, is duizenden malen trager en dat wil je dus liever niet gebruiken. We vinden het het onze verantwoordelijkheid, en dus niet die van onze klanten, om het zo in te stellen dat swap niet wordt gebruikt.

De hoeveelheid pMEM dat je container gebruikt, wordt gerekend in MB’s (megabytes) en dit heeft een harde limiet. Wanneer je hier overheen gaat, krijgen je bezoekers een 503- of een 500-foutmelding te zien, iets wat je wilt voorkomen dus.

Entry processes (EP)

De webserver, bij ons Apache, is verantwoordelijk voor het serveren van de website aan je bezoeker. Webservers hebben een maximum aantal verbindingen (ook wel slots genoemd), die ze tegelijkertijd kunnen afhandelen. Om te voorkomen dat één website alle beschikbare verbindingen in gebruik neemt, en andere websites hierdoor in de verdrukking komen, zit hier een maximum op. Er wordt bij iedere aanvraag van een website gekeken, hoeveel verbindingen de site op dat moment open heeft. Is het maximum bereikt? Dan krijgen bezoekers een 508-foutmelding te zien.

nProc

Hier wordt gemeten hoeveel processen je tegelijk draait. Hoewel de term erg op Entry Processes lijkt, werkt het anders. Hier vallen alle processen van je container onder, behalve de verbindingen die in Apache (de webserver) openstaan.

Deze limiet is aanwezig om te voorkomen dat niet één container bergen processen tegelijk heeft lopen en hiermee problemen op de server veroorzaakt. Wanneer je over het maximum aantal processen gaat, dan kun je geen nieuwen meer starten. Je website zal dan ook 503- of 500-fouten geven.

Het opstapelen van processen kan bijvoorbeeld de volgende oorzaken hebben.

  • Je website is te traag voor het aantal bezoekers dat het moet verwerken.
  • Er zijn cronjobs die niet snel genoeg klaar zijn, waardoor deze opstapelen.

I/O

I/O is de afkorting voor Input / Output. De I/O waar we het hierover hebben, is de bandbreedte van en naar de disk. Dit wordt gemeten in MB/s (megabytes per seconde) en als het maximum bereikt is, dan worden alle processen die I/O nodig hebben vertraagd. Als je dus de alle bandbreedte gebruikt, dan worden processen trager. Net als bij het maximum gebruik van de CPU, is de kans groot dat het aantal gelijktijdige processen opstapelt en de nProc-teller oploopt. Deze limiet is aanwezig om te voorkomen dat één proces alle beschikbare bandbreedte van de server verbruikt, door bijvoorbeeld foute configuratie, scripts of misbruik.

Fouttellers

Wanneer er een fout gegenereerd wordt, bijvoorbeeld omdat je te veel processen tegelijk draait, dan wordt de fout geteld. Elk onderdeel heeft zijn eigen foutteller. De ‘f’ staat voor ‘fault’, om het wat makkelijker te kunnen onthouden.

  • pMEM: PMemF
  • nProc: NprocF
  • EP: EPf

Deze gegenereerde fouten hebben bijna altijd een onderliggende oorzaak. Hoe je deze oorzaak kunt ‘pinpointen’ lees je hieronder.

Alle onderdelen samen

Hieronder heb ik schematisch getekend hoe alle verschillende onderdelen samenwerken en wat de volgorde van verwerken is, wanneer er een bezoeker op je website komt. Ik heb verschillende kleuren gebruikt voor de twee verschillende categorieën.

  • Blauw: onderdelen die een maximale verwerkingssnelheid hebben, zoals GHz en MB/s.
  • Groen: onderdelen die een maximum in aantallen hebben, zoals Megabytes of aantal processen.

Container hosting: wat doet CloudLinux

Wat doet ons platform, stap 1

De webserver krijgt de aanvraag om een bepaalde pagina of andere content naar de gebruiker te sturen. Bij het binnenkomen van de aanvraag wordt er gekeken hoeveel Entry Processes er in gebruik zijn. Is dit minder dan het maximum, dan wordt de aanvraag direct verder verwerkt. Zijn er geen Entry Processes beschikbaar voor de container? Dan krijgt de gebruiker een 508-fout te zien en wordt deze bij het aantal EPf’s geteld.

Wat doet ons platform, stap 2

Bij deze stap wordt er gekeken hoeveel processen er al voor deze container draaien. Een paar voorbeelden hiervan zijn:

  • PHP-processen;
  • Lopende cronjobs;
  • FTP-processen;
  • E-mail-processen.

Is er ruimte voor nieuwe processen? Dan wordt de aanvraag verder verwerkt. Wanneer dit niet het geval is dan krijgt de gebruiker een 503-melding te zien en wordt de NprocF-teller verhoogd.

Wat doet ons platform, stap 3

Tijdens deze stap wordt de aanvraag van de gebruiker verwerkt. Er wordt een proces gestart voor bijvoorbeeld het opbouwen van een PHP-pagina en het uitvoeren van de bijhorende SQL-query’s of het uitvoeren van een cronjob. Tijdens deze fase wordt het geheugengebruik van de container gemonitord. Als een proces meer nodig heeft dan het maximaal mag gebruiken, dan resulteert dit in een 500- of 503-fout voor de gebruiker en wordt de PMemF-teller verhoogd.

Een voorbeeld van de veel I/O

Hier zie je het gebruik van een container die in een korte tijd erg veel I/O is gaan doen, hierdoor werden limieten kort overschreden.

Container hosting: resource usage chart

Uitleg van de oorzaak en het gevolg.

Container hosting: CloudLinux en teveel I/O-verbruik

Tips voor een nog betere performance

  1. Controleer regelmatig je gebruik. Kijk niet alleen naar de afgelopen 24 uur, maar ook naar de afgelopen week en de afgelopen 30 dagen. Op deze manier zie je problemen aankomen, voordat er fouten gegenereerd worden.
  2. Controleer je CPU-gebruik.
    1. Een website met 100 bezoekers per dag hoort niet 50% of meer CPU te doen, waarschijnlijk is er iets mis met je site.
    2. Plotselinge pieken kunnen verantwoordelijk zijn voor kort veel MEM-gebruik, omdat processen langer draaien en dus opstapelen.
  3. Controleer je MEM-gebruik.
    1. Plotselinge pieken kunnen het gevolg zijn van te veel I/O- of CPU-gebruik.
    2. Een ‘normale’ website zal slecht 128 of 256 MB aan MEM nodig hebben.
  4. Controleer je I/O.
    1. Dit is minstens zo belangrijk als CPU.
    2. Het bereiken van deze limiet geeft aan dat er iets niet goed is met je website. Dit resulteert waarschijnlijk in een opeenstapeling van het aantal processen en het geheugengebruik.
    3. De meeste websites hebben ruim voldoende aan 1 MB/s.

Wij zijn er klaar voor!

Dankzij het gebruik van containers en de afgeschermde resources, zijn we in staat een optimale dienstverlening te leveren. Vroeger kwam het wel eens voor dat één gebruiker of website overlast veroorzaakte bij andere gebruikers. Dit is voor ons verleden tijd. Containerisatie draagt enorm bij een de stabiliteit en betrouwbaarheid van ons platform. Tevens aan privacy, wat ook niet geheel onbelangrijk is.

Daarnaast is snelheid een aspect dat steeds belangrijker wordt. Je wilt immers de laatste software, plug-ins en thema’s vloeiend kunnen blijven gebruiken. In de toekomst zal deze vraag alleen maar groter worden. Zodoende richten wij ons platform alvast in op het bieden van een hoge performance. Het doel? Jouw website succesvol online en je daarbij zó helpen dat je er blij van wordt.

Nu je wat meer weet over onze webhosting en je een kijkje in de keuken hebt gekregen van onze systeembeheerelite, ben je wellicht nieuwsgierig naar onze pakketten?

Klik hier voor meer informatie

P.S. Wil je op de hoogte blijven van alle artikelen, updates, tips en trucs die verschijnen op ons blog? Dat kan! Rechts bovenin via RSS, e-mail, het liken op Facebook, het +1’en op Google+ of het volgen op Twitter.