Contents

Introduction

Como os datastores HX são montados no ESXI?

Todos os caminhos para baixo

Descrição do problema

Troubleshooting do Fluxo de Trabalho

Verifica no vCenter Server:

Verifica todas as VMs StCtl:

StCtlVM: StCtlVM de um host ESXi afetado

Verifica no host ESXi:

Introduction

Este documento fornece compreensão rápida e etapas de solução de problemas que podem ser executadas para avaliar a origem do problema se você vir a mensagem de erro "NFS all paths down" no vCenter ao qual o cluster do Hyperflex está integrado.

Como os datastores HX são montados no ESXI?

- Os Hyperflex Datastores são montados nos hosts ESXI como montagens NFS, para montar um armazenamento de dados NFS, precisamos do IP do NFS Server que, no nosso caso, é a interface virtual flutuante eth1:0.

- O cluster hiperflex aproveita o uso de IP virtual flutuante tanto para gerenciamento (eth0:mgmtip) quanto dados de armazenamento (eth1:0) nos quais cada IP será atribuído a uma VM de Controlador de Armazenamento específica (StCtlVM). Observe que eles podem acabar em StCtlVMs diferentes.

- A importância disso é que o IP de dados de armazenamento de cluster (eth1:0) é o usado para montar o(s) datastore(s) criado(s) no cluster do Hyperflex. Assim, é essencial que ele seja atribuído e acessível de todos os nós do cluster.

- Observe que, em caso de falha da StCtlVM que atualmente possui IP virtual eth1:0, ela deve "migrar" para outra StCtlVM disponível que funcione de forma semelhante a um FHRP (First Hop Redundancy Protocol).

Todos os caminhos para baixo

- APD significa que o host não pode acessar o armazenamento e que não há código SCSI PDL (Permanent Device Lost, dispositivo permanente perdido) retornado da matriz de armazenamento.

- Como não sabe se a perda é temporária ou não, ele continuará tentando estabelecer comunicação por mais de 140 s por padrão (tempo limite) + 3 minutos (atraso para failover), o ESXi Host começa a falhar em qualquer tráfego de I/O de máquina não virtual que está sendo enviado ao dispositivo de armazenamento.

- Para obter mais detalhes sobre APD no ambiente vSphere 6.x, consulte o artigo do KB do Vmware Perda de dispositivo permanente (PDL) e All-Paths-Down (APD) no vSphere 5.x e 6.x

- A imagem abaixo explica cada estágio intermitente:

Uma mensagem de erro típica no vCenter será a seguinte.

Descrição do problema

Depois de ver os alertas APD sobre seus hosts, obtenha as informações abaixo para entender melhor a descrição do problema:

- Se um/vários/todos os hosts tiverem impacto, e se alguns dos hosts específicos tiverem impacto

- Se alguma alteração tiver sido feita anteriormente (configuração/atualização/etc.)

- O carimbo de data e hora em que o problema foi observado pela primeira vez e se o problema é recorrente

Troubleshooting do Fluxo de Trabalho

Para solucionar problemas de APD, precisamos examinar 3 componentes - vCenter, SCVM e host ESXi.

Essas etapas são um fluxo de trabalho sugerido para apontar ou restringir a origem do sintoma All Paths Down observado. Observe que este pedido não precisa ser seguido meticulosamente e você pode adequá-lo de acordo com os sintomas específicos observados no ambiente do cliente.

Verifica no vCenter Server:

Conecte-se ao vCenter Server (VCS) e navegue até um host afetado

1. Objetos relacionados -> Máquinas virtuais e confirme se o StCtlVM está ativo e em execução

2. Objetos relacionados -> Datastores e confirme se os datastores NFS mostram "inacessível". Se os armazenamentos de dados parecerem acessíveis e o status, você pode tentar na guia Resumo para "Redefinir para verde" o evento APD e verificar mais tarde se o alerta aparece novamente mais tarde

3. Monitor -> Issues and Monitor -> Events deve fornecer informações sobre quando o APD foi detectado pela primeira vez.

Verifica todas as VMs StCtl:

Conecte-se a todas as VMs StCtl e verifique os indicadores abaixo. Você pode usar MobaXterm software.

