ベアメタルプロビジョニング
日本仮想化技術
野津 新
アジェンダ
• 構成要素
• 動作の解説
– インスタンス起動
– ボリュームの利用

• スケジューリング
• VMプロビジョニングとの互換性
– イメージ
– ネットワーク

• Ironic
構成要素
• ノード:プロビジョニング対象の物理マシ
ン
• ノードDB
– ノードの情報・ステータスを保持
– Nova APIで操作

• 管理ホスト
– nova-compute
– PXE/TFTPサーバ:ノード起動用
• プロビジョニング用起動設定
• 通常起動設定

– nova-baremetal-deploy-helper:プロビジョニン
グ用起動設定と連携
インスタンス起動
管理ホスト

ノード

※対象ノードはスケジューラによって
決定済
ディスク
イメージ

カーネル

カーネル

RAMディス
ク

RAMディス
ク

プロビジョニング用
(ミニOS)

OFF

Glanceからイメージ等ダウンロード
(あらかじめ登録しておく:後述)

通常用

PXE設定はプロビジョニング用
PXE

ノードをPower On
プロビジョニング用ミニOSが起動

イメージをディスクに書き込み

PXE設定を通常用に切替
再起動
以降はVMインスタンスと
同様の起動シーケンス
(cloud-initなど)

PowerManager

power on

nova-barametaldeploy-helper

IPMI

ディスク

プ
ロ
ビ

PXE

通
常

詳
細
後
述
プロビジョニングモード詳細
管理ホスト
ノードをPower On

ディスク
イメージ

ノード

カーネル
RAMディス
ク

プロビジョニング用
ミニOSが起動

プロビジョニング用
(ミニOS)

ディスクをiSCSI
エクスポート

iSCSI
エクスポート
ディスク
iSCSIアタッチ
アタッチしたディスクに
イメージを書き込む

novabarametaldeploy-helper

プ
ロ
ビ

管理ホスト(deploy-helper)
に準備完了を通知

PXE設定を通常用に切替
管理ホスト側での
作業完了を通知
再起動
ノードのハードウェア要件
• IPMIでの電源ON/OFF/状態取得
– または同等の機構+対応したPowerManager
– 例)Moonshot対応
• 当初IPMIを使用する予定だったが、アクセス方
法が特殊(IPMI double bridge)だったため、
IPMIを使用せずSSHインターフェイスで実装
• https://github.com/virtualtech/nova

• PXE起動ができること
イメージ等の事前準備
• ディスクイメージ、カーネル、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
ボリュームのアタッチ
• ボリュームはCinderからiSCSI等でエクスポートされている
• nova-computeがiSCSI接続
– ホスト上にボリュームが現れる
– この時点ではまだインスタンスにはアタッチされていない
– ここまではVMとベアメタルに違いはない

• ボリュームをインスタンスにアタッチ
– VMの場合はVirtIO:自動的に認識される
– ベアメタルの場合はiSCSI:自動的に認識されない
• インスタンス内で明示的なアタッチが必要(iscsiadmコマンド等)

VM
nova

VirtIO

VMインス
タンス

自動認識
Cinder
BM
nova

iSCSI

BMインス
タンス

手動操作が必要
スケジューリング
• スケジューリング=インスタンスをどのノードに割り当て
るか
• nova-schedulerの役割
– nova-computeは自分が持っているリソースの量をnovaschedulerに通知

• デフォルトでは最もメモリの多いノードが選択される
– VMを想定した動作のためBMには向かないことがある
– 小さいインスタンスタイプなのに大きいノードが空いてい
るとそれを使ってしまう

• 設定の変更でなんとかなる?
– 未検証

• 現状では全ノードが均一のスペックであれば問題を回避
できる
イメージの互換性
•

インスタンスがVMかBMかを気にせず同じイメージを使いたい

•

必要なカーネルモジュールが含まれているかどうかが主な問題
–
–

•

VM用イメージには実ハードウェアのドライバが含まれていないことが多い
–
–

•

実ハードウェアのドライバが含まれていないとBMインスタンスでは不可
仮想ハードウェアのドライバが含まれていないとVMインスタンスでは不可
容量削減のため
Ubuntuではlinux-virtualパッケージ

BM用イメージには実ハードウェアのドライバとVM向けドライバの両方が含まれて
いることが多い
–

Ubuntuではlinux-genericパッケージ

•

VMインスタンスでもBM用イメージを使うことにすれば一種類のイメージだけで両
方使える

•

VMとBMの違いはドライバ層でほぼ吸収される
VMインスタン
ス

BMインスタン
ス

VM用イメージ

○

×

BM用イメージ

○

○
ネットワークの互換性
• Nova-networkのFlatDHCPが利用可能
• Neutronも一応利用可能
– 仮想ネットワーク機能は利用できないため
nova-networkを使うのとあまり違いがない

• 仮想ネットワーク対応は今後の課題
• ノードと接続している物理スイッチを制御
する方法が必要と思われる
– 過去にはOpenFlowスイッチ+Quantum NECプ
ラグインでの実験に成功
Ironic
• 次世代のベアメタルプロビジョニング実装
• 現在はNova内で実行されている処理を外に出す
– ノードDB,IPMI,PXE等
– NovaとIronicはHTTPで通信

• 機能的には現在のベアメタルプロビジョニングと
同等
• 現在は開発段階
– Nova側のドライバがまだ存在しないため実際の利用は
できない

• Icehouse期間中のリリース
• リリース後は現在のベアメタルプロビジョニング
は利用非推奨(Deprecated)となる
– 移行プログラムが提供される
※いずれも予定

ベアメタルプロビジョニング