Fs de raiz iSCSI tolerante a falhas para Linux

Question

Estou no processo de mover alguns servidores Linux para um ambiente virtualizado com seus sistemas de arquivos montados a partir de volumes LVM, que por sua vez são hospedados em um NAS remoto via iSCSI. Eu posso iniciá-los e eles funcionam perfeitamente sem problemas.

No entanto, o servidor NAS é baseado no Windows e, quando a Microsoft emite correções, ele automaticamente as aplica e reinicia. Quando é reinicializado, todos os sistemas de arquivos dos servidores virtuais detectam erros e entram no modo somente leitura. Eu tentei remontá-los como leitura / gravação, mas o kernel tem o sistema de arquivos sinalizado como protegido contra gravação, então isso falha. A única maneira que consegui recuperar é desligar o virt, fsck seu volume LVM e reiniciá-lo.

Os virts montam esses volumes LVM com uma entrada fstab do formulário:

/dev/xvda2 / ext3 noatime,nodiratime,errors=remount-ro 0 1

ou

/dev/xvda2 / ext4 errors=remount-ro 0 1

O sistema operacional host virtual também tem uma montagem LVM / iSCSI do servidor NAS (no mesmo grupo de volume, mesmo) que continua trabalhando no modo de leitura / gravação apesar dessas interrupções. Sua entrada no fstab é:

/dev/mapper/nas6-dom0   /mnt/nas6   ext4    _netdev     0   0

Isso me leva a suspeitar que remover errors=remount-ro das entradas fstab dos convidados forneceria tolerância a falhas, mas estou um pouco desconfortável em fazer isso - se um erro real se desenvolver no sistema de arquivos, eu esperaria que isso escritas continuadas para os fs poderiam piorar as coisas em pouco tempo.

Qual é a melhor prática para resolver isso, de modo que os convidados virtuais possam continuar executando depois que o NAS for reinicializado?

    

Answer 1

De acordo com a documentação Open-iSCSI :

8.2 iSCSI settings for iSCSI root

When accessing the root partition directly through a iSCSI disk, the iSCSI timers should be set so that iSCSI layer has several chances to try to re-establish a session and so that commands are not quickly requeued to the SCSI layer. Basically you want the opposite of when using dm-multipath.

For this setup, you can turn off iSCSI pings by setting:

node.conn[0].timeo.noop_out_interval = 0

node.conn[0].timeo.noop_out_timeout = 0

And you can turn the replacement_timer to a very long value:

node.session.timeo.replacement_timeout = 86400

A configuração replacement_timeout é padronizada para 120 segundos e a reinicialização do NAS levou pouco mais de dois minutos e meio, portanto, esse tempo limite foi excedido e a sessão iSCSI foi descartada, juntamente com todas as solicitações de E / S pendentes, causando assim o virtual servidores para ver uma falha no disco e ir para o modo somente leitura.

Alterar a configuração de tempo limite conforme descrito acima deve evitar isso no futuro, pelo menos para interrupções de até 24 horas. E se for para baixo por mais tempo do que isso, existem problemas maiores para lidar de qualquer forma.

    

Answer 2

Há também uma maneira de alterar o parâmetro Recovery Timeout ao vivo, depois que a conexão já estiver estabelecida:

echo 86400 > /sys/class/iscsi_session/session28/recovery_tmo

substitua session28 pelo seu ID de sessão.