1. Verifique se todas as StCtlVMs têm o mesmo tempo usando date ou ntpq -p. O desvio de tempo em StCtlVM pode levar a problemas com a sincronização do banco de dados de zookeeper e, portanto, é fundamental tê-lo em sincronização entre todas as StCtlVMs.

- O sinal de entrada do servidor ntp indica que o NTP de seu SCVM está sincronizado.
root@SpringpathControllerPZTMTRSH7K:~# date

Tue May 28 12:47:27 PDT 2019

root@SpringpathControllerPZTMTRSH7K:~# ntpq -p -4

remote refid st t when poll reach delay offset jitter

==============================================================================

*abcdefghij .GNSS. 1 u 429 1024 377 225.813 -1.436 0.176

2. Se o APD ocorreu durante uma atualização, você pode considerar verificar quais VMs de StCtl não foram completamente atualizadas e, particularmente, identificar a que falhou pela última vez. É possível que tenha sido o que segurava os dentes1:0 anteriormente

- Usar dpkg -l | grep -i springpath para identificar as StCtlVMs que não foram completamente atualizadas, pois elas terão pacotes de springpath de versão mista.
root@SpringpathControllerPZTMTRSH7K:~# dpkg -l | grep -i springpath

ii storfs-appliance 4.0.1a-33028            amd64 Springpath Appliance

ii storfs-asup 4.0.1a-33028                 amd64 Springpath ASUP and SCH

ii storfs-core 4.0.1a-33028                 amd64 Springpath Distributed Filesystem

ii storfs-fw 4.0.1a-33028                   amd64 Springpath Appliance

ii storfs-mgmt 4.0.1a-33028                 amd64 Springpath Management Software

ii storfs-mgmt-cli 4.0.1a-33028             amd64 Springpath Management Software

ii storfs-mgmt-hypervcli 4.0.1a-33028       amd64 Springpath Management Software

ii storfs-mgmt-ui 4.0.1a-33028              amd64 Springpath Management UI Module

ii storfs-mgmt-vcplugin 4.0.1a-33028        amd64 Springpath Management UI and vCenter Plugin

ii storfs-misc 4.0.1a-33028                 amd64 Springpath Configuration

ii storfs-pam 4.0.1a-33028                  amd64 Springpath PAM related modules

ii storfs-replication-services 4.0.1a-33028 amd64 Springpath Replication Services

ii storfs-restapi 4.0.1a-33028              amd64 Springpath REST Api's

ii storfs-robo 4.0.1a-33028                 amd64 Springpath Appliance

ii storfs-support 4.0.1a-33028              amd64 Springpath Support

ii storfs-translations 4.0.1a-33028         amd64 Springpath Translations

3. Verifique se todos os serviços relevantes estão executando service_status.sh:

- Alguns dos principais serviços são Springpath File System (storfs), SCVM Client (scvmclient), System Management Service (stMgr) ou Cluster IP Monitor (cip-monitor).
root@SpringpathController5L0GTCR8SA:~# service_status.sh

Springpath File System                 ... Running

SCVM Client                            ... Running

System Management Service              ... Running

HyperFlex Connect Server               ... Running

HyperFlex Platform Agnostic Service    ... Running

HyperFlex HyperV Service               ... Not Running

HyperFlex Connect WebSocket Server     ... Running

Platform Service                       ... Running

Replication Services                   ... Running

Data Service                           ... Running

Cluster IP Monitor                     ... Running

Replication Cluster IP Monitor         ... Running

Single Sign On Manager                 ... Running

Stats Cache Service                    ... Running

Stats Aggregator Service               ... Running

Stats Listener Service                 ... Running

Cluster Manager Service                ... Running

Self Encrypting Drives Service         ... Not Running

Event Listener Service                 ... Running

HX Device Connector                    ... Running

Web Server                             ... Running

Reverse Proxy Server                   ... Running

Job Scheduler                          ... Running

DNS and Name Server Service            ... Running

Stats Web Server                       ... Running

4. Se algum desses ou de outros serviços relevantes não estiver ativo, inicie-o usando start <serviceName>eg:start storfs

