Auteur Sujet: Les data centers de Googles  (Lu 88949 fois)

0 Membres et 1 Invité sur ce sujet

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 4 835
  • FTTH 1Gb/s sur Paris (75)
Les data centers de Googles
« Réponse #108 le: 07 juillet 2015 à 21:49:25 »
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).

on ne doit pas se comprendre ou avoir le même background de référence. Ca tourne au dialogue de sourds la ;D

Je n 'ai pas vu mentionné que le Jupiter était non-blocking ca serait énorme...
Pour le full-duplex je parlais de la bisection bandwidth et évidemment pas de l'archi ou des liens des serveurs.
Les 100k dont je parlais sont les 100k qu'il mentionne pas les 100k (ou plutot 131k ports) qu'on peut éventuellement 'calculer' en regardant l'agencement des blocks et des liens.

bref pas grave, on parle pas du tout des memes choses, pas la peine de dérailler le topic pour ca.

ruchard5

  • Expert
  • Client Free adsl
  • *
  • Messages: 116
    • Le blog du Ruchard
Les data centers de Googles
« Réponse #109 le: 07 juillet 2015 à 22:21:50 »
Je n 'ai pas vu mentionné que le Jupiter était non-blocking ca serait énorme...

C'est un des principe de base des divers design de DCN Google (lien vers la video a t+741 secondes):

https://youtu.be/FaAZAII2x0w?t=741

Voici le transcript:

"First, we leverage clos topology.This is an old idea, 60+ years ago now, from the telecommunications industry. The notion here is that you can leverage a number of small, commodity switches to build an effectively non-blocking very large scale switch. And it can scale more or less infinitely and certainly to the size of the data centers that we needed. We did this with merchant silicon."

Donc on est d'accord sur une chose: c'est enorme!!!

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 342
  • Malissard (26)
Les data centers de Googles
« Réponse #110 le: 12 juillet 2015 à 15:16:52 »
Attention, dans un DC, il ne faut pas seulement penser Nord/Sud mais aussi Est/Ouest : il y a aussi des flux serveurs à serveurs.

La différence est de taille: pour permettre un flux Est/Ouest sans passer par les SPINE, il faut que l'architecture logique le permette en s'appuyant sur du TRILL ou par une surcouche VXLAN.

Il y a encore 5 ans, on était limité par le fonctionnement d'Ethernet et du protocole Spanning-tree qui imposait de surdimensionner les uplinks. Depuis, non seulement on a amelioré les debits mais on a aussi traité la façon de mieux les flux en les faisant passer 'u plus court'.

L'architecture décrite par Google est helas trop succinte pour comprendre comment ils ont traité ce point.

Chez Facebook, ils ont ecrit leur propre implementation de TRILL.

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 4 835
  • FTTH 1Gb/s sur Paris (75)
Les data centers de Googles
« Réponse #111 le: 12 juillet 2015 à 16:04:45 »
J'attend les détails en août. 'the devil is in the detail' comme on dit.

Je ne suis pas sur que les notions North/South et Upsteam/downsteam aient le même sens dans ce contexte. Ce sont des notions liées au 'monde classique du réseau' (core - distribution - access) que Cisco a bien "brainwasher" tout le monde avec car c'est leur intérêt.

Une des forces de Google justement est de souvent repartir de zéro, rejeter les modèles traditionnels d'un domaine et faire leur propre 'sauce' à  partir des blocs technologiques qu'ils ne peuvent faire eux même.

miky01

  • Expert. Réseau RESO-LIAin (01)
  • Client K-Net
  • *
  • Messages: 3 935
  • Farges (01)
Les data centers de Googles
« Réponse #112 le: 12 juillet 2015 à 16:12:50 »
Le dernier gros DC que j'ai vu, les seveurs sont connetés en fibre mutimode OM4 avec des Cisco, plus efficace que le LAN GBs.

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 342
  • Malissard (26)
Les data centers de Googles
« Réponse #113 le: 12 juillet 2015 à 16:14:11 »
Depuis la gamme Nexus, il n'y a plus de 'Core - Distrib - Access', sur 9000 on ne parle plus que Spine et Leafs. Sur 7000/5000, on est plus dans la philosophie Google avec Spine / Aggregate / ToR.

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.

Il manque aussi le 100G dans les planches Google, ça serait étonnant de ne pas en voir.

ruchard5

  • Expert
  • Client Free adsl
  • *
  • Messages: 116
    • Le blog du Ruchard
Les data centers de Googles
« Réponse #114 le: 13 juillet 2015 à 14:36:20 »
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.

Effectivement. Il y a des différences majeur dans l’implèmentation.

Premièrement Google se base sur des ASIC 16 x 40G et les gèrent indépendamment. CAD que un switch Centauri contient 4 asics mais que cela ne fait pas un switch de 64 x 40G, mais 4 switches de 16 x 40 G. C'est la mise en place de la topologie Clos.

Donc, chaque Centauri switch est une enclosure pour 4 switches de 16 x 40 G (ou 64 X 10G).



On voit aussi cela en essayant de comprendre le design des TORs. La seul chose qui est sure c'est que les TOR sont connectées a l'Aggregation (8 x middle blocks) via 2x10GE. Par ASIC. Soit 16 x 10GE = 4 x 40GE sur l'ASIC.  Cela laisse 12 x 40 GE sur l'asic qui sont utilise pour connecter les 3 autres asic dans la même enclosure en mesh (voir l'image attachée - de moi).

Finalement, depuis le debut de l'initiative (il y a 10 ans) Google avait besoin de la gestion de mutlipaths qui n'existait pas.

En gros, chaque asic est gérée en fonction de sa position dans l'architecture global (par software) et permet de mettre en place des flows est/ouest a wire speed (pour la mise en place de reseau virtual non-basee sur les vlan definit par l'IEEE (Network Function Virtualization) ou autre features).

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 342
  • Malissard (26)
