Google maakt details over datacentra bekend

Tijdens de Google I/O-bijeenkomst gunde Google de aanwezigen een kijkje in de keuken van zijn datacentra. De huis-tuin-en-keukenhardware in de datacentra mag kapot: de software houdt de diensten van het bedrijf draaiende.

Wat zich binnen de datacentra afspeelt, wordt door de zoekgigant gewoonlijk angstvallig geheim gehouden. Slechts mondjesmaat brengt het bedrijf details naar buiten over de hardware en software die de diverse diensten van Google draaiende houden. Dat het bedrijf standaardhardware in zijn servers gebruikt en het Google File System draait mag als bekend verondersteld worden, maar op veel vlakken zijn de locaties met geheimzinnigheid omgeven. Jeff Dean, wetenschappelijk onderzoeker bij Google en medeverantwoordelijk voor de datacentrumsoftware, lichtte tijdens Google I/O een tipje van de sluier op wat betreft de datacentra, schrijft Cnet.

De verschillende datalocaties van Google zijn opgebouwd uit clusters die weer opgebouwd zijn uit racks. Elk rack bevat weer veertig servers en elke server heeft vaak meerdere cores. De hardware, hoewel standaard, wordt door Intel op aangepaste printplaten geleverd en elk rack van veertig servers wordt in een door Google ontworpen behuizing geplaatst. De hardware is, zeker vergeleken met gespecialiseerde servers, goedkoop en makkelijk te vervangen. Dat mag ook wel, aangezien per cluster jaarlijks zo'n duizend pc's uitvallen en duizenden harde schijven de geest geven.

Ook hele racks kunnen de geest geven en de energievoorziening kan kapot gaan, waardoor honderden computers uit het cluster vallen. Ook netwerkproblemen en oververhitting zijn factoren die voor plotselinge uitval van machines zorgen, wat de noodzaak voor redundantie groot maakt. Op softwaregebied zorgt het eigen besturingssysteem van Google voor het omgaan met uitval: Google File System draait op ruim tweehonderd clusters en zorgt onder meer voor het wegschrijven van data. Elk blok van 64MB wordt op ten minste drie pc's, zogenoemde chunkservers, weggeschreven, terwijl een master server bijhoudt waar de data terecht komt.

Twee andere Google-eigen applicaties structureren de data binnen de datacentra: Big Table fungeert als database en Map Reduce voert queries uit. De databasesoftware werd in 2004 door Google ontwikkeld en deze applicatie beheert data voor onder meer het zoeken, Google Earth en Maps en Blogger. De grootste database die de software in beheer heeft is ongeveer 6 petabyte groot. Om met dergelijk grote databases overweg te kunnen, gebruikt Google het eveneens zelfgeschreven Map Reduce. Het gebruik van het in 2003 geschreven programma neemt al jaren toe, en momenteel worden zo'n honderdduizend queries per dag uitgevoerd, die ieder op ongeveer vierhonderd servers draaien.

De volgende stap die Google wil maken is het verder decentraliseren van data. Nu al is het systeem dat het bedrijf op zijn servers gebruikt dermate robuust dat een cluster van achttienhonderd computers een uitval van zestienhonderd systemen kan overleven, maar de apparaten zijn per datacentrum geordend. De toekomstige infrastructuur van Google zou globaal moeten functioneren, zodat onderscheid tussen verschillende datacentra weg valt.

Reacties (76)

[Verwijderd]

Het zou fijn zijn als ze hun clustering techniek eens gingen licenseren/verkopen aan andere bedrijven. Goed werkende clustering software is nooit weg.

maarja, ze zullen zo wel meer verdienen dan met licenties verkopen vermoed ik zo.

[Verwijderd]

Ik vraag me af of er wel zo veel applicaties zijn waarvoor Googles clustering goed werkt...

Vergeet niet dat Google in principe een uiterst simpele taak heeft. Het gaat om stationaire data, die alleen uitgelezen wordt, en niet door klanten wordt ge-update.
Je doet immers alleen zoekacties, maar geen schrijfacties.

Als er eens deel uitvalt, is het geen probleem als het een beetje langzamer gaat. De meeste klanten zullen het zelfs niet merken als een deel van de database niet of nauwelijks toegankelijk is... Dan vindt je niet wat je zoekt... maar je wist bij voorbaat i.h.a. niet of het er uberhaupt was, dus je zult ook niet klagen.

