ESX3.5 Cluster & MD3000i - Ambos os servidores visualizam destinos iSCSI, somente um servidor pode usar partição

Question

Tudo bem. Em primeiro lugar, aviso. Esta é uma questão maior do que a normal. Eu gosto de ser meticuloso e tentar eliminar todas as possíveis respostas "easymode", bem como dar a todos uma sensação do que eu tentei. Eu incluí várias imagens da nossa configuração e o problema que está tendo ...

Versão do TLDR: Então, eu segui os guias localizados aqui: ESX Deployment Guide V1 este é o guia que a Dell me enviou para configurar dois ESX3 .5 servidores que montam um Dell MD3000i. Não funciona Ambos os servidores não podem usar a mesma partição de armazenamento no MD3000. Ambos os servidores o veem, mas apenas um servidor pode realmente usá-lo. (esse servidor sendo qualquer servidor que criou a partição no destino.) Ambos os servidores ESX são membros do Grupo de hosts.

Versão completa

Eu tenho 2 servidores ESX3.5 (10.0.7.102, também chamados EPI2 e 10.0.7.103, também chamados EPI3.) conectados a um dispositivo SAN iSCSI (Dell MD3000i). Ambos os servidores ESX podem "varrer" a SAN e ver o LUNS.

Parte Um: Armazenamento do MD3000i

No MD3000i, os dois servidores estão no meu grupo de hosts.

Eutenhoduaspartições,VM1eVM2,ambasde1,6TB(vmwarenãogostadenadaalémde2TB.)

E você pode até ver que os servidores ESX estão direcionando o MD3000 muito bem.

Partedois:osservidoresESX

Figura 1.

Como você pode ver acima, os dois Servidores ESX (10.0.7.102 e 10.0.7.103) podem ver e varrer a SAN do MD3000i.
Figura 2.

Acima está o armazenamento que os dois servidores veem. Eu criei a partição de armazenamento no EPI2 (102). Em seguida, estendi a partição para incluir o segundo LUN para um total de 3,27 TB de armazenamento.

Quandoeu"verifico novamente" no 103 (o servidor não está montando a partição), recebo o log abaixo em log / messages.     11 de março 10:41:18 kernel do epi3: scsi1: remove-single-device 0 0 0 falhou, dispositivo ocupado (4). sendo a única linha que agarra minhas atenções. (EPI3 é o nome do servidor)

