Calico 网络互连架构

IP Interconnect Fabrics in Calico

Calico 为大规模集群以及云环境的节点提供了 end-to-end 的网络互联。为此,calico 需要一个物理层的互联架构。
大多数情况下, 以太网架构是最合适的。但是对于已有的三层架构,可能会对 calico 造成影响。
由于Calico本身就是路由基础设施,因此在运行Calico时使用IP路由互连结构需要考虑更多的工程,架构和操作注意事项。 我们将简要介绍这篇文章的其余部分。 也就是说,Calico可同时在以太网或IP互连架构上保持良好运行。

Background

Basic Calico architecture overview

有关calico 架构的详述可以在 architectural overview 中找到。
在 calico 中,计算节点充当了路由器的角色。它们为运行在本机上的容器或是虚拟机提供路由。因此我们称之为 vRouter。Linux Kernel 负责数据数据包路由, 通过BPG协议来控制路由分发, calico agent Flelix 来管理路由信息。

The data path is provided by the Linux kernel, the control plane by a BGP protocol server, and management plane by Calico’s on-server agent, Felix.

处于节点上的 Endpoint 只能同本节点 vRouter 通信, calico 中,数据包的第一条和最后一条都是通过 vRouter 中路由规则来实现。vRouter 间通过BGP协议来同步节点上的 Endpoint 信息

Overview of current common IP scale-out fabric architectures

对于可横向扩展的集群,有两种方式构建IP架构。然而, 迄今为止,这两种方案需要当边界路由器同时负责机架间上行数据交换的时候才ok。在 calico 中,计算节点本身已经集成了该功能。

此外,在绝大多数虚拟化场景中,都会采用 overlay 或者 Nat 的方式来封装 vm 或者 容器间通信的报文。例如 weave 和 docker 自带的网络。

  1. 路由架构基于某种形式的IGP。由于IGP网络的扩展限制(see the why BGP post for discussion of this topin), calico 工程小组认为使用IGP协议可能导致 Endpoint 路由无法全部分发到所有节点。但同时使用 IGP 和 BGP 是可行的。其中 IGP 传递 vRouter 下一跳路由信息(在 calico 中对应目的计算节点),BGP 用于分发 endpoint 的下一跳路由信息。实际上,这是广泛分布的IP网络(比如运营商的骨干网络)中最常见的做法。由于其设计较为复杂,本文不做详述。
  2. 路由架构完全使用BGP协议。在这种模式下,IP 网络需要足够的紧凑才能保障 BGP 协议用于 endpoint 路由信息的分发(如果集群太大,会导致同步时间过长)。同时 vRouter 间的路由也会被所有节点所掌握。本文将会重点介绍这个方案。

BGP-only interconnect fabrics

构建一个 BGP-only 的通信架构有多种方案。主要关注三种实现方案,其中每个方式又包含2个变体。

两种变体如下:
1. 第一种BGP架构:每个TOR交换机(包括交换机下附属的服务器)是一个独立的 Autonomous System(AS). 各个TOR交换机之间通过 leaf/spine 架构中的 spine switch 交换设备通信(如下图),或者通过一系列的 spine swtiches。同样,每个 spine switch 是独立的 AS。 我们将其称之为每个 AS per rack model 。 该模型在 IETF working group draft 中有详细介绍
2. 第二种BGP架构:每个计算节点都是独立的AS,TOR 交换机实现AS间通信。我们将其称之为 AS per server model

image

每种方案都包含一个2层或者3层变体。

在第一种架构下(2层),每个 spine switch 提供一个隔离的2层连接平面(个人理解:vlan)来作为 Calico 以太网互联结构模型。每个 TOR 交换机和每个 spine switch 互连。

另一种架构下(3层),每个 spine switch 看做是一个隔离的 AS,TOR 交换机和 spine switch BGP对等。在这两种情况下, TOR 交换机使用 ECMP 实现所有可用 spine switch 的负载均衡。

BGP: Border Gateway Protocol,边界网管协议

BGP用于在不通的AS 间交换路由信息。当两个AS需要交换路由信息时,每个AS都必须指定一个运行BGP的节点,来代表AS与其他的AS交换路由信息。这个节点可以是一个主机。但通常是路由器来执行BGP。两个AS钟利用BGP交换信息的路由器也被称为边界网关(Border Gateway) 或边界路由器(Border Router)。

由于可能与不同的AS相连,在一个AS内部可能存在多个运行BGP的边界路由器。同一个AS中的两个或多个对等实体之间运行的BGP被称为IBGP(Internal/interior BGP)。归属不同的AS的对等实体之间运行的BGP称为EBGP(External/Exterior BGP)。在AS边界上与其他AS交换信息的路由器被称为边界路由器(Border/edge router)。在互联网操作系统(Cisco IOS)中,IBGP通告的路由距离为200, 优先级比EBGP和任何内部网关协议(IGP)通告的路由都低。其他的路由器实现中,优先级顺序也是EBGP高于IGP,而IGP又高于IBGP。

