Pesquisando defeitos down(APD) dos trajetos do armazenamento NFS de Hyperflex todo o emita

Introdução

Este original dá-lhe a compreensão e os passos de Troubleshooting rápidos que podem ser executados a fim avaliar a fonte do problema se você vê “NFS Mensagem de Erro de todos os trajetos para baixo” no vCenter a que o conjunto de Hyperflex está integrado com.

Como HX Datastores são montados em ESXI?

• Hyperflex Datastores é montado nos anfitriões ESXI como o NFS monta, a fim montar um datastore que NFS nós precisamos o IP do servidor de NFS que em nosso caso é a relação eth1:0 de flutuação virtual.
• O conjunto de Hyperflex leverages o uso do IP de flutuação virtual para o Gerenciamento (eth0:mgmtip) e os dados do armazenamento (eth1:0) em que cada IP será atribuído a um controlador particular VM do armazenamento (StCtlVM). Note-os por favor pode terminar acima em StCtlVMs diferente.
• A importância desta é que o IP dos dados do armazenamento do conjunto (eth1:0) é esse usado para montar Assim é essencial tê-la atribuída e alcançável de todos os Nós do conjunto.
• Note por favor que em caso da falha do StCtlVM que possui atualmente o IP virtual eth1:0, ele deve “migrar” a um outro StCtlVM disponível que trabalha em uma maneira similar como um FHRP (primeiro protocolo da redundância de salto).

Todos os trajetos para baixo

• APD significa que o host não pode alcançar o armazenamento e não há nenhum dispositivo permanente (PDL) código perdido SCSI retornado do arranjo de armazenamento.
• Porque não sabe se a perda é provisória ou não, manter-se-á tentar estabelecer à revelia uma comunicação para mais 140s (intervalo) + 3min (atraso para o Failover) o ESXi que o host começa a falhar todo o tráfego I/O da máquina NON-virtual que for enviado ao dispositivo de armazenamento.
• Para mais detalhes a propósito de APD no ambiente do vSphere 6.x, refira a perda permanente do dispositivo do artigo de Vmware KB (PDL) e os Todo-PATH-Para baixo (APD) no vSphere 5.x e 6.x
• Abaixo da imagem explica cada fase intermitente:

Uma mensagem de erro típico no vCenter será como segue.

Descrição do problema

Uma vez que você vê alertas APD em seus anfitriões, obtenha a informação abaixo para compreender melhor a descrição do problema:

• Se uns/diversos/todos os anfitriões impactou, e se alguns que os host particulares impactaram
• Se alguma mudança foi executada previamente (configuração/elevação/etc.)
• O timestamp em quando o problema observado primeiramente e se a edição é periódica

Pesquisando defeitos trabalhos

A fim pesquisar defeitos APD que nós precisamos de olhar em 3 componentes - vCenter, SCVM, e host de ESXi.

Estas etapas são uns trabalhos sugeridos a fim localizar para baixo ou reduzir para baixo a fonte de todo o sintoma dos trajetos observado. Note por favor esta ordem não tem que meticulosamente ser seguido e você pode adequado ele conforme os sintomas particulares observados no ambiente de cliente.

Verifica dentro o server do vCenter:

Conecte ao server do vCenter (VCS) e navegue a um host afetado

1. Os objetos relacionados - > máquinas virtuais e confirmam o StCtlVM são em serviço
2. Os objetos relacionados - > Datastores e confirmam se os datastores NFS mostram “inacessível”. Se os datastores parecem ser acessíveis e estado você pode tentar sobre a aba sumária “restaurar para esverdear” o evento APD e para verificar mais tarde se o alerta estala para trás mais tarde
3. O monitor - > edições e monitor - > eventos deve fornecer a informação em quando o APD foi manchado primeiramente.

Verifica dentro todo o StCtlVMs:

Conecte a todo o StCtlVMs e verifique os ponteiros abaixo, você pode usar o software de MobaXterm.

