CN107743152A - 一种OpenStack云平台中负载均衡器的高可用的实现方法 - Google Patents

Abstract

一种OpenStack云平台中负载均衡器的高可用的实现方法，包括：在OpenStack云平台中划分出两个以上的可用域，在每个可用域中设置两个以上的节点，在一个可用域中，创建至少一种负载均衡器，该种负载均衡器针对不同节点的lbaas‑agent分别创建一个，不同节点之间的同种负载均衡器相互建立通信；每个负载均衡器均设有为QR端口和HA端口，HA端口负责可用域的内部通信，用于监视本体负载均衡器和该可用域内其它LB节点上的同种负载均衡器的工作状态；QR端口负责向该可用域外的对外通信。本发明方法通过多个负载均衡器执行同一业务服务，可减少单个负载均衡器对整个业务的影响，降低风险，且通过划分可用域实现隔离，提高了通信系统安全性和可靠性，以及能降低系统的维护难度。

Description

一种OpenStack云平台中负载均衡器的高可用的实现方法

技术领域

本发明属于通信技术领域，具体涉及一种OpenStack云平台中负载均衡器的高可用的实现方法。

背景技术

为了满足日益增长的业务需求量，通信服务商减少成本，往往会对同一种业务搭建多台服务器，当大量客户端向服务端发送请求时，可以通过负载均衡器将流量平均分发至每台服务器，对于客户端来说是直接访问负载均衡器，因此只需要获取负载均衡器的VIP（virtual IP，虚拟IP地址），并不需要获取所有服务器的IP地址，而负载均衡器则需要获取所有服务器的IP地址。这种方式的优势在于当服务器的数量发生变化或服务器需要进行变更时，不需要中断业务，另外由于同一时间多台服务器出错概率远远小于单台服务器出错概率，因此也提高了业务的健壮性。

由于所有的流量需要通过负载均衡器，因此对负载均衡器的要求比较高，负载均衡器的高可用对整个业务的起到至关重要的作用。

OpenStack是一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作。OpenStack云平台中的负载均衡器（LbaaS v2），其完整的负载均衡器结构图框架如图1所示，其中：

1)Load Balancer（负载均衡器）：起到分发流量的作用，正常工作的负载均衡器会有一个VIP，客户端可通过VIP访问相应的业务；

2)Listener（监听器）：用来监听负载均衡器的端口，因此同一个负载均衡器不同的监听器的端口号不能发生重复；

3)Pool（资源池）：是多个Member的集合；

4)Member（成员）：其作用是记录单个服务器的IP地址，如果服务器IP地址发生变化，需要调整相应的Member；

5)Health Monitor（健康检查器）：其作用是定期对Member所对应的服务器进行健康检查，对出现问题的服务器反馈给Pool，负载均衡器对出现问题的Member不进行流量的分发。

在原生态的OpenStack云平台中，节点、lbaas-agent（负载均衡服务代理）、负载均衡器之间的关系如图2所示，lbaas-agent提供管理负载均衡器的服务，而一个节点中往往只有一种lbaas-agent服务。另外，不同节点的lbaas-agent互不影响，其各自lbaas-agent所创建的负载均衡器也不一样。从上述的关系图可以看出，一种服务只通过单个负载均衡器进行流量的分发，并且由于不同的lbaas-agent没有“标签”，对于云平台来讲无法区别，这种方式服务运行的过程中会造成如下的问题：

1)单个负载均衡器一旦出现问题，整个业务无法继续使用；

2)如果云平台出现问题，而需要调试的节点中存在运行的负载均衡器，则由于无法停止该负载均衡器的工作状态，对问题的查找会具有一定的困难性；

3)在创建一个需要高性能的负载均衡器和低性能的负载均衡器的时候，由于云平台无法区分不同类型的lbaas-agent，会造成比较严重的资源浪；

4)对于不同安全级别的负载均衡器，由于在创建的时候无法指定将负载均衡器创建在哪个lbaas-agent中，因此在安全方面存在隐患。

发明内容

针对现有技术中存在的问题，本发明的技术目的是提供针对OpenStack云平台的负载均衡服务（Loadbalance as a service,LBass），提供一种高可用的实现方法，其技术方案为：

一种OpenStack云平台中负载均衡器的高可用的实现方法，其特征在于，包括：

在OpenStack云平台中划分出两个以上的可用域，按照所需安全级别或性能标准的划分，将待创建的负载均衡器部署在不同的可用域中；

在每个可用域中设置两个以上的可启动lbaas-agent的节点，即每个可用域中包括两个以上的lbaas-agent；

