Lenovo DE Series com VMware ESXi por SAS: corrigir um único caminho por LUN, associação ALUA/NMP e gestão das controladoras

Problema

Um array Lenovo ThinkSystem DE Series está ligado diretamente a hosts VMware ESXi por SAS, mas a configuração não oferece a redundância esperada para a cablagem instalada.

Os sintomas habituais incluem:

• As ligações SAS apresentam Up, mas o ESXi identifica apenas um caminho por LUN;
• Os dispositivos podem surgir como degraded;
• Um initiator SAS está associado ao host ESXi, enquanto outro foi detetado mas não está atribuído;
• O array apresenta Volume Not On Preferred Path;
• Os logs do ESXi indicam repetidamente que um caminho já é gerido pelo NMP, mas uma regra SAS genérica aponta para HPP;
• Uma controladora de storage está acessível pelos caminhos de dados SAS, mas a sua interface Ethernet de gestão está inacessível;
• Surgem alertas de NTP ou de gestão, embora as operações de I/O continuem a funcionar.

É essencial distinguir o estado físico da ligação, a configuração de multipathing e a gestão das controladoras: são três camadas independentes.

Arquitetura

Analisa o ambiente em três planos independentes:

1. DATA PATH

ESXi HBA
   ↓
SAS cabling
   ↓
Controller A / Controller B
   ↓
LUNs

2. MULTIPATHING

ESXi
   ↓
NMP
   ↓
SATP / ALUA
   ↓
PSP Round Robin
   ↓
AO / ANO paths

3. MANAGEMENT

Storage controller Ethernet port
   ↓
Switch
   ↓
Management VLAN
   ↓
Gateway / DNS / NTP / management station

Uma controladora pode ter os caminhos de dados SAS operacionais e, simultaneamente, a interface Ethernet de gestão mal configurada.

Estado esperado

Num desenho com dois caminhos validado para o ambiente, o estado pretendido é semelhante ao seguinte:

2 SAS initiators associated with each ESXi host
2 runtime paths per LUN
Device Status: on
Multipath Plugin: NMP
Storage Array Type: VMW_SATP_ALUA
Path Selection Policy: VMW_PSP_RR
1 path Active Optimized
1 path Active Non-Optimized
RTP_health=UP
Preferred controller ownership correct
No recurring HPP/NMP claiming warnings
Controller management reachable
Recovery Guru reports Optimal

Percurso de diagnóstico

1. Inventariar adaptadores, dispositivos e caminhos

Em cada host ESXi, executa:

esxcli storage core adapter list
esxcli storage core device list
esxcli storage core path list
esxcli storage nmp device list

Inspeciona também a HBA SAS:

esxcli storage san sas list

Confirma que a HBA, o driver e os dispositivos de storage esperados estão presentes.

2. Contar os caminhos por LUN

Uma forma rápida de o fazer é:

esxcli storage core path list |
grep "Device: naa." |
awk '{print $2}' |
sort |
uniq -c

Adapta o filtro aos identificadores dos dispositivos relevantes.

Num desenho com dois caminhos, deverão normalmente existir dois caminhos para cada LUN apresentada.

Se o ESXi identificar apenas um, verifica primeiro o mapeamento das portas do host antes de alterar a política de multipathing.

3. Validar os initiators SAS no Lenovo System Manager

Abre o objeto correspondente ao host no Lenovo System Manager e inspeciona as suas portas e os initiators SAS.

Um padrão de falha frequente é:

SAS link: Up
Initiator: discovered
Host mapping: not assigned

Isto significa que a ligação física existe, mas a LUN não é apresentada ao host através desse initiator.

Associa o initiator detetado ao host ESXi correto apenas depois de confirmares que o endereço SAS pertence a esse host.

Não alteres a associação de um initiator já atribuído por tentativa e erro.

4. Voltar a detetar o storage no ESXi

Depois de corrigires o mapeamento das portas do host:

esxcli storage core adapter rescan --all

Repete as verificações:

esxcli storage core path list
esxcli storage core device list

Resultado esperado:

2 paths per LUN
Status: on

Se o host continuar a identificar apenas um caminho, investiga a cablagem, as portas das controladoras, a apresentação dos targets e a visibilidade da HBA antes de alterares as claim rules.

5. Validar NMP, ALUA e Round Robin

Para uma LUN representativa:

esxcli storage core device list -d <naa.ID>
esxcli storage nmp device list -d <naa.ID>
esxcli storage nmp path list -d <naa.ID>

Um dispositivo Lenovo DE Series em bom estado pode apresentar:

Multipath Plugin: NMP
Vendor: LENOVO
Model: DE_Series
Status: on
Is Local: false

Storage Array Type: VMW_SATP_ALUA
Path Selection Policy: VMW_PSP_RR

Com ALUA, um caminho pode estar Active Optimized (AO) e outro Active Non-Optimized (ANO).

Um exemplo típico do estado dos caminhos é:

Path A
Group State: active
TPG_state=AO
RTP_health=UP

Path B
Group State: active unoptimized
TPG_state=ANO
RTP_health=UP

Se useANO=0, a PSP pode apresentar apenas o caminho AO em Working Paths. Isto não significa necessariamente que só exista um caminho físico ou de runtime.

6. Verificar a controladora preferida dos volumes

No Lenovo System Manager, inspeciona:

Recovery Guru
Volumes
Preferred Owner
Current Owner

Se surgir Volume Not On Preferred Path, não executes imediatamente uma redistribuição manual.

Primeiro, restabelece o caminho em falta ou corrige o mapeamento das portas do host e volta a avaliar a atribuição dos volumes.

