L’idea di questo articolo è introdurre l’argomento del vSphere Network (ver. 7.0), ovvero quali sono gli oggetti che bisogna conoscere, le configurazioni e tutto quello che c’è da sapere per cominciare con il piede giusto quando si mette mano alla parte rete di vSphere. Se desiderate approfondire i concetti esiste la documentazione ufficiale sul vsphere networking: https://docs.vmware.com/en/VMware-vSphere/7.0/vsphere-esxi-vcenter-server-703-networking-guide.pdf
Ovviamente dobbiamo fare un distinguo prima di partire con configurazioni e oggetti del mondo vsphere:
– Network Fisico: network dove le macchine fisiche (bare metal) sono connesse, solitamente tramite Switch utilizzati per inviare e ricevere dati. In questo caso l’hypervisor VMware è installato su una macchina fisica con le sue connessioni di rete.
– Network Virtuale / PortGroup – Distributed PortGroup: questa è la rete delle virtual machine che è creata all’interno di ESXi per poter connettere “logicamente” le Virtual Machines tra loro e con il mondo esterno (Trunk,Access, PVLAN). E’ in fin dei conti un oggetto visibile nel vCenter/ESXi a cui possiamo connettere le VMs.
– Network Opaque / NSX Segments : in questo caso sono reti virtuali create da un entità separata a vSphere. Un esempio sono tutte le reti create tramite il software SDN NSX in grado di integrarsi con vCenter e vSphere e creare i cosiddetti nsx-logicalswitch. La gestione di questi network avviene sono tramite i tool di gestione associati, nell’esempio sopra è l’NSX Manager o le NSX API. (a partire dalla versione 7.0 e NSX 3.0 il vSphere Distribuited Switch 7.0 è in grado di integrarsi con NSX e permette una gestione combinata delle network opaque. (KB79872)
– VMNIC: è la scheda di rete dell’ESXi host dove essenzialmente il cavo di rete è “fisicamente” collegato a uno switch di rete.
– VNIC: interfaccia virtuale connessa alla virtual machine, possono essere anche più di una in base alla configurazione della VM. La vNIC è configurata/connessa a un Virtual Network (PortGroup)
– VMkernel/vmknic: è una interfaccia virtuale Layer3/IP configurata direttamente sull’ESXi utilizzata da diversi o più servizi. Questa interfaccia avrà un indirizzo ip che verrà utilizzato per diversi servizi: management, vmotion, fault tolerance, vsan e molti altri.
– vSphere Standard Switch: è lo switch virtuale standard di ESXi, disponibile direttamente nell’hypervisor e gestibile da quest’ultimo senza la necessità di avere un vCenter. Funziona molto similmente a un normalissimo switch ethernet fisico, si occupa di rilevare quando una vm viene logicamente connessa a una virtual port e usa queste informazioni per inviare il traffico correttamente. Il VSS può essere connesso a uno switch fisico utilizzando gli adattatori ethernet fisici, chiamati anche uplinks così da poter mettere in comunicazione rete virtuale con rete fisica. Nonostante funzioni in maniera molto simile agli switch fisici, non ha molte delle funzionalità avanzate di questi ultimi il che lo rende limitato in alcuni casi specifici.
– vSphere Distributed Switch: in questo caso lo switch distribuito agisce come singolo punto di configurazione per tutti gli hosts a esso associati permettendo quindi di fare tutte le operazioni da un unico oggetto. Per poterlo utilizzare un requisito fondamentale è il vcenter dove è possibile crearlo e successivamente associare gli host e tutte le configurazioni da propagare, in questo caso è possibile anche migrare la virtual machine mantenendo la consistenza del network.
– Host Proxy Switch: è il cosiddetto switch nascosto che risiede su ogni host associato a un VDS. Il compito del proxy switch è replicare le configurazioni dello switch distribuito sull’host.
Port Groups (VSS)
Sono oggetti che identificano il network, solitamente tramite il nome che viene associato all’oggetto portgroup che deve essere “unico” all’interno delle configurazioni network dell’host. I PGs possono essere configurati in diversi modi, ma il modo più semplice per restrigere il traffico è quello di applicare un VLAN ID. (0-4095)
Quando si va a creare un port group in uno standard switch ci sono elle configurazioni possibili una di questa è difatti il vLAN Tagging mode:
– External Switch Tagging o EST, in questo caso il vlan ID è su 0 e significa che il virtual switch non passa traffico associato a nessuna VLAN
– Virtual Guest Tagging o VGT, in questo caso il vlan ID è configurato su 4095, la virtual machine gestisce il traffico usando una o più VLANs e il virtual switch in questo caso passa tutto il traffico da qualsiasi VLAN.
– Virtual Portgroup Tagging o VPG, in questo caso il traffico fatto su questo port group viene definito da una vlan (tagging) attraverso cui la virtual machine potrà comunicare o meno con altre network e/o internet in base alle configurazioni fatte negli apparati di rete fisici (switch, firewall, router). Nell’immagine sotto il traffico delle virtual machine collegate a questo port group verrà taggato con vlan 1000.
Per quanto riguarda MTU (Maximum Transmission Unit) nel caso di Port Group standard non è possibile agire su questa configurazione singolarmente ma è possibile definire un diverso MTU in maniera Generale tra le proprietà del vSphere Standard Switch.
Security (VSS)
All’interno dei port group e anche in maniera più generale sul VSS (le configurazioni in questo caso vengono ereditate in automatico dai Port Group) è possibile attivare o meno delle policy di sicurezza per quanto riguarda Promiscuous Mode, Mac Address Changes e Forged Transmits, andiamo velocemente a capire cosa fa ognuno di questi settaggi.
– Promiscuous Mode: se attivo permette alle VMs di ricevere tutto il traffico anche se non è destinato a loro (sulla stessa VLAN). Di default è disattivata ma in alcuni casi particolari potrebbe essere necessario attivarla per casi di monitoraggio, firewall, ids, port scanner o quando si “gioca” su laboratori “Nested”
– Mac Address Changes: per poter capire appieno questo paramentro di sicurezza bisogna far chiarezza su i tre principali tipi di mac address:
– Initial: è comparabile al “burned-in address” delle schede di rete fisiche, nel caso di vsphere è il mac address creato al momento della creazione della vnic su una VM.
– Effective: questo è il Mac address configurato all’interno del sistema operativo che è ospitato dalla VM, solitamente è identico all’initial
– Runtime: è il mac address effettivo che viene visualizzato dal VSS e che quindi instaura produce traffico
Con il Mac Address changes attivato permettiamo al guest os di poter modificare il mac address effettivo e quindi di poter generare traffico anche con un mac address diverso rispetto a quello configurato sulla vNIC.
– Forged Transmits: è un opzione che protegge dalla MAC impersonation e quindi verifica l’effective mac address con il mac address utilizzato dal sistema operativo, se non fanno match il traffico viene negato. Se cambiamo questa opzione su accept lo switch a questo punto non fa nessun check o filtering e quindi permette al traffico della VM di poter passare anche con MAC address multipli.
Come detto qualche riga sopra le configuraizioni generali di Standard sono automaticamente ereditate dai port groups, ma con l’override è possibile agire anche sul singolo oggetto cambiandole in base alle esigenze. Nell’immagine qui sotto si può vedere come con l’override sul portgroup “vlan1000” è possibile cambiare le policy di security a livello di singolo oggetto rispetto alle policy generali del VSS.
Teaming Policies (VSS)
Con il teaming è possibile fare diverse configurazioni basate sulla quantita di NIC fisiche per raggiungere la ridondanza e un maggiore traffico. Questa configurazione come la precedente può essere configurata sia in maniera generale sullo switch ma anche modificata per singolo port group permettendo quindi di poter distribuire il traffico su una particolare vmnic piuttosto che un altra ed ovviamente gestirne l’eventuale failover. Come mostra l’immagine qui sotto anche qui abbiamo diverse configurazioni disponibili, oltre alla possibilità di decidere vmnic attiva, standby e unused possiamo anche configurare come verificarne i problemi e l’eventuale spostamento del traffico tra una e l’altra.
–Active Adapters: interfacce in uso come uplink per lo switch virtuale se la connetività network è attiva e funzionante
– Standby Adapters: interfacce utilizzate come uplink di riserva se uno o più active adapters non sono funzionanti
– Unused Adapters: le vmnic inserite in questo gruppo non verrano utilizzate per trasportare il traffico
Se ci concentriamo per un momento sul failover ci sono principalmente 3 impostazioni che bisogna conoscere: Network failure detection, notify switches e failback.
Network Failure detection
– Link status only: in questo caso il sistema verifica lo stato del network adapter. E’ in grado di identificare problemi come cavo scollegato o switch fisico spento ma non è in grado di verificare errori di configurazione come porta bloccata a livello switch, spanning tree o configurazioni sbagliate con le VLAN.
– Beacon Probing: è in grado di identificare i cosidetti failures nello switch fisico più vicino. Per poter essere in grado di identificare questi failure invia dei pacchetti chiamati “beacon probes” su tutte le NIC/vmnic nel teaming e usa questa informazioni con l’utilizzo anche del link status per determinare se ci sono dei problemi. In questo caso si è in grado di identificare i problemi del Link Status ma anche configurazioni errate lato switch fisico.
– Notify Switch: permette a vSphere di inviare una Reverse Address Resolution Protocol (RARP) per conto delle VMs. Viene utilizzato il RARP in maniera tale da notificare allo switch fisico che la VM ora è raggiungibile da un altra interfaccia fisica.
– Failback: permette a una vmnic che precedentemente era in stato di “fail” quindi non disponibile/non funzionante per un qualsiasi motivo di rimpiazzare l’eventuale “standby vmnic” che ne aveva preso il posto e tornare subito come attiva. Nell’esempio mostrato sotto abbiamo vmnic4 attivo (che in questo caso va in fail), vmnic7 viene promosso come adapter attivo, ma poco tempo dopo la vmnic4 torna attiva, in questo caso viene nuovamente “declassata” la vmnic7 come standby e la vmnic4 torna in stato Active.
Ho tralasciato per ultimo l’argomento del Load Balancing Method con cui possiamo decidere come il VSS andrà a bilanciare il traffico di rete “outbound” ovvero il traffico in uscita dall’host attraverso gli uplink/vmnic disponibili verso lo switch fisico.
Nello specifico il il vSphere Standard Switch ha quattro opzioni configurabili che andremo a descrivere meglio qualche riga sotto; in questo caso però bisogna sapere che queste configurazioni sono solo a livello di Switch. (non è possibile infatti con il VSS impostare un load balancing method diverso per ogni singolo port group, cosa possibile invece con il VDS)
– Source MAC Hash: il virtual switch seleziona l’uplink per la virtual machine in base al MAC address della vNic. Per calcolare l’uplink da utilizzare per la VM il virtual switch utilizza quindi il mac address e il numero di uplink nel NIC Team. Ha un overhead maggiore rispetto all’opzione Port ID poichè lo switch virtuale deve comunque analizzare i pacchetti e verificare il mac address. Se il mio mac address non cambia continuerò ad utilizzare sempre la vmnic selezionata in principio, anche qui non è un vero bilanciamento poichè non tiene conto dell’utilizzo per vmnic ma effettua solo una selezione/associazione vmnic/vnic.
– Source/Destination IP Hash: in questo caso l’analisi è più accurata poichè ogni pacchetto in uscita è controllato verificandone IP sorgente/destinazione. In questo caso l’hash viene calcolato verificando la vmnic selezionata in base al pacchetto, quindi ogni pacchetto viene verificato per essere instradato sulla vmnic corretta. L’overhead qui è molto più grande rispetto ai metodi precedenti poichè ogni pacchetto viene analizzato per verificare sorgente e destinazione, inoltre richiedere una configurazione LACP sullo switch fisico. Possiamo comunque bilanciare solo il traffico in uscita ma comunque la distribuzione del carico in questo caso è decisamente migliore. Per informazioni sulla configurazione guardare la seguente KB: https://kb.vmware.com/s/article/1001938
– Use explicit failover order: in questo caso non viene fatto nessun tipo di load balancing ma il virtual switch andrà ad utilizzare il primo uplink disponibile in base al failover order.
Con il Virtual Distributed Switch tutte le funzionalità trattate sopra sono disponibili più altre funzionalità che ovviamente accrescono le configurazioni possibili.
(Reminder: VDS è un oggetto creato dal vcenter per poter gestire le configurazioni di rete da un unico punto di controllo e propagare le configurazioni tra diversi esxi host e clusters)
Questo significa che quando creo un PortGroup su questo oggetto, chiamato per l’appunto Distribuited Port Group, quest’ultimo sarà creato automaticamente su tutti gli host collegati al VDS in questione. Come potete ben capire questo riduce significativamente l’overhead a livello di operazioni sul network vsphere e si assicura che la configurazione del port group sia identita tra tutti gli host connessi. La differenza sostanziale rispetto al VSS e che ora i Portgroups van utilizzati anche per ospitare il traffico vmkernel, andreanno quindi creati i port group anche delle network vmkernel che è possibile migrare quando si passa da VSS a VDS. (Nel caso in cui commettere qualche errore niente paura, esiste una funzionalità chiamata rollback che verifica che l’host continui a raggiungere il vcenter se questo non avviene durante la migrazione l’host viene riportato alla configurazione precedente)
L’immagine sotto mostra come il flusso del traffico in un distribuited switch connesso a più hosts con vmkernel e port group distribuiti.
Questa configurazione è riflessa dal VDS su tutti gli host collegati a esso (Host Proxy Switch), un esempio nell’immagine seguente.
Sempre parlando di port group anche qui le configurazioni viste prima con il VSS sono le medesime, è quindi possibile configurarli con EST, VPG o VGT con l’unica differenza che nei DvPGs è possibile mettere un trunking un range di vlan anche non contigue tra loro usando la “virgola“, limitandone di fatto l’utilizzo a livello di connettività come per esempio qui sotto: 1000-1005, 2000-2005, 2300, 2301, 2310.
Un altra configurazione possibile per quanto riguarda i DvPGs è anche la possibilità di decidere il “port binding”, ovvero come le porte dello switch virtuale vengono assegnate alle vNic (VMs). https://kb.vmware.com/s/article/1022312#Static_Binding
– Static Binding: quando un VM viene connessa ad un port group, la porta viene immediatamente assegnata e riservata. In questa maniera si garantisce la connettività sempre, la porta viene disconnessa solo quando la VM è rimossa dal port group. Le VM in questo caso possono solo essere riconnesse solo tramite il vCenter.
– Ephemeral Binding: in questo caso la porta viene assegnata alla virtual machine solo quando quest’ultima viene accesa e la sua vNIC è in stato “connesso”. Quando la VM viene spenta o la NIC disconnessa la porta viene cancellata. Con questa configurazione è possibile assegnare VM ai port group non solo tramite vCenter ma anche tramite ESXi. Da linee guida VMware questo tipo di configurazione sul port group è da utilizzare solo per situazioni di “Recovery” ovvero dove c’è bisogno di fare il provision di una porta bypassando il vCenter, per esempio port group vmkernel di management esxi o portgroup dove risiede la VM vCenter.
Altra differenza rispetto al VSS con il DVS i port group possono andare in overrride e le configurazioni possono essere molteplici e diverse a seconda delle esigenze. (Security, Load Balancing, Active/Standby Uplinks)
VDS Advanced Features
Siccome parliamo di Basi ho lasciato giusto un appendice finale che descrive brevemente le funzionalità avanzate che lo switch Distribuito possiede:
– Port Mirroring: Il port mirroring permetter di inviare una copia del traffico di una porta distribuita su un altra porta o una porta fisica di uno switch. E’ utilizzato quindi per inviare l’esatta copia dei pacchetti in trasito su una porta su un altra per porter monitorare la connessione, fare debug dei dati, errori sul network. Ci sono diverse modalità di port mirroring: Distribuited Port Mirroring, Remote Port Mirroring, Remote Mirroring Destination e Encapsulated Remote Mirroring (L3) Source.
– Netflow/IPFIX: Permette di monitorare i pacchetti che passano attraverso le porte di un distribuited switch. Viene configurato sul VDS o su un Distribuited Port Group l’ip del collector che è in grado di raccogliere i flow che verranno poi analizzati per capire quali sono i patterns ed eventualmente fare sicurezza e prevenzione.
– Network I/O Control (NIOC): introduce la possibilità di riservare una certa banda a un determinato tipo di traffico basato anche sulla capacità totale delle interfacce fisiche degli host. Permette quindi di utilizzare il sistema di reservation simile a quello delle risorse cpu e ram per assicurare risorse per tipo di traffico. Permette inoltre di usare limiti per limitare la banda e le shares per dare invece priorità ad un determinato system traffic rispetto ad un altro che incidono sullo stesso uplink.
– Switch Health Check: Un altra funzionalità molto utile è proprio l’health check poichè ci permette in maniera molto rapida di fare troubleshooting ed eventualmente verificare se ci sono errori di configurazioni tra VDS e Switch Fisico andando a verificare trunk, teaming, mtu. Necessità nella configurazione di default di 1 minuto per verificare le configurazioni.
– CDP/LLDP Monitoring: il DVS supporta inoltre questi due protocolli utili per dare e ricevere le informazioni a livello di interfaccia fisica tra host e switch. Questi due protocolli infatti permettono di determinare a quale porta dello switch fisico il nostro Switch virtuale è connesso. E’ possiible usarlo in 3 operational mode che gestiscono quali informazioni vengono rilevate e inviate: Listen, Advertise e Both.
Spero che questo articolo abbia perlomeno dato un prima idea di cosa significa network nel mondo vSphere e quali sono le configurazioni base disponibili. Se siete giunti fin qui sicuramente avete trovato questo articolo interessante e non posso far altro che dirvi grazie.
