Risoluzione dei problemi di prestazioni nei cluster Hyperflex

Introduzione

Questo documento descrive l'impatto sulle prestazioni in un ambiente hyperflex, dal punto di vista di una Virtual Machine guest (VM), host ESXi e (SCVM) 

Identificazione

Per risolvere i problemi relativi alle prestazioni in un ambiente Hyperflex, è importante identificare il tipo di cluster, l'operazione in cui le prestazioni sono peggiorate, la frequenza del peggioramento delle prestazioni e il livello di impatto sulle prestazioni che provoca il peggioramento delle prestazioni.

In un cluster hyperflex esistono diversi livelli di impatto, a livello di VM guest, host ESXI e VM del controller di storage.

Tipi di cluster

● Nodi ibridi: utilizza unità a stato solido (SSD) per la memorizzazione nella cache e dischi rigidi per il livello di capacità.

● Nodi All-flash: Utilizza unità SSD o storage Non-Volatile Memory Express (NVMe) per la memorizzazione nella cache e unità SSD per il livello di capacità.

● Nodi all-NVMe: utilizza lo storage NVMe per entrambe le operazioni di caching e i nodi all-NVMe del livello di capacità offrono le prestazioni più elevate per i carichi di lavoro più impegnativi con caching

Spiegazione del grafico delle prestazioni

I sistemi hyperflex dispongono di una funzione per il monitoraggio delle prestazioni, i grafici visualizzano le prestazioni di lettura e scrittura del cluster di memoria.

IOPS

Operazioni di input/output al secondo (IOPS) è una metrica comune utilizzata per misurare i dispositivi di storage dei computer, inclusi i dischi rigidi. Questa metrica viene utilizzata per valutare le prestazioni per i carichi di lavoro I/O casuali.

Grafico delle prestazioni IOPS.

Velocità effettiva

Nell'immagine è illustrata la velocità di trasferimento dei dati nel cluster di memoria, misurata in Mbps.

Grafico delle prestazioni del throughput.

 

Latenza

La latenza indica il tempo necessario per il completamento di una singola richiesta di I/O. Si tratta dell'intervallo di tempo tra l'invio di una richiesta e la ricezione di una risposta, misurato in millisecondi.

Grafico delle prestazioni della latenza.

 

Frequenza

È importante definire la frequenza e la durata dell'impatto sulle prestazioni per esaminare il possibile impatto sull'ambiente.

Se l'impatto sulle prestazioni è continuo, è necessario controllare dove ha iniziato a peggiorare le prestazioni e verificare eventuali modifiche o problemi di configurazione tra il cluster.

Se le prestazioni influiscono in modo intermittente, è necessario verificare se in quel momento è in esecuzione un'operazione o un servizio.

Fattori esterni

Le prestazioni del cluster possono essere influenzate da fattori esterni quali le istantanee e le operazioni di backup.

Consulta questi collegamenti per ulteriori informazioni sui fattori esterni: 

Istantanee di VMware vSphere: prestazioni e best practice.

White paper su Cisco HyperFlex Systems e Veeam Backup and Replication.

Identificazione dei problemi di prestazioni a livello di VM guest

Questo è il livello di impatto più visibile nell'ambiente hyperflex, influisce direttamente sui servizi forniti dalle VM ed è più evidente con gli utenti direttamente interessati.

Di seguito sono riportati i test comuni per identificare le prestazioni sui sistemi operativi comuni.

Windows

Esaminare gli strumenti disponibili per identificare i problemi di prestazioni nelle VM guest Windows:

Monitoraggio prestazioni

Monitoraggio risorse

Eseguibile

Dopo aver identificato l'impatto sulle prestazioni e aver analizzato le possibili cause del peggioramento, vengono eseguiti alcuni controlli delle prestazioni per migliorarne le prestazioni.

