目录

OpenStack LBaaS

LBaaS（Load Balancer as a Service）是 OpenStack 的网络负载均衡服务，为用户提供应用集群负载均衡解决方案。LBaaS 支持将来自公网或内部网络的应用服务访问流量按照指定的均衡策略分发到资源池内的云主机，允许用户随时增加、减少提供应用服务的云主机而不影响业务可用性，有效保障了应用服务的响应速度和高可用。

以往，LBaaS 基于 Neutron 实现，LBaaS V1 API 在 Grizzly 版本被集成到 Neutron，功能模块的代码实现在 openstack/neutron-lbaas repo，支持 Plug-In 模式，提供了 HAProxy、F5 等多种 Driver 对接底层负载均衡器。LBaaS V2 API 在 Kilo 版本发布，Liberty 版本正式支持，同期发布的还有 Octavia Plugin。历经几个版本的迭代，Octavia 在 Pike 版本成为了需要在 Keystone 上注册 endpoint 的独立项目而不再是 Neutron 的一个服务插件。现在社区也正逐渐将 openstack/neutron-lbaas repo 实现的 Driver 迁移到 openstack/octavia repo，在 Queens 版本中 neutron-lbaas 正式被标记为废弃「Neutron-lbaas is now deprecated」。

为什么废弃 neutron-lbaas 扩展项目？社区给出了详尽的说明，简单总结一下有两点原因：

1. neutron-lbaas 与 Neutron 项目的耦合度太高，前者会直接使用 Neutron 的代码和 DB 从而导致 LBaaS API 的性能和扩展性不佳，而且 HAProxy Plugin 的实现也不具有高可用特性。总的来说，neutron-lbaas 不适用于大规模部署场景。

2. Ocatvia 项目已经成熟，可以向外提供稳定的 REST API，允许用户跨版本集成和迁移。同时，完全独立的状态会使 Ocatvia 发展得更加迅速。

OpenStack neutron-lbaas Deprecation FAQ 请浏览：
https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation

项目组织的变化：

items	Old	New
Repo	openstack/neutron-lbaas	openstack/octavia
CLI	neutronclient	octaviaclient (openstackclient 的扩展)
Horizon panels	neutron-lbaas-dashboard	octavia-dashboard (Queens 开始支持)

Octavia

Octavia 定位于电信运营商级别的可靠、可扩展负载均衡项目，加速 OpenStack LBaaS 在大规模应用场景中的落地。默认采用 HAProxy + Keepalived 组合的高可用负载均衡方案提供底层支撑。

简单总结一下 Octavia 的工作原理就是：Octavia 通过调用 Nova API 管理负载均衡器的 Lifecycle，调用 Neutron API 构建 LB Network 并接入业务网让负载均衡器纳管业务云主机，最后根据用户请求参数生成 HAProxy 和 Keepalived 的配置文件。前端为用户提供统一的业务访问入口（VIP），后端依靠负载均衡服务自动分发访问请求。

软件架构

网络架构

操作对象基本概念

Load Balancer：负载均衡服务的根操作对象，同时也是与 VIP 关联的逻辑对象。一个 Load Balancer 可以拥有一个或多个 VIPs。Load Balancer 需要占用 Neutron Subnet 的一个 Port，并从 Subnet 获取 IP 地址作为 VIP。

Subnet：下属 Neutron Network 的子网，用户业务云主机（Member）所处的网络，Subnet 与 Load Balancer 关联后，Load Balancer 拥有的 Amphora 才能与 Member 通信。

Listener：本质是 Subnet 的一个 Port，用于监听客户端对 Load Balancer（VIP）的访问请求，监听项为 HTTP/HTTPS、TCP 协议的元素（e.g. Port，URI），但不监听 IP 地址。符合监听规则（e.g. HTTP Port:80）的访问请求才会被转发到与 Listener 关联的 Pool 中。可以为一个 Load Balancer 设定若干个用于访问请求监听的 Listeners，一个 Listener 又可以关联多个 Pool。

