Eu tenho um pool xenserver 6.5 funcional com dois nós. Ele é apoiado por um compartilhamento iscsi em um Dell MD3600i SAN e funciona bem. Foi criado antes do meu tempo.
Adicionamos mais três nós ao pool. No entanto, esses três novos nós não se conectarão ao armazenamento.
Aqui está um dos nós originais, funcionando bem:
[root@node1 ~]# iscsiadm -m session
tcp: [2] 10.19.3.11:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [3] 10.19.3.14:3260,2 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [4] 10.19.3.12:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [5] 10.19.3.13:3260,2 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
Aqui está um dos novos nós. Observe a corrupção no endereço?
[root@vnode3 ~]# iscsiadm -m session
tcp: [1] []:-1,2 ▒A<g▒▒▒-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [2] 10.19.3.12:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [3] 10.19.3.11:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [4] 10.19.3.14:3260,2 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
O endereço IP ausente é 0,13, mas outro nó está ausente 0,12
Comentários :
Tenho VMs de produção em execução ao vivo nos nós existentes e nenhum lugar para movê-las, portanto, reinicializar a SAN não é uma opção.
O multipathing está desabilitado nos nós originais, apesar do san ter 4 interfaces. Isso parece abaixo do ideal, então ativei caminhos múltiplos nos novos nós.
Os três novos nós têm cargas de sistema extremamente altas. As caixas originais têm uma média de carga de 0,5 para 1, e os três novos nós estão em cerca de 11,1, sem VMs em execução. top não mostra processos de alta CPU, então é algo relacionado ao kernel? Não há processos bloqueados no estado D (suspensão ininterrupta)
Se eu disser ao Xencenter para "consertar" esses repositórios de armazenamento, ele ficará girando por horas até que eu clique em cancelar. a mensagem éPlugging PDB for node5
Pergunta : Como faço para que meus novos membros do pool xenserver vejam o armazenamento do pool e funcionem conforme o esperado?
EDITAR Mais informações
- Nenhum dos novos nós fará uma reinicialização limpa - eles ficam presos em "parar o iSCSI" em uma reinicialização e eu tenho que usar o drac para religá-los remotamente.
- O Xencenter está convencido de que os nós estão em modo de manutenção e que não concluíram a inicialização.
Bom nó de pool:
[root@node1 ~]# multipath -ll
36f01faf000eaf7f90000076255c4a0f3 dm-36 DELL,MD36xxi
size=3.3T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=12 status=enabled
| |- 14:0:0:6 sdg 8:96 active ready running
| `- 15:0:0:6 sdi 8:128 active ready running
`-+- policy='round-robin 0' prio=11 status=enabled
|- 12:0:0:6 sdc 8:32 active ready running
`- 13:0:0:6 sdh 8:112 active ready running
36f01faf000eaf6fd0000098155ad077f dm-35 DELL,MD36xxi
size=917G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=14 status=enabled
| |- 12:0:0:5 sdb 8:16 active ready running
| `- 13:0:0:5 sdd 8:48 active ready running
`-+- policy='round-robin 0' prio=9 status=enabled
|- 14:0:0:5 sde 8:64 active ready running
`- 15:0:0:5 sdf 8:80 active ready running
Nó ruim
[root@vnode3 ~]# multipath
Dec 24 02:56:44 | 3614187703d4a1c001e0582691d5d6902: ignoring map
[root@vnode3 ~]# multipath -ll
[root@vnode3 ~]# (ie no response at all, exit code was 0)
Nó ruim
[root@vnode3 ~]# iscsiadm -m session
tcp: [1] []:-1,2 ▒A<g▒▒▒-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [2] 10.19.3.12:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [3] 10.19.3.11:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [4] 10.19.3.14:3260,2 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
[root@vnode3 ~]# iscsiadm -m node --loginall=all
Logging in to [iface: default, target: iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb, portal: 10.19.3.13,3260] (multiple)
^C iscsiadm: caught SIGINT, exiting...
Então, ele tenta fazer login em um IP no SAN, mas gira suas rodas por horas até eu acertar ^ C.
Se a descoberta iSCSI não funcionar, provavelmente é uma questão de IQN no host XenServer, o MD3600i ou ambos não se reconhecendo. Certifique-se de que o MD3600i tenha permissão de acesso de todos os seus IQNs em todos os seus hosts XenServer usando o utilitário MDSM da Dell e tente refazer a descoberta iSCSI:
iscsiadm -m descoberta -t st -p (MD3600i-controlador-principal-endereço IP)
iscsiadm -m node --loginall=all
sessão iscsiadm -m
Você deve ser capaz de fazer ping pelo menos no endereço IP primário do MD3600i de seus XenServers se tiver acesso à rede.
Observe também que você precisará primeiro configurar interfaces iSCSI separadas nos NICs associados a cada novo XenServer e atribuir endereços IP estáticos àqueles que são exclusivos e nas mesmas sub-redes das conexões iSCSI de seus outros hosts.
Espero ter ajudado, --Tobias
Para encerrar, havia várias coisas erradas.
Multipath parecia não ter nenhuma influência no problema.
Excluir e mexer nos arquivos em /var/lib/iscsi/* nos nós do xenserver não teve impacto no problema.
Eu tive que usar outros meios para reiniciar essas caixas mais novas também - elas iriam travar tentando parar o serviço iscsi.
E, finalmente, a corrupção no nome IQN visível
iscsiadm -m sessiondesapareceu completamente. Isso possivelmente estava relacionado à incompatibilidade de MTU.Para futuros pesquisadores da Internet - boa sorte!
Editar: em setembro de 2021, tive exatamente o mesmo problema, com um dell MD3800 SAN e alguns servidores xcp-ng. Novamente, foi causado por MTU incompatível. E o Google acabou de fazer essa pergunta, que eu havia esquecido completamente. Apenas mostra como é importante fornecer um fechamento para futuros leitores ... esse leitor pode ser você.