• Verificare la presenza di overprovisioning (il numero totale di vCPU assegnate a tutte le VM non deve superare il numero totale di core fisici disponibili sul computer host ESXi).
• Anche se il sistema operativo guest non utilizza alcune delle sue vCPU, la configurazione delle VM con queste vCPU impone ancora alcuni piccoli requisiti di risorse su ESXi che si traducono in un reale consumo di CPU sull'host​.
• La sovrallocazione della memoria aumenta inoltre inutilmente il sovraccarico della memoria della VM e può causare conflitti di memoria, soprattutto se vengono utilizzate prenotazioni.
• Verificare che il driver Balloon non mantenga la memoria bloccata. Per ulteriori informazioni, fare riferimento a questo collegamento.

Consultare la sezione Risoluzione dei problemi di prestazioni dei sistemi virtuali ESX/ESXi.  

Verifica PVSCSI 

Gli adattatori Paravirtual SCSI (PVSCSI) sono adattatori di storage ad alte prestazioni in grado di aumentare il throughput e ridurre l'utilizzo della CPU per le macchine virtuali con requisiti elevati di I/O del disco. È consigliabile utilizzare adattatori PVSCSI. Il controller PVSCSI è un adattatore SCSI ad alte prestazioni con riconoscimento della virtualizzazione che consente la latenza più bassa possibile e il throughput più elevato con il sovraccarico minimo della CPU.

scheda PVSCSI.

Controllo scheda di rete

VMXNET 3 è una scheda NIC paravirtualizzata progettata per le prestazioni e fornisce funzionalità ad alte prestazioni comunemente utilizzate nelle reti moderne, ad esempio frame jumbo, supporto di più code (noto anche come Receive Side Scaling in Windows), offload IPv6 e fornitura di interrupt MSI/MSI-X e offload hardware.

Verificare che il tipo di scheda sia VMXNET3.

Scheda di rete.

Controllo RSS

La tecnologia RSS (Receive Side Scaling) è un driver di rete che consente la distribuzione efficiente dell'elaborazione della ricezione di rete su più CPU in sistemi multiprocessore.

I server Windows dispongono di una configurazione di driver che consente la distribuzione del carico di elaborazione di rete in modalità kernel tra più CPU.

Verificare se è abilitato eseguire questo comando in Windows PowerShell:

netsh interface tcp set global rss=enabled

Per abilitare RSS, rivedere il collegamento

Controllo hot-plug CPU

L'hotplug della CPU è una funzione che consente all'amministratore della VM di aggiungere CPU alla VM senza doverla spegnere. Ciò consente di aggiungere immediatamente risorse CPU senza interruzioni al servizio. Quando l'hotplug della CPU è abilitato su una VM, la funzionalità vNUMA è disabilitata.

Hot-plug CPU disabilitato.

Esaminare le procedure ottimali per i sistemi operativi e le applicazioni più comuni:

Windows.

Linee guida per l'ottimizzazione delle prestazioni per Windows Server 2022.

Cappello rosso.

3 suggerimenti per migliorare le prestazioni dei processi Linux con priorità e affinità.

SQL Server

Architettura di Microsoft SQL Server in VMware.

RedHat.

Guida all'ottimizzazione delle prestazioni.

Identificazione dei problemi di prestazioni a livello di host

Per identificare l'impatto sulle prestazioni a livello di host, è possibile esaminare i grafici delle prestazioni che l'host ESXI ha integrato nell'hypervisor ESXI e verificare il numero di host interessati.

È possibile visualizzare i grafici delle prestazioni in vCenter nella scheda Monitor, quindi fare clic sulla scheda Prestazioni.

Grafici delle prestazioni di vCenter.

 

In questi grafici è possibile visualizzare i grafici delle prestazioni relativi alla CPU, alla memoria e al disco. Fare riferimento a questo collegamento per informazioni sui grafici.

Controllo dello storage I/O e controllo della profondità della coda

Il controllo SIOC (Storage I/O Control) viene utilizzato per controllare l'utilizzo di I/O di una macchina virtuale e per applicare gradualmente i livelli di condivisione di I/O predefiniti. È necessario che questa funzionalità sia disabilitata nei cluster Hyperflex.

Profondità coda indica il numero di richieste di input/output (I/O) in sospeso che una risorsa di archiviazione può gestire contemporaneamente.

