openstack网络设计-(一)试探

总体思想

openstack的api只能扩展并且向前兼容，不能影响已经开发的云管和监控等业务。

在机房中虚拟机和非云物理机共存，有些业务因为各种各样的原因一时半会上不了云，要预留好云的扩展能力。

计算存储网络解耦。如果存储用ceph，ceph有api，ceph可以单独作为云盘业务用，完全可以不搭配openstack玩。再比如开发的NAT节点和LB节点，要有NAT api和LB api，可以作为单独的功能用于非云环境，云中也可以把非云中组件纳管进来进行云化管理和使用。

云上VPC和物理网络解耦，物理网络交换机统一管理，如果有耦合也是少数机架和交换机。

网络组件内部计算节点，NAT节点，LB节点有独立技术演进能力，不同节点可以用不同的技术栈，不同的开源软件，同时能互相配合得来就行。

用开源软件集成，管理和控制尽量用python实现的开源项目，涉及内核和性能相关的软件选用C语言实现。

主机overlay和网络overlay

虚拟网络和物理网络解耦，物理网络纯三层互通，没有overlay虚拟网络二层不能互通，问题是用主机overlay还是网络overlay，主机overlay就是把encap/decap功能放物理服务器上，网络overlay就是把encap/decap功能放在TOR交换机上。如果要用网络overlay，neutron得知道服务器连接到TOR那个接口上，创建port有多层次绑定，如果没有厂商的控制器，这点就不好实现。虚拟network/虚拟router都得在交换机上配置，没有标准的配置方法，每个厂商不一样，对接起来不容易，还容易被厂商绑定。好处是交换机处理encap/decap性能强大，而且可以利用厂商的控制面，neutron只下配置就行。主机overlay最大的问题就是性能瓶颈，处理encap/decap太费CPU，有了网卡offload能好很多，好处就是灵活。如果对厂商不熟，那肯定得用主机overlay。

分布式网关和集中式网关

原生openstack外网是二层网络，DVR模式下公网IP在计算节点上，而且公网IP地址要随虚拟机在不同TOR下迁移，但TOR已经是三层转发，这就要求主机和TOR之间运行路由协议对公网IP做通告，按这样说又不解耦了，如果能把公网IP集中配置在几台服务器上，把这些服务器固定到几个机架上，这些服务器南向连接内网TOR，北向连接外网TOR，和外网TOR之间运行路由协议，这样能尽量解耦，能大大减小交换机配置和管理的难度。和外面通信的都集中起来，NAT节点/VPN节点/LB节点都集中在几个机架，只有这些机架通外网，内外网实现隔离，比较安全。

剩下东西向三层转发网关，不通外网，到底是用分布式网关还是集中式网关？

如果用分布式网关，子网之间防火墙规则配置到哪个网关中，防火墙状态能不能跟随虚机迁移，neutron原生还是非对称转发，防火墙状态能不能正常建立，同节点三层都不用封装，流量探针在哪个地方镜像流量。

如果不用集中式网关，东西向三层转发集中点有性能瓶颈，同一计算节点三层还要绕网关节点一圈，好处是防火墙问题就解决了，三层QOS/ACL好找地方落地，而且不管虚拟机怎么迁移转发路径长度一样，时延是固定的。

NAT/VPN/LB节点都需要主备或者多活，甚至好扩展，如果有好的方案，那东西向三层转发用集中式网关更好。

SDN和分布式控制面

SDN控制器北向提供API，什么样的api，能提供什么样的功能，从来没有人说清楚过，南向用标准协议如ovsdb/openflow/netconf控制数据平面，SDN思想是集中式控制，但SDN控制器分身是可以分布式运行的，数据平面如果不知道怎么转发的包就上送控制器，通过什么途径上送控制器，这个途径是怎么建立起来的，到了控制器怎么决定包的转发路径，控制器怎么收集每个数据面的接口和转发能力，控制面挪个地方也不好干，核心问题并没有解决。云可以用SDN也可以不用，反过来说SDN可以控制虚拟交换机/路由器也可以控制物理交换机/路由器。

