3. Data Center Topologies Overview (Übersicht über Rechenzentrum-Topologien)

Dieser Abschnitt bietet einen Überblick über zwei allgemeine Arten von Rechenzentrum-Designs -- hierarchische (auch bekannt als "baumbasierte") und Clos-basierte Netzwerk-Designs.

3.1 Traditional DC Topology (Traditionelle Rechenzentrum-Topologie)

In der Netzwerkbranche sieht eine übliche Design-Wahl für Rechenzentren typischerweise wie ein (auf dem Kopf stehender) Baum mit redundanten Uplinks und drei Hierarchieebenen aus, nämlich Core-, Aggregations-/Verteilungs- und Access-Schichten (siehe Abbildung 1). Um Bandbreitenanforderungen zu erfüllen, hat jede höhere Schicht, vom Server in Richtung DC-Ausgang oder WAN, eine höhere Port-Dichte und Bandbreitenkapazität, wobei der Core als "Stamm" des baumbasierten Designs fungiert. Um die Terminologie einheitlich zu halten und für den Vergleich mit anderen Designs, werden diese Schichten in diesem Dokument als Tier 1, Tier 2 und Tier 3 "Tiers" bezeichnet, anstatt als Core-, Aggregations- oder Access-Schichten.

             +------+  +------+
             |      |  |      |
             |      |--|      |           Tier 1
             |      |  |      |
             +------+  +------+
               |  |      |  |
     +---------+  |      |  +----------+
     | +-------+--+------+--+-------+  |
     | |       |  |      |  |       |  |
   +----+     +----+    +----+     +----+
   |    |     |    |    |    |     |    |
   |    |-----|    |    |    |-----|    | Tier 2
   |    |     |    |    |    |     |    |
   +----+     +----+    +----+     +----+
      |         |          |         |
      |         |          |         |
      | +-----+ |          | +-----+ |
      +-|     |-+          +-|     |-+    Tier 3
        +-----+              +-----+
         | | |                | | |
     <- Servers ->        <- Servers ->

                   Abbildung 1: Typische Rechenzentrum-Netzwerk-Topologie

Leider ist es, wie zuvor erwähnt, nicht möglich, ein baumbasiertes Design in einem ausreichend großen Umfang für die Handhabung von großen Designs zu skalieren, da es nicht möglich ist, Tier-1-Geräte mit einer ausreichend großen Port-Dichte zu erwerben, um Tier 2 ausreichend zu skalieren. Außerdem sind kontinuierliche Upgrades oder der Austausch der Geräte der oberen Ebene erforderlich, wenn die Bereitstellungsgröße oder die Bandbreitenanforderungen zunehmen, was betrieblich komplex ist. Aus diesem Grund ist REQ1 vorhanden, das diese Art von Design von der Betrachtung ausschließt.

3.2 Clos Network Topology (Clos-Netzwerk-Topologie)

Dieser Abschnitt beschreibt ein gängiges Design für horizontal skalierbare Topologie in großen Rechenzentren, um REQ1 zu erfüllen.

3.2.1 Overview (Übersicht)

Eine gängige Wahl für eine horizontal skalierbare Topologie ist eine gefaltete Clos-Topologie, manchmal auch "Fat-Tree" genannt (zum Beispiel [INTERCON] und [ALFARES2008]). Diese Topologie weist eine ungerade Anzahl von Stufen auf (manchmal als "Dimensionen" bezeichnet) und besteht üblicherweise aus einheitlichen Elementen, z. B. Netzwerk-Switches mit derselben Port-Anzahl. Daher erfüllt die Wahl der gefalteten Clos-Topologie REQ1 und erleichtert REQ2. Siehe Abbildung 2 unten für ein Beispiel einer gefalteten 3-Stufen-Clos-Topologie (3 Stufen, wobei die Tier-2-Stufe zweimal gezählt wird, wenn man einen Paketfluss verfolgt):

   +-------+
   |       |----------------------------+
   |       |------------------+         |
   |       |--------+         |         |
   +-------+        |         |         |
   +-------+        |         |         |
   |       |--------+---------+-------+ |
   |       |--------+-------+ |       | |
   |       |------+ |       | |       | |
   +-------+      | |       | |       | |
   +-------+      | |       | |       | |
   |       |------+-+-------+-+-----+ | |
   |       |------+-+-----+ | |     | | |
   |       |----+ | |     | | |     | | |
   +-------+    | | |     | | |   ---------> M Links
    Tier 1      | | |     | | |     | | |
              +-------+ +-------+ +-------+
              |       | |       | |       |
              |       | |       | |       | Tier 2
              |       | |       | |       |
              +-------+ +-------+ +-------+
                | | |     | | |     | | |
                | | |     | | |   ---------> N Links
                | | |     | | |     | | |
                O O O     O O O     O O O   Servers

                  Abbildung 2: 3-Stufen gefaltete Clos-Topologie

