Solução de problemas de desempenho em clusters Hyperflex

Introdução

Este documento descreve o impacto no desempenho em um ambiente hyperflex, da perspectiva de uma máquina virtual convidada (VM), host ESXi e (SCVM) 

Identificar

Para solucionar problemas de desempenho em um ambiente Hyperflex, é importante identificar o tipo de cluster, a operação em que o desempenho é degradado, a frequência da degradação do desempenho e o nível de impacto no desempenho que causa a degradação do desempenho.

Há vários níveis de impacto em um cluster hyperflex, na VM convidada, no nível do host ESXI e no nível da VM do controlador de armazenamento.

Tipos de cluster

● Nós híbridos: usa unidades de estado sólido (SSD) para cache e HDDs para a camada de capacidade.

● Todos os nós flash: Usa unidades SSD ou armazenamento Non-Volatile Memory Express (NVMe) para armazenamento em cache, e unidades SSD para a camada de capacidade.

● Todos os nós NVMe: usa o armazenamento NVMe para o armazenamento em cache e a camada de capacidade todos os nós NVMe fornecem o mais alto desempenho para as cargas de trabalho mais exigentes com armazenamento em cache

Explicação do Gráfico de Desempenho

Os sistemas hyperflex têm um recurso para monitorar o desempenho. Os gráficos exibem o desempenho de leitura e gravação do cluster de armazenamento.

IOPS

Input/output operations per second (IOPS) é uma métrica de desempenho comum usada para medir dispositivos de armazenamento de computador, incluindo HDDs. Essa métrica é usada para avaliar o desempenho de cargas de trabalho de E/S aleatórias.

Gráfico de desempenho de IOPS.

Transferência

A imagem mostra a taxa de transferência de dados no cluster de armazenamento medida em Mbps.

Gráfico de desempenho de throughput.

 

Latência

A latência é uma medida do tempo necessário para que uma única solicitação de I/O seja concluída. É a duração entre emitir uma solicitação e receber uma resposta, medida em milissegundos.

Gráfico de desempenho de latência.

 

Frequência

É importante definir a frequência e a duração do impacto no desempenho para analisar o possível impacto no ambiente.

Se o desempenho for afetado o tempo todo, é necessário verificar onde ele começou a degradar o desempenho e verificar se há alterações ou problemas de configuração entre o cluster.

Se o desempenho estiver afetando intermitentemente, será necessário verificar se há uma operação ou serviço em execução nesse momento.

Fatores externos

O desempenho do cluster pode ser afetado por fatores externos, como snapshots e operações de backup.

Revise estes links para obter mais informações sobre fatores externos: 

Instantâneos do VMware vSphere: desempenho e práticas recomendadas.

White Paper sobre Cisco HyperFlex Systems e Veeam Backup and Replication.

Identificar problemas de desempenho no nível da máquina virtual Convidada

Esse é o nível de impacto mais visível no ambiente hyperflex, ele afeta diretamente os serviços que as VMs estão fornecendo e é mais evidente com os usuários que são diretamente afetados.

Estes são os testes comuns para identificar o desempenho em sistemas operacionais comuns.

Windows

Revise as ferramentas disponíveis para identificar problemas de desempenho nas VMs Convidadas do Windows:

Monitor de desempenho

Monitor de recursos

ESXi

Depois de identificar o impacto no desempenho e revisar as possíveis causas da degradação do desempenho, há algumas verificações de desempenho para melhorar o desempenho.

• Verifique se há excesso de provisionamento (o número total de vCPUs atribuídas a todas as VMs não deve exceder o número total de núcleos físicos disponíveis na máquina host ESXi).
• Mesmo que o sistema operacional convidado não use algumas de suas vCPUs, a configuração de VMs com essas vCPUs ainda impõe alguns pequenos requisitos de recursos no ESXi que se traduzem em consumo real de CPU no host​.
• A superalocação de memória também aumenta desnecessariamente a sobrecarga de memória da VM e pode levar à contenção de memória, especialmente se as reservas forem usadas.
• Verifique se o driver Balloon não está retendo uma retenção na memória. Para obter mais informações, consulte este link.