Pool：类似于传统负载均衡系统中的 Backend Real Server Group 逻辑对象，作为 Member 的容器，接收 Listener 路由过来的客户端访问请求。通常的，会把业务类型相近的云主机划分到同一个 Pool，例如：Web 的动静分离场景。

Member：传统负载均衡系统中的 Real Server，实际运行用户业务的云主机，被包含在一个 Pool 内，具有权重属性。Member 和 Pool one to one 关联。

Health Monitor：Member 的 Health Check，与 Pool 关联，是一个单纯的 DB 对象，描述了运行在 Amphora 中的负载均衡器应该如何对 Pool 下属的 Member 进行健康状态检查的方法（e.g. HTTP Method、TCP、PING）。这是一个可选功能，但如果没有 Health Monitor，Pool 会认为所有 Member 都是 ACTIVE 的，哪怕 Member 其实不能响应。所以 Disabled Health Monitor 可能会造成负载均衡响应异常。

Amphora：为 Members 提供负载均衡服务的实体，类似于传统负载均衡系统中的 Frontend，默认为云主机，也可以是容器或裸机。Amphora 在用户新建 Load Balancer 的同时自动创建，一个 Load Balancer 可以拥有若干个 Amphora，这取决于用户选择的 loadbalancer_topology。

LB Network：全称 Load balancing management network，Octavia Controller 和 Amphora 通信的网络，每一个 Amphora 至少有一个 Port 接入 LB Network。LB Network 不会与任意一个租户关联，也不会暴露给其他的 OpenStack Project 使用。

HAProxy：运行在 Amphora 中的负载均衡器软件。

VIP：Virtual Load Balancer IP Address，与 Load Balancer 关联的虚拟 IP 地址，由运行在 Amphora 中的 Keepalived 应用 VRRP 协议原理来维护 VIP 的漂移和高可用性。

Layer 7 Switching：是针对七层 HTTP/HTTPS 协议的负载均衡功能，能够根据用户设定的 L7 Policy 将不同的客户端请求路由到不同的 Pool 中。

Layer 7 Policy：用于设定 Listener 将客户端请求转发到指定 Pool 的路由策略。当 Listener 关联了多个 Pool 时，可以通过设定 L7 Policy 来控制流量转发到指定的 Pool。Layer 7 Policy 只会与一个 Listener 关联，但可以关联多个 L7 Rule。例如：用户可以设定 URI 以 “/api” 开头的客户端请求都转发到 Listener 下的 Pool: “api_pool” 中。

Layer 7 Rule：本质是 HAProxy frontend section 下的 ACL 规则，可以根据是否满足规则的条件来确定最终处理客户请求的 Member。例如：用户可以设定 L7 Rule: “/api” 来匹配 URI 以 “/api” 开头的客户端请求，交由 Member: api_service 处理。Layer 7 Rule 与 Layer 7 Policy 结合使用实现 Layer 7 Switching 的功能。

Transport Layer Security (TLS) Termination：TLS Termination 是负载均衡器处理 HTTPS 协议的一种方式。通常的，HTTPS 协议要求客户端和服务端进行 3 次连接握手加上 9 次 SSL 安全验证握手，共 12 次握手才得以建立连接。可见如果在服务端（Member）上处理 SSL 握手，会对服务端造成比较大的压力。所以在负载均衡场景中，可以把这些压力转移到负载均衡服务器上，这就是负载均衡器的 TLS Termination 功能，将 HTTPS 连接中最耗时的部分从服务端剥离出来，让服务端专心于自身的业务负载。如果 Listener 设定了 HTTPS 的 Layer 7 Switching，那么 TLS Termination 将会非常有用。

功能实现基本概念

Controller：Octavia 的核心控制层，由 4 大功能模块组成

