Virtual SAN 和网络 IO 控制

原文：http://www.yellow-bricks.com/2013/10/29/virtual-san-network-io-control/

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

       自从我开始研究 Virtual SAN 以来，多多少少忽视了一项内容，那就是网络 IO 控制。但是，VirtualSAN 和网络 IO 控制应该是并驾齐驱的。（Distributed Switch 同样如此。）请注意，在使用 VSAN Beta 版时，也要使用Distributed Switch 和网络 IO 控制。我之所以忽略这项内容，是因为除此之外还有更多值得探讨的事情，但既然现在越来越多的人问及此事，我想现在应该把 Virtual SAN 和网络 IO 控制拿出来说一下了。开始之前，让我们列举一下 VSAN 群集会包含什么网络类型：

• 管理网络

• vMotion 网络

• Virtual SAN 网络

• 虚拟机网络

      既然建议对 Virtual SAN 使用 10GbE，我在这篇博文中就会采用这一带宽。大多数情况下，至少按照我的希望，应该提供一种冗余，因此，我们会配备 2 个 10GbE。这样一来，我会建议如何配置网络呢？

      让我们从各种端口组和 VMkernel 接口开始：

• 1 个管理网络 VMkernel 接口

• 1 个 vMotion VMkernel 接口（所有接口都需要位于同一个子网中）

• 1 个 Virtual SAN VMkernel 接口

• 1 个虚拟机端口组

      一些人可能会对我只提及一次 vMotion VMkernel 接口和 VirtualSAN VMkernel 接口感到吃惊，但就相关内容进行大量讨论和思考之后，特别是考虑到服务器环境的平均 IO 配置文件之后，我想我应该尽可能让事情更简单一些。

     

      默认情况下，我们可以确保各种类型的流量在不同的物理端口上分流，但也可以根据需要设置一些限制和共享。但是我不建议使用限制，为什么要在可以使用共享的情况下来限制某种流量类型呢，为什么要根据资源的使用和需求来“人为限制”流量类型呢？！另请注意，每个上行链路都会实施共享和限制。

      因此我们将使用共享，因为共享只有在出现争用时才会起作用。当前应该考虑 20GbE 并深入研究它。我认为，最简单的方法是，根据每种流量类型的建议，为每种流量类型分配最少数量的 GbE：

• 管理网络 –> 1GbE

• vMotion     VMK –> 5GbE

• 虚拟机端口组 –> 2GbE

• Virtual     SAN VMkernel 接口     –> 10GbE
  
  

      您可能已经发现，“管理”、“虚拟机”和“vMotion”流量共享端口 1，“Virtual SAN”流量使用端口 2。利用此方法，我们就可以确保在正常状态下每种类型的流量都有充足的带宽。此外，我们还希望确保各种流量类型不会相互排挤，为此我们将使用“网络 IO 控制”共享机制。

      现在让我们从共享的角度来审视一下这个问题。您想确保各种流量类型（以 vMotion 和 VirtualSAN 为例）始终都有充足的带宽。我会假设只有一个可用的物理端口，而所有流量类型都共享这一个物理端口。我们知道，事实并非如此，但不妨采用一种“最坏情形”来进行讨论。

      假设共有 1000 个共享，最坏的情形是，一个 10GbE 物理端口发生故障，所有流量都只使用一个端口。这样，就可以确保 Virtual SAN 始终都有 50% 的可支配带宽，而为其他流量类型留出充足的带宽，以避免可能由自身造成的 DoS。

流量类型	共享	限制
管理网络	20	不适用
vMotion VMkernel 接口	50	不适用
虚拟机端口组	30	不适用
Virtual SAN VMkernel 接口	100	不适用

     您可以设想一下，如果能够灵活地选择用于各种流量类型的上行链路，则各种流量类型就可能使用更多的带宽。经过一番思考，我对每种流量类型提出了以下建议：

• 管理网络 VMkernel 接口     = 明确指定故障切换顺序 = P1 活动/P2     待机

• vMotion     VMkernel 接口     = 明确指定故障切换顺序 = P1 活动/P2     待机

• 虚拟机端口组 = 明确指定故障切换顺序 = P1 活动/P2     待机

• Virtual     SAN VMkernel 接口     = 明确指定故障切换顺序 = P2 活动/P1     待机

      为什么要对这些类型明确指定故障切换顺序呢？最好的解释是，提高可预测性。可以通过分离不同流量类型来优化存储性能，同时为 vMotion 和虚拟机通信提供充足的带宽。

      此外，vMotion 流量是突发性流量，可能会用掉所有可用带宽，因此，在同一个上行链路中与 Virtual SAN 结合使用时，您可能会看到这两种流量可能会如何相互影响。当然，这取决于虚拟机的 IO 配置文件以及执行的操作类型。但是，您可以看到，对置备有大量内存的虚拟机执行 vMotion 是如何影响其他流量类型的可用带宽的。不要忽视这个问题，请使用网络 IO 控制！

      让我们试着对一些内容做一下虚拟化，这样才能更好地理解虚拟化的概念。只是要说明一点，虚线表示“待机”，其他线则表示“活动”。

      我希望这能够提供一些指导，帮助您在 VSAN 环境中。当然，您还可以通过其他许多方法来配置，此处只是我根据产品经验而提出的建议，旨在尽量把事情说得简单些。

      呼朋引伴，欢迎分享！

————————————————————————————————————————————

作者： Duncan Epping

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