Introduzione
In questo documento viene descritto come risolvere i problemi di montaggio dell'archivio dati Hyperflex.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse:
Per impostazione predefinita, gli archivi dati Hyperflex vengono installati in NFS v3.
NFS (Network File System) è un protocollo di condivisione dei file utilizzato dall'hypervisor per comunicare con un server NAS (Network Attached Storage) su una rete TCP/IP standard.
Di seguito è riportata una descrizione dei componenti NFS utilizzati in un ambiente vSphere:
- Server NFS: dispositivo di storage o server che utilizza il protocollo NFS per rendere i file disponibili in rete. Nel mondo Hyperflex, ogni VM controller esegue un'istanza del server NFS. L'IP del server NFS per gli archivi dati è l'IP dell'interfaccia eth1:0.
- Archivio dati NFS - Partizione condivisa nel server NFS che può essere utilizzata per la memorizzazione dei file delle macchine virtuali.
- Client NFS - ESXi include un client NFS incorporato utilizzato per accedere ai dispositivi NFS.
Oltre ai normali componenti NFS, su ESXi è installato un VIB denominato IOVisor, che fornisce un punto di accesso NFS (Network File System) in modo che l'hypervisor ESXi possa accedere alle unità disco virtuali collegate alle singole macchine virtuali. Dal punto di vista dell'hypervisor, è semplicemente collegato a un file system di rete.
Problema
I sintomi dei problemi di montaggio possono apparire nell'host ESXi come datastore inaccessibile.
Archivi dati inaccessibili in vCenter
Nota: Quando gli archivi dati risultano inaccessibili in vCenter, vengono visualizzati come non disponibili montati nella CLI di ESX. Ciò significa che gli archivi dati sono stati precedentemente montati sull'host.
Controllare gli archivi dati tramite CLI:
- SSH all'host ESXi, quindi immettere il comando:
[root@node1:~] esxcfg-nas -l
test1 is 10.197.252.106:test1 from 3203172317343203629-5043383143428344954 mounted unavailable
test2 is 10.197.252.106:test2 from 3203172317343203629-5043383143428344954 mounted unavailable
Archivi dati non disponibili in vCenter/CLI
Nota: Quando gli archivi dati non sono presenti in vCenter o nella CLI. Ciò indica che il datastore non è mai stato montato correttamente sull'host in precedenza.
- Controllo degli archivi dati tramite CLI
SSH sull'host ESXi e immettere il comando:
[root@node1:~] esxcfg-nas -l
[root@node1:~]
Soluzione
I motivi per il problema di montaggio possono essere diversi, controllare l'elenco di assegni per convalidare e correggere eventuali.
Verifica della raggiungibilità della rete
La prima cosa da controllare in caso di problemi all'archivio dati è se l'host è in grado di raggiungere l'IP del server NFS.
Nel caso di Hyperflex, l'IP del server NFS è l'IP assegnato all'interfaccia virtuale eth1:0, presente su uno degli SCVM.
Se gli host ESXi non sono in grado di eseguire il ping dell'indirizzo IP del server NFS, gli archivi dati diventano inaccessibili.
Trovare l'indirizzo IP eth1:0 con il comando ifconfig su tutte le SCVM.
Nota: Eth1:0 è un'interfaccia virtuale presente solo su uno degli SCVM.
root@SpringpathControllerGDAKPUCJLE:~# ifconfig eth1:0
eth1:0 Link encap:Ethernet HWaddr 00:50:56:8b:62:d5
inet addr:10.197.252.106 Bcast:10.197.252.127 Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Per risolvere i problemi di montaggio dell'archivio dati sull'host ESXi e verificare se è in grado di raggiungere l'indirizzo IP del server NFS.
[root@node1:~] ping 10.197.252.106
PING 10.197.252.106 (10.197.252.106): 56 data bytes
64 bytes from 10.197.252.106: icmp_seq=0 ttl=64 time=0.312 ms
64 bytes from 10.197.252.106: icmp_seq=1 ttl=64 time=0.166 m
Se è possibile eseguire il ping, seguire la procedura per la risoluzione dei problemi descritta nella sezione successiva.
Se non è possibile eseguire il ping, controllare l'ambiente in uso per verificare la raggiungibilità. è possibile esaminare alcuni indicatori:
- Impostazioni vSwitch hx-storage-data:
Nota: Per impostazione predefinita, tutta la configurazione viene eseguita dal programma di installazione durante la distribuzione del cluster. Se è stato modificato manualmente, verificare le impostazioni
Impostazioni MTU: se è stata abilitata l'MTU jumbo durante la distribuzione del cluster, anche l'MTU sullo switch vSwitch deve essere 9000. Se non si utilizza l'MTU jumbo, questo valore deve essere 1500.
Teaming and Failover: per impostazione predefinita, il sistema tenta di garantire che il traffico dei dati di storage venga commutato localmente da FI. Pertanto, le schede di rete attive e in standby su tutti gli host devono essere uguali.
Impostazioni Vlan gruppo porte - La VLAN dei dati di archiviazione deve essere specificata su entrambi i gruppi di porte Storage Controller Data Network e Storage Hypervisor Data Network.
Nessuna sostituzione a livello di gruppo di porte: le impostazioni di raggruppamento e failover eseguite a livello di vSwitch vengono applicate ai gruppi di porte per impostazione predefinita, pertanto è consigliabile non sostituire le impostazioni a livello di gruppo di porte.
Nota: Per impostazione predefinita, tutta la configurazione viene eseguita dal programma di installazione durante la distribuzione del cluster. Se è stato modificato manualmente, verificare le impostazioni
Impostazioni MTU: verificare che le dimensioni MTU e i criteri QoS siano configurati correttamente nel modello di scheda di rete virtuale dei dati di archiviazione. Le variabili di archiviazione dei dati utilizzano la policy QoS Platinum e l'MTU deve essere configurata in base all'ambiente in uso.
Impostazioni VLAN: la VLAN hx-storage-data creata durante la distribuzione del cluster deve essere consentita nel modello vnic. assicurarsi che non sia contrassegnato come nativo
Controllo stato proxy IOvisor/ SCVMclient/ NFS
La vibrazione del client SCVM in ESXI funge da proxy NFS. Intercetta l'I/O della macchina virtuale, la invia al rispettivo SCVM e le rifornisce con le informazioni necessarie.
Accertarsi che VIB sia installato sugli host, per questo SSH su uno degli ESXI ed eseguire i comandi:
[root@node1:~] esxcli software vib list | grep -i spring
scvmclient 3.5.2b-31674 Springpath VMwareAccepted 2019-04-17
stHypervisorSvc 3.5.2b-31674 Springpath VMwareAccepted 2019-05-20
vmware-esx-STFSNasPlugin 1.0.1-21 Springpath VMwareAccepted 2018-11-23
Controllare lo stato di scvmclient sull'esxi ora e assicurarsi che sia in esecuzione; se è arrestato, avviarlo con il comando /etc/init.d/scvmclient start
[root@node1:~] /etc/init.d/scvmclient status
+ LOGFILE=/var/run/springpath/scvmclient_status
+ mkdir -p /var/run/springpath
+ trap mv /var/run/springpath/scvmclient_status /var/run/springpath/scvmclient_status.old && cat /var/run/springpath/scvmclient_status.old |logger -s EXIT
+ exec
+ exec
Scvmclient is running
UUID Cluster Risolvibile Su IP Di Loopback ESXI
Hyperflex mappa l'UUID del cluster all'interfaccia di loopback di ESXi, in modo che ESXI passi le richieste NFS al proprio client scvmclient. In caso contrario, è possibile che si verifichino problemi con il montaggio degli archivi dati sull'host. Per verificare questa condizione, eseguire il comando ssh sull'host su cui sono stati montati gli archivi dati, il comando ssh sull'host su cui sono stati rilevati problemi e quindi inviare il file /etc/hosts
Se l'host non funzionante non dispone della voce /etc/hosts, è possibile copiarla da un host funzionante negli /etc/hosts dell'host non funzionante.
Host non funzionante
[root@node1:~] cat /etc/hosts
# Do not remove these lines, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
::1 localhost.localdomain localhost
10.197.252.75 node1
Host funzionale
[root@node2:~] cat /etc/hosts
# Do not remove these lines, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
::1 localhost.localdomain localhost
10.197.252.76 node2
127.0.0.1 3203172317343203629-5043383143428344954.springpath 3203172317343203629-5043383143428344954
Voci Dell'Archivio Dati Non Aggiornate In /etc/vmware/esx.conf
Se il cluster HX è stato ricreato senza la reinstallazione di ESXI, è possibile che nel file esx.conf siano presenti voci datastore obsolete.
Ciò non consente di montare i nuovi archivi dati con lo stesso nome. È possibile controllare tutti gli archivi dati HX in esx.conf dal file:
[root@node1:~] cat /etc/vmware/esx.conf | grep -I nas
/nas/RepSec/share = "10.197.252.106:RepSec"
/nas/RepSec/enabled = "true"
/nas/RepSec/host = "5983172317343203629-5043383143428344954"
/nas/RepSec/readOnly = "false"
/nas/DS/share = "10.197.252.106:DS"
/nas/DS/enabled = "true"
/nas/DS/host = "3203172317343203629-5043383143428344954"
/nas/DS/readOnly = "false"
se nell'output si rileva che il datastore precedente è mappato e utilizza l'UUID del cluster precedente, di conseguenza ESXi non consente di montare lo stesso datastore con il nuovo UUID.
Per risolvere questo problema, è necessario rimuovere la voce precedente dell'archivio dati con il comando - esxcfg-nas -d RepSec
Una volta rimosso, riprovare a montare l'archivio dati dalla connessione HX
Verifica delle regole firewall in ESXi
Verifica impostazioni di abilitazione firewall
È impostato su False, causa problemi.
[root@node1:~] esxcli network firewall get
Default Action: DROP
Enabled: false
Loaded: true
Abilitarlo con i seguenti comandi:
[root@node1:~] esxcli network firewall set –e true
[root@node1:~] esxcli network firewall get
Default Action: DROP
Enabled: true
Loaded: true
Verifica impostazioni regole di connessione:
È impostato su False, causa problemi.
[root@node1:~] esxcli network firewall ruleset list | grep -i scvm
ScvmClientConnectionRule false
Abilitarlo con i seguenti comandi:
[root@node1:~] esxcli network firewall ruleset set –e true –r ScvmClientConnectionRule
[root@node1:~] esxcli network firewall ruleset list | grep -i scvm
ScvmClientConnectionRule true
Verifica delle regole modificabili su SCVM
Controllare e verificare il numero di regole su tutte le SCVM. Se non corrispondono, aprire una richiesta TAC per correggerla.
root@SpringpathControllerI51U7U6QZX:~# iptables -L | wc -l
48
Informazioni correlate