Massimizza le prestazioni di Azure Stack HCI: scopri le migliori configurazioni per il networking

Le infrastrutture iperconvergenti (HCI) sono sempre più diffuse in quanto consentono di semplificare la gestione dell’ambiente IT, ridurre i costi e scalare facilmente in caso di necessità. Azure Stack HCI è la soluzione Microsoft che permette di realizzare una infrastruttura hyper-converged per l’esecuzione di workload in ambiente on-premises e che prevede una strategica connessione a vari servizi di Azure per modernizzare la propria infrastruttura IT. Configurare correttamente il networking di Azure Stack HCI è fondamentale per garantire la sicurezza, l’affidabilità e le prestazioni delle applicazioni. In questo articolo, vengono esplorati i fondamenti della configurazione del networking di Azure Stack HCI, approfondendo le opzioni di rete disponibili e le best practice per la progettazione e la configurazione del networking.

Sono differenti i modelli di rete che è possibile prendere come riferimento per progettare, distribuire e configurare Azure Stack HCI. Nei paragrafi seguenti vengono riportati gli aspetti principali da considerare per indirizzare le possibili scelte di implementazione a livello di rete.

Numero di nodi che compongono il cluster Azure Stack HCI

Un singolo cluster Azure Stack HCI può essere composto da un unico nodo e può scalare fino a 16 nodi.

Se il cluster è composto da un singolo server a livello fisico è consigliato prevedere i seguenti componenti di rete, riportati anche nell’immagine:

• singolo switch TOR (L2 oppure L3) per il traffico in direzione nord-sud;
• due\quattro porte di rete in team per gestire il traffico di management e computazionale collegate allo switch;

Inoltre, opzionalmente è possibile prevedere i seguenti componenti:

• due NIC RDMA, utili se si prevede di aggiunge un secondo server al cluster per scalare la configurazione;
• una scheda BMC per la gestione remota dell’ambiente.

Se il cluster Azure Stack HCI è composto da due o più nodi è necessario approfondire i parametri seguenti.

Necessità di switch Top-Of-Rack (TOR) e relativo livello di ridondanza

Per i cluster Azure Stack HCI composti da due o più nodi, in ambiente di produzione, è fortemente consigliata la presenza di due switch TOR, in modo da poter tollerare interruzioni delle comunicazioni riguardanti il traffico nord-sud, in caso di guasto oppure di manutenzione del singolo switch fisico.

Se il cluster Azure Stack HCI è composto da due nodi si può fare in modo di non prevedere una connettività tramite switch per il traffico riguardante lo storage.

Configurazione a due nodi senza switch TOR per la comunicazione storage

In un cluster Azure Stack HCI composto da solo due nodi, per ridurre i costi degli switch, andando magari ad utilizzare switch già in possesso, è possibile collegare in modalità full-mesh le NIC RDMA dello storage.

In determinati scenari, che includono ad esempio branch office, oppure laboratori, si può adottare il seguente modello di rete che prevede un unico switch TOR. Applicando questo modello si ottiene una tolleranza agli errori a livello di cluster, ed è idonea se è possibile tollerare interruzioni della connettività in direzione nord-sud quando il singolo switch fisico si guasta oppure richiede manutenzione.

Sebbene i servizi SDN L3 siano pienamente supportati per questo schema, i servizi di routing come BGP dovranno essere configurati sul dispositivo firewall che si trovano sopra allo switch TOR, se questo non supporta i servizi L3.

Nel caso si voglia ottenere una maggiore tolleranza ai guasti per tutti i componenti di rete è possibile prevedere la seguente architettura, che prevede due switch TOR ridondati:

I servizi SDN L3 sono pienamente supportati da questo schema. I servizi di routing come BGP possono essere configurati direttamente sugli switch TOR se questi supportano i servizi L3. Le funzionalità legate alla sicurezza della rete non richiedono una configurazione aggiuntiva per il dispositivo firewall, poiché sono implementate a livello di virtual network adapter.

A livello fisico è consigliato prevedere i seguenti componenti di rete per ciascun server:

• duequattro porte di rete in team, per gestire il traffico di management e computazionale, collegate alloagli switch TOR;
• due NIC RDMA in una configurazione full-mesh per il traffico est-ovest per lo storage. Ogni nodo del cluster deve avere una connessione ridondata all’altro nodo del cluster;
• come opzionale, una scheda BMC per la gestione remota dell’ambiente.

In entrambi i casi sono necessarie le seguenti connettività:

Reti	Management e computazionale	Storage	BMC
Velocità di rete	Almeno 1 GBps, 10 GBps recommendata	Almeno 10 GBps	Tbd
Tipologia di interfaccia	RJ45, SFP+ oppure SFP28	SFP+ oppure SFP28	RJ45
Porte e aggregazione	Duequattro porte in teaming	Due porte standalone	Una porta

