APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Em iSCSI, encontrar um target durante discovery não prova que exista uma sessão de login funcional. Mesmo com sessão, é necessário validar autorização e apresentação da LUN esperada. A observação deve distinguir rede, portal, nome do target, identidade efetiva do initiator e mapping. Num host reinstalado, o IQN pode diferir daquele que permanece no igroup ou ACL. Um ping bem-sucedido não elimina esse problema. A documentação RHEL mostra inspeção de sessões com iscsiadm, incluindo estado dos dispositivos associados. Usa a evidência da etapa que falhou para orientar o próximo passo, sem formatar discos para tentar corrigir um problema de acesso remoto.
Aplicação guiada
CHAP autentica e não demonstra por si encriptação do payload. Proteção em repouso no array também não prova confidencialidade no percurso de rede. A referência RFC é usada para distinguir funções, sem recomendar algoritmos históricos. Se houver jumbo frames, valida compatibilidade de MTU em todo o percurso; pequenos pings não cobrem os tamanhos pretendidos. No arranque, um filesystem iSCSI depende da rede e das sessões. A opção _netdev participa na indicação dessa dependência, mas não cria sozinha uma sessão autorizada. Num exemplo fictício, o mount manual funciona depois do login enquanto o boot falha; revê preparação e ordem de arranque, além da identidade persistente do dispositivo.
Discovery mostra um target; a sessão e o acesso à LUN continuam a precisar de evidência.
Armadilhas comuns
Ping como autorização; discovery como login; CHAP como cifra; _netdev como configuração completa.
Tópicos relacionados: Topologia e identidade · Fibre Channel e acesso a LUNs · Multipathing e estados dos caminhos
Separa cada etapa e corrige a dependência demonstrada pela evidência.
Referência: RHEL 9 iSCSI discovery, login, boot and session inspection · DR SAN 2026-09; selected RHEL 9, ONTAP 9 and iSCSI behavior