Consulte Solução de problemas de desempenho da máquina virtual ESX/ESXi.  

Verificação de PVSCSI 

Os adaptadores PVSCSI (Paravirtual SCSI) são adaptadores de armazenamento de alto desempenho que podem resultar em maior throughput e menor utilização da CPU para máquinas virtuais com altos requisitos de E/S de disco. É recomendável usar adaptadores PVSCSI. O controlador PVSCSI é um adaptador SCSI de alto desempenho e com reconhecimento de virtualização que permite a menor latência possível e a maior taxa de transferência com a menor sobrecarga de CPU.

Adaptador PVSCSI.

Verificação do adaptador de rede

O VMXNET 3 é uma placa de rede paravirtualizada projetada para desempenho e fornece recursos de alto desempenho comumente usados em redes modernas, como quadros jumbo, suporte a várias filas (também conhecido como Receive Side Scaling no Windows), descarregamentos de IPv6 e descarregamentos de hardware e entrega de interrupção MSI/MSI-X.

Verifique se o tipo de adaptador é VMXNET3.

Adaptador de rede.

Verificação de RSS

Receive Side Scaling (RSS) é uma tecnologia de driver de rede que permite a distribuição eficiente do processamento de recepção de rede através de várias CPUs em sistemas multiprocessadores.

Os servidores Windows têm uma configuração de driver que permite a distribuição da carga de processamento de rede no modo kernel entre várias CPUs.

Verifique se está habilitado. Execute este comando no Windows PowerShell:

netsh interface tcp set global rss=enabled

Para habilitar a revisão de RSS, este link

Verificação de Hot-Plug da CPU

O hotplug da CPU é um recurso que permite ao administrador da VM adicionar CPUs à VM sem ter que desligá-la. Isso permite adicionar recursos da CPU com o sistema em operação sem interromper o serviço. Quando o hotplug da CPU está habilitado em uma VM, o recurso vNUMA é desabilitado.

Hot plug da CPU desativado.

Analise as práticas recomendadas para sistemas operacionais e aplicativos comuns:

Windows.

Diretrizes de Ajuste de Desempenho para Windows Server 2022.

Chapéu Vermelho.

Três dicas para aprimoramento do desempenho do processo Linux com prioridade e afinidade.

Servidor SQL.

Arquitetura do Microsoft SQL Server em VMware.

RedHat.

Performance Tuning Guide (Guia de ajuste de desempenho).

Identificar problemas de desempenho no nível do host

Para identificar o impacto no desempenho no nível do host, você pode revisar os gráficos de desempenho que o host ESXI tem integrado no hipervisor ESXI e verificar quantos hosts são afetados.

Você pode exibir os gráficos de desempenho no vCenter na guia Monitor e clicar na guia Desempenho.

Gráficos de desempenho do vCenter.

 

Nesses gráficos, você pode exibir os gráficos de desempenho relacionados à CPU, memória e Disco. Consulte este link para entender os gráficos.

Controle de armazenamento de E/S e verificação de profundidade da fila

O Storage I/O Control (SIOC) é usado para controlar o uso de E/S de uma máquina virtual e para aplicar gradualmente os níveis de compartilhamento de E/S predefinidos, é necessário ter esse recurso desabilitado em clusters Hyperflex.

A profundidade da fila é o número de solicitações de entrada/saída (E/S) pendentes que um recurso de armazenamento pode tratar a qualquer momento.

Você pode usar estas etapas para verificar se o SIOC está desativado e se a configuração de Profundidade da Fila.

Confirme se o SIOC está sendo executado no ESXi e na Configuração de profundidade da fila

 Etapa 1. Use SSH para um host ESXi HX e emita o comando para listar os armazenamentos de dados.

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

Etapa 2. Use o nome do Repositório de Dados e emita o 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 } 
     

Etapa 3. Na saída, procure a linha  

