Sistemas de arquivos raiz Xen DomU se tornando somente leitura no failover de IP virtual iSCSI

Meus servidores Xen são o openSUSE 11.1 com open-iscsi no nosso cluster SAN iSCSI. Os módulos SAN estão em um grupo de failover de IP atrás de um IP virtual ao qual os iniciadores se conectam.

No caso de o servidor SAN principal ficar inativo, o secundário assume a função de servir como destino. Tudo isso é tratado pelo software LeftHand SAN / iQ e funciona bem na maioria das situações.

O problema que tenho é que, ocasionalmente, algumas das minhas Xen DomUs terão seu sistema de arquivos raiz somente para leitura após um failover de IP. Não é consistente e acontece com um subconjunto diferente cada vez que ocorre um failover. Todos eles estão executando a mesma imagem do software openSUSE 11.1.

Os sistemas de arquivos raiz para cada DomU são montados pelo open-iscsi no Dom0 e, em seguida, o Xen usa o driver de dispositivo de bloco padrão para expô-lo ao DomU.

O sintoma exato é que, como raiz, a execução touch /testretorna o erro "sistema de arquivos somente leitura". No entanto, a saída de mountmostra como sendo montado de leitura e gravação. Obviamente, todas as outras E / S na domU também estão falhando neste momento, portanto a máquina cai com dificuldade. Simplesmente reiniciá-lo a xmpartir do Dom0 sem sequer reconectar a sessão iSCSI faz com que tudo funcione novamente.

No lado do Dom0, as mensagens do syslog durante o failover são algo como o seguinte:

kernel: connection1:0: iscsi: detected conn error (1011)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (1 attempts) 

Estou tendo dificuldade para descobrir em que camada depurar esse problema, é algo no kernel do DomU? ou no nível Dom0 ou Xen? Eu acho que provavelmente existe algum parâmetro em algum lugar que precisa de ajustes para aumentar algum tipo de tempo limite, mas não sei ao certo onde procurar.

Eu realmente não acho que seja um problema com o open-iscsi simplesmente porque o dispositivo de bloco conectado ainda é legível e gravável no Dom0.

Acabei resolvendo isso usando os seguintes conselhos e configurações da documentação do open-iscsi:

8.2 iSCSI settings for iSCSI root
---------------------------------

When accessing the root parition 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

Depois de configurar a conexão com cada LUN, conforme descrito acima, o failover funciona como um encanto, mesmo que demore alguns minutos.

Isso parece um problema com o iniciador iSCSI em execução no dom0. O iniciador não deve enviar falhas SCSI para a pilha tão rapidamente. Você provavelmente desejará definir o ConnFailTimeout no iscsi.conf. Essa é a configuração que determina quanto tempo leva para considerar uma falha na conexão como um erro e envia esse erro para a pilha SCSI.

Também analisaria quanto tempo esse failover realmente está levando, pode levar mais tempo do que o esperado. Nesse caso, talvez o failover VIP esteja demorando muito devido a problemas relacionados ao ARP.

Há alguma mensagem no dom0 indicando algum tipo de erros de leitura / gravação ou de SCSI no momento do failover? Nesse caso, parece que esse erro de gravação está sendo passado para o domU. O domU não "sabe" que é um dispositivo iSCSI, por isso está se comportando como se o disco subjacente tivesse desaparecido e remontando o sistema de arquivos somente leitura (consulte a página de manual mount (1) - errors=continue / errors=remount-ro / errors=panic)

Da perspectiva do dom0, ele não será alterado para somente leitura - esse comportamento somente leitura é uma semântica do sistema de arquivos, não uma semântica de dispositivo de bloco.

Você mencionou que "todas as outras E / S estão falhando" neste momento - você quer dizer domU ou dom0?

Geralmente, ao configurar uma solução iSCSI de alta disponibilidade, uso caminhos múltiplos em vez de controle de IP virtual - ele permite maior visibilidade ao host e você não tem uma sessão iSCSI desaparecendo repentinamente e precisando ser reiniciado - está sempre lá, há apenas duas delas . Esta é uma opção neste ambiente?

Um ... Parte do problema também é que você não está executando / como RO. Práticas recomendadas em termos de segurança, você deve ter "/" ro montado e que todos os sistemas de arquivos que precisam de rw devem ser montados separadamente (ou seja, / var e / tmp). Se houver diretórios em / etc que precisam ser gravados, eles devem ser movidos para / var / etc / path e vinculados a / etc.

"/" deve ser montado apenas RW no modo de usuário único.

A configuração dessa maneira pode impedir o segfault na situação acima, quando combinado com as outras sugestões.