定製裸機：Ironic的Deploy Templates

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的示例：

<code>{
  "interface": "bios",
  "step": "apply_configuration",
  "args": {
    "settings": [
      {
        "name": "LogicalProc", 

        "value": "Disabled"
      }
    ]
  }
}/<code>

RAID

在Mitaka版本中增加了對RAID配置的支持。該RAID驅動程序接口提供了兩個清理step：：

• create_configuration：創建RAID配置
• delete_configuration：刪除所有RAID虛擬磁盤

在清理之前，必須在單獨的API調用中設置目標RAID配置。

<code>{
  "interface": "raid",
  "step": "create_configuration",
  "args": {
    "create_root_volume": true,
    "create_nonroot_volumes": true
  }
}/<code>

當然，對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訪問，如下所示：

<code>{
    "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
}/<code>

請注意，inventory跟蹤了系統管理程序的所有資源，無論它們是否被消耗。分配跟蹤實例消耗了什麼。

Scheduling裸機

上述針對VM的調度不適用於裸機。裸機節點是不可分割的單元，不能被多個實例共享或過量使用。它們不是處於在用狀態就是沒在用狀態。要解決此問題，我們在Nova和Ironic中對Placement的使用會略有不同。

• 裸機節點提供自定義資源的一個單元的inventory
• 裸金屬節點可以標記一個或多個Traits
• 一個實例可能有一個消耗所有裸機節點資源Inventory的分配

現在，如果我們查看裸機節點的資源提供者inventory記錄，則可能如下所示：

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

我們只有一個resource class的一個單元，在本例中是CUSTOM_GOLD。resource class來自節點的resource_class字段，採用大小寫敏感形式，前綴為CUSTOM_，表示它是一個自定義resource class，而不是像VCPU這樣的標準resource class。

調度到該節點需要哪種Nova Flavor？

<code>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'"
}/<code>

請注意，可以出於參考目的指定標準字段（vcpus等），但應使用如上所示的屬性將其歸零。

Traits

到目前為止，我們已經討論了基於數量資源的調度。Placement使用traits來標誌資源。它們與資源提供程序關聯。例如，我們可以查詢GET/resource_providers/{uuid}/traits以查找有關FPGA設備類的信息。

<code>{
    "resource_provider_generation": 1,
    "traits": [
        "CUSTOM_HW_FPGA_CLASS1",
        "CUSTOM_HW_FPGA_CLASS3"
    ]
}/<code>

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

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

與定量調度類似，在創建實例時可以通過Flavor指定Traits。

<code>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'"
}/<code>

為了允許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：

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

該模板的名稱為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。

<code>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/<code>

接下來，操作員創建具有引用deploy template名稱的所需Traits的Nova flavor或Glance鏡像。

<code>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/<code>

最終，用戶使用他們可以訪問的這些flavor創建一個裸機實例。

<code>openstack server create \\
    --name test \\
    --flavor raid1 \\
    --image centos7 \\
    --network mynet \\
    --key-name mykey/<code>

會發生什麼？裸金屬節點由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

更多幹貨技術文章請訪問新鈦雲服官網https://www.tyun.cn

閱讀更多 新鈦雲服 的文章

關鍵字: 數據庫 操作系統 特別