Backup kan ook relatief simpel worden gehouden, aangezien heel veel data op de systemen hetzelfde is.

Vrijwel iedere andere database is ingewikkelder.... Natuurlijk, Google heeft fantastisch geoptimaliseerd voor hun specifieke toepassing. Maar dat is wel een uiterst smalle toepassing.

[JortK]

Dat gaat waarschijnlijk niet gebeuren als je ziet hoeveel tijd en geld Google erin heeft gestoken om dit te ontwikkelen.

Ik denk dat ze te bang zijn dat dan de concurrenten met de technologie aan de haal gaan, terwijl juist deze technologie Google zoveel voorsprong geeft

[mjtdevries]

Goeie kans dat die techniek alleen maar efficient is voor internet search engines.

Zou me niet verbazen dat het zodanig specialistisch is, dat het niet lonend is voor andere soorten clustered applicaties.

[al-ahlex]

Hier zijn ze sinds een maand of wat dus wel mee bezig, ze geven het momenteel zelfs gratis weg. Dit onder de naam "Google App Engine". Op dit moment draait het nog enkel Python (web)applicaties, maar doet dit automatisch op een clustered manier, en ook de database die je erbij krijgt is clustered (deze is geloof ik ook gebaseerd op BigTable).

[Coju]

App Engine is niet bepaald het verkopen of weggeven van de techniek. Ze geven processorkracht, bandbreedte etc. weg maar niet de techniek die achter de clusters van Google zit. Het lijkt meer op wat Amazon doet met de verkoop van processorkracht.

[Verwijderd]

Het gebruik van het in 2003 geschreven programma neemt al jaren toe, en momenteel worden zo'n honderdduizend queries per dag uitgevoerd, die ieder op ongeveer vierhonderd servers draaien.

Het lijkt massief, maar volgens mij is dat een grote fout en moet per uur of minuut zijn (of het is PER server, waardoor het totaal van 40 miljoen queries per dag iets beter overeenkomt met een site zoals google.com).

Ik heb namelijk één server draaien (Core2Duo 2.33Ghz / 4GB) met een sociaal-netwerk site met rond de 100k gebruikers, wat in verhouding tot Google natuurlijk een druppel in de oceaan is, maar toch draait die gemiddeld 300 queries per seconden, oftewel bijna 26 miljoen queries per dag (via \s rapport in mysql shell = Queries per second avg: 314.622).

[edit]: Ok, het oorspronkelijke verhaal geeft een ander beeld, waarbij de 100000 MapReduce queries per dag wel kloppen. Het heeft namelijk niks te maken met de queries die nodig zijn om google.com te laten functioneren, maar meer met vinden van relationele overeenkomsten (het profileren van data voor marketing redenen waarschijnlijk)

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:27]

[MSalters]

Map Reduce wordt overal in Google gebruikt. Ook voor de search. Ja, niet voor elke zoekopdracht die jij ingeeft, maar wel voor het spideren van het web. Dat geeft natuurlijk een heleboel pagina's per dag. Daar moeten woorden in gevonden worden, en alles moet geïndexeerd worden.

[ShadyNetworker]

Zou het op de lange termijn niet makkelijker en efficienter zijn voor Google om hardware te gebruiken die minder snel stukgaat? Als ik dit artiekel lees komt het datacenter nogal simpel over, al zal dat niet zo zijn

[Rob Coops]

Natuurlijk zou dat handig zijn maar dat maken "ze", Intel, AMD enzo, nu eenmaal niet. Vergeet niet dat Google huis tuin en keuken machines gebruikt, ok zelf ontworpen board en een eigen OS, in een eigen kast maar de core is gewoon het zelfde systeem als wat jij en ik onder of op ons tafeltje hebben staan.
Dat soort spul gaat nu eenmaal sneller stuk, probeer maar eens een flinke disk array te bouwen uit SAS en uit standaard SATA schijven, een paar maanden full load en de eerste SATA schijf is waarschijnlijk al dood, waar SAS gewoon langer draait. En NEE dat heeft niets met de interface te maken maar met de build quality en de gebruikte componenten, SAS schijven zijn een stuk duurder en dat is niet omdat dat nu eenmaal leuk is voor de maker maar gewoon omdat ze duurder zijn om te maken.

