VSAN 和网络 IO 控制/VDS 第 2 部分

原文：http://www.yellow-bricks.com/2013/11/12/vsan-network-io-control-vds-part-2/

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

      大约一周前，我写了关于 VSAN 和网络 IO 控制的文章 ( http://vsdsrevolution.blog.51cto.com/8674155/1377983 ) 。文章原本比较长，配置网络部分包含很多选项，但为了简单起见，我最终决定只保留其中一部分。我当时认为，等将来提出更多问题的时候，我再来发布其他内容。而现在正是时机。

      在下述配置中，我们会将两个 10GbE 上行链路绑定在一起（通常称为“以太通道”或“链路聚合”）。由于物理交换机的功能，虚拟层的配置非常简单。在此情形下，我们会考虑遵从建议的最小带宽要求：

• 管理网络 �C> 1GbE

• vMotion     VMkernel �C> 5GbE

• 虚拟机端口组 �C> 2GbE

• Virtual     SAN VMkernel 接口     �C> 10GbE

   

      如果将多个物理上行链路绑定在一起（即，多机箱链路聚合），则 Distributed Switch 负载平衡机制就需要进行如下配置：

1. IP-Hash
   或

2. LACP

      必须使用 LACP 或 IP-Hash（具体取决于所使用的物理交换机类型）在同一个 Distributed Switch 上配置所有端口组和 VMkernel 接口。请注意，所有上行链路都应属于同一个以太通道/LAG。不要尝试创建各种稀奇古怪的东西，因为如果绑定的组在物理和虚拟两方面配置有误，则很可能会延长停机时间！

• 管理网络 VMkernel 接口     = LACP/IP-Hash

• vMotion     VMkernel 接口     = LACP/IP-Hash

• 虚拟机端口组 = LACP/IP-Hash

• Virtual     SAN VMkernel 接口     = LACP/IP-Hash

      由于不同流量类型会共享相同的上行链路，因此，我们也希望确保在出现争用时各种流量类型不会相互排挤，这样我们就会使用“网络 IO 控制”共享机制。

      我们假设只有一个可用物理端口，所有流量类型都会共享这一个物理端口。我们会考虑最坏的情形，这样才能保证即使出现故障也不会影响到性能。此方法可以确保 Virtual SAN 始终都有 50% 的可支配带宽，而为其他流量类型留出充足的带宽，以避免可能由自身造成的 DoS。如果两个上行链路都可用，则此带宽等于 10GbE，如果只有一个上行链路可用，则此带宽会相应地减半，即，5GbE。建议按如下所示为不同类型的流量配置共享：

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

      下图显示了这一配置情形。

     呼朋引伴，欢迎分享！

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

作者： Duncan Epping

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