PXE系列文章(9)- 优化 PXE 装机流程
上一篇文章 PXE 自动化装机技术回顾 我们详细讨论了下, 标准 PXE 使用流程的一些优缺点.对于现今机房数量的大幅度增加, 物理机数量以及类型的增加, 多样化需求的叠加, 尤其是国内还有大量对裸金属服务的依赖, 都希望将传统的安装过程能平台化/模块化/自动化,以满足不断丰富的业务需求, 满足对资源的交付更加高效/可靠/稳定要求, 以及同时减少整体持续运营的成本, 降低研发人员参与的强度.
其实整个传统的PXE装机过程, 偏向串行化, 流程化的, 如果我们能将大部分内容变成服务化,由业务调度提供执行任务, 要求所有任务有足够原子化的粒度,比如做 Raid, 写镜像, 配置网卡等等, 真正的装机模块负责对任务进行执行, 所有任务支持编排, 提供并行/串行机制, 实时反馈,偶发异常自动重试,系统异常自动提醒.
大多厂商都开始使用 OpenStack Ironic 来解决上述问题, Ironic 架构图如下:
Ironic 的整体架构上看大多数需求都能满足, 唯一的问题是, Ironic 的使用时需要和 Neutron/Nova 交互, 国内很多厂商这部分都已经逐步自研对应的组件, 以便更好的满足企业需求. 所以真要使用 Ironic, 我们就需要对 Ironic 动手术, 手术动小了, 满足不了需求, 手术动大了, 如果社区有更新更好的功能出来有无法做到平滑升级, 其实这就有了个矛盾点.
国内很多厂商逐步都在从 OpenStack 中脱离出来,形成自身的云基础设施.因为每个厂商的网络管理环境, 以及资源组织方式, 其实是有差异的, 业务需求不尽相同, 所以我们的裸金属产品希望是自研的技术体系.好在我们其实不是从 0 开始, 在裸金属管理平台中有很多类似 OpenStack Ironic 的优秀组件, 比如Cobbler/Ubuntu Maas. 我们尽可能从这些优秀组件中取其精华去其糟粕.
从上面的流程中,我们可以看到, 整个 Ironic 的装机流程比较长, 而且依赖的组件都非常多(Glance/Neutron/Nova等),详细看完 Ironic Conductor 和 Ironic Agent 之间的交互发现, 大量基于网络工具的操作流程, 比如 iSCSI/HTTP 等等.我们平常坚持一个原则, 一个工具能解决的事情, 坚决不适用两个以上的工具来解决. 但这里给我们提供了一个思路, 就是 Ironic Conductor 触发 PXE 之后,物理机内部启动一个基于 CoreOS 构建内存镜像, 将 ironic-python-agent 集成到 OS 中, 详细的文档信息, 请阅读 https://github.com/openstack/ironic-python-agent/blob/master/imagebuild/coreos/README.rst.
大致的架构思路是这样下面的逻辑:
思路是去掉大多数依赖,让整个自动化装机平台变得独立自主,依赖的网络等等功能可以自由的接入进来.装机业务对外统一使用 Restful API 对外输出,内部调度接收 API 服务下发的任务, 拆解后转换成独立的指令, 由调度驱动 IPMI, PXE 后的内存 OS 中集成的 Agent接收 MQ 中的指令最终执行.
- API 处理用户端提交的资源申请和操作的请求
- Scheduler 负责将任务拆解,形成指令集, 将指令逐个发送到 MQ
- Agent 接收 MQ 中的指令, 并完成具体工作内容,比如根据用户需求做 Raid, 安装用户指定镜像, 配置用户指定网络, 设置用户密码等等.
API 其实可以使用大多数成熟语言来实现 HTTP 服务, Scheduler 很多业务流程控制以及多线程异步调度, 建议由 Java 实现.Agent 主要负责和 OS 系统工具集交互, 建议使用 Python 实现.
相对来说, 我们只要实现好 Agent, 其他两个服务(API/Scheduler)其实都还是很容易实现, 毕竟都是普通的业务流程等内容.接下来,我们就要开始如何定制内存 OS, 然后一步一步实现 Agent, 最终将 Agent 集成到内存 OS 中.一旦,我们实现了这个过程, 其实 API/Scheduler 来不来得及实现, 我们都可以通过 MQ 完整模拟整个装机过程.
