Facebook-storing werd veroorzaakt door interne 'ddos-aanval'

Facebook heeft donderdag te kampen gehad met een storing van 2,5 uur. Een intern controlesysteem veroorzaakte een soort interne ddos-aanval op de database. Dit leidde tot de grootste storing in vier jaar bij de sociale-netwerksite.

In een reactie op de storing schrijft Robert Johnson, hoofd software engineering bij het Amerikaanse bedrijf, dat Facebook beschikt over een geautomatiseerd systeem om de configuratie van de site te controleren. Na een wijziging in een van de instellingen dacht het controlesysteem dat het om een foute waarde ging, waarna het systeem probeerde in te grijpen en de problemen pas echt begonnen.

"De bedoeling van het automatische systeem is om ongeldige waarden in de cache op te sporen en deze te vervangen door de nieuwe waarde", aldus Johnson. "Dit werkt prima voor een losstaand probleem met de cache, maar werkt niet als de persistent store niet klopt." Het gevolg hiervan was dat elke client de ongeldige waarde zag en deze probeerde te repareren. "Omdat hierbij een query naar het databasecluster wordt gemaakt, raakte dit cluster overspoeld met honderdduizenden queries per seconde."

De enige manier om het probleem te herstellen bleek een herstart van het hele databasecluster te zijn, een proces dat ruim twee uur duurt. Nadat de database weer online was, liet Facebook langzaam gebruikers toe en functioneerde de site een half uur later weer als vanouds.

Reacties (110)

[Raven]

"een proces dat ruim twee uur duurt." ... Herstarten ze alles 1 voor 1 of zo om een stroompiek en inschakelende aardlekschakelaar te voorkomen?

[Verwijderd]

Ze zullen het niet een voor een doen (eerder per bundel met server, voorbeeld 25 per keer) maar FaceBook word ondersteunt op ruim 30.000 servers voor de 300 miljoen gebruikers met ongeveer 60 biljoen foto's en 25Tb data per dag.

Dus het is logisch dat ze het rustig opstarten en dan de gebruikers gecontroleerd laten inloggen, doe je dat niet dan krijg je met de wereldwijde gebruikers een flood op je servers met als gevolg dat alles er weer uit klapt.

*bron http://www.datacenterknowledge.com/archives/2009/10/13/facebook-now-has-30000-servers/

[Reactie gewijzigd door Verwijderd op 27 juli 2024 13:53]

[Verwijderd]

Die bron is al bijna een jaar oud. Ze hebben nu 500 miljoen leden (7% van de wereld bevolking), en zijn daarmee (als het een land was) het derde grootste land ter wereld, ruim boven de US, maar ver onder India en China.

[TWeaKLeGeND]

wss onder andere zoiets idd

[Tamarinde]

Had gister gezien dat 4chan van plan was een ddos uit te voeren.
Lijkt me sterk dat het een intern probleem was.

[Brantje]

4 chan zegt wel vaker wat, dus niet serieus nemen.

ontopic:

De enige manier om het probleem te herstellen bleek een herstart van het hele databasecluster te zijn, een proces dat ruim twee uur duurt.

Waarom duurt het rebooten van clusters altijd uren?
Ik loop al een tijdje met die vraag rond, alleen ben er nog niet achter waarom??!?!
Unix, Windows, MacOS, etc redden het allemaal netjes binnen 10 min.

Voor facebook moest dit wel erg balen zijn, helemaal omdat ze de inkomsten uit games en ads halen -> Site down -> No games and ads -> No Money .

Mooi voorbeeld van: Eerst intern testen en dan pas Live gaan.

[IStealYourGun]

Als het probleem zich maar op één server voordoet, dan moet je die maar rebooten en vaak gebeurt zoiets nog automatisch ook. Die server geeft zijn "werk" dan door aan andere servers en reboot rustig zonder dat iemand er last van heeft.

Het probleem hier was echter het werk zelf, waardoor bij een restart van een server, het probleem gewoon werd doorgeschoven en terugkeerde zodra de server was herstart.

Dus diende ze heel de DB-cluster plat te leggen en in het geval van Facebook spreken we van een enorme cluster die zich op verschillende locaties bevind en dus niet simpelweg uit en aan te zetten zijn. Meestal gebeurt dit in stappen om zo de synchronisatie te behouden en alles te balanceren van load. Vandaar dat men ook de bezoekers eventjes helemaal hebben afgesneden.

[Verwijderd]

Daar kunnen zoveel redenen voor zijn, maar uiteindelijk is het gewoon geld.

Het kan bijv. zijn dat ze niet alles tegelijkertijd kunnen laten booten, vanwege stroompieken. Het kan ook zijn dat de software extreem langzaam is (ik bedoel, ze gebruiken PHP, dus het zullen geen experts zijn die er werken).

[Memorice]

Een flink deel van het personeel van Facebook is afkomstig van Amerikaanse top universiteiten of zelfs weggekaapt bij bedrijven als Google, Microsoft, etc. De reden om bij Facebook te werken is dat je behalve een degelijk salaris ook aandelen krijgt in het bedrijf. Wanneer het bedrijf de markt op gaat (en je de aandelen kunt verkopen) zou je hier wel eens een leuk bedrag aan over kunnen houden. Maar goed, er werken dus een hoop top mensen.

