3.7 设计考量：分布式交换机和网络I/O控制
为了提供服务质量（QoS）和性能的可预测性，VSAN和NIOC应该携手共进。在讨论配置选项之前，下列网络类型应该列入考虑范围内：
管理网络
vMotion网络
Virtual SAN网络
虚拟机网络
这个设计考量假设为了可用性已经准备好了万兆的冗余网络连接和一对冗余的交换机。基于使用的网络交换机类型的不同，我们将描述两个场景：
1.?不具备链路聚合能力的冗余万兆以太网交换机配置。
2.?具备链路聚合能力的冗余万兆以太网交换机配置。
链路聚合（IEEE 802.3ad）使得用户可以在网络设备之间用多条链路来进行连接。它将多条物理连接捆绑成一条逻辑连接，并提供某种程度的冗余性和带宽提升。
对于这两种配置，都建议创建以下端口组和VMkernel接口：
1个管理网络VMkernel接口
1个vMotion VMkernel接口（所有接口都在同一个子网内）
1个VSAN VMkernel接口
1个虚拟机端口组
为了简化配置，应该创建单个VSAN和vMotion的VMkernel接口。
为了保证不同类型的流量分别在不同的物理端口上传输，我们将利用标准分布式交换机的能力。接下去我们还会告诉你如何使用份额（share）来避免“嘈杂的邻居”。
场景1：不具备“链路聚合”能力的冗余万兆以太网交换机
在这个配置中有两个独立的万兆以太网上行链路。出于简单性的理由，建议把流量分隔并将一条万兆以太网上行链路专用于VSAN。下面是每种流量类型推荐的最小带宽：
管理网络：1GbE
vMotion VMkernel接口：5GbE
虚拟机网络：2GbE
VSAN VMkernel接口：10GbE
不同的流量类型将共享同一条上行链路。管理网络、虚拟机网络和vMotion网络流量配置成共享上行链路1，而VSAN流量配置成使用上行链路2。通过这种网络配置方式，在VSAN群集处于正常或标准的运行状态下时，所有不同类型的流量都会获得足够的带宽。
为了保证没有一种流量类型会在竞争发生的时候影响其他流量类型，需要配置NIOC并设置份额管理机制。
在这个场景的练习中，当定义流量类型的网络份额（shares）时，假设只有一个物理端口可用，且所有流量类型共享同这一个物理端口。
这个场景还使用了最坏情况法来进行考量——即在故障发生时，也能保证性能。通过这种方法，我们可以确保VSAN始终拥有50%的带宽，同时还给其余流量类型提供足够的带宽，以避免自己引发的可能的拒绝服务攻击。
表3-1列出了不同流量类型推荐配置的份额值。
在为不同类型的流量选择上行链路的时候，应该把不同类型的流量相互隔离，以提供可预见性，同时避免“嘈杂的邻居”的干扰。建议进行以下配置：
管理网络VMkernel接口=使用明确故障切换顺序=上行链路1活动/上行链路2备用
vMotion VMkernel接口=使用明确故障切换顺序=上行链路1活动/上行链路2备用
虚拟机端口组=使用明确故障切换顺序=上行链路1活动/上行链路2备用
Virtual SAN VMkernel接口=使用明确故障切换顺序=上行链路2活动/上行链路1备用
为了拥有可预见性，建议在Teaming and failover部分选择Use explicit failover order（使用明确故障切换顺序）选项（见图3-16）。这个选项——明确故障切换顺序——始终使用活动适配器列表中排在最前面的那条上行链路来传递故障切换检测条件。
将流量分隔开可以优化存储性能，同时也能给vMotion和虚拟机流量提供足够的带宽（见图3-17）。尽管使用“基于负载的绑定”（LBT，Load Based Teaming）机制也能实现，但是请注意，LBT负载均衡周期是30秒，这在共享的上行链路出现“突发”流量的时候可能会引起短时间的拥堵。此外请注意，在进行网络故障排错的时候，它可能会在跟踪物理网卡端口和VMkernel接口之间的关系方面造成一些困难。因此，这个方法也在网络配置上提供了一种简洁性。
场景2：具备“链路聚合”能力的冗余的万兆以太网交换机
在这种场景下，两条万兆以太网上行链路配置成一种捆绑的方式（常称为EtherChannel或链路聚合）。因为物理交换机具备这样的功能，所以虚拟层面的配置便极其简单。我们仍然以前面推荐的最低带宽作为设计的考量因素：
管理网络：1GbE
vMotion VMkernel接口：5GbE
虚拟机端口组：2GbE
VSAN VMkernel接口：10GbE
当物理上行链路捆绑（链路聚合）之后，要求分布式交换机的负载均衡机制配置成下面两种选择之一：
IP哈希
LACP——链路聚合控制协议（Link Aggregation Control Protocol）
IP哈希是一个负载均衡配置的可选项，是配置在那些连接到多个上行链路的VMkernel接口上的。上行链路的选择是基于每个数据包源和目的IP地址的哈希做出的。对于非IP数据包，不管数据包内是什么内容，和IP地址位置相同的那些数值会用来计算哈希。
vSphere 5.5及更高版本的分布式交换机支持LACP。这个特性使你可以用动态链路聚合的方法把ESXi主机和物理交换机连接起来。链路聚合组（Link Aggregation Group，LAG）是在分布式交换机上创建出来的，它们把ESXi主机上的物理网卡的带宽聚合起来，并依次连接到LACP端口通道（Port Channel）。
LACP支持是从vSphere分布式交换机版本5.1开始引入的，到版本5.5功能得到了增强。如果你正在使用的版本较早，则应该至少升级到版本5.5。
要获得IP哈希和LACP支持的更多细节，可以参考官方的vSphere联网指南。
根据所使用的不同物理交换机的类型，建议将所有的端口组和VMkernel接口配置成LACP或IP哈希两种配置之一：
管理网络VMkernel接口= LACP / IP哈希
vMotion VMkernel接口= LACP / IP哈希
虚拟机端口组= LACP / IP哈希
VSAN VMkernel接口= LACP / IP哈希
因为不同的流量类型会共享同一条上行链路，所以你也会希望能确保在拥堵的情况下，不会发生某一种类型的流量排挤其他类型流量的情况。为了这个目的，我们将再次使用NIOC份额机制。
在和前面相同的假设条件下——只有一个可用物理端口并且所有流量类型都共享这同一个物理端口，我们再次用最坏情况法来考虑。这个方法确保了即使发生故障也能保证性能。通过这种方法，我们可以确保VSAN始终能获得50%的带宽并同时能给其他类型的流量留出足够的带宽，以避免自己引发的可能的拒绝服务攻击。
当两条上行链路都可用时，VSAN得到的带宽相当于10GbE。当只有一条上行链路可用时（由于网卡故障或者维护的原因），可用带宽减半，相当于5GbE带宽。
流量类型 份额 限制
管理网络 ??20 /
vMotion VMkernel接口 ??50 /
虚拟机端口组 ??30 /
VSAN VMkernel接口 100 /
这里讨论的两种场景都应该可以给你的VSAN群集提供一个优化的网络配置。