È possibile utilizzare questi passaggi per verificare che SIOC sia disabilitato e che la configurazione Profondità coda sia corretta.

Confermare che SIOC sia in esecuzione su ESXi e sulla configurazione della profondità della coda

 Passaggio 1. SSH a un host HX ESXi e usare il comando per elencare gli archivi dati.

[root@] vsish -e ls /vmkModules/nfsclient/mnt
encrypted_app/
Prod/                                        <----- Datastore name 
Dev/
App/

Passaggio 2. Utilizzare il nome dell'archivio dati ed eseguire il comando.

vsish -e get /vmkModules/nfsclient/mnt/
     
     
       /properties [root@] vsish -e get /vmkModules/nfsclient/mnt/Prod/properties mount point information { volume name:Prod server name:7938514614702552636-8713662604223381594 server IP:127.0.0.1 server volume:172.16.3.2:Prod UUID:63dee313-dfecdf62 client src port:641 busy:0 socketSendSize:1048576 socketReceiveSize:1048576 maxReadTransferSize:65536 maxWriteTransferSize:65536 reads:0 readsFailed:0 writes:285 writesFailed:0 readBytes:0 writeBytes:10705 readTime:0 writeTime:4778777 readSplitsIssued:0 writeSplitsIssued:285 readIssueTime:0 writeIssueTime:4766494 cancels:0 totalReqsQueued:0 metadataReqsQueued(non IO):0 reqsInFlight:0 readOnly:0 hidden:0 isPE:0 isMounted:1 isAccessible:1 unstableWrites:0 unstableNoCommit:0 maxQDepth:1024 <-------- Max Qdepth configuration iormState:0 <-------- I/O control disabled latencyThreshold:30 shares:52000 podID:0 iormInfo:0 NFS operational state: 0 -> Up enableDnlc:1 closeToOpenCache:0 highToAvgLatRatio:10 latMovingAvgSmoothingLevel:2 activeWorlds:55 inPreUnmount:0 } 
     

Passaggio 3. Nell'output cercare la riga  

iormState:0 0= disabled 2= enabled

La riga maxQDepth deve essere 1024

Passaggio 4. Gli stessi passaggi devono essere ripetuti per gli altri archivi dati

Disabilita SIOC 

Per disabilitare il SIOC, eseguire questi passaggi.

 Passaggio 1. Accedere a vsphere utilizzando il client HTML.

Passaggio 2. Dal menu a discesa, selezionare Archiviazione, quindi selezionare l'archivio dati HX applicabile nel riquadro sinistro.

Selezionare l'archivio dati.

 

Passaggio 3. Nella sezione superiore del riquadro destro dell'archivio dati, selezionare la scheda Configura.

Scheda Configura.

 

Passaggio 4. Nella sezione centrale del riquadro di destra in Altro, selezionare Generale, e sul lato destro scorrere verso il basso fino a DataStore Capabilities e fare clic su Edit

Modificare le funzionalità dell'archivio dati.

 

 Se il pulsante di scelta Disabilita controllo I/O e raccolta statistiche della memoria è deselezionato, selezionarlo.

Disabilitare il controllo I/O dello storage.

 

 Se il pulsante di scelta Disabilita controllo I/O archiviazione e raccolta statistiche è selezionato, passare da Abilita controllo I/O archiviazione e raccolta statistiche a Disabilita controllo I/O archiviazione e raccolta statistiche.

Controllo I/O archiviazione disabilitato.

 

Passaggio 5. Ripetere i passaggi da 1 a 4 per tutti gli altri archivi dati.

Modifica MaxQDepth

Per modificare maxQDepth, usare il comando successivo per ciascun archivio dati.

vsish -e set /vmkModules/nfsclient/mnt/
     
     
       /properties maxQDepth 1024 
     

Controlla Rx_no_Buff 

I server Hyperflex con traffico di rete elevato o traffico di rete con microburst possono causare la perdita di pacchetti sotto forma di rx_no_bufs.

Per identificare questo problema, eseguire questi comandi nell'host ESXi per controllare i contatori rx_no_buf. 

