Neutron 理解 (7): 负载均衡器虚拟化

最新推荐文章于 2022-09-03 16:49:00 发布

VIP文章陈晨luminous

最新推荐文章于 2022-09-03 16:49:00 发布

阅读量1k

点赞数

文章标签： OpenStack Neutron 负载均衡器虚拟化

本文链接：https://blog.csdn.net/qq_34043421/article/details/80123119

版权

Neutron 理解 (1): Neutron 所实现的虚拟化网络
 Neutron 理解 (2): 使用 Open vSwitch + VLAN 组网
 Neutron 理解 (3): Open vSwitch + GRE/VxLAN 组网
 Neutron 理解 (4): Neutron OVS OpenFlow 流表和 L2 Population
Neutron 理解 (5)：Neutron 是如何向 Nova 虚机分配固定IP地址的
 Neutron 理解 (6): 如何实现虚拟三层网络

1. 基础知识

1.1 负载均衡的概念

负载均衡（Load Balancing）是将来访的网络流量在运行相同应用的多个服务器之间进行分发的一种核心网络服务。它的功能由负载均衡器（load balancer）提供。负载均衡器可以是一个硬件设备，也可以由软件实现。它充当反向代理，在多个服务器之间分发网络或者应用流量。它常用来增加应用的访问容量（并发用户数）和可靠性，它也会通过降低服务器的负载来提高应用的总体性能。

（1）负载均衡器的分类

负载均衡器一般可以分为两类：第4层负载均衡器和第7层负载均衡器。

第 4 层负载平衡器：基于网络和传输层协议（IP，TCP，FTP，UDP等）来均衡负载。

图片描述

第7层的负载均衡器：基于应用层协议比如 HTTP, SMTP, SNMP, FTP, Telnet 等均衡负载。比如对 HTTP 来说，第七层的负载均衡器能根据应用的特定数据比如 HTTP 头，cookies 或者应用消息中的数据来做进一步的请求分发。

图片描述

（2）负载分发算法

两种类型的负载均衡器都能接收请求，然后根据特定的算法将请求分发到特定的服务器。一些行业标准的算法是：

轮询 (Round robin)：轮流分发到各个（活动）服务器
加权轮循 (Weighted round robin)：每个服务器有一定的加权（weight），轮询时考虑加权。
最少连接 (Least connections)：转发到有最少连接数的服务器
最少响应时间 (Least response time)：转发到响应时间最短的服务器

（3）可靠性和可用性

负载均衡器通过监控应用的健康状态来确保可靠性和可用性，并且只转发请求到能及时做出响应的服务和应用。

（4）Session persistence （会话保持）

会话保持表示在一个会话期间，转发一个用户的请求到同一个后端服务器。这对购物车或者付款类的请求非常重要。常用的方法包括：

Source IP：相同来源的请求转发到同一个服务器
HTTP Cookie：该模式下，loadbalancer 为客户端的第一次连接生成 cookie，后续携带该 cookie 的请求会被某个 member 处理
APP Cookie：该模式下，依靠后端应用服务器生成的 cookie 决定被某个 member 处理

（5）常见的开源软件负载均衡器

HAProxy
Linux Virtual Servers (LVS) - 包括在许多Linux发行版中的简单快速的4层负载均衡软件
Nginx - 一个快速可靠的web服务器也能当作代理和负载均衡器使用。它常常和 HAProxy一起用于缓存和压缩。

1.2 三种部署模式

1.2.1 tow-arms （双臂）模式

也称为 in-line 模式，或者 bridge mode 模式，或者 transparent mode。此时，所以前端访问后端的网络都需要经过 LB，它本身也成为了一种 router。可见，此时的 LB 需要两个网卡，分别连接前端和后端。

图片描述

来看一个具体的 IP 地址配置示例：

图片描述

1.2.2 One-arm （单臂）模式

图片描述

该模式中，LB 不处于前端和后端的通道上，而是在旁边。此时，LB 只使用一块网卡，而且该网卡和后端服务器处于同一个二层网络中。该 LB 的网卡将会被分配一个 virtual load-balanced IP （VIP）。需要注意的是，此时的 LB 需要对进来的网络包做 Source 和 Dest NAT 然后再交给某个后端服务器，使得后端服务器返回的网络包将会到达 LB 而不是直接到达前端，再由 LB 转交给前端。因为使用了 SNAT，因此后端看不到网络包的源IP，这在某些需要审计功能的情况下可能无法满足要求。

