问VMWare，虚拟磁盘，windows软件raid

EN

容错将是一样的，但我认为与在主机上执行RAID1相比，您的性能和可管理性将受到影响，特别是如果您有任何其他VM使用相同的磁盘。

首先，在客户中执行软件RAID将消耗客户的一些CPU片，如果您曾经有CPU争用，那么它将破坏该来宾的磁盘性能。

其次，磁盘争用的问题将因以下事实而更加复杂:您的Windows将在主机逻辑磁盘级别上与(大概)两倍数量的VM竞争--一组用于主机逻辑磁盘1的VM，另一组用于主机逻辑磁盘2的VM。如果一个VM在任何一个磁盘上都处于磁盘饥渴状态，您的在客RAID1性能将受到影响。当然，如果您在主机级别进行RAID，也会发生这种情况，但是这样会更容易预测，并且您可以更容易地确定要移动到另一组磁盘上的客户。在客人内部执行RAID意味着可管理性将是可怕的，因为您试图平衡您的其他VM，这样他们就不会扼杀在客人中的RAID的性能。

第三，如果使用扩展的VMDK(即，未预先分配)，则必须处理物理磁盘上的不同碎片模式。一个VMDK可能在某一组物理磁盘区段中被分段，而另一个VMDK则在不同的物理磁盘区段中被分段，因为据推测，不同VM的虚拟磁盘跨越不同的物理磁盘区段。以一个简单的例子为例，其中每个字母都是来宾的名称，每个letter+number都是该VMDK使用的物理磁盘范围的开始：

A1-A2B2A3B3

C1-A1-C2-A2-C3-A3

在客镜像的磁盘性能将归结为最糟糕的两个物理磁盘布局。另一方面，来宾镜像的物理磁盘访问模式也会影响两个磁盘上其他来宾的性能。如果要在主机级别镜像磁盘，则两个磁盘上的磁盘布局和碎片将是相同的，直到设备，性能才会更可预测。

如果您运气不好，同时存在CPU争用和磁盘争用，那么运行您的内置RAID1的客户将陷入一个令人难以忍受的停顿--更不用说，所有其他竞争同一个CPU片和磁盘I/O的客人了。

因此，如果您不能在主机级别上购买RAID，我至少会尽量减少磁盘争用的可能性，方法是确保物理磁盘仅由运行RAID的单个来宾使用--换句话说，不要让任何其他客人使用这些数据存储。(您甚至可能希望将原始磁盘添加到来宾中，而不是使用VMDK。)这样，您唯一关心的是CPU争用，您应该能够更好地管理这些争用。

你觉得这会给你带来什么好处？这两个虚拟磁盘会存储在同一个SAN/物理驱动器上吗？

如果他们是在同一物理驱动器上的虚拟dists，确实没有任何好处的可靠性立场，这将降低性能。

性能不应比本机显示相同磁盘的性能差得多。一般情况下，这不是我想要做的事情，但是如果你没有选择一个好的硬件RAID，那么我看不出为什么不行。

这是假设两个VMDK存储在两个单独的物理磁盘上。如果两个VMDK位于一个数据存储上，那么就没有多大意义了。

在可伸缩性POV中，您可以使用这种方法来克服VMware的2TBVMDK限制--这确实解决了您的另一个问题，这是一个更可扩展的解决方案，因为in可以用于在Windows中启用卷>2TB，但除非考虑RAID 0，否则不能使用两个磁盘。

从容错的角度来看，这同样取决于场景。如果您的VMware数据存储下只有一个磁盘，那么这是更容错的，但是通常，如果您能够帮助它，就不应该有这样脆弱的数据存储。

就可管理性而言，在小规模上没有什么大不了的。