Google kan overschakelen op duur spul natuurlijk maar volgens hun berekeningen zijn ze dan zo veel duurer uit, dat het verlies van een paar hondered schijven per dag gewoon weg goedkoper is dan de duure spullen aanschafen en enkele tientalen te ver liezen per dag.
Voor zo ver ik weet kunnen ze bij Google redelijk goed rekenen dus ik denk dat ze vast wel gelijk hebben. En zo niet dan vind intel dat vast niet zo erg, ze verdienen er goed aan, net als de leverancier van hun andere hardware.

[mjtdevries]

Dat soort spul gaat nu eenmaal sneller stuk, probeer maar eens een flinke disk array te bouwen uit SAS en uit standaard SATA schijven, een paar maanden full load en de eerste SATA schijf is waarschijnlijk al dood, waar SAS gewoon langer draait.

In de praktijk blijkt dat niet waar te zijn.
Google heeft bv cijfers dat SATA schijven amper minder betrouwbaar zijn en er zijn al vele andere studies die dat bevestigen.

Helaas zit ik onder een NDA, maar ik ben als klant betrokken bij de ontwikkeling van een zeer bekende enterprise applicatie, waarbij men zich nu volledig richt op SATA voor de opslag. (terwijl men voor die klasse applicaties tot nu toe gericht was op dure SANs) Dat product moet over ongeveer anderhalf jaar op de markt komen.

SAS en SCSI schijven zijn voor een belangrijk deel duurder, omdat de enterprise markt bereid is er zoveel meer voor te betalen.

Dat zie je heel veel terugkomen. Voor dat soort zaken wordt zelden echt goed gekeken hoe goed de prijs/prestatie verhouding is. (Als het je eigen geld is doe je dat harder, maar als je het bedrijf een smak geld bespaard dan wordt je er persoonlijk zelden beter van)

[mae-t.net]

Met het verdwijnen van Maxtor uit de markt heb je op zich meer gelijk dan voorheen, maar ik heb nog steeds zo m'n bedenkingen: Ook van andere merken heb ik wel desktopschijven uit zien vallen in servers. Op dit moment zijn we in de hoop op vermindering van de hoeveelheid onderhoud over aan het stappen van consumenten-SATA schijven naar RAID-optimised en near-line-storage SATA modellen. Op papier zien deze er toch echt een stuk betrouwbaarder uit, maar de veiligheidsmaatregelen en redundantie die we bij consumentenschijven altijd in acht namen blijft voor de zekerheid nog wel van kracht.

edit: ja, RAID gebruikten we altijd al, maar nu ook met schijftypes die daarvoor gemaakt zijn (andere firmware, maar eventueel ook mechanisch anders)

[Reactie gewijzigd door mae-t.net op 22 juli 2024 19:27]

[mjtdevries]

Bij SCSI schijven moet je net zo hard Raid arrays gebruiken.

En je wilt niet weten hoeveel schijven er in onze SANs per jaar kapot gaan. Daar schrik je echt van.

Dat schijven in servers stuk gaan is gewoon een gegeven. En daar heb je dan raid arrays voor om je tegen te beschermen.

Uiteindelijk wordt het dan een kosten/baten analyse. Hoeveel meer SATA schijven gaan er stuk, en hoeveel minder kosten ze.
Ook performance verschillen kun je in belangrijkte mate opheffen door gewoon meer disks in je array te stoppen. (is uiteindelijk ook het principe van een SAN)


Op zich is een schijf die continu aan staat in een nette serverruimte een heel gunstig scenario voor een schijf.
Temperatuurschommelingen en stop-starts zijn voor een schijf zeker zo schadelijk als continue operatie. Zo raar is het dan ook eigenlijk niet dat een desktop schijf in een server het stukken beter doet dan verwacht.

[Mbyte]

En dan kijken we bij WD en Seagate en dan zien we dat van een SAS schijf en een SATA schijf de mean time between failures (MTBF) niet heel erg veel uit elkaar liggen. Bij seagate is het minder dan factor 2, WD heeft zelfs sata's met een MTBF die maar iets lager ligt dan die van een SAS schijf.

En aangezien de bouwer twee van zijn eigen producten test kunnen we aannemen dat ze niet de behoefte hebben om er een voor te trekken. Ergo: Goedkoop is niet altijd duurkoop.

[Reactie gewijzigd door Mbyte op 22 juli 2024 19:27]

[mjtdevries]