De medewerkers bij Facebook weten heel goed dat php een hoop nadelen biedt en ze proberen hier oplossingen voor te vinden, waaronder bijv. HipHop. Het ontwikkelen van dergelijke oplossingen kost een hoop tijd en dus geld, maar dit is eenvoudiger dan de miljoenen regels php code van Facebook omzetten naar een andere taal.

Ooit (2004?) is Facebook klein begonnen als sociaal netwerk binnen een universiteit. Toen is het uitgebreid tot meerdere kleine sociale netwerken binnen verschillende universiteiten. Tot daar was php nog geen enkel probleem en zou je het zelfs een amateur project kunnen noemen, maar toen gingen ze deze kleine Facebooks aan elkaar koppelen en ontstond er een enorme groei. Het is dus niet zo dat bij het ontwerp van Facebook nagedacht is over de huidige omvang van de site, wel weet ik zeker dat als de keuze opnieuw gemaakt moest worden (met de huidige kennis, dus hoe groot Facebook zou worden), dat er zeker niet voor php gekozen zou zijn.

Overigens is het gehele systeem veel complexer dan de meeste andere sites, dergelijk omvangrijke sites draaien op grote clusters, welke voor problemen zorgen waar geen enkele amateur (en zelfs vele professionals) ooit mee te maken krijgen.

[Proxx]

waarom zou php niet gebruikt worden door experts ?

[Verwijderd]

Misschien omdat de PHP implementatie zelf crappy is, en vol met veiligheidslekken zit?

En misschien omdat de hoofdontwikkelaar van PHP het gewoon als een hobby had gemaakt en geen goede achtergrond heeft om iets goeds te maken?

Dat geeft hij overigens zelf toe, hoor.

PHP is gewoon een grote vergissing, maar je mag van mij best een ander idee erover hebben.

[YopY]

Misschien omdat de PHP implementatie zelf crappy is, en vol met veiligheidslekken zit?

Zoals? De veiligheidslekken die in PHP zitten zijn in 99% de schuld van de ontwikkelaars.

[mae-t.net]

Welke ontwikkelaars? Zoals jij het schrijft, die van PHP. Dat zal je echter vast niet bedoelen.

Overigens maakt PHP het inderdaad wel vrij simpel om onveilige software te schrijven. Met TCL gaat dat al wel wat beter, met Python geen ervaring maar zal vast goed zijn.

Door gebruik van TCL heb ik ook ervaring met modules, en dat is wel degelijk een sterk punt. Je kan dan eigen bibliotheken vooraf laden.

[Verwijderd]

Bedankt voor je uitleg maar vergeet niet dat zoveel talen (bijv Java) niet bedoeld waren om gigantische web apps te draaien.

[Proxx]

bedankt voor je uitleg maar moest dat nou met die toon

[Bert Gent]

En deze post wordt door de moderator als "ongewenst" beoordeelt?

Dat gaat vrij ver als je het mij vraagt!

[Kettrick]

Ga er maar vanuit dat de keuze voor PHP zeer bewust gemaakt is, dat is ook duidelijk te zien aan het feit dat ze zelf een PHP compiler hebben geschreven om het zaakje nog sneller te maken.

Daarnaast is het opstarten van een PHP webcluster zeer eenvoudig, het zijn immers gewoon scripts. Het opstarten van een tomcat of IIS instance zal ten aller tijde langer duren.

Ik ben overigens geen PHP fanboy, maar bovenstaande verhaal raakt kant nog wal

[Verwijderd]

Erm, mod_php draait "gewoon scripts".
Maar dat is niet wat FB doet. Dat draait in een app server.
Maar zeker weten dat de database veel belangrijker is. Ik bedoel stel je raakt data van je 500 miljoen leden kwijt...

[Verwijderd]

Waarom denk je dat ze een PHP compiler schrijven? Dat doen ze omdat de officiele PHP interpreter een grote fout is.

Dus, ze hebben gewoon niet eerst gekeken wat nu eigenlijk een taal is die een beetje fijn programmeert en technisch goed in elkaar zit. Dat noem ik niet 'zeer bewust', dat noem ik 'hey, PHP werkt best aardig en veel mensen gebruiken het, dus het zal wel goed zijn'.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 13:53]

[Xthemes.us]

Naast die prutsers van Facebook gebruiken ook die prutsers van Yahoo het, en zo nog meer van werelds grootste/meest bezochte sites die miljoenen requests per seconde krijgen te verwerken.

Maar goed, het blijft maar een prutstaaltje dat langzaam werkt, toch?

Het voordeel van PHP is hoe makkelijk het is om er mee te werken (alhoewel als je er goed mee wilt werken het al snel een stuk ingewikkelder word en dan eigenlijk ook weinig makkelijker is dan bijv. .aspx).

Als ik de top 10 van de meest bezochte sites op het web bekijk (volgens alexa) dan weet ik dat 3 van die sites PHP gebruiken (facebook, yahoo, wikipedia). Wel knap dat je het beter weet dan de mensen achter facebook (op een tweede plek achter google).

[Reactie gewijzigd door Xthemes.us op 27 juli 2024 13:53]

