Solución de problemas de rendimiento en clústeres Hyperflex

Introducción

Este documento describe el impacto en el rendimiento en un entorno hiperflex, desde la perspectiva de una máquina virtual de invitado (VM), un host ESXi y una máquina virtual (SCVM) 

Identificar

Para solucionar problemas de rendimiento en un entorno Hyperflex, es importante identificar el tipo de clúster, la operación en la que se ha degradado el rendimiento, la frecuencia de la degradación del rendimiento y el nivel de impacto en el rendimiento que causa la degradación del rendimiento.

Hay varios niveles de impacto en un clúster de hiperflexión, en el nivel de VM de invitado, de host de ESXI y de VM de controlador de almacenamiento.

Tipos de clúster

● Nodos híbridos: utiliza unidades de estado sólido (SSD) para almacenar en caché y discos duros para la capa de capacidad.

● Todos los nodos flash: utiliza unidades SSD o almacenamiento Non-Volatile Memory Express (NVMe) para el almacenamiento en caché, y unidades SSD para la capa de capacidad.

● Nodos NVMe: el uso del almacenamiento NVMe tanto para el almacenamiento en caché como para la capa de capacidad. Todos los nodos NVMe ofrecen el máximo rendimiento para las cargas de trabajo más exigentes con el almacenamiento en caché

Explicación del gráfico de rendimiento

Los sistemas hiperflex tienen una función para supervisar el rendimiento, los gráficos muestran el rendimiento de lectura y escritura del clúster de almacenamiento.

IOPS

Las operaciones de entrada/salida por segundo (IOPS) son una métrica de rendimiento común que se utiliza para medir dispositivos de almacenamiento informático, incluidas las HDD. Esta métrica se utiliza para evaluar el rendimiento de cargas de trabajo de E/S aleatorias.

Gráfico de rendimiento de IOPS.

Rendimiento de procesamiento

La imagen muestra la velocidad de transferencia de datos en el clúster de almacenamiento medida en Mbps.

Gráfico de rendimiento.

 

Latencia

La latencia es una medida del tiempo que tarda en completarse una única solicitud de E/S. Es la duración entre la emisión de una solicitud y la recepción de una respuesta, medida en milisegundos.

Gráfico de rendimiento de latencia.

 

Frecuencia

Es importante definir la frecuencia y la duración del impacto en el rendimiento para revisar el posible impacto en el medio ambiente.

Si el rendimiento se ve afectado todo el tiempo, es necesario comprobar dónde comenzó a degradar el rendimiento y comprobar si hay cambios de configuración o problemas entre el clúster.

Si el rendimiento está afectando de forma intermitente, es necesario comprobar si hay alguna operación o servicio en ejecución en ese momento.

Factores externos

El rendimiento del clúster puede verse afectado por factores externos como las instantáneas y las operaciones de copia de seguridad.

Consulte estos enlaces para obtener más información sobre factores externos: 

Instantáneas de VMware vSphere: rendimiento y prácticas recomendadas.

Sistemas Cisco HyperFlex y Veeam Backup and Replication White Paper.

Identificar problemas de rendimiento en el nivel de VM de invitado

Este es el nivel de impacto más visible en el entorno hiperflex, afecta directamente a los servicios que las VM están proporcionando y es más evidente con los usuarios que se ven directamente afectados.

A continuación se indican pruebas comunes para identificar el rendimiento en sistemas operativos comunes.

Windows:

Revise las herramientas disponibles para identificar problemas de rendimiento en las VM de invitado de Windows:

Supervisor de rendimiento

Monitor de recursos

ESXi

Después de identificar el impacto en el rendimiento y revisar las posibles causas de la degradación del rendimiento, hay algunas comprobaciones de rendimiento para mejorar el rendimiento.

• Compruebe si hay provisión excesiva (el número total de vCPU asignadas a todas las VM no debe superar el número total de núcleos físicos disponibles en el equipo host de ESXi).
• Incluso si el SO invitado no utiliza algunas de sus vCPU, la configuración de VM con esas vCPU sigue imponiendo algunos pequeños requisitos de recursos en ESXi que se traducen en un consumo real de CPU en el host​.
• La sobreasignación de memoria también aumenta innecesariamente la sobrecarga de memoria de la VM y puede conducir a la contención de la memoria, especialmente si se utilizan reservas.
• Compruebe que el controlador de globo no mantiene una retención en la memoria. Para obtener más información, consulte este vínculo.