Pas op!
Dat de MTBF hetzelfde is, zegt nog niet veel.
Het gaat er om dat de omstandigheden waaronder ze zijn getest ook gelijk zijn.


Zo kun je een MTBF berekenen voor een schijf die 24/7 bezig is in een serverruimte bij een constante temperatuur.

Je kan ook een MTBF berekening doen voor een (desktop) schijf die 8 uur per dag actief en vervolgens 16 uur afkoelt.

In beide getallen krijg je een getal voor MTBF, maar je zult begrijpen dat die getallen niet met elkaar te vergelijken zijn.

Meestal moet je bij een SATA schijf er vanuit gaan dat de MTBF berekening is uitgevoerd voor "typical operation conditions". M.a.w. desktop en geen 24/7
Indien een SATA schijf wel specifiek voor 24/7 ontworpen en/of getest is, dan staat dat er meestal duidelijk bij vermeld.

[Denni]

Ik kan uit ervaring spreken dat je toch echt beter een fatsoenlijke HDD in je server kunt stoppen. Ik heb 2 servers; 1 heb ik gekocht met een 250 gb maxtor erin. 1 heb ik gekocht met een 74 gb raptor erin. De eerste server moest al na 6 maanden vervangen worden door een crash. Toen heb ik er weer een 250 gb schijf in laten stoppen maar na 6 maanden begaf die het ook alweer. Toen nog een raptor geprobeert(omdat die nog niet gecrashed was, nu nog niet gelukkig:)) en hopenlijk kan ik binnenkort zeggen dat deze nog steeds werkt:)

The point: Voor servers is een kwaliteitsschijf toch wel gewenst.

[Verwijderd]

Eén ervaring is natuurlijk bij lange na niet representatief. Bovendien ben ik ervan overtuigd, dat ze bij Google alle beschikbare mogelijkheden tegen elkaar afgewogen hebben, en ze voor de beste optie gekozen hebben in hun situatie. Zij kennen die uiteraard als geen ander

[Coju]

Albert Heijn hoeft ook (haast) geen onafhankelijke prijsonderzoeken te doen om te kijken naar het gedrag van de consument en prijselasticiteiten etc. Ze doen constant onderzoek door te kijken naar de verkopen van hun producten. Hetzelfde geldt voor Google, ze hebben zoveel servers dat ze statistiek op het falen ervan kunnen loslaten en zodoende de beste afweging tussen prijs en kwaliteit kunnen maken.

[Phu]

lol je hebt 2 server en ervaring
wij een heel park van 200 heb ik dan meer ervaring ?

[mvdejong]

Bij bijv. Seagate zijn over het algemeen van eenzelfde schijf IDE, SATA en SAS (enz., enz., enz.) uitvoeringen verkrijgbaar, alleen de controller-kaart verschilt, en dan alleen nog maar de bus-gerelateerde hardware en de firmware.

Het prijs-verschil zit in de aantallen die van bepaalde typen worden gemaakt, er was een tijd dat voor de schijven met grote capaciteiten (ik praat dan over 500-1000 MByte) een SCSI-schijf maar een paar tientjes duurder was dan dezelfde schijf in IDE-uitvoering (omdat de SCSI-schijf voor servers werd gebruikt, en de IDE-schijf voor werk-stations). Toen ook voor servers IDE werd ingezet, daalden de prijzen van SCSI-uitvoeringen veel minder snel dan die van de IDE-uitvoeringen.

[mae-t.net]

En dat is ook logisch, want er zijn zo een paar belangrijke verschillen in hardware aan te wijzen. Zo zijn bij serverschijven soms de platters kleiner, het toerental hoger, de lagering beter, de constructie minder slijtgevoelig, en dan heb ik het nog niet over optimalisaties in de firmware die natuurlijk ook ontwikkelkosten met zich meebrengen.

[latka]

Kan me nog een artikel herinneren over HDs die google onderzocht. Vooral de conclusies waren alleraardigst en wezen er niet op dat SATA nou zou erg slecht zou zijn. Heeft natuurlijk ook een hoog 'cover your ass' gehalte: als de schijven knallen in de server en je zegt tegen de baas dat je even nieuwe schijven bij de computerboer op de hoek gaat halen klinkt lang niet zo goed als dat je even een incident bij HP moet melden met hoge prio waarna er een consultant langskomt met een nieuwe schijf..

[Emielio]

