PowerFlex: A troca excessiva de funções de dados causa latência de E/S e erros

Em certas transições de estado de cluster, a lógica de balanceamento de funções do MDM pode produzir switches de função primário/secundário rápidos e repetidos em muitos combs (estruturas de dados internas que rastreiam quais nós SDS armazenam cada parte dos dados de volume). Cada switch de função invalida os mapas de pente fino do lado do client (SDC) e força as tentativas de E/S. Quando combs suficientes são afetados simultaneamente, a sobrecarga cumulativa de repetição causa picos de latência de E/S e erros de E/S nos hosts do SDC. Dependendo do ambiente de host, isso pode resultar em tempos de espera excedidos de E/S do aplicativo, VMs entrando no estado somente leitura ou indisponibilidade do file system.

Esse comportamento foi observado em vários cenários de acionamento e não está limitado a um único procedimento operacional.

Indicadores comuns

• MDM_DATA_DEGRADED evento seguido por latência de E/S sustentada com duração de 1 a 15+ minutos
• Os hosts do SDC relatam erros de E/S e/ou tempos de espera excedidos de E/S durante a janela degradada
  • VMware (ESXi): Tempos de espera excedidos de heartbeat VMFS, erros de hardware SCSI (sense data: 0x4 0x0 0x0), VMs entrando em estado somente leitura, possível failover de HA
  • Linux: Erros de E/S nos logs do sistema (/var/log/messages, dmesg), os aplicativos podem enfrentar tempos de espera excedidos de E/S ou remontagem do file system somente leitura
• Os logs de eventos do MDM mostram o sistema em estado DEGRADED por mais tempo do que o esperado para uma única perda de SDS
• Por fim, o sistema se recupera automaticamente para um estado NORMAL sem intervenção manual (geralmente)

Cenário 1: Perda ingraciosa do SDS (sem modo de manutenção)

Quando isso pode acontecer:

• Este é um cenário raro. Para que os eventos rápidos e repetidos de role-switch ocorram durante uma perda ingraciosa de SDS, várias condições específicas devem estar presentes simultaneamente:

• • Ambiente de grande escala — número significativo de nós e volumes de SDS
  • Carga pesada de E/S de produção - Atividade significativa de E/S no momento em que o SDS falha
  • A carga de trabalho de reconstrução excede a capacidade de processamento — o número de linhas de metadados que exigem recriação excede o limite por ciclo do balanceador do MDM de 1.024 linhas

Cada ciclo de rebalanceamento pode processar até 1.024 linhas de metadados. Quando mais linhas precisarem ser recriadas, o balanceador não poderá concluir o plano atual antes de gerar o próximo.

O que acontece:

• O SDS se desacopla abruptamente do MDM (evento SDS_DECOUPLED)
• Todos os SDCs que estavam conectados a esse SDS perdem suas conexões → eventos de desconexão do SDC
• O MDM marca o cluster como DEGRADADO (evento MDM_DATA_DEGRADED)
• Como o número de linhas a serem recriadas é superior a 1.024, o balanceador do MDM não pode concluir o plano de rebalanceamento atual
• O balanceador inicia um novo plano enquanto o plano anterior ainda está em execução, produzindo eventos rápidos e repetidos de troca de função
• Os SDCs do client observam falhas contínuas de E/S (IO_FAULT_NOT_PRI, SCSI sense 0x4). Depois que as repetições são esgotadas, o sistema operacional do host relata erros de E/S, tempos de espera excedidos ou um file system somente leitura
• Evidências de rastreamento de MDM:

Quando a carga de trabalho de rebalanceamento excede o limite de 1.024 linhas, o rastreamento do MDM mostra o limite que está sendo ultrapassado:

2026/03/28 22:43:53.246702 MED:7f1f984aedb0:balanceExec_HandleDegradedRows:00343: BALANCER: Storage Pool: 1193844800000000 - 1024 rows processed out of 1098 degraded rows. 0 allocation failures. 0 cumulative allocation failures.

Isso indica que 1.098 linhas precisaram ser recriadas, mas apenas 1.024 puderam ser processadas no ciclo atual. As linhas restantes acionam um novo plano de rebalanceamento antes que o plano anterior seja concluído, iniciando o ciclo de feedback.

Cadeia de eventos:

Log Source     Event / Pattern
MDM events     SDS_DECOUPLED — SDS formally declared dead
MDM events     MDM_DATA_DEGRADED — Cluster enters DEGRADED state
SDS traces     Flood of IO_FAULT_NOT_PRI — SDS received IO for a comb it is no longer primary for
ESXi vmkernel  SCSI sense data: 0x4 0x0 0x0 — Hardware error
MDM events     MULTIPLE_SDC_CONNECTIVITY_CHANGES — Mass SDC connectivity storm
MDM events     SDC_DISCONNECTED_FROM_SDS_IP — SDCs losing contact with the failed SDS

