数据中心服务器接入部署1-多网卡接入,网络部署方案.pptVIP

Load Balancing: 目前支持三种hash模式(通过xmit_hash_policy参数来指定)： layer2 取报文的源MAC和目的MAC来进行hash，具体计算公式如下：(source mac⊕destination mac)%n 这种hash算法会导致所有到特定主机的报文都从同一个接口发出。 ? layer2+3 对于IP报文取报文的源MAC、目的MAC、源IP和目的IP字段来进行hash，具体计算公式如下：((source IP⊕destination IP)⊕(source mac⊕destination mac))%n 对于二层报文，仍然取报文的源MAC和目的MAC来进行hash，这种hash算法会导致所有到特定主机的报文都从同一个接口发出。 ? layer3+4 对于TCP/UDP报文，具体的计算hash公式如下： ((source port⊕destination port)⊕(source ip⊕destination ip))%n 对于分片TCP/UDP报文、其他IP类型报文，源端口和目的端口被忽略掉。 对于二层报文，仍然取报文的源MAC和目的MAC来进行hash。 这种hash算法到达特定主机的不同会话分散到多个接口上，但是对于某一个会话仍然保留在特定的接口发出。 * adaptive load balancing 该模式包含了TLB模式，同样会发snap报文来检测链路。同时加上针对IPv4流量的接收负载均衡(Receive Load Balance, RLB)，而且不需要任何交换机的支持。接收负载均衡是通过ARP协议实现的。绑定驱动截获本机发送的ARP应答，并把源MAC地址改写为绑定中某个slave(指的是绑定网卡集合中的其中一个成员)的唯一MAC地址，从而使得不同的对端使用不同的MAC地址与服务器进行通信。所有端口都会收到对端的ARP请求报文，回复ARP报文时，绑定驱动模块会截获所发的ARP回复报文，根据算法算到相应端口，这时会把ARP回复报文的源mac，sender源MAC都改成相应端口MAC，回复报文是第一个从端口1发，第二个从端口2发。以此类推。这样来自服务器端的接收流量也会被均衡。 当本机发送ARP请求时，绑定驱动把对端的IP信息从ARP包中获取并保存下来。当ARP应答从对端到达时，绑定驱动把它的MAC地址提取出来，并发起一个ARP应答给绑定网卡中的某个slave(这个算法和上面一样，比如算到1口，就发送ARP请求，1回复时MAC用1的mac)。使用ARP协议进行负载均衡的一个问题是：每次广播 ARP请求时都会使用绑定的MAC地址，因此对端学习到这个MAC地址后，接收流量将会全部流向当前的slave。这个问题需要通过给所有的对端发送更新（ARP应答）来解决，往所有端口发送应答，应答中包含他们独一无二的MAC地址，从而导致流量重新分布。当新的slave加入到bond中时，或者某个未激活的slave重新激活时，接收流量也要重新分布。接收的负载被顺序地分布（round robin）在bond中最高速的slave上 当某个链路被重新接上，或者一个新的slave加入到绑定中，接收流量在所有当前激活的slave中全部重新分配，通过使用指定的MAC地址给每个client发起ARP应答。当curr_active_slave 端口出故障，其他端口会接过这个端口的MAC继续工作，当原来的curr_active_slave 端口恢复正常后，将不会立即成为curr_active_slave。只有重启后才会重新成为curr_active_slave。在这个过程中curr_active_slave 和将成为curr_active_slave 的端口MAC信息会互换。 * * 内页: 标题前红色竖条可自由移动 标题 (1级) : 22-24pt 标题 (2-5级) :20-22pt 正文: 12-18pt 颜色: R89 G89 B89 中文字体:微软雅黑 英文字体:Arial 配色参考方案： 建议同一页面内不超过三种颜色，以下是10组配色方案，同一页面内只选择一组使用。（仅供参考） 目录页： 目录整体文字部分可以上下移动 目录:中文-微软雅黑 24-28pt 颜色: R255 G255 B255 英文-Arial 24-28pt 颜色: R127 G127 B127 子目录：中文-微软雅黑 24-28pt 颜色: R127 G127 B127 英文-Arial 24-28pt 颜色: R127 G127 B127 配色参考方案： 建议同一页面内不超过三种颜色，以下是10组配色方案，同一页面内只选择一组使用。（仅供参考） 内页: 标题前红色竖条可自由