[Verwijderd]

Als ik de top 10 van de meest bezochte sites op het web bekijk (volgens alexa) dan weet ik dat 3 van die sites PHP gebruiken (facebook, yahoo, wikipedia)

7 van de 10 doen het heel verstandig dus niet. En dat is dus meer dan de helft.

[Xthemes.us]

Het is maar hoe je het bekijkt.. top 10:

• php: facebook/yahoo/wikipedia (3)
• aspx: live.com/msn.com (2)
• geen flauw idee: baidu.com/qq.com (2)
• ruby on rails: twitter (1)
• python: youtube(1)
• mix van C++/Java/Python: google.com (1)

Meeste keuzes zijn dus blijkbaar voor PHP gevallen en bij Microsoft is het enkel logisch dat ze voor apsx kiezen, staat natuurlijk niet bijzonder goed als ze niet hun eigen product gebruiken . Hoewel het merendeel van de PHP sites ook werkelijk prutssites zijn betekent dat niet automatisch dat elke php site gelijk staat aan gepruts.

Maar goed, ik zou eens moeten leren de "do not feed the trolls" borden te lezen waar er helaas steeds meer van lijken te verschijnen op tweakers.net.

[ontopic]
Zo blijkt maar weer, waar gewerkt wordt worden fouten gemaakt. Zelfs de grootste sites laten wel eens een steekje vallen waardoor alles plots op z'n gat ligt. Ben eigenlijk wel benieuwd naar wat zo'n grapje ze kost aan gemiste inkomsten.

[RMX]

Mag ik vragen welk alternatief jij zou aandragen?

IIS + ASP ¿

[Ali3nSt0rmz]

Dat vind ik veel beter werken in alle geval, en veel overzichtelijker (al is dat mijn persoonlijke mening).

Maar dat is ook maar waar je voor bent. Liefst heb ik bijvoorbeeld ook geen taal waar je case sensitive moet zijn. Dus geen java, javascript, php, ...

[st0p]

PHP is niet case sensitive. $foo->bar() is gelijk aan $foo->Bar(). Diep van binnen zou ik ook willen dat dat anders was, maar onder aan de streep maakr het geen fuck uit.

Los van het feit dat je dus niet weet waar je het over hebt, is het wel of niet case-sensitive zijn van een taal wel het laatste waar je je druk over moet maken bij de keuze voor een platform + ecosysteem.

[Pepperoni]

@Ali3nSt0rmz: Niet zo belangrijk maar java is wel degelijk case sensitive.

[.oisyn]

.
Ik deel je mening over PHP, maar iemand die in PHP ontwikkelt is niet meteen een amateur, en bovendien is het louter de front-end van facebook die op PHP draait. Daarnaast hebben ze intern ook gewoon aanpassingen gemaakt aan PHP. Lees bijvoorbeeld eens http://blog.facebook.com/blog.php?post=2223862130 en http://blog.facebook.com/blog.php?post=2356432130.

Some of our behind-the-scenes software is written in Python and Perl and Java, and we use gcc and Boost for the parts that aren't.

[Reactie gewijzigd door .oisyn op 27 juli 2024 13:53]

[SuperDre]

(ik bedoel, ze gebruiken PHP, dus het zullen geen experts zijn die er werken).

uhh, kun je een nog dommere uitspraak doen? Dan kun je ook net zo goed zeggen 'oh ze gebruiken javascript/ASP.NET/VBscript/whatever dus ze zullen geen experts zijn die er werken'..

maar iemand die bij zijn volle verstand is, gebruikt geen PHP.
begin dan eerst zelf maar eens een beetje verstand te krijgen.... want PHP is niet het probleem...

[SilentThunder]

Wacht even, dus sites die zijn gemaakt in PHP, worden allemaal door amateurs gebouwd?

[Verwijderd]

Dat heb je heel goed gezien. Er zijn vast mensen die wel degelijk verstand van zaken hebben en 'gedwongen' worden om het te gebruiken, maar iemand die bij zijn volle verstand is, gebruikt geen PHP.

[Ajunne]

Goed gezien. Voor een site als Facebook is PHP helemaal niet meer geschikt...

Voor een kleine site met een paar duizend bezoekers (iets zoals Tweakers.net bijvoorbeeld) kom je nog wel mooi met de amateurcombinatie LAMP weg, maar als je hondderduidenzden of zelfs miljoenen hits moet gaan verzorgen ga je toch wel moeten uitwijken naar een echte applicatieserver.

Facebook heeft het nu kunnen ondervangen door zelf een PHP compiler en applicatieserver te bouwen, maar ze hadden bijvoorbeeld ook de PHP implementatie van Caucho kunnen gebruiken (die keihard de vloer veegt met de standaardimplementatie) die in Java draait. Nog beter was zelf hun app te bouwen in Java en te draaien in Weblogic of Websphere. De originele PHP schaalt gewoonweg niet, punt.

Wat betreft het databasecluster, ik kan me wel voorstellen dat het even duurt om het geheel down en terug op te brengen, en ik vind 2,5 uur nog lang niet overdreven, al hebben ze hier natuurlijk wel een veiligheidsmarge ingebouwd.