Mar 11 10:41:04 epi3 vmkiscsid[5436]: Connected to Discovery Address 192.168.130.101 
Mar 11 10:41:04 epi3 vmkiscsid[5437]: Connected to Discovery Address 192.168.130.102 
Mar 11 10:41:04 epi3 vmkiscsid[5438]: Connected to Discovery Address 192.168.131.101 
Mar 11 10:41:04 epi3 vmkiscsid[5439]: Connected to Discovery Address 192.168.131.102 
Mar 11 10:41:17 epi3 kernel: scsi singledevice 2 0 0 0
Mar 11 10:41:17 epi3 kernel:   Vendor: DELL      Model: MD3000i           Rev: 0735
Mar 11 10:41:17 epi3 kernel:   Type:   Direct-Access                      ANSI SCSI revision: 05
Mar 11 10:41:17 epi3 kernel: VMWARE SCSI Id: Supported VPD pages for sdb : 0x0 0x80 0x83 0x85 0x86 0x87 0xc0 0xc1 0xc2 0xc3 0xc4 0xc8 0xc9 0xca 0xd0 
Mar 11 10:41:17 epi3 kernel: VMWARE SCSI Id: Device id info for sdb: 0x1 0x3 0x0 0x10 0x60 0x1 0xe4 0xf0 0x0 0x1a 0x1a 0xa2 0x0 0x0 0x15 0xe2 0x4d 0x75 0xf6 0x99 0x53 0x98 0x0 0x54 0x69 0x71 0x6e 0x2e 0x31 0x39 0x38 0x34 0x2d 0x30 0x35 0x2e 0x63 0x6f 0x6d 0x2e 0x64 0x65 0x6c 0x6c 0x3a 0x70 0x6f 0x77 0x65 0x72 0x76 0x61 0x75 0x6c 0x74 0x2e 0x36 0x30 0x30 0x31 0x65 0x34 0x66 0x30 0x30 0x30 0x31 0x61 0x31 0x61 0x61 0x32 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x34 0x37 0x39 0x30 0x36 0x32 0x32 0x65 0x2c 0x74 0x2c 0x30 0x78 0x30 0x30 0x30 0x31 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x32 0x0 0x0 0x0 0x51 0x94 0x0 0x4 0x0 0x0 0x80 0x1 0x53 0xa8 0x0 0x44 0x69 0x71 0x6e 0x2e 0x31 0x39 0x38 0x34 0x2d 0x30 0x35 0x2e 0x63 0x6f 0x6d 0x2e 0x64 0x65 0x6c 0x6c 0x3a 0x70 0x6f 0x77 0x65 0x72 0x76 0x61 0x75 0x6c 0x74 0x2e 0x36 0x30 0x30 0x31 0x65 0x34 0x66 0x30 0x30 0x30 0x31 0x61 0x31 0x61 0x61 0x32 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x34 0x37 0x39 0x30 0x36 0x32 0x32 0x65 0x0 0x0 0x0 0x0 
Mar 11 10:41:17 epi3 kernel: VMWARE SCSI Id: Id for sdb 0x60 0x01 0xe4 0xf0 0x00 0x1a 0x1a 0xa2 0x00 0x00 0x15 0xe2 0x4d 0x75 0xf6 0x99 0x4d 0x44 0x33 0x30 0x30 0x30 
Mar 11 10:41:17 epi3 kernel: VMWARE: Unique Device attached as scsi disk sdb at scsi2, channel 0, id 0, lun 0
Mar 11 10:41:17 epi3 kernel: Attached scsi disk sdb at scsi2, channel 0, id 0, lun 0
Mar 11 10:41:17 epi3 kernel: scan_scsis starting finish
Mar 11 10:41:17 epi3 kernel: SCSI device sdb: 3509329920 512-byte hdwr sectors (1797751 MB)
Mar 11 10:41:17 epi3 kernel:  sdb: sdb1
Mar 11 10:41:17 epi3 kernel: scan_scsis done with finish
Mar 11 10:41:17 epi3 kernel: scsi singledevice 2 0 0 1
Mar 11 10:41:17 epi3 kernel:   Vendor: DELL      Model: MD3000i           Rev: 0735
Mar 11 10:41:17 epi3 kernel:   Type:   Direct-Access                      ANSI SCSI revision: 05
Mar 11 10:41:18 epi3 kernel: VMWARE SCSI Id: Supported VPD pages for sdc : 0x0 0x80 0x83 0x85 0x86 0x87 0xc0 0xc1 0xc2 0xc3 0xc4 0xc8 0xc9 0xca 0xd0 
Mar 11 10:41:18 epi3 kernel: VMWARE SCSI Id: Device id info for sdc: 0x1 0x3 0x0 0x10 0x60 0x1 0xe4 0xf0 0x0 0x1a 0x1a 0x86 0x0 0x0 0xd 0xb7 0x4d 0x75 0xf2 0x77 0x53 0x98 0x0 0x54 0x69 0x71 0x6e 0x2e 0x31 0x39 0x38 0x34 0x2d 0x30 0x35 0x2e 0x63 0x6f 0x6d 0x2e 0x64 0x65 0x6c 0x6c 0x3a 0x70 0x6f 0x77 0x65 0x72 0x76 0x61 0x75 0x6c 0x74 0x2e 0x36 0x30 0x30 0x31 0x65 0x34 0x66 0x30 0x30 0x30 0x31 0x61 0x31 0x61 0x61 0x32 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x34 0x37 0x39 0x30 0x36 0x32 0x32 0x65 0x2c 0x74 0x2c 0x30 0x78 0x30 0x30 0x30 0x31 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x32 0x0 0x0 0x0 0x51 0x94 0x0 0x4 0x0 0x0 0x80 0x1 0x53 0xa8 0x0 0x44 0x69 0x71 0x6e 0x2e 0x31 0x39 0x38 0x34 0x2d 0x30 0x35 0x2e 0x63 0x6f 0x6d 0x2e 0x64 0x65 0x6c 0x6c 0x3a 0x70 0x6f 0x77 0x65 0x72 0x76 0x61 0x75 0x6c 0x74 0x2e 0x36 0x30 0x30 0x31 0x65 0x34 0x66 0x30 0x30 0x30 0x31 0x61 0x31 0x61 0x61 0x32 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x34 0x37 0x39 0x30 0x36 0x32 0x32 0x65 0x0 0x0 0x0 0x0 
Mar 11 10:41:18 epi3 kernel: VMWARE SCSI Id: Id for sdc 0x60 0x01 0xe4 0xf0 0x00 0x1a 0x1a 0x86 0x00 0x00 0x0d 0xb7 0x4d 0x75 0xf2 0x77 0x4d 0x44 0x33 0x30 0x30 0x30 
Mar 11 10:41:18 epi3 kernel: VMWARE: Unique Device attached as scsi disk sdc at scsi2, channel 0, id 0, lun 1
Mar 11 10:41:18 epi3 kernel: Attached scsi disk sdc at scsi2, channel 0, id 0, lun 1
Mar 11 10:41:18 epi3 kernel: scan_scsis starting finish
Mar 11 10:41:18 epi3 kernel: SCSI device sdc: 3509329920 512-byte hdwr sectors (1797751 MB)
Mar 11 10:41:18 epi3 kernel:  sdc: sdc1
Mar 11 10:41:18 epi3 kernel: scan_scsis done with finish
Mar 11 10:41:18 epi3 kernel: scsi1: remove-single-device 0 0 0 failed, device busy(4).
Mar 11 10:41:18 epi3 kernel: scsi singledevice 1 0 0 0

