ONTAP Health Check Cookbook

A maioria dos incidentes de storage deixa sinais antes que os usuários percebam uma indisponibilidade. Pressão de capacidade, RAID degradado, replicação atrasada, LIFs fora de origem e certificados próximos do vencimento podem ser detectados com uma rotina consistente de health check.

Este tutorial transforma essa rotina em um runbook guiado. Siga as etapas na ordem, use o botão Copiar em cada bloco de comandos, compare a saída com o estado esperado e registre todas as exceções no log operacional. Os comandos abaixo são somente leitura.

Formate e salve a saída

Antes de executar o health check, aumente o limite de linhas ou o buffer de rolagem do cliente SSH e habilite o registro da sessão. Salve o log com o nome do cluster e a data da coleta para manter a saída completa disponível para comparação, escalação e auditoria.

Antes de começar

Conecte-se à LIF de gerenciamento do cluster e registre o cluster, a versão do ONTAP, a data e o número do chamado. Confirme se há manutenção, takeover/giveback, atualização ou teste de replicação em andamento. Mantenha o relatório anterior aberto para identificar mudanças, em vez de analisar valores isolados.

rows 0
set -showseparator ","
cluster identity show
version
system node show -fields health,uptime,model

• rows 0 desativa a paginação para que toda a saída seja registrada sem prompts ou páginas interrompidas.
• set -showseparator "," separa os campos exibidos por vírgulas. Isso facilita salvar a saída tabular como CSV e importá-la no Excel após remover os prompts da CLI e as linhas não relacionadas.
• cluster identity show registra o nome e o UUID do cluster, evitando que o relatório seja associado ao ambiente errado.
• version captura a versão do ONTAP em execução para que os campos dos comandos e os achados sejam interpretados na versão correta.
• system node show apresenta a integridade, o uptime e o modelo de cada nó. Um uptime inesperado pode revelar reboot, takeover ou manutenção recente.

Essas preferências de exibição da CLI valem apenas para a sessão atual. Salve a saída relevante com a extensão .csv quando precisar filtrar, comparar ou criar relatórios no Excel.

Checkpoint: confirme se o cluster, a quantidade de nós, os modelos e o uptime correspondem ao inventário.

1. Integridade do cluster

cluster show
cluster ha show
system health status show
system health subsystem show
system health alert show

Esperado: todos os nós estão íntegros e elegíveis, o HA corresponde ao desenho, o estado geral é OK e não existem alertas sem explicação.

Para qualquer alerta, colete a causa, o impacto e a ação recomendada:

system health alert show -instance

Trate novos alertas críticos ou major como escalações para o mesmo dia. Não suprima ou exclua um alerta apenas para limpar o painel.

2. Capacidade e disponibilidade

storage aggregate show -fields size,usedsize,availsize,percent-used,state,raidstatus
storage aggregate show -state !online
volume show -fields size,available,percent-used,state,percent-snapshot-space
volume show -state !online

Esperado: aggregates e volumes de produção estão online, o RAID apresenta estado normal e o espaço livre cobre o crescimento previsto e o tempo necessário para adicionar ou mover capacidade.

• 70–80%: projete a data de esgotamento e planeje a expansão.
• 85–90%: defina um responsável e uma correção de curto prazo.
• 95% ou mais: trate como incidente.

Sempre combine utilização e taxa de crescimento. Um aggregate com 75% e crescimento de 5% por semana pode ser mais urgente que outro estável em 88%.

3. Discos, RAID e shelves

storage disk show -broken
storage disk error show
storage aggregate show -fields state,raidstatus
storage shelf show -connectivity

Esperado: nenhum disco quebrado ou erro sem explicação, aggregates online com RAID normal e conectividade redundante com as shelves.

Se o RAID estiver degradado, registre o aggregate afetado, o estado da reconstrução, a disponibilidade de spares e a redundância restante. Siga o procedimento aprovado para a plataforma; não falhe nem remova discos a partir deste checklist.

4. Snapshots e replicação

volume snapshot show -fields size,create-time
volume snapshot policy show
volume show -fields percent-used,percent-snapshot-space
volume show -snapshot-policy none
volume snapshot autodelete show -enabled true
snapmirror show -fields source-path,destination-path,state,status,healthy,lag-time,unhealthy-reason
snapmirror show -healthy false

Esperado: os snapshots seguem a política sem consumir espaço inesperado, e todas as relações protegidas estão íntegras e dentro do RPO da aplicação.

Não presuma que healthy=true comprova o RPO. Compare lag-time com o requisito do negócio. Para uma exceção, registre origem, destino, atraso, resultado da última transferência, motivo do estado unhealthy e responsável pela aplicação. Confirme a propriedade e a retenção antes de excluir snapshots. Verifique também se a exclusão automática de snapshots está desativada, pois, durante um ataque de ransomware, os snapshots podem ser excluídos quando o volume atingir o limite configurado para autodelete. Revise se existem volumes sem uma política de snapshots atribuída.

5. Portas e LIFs