- Você pode consultar o script service_status.sh para obter os nomes dos serviços . Faça um head -n25 /bin/service_status.sh e identifique o nome real do serviço.
root@SpringpathController5L0GTCR8SA:~# head -n25 /bin/service_status.sh

#!/bin/bash

declare -a upstart_services=("Springpath File System:storfs"\

"SCVM Client:scvmclient"\

"System Management Service:stMgr"\

"HyperFlex Connect Server:hxmanager"\

"HyperFlex Platform Agnostic Service:hxSvcMgr"\

"HyperFlex HyperV Service:hxHyperVSvcMgr"\

"HyperFlex Connect WebSocket Server:zkupdates"\

"Platform Service:stNodeMgr"\

"Replication Services:replsvc"\

"Data Service:stDataSvcMgr"\

"Cluster IP Monitor:cip-monitor"\

"Replication Cluster IP Monitor:repl-cip-monitor"\

"Single Sign On Manager:stSSOMgr"\

"Stats Cache Service:carbon-cache"\

"Stats Aggregator Service:carbon-aggregator"\

"Stats Listener Service:statsd"\

"Cluster Manager Service:exhibitor"\

"Self Encrypting Drives Service:sedsvc"\

"Event Listener Service:storfsevents"\

"HX Device Connector:hx_device_connector");

declare -a other_services=("Web Server:tomcat8"\

"Reverse Proxy Server:nginx"\

"Job Scheduler:cron"\

"DNS and Name Server Service:resolvconf");

5. Identifique qual StCtlVM contém o cluster de armazenamento IP (eth1:0) usando ifconfig -a

- Se nenhuma StCtlVM contiver esse IP, possivelmente os storfs não estarão em execução em um ou mais nós.
root@help:~# ifconfig

eth0:mgmtip Link encap:Ethernet HWaddr 00:50:56:8b:4c:90

inet addr:10.197.252.83 Bcast:10.197.252.95 Mask:255.255.255.224

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

6. Verifique se StCtlVM está em contato com o CRMMaster e se o serviço zookeeper está ativo e em execução

- echo srvr | nc localhost 2181 e verifique se mode é Leader, Follower ou Standalone e if connections > 0
root@help:~# echo srvr | nc localhost 2181

Zookeeper version: 3.4.12-d708c3f034468a4da767791110332281e04cf6af, built on 11/19/2018 21:16 GMT

Latency min/avg/max: 0/0/137

Received: 229740587

Sent: 229758548

Connections: 13

Outstanding: 0

Zxid: 0x140000526c

Mode: leader

Node count: 3577

- status do exibidor de serviço ou ps -ef | expositor grep-i
root@help:~# service exhibitor status

exhibitor start/running, process 12519

root@help:~# ps -ef | grep -i exhibitor

root 9765 9458 0 13:19 pts/14 00:00:00 grep --color=auto -i exhibitor

root 12519 1 0 May19 ? 00:05:49 exhibitor

- Em caso de erro ou serviço que não esteja em execução, você pode verificar os registros abaixo e tentar iniciar o serviço de manutenção

- /var/log/springpath/exhibitor.log e /var/log/springpath/stMgr.log

- Expositor de serviço começa a iniciar o serviço de zootecnista

7. Verifique se o VC pode ser acessado de todas as VMs StCtl

- informação de cluster stcli | grep -i "url" para mostrar a URL usada contendo FQDN ou IP do VC. Verifique a conectividade com o VC usando o ping <VC>
root@help:~# stcli cluster info | grep -i "url"

vCenterUrl: https://10.197.252.101

vCenterURL: 10.197.252.101

root@help:~# ping 10.197.252.101

PING 10.197.252.101 (10.197.252.101) 56(84) bytes of data.

64 bytes from 10.197.252.101: icmp_seq=1 ttl=64 time=0.435 ms

8. Confirme se DNS está acessível no caso do cluster que usa FQDN

- stcli services dns mostram para listar os servidores DNS configurados em StCtlVM. Teste a conectividade e resolução para servidores DNS usando ping <DNS_IP> e host <FQDN> <DNS_IP>
root@help:~# stcli services dns show

1.1.128.140