设承担同一个业务的为同一种负载均衡器，在一个可用域中，创建至少一种负载均衡器，该种负载均衡器针对不同节点的lbaas-agent分别创建一个，即在该可用域中不同节点之间，有多个负载均衡器承担同一个业务，且不同节点之间的同种负载均衡器相互建立通信；

每个负载均衡器设有两个连接网络的端口，为QR端口和HA端口，所述HA端口自带IP，为负责可用域内部通信的端口，用于监视本体负载均衡器和该可用域内其它LB节点上的同种负载均衡器的工作状态 ；所述QR端口的IP为本体负载均衡器的VIP，为负责可用域对外通信的端口。

在上述方案的基础上，进一步改进或优选的方案还包括：

在所有的lbaas-agent中安装Keepalived， HA端口通过keepalived conntracked服务了解其它负载均衡器和本体负载均衡器的工作状态。

每个可用域中，只允许一个节点启动lbaas-agent提供服务时，只有启动lbaas-agent节点的负载均衡器的QR端口显示该负载均衡器的VIP；当该节点的负载均衡器出现故障后，关闭故障负载均衡器的QA端口，启动另一个节点的lbaas-agent，并将该节点与故障负载均衡器同种的负载均衡器的QR端口的IP设置成故障负载均衡器的 VIP地址。

同一负载均衡器上的HA端口和QR端口使用同一张物理网卡；同一可用域中的 QR端口和HA端口使用共同的外部的SWITCH交换机进行转发。

在可用域中，创建负载均衡器的过程为：

1）判断负载均衡服务集群中是否存在HA网络，是则进入步骤2），否则创建HA网络后，再进入步骤2）；

2）获取lbaas-agent的列表agents；

3）根据列表agents，针对每个需要创建的负载均衡器先分别创建HA端口，并将HA端口与HA网络进行关联；

4）针对每种需要创建的负载均衡器分别分配一个vr_id，vr_id是用于识别不同节点中的负载均衡器是否为承担同一业务负载均衡器的标识，并将HA端口与vr_id进行关联；

5）在每个lbaas-agent中，创建负载均衡器，并将负载均衡器与对应的HA端口和vr_id进行关联，QR端口在创建负载均衡器时自动产生；

6）对创建完毕的负载均衡器关联和启动Keepalive服务。

有益效果：

1）多个负载均衡器执行同一业务服务，可以减少单个负载均衡器对整个业务的影响，降低风险，提高通信系统的可靠性；

2）多个agent中的负载均衡器做了高可用，可对单个节点进行调试或者服务的重启等操作，降低维护难度；

3）通过可用域的划分可以对不同的agent进行特定的划分，例如高性能的agent创建高性能的负载均衡器，且可以实现隔离，提高通信系统安全性。

附图说明

图1为OpenStack云平台创建负载均衡器的结构图；

图2为原生态OpenStack云平台中，节点、lbaas-agent、负载均衡器之间的关系示意图；

图3为实施例1中对负载均衡器进行高可用配置之后其位置关系图；

图4为实施例2中负载均衡器实现高可用的工作原理图；

图5为创建高可用的负载均衡器的流程图。

具体实施方式

为了进一步阐明本发明的技术方案和工作原理，下面结合附图与具体实施例对本发明做进一步的介绍。

如图1至图5所示，在构建负载均衡服务集群时，为了提高安全性和做到流量分散，通过划分可用域的方式可为不同的agent放上对应的标签，可用域AZ（available zone）为OpenStack提供一种划分区域进行管理的机制，在提高负载均衡器高可用方面，可以通过创建多个负载均衡器共同承担同一个业务的方式进行，具体设计思想如图3所示，通过和图2对比发现，同一种（或者说同一名称的）负载均衡器在同一个可用域下，在每个lbaas-agent中都进行了创建，而这些在不同lbaas-agent中的相同名称的负载均衡器可通过特定机制进行通信，详见以下实施例。

实施例1：

一种OpenStack云平台中负载均衡器的高可用的实现方法，如图3所示，划分出两个可用域test以及nova，可用域test中设有节点2、节点3，可用域nova中设有节点1、节点4，按照安全级别或性能标准的划分，将待创建的负载均衡器部署在不同的可用域中，设其一可用域中的两个节点为计算节点，另一可用域中的两个节点为控制节点。真实环境中，可用域的划分个数以及可用域中agent的个数用户可根据需要自定义。

设承担同一个业务的为同一种负载均衡器（即功能相同的负载均衡器为同种负载均衡器），本实施例中，体现为名称相同的负载均衡器。

以可用域test为例，如图3所示，负载均衡器A、负载均衡器B在节点2、节点3中均分别创建一个，对于用户来说，这些名称相同的负载均衡器相当于同一个负载均衡器，即HA（高可用）负载均衡器，和原生态的OpenStack云平台相比，对负载均衡器的创建的方式有所不同。

