Normaal gesproken komt er op dit soort artikelen veel feedback. Jullie overladen ons met vragen, tips en eigen ervaringen. Die feedback is voor zowel ons als de medetweakers interessant en we steken er ook nog wat van op. De feedback dwingt ons om na te denken over onze huidige oplossingen, geeft inzichten in hoe we die beter kunnen inzetten en opent onze ogen voor alternatieven.
Helaas kunnen we er in de praktijk niet altijd wat mee. De besproken hardware en software zijn over het algemeen al daadwerkelijk in gebruik. 'Even' iets anders kopen of installeren is op zijn minst onpraktisch en soms te kostbaar. Dat is natuurlijk extra jammer als blijkt dat jullie alternatieve oplossingen noemen die beter en/of goedkoper zijn. Dat soort tips krijgen we liever vóórdat we een keuze maken
We gaan binnenkort ook hardware en software vervangen. Voor die zaken komt de feedback dan natuurlijk juist nu op het goede moment. Daarom geven we jullie een vooruitblik op wat we in 2016 van plan zijn.
Loadbalancers
Het eerste project wordt het plaatsen van nieuwe loadbalancers. Op dit moment gebruiken we daarvoor drie adc's in een active-passive paar op de primaire locatie en een enkele op de uitwijklocatie.
Van boven naar beneden: 10Gbit-switch, firewall en loadbalancer
Er komt veel kijken bij de selectie van loadbalancers, omdat er allerlei functies bestaan die interessant kunnen zijn. We beschrijven hieronder de zaken waar we naar kijken, om zo ook een kijkje in de keuken te geven. Het is overigens een lastig proces door de vele variabelen
Mogelijke varianten
De eerste keuze zit in het type platform. Er kan ruwweg gekozen worden tussen een hardware-appliance, een virtuele appliance en losse, zelf gekozen software.
- Hardware-adc's
- Virtuele adc's
- Losse software
Als nadeel is er onder andere de prijs. In verhouding tot wat je uitgeeft, zijn de hardwarecomponenten meestal niet erg snel en zelfs redundante voedingen zijn niet standaard. Een ander nadeel is dat ondersteuning op een gegeven moment zal worden stilgelegd. Als je dan toch nieuwe functionaliteit of ondersteuning wil, zal er een nieuwe investering moeten volgen. Ook als de soft- of hardware in principe nog voldoet.
De nadelen omvatten onder andere de prijs. De prijs van virtuele adc's is meestal gerelateerd aan de benodigde bandbreedte en komt soms dicht in de buurt van die van de hardwareversies. Verder introduceer je met virtuele machines extra (kans op) latency in een toepassing waarin je dat niet wil.
Nadelen zijn er ook; We moeten zelf alles met elkaar combineren en verbinden. Het is lastiger te achterhalen waar het fout gaat. Ook zullen de eventuele gui's minder compleet en/of informatief zijn.
We hebben nog geen keuze gemaakt uit de drie opties en horen graag jullie mening hierover. We hebben uiteraard nog wel wat eisen en wensen daarbij, waar we ook rekening mee moeten houden.
- Eisen en wensen
- Must have
- Should have
- Nice to have
Als je die lijstjes interessant vindt, kun je ze in de tabjes hiernaast bekijken.
- Als een webserver uitvalt of weer terugkomt, moet dat automatisch herkend worden en op de achtergrond gebeuren. Ook voor andere (eenvoudige) configuratiewijzigingen mag er geen noemenswaardige downtime zijn.
- Multipool/last resort
- Zoals je kunt lezen bij de webservers hebben we op dit moment twee pools van servers. Als geen enkele server van de eerste pool nog reageert, wordt de tweede ingezet. En als ook dat niet meer lukt, word je door onze loadbalancers geredirect naar error.tweakers.net. Dan krijg je in ieder geval een bevestiging dat het aan ons ligt in plaats van aan jouw verbinding
- Automatische fail-over/fail-back
- In onze hoofdlocatie willen we (minimaal) twee adc's plaatsen. Deze hoeven niet per se in active-active-modus te draaien, maar moeten wel automatisch elkaars werk kunnen ovenemen.
- 10Gbit-aansluitingen
- We hebben een redundante 10Gbit-verbinding en 10Gbit-switches, dus het is wel zo handig als we de adc's daar direct op aan kunnen sluiten. In de praktijk komt het gros van het verkeer via de videostreaming, waardoor de adc's niet per se ook die 10Gbit hoeven te kunnen verwerken.
- Global server load balancing
- Hiermee zorgen we ervoor dat jullie automatisch naar de uitwijklocatie worden gestuurd. Het werkt door dns-responses voor 'tweakers.net', afhankelijk van de belasting, te beantwoorden met een van twee ip's.
-
Ssl-offload
- Op dit moment gebruiken we Varnish voor caching van data. Varnish werkt goed, maar kan niet overweg met ssl. We kunnen uiteraard Varnish vervangen of een extra proxy voor Varnish zetten, maar ssl-termination op de adc zou dit ook oplossen.
- Http/2
- De browserondersteuning voor http/2 is al behoorlijk ver. Daarom is het ook handig als de adc dat al ondersteunt of in ieder geval bij de makers in beeld is.
- Ipv4 naar ipv6/ipv6 naar ipv4
- Op dit moment is onze ipv6-implementatie nog niet compleet. Het kan daarom nuttig zijn als een adc het inkomende ipv6-verkeer kan omzetten in ipv4.
- Scripting/api
- Soms wil je meer dan de standaardfunctionaliteit en dan is een ingebouwde scriptingtaal en/of api erg nuttig.
- Support/documentatie
- Zonder documentatie kom je nergens en als het dan nog niet lukt, is iemand anders kunnen vragen hoe iets moet ook wel handig.
- 'Layer 7'-loadbalancing
- Soms is het handig om aan de hand van de inhoud van requests keuzes te maken. Het inspecteren van requests wordt meestal L7-loadbalancing genoemd. Direct server return
- Voor video-streaming is het handig als de loadbalancer een server uitkiest en als daarna de streaming-server zélf reageert op de request, in plaats van het naar de loadbalancer terug te sturen. Daarvoor is dsr bedoeld. Caching
- We gebruiken Varnish voor 'reverse proxy'-caching. Als de adc dat beter kan of meer functionaliteit erbij biedt, kan dat interessant zijn om in te zetten.
- Web application firewall
- Voor de beveiliging kunnen waf-functies nuttig zijn. We zijn er overigens op dit moment nog niet van overtuigd dat dat gaat werken op Tweakers, al is het alleen maar omdat je voorbeeldscripts wil kunnen plaatsen in een programmeertopic
Het kan natuurlijk zijn dat we in de bovenstaande lijsten nog dingen vergeten zijn of aannemen dat het standaard op adc-platforms zit; denk aan tcp-multiplexing en syn-flood-bescherming. Dan horen we dat graag van jullie in de reacties onder dit artikel. Uiteraard horen we in elk geval graag jullie ervaringen, tips en feedback, ook als je denkt dat we genoeg zouden moeten hebben aan een oplossing die niet aan alle bovenstaande wensen en eisen voldoet
Centrale opslag
Na onze loadbalancers is de centrale opslag aan de beurt. Zoals beschreven gebruiken we nu twee ZFS-storage-appliances. Ze werken goed, maar hebben bij ons geen automatische fail-over. Verder is er een complete analyse van de data nodig, nadat er handmatig wordt overgeschakeld. Dat is niet vaak nodig, maar betekent wel dat het urenlang in de gaten moet worden gehouden.
Naast ZFS-oplossingen zijn er allerlei object storage- en private cloud-toepassingen, zoals Ceph en GlusterFS. Dan gaat het ons vooral om de redundantie en automatische fail-over, niet om de 'oneindige' capaciteit. We verwachten dat de gebruikte capaciteit voorlopig onder de 30TB blijft. Onze huidige 2U back-upserver biedt dat al.
Ook hiervoor kijken we naar allerlei aspecten.
- Eisen en wensen
- Must have
- Should have
- Nice to have