SDC_DISCONNECTED_FROM_SDS_IP    SDC disconnected from SDS <name>
SDS_DECOUPLED                   SDS <name> decoupled
MDM_DATA_DEGRADED               The system is now in DEGRADED state

Cenário 2: Desligamento do SDS durante a entrada do PMM

Quando isso pode acontecer:
Esse é um cenário raro que requer dois eventos simultâneos:

• Um SDS está entrando no modo de manutenção protegida (PMM)
• O SDS falha ou é desligado antes que a transição do PMM seja concluída

O que acontece: 

• O MDM recebe o comando de entrada do PMM e o registra como bem-sucedido
• O SDS se desacopla inesperadamente enquanto a entrada do PMM ainda está em andamento
• O MDM marca o cluster como DEGRADADO
• O balanceador de função entra em um loop sustentado de role-switch durante toda a fase de entrada do PMM
• As linhas de dados não PMM são repetidamente comutadas por função em todo o pool de armazenamento
• A tempestade persiste até que o SDS reingresse no cluster e conclua a transição do modo de manutenção

Cadeia de eventos:

Log Source  Event / Pattern
MDM events  CLI_COMMAND_SUCCEEDED — enter_protected_maintenance_mode command succeeded
MDM events  SDS_DECOUPLED — SDS decoupled before maintenance mode started
MDM events  MDM_DATA_DEGRADED — Cluster enters DEGRADED state
SDS traces  Repeated role-switch operations across non-PMM rows

Exemplo de sequência de eventos do MDM:

CLI_COMMAND_SUCCEEDED            Command enter_protected_maintenance_mode succeeded
SDS_DECOUPLED                    SDS <name> decoupled
MDM_DATA_DEGRADED               The system is now in DEGRADED state

Quando o SDS for reingressado e o PMM for concluído:

SDS_MAINTENANCE_MODE_STARTED     SDS maintenance mode started
MDM_DATA_NORMAL                 The system is now in NORMAL state

Cenário 3: SDS no modo de manutenção instantânea (IMM)

Quando isso pode acontecer:
Um SDS entra ou sai do modo de manutenção instantânea (IMM). Esse cenário ocorre quando um único SDS está no modo de manutenção e o sistema não pode decidir qual SDS deve lidar com E/S para dados específicos.

O que acontece:

• O sistema altera repetidamente qual SDS é responsável por servir os mesmos dados
• Essas alterações constantes fazem com que os aplicativos não saibam para onde enviar suas solicitações de E/S
• A E/S é enviada para o SDS errado, causando repetições e atrasos
• Os aplicativos enfrentam latência ou tempos de espera excedidos ao tentar acessar os dados afetados

Impacto:

• Impacto sobre o cliente: Os aplicativos relatam latência e tempos de espera excedidos enquanto o SDS está no IMM
• Duração: Continua enquanto o SDS está no estado IMM
• Recuperação: Automática - resolve quando o SDS sai do IMM

Cadeia de eventos:

Log Source  Event / Pattern
SDS traces  Repeated role-switch operations on the same data
SDS traces  Primary and secondary role switches on identical data

Cenário 4: Saída do SDS do modo de manutenção protegida (PMM)

Quando isso pode acontecer:
Um SDS sai do modo de manutenção protegida (PMM). Esse cenário ocorre durante cada saída do PMM - não é um evento raro, mas a severidade depende de quanto tempo durou a operação do modo de manutenção.

O que acontece:

• Quando o SDS sai do PMM, o balanceador de função deve reatribuir segmentos de dados para incluir o SDS que retorna
• O processo de rebalanceamento afeta todo o pool de armazenamento, não apenas os dados no SDS que retorna
• As trocas de função ocorrem em muitos segmentos de dados durante a reintegração
• Os aplicativos podem apresentar erros breves de E/S ou latência à medida que as atribuições de função se estabilizam

Impacto:

• Impacto sobre o cliente: Para janelas de manutenção curtas (menos de 5 segundos), o impacto é quase imperceptível. Para manutenção prolongada com E/S ativa, milhares de trocas de função podem ocorrer, causando paralisações contínuas de E/S
• Duração: Continua durante a fase de reintegração até que o rebalanceamento seja concluído
• Recuperação: Automático

Cadeia de eventos:

Log Source  Event / Pattern
MDM events  Role-switch operations across the storage pool during exit
SDS traces  Repeated role-switch operations during reintegration

Exemplo de sequência de eventos do MDM:

SDS_MAINTENANCE_MODE_EXIT_STARTED    SDS maintenance mode exit started
SDS_MAINTENANCE_MODE_EXIT_COMPLETED   SDS maintenance mode exit completed

Saídas de log:
 

