Resumo

  • A RFC 3721 separou o nome de protocolo permanente de um nó iSCSI, seu endereço de rede mutável e um apelido humano que não precisa ser único: três valores para perguntas distintas.
  • A descoberta localizava nomes de destinos e caminhos, mas não enumerava unidades lógicas SCSI nem comprovava login, autorização ou E/S bem-sucedida.

“Disco local” é um rótulo tranquilizador em um console de armazenamento. Também é uma identidade de protocolo ruim. A expressão pode ajudar alguém a escolher uma linha, mas não diz ao sistema remoto qual destino contatar, não comprova quem está se conectando e não decide o que essa conexão poderá usar. Em abril de 2004, a RFC 3721 explicitou essas diferenças para a nomenclatura e a descoberta do Internet Small Computer Systems Interface (iSCSI).

A principal escolha de projeto foi separar o nome de um nó do seu endereço. Um nó iSCSI lógico recebe um nome permanente e independente de localização durante toda a sua vida. O endereço combina esse nome com uma localização TCP, como host e porta. Um nó pode ter vários endereços, e suas coordenadas de rede podem mudar. A possibilidade de mover um adaptador entre máquinas era uma razão para não fazer da placa a identidade: o nó de armazenamento lógico poderia manter o estado SCSI e a configuração de autorização mesmo quando o caminho mudasse.

O nome qualificado iqn. incorpora uma data, um domínio escrito em ordem inversa que identifica a autoridade de nomenclatura e um sufixo local opcional. Essa sintaxe organiza um espaço de nomes; não prova a titularidade atual do domínio nem informa onde o destino está acessível. A RFC 3721 também descreve o formato eui., baseado em um identificador IEEE EUI-64. Nos dois casos, o nome identifica o nó, não funciona como rota de rede.

O apelido pertence a outra camada. É uma cadeia opcional de exibição em UTF-8 e não precisa ser única. O exemplo da RFC 3721 mostra “Local Disk” ao lado do nome real do destino. O apelido serve para reconhecimento humano; o protocolo não deve usá-lo para identificar, endereçar ou autenticar um iniciador ou destino. Dois sistemas podem mostrar a mesma expressão sem se referir ao mesmo destino. O nome pode continuar estável mesmo que o endereço mude. Um caminho pode levar a um destino sem dizer se determinada pessoa tem permissão para entrar.

Essa separação é especialmente importante quando o armazenamento muda de lugar. Se o nome do nó estivesse preso a uma interface ou endereço específico, uma reconfiguração da rede poderia parecer a criação de uma nova identidade de armazenamento. O nome estável permite que a configuração aponte para o nó lógico; os endereços descrevem onde uma sessão pode ser tentada. Isso é um mecanismo de continuidade, não uma garantia automática de migração: a RFC define comportamento de nomes e descoberta, mas não comprova que toda implementação preserve o estado corretamente durante uma mudança.

A descoberta também tem limites. Seu objetivo é permitir que o iniciador encontre destinos aos quais tem acesso e obtenha um ou mais endereços. A configuração estática pode fornecer essas informações de antemão. SendTargets permite consultar uma entidade de rede conhecida e pedir dados sobre destinos. Estruturas de descoberta sem configuração, como SLP e iSNS, oferecem opções mais amplas. A presença desses mecanismos em uma especificação não é um levantamento de quais redes de armazenamento os adotaram.

Acima de tudo, encontrar um destino não é encontrar seus discos. A RFC 3721 trata a descoberta de unidades lógicas SCSI (LUNs) como uma tarefa da camada SCSI, distinta da descoberta de destinos iSCSI. Um nome e um endereço retornados não comprovam uma sessão estabelecida, autenticação aprovada, autorização, um LUN visível nem a transferência de dados de uma aplicação. Cada etapa tem uma decisão e evidência próprias.

A seção de segurança reforça essa distinção. Em ambientes não confiáveis, não se deve confiar apenas no nome de nó declarado pelo iniciador. O destino autentica um identificador de segurança — os exemplos no documento incluem CHAP, SRP e Kerberos — e depois autoriza o acesso, geralmente por uma lista de controle de acesso. Esse identificador autenticado pode ser diferente do nome iSCSI declarado; a política precisa estabelecer explicitamente a correspondência entre eles. Autenticação responde quem comprovou uma credencial. Autorização responde o que essa identidade pode fazer.

Nem o apelido nem a resposta de descoberta resolvem essas perguntas.

A evolução posterior dos padrões acrescenta uma ressalva útil, mas limitada. A RFC 4171 tornou o iSNS opcional para iSCSI e obrigatório para iFCP. A RFC 7143, que consolidou o protocolo iSCSI em 2014, diz que equipamentos que precisem de descoberta além de SendTargets deveriam implementar iSNS para gestão estendida e interoperabilidade. Também registra que SLP não havia sido amplamente implementado ou implantado para iSCSI e recomenda que implementações não dependam da interoperabilidade baseada em SLP.

Essa é uma observação delimitada sobre iSCSI num RFC posterior — não um censo de todos os produtos de armazenamento ou métodos de descoberta de serviços.

A RFC 3721 é Informativa e complementa, sem substituir, a especificação de protocolo da RFC 3720. Sua contribuição histórica é um vocabulário de registros que não são intercambiáveis: nome estável do nó, endereço atual, apelido opcional, identidade de segurança autenticada, regra de autorização e destino descoberto. Um console prático pode exibi-los juntos. Uma operação confiável começa por não tratá-los como se fossem a mesma coisa.

Fontes