在其字面意义上更强调了它是一种未安装操作系统或者刻意剥离操作系统的一种概念，更确切的表面他是CPU、RAM、local_gb的计算资源产品集合。

1、Ironic项目和组件介绍

Ironic是OpenStack中专注于裸金属管理和系统推送的项目，它的很多设计也是遵循了OpenStack其他项目的逻辑，主方向便是建立一个基于裸金属服务的IaaS云服务，裸金属服务对比虚拟化服务主要面对以下需求：

• 高性能计算

• 需要直接访问硬件的计算服务

• 部分无法运行在虚拟化云服务中的数据库

• 单租户访问计算资源、安全、性能等要求不可共享硬件资源、可信需求或者其他管理型要求

• 需要快速部署一个云服务的基础设施需求

Ironic在资源管理和上层用户端接入上有三种方式:

1. 以虚拟化接口主线的方式（nova）接入Ironic：Ironic以一个virt driver形式接入nova实例管理解决方案中，此种方式优势是其方案中组件接入齐全，上层提供的功能较多，特别是对于完全可兼容共存OpenStack的虚拟化方案。
2. Ironic standalone（Bifrost）：以不依赖其他组件方式如nova、glance、neutron、keystone，构建完整的裸金属管理部署平台，此种方式更多是对裸金属的部署做管理。
3. Mogan：OpenStack专注于裸机云的子项目，平级于1）中的nova子项目，它的目的是为了解决nova在接口层面以虚拟化为默认特性对外暴露资源而造成的支持兼容度，这个项目比2）中的Bifrost功能更加全面，同时可以接入OpenStack其他项目如neutron、cinder、glance等。

以上的三种方式更多是强调了裸金属实例的管理实现，更多的是对于Ironic的上层功能封装，这里不再详细说明。

Ironic项目包含了以下几个组件，分别用于裸金属在不同阶段中的事物处理：

其中Ironic组件是整个Ironic项目中的核心组件，它是裸金属管理的唯一接口，其他组件都是辅助Ironic对于裸金属生命周期管理的完善工具，需要强调的是，对于Ironic的driver选择不同以及用户层逻辑选的区别，以上出Ironic组件之外并不是所有组件都是裸金属生命周期管理所必须的。

如同OpenStack其他组件一样，Ironic在上层规定了裸金属的数据关联模型、裸金属行为策略以及驱动实现，以下会按照这三个部分做详细解说。

2、Ironic的数据关联模型

在Ironic中直接对于裸金属管理node信息，他是裸金属管理信息的数据体现，如裸金属本身的硬件信息、配置信息、Ironic对裸金属控制的相关driver信息等，而以Ironic node实体数据信息为核心，组成了以下的数据关联信息：

• chassis: 裸金属模板，它是以中笼统概念，主要用于node的管理分类；

• node: 裸金属基础信息包括CPU、存储等信息，同时ironic管理每一个裸金属所使用的driver都存储在此数据模型中；

• port: 标识裸金属网口基础信息，如mac地址、lldp信息；

• portgroup: 在实际裸金属环境中其上联交换机对于网口配置端口组，此项数据模型便是标识交换机端口组配置；

• conductor: 记录ironic conductor状态和支持driver数据模型；

• volume connector/target: 这是记录裸金属的块设备挂载信息，用于裸金属挂载块存储的数据信息；

如前文介绍，ironic组件在服务层面分为ironic-api和ironic-conductor，前者主要负责处理rest和数据层面的请求后者主要负责执行裸金属行为管控和具体driver的逻辑处理，二者依赖于消息队列通讯。因为ironic-conductor和其所支持的driver有对应关系，所以根据节点的配置不同，不同节点上的ironic-conductor服务器所支持的driver也不尽相同。

在用户注册ironic node数据信息时都是需要指定driver，ironic会根据注册信息将node分配到支持对应driver的ironic-conductor服务之中，对于多个conductor和多个node之间的关联，由于需要做到有状态管理和避免管理冲突问题，ironic使用了一致性hash算法。

裸金属node conductor一致性hash关联示意图

通过以上的数模型，Ironic从数据层面将裸金属纳管关系建立如下示意：

裸金属node conductor关联示意图