Diese Topologie wird oft auch als "Leaf and Spine"-Netzwerk bezeichnet, wobei "Spine" der Name für die mittlere Stufe der Clos-Topologie (Tier 1) ist und "Leaf" der Name der Eingangs-/Ausgangs-Stufe (Tier 2) ist. Zur Einheitlichkeit wird dieses Dokument auf diese Schichten mit der "Tier n"-Notation verweisen.

3.2.2 Clos Topology Properties (Eigenschaften der Clos-Topologie)

Im Folgenden sind einige wichtige Eigenschaften der Clos-Topologie aufgeführt:

Die Topologie ist vollständig nicht-blockierend, oder genauer gesagt nicht-störend, wenn M >= N ist, und ansonsten um einen Faktor von N/M überzeichnet. Hier sind M und N die Uplink- bzw. Downlink-Port-Anzahl für einen Tier-2-Switch, wie in Abbildung 2 gezeigt.
Die Nutzung dieser Topologie erfordert Unterstützung der Steuerungs- und Datenebene für ECMP mit einem Fan-Out von M oder mehr.
Tier-1-Switches haben in dieser Topologie genau einen Pfad zu jedem Server. Dies ist eine wichtige Eigenschaft, die die Routen-Aggregation in dieser Topologie gefährlich macht (siehe Abschnitt 8.2 unten).
Der Verkehr, der von Server zu Server fließt, wird über alle verfügbaren Pfade unter Verwendung von ECMP lastverteilt.

3.2.3 Scaling the Clos Topology (Skalierung der Clos-Topologie)

Eine Clos-Topologie kann entweder durch Erhöhung der Port-Dichte der Netzwerkelemente oder durch Hinzufügen weiterer Stufen skaliert werden, z. B. durch den Übergang zu einer 5-Stufen-Clos, wie in Abbildung 3 unten dargestellt:

                                      Tier 1
                                     +-----+
          Cluster                    |     |
 +----------------------------+   +--|     |--+
 |                            |   |  +-----+  |
 |                    Tier 2  |   |           |   Tier 2
 |                   +-----+  |   |  +-----+  |  +-----+
 |     +-------------| DEV |------+--|     |--+--|     |-------------+
 |     |       +-----|  C  |------+  |     |  +--|     |-----+       |
 |     |       |     +-----+  |      +-----+     +-----+     |       |
 |     |       |              |                              |       |
 |     |       |     +-----+  |      +-----+     +-----+     |       |
 |     | +-----------| DEV |------+  |     |  +--|     |-----------+ |
 |     | |     | +---|  D  |------+--|     |--+--|     |---+ |     | |
 |     | |     | |   +-----+  |   |  +-----+  |  +-----+   | |     | |
 |     | |     | |            |   |           |            | |     | |
 |   +-----+ +-----+          |   |  +-----+  |          +-----+ +-----+
 |   | DEV | | DEV |          |   +--|     |--+          |     | |     |
 |   |  A  | |  B  | Tier 3   |      |     |      Tier 3 |     | |     |
 |   +-----+ +-----+          |      +-----+             +-----+ +-----+
 |     | |     | |            |                            | |     | |
 |     O O     O O            |                            O O     O O
 |       Servers              |                              Servers
 +----------------------------+

                      Abbildung 3: 5-Stufen-Clos-Topologie

