Josh博客原文

在这一部分中，我们将介绍每个产品写操作的I / O路径，这里的写操作是带镜像的（也称为vSAN的FTT1和Nutanix的RF2）。

我将发布部署软件定义的存储“In-Kernel”与“控制器VM”之间的单独详细比较，本文将重点介绍流量如何穿越和利用集群。

假设针对vSAN和Nutanix ADSF的全新4节点集群以及具有600GB虚拟磁盘的单个VM。 选择600GB的值有两个原因。

1. 我在本文档后面引用的VMware文章使用了这种大小

2. 600GB表示vSAN将磁盘拆分为多个对象，这对vSAN有利（<255GB表示单个对象）。

从vSAN开始讲起:

The objects will be placed on the node where the VM is hosted and on a single other node as shown below. (Screenshot courtesy of URL below).

由于255GB的对象大小限制，vSAN会将vDisk分成3个对象。 这意味着我们将有3个对象和3个副本以及一个见证（witness）。

对象将放置在托管VM的节点上，同时放置在另一个节点上，如下所示。 （屏幕截图由下面的URL提供）。

Reference: https://storagehub.vmware.com/t/vsan-6-7-update-1-technical-overview/vsan-objects-and-component-placement-3/

vSAN 写路径总结:

在最佳情况下，如果VM尚未从其被创建的主机上移走，或者已移回到原始主机上，则一次写入将写入本地对象，另一次写入将写入远程对象。

场景1：vSAN

如果VM是手动或通过DRS进行vMotion操作的，则如果偶然驻留在节点2上，则其最佳写入路径将如下所示。

场景2：vSAN

如果VM位于没有任何对象托管的主机上（4节点群集中有50％的机会），则所有写入操作都将通过网络远程执行，就像在传统SAN环境中一样，如下所示。

场景3：vSAN有点难

这些情况突显出，即使我们接受vSAN的“内核”架构是最理想（或最短）的IO路径，但在IO处于远程的情况下，可以说消除了理论上的优势。

让我们更深入地研究一下VM在集群中的移动情况（通常情况下）。

让我们用一个简单的示例说明两个VM，它们是由于维护或DRS平衡群集而移动的。 他们每个都最终驻留于一个不承载任何对象的节点上。 IO路径如何查找这些VM？

下图突出显示了问题，我们现在有两个VM，它们的100％的写入I / O都在远程进行。 更糟的是，节点1和节点3上的网络流量都正在服务于2个远程写

场景4：vSAN糟糕了

如前所述，随着群集的增长，VM托管在其对象所在位置的机会减少，因此这种情况变得越来越有可能给环境带来不必要的资源开销。

如果为环境配置了容错2（FFT2），则100％远程VM IO的开销也会增加。

场景5：vSAN

假设VM处于运维状态被vmotion或者DRS移动到了恰好具有该VM对象数据副本的节点，则它会有较理想的数据本地化写IO操作，但随着集群规模增大，数据本地化极具偶然性。4节点集群，这样的偶然性为50%，8节点集群下降到了25%，32节点集群只有6.25%。因此在VM维护期间，大多数写I/O都是跨网络执行的，这会导致与其他VM的争用。

vSAN写I/O路径总结：

“扩展阅读”： 将 vSAN 群集的成员置于维护模式时，有3种数据撤出模式，其中“确保可访问性” 为默认选项。在关闭主机电源或将主机从群集中移除时，vSAN 将确保此主机上的所有可访问的虚拟机均保持可访问状态。如果要将主机暂时移出群集（例如，为了安装升级）并计划将主机移回群集中，请选择此选项。如果要将主机从群集中永久移除，则此选项不适用。通常，只需撤出部分数据。但是，撤出期间，虚拟机可能不再完全符合虚拟机存储策略。这意味着它可能无权访问其所有副本。如果在主机处于维护模式且允许的故障数主要级别设置为1时出现故障，群集可能会出现数据丢失的情况。

REFERENCE:HTTPS://DOCS.VMWARE.COM/EN/VMWARE-VSPHERE/6.7/COM.VMWARE.VSPHERE.VIRTUALSAN.DOC/GUID-521EA4BC-E411-47D4-899A-5E0264469866.HTML

