Resumo

  • A RFC 7147 colocou iSCSIProtocolLevel nos atributos de cada sessão e preservou o escopo da negociação entre iniciador e destino.
  • O nível 2 é evidência de estado do protocolo; não é recibo de uma tarefa SCSI concluída nem do resultado visto por uma aplicação.

O equipamento não é uma conversa só

Uma ficha de produto costuma condensar compatibilidade em um selo. Um sistema iSCSI em operação pode ter várias instâncias, nós, portais, sessões e conexões TCP. Cada sessão liga um iniciador a um destino, e é nesse vínculo que os pares negociam parâmetros. Outra sessão pode envolver outro host e outro estado, mesmo que chegue à mesma caixa de armazenamento.

Essa diferença aparece no desenho da RFC 7147. Publicada em abril de 2014, ela substituiu a RFC 4544 e atualizou o MIB de iSCSI para acompanhar as RFCs 7143 e 7144. O documento acrescentou à tabela de sessões dois atributos somente de leitura: iscsiSsnProtocolLevel e iscsiSsnTaskReporting. O primeiro informa o nível iSCSI negociado para aquela sessão. O segundo registra a semântica acordada com o destino para reportar a conclusão de tarefas.

Fixar o valor na linha da sessão preserva quem negociou com quem. Se o painel transformar esse número em uma propriedade geral do equipamento, uma negociação entre um iniciador e um destino vira, sem justificativa, uma promessa para todos os caminhos. O MIB mantém o escopo que o protocolo definiu, em vez de apagar a diferença numa etiqueta única.

A negociação abre a porta; não confirma o uso

A RFC 7144 exige que o valor 2 de iSCSIProtocolLevel seja negociado para usar as funções que ela descreve. Mas também diz que essa negociação é necessária, não suficiente, para usar as capacidades SCSI correspondentes. Uma implementação ainda pode recusar uma função específica de gerenciamento de tarefas. O iniciador precisa processar a resposta SCSI; a consulta ao MIB não substitui essa resposta.

Por isso, ler “nível 2” não permite concluir que toda função está disponível ou que uma operação foi bem-sucedida. O que a leitura sustenta é mais restrito: as duas pontas daquela sessão concordaram com o nível de protocolo. A implementação concreta, o comando enviado, a resposta do destino e a forma como o host tratou essa resposta continuam sendo perguntas separadas.

O atributo TaskReporting reforça a distinção. Seus bits representam regras negociadas para reportar a conclusão de tarefas, incluindo a referência da RFC 3720, ResponseFence e FastAbort. Eles descrevem a semântica do reporte; não atestam que uma tarefa particular ocorreu, que os dados foram persistidos ou que a aplicação aceitou o resultado.

A árvore de gestão não mistura as camadas

O MIB começa por uma instância iSCSI e organiza abaixo dela nós, portais, sessões e conexões. Cada objeto não escalar é indexado primeiro pela instância. Ela pode representar uma partição física ou virtual. A RFC 7147 ressalta que a instância não substitui um contexto SNMP; ela facilita associar uma partição a um ou mais contextos sem repetir o mapeamento em cada linha de nó, portal e sessão.

Essa estrutura deixa perguntas diferentes em lugares diferentes. A tabela de sessões expõe estado negociado de iSCSI; o MIB TCP descreve conexões de transporte; o MIB SCSI pode tratar atributos da camada SCSI. O host e a aplicação ainda definem seus próprios critérios de sucesso. Um operador consegue relacionar essas visões, mas um campo não transforma todas elas numa prova única.

É uma aplicação modesta da primazia do código em execução. A especificação tem valor quando iniciador e destino a implementam, negociam e trocam comandos. O MIB tem valor quando permite observar o estado definido naquele sistema. Só que uma observação continua presa a uma camada e a um instante. Para dizer que a operação deu certo, é preciso acompanhar a evidência até a resposta e até quem precisava do resultado.

O alcance correto do dado

O nível por sessão ajuda a explicar por que dois caminhos para o mesmo armazenamento podem se comportar de maneira diferente. Ele serve à análise de compatibilidade, à revisão de mudanças e à investigação de falhas. Também pode revelar que a negociação real divergiu da expectativa de configuração. Resumi-lo no nível do equipamento faria desaparecer justamente essa precisão.

As RFCs não informam quantos fabricantes implementaram os objetos, com que frequência eles são coletados ou como os clientes os usam. Uma leitura precisa guardar também o identificador da sessão e o horário. Se a sessão foi refeita, uma amostra antiga não descreve o caminho atual. Para verificar uma operação, é preciso correlacionar o estado com a resposta SCSI, o registro do host e o resultado da aplicação.

A conclusão é simples: o nível pertence ao acordo que o gerou. A RFC 7147 deu a esse acordo uma linha própria no MIB; o resultado da operação exige outra evidência.

Fontes