3. VXLAN Problem Statement (VXLAN-Problemstellung)
Dieser Abschnitt bietet weitere Details zu den Bereichen, die VXLAN adressieren soll. Der Fokus liegt auf der Netzwerkinfrastruktur innerhalb des Rechenzentrums und den damit verbundenen Problemen.
3.1. Limitations Imposed by Spanning Tree and VLAN Ranges (Durch Spanning Tree und VLAN-Bereiche auferlegte Einschränkungen)
Aktuelle Schicht-2-Netzwerke verwenden das IEEE 802.1D Spanning Tree Protocol (STP) [802.1D], um Schleifen im Netzwerk aufgrund doppelter Pfade zu vermeiden. STP blockiert die Verwendung von Links, um die Replikation und das Schleifen von Frames zu vermeiden. Einige Rechenzentrumsbetreiber sehen dies als Problem bei Schicht-2-Netzwerken im Allgemeinen, da sie mit STP effektiv für mehr Ports und Links bezahlen, als sie wirklich nutzen können. Darüber hinaus ist die Ausfallsicherheit durch Mehrfachpfade beim STP-Modell nicht verfügbar. Neuere Initiativen wie TRILL [RFC6325] und SPB [802.1aq] wurden vorgeschlagen, um bei Mehrfachpfaden zu helfen und einige der Probleme mit STP zu überwinden. STP-Einschränkungen können auch vermieden werden, indem Server in einem Rack so konfiguriert werden, dass sie sich im selben Schicht-3-Netzwerk befinden, wobei das Switching sowohl innerhalb des Racks als auch zwischen Racks auf Schicht 3 erfolgt. Dies ist jedoch mit einem Schicht-2-Modell für die Inter-VM-Kommunikation nicht kompatibel.
Ein Hauptmerkmal von Schicht-2-Rechenzentrumsnetzwerken ist ihre Verwendung von virtuellen LANs (VLANs) zur Bereitstellung von Broadcast-Isolierung. Eine 12-Bit-VLAN-ID wird in den Ethernet-Datenframes verwendet, um das größere Schicht-2-Netzwerk in mehrere Broadcast-Domänen zu unterteilen. Dies hat für viele Rechenzentren gut funktioniert, die weniger als 4094 VLANs benötigen. Mit der wachsenden Einführung der Virtualisierung steht diese Obergrenze unter Druck. Darüber hinaus begrenzen aufgrund von STP mehrere Rechenzentren die Anzahl der VLANs, die verwendet werden könnten. Darüber hinaus beschleunigen Anforderungen für Mehrbenutzer-Umgebungen den Bedarf an größeren VLAN-Grenzen, wie in Abschnitt 3.2 diskutiert.
3.2. Multi-tenant Environments (Mehrbenutzer-Umgebungen)
Cloud Computing beinhaltet die bedarfsgesteuerte elastische Bereitstellung von Ressourcen für Mehrbenutzer-Umgebungen. Das häufigste Beispiel für Cloud Computing ist die öffentliche Cloud, bei der ein Cloud-Service-Provider diese elastischen Dienste mehreren Kunden/Mandanten über dieselbe physische Infrastruktur anbietet.
Die Isolierung des Netzwerkverkehrs durch einen Mandanten kann über Schicht-2- oder Schicht-3-Netzwerke erfolgen. Für Schicht-2-Netzwerke werden häufig VLANs verwendet, um den Verkehr zu trennen – so könnte ein Mandant beispielsweise durch sein eigenes VLAN identifiziert werden. Aufgrund der großen Anzahl von Mandanten, die ein Cloud-Anbieter bedienen könnte, ist die VLAN-Grenze von 4094 oft unzureichend. Darüber hinaus besteht oft ein Bedarf an mehreren VLANs pro Mandant, was das Problem verschärft.
Ein verwandter Anwendungsfall ist die Pod-übergreifende Erweiterung. Ein Pod besteht typischerweise aus einem oder mehreren Server-Racks mit zugehöriger Netzwerk- und Speicherkonnektivität. Mandanten können auf einem Pod beginnen und aufgrund der Erweiterung Server/VMs auf anderen Pods benötigen, insbesondere in dem Fall, wenn Mandanten auf den anderen Pods nicht alle ihre Ressourcen vollständig ausnutzen. Dieser Anwendungsfall erfordert eine "gestreckte" Schicht-2-Umgebung, die die einzelnen Server/VMs verbindet.
Schicht-3-Netzwerke sind auch keine umfassende Lösung für Mehrmandantenfähigkeit. Zwei Mandanten könnten denselben Satz von Schicht-3-Adressen in ihren Netzwerken verwenden, was den Cloud-Anbieter erfordert, die Isolierung in einer anderen Form bereitzustellen. Darüber hinaus schließt die Anforderung, dass alle Mandanten IP verwenden, Kunden aus, die auf direkte Schicht-2- oder Nicht-IP-Schicht-3-Protokolle für die Inter-VM-Kommunikation angewiesen sind.
3.3. Inadequate Table Sizes at ToR Switch (Unzureichende Tabellengrößen am ToR-Switch)
Die heutigen virtualisierten Umgebungen stellen zusätzliche Anforderungen an die MAC-Adresstabellen von Top-of-Rack (ToR)-Switches, die mit den Servern verbunden sind. Anstelle von nur einer MAC-Adresse pro Server-Link muss der ToR jetzt die MAC-Adressen der einzelnen VMs lernen (die sich auf Hunderte pro Server belaufen könnten). Dies ist erforderlich, da der Verkehr zu/von den VMs zum Rest des physischen Netzwerks den Link zwischen dem Server und dem Switch durchqueren wird. Ein typischer ToR-Switch könnte abhängig von der Anzahl seiner serverzugewandten Ports mit 24 oder 48 Servern verbunden werden. Ein Rechenzentrum könnte aus mehreren Racks bestehen, sodass jeder ToR-Switch eine Adresstabelle für die kommunizierenden VMs über die verschiedenen physischen Server hinweg pflegen müsste. Dies stellt im Vergleich zu nicht virtualisierten Umgebungen eine viel größere Anforderung an die Tabellenkapazität.
Wenn die Tabelle überläuft, kann der Switch aufhören, neue Adressen zu lernen, bis Leerlaufeinträge altern, was zu erheblichem Flooding nachfolgender Frames mit unbekanntem Ziel führt.