APRENDER. PRATICAR. EVOLUIR.Começar por uma matriz de evidência
Nesta oficina, as linhas de inventário são fictícias e identificadas como tal. Não foram recolhidas numa SAN, nem representam a infraestrutura de um banco. Executa o script local para obter oito resultados determinísticos e compara primeiro as previsões com o JSON. Para cada linha, regista o host, alias local, WWID, iniciador e componentes atravessados. Acrescenta a origem e a hora quando estiveres a trabalhar com evidência real. Um inventário antigo pode descrever corretamente uma configuração que já mudou. O resultado esperado da oficina é uma decisão fundamentada, acompanhada das verificações ainda em falta. A execução do modelo não demonstra compatibilidade de drivers, desempenho ou comportamento de failover de um produto.
Resolver a identidade entre hosts
O primeiro grupo apresenta host-a/mpatha/W-A e host-b/mpatha/W-B. O mesmo alias está associado a volumes diferentes. No host-b, a entrada mpathc corresponde a W-A e é a candidata a correlacionar com o volume do host-a. Não alteres a identidade do volume para fazer o nome coincidir. Numa reconstrução, compara o inventário aprovado com a apresentação efetiva antes de qualquer escrita. Capacidade igual ou número de LUN igual também não resolve uma divergência de WWID. A decisão deve incluir qual volume se pretendia disponibilizar e qual foi realmente observado. Se a correspondência continuar incerta, mantém a aplicação sem acesso de escrita enquanto storage e aplicação reconciliam a informação.
Contar dependências que sobrevivem
No segundo grupo, quatro caminhos combinam duas HBAs, duas fabrics e dois controladores. Retirar fabric-a deixa p3 e p4; retirar também controller-a deixa apenas p4. Uma variante coloca todos os caminhos em fabric-a e perde os quatro quando essa fabric falha. Estes resultados provêm de conjuntos de dependências declarados, não de desligar equipamentos. O exercício obriga a formular a falha que se pretende tolerar. Acrescentar cabos no mesmo domínio pode melhorar outro aspeto sem resolver essa falha. Depois de prever os sobreviventes, identifica a evidência que falta: caminhos realmente utilizáveis, carga suportada e tempo de recuperação. Não apresentes um caminho restante como garantia automática de cumprimento do SLA.
Separar login de autorização da LUN
O terceiro grupo recebe sessão estabelecida, IQN efetivo aps-new e uma autorização que só contém aps-old. O predicado de acesso do modelo permanece falso. É uma simplificação para discutir duas condições diferentes, não uma implementação de iSCSI. No diagnóstico, usa a divergência para orientar a próxima recolha: identidade prevista do servidor reconstruído, configuração efetiva e mapping da LUN em falta. Copiar todos os acessos antigos sem revisão pode introduzir exposição indevida. Se o IQN já coincidir, a investigação continua pelo mapping específico e pelas restantes condições da plataforma. Documenta o que foi confirmado e o que falta. Um login positivo é evidência útil, mas não encerra a análise do volume pretendido.
Interpretar reservas pelo tipo concreto
O quarto grupo fixa host-a como holder e host-b como iniciador registado. Com PR_WRITE_EXCLUSIVE, o modelo permite leitura a host-b e recusa escrita. Com PR_EXCLUSIVE_ACCESS, recusa ambas; com PR_WRITE_EXCLUSIVE_REG_ONLY, permite ambas ao iniciador registado. A comparação mostra por que motivo a frase há uma reserva não basta para decidir quem pode escrever. O script não envia comandos SCSI, não transfere ownership e não testa fencing. Numa intervenção real, confirma o tipo, o holder, os registos e a coordenação prevista pelo cluster antes de propor qualquer alteração. Remover uma reserva para ultrapassar um erro pode eliminar uma proteção necessária. O passo seguinte depende da aplicação e do procedimento autorizado.
Decidir perante manutenções sobrepostas
Reserva dez minutos da oficina para a primeira situação de APS. Uma equipa mantém fabric-a indisponível e outra quer parar fabric-b antes do fim da janela. Usa a matriz para mostrar que os caminhos restantes dependem da segunda fabric. Produz uma decisão curta com estado observado, impacto da sobreposição, condição de avanço e responsável por validar recuperação. Se a janela não permitir repor e observar fabric-a, propõe reagendamento com o impacto comunicado. O facto de existirem dois tickets não demonstra independência técnica. Antes de aplicar o raciocínio a ONTAP, consulta também a matriz atual de plataforma, protocolo e versão. As regras de failover variam e não devem ser reduzidas a uma afirmação universal.
python3 content/labs/san-evidence/run.py
# Fictional path inventory; not output from multipath -ll
# p1 hba-a fabric-a controller-a
# p2 hba-a fabric-a controller-b
# p3 hba-b fabric-b controller-a
# p4 hba-b fabric-b controller-b
# Failed {fabric-a, controller-a} -> survivor p4
# Offline model; no SAN connection or physical failure injection.Um host fictício reconstruído apresenta o alias esperado, mas outro WWID. A sessão iSCSI existe e o mapping ainda refere o IQN anterior.
Armadilhas comuns
Confundir alias com identidade global, sessão com autorização, quatro caminhos com quatro domínios independentes ou registo de chave com exclusividade de escrita.
Tópicos relacionados: Storage · Suporte de produção L3 · Alta disponibilidade
Antes de autorizar escrita ou uma segunda manutenção, confirma o volume pretendido, quem lhe acede e que caminhos sobrevivem às falhas consideradas.
Referência: RHEL 9 DM Multipath: topology, identity, queue policy, resize and safe removal · DR SAN 2026-09; selected RHEL 9, ONTAP 9 and iSCSI behavior