Coisas que tentei:

1. Remover os alvos iSCSI de apenas 103, desabilitando o iSCSI, reinicializando, habilitado iSCSI, adicionando novamente os destinos e verificando novamente. Mesmo resultado.
2. Removendo a partição em 102, partição formatada em 103. Mesmo resultado, exceto invertido. 103 pode usar o armazenamento, 102 não pode.
3. Começar de novo. Removendo todos os iSCSI Targets em ambas as ESX Boxes, desabilitando o iSCSI, desligando o firewall para iSCSI, reinicializando o ESX. Em seguida, no MD3000, Removido o Grupo de Host, Removido o Mapeamento do Host para Virtual, Reiniciando a SAN. Seguiu a Documentação novamente, mesmo resultado. Ambos os servidores veem o armazenamento, mas apenas um servidor pode usá-lo.
4. Desativando e reativando o VMware DRS e o HA. O mesmo resultado.
5. Desativando o VMware DRS e o HA, e fazendo a etapa de "iniciar novamente" para ver se talvez isso funcionava. Mesmo resultado.

Eu meio que estou perdendo a cabeça aqui, Tudo que eu leio online diz "apenas particione e se as caixas do ESX puderem ver os alvos, simplesmente funciona" .... bem, porcaria.

Alguma ideia, alguma outra coisa para tentar? Alguém pode pelo menos me apontar na direção certa? Estou muito cansado de trabalhar de 1h às 4h (nossas horas de manutenção)

    

Answer 1

Não é uma ótima resposta, mas resolvemos o problema.

Parece que nosso servidor "EPI2" estava pirando de alguma forma que se recusou a compartilhar seu armazenamento.

Uma vez que eu removi o EPI2 do cluster e fiz a varredura usando EPI1 (ESX4.1) e EPI3 (ESX3.5) encontrei e montei o armazenamento adequadamente.

Como o EPI2 causou esses problemas, decidimos migrar todos os virtuais e atualizá-lo para o 4.1.

Desde a atualização, não tivemos problemas, todas as três caixas ESX veem o armazenamento e o compartilham corretamente.

Obrigado a todos pela sua ajuda.

    

Answer 2

Eu sinto sua dor ... Eu batalhei com o ESX e o iSCSI várias vezes no ano passado.

Não tenho certeza, mas você pode estar se deparando com um problema devido ao tamanho do armazenamento de dados resultante. Há um limite de 2 TB para um iSCSI LUN, o que é bom, já que você o dividiu em dois LUNs de 1,6 TB.

Gostaria de saber se o epi3 não pode carregar o armazenamento de dados porque acredita que seja um tamanho inválido.

Você já tentou carregar cada lun como seu próprio armazenamento de dados para ver se os hosts podem vê-los corretamente dessa maneira?

    

Answer 3

Parece que é permitido acesso iSCSI, mas não leitura / gravação ... Isso foi feito?

Select “Yes: This host will share access to the same virtual disks with other hosts”

(de link )

EDIT: Para eliminar o ESX como sendo o problema, você pode colocar o segundo ESX em um grupo de hosts separado e atribuir a esse grupo de host um lun? Além disso, vi algumas postagens antigas em que, se o nome do iniciador tivesse mais de 31 caracteres, a caixa do ESX não se conectaria. Pelo que vejo nas suas capturas de tela, e supondo que elas consertaram isso, você deve ficar bem. Apenas pensei que valeu a pena mencionar aqui.

    

Answer 4

O tamanho de um disco iSCSI está limitado a 2 TB. link Parece que você está ultrapassando esse limite tentando estender esses dois TB de 1,6 TB LUNS.

Essas postagens podem ser semelhantes no site da VMware.

1) link Não é possível reconhecer as unidades de armazenamento do servidor ESX 3.5 2) link LUN não está montado.