Назад | Перейти на главную страницу

Кластер ESX3.5 и MD3000i - оба сервера видят цели iSCSI, только один сервер может использовать раздел

Хорошо. Прежде всего, Предупреждение. Это более серьезный вопрос. Мне нравится быть внимательным и стараться исключить все возможные ответы "легкого режима", а также дать всем почувствовать, что я пробовал. Я включил несколько изображений нашей установки и проблемы, с которой она связана.

Версия TL; DR: Итак, я следовал руководствам, расположенным здесь: Руководство по развертыванию ESX V1 Это руководство, которое Dell прислала мне по настройке двух серверов ESX3.5, на которых устанавливается Dell MD3000i. Не работает. Оба сервера не могут использовать один и тот же раздел хранения на MD3000. Оба сервера видят его, но только один сервер может его использовать. (этим сервером является тот сервер, который создал раздел на целевом сервере.) Оба сервера ESX являются членами группы хостов.

Полная версия

У меня есть 2 сервера ESX3.5 (10.0.7.102, также называемый EPI2 и 10.0.7.103, также называемый EPI3.), Подключенных к устройству iSCSI SAN (Dell MD3000i). Оба сервера ESX могут «сканировать» SAN и видеть LUNS.

Часть первая: хранилище MD3000i

На MD3000i оба сервера находятся в моей группе хостов.

У меня есть два раздела, VM1 и VM2, оба по 1,6 ТБ (vmware не любит ничего сверх 2 ТБ.)

И вы даже можете видеть, что серверы ESX отлично нацелены на MD3000.

Часть вторая: серверы ESX

Фигура 1.

Итак, как вы можете видеть выше, оба сервера ESX (10.0.7.102 и 10.0.7.103) могут видеть и сканировать MD3000i SAN.
Фигура 2.

Выше - хранилище, которое видят оба сервера. Я создал раздел хранения на EPI2 (102). Затем я расширил раздел, включив в него второй LUN, получив в общей сложности 3,27 ТБ памяти.

Когда я выполняю «повторное сканирование» на 103 (сервер не монтирует раздел), я получаю следующий журнал / сообщения. 11 марта 10:41:18 ядро ​​epi3: scsi1: remove-single-device 0 0 0 не удалось, устройство занято (4). единственная линия, которая привлекает мое внимание. (EPI3 - это имя сервера)

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

Вещи, которые я пробовал:

  1. Удаление целей iSCSI только из 103, отключение iSCSI, перезагрузка, включение iSCSI, повторное добавление целей, повторное сканирование. Тот же результат.
  2. Удаление раздела на 102, вместо этого отформатированный раздел на 103. Тот же результат, кроме перевернутого. 103 может использовать хранилище, 102 не может.
  3. Начать сначала. Удаление всех целей iSCSI на обоих блоках ESX, отключение iSCSI, отключение брандмауэра для iSCSI, перезагрузка ESX. Затем на MD3000 удалили группу хостов, удалили сопоставления хостов и виртуальных машин, перезапустили SAN. Снова последовал за документацией, результат тот же. Оба сервера видят хранилище, но использовать его может только один сервер.
  4. Отключение и повторное включение VMware DRS и HA. Тот же результат.
  5. Полное отключение VMware DRS и HA и выполнение шага «начать заново», чтобы посмотреть, не сработало ли это. Тот же результат.

Я тут как бы схожу с ума. Все, что я читаю в Интернете, гласит: «Просто разбейте его на части, и если блоки ESX могут видеть цели, это просто работает» ... ну, черт.

Есть идеи, что еще можно попробовать? Может ли кто-нибудь указать мне хотя бы в правильном направлении? Я действительно устал работать с 1 до 4 утра (наши часы обслуживания)

Это не лучший ответ, но мы решили проблему.

Похоже, что наш сервер "EPI2" каким-то образом испугался, отказавшись поделиться своим хранилищем.

После того, как я удалил EPI2 из кластера и повторно просканировал с использованием EPI1 (ESX4.1) и EPI3 (ESX3.5), я нашел и правильно смонтировал хранилище.

Поскольку эти проблемы вызывал EPI2, мы решили перенести с него все виртуальные машины и обновить до 4.1.

С момента обновления у нас не было проблем, все 3 бокса ESX видят хранилище и правильно его используют.

Спасибо всем за вашу помощь.

Похоже, доступ iSCSI разрешен, но нет чтения / записи ... Это было сделано?

Выберите «Да: этот хост будет предоставлять доступ к одним и тем же виртуальным дискам другим хостам».

(из http://www.dell.com/downloads/global/solutions/pvault_esx_storage_deployment_guide_v1.pdf)

РЕДАКТИРОВАТЬ: Чтобы исключить ESX как проблему, можете ли вы поместить второй ESX в отдельную группу хостов и назначить этой группе хостов lun? Кроме того, я видел несколько старых сообщений, в которых, если имя инициатора было длиннее 31 символа, блок ESX не подключался. Судя по тому, что я вижу на ваших скриншотах, и если они исправят это, с вами все будет в порядке. Просто подумал, что стоит упомянуть здесь.

Я чувствую вашу боль .... Я несколько раз сражался с ESX и iSCSI за последний год.

Я не уверен, но вы можете столкнуться с проблемой из-за размера полученного хранилища данных. Для iSCSI LUN есть ограничение в 2 ТБ, и это нормально, поскольку вы разделили его на два LUN по 1,6 ТБ.

Интересно, не может ли epi3 загрузить хранилище данных, потому что считает его недопустимым размером.

Вы пробовали загружать каждый lun как собственное хранилище данных, чтобы увидеть, могут ли хосты правильно их видеть?

Размер диска iSCSI ограничен 2 ТБ. http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_config_max.pdf Похоже, вы превысили этот предел, пытаясь расширить эти два LUNS по 1,6 ТБ.

Это могут быть похожие сообщения на сайте VMware.

1) http://communities.vmware.com/message/1323224 Не удается распознать логические файлы хранилища с сервера ESX 3.5 2) http://communities.vmware.com/thread/71152 LUN не монтируется.