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

Question

iSCSI com dois Os nós primários do DRBD não são uma boa ideia se os dois caminhos obtiverem 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, nessa 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 encerrar 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.

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

Eu quero desligar um servidor de forma limpa (eu tenho que parar o acesso ao alvo, então eu posso mudar o drbd para o secundário) e o outro servidor deve se tornar automaticamente ativo (nada a ver nesta constelação IMHO).

Perguntas nesse contexto: O seguinte está ok ou estou faltando alguma coisa?

1. parada forçada do tgtd (primeiro desconectará os destinos)
2. derrubar o IP na direção do iniciador (linha diferente daquela usada para a replicação do drbd)
3. shutdown drbd (tornando-o secundário primeiro)
4. reinicializar ou desligar o servidor

Answer 1

Sim, eu senti falta de algo. 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), ele deixará os iniciadores ativados em um estado "suspenso".

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

1. no vCenter desabilite todos os caminhos para um determinado servidor iSCSI.
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 reiniciado com segurança sem interrupção do cliente.
4. Depois que o iSCSI-Server estiver ativo e em execução novamente, os caminhos iSCSI originais poderão ser reativados ao ativar esses caminhos no vCenter.

Então a resposta adequada para minhas perguntas parece ser:

Curto: Não há um caminho adequado. Seus clientes vão parar.

Long: Depende. Se você tiver uma camada intermediária capaz de silenciar / terminar adequadamente o tráfego iSCSI primeiro, poderá finalizar o destino posteriormente (mesmo que o servidor de destino ainda pense que há clientes iniciadores conectados).