iormState:0 0= disabled 2= enabled

A linha maxQDepth deve ser 1024

Etapa 4. As mesmas etapas devem ser repetidas para o restante dos datastores

Desabilitar SIOC 

Para desativar o SIOC, execute estas etapas.

 Etapa 1. Faça login no vsphere usando o cliente HTML.

Etapa 2. No menu suspenso, selecione Storage (Armazenamento) e selecione o HX Datastore aplicável no painel esquerdo.

Selecione o armazenamento de dados.

 

Etapa 3. Na seção superior do painel direito do Armazenamento de dados, selecione a guia Configurar.

guia Configurar.

 

Etapa 4. Na seção do meio do painel direito, em More (Mais), selecione General (Geral) e, no lado direito, role para baixo até Data Store Capabilities (Recursos do Data Store) e clique em Edit (Editar)

Editar recursos de armazenamento de dados.

 

 Se o botão de opção Desativar o controle de E/S de armazenamento e a coleta de estatísticas estiver desmarcado, marque-o.

Desabilite o controle de E/S de armazenamento.

 

 Se o botão de opção Desativar Controle de E/S de Armazenamento e coleta de estatísticas estiver marcado, alterne entre Ativar Controle de E/S de Armazenamento e coleta de estatísticas e Desativar Controle de E/S de Armazenamento e coleta de estatísticas.

Controle de E/S de armazenamento desabilitado.

 

Etapa 5. Repita as etapas de 1 a 4 conforme necessário para todos os outros armazenamentos de dados.

Modificar MaxQDepth

Para modificar o maxQDepth, emita o próximo comando para cada armazenamento de dados.

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

Verificar Rx_no_Buff 

Os servidores Hyperflex com tráfego pesado de rede ou tráfego de rede com microintermitências podem levar à perda de pacotes vistos na forma de rx_no_bufs.

Para identificar esse problema, execute esses comandos no host ESXi para verificar os 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

Aguarde alguns minutos e execute o comando novamente e verifique se os contadores rx_no_bufs não estão aumentando.

• Se esses contadores forem baixos (< 1.000), haverá pouca perda de pacotes devido à configuração de fila padrão e provavelmente nenhum ajuste precisará ser feito.
• Se esses contadores forem altos (> 10.000), haverá algum impacto devido a essa configuração de fila e o ajuste poderá ajudar um pouco.
• Se esses contadores forem muito altos (> 1.000.000), haverá um impacto mais significativo, o aumento de filas é altamente recomendado.
• Se o rx_no_bufs estiver sendo incrementado ativamente, isso significa que o pacote foi feito por toda a rede e chega à camada virtualizada, em seguida, o pacote é descartado.
  
  

Se você vir o contador desses valores, entre em contato com o TAC da Cisco para ajustar a configuração do vNIC para obter melhor desempenho.

Reveja as melhores práticas e verificações adicionais no ESXI Level.

Práticas recomendadas de desempenho para o VMware vSphere 7.0.

Identificar problemas de desempenho Nível da máquina virtual do controlador de armazenamento (SCVM)

Integridade do Cluster

Verifique se o cluster está íntegro. 

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

Esta saída mostra um cluster não íntegro devido a um nó indisponível.

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

Esta saída mostra um cluster não íntegro devido à recriação. 

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

Esses comandos mostram um resumo geral da integridade do cluster e permitem que você saiba se algo está afetando a operação do cluster, por exemplo, se há um disco na lista negra, um nó off-line ou se o cluster está se recuperando.

 Nós Participando De I/O

O desempenho pode ser afetado por um nó que não participa das operações de entrada e saída. Para verificar os nós que participam da E/S, emita esses comandos. 

Dica: da versão 5.0(2a), o usuário diag está disponível para permitir que os usuários tenham mais privilégios para solucionar problemas com acesso a pastas restritas e comandos que não são acessíveis através da linha de comando priv, que foi introduzida na versão 4.5.x do Hyperflex.

