问题导读:
1.什么是Ironic? 2.baremetal的部署数据流是怎样的? 3.Ironic的部署数据流是怎样的?
如今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的机制来解决一直以来业界没有解决的厂商硬件异构的问题,前景非常好。
Ref
1,418 total views, 6 views today
|