Azure VMware Solution - Networking Aspects

Azure VMware Solution - Networking Aspects

Introduzione

Azure VMware Solution (AVS) rappresenta una soluzione cloud ibrida chiave che consente alle organizzazioni di eseguire workload VMware nativamente nell'ecosistema Microsoft Azure. Questa offerta enterprise permette di migrare e modernizzare le applicazioni VMware esistenti senza affrontare i costi e i rischi associati a un refactoring completo dell'infrastruttura.

1.00

Microsoft, in qualità di membro del programma VMware Metal-as-a-Service (MaaS), sfrutta VMware Cloud Provider Stack (VCPS) per orchestrare efficacemente la pianificazione degli aggiornamenti di Azure VMware Solution. Questa collaborazione tecnologica rappresenta un vantaggio competitivo significativo per le organizzazioni enterprise.

Un beneficio sostanziale di AVS è la gestione completa dell'infrastruttura sottostante. Microsoft assume la responsabilità integrale del ciclo di vita dei componenti critici VMware (ESXi, vCenter, vSAN, NSX).

Microsoft gestisce proattivamente:

  1. L'applicazione di patch e aggiornamenti all'intero stack VMware nel cloud privato
  2. Il bootstrap della configurazione di rete, inclusa la creazione del gateway di livello T0
  3. L'abilitazione del routing verticale nord-sud per garantire connettività ottimale

Si è responsabili della configurazione di NSX SDN: segmenti di rete, regole del firewall distribuite, gateway di livello 1 e servizi di bilanciamento del carico.

Per le configurazioni di HCX Manager e del server vCenter è pianificato un backup giornaliero, mentre per la configurazione NSX è pianificato un backup orario. Questi backup vengono conservati per un minimo di tre giorni.

Casi d'uso ideali

  1. Migrazione datacenter - Trasferimento rapido dell'intero parco VMware
  2. Disaster Recovery - Implementazione di soluzioni DR verso il cloud
  3. Espansione delle capacità (bursting) - Estensione delle risorse on-premises
  4. Modernizzazione graduale - Accesso ai servizi cloud mantenendo l'infrastruttura attuale

Cos'è Azure VMware Solution?

Azure VMware Solution offre cloud privati enterprise-grade basati su cluster VMware vSphere, implementati su infrastruttura Azure bare metal dedicata.

  • Host server bare metal dedicati di cui è stato effettuato il provisioning con l'hypervisor VMware ESXi
  • Server VMware vCenter per la gestione di ESXi e vSAN
  • Software-Defined Networking VMware NSX per le macchine virtuali del carico di lavoro vSphere
  • Archivio dati VMware vSAN per le macchine virtuali del carico di lavoro vSphere
  • VMware HCX per la mobilità del carico di lavoro

1.00

La suite di tecnologie HCX facilita la migrazione e la protezione dei workload tra ambienti diversi, fornendo:

  • Migrazione in tempo reale senza interruzioni di servizio
  • Estensione Layer 2 per preservare gli indirizzi IP
  • Connettività sicura e ottimizzata tra data center

Si utilizzano vCenter Server e NSX Manager come hub di controllo centrali per amministrare in modo completo la configurazione e l'operatività del cluster.

Servizi come Azure ExpressRoute o Virtual WAN di Azure offrono la connettività. Per connettere i cloud privati agli ambienti on-premises viene usato il servizio ExpressRoute Global Reach.

Concetti generali

Quando si distribuisce Azure VMware Solution, si ottiene un'infrastruttura di base che comprende:

  • Minimo tre nodi fisici per garantire alta disponibilità e resilienza
  • Un circuito ExpressRoute dedicato per connettività sicura e a bassa latenza

1.00

Poiché l'ambiente AVS viene distribuito su server bare metal dedicati, è fondamentale eseguire il peering in Azure per stabilire la connettività di rete con altri servizi e risorse Azure. Questo requisito deriva dalla natura dell'infrastruttura fisica isolata che richiede configurazioni di rete esplicite per l'integrazione.

Per accedere alla soluzione Azure VMware dall'ambiente locale tramite ExpressRoute è necessario implementare Global Reach in quanto il gateway ExpressRoute non fornisce routing transitivo tra i circuiti diversi.

1.00

Global Reach gestisce l'instradamento del traffico est-ovest tra i due circuiti utilizzando BGP.

1.00

