Octavia 加速 OpenStack LBaaS 落地大规模应用场景
发布日期:2021-06-30 18:28:32 浏览次数:4 分类:技术文章

本文共 18119 字,大约阅读时间需要 60 分钟。

> 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

项目结构的变化

> Octavia

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

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

注:本文主要以 HAProxy + Keepalived 为例,认为读者已具有相关基础知识储备。

软件架构

网络架构

该图摘自孔令贤的博客:https://lingxiankong.github.io/2017-09-13-octavia.html

操作对象基本概念

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 用于监听不同请求目的的访问。

Pool:类比传统负载均衡体系的 Backend Real Server Group,是一个逻辑对象,作为 Member 的容器,接收 Listener 路由过来的客户端访问请求,一个 Listener 可以关联多个 Pool。通常的,会把业务类型相近的云主机划分为同一个 Pool,例如:Web 应用的动静分离。

Member:类比传统负载均衡体系的 Real Server,实际运行用户业务的云主机,被包含在一个 Pool 内,具有权重属性。

Health Monitor:类比传统负载均衡体系的 Health Check 功能,与 Pool 关联,是一个单纯的 DB 对象,描述了运行在 Amphora 中的负载均衡器应该如何对下属 Member 进行健康检查的方法。一般具有 HTTP、TCP、PING 三种。Health Monitor 是一个可选功能,但如果不启用,就很可能会造成响应异常。因为此时的 Pool 会恒久的认为所有 Member 都处于 ACTIVE 状态。

Amphora:类比传统负载均衡体系的 Frontend,实际为 Members 提供负载均衡服务的实体。默认为云主机,也可以是容器或裸机。Amphora 是 Load Balancer 的生命共同体,一个 Load Balancer 可以拥有若干个 Amphora,取决于用户选择的 LB Topology 类型。

LB Network:全称 Load balancing management network,Octavia Controller 与 Amphora 通信的网络,每一个 Amphora 至少有一个 Port 接入 LB Network,这样 Octavia 的大脑才得以控制它。LB Network 不会与任意一个租户关联,也不会暴露给其他的 OpenStack Project 使用。

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

VIP:Virtual Load Balancer IP Address,与 Load Balancer 关联的虚拟 IP 地址,由运行在 Amphora 中的 Keepalived 来维护 VIP 的漂移和高可用性,遵守  VRRP 协议。

Layer 7 Switching:是针对七层网络协议(HTTP/HTTPS)的负载均衡功分发动作,根据用户设定的 L7 Policy 将不同访问请求路由到指定的 Pool 中。

Layer 7 Policy:与 Listener 关联,用于设定 Listener 转发访问请求到 Pool 的路由策略。当 Listener 关联了多个 Pool 时,L7 Policy 才有用武之地。例如:用户可以设定 URL 以 "/api" 开头和以 "/work" 开头的访问请求分别转发到 Listener 下属的 "api_pool" 或者 "work_pool" 中。

Layer 7 Rule:本质是 haproxy.cfg frontend p 下的 ACL 规则,根据是否符合规则来确定最终处理客户请求的 backend。用户在 L7 Policy 的基础之上,得以继续细分转发粒度(Pool ==> Member)。 例如:URI 以 "/api" 开头的客户端请求,交由 Member: api_service 处理。

Transport Layer Security (TLS) Termination:TLS Termination 是负载均衡器针对 HTTPS 协议的一种处理方式。通常的,HTTPS 协议要求客户端和服务端进行 3 次连接握手和 9 次 SSL 安全验证握手,共 12 次握手才建立连接。显然,高并发的 SSL 握手对服务端(Member)来说是一种压力。在负载均衡体系中,就实现了将这种压力转移到负载均衡服务器上的能力,这就是负载均衡器的 TLS Termination,把建立 HTTPS 连接中最耗时的部分从服务端剥离,让服务端专心于有效的业务负载。如果 Listener 设定了 HTTPS 的 Layer 7 Switching,那么 TLS Termination 将会非常有用。

功能实现基本概念

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

  • API:Octavia 的 REST API

  • Worker:实际的 LB 服务协同、管理模块。负责联接 Nova、Neutron、Agent,支持插件框架。

  • Health Manager:监控 Member 的健康状态,如果出现故障,则自动进行故障转移。与 Amphora 通过 Agent 通信,以更新负载均衡器的健康检查方式。

  • Housekeeping Manager

    • SpareAmphora:管理 Backup Amphorae

    • DatabaseCleanup:用于清除残留(实际已删除)的数据库记录

    • CertRotation:管理安全通信证书的使用

Agent:Amphora Agent,Amphorae 的内部服务进程,接收外部请求并组织 HAProxy 和 Keepalived,同时也负责上报 Member 的健康状态到 Health Manager。