我同意Duncan对vSAN的建议，并且上述维护场景中的数据面临风险，这凸显了vSAN上对FFT2的需求。注意：默认情况下，Nutanix ADSF始终通过RF2（FTT1）保持写入I / O完整性，这是ADSF的主要容量，弹性和性能优势。

我将在以后的文章中介绍更多重要的弹性考虑因素。

让我们再来看一下Nutanix ADSF：

假设与vSAN上的VM配置相同，一个600GBvdisk。Nutanix ADSF没有对象的概念。所有数据不管有多少vdisk被分割成1MB和4MB的extent group。

VM的所有的写操作，都会保持1份数据在该VM所在的本地节点，另一份数据分布到集群的其他节点。

Nutanix正在写路径中提供容量效率和性能。

接下来让我们讨论下将VM从节点1迁移到节点2时的情况。

在所有情况下，我们仍然可以看到，有一个副本被写入运行VM的主机，另一个副本被写入并分布在整个集群中。

即使在vMotion之后，Nutanix仍继续在写入路径中提供容量效率和性能。

现在，将vMotion VM移至节点3。

在vm被第二次vmotion到节点3时，仍然保证一份数据本地写，一份数据智能分布在集群其他节点。

现在让我们将VM vmotion回其原来的节点。

结果是7个数据中有4个是在本地的，3个是在远程节点的，如果远程节点数据被访问，就会被本地化。如果从未访问过它，那么它将保持远程，不会对vm性能产生影响。

这里的关键点是，不管VM移动到哪里，写路径总是在本地写一个副本，在远程写一个副本，从而提供一致的写性能。

写路径还使用了智能数据副本放置，以确保集群尽可能地平衡。从这个简单的示例中可以看到，节点有3或4个数据片段，所有节点以分布式方式参与写IO。

What about the scenario I highlighted with vSAN where two VMs are moved to hosts they were not created on?

Nutanix ADSF写IO路径总结：

无论VM/s在集群中的什么位置，写路径都是相同的。一个副本被写入运行VM的节点，第二个(RF3的情况下是第三个)副本智能地分布在整个集群中。一致性是关键，这也正是Nutanix数据本地化为写I/Os提供的独特性。

一致性是关键，而这正是Nutanix独特的Data Locality为写入I / O提供的功能。

Nutanix不执行数据本地化的场景？

1. 如果本地节点已满

2. 如果本地节点CVM不可用

3. 覆盖overwrite(“就地”完成)

在前两种情况下，所有写和读I/O都是远程的。

对于覆盖overwrite，仍然在本地向oplog写入随机I/O以获得最佳性能。当IO被耗尽到extent存储时，该操作在本地或远程执行。如果被覆盖的数据被读取，它将被本地化，以实现未来最优的覆盖(和读取)操作。

简而言之，对于Nutanix ADSF，最坏的情况（所有IO远程）是vSAN的典型情况。

由于计划的维护（例如AOS升级），CVM可能不可用。 万一CVM意外脱机，VM会继续运行，并且IO将被远程提供服务，但是关键的智能副本放置仍然适用。 CVM重新联机后，将恢复最佳写入路径。

接下来，我们将介绍vSAN和Nutanix ADSF的读取I / O路径。

总结：

1. vsan的写入路径会因VM在集群中位置的变化而变化很大，在VM迁移发生时，很大的几率为远程IO读写。
2. vSAN静态、基于对象的写路径不允许在维护期间保护写进来的IO
3. Nutanix ADSF总是基于所配置的存储策略(弹性因素)维护写I/O的完整性。
4. Nutanix ADSF提供了一致的写IO路径，而无需考虑VM会驻留在哪个节点或被移动到的集群中位置。
5. Nutanix ADSF 写I/O最坏的情况是仅在维护或CVM故障期间才远程发送两个写副本，而这个最坏情况确是vSAN的常见的写IO场景。
6. Nutanix ADSF数据本地化是机制的设计；vSAN的数据本地化极具偶然性。