1. Verifique se todo o StCtlVMs tem o mesmo tempo usando a data ou o ntpq – o enviesamento do tempo P. em StCtlVM pode conduzir às edições com sincronização de base de dados do zookeeper e assim é primordial tê-la na sincronização entre todo o StCtlVMs.
   • O infort do sinal do astrick do server NTP denota que o NTP de seu SCVM é 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 APD ocorreu durante uma elevação você pôde considerar para verificar que StCtlVMs não foi promovido completamente e para identificar particularmente esse que último falhado. É possível que era esse que guarda o eth1:0 previamente
   • Dpkg do uso - l | grep - springpath i para identificar o StCtlVMs promovido não completamente porque terão misturado pacotes do springpath da versão.

     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 serviços principais são sistema de arquivos de Springpath (storfs), cliente SCVM (scvmclient), monitor IP do orCluster do serviço de gerenciamento de sistema (stMgr) (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 qualquer um ou outro serviço relevante não está acima, comece-o usingstart < serviceName > por exemplo: comece storfs
   • Você pode referir o script de service_status.sh para obter os nomes do serviço. Faça uma cabeça -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 que StCtlVM contém o IP do conjunto do armazenamento (eth1:0) que usa o ifconfig - a
   • Se nenhum StCtlVM contém que IP possivelmente que os storfs não estão executando em uns ou vários 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 é em contato com CRMMaster e se o serviço do zookeeper é em serviço
   • ecoe o srvr | host local 2181 nc e verificação se o modo é líder, seguidor ou autônomo e se conexões > 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

   • preste serviços de manutenção ao estado do expositor ou ao picosegundo - ef | grep - expositor 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 todo o erro ou serviço não o executar pode verificar os logs abaixo e tentá-los começar o serviço do zookeeper

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

     • preste serviços de manutenção ao começo do expositor para começar o serviço do zookeeper
7. Verifique se VC alcançável de todo o StCtlVMs
   • informação de cluster do stcli | grep - i “URL” para mostrar a URL usada contendo o FQDN ou o IP do VC. Verifique a Conectividade ao VC usando o sibilo <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 o DNS é alcançável em caso do conjunto usando o FQDN
   • mostra dns dos serviços do stcli para alistar os servidores configurados DNS em StCtlVM. Teste a Conectividade e a definição aos servidores DNS usando o sibilo <DNS_IP> e hospede <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 todo o StCtlVMs tem o mesmo valor de entradas dos iptables:   iptables - L | wc - l. Caso que combinam mal, satisfaça abrem um caso de TAC.

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

10. O que são o estado e a saúde atuais do conjunto
    • informação de cluster do stcli | informação de cluster menos ou do stcli | grep - active i “\|estado \|não disponível” se tentando encontrar que nós específicos aparecem com o armazenamento não disponí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

    • armazenamento-sumário do conjunto do stcli --detalhe para obter os detalhes do conjunto do 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. Que 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 que os comandos do stcli tomam demasiado por muito tempo ou falham você pode tentar o seguinte sysmtool comanda (não use se trabalhos do stcli)
    1. sysmtool --conjunto ns --informação do cmd 
    2. sysmtool --conjunto ns --healthdetail do cmd 
    3. sysmtool --datastore ns --lista do cmd 

StCtlVM: StCtlVM de um host afetado de ESXi

Conecte ao StCtlVM do host afetado de ESXi 

1. Verifique a Conectividade ao IP do conjunto do armazenamento (eth1:0) e a outros server na rede de armazenamento (eth1 em StCtlVMs)
   
   • Execute a informação de cluster do stcli | grep - i - “stctl B1 \|hypervisor” para identificar todo o eth0 do IP de gerenciamento, do StCtlVM de ESXi (Mgmt) e StCtlVM eth1 (dados do armazenamento) que participa respectivamente no conjunto
   • Teste o sibilo da Conectividade – Mim eth1 [– M faz – o IP address do <target s 8972] >, Jumbo Frames testa entre ESXI VMK1 e SCVM eth1.
2. Se o problema ainda não localizado lhe pode ter um olhar em seguintes logs
   • /var/log/springpath/debug-storfs.log
     • Verifique se alguns se apavorar, falha do seg ou grep dos eventos críticos - segmentação ai a “\|crítico \|pânico” debug-storfs.log
   • /var/log/springpath/stmgr.log

   • Verifique se fora do grep do presente do problema de memória - oom i “\|fora do mem” /var/log/kern.log

3. Finalmente você pode tentar recarregar o StCtlVM do nó ainda que experimenta a edição e verificar se o problema persiste.

Verifica dentro o host de ESXi:

Conecte a um host afetado de ESXi através do SSH e execute as seguintes ações:

1. orEsxcfg-nas da lista NFS do armazenamento do esxcli - l para alistar os datastores atualmente montados NFS e se sã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ê pode igualmente confirmar de /etc/vmware/esx.conf para verificar a consistência na configuração de ESXi nos datastores montados NFS, usando o comando cat /etc/vmware/esx.conf | grep - Mim nas
2. Verifique /var/log/vmkernel.log e procure o estado falho do exemplo, os problemas de montagem ou o erro em torno do timestamp identificado em etapas precedentes
3. Verifique o estado do proxy IOVisor/NFS/SCVMClient
   • Verifique se o serviço está sendo executado em ESXi usando o estado do comando /etc/init.d/scvmclient
     • [Optional] você pode verificar se alguma conexão aberta que usa a conexão IP da rede do esxcli alista | grep - i “proto \|scvmclient”
   • Confirme se SCVMClient VIB é a mesma versão que seu conjunto HX, lista do vib do software de Esxcli | grep - mola i

     • [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 alguns incapazes atuais dos erros a saber “de obter o clustermap”
   • Você pode reiniciar o serviço de SCVMClient caso necessário com etc./init.d/scvmclientrestart
     

4. Verifique a conectividade de rede com outros anfitriões de ESXi na rede vmk1, particularmente a IP eth1:0 do conjunto do armazenamento

   • esxcfg-vmknic - l para obter a informação nos detalhes NIC do vmk, por exemplo IP, máscara e MTU

   • vmkping - Mim [-v -s 8972] -d <target IP address> to test connectivity [optionally with jumbo frames] vmk1 entre anfitriões de ESXi na rede de dados do controlador
5. a plataforma de hardware do esxcli consegue obter o server SN que é usado no nome do StCtlVm e pode ajudá-lo a identificar rapidamente em que host um StCtlVM específico está executando.