Over Erik Jan Hofstede

Erik Jan is werkzaam op afdeling Systeembeheer. Hier is hij verantwoordelijk voor het beheer van alle systemen, van hard- tot software en networking binnen Antagonist.

Smart Index Creator: hoe wij stiekem je database sneller maken!

Regelmatig vertellen we je over onze ontwikkelingen via e-mail of blogartikelen, maar niet alles komt ter sprake. Ik denk dat dit vaak komt, doordat wij het vanzelfsprekend vinden ons volledig in te zetten voor een zo goed mogelijke klantbeleving. Het is onze tweede natuur, het zit in ons DNA. Vandaar dat het me een leuk idee lijkt om eens wat te vertellen over een tool die al jaren bij ons op de achtergrond draait, we weinig omkijken naar hebben, maar heel veel moois voor je website en database brengt: de ‘Smart Index Creator’!

Smart Index Creator: hoe wij stiekem je database sneller maken!

Oorsprong

Deze tool is ongeveer drie jaar geleden ontstaan, nadat er een aantal servers overbelast waren. Na enkele seconden naar de ‘top’ te kijken, zagen we al vrij snel wat het probleem was: MySQL liep nogal te stampen, er waren bijna 10 CPU-cores in gebruik!

Smart Index Creator: MySQL-belasting

Vervolgens zijn we binnen MySQL gaan kijken, om zo de query’s die hier verantwoordelijk voor waren op te sporen. Het bleken een handvol query’s te zijn, die ‘full tables scans’ aan het uitvoeren waren (straks meer over ‘full table scans’).

Tabellen van 800 MB waren geen uitzondering. Nu hoeft een grote tabel niet direct een prestatieprobleem op te leveren, maar wanneer het opvragen van data hieruit niet efficiënt gebeurt, dan kan het snel mis gaan. Zeker wanneer je gastenboek door vervelende bots op het internet met vunzige teksten is ‘volgespamd’.

Wij, als webhoster, zitten met dit soort situaties vaak in een spagaat. De klant is verantwoordelijk voor zijn applicatie, maar gebruikt in 99 van de 100 gevallen een standaard CMS. De klant heeft geen of weinig kennis van de interne werking van de software, wat ook volkomen logisch is. Ik heb ook een auto, maar ben geen automonteur.

Verder lezen

File system caching bij Antagonist!

Caching is de laatste tijd een populaire term en wordt vaak in de algemene zin gebruikt. Deze techniek kan echter op verschillende niveau’s plaatsvinden, zoals op applicatie- of file system-niveau. Wanneer er gesproken wordt over caching voor een website, dan vindt dit plaats op applicatie-niveau. Daar gaan we het nu niet over hebben. Aan caching binnen applicaties kun je namelijk al een volledig artikel wijden, wie weet iets voor later 😉 We duiken daarom nu een stukje dieper in het file system-niveau, en dan specifiek file system caching!

Filesystem caching bij Antagonist: hoe werkt het exact?

File system caching wordt gebruikt om het opvragen en wegschrijven van bestanden te versnellen door veel opgevraagde bestanden of ‘blocks’ (tijdelijk) op een ander, veel sneller medium te plaatsen. Bij Antagonist maken we gebruik van een cachingmechanisme dat anders is dan traditionele systemen. Het is niet alleen anders, want anders is per definitie niet beter. De caching die wij gebruiken, is vele malen sneller. Sneller is wel beter!

Een woord vooraf
Dit artikel is behoorlijke ‘technische hardcore’. Om ervoor te zorgen dat het zo goed mogelijk is te volgen, heb ik het zo gestructureerd mogelijk opgezet. Handig om te weten, is dat er een aantal termen zijn die ik willekeurig door elkaar gebruik, maar waarmee ik hetzelfde bedoel:

  • blocks, files en bestanden;
  • lezen, leestransacties en reads;
  • schrijven, schrijftransacties en writes;
  • disk, harddisk, schijf en harde schijf;
  • werkgeheugen en RAM.

Read en write caching

Het cachen van bestanden (file system caching) kan worden onderverdeeld in twee categorieën, namelijk: lezen (read caching) en schrijven (write caching).

Verder lezen

Nieuw: SSH voor onze klanten!

“Rozen zijn rood, Antagonist is blauw, vandaag op deze Valentijnsdag geven wij SSH aan jou ;-)”

