☰

ESX3.5 集群和 MD3000i - 两台服务器都可以看到 iSCSI 目标，只有一台服务器可以使用分区

tag-icon • tag-icon dell iscsi dell-powervault vmware-esx
ESX3.5 集群和 MD3000i - 两台服务器都可以看到 iSCSI 目标，只有一台服务器可以使用分区

好吧。首先，警告。这是一个比正常问题更大的问题。我喜欢彻底解决，并尝试排除所有可能的“简单模式”答案，并让每个人都感受一下我尝试过的方法。我附上了几张我们的设置和它遇到的问题的图片。

TLDR 版本： 因此我遵循了此处的指南：ESX 部署指南 V1 这是戴尔发给我的指南，用于设置两个安装有戴尔 MD3000i 的 ESX3.5 服务器。它不起作用。两个服务器不能使用 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.6TB（vmware 不喜欢超过 2TB 的任何东西。） 在此处输入图片描述

您甚至可以看到 ESX 服务器完美地瞄准了 MD3000。在此处输入图片描述

第二部分：ESX 服务器

扫描md3000 图1。

因此，如上所示，两个 ESX 服务器 (10.0.7.102 和 10.0.7.103) 均能够查看和扫描 MD3000i SAN。
Vmware 上的存储 图 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 盒上的所有 iSCSI 目标，禁用 iSCSI，关闭 iSCSI 防火墙，重新启动 ESX。然后在 MD3000 上，删除主机组，删除主机到虚拟映射，重新启动 SAN。再次按照文档操作，结果相同。两个服务器都可以看到存储，但只有一个服务器可以使用它。
  4. 禁用并重新启用 VMware DRS 和 HA。结果相同。
  5. 彻底关闭 VMware DRS 和 HA，然后执行“重新开始”步骤，看看是否会导致问题。结果相同。

我有点失去理智了，我在网上看到的所有内容都说“只需对其进行分区，如果 ESX 框可以看到目标，它就可以工作”......好吧，废话。

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

答案1

我理解你的痛苦......在过去的一年里我多次与 ESX 和 iSCSI 斗争。

我不确定，但您可能会遇到由生成的数据存储大小引起的问题。iSCSI LUN 的限制为 2TB，这没问题，因为您已将其拆分为两个 1.6 TB 的 LUN。

我想知道 epi3 是否无法加载数据存储，因为它认为它的大小无效。

您是否尝试过将每个 lun 加载为其自己的数据存储，以查看主机是否可以通过这种方式正确看到它们？

答案2

似乎允许 iSCSI 访问但不允许读/写...这已经完成了吗？

选择“是：此主机将与其他主机共享对同一虚拟磁盘的访问权限”

（从http://www.dell.com/downloads/global/solutions/pvault_esx_storage_deployment_guide_v1.pdf）

编辑：为了消除 ESX 问题，您可以将第二个 ESX 放在单独的主机组中，并为该主机组分配一个 LUN 吗？此外，我看到一些旧帖子，如果启动器名称超过 31 个字符，ESX 框将无法连接。从我在您的屏幕截图上看到的情况来看，假设他们已经修复了这个问题，您应该没问题。只是觉得值得在这里提一下。

答案3

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

看来我们的“EPI2”服务器出现了某种问题，拒绝共享其存储。

一旦我从集群中移除 EPI2 并使用 EPI1（ESX4.1）和 EPI3（ESX3.5）重新扫描，两者都会正确找到并安装存储。

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

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

感谢大家的帮助。

答案4

iSCSI 磁盘的大小限制为 2 TB。http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_config_max.pdf看起来您在尝试扩展这两个 1.6 TB 的 LUN 时超出了此限制。

这些可能是 VMware 网站上的类似帖子。

1）http://communities.vmware.com/message/1323224无法识别 ESX 3.5 服务器 2 的存储 LUNhttp://communities.vmware.com/thread/71152LUN 未安装。

相关内容