Ik heb liever 2 budget servers waar alles door blijft draaien als er 1 crashed dan 1 dure server die welliswaar niet zo snel crashed maar als die crashed wel alles onderuit haalt. En in dure servers is veel redunant uitgevoerd, maar lang niet alles, een moederbord is altijd een kritiek onderdeel.

[Denni]

Bij 2 servers zit het misschien zo. Bij meer dan 2 niet meer.
Ik heb liever 2 dure servers die 99,95% draaien dan 4 goedkope servers die 99% halen, maar dan ook nog natuurlijk trager zijn. Mocht er iets kapot gaan moet je er weer personeel op afsturen wat dus ook nog eens gauw 100€/h kan kosten. Dan weer nieuwe onderdelen erin en je bent in het totaal 400+€ per crash armer. En dit gebeurt nogal vaak bij vooral budget-hardeschijven. Tevens moet je dan ook alles kopieeren op een 2e harde schijf. En als dat al niet meer kan dan ben je dus erg veel gegevens kwijt(en dan krijg je misschien weer schadeclaims etc.). Dus zo simpel is het niet..

[ritsjoena]

Mocht er iets kapot gaan moet je er weer personeel op afsturen wat dus ook nog eens gauw 100€/h kan kosten. Dan weer nieuwe onderdelen erin en je bent in het totaal 400+€ per crash armer. En dit gebeurt nogal vaak bij vooral budget-hardeschijven. Tevens moet je dan ook alles kopieeren op een 2e harde schijf. En als dat al niet meer kan dan ben je dus erg veel gegevens kwijt(en dan krijg je misschien weer schadeclaims etc.). Dus zo simpel is het niet..

Je denkt toch niet dat ze voor elke crash iemand moeten sturen? En dat die de hele schijf moet kopieren? Ze hebben er gewoon mensen rondlopen die gewoon alle onderdelen vervangen die aangeven stuk te zijn en dat de hele dag door. Het zal waarschijnlijk zo uitgevoerd zijn dat het vervangen van bv een schijf niet meer dan een paar minuten kost (ze hebben niet voor niets eigen ontwerp kasten). Misschien zelfs minder. Alles is redundant uitgevoerd dus het kopieren kan volautomatisch van 1 van de andere schijven. Daar zorgt de centrale aanstuurserver wel voor.

€10,-/crash bovenop materiaalkosten lijkt me dus meer in de richting komen.

[Reactie gewijzigd door ritsjoena op 22 juli 2024 19:27]

[Denni]

€10,-/crash bovenop materiaalkosten lijkt me dus meer in de richting komen.

En die mannetjes die de servers onderhouden doen dit gratis? Tevens moet je de servers laten monitoren. En je moet een ervaren(= duur) iemand in dienst hebben die meteen weet wat het probleem is.

Alles is redundant uitgevoerd dus het kopieren kan volautomatisch van 1 van de andere schijven.

Ja maar wat als de hdd nou écht kapot is(kunt er dus ook niet meer van lezen). Daarom hebben ze nu per 2 server 16 extra servers voor de zekerheid nodig. Met kwaliteitsproducten had je misschien 6 extra servers nodig gehad. Minder stroom, minder grond(= minder kosten), minder om te laten nakijken(= minder uurloon en minder server power van master server nodig), minder mensen nodig die de boel kunnen repareren(= minder uurloon). Ik weet niet zeker of dit voor een groot bedrijf als google de beste manier is. Maar dat zullen ze zelf moeten zien

[ritsjoena]

[...]

En die mannetjes die de servers onderhouden doen dit gratis? Tevens moet je de servers laten monitoren. En je moet een ervaren(= duur) iemand in dienst hebben die meteen weet wat het probleem is.

Die €10,-/crash is een schatting inclusief arbeidskosten. Vergeet niet dat er hier voordeel getrokken wordt uit schaalgrootte en automatisering. De arbeidskracht kan makkelijk 10 en waarschijnlijk zelfs tientallen schijven per uur vervangen.

[...]

Ja maar wat als de hdd nou écht kapot is(kunt er dus ook niet meer van lezen).

Er wordt gekopieerd vanaf een andere schijf, waar dezelfde data op staat als op de kapotte schijf. De kapotte schijf kan in principe direct de prullenbak in en hoeft niet meer te worden gebuikt. Er zouden alleen problemen ontstaan als alle drie de schijven met data X tegelijk kapot gaan. Nu ik eraan denk zal het waarschijnlijk zelfs zo zijn dat er reserve-schijven draaien die de rol van de kapotte schijf over kunnen nemen, zodra deze kapot is.

