3. VXLAN Problem Statement (Énoncé du problème VXLAN)
Cette section fournit plus de détails sur les domaines que VXLAN vise à traiter. L'accent est mis sur l'infrastructure réseau au sein du centre de données et les problèmes qui y sont liés.
3.1. Limitations Imposed by Spanning Tree and VLAN Ranges (Limitations imposées par le spanning tree et les plages VLAN)
Les réseaux de couche 2 actuels utilisent le protocole Spanning Tree IEEE 802.1D (Spanning Tree Protocol, STP) [802.1D] pour éviter les boucles dans le réseau dues à des chemins en double. STP bloque l'utilisation de liens pour éviter la réplication et le bouclage des trames. Certains opérateurs de centres de données considèrent cela comme un problème avec les réseaux de couche 2 en général, car avec STP, ils paient effectivement pour plus de ports et de liens qu'ils ne peuvent réellement utiliser. De plus, la résilience due au multichemin n'est pas disponible avec le modèle STP. De nouvelles initiatives, telles que TRILL [RFC6325] et SPB [802.1aq], ont été proposées pour aider au multichemin et surmonter certains des problèmes avec STP. Les limitations STP peuvent également être évitées en configurant les serveurs dans un rack pour qu'ils soient sur le même réseau de couche 3, avec la commutation se produisant à la couche 3 à la fois dans le rack et entre les racks. Cependant, cela est incompatible avec un modèle de couche 2 pour la communication inter-VM.
Une caractéristique clé des réseaux de centres de données de couche 2 est leur utilisation de réseaux locaux virtuels (VLAN) pour fournir une isolation de diffusion. Un ID VLAN de 12 bits est utilisé dans les trames de données Ethernet pour diviser le réseau de couche 2 plus grand en plusieurs domaines de diffusion. Cela a bien fonctionné pour de nombreux centres de données qui nécessitent moins de 4094 VLAN. Avec l'adoption croissante de la virtualisation, cette limite supérieure est sous pression. De plus, en raison de STP, plusieurs centres de données limitent le nombre de VLAN qui pourraient être utilisés. De plus, les exigences pour les environnements multi-locataires accélèrent le besoin de limites VLAN plus importantes, comme discuté dans la section 3.2.
3.2. Multi-tenant Environments (Environnements multi-locataires)
Le cloud computing implique un provisionnement élastique à la demande de ressources pour des environnements multi-locataires. L'exemple le plus courant de cloud computing est le cloud public, où un fournisseur de services cloud offre ces services élastiques à plusieurs clients/locataires sur la même infrastructure physique.
L'isolation du trafic réseau par un locataire peut être effectuée via des réseaux de couche 2 ou de couche 3. Pour les réseaux de couche 2, les VLAN sont souvent utilisés pour séparer le trafic -- ainsi un locataire pourrait être identifié par son propre VLAN, par exemple. En raison du grand nombre de locataires qu'un fournisseur de cloud peut desservir, la limite de 4094 VLAN est souvent inadéquate. De plus, il y a souvent besoin de plusieurs VLAN par locataire, ce qui exacerbe le problème.
Un cas d'utilisation connexe est l'expansion cross-pod. Un pod se compose généralement d'un ou plusieurs racks de serveurs avec une connectivité réseau et de stockage associée. Les locataires peuvent commencer sur un pod et, en raison de l'expansion, nécessiter des serveurs/VM sur d'autres pods, en particulier dans le cas où les locataires sur les autres pods n'utilisent pas pleinement toutes leurs ressources. Ce cas d'utilisation nécessite un environnement de couche 2 "étendu" reliant les serveurs/VM individuels.
Les réseaux de couche 3 ne sont pas non plus une solution complète pour la multi-location. Deux locataires pourraient utiliser le même ensemble d'adresses de couche 3 dans leurs réseaux, ce qui oblige le fournisseur de cloud à fournir une isolation sous une autre forme. De plus, exiger que tous les locataires utilisent IP exclut les clients qui dépendent de protocoles de couche 2 directs ou de protocoles de couche 3 non-IP pour la communication inter-VM.
3.3. Inadequate Table Sizes at ToR Switch (Tailles de tables inadéquates au niveau du commutateur ToR)
Les environnements virtualisés d'aujourd'hui imposent des exigences supplémentaires sur les tables d'adresses MAC des commutateurs Top-of-Rack (ToR) qui se connectent aux serveurs. Au lieu d'une seule adresse MAC par lien de serveur, le ToR doit maintenant apprendre les adresses MAC des VM individuelles (qui pourraient se compter par centaines par serveur). Cela est nécessaire car le trafic vers/depuis les VM vers le reste du réseau physique traversera le lien entre le serveur et le commutateur. Un commutateur ToR typique pourrait se connecter à 24 ou 48 serveurs en fonction du nombre de ses ports orientés serveur. Un centre de données peut se composer de plusieurs racks, de sorte que chaque commutateur ToR devrait maintenir une table d'adresses pour les VM communicantes sur les différents serveurs physiques. Cela impose une demande beaucoup plus importante sur la capacité de la table par rapport aux environnements non virtualisés.
Si la table déborde, le commutateur peut cesser d'apprendre de nouvelles adresses jusqu'à ce que les entrées inactives expirent, ce qui conduit à un débordement important de trames de destination inconnues ultérieures.