Databases zijn op zich al zeer ingewikkelde beesten, ze zijn dan ook volledig verantwoordelijk voor de referentiële integriteit van de data, en dat terwijl ze miljoenen transacties te verwerken krijgen. Op één server is dat al een pak werk, maar op een cluster van servers (en ik kan me voorstellen dat in het geval van Facebook het tientallen servers betreft, verspreid over een hoop fysieke locaties) wordt het geheel meteen een aantal ordegroottes ingewikkelder. Servers moeten in een bepaalde volgorde op gebracht worden en er moet rekening gehouden worden met allerlei dependencies.

Al met al kan ik me voorstellen dat het een druk namiddagje geweest is bij Facebook. Een hoop engineers hebben flink mogen zweten om de boel weer op gang te brengen...

[Memorice]

Van tientallen servers mag je gerust honderden/duizenden maken...

[3dziggy]

FB -2009- 30.000 servers kijk: http://www.datacenterknow...ok-now-has-30000-servers/
edit: ik had nog niet verder gelezen, er zijn meer mensen die3 google gebruiken,...dit maakt mijn reactie redelijk overbodig

[Reactie gewijzigd door 3dziggy op 27 juli 2024 13:53]

[demonite]

ik heb 9 jaar terug een jaar gewerkt met bea weblogic en dat was toch echt by far het allertraagste product wat ik ooit heb gezien, geen idee hoe het nu is... maar toen had het, wat mij betreft, echt geen bestaansrecht en lifte puur mee op de applicatieserver hype. Het verbaast me dat dat nog bestaat.
Ik ben ook wel benieuwd naar dat Caucho, heb je toevallig een link naar een performance vergelijking tussen de std php en caucho?

[st0p]

O, dus vandaar dat wikipedia al een van de grootste sites op aarde is en op PHP draait?

[mzziol]

Op Wikipedia worden lang niet zoveel veranderingen per seconde aangebracht als op Facebook. Cachen wordt hierdoor een stuk eenvoudiger.

[st0p]

Cachen met memcached (veelvuldig ingezet door FB, maar ook door tweakers en mijn werkgever) is eenvoudig in een heleboel talen, waaronder PHP.

[RMX]

Haha Grappig..
Jij weet dus echt niet waarover je praat..

[mzziol]

Goed beargumenteerd!

Er zijn wel degelijk redenen om geen PHP te gebruiken (dit is vs. Python):

• Geen goede introspectie introspectie
• Een lelijke, onoverzichtelijke syntax
• Het is traag
• Geen namespaces
• Geen modules
• Het is niet object-georiënteerd. Tenminste, v5 probeert het, maar het is nog steeds niet goed geïmplementeerd
• Geen threading / PHP functies zijn vaak niet thread-safe
• Geen Unicode ondersteuning (standaard!)

Houd in het achterhoofd dat Facebook zelf een PHP compiler heeft geschreven. In Python schrijf je een module in "pure" Python en als het niet snel genoeg blijkt te zijn, port je het heel eenvoudig naar C.

[borft]