SDN没有严格的定义，总得来说是一种思想，不管白猫黑猫能抓老鼠就是好猫，实践是检验真理的唯一标准，neutron就是实践出来的一个东西，neutron-ovs-agent是控制器，用openflow给本节点上ovs安装流表，而且流表是预先都安装好的，不存在首包上送，动态安装流表，控制器和数据面在一个节点，本地就收集到数据面的信息，也不能算是控制和转发分离，但neutron的牛逼之处是有api，能把虚拟的网络/路由落地到实处，云最大的问题也就是第一把虚拟网络/交换机/路由器落到实处，第二把虚拟网络/交换机/路由器打通。第一个问题neutron做的很好，有各种extension/plugin/driver对接各种各样的机制，能把虚拟网络/交换机/路由器落实到各处，并把资源预留出来，比如ovs bridge，router namespace，交换机vrf等等。第二个问题neutron就做得不太好，打通就是MAC表/路由表/ARP/Session/封装/Openflow等，网络路径很长，确实很难，集中控制大部分场景搞不定，就拿vxlan来说得知道remote ip，建立tunnel，绑定vni，同步MAC/IP，neutron是有l2 popluation，但任何数据面要用l2 population就得实现l2 population的rpc，不说l2 population的性能和扩展性，首先l2 population不是标准，实现了l2 population只能和neutron强绑定，不能用于其它场景，比如有NAT网关和VPN网关，在云中和VXLAN一起用，NAT网关和VPN网关提供api，在neutron-server中有plugin，plugin调用网关的api，难道NAT网关和VPN网关再运行agent实现l2 population，NAT网关和VPN网关还要用于其它非云场景应用，实现l2 population有什么好处，实现EVPN不香吗，和其它实现EVPN的设备都能一起用的起来。

再抽象一下，把设备分成配置面/控制面/转发面，把配置面集中到neutron，控制面和转发面放一起，分布式控制面，控制面之间运行分布式协议，这样似乎更好。

智能网卡和offload

网关节点需求：

vxlan/nat/ipsec offload

计算节点需求：

支持virtio/openflow/vxlan/qos/ct offload，几点结合才能完美实现少数报文上CPU，多数报文硬件加速从计算节点外直接到VM内或者VM内直接出计算节点。virtio支持live migration，不能用sr-iov，VM内不能安装厂商私有driver，最好网络和存储能同时加速。

裸机需求：

能解决vxlan接入的问题，支持virtio offload，并且裸机通过智能网卡能对接ceph，裸机和虚机一样只能用virtio驱动，不能麻烦用户要安装这驱动那驱动，用户觉得这台裸机性能不够，那换一台性能更强大的裸机，网络和原来一样，原来裸机上的数据新裸机上还都在。

DCI

跨DC之间二层互通怎么搞？出外网的节点放在哪个DC？出外网的流量存不存在绕路？出外网节点要不要在不同DC之间主备或者多活？

总结

任何东西说起来容易做起来难，有时间得一点一点想一点一点细化一点一点写，看有没有时间和能力把每一点细化出来单独成文章，好坏和成败在于细节中，魔鬼在于细节中，好的设计和方案肯定不是画画图吹吹牛，这简单那简单，这样一搞那样一搞就好了，嘴上说的只是代码中一个分支，真正写代码时各种情况都要考虑进去，很多分支，每个分支都有可能执行到都不能出问题，设计和方案要细化，最终要想象出代码有多少函数，每个函数多少个分支，如果自己想不出个大概样或者自己想代码时都觉得太复杂，那设计和方案就太扯蛋了，如果自己把代码想不出个模样，那别人实现起来就坑坑不息，上线了一定问题频出，并且定位问题困难。

其实我这儿写的也很扯蛋，大家一笑而过就行了。