Daarom hebben ze nu per 2 server 16 extra servers voor de zekerheid nodig. Met kwaliteitsproducten had je misschien 6 extra servers nodig gehad. Minder stroom, minder grond(= minder kosten), minder om te laten nakijken(= minder uurloon en minder server power van master server nodig), minder mensen nodig die de boel kunnen repareren(= minder uurloon). Ik weet niet zeker of dit voor een groot bedrijf als google de beste manier is. Maar dat zullen ze zelf moeten zien

Voor kleine installaties heb je gelijk. Dan is het minder snel stuk gaan voordeliger dan de arbeidsloon. Zeker omdat je de arbeid minder efficient kan inzetten. Echter op deze schaal kun je de arbeid wel efficient inzetten en wordt het dus per schijf goedkoper. Als er dagelijks honderden schijven kapotgaan moeten er vele duizenden schijven in het systeem zitten.

Verder denk ik niet dat de schijven echt gerepareerd worden. Hooguit wat automatische basis-tests. De rest beland denk ik bij het afval.

Nogmaals deze strategie werkt dankzij de schaalgrootte.

[mae-t.net]

Die mannetjes die de servers onderhouden zouden volgens degene waar je op reageert ongeveer 10 euro per crash kosten. Ik vind dat nog niet eens zo'n vreemde schatting, maar ook als het ietsjes meer is, loont het best op die manier.

Verder heb je het over "laten monitoren", het lijkt me voordehandliggend dat een monitorfunctie in Google-OS zit ingebouwd en een monteur dus in 1 oogopslag kan zien welke computers hij op zijn ronde langs moet gaan.

[latka]

Ik heb ooit getallen gehoord van de aantallen servers waar google mee werkt. Volgens de wikipedia momenteel zo'n 450.000. Standaard PC prijsje is dan zo'n 300 euri (consumenten verkoopprijs, niet inkoopprijs!) tegen een echte server (zeg een Dell PowerEdge 1950 met dubbele voeding en raid5, UPS en andere zut om het maar betrouwbaar te maken). Die kost dan zo'n 6000 euri. Heb je je in je oneindige wijsheid zojuist 2,5 miljard euro over de balk gesmeten.... Uiteraard moet je software hier wel mee overweg kunnen en hier gaat het meestal mis: veel software kan gewoonweg niet op zo'n cluster draaien en dan moet je wel naar een flinke redundante server grijpen, maar zoals je kunt zien is het wellicht veel beter om je software goed te selecteren om zo flink geld te besparen...

[RemcoDelft]

Ik las al eerder (paar jaar terug) dat ze simpelweg een klein team hebben rondlopen om continu defecte harddisken te vervangen...
Bij honderdduizenden servers is dit simpelweg een hele mooie oplossing, fail safe uitgevoerd.

[GeniusDex]

Het is niet zo dat elke keer zodra er 1 onderdeel kapot gaat ze direct het datacentrum instormen om dat onderdeel te vervangen bij Google. Ze maken eerder elke week een rondje voor de suites om in een keer alle kapotte schijven te vervangen. Als er meer kritieke hardware faalt schuiven ze er gewoon een nieuwe server in. Er is geen enkel moment waarop er zo goed als geen kapotte hardware in een google suite hangt.

[Phu]

euh ja vriend daar heb je spare troep voor

virtueel de image laden vanuit de backup array naar de live swappable server
waar virtueel weer een os op draait

en dan hebben we het niet over bagger VPS techniek

[PolarBear]

Nou moederbord altijd een kritiek onderdeel. Niet als je deze jongens neerzet hoor.

[Verwijderd]

Gefeliciteerd, je gaat niet door voor de koelkast. Het ging er dus juist over dat ze NIET dat soort dingen neer willen zetten maar het gewoon erg redundant opzetten, daar waar jij aan refereert is alles behalve goedkoop.

[PolarBear]

Duurder hardware gaat ook stuk maar heeft meer redunantie. Alles hotswappeble. Dus daar schieten ze niet zo heel veel mee op.

[Rrob]

Nu al is het systeem dat het bedrijf op zijn servers gebruikt dermate robuust dat een cluster van achttienhonderd computers een uitval van zestienhonderd systemen kan overleven