network port show -fields link,health-status
network interface show -fields status-admin,status-oper,is-home,home-node,home-port,curr-node,curr-port
network interface show -is-home false
network interface show -failover

Esperado: as portas necessárias estão íntegras, as LIFs de clientes estão operacionais e toda LIF fora de origem é explicada pelo desenho ou por uma manutenção ativa.

Uma LIF fora de origem não é automaticamente uma falha. Valide a porta atual, os destinos de failover, a manutenção e o impacto aos clientes. Não reverta uma LIF a partir de um checklist genérico.

6. Baseline de desempenho

qos statistics workload latency show
statistics show-periodic -object volume -counter total_ops,avg_latency
system node run -node <node> -command "sysstat -c 10 1"

Esperado: latência, operações e CPU permanecem dentro da faixa normal para o mesmo período de carga.

Um valor de latência sem contexto de workload é uma evidência fraca. Compare IOPS, latência e CPU com o baseline estabelecido. Use esta etapa para detectar desvios; faça uma análise dedicada antes de alterar configurações de desempenho.

7. Coleta de versões de firmware

version
system service-processor show -fields type,status,fw-version
storage disk show -fields model,serial-number,firmware-revision
storage shelf show -module
network fcp adapter show -instance

Esperado: os firmwares do ONTAP, SP/BMC, discos, módulos de shelf e adaptadores FC correspondem às versões aprovadas para a plataforma. Registre o modelo (part number), o número de série e a revisão de firmware de cada disco, além das exceções por nó, adaptador, shelf ou modelo de disco; não inicie atualizações de firmware a partir deste health check.

8. Health Check de SAN

network interface show -data-protocol iscsi
iscsi initiator show -fields igroup,initiator-name,tpgroup
vserver iscsi session show
vserver iscsi connection show
network interface show -data-protocol fcp
fcp initiator show -fields igroup,wwpn,lif
lun mapping show -fields node,reporting-nodes,igroup,protocol

Esperado: compare a quantidade de iniciadores iSCSI e FC conectados com o inventário aprovado de hosts. Os iniciadores iSCSI devem usar os target portal groups previstos, os iniciadores FC devem estar conectados pelas LIFs e fabrics esperadas, e os reporting nodes das LUNs devem corresponder ao desenho do nó proprietário e seu parceiro de HA. Confirme em cada host se o MPIO está habilitado, o ALUA é reconhecido, todos os caminhos esperados estão ativos e os caminhos atravessam iniciadores, switches ou VLANs, LIFs de destino e controladoras independentes. O ONTAP mostra a conectividade do lado do destino; somente o host pode confirmar a política de multipath e o estado do caminho ponta a ponta.

9. Suportabilidade

system node autosupport show -node *
system node autosupport check show
system license show
cluster time-service ntp server show
security certificate show -fields expiration -expiration <60d

Esperado: AutoSupport operacional, licenças necessárias válidas, NTP configurado e certificados com tempo suficiente para o processo de renovação.

Registre o certificado com vencimento mais próximo. Ausência de telemetria, desvio de relógio ou certificado próximo do vencimento pode não causar uma falha hoje, mas pode complicar o próximo incidente ou janela de manutenção.

Encerramento do health check

Para cada exceção, registre o objeto afetado, a descoberta, o impacto ao negócio, o responsável, o chamado e a data-alvo. Classifique indisponibilidade ativa, aggregates quase cheios, perda de redundância e proteção fora do RPO contratado como críticos. Acompanhe tendências e riscos de suportabilidade conforme o tempo até o impacto.

Rotina pronta para copiar

Diariamente

system health alert show
storage disk show -broken
storage aggregate show -state !online
volume show -state !online
snapmirror show -healthy false
network interface show -is-home false
volume show -snapshot-policy none
volume snapshot autodelete show -enabled true

Semanalmente

storage aggregate show -fields availsize,percent-used-capacity,state,raidstatus
volume show -fields available,percent-used,state,percent-snapshot-space
storage disk error show
storage shelf show -connectivity
snapmirror show -fields state,status,healthy,lag-time,unhealthy-reason
network port show -fields link,health-status
system node autosupport check show

Mensalmente

system node show -fields health,uptime,model
system service-processor show -fields type,status,fw-version
storage disk show -fields model,serial-number,firmware-revision
storage shelf show -module
network fcp adapter show
fcp initiator show -fields igroup,wwpn,lif
iscsi initiator show -fields igroup,initiator-name,tpgroup
vserver iscsi connection show
lun mapping show -fields node,reporting-nodes,igroup,protocol
system license show
cluster time-service ntp server show
security certificate show -fields expiration -expiration <60d
qos statistics workload latency show

Nota sobre versão e segurança

Campos e privilégios podem variar conforme a versão do ONTAP, a plataforma e o contexto do cluster. Valide esta rotina na referência atual de comandos do ONTAP e nos procedimentos locais. Este tutorial termina na detecção e coleta de evidências; use um runbook aprovado para a correção.

Quais comandos você adicionaria a essa rotina? Compartilhe seus scripts nos comentários abaixo!