openstack中VM启动流程图

点击打开链接


The OpenStack architecture consists of multiple distributed services which often work together to carry out a single logical operation. Given the nature of this architecture, getting up to speed on the call flows and interactions can be a daunting task for developers and operational admins alike.

Not so long ago, I had to pleasure of digging into one of the more common flows in OpenStack nova compute -- the nova 'boot server' operation. As we all know the boot server operation provisions a new nova compute Virtual Machine (VM) on an underlying hypervisor such as KVM, ESXi, etc.. As part of the boot server operation, a number of OpenStack components are involved including:

  • REST API controllers.
  • The nova compute scheduler.
  • Nova compute manager and virt driver (a per hypervisor component).
  • Numerous OpenStack clients which interface with other OpenStack services (glance, neutron, etc.).
  • Conductor for database persistence.
  • RPC via AMQP.
  • etc..


For a single boot server operation consider some of the high level logistics which must be carried out:

  • A REST API controller must validate, sanitize and initiate a request operation.
  • An initial 'shell' server must be persisted in the database (the operation is mostly async and thus a 'shell' server response must be returned to caller so they can poll status).
  • The scheduler must choose and reserve a hypervisor / host for the provision operation.
  • A VM image must be downloaded from glance (if not already cached on the hypervisor) to boot the server from.
  • Volumes must often be allocated and realized from OpenStack Cinder.
  • Network related aspects must be allocated and realized.
  • The VM must be booted, prepped and plugged (volume(s), network info, etc.).

The list given above is a very abstract and simplistic view provided to illustrate the complexity and breadth of operations which must occur to fulfill a single request. For this reason I found it easiest to visualize the components and interactions using a diagram which is provided below.

The ad-hoc diagram below depicts the high level call flow of an OpenStack nova compute 'boot server' operation. In this diagram each of the boxes illustrate a major component of OpenStack and the lines represent interactions between components.  This diagram is not intended to show each and every interaction / operation, however it provides incite into the major operations and interactions which occur to full the provisioning of a new nova VM. Finally note this diagram was constructed in late July of 2013 and thus reflects the state of OpenStack at that point in time -- internals may have shifted.


Legend: Component (box) color coding
Box Color
Component Type
Yellow
Controller classes for nova API
Pink
Nova scheduler classes
Green
Nova manager (framework) classes
Cyan
Nova virt driver (implemented per hypervisor type)
Grey
Clients used by the various nova classes to interface with other services via REST API
Red
Other OpenStack services



Legend: Interaction (line) color coding
Line Type
Interaction Type
Solid black
Python API call
Black dashed
REST API call
Reddish solid
AMQP

Diagram: OpenStack nova compute 'boot server' call flow





评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值