定制裸机：Ironic的Deploy Templates

最新推荐文章于 2023-01-31 11:11:42 发布

新钛云服

最新推荐文章于 2023-01-31 11:11:42 发布

阅读量461

点赞数

本文链接：https://blog.csdn.net/NewTyun/article/details/104788190

版权

Ironic简述

OpenStack Ironic就是一个进行裸机部署安装的项目。所谓裸机，就是指没有配置操作系统的计算机。从裸机到应用还需要进行以下操作：

硬盘RAID、分区和格式化；
安装操作系统、驱动程序；
安装应用程序。

Ironic实现的功能，就是可以很方便的对指定的一台或多台裸机，执行以上一系列的操作。例如部署大数据群集需要同时部署多台物理机，就可以使用Ironic来实现。Ironic可以实现硬件基础设施资源的快速交付。

OpenStack Ironic的Deploy Templates功能使我们更容易的自动配置裸机服务。

BIOS和RAID

驱动deploy templates工作的最需要的功能是动态BIOS和RAID配置。让我们考虑deploy templates之前的状态。

长期以来，Ironic支持一种叫做“清理”的功能。这通常用于执行清理硬件的操作，但也可以执行一些一次性配置任务。有两种模式——自动和手动。当节点被解除配置时，会发生自动清理。自动清理的一个典型用例是擦除磁盘以删除敏感数据。当节点不在使用时，按需进行手动清理。下图显示了与清理相关的节点状态的简化视图。

清理工作是通过执行一系列清理step来完成的，这些step映射到使用中的Ironic驱动程序公开的方法。每个清理step都有以下字段：

接口：deploy，电源，管理，BIOS， raid
step：驱动程序界面上的方法（功能）名称
args：关键字参数字典
优先级：执行顺序（更高的运行在前面）

BIOS

在Rocky版本中增加了BIOS配置支持。该BIOS驱动程序接口提供了两个清理step：

apply_configuration：应用BIOS配置
factory_reset：将BIOS配置重置为出厂默认值

这是一个使用BIOS驱动程序界面禁用超线程的清理step的示例：

{
  "interface": "bios",
  "step": "apply_configuration",
  "args": {
    "settings": [
      {
        "name": "LogicalProc",
        "value": "Disabled"
      }
    ]
  }
}

RAID

在Mitaka版本中增加了对RAID配置的支持。该RAID驱动程序接口提供了两个清理step：：

create_configuration：创建RAID配置
delete_configuration：删除所有RAID虚拟磁盘

在清理之前，必须在单独的API调用中设置目标RAID配置。

{
  "interface": "raid",
  "step": "create_configuration",
  "args": {
    "create_root_volume": true,
    "create_nonroot_volumes": true
  }
}

当然，对BIOS和RAID配置的支持取决于硬件。

局限性

尽管通过清理触发的BIOS和RAID配置可能很有用，但它有许多限制。该配置未集成到Ironic节点部署中，因此用户无法按需选择配置。Nova用户无法使用清理功能，因此只有管理员可以使用。最后，需要单独的API调用来设置目标RAID配置，这一要求非常繁杂，并且会阻止RAID在自动清理中的配置。

考虑到这些限制，让我们考虑定制裸机的目标。

目标

我们希望允许将硬件资源池应用于各种任务，并为每个任务使用最佳服务器配置。一些例子：

仅有一堆磁盘（JBOD）的Hadoop节点
具有镜像磁盘和条带化磁盘的数据库服务器（RAID 10）
具有优化的BIOS参数的高性能计算（HPC）计算节点

为了避免对硬件进行分区，我们希望能够在部署裸机实例时动态配置这些内容。

我们也想使其云化管理。它不应该要求管理员特权，而是应该从硬件规范中抽象出来。操作员应该能够控制可以配置的内容以及可以配置的人员。我们还希望尽可能使用现有的接口和概念。

回顾：Nova中的Scheduling

理解deploy templates的机制需要合理地了解scheduling在Ironic的Nova中是如何工作的。Placement服务在Newton版本中添加到Nova，并在Stein版本中成为单独项目。它提供了一个用于跟踪资源Inventory和消耗的API，支持定量和定性两个方面。

让我们开始介绍Placement中的关键概念。

资源提供程序提供不同resource class的资源Inventory
资源提供者可能被标记为一个或多个Traits
使用者可能具有消耗资源提供者的某些Inventory的分配

Scheduling虚拟机

对于虚拟机，这些概念映射如下：

计算节点提供vCPU、磁盘和内存资源的Inventory
计算节点可以标记一个或多个Traits
一个实例可能有一个消耗计算节点的一些Inventory的分配

具有35GB磁盘、5825MB RAM和4个CPU的虚拟机监控程序可能会在Placement中有一个资源提供程序inventory记录，该记录通过GET/resource和providers/{uuid}/inventory访问，如下所示：