Configurazione a due o più nodi utilizzando switch TOR anche per la comunicazione storage

Quando si prevede un cluster Azure Stack HCI composto da più di due nodi oppure se non si vuole precludere la possibilità di poter aggiungere facilmente ulteriori nodi al cluster, è necessario far confluire anche il traffico riguardante lo storage dagli switch TOR. In questi scenari si può prevedere una configurazione dove si mantengono delle schede di rete dedicate per il traffico storage (non-converged), come mostrato nella seguente immagine:

A livello fisico è consigliato prevedere i seguenti componenti di rete per ciascun server:

• due schede di rete in team per gestire il traffico di management e computazionale. Ogni NIC è collegata a uno switch TOR diverso;
• due NIC RDMA in configurazione standalone. Ogni NIC è collegata a uno switch TOR diverso. La funzionalità multicanale SMB garantisce l’aggregazione dei percorsi e la tolleranza agli errori;
• come opzionale, una scheda BMC per la gestione remota dell’ambiente.

Queste le connettività previste:

Reti	Management e computazionale	Storage	BMC
Velocità di rete	Almeno 1 GBps, 10 GBps recommendata	Almeno 10 GBps	Tbd
Tipologia di interfaccia	RJ45, SFP+ oppure SFP28	SFP+ oppure SFP28	RJ45
Porte e aggregazione	Due porte in teaming	Due porte standalone	Una porta

Un’altra possibilità da tenere in considerazione prevede una configurazione “fully-converged” delle schede di rete, come riportato nella seguente immagine:

Quest’ultima soluzione è preferibile quando:

• i requisiti di larghezza di banda per il traffico nord-sud non richiedono schede dedicate;
• le porte fisiche degli switch sono un numero ridotto;
• si vogliono mantenere contenuti i costi della soluzione.

A livello fisico è consigliato prevedere i seguenti componenti di rete per ciascun server:

• due schede di rete RDMA in team per il traffico di management, computazionale e storage. Ogni NIC è collegata a uno switch TOR diverso. La funzionalità multicanale SMB garantisce l’aggregazione dei percorsi e la tolleranza agli errori;
• come opzionale, una scheda BMC per la gestione remota dell’ambiente.

Queste le connettività previste:

Reti	Management, computazionale e storage	BMC
Velocità di rete	Almeno 10 GBps	Tbd
Tipologia di interfaccia	SFP+ oppure SFP28	RJ45
Porte e aggregazione	Due porte in teaming	Una porta

I servizi SDN L3 sono pienamente supportati da entrambi i modelli sopra riportati. I servizi di routing come BGP possono essere configurati direttamente sugli switch TOR se questi supportano i servizi L3. Le funzionalità legate alla sicurezza della rete non richiedono una configurazione aggiuntiva per il dispositivo firewall, poiché sono implementate a livello di virtual network adapter.

Tipologia di traffico che deve passare dagli switch TOR

Per scegliere gli switch TOR più adatti è necessario valutare il traffico di rete che confluirà da tali apparati di rete, il quale può essere suddiviso in:

• traffico di management;
• traffico computazionale (generato dai workload ospitati dal cluster), il quale può essere suddiviso in due categorie:
  • traffico standard;
  • traffico SDN;
• traffico storage.

Microsoft ha recentemente cambiato l’approccio a riguardo. Infatti, non è più richiesto che gli switch TOR rispettino ogni requisito di rete riguardante le varie funzionalità, indipendentemente dal tipo di traffico per il quale lo switch viene utilizzato. Questo consente di avere switch fisici supportati in base al tipo di traffico che trasportano e permette di poter scegliere tra un maggior numero di dispositivi di rete ad un costo più contenuto, ma sempre di qualità.

In questo documento sono elencati gli standard di settore obbligatori per i ruoli specifici degli switch di rete utilizzati nelle implementazioni di Azure Stack HCI. Questi standard contribuiscono a garantire comunicazioni affidabili tra i nodi dei cluster Azure Stack HCI. In questa sezione sono invece riportati i modelli degli switch supportati dai vari vendor, in base alla tipologia di traffico prevista.

Conclusioni

Configurare correttamente il networking di Azure Stack HCI è fondamentale per garantire che l’infrastruttura hyper-converged funzioni in modo corretto, garantendo sicurezza, affidabilità e prestazioni ottimali. In questo articolo sono stati riportati i concetti fondamentali riguardanti la configurazione del networking di Azure Stack HCI, analizzando le opzioni di rete disponibili. Il consiglio è di pianificare sempre attentamente gli aspetti legati al networking di Azure Stack HCI, scegliendo l’opzione di rete più appropriata per le esigenze del vostro business e seguendo le best practice di implementazione.