Les data centers de Googles
« Réponse #115 le: 13 juillet 2015 à 15:20:48 »
Il est sympa ton schéma, ça me donne des idées... :)

Cisco ne détaille pas autant le fonctionnement interne de sa gamme Nexus 9300. D'après BRKARC-2222, on sait juste que:
 - sur le N9396PX (48x10GbE+12x40GbE), on a 12x40GbE downlink et 12x42GbE uplink : en supposant que le NFE soit composé de 3 ASIC identiques à ceux de Google, ça donne le schéma de gauche.
 - sur le N93128Tx (96x1/10GbT+8x40GbE), on a 24x40GbE downlink et 8x42GbE uplink : toujours avec l'hypothèse des memes ASIC, avec 5 ça colle avec une architecture SPINE&LEAF (schéma de droite). Mais du coup, on perd (un peu) sur les capacités Est/ouest interne du switch.

Donnez-leur un composant, intéressant de voir les différentes approches.


ruchard5

  • Expert
  • Client Free adsl
  • *
  • Messages: 116
    • Le blog du Ruchard
Les data centers de Googles
« Réponse #116 le: 14 juillet 2015 à 23:18:34 »
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?


Oui - je me suis bel et bien trompe :D.



Ayant finalement compris le design des TORs avec les 4 asics connecter en mesh, on peut corriger le compte de port en 10G (qui n'est qu'un point d'information, puisque Google a annoncer que les serveur peuvent être en 10 ou 40GE, amis cela nous donne un maximum théorique pour commencer).

  • 64 blocks * 32 switch * 64 ports * 10 Gbps
  • 64 blocks * 32 * 64 * 10 Gbps
  • 64 blocks * 2048 * 10 Gbps
  • 131 072 * 10 Gbps

Ce qui, en laissant quelques ports pour l’interconnexion au Campus / Wan (disons 31 072 x 10G quand même!!!) nous laisse exactement 100 000 serveur - ce que correspond au nombre fournit par Google!

Sans parler de la possibilité de mettre le système a jour (sans évolution du design) avec des asics en 16x100GE...

ruchard5

  • Expert
  • Client Free adsl
  • *
  • Messages: 116
    • Le blog du Ruchard
Les data centers de Googles
« Réponse #117 le: 15 juillet 2015 à 08:21:42 »
Chez Facebook, ils ont ecrit leur propre implementation de TRILL.

En parlant de Facebook, l'illustration [1] de leur plateforme réseau nous permet de comparer le peu de différences entre les implèmentations de Google et Facebook:



  • Facebook se base sur 48 TOR par POD vers 4 fabric switches connecté a 4 spine planes de 48 switches.
  • Google se base sur 32 TOR par POD vers 8 fabric switches connecté a 4 spine planes de 64 switches.

A noter que le nombre de POD / fabric switch chez Facebook n'est pas spécifier (mais avec le 6-pack [2] qui est un switch de 128 x 40GE on peut donner un maximum a 64 server pods, moins 4 edge pods = 60).

Les différences majeur sont donc au niveau des TORs et de l'aggregation:
  • Facebook Over-subscription au niveau des TORs [3] de 1:3 (4x40G uplink pour 12 x40G vers des serveurs en 10G) alors que Google est sur un modele 1:1
  • Facebook utilise des switches de 48 in / 48 out (max 64 in / 64 out au format 6-pack) pour une bisection de 7.68Tbps (10.24T max) alors que Google a 20Tbps de bi-section sur l'aggregation

[1] Introducing data center fabric, the next-generation Facebook data center network
[2] Introducing “6-pack”: the first open hardware modular switch
[3] Introducing “Wedge” and “FBOSS,” the next steps toward a disaggregated network
« Modifié: 15 juillet 2015 à 14:12:59 par ruchard5 »

ruchard5

  • Expert
  • Client Free adsl
  • *
  • Messages: 116
    • Le blog du Ruchard
Les data centers de Googles
« Réponse #118 le: 17 juillet 2015 à 14:11:01 »
Oui - je me suis bel et bien trompe :D.

Oui, mais non!

L'erreur provient du dessin des TORs qui ne correspond pas a l'architecture définit par Google: 2 x 10GE vers 8 aggregation blocks _par_ asic. Cela fait 16 x 10 GE vers chacune des 4 asics dans chaque enclosure, ce qui nous fait 64 x 10GE (que l'on retrouve a l'aggregation via 256 x 10 GE x 8 middle blocks / 32 TOR = 64 x 10 GE).

Donc, l'agencement des TORs se fait avec:

  • 16 x 10GE South (vers les serveurs)
  • 16 x 10GE North (vers l'aggregation
  • 4 x 40GE East (vers une asic dans l'enclosure)
  • 4 x 40 GE West (vers une autre asic dans l'enclosure)

Ce qui nous donne le schéma suivant:

ruchard5

  • Expert
  • Client Free adsl
  • *
  • Messages: 116
    • Le blog du Ruchard
Les data centers de Googles
« Réponse #119 le: 19 juillet 2015 à 17:48:36 »
Petite question concernant le choix du design des switch Google en mode "clos".

Les middles bloc et spine switches (illustration jointes) sont-ils vraiment mieux que le 6-pack de Facebook par exemple (ou d'autre switch classique en 128 x 40 GE)?

Quels sont les avantages et inconvénient d'un telle design?




 

Mobile View