实施例2：

如图4所示，在实施例1的基础上，将可用域test放大，以该可用域间负载均衡器A之间的关系为例。

每个负载均衡器A均设有两个连接网络的端口，为QR端口和HA端口。所述HA端口拥有自己的IP，负责可用域test的内部通信，用于监视与该HA端口对应的本体负载均衡器和可用域test内其它节点上的负载均衡器A的工作状态。所述QR端口的IP为本体负载均衡器的VIP，负责向该可用域外的对外通信，包括和后端服务器的通信和对用户的通信。同一负载均衡器A上的HA端口和QR端口使用同一张物理网卡，同一可用域中负载均衡器A 的QR端口和HA端口使用共同的外部的SWITCH交换机进行转发，但HA端口和QR端口的IP完全处于两个不同的网段，HA端口的IP的网段是负载均衡器内部的通信，在创建第一个高可用的负载均衡器A的时候会自动生成，QR端口是在创建负载均衡器的时候创建的，由于这一步在原生态的OpenStack中已经实现，本发明就不再介绍，因此创建HA端口与QR端口使用共同的出口，由外部的SWITCH进行转发。

在可用域test所有的lbaas-agent中安装Keepalived（一个类似于layer3, 4 & 7交换机制的软件，也就是我们平时说的第3层、第4层和第7层交换，Keepalived是自动完成，不需人工干涉。），节点2、节点3中负载均衡器A的HA端口通过keepalived conntracked服务了解其它负载均衡器A和本体负载均衡器A的工作状态。

当该可用域test中，只允许一个节点启动lbaas-agent提供服务时，设置只有启动lbaas-agent节点的负载均衡器的QR端口显示该负载均衡器的VIP。

例如，设节点2为MASTER节点，节点3为SLAVER节点，当MASTER节点的负载均衡器A出现故障，其HA端口发现自己无法通信后，将其QR端口关闭。与此同时，控制SLAVER节点启动lbaas-agent，SLAVER节点负载均衡器A的HA端口通过keepalived conntracked将自己QR端口的IP设置成MASTER的VIP地址，使得节点SLAVER成为MASTER，VIP的位置也从原来的MASTER切换到SLAVER中。从云平台的可靠性来讲，一个agent出现故障的可能性远远大于多个agent出现故障，因此将多个负载均衡器分别创建在多个agent中大大提高负载均衡器高可用。

如图5所示，在一可用域中，创建负载均衡器的过程如下：

1）判断负载均衡服务集群中是否存在HA网络，是则进入步骤2），否则创建HA网络后，再进入步骤2）；

2）获取lbaas-agent的列表agents；

3）根据列表agents，针对每个需要创建的负载均衡器先分别创建HA端口，并将HA端口与HA网络进行关联；

4）针对每种需要创建的负载均衡器分别分配一个vr_id，vr_id是用于识别不同节点中的负载均衡器是否为同一种负载均衡器的标识，并将HA端口与vr_id进行关联；

5）在每个lbaas-agent中，创建负载均衡器，并将负载均衡器与对应的HA端口和vr_id进行关联，QR端口在创建负载均衡器时自动产生；

6）对创建完毕的负载均衡器关联和启动Keepalive服务。

创建HA（高可用）负载均衡器相对比较复杂，但是更新和删除负载均衡器与现有技术中单节点的负载均衡器相差不大，主要区别为在本发明更新的时候需要在每个agent上的负载均衡器进行更新，在删除的时候除了在每个agent进行操作，还需要将HA端口一并删除。

对采用上述实施例1、2方法创建的高可用负载均衡器，实验方式及测试结果如下：

以两个控制节点两个计算节点的OpenStack环境为例，在其中一个可用域中创建一个HA的负载均衡器，查看VIP位于哪个lbaas-agent的负载均衡器中，最后通过人为的方式破坏MASTER节点，一段时间后观察VIP是否发生了切换，是否出现脑裂情况；然后在每个可用域中分别创建两个HA的负载均衡器，观察不同可用域之间的负载均衡器以及不同lbaas-agent的同种负载均衡器。

在OpenStack环境中的agent列表图中找出相应lbaas-agent所对应的节点，本次实验环境使用了lbaas的第二版本，因此agent类型为Loadbalancerv2 agent。

创建相应的HA的负载均衡器，查看HA负载均衡器对应的IP情况，本次实验OpenStack环境使用namespace，因此可通过namespace进行查看其IP情况，其中，节点2中tap网卡并没有出现IP，而ha网卡出现一个IP，只有一条关于ha网卡的路由。