- Betrouwbaar
- Een opslagplatform moet natuurlijk betrouwbaar zijn, bestanden moeten daadwerkelijk op permante opslag staan als het filesystem dat beweert. Overigens mogen thumbnails wel 'wegrotten', zolang ze dan maar als geheel worden verwijderd.
- Ondersteuning voor veel (kleine) files
- We hebben veel kleine bestanden, vooral (thumbnails van) afbeeldingen. Met veel bedoelen we een paar miljoen; we zijn geen Google of Facebook
Als we een directory met dergelijke bestanden verwijderen, moet het platform dat natuurlijk ook aankunnen.
- Ondersteuning voor grote files en vm-images
- We bewaren ook grote files zoals video's en vm-images. Video's worden alleen geschreven en niet meer aangepast, maar bij vm-images worden juist kleine stukjes van de bestanden veranderd.
- Replicatie/redundantie
- Er moet een vorm van replicatie en redundantie beschikbaar zijn, idealiter met automatische fail-over waar we niets van merken.
- Back-ups
- Het moet mogelijk zijn om back-ups van delen van het filesystem te maken. Liefst is het ook mogelijk om incrementele back-ups te maken, bijvoorbeeld door het verschil tussen twee snapshots op te vragen.
- Posix/nfs
- Een migratie van Posix (via nfs) naar 'iets anders', bijvoorbeeld object storage, zal tijd kosten en voor sommige bestanden, zoals cli-scripts, niet zomaar kunnen. Daarom is ondersteuning voor Posix handig. Dat mag eventueel ook met een losse nfs-server, maar we hebben dat het liefst net zo betrouwbaar en redundant als de rest.
- Snapshots
- Met de hoeveelheid bestanden die we hebben, is het lastig om (vaak) back-ups te maken, snapshots kunnen helpen om fouten te herstellen. We willen er het liefst een paar per dag, week en maand hebben. Idealiter kan het aanmaken en verwijderen van snapshots automatisch worden gedaan.
- Always on/uitbreidbaar
- Hardware gaat zo nu en dan stuk en software krijgt updates. Beide willen we liefst zonder merkbare gevolgen kunnen vervangen. Ook is het handig als de capaciteit gaandeweg uitgebreid kan worden, mocht onze schatting toch niet kloppen.
- Geolocatie
- We slaan bestanden op twee locaties op. Idealiter houdt het platform daar rekening mee, liefst zo dat servers op locatie A ook vooral met de nodes van locatie A communiceren.
- Prestaties
- Door caching op webservers wordt het bestandssystem relatief weinig gebruikt, maar voor alle cache misses willen we wel een snelle reactie. Ook moet het uploaden of wijzigen van bestanden niet te lang duren.
- Deduplication
- Bij afbeeldingen en andere bestanden komen duplicaten voor. Deduplicatie kan daarom helpen om ruimte te besparen.
- Compressie
- Hoewel we vooral afbeeldingen en video's plaatsen, kan het ons toch wat ruimte besparen als we, voor delen van het systeem, kunnen aangeven dat de bestanden gecomprimeerd mogen worden. Multi-level storage/ssd-caching
- We hebben bestanden die vaak worden opgevraagd en bestanden die nauwelijks worden opgevraagd. Hoewel die eerste al in Varnish zullen worden gecached, kan het toch nuttig zijn om (automatisch) de meestgebruikte typen bestanden op ssd's te plaatsen.
- Support
- We vinden het niet erg om zelf een server in te richten, maar bij dit soort complexe toepassingen zijn goede documentatie en de mogelijkheid tot ondersteuning wel prettige bijkomstigheden.
Bovenstaande eisen en wensen zijn afgeleid van wat we nu met ZFS doen en sterk beïnvloed door wat Ceph zoal kan. Dat lijkt goed te voldoen aan de meeste van de eisen en wensen, en doet zelfs nog een gooi naar de nice to haves. Als de eisen en wensen onrealistisch zijn, horen we het graag. Verder lezen we natuurlijk ook hierover graag jullie ervaringen, tips en feedback onder dit artikel.
Webservers en reverse proxy
We zijn behoorlijk tevreden over onze caching reverse proxy Varnish en onze webserver Apache, maar er zijn diverse alternatieven te vinden. We weten uiteraard van het bestaan van veel ervan, maar we kunnen ze niet zo makkelijk 'even' in productie uitproberen. We maken dankbaar gebruik van allerlei krachtige functionaliteit in Varnish en Apache; dat zouden we dan moeten omzetten of soms zelfs moeten verplaatsen naar onze php-code.
Het is niet allemaal perfect. Zo kan Varnish niet overweg met https en dat biedt ook weinig hoop voor http/2.0-ondersteuning. Daarnaast krijgen we bij Apache de stabielste werking via de proces-based workers, maar dat schaalt niet goed.
Om dat soort redenen zijn we erg benieuwd naar praktijkervaringen met die mogelijke vervangers. De bekendste is waarschijnlijk Nginx. In benchmarks die we een tijd geleden deden, bleek die niet sneller te zijn. Apache+mod_php was sneller dan Nginx+php-fpm en doordat Varnish de statische content toch al voor zijn rekening neemt, is de winst van Nginx daarbij beperkt.
We horen natuurlijk graag of dat intussen beter is geworden of dat er andere, (nog) betere alternatieven bestaan.
Conclusie
In dit artikel hebben we een nieuw overzicht gegeven van de hardware die Tweakers gebruikt. De architectuur, waaronder de gebruikte software, is niet echt veranderd. Er zijn vast allerlei dingen nog niet duidelijk of niet in voldoende detail benoemd. We verwachten uiteraard dat jullie dat in de reacties kenbaar maken, zodat wij nog meer kunnen uitleggen
Op deze laatste pagina hebben we beschreven waar we het komende jaar mee aan de slag gaan. Mocht je hierover wat willen weten of juist kunnen delen, dan horen we dat heel graag. We proberen de beste keuze te maken, maar de mogelijkheden zijn legio en het is lastig om overal een goed beeld van te krijgen. Jullie ideeën, tips en praktijkervaringen zullen ons, én de medetweakers, erg van nut zijn.