Misschien begrijp ik het bovenstaande niet goed, maar betekend dit ook dat data die op 200 servers past, bij google 1800 servers vult? Dat lijkt me niet erg energie/grondstoffen efficient

[C-sharp]

als je efficiëntie beschouwd als maximale densiteit van data, dan is efficiëntie gelijklopend met ecologie, maar je redundantie wordt nul (alle eitjes in één mand).

als je efficiëntie beschouwd als maximale toegangssnelheid tot data, dan is efficiëntie strijdig met ecologie maar je redundantie stijgt (elk eitje apart verpakt).

Voor een wereldwijd netwerk dat een businessmodel heeft dat 100% afhankelijk is van e-service, vindt ik een dataredundantie van factor 9 ook wel stevig maar te waarschijnlijk te rechtvaardigen door de lage infrastructuurkost van standaard-componenten.

[TD-er]

Vergeet niet dat extra redundantie in dit geval ook scheelt in de traffic en die is ook niet gratis en zeker niet sneller dan lokale data.

[metaal]

Misschien begrijp ik het bovenstaande niet goed, maar betekend dit ook dat data die op 200 servers past, bij google 1800 servers vult?

Als ik het CNet artikel lees krijg ik de indruk dat het hier over Map Reduce servers gaat. Die slaan geen data op, maar prakken queries door een gehaktmolen:

The MapReduce reliability was severely tested once during a maintenance operation on one cluster with 1,800 servers. Workers unplugged groups of 80 machines at a time, during which the other 1,720 machines would pick up the slack. "It ran a little slowly, but it all completed," Dean said.

And in a 2004 presentation, Dean said, one system withstood a failure of 1,600 servers in a 1,800-unit cluster.

[n4m3l355]

Er is een wezenlijk verschil tussen de kosten en baten. Bij Google zullen de kosten die 1600 extra servers opwegen in zekerheid en kosten tov energie/grondstoffen. Niet te vergeten dat die 1600 stuks uitval waarschijnlijk wel voor vertragingen zullen zorgen maar geen verlies van data of daadwerkelijke downtime.
Ik vraag me daarintegen af wat Google nou jaarlijks kwijt is aan electra om dit geheel draaiende te houden en te koelen. Het is misschien wel eens interessant om zoiets te zien zeker met het blik van de nieuwe sdd schijven die Google wilt gebruiken.

[L0we]

Voor google is het van levensbelang dat ze blijven draaien. Redundantie is inderdaad bijzonder inefficient, maar wel degelijk een vereiste wil je een robuust systeem neerzetten.

[xxxneoxxx]

Interessant stuk om te lezen zo. Wel jammer dat Google geen algehele kijk in de keuken geeft.

[Verwijderd]

Kennis is het grootste kapitaal van Google. Dat gaan ze echt niet zomaar weggeven hoor, en terecht.

[mjtdevries]

wel jammer ja. Waar zijn ze eigenlijk bang voor?

Kan me niet voorstellen dat je echt iets wereldschokkends zou kunnen zien. (de interessante dingen zitten immers in de software)

Maar sommige bedrijven zijn nou eenmaal erg gesloten. (en vaak zeer ten onrechte, omdat ze echt geen spannende zaken doen)

[mae-t.net]

Een manier van werken en andere bedrijfsspecifieke kennis is niet altijd effectief te patenteren, maar is wel cruciaal voor het slagen van een kennisintensief bedrijf. Mijn conclusie is dat er behalve in de software ook veel moeite in een efficiente hardwarearchitectuur en strategie is gestoken, en ze die dus terecht ook niet geheel bloot willen geven.

[mjtdevries]

En dat zou je dan blootgeven bij een rondleiding door een serverruimtes?

Echt niet!

[Verwijderd]

Ze zijn vast bang dat het publiek de aangebrande pannen ziet liggen, dat is voor mij een belangrijke reden om mensen niet zo snel in de keuken te laten.

[? ?]

Alles wat in het stukje staat, heb ik al een hele tijd terug gelezen; zo geheimzinnig is het nu ook weer niet.

Elke server heeft ook een soort van geocode: zo weten ze dat de data minstens op 3 servers staat, die niet op dezelfde plaats staan.