在节点3中查看负载均衡器的IP情况，观察到tap网卡有IP，这个IP就是负载均衡器的VIP，另外，ha网卡中有两个IP地址，第一个IP地址是ha网卡自己的IP地址，第二个地址表示MASTER节点的IP地址，所有的SLAVER将对这个IP地址发送自己的状态并监听MASTER的状态，网关位于tap网卡上的网段。

通过手动关闭节点3的ha网卡半分钟后，在节点3中查看HA负载均衡器的IP情况，节点3的负载均衡器的tap网卡中已经没有VIP的信息，然后查看节点2的负载均衡器的IP信息以及路由信息，发现VIP以及路由已经切换到节点2中的负载均衡器中，节点2的负载均衡器成为了MASTER。

测试lbaas-agent可用域的划分相对来说较为简单，图3中有两个可用域，test和nova，创建四个负载均衡器并指定对应的可用域，查看负载均衡器列表图，可知列出的负载均衡器处于指定的可用域中。另外需要确认负载均衡器是否已经落实到各个节点的namespace中，分别查看节点1和节点2的负载均衡器namespace列表图，该图需要和前述的负载均衡器列表图进行对照，观察是否匹配，若为同一个负载均衡器，其在负载均衡器namespace列表图中的qlbaas-字符串后的ID与前述的负载均衡器列表图的ID应保持一致。

以上显示和描述了本发明的基本原理、主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，本发明要求保护范围由所附的权利要求书、说明书及其等效物界定。

Claims (5)

1.一种OpenStack云平台中负载均衡器的高可用的实现方法，其特征在于，包括：

在OpenStack云平台中划分出两个以上的可用域，按照对所需安全级别或性能标准的划分，将待创建的负载均衡器部署在不同的可用域中；

在每个可用域中设置两个以上的可启动lbaas-agent的节点，即每个可用域中包括两个以上的lbaas-agent；

设承担同一个业务的为同一种负载均衡器，在一个可用域中，创建至少一种负载均衡器，该种负载均衡器针对不同节点的lbaas-agent分别创建一个，即在该可用域中不同节点之间，有多个负载均衡器承担同一个业务，且不同节点之间的同种负载均衡器相互建立通信；

每个负载均衡器设有两个连接网络的端口，为QR端口和HA端口，所述HA端口自带IP，为负责可用域内部通信的端口，用于监视本体负载均衡器和该可用域内其它LB节点上的同种负载均衡器的工作状态 ；所述QR端口的IP为本体负载均衡器的VIP，为负责该可用域对外通信的端口。

2.根据权利要求1所述的一种OpenStack云平台中负载均衡器的高可用的实现方法，其特征在于：

在所有的lbaas-agent中安装Keepalived， HA端口通过keepalived conntracked服务了解其它负载均衡器和本体负载均衡器的工作状态。

3.根据权利要求1所述的一种OpenStack云平台中负载均衡器的高可用的实现方法，其特征在于：

每个可用域中，只允许一个节点启动lbaas-agent提供服务时，只有启动lbaas-agent节点的负载均衡器的QR端口显示该负载均衡器的VIP；

当该节点的负载均衡器出现故障后，关闭故障负载均衡器的QA端口，启动另一个节点的lbaas-agent，并将该节点与故障负载均衡器同种的负载均衡器的QR端口的IP设置成故障负载均衡器的 VIP地址。

4.根据权利要求1所述的一种OpenStack云平台中负载均衡器的高可用的实现方法，其特征在于：

同一负载均衡器上的HA端口和QR端口使用同一张物理网卡；同一可用域中的 QR端口和HA端口使用共同的外部的SWITCH交换机进行转发。

5.根据权利要求1-4中任一项所述的一种OpenStack云平台中负载均衡器的高可用的实现方法，其特征在于，在可用域中，创建负载均衡器的过程为：

1）判断负载均衡服务集群中是否存在HA网络，是则进入步骤2），否则创建HA网络后，再进入步骤2）；

2）获取lbaas-agent的列表agents；

3）根据列表agents，针对每个需要创建的负载均衡器先分别创建HA端口，并将HA端口与HA网络进行关联；

4）针对每种需要创建的负载均衡器分别分配一个vr_id，vr_id是用于识别不同节点中的负载均衡器是否为承担同一业务的负载均衡器的标识，并将HA端口与vr_id进行关联；

5）在每个lbaas-agent中，创建负载均衡器，并将负载均衡器与对应的HA端口和vr_id进行关联，QR端口在创建负载均衡器时自动产生；

6）对创建完毕的负载均衡器关联和启动Keepalive服务。