Consulte Solución de problemas de rendimiento de la máquina virtual ESX/ESXi.  

Comprobación de PVSCSI 

Los adaptadores SCSI paravirtuales (PVSCSI) son adaptadores de almacenamiento de alto rendimiento que pueden dar como resultado un mayor rendimiento y una menor utilización de la CPU para máquinas virtuales con requisitos de E/S de disco elevados. Se recomienda utilizar adaptadores PVSCSI. El controlador PVSCSI es un adaptador SCSI de alto rendimiento preparado para la virtualización que permite la menor latencia posible y el mayor rendimiento con la menor sobrecarga de CPU.

Adaptador PVSCSI.

Comprobación del adaptador de red

VMXNET 3 es una NIC paravirtualizada diseñada para el rendimiento y proporciona funciones de alto rendimiento que se utilizan habitualmente en las redes modernas, como tramas gigantes, compatibilidad con varias colas (también conocida como Receive Side Scaling en Windows), descargas de IPv6 y entrega de interrupciones MSI/MSI-X y descargas de hardware.

Asegúrese de que el tipo de adaptador es VMXNET3.

Adaptador de red.

Comprobación de RSS

La escalabilidad del lado de recepción (RSS) es una tecnología de controlador de red que permite la distribución eficaz del procesamiento de recepción de red entre varias CPU en sistemas multiprocesador.

Los servidores de Windows tienen una configuración de controlador que permite la distribución de la carga de procesamiento de red en modo kernel a través de varias CPU.

Compruebe si está habilitado para ejecutar este comando en Windows PowerShell:

netsh interface tcp set global rss=enabled

Para habilitar RSS revise este link

Comprobación de conexión en caliente de CPU

La conexión en caliente de la CPU es una función que permite al administrador de la máquina virtual agregar CPU a la máquina virtual sin tener que apagarla. Esto permite agregar recursos de CPU sobre la marcha sin interrumpir el servicio. Cuando se habilita el hotplug de la CPU en una máquina virtual, se deshabilita la capacidad vNUMA.

Conexión en caliente de la CPU desactivada.

Revise las prácticas recomendadas para las aplicaciones y los sistemas operativos comunes:

Windows.

Instrucciones de ajuste del rendimiento para Windows Server 2022.

Sombrero rojo.

3 consejos para mejorar el rendimiento de los procesos de Linux con prioridad y afinidad.

Servidor SQL.

Arquitectura de Microsoft SQL Server en VMware.

RedHat.

Guía de ajuste del rendimiento.

Identificar problemas de rendimiento a nivel de host

Para identificar el impacto en el rendimiento a nivel de host, puede revisar los gráficos de rendimiento que el host de ESXI ha incorporado en el hipervisor de ESXI y comprobar cuántos hosts se han visto afectados.

Puede ver los gráficos de rendimiento en vCenter en la ficha Monitor y, a continuación, haga clic en la ficha Rendimiento.

Gráficos de rendimiento de vCenter.

 

En estos gráficos, puede ver los gráficos de rendimiento relacionados con la CPU, la memoria y el disco. Consulte este enlace para comprender los gráficos.

Control de E/S de almacenamiento y comprobación de profundidad de cola

El control de E/S de almacenamiento (SIOC) se utiliza para controlar el uso de E/S de una máquina virtual y para aplicar gradualmente los niveles de uso compartido de E/S predefinidos. Es necesario desactivar esta función en los clústeres de hiperflexión.

Profundidad de cola es el número de solicitudes pendientes de entrada/salida (E/S) que un recurso de almacenamiento puede gestionar en cualquier momento.

Puede utilizar estos pasos para verificar que SIOC está desactivado y que la configuración de profundidad de la cola.

Confirme que SIOC se está ejecutando en ESXi y la configuración de profundidad de la cola

 Paso 1. SSH a un host HX ESXi y ejecute el comando para enumerar los almacenes de datos.

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