来看一个具体的 IP 地址配置示例：

图片描述

1.2.3 Direct Server Response 模式

图片描述

这种模式下，LB 只接收进来的网络包，转给后端服务器后，后端服务器直接将返回包发回给客户端。这种模式的好处是，可以提高网络的吞吐量，坏处是配置较为复杂。

注：以上信息来自 Basic Load-Balancer Scenarios Explained。

1.3 High Availability Proxy（HAProxy）

HAProxy 是个著名的开源的软件 TCP（四层）/HTTP（七层）负载均衡器和代理（proxy）软件，可以运行在 Linux，Solaris 和 FreeBSD 等系统上。它最常用的用途是通过在多个服务器（比如 web服务器，应用，数据库等）之间分发负载来改善一个服务器系统的性能和可靠性。目前，它已经被许多大公司采用，包括GitHub, Imgur, Instagram, and Twitter 等。它类似 Nginx 的，采用了单进程和事件驱动模型；它使用的内存量低而且稳定，能够处理大量并发请求。这篇文章讲述了怎样使用 HAProxy。

主要概念：

Frontend：定义请求如何被转发到 backend。
Backend：一组接收转发的请求的服务器。其定义包括分发算法和一组服务器的地址和端口。

支持的分发算法：

Round robin：平均的将网络流量分发到多个 member。
Source IP：从某一个特定 IP 发来的网络请求，总是发到特定的 member。
Least connections：将收到的网络请求，发给当前负载均衡池中连接数最少的 member。如果所有的 member 连接数一样，则遵循 Round robin 的方式。

一个 HAProxy + Keepalived 配置实例：

图片描述

Health Check（健康检查）：

HAProxy 使用 Health Check 来确定一个 backend server 能不能接收转发的请求。这避免了在服务器不可用时需要手工删除它。默认的 Health Check 是试着去和一个server 建立一个 TCP 连接，比如，检查该 backend server 是否在配置的 IP 和端口上监听。你可以指定 health check 方法，包括 tcp，http，ping 等。

当一个 backend server 检查失败时，它就无法接受请求了，它就会自动被禁用，请求也不会被转发到该服务器上，直到它重新变为可用。如果一个 backend 内的所有服务器都 health check 失败，其对应的服务就会变得不可用。

配置文件：

HAProxy 的核心在于其配置文件（etc/haproxy/haproxy.cfg）。Neutron 的 LBaas 其实也就是生成了该配置文件，然后由 HAProxy 去执行。

global #全局配置，基本不需要修改
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

        # Default ciphers to use on SSL-enabled listening sockets.
        # For more information, see ciphers(1SSL).
        ssl-default-bind-ciphers kEECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

frontend localnodes #where HAProxy listens to connections
    bind *:80              #HAProxy 在所有网卡的 80 端口上监听 HTTP 请求
    mode http              #监听 HTTP 请求，这时它作为一个七层负载均衡器
    default_backend nodes  #所使用的后端服务器

backend nodes #Where HAPoxy sends incoming connections
    mode http          #转发 HTTP 包给后端服务器
    balance roundrobin #分发算法
    option forwardfor  #在 HTTP 头中添加 X-Forwarded-For 头，使得后端服务器可以获取原始请求的来源地址
    http-request set-header X-Forwarded-Port %[dst_port] #在 HTTP 头中添加 X-Forwarded-Port 头从而使得后端服务器可以知道原始的 HTTP Port
    http-request add-header X-Forwarded-Proto https if { ssl_fc } #在使用 SSL 时添加 X-Forwarded-Proto头
    option httpchk HEAD / HTTP/1.1\r\nHost:localhost #使用 health check 来检查后端服务器的可达性
    server web01 127.0.0.1:9000 check #后端服务器。”check“表示做 health check。
    server web02 127.0.0.1:9001 check
    server web03 127.0.0.1:9002 check

listen stats *:1936 #用于监控 HAProxy
    stats enable
    stats uri /
    stats hide-version
    stats auth someuser:password

2. Neutron 中的虚拟负载均衡器

