Server- & netwerkstatusmeldingen XI

Problemen met de servers en de netwerkverbinding van Tweakers.net worden in deze .plan gemeld. De laatste informatie over de serverloads en -uptimes kun je volgen op de statistiekenpagina.

Statusmeldingen

03-08-2011 Morgenochtend rond een uur of zes willen wij ons mongodb-server-cluster upgraden en opschonen. Hierdoor kan het zijn dat je sessie kwijtraakt, of dat er wat tellertjes in je sessiecounter omlaag springen. Deze upgrade gaat ongeveer een half uur duren in totaal.

18-06-11 We gaan even bezig met een update van de jobs sectie. Dit zorgt ervoor dat het even kan zijn dat de tweakers.net/jobs even niet werkt of geen vacatures laat zien. Ook ben je eventuele gebookmarkte jobs kwijt, maar aangezien er een compleet nieuwe batch aan jobs wordt ingeladen, waren deze toch niet meer heel zinvol. Opgeslagen zoekopdrachten blijven wel bewaard, aangezien deze onafhankelijk van specifieke vacatures opgeslagen worden. Hopelijk is het zo gepiept! En klaar alweer! Enjoy.

23-02-11 En zo vonden we toch een DDoS-variant waar de RioRey-appliance ons blijkbaar niet zo goed tegen weet te beschermen. Het lijkt op een Slowloris-aanval. E.e.a. wordt uiteraard met hun support-afdeling opgenomen, maar gelukkig is dat type aanval toevallig vrij goed af te slaan door simpelweg je Apache-frontend te vervangen door bijvoorbeeld een Varnish-frontend. En laten we die nou toevallig al meer dan een jaar hebben draaien voor het snel aanleveren van semi-statische plaatjes. We hebben daarom in de loadbalancers de boel aangepast, zodat ook het verkeer voor 'tweakers.net' zelf wordt omgeleid via die Varnish-installaties, in plaats van het direct naar de Apache-servers te sturen.

7-02-11 Nouja, toen ehm.. deden we nog maar 30mbit verkeer , 20 mbit minder dan een paar secondes ervoor. Wat er aan de hand was? Geen flauw idee :P Maar bij True waren ze hard bezig werd ons verteld Anyways, we zijn weer up, alleen doet IPv6 nog wel wat stom, dus als je naar AAAA dns-records kijkt: irc.tweakers.net is dan helaas wat minder goed bereikbaar, maar ook daar wordt aan gewerkt, door onze vrienden van True.

24-01-11 En zo kom je nog eens ergens achter.. Waarachter? Nou, wat het effect is als onze mongodb-installatie faalt. Blijkbaar was onze hot-standby databaseserver ermee gestopt wat na een powercycle een brakke mongodb-installatie opleverde. Aangezien mongo het niet tof vindt als we de reparaties uitvoeren terwijl er druk contact met hem wordt gelegd, hebben we tijdelijk even het inloggen bewust stuk gemaakt. Helaas had dat als effect dat iedereen de melding 'hey, je wachtwoord is stom in combinatie met je username' (vrije vertaling, ik heb hem niet gezien ) gaf, in plaats van 'joh, tijdelijk kun je ff niet inloggen'. Nouja, weer een reden om wat creatieve nieuwe foutmeldingen in die code te verwerken Oftewel, na een korte sessie met mongodb waarin we hem over z'n bol aaiden en zeiden dat het allemaal niet zo erg was, dat a-l-l-e-s goed zou komen, hebben we nieuwe indexen aan laten maken, en werkt alles weer Nu nog erachter komen waarom Apollo besloot na 221 dagen ermee te stoppen, maar we gokken op een race-conditie ergens in de irq verwerking van de kernel.

27-12-10 Zoals je ondertussen wel door hebt is Tweakers.net al een paar uur minder goed bereikbaar. Momenteel worden we lastig gevallen met een DDoS-aanval, waardoor we een dikke 40-50Mbit aan troep moeten zien af te slaan, terwijl we normaal hooguit 5-10Mbit inkomend verkeer hebben. Aan de statistieken van onze RioRey te zien is zo'n 90% van dat verkeer "pollution".