/usr/lib/vmware/vm-support/bin/nicinfo.sh | egrep "^NIC:|rx_no_buf"
NIC: vmnic0
rx_no_bufs: 1
NIC: vmnic1
rx_no_bufs: 2
NIC: vmnic2
rx_no_bufs: 2
NIC: vmnic3
rx_no_bufs: 71128211 <---------Very high rx_no_bufs counter
NIC: vmnic4
rx_no_bufs: 1730
NIC: vmnic5
rx_no_bufs: 897
NIC: vmnic6
rx_no_bufs: 24952
NIC: vmnic7
rx_no_bufs: 2

Attendere alcuni minuti, eseguire di nuovo il comando e verificare se i contatori rx_no_bufs non aumentano.

• Se i contatori sono bassi (< 1.000), la perdita di pacchetti è minima a causa della configurazione predefinita della coda e probabilmente non è necessario eseguire alcuna regolazione.
• Se questi contatori sono elevati (> 10.000), si verificherà un certo impatto dovuto alla configurazione della coda e il tuning potrebbe essere utile.
• Se questi contatori sono molto elevati (> 1.000.000), l'impatto sarà maggiore, pertanto si consiglia di aumentare le code.
• Se rx_no_bufs aumenta attivamente, il pacchetto viene creato in tutta la rete e arriva al livello virtualizzato, quindi viene scartato.
  
  

Se questi valori indicano il contatore, contattare Cisco TAC per regolare la configurazione della vNIC e ottenere prestazioni migliori.

Esaminare le best practice e i controlli aggiuntivi a livello ESXI.

Procedure ottimali per le prestazioni di VMware vSphere 7.0.

Identificazione dei problemi di prestazioni a livello di macchina virtuale (SCVM) del controller di archiviazione

Integrità cluster

Verificare se il cluster è integro. 

hxshell:~$ sysmtool --ns cluster --cmd healthdetail
Cluster Health Detail:
---------------------:
State: ONLINE                       <---------- State of the cluster 
HealthState: HEALTHY                <---------- Health of the cluster 
Policy Compliance: COMPLIANT
Creation Time: Tue May 30 04:48:45 2023
Uptime: 7 weeks, 19 hours, 45 mins, 51 secs
Cluster Resiliency Detail:
-------------------------:
Health State Reason: Storage cluster is healthy.
# of nodes failure tolerable for cluster to be fully available: 1
# of node failures before cluster goes into readonly: NA
# of node failures before cluster goes to be crticial and partially available: 3
# of node failures before cluster goes to enospace warn trying to move the existing data: NA
# of persistent devices failures tolerable for cluster to be fully available: 2
# of persistent devices failures before cluster goes into readonly: NA
# of persistent devices failures before cluster goes to be critical and partially available: 3
# of caching devices failures tolerable for cluster to be fully available: 2
# of caching failures before cluster goes into readonly: NA
# of caching failures before cluster goes to be critical and partially available: 3
Current ensemble size: 3
Minimum data copies available for some user data: 3
Minimum cache copies remaining: 3
Minimum metadata copies available for cluster metadata: 3
Current healing status:
Time remaining before current healing operation finishes:
# of unavailable nodes: 0

hxshell:~$

Questo output mostra un cluster danneggiato a causa di un nodo non disponibile.