Paso 2. Utilice el nombre del almacén de datos y ejecute el 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 } 
     

Paso 3. En el resultado, busque la línea  

iormState:0 0= disabled 2= enabled

La línea maxQDepth debe ser 1024

Paso 4. Se deben repetir los mismos pasos para el resto de los almacenes de datos

Desactivar SIOC 

Para inhabilitar el SIOC, ejecute estos pasos.

 Paso 1. Inicie sesión en vsphere mediante el cliente HTML.

Paso 2. En el menú desplegable, seleccione Almacenamiento y, a continuación, seleccione el almacén de datos HX correspondiente en el panel izquierdo.

Seleccione almacén de datos.

 

Paso 3. En la sección superior del panel derecho del almacén de datos, seleccione la ficha configurar.

Ficha Configurar.

 

Paso 4. En la sección central del panel derecho, en Más, seleccione General y, en la parte derecha, desplácese hasta Capacidades del almacén de datos y haga clic en Editar

Edite las capacidades del almacén de datos.

 

 Si el botón de opción Desactivar control de E/S de almacenamiento y recopilación de estadísticas no está activado, márquelo.

Desactive el control de E/S de almacenamiento.

 

 Si el botón de opción Desactivar el control de E/S de almacenamiento y la recopilación de estadísticas está activado, alterne entre Activar control de E/S de almacenamiento y recopilación de estadísticas y Desactivar control de E/S de almacenamiento y recopilación de estadísticas.

Control de E/S de almacenamiento desactivado.

 

Paso 5. Repita los pasos del 1 al 4 según sea necesario para todos los demás almacenes de datos.

Modificar MaxQDepth

Para modificar el maxQDepth, ejecute el siguiente comando para cada almacén de datos.

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

Comprobar Rx_no_Buff 

Los servidores hiperflex con tráfico de red denso o tráfico de red con microrráfagas pueden conducir a la pérdida de paquetes en forma de rx_no_bufs.

Para identificar este problema, ejecute estos comandos en el host de ESXi para comprobar los contadores 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

Espere unos minutos y ejecute el comando nuevamente y verifique si los contadores rx_no_bufs no aumentan.

• Si estos contadores son bajos (< 1.000), entonces con poca pérdida de paquetes debido a la configuración de cola predeterminada y probablemente no es necesario realizar ningún ajuste.
• Si estos contadores son altos (> 10.000), entonces hay cierto impacto debido a esta configuración de cola y el ajuste podría ayudar un poco.
• Si estos contadores son muy altos (> 1.000.000), entonces hay un impacto más significativo, se recomienda encarecidamente aumentar las colas.
• Si rx_no_bufs está incrementando activamente, esto significa que el paquete llegó hasta el final de la red y llega a la capa virtualizada, entonces el paquete se descarta.
  
  

Si ve el contador en estos valores, póngase en contacto con el TAC de Cisco para ajustar la configuración de vNIC y obtener así un mejor rendimiento.

Revise las mejores prácticas y verificaciones adicionales en el nivel ESXI.

Prácticas recomendadas de rendimiento para VMware vSphere 7.0.

Identificar problemas de rendimiento Nivel de máquina virtual del controlador de almacenamiento (SCVM)

Estado del clúster

Compruebe si el clúster está correcto. 

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:~$

Este resultado muestra un clúster inestable debido a un nodo no disponible.

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:~$

Este resultado muestra un clúster inestable debido a la reconstrucción. 

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

Estos comandos muestran un resumen general del estado del clúster y le permiten saber si hay algo que esté afectando al funcionamiento del clúster, por ejemplo, si hay un disco en la lista negra, un nodo sin conexión o si el clúster se está recuperando.

 Nodos Que Participan En E/S

El rendimiento puede verse afectado por un nodo que no participa en las operaciones de entrada y salida; para comprobar los nodos que participan en E/S, ejecute estos comandos. 

Sugerencia: a partir de la versión 5.0(2a), el usuario diag está disponible para permitir que los usuarios tengan más privilegios para solucionar problemas con el acceso a carpetas y comandos restringidos que no son accesibles a través de la línea de comandos priv que se introdujo en la versión 4.5.x de Hyperflex.