3、Ironic的状态机管理

如同其他的OpenStack组件一样，Ironic在接口层面定义了一套通用的管理、系统部署流程，用于规范裸金属纳管、部署过程中的行为。目前Ironic主要包含三大状态机流程， Inspection、Provision和Clean，每个子状态机相互独立又相互关联，囊括裸金属生命周期管理的所有流程。

4、Inspection阶段

在Ironic向用户提供裸金属服务过程中，需要很多的裸金属数据需要录入其db中，以便完成它的各项操作需求， Inspection阶段便是满足此部分要求而设计的自动检测流程，从而可以尽量减少用户、运维人员的数据录入工作。同时，Ironic项目提供了Ironic-inspector组件辅助此过程的数据处理，可以做到数据处理的最大化可控，当然基于driver 的选择不同，此组件也可弃用。

默认情况下，用户需要注册裸金属node信息到Ironic服务之中，开始裸金属整个生命周期的纳管开始，可以理解为【数据录入】-> 【运维管理】-> 【数据检测】-> 【节点可用】，以下是具体状态图。

Ironic Inspection状态机

• enroll: 所有的裸金属node信息注册到Ironic时，都会以一个【enroll】状态展示数据，此时的裸金属数据仅仅代表一条数据；

• verifying: 如上在用户确认录入裸金属信息完毕后并无误后，发起【manage】请求，Ironic会依赖用户录入信息做依赖数据校验，以确认用户录入数据是否满足下一步操作要求，即可管理，如带外观信息、以及其对应的用户名、密码是否正确等；

• manageable: 裸金属node管理状态，是裸金属数据维护的一个中间状态；

• provide: 此动作是在用户准备好裸金属的全部数据后的向裸金属计算资源使用用户提供资源指令，意在告诉Ironic此部分裸金属已经准备好，可以部署操作系统（这里中间涉及到一个cleaning状态机，因为它并不是强制使用且后面会有详细解释，这里不再详述）；

• available: 此状态裸金属便是一个【可用】状态的，用户可以随意使用，此时裸金属的基础信息如CPU核数、ram、disk大小、物理网口等信息应当全部录入完毕；

• inspecting: 此状态机操作是Ironic为了完善裸金属信息录入而设置的一个自动化数据检测和录入过程，主要是为了将CPU核数、ram、disk大小、物理网口等硬件信息这些无需用户手动录入的信息自动化。

5、Provision阶段

此阶段是裸金属操作系统部署过程的一个描述，用户可以通过provision/rebuild指令发起部署，再次之前用户需要按照一定格式将部署参数patch到Ironic数据库之中，如user-image、tenant-work、configdriver等。

具体的状态机：

Ironic Provision状态机

如上所述，需要部署一台裸金属，其状态机必须处于【available】

• available: 针对一个处于【available】状态的裸金属发起部署请求，在此操作之前需要将裸金属需要部署的操作系统信息注入裸金属数据库中，如user-image、instance metadata、网络资源分配等；

• deploying: 裸金属准备部署阶段，在此刻ironic会主动cache ramdisk到ironic conductor并实施开启动作（如果裸金属服务器在开启状态即执行重启动作）；

• wait callback: 裸金属服务在完成启动或者重启动作，ironic根据不同的driver策略控制裸金属进入操作系统引导，其中pxe是其默认的引导方式，在这个阶段ironic会等待裸金属服务器引导进入ramdisk，ramdisk会默认启动ironic-python-agent并回调Ironic，告知裸金属已经进入ironic-python-agent的控制，可以发送注入user-image指令，并监控注入进度；

• deploying: 待镜像注入完成后，Ironic需要控制裸金属进入user-image，并完成控制层面数据维护；

• active: 此状态即代表裸金属操作系统推送完成，需要强调的是此过程类似nova libvirt过程，其状态active并不代表其操作系统加载完成，特别是裸金属服务器在开启过程时间较长，所以此过程尤为明显。

6、Clean阶段

在Inspection阶段提到裸金属在provide动作时有可选的cleaning状态机动作，便是进入此阶段的动作。由于ironic的裸金属定义是为用户提供一个基于物理化的云主机，所以在向用户提供裸金属计算资源时，配置统一、无非必要数据残留的计算资源对于一个云平台是非常重要的，尤其是在裸金属不断在被不通用户循环租赁的情况下。