De DDoS-firewall lijkt het redelijk tegen te houden, maar de site is duidelijk minder goed bereikbaar dan anders. Mocht de boel dus minder goed reageren probeer na een paar seconden even of je met een refresh de juiste pagina wel krijgt.

Reacties (96)

Ik snap even niet waarom het hier over megabits gaat. Laatst was er toch voor gigabits aan datalijnen/capaciteit uitgebreid?

Dit is een SYN-aanval. Daarbij probeert men continu nieuwe verbindingen met onze servers op te zetten. Daardoor blijven de doelwitten (onze servers dus) met allerlei onbruikbare verbindingen zitten, wat de meeste servers wel bijhouden en vaak zelfs 'dure' processen of threads voor reserveren. Op die manier worden uiteindelijk dus alle beschikbare 'slots' of het geheugen/cpu-gebruik, etc vanzelf opgebruikt. En men probeert dat dan honderden keren per seconde (per deelnemend systeem).

Het ironische is dat je voor dergelijke aanvallen nauwelijks bandbreedte nodig hebt. De packets waarmee een verbinding geinitieerd wordt zijn doorgaans 64 bytes. Dus met een stroom van 100.000 van die packets in een seconde heb je nog steeds maar ongeveer 60Mbit aan dataverkeer. De piek was zo te zien ongeveer 80Mbit en normaal doen we op drukke momenten ongeveer 5Mbit aan legitiem inkomend verkeer.

Als er daadwerkelijk data wordt verzonden heen of weer, dan kan het oplopen tot 1500 bytes. En packets van die grootte worden uiteraard in normale omstandigheden veel meer verzonden, zeker bij de video-hosting. Met 100.000 packets per seconde van 1500 bytes zouden we op zo'n 1.5Gbit hebben gezeten.

[Reactie gewijzigd door ACM op 28 december 2010 10:54]

die 4gbit is bedoelt om data weg te kunnen sturen, de requests die we krijgen van onze gebruikers zijn over het algemeen vrij klein, dus een stroom van 40mbit is redelijk abnormaal voor ons doen. Verder komt die 40mbit aan bij servers die er niets mee kunnen wat dus ook overlast veroorzaakt.

Ook maar een keer een pagina die niet loadde. Hulde voor de firewall die deze ddos afslaat. Je kan maar beter goed voorbereid zijn. De enige vraag ook bij mij: waarom T.net?

Ik kan me niet herinneren dat we ooit een verklaring van iemand hebben gekregen van de dader(s) waarin uitgelegd werd wat we fout gedaan zouden hebben... En ook deze keer vindt men het niet nodig te laten weten waarom we dan aangevallen zouden moeten worden

best flauw eigenlijk zou je dan gewoon de ips moeten posten, kijken hoeveel tweakers er zin hebben om iets terug te doen .... gewoon uit intresse... natuurlijk

Altijd leuk van dat soort problemen. Waar gebruikt Tweakers.net eigenlijk mongodb voor? Ik moet zeggen mongodb is mooi systeem, maar het ontbreken van foreign keys (met on update / on delete) achtige functionaliteit maken het toch nog onbruikbaar om een volledige applicatie / website mee te draaien.

plan: Nieuwe databaseserver op 23 juni - update