hxshell:~$ sysmtool --ns cluster --cmd healthdetail
Cluster Health Detail:
---------------------:
State: ONLINE                   <-------State of the cluster
HealthState: UNHEALTHY          <-------Health of the cluster 
Policy Compliance: NON-COMPLIANT
Creation Time: Tue May 30 04:48:45 2023
Uptime: 7 weeks, 19 hours, 55 mins, 9 secs
Cluster Resiliency Detail:
-------------------------:
Health State Reason: Storage cluster is unhealthy.Storage node 172.16.3.9 is unavailable.                  <----------- Health state reason
# of nodes failure tolerable for cluster to be fully available: 0
# of node failures before cluster goes into readonly: NA
# of node failures before cluster goes to be crticial and partially available: 2
# of node failures before cluster goes to enospace warn trying to move the existing data: NA
# of persistent devices failures tolerable for cluster to be fully available: 1
# of persistent devices failures before cluster goes into readonly: NA
# of persistent devices failures before cluster goes to be critical and partially available: 2
# of caching devices failures tolerable for cluster to be fully available: 1
# of caching failures before cluster goes into readonly: NA
# of caching failures before cluster goes to be critical and partially available: 2
Current ensemble size: 3
Minimum data copies available for some user data: 2
Minimum cache copies remaining: 2
Minimum metadata copies available for cluster metadata: 2
Current healing status: Rebuilding/Healing is needed, but not in progress yet. Warning: Insufficient node or space resources may prevent healing. Storage Node 172.16.3.9 is either down or initializing disks.
Time remaining before current healing operation finishes:
# of unavailable nodes: 1

hxshell:~$

Questo output mostra un cluster non integro a causa della ricostruzione. 

Cluster Health Detail:
---------------------:
State: ONLINE
HealthState: UNHEALTHY
Policy Compliance: NON-COMPLIANT
Creation Time: Tue May 30 04:48:45 2023
Uptime: 7 weeks, 20 hours, 2 mins, 4 secs
Cluster Resiliency Detail:
-------------------------:
Health State Reason: Storage cluster is unhealthy.
# of nodes failure tolerable for cluster to be fully available: 1
# of node failures before cluster goes into readonly: NA
# of node failures before cluster goes to be crticial and partially available: 2
# of node failures before cluster goes to enospace warn trying to move the existing data: NA
# of persistent devices failures tolerable for cluster to be fully available: 1
# of persistent devices failures before cluster goes into readonly: NA
# of persistent devices failures before cluster goes to be critical and partially available: 2
# of caching devices failures tolerable for cluster to be fully available: 1
# of caching failures before cluster goes into readonly: NA
# of caching failures before cluster goes to be critical and partially available: 2
Current ensemble size: 3
Minimum data copies available for some user data: 3
Minimum cache copies remaining: 2
Minimum metadata copies available for cluster metadata: 2
Current healing status: Rebuilding is in progress, 58% completed.
Time remaining before current healing operation finishes: 18 hr(s), 10 min(s), and 53 sec(s)
# of unavailable nodes: 0

Questi comandi consentono di visualizzare un riepilogo generale dello stato del cluster e di sapere se il funzionamento del cluster è interessato da un problema, ad esempio se è presente un disco nella lista nera, un nodo non in linea o se il cluster sta eseguendo la correzione.

 Nodi che partecipano all'I/O

Le prestazioni possono essere influenzate da un nodo che non partecipa alle operazioni di input e output. Per controllare i nodi che partecipano alle operazioni di I/O, eseguire questi comandi. 

Suggerimento: a partire dalla versione 5.0(2a), diag user è disponibile per consentire agli utenti di disporre di più privilegi per la risoluzione dei problemi relativi all'accesso a cartelle e comandi con restrizioni non accessibili tramite la riga di comando priv introdotta in Hyperflex versione 4.5.x.

Passaggio 1. Accedere alla shell di diagnostica di una VM del controller di storage.

hxshell:~$ su diag
Password:
 _   _ _                      _  _             _____ _                      ___
| \ | (_)_ __   ___          | || |           |  ___(_)_   _____           / _ \ _ __   ___
|  \| | | '_ \ / _ \  _____  | || |_   _____  | |_  | \ \ / / _ \  _____  | | | | '_ \ / _ \
| |\  | | | | |  __/ |_____| |__   _| |_____| |  _| | |\ V /  __/ |_____| | |_| | | | |  __/
|_| \_|_|_| |_|\___|            |_|           |_|   |_| \_/ \___|          \___/|_| |_|\___|


Enter the output of above expression: -1
Valid captcha

Passaggio 2. Eseguire questo comando per verificare i nodi che partecipano alle operazioni di I/O. Il numero di IP deve essere uguale al numero di nodi convergenti sul cluster.

