2. Network Design Requirements (Exigences de conception de réseau)

Cette section décrit et résume les exigences de conception de réseau pour les centres de données à grande échelle.

2.1 Bandwidth and Traffic Patterns (Bande passante et modèles de trafic)

L'exigence principale lors de la construction d'un réseau d'interconnexion pour un grand nombre de serveurs est de répondre aux exigences de bande passante et de latence des applications. Jusqu'à récemment, il était assez courant de voir la majorité du trafic entrant et sortant du centre de données, communément appelé trafic "nord-sud". Les topologies "arborescentes" traditionnelles étaient suffisantes pour accueillir de tels flux, même avec des ratios de sursouscription élevés entre les couches du réseau. Si plus de bande passante était nécessaire, elle était ajoutée en "montant en puissance" les éléments du réseau, par exemple en mettant à niveau les cartes de ligne ou les structures du dispositif ou en remplaçant le dispositif par un autre avec une densité de ports plus élevée.

Aujourd'hui, de nombreux centres de données à grande échelle hébergent des applications générant des quantités importantes de trafic serveur à serveur, qui ne quitte pas le DC, communément appelé trafic "est-ouest". Des exemples de telles applications pourraient être des clusters informatiques tels que Hadoop [HADOOP], une réplication massive de données entre les clusters nécessaire pour certaines applications, ou des migrations de machines virtuelles. L'extension des topologies arborescentes traditionnelles pour répondre à ces demandes de bande passante devient soit trop coûteuse, soit impossible en raison de limitations physiques, par exemple la densité de ports dans un commutateur.

2.2 CAPEX Minimization (Minimisation des CAPEX)

Les dépenses en capital (CAPEX) associées uniquement à l'infrastructure réseau constituent environ 10-15% des dépenses totales du centre de données (voir [GREENBERG2009]). Cependant, le coût absolu est important, et il est donc nécessaire de réduire constamment le coût des éléments de réseau individuels. Cela peut être accompli de deux manières:

Unifier tous les éléments du réseau, de préférence en utilisant le même type de matériel ou même le même dispositif. Cela permet une tarification en volume sur les achats groupés et réduit les coûts de maintenance et d'inventaire.
Réduire les coûts en utilisant les pressions concurrentielles, en introduisant plusieurs fournisseurs d'équipements réseau.

Afin de permettre une bonne diversité de fournisseurs, il est important de minimiser les exigences en matière de fonctionnalités logicielles pour les éléments du réseau. Cette stratégie offre une flexibilité maximale dans le choix des équipements des fournisseurs tout en appliquant l'interopérabilité à l'aide de normes ouvertes.

2.3 OPEX Minimization (Minimisation des OPEX)

L'exploitation d'une infrastructure à grande échelle peut être coûteuse car un plus grand nombre d'éléments échoueront statistiquement plus souvent. Avoir une conception plus simple et fonctionner avec un ensemble de fonctionnalités logicielles limité minimise les défaillances liées aux problèmes logiciels.

Un aspect important de la minimisation des dépenses opérationnelles (OPEX) est la réduction de la taille des domaines de défaillance dans le réseau. Les réseaux Ethernet sont connus pour être sensibles aux tempêtes de trafic de diffusion ou monodiffusion qui peuvent avoir un impact dramatique sur les performances et la disponibilité du réseau. L'utilisation d'une conception entièrement routée réduit considérablement la taille des domaines de défaillance du plan de données, c'est-à-dire les limite au niveau le plus bas de la hiérarchie du réseau. Cependant, ces conceptions introduisent le problème des défaillances du plan de contrôle distribué. Cette observation nécessite des protocoles de plan de contrôle plus simples et moins nombreux pour réduire les problèmes d'interaction de protocole, réduisant ainsi le risque d'effondrement du réseau. La minimisation des exigences en matière de fonctionnalités logicielles comme décrit dans la section CAPEX ci-dessus réduit également les exigences en matière de tests et de formation.

2.4 Traffic Engineering (Ingénierie du trafic)

Dans tout centre de données, l'équilibrage de charge des applications est une fonction critique exécutée par les dispositifs réseau. Traditionnellement, les équilibreurs de charge sont déployés en tant que dispositifs dédiés dans le chemin de transmission du trafic. Le problème se pose lors de l'extension des équilibreurs de charge sous une demande de trafic croissante. Une solution préférable serait capable d'étendre horizontalement la couche d'équilibrage de charge, en ajoutant plus de nœuds uniformes et en distribuant le trafic entrant sur ces nœuds. Dans de telles situations, un choix idéal serait d'utiliser l'infrastructure réseau elle-même pour distribuer le trafic sur un groupe d'équilibreurs de charge. La combinaison de l'annonce de préfixe anycast [RFC4786] et de la fonctionnalité Equal Cost Multipath (ECMP) peut être utilisée pour atteindre cet objectif. Pour permettre une distribution de charge plus granulaire, il est bénéfique pour le réseau de supporter la capacité d'effectuer une ingénierie du trafic contrôlée par saut. Par exemple, il est bénéfique de contrôler directement l'ensemble de sauts suivants ECMP pour les préfixes anycast à chaque niveau de la hiérarchie du réseau.

2.5 Summarized Requirements (Exigences résumées)

Cette section résume la liste des exigences décrites dans les sections précédentes:

REQ1: Sélectionner une topologie qui peut être étendue "horizontalement" en ajoutant plus de liens et de dispositifs réseau du même type sans nécessiter de mises à niveau des éléments du réseau eux-mêmes.
REQ2: Définir un ensemble restreint de fonctionnalités/protocoles logiciels supportés par une multitude de fournisseurs d'équipements réseau.
REQ3: Choisir un protocole de routage qui a une implémentation simple en termes de complexité du code de programmation et de facilité de support opérationnel.
REQ4: Minimiser le domaine de défaillance des équipements ou des problèmes de protocole autant que possible.
REQ5: Permettre une certaine ingénierie du trafic, de préférence via un contrôle explicite du saut suivant du préfixe de routage en utilisant les mécaniques de protocole intégrées.