hmm ff kijken naar 5.3
- wel namespaces
- traagheid is relatief... voor simpele dingen is php veel sneller dan bv java, uiteindelijk blijft het natuurlijk wel een geinterpreteerde taal, maar traagheid is lijkt me meer een eigenschap van de interpreter dan van de taal zelf. Als je een compiler of zelfs een byte compiler voor php schrijft kan het prima snel zijn. Veel van de standaard functionaliteit zijn gewoon 1 op 1 ports van de C api.
- wel object georienteerd
- er is zeker wel threading (alhoewel het niet heel briljant werkt
- unicode werkt prima

hoe zit het eigenlijk met closures in python?


Afgezien daarvan ben ik het met je eens dat php de nodige problemen heeft... oa wat striktere typing staat vrij hoog op mijn verlanglijstje Maar als je echt het statement durft te maken dat de mensen achter facebook niet professioneel zijn omdat ze in php ontwikkelen, dan ben ik erg benieuwd aan wat voor grootschalige projecten jij al gewerkt hebt

[mzziol]

5.3 is nog niet uit, dus kan niet gebruikt worden in productie-omgevingen.
Excuus!

- wel object georienteerd

Maar zeer zwak geïmplementeerd, zoals ik al zei.

er is zeker wel threading

Maar je hebt er geen bal aan als de functie niet thread-safe zijn

hoe zit het eigenlijk met closures in python?

Lambda's!

Maar als je echt het statement durft te maken dat de mensen achter facebook niet professioneel zijn omdat ze in php ontwikkelen, dan ben ik erg benieuwd aan wat voor grootschalige projecten jij al gewerkt hebt

Dat beweerde ik niet, dat beweerde gang-ster. Ik denk dat de Facebook ontwikkelaars wel degelijk professioneel zijn; ik gaf alleen maar redenen om Python over PHP te kiezen.

Verder staat in mijn profiel wat ik doe (note: dat project is inderdaad niet bekend bij het grote publiek, het wordt gebruikt door universiteiten).

[Reactie gewijzigd door mzziol op 27 juli 2024 13:53]

[Verwijderd]

5.3.3 is al maanden uit?
source php.net

[.oisyn]

lambda's zijn geen closures. In een lambda kun je geen lokale variabelen gebruiken.

[st0p]

Ooh, en de GIL zorgt niet voor grote problemen in multithreaded python?

[Verwijderd]

Meestal vallen die problemen wel mee. De GIL helpt trouwens om bepaalde threading-problemen te versimpelen.

En er zijn natuurlijk ook minstens 2 of 3 Python-implementaties zonder GIL (het is geen onderdeel van de taal, wel van sommige implementaties).

[YopY]

Lekker onderbouwd...

Een lelijke, onoverzichtelijke syntax

Dat is persoonlijk.

Het is traag

Dat is relatief. Wat is traag? En hoe traag is het nadat ze het door hun inhouse ontwikkelde HipHop compiler?

Geen namespaces

welles

Geen modules

Wat versta je onder modules?

Geen threading / PHP functies zijn vaak niet thread-safe

Daar is het ook niet voor bedoeld. PHP scripts / 'programma's' zijn gemaakt om per request uit te voeren. Per request wordt er geen code of geheugen gedeeld. Threading is in het geval van PHP niet nodig, omdat de levensduur van een php applicatie exact gelijk is aan de levensduur van een request.

Bovenop PHP zelf zitten er bij Facebook en Tweakers.net lagen die de performance verbeteren (ik zeg niet dat de 'statelessheid' van PHP goed is voor de performance bij grotere applicaties), daar zit dan wel weer threading in. Maar PHP is slechts een laag in die applicaties.

In Python schrijf je een module in "pure" Python en als het niet snel genoeg blijkt te zijn, port je het heel eenvoudig naar C.

port moet compile zijn, neem ik aan? Aangezien C en Python nogal verschillen om het te 'porten'.

Je opmerkingen zijn hier en daar semi-correct, maar ruiken naar opzettelijk negatief en gebaseerd op achterhaalde problemen. Nee, PHP is niet geweldig en Python is in bepaalde gevallen 'beter' (als zoiets bestaat), maar je hoeft het ook niet de grond in te boren met overdrijvingen of achterhaalde zaken.

[SuperDre]

Goed beargumenteerd!

Er zijn wel degelijk redenen om geen PHP te gebruiken (dit is vs. Python):
•Geen goede introspectie introspectie
•Een lelijke, onoverzichtelijke syntax
•Het is traag
•Geen namespaces
•Geen modules
•Het is niet object-georiënteerd. Tenminste, v5 probeert het, maar het is nog steeds niet goed geïmplementeerd
•Geen threading / PHP functies zijn vaak niet thread-safe
•Geen Unicode ondersteuning (standaard!)
Houd in het achterhoofd dat Facebook zelf een PHP compiler heeft geschreven. In Python schrijf je een module in "pure" Python en als het niet snel genoeg blijkt te zijn, port je het heel eenvoudig naar C.


hoezo zit je hier weer ff je eigen voorkeur zonder zelf enige goede argumentatie..
Alsof de syntax van phython wel mooi is.... tja, jij komt niet met echte argumenten, maar met jouw voorkeuren...

[GamingZeUs]

Een van de belangrijkste dingen aan python is de syntax.
Zo belangrijk zelfs dat de syntaxt vaststaat, zodat je een gezonde manier van opmaken verplicht bent.
Ook is alles compleet ontworpen voor overzicht, helderheid en een minimale hoeveelheid karakters.
(indentatie ipv {} bijvoorbeeld.)


Dan kan je zeggen dat het een mening is dat overzicht mooi is, maar ik heb nog nooit van iemand gehoord dat hij het daar niet mee eens is.

[Sando]

Dat zijn vooral meningen en gedateerde feiten.

Betreft hetgeen nog overeind staat:

Met PHP kan je zo ver gaan als je wilt. Althans, ze hebben misschien niet te veel aandacht gevestigd op de extremen, maar CISC was ook patseriger in de complexe gebedieden dan RISC, maar toch heeft die laatste gewonnen in de computerevolutie omdat het helemaal niet nodig is te ingewikkeld te doen.

[CyBeR]

Haha Grappig..
Jij weet dus echt niet waarover je praat..

Hoewel ik denk dat 'ie dat niet persee weet is het wel degelijk zo dat Facebook voor een groot deel op PHP draait juist zodat ze geen ontzettende überspecialisten hoeven in te huren voor simpele dingen.

[IStealYourGun]

Vandaar dat er tal van grote bedrijven zijn die gebruik maken van die technologie. Al die mensen zijn gewoon niet bij hun volle verstand. -_-

Ik wil je gerust gelijk geven dat PHP qua veiligheid niet uitblinkt, maar als je daar rekening mee houd en er een mooie framework mee bouwt dan kan je daar zeer goede applicaties mee bouwen.

[Carharttguy]

Je kan er heel wat mooie dingen mee doen. Maar het is toch wat traag voor zo'n grote systemen.

Daarom dat FB ook HipHop gebruikt in plaats van pure PHP.

[YopY]

HipHop is pure PHP, alleen gecompiled naar assembler/y ivm performance.

Ja, ze konden ook gelijk in C oid gaan programmeren, maar dan moesten ze hun grote team developers omscholen (evenals nieuwe ontwikkelaars) en meer tijd besteden aan ontwikkelen.

[mddd]

Waarom duurt het rebooten van clusters altijd uren?

Ik ben geen cluster expert, maar het lijkt me dat je een hoop zaken weer op orde moet krijgen: zorgen dat allerlei data die in werkgeheugen staat weer netjes is geladen; zorgen dat caches weer worden opgebouwd; zorgen dat masters en slaves up to date met elkaar zijn. Zeg maar: alles wat je moet hebben om volledig operationeel te zijn.

Als je al die dingen nog niet helemaal klaar hebt (bijvoorbeeld: bepaalde caches zijn nog leeg) en je krijgt alweer een stapel requests binnen, dan gebruik je dus een niet-geoptimaliseerde database en heb je dikke kans dat het meteen allemaal weer vastloopt.

[L-VIS]

Ze hebben ruim 30.000 server. Nu weet ik niet hoeveel er in hun restart cluster zaten, maar er zijn genoeg redenen te bedenken waarom dat niet binnen 10 minuten kan. Dat wordt ook hierboven genoemd.
http://www.datacenterknow...ok-now-has-30000-servers/


Over het test. Ik denk dat het gewoon niet te testen was. Je kunt sommige dingen niet 1-op-1 testen in een testomgeving. Als jij duizenden servers in productie hebt, heb je waarschijnlijk geen acceptatie omgeving die ook uit duizenden servers bestaat. Maw, dit was zeer moeilijk om te voorkomen.

[Marcelloz]

waarom het uren duurt ipv 10 minuten?
Ik denk dat ze het nog snel doen met hun 100-en servers. Die kan je ook niet tegelijk laten booten, dat geeft een piek belasting. Zelfde met down brengen.

Verder wil je dat er genoeg handjes zijn om eventuele zaken te herstellen en om al die servers te monitoren.

[Wim-Bart]

Ligt aan type cluster, maar gezien het probleem kan het zijn dat er een integriteitscheck plaats moet vinden. En dat kan vreselijk lang duren.

Darnaast ligt het ook aan de database afmeting en de indexen. In dit geval zou een active-active cluster niet zo vreemd zijn, maar daarbij praat je dus al snel over 5 tot 10 minuten met een 200GB database. Dus 2,5 uur voor een paar TB is niet zo gek.

[-GSF-JohnDoe]

Alsof 4chan genoeg computers heeft on facebook plat te leggen

[Adanteh]

Ze wilden het doen, het is al een tijd geleden geprobeerd, zonder al te veel resultaat. Facebook heeft écht gigantisch veel servers draaien., iets waar ook 4chan weinig tegen in te brengen heeft. Overigens was 4chan al van plan om 19 augustus te DDOSen, en hier wist niemand iets van. Overigens begonnen wel 's avonds wat mensen plaatjes te posten en hun complimenten uit te spreken, maarja.. trolllllll

Maarja, de eerste 'major' site uit de lucht halen.... Dit is toch wel wat groter dan al die andere sites.. Dat is net zoiets als Youtube proberen uit de lucht te halen, dat gaat 'helaas' niet echt lukken..

[YopY]

Het zou wel mogelijk zijn denk ik, maar niet met dat handjevol 'anonymous' leden (waarvan 5% lid is en de andere 99.9% meeloper, wat 4chan eigenlijk is - imho). Ze zouden dan botnets moeten huren, en zelfs dan zou het maar moeilijk gaan lijkt me - kan me zo voorstellen dat facebook en youtube en dergelijke grote enorme sites zoveel overcapaciteit en bescherming hebben dat ze wel wat weerstaan kunnen. T.net testte een paar maanden terug ook een apparaat dat tegen veel DDOS aanvallen bescherming biedt, waarschijnlijk heeft facebook e.d. dat ook wel - en meer.

[Cronax]

Botnets huren? Die hoef je niet te huren hoor, die kosten niets, iedere onvoldoende beveiligde PC is vrijwel zeker onderdeel van een botnet...

[Perkele]

hmmm, 5% + 99.9 % = 104.9%

[Soldaatje]

De leden zijn ook meelopers.

[Verwijderd]

true.

Een site zoals netlog haal je er wel uit. Maar FB zou me toch verbazen. Het feit dat ze zichzelf de das omdeden maakt het best grappig

[Bonthouse]

Ga daar maar wel van uit. Zoek ondertussen ook maar eens naar de andere stunts van Anonymous.

[Verwijderd]

inderdaad. Sommige denken dat 4chan niets kan ... Zou niet de eerste major site die Anonymous neerlegt

Onlangs hadden ze zelfs plannen om netlog neer te halen ... (belgische gedeelte van 4channers dan toch )

[elmuerte]

inderdaad. Sommige denken dat 4chan niets kan ... Zou niet de eerste major site die Anonymous neerlegt

Welke is dan de eerste?

[Carharttguy]

offtopic:
Operation Titstorm?

Youtube porn day was niet het lamleggen van youtube, maar het had toch ook een lelijk effect.

Anon is groot, en veel machtiger dan meeste mensen doorhebben denk ik.

Overigens vraag ik mij af, hoe zo'n groot probleem kan voorkomen door 'gewoon' een instelling die fout was? Zitten er op zo'n instellingen dan geen iffen die de boel checken op tegenstrijdigheden enzo?

[DenHond]

heeft anonymus ook niet de site van scientology plat gekregen?

[Cronax]

Onder andere ja. Tussen de anonieme massa van 4chan zitten ook mensen die botnets tot hun beschikking hebben, dan gaat het hard hoor...

[Verwijderd]

Sommige denken dat 4chan niets kan
4Chan kan ook niets, een paar gebruikers maar het merendeel heeft een tutorial nodig van minimum 1600x1050 om te weten waar de klepel hangt. En ja dat kan je op alle manier interpreteren

[Verwijderd]

als ze het zeggen, waarom niet??

[IStealYourGun]

Cache blijft toch steeds een moeilijk punt binnen een netwerkomgeving. Als je het er teveel controle systemen insteekt, verlies je de snelheid en als je te weinig doet dan riskeer je een vuile cache?

Maar als ik het goed versta, dan bleek net het controle systeem voor problemen te zorgen? De ironie.

[Brantje]

Ja staat in het artikel:

Na een wijziging in een van de instellingen dacht het controlesysteem dat het om een foute waarde ging, waarna het systeem probeerde in te grijpen en de problemen pas echt begonnen.

"De bedoeling van het automatische systeem is om ongeldige waarden in de cache op te sporen en deze te vervangen door de nieuwe waarde", aldus Johnson. "Dit werkt prima voor een losstaand probleem met de cache, maar werkt niet als de persistant store niet klopt."

Maar idd cache is idd moeilijk, ik moet regelmatig de cache van me WP instalatie legen, anders stroomt de hardeschijf in no time over, maar gelukkig zijn er al wel wat plugins die dit kunnen beheren.

Note: Mijn WP site is bij lange na niet zo groot als Facebook

[YopY]

Je WP cache stinkt, . Misschien zou je over moeten stappen naar een ander systeem dat zijn eigen cache in de gaten houdt.

[the_stickie]

Het controlesysteem verving de "foute" (ongekende) waarde door de waarde in het zeker-goed-bestand, maar dat bestand bevatte dezelfde waarde. Omdat elke clusternode die check uitvoert, probeerde elke clusternode keer op keer de correctie te doen; gevolg is dat de databaseserver niet meer kon volgen.
Ergens is er toch wat fout geîmplementeerd als het zeker-goed-bestand blijkbaar niet overeenstemde met de waardes die gebruikt werden voor de check!

[biert1982]

Facebook is vaker negatief (privacy) in het nieuws als positief. Het feit dat er nu ook problemen zijn met de bereikbaarheid van de site is natuurlijk geen goed nieuws.

Door de grote van Facebook zullen ze hier wel tegen bestand zijn voor de korte termijn, maar vraag me wel af als er andere alternatieven zich verder ontwikkelen of mensen dan niet gaan overstappen.

[mddd]

Alsof de gemiddelde tiener er wakker van ligt dat die site 2 uur niet bereikbaar is geweest.
Ik denk dat dit 0,0 effect heeft. Gebruikers van deze site maken echt niet de afweging "welke vriendensite zal ik gebruiken, hm.. Facebook heeft minder uptime garantie"..

Als er een andere site gebruikers van Facebook af gaat pakken dan is dat gewoon omdat Facebook niet meer hip meer is.

[YopY]

Facebook is vaker negatief (privacy) in het nieuws als positief. Het feit dat er nu ook problemen zijn met de bereikbaarheid van de site is natuurlijk geen goed nieuws.

Het feit dat het één van de populairste sites van het internet is (en al jaren), ongeacht het negatieve nieuws, zegt al dat dat niet zo'n groot effect heeft. Facebook heeft de andere alternatieven immers al verslagen - het ging voorbij aan bijvoorbeeld Myspace, dat voorheen de grootste social network site was.

[Vinnybinny]

PHP is zeker geen brakke programmeertaal. Het is begonnen als simpel avond programmeertaal, maar uitgegroeid tot een professionele grote taal. Python is ook zo´n voorbeeld, geloof ik gestart in de jaren 90 met geen directe boodschap, is nu de grootste programmeertaal achter Google.

Vroeger was PHP inderdaad nog in kinderschoenen, maar sinds PHP5 mogen we echt spreken van een volwassen programmeertaal. Argument dat iedereen het gebruikt is natuurlijk onzinnig, maar er is geen enkele rede waarom een als amateuristisch begonnen programmeertaal nu opeens `crappy´ is. Bovendien beginnen 99 van de 100 bedrijven het gewoon als een leuk avondproject, denk bijv. aan Google (Larry Page & Sergey Brin) die in 1997 in een garage een project startte dat uitgegroeid is tot het grootste internetbedrijf ter wereld.

Zie zo'n storing even als een plotselinge uitval van Outlook, alles moet opnieuw gecached en geïndexeerd/gerepareerd worden, bovendien gaat het hier om meer dan een paar gigabyte aan data.

[Reactie gewijzigd door Vinnybinny op 27 juli 2024 13:53]

[BumEyes]

Of PHP een brakke programmeertaal is is natuurlijk hartstikke subjectief.

Het is in ieder geval wel zo dat PHP gigantisch veel rare kleine dingen heeft die gewoon slecht ontworpen zijn. Ze hebben zeker wel grote stappen gemaakt met PHP5 maar veel dingen blijven altijd een beetje aanklooien.

Als je klein begint gebruik je gewoon een taal die je kent en dat is voor veel mensen PHP.

[hackerhater]

Het klopt dat er designfouten in PHP zitten die ze stapje voor stapje op het lossen zijn
Ze kunnen simpelweg niet alles in 1 keer fixen omdat je dan bijna alle bestaande implementaties sloopt

[YopY]

Het ging een tijdje de goede kant op met PHP sinds 5, echter het lijkt er steeds meer op dat de taal een stille dood gaat sterven. PHP 6 is voor onbepaalde tijd uitgesteld (of zoiets), en ik heb maar van knap weinig ontwikkelingen gehoord de laatste tijd / jaren.

[Tarabass]

PHP is geen programmeertaal, maar een scripttaal. En dat Python het meest gebruikt wordt door Google durf ik te betwijfelen. Zeker als je gewerkt hebt met java icm gwt zal die twijfel ook bij jou moeten toenemen

Maar dit probleem heeft weinig met de taal die gebruikt wordt te maken mijns inziens, maar meer met de architectuur van het gehele systeem. Of je nou vanuit php queries blijft afschieten op een mysql of sqlserver, of dit doet vanuit .net, java of een andere taal, de database zal plat gaan.

[hackerhater]

Sinds versie 5 is het een programmeertaal (haalt turingtest ed)
Ervoor was het een scripttaal inderdaad

[Verwijderd]

Je kan natuurlijk ook Python gebruiken icm GWT... ;-)

Maar wat betreft python gebruik bij Google:
- YouTube
- Google Groups
- onderdelen van GMail
- onderdelen van de zoekmachine (o.a. van de spiders)
- ... (vermoedelijk nog een hoop dingen waarvan ik het niet weet)

En er zijn zo nog wel een aantal onderdelen.
Verder gebruiken ze o.a. ook C++, Java en zelfs .NET vziw.

[hdv111]

het is ook mogelijk dat er dataverlies is ontstaan

bron: de telegraaf
Ook heeft het bedrijf laten weten dat het mogelijk is dat informatie die in de dagen voor de storing was toegevoegd, verloren is gegaan. De schade zou echter minimaal zijn.

[Tha_Butcha]

(ik bedoel, ze gebruiken PHP, dus het zullen geen experts zijn die er werken).

Je weet waar de site, waar je nu op post, voor een groot gedeelte in is gebouwd toch?

En dan nog, als jij een site begint, dan ram je toch ook niet gelijk een stel octacore servers met 16GB neer en gaat aan de gang met tomcat omdat in de toekomst - mocht je site heel toevallig een van de grootste sites van de wereld worden - je de snelste taal wilt hebben, en je 100.000'en queries per sec. krijgt?

PHP is niet ideaal nee, maar dat kan je ook van mysql zeggen (kom maar op met het geflame), maar als je begint met je eigen (hobby)site is dat een ver van je bed show.

En ja, het klopt dat PHP ruimte biedt voor smerig programmeren; het is zo'n beetje een publiek geheim dat de code van hyves nou niet optimaal is. Al moet ik wel zeggen dat ze flink wat verbeterd zijn tegenwoordig.

[YopY]

Gelukkig is smerig programmeren één feature die alle programmeertalen delen, .

[Ruzz321]

24 september 2010, dag van de storingen? Zie ook de pinstoringen van eerder vandaag

[grol4]

En weten we nog van de twitter-storing op de 22e?

[TheFes]

Donderdag was het nog 23 september.

[enveekaa]

"Facebook heeft donderdag te kampen gehad....."

[Malantur]

Dat de facebook storing op donderdag 23 september was en de pin storing vrijdag 24 september is.

[codeneos]

Dat de storing op donderdag was, zoals in het artikel vermeld staat. Dus klopt de opmerking: "24 september 2010, dag van de storingen" niet.

Lastig hé lezen .

[Gerardus]

voor sommige mensen kan het inderdaad lastig zijn. die lezen te snel, in de toekomst dus.

[Zidane007nl]

Ik dacht gister al dat er iets aan de hand was met FB, Ik kreeg een DNS error.

[Sand0rf]

Facebook is bij mij al langere tijd minder goed bereikbaar...

[engessa]

Wait, what? Facebook is echt heel iets anders dan Hotmail dus ik kan echt de link niet leggen tussen een downtime op Facebook en een Hotmailaccount dat gehacked is..

[HMS]

Misschien had ie de hele authentication chain, wachtwoorden, usernames en IP-addressen van het cache controle systeem in zijn hotmail account staan.

[Reactie gewijzigd door HMS op 27 juli 2024 13:53]

[YopY]

Zou waarschijnlijk niet de eerste keer zijn, .

[Gerardus]

dat lijkt me vrij onlogish, alleen omdat er "het woord "DDOS" in het stuk staat denk je van o help hackers ik ben gehackt. Facebook zal je niet kunnen hacken, waarschijnlijk had iemand er al toegang toe.

lijtk me verstandig om je pc te scannen en dan je ww te veranderen.