企业级负载均衡解决方案之十：微软Azure公有云负载均衡系统Ananta

最新推荐文章于 2021-12-01 14:49:40 发布

cloudvtech

最新推荐文章于 2021-12-01 14:49:40 发布

阅读量1.3k

点赞数

分类专栏：企业级负载均衡解决方案文章标签：云原生负载均衡器

本文链接：https://blog.csdn.net/cloudvtech/article/details/105899017

版权

企业级负载均衡解决方案专栏收录该内容

10 篇文章 15 订阅

订阅专栏

一、前言

之前介绍的很多互联网企业分布式负载均衡器，主流的方案都是两面三层架构：

1）两面

控制面
数据面

2）三层

接入层：路由器接入(BGP/ECMP)
转发层：Multiplexer进行目标选择(基于普通服务器的深度优化的kernel bypass数据流)
消费层：在服务端点(物理机/VM hypervisor/容器宿主机等)进行最后阶段处理(NAT/de-NAT、本地路由等)和数据包消费

本文介绍的Azure的Ananta公有云LB通过深入分析公有云数据流的特点，同样是基于上述三层架构，但是将部分第二层Multiplexer的能力后移到第三层在服务端点进行重点处理，形成了高可用、可扩展的公有云负载均衡器。详细的内容可以在微软Azure团队发表的Paper《Ananta: Cloud Scale Load Balancing》上看到

转载自https://blog.csdn.net/cloudvtech

二、Azure公有云的业务需求

2.1 Azure公有云数据流特点

可以看到，公有云供应商的数据中心的流量的几个基本特点：

东西向流量远远大于南北向流量
内网流量远远大于外网流量
DC内部流量远远大于跨DC流量
而虚拟IP流量和DC内部实IP流量接近

2.2 Azure对于分布式负载均衡器的需求

低成本可扩展性：Ananta的设计成本是服务器成本的1%，他们的初始设计场景是对于有4万服务器、400Gbps外部流量和100Tbps内部流量的数据中心，成本在1百万美元以下；而传统的硬件LB每20Gbps就需要近8万美元，每1Gbps的成本差别在400倍以上。
超高可用性：LB的可用性直接影响云供应商向客户提供的SLA的水平，同时LB需要提供N+1的冗余以及出现问题时候的降级服务能力
跨L2的服务能力：LB需要能为在不同DC或者AZ乃至不同城市或者国家部署的服务提供同一的负载均衡能力
租户管理：资源的预留和隔离是公有云服务最基本的一个需求之一

2.3 Ananta的基本设计理念

scale-out而不是scale-up
向路由器学习，多个Ananta 网络组建不需要per-flow的状态同步就可以并行处理数据包
一个基本假设是L4负载均衡不必要使用需要全局状态同步的负载均衡策略，基于带权重随机的策略就可满足业务需求
将部分压力后移到第三层服务端点Hypervisor上，大幅度减轻Multiplexer的压力；通过2.1数据中心流量特点的分析，可以看到，80%以上的VIP流量都可以由端点进行处理，Multiplexer只需要处理20%的VIP流量

转载自https://blog.csdn.net/cloudvtech

三、Ananta的总体架构

3.1 总体架构

从架构图可以看到Ananta也是采用分布式负载均衡器典型的2面三层设计，在控制面，由AM(Ananta Manager)进行路由管理、转发选择和安全监控，在数据面由Mux和HA(Host Agent)组成，Mux进行目的地选择和IP-over-IP封装，HA进行IP解封以及NAT操作。AM和Mux都是集群化部署，而HA是分布在每个宿主机Hypervisor上的一个模块。

3.2 数据流通

第一层，3层接入，通过路由器的ECMP协议，进行3层数据包接入和转发
第二层，4层转发，在TCP连接层面进行数据转发，这部分Mux转发服务在普通服务器上实现
第三层，vSwitch转发，进行带状态的NAT操作

转载自https://blog.csdn.net/cloudvtech

四、Ananta流量处理的细节

4.1 外部对内的连接

外部发起的连接请求进入到路由器，经过ECMP协议被转发到Mux Pool里面的某一个Mux；之后由该Mux从对应后端服务列表里面选择一个VM IP，然后进行原始包的封装(IP-in-IP)并发送给该VM对应的IP，这种封装模式跨越了L2流通域，只要具有L3的连通性就可以；HA接收到数据包之后会先进行解包，发送给VM，处理之后再返回给HA；HA进行SNAT，将VIP和端口作为源数据包地址rewrite返回数据包，并且进行DSR，不经过Mux直接返回给客户端。

4.2 内部对外的连接

内部发起的外连请求在向外走的过程中，需要先将该数据包放入HA的处理队列，然后HA会向控制面AM申请VIP和Port，待AM返回之后进行SNAT操作，用申请到的VIP和Port rewrite初始数据包，直接发送给目的server，目的server的回包会走4.1类似的流程。这里的问题在于初始建立连接会经历控制面的VIP申请流程，存在一定的建立时延，Ananta采用了包括VIP+Port复用、一次申请返回多个Port等方式进行了优化。

4.3 内部流量的快速通道

Ananta基本上不处理DC内部流量，这部分流量主要由Mux进行简单处理之后，后续由HA直接进行直接沟通；初始连接的建立需要依赖Mux，后续当HA感知对方服务DIP的细节之后，会进行直接数据连接；这种方式使得DC内部流量基本上不需要消耗Ananta的资源。当然，这种负载均衡放弃管理流量的管理方式，也会存在一些风险，需要进行适当权衡。

4.4 Mux的架构特点

每个Ananta实例包含一系列的Muxes Pool，这个Pool里面的Mux具有同等的配置和能力，响应同一批VIP的服务请求。Mux要处理的工作包括：

路由管理
数据包操作
流状态管理
Mux Pool管理

4.5 HA的架构特点

Azure号称它的HA设计是Ananta架构的最大特色，可以从这段原话略窥一二：

A differentiating component of the Ananta architecture is an agent, called Host Agent, which is present on the host partition of every physical machine that is served by Ananta. The Host Agent is the key to achieving DSR and SNAT across layer-2 domains. Furthermore, the Host Agent enables data plane scale by implementing Fastpath and NAT; and control plane scale by implementing VM health monitoring.

HA主要的工作包括：