• API：Octavia 项目的 REST API
• Worker：实际的负载均衡业务逻辑，与 Nova 配合，完成 Amphora 的生命周期管理；与 Neutron 配合，完成 LB Network 接入 Subnet。还会通过与 Agent 通信将执行指令下发到 Amphora，支持插件框架。
• Health Manager：用于监控 Member 的健康状态，如果出现故障，则自动进行故障转移。通过于 Agent 通信来更新 Amphora 中的负载均衡器的健康检查方式。
• Housekeeping Manager：
  • SpareAmphora：管理 Backup Amphorae
  • DatabaseCleanup：用于清除残留（实际已删除）的数据库记录
  • CertRotation：管理 Amphorae 证书的循环使用

Agent：Amphora Agent，运行在 Amphorae 内，接收外部请求并组织 HAProxy 和 Keepalived，同时也负责上报 Member 的健康状态信息给 Health Manager。

Amphora Load Balancer Driver：负责 Controller 与 Amphora 在 LB Network 中的通信。

Ocatvia Daemon 列表

• octavia-api.service
• octavia-worker.service
• octavia-health-manager.service
• octavia-housekeeping.service

部署 Ocatvia

• 版本：Pike
• 操作系统：CentOS 7

手动方式集成 Octavia

Step 1. 安装软件包

yum -y install \openstack-octavia-api.noarch \openstack-octavia-common.noarch \openstack-octavia-health-manager.noarch \openstack-octavia-housekeeping.noarch \openstack-octavia-worker.noarch \openstack-octavia-diskimage-create.noarch# openstack loadbalancer 扩展子命令
git clone https://github.com/openstack/python-octaviaclient.git -b stable/pike
pip install -r requirements.txt -e .

Step 2. 创建数据库

mysql> CREATE DATABASE octavia;
mysql> GRANT ALL PRIVILEGES ON octavia.* TO 'octavia'@'localhost' IDENTIFIED BY 'OCTAVIA_DBPASS';
mysql> GRANT ALL PRIVILEGES ON octavia.* TO 'octavia'@'%' IDENTIFIED BY 'OCTAVIA_DBPASS';
mysql> flush privileges ;

Step 3. 创建 Keystone 认证体系

openstack user create --domain default --password-prompt octavia
openstack role add --project service --user octavia admin
openstack service create load-balancer --name octavia
openstack endpoint create octavia public http://172.18.128.109:9876 --region RegionOne
openstack endpoint create octavia admin http://172.18.128.109:9876 --region RegionOne
openstack endpoint create octavia internal http://172.18.128.109:9876 --region RegionOne

Step 4. 创建安全组

# Amphora 虚拟机使用，LB Network 与 Amphora 通信
openstack security group create lb-mgmt-sec-grp --project <admin project id>
openstack security group create lb-mgmt-sec-grp --project <service project id>

# Amphora 虚拟机使用，Health Manager 与 Amphora 通信
openstack security group create lb-health-mgr-sec-grp --project <admin project id>
openstack security group create lb-health-mgr-sec-grp --project <service project id>

Step 5. 创建 LB Network，Octavia Controller 与 Amphora 通信的网络

openstack network create lb-mgmt-net
openstack subnet create \--subnet-range 192.168.0.0/24 \--allocation-pool start=192.168.0.2,end=192.168.0.200 \--network lb-mgmt-net lb-mgmt-subnet

Step 6. 签署和自检 CA 证书，在 Octavia Controller 和 Amphora 或者 Amphora 和后端云主机通信时，都会使用到 CA 证书。所以还需要注意开启 barbican 服务。

source /opt/pike/octavia/bin/create_certificates.sh /etc/octavia/certs/ /opt/pike/octavia/etc/certificates/openssl.cnf

Step 7. 创建 Health Manager 对应的 Controller 网络端口，Controller 中的 Health Manager 通过该 Port 与 Amphora 通信

neutron port-create --name octavia-health-manager-standalone-listen-port \--security-group <lb-health-mgr-sec-grp> \--device-owner Octavia:health-mgr \--binding:host_id=<hostname> lb-mgmt-net \--tenant-id <octavia service>ovs-vsctl --may-exist add-port br-int o-hm0 \-- set Interface o-hm0 type=internal \-- set Interface o-hm0 external-ids:iface-status=active \-- set Interface o-hm0 external-ids:attached-mac=<Health Manager Listen Port MAC> \-- set Interface o-hm0 external-ids:iface-id=<Health Manager Listen Port ID>

