作者：祝祥 翻译

OpenStack裸机又名Ironic，是一个集成的OpenStack程序，旨在提供从Nova裸机驱动程序派生的裸机而不是虚拟机。最好将其视为裸机虚拟机管理程序API和一组与裸机虚拟机管理程序交互的插件。默认情况下，它将使用PXE和IPMI来配置和打开/关闭计算机，但是Ironic还支持特定于供应商的插件，这些插件可以实现其他功能。

OpenStack Ironic一直处于充满挑战的环境中。Ironic的每一个版本都引入了更具创造性的虚拟化抽象的功能实现。但是，裸机管理一直被硬件管理所困扰：在软件定义的云中没有等效的设备和配置。要继续存在，Ironic必须提供纯粹的抽象，但是要成功，它还必须提供更多的功能实现。

长时间以来，HPC系统管理员的传统角色包括部署裸机，有时是大规模部署。除了确保系统的可重复性，可扩展性和效率之外，自动化对于数量众多的系统而言也至关重要。到目前为止，这种自动化已经以特定于领域的方式发展，并且在快速简化流程，这使得能够通过最少的服务来配置和管理大型基础架构。Ironic是第一个在云模式中定义裸机基础设施的框架。

理论上讲了这么多：使用硬件一直很繁琐，从来没有像预期的那样可预测或可靠。软件定义的基础架构是支撑现代敏捷性的方法，在数量级上加速了与硬件服务的交互。Ironic努力在不可靠的情况下提供完美的解决方案（尽量减少让数据中心的人操作硬件的需要）。

HPC地震分析基础设施

作为地震处理行业的领导者，ION Geophysical公司维护着超大规模的生产HPC基础设施，并采用分阶段采购模式，使得生产环境中的几代硬件随时处于活跃状态。现场故障和更换增加了进一步的复杂度。在多个硬件配置之间提供一致的软件环境可能是一个挑战。

ION正在将本地HPC基础设施迁移到OpenStack私有云中。使用Kayobe部署和配置OpenStack基础环境，该项目将Ironic（用于硬件部署）和Kolla-Ansible（用于OpenStack部署）集成在一个Ansible框架中。Ansible为从物理层到应用程序工作负载本身的所有内容提供一致的接口。

这段旅程始于一些较早的HPE SL230计算节点，并将控制权转移到OpenStack管理。每个节点都有两个硬盘。为了满足工作负载要求，将它们配置为两个RAID卷-一个为镜像卷（用于OS），另一个为数据卷（用于工作负载的暂存空间）。

每个节点还具有一个硬件RAID控制器，并且Ironic的标准做法是利用这一点。但是，在分析了硬件之后，发现：

需要通过BIOS启用硬件RAID控制器，但是BIOS管理工具在许多节点上都失败了，因为“personality board”发生了故障，从而阻止了该工具检索服务器型号。RAID控制器需要专有的内核驱动程序，该驱动程序不适用于最新的CentOS版本。不仅需要驱动程序来管理控制器，还需要安装RAID卷。

考虑到这些因素和其他因素，可以确定硬件RAID控制器不可用。幸运的是，Ironic开发了基于软件的替代方案。

配置软件RAID

Linux服务器通常将其根文件系统部署在RAID-1卷上。这项要求体现了Ironic项目内在的矛盾。虚拟化的抽象要求将Guest OS视为黑盒子，但是软件RAID的实现是Linux特有的。但是，不支持Linux软件RAID将是主要用例的一个限制。在不丧失Ironic的通用功能的情况下，Guest OS“黑匣子”在这种特殊情况下成为白匣子。由CERN领导的最新工作为Ironic Train版本贡献了软件RAID支持。

CERN团队已在其技术博客中记录了软件RAID支持。

在其最初的实施中，软件RAID功能受到限制。裸机节点被分配一个持久性软件RAID配置，每当一个节点被清理并用于所有实例部署时就应用该配置。涉及StackHPC团队以开发实例驱动的RAID配置的先前工作尚不适用于软件RAID。但是，当前的驱动程序实现为Kayobe的云基础架构部署提供了正确数量的功能。

配置方法

Ironic中的RAID配置在Ironic管理指南中有更详细的描述。以下提供了更详细的概述。

在Ussuri发布之前，不支持带UEFI引导的软件RAID，在Ussuri版本中，它可以与作为镜像的元数据存储在Glance等服务中的rootfs UUID结合使用。对于Bifrost用户来说，这意味着Latency BIOS引导模式是唯一的选择，暂时不支持UEFI引导和NVMe设备。

在本例中，任务是使用OpenStack Train提供大量计算节点，每个节点都有两个物理磁盘，并配置为Latency BIOS引导模式。这些都是根据OpenStack文档提供的，并有CERN博客文章提供的一些背景。在每个节点的RAID配置集=中指定了两个RAID设备；第一个用于操作系统，第二个用于Nova作为vm的数据空间。

{  "logical_disks": [    {      "raid_level": "1",      "size_gb"   : 100,      "controller": "software"    },    {      "raid_level": "0",      "size_gb"   : "800",      "controller": "software"    }  ]}

请注意，尽管通过将size_gb设置为MAX来创建逻辑磁盘时可以使用所有剩余空间，但您可能希望保留一些备用空间，以确保如果故障磁盘被容量相差不大的型号所替换时可以重建故障磁盘。

然后，按照以下OpenStack文档中详述的清理步骤应用RAID配置：