- We hebben geen zin of tijd om het beheerwerk zelf te schrijven. Cassandra en Hadoop vielen daardoor af.
- We willen de instellingen per gebruiker logisch gegroepeerd houden, zonder concessies te doen aan het aantal en het type van de instellingen. Hierdoor viel een hoop software af, waaronder MemcacheDB en Tokyo Cabinet, en bleven vooral document databases over.
- We willen niet verplicht zijn om meer hardware toe te voegen als er meer data dan ram is - dus moesten we Redis en Terrastore schrappen.
- Query's als 'geef de instellingen behorende bij sessie X', 'geef alle sessies voor gebruiker Y' en 'hoeveel sessies zijn er voor Firefox-gebruikers' moeten efficiënt en snel worden uitgevoerd. De mapreduce-only document databases, zoals bijvoorbeeld CouchDB en Riak, waren daarom ongeschikt.
- We slaan slechts een paar gigabyte aan data op, dus rauwe performance is voor ons belangrijker dan uitgebreide schaalbaarheid.
- Aangezien we met PHP werken, moet daar eenvoudig mee gecommuniceerd kunnen worden.

Bedankt voor je antwoord. Dit maakt het inderdaad duidelijk. Thnx

Op Load & CPU-belasting is duidelijk te zien dat vanaf een uur of 22:00 gisteren de load gestaag omhoog gaat.

Dat is een server die vziw niet gerelateerd is aan deze aanval... Als je bij de gewone webservers kijkt zie je niet echt een toename in de load tov andere momenten.

40-50mbit ... dat is toch niet eens zoveel? De laatste DDOS die wij hier te verstouwen kregen pompte ~300mbit door onze lijntjes heen.

Dat is geen leuke rekening als je 10mbit 95pct afneemt

40-50Mbit niet nee... we kunnen makkelijk meer aan. Maar 100.000 nieuwe verbindingen per seconde proberen op te zetten is natuurlijk wel wat gerichter dan enkel bandbreedte
Zie ook mijn uitleg hierboven.

In dat geval zal ik de hosting provider verdenken.

Enige idee waarom deze DDoS attack wordt uitgevoerd?

vraag ik me ook af ze blokkeren toch niet wikileaks ?
Heb der weinig last van een keer uitval gehad op het forum mar verder niks

LMAO. Heerlijk waar het nu naar toe gaat. Als een website geDDoS'ed wordt worden er gelijk banden getrokken met Wikileaks.

heb het ook gemerkt.
alweer een ddos, de vorige was niet lang geleden. jullie lijken een ware proeftuin voor ddos technieken te worden. helaas was dit een redelijk geslaagde aanval, een heleboel andere sites zullen veel meer moeite hebben zich hier tegen te wapenen.

nog geen posts gelezen over wie er achter zou kunnen zitten, doen jullie daar geen uitspraken over of is het echt niet bekend?

weten we niet. Als jij het wel weet, kees at tweakers.net ontvangt graag mailtjes van de daders

Stomme vraag misschien, maar doen jullie aangifte van dit soort aanvallen?

Dit geeft aan hoe veel beter het model is van een server als nginx die niet per request een thread aanmaakt. Waarom nog Apache gebruiken?

Omdat Apache - vziw dan uiteraard - nou eenmaal nog steeds veel beter samenwerkt met PHP en allerlei wat meer complexe zaken ondersteund.

Nu tegenwoordig php-fpm bestaat is de samenwerking tussen php en nginx optimaal (spawn-fcgi werkt ook goed). Een heleboel complexere zaken (iig rewrites, virtual hosts, ssl) zitten tegenwoordig ook in nginx. Voor een goede uitleg waarom nginx zelfs beter zou zijn vond ik dit een goede post.

En ook een goede indicatie over stabiliteit, alles zit in de stable Debian repo's (fpm zit bij php ingebakken).

(Zie ook de discussie die ik gestart heb @GOT)

[Reactie gewijzigd door Pete op 24 februari 2011 15:08]

Jullie staken jullie dienstverlening aan Wikileaks ofzo? Enig idee wie er achter zou kunnen zitten?

afaik heeft Anon niets tegen #tweakers.net (=

De frontpage wordt nu steeds slechter bereikbaar. waarom zou iemand het in zijn hoofd halen om tweakers.net aan te vallen?

Misschien dat er mensen zijn die willen voorkomen dat er nog langer nieuws over Apple op t-net geplaatst kan worden

[Reactie gewijzigd door Iva_Bigone op 27 december 2010 13:55]