Amphora Load Balancer Driver:负责 Octavia 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/pikepip 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 octaviaopenstack role add --project service --user octavia adminopenstack service create load-balancer --name octaviaopenstack endpoint create octavia public http://172.18.128.109:9876 --region RegionOne openstack endpoint create octavia admin http://172.18.128.109:9876 --region RegionOneopenstack 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 

# Amphora 虚拟机使用,Health Manager 与 Amphora 通信openstack security group create lb-health-mgr-sec-grp --project 

除此之外,Octavia 启动 Amphora 时还会自动添加 lb-XXX 安全组

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

openstack network create lb-mgmt-netopenstack 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. 生成 Ocatvia Controller 与 Amphora 的安全通信证书

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 
\  --device-owner Octavia:health-mgr \  --binding:host_id=
lb-mgmt-net \  --tenant-id
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=
\  -- set Interface o-hm0 external-ids:iface-id=

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

# /etc/octavia/dhcp/dhclient.confrequest subnet-mask,broadcast-address,interface-mtu;do-forward-updates false;
ip link set dev o-hm0 address 
dhclient -v o-hm0 -cf /etc/octavia/dhcp/dhclient.conf

Step 9. 创建 Amphora 的 Key Pair

mkdir -p /etc/octavia/.sshssh-keygen -b 2048 -t rsa -N "" -f /etc/octavia/.ssh/octavia_ssh_keynova keypair-add --pub-key=/etc/octavia/.ssh/octavia_ssh_key.pub octavia_ssh_key --user 

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

octavia-diskimage-create.sh -i centosopenstack 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_producerbind_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:11211signing_dir =cafile = /opt/stack/data/ca-bundle.pemproject_domain_name = Defaultproject_name = serviceuser_domain_name = Defaultpassword = adminusername = octaviaauth_url = http://172.18.128.109/identityauth_type = password[certificates]ca_private_key_passphrase = foobarca_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.pembase_path = /var/lib/octaviabase_cert_dir = /var/lib/octavia/certsconnection_max_retries = 1500                 # 验证 Amphora 是否正常启动的超时配置connection_retry_interval = 1rest_request_conn_timeout = 10rest_request_read_timeout = 120[controller_worker]amp_boot_network_list = 6fd0afdc-c683-4157-8354-dcdd43011dad    # Step 5 创建的 LB Networkamp_image_tag = amphora                                         # Step 9 制作的镜像 tagamp_secgroup_list = d4d7a2bb-efc4-4a0f-bb6b-efcc6f9797d3        # lb-mgmt-sec-grp IDamp_flavor_id = 0b8517a7-0a9c-4d66-b9f1-60afd2e3061c            # Amphora Flavoramp_image_owner_id = 542a9377317a4fe081c9bac54780eb75           # Amphora Image Owner IDamp_ssh_key_name = octavia_ssh_key                              # Amphora Key Pairnetwork_driver = allowed_address_pairs_drivercompute_driver = compute_nova_driveramphora_driver = amphora_haproxy_rest_driverworkers = 2amp_active_retries = 100amp_active_wait_sec = 2loadbalancer_topology = ACTIVE_STANDBY                          # 启动主备模式 Amphora[task_flow][oslo_messaging]topic = octavia_provrpc_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:11211cafile = /opt/stack/data/ca-bundle.pemproject_domain_name = Defaultproject_name = adminuser_domain_name = Defaultpassword = adminusername = adminauth_type = passwordauth_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.servicesystemctl start octavia-worker.servicesystemctl start octavia-health-manager.servicesystemctl start octavia-housekeeping.service

Step 14. 添加 Load Balancers 页面