Step 8. Health Manager 监听端口设置 IP

# /etc/octavia/dhcp/dhclient.conf
request subnet-mask,broadcast-address,interface-mtu;
do-forward-updates false;

ip link set dev o-hm0 address <Health Manager Listen Port MAC>
dhclient -v o-hm0 -cf /etc/octavia/dhcp/dhclient.conf

Step 9. 创建 Amphora 的 Key Pair

mkdir -p /etc/octavia/.ssh
ssh-keygen -b 2048 -t rsa -N "" -f /etc/octavia/.ssh/octavia_ssh_key
nova keypair-add --pub-key=/etc/octavia/.ssh/octavia_ssh_key.pub octavia_ssh_key --user <octavia user id>

Step 10. 制作并上传 Amphora 镜像文件，生产环节中不建议设定密码，使用 Key Pair 启动实例

octavia-diskimage-create.sh -i centos
openstack image create amphora-x64-haproxy \--public \--container-format=bare \--disk-format qcow2 \--file /opt/pike/octavia/diskimage-create/amphora-x64-haproxy.qcow2 \--tag amphora

Step 11. 修改 Octavia 配置文件（PS：这里以 Devstack 自动生成的配置文件举例）

[DEFAULT]
transport_url = rabbit://stackrabbit:admin@172.18.128.109:5672/
api_handler = queue_producer
bind_host = 172.18.128.109
[api_settings]
[database]
connection = mysql+pymysql://root:admin@127.0.0.1:3306/octavia
[health_manager]
bind_port = 5555            # lb-health-mgr-sec-grp 安全组开发该 UDP 端口
bind_ip = 192.168.0.7       # Step 7 创建的 o-hm0 网络设备 IP 地址
controller_ip_port_list = 192.168.0.7:5555     # 对应 Step 7 的 Health Manager 监听端口
heartbeat_key =insecure
[keystone_authtoken]
memcached_servers = 172.18.128.109:11211
signing_dir =
cafile = /opt/stack/data/ca-bundle.pem
project_domain_name = Default
project_name = service
user_domain_name = Default
password = admin
username = octavia
auth_url = http://172.18.128.109/identity
auth_type = password
[certificates]
ca_private_key_passphrase = foobar
ca_private_key = /etc/octavia/certs/private/cakey.pem    # Step 6 生成的证书
ca_certificate = /etc/octavia/certs/ca_01.pem
[anchor]
[networking]
[haproxy_amphora]
server_ca = /etc/octavia/certs/ca_01.pem      # 与 certificates Section 的证书匹配
client_cert = /etc/octavia/certs/client.pem
base_path = /var/lib/octavia
base_cert_dir = /var/lib/octavia/certs
connection_max_retries = 1500                 # 验证 Amphora 是否正常启动的超时配置
connection_retry_interval = 1
rest_request_conn_timeout = 10
rest_request_read_timeout = 120
[controller_worker]
amp_boot_network_list = 6fd0afdc-c683-4157-8354-dcdd43011dad    # Step 5 创建的 LB Network
amp_image_tag = amphora                                         # Step 9 制作的镜像 tag
amp_secgroup_list = d4d7a2bb-efc4-4a0f-bb6b-efcc6f9797d3        # lb-mgmt-sec-grp ID
amp_flavor_id = 0b8517a7-0a9c-4d66-b9f1-60afd2e3061c            # Amphora Flavor
amp_image_owner_id = 542a9377317a4fe081c9bac54780eb75           # Amphora Image Owner ID
amp_ssh_key_name = octavia_ssh_key                              # Amphora Key Pair
network_driver = allowed_address_pairs_driver
compute_driver = compute_nova_driver
amphora_driver = amphora_haproxy_rest_driver
workers = 2
amp_active_retries = 100
amp_active_wait_sec = 2
loadbalancer_topology = ACTIVE_STANDBY                          # 启动主备模式 Amphora
[task_flow]
[oslo_messaging]
topic = octavia_prov
rpc_thread_pool_size = 2
[house_keeping]
load_balancer_expiry_age = 3600         # 定时清理周期
amphora_expiry_age = 3600
[amphora_agent]
[keepalived_vrrp]
[service_auth]
memcached_servers = 172.18.128.109:11211
cafile = /opt/stack/data/ca-bundle.pem
project_domain_name = Default
project_name = admin
user_domain_name = Default
password = admin
username = admin
auth_type = password
auth_url = http://172.18.128.109/identity
[nova]
[glance]
[neutron]
[quotas]

