OpenStack集成A10设备：a10-openstack-lbaas驱动解析与应用实践

1. 这东西到底是干什么的？

1.1 解决什么痛点

第一次听说a10-openstack-lbaas这个包，是在给一套老旧的OpenStack环境做负载均衡改造的时候。当时OpenStack平台里的云主机数量到了一定规模，业务方要求提供自动化的负载均衡能力，而不是每次手动登录A10设备去配VIP、配池子、绑后端。手工操作很容易出错，尤其是后端服务器扩容缩容的时候，配置改来改去，时间一长没人说得清设备上到底是哪套配置在跑。

a10-openstack-lbaas是A10 Networks为OpenStack Neutron LBaaS v2提供的driver，简单说就是一座桥，把OpenStack对外的负载均衡API请求，翻译成A10 ACOS设备能执行的配置指令。我见过很多人把注意力放在OpenStack侧怎么装包、怎么改配置上，实际上这个包真正解决的是“多云环境里网络配置自动化”的问题。只要OpenStack侧创建了负载均衡器，驱动就会自动在A10设备上创建对用的虚拟服务器、服务组和健康检查策略，整个过程不需要人工登录设备，后端实例上线和下线都动态感知。

1.2 整体架构与工作流程

对不熟悉OpenStack网络服务的人，我先用一句话概括整条链路：用户在Horizon或命令行执行LBaaS相关的API请求，Neutron-lbaas把请求交给driver，driver再调用A10的AXAPI把配置下发到设备。这里的a10-openstack-lbaas就处在driver层，它负责对象的映射和API调用。

这个包内部沿用了Neutron-lbaas的插件机制，就是通过setup.cfg里的entry_points注册一个Provider，比如A10NetworksDriver。一旦Neutron识别到这个Provider，创建loadbalancer、listener、pool、member、healthmonitor这些资源时，driver就会收到回调事件。

具体的工作流程一般是这样的：OpenStack API收到create请求以后，Neutron-lbaas的plugin先把请求写入数据库，然后通过driver的create_loadbalancer、create_listener、create_pool、create_member这些方法触发A10端的配置。A10返回成功以后，driver再回写状态，整个生命周期就是这样一个“双向翻译”的过程。

2. 包结构与核心语法拆解

2.1 项目目录与入口点

用pip装完a10-openstack-lbaas以后，建议直接把包目录翻一遍，这个项目源码里最能看出设计思路。目录里比较关键的几个文件包括setup.cfg、setup.py、a10_openstack_lbaas目录本身，还有a10_examples之类的示例配置。

我先看setup.cfg，入口点的注册就写在这里，类似这样：

python复制entry_points =
    neutron_lbaas.drivers =
        a10networks_driver = a10_openstack_lbaas.A10NetworksDriver

这里的重点是，Neutron-lbaas在启动的时候会扫描所有entry_points，通过名称找到对应的driver类。所以如果你改过包名或者复制了一份代码自己维护，这里的路径必须严格对应实际类所在位置，否则插件加载时会静默失败，后面日志里只会报“Provider not found”之类的模糊错误。

2.2 关键类与接口设计

真正干活的逻辑分布在几个核心模块里。a10_openstack_lbaas包的核心类包括A10NetworksDriver、A10OpenstackLBaaSObj、A10OpenstackLBaasVThunder等。

• A10NetworksDriver：全局入口，负责初始化客户端、设备映射和资源分发。
• A10OpenstackLBaaSObj：负载均衡器资源的驱动实现，负责vThunder实例的创建和删除。
• A10OpenstackLBaasVThunder：核心中的核心，已选定的vThunder设备上执行具体的虚拟服务器和池子配置。

接口设计上，这个包基本完整实现了Neutron-lbaas定义的标准方法：create、update、delete。每种资源对应一套方法，签名大致是：

python复制def create_listener(self, context, listener):
    ...

这里的context参数是OpenStack传递的请求上下文，里面能找到用户租户ID和认证信息。listener是一个字典对象，包含protocol、protocol_port、default_pool_id这些核心字段。

2.3 资源对象的属性映射

搞懂这个包，有一半功夫要花在理解属性映射上。OpenStack的listener对应A10设备上Virtual Server的Port概念；OpenStack的pool对应A10的Service Group；member就对应real server；healthmonitor则对应A10的Health Monitor配置。

举个例子，OpenStack创建一个listener的时候，protocol和protocol_port会作为创建虚服务的依据：

python复制listener = {
    "id": listener_id,
    "protocol": "HTTP",
    "protocol_port": 80,
    "tenant_id": project_id,
    "default_pool_id": pool_id,
    ...
}

在A10的设备上，这条配置会被翻译成：