Etapa 1. Entre no shell de diagnóstico em uma VM de controladora de armazenamento.

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


Enter the output of above expression: -1
Valid captcha

Etapa 2. Emita este comando para verificar os nós que estão participando das operações de I/O, o número de IPs deve ser igual ao número de nós convergentes no cluster.

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

Verificação de Serviços Internos

Limpador

Um dos principais objetivos do Cleaner é identificar blocos de armazenamento mortos e vivos no sistema e remover os mortos, liberando o espaço de armazenamento ocupado por eles É um trabalho de fundo, e sua agressividade é definida com base em uma política.

Você pode verificar o serviço de limpeza emitindo o próximo 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 o processo de limpeza, execute 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# 

Rebalancear

O cluster de armazenamento é rebalanceado regularmente. É usado para realinhar a distribuição dos dados armazenados em alterações no armazenamento disponível e para restaurar a integridade do cluster de armazenamento.

Rebalancear execuções em clusters por diferentes motivos:

• Um recurso físico (nó/disco) está inativo e o HX está realocando esses Vnodes para um recurso físico diferente no cluster.
• Nem todos os drives individuais no cluster são utilizados de forma comparável e, portanto, alguns pontos de acesso foram criados em termos de disponibilidade de dados no cluster HX (colocação de dados).
• O rebalanceamento também pode ser executado se a conformidade de zona não estiver lá, mesmo se o cluster estiver íntegro.
• Quando um novo nó é adicionado ao cluster existente, os nós adicionados assumem novas gravações assim que ingressam no cluster existente.

Verifique se o reequilíbrio do cluster está habilitado.

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

Falha de disco

Para que o cluster funcione corretamente, ele não deve ter nenhum disco ou recurso off-line na lista negra.

Você precisa verificar se há algum disco na lista negra do cluster na interface do HX Connect. 

Disco na lista negra.

Verifique na CLI se há recursos off-line em cada nó de convergência.

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

Verifique se há recursos na 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

 

Você precisa verificar se há algum disco com falha em cada nó de convergência com esse 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:~$

Exemplo de um nó sem nenhuma falha 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:~$

Memória livre

Verifique a memória livre com esse comando; a memória livre deve ter mais de 2048 MB (cache + livre).

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

se a memória livre + cache for menor que 2048, isso será necessário para identificar o processo que está gerando a condição Out Of Memory.

Condição de Fim de Espaço

A prática recomendada de utilização do espaço do cluster de armazenamento é não ir além de 76% na visualização da capacidade do HX Connect. Além dos 76%, o uso na visualização da capacidade do HX Connect resulta em redução do desempenho.

Se o cluster de armazenamento estiver passando por uma condição ENOSPC, o limpador será executado automaticamente com alta prioridade, o que pode criar problemas de desempenho no cluster. A prioridade é determinada pelo uso do espaço do cluster.

Se o cluster de armazenamento atingir uma condição WARN do ENOSPC, o limpador aumentará sua intensidade aumentando o número de E/S para coletar lixo com uma condição definida pelo ENOSPC, ele será executado na prioridade mais alta.

Você pode verificar o status de ENOSPCINFO no cluster com esse 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 o White Paper Gerenciamento de Capacidade no Cisco HyperFlex para identificar as práticas recomendadas para gerenciar o espaço no cluster do Hyperflex.

Gráficos de Desempenho de Troubleshooting

Às vezes, os gráficos de desempenho do hyperflex não estão exibindo informações.

Gráficos de desempenho do Hyperflex.

 

Se você enfrentar esse comportamento, será necessário verificar se os serviços stats estão em execução no 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 os processos não estiverem em execução, inicie os serviços manualmente.

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

Informações Relacionadas

• White paper sobre gerenciamento de capacidade no Cisco HyperFlex.
• Teste de desempenho de carga de trabalho de missão crítica de diferentes abordagens hiperconvergentes no Cisco Unified Computing System Platform (UCS)
• Suporte Técnico e Documentação - Cisco Systems.