diag# nfstool -- -m | cut -f2 | sort | uniq
172.16.3.7
172.16.3.8
172.16.3.9

Controllo servizi interni

Pulizia

Uno degli obiettivi principali di Cleaner è identificare i blocchi di storage morti e attivi nel sistema e rimuovere quelli morti, liberando lo spazio di storage da essi occupato. Si tratta di un lavoro di background, e la sua aggressività è impostata sulla base di una politica.

Per controllare il servizio di pulitura, eseguire il comando successivo.

bash-4.2# stcli cleaner info
{ 'name': '172.16.3.7', 'id': '1f82077d-6702-214d-8814-e776ffc0f53c', 'type': 'node' }: OFFLINE                <----------- Cleaner shows as offline 
{ 'name': '172.16.3.8', 'id': 'c4a24480-e935-6942-93ee-987dc8e9b5d9', 'type': 'node' }: OFFLINE
{ 'name': '172.16.3.9', 'id': '50a5dc5d-c419-9c48-8914-d91a98d43fe7', 'type': 'node' }: OFFLINE

Per avviare il processo di pulizia, usare questo comando.

bash-4.2# stcli cleaner start                                                                                  
WARNING: This command should be executed ONLY by Cisco TAC support as it may have very severe consequences. Do you want to proceed ? (y/n): y
bash-4.2# stcli cleaner info
{ 'type': 'node', 'id': '1f82077d-6702-214d-8814-e776ffc0f53c', 'name': '172.16.3.7' }: ONLINE
{ 'type': 'node', 'id': 'c4a24480-e935-6942-93ee-987dc8e9b5d9', 'name': '172.16.3.8' }: ONLINE
{ 'type': 'node', 'id': '50a5dc5d-c419-9c48-8914-d91a98d43fe7', 'name': '172.16.3.9' }: ONLINE           <---------All nodes need to be online
bash-4.2# 

Ribilanciamento

Il cluster di memoria viene ribilanciato in base a una pianificazione regolare. Viene utilizzato per riallineare la distribuzione dei dati archiviati tra le modifiche nello storage disponibile e per ripristinare lo stato del cluster di storage.

Il ribilanciamento viene eseguito nei cluster per diversi motivi:

• Una risorsa fisica (nodo/disco) è inattiva e HX sta riposizionando tali nodi in una risorsa fisica diversa nel cluster.
• Le singole unità all'interno del cluster non sono tutte utilizzate in modo comparabile, pertanto sono stati creati alcuni hotspot in termini di disponibilità dei dati all'interno del cluster HX (collocazione dei dati).
• Il ribilanciamento può inoltre essere eseguito se la conformità alla zona non è presente anche se il cluster è integro.
• Quando un nuovo nodo viene aggiunto al cluster esistente, i nodi aggiunti eseguono nuove scritture non appena si uniscono al cluster esistente.

Verificare che per il cluster sia abilitato il ribilanciamento.

hxshell:~$ stcli rebalance status
rebalanceStatus:
    percentComplete: 0
    rebalanceState: cluster_rebalance_not_running
rebalanceEnabled: True     <---------Rebalance should be enabled 
hxshell:~$

Errore del disco

Per il corretto funzionamento, il cluster non deve disporre di dischi in blacklist o di risorse offline.

È necessario verificare se nel cluster è presente un disco presente nella lista nera dell'interfaccia di connessione HX. 

Disco in blacklist.

Controllare nella CLI eventuali risorse non in linea su ciascun nodo di convergenza.

sysmtool --ns cluster --cmd offlineresources 
UUID                                Type         State      InUse      Last modified            
----                                ----         -----      -----      -------------            
000cca0b019b4a80:0000000000000000   DISK         DELETED    YES          <------- Offline disk                       
5002538c405e0bd1:0000000000000000   DISK         BLOCKLISTED NO          <------- Blacklisted disk                         
5002538c405e299e:0000000000000000   DISK         DELETED    NO                                  
Total offline resources: 3, Nodes: 0, Disks: 3

Verificare se sono presenti risorse in blacklist.