{
    "inventories": {
        "DISK_GB": {
            "allocation_ratio": 1.0, "max_unit": 35, "min_unit": 1,
            "reserved": 0, "step_size": 1, "total": 35
        },
        "MEMORY_MB": {
            "allocation_ratio": 1.5, "max_unit": 5825, "min_unit": 1,
            "reserved": 512, "step_size": 1, "total": 5825
        },
        "VCPU": {
            "allocation_ratio": 16.0, "max_unit": 4, "min_unit": 1,
            "reserved": 0, "step_size": 1, "total": 4
        }
    },
    "resource_provider_generation": 7
}

请注意，inventory跟踪了系统管理程序的所有资源，无论它们是否被消耗。分配跟踪实例消耗了什么。

Scheduling裸机

上述针对VM的调度不适用于裸机。裸机节点是不可分割的单元，不能被多个实例共享或过量使用。它们不是处于在用状态就是没在用状态。要解决此问题，我们在Nova和Ironic中对Placement的使用会略有不同。

裸机节点提供自定义资源的一个单元的inventory
裸金属节点可以标记一个或多个Traits
一个实例可能有一个消耗所有裸机节点资源Inventory的分配

现在，如果我们查看裸机节点的资源提供者inventory记录，则可能如下所示：

{
    "inventories": {
        "CUSTOM_GOLD": {
            "allocation_ratio": 1.0,
            "max_unit": 1,
            "min_unit": 1,
            "reserved": 0,
            "step_size": 1,
            "total": 1
        }
    },
    "resource_provider_generation": 1
}

我们只有一个resource class的一个单元，在本例中是CUSTOM_GOLD。resource class来自节点的resource_class字段，采用大小写敏感形式，前缀为CUSTOM_，表示它是一个自定义resource class，而不是像VCPU这样的标准resource class。

调度到该节点需要哪种Nova Flavor？

openstack flavor show bare-metal-gold -f json \
    -c name -c ram -c properties -c vcpus -c disk
{
  "name": "bare-metal-gold",
  "vcpus": 4,
  "ram": 4096,
  "disk": 1024,
  "properties": "resources:CUSTOM_GOLD='1',
                 resources:DISK_GB='0',
                 resources:MEMORY_MB='0',
                 resources:VCPU='0'"
}

请注意，可以出于参考目的指定标准字段（vcpus等），但应使用如上所示的属性将其归零。

Traits

到目前为止，我们已经讨论了基于数量资源的调度。Placement使用traits来标志资源。它们与资源提供程序关联。例如，我们可以查询GET/resource_providers/{uuid}/traits以查找有关FPGA设备类的信息。

{
    "resource_provider_generation": 1,
    "traits": [
        "CUSTOM_HW_FPGA_CLASS1",
        "CUSTOM_HW_FPGA_CLASS3"
    ]
}

Ironic的节点除了其resource class之外，还可以分配有Traits：GET/nodes/{uuid}？fields=name,resource_class，traits：

{
  "Name": "gold-node-1",
  "Resource Class": "GOLD",
  "Traits": [
    "CUSTOM_RAID0",
    "CUSTOM_RAID1",
  ]
}

与定量调度类似，在创建实例时可以通过Flavor指定Traits。

openstack flavor show bare-metal-gold -f json -c name -c properties
{
  "name": "bare-metal-gold",
  "properties": "resources:CUSTOM_GOLD='1',
                 resources:DISK_GB='0',
                 resources:MEMORY_MB='0',
                 resources:VCPU='0',
                 trait:CUSTOM_RAID0='required'"
}

为了允许Ironic对象根据请求的Traits采取行动，所需Traits的列表存储在instance_info字段下的Ironic节点对象中。

这种flavor将选择具有resource_class为 CUSTOM_GOLD的裸机节点，以及包括CUSTOM_RAID0的Traits列表。

Ironic的deploy step

Ironic的deploy step框架是在Rocky版本中添加的，作为使部署过程更加灵活的第一步。它基于前面描述的清理step模型，并允许驱动程序定义可在部署期间执行的step。这是我们前面看到的简化状态图，这次突出显示了执行deploy step的部署状态。

每个deploy step都具有：

接口：部署，电源，管理，BIOS， Raid
step：驱动程序界面上的方法（功能）名称
args：关键字参数字典
优先级：执行顺序（较高的运行顺序更早）

请注意，这与清理step相同。

更进一步

部署过程的大部分被转移到一个叫做deploy on the deploy interface的step，优先级为100。此step大致执行以下操作：

打开节点以启动代理
等待代理启动
将映像写入磁盘
断电关机
从供应网络分离
接入租户网络
设置启动模式
开机

驱动程序当前可以在此step之前或之后添加step。该计划将其分为多个核心step，以对部署过程进行更精细的控制。

局限性

