Xenserver, iSCSI e Dell MD3600i

Question

Eu tenho um pool xenserver 6.5 funcional com dois nós. É apoiado por um compartilhamento iscsi em uma SAN Dell MD3600i, e isso 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 é .13 mas falta outro nó .12

Comentários :

Eu tenho VMs de produção em execução ao vivo nos nós existentes e nenhum lugar para movê-los, portanto, reinicializar a SAN não é uma opção.

O multipathing está desativado nos nós originais, apesar de o san ter 4 interfaces. Isso parece sub ideal, então eu liguei vários caminhos nos novos nós.

Os três novos nós têm cargas de sistema muito altas. As caixas originais têm uma carga média de 0,5 a 1 e os três novos nós estão em torno de 11,1, sem VMs em execução. top não mostra altos processos de CPU, então é algo relacionado ao kernel? Não há processos bloqueados no estado D (sono ininterrupto)

Se eu disser ao Xencenter para "reparar" esses Repositórios de Armazenamento, ele ficará girando por horas até eu 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 como esperado?

EDITAR Mais informações

• Nenhum dos novos nós fará uma reinicialização limpa - eles serão colocados em "parar o iSCSI" em uma reinicialização e eu tenho que usar o drac para remotamente-los.
• O Xencenter está convencido de que os nós estão no 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ó inválido

[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ó inválido

[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 na SAN, mas gira suas rodas por horas até que eu pressione ^ C.

    

Answer 1

Para o encerramento, houve várias coisas erradas.

1. Os hosts foram configurados para uma MTU de 1500 bytes, enquanto a SAN de armazenamento estava usando MTU de 9216 bytes.
2. Um dos hosts tinha um IQN sutilmente diferente da realidade - o SAN listou o IQN correto como "não atribuído", embora fosse visualmente o mesmo que o IQN em uso.
3. Meus dois nós originais tinham IPs de gerenciamento configurados em sua placa de 1 Gbit interna. Os três novos nós tinham um IP de gerenciamento aceitável configurado na interface ligada, em uma vlan. Isso era muito diferente e impedia que os novos hosts saíssem do modo de manutenção após uma inicialização.

O Multipath pareceu não ter qualquer influência sobre o problema.

Excluir e mexer nos arquivos em / var / lib / iscsi / * nos nós xenserver não teve impacto sobre o problema.

Eu tive que usar outros meios para reinicializar essas novas caixas também - eles tentavam parar o serviço iscsi.

E, finalmente, a corrupção no nome IQN visível em iscsiadm -m session desapareceu completamente. Isso possivelmente foi relacionado à incompatibilidade de MTU.

Para futuros pesquisadores da internet - boa sorte!

    

Answer 2

Se a descoberta do iSCSI não funcionar, provavelmente é uma questão do IQN no host do XenSerever, o MD3600i ou ambos não reconhecendo um ao outro. Certifique-se de que o MD3600i tenha acesso permitido de todos os seus IQNs em todo o seu host XenServer usando o utilitário MDSM da Dell e tente refazer a descoberta iSCSI:

iscsiadm -m discovery -t st -p (MD3600i-primary-controller-IP-address)

iscsiadm -m node --loginall = all

iscsiadm -m session

Você deve pelo menos conseguir efetuar o ping do endereço IP principal do MD3600i a partir dos seus XenServers, se tiver acesso à rede.

Observe também que você precisa primeiro configurar interfaces iSCSI separadas nas NICs associadas a cada novo XenServer e atribuir endereços IP estáticos àqueles que são exclusivos e nas mesmas sub-redes das conecções iSCSI de outros hosts.

Espero que ajude --Tobias