如今Openstack在虚拟化管理部分已经很成熟了， 通过nova我们可以创建虚拟机、枚举虚拟设备、管理电源状态、安装操作系统等。但是有时候虚拟机无法满足要求，比如以下几种情况需要直接使用物理机：

• 高性能的计算集群
• 计算任务需要访问无法虚拟化的硬件设备
• 数据库主机（有些数据库在hypervisor中运行效率很差）
• 单租户、专用硬件、安全性、可靠性和其他控制要求
• 快速部署云基础设施

但是在物理机管理上一直没有成熟的解决方案。在这样的背景下Ironic（Bare-Metal Provisioning）诞生了，它可以解决物理机的添加，删除，电源管理和安装部署。Ironic提供了一系列常用的驱动，同时提供了插件的机制让厂商可以开发自己的driver，这让它支持几乎所有的硬件。
部署物理机跟部署虚拟机的概念在nova来看是一样，都是nova通过创建虚拟机的方式来触发，只是底层nova-scheduler和nova-compute的驱动不一样。虚拟机的底层驱动采用的libvirt的虚拟化技术，而物理机是采用Ironic技术，ironic可以看成一组Hypervisor API的集合，其功能与libvirt类似。

前世今生

最早baremetal的概念出现在nova里，物理机和虚拟机管理有很多地方非常相似，比如物理机和虚拟机都需要开机关机，安装部署，添加和删除，为了避免重复造轮子，他们在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，从Icehouse版开始进入孵化项目，并在Juno版与Nova进行集成，从完成了项目毕业评审，在Kilo版正式的集成到openstack项目中来，今后会通过nova调用Ironic的api来实现对物理机资源的管理和控制。

传统的hypervisor一般包括创建虚拟机、枚举虚拟设备、管理电源、加载操作系统等功能，与之对应，Ironic可以看成结合多个驱动提供一套hypervisor API来操作物理机提供类似操作，所以ironic可以看成一个hypervisor驱动来给Nova来用。

架构

项目组成

• ironic： 包含ironic-api 和ironic-conductor进程
• python-ironicclinet: python clinet and CLI
• ironic-python-agent: 一个运行在deployment ramdisk中的Python程序，用于执行一系列部署动作
• pyghmi: 一个python的IPMI库，可以代替IPMItool
• ironic-inspector: 硬件自检工具
• ironic-lib： ironic的通用库函数
• ironic-webclinet ：web客户端
• ironic-ui：ironic的horizon插件
• bifrost：一套只运行Ironic的Ansible脚本

概念架构（与其他组件的关系）

下图显示了在提供物理机服务时各个组件的关系。（Ceilometer和Swift能与Ironic一起使用，但是在图中没有显示）

逻辑架构（与其他组件的调用关系）

• Ironic API，一个RESTful API服务，管理员和其他服务通过API与Ironic进行交互
• Ironic Conductor， 完成Ironic服务的绝大部分工作，通过API对外开放其功能，与Ironic API通过RPC进行交互；负责与其他组件进行交互
• Dirvers，真正管理物理机的模块，通过一系列的驱动来支持不同的硬件
• Database，用来存储资源信息
• 消息队列

部署架构

云平台管理员可以使用RESTful API注册硬件，制定硬件的属性，比如MAC地址、IPMI证书。可以开启多个API服务实例。

由于Ironic Conductor是唯一一个需要访问数据层和IPMI控制层的服务，为了安全起见，最好将conductor service 放在一个独立的主机上。为了支持各类驱动和管理故障迁移，可以有多个conductor实例存在，每个conductor实例可以运行多个drivers。

消息路由

每一个Condutor实例在启动时想数据库注册自己，注册的信息包含了本实例支持的驱动列表，并且定期更新自己记录的时间戳，这就使得所有的服务能够知道哪些Condutor和哪些驱动可用。

物理机根据自己的驱动，使用一致性哈希算法映射在一组Condutor上。部署任务通过RPC从API层分发到合适的Condutor上。当Condutor实例加入或者退出集群，物理机会重新映射到不同的Condutor上，会触发驱动的多种动作，比如take-over 或者 clean-up动作。