我们有一个连接到ESX服务器集群的iSCSI SAN单元。 这些服务器全部由vCenter实例pipe理。 vCenter实例pipe理一打Windows Server虚拟机。
大多数虚拟机具有多个卷。 这些卷显示在vCenter中的VM设置中。 Windows中的驱动器C在vCenter中显示为硬盘1。 驱动器D显示为硬盘2，依此类推。 换句话说，SAN是从服务器混淆的。
但是，一台服务器configuration不同。 其C驱动器由vCenter处理，但其第二卷通过Windows iSCSI Initiator直接连接到SAN。 当我问服务器pipe理员为什么这样configuration时，他问：“你为什么要一个中间人处理你的卷？ 我试图解释说，vCenter的HA和Snapshotfunction将不会涵盖第二卷，但他仍然不相信。
我仍然不信任。 尽pipe虚拟机的所有卷似乎都应该由vCenter来处理，但我可能是错的。 你有没有以类似的方式configuration你的虚拟机？ 启动磁盘由vCenter提供给VM，但所有其他卷都直接连接到SAN？
是。
有时候人们这样做 。 原因可能包括：
对于这些直接连接的卷，vSphere将无法进行快照或实际上做得太多。 除非绝对必要，否则我不是这样做的倡导者。 这会造成混淆，使networkingdevise复杂化，灾难恢复很lesslogging在案。
我曾经在一个特定的客户端在900个虚拟机中的每一个上做这个工作。 从多个SANarrays直接向虚拟机而不是VMDK提供CIFS，iSCSI，NFS的可怕组合。
我们目前有一个类似的文件服务器configuration。 启动驱动器和其他几个是通过VMWare和数据驱动器是一个直接的iSCSI连接。 之前configuration的方式是为了克服VMWare硬盘的2TB限制。 是的，vCenter的快照和HA的function将不会适用于该卷，因为它直接提供给服务器。 这对我们来说工作得很好，因为SAN的快照覆盖了“驱动器”。
至于pipe理员提出的中间人的评论，我不得不说，性能没有问题，没有理由不利用快照和HAfunction。 本文特别表明，pipe理程序的存储开销很小。 在发送到集中存储器时，您的瓶颈将不是虚拟机pipe理程序，而是将主机连接到存储设备（光纤，以太网等）的媒介，并超越了驱动器和控制器本身。 我只能看到虚拟机pipe理程序成为一个瓶颈，就是如果你使用虚拟分配的资源来重载虚拟机，而不是虚拟机的虚拟机一次调用它们。 如果您确信虚拟机pipe理程序会导致性能问题，则可以使用直接设备映射。 如果你花一些时间来search它们，那么有关于存储和VMWare性能的多个案例研究。
就我个人而言，使用VMWare来pipe理存储没有任何问题，尤其是在版本5.5和存储的新限制方面。 希望这可以帮助。