Início / server / Perguntas / 661881
Accepted
Nils
Asked: 2015-01-24 06:37:12 +0800 CST

Qual é a maneira correta de desligar um destino iSCSI com clientes conectados?

  • 772

iSCSI com dois nós primários DRBD é uma má ideia de usar se os dois caminhos receberem solicitações de gravação simultâneas. Mas estou pensando em usar essa ideia como armazenamento de back-end para um host ESXi 5.5U2.

Eu já testei isso com configurações primárias/secundárias e um cluster de failover clássico.

O que o ESXi faz neste ponto é que ele detecta um multipath e usa apenas um caminho ativamente. Portanto, nesta constelação, o problema de gravação simultânea não parece surgir.

Agora, o problema em ambos os casos (primário/secundário ou primário/primário) é: Como faço para desligar um servidor iSCSI (provedor de destino iSCSI em termos iSCSI) que possui conexões abertas ativas para um cliente iSCSI (iniciador iSCSI em termos iSCSI)?

Atualmente, uso o CentOS 5 nos servidores de destino.

CO5 usa tgtd para fornecer os alvos. Para minha surpresa, o método de parada normal falha, se houver clientes conectados. Em vez disso, a parada forçada parece ser o que preciso neste caso.

Desejo desligar um servidor de forma limpa (tenho que interromper o acesso ao destino, para poder alternar drbd para secundário) e o outro servidor deve se tornar ativo automaticamente (nada a fazer nesta constelação IMHO).

Perguntas nesse contexto: O seguinte está correto ou estou perdendo alguma coisa?

  1. parada forçada de tgtd (primeiro desligará os alvos)
  2. destruir o IP na direção do iniciador (linha diferente daquela usada para replicação drbd)
  3. drbd de desligamento (tornando-o secundário primeiro)
  4. reiniciar ou desligar o servidor
centos

1 respostas

  1. Best Answer

    Sim, eu perdi alguma coisa. O problema ainda é que o protocolo subjacente (SCSI) é um protocolo stateful . Portanto, mesmo que eu consiga desligar o alvo (por exemplo, com parada forçada), isso deixará os iniciadores de atividade em um estado "pendurado".

    Mas: No meu caso de uso, há uma solução para o problema.

    1. no vCenter, desative todos os caminhos para um determinado iSCSI-Server.
    2. Isso encerrará ordenadamente todas as transações iSCSI abertas e abrirá novas transações no outro caminho para o outro servidor.
    3. Depois disso, o iSCSI-Server pode ser reinicializado com segurança sem interrupção do cliente.
    4. Depois que o iSCSI-Server estiver funcionando novamente, os caminhos iSCSI originais podem ser reativados ativando esses caminhos no vCenter.

    Portanto, a resposta adequada às minhas perguntas parece ser:

    Curto: Não existe uma maneira adequada. Seus clientes vão travar.

    Longo: Depende. Se você tiver uma camada intermediária que seja capaz de silenciar/encerrar adequadamente o tráfego iSCSI primeiro, você pode encerrar o destino posteriormente (mesmo que o servidor de destino ainda pense que existem clientes iniciadores conectados).

    • 0

relate perguntas