BGP属于外部网关路由协议,可以实现AS间无环路的域间路由。BGP是沟通Internet 广域网的主要路由协议,例如不同省份、不同国家之间的路由大多要依靠BGP协议。BGP可分为IBGP和EBGP.BGP的邻居关系(或称为通信对端/对等实体)是通过人工配置实现的,对等实体之间通过TCP(179端口)会话交互数据。BGP路由器会周期地发送19字节的 keep-alive 消息来维护连接(默认周期为30s)。在路由协议中,只有BGP使用TCP作为传输层协议。

ECMP: 等价路由

ECMP存在多条不同链路到达同一目的地址的网络环境中,如果使用传统的路由技术,发往该目的地址的数据包只能利用其中的一条链路,其它链路处于备份状态或无效状态,并且在动态路由环境下相互的切换需要一定时间,而等值多路径路由协议可以在该网络环境下同时使用多条链路,不仅增加了传输带宽,并且可以无时延无丢包地备份失效链路的数据传输。

ECMP最大的特点是实现了等值情况下,多路径负载均衡和链路备份的目的,在静态路由和OSPF中基本上都支持ECMP功能。

但是实际情况是,各路径的带宽、时延和可靠性等不一样,把Cost认可成一样,不能很好地利用带宽,尤其在路径间差异大时,效果会非常不理想。例如,路由器两个出口,两路径,一个带宽是100M,一个是2M,如果部署是ECMP,则网络总带宽只能达到4M的利用率。

Some BGP network design considerations

同主流的意见相比,BGP 实际上是个相对简单的协议。eg. BGP 在 calico 节点上的配置大约只有6行(除去注释)。只是BGP的使用方式会让人感觉很复杂。许多BGP使用场景都涉及到了复杂的策略规则,用来满足技术需求(比如商业,金融等)。Calico 默认不考虑这些复杂的需求,因此相当简洁。

也就是说,在设计 Calico 节点网络时只需要记住少数几条设计原则即可。这些设计要求可以被移植,如果有必要,但是这样做会使设计人员脱离标准的BGP封装,只能由一个对高级BGP设计非常熟悉的实现者来完成。

注意事项:

  • AS continuity

    or AS puddling Any router in an AS must be able to communicate with any other router in that same AS without transiting another AS.

    不会翻 ╮(╯▽╰)╭

  • Next hop behavior
    默认情况下,对于位于同一AS下的对等实体,BGP路由器不会改变下一跳路由。反之也成立, 对等实体处于其它AS,BGP路由器会重设自己的下一跳路由。

  • Router reflection
    位于同一AS下的所有BGP 路由器彼此对等,这种行为又称为 complete BGP mesh(IBGP全连接)。当路由器数量扩张时,这种全网状的连接就会产生问题。Router reflection 可以减轻全网连接的负载。当然, route reflection 也需要做扩容考虑。

    路由反射器

    提供了在大型IBGP实现中IBGP全网状连接问题的一个简单解决方案。为保证IBGP对等体之间的连通性,需要在IBGP对等体之间建立全连接关系。假设在一个AS内部有n台路由器,那么应该建立的IBGP连接数就为n(n-1)/2。当IBGP对等体数目很多时,对网络资源和CPU资源的消耗都很大。

    利用路由反射可以解决这一问题。在一个AS内,其中一台路由器作为路由反射器RR(Route Reflector),其它路由器作为客户机(Client)与路由反射器之间建立IBGP连接。路由反射器在客户机之间传递(反射)路由信息,而客户机之间不需要建立BGP连接。

  • Endpoints
    在 Calico 网络中,每个Endpoint都对应一条路由。 硬件网络平台有学习路由数量的限制,一般在 10,000 ~ 100,000 条之间。路由聚合是个办法,但这通常取决于编排软件(例如OpenStack)使用的调度程序的功能。

The AS Per Rack model

将一个机架看做一个AS(一般TOR交换机和连接该交换机的服务器位于同一个机架上)。这种模式最接近 IETF’s Routing Area Working Group draft on BGP use in data centers. 中给出的建议。

正如之前所提到的,这种方案有两个变种,一个使用一组二层平面,平面间节点通过 TOR 交换机通信,另外一种则使用三层平面,通过Spine switch 通信。

img

This diagram shows the AS per rack model where the ToR switches are physically meshed via a set of Ethernet switching planes.

img

This diagram shows the AS per rack model where the ToR switches are physically meshed via a set of discrete BGP spine routers, each in their own AS.

在这种方案里,每个Tor 交换机到Tor 交换机或者TOR交换机到 spine switch 的链路是EBGP对等的。那就意味着北向 tor 交换机无法使用 RR(Route Reflector)

如果使用了2层的方式,结果就是每个Tor 交换机之间必须彼此对等(可能有上百个对等),可能会造成负载过重。

如果使用3层的方式,那么每个TOR 交换机只需要和上级的 spine switch 对等即可。虽然spine switch 下会有许多TOR 交换机,可以使用RR(如上图所示),而且绝大部分spine switch拥有比TOR交换机更好的平面控制能力,在多数环境下更易扩展。

两者的配置基本相同,只是在TOR 交换机的北向配置上有些差异。

