亲测VxFlex部署在ESXI6.7，配置数据网络一点探讨

【开荒小记】

请输入

大家好，这里是「TECH TALK」，一个专门为神州数码技术达人开辟的小块自留地。每一期，都会有一名技术大咖空降此地，围绕一个技术话题开展“自说自话”、“自由自在”的讨论。如果你有不同意见，请务必留言battle；如果你有独到的研发心得或各式奇思妙想，欢迎后台报名投稿。

期待下期作者介绍里，是你的名字。

【本期作者介绍】

存储人生：西二旗某（不怎么）知名存储技术专家。北漂十余年，一入圈子深似海，时常记录并分享自己的一些感悟，主要是为激励自己，如果能帮助到一些朋友，就更好了。

最近在实验室测试了VxFlex3.0.0部署在ESXI6.7U2，过程不必赘叙。

其中选择后端数据网络时，以前都是在非冗余网络测试，但是生产里面一般都是冗余网络，那样的话在每个ESXI上单个SVM进行数据交互选择创建 两个虚拟网络，结果1：创建了两个vswitch用于SVM后端数据交换，ip地址等于多了一倍，虚拟交换机比较繁琐 结果2：需要SVM虚拟机处理流量分导，然后虚拟机跟虚拟交换机进行协商，聚合协商时，消息可能传递不到上联交换，会失败，还有点low（以上和资深ccie刘晗大神探讨）

那假如创建一个虚拟交换机，关联两块物理网卡时，那么双物理网卡情况下负载均衡是如何实现，主要有以下3种方式。

1、Originating Virtual Port ID，基于源虚拟端口负载均衡，ESXi主机网络默认的负载均衡方式，这种方式系统会将虚拟机网卡与虚拟交换机所属的物理网卡进行对应和绑定，绑定后虚拟机流量始终走虚拟交换机分配的物理网卡，不管这个物理网卡流量是否过载，除非当分配的这个物理网卡故障后才会尝试走另外活动的物理网卡，也就是说基于源虚拟端口负载均衡不属于动态的负载均衡方式，但可以实现冗余功能。

2、Source MAC Hash，基于源MAC地址哈希算法负载均衡，这种方式与基于源虚拟端口负载均衡方式相似，如果虚拟机只使用一个物理网卡，那么它的源MAC地址是不会发生任何变化，系统分配物理网卡以及绑定后，虚拟机流量始终走虚拟交换机分配的物理网卡，不管这个物理网卡流量是否过载，除非当分配的这个物理网卡故障后才会尝试走另外活动的物理网卡。基于源MAC地址哈希算法负载均衡还有另外的一种实现方式是虚拟机使用多个虚拟网卡，以便生成多个MAC地址，这样就虚拟机就可能绑定多个物理网卡以实现负载均衡。

3、IP Base Hash，基于IP哈希算法的负载均衡，这种方式与前两种负载均衡方式是完全不一样的，IP哈希是基于源IP地址和目标IP地址计算出一个散列值，源IP地址和不同目标IP地址计算的散列值不一样，当虚拟机与不同目标IP地址通信时使用不同的散列值，这个散列值就会走不同的物理网卡，这样就可以实现动态的负载均衡，但是需要物理交换机必须支持链路聚合协议lacp，如果交换机不配置使用链路聚合协议，那么基于IP哈希算法的负载均衡模式无效。

目前我创建了一个虚拟交换机用于后端数据交换网络，关联两块万兆物理网卡，上联两台物理交换机做堆叠，默认应该是情况一，主备模式，因为每台ESXI上svm只有一台，计划后续将策略改为IP Base Hash，同时前端堆叠的两台交换机在相应端口做lacp捆绑。

.

.

.

.

.

.

233269