Neutron LBaas （load-balancer-as-a-service）扩展（extension）提供向在多个 Nova 虚机中运行的应用提供负载均衡的方法。它还提供 API 来快速方便地部署负载均衡器。它早在 OpenStack 的 Grizzly 版本就集成到 Neutron 中。自集成到 Neutron 以来，LBaaS 经历过几次大的变化。目前，在最新发布的 Kilo 版本中，LBaas 代码从 Neutron 中抽离，直接由独立的项目管理，以及实现了 LBaaS V2。本文是基于 Juno 版本的 LBaas 进行分析。 OpenStack Neutron 默认以 HAProxy 为负载均衡的 driver，同时也支持 A10 network（参考链接）、netscaler、radware （参考文档）等作为 driver。

2.1 LBaas 中的概念

LBaas 可以看做 OpenStack Neutron 对各种物理负载均衡器的虚拟化。它的概念可以和 HAProxy 中的概念进行类比：

HAProxy 的概念	LBaas 的概念	说明
	Driver	LBaas 也是采取 driver 模型来支持多种物理的负载均衡器。LBaas 默认实现了 HAProxy driver，同时，它也支持多个其他 Vendor driver。
Frontend	VIP(Virturl IP address)	LBaas 对外提供服务的地址。VIP 有自己的 IP 地址，而且一般都能通过公网进行访问。VIP 负责将网络流量分发到各个 member。
Backend	Pool	代表负载后端的虚拟机池。在以 HAProxy 为 Driver 的情况下，一个 Pool 对应着在一个独立的 network namespace 中运行的 HAProxy 进程所管理的 backend。目前一个 pool 只能有一个 VIP。
Backend server	Member	Member 对应的是 pool 里面处理网络请求的一个 OpenStack Nova 虚机。
Health check	Health monitor	它用来监测 pool 里面 member 的状态，支持 HTTP, TCP, 和 ping 等多种检测方法。在 Nuetron 中这是可选的，如果没有 Health monitor，pool 会一直认为所有的 member 都是 ACTIVE 状态，这样所有的 member 会一直出现在 VIP 的分发列表中，哪怕 member 对应的实例不能响应网络请求。这在实际应用中会造成负载均衡的响应异常。

LBaas driver 模型：

图片描述

基本概念：

图片描述

基本概念之间的联系：

图片描述

2.2 LBaas HAProxy 部署实例

OpenStack 直接采用各种开源可用的负载均衡项目来完成负载均衡的任务，默认使用 HAProxy。LBaaS 所做的任务就是根据用户提出的负载均衡要求生成符合要求的HAProxy配置文件并启动 HAProxy，然后由 HAProxy 进行负载均衡。

2.2.1 安装

不同的 LBaas drive 支持不同的部署模式。社区实现 LBaas HAPorxy driver 只支持 one-arm 模式。你可以部署LBaas Agent 在network 节点上，也可以部署在别的节点上。本实例中，将 neutron-lbaas-agent 安装在 network 节点上。你可以部署多个 LBaas 节点（agent），每个 agent 上运行不同的物理负载均衡器。

图片描述

网络节点上：

apt-get install neutron-lbaas-agent

apt-get install haproxy

修改 /etc/neutron/lbaas_agent.ini： 

interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver

device_driver = neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver

修改/etc/neutron/neutron.conf

service_plugins = router,lbaas

启动 service：

service neutron-lbaas-agent restart

lbaas-agent 进程：

neutron  18890     1  5 06:53 ?        00:00:01 /usr/bin/python /usr/bin/neutron-lbaas-agent --config-file=/etc/neutron/lbaas_agent.ini --config-file=/etc/neutron/neutron.conf --log-file=/var/log/neutron/lbaas-agent.log

Controller 节点上：

修改/etc/neutron/neutron.conf

service_plugins = router,lbaas

service neutron-server restart

修改/etc/openstack-dashboard/local_settings.py： 

