Octavia 创建 loadbalancer 的实现与分析

目录

文章目录

• 目录
• 从 Octavia API 看起
• Octavia Controller Worker
• database_tasks.MapLoadbalancerToAmphora
• compute_tasks.CertComputeCreate & ComputeCreate
• network_tasks.AllocateVIP
• network_tasks.PlugVIP
• 最后

从 Octavia API 看起

通过 CLI 创建一个 loadbalancer：

(octavia_env) [root@control01 ~]# openstack loadbalancer create --vip-subnet-id 122056f4-0fad-4ab2-bdf9-9b0942d0b213 --name lb1 --debug

Create LB 的 Octavia API UML 图：

其中 2. _validate_vip_request_object 的细节如下 UML 图：

通过 上述 UML 图可以看出当 octavia-api service 接收到 create loadbalancer 请求后主要处理了下列几件事情：

1. 验证请求用户的身份。
2. 验证请求 VIP 及其相关对象（e.g. port, subnet, network, ）是否可用，可以通过 config secition [networking] 来配置 Allow/disallow 的网络对象。
3. 检查请求 Project 的 LB 相关 Quota，可以通过 config section [quotas] 来配置默认 Quota。
4. 准备创建 loadbalancer 数据库记录的数据结构。
5. 创建 loadbalancer 和 vip 的数据库记录。
6. 调用 Amphora driver（default lb provider）创建 VIP 对应的 port，并将 Port、VIP、LB 三者的数据库记录关联起来。
7. 以图的方式创建 loadbalancer 下属的 Listeners 和 Pools。
8. 准备传递给 Amphora driver 实际用于 create_loadbalancer_flow 的数据结构。
9. 异步调用 octavia-cw service 执行 create_loadbalancer_flow。

其中有几点值得我们额外的注意：

• 通过 networking 和 quota 用户可以限制 LBaaS 的资源范围，e.g. loadbalancer 的个数、listener 的个数 etc… 甚至可以规定使用的 VIP 列表和 VIP 只能在规定的 network/subnet 中创建。

• 虽然 CLI 并没有给出类似 --listeners or --pools 的选项让用户传递 loadbalancer 下属 Listeners 和 Pools 的 body 属性，但实际上 POST /v2.0/lbaas/loadbalancers 的视图函数时可以处理这两个参数的。所以在 UI 设定的时候可以完成 CLI 不支持的一次性创建 loadbalancer、listener 及 pool 的操作。

• 创建 loadbalancer 时，如果 VIP 的 port 不存在，那么 octavia-api 会调用 neutronclient 创建，命名规则为 lb-<load_balancer.id>，所以你会在 VIP 的 network/subnet 中看见类似的 Port。

Octavia Controller Worker

这是一个典型的 taskflow 外层封装，从 get flow、prepare flow store、get flow engine 到最后的 run flow。其中最核心的步骤是 3. self._lb_flows.get_create_load_balancer_flow，想要知道创建 loadbalancer 都做了些什么事情，就要看看这个 Flow 里面都有哪些 Task。

这里我们主要关注为 loadbalancer 准备 Amphora 和 Amphora 的 Networking Setup。

为 loadbalancer 准备 Amphora 的 UML 如下：

为 loadbalancer 准备 Amphora 的过程中有几点值得我们注意：

• 如果配置 [controller_worker] loadbalancer_topology = ACTIVE_STANDBY 时，可以结合 [nova] enable_anti_affinity = True 反亲和性进一步提高 loadbalancer 的高可用性。
• 为 loadbalancer 准备 Amphora 并非每次都是通过 create amphora 来实现的，flow 会先检查是否存在可以映射到 loadbalancer 的 Amphora instance，如果存在就直接映射给 loadbalancer 使用。如果不存在才会启动创建 Amphora instance 的任务流，这里需要配合 housekeeping 机制来完成。housekeeping 会根据配置 [house_keeping] spare_amphora_pool_size=2 来准备 spare Amphora instance pool，加速 loadbalancer 的创建流程。
• 创建 Amphora 使用的是 graph flow（图流），图流的特性就是开发者可以自定义条件来控制任务的流向，amp_for_lb_flow.link 就是设定判断条件的语句，这里的判断条件设定为了：如果为 loadbalancer mapping Amphora instance 成功就直接修改数据库中相关对象的隐射关系，如果 mapping 失败则先创建 Amphora instance 之后再修改数据库中相关对象的隐射关系。

