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 .

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

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.

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.

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.

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).

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 .



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...

Oui - je me suis bel et bien trompe .

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: