iSCSI, failover e XenServer

Question

Eu tenho uma configuração de implementação de failover iSCSI, portanto, se uma das minhas unidades de armazenamento falhar, a outra assumirá imediatamente (ela também executará os compartilhamentos NFS). Quando o failover ocorre, os volumes são exportados, o IP é comutado para a outra máquina e os destinos são reconfigurados. O failover do próprio sistema de armazenamento funciona bem. Eu uso o NexentaStor para o meu arquivador.

Quando faço um failover (manual) de teste do meu armazenamento, ocorre o seguinte:

Observação: eu executo as VMs administrativas no NFS e as VMs baseadas no cliente no iSCSI

1. Todas as VMs baseadas em NFS permanecem funcionando perfeitamente com o failover e depois
2. Todas as VMs em execução no iSCSI relatam o seguinte:
   • Um erro sobre não ser capaz de gravar em um determinado bloco
   • Um erro sobre o diário não funcionar
   • Em seguida, o sistema de arquivos fica em RO

Para que as VMs funcionem novamente, preciso fazer o seguinte:

1. Forçar o desligamento das VMs "quebradas".
2. Desanexe o iSCSI SR
3. Anexe novamente o SR iSCSI
4. Inicialize a VM em um servidor diferente (5 no meu pool) Se eu não inicializar em um servidor diferente, recebo esse erro "Internal error: Failure("The VDI <uuid&gt; is already attached in RW mode; it can't be attached in RO mode!")" A única maneira que encontrei para corrigir esse erro é reinicializar todo o servidor estava sendo executado anteriormente, o que obviamente é uma grande dor.

Atualmente, o multipathing NÃO está habilitado (mas pode ser e a mesma coisa ainda ocorre). Eu editei muito do arquivo /etc/iscsid.conf para trabalhar com as configurações de tempo limite, mas sem sucesso.

Em suma, meu armazenamento falha corretamente, mas o XenServer não mantém a conexão ativa. Como um pensamento, o erro que aparece no # 4 acima pode ser a causa final e a correção que consertaria tudo?

Qualquer ajuda seria apreciada mais do que você sabe.

    

Answer 1

Eu tive um problema muito parecido com o failover do iSCSI. É abordado em esta questão . Você pode ver minha solução aceita que descobri sozinha para obter informações sobre como resolvi isso.

Basicamente, envolvia a configuração

node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0
node.session.timeo.replacement_timeout = 86400

para que a sessão do iSCSI tenha tempo suficiente para se recuperar antes de relatar erros na cadeia até o kernel.

    

Answer 2

xe-toolstack-restart corrigiu para mim.