hxshell:~$ sysmtool --ns disk --cmd list | grep -i blacklist
Blacklist Count: 0
Blacklist Count: 0
Blacklist Count: 0
Blacklist Count: 0
State: BLACKLISTED
Blacklist Count: 5
Blacklist Count: 0
Blacklist Count: 0

 

Con questo comando è necessario verificare la presenza di eventuali errori del disco in ciascun nodo di convergenza.

admin:~$ cat /var/log/springpath/diskslotmap-v2.txt
0.0.1:5002538e000d59a3:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302248:HXT76F3Q:SATA:SSD:3662830:Inactive:/dev/sdj    <---------Inactive disk
1.0.2:5002538c40be79ac:Samsung:SAMSUNG_MZ7LM240HMHQ-00003:S4EGNX0KC04551:GXT51F3Q:SATA:SSD:228936:Active:/dev/sdb
1.0.3:5002538e000d599e:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302243:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdc
1.0.4:5002538e000d59a0:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302245:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdd
1.0.5:5002538e000eb00b:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302480:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdi
1.0.6:5002538e000d599b:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302240:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdf
1.0.7:5002538e000d57f6:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M301819:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdh
1.0.8:5002538e000d59ab:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302256:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sde
1.0.9:5002538e000d59a1:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M302246:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdg
1.0.10:5002538e0008c68f:Samsung:SAMSUNG_MZ7LH3T8HMLT-00003:S4F3NY0M200500:HXT76F3Q:SATA:SSD:3662830:Active:/dev/sdj
0.1.192:000cca0b01c83180:HGST:UCSC-NVMEHW-H1600:SDM000026904:KNCCD111:NVMe:SSD:1526185:Active:/dev/nvme0n1
admin:~$

Esempio di un nodo senza errori del disco.

hxshell:~$ sysmtool --ns cluster --cmd offlineresources
No offline resources found              <-------- No offline resources 

hxshell:~$ sysmtool --ns disk --cmd list | grep -i blacklist
hxshell:~$                              <-------- No blacklisted disks
hxshell:~$ cat /var/log/springpath/diskslotmap-v2.txt
1.14.1:55cd2e404c234bf9:Intel:INTEL_SSDSC2BX016T4K:BTHC618505B51P6PGN:G201CS01:SATA:SSD:1526185:Active:/dev/sdc
1.14.2:5000c5008547c543:SEAGATE:ST1200MM0088:Z4009D7Y0000R637KMU7:N0A4:SAS:10500:1144641:Active:/dev/sdd
1.14.3:5000c5008547be1b:SEAGATE:ST1200MM0088:Z4009G0B0000R635L4D3:N0A4:SAS:10500:1144641:Active:/dev/sde
1.14.4:5000c5008547ca6b:SEAGATE:ST1200MM0088:Z4009F9N0000R637JZRF:N0A4:SAS:10500:1144641:Active:/dev/sdf
1.14.5:5000c5008547b373:SEAGATE:ST1200MM0088:Z4009GPM0000R634ZJHB:N0A4:SAS:10500:1144641:Active:/dev/sdg
1.14.6:5000c500854310fb:SEAGATE:ST1200MM0088:Z4008XFJ0000R6374ZE8:N0A4:SAS:10500:1144641:Active:/dev/sdh
1.14.7:5000c50085424b53:SEAGATE:ST1200MM0088:Z4008D2S0000R635M4VF:N0A4:SAS:10500:1144641:Active:/dev/sdi
1.14.8:5000c5008547bcfb:SEAGATE:ST1200MM0088:Z4009G3W0000R637K1R8:N0A4:SAS:10500:1144641:Active:/dev/sdj
1.14.9:5000c50085479abf:SEAGATE:ST1200MM0088:Z4009J510000R637KL1V:N0A4:SAS:10500:1144641:Active:/dev/sdk
1.14.11:5000c5008547c2c7:SEAGATE:ST1200MM0088:Z4009FR00000R637JPEQ:N0A4:SAS:10500:1144641:Active:/dev/sdl
1.14.13:5000c5008547ba93:SEAGATE:ST1200MM0088:Z4009G8V0000R634ZKLX:N0A4:SAS:10500:1144641:Active:/dev/sdm
1.14.14:5000c5008547b69f:SEAGATE:ST1200MM0088:Z4009GG80000R637KM30:N0A4:SAS:10500:1144641:Active:/dev/sdn
1.14.15:5000c5008547b753:SEAGATE:ST1200MM0088:Z4009GH90000R635L5F6:N0A4:SAS:10500:1144641:Active:/dev/sdo
1.14.16:5000c5008547ab7b:SEAGATE:ST1200MM0088:Z4009H3P0000R634ZK8T:N0A4:SAS:10500:1144641:Active:/dev/sdp  <------All disks are active
hxshell:~$

