Wat eraan voorafging
Achttien jaar geleden begon Femme deze site op een shared-hostingaccountje bij Pair Networks. Nu draait Tweakers op meer dan veertig verschillende servers en devices, verdeeld over drie serverracks op twee locaties. Dat gebeurde uiteraard niet van de ene dag op de andere en in de tussentijd zijn er veel dingen geleerd, fouten gemaakt, servers vervangen en verhuizingen geweest.
Acht jaar geleden hebben we daarover een reeks artikelen geschreven voor het tienjarige bestaan van Tweakers, dus is het nu hoog tijd voor een vervolg. Dit vervolg is wel korter dan de trilogie die hieraan voorafging, domweg omdat er veel minder fout ging en de enige noemenswaardige momenten upgrades van servers zijn, waarbij niets misging.
Verschillende fileservers door de jaren heen
Eerdere artikelen
In de hostinggeschiedenis 1998 - 2001 bespreekt Femme hoe Tweakers groeide van hosting op een simpel shared-hostingaccount tot de eerste stappen in de colocatiewereld, met een tweetal servers bij Vuurwerk Internet. Dit artikel is opgevolgd door de hostinggeschiedenis 2001- 2004, waarin we verdergaan met de hosting van Tweakers: van twee servers bij Vuurwerk Internet tot aan een rack vol servers bij True in Redbus. Het slotstuk van deze trilogie is de hostinggeschiedenis 2005 - 2008, waarin we ons verhaal voortzetten met de hostinggeschiedenis van Tweakers, eerst nog in Redbus, en later de verhuizing naar EUNetworks-suite van True. Verder gaan we nog even in op de roerige geschiedenis van loadbalancers en fileservers.
En nu verder: 2008 - 2010
Aan het einde van de vorige reeks waren we net verhuisd naar Eunetworks en hadden we plannen om onze storageomgeving om te zetten in een via iscsi gedeelde disk met daarop gfs. Na enkele weken testen bleek gfs echter niet zo stabiel te zijn als we hoopten. Sterker nog, zodra de filesize boven de 4kb uitkwam, gaf gfs een leeg bestand terug. Omdat we de hardware al wel hadden staan, besloten we om er ocfs2 op te zetten.
Ook ocfs2 was niet bijzonder stabiel en crashte regelmatig, of de nodes kregen onderling ruzie, waarmee ze het volledige cluster onderuit trokken. Het dieptepunt was een Stonith-reeks, waarbij de servers om de beurt een andere server gingen rebooten. Ook handmatig onderhoud veroorzaakte problemen; een netwerkswitch rebooten leidde tot problemen met de fileserver, waardoor een in theorie korte downtime ineens veel langer duurde.
Toch knap dat acties van honderden jaren geleden tot
bugs in onze moderne software kunnen leiden
Nog afgezien van de problemen die we met ocfs2 hadden, bleek ook onze iscsi-server niet geheel bugvrij te zijn. Zodra er een disk doodging, wat regelmatig gebeurde, crashte de hele appliance en wilde hij niet meer normaal werken totdat de schijf vervangen was. Dit had aardige gevolgen op de servers die van die iscsi-export gebruikmaakten, zoals een 'load' van meer dan 10.000.
Ook met MySQL hadden we vreemde problemen, waardoor het Forum er elke dag enkele seconden tot minuten uit lag. Na lang debuggen bleek de server te crashen als de profielpagina van een gebruiker werd opgevraagd en deze gebruiker een geboortedatum tussen 0000-01-01 en 0000-02-28 had opgegeven. MySQL probeerde die dagen terug te rekenen naar 'het aantal dagen sinds het begin van de jaartelling', maar vanwege diverse kalenderaanpasingen in de afgelopen 2000 jaar kwamen deze data uit op een negatief getal en dus besloot MySQL dan maar te herstarten. Toch wel knap dat acties van honderden tot duizend jaar geleden tot bugs in onze moderne software kunnen leiden.
Weer een nieuwe databaseserver
In 2009 hebben we ook de hoofddatabaseserver weer eens vervangen, deze keer door Artemis 6, de zesde nieuwe databaseserver in minder dan tien jaar tijd. Deze server was de eerste databaseserver die zijn data niet meer opsloeg op een groot aantal ronddraaiende schijven, maar op een disk-array bestaande uit zes 50GB-ssd's. Ook de geheugenupgrade was indrukwekkend, van 16GB in Artemis 5 naar 72GB in Artemis 6.
Deze nieuwe databaseserver was zo krachtig dat we de splitsing in databases die acht jaar daarvoor nog noodzakelijk was, weer ongedaan konden maken. Bovendien konden we de vrijgekomen databaseserver gebruiken in een master-slave-replicatieopstelling, zodat we, zelfs als een databaseserver volledig dood zou gaan zoals bij Big Crash 3, nooit meer dan een paar seconden dataverlies zouden lijden.
Artemis 6 - Dell R710
Videoplatform en storageomgeving 2010-2012
Het grootste probleem in onze omgeving medio 2010 was nog steeds de fileserver. We hadden hier nog geen goede oplossing voor gevonden. De jaren hiervoor hadden we vele oplossingen geprobeerd: linux/freebsd-NFS-servers, iscsi-disks met een clusterfilesysteem zoals gfs en ocfs2, enzovoort. We besloten om dit keer terug te grijpen op NFS, maar dan met een server die op OpenSolaris draaide. Dat Oracle OpenSolaris afschoot direct nadat wij het geïnstalleerd hadden, zat niet in de planning.
Deze nieuwe server kreeg maar liefst tien 500GB-disks en vier ssd's voor ZFS's L2ARC en ZIL. Afgewerkt met 2x Intel Xeon E5520 en 24GB geheugen was dit de eerste opslag die niet de hele tijd grote problemen opleverde.
Dat Oracle OpenSolaris afschoot direct nadat wij het geïnstalleerd hadden, zat niet in de planning
Vervanging secundaire databaseserver
Op de vorige pagina heb je kunnen lezen hoe we weer een nieuwe databaseserver hadden gekocht. Enkele maanden na die server hebben we ook de secundaire slavedatabaseserver vervangen. De hardware was nu krachtig genoeg om bij het uitvallen van de hoofddatabaseserver alle taken over te nemen.
Deze nieuwe server repliceerde de database op de hoofddatabaseserver zodat er, bij het uitvallen van de andere server, nooit meer dan een paar seconden aan dataverlies zou zijn. Dat was al een heel stuk beter dan enkele maanden aan dataverlies zoals bij Big Crash 3.
Videoplatform en uplinkuitbreiding
In augustus van dat jaar namen we ons nieuwe videoplatform in gebruik. Dit betekende een stapel extra servers om de video's te serveren, transcoderen en beheren. De webservers die we kozen, waren simpele Dell R210-servers, met zes netwerkpoorten. Deze hingen we vervolgens met vier kabels aan een switch, waardoor we in theorie 4Gbit/s aan traffic konden uitsturen. Om daarbij in de buurt te kunnen komen heeft True onze internetverbinding voorzien van een upgrade; van 2x1Gbit/s-lijnen naar 2x2 1Gbit/s-lijnen, zodat we 4Gbit/s uitgaand verkeer konden halen als alle routers werkten.
Voor de transcodering en het beheer werden twee R410's aangeschaft. De transcodering en het beheer werden daar vervolgens in virtuele machines gedaan. Ook onze eigen virtuele machines kwamen hiernaast te draaien.
Een videowebserver, een VM-server en twee (hergebruikte) transcoderingsservers
Tweakers 7
In oktober 2012 vond de jongste grote overhaul van de site plaats. De servers hadden het verdraaid lastig met al deze nieuwe code en er moesten in een hoog tempo hotfixes bedacht en geschreven worden. Zo werd bijvoorbeeld de engine veel meer gebruikt. Die werkte heel goed en handelde soms tientallen query's per pageview af, maar als je dan elke keer een nieuwe connectie opzet, loop je vrij snel tegen een aantal limieten aan.
Als je tegen die limieten aanloopt, werkt je webserver niet meer. Gelukkig hadden we genoeg webservers om de site redelijk werkend te houden, maar elk kwartier een van de webservers offline halen om 'af te koelen' is niet ideaal. Door hard werk van de developers konden we dat gelukkig nog voor het einde van de dag oplossen.
De load op een van de webservers, kort na de release van Tweakers 7
Project Phoenix 2012-2015
In de zomer van 2011 begonnen we met het bedenken en uitvoeren van Project Phoenix, een project om de site nog beter bestand te maken tegen verschillende soorten downtime. De afgelopen jaren waren al bijzonder goed verlopen wat downtime betreft, zeker vergeleken met de beginjaren, waarin we er soms dagen uitlagen, maar het kon nog beter. We waren vooral kwetsbaar doordat we maar één locatie hadden en mocht daar iets ernstigs gebeuren, zoals brand of overstroming, dan hadden we helemaal niets meer en zouden we dagen tot weken plat liggen. Om dit voor te zijn besloten we om een tweede locatie op te zetten, die alle belangrijke taken kan overnemen bij uitval van de hoofdlocatie.
Ook nieuw was dat we bij dit project alle serverleveranciers vroegen om een mooie offerte
In samenwerking met onze leverancier Quanza werd het project gestart en vulden we een rack bij Redbus Telecity3 Equinix AM8, een locatie die ons wel bekend was, aangezien we daar zelf twee jaar hadden gezeten. Dit nieuwe rack werd voorzien van een kopie van alle servers op de hoofdlocatie en werd verbonden door middel van een redundante 10Gbit/s-'dark-fiber'-verbinding met onze hoofdlocatie.
Ook nieuw was dat we bij dit project alle serverleveranciers vroegen om een mooie offerte voor een hele stapel servers. IBM bleek uiteindelijk de mooiste offerte te kunnen overleggen en dus kochten we voor het eerst sinds december 2007 weer een IBM-server.
Nieuwe software, databaseserver en storage
Naast de verdubbeling van het aantal servers, besloten we om het beheer van de servers te vereenvoudigen. Hiervoor namen we het besluit om Debian Testing als standaardbesturingssysteem te laten varen en over te stappen op de LTS-serie van Ubuntu. Daarnaast werden alle servers gedefinieerd in een Puppet-manifest, zodat het opnieuw installeren van een server in theorie een fluitje van een cent is.
Verder, zoals op zo'n beetje elke pagina terugkomt, installeerden we begin 2013 opnieuw een nieuwe databaseserver. De oude had het meer dan drie jaar volgehouden en mocht met pensioen als developmentserver. Ook de storageomgeving was weer aan vervanging toe en omdat de vorige OpenSolaris-installatie goed was bevallen, stapten we nu over op twee Sun ZFS Storage 7120-appliances, die naar elkaar repliceerden.
/i/2001244995.jpeg?f=imagenormal)
Netwerkupgrade en schoonmaken racks
In 2015 zijn we druk bezig geweest om, vrijwel zonder downtime, de volledige stroomvoorziening te vervangen. Hiervoor werden weer eens ouderwets heel wat dagen in het datacentrum doorgebracht om alle 0u PDU's te vervangen. In theorie klinkt een 0u PDU als een goed idee om niet al te veel rackspace kwijt te raken aan je stroomvoorziening, maar in de praktijk bleek dat deze stroomvoorziening achter in je rack het vrijwel onmogelijk maakte om daar te werken.
Zo konden we bijvoorbeeld de switches niet vervangen, omdat de 'skilatten' in de weg zaten. Verder kochten we op een gegeven moment een server die langere sliders had dan de vorige generatie servers en daardoor niet in het rack opgehangen kon worden. Daardoor waren we gedwongen om een andere server tot 'plank' te promoveren. Verder was het wegwerken van de netwerkkabels vrijwel onmogelijk en was het aan de achterkant van het rack niet prettig werken vanwege de enorme kabelbos.
Om dit aan te pakken hebben we de stroomvoorziening vervangen door 1u-stekkerdozen en hebben we van True vier zijplaten in het rack gekregen. Vervolgens hebben we alle netwerkkabels vervangen door exemplaren van de correcte lengte en alle kabels gelabeld en weggewerkt met enkele rollen klittenband.
Toen de racks weer toonbaar waren, hebben we bovendien twee nieuwe 10Gbit/s-switches in het rack gehangen, de uplink naar true omgezet van 2x2 1GbIt/s-koperdraden naar twee 10Gbit/s-fibers en nieuwe firewalls opgehangen die 20Gbit/s konden verwerken.
Achterkant van het rack voor en na de opruimactie
De stand van zaken
De laatste update rond de servers hebben we vorig jaar gegeven. Daar is niet heel veel aan veranderd, dus lopen we er in sneltreinvaart doorheen.
Webservers
We hebben momenteel in totaal tien webservers in dienst. Vier daarvan zijn 'applicatie'-servers, die voornamelijk php-scripts verwerken en onder andere een aantal caches, zoals de Java Engine, lokaal draaien. De statischecontentservers serveren, vanzelfsprekend, meestal statische content, zoals afbeeldingen en stylescripts, maar kunnen ook de dynamische scripts serveren als dat nodig is. De videowebservers serveren tot slot al onze video's en zijn daarom ook met vijf netwerkkabels op onze switches aangesloten, om zo met maximaal 5Gbit/s video's te streamen.
| Onderdeel |
Application server |
Statische content |
Video |
| Chassis |
4x IBM x3550 M5 |
3x IBM x3250 M5 + 1x M4 |
3x IBM x3250 M4 |
| Cpu |
2x E5-2640 v3 (2,6GHz 8c) |
M5: E3-1271 v3 (3,6GHz 4c)
M4: i3-3220 (3,3GHz 4c) |
i3-3220 (3,3GHz 4c) |
| Geheugen |
8 x 8GB (64GB) |
4 x 8GB (32GB) |
4 x 8GB (32GB) |
| Disk |
500GB-sata |
M5: 250GB-sata
M4: 64GB-ssd |
64GB-mlc-ssd
900GB-10k-sas |
| Netwerk |
4x 1Gbit/s |
M5: 4x 1Gbit/s
M4: 6x 1Gbit/s |
6x 1Gbit/s |
Loadbalancers en virtualisatieplatform
De loadbalancers die we tegenwoordig gebruiken, zijn gewone servers met daarop een gewone Ubuntu-installatie en speciale software van Brocade. De servers die we voor virtualisatietaken gebruiken, draaien een mix van docker-containers en kvm-images.
| Onderdeel |
Loadbalancer |
Virtualisatie |
| Chassis |
3x Dell R430 |
3x IBM x3550 M4 |
| Cpu |
2x Xeon E5-2623 v4 (3,0GHz, 8c) |
2x Xeon E5-2630 v2 (2,6GHz, 6c) |
| Geheugen |
4 x 16GB-(64GB-)ddr4 |
64GB-ddr4-1866 |
| Disk |
2x 120GB-ssd
2x 1TB-7200rpm-sata |
2x1TB-7200rpm-sata |
| Netwerk |
2x 10Gbit/s-sfp+
4x 1Gbit/s |
M5: 4x 1Gbit/ |
Databaseservers
We hebben diverse databases en zoekmachines in ons cluster staan. De hoofddatabase staat in MySQL, maar we hebben ook mongodb, activemq en twee machines voor de zoekmachine. Deze zijn allemaal redundant uitgevoerd, zodat er eentje mag crashen. Een kort overzicht:
| Onderdeel |
MySQL master |
MySQL slave |
NoSQL & Search |
| Chassis |
HP DL360 |
IBM x3550 M4 |
4x IBM x3550 M5 |
| Cpu |
2x Xeon E5-2643 v3 (3,4GHz 6c) |
2x E5-2643 v1 (3,3GHz 4c) |
2x Xeon E5-2623 v3 (3GHz, 4c) |
| Geheugen |
16 x 16GB (256GB) |
16 x 16GB (256GB) |
4x 16GB (64GB) |
| Disk |
2x 80GB-boot-ssd
6x 240GB-mlc-ssd |
2x 500GB-boot-sata
6x 240GB-mlc-ssd |
2x 120GB-mlc-ssd |
| Netwerk |
2x 10Gbit/s-sfp+
4x 1Gbit/s |
4x 1Gbit/s |
2x 10Gbit/s-sfp+
4x 1Gbit/s |
Opslag
Om alle plaatjes, video's en virtual server images op te slaan, gebruiken we twee Oracle-applicaties. De back-ups daarvan worden weggeschreven op een server met een hele rits disks.
| Onderdeel |
Hoofdopslag |
Back-up |
| Chassis |
2x Oracle ZFS 7120 |
IBM x3630 M4 |
| Cpu |
1x E5620 (2,4GHz, 4c) |
2x Xeon E5-2407 (2,2GHz, 4c) |
| Geheugen |
6 x 4GB (24GB) |
4x 16GB (64GB) |
| Disk |
11x 3TB-sata
1x 80G-slc-ssd |
12x 4TB-sata |
| Netwerk |
4x 1Gbit/s |
4x 1Gbit/s |
Overige servers
Naast de servers voor de hoofdtaken hebben we nog een scala aan servers in het rack hangen om diverse andere taken af te handelen. De mailserver spreekt voor zich, de managementservers handelen taken als dns en ldap af en de developmentserver draait een mix van docker-containers en kvm-images om een developmentomgeving aan te bieden.
| Onderdeel |
Mailserver |
Management |
Development |
| Chassis |
IBM 3550 M4 |
2x IBM x3550 M4 |
IBM x3550 M5 |
| Cpu |
2x Xeon E5-2620 v2 (2,1GHz, 6c) |
1x Xeon E5-2620 v2 (2,1GHz, 6c) |
2x Xeon E5-2630 v3 (2,4GHz, 8c) |
| Geheugen |
6x 4GB (24GB) |
4 x 8GB (32GB) |
8x 16GB (128GB) |
| Disk |
2x 64GB-mlc-ssd |
1x 1TB-sata |
4x 1TB-mlc-ssd |
| Netwerk |
4x 1Gbit/s |
4x 1Gbit/s |
2x 10Gbit/s
4x 1Gbit/s |
Netwerk en firewalls
Het interne netwerk bestaat uit een enkele HP Procurve 2510-1Gbit/s-switch met 10 poorten, drie 1Gbit/s-Cisco 2960S-switches met 24 poorten, aangevuld met drie 1Gbit/s-Cisco 2960S-switches met 48 poorten en afgetopt met twee 10Gbit/s-Arista 7150S switches met 24 poorten.
De firewalls zijn twee Fortigate 800C-firewalls met een throughput van 20Gbit/s en een enkele Fortigate 300D voor op de uitwijklocatie.
Het 10Gbit/s-netwerk, firewall en loadbalancers
Databaseservers en stats
In de loop van achttien jaar hebben we ruim zestien (MySQL-)databaseservers verbruikt. Deze servers zijn traditiegetrouw de snelste en vetst uitgevoerde servers in ons serverpark geweest. Pas in de laatste jaren bemerken we geen fors toegenomen prestaties van de nieuwe databaseservers, terwijl dit in het verleden grote invloed had op de snelheid van de website.
Artemis en Apollo
De belangrijkste server in ons serverpark heeft altijd Artemis geheten. Op deze server draait tegenwoordig de database voor de hele site en hij is de active masterserver in onze active-passive multimaster-MySQL-databaseset-up.
De databaseserver is vrijwel altijd redundant uitgevoerd geweest. De tweede server kreeg de naam Apollo en was meestal net niet de snelste die we hadden. De Forum-database heeft een tijd lang exclusief op Apollo gedraait, vandaar dat Apollo 3 tot 5 in een rap tempo zijn vervangen om het Forum op een acceptabel prestatieniveau te houden.
| Naam |
Jaar |
Cpu |
Geheugen |
Db-opslag |
| Artemis 1 |
2000 |
2x PIII 733MHz |
1,5GB |
3x Cheetah X15 18GB |
| Apollo 1 |
2001 |
2x PIII 1GHz |
2GB |
2x Atlas 10K II 18GB |
| Artemis 2 |
2001 |
2x AMD MP1600+ 1,4GHz |
2GB |
5x Cheetah X15 18GB |
| Apollo 2 |
2002 |
2x AMD MP1600+ 1,6GHz |
3,5GB |
5x Cheetah 36XL 36GB |
| Artemis 3 |
2003 |
2x Opteron 246 2,0GHz |
4GB |
4x Cheetah 10K.6 36GB |
| Apollo 3 |
2003 |
2x Opteron 242 1,6GHz |
6GB |
6x Cheetah 10K.6 36GB |
| Apollo 4 |
2004 |
2x Opteron 244 1,8GHz |
8GB |
6x Cheetah 15K.3 36GB |
| Apollo 5 |
2006 |
2x Xeon 5160 3,0GHz |
16GB |
15x Fujitsu 15K 36GB-sas |
| Artemis 4 |
2006 |
2x Opteron 254 2,8GHz |
8GB |
6x Cheetah 15K.3 36GB |
| Artemis 5 |
2007 |
2x Xeon X5355 2,66GHz |
16GB |
15x Cheetah 15K.5 73GB |
| Artemis 6 |
2009 |
2x Xeon X5570 2,93GHz |
72GB |
6x 50GB-ssd |
| Apollo 6 |
2010 |
2x Xeon X5660 2,8GHz |
48GB |
6x 50GB-ssd |
| Artemis 7 |
2013 |
2x Xeon E5-2643 3,3GHz |
256GB |
6x 256GB-ssd |
| Apollo 7 |
2013 |
2x Xeon E5-2643 3,3GHz |
256GB |
6x 240GB-ssd |
| Artemis 8 |
2016 |
2x Xeon E5-2643 v3 3,4GHz |
256GB |
6x 240GB-ssd |
| Apollo 8 |
2016* |
2x Xeon E5-2643 v4 3,4GHz |
256GB |
6x 800GB S3510-ssd |
* Nog niet in gebruik genomen
Zoals op de eerste foto te zien is, hadden vooral de eerste databaseserver-upgrades significante prestatievoordelen. De latere upgrades laten een minder grote prestatieverbetering zien. Daarnaast werden we steeds beter in het offloaden van zware queries naar gespecialiseerde applicaties en het inzetten van bijvoorbeeld memcached.
Stats!
Wij tweakers zijn dol op statistieken. Veel daarvan kun je al op de site terugvinden, maar hieronder hebben we er toch nog een paar voor je bijeengezocht om de groei van ons serverpark weer te geven.
| Hoeveelheid |
2001 |
2008 |
2016 |
| Servers |
3 |
16 |
29 |
| Processoren |
4 |
28 |
47 |
| Cores (zonder HT) |
4 |
54 |
210 |
| Bogomips |
6.132 |
273.920 |
1.268.000 |
| Geheugen |
2,4GB |
86GB |
1.980GB |
Harddisks
ssd |
8
- |
104
- |
57
42 |
Diskruimte
ssd |
110GB
- |
17.129GB
- |
198.200GB
17.264GB |
| Switchpoorten |
8x 100Mbit/s |
160x 1Gbit/s
12x 10Gbit/s |
226x 1Gbit/s
60x 10Gbit/s |
| Internetverbinding |
100Mbit/s |
2Gbit/s |
21Gbit/s |
Serverpower van het begin van de hostinggeschiedenis tot september 2016
En nu
Zoals je hebt kunnen lezen en aan de grafiek hierboven hebt kunnen zien, is het in de afgelopen jaren op serverbeheergebied steeds rustiger geworden. Konden we vroeger nog reviews volschrijven over een paar jaar geschiedenis, nu hebben we aan acht jaar geschiedenis al nauwelijks genoeg voor een review. Dat is niet omdat er niets is gebeurd, maar wat er is gebeurd, had weinig gevolgen voor onze bezoekers.
Door de toegenomen redundantie hoeven we ons bed niet meer uit te komen als er een server onderuitgaat en doordat we nu de servers met support kopen, hoeven we niet naar Schiphol te rijden om bij een hardwarefabrikant wat schroefjes te halen om een harde schijf vast te kunnen zetten.
We blijven ook in de komende jaren letten op de prestaties van de site. Hierbij hopen we dat jullie weinig van ons werk gaan merken, behalve dat de site snel is en een hoge uptime heeft.
:strip_exif()/i/2001245037.jpeg?f=imagegallery)
:strip_exif()/i/2001245039.jpeg?f=imagegallery)
:strip_exif()/i/2001245041.jpeg?f=imagegallery)
:strip_exif()/i/2001245043.jpeg?f=imagegallery)
:strip_exif()/i/2000621788.jpeg?f=imagegallery)
:strip_exif()/i/2000621789.jpeg?f=imagegallery)
:strip_exif()/i/2000621791.jpeg?f=imagegallery)
:strip_exif()/i/2000621790.jpeg?f=imagegallery)
:strip_icc():strip_exif()/i/2003096314.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2000866307.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/1361447711.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/1327998821.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/1223473000.jpg?f=fpa_thumb)
:strip_icc():strip_exif()/i/1222700622.jpg?f=fpa_thumb)
:strip_icc():strip_exif()/i/1222086466.jpg?f=fpa_thumb)
/u/8/oog3.png?f=community){kind=small}
. Ik kan redelijk raden wat er gebeurd als ik dit serverpark zou gebruiken om een ddos uit te voeren: /u/417613/crop5df91c60a28d2.png?f=community){kind=small}
:strip_icc():strip_exif()/u/174665/crop5f3505845c31b_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/450644/crop5dc26bbdeb9aa_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/53213/crop57ace20969734.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/242056/hellno%2520-%2520Copy.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/129865/crop5cb775b8692d8.jpeg?f=community){kind=small}
/u/148661/crop559fd5b259ff4.png?f=community){kind=small}
:strip_exif()/u/16970/crop57cd1ef1eb0d0.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/205841/crop5770e8a391a18_cropped.jpeg?f=community){kind=small}
:strip_exif()/u/284473/crop598caffe294d9.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/2030/zeef.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/140051/BSOD.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/393218/Tweakers.net.jpg?f=community){kind=small}
:strip_exif()/u/160115/small.gif?f=community){kind=small}
/u/1830/acm.png?f=community){kind=small}
:strip_icc():strip_exif()/u/146731/crop562615a0aa64c.jpeg?f=community){kind=small}
Daar lees ik niks over in het artikel. Neem aan dat er van alles gemonitord wordt qua CPU-load, schijfruimte, netwerkverkeer etc.