Quando Global Reach non è disponibile o esistono requisiti specifici (come l'ispezione del traffico), è possibile progettare la connettività di rete con Azure Route Server per lo scambio di rotte.

1.00

Va notato che questa soluzione alternativa introduce maggiore complessità, come descritto in documentazione: "L'opzione preferita per connettere Azure VMware Solution e ambienti on-premises è una connessione ExpressRoute Global Reach diretta".

I prossimi paragrafi esplorano i concetti di networking fondamentali. Ciascun elemento tecnico verrà analizzato costruendo progressivamente la comprensione necessaria per comprendere questa tecnologia.

Architettura Spine & Leaf

L'architettura Spine-and-Leaf rappresenta un modello topologico di rete a due livelli progettato principalmente per data center moderni. Questa architettura si basa sul design Clos originariamente sviluppato negli anni '50 da Charles Clos per le reti telefoniche.

1.00

Si discosta dal tradizionale design a tre livelli, offrendo maggiore efficienza e scalabilità. Un vantaggio fondamentale è che permette di espandere l'infrastruttura del data center orizzontalmente anziché verticalmente.

E' composta da due livelli principali:

  1. Spine Layer (Livello Dorsale): Costituisce la "spina dorsale" della rete

    • Switch spine interconnessi con tutti gli switch leaf in una topologia a maglia completa
    • Funzionano tipicamente come switch Layer 3
    • Ogni switch spine è connesso a ogni singolo switch leaf
  2. Leaf Layer (Livello Foglia): Rappresenta il punto di connessione per i dispositivi finali

    • Switch leaf collegati a server, storage e altri endpoint
    • Ogni leaf è connesso a tutti gli switch spine
    • Funziona come punto di accesso alla rete per i dispositivi finali

L'architettura può essere implementata secondo diverse strategie. EVPN (Ethernet VPN) combinato con VXLAN e BGP rappresenta l'approccio più avanzato e moderno per l'implementazione.

EVPN sostituisce STP, consentendo l'utilizzo di tutti i percorsi disponibili e rimuovendo le limitazioni del tradizionale spanning tree. ECMP permette di bilanciare il carico su tutti i percorsi disponibili tra leaf e spine, piuttosto che utilizzare un singolo percorso come farebbe STP.

Il Layer 2 è strettamente confinato alle coppie vPC/MLAG, migliorando la stabilità della rete.

VXLAN viene tipicamente utilizzato come tecnologia di overlay per incapsulare il traffico Layer 2 su una rete IP.

1.00

Nelle reti Layer 2 tradizionali, le informazioni di raggiungibilità vengono distribuite nel data plane attraverso il flooding. Con le reti EVPN-VXLAN, questa attività si sposta al control plane.

Virtualizzazione di rete

VXLAN

VXLAN (Virtual Extensible LAN) è uno dei protocolli di overlay più diffusi, sviluppato per risolvere le limitazioni delle VLAN tradizionali:

  • Utilizza un identificatore di rete virtuale a 24 bit (VNI - VXLAN Network Identifier), permettendo fino a 16 milioni di reti logiche rispetto alle 4096 delle VLAN tradizionali basate su IEEE 802.1Q
  • Incapsula i frame Ethernet in pacchetti UDP/IP creando un tunnel logico
  • Utilizza tipicamente la porta UDP 4789 come standard IANA, sebbene alcune implementazioni possono utilizzare porte differenti
  • Richiede un MTU maggiore (tipicamente 1550-1600 bytes) per compensare l'overhead di incapsulamento e evitare frammentazione dei pacchetti, che potrebbe degradare performance e causare problemi di connettività

Le reti overlay rappresentano un paradigma fondamentale nella virtualizzazione di rete moderna, creando topologie virtuali indipendenti dall'infrastruttura fisica sottostante. Questo approccio consente di superare i limiti delle reti tradizionali, separando la logica di rete dalle restrizioni fisiche e permettendo architetture multi-tenant altamente scalabili.

1.00

L'incapsulamento Layer 2 su Layer 3 è il meccanismo chiave che consente alle reti overlay di funzionare. Questo processo prevede la presa di frame Ethernet (Layer 2) completi e il loro inserimento in pacchetti IP (Layer 3), permettendo:

  • Trasmissione di traffico Layer 2 attraverso confini Layer 3 (subnet diverse)
  • Estensione di segmenti Layer 2 su distanze geografiche

1.00

VTEP (VXLAN Tunnel Endpoint) sono i componenti che gestiscono l'incapsulamento e il decapsulamento del traffico attraverso l'overlay network:

  • Risiedono sui nodi di trasporto (hypervisor o switch fisici)
  • Possiedono un indirizzo IP nella rete di trasporto fisica
  • Creano e terminano i tunnel di overlay
  • Mantengono le tabelle di mapping tra MAC address delle VM e l'indirizzo IP del VTEP remoto
  • Gestiscono l'apprendimento delle informazioni di forwarding tramite control plane e data plane
GENEVE

NSX-T utilizza principalmente GENEVE (Generic Network Virtualization Encapsulation) anziché VXLAN:

  • Maggiore estensibilità grazie al supporto nativo per metadati e TLV (Type-Length-Value)
  • Trasporto di informazioni di policy e sicurezza insieme ai dati
  • Flessibilità per supportare nuove funzionalità senza modificare il protocollo base
  • Compatibilità con hardware di rete moderno
Underlay Vs Overlay

L'architettura di virtualizzazione di rete si articola su due livelli distinti.

1.00

Rete di Underlay (o rete di trasporto):

  • L'infrastruttura fisica hardware che implementa IP e fornisce connettività tra i nodi di trasporto
  • Tipicamente utilizza routing IP standard (OSPF, BGP) per massimizzare percorsi multipli
  • Richiede solo routing IP e non necessita di supportare protocolli specifici dell'overlay
  • Deve essere dimensionata per gestire MTU maggiori per i pacchetti incapsulati

Rete di Overlay:

  • Rete logica virtuale creata sopra l'underlay
  • Offre connettività Layer 2 o Layer 3 ai workload virtualizzati
  • Isola completamente i tenant grazie a identificatori virtuali unici
  • Gestisce policy di sicurezza, QoS e routing indipendentemente dall'infrastruttura sottostante

Questa architettura a due livelli consente di implementare reti cloud-scale con agilità, isolamento e scalabilità impossibili da raggiungere con approcci tradizionali, formando la base delle moderne infrastrutture SDN (Software-Defined Networking) come NSX-T.

NSX-T

NSX-T implementa un'architettura modulare con chiara separazione tra management plane (NSX-T Manager), control plane (NSX-T Controller) e data plane (Hypervisor).

1.00

vCenter Server funge da Compute Manager per NSX-T, consentendo il discovery e l'integrazione con l'infrastruttura vSphere, inclusi host ESXi, reti e macchine virtuali.

Per fornire la rete a diversi tipi di nodi di calcolo, NSX-T si basa su uno switch virtuale distribuito N-VDS chiamato anche “hostswitch”.

Host Transport Node

Un Host Transport Node è un hypervisor ESXi su cui sono stati installati i moduli NSX-T. La preparazione dell'host include l'installazione del piano dati NSX-T (N-VDS o VDS con NSX-T) e la configurazione di un Tunnel Endpoint (TEP). Questo TEP consente all'host di partecipare alla rete overlay, creando tunnel di incapsulamento con altri nodi transport per il traffico tra workload virtualizzati su diversi host.

1.00

Edge Node

Un Edge Node è un'appliance specializzata (disponibile come VM o appliance fisica) che fornisce servizi di rete avanzati all'infrastruttura NSX-T. Funziona come gateway tra l'ambiente virtuale NSX-T e le reti fisiche esterne, implementando servizi centralizzati quali:

  • Routing north-south
  • Network Address Translation (NAT)
  • Load Balancing
  • VPN (site-to-site e remote access)
  • Protocolli di routing dinamico (BGP, OSPF)
  • Stateful firewall

Oltre a quanto riportato sopra, supporta il Bidirectional Forwarding Detection (BFD) come meccanismo avanzato per il rilevamento rapido dei guasti, complementare ai protocolli di routing.

Gli Edge Node vengono sempre configurati anche come Transport Node (con propri TEP), permettendo loro di comunicare direttamente attraverso la rete overlay con gli Host Transport Node. Questa configurazione consente una connettività seamless tra l'infrastruttura virtualizzata e le reti fisiche esterne.

Management Plane

Il management plane fornisce un punto di ingresso API unificato al sistema ed è responsabile per:

  • Mantenere le configurazioni utente
  • Gestire le query degli utenti
  • Eseguire operazioni su tutti i nodi di management, control e data plane

L'NSX Manager rappresenta il componente centrale, fornendo un'interfaccia grafica basata su browser per l'amministrazione dell'ambiente.

Control Plane

Il control plane è suddiviso in due componenti principali:

  1. Central Control Plane (CCP): Implementato nel cluster di manager NSX-T, offre ridondanza e scalabilità. È logicamente separato dal traffico del data plane, garantendo che eventuali guasti nel control plane non influiscano sulle operazioni esistenti del data plane;
  2. Local Control Plane (LCP): Opera sui nodi di trasporto, adiacente al data plane che controlla. Si connette al CCP ed è responsabile della programmazione delle voci di inoltro e delle regole del firewall del data plane.
Data Plane

Il data plane esegue l'inoltro e la trasformazione stateless dei pacchetti basati su tabelle popolate dal control plane. Riporta informazioni topologiche al control plane e mantiene statistiche a livello di pacchetto.

Zone di trasporto

Una Zona di Trasporto (Transport Zone) in NSX-T rappresenta un dominio di comunicazione che definisce quali host e quali VM possono comunicare direttamente tra loro attraverso l'infrastruttura virtualizzata. Le zone di trasporto delimitano il perimetro massimo di estensione di una rete logica, fungendo da confine per la mobilità delle VM e il broadcast di Layer 2.

NSX-T supporta due tipi principali di zone di trasporto, ciascuna ottimizzata per uno specifico modello di connettività:

  • Zona di trasporto VLAN: Per la connessione al fabric di rete fisico

    • Utilizzate per connettere il mondo virtuale all'infrastruttura fisica
    • Non utilizzano incapsulamento, ma mappano direttamente alle VLAN fisiche
    • Servono principalmente per connettività north-south o per workload fisici
    • Sono necessarie per collegare i nodi edge alle reti fisiche esterne
  • Zona di trasporto Overlay: Per la comunicazione con altri nodi edge e nodi di trasporto host nel fabric NSX

    • Utilizzate per creare reti virtuali completamente astratte dall'infrastruttura fisica
    • Impiegano protocolli di incapsulamento (GENEVE) per creare tunnel tra TEP
    • Supportano l'implementazione di segmenti virtualizzati Layer 2 e Layer 3
    • Consentono la mobilità delle VM senza vincoli di località fisica
    • Ideali per il traffico east-west tra workload virtualizzati

1.00

Il termine fabric si riferisce all'infrastruttura fisica e virtuale sottostante che supporta l'ambiente di rete virtualizzato. In sostanza, il fabric costituisce le fondamenta su cui vengono implementati i servizi di rete.

Ogni nodo di trasporto (host hypervisor o nodo edge) può appartenere a multiple zone di trasporto, consentendo flessibilità nella progettazione della rete.

Routing a livelli

NSX-T implementa un modello di routing a due livelli:

  • Gateway Tier-0 (T0): Connette l'infrastruttura virtuale alla rete fisica esterna, gestendo il traffico nord-sud. Supporta OSPF e BGP per il routing dinamico. Comprende componenti distribuiti (DR) su tutti i nodi di trasporto e componenti di servizio (SR) sui nodi edge
  • Gateway Tier-1 (T1): Gestisce il routing est-ovest tra segmenti logici all'interno del datacenter virtuale, fornendo un ulteriore livello di astrazione e separazione del traffico

1.00

Il routing distribuito viene eseguito come modulo del kernel in ogni hypervisor, consentendo l'instradamento inter-subnet tra VM sullo stesso server ESXi senza necessità che il traffico lasci l'hypervisor.

Principi di progettazione

Le linee guida architetturali di Azure sono costruite attorno ai cinque pilastri fondamentali dell'eccellenza architettonica, creando un framework completo per garantire che i carichi di lavoro soddisfino obiettivi specifici in termini di qualità, performance e ritorno sull'investimento.

1.00

Il Well-Architected Framework si basa effettivamente su pilastri fondamentali che incorporano i concetti di modularità, separazione dei ruoli e miglioramento della produttività operativa.

1.00

Assessment preliminare

Azure Migrate offre un potente strumento di assessment per valutare la migrazione degli ambienti VMware locali verso Azure VMware Solution (AVS).

Il processo analizza dettagliatamente le VM on-premises, considerando configurazioni hardware, utilizzo delle risorse e requisiti di performance. Utilizzando queste informazioni è possibile determinare il numero ottimale di nodi necessari per supportare il carico di lavoro esistente.

La valutazione include anche una stima dei costi mensili permettendo alle organizzazioni di prendere decisioni informate basate su dati concreti.

Macro-steps di implementazione

  1. Identificare la sottoscrizione, gruppo di risorse e regione
  2. Identificare il numero di host necessari (AV36, AV36P, AV52 e AV64)
  3. Richiedere una quota di host per la sottoscrizione
  4. Identificare almeno un segmento IP CIDR /22 non sovrapposto
  5. Identificare o distribuire una vNet
  6. Distribuire il Gateway nella vNet per fare il peer

Riferimenti

Related Posts

Da Solaris a Linux - Un viaggio verso Azure

Da Solaris a Linux - Un viaggio verso Azure

Case study

AI Integration - Un case study su Azure Document Intelligence

AI Integration - Un case study su Azure Document Intelligence

Case Study

IA e Microsoft Azure

IA e Microsoft Azure

Servizi di Intelligenza Artificiale nel cloud Azure

Azure Kubernetes Service - Apache Superset deployment

Azure Kubernetes Service - Apache Superset deployment

Apache Superset deployment in Azure Kubernetes Service

Azure Cloud - Reference Architecture Design

Azure Cloud - Reference Architecture Design

Reference Architecture for Azure cloud environment

Windows Server & VPN SSL - MFA with Azure AD

Windows Server & VPN SSL - MFA with Azure AD

MFA implementation with Entra ID

Azure Networking - Hub Vnet Migration

Azure Networking - Hub Vnet Migration

Case Study

Azure Virtual Desktop - Deploy with Terraform

Azure Virtual Desktop - Deploy with Terraform

Automated Deployment with Terraform