O array pode devolver automaticamente os volumes à controladora preferida quando a topologia dos caminhos estiver operacional.

7. Verificar a associação a HPP ou NMP

O ESXi 7.0 U2 e versões posteriores alteraram o comportamento de associação predefinido para dispositivos SAS, podendo envolver HPP. A Broadcom documenta casos SAS em que arrays remotos podem precisar de uma claim rule explícita para NMP.

Inspeciona as regras atuais:

esxcli storage core claimrule list
esxcli storage nmp satp rule list | grep -i -B 2 -A 2 LENOVO

Inspeciona os logs recentes:

grep -Ei "HPP|NMP|claim|claimrule" /var/log/vmkernel.log | tail -100

Um padrão recorrente pode ser semelhante a:

Path ... is claimed by plugin NMP,
but current claimrule indicates that it should be claimed by plugin HPP.

Antes de adicionares uma regra do fabricante, confirma a identidade do dispositivo:

esxcli storage core device list -d <naa.ID> |
grep -E "Multipath Plugin:|Vendor:|Model:|Status:|Is Local:"

8. Adicionar uma claim rule NMP específica quando necessário

A Broadcom documenta a utilização de uma regra por fabricante/modelo com número inferior a 50 para os arrays SAS remotos afetados.

Exemplo para Lenovo DE Series:

esxcli storage core claimrule add \
-r 49 \
-t vendor \
-V LENOVO \
-M DE_Series \
-P NMP \
--force-reserved

esxcli storage core claimrule load

Valida:

esxcli storage core claimrule list

Padrão esperado:

49 runtime vendor NMP vendor=LENOVO model=DE_Series
49 file    vendor NMP vendor=LENOVO model=DE_Series

Nota de segurança importante

Adicionar e carregar uma regra não é o mesmo que forçar um dispositivo ativo a passar por um ciclo de unclaim/reclaim.

Não executes storage core claiming unclaim, claimrule run nem reinicies um host com datastores de produção sem um plano de manutenção.

A documentação da Broadcom refere explicitamente que, em alguns casos, pode ser necessário um reclaim ou reinício para a nova claim rule produzir efeito. Trata estas operações como potencialmente disruptivas.

9. Confirmar que os avisos de associação deixam de se repetir

Regista a hora:

date -u

Volta a verificar:

grep -Ei "claimed by plugin NMP|claimrule" /var/log/vmkernel.log | tail -20

Se os avisos surgiam a intervalos regulares, espera mais do que esse intervalo e confirma que não existem novos eventos.

10. Validar separadamente a gestão das controladoras

Se uma controladora estiver inacessível por Ethernet, não assumas que existe um problema SAS.

Verifica:

• A tabela MAC do switch;
• O estado da ligação da porta;
• A velocidade e o duplex;
• A VLAN de acesso / PVID;
• A tabela ARP do gateway;
• Os pedidos e as respostas NTP.

Uma falha frequente é:

Controller IP belongs to Management VLAN A
Switch access port is untagged in VLAN B
→ ARP fails
→ management ping fails
→ NTP fails

Corrige a VLAN de acesso / PVID apenas depois de confirmares a sub-rede de gestão esperada.

11. Validação final

Em cada host ESXi, confirma:

esxcli storage core path list
esxcli storage core device list
esxcli storage nmp device list -d <naa.ID>
esxcli storage nmp path list -d <naa.ID>
esxcli storage core claimrule list

Estado pretendido:

[ ] expected paths per LUN
[ ] devices Status: on
[ ] NMP
[ ] VMW_SATP_ALUA
[ ] VMW_PSP_RR
[ ] AO + ANO healthy
[ ] RTP_health=UP
[ ] preferred ownership healthy
[ ] no new HPP/NMP warnings
[ ] controller management reachable
[ ] Recovery Guru reports Optimal

Desempenho e resiliência

Esta distinção é essencial.

Uma configuração de storage pode estar incorreta do ponto de vista da resiliência sem ser a causa de um incidente de desempenho de uma aplicação.

Exemplos:

single-path            ≠ proof of storage bottleneck
device degraded flag   ≠ proof of high latency
NTP failure            ≠ proof of I/O latency
claim-rule warning     ≠ proof of application slowness

Se os valores DAVG/GAVG do ESXi, a latência dos discos no Windows e a latência medida no array permanecerem baixos durante o incidente, não atribuas retroativamente a causa à configuração de storage.

Corrige o problema de resiliência, repete a mesma carga de trabalho e compara as medições antes e depois.

Nota sobre Round Robin

A Lenovo documenta que os arrays DE Series utilizam habitualmente VMware NMP com Round Robin e que reduzir o contador de I/O do Round Robin face ao valor predefinido pode melhorar a latência do lado do host em determinadas cargas de trabalho. É uma opção de ajuste, não uma configuração obrigatória: só deve ser alterada depois de medir o desempenho e validar a recomendação do fabricante.

Rollback e controlo de alterações

As ações potencialmente disruptivas incluem:

• Executar unclaim em dispositivos ativos;
• Forçar reclaim;
• Alterar SATP/PSP em LUNs ativas;
• Reiniciar hosts ESXi;
• Alterar a atribuição dos volumes às controladoras por tentativa e erro;
• Modificar ligações SAS durante operações de I/O.

Executa estas ações apenas com:

• Backups atuais;
• Janela de manutenção;
• Plano de rollback;
• Correspondência entre fabricante/modelo confirmada;
• Validação em todos os hosts.

Fontes

Consulta as referências da Broadcom e da Lenovo nos metadados do artigo.