image.png
Gateway scheduling has been proposed in [2]. However, rebalancing or rescheduling was not a part of that solution. This specification clarifies what is rescheduling and rebalancing. Rescheduling would automatically happen on every event triggered by addition or deletion of chassis. Rebalancing would be only triggered by manual operator action.
ovn gw 的重调度已经实现了，曾经有一些bug。 该文档即阐述了 重调度和均衡的对象。 重调度动作由新增和删除chassis自动触发。 而再平衡只能由操作者手动触发
1. 关于gw chassis 的重调度
首先有一个最大gw chassis 数目限制，这个数据是5，感觉主备或三节点是一个好维护的选择。
既然最多是5个node，kube-ovn当前的基于configmap的方式指定gw nodes 方式是比较理想的维护方式，完全基于node的label和annotaion记录优先级或许过于灵活了。
当添加或移除chassis都会触发重调度，schedule_unhosted_gateways 这个方案会调用来处理为处理过的gw。 没有lrp（连接到公网）的routers会被排除在外。可以在ovn nbdb gateway_chassis 表中查到lrp关联到chassis的更多细节。
c1fd3af798dd4417ab242cd8032ae339.png
enable-chassis-as-gw 的chassis才有资源转发lrp来的流量，这些gw chassis基于优先级来确定哪一个来负责，优先级最大的来负责，其他的都是备份。
networking-ovn 目前支持两种方式来实现重调度。
- Least loaded 最小负载，优先选择最小负载的chassis。
- 随机选取
设计上的一些考虑：
- 如果有两个chassis，c1 和 c2，router 出网流量已经调度到这两个chassis其中一个，然后添加了chassis c3，那么此时只会出现 lrp的调度从c1切到c3, 或者 c2 切到c3. c1和c2 之间的重新决策和评估流程不应再出现。
- 为了“重新”调度router的chassis，当前的主chassis将原封不动。 然而，这种场景下，所有的router都会调度到一个chassis，而这个chassis已经是主chassis了。再添加第二个chassis，那么这个新的chassis只能成为优先级较低的chassis。
以下场景应该被考虑到：
场景1： 当系统内只有一个chassis C1，并且所有的router都已经调度到这个C1.然后我们添加 chassis C2.
期望结果： 如果C2的优先级更高，那么所有router都必须从C1切换到C2。
场景2： 当系统有两个chassis C1，C2，（C1的优先级更高），然后C1 掉电，
期望结果： 所有的router 都会调度到C2，而一旦C1 回来了，那么所有router将会重新调度到C1. C2 既然是新的master，那么C1的优先级会比C2低。 ？？？ （C1 优先级更低，怎么实现调度回C1）
场景3： 当系统有两个chassis C1，C2，然后加了个C3.
期望结果： 这种场景下，现有的router不会发生切换（C3优先更高也不行嘛？？），假如router都在C1，那么C3加入后依旧在C1. 然而如果C3的优先级确实比较高，那么还是会发生切换，这取决于调度器的类型（随机还是最小负载）。
1. 关于gw chassis 的再平衡
再平衡是设计中的第二个部分，它会将新的master绑定给已经实现调度的gw 端口（lrp），也就是说，之前lrp已经选到了一个chassis，但是会发生给lrp切换chassis的情况。 当然这个操作会导致丢包（downtime）。 再平衡可以基于外部客户端脚本实现。类似的实现可以参考 dhcp重调度。重调度触发的条件是 正在用的chassis所承载的lrp数量超过了平均数量（所有lrp除以所有chassis）。 这个其实也是仅仅是从lrp的数量判断的，但是可能一个lrp的流量比其他lrp的总量加起来还要大，这个并没有从带宽饱和度来判断。
avg_gw_per_chassis = num_gw_by_provider_net / num_chassis_with_provider_net
场景1
系统只有C1 和 C2， 而且他们承担的chassis数目一样，重新平衡不会发生。
如果正好是奇数个chassis，会不会存在一个跳来跳去？？
场景2
系统本来只有C1和C2，C1 有3gw， C2 有2gw
重新平衡不会发生，不会发生循环在不同 的chassis之间重复平衡gw。
场景3
系统本来只有C1和C2，加了一个C3，
重新平衡应该会发生，会按照上面的平均数算法来平衡。
场景4
系统本来只有C1和C2，C1连接到公网vlan1，C2 连接到公网vlan2.
重新平衡不会发生，因为这两个chassis分属于不通的运营商网络。
大致总结一下， 关于gw 如何选择chassis
假设我有三个gw chassis
- 静态指定gw chassis的优先级，把这三个gw chassis绑定给所有router gw的lrp，那么结果就是所有流量都调度到优先级最高的那个，如果挂了，就切到较低优先级的那个， 这三个chassis也可以基于ha-chassis-group维护，可以自动切换，高可用更好一些。
- 基于network ovn的调度策略（最小GW LRP负载或者完全随机）+ 平衡策略搞，用户只需要指定三个gw chassis，不要设置优先级。那么随着 chassis数量的改变和gw数目的改变，networking ovn 会尝试变换不同的chassis给gw，目前的实现也是没法基于“带宽”做最小负载的。
- 还有一种方式就是kube-ovn目前在用的方式，结合port-group 和策略路由去本地直接出，或者基于ECMP hash到这3个网关节点出。
参考： https://docs.openstack.org/networking-ovn/latest/contributor/design/l3_ha_rescheduling.html
网友评论