3. Data Center Topologies Overview (Panoramica delle topologie dei data center)
3. Data Center Topologies Overview (Panoramica delle topologie dei data center)
Questa sezione fornisce una panoramica di due tipi generali di progetti di data center -- gerarchici (noti anche come "basati su albero") e basati su Clos.
3.1 Traditional DC Topology (Topologia tradizionale dei data center)
Nell'industria del networking, una scelta di progettazione comune per i data center assomiglia tipicamente a un albero (capovolto) con uplink ridondanti e tre livelli di gerarchia, vale a dire core, aggregazione/distribuzione e livelli di accesso (vedi Figura 1). Per soddisfare le richieste di larghezza di banda, ogni livello superiore, dal server verso l'uscita del DC o la WAN, ha una densità di porte e una capacità di larghezza di banda più elevate dove il core funziona come il "tronco" del design basato su albero. Per mantenere una terminologia uniforme e per il confronto con altri design, in questo documento questi livelli saranno chiamati tier Tier 1, Tier 2 e Tier 3, invece di livelli core, aggregazione o accesso.
+------+ +------+
| | | |
| |--| | Tier 1
| | | |
+------+ +------+
| | | |
+---------+ | | +----------+
| +-------+--+------+--+-------+ |
| | | | | | | |
+----+ +----+ +----+ +----+
| | | | | | | |
| |-----| | | |-----| | Tier 2
| | | | | | | |
+----+ +----+ +----+ +----+
| | | |
| | | |
| +-----+ | | +-----+ |
+-| |-+ +-| |-+ Tier 3
+-----+ +-----+
| | | | | |
<- Servers -> <- Servers ->
Figura 1: Topologia di rete tipica dei data center
Sfortunatamente, come notato in precedenza, non è possibile scalare un design basato su albero a un grado sufficientemente grande per gestire design su larga scala a causa dell'impossibilità di acquisire dispositivi Tier 1 con una densità di porte sufficientemente grande per scalare adeguatamente Tier 2. Inoltre, sono necessari aggiornamenti continui o la sostituzione dei dispositivi di livello superiore man mano che la dimensione del deployment o i requisiti di larghezza di banda aumentano, il che è operativamente complesso. Per questo motivo, REQ1 è in atto, eliminando questo tipo di design dalla considerazione.
3.2 Clos Network Topology (Topologia di rete Clos)
Questa sezione descrive un design comune per una topologia scalabile orizzontalmente nei data center su larga scala al fine di soddisfare REQ1.
3.2.1 Overview (Panoramica)
Una scelta comune per una topologia scalabile orizzontalmente è una topologia Clos ripiegata, a volte chiamata "fat-tree" (ad esempio, [INTERCON] e [ALFARES2008]). Questa topologia presenta un numero dispari di stadi (a volte noti come "dimensioni") ed è comunemente composta da elementi uniformi, ad esempio switch di rete con lo stesso numero di porte. Pertanto, la scelta della topologia Clos ripiegata soddisfa REQ1 e facilita REQ2. Vedere la Figura 2 di seguito per un esempio di topologia Clos ripiegata a 3 stadi (3 stadi contando lo stadio Tier 2 due volte, quando si traccia un flusso di pacchetti):
+-------+
| |----------------------------+
| |------------------+ |
| |--------+ | |
+-------+ | | |
+-------+ | | |
| |--------+---------+-------+ |
| |--------+-------+ | | |
| |------+ | | | | |
+-------+ | | | | | |
+-------+ | | | | | |
| |------+-+-------+-+-----+ | |
| |------+-+-----+ | | | | |
| |----+ | | | | | | | |
+-------+ | | | | | | ---------> M collegamenti
Tier 1 | | | | | | | | |
+-------+ +-------+ +-------+
| | | | | |
| | | | | | Tier 2
| | | | | |
+-------+ +-------+ +-------+
| | | | | | | | |
| | | | | | ---------> N Collegamenti
| | | | | | | | |
O O O O O O O O O Server
Figura 2: Topologia Clos ripiegata a 3 stadi
Questa topologia è spesso indicata anche come rete "Leaf and Spine", dove "Spine" è il nome dato allo stadio intermedio della topologia Clos (Tier 1) e "Leaf" è il nome dello stadio di input/output (Tier 2). Per uniformità, questo documento farà riferimento a questi livelli utilizzando la notazione "Tier n".
3.2.2 Clos Topology Properties (Proprietà della topologia Clos)
Le seguenti sono alcune proprietà chiave della topologia Clos:
-
La topologia è completamente non-bloccante, o più precisamente non-interferente, se M >= N e sovraiscritta di un fattore di N/M altrimenti. Qui M e N sono rispettivamente il conteggio delle porte uplink e downlink per uno switch Tier 2 come mostrato nella Figura 2.
-
L'utilizzo di questa topologia richiede il supporto del piano di controllo e dati per ECMP con un fan-out di M o più.
-
Gli switch Tier 1 hanno esattamente un percorso verso ogni server in questa topologia. Questa è una proprietà importante che rende pericolosa la summarizzazione delle route in questa topologia (vedere la Sezione 8.2 di seguito).
-
Il traffico che fluisce da server a server è bilanciato in carico su tutti i percorsi disponibili utilizzando ECMP.
3.2.3 Scaling the Clos Topology (Scalare la topologia Clos)
Una topologia Clos può essere scalata aumentando la densità delle porte degli elementi di rete o aggiungendo più stadi, ad esempio passando a un Clos a 5 stadi, come illustrato nella Figura 3 di seguito:
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
| Server | Server
+----------------------------+
Figura 3: Topologia Clos a 5 stadi
Il piccolo esempio di topologia nella Figura 3 è costruito da dispositivi con un conteggio di porte di 4. In questo documento, un insieme di dispositivi Tier 2 e Tier 3 direttamente connessi insieme ai loro server collegati sarà chiamato "cluster". Ad esempio, DEV A, B, C, D e i server che si collegano a DEV A e B, nella Figura 3 formano un cluster. Il concetto di cluster può anche essere un concetto utile come singola unità di deployment o manutenzione che può essere operata a una frequenza diversa rispetto all'intera topologia.
In pratica, Tier 3 della rete, che è tipicamente costituito da switch Top-of-Rack (ToR), è dove viene introdotta la sovrascrizione per consentire di impacchettare più server nel data center soddisfacendo al contempo i requisiti di larghezza di banda per diversi tipi di applicazioni. Il motivo principale per limitare la sovrascrizione a un singolo livello della rete è semplificare lo sviluppo delle applicazioni che altrimenti dovrebbero tenere conto di più pool di larghezza di banda: all'interno del rack (Tier 3), tra i rack (Tier 2) e tra i cluster (Tier 1). Poiché la sovrascrizione non ha una relazione diretta con il design del routing, non viene ulteriormente discussa in questo documento.
3.2.4 Managing the Size of Clos Topology Tiers (Gestione della dimensione dei tier della topologia Clos)
Se la dimensione di una rete di data center è piccola, è possibile ridurre il numero di switch in Tier 1 o Tier 2 di una topologia Clos di un fattore di due. Per capire come questo potrebbe essere fatto, prendiamo Tier 1 come esempio. Ogni dispositivo Tier 2 si connette a un singolo gruppo di dispositivi Tier 1. Se metà delle porte su ciascuno dei dispositivi Tier 1 non viene utilizzata, allora è possibile ridurre il numero di dispositivi Tier 1 della metà e semplicemente mappare due uplink da un dispositivo Tier 2 allo stesso dispositivo Tier 1 che erano precedentemente mappati a diversi dispositivi Tier 1. Questa tecnica mantiene la stessa larghezza di banda riducendo il numero di elementi in Tier 1, risparmiando così su CAPEX. Il compromesso, in questo esempio, è la riduzione della dimensione massima del DC in termini di numero complessivo di server della metà.
In questo esempio, i dispositivi Tier 2 utilizzeranno due collegamenti paralleli per connettersi a ciascun dispositivo Tier 1. Se uno di questi collegamenti fallisce, l'altro raccoglierà tutto il traffico del collegamento fallito, possibilmente causando una forte congestione e un degrado della qualità del servizio se la procedura di determinazione del percorso non tiene conto della quantità di larghezza di banda, poiché il numero di dispositivi Tier 1 upstream è probabilmente più ampio di due. Per evitare questa situazione, i collegamenti paralleli possono essere raggruppati in gruppi di aggregazione di collegamenti (LAG), ad esempio [IEEE8023AD], con impostazioni di implementazione ampiamente disponibili che portano giù l'intero "bundle" al verificarsi di un singolo guasto di collegamento. Tecniche equivalenti che impongono la "condivisione del destino" sui collegamenti paralleli possono essere utilizzate al posto dei LAG per ottenere lo stesso effetto. Come risultato di tale condivisione del destino, il traffico di due o più collegamenti falliti sarà riequilibrato sulla moltitudine di percorsi rimanenti che equivale al numero di dispositivi Tier 1. Questo esempio utilizza due collegamenti per semplicità, avere più collegamenti in un bundle avrà meno impatto sulla capacità al verificarsi di un guasto di un collegamento membro.