TOR 交换机,作为EBGP router 会获取其他TOR switch 以及数据中心上的路由,重新分配到该AS下的每个计算节点上。并且会将自身AS内的所有路由信息向外通告。这就意味着,每个计算节点会将该AS内的TOR 交换机视为到外部路由的下一跳。外部路由到该AS的下一跳则是该AS下的某台计算节点

The ToR, as the eBGP router redistributes all of the routes from other ToRs as well as routes external to the data center to the compute servers that are in its AS, and announces all of the routes from within the AS (rack) to the other ToRs and the larger world. This means that each compute server will see the ToR as the next hop for all external routes, and the individual compute servers are the next hop for all routes external to the rack.

The AS per Computer Server model

这种模式的概念同 The AS per rack 类似。在早期的 IETF draft 中,整个架构的路由和汇聚都由TOR发起。在 Calico 中,那么路由和汇聚的起始点为各计算节点。如果TOR为3层的路由器,也只能作为2机的路由和汇聚点。

因此,顺着架构往下分析,计算节点会作为AS的边界router。同 The AS per rack 的差异可从下面2张图体现。

img

This diagram shows the AS per compute server model where the ToR switches are physically meshed via a set of Ethernet switching planes.

img

This diagram shows the AS per compute server model where the ToR switches are physically connected to a set of independent routing planes.

从上图不难发现,TOR 和 spine swtichAS per rack 模式中一样。真正的不同在于,计算节点和TOR处于不同的AS中。为了扩展集群,需要使用4字节的AS编号(RFC 4893). 如果不使用4字节的AS编号(默认2字节),那么calico 平面中的TOR 和计算节点大约只有5000左右的私有AS编号可使用。如果采用了4字节,则会有接近92,000000私有AS编号可用。

4字节AS*

AS (Autonomous System number,自治域系统号)是指拥有同一选路策略,在同一技术管理部门下运行的一组路由器的集合。BGP的RFC1771里留给AS的范围是2个字节,所以AS的取值范围为1-65535,其中64512以上的为私有AS。由于BGP在邻居协商以及路由发送接受的时候都需要使用AS属性, 鉴于IPv4地址空间不够这个前车之鉴,在RFC4893里定义了一个BGP的新功能——4字节AS(BGP Support for Four-octet AS Number,一般用M.N来描述)。

还有个差异,就是在per AS Compute Server 模式中没有 RR(Router Reflector)。所有设备都是EBGP对等的。当同一机架下的两个计算节点之间需要通信时,会通过TOR来路由。

可以将这种模式看做The AS per rack 的缩影。

The Downward Default model

最后一种模式会显得有些不同。在上面介绍的架构中,路由器需要收集机构中所有的路由表,并使他们的AS路径保持原样。这种模式在路由阶段将AS号移除。

This is to prevent routes from other nodes in the network from not being installed due to it coming from the local AS (since they share the source and dest of the route share the same AS).

不会翻 ╮(╯▽╰)╭

img

In this diagram, we are showing that all Calico nodes share the same AS number, as do all ToR switches. However, those ASs are different (A1 is not the same network as A2, even though the both share the same AS number A ).

所有TOR使用一个AS,结算节点使用另一个AS的做法简化了部署(使用标准配置即可),带来的好处就是简化了TOR中的路由表。

这种模式下,每个 Router 都向上级节点汇报自己的路由信息(vRouter –> TOR –> spine switch)。however, 作为回应,上级节点仅仅返回一条默认路由。在这种情况下,vRouter 只有本机Endpoint的路由以及到TOR的默认路由。同样,对于TOR来说只有到直连vRouterspine switch的路由。即使我们一个机架下有80台计算节点,每个计算节点上有200个Endpoint, 那在TOR上也就16000条记录左右。(大多数交换机都能达到这个数目)

由于路由下发默认是由 spine 发起的,所以下游的AS接受者无法下发路由,这就避免了AS的干扰问题。

原文:
Since the default is originatedby the Spine (originally) there is no chance for a downward announced route to originate from the recipient’s AS, preventing the AS puddling problem.

这种模式下,有个主要的缺点:非法目的地址(eg. 目的地址不存在)的流量都会被送往spine switch

值得注意的是,spine switch会收集 calico 网络中所有的路由条目。这种模式并不会使spine switch 中的路由条目比原来更多,但却着实减少了TOR上的路由信息。同时也减少了vRouter上的路由信息。但这并不是关注的重点,因为Calico中的完整路由表所消耗的内存量是现代计算服务器上可用总内存的一部分。

Recommendation

如果TOR和SPINE可以容纳所产生的路由条目,Calico 团队建议使用 AS per rack 模式。记得考虑后期扩容问题。

如果担心TOR交换机路由表大小,Calico 团队建议使用 Downward default 模式。

如果对TOR路由表大小不放心,以及希望运行非常简单的2层架构来连接Calico节点,则考虑上文介绍的Ethernet fabric(2层平面模式)。

如果Calico用户对每个计算节点一个AS的模式感兴趣,则Project Calico团队将非常有兴趣讨论该模型的部署。

Appendix

Other Options