TechNet
Exportar (0) Imprimir
Expandir Tudo
Este artigo foi traduzido por máquina. Para visualizar o arquivo em inglês, marque a caixa de seleção Inglês. Você também pode exibir o texto Em inglês em uma janela pop-up, movendo o ponteiro do mouse sobre o texto.
Tradução
Inglês

Notas de implementação de destino iSCSI

 

Aplica-se a: Windows Storage Server 2012

Servidor de destino iSCSI foi implementado em conformidade com os padrões do setor que são especificados pelo RFC 3720 e RFC 5048. Para verificar essa conformidade, o servidor de destino iSCSI foi testado por uma organização de testes de conformidade.

Este documento lista os problemas encontrados durante o teste do servidor de destino no Windows Server 2012 de iSCSI. Para obter a versão anterior – Microsoft iSCSI Software Target versão 3.3 - problemas conhecidos são listados emMicrosoft iSCSI Software destino 3.3 implementação notas(http://technet.microsoft.com/library/gg983494 (v=ws.10)).

A seguir estão os problemas conhecidos com o servidor de destino de iSCSI do Windows ® Server 2012.

RFC 3720, seção 3.2.4.2, especifica o seguinte:

Também é um erro para um iniciador envie mais dados não solicitados, se imediata ou como PDUs separadas, que FirstBurstLength.

O comportamento apresentado pelo servidor de destino ISCSI:

Ao responder a umagravarcomando com dados mais imediata do que o especificado pelo FirstBurstLength, o servidor de destino iSCSI envia uma PDU de resposta SCSI com um status deBOM.

RFC 3720, seção 10.4.7.2, especifica o seguinte:

O destino reporta a condição 'Valor incorreto de dados' se durante a saída de dados, o comprimento total dos dados de saída é maior que FirstBurstLength e o iniciador enviou dados distantes não solicitados, mas a quantidade total de dados não solicitados é diferente de FirstBurstLength. O destino relata o mesmo erro quando a quantidade de dados enviados como resposta a um R2T não coincide com a quantidade solicitada.

O comportamento apresentado pelo servidor de destino ISCSI:

O iSCSI no servidor de destino responde com status de 0x00 (BOM) depois de receber mais de 512 bytes de dados quando FirstBurstLength = 512.

O servidor de destino iSCSI responde com status de 0x00 (BOM) após o recebimento de dados menor que ExpectedDataTranserLength especificado e F bit definido como 1.

RFC 3720, seção 12.11, especifica o seguinte:

Se ImmediateData estiver definida como não e InitialR2T estiver definido como Sim, o iniciador não deve enviar não solicitados dados e o destino devem rejeitar dados não solicitados com o código de resposta correspondente.

O comportamento apresentado pelo servidor de destino ISCSI:

Quando o ImmediateData estiver definida como não e InitialR2T está definida como Sim, o servidor de destino iSCSI foi observado para responder com o status bom quando ele recebeu um comando de gravação com dados não solicitados inesperados.

RFC 3720, seção 10.11.1, especifica o seguinte:

Uma resposta de texto com o bit de F definido como 1 em resposta a uma solicitação de texto com o bit de F definido como 0 é um erro de protocolo.

O comportamento apresentado pelo servidor de destino ISCSI:

O iSCSI de servidor de destino foi observada para enviar uma resposta de texto: TargetTransferTag = 0xFFFFFFFF enquanto o bit F não foi definido.

RFC 3720, seção 3.5.3.1, especifica o comportamento do texto de solicitação e resposta de texto da seguinte maneira:

Texto de solicitações e respostas são projetadas como um veículo de negociação de parâmetro e como um veículo para uma futura extensão.

No segmento de dados, texto solicitações/respostas transportar informações de texto usando um simples "key = value" sintaxe.

Solicitações/respostas de texto pode formar sequências estendidas usando a mesma marca de tarefa do iniciador. O iniciador usa o bit de sinalizador (Final) F no cabeçalho da solicitação de texto para indicar sua prontidão para encerrar uma sequência. O destino usa o bit de sinalizador (Final) F no cabeçalho de resposta de texto para indicar seu consentimento para o término da sequência.

Solicitação de texto e as respostas também usam a marca de transferência de destino para indicar a continuação de uma operação ou um novo início. Um destino que deseja continuar uma operação definirá a marca de transferência de destino em uma resposta de texto para um valor diferente do padrão 0xffffffff.

Um iniciador disposto a continuar copiará esse valor na marca de transferência de destino da próxima solicitação de texto. Se quiser que o iniciador reiniciar a negociação de destino atual (Iniciar nova) definirá a marca de transferência de destino como 0xffffffff.

Embora uma troca completa é sempre iniciada pelo iniciador, negociações de parâmetro específico podem ser iniciadas pelo iniciador ou destino.

O comportamento apresentado pelo servidor de destino ISCSI:

O iSCSI servidor de destino foi observada para desconectar a sessão depois que ele recebeu uma solicitação de texto durante uma sessão normal, quando as seguintes condições existiam:

F bit foi definido como 0

Houve um MaxRecvDataSegmentLengthKey anexado

Isso acontece com ou sem um ITT válido (marca de tarefa do iniciador).

RFC 3720, seção 3.3, especifica o seguinte:

Sessão de descoberta - somente uma sessão aberta para a descoberta de destino. O destino deve apenas aceitar solicitações de texto com a chave SendTargets e uma solicitação de logout com o motivo "fechará a sessão". Todas as outras solicitações devem ser rejeitadas.

O comportamento apresentado pelo servidor de destino ISCSI:

O servidor de destino iSCSI foi observado desconectar depois de receber uma solicitação de texto com uma chave MaxRecvDataSegmentLength anexada durante uma sessão de descoberta.

RFC 3720, Apêndice D, especifica o seguinte:

Se o valor de SendTargets for nothing no texto Request, "a sessão deve responder apenas com endereços de destino ao qual a sessão está conectada. Isso deve ser suportado em sessões operacionais e não deve retornar destinos diferente ao qual a sessão está conectada.

O comportamento apresentado pelo servidor de destino ISCSI:

O iSCSI foi observado que o servidor de destino para desconectar depois de receber uma solicitação de texto com um anexado "SendTargets =" chave durante uma sessão de descoberta e durante uma sessão normal.

RFC 3720, Apêndice D, especifica o seguinte:

Se o valor de SendTargets for "All" na solicitação de texto, "o iniciador está solicitando que informações sobre todos os destinos relevantes conhecidos na implementação seja retornado. Esse valor deve ser suportado em uma sessão de descoberta e não deve ser suportado em uma sessão operacional."

O comportamento apresentado pelo servidor de destino ISCSI:

O iSCSI foi observado que o servidor de destino para desconectar depois de receber uma solicitação de texto com um anexado "SendTargets = All" chave durante uma sessão normal.

RFC 3720, seção 6.10, especifica o seguinte:

Uma falha de negociação é considerada um ou mais destes procedimentos:

Nenhuma das opções ou o valor indicado, é aceitável para um dos lados na negociação.

A solicitação de texto atingiu o tempo limite e possivelmente encerrado.

A solicitação de texto foi respondida com uma PDU rejeitar.

O comportamento implementado pelo ISCSI Software Target no Windows Server 2012:

O iSCSI o servidor de destino foi observado para desconectar a sessão depois de receber uma solicitação de texto com o bit de F definido como 0 e um MaxRecvDataSegmentLengthKey anexado.

RFC 3720, seção 5.2, especifica o seguinte:

Um destino de receber um texto ou uma solicitação de logon com o bit de C definido como 1 deve responder com uma resposta de logon ou de texto com nenhum segmento de dados (DataSegmentLength 0).

O comportamento apresentado pelo servidor de destino ISCSI:

O servidor de destino iSCSI foi observado desconectar após receber uma solicitação de texto com C bit definido como 1.

RFC 3720, seção 10.13.3, especifica o seguinte:

Uma nova sessão, o destino deve gerar um TSIH diferente de zero e retornar somente o logon Final-resposta.

O comportamento apresentado pelo servidor de destino ISCSI:

Quando o iniciador iSCSI executada um logon padrão e negociado os parâmetros de logon, o servidor de destino iSCSI foi observado para definir o campo TSIH no primeiro logon resposta PDU.

RFC 3720, seção 3.2.2.1 Especifica o seguinte:

O destino deve ignorar silenciosamente qualquer comando distantes fora esse intervalo ou distantes duplicatas dentro do intervalo.

Para comandos não imediato, o campo CmdSN pode ter qualquer valor de ExpCmdSN para MaxCmdSN inclusivo. O comportamento apresentado pelo servidor de destino ISCSI:

O servidor de destino iSCSI não envia um R2T em resposta a um comando de gravação que foi seguido por uma gravação duplicada. Ele ignora qualquer PDU que CmdSN não é a próxima CmdSN seqüencial silenciosamente.

System_CAPS_noteObservação

Como o servidor de destino iSCSI oferece suporte a uma conexão por sessão, ele ignora atualmente silenciosamente qualquer PDU que CmdSN não é a próxima CmdSN seqüencial.

RFC 3720, seção 10.6.1, especifica o seguinte:

Se a marca de tarefa referenciado não identifica uma tarefa existente e a CmdSN indicado pelo campo RefCmdSN na solicitação de função de gerenciamento de tarefas está fora da janela CmdSN válida, destinos devem retornar a resposta "Tarefa não existe".

O destino fornece uma resposta, que pode assumir os seguintes valores:

a)    0 - Function complete. b)    1 - Task does not exist. c)    2 - LUN does not exist. d)    3 - Task still allegiant. e)    4 - Task allegiance reassignment not supported.