[{  "interface": "raid",  "step": "delete_configuration" }, {  "interface": "deploy",  "step": "erase_devices_metadata" }, {  "interface": "raid",  "step": "create_configuration" }]

为操作系统选择RAID-1，以便在单个磁盘发生故障时hypervisor仍能正常工作。RAID-0用于暂存空间，以利用此配置提供的性能优势和额外的存储空间。应该注意的是，此配置特定于预期的用例，并且可能并非对所有部署都是最佳的。

如CERN 博客文章所述，mdadm软件包已安装在Ironic Python Agent（IPA）ramdisk中，目的是在清理过程中配置RAID阵列。 mdadm也已安装到部署映像中，以支持将grub2引导加载程序安装到物理磁盘上，以便在一个磁盘出现故障时从任一磁盘加载操作系统。最后，将mdadm添加到了部署映像ramdisk中，以便当节点从磁盘启动时，它可以转到根文件系统中。尽管我们通常会使用Disk Image Builder，但最后一步的一个简单技巧是使用virt-customize：

virt-customize -a deployment_image.qcow2 --run-command'dracut --regenerate-all -fv --mdadmconf --fstab --add = mdraid --add-driver =“ raid1 raid0”'

作为一个开源项目，Ironic依赖于一个蓬勃发展的用户基础，为项目做出贡献。我们的经验涵盖了新的领域：软件RAID驱动程序以前从未使用过的硬件。不可避免地，会发现新的问题。

第一次观察到，在清理过程中，大约56个节点中有25％的节点上RAID设备的配置将失败。失败的节点记录以下消息：

mdadm: super1.x cannot open /dev/sdXY: Device or resource busy

其中X是a或b，Y是1或2，分别表示物理磁盘和分区号。这些节点以前已经通过Ironic或其他方式使用软件RAID进行了部署。

对内核日志的检查表明，在所有情况下，标记为busy的设备都被内核从阵列中弹出：

md: kicking non-fresh sdXY from array!

被弹出的设备，可能同步，也可能没有同步，作为RAID-1阵列的一部分出现在/proc/mdstat中。另一个驱动器已被擦除，但在输出中丢失。得出的结论是，弹出的设备绕过了旨在删除所有先前配置的清理步骤，后来又自行恢复，从而在create_configuration清理步骤期间阻止了阵列的创建。

为了成功清理，应用了手动解决方法，停止此RAID-1设备并将块中的签名归零：

mdadm --zero-superblock /dev/sdXY

删除所有先前存在的状态大大提高了Ironic创建软件RAID设备的可靠性。剩下的问题是为什么有些服务器会出现这个问题，而其他服务器没有。进一步的检查表明，虽然许多磁盘都是旧的，但没有报告故障，磁盘通过了自检，虽然总体上接近，但没有超过平均故障前时间（MTBF）。除了从阵列中删除设备之外，内核没有报告任何故障迹象。例如通过运行badblocks之类的工具来运行整个磁盘介质，结果表明只有极少数磁盘出现问题。基准测试，老化和异常检测可能会更快地识别出这些设备。

进一步的研究可能有助于我们确定表现出这种行为的磁盘是否存在其他方面的故障。另一项调查可能是增加内核中驱动器的重试和超时等阈值。目前，这些细节都在错误报告中注明。

观察到的第二个问题发生在节点从RAID-1设备引导的时候。这些节点运行IPA并基于Centos 7.7.1908和内核版本3.10.0-1062部署映像，将显示降级的RAID-1阵列，并在失败的清理周期中看到相同的消息：

md: kicking non-fresh sdXY from array!

通过针对节点运行Kayobe自定义playbook，将sdXY重新添加到阵列中，从而开发了针对此问题的解决方法。在所有情况下，都可以观察到弹出的设备与RAID设备重新同步。使用OpenStack Monasca监视RAID阵列的状态，从Prometheus Node Exporter的最新版本中获取数据，其中包含有关MD/RAID监视的一些增强功能。可以使用简单的仪表板显示软件RAID状态：

Monasca MD/RAID Grafana仪表板使用从Prometheus node exporter抓取的数据。

左上方的图显示了每个RAID设备上已同步块的百分比。在设备被强制故障后，可以看到单个RAID-1阵列正在恢复，然后将其添加回去以模拟磁盘的故障和更换。不幸的是，由于Ironic 不支持软件RAID的名称字段，因此尚无法区分每个节点上的RAID-0和RAID-1设备。因此，RAID-0和RAID-1阵列的名称在md126和md127之间随机交替。右上方：几秒钟内即可看到模拟的故障设备。这是一个生成警报的良好指标。左下方：阵列重建时，该设备被标记为正在恢复。右下方：没有启动手动重新同步。该设备被MD/RAID视为正在恢复，并且未在此图中显示。

这两个问题的根本原因尚未确定，但它们很可能已连接，并且与这些磁盘和内核MD/RAID代码之间的交互有关。

开源，开放的社区

与硬件交互的软件很快就能建立一个关于快速发展及的广泛的“case law”。像Ironic这样的开放式项目在用户成为贡献者时得以生存和发展。不利用社区贡献的同等其他项目最终无疾而终。

CERN团队（以及OpenStack社区的其他人员）的最初贡献使StackHPC和ION Geophysical能够以最佳方式部署基础设施进行地震处理。在这种情况下，我们希望自己做出更大的贡献，但我们希望通过分享我们的经验，可以促使其他用户参与该项目。

原文链接：