Registros de eventos do MDM: O registro de eventos do MDM mostra a sequência no nível do cluster. Os indicadores-chave são operações de role-switch durante a saída do modo de manutenção.

Logs de rastreamento do SDS: Nos nós do SDS, os logs de rastreamento mostram operações repetidas de role-switch durante a reintegração:

raidComb_SetPriTgtGenNum: combId <id> combGenNum: cur <gen> new <gen>
contCmd_SetCombState: CombId <id> devId <id> PRI->SEC Switch roles
contCmd_SetCombState: CombId <id> devId <id> SEC->PRI Switch roles

Um alto volume de entradas de funções de switch em um espaço de tempo curto (milhares ou mais em segundos) é o indicador definitivo do lado do SDS sobre esse problema.

Logs do SDC/host: O E/S do VMware (ESXi) SDC mostra novamente o pente, o SDS de destino e o código de falha:

vmkernel log
PowerFlex mapVolIO_Do_CK:1496 :Mit: <addr>. Retrying IO Type WRITE. Failed comb: <id>. SDS_ID <id>. Comb Gen <gen>. Head Gen <gen>.
PowerFlex mapVolIO_Do_CK:1510 :Mit: <addr>. Vol ID <id>. Last fault Status IO_FAULT_NOT_PRI(12). Retry count (1)

Se repetir, os erros SCSI serão exibidos: 

sense data: 0x4 0x0 0x0   -- SCSI Hardware Error

Dica de diagnóstico: Se você vir erros de E/S em vários nós SDS (não apenas no nó que teve problema), isso pode indicar uma tempestade de role-switch, em vez de um comportamento normal de estado degradado. Se os erros de E/S forem isolados em um único SDS, esse é o comportamento esperado de estado degradado.

Cenário 5: Transições de fase do modo de manutenção 

Quando isso pode acontecer:
Durante a transição, quando um SDS entra ou sai do modo de manutenção (IMM ou PMM) — no momento, o estado muda de normal para MM ou de MM de volta ao normal.

O que acontece:

• O balanceador de função redistribui as responsabilidades de dados para acomodar a alteração
• Breves picos de trocas de função ocorrem à medida que o sistema se acomoda no novo arranjo
• Os aplicativos podem enfrentar picos curtos de latência durante a transição

Impacto:

• Impacto sobre o cliente: Picos de latência breves que duram de segundos a alguns minutos. Geralmente abaixo dos limites de tempo de espera excedido do aplicativo
• Duração: Dura de segundos a alguns minutos, depois se acomoda
• Recuperação: Automático

Cadeia de eventos:

Log Source  Event / Pattern
SDS traces  Brief role-switch operations during phase transitions

Um defeito de software na lógica de balanceamento de funções do MDM causa um loop de feedback quando o cluster faz a transição de estado devido a uma perda de SDS ou operação no modo de manutenção.

Em determinadas condições, o MDM reatribui repetidamente quais nós SDS são responsáveis por servir E/S aos pentes afetados. Cada reatribuição invalida a exibição em cache do SDC de onde os dados estão localizados, forçando novas tentativas de E/S. Quando muitos combs são afetados simultaneamente, o volume de reatribuições supera a capacidade de atualização dos SDCs, resultando em erros contínuos de E/S em vários hosts.

A tempestade é tipicamente autolimitada. Ele é resolvido assim que o cluster se estabiliza, mas a duração depende do tamanho do domínio de proteção e da carga de E/S no momento do evento.

Esse problema é resolvido no PowerFlex Core versão 4.5.6. Faça upgrade para essa versão assim que estiver disponível. Entre em contato com o Suporte Dell para obter informações sobre a linha do tempo da versão.

Para operações de manutenção planejada:

• Não realize o ciclo de alimentação nem reinicialize um SDS até que o MDM efetue o registro SDS_MAINTENANCE_MODE_STARTED. Verifique se o SDS entrou totalmente no modo de manutenção antes de prosseguir com a manutenção física.
• Monitore picos de latência ao entrar ou sair do modo de manutenção.

Para interrupções não planejadas do SDS:

• A tempestade é autolimitada e normalmente se resolve em minutos à medida que o cluster se estabiliza. Se o problema for observado, colete getinfo logs de todos os nós SDS no domínio de proteção, dos MDMs de todos os gerenciadores o mais rápido possível após o evento, e entre em contato com o Suporte Dell.

Em casos raros em que o problema não é resolvido automaticamente, desabilitar temporariamente e reativar a reconstrução pode permitir que o MDM se estabilize:

scli --set_rebuild_mode --protection_domain_name <pd_name> --storage_pool_name <sp_name> --disable_rebuild

# Aguarde de 5 a 10 segundos e ative a recriação: 

scli --set_rebuild_mode --protection_domain_name <pd_name> --storage_pool_name <sp_name> --enable_rebuild