text复制slb virtual-server 提取出的ip 80
  slb service-group 对应的pool信息
    port 80

这种一对多的关系需要特别注意。一个listener可以绑定一个默认pool，但listener上的policy、session_persistence这些高级特性如果配置不当，很容易导致A10设备上生成多条重复配置或者配置覆盖异常。

3. 关键参数详解

3.1 全局配置参数

配置a10-openstack-lbaas，第一个要解决的是设备连接参数。在Neutron配置文件的lbaas_agent.ini或者neutron_lbaas.conf里，你通常会看到这样一段：

ini复制[service_providers]
service_provider = LOADBALANCERV2:A10Networks:a10networks_driver:default

[a10]
a10_username = admin
a10_password = secret
a10_authtoken = 
a10_device_type = vthunder
a10_device_interface = eth0

这里有几个参数会影响整体行为。

a10_username和a10_password就是登录A10设备的凭据，但在较新版本里，推荐用a10_authtoken替代密码做认证，因为authtoken可以限制权限范围。a10_device_type的值有vthunder和hardware两种。我之前见过有人在这写错了，导致驱动一直用vThunder的管理方式去做硬件设备的ACOS分区操作，怎么连都失败。

还有一个容易忽略的参数是a10_device_interface。vThunder里通常有管理口和业务口，如果你不指定，驱动不知道把地址池绑到哪个接口上，后面创建浮动IP或Direct路由配置的时候就会报错。

3.2 设备调度与高可用相关参数

a10-openstack-lbaas支持多台A10设备的编排，所以有专门的设备池调度参数。比较常用的是：

ini复制[a10]
use_database = True
multi_tenant = True
shared_partition = False

use_database决定了驱动是否把设备信息写入OpenStack数据库。多租户环境下，multi_tenant开启以后，每个租户都会被调度到指定设备上的独立分区中，减少了租户之间的配置干扰。shared_partition设置成False，是让每个租户使用自己的分区，防止一个租户的认证信息暴露给另一个租户。

调度算法本身是通过a10_device_manager来完成的。它会把所有可用的vThunder存在一张表里，然后根据租户ID哈希决定落到哪台设备。如果想固定某几个租户走指定设备，可以通过设置device_management_url和availability_zone来打标。实际运维中，我用这个功能把核心业务和测试业务分开部署在两套vThunder上，效果比用一个大的设备池好得多，至少测试环境刷配置的时候不会影响生产VIP。

3.3 listener、pool、member、healthmonitor的字段含义

真正到资源级别，参数就更多了。直接上一段我做后端服务注册时最常用的配置参考：

• listener：protocol（TCP/HTTP/HTTPS）、protocol_port、load_balancer_id、default_pool_id、default_tls_container_ref（HTTPS用）、connection_limit。
• pool：protocol（这个字段必须是TCP或HTTP的实际转发协议，不是listen协议）、lb_algorithm（ROUND_ROBIN、LEAST_CONNECTIONS、SOURCE_IP）。
• member：address（后端服务器IP必须是能通向A10接口的地址）、protocol_port、weight、subnet_id。
• healthmonitor：type（PING、TCP、HTTP、HTTPS）、delay、timeout、max_retries、http_method、url_path、expected_codes。

这里我要专门点一下lb_algorithm参数。OpenStack侧定义的是ROUND_ROBIN，但A10设备上叫round_robin，中间是下划线分隔，驱动会做字符串替换。如果在自定义代码里直接调用A10的API，拼法不一样就会报参数不合法。这种“大小写和分隔符不一致”的问题，是接线排查时最常见的坑。

healthmonitor的delay、timeout、max_retries三个参数有一个约束关系：timeout必须小于delay乘以max_retries，否则健康检查的判定逻辑会出现矛盾，比如一次探测超时的时间比整个检测周期还要长。A10端会直接拒绝这种配置，OpenStack侧会显示“Monitor configuration invalid”之类的原因，其实原因很简单，就是参数不合理。

4. 实际应用案例：一套Web应用集群的自动编排

4.1 场景定义

我拿一个实际做过的案例来说。某业务方有一套Web集群，前端两台Nginx，后端四台Tomcat，跑在OpenStack云主机里。原来的架构是运维手动登录vThunder配置虚拟服务器，每次发布新版本要手动摘除后端、等启动后再挂回去，全程大概 40 分钟，还容易漏改配置文件。

引入a10-openstack-lbaas之后，业务方直接用OpenStack API创建负载均衡器。只需要定义一个模板，每次扩容或缩容的时候，通过更新member列表就能完成后端实例的动态调整。整个过程从40分钟缩短到几秒，而且要求不高，完全靠OpenStack统一控制台就够用了。

