Configurazione di rete
Suggerisci modifiche
PDF
La configurazione delle impostazioni di rete quando si utilizza vSphere con sistemi che eseguono ONTAP è semplice e simile ad altre configurazioni di rete.
Ecco alcuni aspetti da considerare:
-
Separare il traffico di rete dello storage dalle altre reti. È possibile ottenere una rete separata utilizzando una VLAN dedicata o switch separati per lo storage. Se la rete di storage condivide percorsi fisici come gli uplink, potrebbe essere necessario QoS o porte di uplink aggiuntive per garantire una larghezza di banda sufficiente. Non connettere gli host direttamente allo storage a meno che la guida alla soluzione non lo richieda specificamente; utilizzare gli switch per disporre di percorsi ridondanti e consentire a VMware ha di funzionare senza alcun intervento.
-
I frame jumbo devono essere utilizzati se supportati dalla rete. Se vengono utilizzati, assicurarsi che siano configurati in modo identico su tutti i dispositivi di rete, VLAN e così via nel percorso tra lo storage e l'host ESXi. In caso contrario, potrebbero verificarsi problemi di connessione o di prestazioni. La MTU deve essere impostata in modo identico anche sullo switch virtuale ESXi, sulla porta VMkernel e anche sulle porte fisiche o sui gruppi di interfacce di ciascun nodo ONTAP.
-
NetApp consiglia di disattivare solo il controllo di flusso di rete sulle porte di cluster Interconnect in un cluster ONTAP. NetApp non fornisce altre raccomandazioni per le Best practice relative al controllo di flusso per le restanti porte di rete utilizzate per il traffico dati. Se necessario, è necessario attivarlo o disattivarlo. Vedere "TR-4182" per ulteriori informazioni sul controllo di flusso.
-
Quando gli array di storage ESXi e ONTAP sono collegati a reti di storage Ethernet, NetApp consiglia di configurare le porte Ethernet a cui questi sistemi si connettono come porte edge RSTP (Rapid Spanning Tree Protocol) o utilizzando la funzione PortFast di Cisco. NetApp consiglia di abilitare la funzione di trunk PortFast Spanning-Tree in ambienti che utilizzano la funzionalità Cisco PortFast e che dispongono di un trunking VLAN 802.1Q abilitato per il server ESXi o gli array di storage ONTAP.
-
NetApp consiglia le seguenti Best practice per l'aggregazione dei collegamenti:
-
Utilizzare switch che supportano l'aggregazione di collegamenti di porte su due chassis switch separati utilizzando un approccio a gruppi di aggregazione di collegamenti multi-chassis, ad esempio Virtual PortChannel (VPC) di Cisco.
-
Disattivare LACP per le porte dello switch connesse a ESXi, a meno che non si utilizzi dvSwitch 5.1 o versioni successive con LACP configurato.
-
Utilizzare LACP per creare aggregati di link per sistemi storage ONTAP con gruppi di interfacce multimodali dinamiche con hash IP.
-
Utilizzare un criterio di raggruppamento hash IP su ESXi.
-
La seguente tabella fornisce un riepilogo degli elementi di configurazione di rete e indica la posizione in cui vengono applicate le impostazioni.
| Elemento | ESXi | Switch | Nodo | SVM |
|---|---|---|---|---|
Indirizzo IP |
VMkernel |
No** |
No** |
Sì |
Aggregazione dei collegamenti |
Switch virtuale |
Sì |
Sì |
No* |
VLAN |
Gruppi di porte VMkernel e VM |
Sì |
Sì |
No* |
Controllo di flusso |
NIC |
Sì |
Sì |
No* |
Spanning tree |
No |
Sì |
No |
No |
MTU (per frame jumbo) |
Switch virtuale e porta VMkernel (9000) |
Sì (impostato su max) |
Sì (9000) |
No* |
Gruppi di failover |
No |
No |
Sì (creare) |
Sì (selezionare) |
*Le LIF SVM si connettono a porte, gruppi di interfacce o interfacce VLAN con VLAN, MTU e altre impostazioni. Tuttavia, le impostazioni non vengono gestite a livello di SVM.
**Questi dispositivi dispongono di indirizzi IP propri per la gestione, ma non vengono utilizzati nel contesto dello storage di rete ESXi.
SAN (FC, NVMe/FC, iSCSI, NVMe/TCP), RDM
ONTAP offre storage a blocchi di livello Enterprise per VMware vSphere utilizzando i tradizionali iSCSI e Fibre Channel Protocol (FCP) oltre al protocollo a blocchi di nuova generazione, NVMe over Fabrics (NVMe-of), ad alta efficienza e performance, con supporto per NVMe/FC e NVMe/TCP.
Per le Best practice dettagliate per l'implementazione dei protocolli a blocchi per lo storage delle macchine virtuali con vSphere e ONTAP, fare riferimento a. "Datastore e protocolli: SAN"
NFS
VSphere consente ai clienti di utilizzare array NFS di livello Enterprise per fornire l'accesso simultaneo agli archivi dati a tutti i nodi di un cluster ESXi. Come menzionato nella "datastore"sezione, quando si utilizza NFS con vSphere, esistono alcuni benefici di facilità d'uso ed efficienza dello storage.
Per le Best practice consigliate fare riferimento a. "Datastore e protocolli: NFS"
Connessione di rete diretta
Gli amministratori dello storage a volte preferiscono semplificare le loro infrastrutture rimuovendo gli switch di rete dalla configurazione. Questo può essere supportato in alcuni scenari. Tuttavia, ci sono alcune limitazioni e avvertimenti da essere informati di.
ISCSI e NVMe/TCP
Un host che utilizza iSCSI o NVMe/TCP può essere collegato direttamente a un sistema storage e funzionare normalmente. La ragione è la pedata. Le connessioni dirette a due storage controller differenti offrono due percorsi indipendenti per il flusso di dati. La perdita di percorso, porta o controller non impedisce l'utilizzo dell'altro percorso.
NFS
È possibile utilizzare lo storage NFS con connessione diretta, ma con una limitazione significativa: Il failover non funzionerà senza una significativa attività di scripting, che sarà responsabilità del cliente.
Il motivo per cui il failover senza interruzioni è complicato con lo storage NFS connesso direttamente è il routing che si verifica sul sistema operativo locale. Ad esempio, si supponga che un host abbia un indirizzo IP 192.168.1.1/24 e che sia collegato direttamente a un controller ONTAP con un indirizzo IP 192.168.1.50/24. Durante il failover, l'indirizzo 192.168.1.50 può eseguire il failover sull'altro controller e sarà disponibile per l'host, ma in che modo l'host rileva la sua presenza? L'indirizzo 192.168.1.1 originale esiste ancora sulla scheda di rete host che non si connette più a un sistema operativo. Il traffico destinato a 192.168.1.50 continuerebbe ad essere inviato a una porta di rete inutilizzabile.
La seconda scheda NIC del sistema operativo potrebbe essere configurata come 19 2.168.1.2 e sarebbe in grado di comunicare con l'indirizzo 192.168.1.50 non riuscito, ma le tabelle di routing locali avrebbero un valore predefinito di utilizzo di un solo indirizzo e di un solo indirizzo per comunicare con la subnet 192.168.1.0/24. Un amministratore di sistema potrebbe creare un framework di script che rilevi una connessione di rete non riuscita e alteri le tabelle di routing locali o che porti le interfacce verso l'alto e verso il basso. La procedura esatta dipende dal sistema operativo in uso.
In pratica, i clienti NetApp dispongono di NFS con connessione diretta, ma in genere solo per i workload in cui le pause io durante i failover sono accettabili. Quando si utilizzano i supporti rigidi, non devono verificarsi errori di i/o durante tali pause. L'io dovrebbe bloccarsi fino a quando i servizi non vengono ripristinati, mediante failback o intervento manuale, per spostare gli indirizzi IP tra le schede NIC dell'host.
Connessione diretta FC
Non è possibile connettere direttamente un host a un sistema storage ONTAP utilizzando il protocollo FC. Il motivo è l'uso di NPIV. Il WWN che identifica una porta FC ONTAP per la rete FC utilizza un tipo di virtualizzazione chiamato NPIV. Qualsiasi dispositivo collegato a un sistema ONTAP deve essere in grado di riconoscere un WWN NPIV. Attualmente non vi sono fornitori di HBA che offrono un HBA che può essere installato in un host in grado di supportare un target NPIV.