Ironic , Openstack Baremetal Hypervisor

Ironic , Openstack Baremetal Hypervisor，首发于UnitedStack Inc.。

转自： http://ju.outofmemory.cn/entry/48769

如今Openstack在虚拟化管理部分已经很成熟了，通过nova我们可以创建虚拟机，虚拟磁盘，管理电源状态，快速通过镜像启动虚拟机。但是在物理机管理上一直没有成熟的解决方案。

在这样的背景下Ironic诞生了，它可以解决物理机的添加，删除，电源管理和安装部署。Ironic最大的好处是提供了插件的机制让厂商可以开发自己的driver，这让它支持几乎所有的硬件。

Ironic的前世和今生

最早baremetal的概念出现在nova里，最早的blueprint是由USC/ISI以及 NTT-Docomo提出并实现的，其中NTT-Docomo是一家日本公司，而USC/ISI是一家研究HPC的教育机构。

物理机和虚拟机管理有很多地方非常相似，比如物理机和虚拟机都需要开机关机，安装部署，添加和删除，为了避免重复造轮子，他们在nova中实现了一个物理机的driver，这样把物理机管理做为计算资源管理的一个子集了。后来发现这样做有问题：

早期baremetal作为一个driver有自己的数据库，同一个项目中有两套数据库不合适。
在部署和管理baremetal的过程中有很多需要存储的信息是和部署管理虚拟机是不同的，通过nova api来获取这些信息比较尴尬，把baremetal剥离出来有助于划清baremetal和虚拟机部署的界限。
有时候baremetal需要做一些比较特殊的行为，比如discovery, hardware raid configuration, firmware updates, burn-in这些操作，它们不适合放在nova里面。比较好的办法是当完成这些操作的时候，向nova去注册信息，作为nova中的可用的资源，最后通过nova boot去调用这些资源。

经过很多次讨论，社区把bare metal分离出来了, 命名为用Ironic，今后会通过nova调用用Ironic的api来实现对物理机资源的管理和控制。

具体的讨论内容如下：

Openstack Nova baremental 部署数据流

我们可以看到数据流从nova boot开始，当用户执行nova boot的时候nova api 会通过message queues来通知nova-scheduler，通常message queue是rabbitmq。
nova-schedule收到baremetal boot请求的时候会去找是否有可用的Baremetal Node。
如果有可用node，nova-scheduler就会通过RPC call nova-compute，根据baremetal driver调用driver.spawn()来启动物理机。
nova-compute通过baremetal database可以获取已经注册节点的信息。
通过刚才从数据库中得到的节点信息，nova-comupte在quantum中配置VIFs。
配置完VIFs，nova-compute开始从glance中下载镜像。
然后nova-compute把需要安装的机器对应的bootloader激活。
通过IPMI 启动电源。
开机以后通过PXE启动到bootloader镜像下，自动暴露ISCSI，然后直接通过nova-baremetal-deploy-helper把镜像写到机器上去。
重启机器。
更新机器状态。
更新数据库中目标物理机状态。

Openstack Ironic 部署数据流

我们可以看到数据流从nova boot开始，当用户执行nova boot的时候nova api 会通过message queues来通知nova-scheduler，通常message queue是rabbitmq。
nova-schedule收到baremetal boot请求的时候会去找是否有可用的Baremetal Node。
如果有可用node，nova-scheduler就会通过RPC call nova-compute，根据baremetal driver调用driver.spawn()来启动物理机。
nova-compute通过Ironic API 可以获取已经注册节点的信息。
通过刚才通过Ironic API获取到节点信息，nova-comupte在neutron中配置VIFs。
配置完VIFs，nova-compute通过刚才获取的信息开始从glance中下载镜像。
Nova compute 通过Ironic API 发出一些请求来部署节点。
一部分请求通过Ironic Conductor来调用PXE Dirver中的deploy方法来激活bootloader。
另一部分请求通过 Ironic Conductor来调用IPMI Dirver让目标机器重启。
机器重启到Bootloader镜像通过client和Ironic-Deploy-Baremetal-Helper取得联系让helper通过ISCSI把镜像写到物理机上。
写完以后reboot目标物理机。
更新数据库中目标物理机状态。

Ironic中硬件异构是通过写多个dirver的方式去解决的，而且每一台节点后端可以有不同的driver。

大家可以看上图中Ironic中driver的架构，每一个driver可以实现4类功能。

deploy：实现把镜像部署到物理机中。
power：实现对物理机电源的管理。
console：实现通过硬件直接得到物理机Console。
vendor：厂商自定义行为。

1-3的功能可以完成大家90%以上的常用需求，而4可以完成硬件定制物理机管理过程的需求。

Ironic社区现状和总结

从上面的分析可以看到Ironic的结构良好，设计优雅，并且通过厂商自定义driver的机制来解决一直以来业界没有解决的厂商硬件异构的问题，前景非常好。

由于开发时间比较短，因此到目前为止，项目尚未开发完成，目前整体还不可用，如果你是用户可能还需要等上一段时间，如果你是开发者，请加入社区，为社区贡献一份力量。http://docs.openstack.org/developer/ironic/

Ref

Openstack Baremetal官方Wiki https://wiki.openstack.org/wiki/Baremetal
Ironic PTL Devananda Slides http://www.slideshare.net/devananda1/ods-havana-provisioning-bare-metal-with-open-stack
Ironic官方Wiki https://wiki.openstack.org/wiki/Ironic
Ironic git仓库 https://github.com/openstack/ironic
Nova Baremetal 分离为 Ironic的会议 http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-05-07-20.01.html