OPENSTACK_NEUTRON_NETWORK = {
'enable_router': True,
'enable_quotas': True,
'enable_ipv6': True,
'enable_distributed_router': False,
'enable_ha_router': False,
'enable_lb': True

2.2.2 配置

图片描述

（1）Create pool

s1@controller:~$ neutron lb-pool-list
+--------------------------------------+-------+----------+-------------+----------+----------------+--------+
| id | name | provider | lb_method | protocol | admin_state_up | status |
+--------------------------------------+-------+----------+-------------+----------+----------------+--------+
| 3b9d8ebd-9eea-4925-b14e-593a6111ff33 | pool1 | haproxy | ROUND_ROBIN | HTTP | True | ACTIVE |
+--------------------------------------+-------+----------+-------------+----------+----------------+--------+

（2）Create members

s1@controller:~$ neutron lb-member-list
+--------------------------------------+-------------+---------------+--------+----------------+--------+
| id | address | protocol_port | weight | admin_state_up | status |
+--------------------------------------+-------------+---------------+--------+----------------+--------+
| 1f74a288-937d-4804-9ded-472a5d1110dc | 81.1.180.13 | 80 | 1 | True | ACTIVE |
| 944ff4a0-4070-40e4-8189-20f385755113 | 91.1.180.14 | 80 | 1 | True | ACTIVE |
| c5bd3138-9635-4588-889f-d08fcd364ed4 | 81.1.180.12 | 80 | 1 | True | ACTIVE |
+--------------------------------------+-------------+---------------+--------+----------------+--------+

（3）Create VIP for pool

s1@controller:~$ neutron lb-vip-list
+--------------------------------------+------+-------------+----------+----------------+--------+
| id | name | address | protocol | admin_state_up | status |
+--------------------------------------+------+-------------+----------+----------------+--------+
| 0c32d37d-f84a-4309-9e01-72d9f0bac69e | vip2 | 81.1.180.81 | HTTP | True | ACTIVE |
+--------------------------------------+------+-------------+----------+----------------+--------+

VIP 的 subnet 也可以和 pool 的subnet 不一致，主要是在指定的 subnet 内创建一个 port。

注意：这里的 VIP 从字面上看具有一定的迷惑性。VIP （virtual ip）必须创建在 pool 所在的 subnet 中，所以它本身只是一个和 pool member 的 fixed ip 一样的 fixed ip address。如果要从外网访问该 lb pool 的话，则还需要创建一个 floating ip 并且把它关联到 lb pool 的 vip 上。这也是 one-arm 单臂的由来，也就是说 haproxy 所在的namespace 其实只有一个IP地址，分别接收外部连接以及和成员之间的连接。

从 Horizon 中看创建 VIP 的情景：

图片描述

（4）Create health monitor

s1@controller:~$ neutron lb-healthmonitor-list
+--------------------------------------+------+----------------+
| id | type | admin_state_up |
+--------------------------------------+------+----------------+
| df1fcdd1-c0b5-4e14-a2fe-2d0789fc26a5 | PING | True |
+--------------------------------------+------+----------------+

（5） associate health monitor with pool

s1@controller:~$ neutron lb-healthmonitor-associate df1fcdd1-c0b5-4e14-a2fe-2d0789fc26a5 3b9d8ebd-9eea-4925-b14e-593a6111ff33
Associated health monitor df1fcdd1-c0b5-4e14-a2fe-2d0789fc26a5

以上步骤后的 pool 的详细配置：

s1@controller:~$ neutron lb-pool-show 3b9d8ebd-9eea-4925-b14e-593a6111ff33
+------------------------+--------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------------+--------------------------------------------------------------------------------------------------------+
| admin_state_up | True |
| description | |
| health_monitors | df1fcdd1-c0b5-4e14-a2fe-2d0789fc26a5 |
| health_monitors_status | {"monitor_id": "df1fcdd1-c0b5-4e14-a2fe-2d0789fc26a5", "status": "ACTIVE", "status_description": null} |
| id | 3b9d8ebd-9eea-4925-b14e-593a6111ff33 |
| lb_method | ROUND_ROBIN |
| members | 1f74a288-937d-4804-9ded-472a5d1110dc |
|                | 944ff4a0-4070-40e4-8189-20f385755113 |
|                | c5bd3138-9635-4588-889f-d08fcd364ed4 |
| name      | pool1 |
| protocol   | HTTP |
| provider   | haproxy |
| status      |

最低0.47元/天解锁文章

陈晨luminous

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
Neutron 理解 (7): 负载均衡器虚拟化

Neutron 理解 (1): Neutron 所实现的虚拟化网络 Neutron 理解 (2): 使用 Open vSwitch + VLAN 组网 Neutron 理解 (3): Open vSwitch + GRE/VxLAN 组网 Neutron 理解 (4): Neutron OVS OpenFlow 流表和 L2 Population Neutron 理...
复制链接

扫一扫