Paso 1. Ingrese en el shell de diagnóstico en una máquina virtual de controlador de almacenamiento.

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


Enter the output of above expression: -1
Valid captcha

Paso 2. Ejecute este comando para verificar los nodos que participan en las operaciones de E/S. El número de IP debe ser igual al número de nodos convergentes del clúster.

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

Comprobación de servicios internos

Limpiador

Uno de los principales objetivos de Cleaner es identificar los bloques de almacenamiento muertos y vivos en el sistema y eliminar los muertos, liberando el espacio de almacenamiento ocupado por ellos. Es un trabajo de fondo, y su agresividad se establece en base a una política.

Puede comprobar el servicio de limpieza ejecutando el siguiente comando.

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

Para iniciar el proceso de limpieza, ejecute este 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# 

Reequilibrar

El clúster de almacenamiento se reequilibra según una programación regular. Se utiliza para realinear la distribución de los datos almacenados a través de los cambios en el almacenamiento disponible y para restaurar el estado del clúster de almacenamiento.

El re-equilibrio se ejecuta en clústeres por diferentes razones:

• Un recurso físico (nodo/disco) está inactivo y HX está reubicando esos Vnodes en un recurso físico diferente del clúster.
• No todas las unidades individuales del clúster se utilizan de forma comparable, por lo que se han creado algunas zonas Wi-Fi en términos de disponibilidad de datos dentro del clúster HX (ubicación de datos).
• El re-equilibrio también puede ejecutarse si no hay cumplimiento de la zona, incluso si el clúster está en buen estado.
• Cuando se agrega un nuevo nodo al clúster existente, los nodos agregados asumen nuevas escrituras tan pronto como se unen al clúster existente.

Verifique que el clúster tenga habilitado el reequilibrio.

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

Error de disco

Para un funcionamiento correcto, el clúster no debe tener discos en la lista negra ni recursos sin conexión.

Debe comprobar si hay algún disco en la lista negra del clúster en la interfaz de conexión de HX. 

Disco en la lista negra.

Verifique en la CLI cualquier recurso sin conexión en cada nodo convergente.

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

Compruebe si hay algún recurso en la lista negra.

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

 

Debe verificar si hay algún disco fallido en cada nodo convergente con este comando.

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:~$

Ejemplo de un nodo sin ningún error de 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 libre

Verifique la memoria libre con este comando, la memoria libre debe ser superior a 2048 MB (libre +caché).

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

si la memoria caché libre + es menor que 2048, es necesario identificar el proceso que está generando la condición Out Of Memory (Sin memoria).

Condición de fin de espacio

La práctica recomendada de la utilización del espacio del clúster de almacenamiento es no superar el 76% en la vista de capacidad de HX Connect. Más allá del 76%, el uso en la vista de capacidad de HX Connect reduce el rendimiento.

Si el clúster de almacenamiento experimenta una condición ENOSPC, el limpiador se ejecuta automáticamente con prioridad alta, lo que puede crear problemas de rendimiento en el clúster. La prioridad se determina por el uso de espacio del clúster.

Si el clúster de almacenamiento alcanza una condición ENOSPC WARN, el limpiador aumenta su intensidad aumentando el número de E/S para recolectar basura con una condición ENOSPC establecida, se ejecuta con la prioridad más alta.

Puede verificar el estado ENOSPCINFO en el clúster con este comando. 

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:~$

Consulte el informe técnico sobre administración de la capacidad de Cisco HyperFlex para identificar las prácticas recomendadas para administrar el espacio en el clúster de Hyperflex.

Troubleshooting de Gráficos de Rendimiento

A veces, los gráficos de rendimiento de hiperflexión no muestran información.

Gráficos de rendimiento de hiperflex.

 

Si se enfrenta a este comportamiento, debe revisar si los servicios de estadísticas se están ejecutando en el clúster. 

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

Si los procesos no se están ejecutando, inicie manualmente los servicios.

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

Información Relacionada

• Administración de la capacidad en el informe técnico de Cisco HyperFlex.
• Pruebas de rendimiento de cargas de trabajo críticas de diferentes enfoques hiperconvergentes en la plataforma Cisco Unified Computing System Platform (UCS)
• Soporte Técnico y Documentación - Cisco Systems.