Step 12. 初始化 Octavia 数据库

octavia-db-manage upgrade head

Step 13. 启动服务

systemctl start octavia-api.service
systemctl start octavia-worker.service
systemctl start octavia-health-manager.service
systemctl start octavia-housekeeping.service

Step 14. 添加 Load Balancers 页面

# Pike 版本依旧使用 neutron-lbaas-dashboard
git clone https://github.com/openstack/neutron-lbaas-dashboard.git -b stable/pike
pip install -r requirements.txt -e .
cp /opt/pike/neutron-lbaas-dashboard/neutron_lbaas_dashboard/enabled/_1481_project_ng_loadbalancersv2_panel.py /opt/pike/horizon/openstack_dashboard/enabled//opt/pike/horizon/manage.py collectstatic
/opt/pike/horizon/manage.py compress
sudo service apache2 restart

Step 15. 修改 Neutron 配置

# /etc/neutron/neutron.conf
[DEFAULT]
service_plugins = neutron.services.l3_router.l3_router_plugin.L3RouterPlugin,lbaasv2[octavia]
base_url = http://172.18.128.109/load-balancer
request_poll_timeout = 3000# /etc/neutron/neutron_lbaas.conf
[DEFAULT]
[certificates]
[quotas]
[service_auth]
auth_version = 2
admin_password = admin
admin_user = admin
admin_tenant_name = admin
auth_url = http://172.18.128.109/identity/v2.0
[service_providers]
service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default# /etc/neutron/services/loadbalancer/haproxy/lbaas_agent.ini
[DEFAULT]
user_group = nobody
interface_driver = openvswitch
ovs_use_veth = False
[haproxy]
user_group = nobody

最后不要忘记重启 Neutron 服务。

Devstack 方式部署

LBaaS 相关组件：

• neutron
• octavia
• neutron-lbaas
• neutron-lbaas-dashboard

[[local|localrc]]
HOST_IP=172.18.128.109# Reclone each time
RECLONE=no
#OFFLINE=True# Enable Logging
DEST=/opt/pike
LOGFILE=$DEST/logs/stack.sh.log
VERBOSE=True
LOG_COLOR=True
SCREEN_LOGDIR=$DEST/logs# Define images to be automatically downloaded during the DevStack built process.
DOWNLOAD_DEFAULT_IMAGES=False
IMAGE_URLS="http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img"# use TryStack git mirror
GIT_BASE=http://git.trystack.cn
NOVNC_REPO=http://git.trystack.cn/kanaka/noVNC.git
SPICE_REPO=http://git.trystack.cn/git/spice/sice-html5.git# Credentials
ADMIN_PASSWORD=admin
DATABASE_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=$ADMIN_PASSWORD## Neutron
ENABLED_SERVICES+=,q-lbaasv2
ENABLED_SERVICES+=,octavia,o-cw,o-hk,o-hm,o-api
enable_plugin neutron-lbaas https://git.openstack.org/openstack/neutron-lbaas
enable_plugin octavia https://git.openstack.org/openstack/octavia
enable_plugin neutron-lbaas-dashboard https://github.com/openstack/neutron-lbaas-dashboard
disable_service n-net
enable_service q-svc q-agt q-dhcp q-l3 q-meta neutron
enable_service q-fwaas q-vpn

