vCenter只处理引导卷？

Question

我们有一个连接到ESX服务器集群的iSCSI SAN单元。服务器都由vCenter的一个实例管理。vCenter实例管理十几个。

大多数VM都有多个卷。这些卷出现在vCenter中的VM设置中。Windows中的驱动器C在vCenter中显示为硬盘1。驱动器D显示为硬盘2，以此类推。换句话说，SAN被服务器混淆了。

但是，一台服务器的配置方式不同。它的C驱动器由vCenter处理，但它的第二个卷通过Windows iSCSI启动器直接连接到SAN。当我问服务器管理员为什么要这样配置它时，他问：“为什么要一个中间人来处理您的卷呢？”我试图解释，vCenter的HA和快照功能不会涵盖第二卷，但他仍然不相信。

我也不相信。虽然似乎所有VM的卷都应该由vCenter处理，但我可能错了。您是否以类似的方式配置您的VM？引导磁盘是由vCenter提供给VM的，但是所有其他卷都直接连接到SAN？

Answer 1

是。

有时候人们会这么做。理由可能包括：

• SAN/存储性能。
• 需要一个体积，其大小要求超过VMFS可用的最大值。
• 在比VMware更高的层次上进行的聚类。

vSphere无法对这些直接附加的卷进行快照或实际操作。除非绝对必要，否则我不主张这样做。它造成混乱和复杂的网络设计，DR和很少有文档。

我在一个环境中工作，其中一个特定的客户端在他们的900台虚拟机中的每一台上都这样做。CIFS、iSCSI、NFS从多个SAN数组直接呈现给VM，而不是VMDK，这是一个可怕的组合。

Answer 2

我们目前有一个以类似方式配置的文件服务器。引导驱动器和其他几个驱动器都是通过VMWare进行的，数据驱动器是一个直接的iSCSI连接。它以前是以这种方式配置的，以克服VMWare中硬盘驱动器的2TB限制。是的，vCenter快照和HA的特性不适用于该卷，因为它直接呈现给服务器。这对我们来说很好，因为SAN上的快照覆盖了“驱动器”。

至于管理员的中间人评论，我不得不说，性能没有问题，也没有理由不利用快照和HA功能。特别是这篇文章表明管理程序的存储开销是最小的。当发送到集中存储时，您的瓶颈将不是虚拟机监控程序，而是连接主机到存储的介质(光纤、以太网等)。过去，驱动器和控制器本身。我唯一能看到虚拟机管理程序成为瓶颈的情况是，如果您已经在主机上重载了比实际分配的资源更多的资源，并且所有VM都同时调用了这些资源，那么它就会成为瓶颈。如果您确信虚拟机管理程序会导致性能问题，则可以使用直接的设备映射。如果您花一些时间搜索它们，就会有多个关于存储和VMWare性能的案例研究。

就我个人而言，我没有遇到使用VMWare来管理存储的问题，特别是使用5.5版和新的存储限制。希望这能有所帮助。