上一篇
openstack 物理机接管
enStack支持物理机接管，通过Ironic组件实现裸金属即服务，可将未虚拟化的实体服务器纳入云平台统一
OpenStack中实现物理机接管（即裸金属管理）主要通过其组件Ironic来完成,以下是详细的技术实现流程及关键要点：
核心架构与角色分工
| 服务名称 | 功能定位 |
|---|---|
| Keystone | 负责认证授权，确保只有合法用户可操作裸金属资源 |
| Glance | 存储操作系统镜像文件，为部署提供基础软件介质 |
| Nova | 统一调度逻辑，将裸机视为特殊类型的计算资源（Hypervisor实例）进行分配 |
| Ironic | 核心管理模块，处理硬件发现、远程控制、PXE引导等底层交互 |
| Neutron | 配置物理网络接入，支持VLAN/Flat模式以满足不同隔离需求 |
| Swift | 暂存ConfigDrive数据，用于传递个性化配置参数 |
这种设计使得管理员能像管理虚拟机一样批量操作物理服务器，同时保持对底层硬件的精细控制，当租户申请裸机时,系统会自动选择匹配硬件特性的机器并通过标准API交付使用。
部署全流程解析
前期准备阶段
- BMC信息采集：记录所有目标物理机的基板管理控制器IP地址及其他带外管理参数,这是实现远程电源管理的先决条件。
- 交换机预配：获取网络设备的登录凭证，以便后续动态调整端口配置,特别需要注意Trunk端口的VLAN划分策略。
- 镜像适配优化：相较于虚拟机使用的通用镜像，物理机需要包含更完整的驱动支持，推荐使用DIB工具定制专用镜像,并确保启用串口控制台功能。
PXE启动过程
conductor节点会临时启动TFTP服务存放引导文件，配合Neutron提供的DHCP服务指示客户端从指定URL获取内核与initramfs,此阶段涉及三次关键跳转：
- 第一阶段：加载部署用的微型OS（deploy OS），该系统集成了ironic-python-agent代理程序；
- 第二阶段：由代理程序从Glance拉取用户指定的主镜像到本地存储；
- 第三阶段：执行实际安装流程，包括磁盘擦除、分区格式化及文件系统拷贝操作，若配置了ConfigDrive,还会从Swift对象存储同步元数据到独立分区。
网络切换机制
为避免生产流量与部署通道混杂，Ironic引入了专用的provisioning网络进行临时通信，当操作系统安装完成后，系统会自动将网卡切换至用户指定的业务网段,这个过程涉及动态修改BIOS启动顺序和网络接口绑定关系。
运维管理特性对比
| 功能项 | 虚拟机支持情况 | 物理机实现方式 |
|---|---|---|
| 在线迁移 | 实时热迁移 | 不支持，但可通过重建实现主机替换 |
| 卷挂载 | Cinder集成 | 需手动配置本地存储 |
| 密码重置 | qemu-guest-agent交互 | 依赖rescue模式进入救援系统修改 |
| 性能监控 | Ceilometer指标采集 | ️ 有限支持，建议结合独立监控方案 |
| 控制台访问 | VNC网页控制台 | SOL串口重定向（需IPMI配合） |
值得注意的是，物理机的Web控制台采用多层转发架构：用户请求→nova-serialconsoleproxy→ironic-conductor→IPMI SOL通道，这种设计虽然增加了延迟,但实现了统一的访问入口。
安全回收机制
当释放裸金属资源时，系统会强制进入维护模式执行全盘擦除操作,具体流程包括：
- 启动部署环境加载清理脚本；
- 对所有检测到的块设备执行
dd if=/dev/zero of=/dev/X命令； - 验证数据不可恢复性后重置BMC管理密码；
- 最后从资源池中移除该节点。
FAQs
Q1: Ironic与Nova的关系是什么？如何区分它们管理的资源类型？
A: Ironic作为Nova的下层驱动存在，二者通过flavor属性中的extra specs进行协商，当创建请求携带cpu-arch、boot-option等硬件特征标签时，Nova调度器会自动选择Ironic管理的物理节点而非默认的Libvirt虚拟化路径,这种松耦合设计允许在同一套API下同时管理异构计算资源。
Q2: 为什么物理机镜像不能直接复用虚拟机镜像？如何处理驱动兼容性问题？
A: 因为物理服务器的硬件差异远大于虚拟环境，特别是RAID卡、HBA卡等设备需要特定驱动支持，解决方案包括：使用dracut工具生成含所有模块的initramfs；针对LVM分区添加额外驱动参数；测试阶段采用相同厂商型号的设备集群以保证驱动一致性，对于跨平台场景，建议构建厂商中立
