Les emplacements des DC de Berkeley County et Hamina ne sont pas officiels Google mais un recoupement très probable d’après des infos et des photos.
(https://lafibre.info/images/datacenter/200910_google_large_distributed_systems.jpg) (https://lafibre.info/images/datacenter/200910_google_large_distributed_systems.pdf)[2] http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/fr//pubs/archive/36863.pdf (http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/fr//pubs/archive/36863.pdf)
En fait, on voit pleins de détails sur cette dernière :
- les serveurs n'ont pas de boitiers
- 4 connexions Gigabit (2x 2) avec des cables non-blindes (les connecteurs RJ-45 sont transparents)
- ports USB inutilisés
- 1x switch Gigabit 48 ports par rack
- 2x onduleurs APC Back-UPS CS (pour les switches je pense)
Et amène des questions : où sont les uplinks des switches ?! pas de prise à main à distance ? à quoi servent les blocs d'alimentations tout en haut qui ont des interfaces RJ-45 ? des STS ?
Et amène des questions : où sont les uplinks des switches ?! pas de prise à main à distance ? à quoi servent les blocs d'alimentations tout en haut qui ont des interfaces RJ-45 ? des STS ?Uplink des switches : certains switch ont leur connexion d'uplink à l'arrière, à côté de l'alimentation. Ici, on voit aussi de simples onduleurs certainement pour les switches.
Pour pouvoir agréger les ports et ne faire qu'un lien de 4 Gb/s, il faut mettre tous les câbles sur le même switch. Si on va plusieurs switch, c'est pour faire de la tolérance aux panne, pas du partage de charge.
Uplink des switches : certains switch ont leur connexion d'uplink à l'arrière, à côté de l'alimentation.Je savais pas que ca existait des switches avec ports a l'arriere ... ca pose pas des problemes d'interferences avec l'alim et la ventil ?! et c'est pas trop pratique a brasser non plus.
Mais on peut tres bien faire les 2 (tolérance et partage) au niveau plus haut (style IP failover).
J'aurais cru qu'ils faisaient ca la mais a priori c'est juste de l'aggregation Ethernet classique, ce qui a du sens si cette rangée de baies (voir tout le DC) est la que pour faire du GFS par exemple.
Uplink des switches : certains switch ont leur connexion d'uplink à l'arrière, à côté de l'alimentation. Ici, on voit aussi de simples onduleurs certainement pour les switches.
Leurs switches sont de la marque Quantas. Il n'y a pas de connexion réseau à l'arrière (j'y ai pensé aussi en plus d'un éventuel cable de stack).
D'ailleurs ce modèle ne se fait plus.
Leurs switches sont de la marque Quantas. Il n'y a pas de connexion réseau à l'arrière (j'y ai pensé aussi en plus d'un éventuel cable de stack).Tu es certain qu'il n'y a pas d'uplink à l'arrière?
D'ailleurs ce modèle ne se fait plus.
Tu es certain qu'il n'y a pas d'uplink à l'arrière?
Regarde par exemple ce switch de la marque Quanta (que tu nous as donné), il a 4 ports SFP+ 10Gb/s à l'arrière.
http://www.quantaqct.com/en/01_product/02_detail.php?mid=30&sid=114&id=115&qs=61 (http://www.quantaqct.com/en/01_product/02_detail.php?mid=30&sid=114&id=115&qs=61)
Leon.
Bon, je me répond à moi même. Sur ces 2 photos, on voit des switch de baie placés verticalement, avec les connexion d'uplink à l'arrière du switch, donc orienté vers le haut.
Du coup, il n'y a que 2 uplinks 10Gb par switch. Par rapport au nombre de ports, ça fait pas beaucoup ce qui laisse supposer qu'il n'y a donc pas tant de trafic que cela.J'ai l'impression que ça dépend des baies et des types de serveurs dans la baie.
Ce qui nous donne 14 serveurs par rack. Sachant qu'un serveur standard a 2 disque de 1 TO, combien de disque peuvent ils mettre sur une baie? Puisqu'un cable SATA peut connecter 5 disques (comme sur les storage pods de Backblaze (http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/) cela nous fait donc 10 TO de disponible (Google utilisant des replicas sur plusieurs serveurs plutôt qu'une redondance par RAID) ou plus (si ils utilisent des disque de 2 ou 4 TO).J'ai trouvé la réponse a cet question (pas sur la taille, mais sur la quantité de disque) grace a une autre video Youtube de CBS [vidéo supprimée] :
Et sur ces autres photos, on voit d'autres techno de lien entre switch et serveurs. Je pense que c'est du 10Gb/s CX4. Les serveurs ont alors une carte d'extension, que l'on voit verticale.
Tiens ils ont du Sun pour le robot de sauvegarde. Doit y en avoir d'autres car il me parait bien "petit" vu la taille de Google. Ou alors ils sont très optimistes sur les sauvegardes et font de la dedup à fond.
Moi, il y a un truc que je ne comprends pas.
Pourquoi ils mettent des faux planchers?
...
Circulation d'eau? Si oui, c'est vraiment étrange. s'embêter à mettre des faux planchers juste pour ça, ça ne me parait pas logique.
Leon.
Oui mais c'est plus facile d'entretenir la surface d'un faux plancher qu'un sol en béton, non?Il y a béton et béton. Il existe à la fois des bétons avec un surfaçage très lisses, et il existe aussi des revêtements que l'on mets sur le béton, et qui sont très lisses et très résistants. C'est souvent ce qu'il y a dans les usines, ateliers. Ca coute beaucoup moins cher et c'est beaucoup moins complexe à gérer que du faux plancher. Encore une fois, plusieurs acteurs de datacenter ont abandonné les faux planchers : Facebook, OVH, etc...
Je me demande dans quels POP ils ont des serveurs de cache et dans quels pop ils ont uniquement de la trans.Je pense qu'ils mettent des gros PoP en place est qu'ensuite ils rajoutent d'autre PoP en formant un topology en étoile (hub and spoke). Pour la France je parierais que le NetCenter
TH2 par exemple cela semble être uniquement de la trans.
www.youtube.com (https://www.youtube.com) | 2a00:1450:400c:c06::5d |
apis.google.com | 2a00:1450:4007:809::1005 |
csi.gstatic.com | 2404:6800:4006:804::100f |
gp3.googleusercontent.com | 2a00:1450:4007:809::100a |
i2.ytimg.com | 2a00:1450:4007:809::1001 |
i3.ytimg.com | 2a00:1450:4007:809::1005 |
i4.ytimg.com | 2a00:1450:4007:809::100e |
lh3.googleusercontent.com | 2a00:1450:4007:806::100b |
plus.google.com | 2a00:1450:4007:809::1009 |
r11---sn-25ge7n7l.c.youtube.com | 2a00:1450:4007:11::10 |
s.youtube.com | 2a00:1450:4007:809::1005 |
s.ytimg.com | 2a00:1450:4007:809::1006 |
s2.youtube.com | 2a00:1450:4007:809::1000 |
ssl.gstatic.com | 2a00:1450:4007:806::100f |
www.youtube-nocookie.com (https://www.youtube-nocookie.com) | 2a00:1450:400c:c06::5b |
Petit check: par10s10-in-f31.1e100.net n'as pas de AAAA, est chez free est routé via Cogent (et Londre!):
10 bzn-crs16-2-be2000.intf.routers.proxad.net (78.254.250.125) 15.690 ms 19.586 ms 19.780 ms
11 te0-1-0-7.369.mag21.par01.atlas.cogentco.com (149.6.161.29) 19.836 ms te0-1-0-4.377.mag21.par01.atlas.cogentco.com (149.6.115.25) 20.538 ms te0-1-0-3.363.mag21.par01.atlas.cogentco.com (149.6.160.97) 20.781 ms
12 te0-7-0-10.mpd21.par01.atlas.cogentco.com (154.54.74.157) 21.741 ms te0-0-0-10.mpd21.par01.atlas.cogentco.com (154.54.74.141) 16.126 ms te0-7-0-7.mpd21.par01.atlas.cogentco.com (154.54.60.29) 16.853 ms
13 te0-0-0-1.mpd22.lon13.atlas.cogentco.com (130.117.50.13) 25.713 ms te0-2-0-1.ccr22.lon13.atlas.cogentco.com (130.117.50.197) 26.921 ms te0-4-0-6.mpd21.lon13.atlas.cogentco.com (154.54.37.157) 27.172 ms
14 te0-4-0-1.ccr22.lon01.atlas.cogentco.com (130.117.0.245) 29.133 ms te0-1-0-0.ccr21.lon01.atlas.cogentco.com (130.117.1.1) 29.332 ms te0-4-0-1.ccr22.lon01.atlas.cogentco.com (130.117.0.245) 31.534 ms
15 te2-2.ccr01.lon18.atlas.cogentco.com (154.54.61.218) 31.268 ms te1-2.ccr01.lon18.atlas.cogentco.com (154.54.61.150) 32.509 ms te2-1.ccr01.lon18.atlas.cogentco.com (154.54.61.214) 33.048 ms
16 149.6.146.30 (149.6.146.30) 33.747 ms 35.188 ms 35.928 ms
17 209.85.255.78 (209.85.255.78) 24.294 ms 209.85.255.76 (209.85.255.76) 85.192 ms 209.85.255.78 (209.85.255.78) 27.896 ms
18 209.85.253.90 (209.85.253.90) 24.423 ms 209.85.253.92 (209.85.253.92) 25.712 ms 209.85.253.196 (209.85.253.196) 24.494 ms
19 209.85.242.79 (209.85.242.79) 24.734 ms 72.14.232.210 (72.14.232.210) 24.362 ms 24.862 ms
20 72.14.235.172 (72.14.235.172) 25.218 ms 25.449 ms 26.035 ms
21 209.85.243.47 (209.85.243.47) 25.366 ms 26.035 ms 24.832 ms
22 par10s10-in-f31.1e100.net (173.194.40.159) 24.022 ms 24.500 ms 24.201 ms
L'explication de Vivien (sensibilité aux fuites d'eau) est peut-être la bonne, mais ça reste surprenant.
mouais.
l'electricité de ces Datacenter de google, en californie, est produite par des centrales a charbon, et j'ai vu un reportage sur comment ils se demerdent pour recuperer ce charbon pour le moins cher possible... c'est pas tres beau a voir.
Et tout les deux, Google et apple ont construit un Datacenter 'ecolo' avec quelques centaines de m2 de solaire... la bonne blague.
un peu 'léger et polémique' ce genre de commentaire pour ne pas dire primaire...On comprend pourquoi :
Deja Google n'a pas de datacenter en Californie...mais bon c'est un 'détail' hein ...
Pour ce qui est du charbon, c'est surtout en Caroline du Nord que ca se passe a cause des conditions géographiques et politiques (proximité et importance des mines de charbon, climat, réseau d'eau, taxes, faible densité habitants, etc).La part du charbon dans la production d'énergie électrique aux USA est énorme :
Today, Google confirmed that it is investing an additional $1 billion in massive Iowa data centers into which it has already put $1.5 billion. And now VentureBeat has obtained video of the massive project.https://www.youtube.com/watch?v=TbP1UW6Oi_s
Google told VentureBeat that:http://venturebeat.com/2015/04/17/go-up-over-and-inside-googles-huge-iowa-data-centers-in-this-new-video/
In new video footage we’re sharing, you can see for the first time what our two Council Bluffs data center facilities look like on the inside and from the air — that’s hundreds of thousands of square feet of computing power to deliver your most important search results and your favorite videos, the instant you want them. It’s all managed by more than 300 employees and contractors hard at work across the two campuses.
Google’s data centers are some of the most efficient in the world, using 50 percent less energy than the typical data center. Google is the first major Internet services company to gain external certification of the high environmental, workplace safety, and energy management standards of its data centers. And as always, one of our highest priorities when building a new facility is finding renewable energy sources to power it. For Council Bluffs, we’ve secured 407 [megawatts] of wind power from local utility MidAmerican Energy and 114 MW of wind power from a facility in Story County, Iowa. Separately, we’ve invested $75 million in a 50 MW wind farm in Greene County, north of Des Moines.
Les éoliennes sont "green"?
Les éoliennes sont "green"?1
Pour mes poumons oui ;D
1Certains matériaux sont extraits en Chine dans des conditions effroyables, c'est loin donc en s'en fout.
vaste débat ;) en tout cas plus que le charbon&pétrole (car même si il en faut pour les fabriquer, il en faut aussi pour les centrales... et il n'en faut presque plus pendant leurs fonctionnements)
j'ai du mal a le situer sur la carte. D'apres la video, les 2 batiments sont a coté d'une grand étendue 'vide' (champs):
hors le batiment d'origine visible sur Google Maps (loc: https://www.google.com/maps/@41.2206994,-95.8642342,720m/data=!3m1!1e3 )
n'est clairement pas au même endroit: au nord il y a la ville et au sud un lac.
Il y aurait donc 2 sites a Council Bluffs ? et 3 DC en tout ?
Si quelqu'un trouve l'emplacement correspondant a la video ca m’intéresse ;)
Apres B4, leur Software Defined WAN (http://cseweb.ucsd.edu/~vahdat/papers/b4-sigcomm13.pdf) publié en 2013 qui donnait quelques infos sur le "mega WAN" reliant les DC de Google,
Apres Andromeda en 2014 (https://googlecloudplatform.blogspot.fr/2014/04/enter-andromeda-zone-google-cloud-platforms-latest-networking-stack.html), la "network virtualization stack" utilisée dans leur DC,
Hier, lors de la conférence Open Networking Sumit 2015, Google a dévoilé encore un élèment important de l'architecture utilisée dans leur DC: Jupiter Super Block, leur 5eme génération de SDN qui est le 'LAN' interne de leur DC.
Basé sur un réseau de Clos, utilisant des composants bas niveau plutôt que des produits d’équipementiers, fonctionnant avec des nouveaux protocoles inventés pour DC plutôt que les standards d'Internet, leur SDN arrive a fournir un total de 1 Petabit/sec de "bisection bandwidth" permettant a 100 000 serveurs d'échanger des informations a 10 Gbps chacun .... :o
Une publication plus détaillée sera faite lors du SIGCOMM 2015 en août, en attendant voila la keynote de l'Open Networking Sumit 2015:
https://www.youtube.com/watch?v=FaAZAII2x0w
Bon, pour en finir un peu avec les data centres Google, voici quelques éléments concernant le réseau distant:Au sujet des Google switchs, je ne pense pas que Google ait développer un switch pour déployer quelques boxes par data centre (les salles réseau sont très petites pour la tailles des data floors) - donc je pense qu'ils les utilisent comme cluster switch, pour connecter les TORs et former _the_ interconnect fabric (et avec 128x10GE on peut faire de jolie flattened butterflies ou dragon flies).
- La présentation de Urs Hoezle ou il présente l’implèmentation d'open flow chez Google, dont la vidéo est accessible ci-dessous.
- Une image (extrait de la présentation) montrant le liens entre data centres (avec Paris sur la cartes :D - avec un gros PoP s'entends)
- Une image du Google Switch -> 8 line cards de 8 x 10 GE.
Donc, on est bien au delà des 100,000 serveurs annoncer, ou me suis-je tromper quelque par?
Regardez sur la photo ci-dessous en zoomant : on voit bien la présence de 4 ports 1 Gb/s cuivre par serveur :
(https://lafibre.info/images/datacenter/201305_datacenter_google_mini_PRY_20.jpg) (https://lafibre.info/images/datacenter/201305_datacenter_google_PRY_20.jpg)
Google semble connecter ses serveurs en 4 Gb/s (4 x 1 Gb/s).
Le 10 Gb/s serait réservé a la toute dernière génération et je ne sais pas si c'est généralisé sur les nouveaux déploiements de serveurs.
The Dalles, Oregon
Ceci est le premier data centre construit par Google, en 2008. On peux voir que la hauteur des bâtiments limites de volume d'air a l’intérieur des data halls, alors que les tours de refroidissement sont plus hautes, donnant l'impression de voir deux "pétrolier" échouer sur les berges de la rivière Columbia.
La plomberie sous les tours de refroidissement suit un code de couleur qui rends l'ensemble très jolie: Rouge pour les circuits chaud, Bleue pour les circuits froid, Vert et Jaune pour les échangeurs thermique et groupes de refroidissement.
(https://lafibre.info/images/datacenter/201305_datacenter_google_mini_DLS_019.jpg) (https://lafibre.info/images/datacenter/201305_datacenter_google_DLS_019.jpg)
Les 100k serveurs mentionnés ne sont pas le nombre de serveurs effectifs mais juste la division de la capacité de Jupiter (1 Petabit/sec) par 10 Gbps (connectique de base d'un serveur). C'était juste pour illustré l'un ordre de grandeur de ce que représente 1 Petabit/sec .
Il va de soi qu'ils ne provisionnent probablement pas leur serveurs a 10Gbps chacun mais probablement beaucoup moins donc en pratique ca supporte nettement plus de serveurs. Apres effectivement ils se laissent peut-être aussi de la marge pour évoluer.
bisection bandwidth = bandwidth across smallest cut that divides network into two equal halves
For a given topology, bisection bandwidth, is calculated by dividing(tiré d'une lecture conseillée: Computer Architecture: A Quantitative Approach (http://www.amazon.fr/Computer-Architecture-Quantitative-John-Hennessy/dp/012383872X) )
the network into two roughly equal parts—each with half the nodes—and
summing the bandwidth of the links crossing the imaginary dividing line
L'architecture est détaillé tel que je l'ai poste précédemment (je remet l'image extraite de la vidéo ici)... donc ceci n'est pas une vue de l'esprit ou une théorie :D.
On peux donc calculer le maximum possible en pratique pour cet fabrique réseau non-blocking.
Evidemment l'architecture et les valeur de bandes passante sont full-duplex. Les serveurs sont en 10 ou 40G (pas de précision sur le multi-link).
Je n 'ai pas vu mentionné que le Jupiter était non-blocking ca serait énorme...
Et je suis à peu près certain que tout le monde utilise les memes ASIC, donc peu de difference sur le hard, c'est vraiment sur l'implementation logique qu'on va trouver des écarts.
Pour ce qui est du compte de serveur, le calcule est plus simple:
- 64 blocks * 32 switch * 32 ports * 4 * 10 Gbps
- 64 blocks * 32 * 32 * 4 * 10 Gbps
- 64 blocks * 4 096 * 10 Gbps
- 262 144 * 10 Gbps
Donc, on est bien au delà des 100,000 serveurs annoncer, ou me suis-je tromper quelque par?
Chez Facebook, ils ont ecrit leur propre implementation de TRILL.
Oui - je me suis bel et bien trompe :D.
La réponse est dans la couche SDN: ton infra physique est capable d'avoir plusieurs topologies virtuelles. La tendance est à l'utilisation de VXLAN, il y a aussi TRILL. L'infra doit donc etre capable de s'adapter à tous les 'sens'/cas de figure des flux.
Dans tous les cas, ce sont des reseaux où le bon vieux spanning-tree en a été banni.
"TRILL switches (RBridges) run a link state protocol amongst themselves. A link state protocol is one in which connectivity is broadcast to all the RBridges, so that each RBridge knows about all the other RBridges, and the connectivity between them"
Je ne pense pas que TRILL soit une option que Google choisirait, du a la nature de trill [1] (emphasis mine):
Quesiton: Cela a-t-il une incidence (positive) du point de vue économique?
Il y a dans ce thread pas mal d'actualités sur les annonces d'infrastructures Google des 2 dernières années !
Puisque je vois que certains suivent particulièrement les implantations, extensions etc. des DC Google un peu partout sur la planète : au total cela correspond à quelle surface en termes d'emprise au sol ?
Les 2 nouveaux bâtiments en construction a Councils Buffs font chacun 78k et 86k , ce sont des monstres (+600m de long, +120m de large).
On peux aussi ajouter la deuxième tranche de Mayes County, un batiment qui était a Gatorade et que Google a acheter qui fait ~ 660 x 200m (132k m2!!!).
Je ne sais pas si l’aménagement du DC a commencer...
Google Maps - Mayes County, tranche 2 (http://"https://www.google.fr/maps/place/36%C2%B014'41.7%22N+95%C2%B019'30.4%22W/@36.24491,-95.325126,785m/data=!3m2!1e3!4b1!4m2!3m1!1s0x0:0x0?hl=en")
[...]qui fait ~ 660 x 200m (132k m2!!!).Je crois que tu confond les unités.
Je crois que tu confond les unités.
1km² = 1km x 1km = 1000m x 1000m = 1 Million de m²
Donc le datacenter en question ferait 132 000m².
Leon.
T'es sur que le batiment de Gatorade va devenir un DC ? sinon je vois un truc en construction juste en dessous, tranche 3 de Mayes?
Par ailleurs, 4 autres DC sont en cours d'agrandissement, notamment celui en Belgique qui nous concerne directement.
Il va quasiment doubler (le nouveau bâtiment est a l’arrière plan):
(https://lafibre.info/images/datacenter/201506_datacenter_google_3.jpg)