Octavia 使用

Step 1. 准备租户网络，用户的业务云主机在该网络内。

Step 2. 选定 Load Balancer 服务的 Subnet。

Step 3. 设定 Load Balancer 下属的 Listener，指定监听 HTTP Port: 80 访问请求。

Step 4. 设定 Listener 下属的 Pool，配置 SOURCE_IP 策略，来自同一客户端的请求会持续被分发到指定的一个 Member。

Step 5. 设定 Pool 下属的 Members，添加 Member 的本质是将业务云主机的 IP/MAC 地址绑定到 Pool，HAProxy 是通过主机 IP/MAC 地址来进行分发的，这些 IP 地址将会被作为 server 配置项写入到 haproxy.cfg 文件。

Step 6. 设定 Pool 下属的 Health Monitor，配置使用 PING 方式来检查下属 Member 的健康状态。

测试分析

创建 Load Balancer 的同时会自动创建 Amphora 实例，因为配置了 loadbalancer\_topology = ACTIVE_STANDBY 所以创建了一个 Master Amphora 和一个 Backup Amphora，避免了单点故障。否则就是 Single Amphora，Pike 版本暂不支持 ActiveActive 主主模式。

lb-mgmt-net 是 LB Network，Octavia Controller 与 Amphora 使用该网络进行通信，所以 lb-mgmt-net 也需要接入 OpenStack API/Management Network。

在 Sunbet 中自动创建了 3 个 Port，两个 lb-vrrp 分别是两个 Amphora 的 Port，一个 loadbalance 是 VIP 的 Port。VIP 由运行在 Amphora 上的 Keepalived 维护，遵守 VRRP 虚拟路由冗余协议，支持着 VIP 的高可用。

可以将 VIP 绑定到浮动 IP 从外网进行访问。

创建 LB 时，还会自动创建 Amphora 实例（VIP）的安全组 lb-<Load Balancer ID>，该安全会随着 LB 下属的 Listeners 的变化（增加/删除了 L4/L7 的 Listener，octavia-worker 会自动增加/删除相应的 Port 的安全组规则）。因为上面设定的 Listener 监听 HTTP Port: 80，所以会自动添加 80(HTTP) 规则。但如果想 Ping/SSH VIP 的话，还需要手动添加 ICMP/SSH 规则。

$ ip netns exec qdhcp-6fd0afdc-c683-4157-8354-dcdd43011dad ssh -i /etc/octavia/.ssh/octavia_ssh_key ubuntu@192.168.0.11 -p 22

可以通过 LB Network 的 DHCP namespace SSH 进入 Amphora。

上图可以看见 Amphora 只有一张 LB Network 的网卡（通过 IP 地址判断），那接入 Subnet 的网卡呢？

Amphora 会启动一个 namespace amphora-haproxy，Sunbet 的网卡、HAProxy 和 Keepalived 的服务进程都在该 namespace 中运行。

Amphora 中最重要的几个服务进程：

# HAProxy
usr/sbin/haproxy -f /var/lib/octavia/b45ed46d-ec04-421b-a0e0-a3268ccea61e/haproxy.cfg -f /var/lib/octavia/haproxy-default-user-group.conf
/usr/sbin/haproxy-systemd-wrapper -f /var/lib/octavia/b45ed46d-ec04-421b-a0e0-a3268ccea61e/haproxy.cfg -f /var/lib/octavia/haproxy-default-user-group.conf# Keepalived
/usr/sbin/keepalived -D -d -f /var/lib/octavia/vrrp/octavia-keepalived.conf# Amphora Agent，北接 Controller 南对 Member
/usr/bin/python2 /usr/local/bin/amphora-agent --config-file /etc/octavia/amphora-agent.conf# 动态获取/释放 IP 地址
/sbin/dhclient -1 -v -pf /run/dhclient.ens3.pid -lf /var/lib/dhcp/dhclient.ens3.leases -I -df /var/lib/dhcp/dhclient6.ens3.leases ens3