O comportamento apresentado pelo servidor de destino ISCSI:

O servidor de destino iSCSI foi observado responder com 0 (função concluída), ao receber um RefrencedTaskTag inexistente e um RefCmdSN fora da janela CmdSN válida.

RFC 3720, seção 3.3, especifica o seguinte:

Sessão de descoberta - somente uma sessão aberta para a descoberta de destino. O destino deve apenas aceitar solicitações de texto com a chave SendTargets e uma solicitação de logout com o motivo "fechará a sessão". Todas as outras solicitações devem ser rejeitadas.

O comportamento apresentado pelo servidor de destino ISCSI:

Durante a sessão de descoberta, o servidor de destino iSCSI envia um código de resposta de 0x00 (êxito) em resposta a uma solicitação de logout com o código de motivo 2 (remover a conexão com recuperação).

RFC 3720, seção 10.14, especifica o seguinte:

Ao receber uma solicitação de Logout com o código de motivo de "fechar a conexão" ou "sessão", o destino deve terminar todos os comandos pendentes, se confirmado via ExpCmdSN ou não, na conexão ou sessão, respectivamente.

O comportamento apresentado pelo servidor de destino ISCSI:

O servidor de destino iSCSI envia um código de resposta de 0x00 (êxito) em resposta a uma solicitação de logout com o código de motivo 1 (fecha a conexão) para um CID inexistente.