4.2 环境准备与参数规划

这个案例里我的环境参数如下：

配置驱动时，Neutron的service_provider需要单独指定，采用独占driver而不是默认的Octavia，否则新版本的Neutron会优先加载Octavia，根本不会走到A10驱动。

ini复制[service_providers]
service_provider = LOADBALANCERV2:A10Networks:a10networks_driver:default

确认provider加载成功，可以在neutron-server日志里搜索“Loaded service provider”关键字，看到了A10Networks条目才算真正生效。

4.3 编排流程的代码化实现

资源创建顺序要严格按照依赖关系来：先创建loadbalancer，然后listener，再pool，最后member和healthmonitor。因为listener要挂在loadbalancer下，pool要挂在listener下，member必须挂在pool下。顺序反了就会报关联资源不存在。

用Python脚本调用OpenStack SDK的代码大致是这个样子：

python复制from openstack import connection

conn = connection.Connection(auth_url=args.os_auth_url,
                             project_name=args.project_name,
                             username=args.username,
                             password=args.password)

# 创建负载均衡器，指定vip_subnet_id
lb = conn.load_balancer.create_load_balancer(
    name="web-lb",
    vip_subnet_id="subnet-uuid",
)

# 等待lb状态为ACTIVE
conn.load_balancer.wait_for_status(lb, "ACTIVE", interval=5, wait=120)

# 创建listener
listener = conn.load_balancer.create_listener(
    load_balancer_id=lb.id,
    protocol="HTTPS",
    protocol_port=443,
    default_tls_container_ref="container-uuid",
    name="web-https",
)

# 创建后端pool
pool = conn.load_balancer.create_pool(
    listener_id=listener.id,
    protocol="HTTP",
    lb_algorithm="LEAST_CONNECTIONS",
    name="web-tomcat-pool",
)

# 创建后端member
for i, ip in enumerate(["10.10.1.11", "10.10.1.12", "10.10.1.13", "10.10.1.14"]):
    conn.load_balancer.create_member(
        pool_id=pool.id,
        address=ip,
        protocol_port=8080,
        weight=1,
    )

# 创建健康检查
conn.load_balancer.create_health_monitor(
    pool_id=pool.id,
    type="HTTP",
    delay=5,
    timeout=3,
    max_retries=3,
    http_method="GET",
    url_path="/healthz",
    expected_codes="200",
)

这里的wait_for_status一定要加，因为驱动下发配置到A10是同步调用，但OpenStack侧的状态更新是异步的。如果不等状态变成ACTIVE就创建listener，可能会因为loadbalancer在数据库中尚处于PENDING状态而拒绝后续操作。

4.4 在A10设备上验证执行结果

配置下发完成之后，一定要登录A10设备确认配置确实写进去了。在vThunder的命令行下，查看虚拟服务器的命令是：

text复制show running-config slb virtual-server

如果看到了OpenStack侧创建的名称和IP，再查看对应的服务组：

text复制show running-config slb service-group

你会看到pool里的成员和权重都在，健康检查策略也挂在了服务组上，这说明驱动已经把一整条链路从OpenStack对象翻译成了A10配置。

还有一个细节值得留意：A10设备上针对同一个VIP下多个listener，默认会将它们合并到一个virtual-server里，端口不同而已。比如你创建了一个80端口和一个443端口的listener，驱动在设备上会生成同一个virtual-server下的两条port配置。这样设计是对的，因为一台vThunder上虚拟服务器是网络层的概念，端口才是应用层的区分。不过，如果两个listener的protocol不同，一个TCP一个UDP，它们最终还是会拆成不同的virtual-server，因为协议不同没法合并。这个行为不要试图去改，改了反而容易触发ACOS的兼容性问题。

5. 常见问题与排查技巧

5.1 设备连接失败与认证问题

最常见的故障就是Neutron日志里出现“Unable to authenticate with device”的报错，或者连接超时。排查时先从这三方面下手：

第一，确认A10设备的管理地址和接口。如果vThunder是通过管理口提供API，从Neutron所在节点必须能ping通管理IP，且AXAPI端口（通常是443）没有被防火墙拦截。我遇到过一次Neutron节点和vThunder管理网段隔离的情况，驱动能调度成功但API一直超时，后来把路由打通才解决。

第二，确认ACOS API的认证方式。较老版本用用户名密码登录，新版本会强制推authtoken。如果配置里只写了password，而设备上启用了authtoken，请求会被拒绝。此时在a10配置里同时提供authtoken即可。

第三，确认当前登录用户在设备上的权限级别。驱动需要创建分区、创建虚服务、修改接口，如果用户只有只读权限，后面操作会失败在“No permission”一步。