查看 Keepalived 的配置文件：

vrrp_script check_script {script /var/lib/octavia/vrrp/check_script.shinterval 5fall 2rise 2
}vrrp_instance 09f967f9355b498cb56f11d5bfe32f19 {state BACKUP                  # 该 Amphora 充当 Backup 路由器interface eth1                # VIP 对接 Subnetvirtual_router_id 1           # VRIDpriority 90nopreemptgarp_master_refresh 5garp_master_refresh_repeat 2advert_int 1authentication {auth_type PASSauth_pass 2d2cd51}unicast_src_ip 192.168.0.10   # 与 Master 路由器的对盯方式unicast_peer {192.168.0.16}virtual_ipaddress {192.168.0.3                  # VIP 地址}track_script {check_script}
}

查看 HAProxy 的配置文件：

# Configuration for test_lb1
globaldaemonuser nobodylog /dev/log local0log /dev/log local1 noticestats socket /var/lib/octavia/b45ed46d-ec04-421b-a0e0-a3268ccea61e.sock mode 0666 level userdefaultslog globalretries 3option redispatchtimeout connect 5000timeout client 50000timeout server 50000peers b45ed46dec04421ba0e0a3268ccea61e_peerspeer qenPC2HfzYBAclR9HimRSWmYznU 192.168.0.10:1025peer yKL51Z6MZq1lHKxajQ4sXXuWZmM 192.168.0.16:1025frontend b45ed46d-ec04-421b-a0e0-a3268ccea61e             # 前端服务器option httplogbind 192.168.0.3:80                                   # 前端服务器绑定 VIPmode httpdefault_backend 209f2923-f8b1-476b-80e9-6ac2a5145ca1  # 默认后端服务器backend 209f2923-f8b1-476b-80e9-6ac2a5145ca1              # 后端服务器mode httpbalance source                                        # 负载均衡服务器timeout check 5s                                      # Health Check 间隔server 34e36204-48dc-4c2c-95dc-bb9e6a3f9fbd 192.168.0.8:80 weight 1 check inter 5s fall 3 rise 3                   # Real Server，用户业务云主机 instance1server 97cba054-4f8c-4a9f-91e2-56973efcb417 192.168.0.9:80 weight 2 check inter 5s fall 3 rise 3                   # Real Server，用户业务云主机 instance2

修改 Health Monitor 为 HTTP GET URI 方式的话，haproxy.cfg 变更为：

backend 209f2923-f8b1-476b-80e9-6ac2a5145ca1mode httpbalance sourcetimeout check 5soption httpchk GET /apihttp-check expect rstatus 200server 34e36204-48dc-4c2c-95dc-bb9e6a3f9fbd 192.168.0.8:80 weight 1 check inter 5s fall 3 rise 3server 97cba054-4f8c-4a9f-91e2-56973efcb417 192.168.0.9:80 weight 2 check inter 5s fall 3 rise 3

可以通过指令 openstack loadbalancer l7policy create 和 openstack loadbalancer l7rule create 来创建七层的 Policy 和 Rule。当创建 L7 Rule 时，会为 frontend 添加 ACL 规则。e.g.

frontend b45ed46d-ec04-421b-a0e0-a3268ccea61eoption httplogbind 192.168.0.3:80mode httpacl dc6f6294-b7ca-4684-8f15-8f1dbf86185a path -m reg /#  满足 acl 规则的请求重定向至 http://www.baidu.comredirect location http://www.baidu.com if dc6f6294-b7ca-4684-8f15-8f1dbf86185adefault_backend 209f2923-f8b1-476b-80e9-6ac2a5145ca1

最后

除了上述提到功能外，Ocatvia 还支持许多更加细致的七层负载均衡分发配置，比如：最大连接数、会话保持类型、附加 HTTP Header 字段、TLS Termination、L7 策略动作类型、L7 规则类型等等，都是非常精彩的负载均衡分发实现。碍于篇幅的原因，我们下次再聊。