System_CAPS_noteObservação

O servidor de destino iSCSI oferece suporte a uma sessão por conexão e atualmente ignora o valor de CID.

RFC 3720, seção 5.2, especifica o seguinte:

Se aceitante envia "Rejeitar" como uma resposta a chave negociada é deixada no seu valor atual (ou padrão se nenhum valor foi definido). Se o valor atual não é aceitável para proposer na conexão ou a sessão que é enviado, o proposer pode optar por encerrar a conexão ou a sessão.

Todas as chaves contidas neste documento, exceto para X formatos de extensão devem ser suportados por iniciadores iSCSI e destinos quando usado como especificado aqui. Se usado conforme especificado, essas chaves não devem ser respondidas com NotUnderstood.

O comportamento apresentado pelo servidor de destino ISCSI:

O iSCSI de servidor de destino foi observada para enviar uma mensagem de sucesso de logon quando ele recebeu uma solicitação com o TargetPortalGroupTag = chave NotUnderstood.

RFC 3720, seção 5.3, especifica o seguinte:

O iniciador nem o destino deve tentar declarar ou negocie um parâmetro de mais de uma vez durante o logon, exceto as respostas para as chaves específicas que permitam explicitamente as declarações da chave repetidas (por exemplo, TargetAddress). Uma tentativa de renegociar ou redeclarar parâmetros não especificamente permitido deve ser detectada pelo iniciador e de destino. Se uma tentativa for detectada pelo computador de destino, o destino deve responder com logon Rejeitar (erro do iniciador).

O comportamento apresentado pelo servidor de destino ISCSI:

Foi observado que o servidor de destino iSCSI permitem renegociação dos seguintes parâmetros durante a fase de logon:

Chave ImmediateData = par de valor para Sim

Chave MaxBurstLength = par de valor para 32524

Chave DataDigest = par de valor para CRC32C

Double negociação da chave DataDigest = par de valor na mesma PDU

Quando ele recebe parâmetros anteriores duas vezes na fase de negociação, o servidor de destino iSCSI prosseguirá com a solicitação de logon.

RFC 3720, seção 10.17.3, especifica o seguinte:

StatSN, ExpCmdSN e MaxCmdSN executar seus valores normais e não estão relacionados ao comando rejeitado. StatSN é avançado após um rejeitar.

O comportamento apresentado pelo servidor de destino ISCSI:

O servidor de destino iSCSI foi observado para enviar um StatSN incorreta ao rejeitar a solicitação de dica.

RFC 3720, seção 5.2, especifica o seguinte:

Qualquer tecla não compreendida pelo aceitante pode ser ignorada pelo aceitante sem afetar o funcionamento básico. No entanto, a resposta para uma chave não compreendida deve ser chave = NotUnderstood.

O comportamento apresentado pelo servidor de destino ISCSI:

O iSCSI o servidor de destino foi observado para ignorar as chaves específicas do fornecedor e continuar com a fase de logon quando o bit C é definida. Se o bit de C não for definido, o servidor de destino iSCSI em conformidade com o padrão.

Mostrar:
© 2016 Microsoft