Virtual SAN 和数据局部性/重心

原文：http://www.yellow-bricks.com/2013/09/30/virtual-san-data-locality/

注明：本文内容基于 VMware VSAN beta 版本撰写，请访问http://www.vmware.com/products/virtual-san/获得有关正式版本的更新信息。

      前些时候，我读了 Michael Webster 写的一篇有关巨帧优势的文章。Michael 从 IOPS 和延迟两个角度，测试了运行巨帧和非巨帧产生的影响。Michael 发现巨帧具有显著的优势：

• IOPS 更高

• 延迟更短

• CPU 利用率更低

      我强烈推荐您阅读 Michael 的全文来了解详细信息，我可不想抢了他的风头。我在下面引用了那篇文章中最有意思的部分，我很敬重 Michael，他很聪明，他的发现通常是准确无误的：

      我听说有些人一直在测试 VSAN，但是当他们在主机间的 10G 网络中使用巨帧时，并没有发现性能上有什么明显的改进。尽管我的实验室中还没有 VSAN，但是我认为造成这种现象的原因在于网络并不是 VSAN 的瓶颈。在VSAN 环境中，大多数存储访问都是在本地完成的，只有复制流量和数据移动时所需的流量才会在 VSAN 主机间的网络中进行。

     

      正如我前面所说的，Michael 是一个聪明人，我之前听到过各路人马探讨这个问题，所以我认为 VSAN 环境下大多数IO 都是本地的，倒也不是什么的标新立异的假设，我想这大概是一种 Nutanix 模型。但是VSAN 并非 Nutanix。VSAN 采用的是一种完全不同的方法，认识到这一点是至关重要的。

      我想如果 Michael 使用了一个非常小的群集（只有 3 个节点），那么他认为 IO 是本地的这种可能性会更大。然而即使如此，由于数据镜像，IO 也至少有 50% 不是本地的（允许的故障数目设置为 1 时）。那么VSAN 是如何进行处理的呢？需要牢记哪些注意事项呢？让我们先从 VSAN 的一些原则谈起：

• Virtual     SAN 使用了一种“对象模型”，这些对象存储在一个或多个磁盘和主机中。

• Virtual     SAN 主机能够远程访问“对象”，并执行读写功能。

• Virtual     SAN 中不存在数据局部性/重心的概念，这意味着，对象不会随虚拟机移动，因为从资源的角度来说移动数据的成本是很高的。

• Virtual     SAN 具有从多个镜像副本读取的功能，这意味着，如果有 2 个镜像副本，那么 IO 会平均分配。

      这是什么意思呢？首先，假设您有一个包含 8 台主机的 VSAN 群集。您配置了一个可用性策略：N+1。也就是说，对象（虚拟磁盘）会至少放在两台主机上。那么从内存和 CPU 的角度来看，应该将虚拟机存放在哪里呢？它可能位于 8 台主机的任何一台主机上。由于至少每 5 分钟调用一次DRS，因此，虚拟机（从 CPU/内存角度说）更有可能位于 6 台主机中不存放对象（虚拟磁盘）的主机上。换句话说，有可能远程执行 I/O（读取和写入）。

      我想从 I/O 路径角度重申一点，那就是两个镜像副本都可以并且也会处理 I/O，每个镜像副本会处理 ~50% 的 I/O。请注意，每台主机对于该镜像副本都有一个读取缓存，但是读取缓存中的块只会存储一次，这就意味着每台主机都会“拥有”一组块，并会为这些块提供数据，无论是来自缓存还是来自磁盘心轴。是不是很简单？

      想象一下，您已经配置好了“主机故障”策略并设置为 2。现在，I/O 可能至少来自 3 台主机。为什么要说“至少”呢？因为如果您配置了条带宽度，或者出于任何原因使条带分布在主机间（而不是磁盘间，在某些情况下是有可能分布在磁盘间的），则 I/O 可能来自更多的主机…所以我说 VSAN 堪称一种真正的完全分布式解决方案！下面的示例将“故障数目”设置为 1，并将“条带宽度”设置为 2，可以看到 3 台主机存放了对象。

      我们再重申一下。如果将“主机故障”定义为 1，并将条带宽度定义为 1，那么，VSAN 仍然可以在需要时在多个磁盘和主机间划分条带。“在需要时”是指在 VMDK 大小大于单个磁盘大小或类似情况时。

      现在，让我们回到一开始 Michael 自问的那个问题，使用巨帧有意义吗？Michael 的测试清楚地表明，使用巨帧是有意义的，在他的那个特定的场景下，这一点是毋庸置疑的。我不得不同意，(!!) 如果配置得当，尝试一下也无妨，问题在于，您是否总需要实施它呢？我想如果您能保证实施一致性，那么就可以像 Michael 那样去测试。看看它是否能给您带来好处，如果它可以缩短延迟，并提高 IOPS，那么我就有理由推荐您使用巨帧。

――――――――――――――――――――――――――――――――――――――――――――

作者： Duncan Epping

Duncan Epping 现任 VMware R&D 的 SDDC 新兴解决方案团队首席架构师。他主要负责挖掘现有产品和功能的新机会，并通过对新解决方案或产品进行原型开发来为 VMware 探索新的业务商机。他主要致力于软件定义的存储和业务连续性/灾难恢复解决方案，目前正在申请一项专利。