Yes, daar is ‘ie: SSH-toegang naar je hostingaccount! Afgelopen maanden hebben we keihard aan deze nieuwe feature gewerkt. In dit artikel heb ik de eer om jullie mede te delen dat vanaf nu SSH-toegang beschikbaar is op Slim-, Plus-, en Pro-pakketten. Graag vertel ik jullie wat meer over: wat SSH betekent, wat we precies voor jullie hebben gemaakt en hoe je ermee aan de slag kunt. Over twee weken zal mijn collega Sander dieper ingaan op een aantal hippe tools die je kunt gaan gebruiken, dankzij SSH. Maar nu eerst een uitleg, let’s go!

Introductie SSH: OpenSSH logo

Wat is SSH?

De afkorting ‘SSH’ staat voor ‘Secure Shell’. Het is een vervanging voor ‘telnet’, wat gelukkig (en vooral hopelijk) al lang niet meer wordt gebruikt. Telnet is een niet-versleuteld protocol om opdrachten naar apparaten te sturen die zijn verbonden met een netwerk.

Het SSH-protocol maakt voor de authenticatie gebruik van zogeheten ‘public-key cryptography’. Het versleutelen van de verbinding gebeurt door middel van symmetrische cryptografie. De sleutel die hiervoor wordt gebruikt, is alleen bekend bij de server en de client en wordt gemaakt zodra de verbinding wordt opgezet. Op deze manier kan er veilig gecommuniceerd worden met een server over een onveilige verbinding.

Dankzij SSH kun je dus met een versleutelde manier inloggen op een andere computer (of server). Zo kun je op afstand commando’s uitvoeren via een shell. Omdat SSH met encryptie werkt, is het voor eventuele afluisteraars zo goed als onmogelijk om wachtwoorden of commando’s te achterhalen.

Waarom SSH?

Het concrete antwoord op deze kritische vraag: onze klanten vragen hier heel erg vaak om en wij houden van onze klanten. Er zijn een aantal dingen die onze klanten graag zouden willen, zodat ze hun website beter kunnen beheren. Een korte opsomming:

  • Git: de beste tool voor ontwikkelaars om code te beheren en delen;
  • Subversion/SVN: ook een (ietwat verourderde) manier om code te beheren;
  • SFTP: bestanden beheren over een SSH-verbinding. Niet te verwarren met FTPS, iets dat we al hadden. Zie SFTP als FTP maar dan veilig;
  • Softwarebeheer: eenvoudiger installaties doen van applicaties, bijvoorbeeld met een bijgeleverd installatiescript.

Verder lezen

Hoe wij ons platform en infrastructuur nauwkeurig monitoren

Het is weer hardcore tech-time! Dit keer neem ik je mee in de monitoring van onze systemen en ons platform. Doordat we alles nauwlettend in de gaten houden, weten we precies wat er wel en wat er niet goed gaat in ieder onderdeel van ons platform. We hebben onze monitoring zorgvuldig afgericht, waardoor we problemen vrijwel altijd van tevoren zien aankomen. We ondernemen dan proactief actie, zodat de impact van het probleem minimaal blijft en niet escaleert.

Monitoring bij Antagonist: de servers bij Antagonist

De kwaliteit van onze dienstverlening is immers zo goed als onze monitoring; hoe beter we anticiperen, hoe gebruiksvriendelijker het voor je wordt! Dat betekent dat er heel veel achter de schermen wordt gedaan zonder dat iemand het in de gaten heeft. Want wat er onder de ‘motorkap’ gebeurt is onze verantwoording, zodat jij met je website kunt doen wat je écht wilt. Toch is het af en toe interessant om even onder die motorkap te kijken naar wat voor successen er worden geboekt. Iets dat wijzelf ook weleens vergeten om bij stil te staan.

Onze setup voor monitoring

Voor onze monitoring maken we gebruik van Zabbix. Deze (opensource)software stelt ons in staat om ieder onderdeel van ons platform tot in detail te observeren. Als dingen niet zo gaan zoals het hoort, dan kunnen we eenvoudig hier acties op uit te voeren. Een simpel voorbeeld van één van deze acties is: het versturen van een bericht naar de dienstdoende systeembeheerder zijn.

Monitoring bij Antagonist: logo Zabbix

Iedere server wordt constant op 458 punten gecontroleerd. De uitkomst van deze checks wordt opgeslagen in een PostgreSQL-database, zodat we er later uptime- en performance-statistieken kunnen uithalen voor rapportage. Ook gebruiken we deze gegevens voor het generen van rapportages voor storingen. Samen – alle servers bij elkaar opgeteld – zorgt dat ervoor, dat onze Zabbix-installatie 897 punten per seconde controleert en opslaat. Hoe veilig wil je het hebben?

Dikke server

