vSAN consente di esaminare e risolvere i diversi tipi di problemi che si verificano perché la rete di vSAN non è configurata correttamente.
Le operazioni di vSAN dipendono dalla configurazione, dall'affidabilità e dalle prestazioni della rete. Molte richieste di supporto vengono inviate perché la rete non è configurata correttamente o non funziona nel modo previsto.
Utilizzare il servizio di integrità di vSAN per risolvere i problemi della rete. In base ai risultati dei controlli di integrità della rete, è possibile che l'utente venga indirizzato a un articolo della Knowledge Base appropriato. L'articolo della Knowledge Base fornisce le istruzioni per risolvere il problema della rete.
Controlli di integrità della rete
Il servizio di integrità include una categoria per i controlli di integrità della rete.
In ogni controllo di integrità è disponibile un link AskVMware. Se il controllo di integrità non riesce, fare clic su AskVMware e leggere l'articolo della Knowledge Base di VMware associato per ulteriori dettagli e istruzioni per risolvere il problema.
- vSAN: controllo della connettività di base (unicast). Questo controllo verifica l'esistenza della connettività IP tra tutti gli host ESXi nel cluster vSAN, eseguendo il ping di ciascun host ESXi nella rete di vSAN da un altro host ESXi.
- vMotion: controllo della connettività di base (unicast). Questo controllo verifica l'esistenza della connettività IP tra tutti gli host ESXi nel cluster vSAN in cui è configurato vMotion. Ogni host ESXi nella rete di vMotion esegue il ping di tutti gli altri host ESXi.
- Tutti gli host hanno una vmknic vSAN configurata. Questo controllo assicura che in ogni host ESXi nel cluster vSAN sia configurata una scheda NIC VMkernel per il traffico di vSAN.
- Tutti gli host presentano impostazioni multicast corrispondenti. Questo controllo garantisce che ogni host disponga di un indirizzo multicast configurato correttamente.
- Tutti gli host hanno subnet corrispondenti. Questo controllo verifica che tutti gli host ESXi in un cluster vSAN siano stati configurati in modo che tutte le NIC VMkernel di vSAN si trovino nella stessa subnet IP.
- Host disconnessi da VC. Questo controllo verifica che vCenter Server disponga di una connessione attiva a tutti gli host ESXi nel cluster vSAN.
- Host con problemi di connettività. Questo controllo fa riferimento a situazioni in cui vCenter Server indica l'host come connesso, ma le chiamate API da vCenter all'host non riescono. Può evidenziare i problemi di connettività tra un host e il vCenter Server.
- Latenza di rete. Questo controllo verifica la latenza di rete degli host vSAN. Se la soglia supera 5 ms, viene visualizzato un avviso.
- vMotion: controlli MTU (ping con pacchetti di grandi dimensioni). Questo controllo integra il controllo di connettività ping di vMotion di base. Le dimensioni massime dell'unità di trasmissione sono aumentate per migliorare le prestazioni della rete. È possibile che le MTU configurate in modo errato non vengano segnalate come un problema di configurazione della rete, ma possono causare problemi di prestazioni.
- Partizione del cluster vSAN. Questo controllo di integrità esamina il cluster per verificare quante partizioni sono presenti. Visualizza un errore se nel cluster vSAN è presente più di una singola partizione.
- Valutazione multicast sulla base di altri controlli. Questo controllo di integrità aggrega i dati di tutti i controlli di integrità della rete. Se il controllo non riesce, significa che il multicast è probabilmente la causa principale di una partizione di rete.
Comandi per controllare la rete
Una volta configurata la rete di vSAN, utilizzare questi comandi per verificarne lo stato. È possibile verificare quale scheda VMkernel (vmknic) viene utilizzata per vSAN e quali attributi contiene.
Utilizzare i comandi ESXCLI e RVC per verificare che la rete funzioni in modo corretto e per risolvere eventuali problemi di rete relativi a vSAN.
È possibile verificare che la vmknic utilizzata per la rete di vSAN sia configurata correttamente in tutti gli host, controllare che il multicast funzioni e verificare che gli host che fanno parte del cluster vSAN possano comunicare correttamente tra loro.
esxcli vsan network list
Questo comando consente di identificare l'interfaccia di VMkernel utilizzata dalla rete di vSAN.
L'output seguente indica che la rete di vSAN utilizza vmk2. Questo comando continua a funzionare anche se vSAN è stato disattivato e gli host non fanno più parte di vSAN.
È inoltre importante controllare il multicast del gruppo di agenti e il multicast del gruppo master.
[root@esxi-dell-m:~] esxcli vsan network list Interface VmkNic Name: vmk1 IP Protocol: IP Interface UUID: 32efc758-9ca0-57b9-c7e3-246e962c24d0 Agent Group Multicast Address: 224.2.3.4 Agent Group IPv6 Multicast Address: ff19::2:3:4 Agent Group Multicast Port: 23451 Master Group Multicast Address: 224.1.2.3 Master Group IPv6 Multicast Address: ff19::1:2:3 Master Group Multicast Port: 12345 Host Unicast Channel Bound Port: 12321 Multicast TTL: 5 Traffic Type: vsan
Fornisce informazioni utili come l'interfaccia VMkernel utilizzata per il traffico di vSAN. In questo caso, è vmk1. Vengono tuttavia visualizzati anche gli indirizzi multicast. Queste informazioni possono essere visualizzate anche quando il cluster è in esecuzione in modalità unicast. Sono disponibili l'indirizzo e la porta multicast del gruppo. La porta 23451 viene utilizzata per l'heartbeat inviato ogni secondo dall'host primario e visibile in ogni altro host nel cluster. La porta 12345 viene utilizzata per gli aggiornamenti di CMMDS tra l'host primario e l'host di backup.
esxcli network ip interface list
Questo comando consente di verificare elementi come vSwitch o il commutatore distribuito.
Utilizzare questo comando per verificare a quale vSwitch o commutatore distribuito è collegato e le dimensioni di MTU che possono essere utili se nell'ambiente sono stati configurati jumbo frame. In questo caso, il valore predefinito di MTU è 1500.
[root@esxi-dell-m:~] esxcli network ip interface list vmk0 Name: vmk0 <<truncated>> vmk1 Name: vmk1 MAC Address: 00:50:56:69:96:f0 Enabled: true Portset: DvsPortset-0 Portgroup: N/A Netstack Instance: defaultTcpipStack VDS Name: vDS VDS UUID: 50 1e 5b ad e3 b4 af 25-18 f3 1c 4c fa 98 3d bb VDS Port: 16 VDS Connection: 1123658315 Opaque Network ID: N/A Opaque Network Type: N/A External ID: N/A MTU: 9000 TSO MSS: 65535 Port ID: 50331814
Le dimensioni massime dell'unità di trasmissione visualizzate sono 9000, quindi questa porta VMkernel è configurata per i jumbo frame, che richiedono una MTU pari a circa 9.000. VMware non offre alcun consiglio sull'utilizzo dei jumbo frame. Tuttavia, i jumbo frame sono supportati per l'utilizzo con vSAN.
esxcli network ip interface ipv4 get –i vmk2
Questo comando visualizza informazioni come l'indirizzo IP e la netmask dell'interfaccia VMkernel di vSAN.
Con queste informazioni, un amministratore può iniziare a utilizzare gli altri comandi disponibili nella riga di comando per verificare che la rete di vSAN funzioni correttamente.
[root@esxi-dell-m:~] esxcli network ip interface ipv4 get -i vmk1 Name IPv4 Address IPv4 Netmask IPv4 Broadcast Address Type Gateway DHCP DNS ---- ------------ ------------- -------------- ------------ ------- -------- vmk1 172.40.0.9 255.255.255.0 172.40.0.255 STATIC 0.0.0.0 false
vmkping
Il comando vmkping verifica se tutti gli altri host ESXi della rete rispondono alle richieste di ping.
~ # vmkping -I vmk2 172.32.0.3 -s 1472 -d PING 172.32.0.3 (172.32.0.3): 56 data bytes 64 bytes from 172.32.0.3: icmp_seq=0 ttl=64 time=0.186 ms 64 bytes from 172.32.0.3: icmp_seq=1 ttl=64 time=2.690 ms 64 bytes from 172.32.0.3: icmp_seq=2 ttl=64 time=0.139 ms --- 172.32.0.3 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.139/1.005/2.690 ms
Nonostante non verifichi la funzionalità multicast, può consentire di identificare un host ESXi non autorizzato con problemi di rete. È inoltre possibile esaminare i tempi di risposta per verificare se è presente una latenza anomala nella rete di vSAN.
Se sono configurati jumbo frame, questo comando non segnala alcun problema se le dimensioni della MTU del jumbo frame non sono corrette. Per impostazione predefinita, questo comando utilizza dimensioni della MTU pari a 1500. Se è necessario verificare se i jumbo frame funzionano correttamente end-to-end, utilizzare vmkping impostando l'opzione delle dimensioni del pacchetto (-s) su un valore maggiore come indicato di seguito:
~ # vmkping -I vmk2 172.32.0.3 -s 8972 -d PING 172.32.0.3 (172.32.0.3): 8972 data bytes 9008 bytes from 172.32.0.3: icmp_seq=0 ttl=64 time=0.554 ms 9008 bytes from 172.32.0.3: icmp_seq=1 ttl=64 time=0.638 ms 9008 bytes from 172.32.0.3: icmp_seq=2 ttl=64 time=0.533 ms --- 172.32.0.3 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.533/0.575/0.638 ms ~ #
È consigliabile aggiungere -d al comando vmkping per verificare se i pacchetti possono essere inviati senza frammentazione.
esxcli network ip neighbor list
Questo comando consente di verificare se tutti gli host vSAN si trovano nello stesso segmento di rete.
In questa configurazione, è presente un cluster a quattro host e questo comando restituisce le voci ARP (Address Resolution Protocol) degli altri tre host, inclusi i rispettivi indirizzi IP e la loro vmknic (vSAN è configurato per utilizzare vmk1 in tutti gli host di questo cluster).
[root@esxi-dell-m:~] esxcli network ip neighbor list -i vmk1 Neighbor Mac Address Vmknic Expiry State Type ----------- ----------------- ------ ------- ----- ------- 172.40.0.12 00:50:56:61:ce:22 vmk1 164 sec Unknown 172.40.0.10 00:50:56:67:1d:b2 vmk1 338 sec Unknown 172.40.0.11 00:50:56:6c:fe:c5 vmk1 162 sec Unknown [root@esxi-dell-m:~]
esxcli network diag ping
Questo comando verifica la presenza di duplicati nella rete e i tempi di andata/ritorno.
Per ottenere ulteriori dettagli sulla connettività di rete di vSAN tra i vari host, ESXCLI offre un efficace comando di diagnostica di rete. Di seguito è disponibile un esempio di tale output, in cui l'interfaccia VMkernel si trova in vmk1 e l'IP di rete vSAN remoto di un altro host nella rete è 172.40.0.10
[root@esxi-dell-m:~] esxcli network diag ping -I vmk1 -H 172.40.0.10
Trace:
Received Bytes: 64
Host: 172.40.0.10
ICMP Seq: 0
TTL: 64
Round-trip Time: 1864 us
Dup: false
Detail:
Received Bytes: 64
Host: 172.40.0.10
ICMP Seq: 1
TTL: 64
Round-trip Time: 1834 us
Dup: false
Detail:
Received Bytes: 64
Host: 172.40.0.10
ICMP Seq: 2
TTL: 64
Round-trip Time: 1824 us
Dup: false
Detail:
Summary:
Host Addr: 172.40.0.10
Transmitted: 3
Recieved: 3
Duplicated: 0
Packet Lost: 0
Round-trip Min: 1824 us
Round-trip Avg: 1840 us
Round-trip Max: 1864 us
[root@esxi-dell-m:~]
vsan.lldpnetmap
Questo comando RVC visualizza informazioni sulla porta di uplink.
Se nell'ambiente sono presenti commutatori non Cisco con Link Layer Discovery Protocol (LLDP) abilitato, è disponibile un comando RVC per visualizzare uplink <-> commutatore <-> informazioni sulla porta del commutatore. Per ulteriori informazioni su RVC, fare riferimento alla guida dei comandi di RVC.
In questo modo è possibile determinare quali host sono collegati a determinati commutatori quando il cluster vSAN si estende in più commutatori. Può consentire di isolare un problema in un determinato commutatore quando è coinvolto solo un sottoinsieme degli host nel cluster.
> vsan.lldpnetmap 02013-08-15 19:34:18 -0700: This operation will take 30-60 seconds ...+---------------+---------------------------+| Host | LLDP info |+---------------+---------------------------+| 10.143.188.54 | w2r13-vsan-x650-2: vmnic7 || | w2r13-vsan-x650-1: vmnic5 |+---------------+---------------------------+
Questa opzione è disponibile solo con i commutatori che supportano LLDP. Per configurarla, accedere al commutatore ed eseguire le operazioni seguenti:
switch# config t Switch(Config)# feature lldp
Per verificare che LLDP sia abilitato:
switch(config)#do show running-config lldp
LLDP funziona in modalità di invio e ricezione per impostazione predefinita. Controllare le impostazioni delle proprietà di vDS se le informazioni relative al commutatore fisico non vengono rilevate. Per impostazione predefinita, vDS viene creato con il protocollo di rilevamento impostato su CDP, ossia Cisco Discovery Protocol. Per risolvere il problema, impostare il protocollo di rilevamento su LLDP e l'operazione su Entrambi nel vDS.
Controllo delle comunicazioni multicast
Le configurazioni multicast possono causare problemi per la distribuzione di vSAN iniziale.
Uno dei modi più semplici per verificare se il multicast funziona correttamente nell'ambiente vSAN in uso consiste nell'utilizzare il comando tcpdump-uw. Questo comando è disponibile dalla riga di comando degli host ESXi.
Il comando tcpdump-uw indica se l'host primario invia correttamente i pacchetti multicast (informazioni su porta e IP) e se tutti gli altri host nel cluster li ricevono.
Nell'host primario, questo comando indica i pacchetti che vengono inviati all'indirizzo multicast. In tutti gli altri host, sono visibili gli stessi pacchetti (dall'host primario all'indirizzo multicast). Se non sono visibili, significa che il multicast non funziona correttamente. Eseguire il comando tcpdump-uw illustrato qui in qualsiasi host del cluster. Gli heartbeat dell'host primario sono visibili. In questo caso, l'host primario si trova all'indirizzo IP 172.32.0.2. La -v per la verbosità è facoltativa.
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast -v tcpdump-uw: listening on vmk2, link-type EN10MB (Ethernet), capture size 96 bytes 11:04:21.800575 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 34917, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200 11:04:22.252369 IP truncated-ip - 234 bytes missing! (tos 0x0, ttl 5, id 15011, offset 0, flags [none], proto UDP (17), length 316) 172.32.0.2.38170 > 224.2.3.4.23451: UDP, length 288 11:04:22.262099 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 3359, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.3.41220 > 224.2.3.4.23451: UDP, length 200 11:04:22.324496 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 20914, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.5.60460 > 224.1.2.3.12345: UDP, length 200 11:04:22.800782 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 35010, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200 11:04:23.252390 IP truncated-ip - 234 bytes missing! (tos 0x0, ttl 5, id 15083, offset 0, flags [none], proto UDP (17), length 316) 172.32.0.2.38170 > 224.2.3.4.23451: UDP, length 288 11:04:23.262141 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 3442, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.3.41220 > 224.2.3.4.23451: UDP, length 200
Anche se questo output sembra un po' confuso, è sufficiente dire che l'output illustrato qui indica che i quattro host nel cluster ricevono un heartbeat dall'host primario. Il comando tcpdump-uw deve essere eseguito in tutti gli host per verificare che ricevano l'heartbeat. Il comando verifica che l'host primario invii gli heartbeat e che tutti gli altri host del cluster li ricevano. Ciò indica che il multicast funziona.
Se alcuni degli host vSAN non sono in grado di ricevere gli heartbeat di un secondo dall'host primario, l'amministratore di rete deve controllare la configurazione multicast dei rispettivi commutatori.
Per evitare il messaggio truncated-ip – 146 bytes missing!, utilizzare l'opzione -s0 nello stesso comando per interrompere il troncamento dei pacchetti:
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast -v -s0
tcpdump-uw: listening on vmk2, link-type EN10MB (Ethernet), capture size 65535 bytes
11:18:29.823622 IP (tos 0x0, ttl 5, id 56621, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200
11:18:30.251078 IP (tos 0x0, ttl 5, id 52095, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.3.41220 > 224.2.3.4.23451: UDP, length 200
11:18:30.267177 IP (tos 0x0, ttl 5, id 8228, offset 0, flags [none], proto UDP (17), length 316)
172.32.0.2.38170 > 224.2.3.4.23451: UDP, length 288
11:18:30.336480 IP (tos 0x0, ttl 5, id 28606, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.5.60460 > 224.1.2.3.12345: UDP, length 200
11:18:30.823669 IP (tos 0x0, ttl 5, id 56679, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200
Il comando tcpdump è correlato all'appartenenza a IGMP (Internet Group Management Protocol). Gli host (e i dispositivi di rete) utilizzano IGMP per stabilire l'appartenenza al gruppo multicast.
Ogni host ESXi nel cluster vSAN invia regolarmente report di appartenenza a IGMP.
Il comando tcpdump mostra i report di appartenenza a IGMP da un host:
[root@esxi-dell-m:~] tcpdump-uw -i vmk1 igmp tcpdump-uw: verbose output suppressed, use -v or -vv for full protocol decode listening on vmk1, link-type EN10MB (Ethernet), capture size 262144 bytes 15:49:23.134458 IP 172.40.0.9 > igmp.mcast.net: igmp v3 report, 1 group record(s) 15:50:22.994461 IP 172.40.0.9 > igmp.mcast.net: igmp v3 report, 1 group record(s)
L'output mostra che i report IGMP v3 sono in esecuzione, indicando che l'host ESXi aggiorna regolarmente la propria appartenenza. Se un amministratore di rete desidera verificare se gli host ESXi di vSAN eseguono correttamente IGMP, può utilizzare questo comando in ogni host ESXi nel cluster e visualizzare questa traccia.
Se sono presenti comunicazioni multicast, utilizzare IGMP v3.
Il comando seguente può infatti essere utilizzato per esaminare contemporaneamente il traffico multicast e IGMP:
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast or igmp -v -s0
Un problema comune consiste nel fatto che il cluster vSAN è configurato in più commutatori fisici e anche se il multicast è stato abilitato in un commutatore, non è abilitato tra i commutatori. In questo caso, il cluster forma una partizione con due host ESXi e un altro host ESXi (connesso all'altro commutatore) non è in grado di partecipare al cluster. Forma invece il proprio cluster vSAN in un'altra partizione. Il comando vsan.lldpnetmap illustrato in precedenza consente di stabilire la configurazione di rete e quali host sono collegati a un determinato commutatore.
Mentre il cluster vSAN viene creato, alcuni indicatori segnalano che il multicast potrebbe rappresentare un problema.
Si supponga di aver applicato l'elenco di controllo per subnet, VLAN e MTU e che ogni host nel cluster possa eseguire vmkping in ogni altro host nel cluster.
Se si verifica un problema relativo al multicast quando il cluster viene creato, un sintomo comune è che ogni host ESXi forma il proprio cluster vSAN, con se stesso come host primario. Se ogni host ha un ID di partizione di rete univoco, questo sintomo indica che tra gli host non è presente alcun multicast.
Tuttavia, se si verifica una situazione in cui un sottoinsieme degli host ESXi forma un cluster e un altro sottoinsieme forma un altro cluster e ognuno dispone di partizioni univoche con il proprio host primario, con l'host di backup e forse persino con gli host dell'agente, significa che il multicast è abilitato nel commutatore, ma non tra i commutatori. vSAN mostra gli host nel primo commutatore fisico che formano la propria partizione del cluster e gli host nel secondo commutatore fisico che formano la propria partizione del cluster, ciascuno con il proprio host primario. Se è possibile verificare a quali commutatori gli host del cluster si connettono e si stabilisce che gli host di un cluster sono connessi allo stesso commutatore, è probabile che il problema sia questo.
Controllo delle prestazioni della rete di vSAN
Assicurarsi che la larghezza di banda tra gli host ESXi sia sufficiente. Questo strumento consente di verificare se la rete di vSAN funziona in modo ottimale.
Per verificare le prestazioni della rete di vSAN, è possibile utilizzare lo strumento iperf per misurare la larghezza di banda e la latenza massime di TCP. Tale strumento è disponibile in /usr/lib/vmware/vsan/bin/iperf.copy.. Eseguirlo con -–help per visualizzare le varie opzioni. Utilizzare questo strumento per verificare la larghezza di banda e la latenza di rete tra gli host ESXi che fanno parte di un cluster vSAN.
Informazioni per l'installazione e il test sono disponibili nell'articolo 2001003 della Knowledge Base di VMware.
Questo strumento risulta particolarmente utile quando si sta per implementare un cluster vSAN. L'esecuzione dei test iperf nella rete di vSAN quando il cluster è già in produzione può influire sulle prestazioni delle macchine virtuali in esecuzione nel cluster.
Controllo dei limiti della rete di vSAN
Il comando vsan.check.limits verifica che nessuna delle soglie del vSAN venga superata.
> ls 0 / 1 vcsa-04.rainpole.com/ > cd 1 /vcsa-04.rainpole.com> ls 0 Datacenter (datacenter) /vcsa-04.rainpole.com> cd 0 /vcsa-04.rainpole.com/Datacenter> ls 0 storage/ 1 computers [host]/ 2 networks [network]/ 3 datastores [datastore]/ 4 vms [vm]/ /vcsa-04.rainpole.com/Datacenter> cd 1 /vcsa-04.rainpole.com/Datacenter/computers> ls 0 Cluster (cluster): cpu 155 GHz, memory 400 GB 1 esxi-dell-e.rainpole.com (standalone): cpu 38 GHz, memory 123 GB 2 esxi-dell-f.rainpole.com (standalone): cpu 38 GHz, memory 123 GB 3 esxi-dell-g.rainpole.com (standalone): cpu 38 GHz, memory 123 GB 4 esxi-dell-h.rainpole.com (standalone): cpu 38 GHz, memory 123 GB /vcsa-04.rainpole.com/Datacenter/computers> vsan.check_limits 0 2017-03-14 16:09:32 +0000: Querying limit stats from all hosts ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-m.rainpole.com (may take a moment) ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-n.rainpole.com (may take a moment) ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-o.rainpole.com (may take a moment) ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-p.rainpole.com (may take a moment) ... 2017-03-14 16:09:39 +0000: Done fetching vSAN disk infos +--------------------------+--------------------+-----------------------------------------------------------------+ | Host | RDT | Disks | +--------------------------+--------------------+-----------------------------------------------------------------+ | esxi-dell-m.rainpole.com | Assocs: 1309/45000 | Components: 485/9000 | | | Sockets: 89/10000 | naa.500a075113019b33: 0% Components: 0/0 | | | Clients: 136 | naa.500a075113019b37: 40% Components: 81/47661 | | | Owners: 138 | t10.ATA_____Micron_P420m2DMTFDGAR1T4MAX_____ 0% Components: 0/0 | | | | naa.500a075113019b41: 37% Components: 80/47661 | | | | naa.500a07511301a1eb: 38% Components: 81/47661 | | | | naa.500a075113019b39: 39% Components: 79/47661 | | | | naa.500a07511301a1ec: 41% Components: 79/47661 | <<truncated>>
Dal punto di vista della rete, sono importanti le associazioni RDT (Assocs) e il numero di socket. In vSAN 6.0 e versioni successive sono presenti 45.000 associazioni per host. Un'associazione RDT viene utilizzata per tenere traccia dello stato della rete peer-to-peer in vSAN. vSAN ha dimensioni tali da non esaurire mai le associazioni RDT. vSAN limita inoltre il numero di socket TCP che è consentito utilizzare e ha dimensioni tali da non esaurire mai le allocazioni dei socket TCP. Esiste un limite di 10.000 socket per host.
Un client vSAN rappresenta l'accesso dell'oggetto nel cluster vSAN. Il client rappresenta in genere una macchina virtuale in esecuzione in un host. Il client e l'oggetto potrebbero non trovarsi nello stesso host. Non è definito alcun limite rigido, ma questa metrica viene visualizzata per consentire di comprendere il modo in cui i client vengono bilanciati tra gli host.
Per un determinato oggetto vSAN, esiste un solo proprietario vSAN che si trova in genere nella stessa posizione del client vSAN che accede a questo oggetto. I proprietari vSAN coordinano tutti gli accessi all'oggetto vSAN e implementano le funzionalità, come il mirroring e lo striping. Non è definito alcun limite rigido, ma questa metrica viene visualizzata per consentire di comprendere il modo in cui i proprietari vengono bilanciati tra gli host.
