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
閱讀更多 新鈦雲服 的文章
