Os sistemas de arquivos raiz Xen DomU se tornam somente leitura no failover de IP virtual iSCSI

Question

Meus servidores Xen são openSUSE 11.1 com open-iscsi para o 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 selecionará a função de veiculação como o destino. Tudo isso é gerenciado pelo software LeftHand SAN / iQ e funciona bem na maioria das situações.

O problema que tenho é que ocasionalmente alguns dos meus Xen DomUs terão seu sistema de arquivos raiz como somente leitura após um failover de IP. Não é consistente e acontece com um subconjunto diferente sempre que ocorre um failover. Todos executam a mesma imagem do software openSUSE 11.1.

Os sistemas de arquivos raiz para cada DomU são montados por 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 root, a execução de touch /test retorna o erro "sistema de arquivos somente leitura". No entanto, a saída de mount mostra a montagem como leitura-gravação. Naturalmente, todas as outras E / S no domU também estão falhando neste momento, então a máquina é danificada. Simplesmente reiniciá-lo com xm do Dom0 sem até mesmo reconectar a sessão iSCSI faz tudo funcionar novamente.

No lado 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 em descobrir em que camada depurar esse problema, é algo no kernel DomU? ou no nível Dom0 ou Xen? Eu acho que há algum parâmetro em algum lugar que precise de ajustes para aumentar algum tempo, mas não tenho certeza 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 a partir do Dom0.

    

Answer 1

Eu finalmente resolvi 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 recurso, mesmo que demore vários minutos para acontecer.

    

Answer 2

Isso soa como um problema com o iniciador iSCSI em execução no dom0. O iniciador não deve estar enviando falhas SCSI para a pilha rapidamente. Você provavelmente desejará configurar o ConnFailTimeout em iscsi.conf, essa é a configuração que determina quanto tempo demora para considerar uma falha de conexão como um erro e envia esse erro para a pilha SCSI.

Eu também verificaria quanto tempo esse failover está realmente tomando, pode levar mais tempo do que o esperado. Se sim, talvez o failover do VIP esteja demorando muito devido a problemas relacionados ao ARP.

    

Answer 3

Existe alguma mensagem no dom0 indicando algum tipo de erro de leitura / gravação ou erro scsi no momento do failover? Se assim for, parece que este erro de escrita 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 sumido e remontado o sistema de arquivos como somente leitura (consulte a manpage mount (1) - errors=continue / errors=remount-ro / errors=panic )

Do ponto de vista do dom0, ele não será alterado para somente leitura - este comportamento somente leitura é uma semântica do sistema de arquivos, não um semântico de dispositivo de bloco.

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

Normalmente, ao configurar uma solução HA iSCSI, eu uso multipathing em vez de IP virtual - ele permite uma maior visibilidade do host e você não tem uma sessão iSCSI de repente desaparecendo, em seguida, precisando ser reiniciada - está sempre lá, há apenas dois deles. Esta é uma opção neste ambiente?

    

Answer 4

Um ... Parte do problema é que você não está rodando / como RO. As melhores práticas de segurança dizem que você deve ter "/" montado ro, e que quaisquer sistemas de arquivos que precisem de rw devem ser montados separadamente (isto é, / var e / tmp). Se existem diretórios em / etc que precisam ser escritos, eles devem ser movidos para / var / etc / path e link para / etc.

"/" só deve ser montado em RW no modo de usuário único.

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