# Pike 版本依旧使用 neutron-lbaas-dashboardgit clone https://github.com/openstack/neutron-lbaas-dashboard.git -b stable/pikepip 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 compresssudo 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-balancerrequest_poll_timeout = 3000# /etc/neutron/neutron_lbaas.conf[DEFAULT][certificates][quotas][service_auth]auth_version = 2admin_password = adminadmin_user = adminadmin_tenant_name = adminauth_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 = nobodyinterface_driver = openvswitchovs_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 timeRECLONE=no#OFFLINE=True# Enable LoggingDEST=/opt/pikeLOGFILE=$DEST/logs/stack.sh.logVERBOSE=TrueLOG_COLOR=TrueSCREEN_LOGDIR=$DEST/logs# Define images to be automatically downloaded during the DevStack built process.DOWNLOAD_DEFAULT_IMAGES=FalseIMAGE_URLS="http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img"# use TryStack git mirrorGIT_BASE=http://git.trystack.cnNOVNC_REPO=http://git.trystack.cn/kanaka/noVNC.gitSPICE_REPO=http://git.trystack.cn/git/spice/sice-html5.git# CredentialsADMIN_PASSWORD=adminDATABASE_PASSWORD=$ADMIN_PASSWORDSERVICE_PASSWORD=$ADMIN_PASSWORDRABBIT_PASSWORD=$ADMIN_PASSWORDSERVICE_TOKEN=$ADMIN_PASSWORD## NeutronENABLED_SERVICES+=,q-lbaasv2ENABLED_SERVICES+=,octavia,o-cw,o-hk,o-hm,o-apienable_plugin neutron-lbaas https://git.openstack.org/openstack/neutron-lbaasenable_plugin octavia https://git.openstack.org/openstack/octaviaenable_plugin neutron-lbaas-dashboard https://github.com/openstack/neutron-lbaas-dashboarddisable_service n-netenable_service q-svc q-agt q-dhcp q-l3 q-meta neutronenable_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 从外网进行访问。

同时还会自动创建 VIP(Amphora 实例)的安全组 lb-<LoadBalancerID>,因为上面设定的 Listener 监听 HTTP Port: 80,所以会自动添加 80(HTTP) 规则。但如果想 Ping VIP 的话,还需要手动添加 ICMP 规则了。

$ 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 中最重要的几个服务进程

# HAProxyusr/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.sh  interval 5  fall 2  rise 2}vrrp_instance 09f967f9355b498cb56f11d5bfe32f19 { state BACKUP                  # 该 Amphora 充当 Backup 路由器 interface eth1                # VIP 对接 Subnet virtual_router_id 1           # VRID priority 90 nopreempt garp_master_refresh 5 garp_master_refresh_repeat 2 advert_int 1 authentication {  auth_type PASS  auth_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_lb1global    daemon    user nobody    log /dev/log local0    log /dev/log local1 notice    stats socket /var/lib/octavia/b45ed46d-ec04-421b-a0e0-a3268ccea61e.sock mode 0666 level userdefaults    log global    retries 3    option redispatch    timeout connect 5000    timeout client 50000    timeout server 50000peers b45ed46dec04421ba0e0a3268ccea61e_peers    peer qenPC2HfzYBAclR9HimRSWmYznU 192.168.0.10:1025    peer yKL51Z6MZq1lHKxajQ4sXXuWZmM 192.168.0.16:1025frontend b45ed46d-ec04-421b-a0e0-a3268ccea61e             # 前端服务器    option httplog    bind 192.168.0.3:80                                   # 前端服务器绑定 VIP    mode http    default_backend 209f2923-f8b1-476b-80e9-6ac2a5145ca1  # 默认后端服务器backend 209f2923-f8b1-476b-80e9-6ac2a5145ca1              # 后端服务器    mode http    balance 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,用户业务云主机 instance1    server 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-6ac2a5145ca1    mode http    balance source    timeout check 5s    option httpchk GET /api    http-check expect rstatus 200    server 34e36204-48dc-4c2c-95dc-bb9e6a3f9fbd 192.168.0.8:80 weight 1 check inter 5s fall 3 rise 3    server 97cba054-4f8c-4a9f-91e2-56973efcb417 192.168.0.9:80 weight 2 check inter 5s fall 3 rise 3

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

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

> 总结

除了上述提到功能之外,Ocatvia 还支持,或者说 HAProxy + Keepalived 还支持许多更加精彩的功能,比如:最大连接数、会话保持类型、附加 HTTP Header 字段、TLS Termination、L7 策略动作类型、L7 规则类型等等。但碍于篇幅太长的原因,只好且听下回分解了。不过毋容置疑的是,Octavia 项目的独立,绝对算得上是一个明智的选择,Octavia 的前方是星辰大海。

>  关于作者:飓风,九州云(99Cloud)OpenStack 研发工程师,曾先后服务于 Windows Azure、Redhat OpenStack 与 Prophetech HyperMotion,专注于探索云计算与边缘计算的深度结合应用场景。

> >  关于『 Linux宝库 』:欢迎关注『Linux宝库』微信公众号,这里每天发布最新的开源人物和开源事件。谨以此号记录Linux和开源业界的点点滴滴,为开源爱好者和从业者点亮人生。

- END -

- 责任编辑:RAY MAN -

为开源爱好者和从业者点亮人生!

长按二维码关注我们

转载地址:https://lingyun.blog.csdn.net/article/details/107036159 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:开源之道(下)
下一篇:【精品分享】决定边缘计算未来形态的五大需求

发表评论

最新留言

逛到本站,mark一下
[***.202.152.39]2024年04月11日 09时04分58秒