5.2 成员状态不对与健康检查失效

member创建成功以后，OpenStack侧显示状态为ACTIVE，但A10设备上成员的健康检查一直显示DOWN。这个问题的排查链路比较长。

先确认后端服务器到A10设备的网络通不通。多数情况下，健康检查走的是A10的业务口，如果后端服务器和业务口二层网络之间没有打通，检查类型是PING还能通，但换成HTTP检查就会失败。其次是检查healthmonitor的url_path是否真实存在，我一直建议后端应用提供一个专门的轻量检查接口，比如/healthz，而不是直接检查根路径或某个静态页面。根路径可能被内嵌大量重定向逻辑，静态页面无法反映应用进程的真实状态。

最后一个容易忽略的点是expected_codes。如果后端接口返回的是302重定向，而你的期望值只写了200，那驱动会认为前端应用不健康。处理方式有两种：一是把expected_codes改成200,302，二是让后端检查接口避免跳转。这里我更推荐第二种，因为健康检查接口本身不应该参与业务逻辑跳转。

我建立了一个排查速查表，遇到问题可以直接对照：

5.3 驱动重载与配置漂移

OpenStack复杂环境里，Neutron-server有时会重启，驱动也会跟着重新初始化。重启之后再执行健康检查、刷新状态的时候，偶尔会出现配置漂移的情况：设备上还有这些配置，但OpenStack数据库里对应的记录已经处于DELETED状态。

这种情况我第一次遇到也很困惑。后来发现根本原因是Neutron数据库和A10设备之间没有完整的对账机制。官方驱动提供的façade接口能把设备上的配置同步回来，但不是自动执行的。我自己维护定时任务，每隔十分钟调用一次sync接口，把设备端和OpenStack端比对一遍，发现差异就在日志里打告警。对于关键业务，这个机制是必须的，否则手动在设备上改配置、或OpenStack侧误操作导致状态不一致，最终影响的都是线上流量。

6. 这个包的适用边界与替代方案

6.1 它适合谁

讲实话，a10-openstack-lbaas并不是一个开箱即用特别顺滑的包。它适合的是那些已经用了A10设备，并且OpenStack版本还停留在Neutron LBaaS时期的环境。对这类用户来说，用这个驱动把自动化带起来，是最干净利落的路子。

如果环境里没有A10设备，或者OpenStack版本已经升级到Train之后并默认使用Octavia，那就完全不需要碰这个包。Octavia有自己的provider机制，A10也有对应的Octavia provider，虽然功能路径类似，但是实现细节和LBaaS时代有差别，要按Octavia那边的文档单独配。

6.2 设计上游刃有余的小技巧

使用这个包时，我一直持有一个观点：它不是万能的配置生成器，而是一个API翻译层。它负责把OpenStack的标准资源模型翻译成A10能识别的配置，所以不要在OpenStack侧使用超出A10能力的参数。比如，OpenStack支持TERMINATED_HTTPS类型的listener，但A10设备上你必须先上传证书模板，然后驱动里还要做额外的证书映射。这个就牵扯到tls_container_ref参数，不是所有版本的驱动都支持，老版本里这个功能非常弱，我建议新部署环境选择较新的驱动版本，避免在证书绑定上反复踩坑。

另外，在线更新pool的lb_algorithm时，要特别注意旧配置的清除行为。有的版本只更新服务组算法，但不会自动清除旧冗余服务组配置，导致设备上同时存在新旧两套服务组。这种情况下，显式删除pool再重建是最好的办法，虽然有几秒闪断，但配置干净可控。

7. 后续扩展方向

用这套驱动把基础负载均衡自动化跑起来之后，可以继续做的方向还有很多。比如结合监控系统，在检测到后端实例CPU持续过高时，自动调用OpenStack API把新的云主机加入pool，实现简单的弹性伸缩闭环。

我个人实测下来的体会是，这类型驱动最怕的不是技术复杂，而是配置和状态的“双重维护”。OpenStack侧维护一份状态，物理设备侧维护一份配置，两边一旦因为网络故障或手动操作而不同步，排查成本远高于初始接入成本。所以如果你决定用这个包，建议一开始就从制度上定好：所有变更只通过OpenStack API发起，设备侧不保留任何人工修改。定好这个规矩以后，故障率会下降好几个级别。

最后再分享一个小技巧。因为a10-openstack-lbaas底层是通过AXAPI和ACOS交互的，每次API交互都会在设备日志里留下记录。如果你不确定某项参数是否真正下发成功，不要只看Neutron侧的状态，直接去A10的设备log里查configure事务，能看到每一次真正的变更内容。这套双重验证的习惯，能帮你省下大量排查时间。