ESX3.5 Cluster & MD3000i -- 两台服务器都看到iSCSI Targets，只有一台服务器可以使用分区

Question

好吧。首先，警告。这是一个更重要的问题。我喜欢彻底并尝试消除所有可能的“easymode”答案，并让每个人都了解我尝试过的内容。我已经包含了我们设置的几张图片以及它遇到的问题..

TLDR 版本： 所以我遵循了位于此处的指南：ESX 部署指南 V1 这是戴尔发给我的指南，用于设置两台安装戴尔 MD3000i 的 ESX3.5 服务器。它不起作用。两台服务器不能在 MD3000 上使用相同的存储分区。两台服务器都看到它，但实际上只有一台服务器可以使用它。（该服务器是在目标上创建分区的任何服务器。）两个 ESX 服务器都是主机组的成员。

完整版本

我有 2 个 ESX3.5 服务器（10.0.7.102，也称为 EPI2，和 10.0.7.103，也称为 EPI3。）连接到 iSCSI SAN 设备（戴尔 MD3000i）。两个 ESX 服务器都可以“扫描”SAN 并查看 LUN。

第一部分：MD3000i 存储

在 MD3000i 上，两台服务器都在我的主机组中。

我有两个分区，VM1 和 VM2，都是 1.6TB（vmware 不喜欢超过 2tb 的任何东西。）

您甚至可以看到 ESX 服务器正以 MD3000 为目标。

第二部分：ESX 服务器

图1。

因此，如上所示，两个 ESX Server（10.0.7.102 和 10.0.7.103）都能够查看和扫描 MD3000i SAN。
图 2。

以上是两台服务器看到的存储。我在 EPI2 (102) 上创建了存储分区。然后我扩展了分区以包括第二个 LUN，总共 3.27 TB 的存储空间。

当我在 103（服务器未安装分区）上“重新扫描”时，我在日志/消息中得到以下日志。3 月 11 日 10:41:18 epi3 内核：scsi1：删除单个设备 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. 仅从 103 中删除 iSCSI 目标、禁用 iSCSI、重新启动、启用 iSCSI、重新添加目标、重新扫描。结果一样。
2. 删除 102 上的分区，改为 103 上的格式化分区。相同的结果，除了翻转。103可以使用存储，102不能。
3. 从头开始。删除两个 ESX Box 上的所有 iSCSI 目标，禁用 iSCSI，关闭 iSCSI 的防火墙，重新启动 ESX。然后在 MD3000 上，删除主机组，删除主机到虚拟映射，重新启动 SAN。再次遵循文档，结果相同。两台服务器都可以看到存储，但只有一台服务器可以使用它。
4. 禁用和重新启用 VMware DRS 和 HA。结果一样。
5. 彻底关闭 VMware DRS 和 HA，然后执行“重新开始”步骤，看看是否会令它厌烦。结果相同。

我在这里有点发疯，我在网上阅读的所有内容都说“只需对其进行分区，如果 ESX 盒可以看到目标，它就可以正常工作”....废话。

有什么想法，还有其他要尝试的事情吗？至少有人能指出我正确的方向吗？我真的厌倦了从凌晨 1 点工作到凌晨 4 点（我们的维护时间）

Answer 1

这不是一个很好的答案，但我们解决了问题。

看来我们的“EPI2”服务器以某种方式崩溃了，拒绝共享其存储。

当我从集群中删除 EPI2 并使用 EPI1 (ESX4.1) 和 EPI3 (ESX3.5) 重新扫描时，两者都找到并正确安装了存储。

由于 EPI2 引起了这些问题，我们决定迁移所有虚拟机并将其升级到 4.1。

自从升级以来，我们没有遇到任何问题，所有 3 个 ESX 盒子都能看到存储并正确共享它。

感谢大家的帮助。