Ironic针对以上情况定义了一个clean过程，旨在对于裸金属的配置、数据清理做一个统一可扩展的流程。通过这一套流程，用户可以指定需要清理的过程如抹盘、raid配置、bios设置等以及这些过程优先级排序。具体状态机流程如下：

Ironic Clean状态机

前面在裸金属Provision阶段，已经介绍了在用户发起provide动作时，ironic会判断是否需要自动为需要available的裸金属自动做clean，这个判断依据便是裸金属自动clean配置，如果用户在配置ironic服务时要求裸金属自动clean，那么在inspection阶段provide动作的裸金属都会自动clean，具体体现在上图的（1）、（2）阶段，同时也体现在provision阶段的delete动作（3），即每一次裸金属退订流程都会触发clean动作。

7、Ironic driver集模型介绍

裸金属服务器本身是一类产品集成度较高的硬件产品，其中涉及到不同模块的各异功能组成，同时服务器用途上也会存在各自差异，为此Ironic在设计其driver模型时使用的和裸金属服务器一样的思路，即Ironic使用了driver集合将每一个裸金属的管理对应起来， driver是直接附属在其每一个裸金属之上，而对于每一个driver集合又可以分为很多明细driver，通过裸金属服务器的硬件功能区分为：

• power: 电源管理驱动

• boot: 裸金属开关机管理驱动

• deploy: 裸金属部署操作系统驱动

• management: 裸金属管理驱动

• raid: 裸金属raid管理驱动

• vendor: 裸金属厂商驱动，厂商可以根据自己特有功能自定义扩展其特有的功能并通过Ironic暴露出restful api

• inspect: 裸金属检测驱动

• console: 裸金属console驱动

• network: 网络管理驱动

• storage: 存储管理驱动

Ironic driver关系示意图

如上示意展示模型，通过预定义模块化明细driver自由组合为大大增强了各种厂商、型号、平台的裸金属服务器的各种功能复用能力，driver集合模型从一定程度上减少了上层学习和运维阻力。

以下以操作过程视图形式说明下ironic中三个比较有特点的driver组合，由于在Inspection阶段大体实现相同，这里更突出在Provision阶段的driver实现，其中默认使用的network driver都为neutron，相关资料可参考。

• agent_ipmitool：

agent指的是ironic-python-agent，ipmitool即linux下的ipmi指令访问工具，它的特点是兼容目前主流的x86服务器，并且使用直接在裸金属节点拉取用户需要安装的镜像并注入。

以下是它的具体过程示意图：

agent_ipmitool Provision阶段过程示意图

iscsi_ilo：

这是一个基于惠普proliant系列服务器带外管理协议ilo的一个driver，特点是它不依赖于pxe获取ramdisk，可以很好的避免pxe网络异常造成的部署失败问题，这个也是Ironic目前在部署过程中比较头疼的问题之一。

以下是Provision过程示意图：

iscsi_ilo Provision阶段过程示意图

比较遗憾的是iscsi_ilo driver在ironic的后期版本中被社区抛弃，这里将它提出来的目的是此driver抛弃了pxe的部署用户镜像方式，一定程度上减少了Ironic在部署和纳管裸金属的难度，这也是目前Ironic在实施过程中的痛点之一。

总结

如同OpenStack其他组件所具有的优点一样：

一方面Ironic项目从用户层定义了一套较为完整的裸金属管理规范，使用户可以一定程度上摆脱厂商限制，以统一视角管理由各种厂商服务器搭建的裸金属资源；

另一方面Ironic提供了一套相对完善的管理框架，使得其拥有比较广的兼容性和扩展性。

当然由于其再设计之初便面向云服务，所以其在特定场景下有着比较明显的弱势，比如Ironic在其管理生命周期内对于服务器硬件检测、主动适配有着很明显的弱势、对于裸金属操作系统内的功能或者状态管理也是缺失的，所以Ironic项目更适于面向云裸金属平台搭建。

原文发布时间为：2018-08-02
本文来自云栖社区合作伙伴“ Linux宝库”，了解相关信息可以关注“ Linux宝库”。