轉：https://doodu.gitbooks.io/openstack-ironic
簡介
Bare Metal Servcie 裸機服務 -- 'bear betal'
ironic簡介
如今Openstack在虛擬化管理部分已經很成熟了， 通過nova我們可以創建虛擬機、枚舉虛擬設備、管理電源狀態、安裝操作系統等。但是有時候虛擬機無法滿足要求，比如以下幾種情況需要直接使用物理機：
- 高性能的計算集群
- 計算任務需要訪問無法虛擬化的硬件設備
- 數據庫主機（有些數據庫在hypervisor中運行效率很差）
- 單租戶、專用硬件、安全性、可靠性和其他控制要求
- 快速部署雲基礎設施
但是在物理機管理上一直沒有成熟的解決方案。在這樣的背景下Ironic（Bare-Metal Provisioning）誕生了，它可以解決物理機的添加，刪除，電源管理和安裝部署。Ironic提供了一系列常用的驅動，同時提供了插件的機制讓廠商可以開發自己的driver，這讓它支持幾乎所有的硬件。 
部署物理機跟部署虛擬機的概念在nova來看是一樣，都是nova通過創建虛擬機的方式來觸發，只是底層nova-scheduler和nova-compute的驅動不一樣。虛擬機的底層驅動采用的libvirt的虛擬化技術，而物理機是采用Ironic技術，ironic可以看成一組Hypervisor API的集合，其功能與libvirt類似。
前世今生
最早baremetal的概念出現在nova里，物理機和虛擬機管理有很多地方非常相似，比如物理機和虛擬機都需要開機關機，安裝部署，添加和刪除，為了避免重復造輪子，他們在nova中實現了一個物理機的driver，這樣把物理機管理做為計算資源管理的一個子集了。后來發現這樣做有問題：
- 早期baremetal作為一個driver有自己的數據庫，同一個項目中有兩套數據庫不合適。
- 在部署和管理baremetal的過程中有很多需要存儲的信息是和部署管理虛擬機是不同的，通過nova api來獲取這些信息比較尷尬，把baremetal剝離出來有助於划清baremetal和虛擬機部署的界限。
- 有時候baremetal需要做一些比較特殊的行為，比如discovery, hardware raid configuration, firmware updates, burn-in這些操作，它們不適合放在nova里面。比較好的辦法是當完成這些操作的時候，向nova去注冊信息，作為nova中的可用的資源，最后通過nova boot去調用這些資源。
經過很多次討論，開始社區把bare metal分離出來了, 命名為Ironic，從Icehouse版開始進入孵化項目，並在Juno版與Nova進行集成，從完成了項目畢業評審，在Kilo版正式的集成到openstack項目中來，今后會通過nova調用Ironic的api來實現對物理機資源的管理和控制。
傳統的hypervisor一般包括創建虛擬機、枚舉虛擬設備、管理電源、加載操作系統等功能，與之對應，Ironic可以看成結合多個驅動提供一套hypervisor API來操作物理機提供類似操作，所以ironic可以看成一個hypervisor驅動來給Nova來用。
架構
項目組成
- ironic： 包含ironic-api 和ironic-conductor進程
- python-ironicclinet: python clinet and CLI
- ironic-python-agent: 一個運行在deployment ramdisk中的Python程序，用於執行一系列部署動作
- pyghmi: 一個python的IPMI庫，可以代替IPMItool
- ironic-inspector: 硬件自檢工具
- ironic-lib： ironic的通用庫函數
- ironic-webclinet ：web客戶端
- ironic-ui：ironic的horizon插件
- bifrost：一套只運行Ironic的Ansible腳本
概念架構（與其他組件的關系）
下圖顯示了在提供物理機服務時各個組件的關系。（Ceilometer和Swift能與Ironic一起使用，但是在圖中沒有顯示）
邏輯架構（與其他組件的調用關系）
Ironic服務由以下組件構成。
- Ironic API，一個RESTful API服務，管理員和其他服務通過API與Ironic進行交互
- Ironic Conductor， 完成Ironic服務的絕大部分工作，通過API對外開放其功能，與Ironic API通過RPC進行交互；負責與其他組件進行交互
- Dirvers，真正管理物理機的模塊，通過一系列的驅動來支持不同的硬件
- Database，用來存儲資源信息
- 消息隊列
部署架構
雲平台管理員可以使用RESTful API注冊硬件，制定硬件的屬性，比如MAC地址、IPMI證書。可以開啟多個API服務實例。
由於Ironic Conductor是唯一一個需要訪問數據層和IPMI控制層的服務，為了安全起見，最好將conductor service 放在一個獨立的主機上。為了支持各類驅動和管理故障遷移，可以有多個conductor實例存在，每個conductor實例可以運行多個drivers。
消息路由
每一個Condutor實例在啟動時想數據庫注冊自己，注冊的信息包含了本實例支持的驅動列表，並且定期更新自己記錄的時間戳，這就使得所有的服務能夠知道哪些Condutor和哪些驅動可用。
物理機根據自己的驅動，使用一致性哈希算法映射在一組Condutor上。部署任務通過RPC從API層分發到合適的Condutor上。當Condutor實例加入或者退出集群，物理機會重新映射到不同的Condutor上，會觸發驅動的多種動作，比如take-over 或者 clean-up動作。