Zoals je begrijpt, hebben we een flinke server nodig om al die controles per seconde uit te voeren en hiervan de resultaten op te slaan. Daarnaast moet het ook nog eens gemakkelijk verwerkt kunnen worden. Voor de techneuten (of andere geïnteresseerden) zijn dit de specificaties van deze server: 2 x Intel E5-2640 2.5GHz CPU (totaal 24 threads), 64 GB RAM, 15k RPM disks in RAID10 configuratie.

Om je een beter inzicht te geven in hoe diep wij ons platform monitoren, ga ik ieder onderdeel hieronder afzonderlijk bespreken.

Verder lezen

Software-updates bij Antagonist

In dit artikel ga ik jullie weer een kijkje in de keuken van Systeembeheer geven. In een vorige artikel vertelde mijn collega Ewoud al over Open Source software, en daar is Antagonist een fanatiek gebruiker van. Software heeft echter liefde en aandacht nodig, en het gebeurt maar al te vaak dat, na het installeren er niet meer naar omgekeken wordt. Dit is één van de grootste oorzaken van vreemde bugs en ernstige security-problemen.

Software-updates bij Antagonist

Maar het kan ook anders, want dat bewijzen we bij Antagonist! Zodoende neem ik je in dit artikel graag mee in het reilen en zeilen van software-updates binnen Antagonist. Hoe kiezen we onze software, minimaliseren we de kans op bugs en zorgen we dat altijd de laatste stabiele versies hebben draaien? Op deze vragen zul je hieronder een antwoord vinden.

Routines zijn belangrijk

Een aantal maanden geleden hebben we een tweewekelijkse routine ingevoerd voor het up-to-date houden van de software die wij draaien om je website te serveren. We hebben dit gedaan om de kwaliteit van onze dienstverlening naar een nog hoger niveau te tillen. Deze routine heeft de naam ‘update-donderdag’ gekregen en valt zoals de naam al aangeeft op een donderdag, in elke week met een oneven nummer. Omdat we als organisatie steeds verder groeien, ontstond langzaam de vraag naar standaardisatie van werkzaamheden. Update-donderdag is hier een mooi voorbeeld van. We hebben hier een aantal waardevolle doelen mee bereikt.

  • Iedereen binnen ons bedrijf is op de hoogte welke updates (inclusief de specifieke versienummers) er gaan plaatsvinden.
  • Er is een vast moment wanneer updates worden uitgerold. Er zijn geen verrassingen voor medewerkers.
  • Doordat er een vast moment is, kunnen we problemen die, in het meest onfortuinlijke geval zouden ontstaan, snel in kaart brengen. Dit houdt tevens in dat problemen die buiten dit tijdsbestek ontstaan, waarschijnlijk niet gerelateerd zijn aan de updates.
  • We kunnen er in onze (tweewekelijkse) urenplanning rekening mee houden. We weten uit ervaring hoeveel tijd het kost om ons platform te updaten. Dit maakt realistisch plannen een heel stuk gemakkelijker!
  • We weten zeker dat we nooit meer dan twee weken achterlopen op de meest recente versie van software.
  • Mochten we een belangrijke (bijvoorbeeld security-) update over het hoofd hebben gezien, dan wordt deze alsnog met de routine meegenomen. Het is dus een extra vangnet.

Verder lezen

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

Verder lezen

Nieuw: het netwerk van Antagonist doet nu 10 Gigabit per seconde!

Achter de schermen zijn we bij Antagonist de laatste paar maanden bezig met grote technische verbeteringen. Eén hiervan is het upgraden van ons netwerk naar een volledig 10 Gigabit-omgeving. Deze upgrade is nodig vanwege toekomstige groei, zodat we aan zowel bestaande als nieuwe klanten een hoge performance kunnen bieden. Wij hebben een grens gesteld wanneer verbindingen voor zo’n 50% worden belast. Zodra je richting een belasting van 70% gaat, dan begin je latency te krijgen en dat zou afbreuk doen aan de hoge performance die we willen bieden.

10 Gigabit per seconde: het nieuwe netwerk van Antagonist!

Samen met ons nieuwe ‘Generation 4 Platform’ (waarover we je later meer gaan vertellen) hebben we besloten om alles op 10 Gbit/s aan te sluiten. Van server tot router, want we doen het goed of we doen het niet. Geen half werk dus! Als systeembeheerder gaat mijn hartje sneller kloppen van een dergelijk project. Omdat Antagonist transparantie hoog in het vaandel heeft en mijn enthousiasme groot is, ga ik jullie in dit artikel uitleggen hoe het proces van deze upgrade precies in z’n werk is gegaan.

Het probleem van klassiek ethernet

