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 图来描述主要流程再辅以文字说明关键点的方式来进行介绍。