Das kleine Beispiel der Topologie in Abbildung 3 ist aus Geräten mit einer Port-Anzahl von 4 aufgebaut. In diesem Dokument wird eine Gruppe von direkt verbundenen Tier-2- und Tier-3-Geräten zusammen mit ihren angeschlossenen Servern als "Cluster" bezeichnet. Zum Beispiel bilden DEV A, B, C, D und die Server, die mit DEV A und B verbunden sind, in Abbildung 3 einen Cluster. Das Konzept eines Clusters kann auch als einzelne Bereitstellungs- oder Wartungseinheit nützlich sein, die mit einer anderen Frequenz als die gesamte Topologie betrieben werden kann.

In der Praxis ist Tier 3 des Netzwerks, das typischerweise Top-of-Rack-Switches (ToRs) sind, der Ort, an dem Überzeichnung eingeführt wird, um das Verpacken von mehr Servern im Rechenzentrum zu ermöglichen und gleichzeitig die Bandbreitenanforderungen für verschiedene Arten von Anwendungen zu erfüllen. Der Hauptgrund, die Überzeichnung auf eine einzige Schicht des Netzwerks zu beschränken, besteht darin, die Anwendungsentwicklung zu vereinfachen, die ansonsten mehrere Bandbreiten-Pools berücksichtigen müsste: innerhalb des Racks (Tier 3), zwischen Racks (Tier 2) und zwischen Clustern (Tier 1). Da die Überzeichnung keine direkte Beziehung zum Routing-Design hat, wird sie in diesem Dokument nicht weiter diskutiert.

3.2.4 Managing the Size of Clos Topology Tiers (Verwaltung der Größe von Clos-Topologie-Tiers)

Wenn die Größe eines Rechenzentrum-Netzwerks klein ist, ist es möglich, die Anzahl der Switches in Tier 1 oder Tier 2 einer Clos-Topologie um einen Faktor von zwei zu reduzieren. Um zu verstehen, wie dies geschehen könnte, nehmen Sie Tier 1 als Beispiel. Jedes Tier-2-Gerät verbindet sich mit einer einzigen Gruppe von Tier-1-Geräten. Wenn die Hälfte der Ports auf jedem der Tier-1-Geräte nicht verwendet wird, ist es möglich, die Anzahl der Tier-1-Geräte um die Hälfte zu reduzieren und einfach zwei Uplinks von einem Tier-2-Gerät auf dasselbe Tier-1-Gerät abzubilden, die zuvor auf verschiedene Tier-1-Geräte abgebildet waren. Diese Technik erhält die gleiche Bandbreite bei gleichzeitiger Reduzierung der Anzahl der Elemente in Tier 1 und spart somit CAPEX. Der Kompromiss in diesem Beispiel ist die Reduzierung der maximalen DC-Größe in Bezug auf die Gesamtanzahl der Server um die Hälfte.

In diesem Beispiel verwenden Tier-2-Geräte zwei parallele Links, um sich mit jedem Tier-1-Gerät zu verbinden. Wenn einer dieser Links ausfällt, übernimmt der andere den gesamten Verkehr des ausgefallenen Links, was möglicherweise zu starker Überlastung und Verschlechterung der Dienstgüte führt, wenn das Pfadbestimmungsverfahren die Bandbreitenmenge nicht berücksichtigt, da die Anzahl der vorgelagerten Tier-1-Geräte wahrscheinlich größer als zwei ist. Um diese Situation zu vermeiden, können parallele Links in Link-Aggregationsgruppen (LAGs) gruppiert werden, z. B. [IEEE8023AD], mit weit verbreiteten Implementierungseinstellungen, die das gesamte "Bündel" bei einem einzelnen Link-Ausfall herunterfahren. Äquivalente Techniken, die "Fate Sharing" auf den parallelen Links erzwingen, können anstelle von LAGs verwendet werden, um denselben Effekt zu erzielen. Als Ergebnis eines solchen Fate-Sharing wird der Verkehr von zwei oder mehr ausgefallenen Links über die Vielzahl der verbleibenden Pfade neu verteilt, die der Anzahl der Tier-1-Geräte entsprechen. Dieses Beispiel verwendet zwei Links zur Vereinfachung, bei mehr Links in einem Bündel wird ein Ausfall eines Mitglieds-Links weniger Auswirkungen auf die Kapazität haben.