我们有一个 iSCSI SAN 单元连接到 ESX 服务器集群。这些服务器均由 vCenter 实例管理。vCenter 实例管理十几个 Windows Server VM。
大多数虚拟机都有多个卷。这些卷显示在 vCenter 中的虚拟机设置中。Windows 中的驱动器 C 在 vCenter 中显示为硬盘 1。驱动器 D 显示为硬盘 2，依此类推。换句话说，SAN 对服务器来说是模糊的。
然而，有一台服务器的配置有所不同。它的 C 盘由 vCenter 处理，但其第二个卷通过 Windows iSCSI Initiator 直接连接到 SAN。当我问服务器管理员为什么这样配置时，他问道：“你为什么要让中间人来处理你的卷？”我试图解释说 vCenter 的 HA 和快照功能不会覆盖第二个卷，但他仍然不相信。
我也仍然不相信。尽管它似乎就像所有虚拟机的卷都应该由 vCenter 处理一样，我可能错了。您是否以类似的方式配置了虚拟机？启动盘由 vCenter 呈现给虚拟机，但所有其他卷都直接连接到 SAN？
答案1
是的。
有时人们会这样做。原因可能包括：
- SAN/存储性能。
- 需要一个卷，其大小要求超出 VMFS 可用的最大值。
- 比 VMware 更高级别的集群。
vSphere 将无法对这些直接连接的卷进行快照或真正执行很多操作。除非绝对必要，否则我不提倡这样做。这会造成混乱并使网络设计和 DR 复杂化，而且很少有很好的记录。
我曾经在一个特定的客户这样做的环境中工作每一个他们的 900 台虚拟机之一。CIFS、iSCSI、NFS 的可怕混合从多个 SAN 阵列直接呈现到虚拟机而不是 VMDK。
答案2
我们目前有一个以类似方式配置的文件服务器。启动驱动器和其他几个驱动器通过 VMWare 连接，数据驱动器是直接 iSCSI 连接。它以前以这种方式配置，以克服 VMWare 中 2TB 的硬盘限制。是的，vCenter 的快照和 HA 功能不适用于该卷，因为它直接呈现给服务器。这对我们来说很有效，因为该“驱动器”由 SAN 上的快照覆盖。
至于管理员所作的中间人评论，我不得不说，性能没有问题，没有理由不利用快照和 HA 功能。 本文特别表明虚拟机管理程序的存储开销很小。当发送到集中式存储时，瓶颈不是虚拟机管理程序，而是将主机连接到存储的介质（光纤、以太网等...）以及驱动器和控制器本身。我唯一能看到虚拟机管理程序成为瓶颈的情况是，如果您使用比物理上更多的虚拟分配资源使主机过载，并且所有虚拟机同时调用它们。如果您完全确信虚拟机管理程序会导致性能问题，则可以使用直接设备映射。如果您花一些时间搜索它们，就会发现有多个关于存储和 VMWare 性能的案例研究。
就我个人而言，使用 VMWare 管理存储没有遇到任何问题，尤其是版本 5.5以及新的存储限制。希望这能有所帮助。