De kracht van google is dat ze hun eigen DB en FS hebben gemaakt, voor hun noden. Er deden ook geruchten dat ze zelfs eigen harddisk drivers schrijven. Queries worden opgedeeld in stukken en naar verschillende servers gestuurd, resultaten worden daarna gecombineerd en teruggestuurd naar de client.

[Reactie gewijzigd door ? ? op 22 juli 2024 19:27]

[Verwijderd]

Is het écht nodig om 'meerdere' cores per server te hebben? Twee kan ik nog begrijpen, maar als je er bv. vier hebt, is de load dan niet wat laag? Waarom vier cores voeden als je ze niet gebruikt? +warmte +verbruik +kans op een uitval Volgens mij is de 'load' op zo een server toch vrij 'normaal', omdat de load wordt opgesplitst over cluster/rack/server.

Maar bon, dit is natuurlijk in de veronderstelling dat ze vier cores of dergelijke zouden hebben, ik ben er zeker van dat Google ook wel slim genoeg is om niet te overdrijven in hun hardware. (Heb het volledige artikel nog niet gelezen, weet niet of daar meer info in staat)

EDIT: lees net in de bron dat ze hun problemen wel parallel oplossen, en dat ze wel blij zijn met de multicore chips. Vergeet heel mijn post dus maar!

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:27]

[mr_obb]

Het plaatje van het Data Center rechtsbovenin is (volgens de bron) trouwens van crica 2000 en opmerkelijk is de ventilator rechtsonderin die de servers koel moet houden. Een grotere versie van het plaatje zit in de bron... Ik vond het wel een leuke wetenswaardigheid.

[FlowDesign]

Die hardware is natuurlijk leuk en aardig, maar lang niet zo interessant als de software die heel het zaakje draaiend houdt.

Ga eens na hoeveel queries er per seconde door Google verwerkt worden om heel het internet door te zoeken. Daar hebben ze blijkbaar enorm geniale indexering-, zoek-, file- en database-systemen voor ontworpen, iets wat niemand anders tot nu toe heeft kunnen overtreffen. Dát lijkt me pas interessant om meer over te weten.

[beany]

iets wat niemand anders tot nu toe heeft kunnen overtreffen

In ieder geval niet op het gebied van een internet zoek machine. Maar ik denk dat er nog wel grotere databases op de wereld zijn. NSA, NASA, CIA ?? Die hebben ook enorme bergen met data. Alleen van inlichtingendiensten krijg je nooit te horen wat ze hebben draaien. Die zijn wat dat betreft nog erger dan google

[metaal]

Wellicht zijn die databases wel groter in omvang qua bytes, maar niet wat betreft concurrent access. Dat maakt de systemen van Google ook zo bijzonder. Lees de pdfjes over GFS, BigTable en Map Reduce maar eens, dan zie je dat dit de belangrijkste design requirements zijn geweest voor deze systemen.

Leuk om te weten is trouwens ook dat de NASA (of de ESA) de hulp van Google heeft geroepen voor het opslaan, indexeren en verspreiden van data verzameld door die nieuwe radiotelescopen in Zuid Amerika. Weet even niet om welke het precies gaat.

[shadow_tj]

4 letters.... ff kijken.

Sun = 3
Intel = 5
HP = 2
Amd = 3
Via = 3
Sgi = 3


heheheheh HEB ER TWEE

DELL of CRAY beide 4 letters.

Google ( dell ) inside ???
ok lekker goedkoope hardware... ok mijn gok... Google draait op GRAY systems.
wel logisch.. staat top500 supercomputers ook vol mee

[XplodingForce]

Denk't niet, overal wordt gezegd dat google op normale hardware draait. CRAY supercomputers kun je nou niet echt normale hardware noemen, dus Dell lijkt me een betere gok dan.

[SpamLame]

Dell is een logische keuze aangezien de Google Search Appliances ook in een dell behuizing zitten

[mjtdevries]

Asus = 4

Maar Dell lijkt mij ook meer waarschijnlijk. Met name omdat dat in de VS nogal een grote speler is, en omdat ze vaak gebruikt worden voor appliances.

[shadow_tj]

jah normale hardware... daar vald gray niet onder... dat is zo.

dus mogen we dan concluderen dat ze met Dell systemen werken ?


ff snel server op dell.com

http://www1.euro.dell.com...l&cs=RC1078544&l=nl&s=pad


okee groene energy.. 4 letters in fabrikant naam.... Hebbes. !!!