講師：日本仮想化技術 野津 日時：2013/11/13 アジェンダ： - 構成要素 - 動作の解説 - インスタンス起動 - ボリュームの利用 - スケジューリング - VMプロビジョニングとの互換性 - イメージ - ネットワーク - Ironic

1. ベアメタルプロビジョニング
日本仮想化技術
野津 新

2. アジェンダ
• 構成要素
• 動作の解説
– インスタンス起動
– ボリュームの利用
• スケジューリング
• VMプロビジョニングとの互換性
– イメージ
– ネットワーク
• Ironic

3. 構成要素
• ノード：プロビジョニング対象の物理マシ
ン
• ノードDB
– ノードの情報・ステータスを保持
– Nova APIで操作
• 管理ホスト
– nova-compute
– PXE/TFTPサーバ：ノード起動用
• プロビジョニング用起動設定
• 通常起動設定
– nova-baremetal-deploy-helper：プロビジョニン
グ用起動設定と連携

4. インスタンス起動
管理ホスト
ノード
※対象ノードはスケジューラによって
決定済
ディスク
イメージ
カーネル
カーネル
RAMディス
ク
RAMディス
ク
プロビジョニング用
（ミニOS）
OFF
Glanceからイメージ等ダウンロード
（あらかじめ登録しておく:後述）
通常用
PXE設定はプロビジョニング用
PXE
ノードをPower On
プロビジョニング用ミニOSが起動
イメージをディスクに書き込み
PXE設定を通常用に切替
再起動
以降はVMインスタンスと
同様の起動シーケンス
(cloud-initなど)
PowerManager
power on
nova-barametaldeploy-helper
IPMI
ディスク
プ
ロ
ビ
PXE
通
常
詳
細
後
述

5. プロビジョニングモード詳細
管理ホスト
ノードをPower On
ディスク
イメージ
ノード
カーネル
RAMディス
ク
プロビジョニング用
ミニOSが起動
プロビジョニング用
（ミニOS）
ディスクをiSCSI
エクスポート
iSCSI
エクスポート
ディスク
iSCSIアタッチ
アタッチしたディスクに
イメージを書き込む
novabarametaldeploy-helper
プ
ロ
ビ
管理ホスト(deploy-helper)
に準備完了を通知
PXE設定を通常用に切替
管理ホスト側での
作業完了を通知
再起動

6. ノードのハードウェア要件
• IPMIでの電源ON/OFF/状態取得
– または同等の機構+対応したPowerManager
– 例)Moonshot対応
• 当初IPMIを使用する予定だったが、アクセス方
法が特殊（IPMI double bridge）だったため、
IPMIを使用せずSSHインターフェイスで実装
• https://github.com/virtualtech/nova
• PXE起動ができること

7. イメージ等の事前準備
• ディスクイメージ、カーネル、RAMディスクが必要
• いずれもdiskimage-builderで作成可能
– https://github.com/openstack/diskimage-builder
• Ubuntuのディスクイメージ作成(A)
– $ disk-image-create ubuntu
• 作成したディスクイメージからのカーネル&RAMディス
ク抽出(B,C)
– $ disk-image-get-kernel -iディスクイメージ
• プロビジョニング用ミニOSのRAMディスク作成(D)
– $ ramdisk-image-create deploy
• A,B,C,DをGlanceに登録
• ミニOSのイメージIDは設定ファイル(nova.conf)に書く
[baremetal]
deploy_kernel=BのイメージID
deploy_ramdisk=DのイメージID

8. ボリュームのアタッチ
• ボリュームはCinderからiSCSI等でエクスポートされている
• nova-computeがiSCSI接続
– ホスト上にボリュームが現れる
– この時点ではまだインスタンスにはアタッチされていない
– ここまではVMとベアメタルに違いはない
• ボリュームをインスタンスにアタッチ
– VMの場合はVirtIO：自動的に認識される
– ベアメタルの場合はiSCSI：自動的に認識されない
• インスタンス内で明示的なアタッチが必要（iscsiadmコマンド等）
VM
nova
VirtIO
VMインス
タンス
自動認識
Cinder
BM
nova
iSCSI
BMインス
タンス
手動操作が必要

9. スケジューリング
• スケジューリング=インスタンスをどのノードに割り当て
るか
• nova-schedulerの役割
– nova-computeは自分が持っているリソースの量をnovaschedulerに通知
• デフォルトでは最もメモリの多いノードが選択される
– VMを想定した動作のためBMには向かないことがある
– 小さいインスタンスタイプなのに大きいノードが空いてい
るとそれを使ってしまう
• 設定の変更でなんとかなる？
– 未検証
• 現状では全ノードが均一のスペックであれば問題を回避
できる

10. イメージの互換性
•
インスタンスがVMかBMかを気にせず同じイメージを使いたい
•
必要なカーネルモジュールが含まれているかどうかが主な問題
–
–
•
VM用イメージには実ハードウェアのドライバが含まれていないことが多い
–
–
•
実ハードウェアのドライバが含まれていないとBMインスタンスでは不可
仮想ハードウェアのドライバが含まれていないとVMインスタンスでは不可
容量削減のため
Ubuntuではlinux-virtualパッケージ
BM用イメージには実ハードウェアのドライバとVM向けドライバの両方が含まれて
いることが多い
–
Ubuntuではlinux-genericパッケージ
•
VMインスタンスでもBM用イメージを使うことにすれば一種類のイメージだけで両
方使える
•
VMとBMの違いはドライバ層でほぼ吸収される
VMインスタン
ス
BMインスタン
ス
VM用イメージ
○
×
BM用イメージ
○
○

11. ネットワークの互換性
• Nova-networkのFlatDHCPが利用可能
• Neutronも一応利用可能
– 仮想ネットワーク機能は利用できないため
nova-networkを使うのとあまり違いがない
• 仮想ネットワーク対応は今後の課題
• ノードと接続している物理スイッチを制御
する方法が必要と思われる
– 過去にはOpenFlowスイッチ+Quantum NECプ
ラグインでの実験に成功

12. Ironic
• 次世代のベアメタルプロビジョニング実装
• 現在はNova内で実行されている処理を外に出す
– ノードDB,IPMI,PXE等
– NovaとIronicはHTTPで通信
• 機能的には現在のベアメタルプロビジョニングと
同等
• 現在は開発段階
– Nova側のドライバがまだ存在しないため実際の利用は
できない
• Icehouse期間中のリリース
• リリース後は現在のベアメタルプロビジョニング
は利用非推奨（Deprecated）となる
– 移行プログラムが提供される
※いずれも予定