对于一组给定的驱动程序接口，deploy step是静态的，并且当前都处于带外——无法在部署代理上执行step。

Ironic的deploy templates

Ironic的deploy templates API是在Stein周期中添加的，它允许注册deploy templates，这些模板具有：

一个名字，必须是一个有效的Traits
deploy step列表

例如，可以通过POST/v1/deploy_templates注册一个deploy templates：

{
    "name": "CUSTOM_HYPERTHREADING_ON",
    "steps": [
        {
            "interface": "bios",
            "step": "apply_configuration",
            "args": {
                "settings": [
                    {
                        "name": "LogicalProc",
                        "value": "Enabled"
                    }
                ]
            },
            "priority": 150
        }
    ]
}

该模板的名称为CUSTOM_HYPERTHREADING_ON（这也是有效的Traits名称），并引用bios接口上的deploy step，该step将LogicalProc BIOS设置为Enabled，以便在节点上启用超线程。

未来的RAID

在Stein版本中，我们具有deploy template和steps框架，但是缺少带有deploy steps实现的驱动程序来实现这一点。作为定制裸机会话演示的一部分，我们构建并演示了一个概念验证deploy step，用于在Dell计算机上部署期间配置RAID。这段代码经过了润色，在编写时正在向上游运行，还影响了HP iLO驱动程序的deploy step。感谢Shivanand Tendulker从PoC中提取并更新了一些代码。

现在，我们在RAID接口上有一个apply_configuration deploy step，该step接受RAID配置作为参数，以避免清理时需要单独的API调用。

在iDRAC驱动程序中实现此功能的第一阶段花费了30分钟以上才能完成部署。通过将删除和创建虚拟磁盘整合到一个deploy step中，从而避免了不必要的重启，从而将流程精简到仅10分钟。

端到端流程

现在我们知道deploy template的样子，那如何使用它们？

首先，云操作员通过Ironic API创建deploy templates，以执行允许的操作的deploy steps。在此示例中，我们具有用于创建42GB RAID1虚拟磁盘的deploy template。

cat << EOF > raid1-steps.json
[
    {
        "interface": "raid",
        "step": "apply_configuration",
        "args": {
            "raid_config": {
                "logical_disks": [
                    {
                        "raid_level": "1",
                        "size_gb": 42,
                        "is_root_volume": true
                    }
                ]
            }
        },
        "priority": 150
    }
]
EOF

openstack baremetal deploy template create \
    CUSTOM_RAID1 \
    --steps raid1-steps.json

接下来，操作员创建具有引用deploy template名称的所需Traits的Nova flavor或Glance镜像。

openstack flavor create raid1 \
    --property resources:VCPU=0 \
    --property resources:MEMORY_MB=0 \
    --property resources:DISK_GB=0 \
    --property resources:CUSTOM_COMPUTE=1 \
    --property trait:CUSTOM_RAID1=required

最终，用户使用他们可以访问的这些flavor创建一个裸机实例。

openstack server create \
    --name test \
    --flavor raid1 \
    --image centos7 \
    --network mynet \
    --key-name mykey

会发生什么？裸金属节点由Nova调度，Nova具有flavor和镜像所需的所有Traits。然后，这些特性被Ironic用来查找具有匹配名称的deploy template，并且这些模板中的deploy steps除了核心step之外，还按照它们的优先级确定的顺序执行。在本例中，RAID apply_configuration deploystep在核心step之前运行，因为它具有更高的优先级。

未来的挑战

仍有工作要做以提高裸机部署的灵活性。我们需要支持在节点上运行的代理中执行step，这将使部署时使用CERN的Arne Wiebalck最近开发的软件RAID支持成为可能。

驱动程序需要针对BIOS，RAID和其他功能公开更多deploy steps。我们应该就如何多次执行一个step以及所有棘手的极端情况达成共识。

我们已经在这里讨论了Nova用例，但是我们也可以在独立模式下使用deploy step，方法是将要执行的step列表传递给Ironic的provision API调用，类似于手动清理。Madhuri Kumari还提出了一个规范，它允许重新配置活动节点，以便在不需要重新部署的情况下调整BIOS设置。

感谢所有参与设计、开发和评审Nova和Ironic系列功能的人，这些功能使我们走到了今天。特别是John Garbutt提出了deploy steps和deploy templates的规范，Ruby Loo实现了deploy steps框架。

原文：http://www.stackhpc.com/bespoke-bare-metal.html

分割线

今晚 20:00分参与直播有机会获得倪朋飞老师极客时间的课程一套！

新钛云服

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
定制裸机：Ironic的Deploy Templates

Ironic简述OpenStack Ironic就是一个进行裸机部署安装的项目。所谓裸机，就是指没有配置操作系统的计算机。从裸机到应用还需要进行以下操作：硬盘RAID、分区和格式化；安装...
复制链接

扫一扫