root@help:~# ping 1.1.128.140

PING 1.1.128.140 (1.1.128.140) 56(84) bytes of data.

64 bytes from 1.1.128.140: icmp_seq=1 ttl=244 time=1.82 ms

9. Confirme se todas as VMs StCtl têm a mesma quantidade de entradas iptables: iptables -L | wc -l. Em caso de incompatibilidade, abra um caso no TAC.

- root@SpringpathControllerI51U7U6QZX:~# iptables -L | wc -l

48

10. Qual é o status e a integridade do cluster atual?

- informação de cluster stcli | menos ou informações do cluster stcli | grep -i "ative\|state\|unavailable" se tentar encontrar os nós específicos que aparecem com armazenamento indisponível.
root@SpringpathControllerI51U7U6QZX:~# stcli cluster info | grep -i "active\|state\|unavailable"

locale: English (United States)

state: online

upgradeState: ok

healthState: healthy

state: online

state: 1

activeNodes: 3

state: online

- stcli cluster storage-summary —detalhe obter os detalhes do cluster de armazenamento
root@SpringpathControllerI51U7U6QZX:~# stcli cluster storage-summary --detail

address: 10.197.252.106

name: HX-Demo

state: online

uptime: 185 days 12 hours 48 minutes 42 seconds

activeNodes: 3 of 3

compressionSavings: 85.45%

deduplicationSavings: 0.0%

freeCapacity: 4.9T

healingInfo:

inProgress: False

resiliencyDetails:

current ensemble size:3

# of caching failures before cluster shuts down:3

minimum cache copies remaining:3

minimum data copies available for some user data:3

minimum metadata copies available for cluster metadata:3

# of unavailable nodes:0

# of nodes failure tolerable for cluster to be available:1

health state reason:storage cluster is healthy.

# of node failures before cluster shuts down:3

# of node failures before cluster goes into readonly:3

# of persistent devices failures tolerable for cluster to be available:2

# of node failures before cluster goes to enospace warn trying to move the existing data:na

# of persistent devices failures before cluster shuts down:3

# of persistent devices failures before cluster goes into readonly:3

# of caching failures before cluster goes into readonly:na

# of caching devices failures tolerable for cluster to be available:2

resiliencyInfo:

messages:

Storage cluster is healthy.

state: 1

nodeFailuresTolerable: 1

cachingDeviceFailuresTolerable: 2

persistentDeviceFailuresTolerable: 2

zoneResInfoList: None

spaceStatus: normal

totalCapacity: 5.0T

totalSavings: 85.45%

usedCapacity: 85.3G

zkHealth: online

clusterAccessPolicy: lenient

dataReplicationCompliance: compliant

dataReplicationFactor: 3

11. Quais datastores estão montados e disponíveis

- root@bsv-hxaf220m5-sc-4-3:~# stcli datastore list

----------------------------------------

virtDatastore:

status:

EntityRef(idtype=None, confignum=None, type=6, id='235ea35f-6c85-9448-bec7-06f03b5adf16', name='bsv-hxaf220m5-hv-4-3.cisco.com'):

accessible: True

mounted: True

EntityRef(idtype=None, confignum=None, type=6, id='d124203c-3d9a-ba40-a229-4dffbe96ae13', name='bsv-hxaf220m5-hv-4-2.cisco.com'):

accessible: True

mounted: True

EntityRef(idtype=None, confignum=None, type=6, id='e85f1980-b3c7-a440-9f1e-20d7a1110ae6', name='bsv-hxaf220m5-hv-4-1.cisco.com'):

accessible: True

mounted: True

12. Caso os comandos stcli demorem muito ou falhem, você pode tentar os seguintes comandos sysmtool(Não usar se o stcli funcionar)

1. sysmtool —ns cluster —cmd info

2. sysmtool —ns cluster —cmd health detail

3. sysmtool —ns datastore —cmd list

StCtlVM: StCtlVM de um host ESXi afetado

Ligar à StCtlVM do anfitrião ESXi afetado

1. Verifique a conectividade com o IP do cluster de armazenamento (eth1:0) e com outros servidores na rede de armazenamento (eth1 em VMsCtl)