为 loadbalancer 的 Amphora 准备 networking 的 UML 如下：

从 UML 可以见 Amphora 的 Networking 主要的工作是为 Amphora 的 Keepalived 设定 VIP，过程中会涉及到大量的 octavia-cw service 与 amphora agent 的通信。后面我们再继续深入看看关键的 Task 中都做什么什么事情。

再继续看看当 listeners 参数被传入时的 flow 是怎么样的：

创建 Listener 实际上就是更新了 Amphora 内 HAProxy 的配置信息，所以可见上述最重要的 Task 就是 amphora_driver_task.ListenersUpdate。

自此整个 create loadbalancer 的 flow 就都看完了，接下来我们继续深入到一些关键的 Task 里，看看都做了什么事情。

database_tasks.MapLoadbalancerToAmphora

为 loadbalancer 创建 amphora 时首先会尝试 Maps and assigns a load balancer to an amphora in the database，如果 mapping SUCCESS 则会 return amphora uuid 否则为 None。graph flow 类型的 amp_for_lb_flow 就是通过这个 return 来作为任务流向控制判断条件的。

if None:
    create_amp
else:
    map_lb_to_amp

compute_tasks.CertComputeCreate & ComputeCreate

Task CertComputeCreate & ComputeCreate 都是创建一个 amphora instance，通过配置项 [controller_worker] amphora_driver 进行选择。当 amphora_driver = amphora_haproxy_rest_driver 时使用 CertComputeCreate，octavia-cw service 与 amphora-agent 之间通过 HTTPS 进行安全通信；当 amphora_driver = amphora_noop_driver 时使用后者，但 amphora_noop_driver 一般被用作测试，可以忽略不计。

            compute_id = self.compute.build(
                name="amphora-" + amphora_id,
                amphora_flavor=CONF.controller_worker.amp_flavor_id,
                image_id=CONF.controller_worker.amp_image_id,
                image_tag=CONF.controller_worker.amp_image_tag,
                image_owner=CONF.controller_worker.amp_image_owner_id,
                key_name=key_name,
                sec_groups=CONF.controller_worker.amp_secgroup_list,
                network_ids=network_ids,
                port_ids=[port.id for port in ports],
                config_drive_files=config_drive_files,
                user_data=user_data,
                server_group_id=server_group_id)

这里调用了 novaclient 的封装来创建 amphora instance，其中 image、flavor、sec_groups、keypair 均在配置 [controller_worker] 中定义了。需要注意的是 config_drive_files 和 user_data 两个形参就是为了 amphora instance 启动时为 amphora-agent 注入证书的参数项，应用了 Nova Store metadata on a configuration drive 机制。

config_drive_files = {
            '/etc/octavia/certs/server.pem': server_pem,
            '/etc/octavia/certs/client_ca.pem': ca}

network_tasks.AllocateVIP

Task AllocateVIP 实际调用了 octavia.network.drivers.neutron.allowed_address_pairs:AllowedAddressPairsDriver.allocate_vip method，return 的是一个建立了 Port、VIP 和 LB 三者关系的 data_models.Vip 对象。该 method 在 octavia-api 已经被调用过一次了，所以到此时 VIP 的 Port 一般都已经存在了，只需要返回一个 data object 即可。然后在通过 Task UpdateAmphoraVIPData 落库持久化。

network_tasks.PlugVIP

Task PlugVIP 是实际为 Amphora instance(s) 设定 VIP 的。

在 PlugVIP 的过程中需要注意几点：

• 在创建 Listener 时都会 update VIP port 的 security_group_rules，因为 Listener 是依附于 VIP 的，所以 Listener 监听的协议端口都应该在 VIP 的安全组上打开，并且关闭不必要的端口。
• PlugVIP 会轮询检查所有 loadbalancer.amphora 是否具有 VIP 对应的 Port，如果没有则会创建出来，设定 VIP 再挂载到 Amphora instance 上。

NOTE：VIP 是 Act/Stby topo Amphora 的虚拟 IP。

最后

至此 Octavia 创建 loadbalancer 的流程就分析分完了，总的来说一图顶千言，还是希望通过 UML 图来描述主要流程再辅以文字说明关键点的方式来进行介绍。