OpenStack之Provisioning Blocks管理复杂对象的状态

云计算 专栏收录该内容
40 篇文章 0 订阅

我们使用对象的STATUS字段表示资源是否可用,如果设置为ACTIVE,外部系统认为可以安全的使用此资源。如果仅有一个实体负责配置(provisioning)给定的对象,很容易知道合适将status设置为ACTIVE。当实体完成配置(provisioning),我们就更新STATUS到ACTIVE。尽管如此,在Neutron内部由许多资源需要在可用之前由多个异步的实体进行配置(provisioning),所以管理status到ACTIVE状态的转变变得更加复杂。为处理此情况,Neutron增加了 provisioning_blocks 模块用于跟踪正在配置(provisioning)资源的实体。

ML2模块中的主要示例是:L2 agents 和 DHCP agents。当port被创建并绑定到主机时,它处于DOWN状态。L2 agent需要为port建立流flows,安全组规则等,DHCP agent需要建立port的IP和MAC地址的预留绑定。在转到ACTIVE之前,两个agent必须完成他们的工作,或者port的使用者(如 Nova)可能尝试使用此port,而得不到连通性。为解决此问题,provisioning_blocks模块用来跟踪每个agent的配置(provisioning)状态,对象的status只有在两个agent完成时才会更新。

High Level View

要使用provisioning_blocks模块,即当对象的status转换为ACTIVE之前,需要另外的实体完成工作,必须添加配置(provisioning)组件。通过为每个实体调用方法add_provisioning_component来实现。当每个实体完成配置(provisioning)对象后,provisioning_complete被调用移除配置(provisioning)块。

当最后一个配置块被移除后,provisioning_blocks模块将触发回调通知,其中包含对象资源类型的对象ID,事件为PROVISIONING_COMPLETE。此事件的订阅者现在可更新对象的status到ACTIVE状态,或者执行其它需要的动作。

通常的状态转变过程如下:

  1. 请求创建对象
  2. Neutron服务器逻辑决定哪些实体需要去配置(provision)此对象,并为此对象的所需实体添加配置(provisioning)组件
  3. 发送通知到实体,以便它们开始工作.
  4. 对象返回给API调用者,status为DOWN(或 BUILD)状态.
  5. 每个实体在完成对象配置(provisioning)之后通知服务器。Neutron服务器为每个完成的实体调用provisioning_complete
  6. 当为最后一个实体调用了provisioning_complete之后,provisioning_blocks模块将发出表示对象以及配置(provisioning)完成的事件。
  7. 服务器上的此事件订阅者将更新对象的status到ACTIVE状态,表示它已经配置完成

关于更精确的示例,参见以下章节.

ML2, L2 agents, 和 DHCP agents

ML2使用provisioning_blocks模块防止在L2 agent和DHCP agent完成port连接工作之前,将port的status转换到ACTIVE状态。

当port创建或更新,以下步骤注册DHCP agent的配置(provisioning)块:

  1. 从port的fixed_ips字段抽取出来 subnet_ids,之后ML2检查DHCP是否在其中的subnet上启用。
  2. 查找承载网络的DHCP agent配置以确保至少有一个足够新的可报告其完成了port预留。
  3. 以上的两个条件有一个失败的话,DHCP agent的配置(provisioning)块将不会添加,并且任何现存的阻塞此port的DHCP agent将被清除,以保证port不会阻塞在等待一个不会发生的事件。
  4. 如果以上的条件成立,port的配置(provisioning)块被添加在“DHCP”实体下。

当port创建或更新,以下步骤注册L2 agent的配置(provisioning)块:

  1. 如果port没有绑定,不做任何事,因为我们还不知道是否会涉及到L2 agent,所以必须等待绑定端口的更新.
  2. 一旦port绑定,基于agent的mechanism驱动将检查绑定主机上是否存在agent,VNIC类型是否属于mechanism驱动,port的配置(provisioning)块被添加在“L2 agent”实体下.

一旦DHCP agent完成预留的建立,它通过带有port ID的RPC API调用dhcp_ready_on_ports。DHCP RPC处理器接收到,调用配置(provisioning)模块中的“provisioning_complete”,带有port ID,并且“DHCP”实体去删除配置(provisioning)块。

一旦L2 agent完成预留的建立,它通过RPC API调用正常的update_device_list(如,update_device_up)。RPC回调处理器带有port ID调用“provisioning_complete”,“L2 agent”实体删除配置(provisioning)块。

当"provisioning_complete"调用删除最后一个记录后,provisioning_blocks模块发出回调PROVISIONING_COMPLETE事件,与port ID一起。ML2中订阅此事件的方法调用update_port_status设置port的状态到ACTIVE

此时正常的通知发向Nova,以允许VM继续运行。

在DHCP或者L2 agent 进入关闭状态的事件中,port将不转换到ACTIVE状态(如L2 agent关闭)。agent必须考虑这种情况,通知服务器在启动过程中进行了所有配置之后连线已经完成。这保证了创建于离线的agent(agents崩溃或重启)的port最终可变为ACTIVE。

考虑到服务器不稳定,有关端口连线的通知必须使用RPC调用,以便agent从服务器获得确认,它必须一直重试,直到端口被删除或成功。

如果ML2驱动程序快速将绑定端口置于ACTIVE状态(例如,在调用update_port_postcommit的后端之后),此修补程序不会对这个过程产生任何影响。

  • 1
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值