原文：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 上行链路绑定在一起（通常称为“以太通道”或“链路聚合”）。由于物理交换机的功能，虚拟层的配置非常简单。在此情形下，我们会考虑遵从建议的最小带宽要求：
管理网络 –> 1GbE
vMotion VMkernel –> 5GbE
虚拟机端口组 –> 2GbE
Virtual SAN VMkernel 接口 –> 10GbE
如果将多个物理上行链路绑定在一起（即，多机箱链路聚合），则 Distributed Switch 负载平衡机制就需要进行如下配置：
IP-Hash
或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 探索新的业务商机。他主要致力于软件定义的存储和业务连续性/灾难恢复解决方案，目前正在申请一项专利。
转载于:https://blog.51cto.com/vsdsrevolution/1377985