- Executar informações do cluster stcli | grep -i -B 1 "stctl\|hypervisor" para identificar todos os IP de gerenciamento ESXi, StCtlVM eth0 (Mgmt) e StCtlVM eth1 (dados de armazenamento) que participam respectivamente do cluster

- Teste a conectividade ping -I eth1 [-M do -s 8972] <target IP address>, Jumbo frames test entre ESXI VMK1 e SCVM eth1.

2. Se o problema ainda não tiver sido identificado, você pode consultar os seguintes registros

- /var/log/springpath/debug-storfs.log

- Verifique se há pânico, falha de seg ou eventos críticos grep -ai "segmentation\|Critical\|Pânico" debug-storfs.log

- /var/log/springpath/stmgr.log

- Verifique se o problema de memória não está presente grep -i "oom\|out of mem" /var/log/kern.log

3. Em última análise, você pode tentar reinicializar a StCtlVM do nó ainda com o problema e verificar se o problema persiste.

Verifica no host ESXi:

Conecte-se a um host ESXi afetado via SSH e execute as seguintes ações:

1. lista nfs de armazenamento esxcli ouEsxcfg-nas -l para listar os datastores NFS atualmente montados e se eles estão acessíveis

- [root@bsv-hx220m5-hv-4-3:~] esxcli storage nfs list

Volume Name  Host                                     Share                 Accessible  Mounted  Read-Only   isPE  Hardware Acceleration

-----------  ---------------------------------------  --------------------  ----------  -------  ---------  -----  ---------------------

test         8352040391320713352-8294044827248719091  192.168.4.1:test            true     true      false  false  Supported

sradzevi     8352040391320713352-8294044827248719091  192.168.4.1:sradzevi        true     true      false  false  Supported

[root@bsv-hx220m5-hv-4-3:~] esxcfg-nas -l

test is 192.168.4.1:test from 8352040391320713352-8294044827248719091 mounted available

sradzevi is 192.168.4.1:sradzevi from 8352040391320713352-8294044827248719091 mounted available

- Você também pode confirmar em /etc/vmware/esx.conf para verificar a consistência na configuração do ESXi nos datastores montados em NFS, usando o comando cat /etc/vmware/esx.conf | grep -I nas

2. Verifique /var/log/vmkernel.log e procure por exemplo o estado de falha, problemas de montagem ou erro em torno do timestamp identificado nas etapas anteriores

3. Verifique o status de IOVisor/NFS Proxy/SCVMClient

- Verifique se o serviço está em execução no ESXi usando o comando /etc/init.d/scvmclient status

- [Opcional] Você pode verificar se há conexões abertas usando a lista de conexões ip de rede esxcli | grep -i "proto\|scvmclient"

- Confirme se o SCVMClient VIB é da mesma versão do cluster HX, lista de vib do software Esxcli | grep -i primavera

- [root@bsv-hx220m5-hv-4-3:~] esxcli software vib list | grep -i spring

scvmclient                     3.5.1a-31118                         Springpath          VMwareAccepted    2018-12-13

stHypervisorSvc                3.5.1a-31118                         Springpath          VMwareAccepted    2018-12-06

vmware-esx-STFSNasPlugin       1.0.1-21                             Springpath          VMwareAccepted    2018-11-16

- Verifique /var/log/scvmclient.log para ver se existem erros, nomeadamente "impossível obter o mapa de clusters"

- Você pode reiniciar o serviço SCVMClient, se necessário, por meio de etc/init.d/scvmclientrestart

4. Verificar a conectividade de rede com outros hosts ESXi na rede vmk1, particularmente com o cluster de armazenamento IP eth1:0

- esxcfg-vmknic -l para obter informações sobre os detalhes da placa de rede vmk, como IP, máscara e MTU

- vmkping -I vmk1 [-v -s 8972] -d <endereço IP de destino> paraTestar a conectividade [opcionalmente com quadros jumbo] entre hosts ESXi na rede de dados do controlador

5. a plataforma de hardware esxcli obtém a SN do servidor usada no nome do StCtlVm e pode ajudá-lo a identificar rapidamente em que host um StCtlVM específico está em execução.