Memoria disponibile

Controllare la memoria libera con questo comando. La memoria libera deve essere superiore a 2048 MB (free +cache).

hxshell:~$ free –m                       
              total        used        free      shared  buff/cache   available
Mem:       74225624    32194300    38893712        1672     3137612    41304336
Swap:             0           0           0
hxshell:~$                              

se la memoria libera + cache è inferiore a 2048, è necessario identificare il processo che sta generando la condizione di memoria insufficiente.

Condizione di fine spazio

La procedura ottimale per l'utilizzo dello spazio del cluster di memoria consiste nel non superare il 76% nella vista della capacità di HX Connect. Oltre il 76%, l'utilizzo della vista della capacità di HX Connect determina una riduzione delle prestazioni.

Se nel cluster di archiviazione si verifica una condizione ENOSPC, la pulitura viene eseguita automaticamente con priorità alta e ciò può creare problemi di prestazioni nel cluster. La priorità viene determinata dall'utilizzo dello spazio del cluster.

Se il cluster di memoria raggiunge una condizione ENOSPC WARN, la pulitura aumenta la sua intensità aumentando il numero di I/O per raccogliere il garbage con una condizione ENOSPC impostata, viene eseguita con la massima priorità.

Con questo comando è possibile controllare lo stato di ENOSPCINFO sul cluster. 

hxshell:~$ sysmtool --ns cluster --cmd enospcinfo
Cluster Space Details:
---------------------:
Cluster state: ONLINE
Health state: HEALTHY
Raw capacity: 42.57T
Usable capacity: 13.06T
Used capacity: 163.08G
Free capacity: 12.90T
Enospc state: ENOSPACE_CLEAR    <--------End of space status
Space reclaimable: 0.00
Minimum free capacity
required to resume operation: 687.12G
Space required to clear
ENOSPC warning: 2.80T           <--------Free space until the end of space warning appears 
Rebalance In Progress: NO
Flusher in progress: NO
Cleaner in progress: YES
Disk Enospace: NO

hxshell:~$

Consultare il white paper sulla gestione della capacità in Cisco HyperFlex per identificare la procedura ottimale per gestire lo spazio nel cluster Hyperflex.

Risoluzione dei problemi relativi ai grafici delle prestazioni

A volte i grafici delle prestazioni hyperflex non visualizzano le informazioni.

Grafici delle prestazioni Hyperflex.

 

Se si verifica questo comportamento, è necessario verificare se i servizi Stats sono in esecuzione nel cluster. 

hxshell:~$ priv service carbon-cache status
carbon-cache stop/waiting

hxshell:~$ priv service carbon-aggregator status
carbon-aggregator stop/waiting

hxshell:~$ priv service statsd status
statsd stop/waiting

Se i processi non sono in esecuzione, avviare manualmente i servizi.

hxshell:~$ priv service carbon-cache start
carbon-cache start/running, process 15750

hxshell:~$ priv service carbon-aggregator start
carbon-aggregator start/running, process 15799

hxshell:~$ priv service statsd start
statsd start/running, process 15855

Informazioni correlate

• Gestione della capacità nel white paper Cisco HyperFlex.
• Test delle prestazioni dei carichi di lavoro mission critical su diversi approcci iperconvergenti su Cisco Unified Computing System Platform (UCS)
• Documentazione e supporto tecnico - Cisco Systems.