Een van de grootste nachtmerries van een netwerkbeheerder zijn ethernet-storms. Een ethernet-storm is een lus in het netwerk die zichzelf versterkt. Uiteindelijk zorgt een dergelijke storm ervoor dat alle verbindingen 100% belast zijn. Het gevolg: downtime! Wij, als Antagonisters, hebben een ‘downtime-allergie’. Iets dat onze klanten bewust of onbewust veelal met ons delen (hoewel dit niet wetenschappelijk is aangetoond). Een lus ontstaat meestal in enkele seconden en de enige manier om het te onderbreken is door verbindingen uit te schakelen.

10 Gigabit per seconde: wat is een broadcast storm?

Een ethernet-storm wordt veroorzaakt door ‘unknown-unicast’ en ‘broadcast packets’. Dit type pakketten wordt door de switch, die ze ontvangt, uit alle poorten verstuurd. Als je een netwerk in een ring hebt (voor redundantie), dan komt dit pakket terug bij de switch die hem eerder ook verzonden heeft. Deze switch doet vervolgens hetzelfde nog een keer, en nog een keer, en nog een keer, en nog een keer… Het gevolg: er ontstaat een niet te stoppen lus. Ethernet is hier enorm gevoelig voor, door het ontbreken van een TTL (Time To Live), iets dat IP wel heeft. Wij hebben, bij Antagonist, overigens nog nooit een ethernet-storm in ons netwerk gehad. Zoals je zult begrijpen doen we er ook alles aan om dat te voorkomen.

Verder lezen

Systeembeheer bij Antagonist, een kijkje in de keuken: configuratie-management

Systeembeheer: configuratie-management bij AntagonistTijd voor een kijkje in de keuken van de afdeling Systeembeheer bij Antagonist. Niks geen klikker-de-klik met de muis (sorry Windows sysadmins), het gaat hier over keiharde, diepgaande Linux-automatisering. In dit artikel zullen we een duik nemen in het configuratie-management van de servers waarop jouw websites en e-mail zijn opgeslagen. Tevens krijg je enigszins een inzicht in de werkwijze van de afdeling Systeembeheer bij Antagonist.

Waarom configuratie-management voor systeembeheer?

Als je vroeger (slechts enkele jaren geleden) een wijziging wilde doorvoeren aan de configuratie, op laten we zeggen 60 servers, dan moest je op elke server met SSH inloggen. Vervolgens voerde je de benodigde handelingen uit en controleerde je of alles goed was gegaan. Een intensieve klus, met veel ‘breindodend’ werk die helaas regelmatig voorkwam, niet echt de hobby van een systeembeheerder bij Antagonist.

Systeembeheer: de servers van Antagonist

Dit was echter niet het enige waar we tegenaan liepen. Om te streven naar een volmaaktheid in automatische processen waren er diverse obstakels, een opsomming hiervan, die snakten naar een goede oplossing, worden hieronder beschreven.

  • Als je bij één van de snelstgroeiende IT-bedrijven van de Benelux werkt, dan groeit je serverpark vanzelf ook snel. Elke server die erbij komt zorgt voor extra werk en kost dus extra tijd, want het aantal wijzigingen om door te voeren groeit bij elke extra server.
  • Namate we meer servers kregen en deze ‘ouder’ werden, begonnen zogenaamde configuration drifts te ontstaan. De configuratie, zoals hij zou moeten zijn, begon langzaam maar zeker per server af te wijken. Hierdoor ontstonden rare bugs en afwijkend onvoorspelbaar gedrag. Iets wat tijd kost om keer op keer opnieuw uit te zoeken, maar nog belangrijker: een klant van ons kon hier last van krijgen. Daarnaast houden nerds niet van onvoorspelbaar gedrag ;).
  • Wanneer we een wijziging doorvoerden, dan wist degene die dat deed natuurlijk prima wat er gedaan was, maar de rest van het bedrijf was niet op de hoogte en dit was na verloop van tijd ook lastig terug te vinden.
  • Waar mensen werken worden nou eenmaal fouten gemaakt, zelfs door Linux-ninja’s ;). Bij een handeling die je 100 keer moet uitvoeren is er immers een kans aanwezig dat er ergens een klein foutje insluipt en ervoor zorgt dat bijvoorbeeld de webserver niet meer werkt.
  • Wanneer een wijzing niet zoals gepland ging en een zogenaamde rollback nodig was, dan kwam er een hoop handmatig werk aan te pas, server voor server waren er handelingen vereist en dat kostte bijzonder veel tijd.

Met alle uitdagingen die hierboven beschreven staan, viel ons oog al snel op een nieuw, shiny en fancy stukje software genaamd Puppet!

Verder lezen