Upcoming SlideShare
ベアメタルプロビジョニング - OpenStack最新情報セミナー 2014年2月
- 1. ベアメタルプロビジョニング 日本仮想化技術 野津 新 notsu@virtualtech.jp 1
- 2. 自己紹介 • 野津 新（のつ あらた） • 日本仮想化技術クラウド開発課所属 • インフラ系エンジニア • OpenStack – ベアメタルプロビジョニング – diskimage-builder（イメージ作成ツール）
- 3. アジェンダ • ベアメタルプロビジョニングとは？ • 構成要素 • 動作の解説 – インスタンス起動 • イメージの作成方法 – ボリュームの利用 • VMプロビジョニングとの互換性 – イメージ – ネットワーク • Ironic 3
- 4. ベアメタルプロビジョニングとは？ • サーバ仮想化技術を利用しないIaaS • メリット:高パフォーマンス • デメリット:物理マシン数がインスタンス数の 上限 従来のOpenStack ベアメタル OpenStack ユーザA ユーザA ユーザB ユーザB ユーザC ユーザC インスタンス=仮想マシン 物理サーバ群 インスタンス=物理マシン 物理サーバ群 4
- 5. インスタンスの機能 • インスタンスの起動・停止・再起動 – VMと同一のイメージから起動可能 • FlatNetworkに対応 – Neutronは利用可能だが仮想NWは不可 • 上記以外は未対応 – セキュリティグループ、スナップショット、VNC接続・・・ 参考:Hypervisor feature support matrix https://wiki.openstack.org/wiki/HypervisorSupportMatrix 5
- 6. 構成要素 • ノード：プロビジョニング対象の物理 マシン • ノードDB – ノードの情報・ステータスを保持 – Nova APIで操作 • ベアメタル管理ホスト – nova-compute + BareMetalDriver – PXE/TFTPサーバ：ノードをネットワーク ブート • デプロイ用ミニOS:ディスクにイメージを書き 6 込む
- 7. インスタンス起動 管理ホスト ノード 対象ノードはスケジューラによって 決定済:後述 ディスク イメージ カーネル カーネル RAMディス ク RAMディス ク デプロイ用 （ミニOS） OFF Glanceからイメージダウンロード (準備は後述） インスタンス用 PXE設定はデプロイ用 PXE ノードをPower On デプロイ用ミニOSが起動 イメージをディスクに書き込み PowerManager power on nova-barametaldeploy-helper ディスク デ プ ロ イ PXE PXE設定をインスタンス用に切替 再起動 以降はVMインスタンスと 同様の起動シーケンス (cloud-initなど) IPMI 通 常 7 詳 細 後 述
- 8. デプロイモード詳細 管理ホスト ノードをPower On ディスク イメージ ノード カーネル RAMディス ク デプロイ用 ミニOSが起動 プロビジョニング用 （ミニOS） ディスクをiSCSI エクスポート iSCSI エクスポート ディスク iSCSIアタッチ アタッチしたディスクに イメージを書き込む novabarametaldeploy-helper デ プ ロ イ 管理ホスト(deploy-helper) に準備完了を通知 PXE設定を通常用に切替 管理ホスト側での 作業完了を通知 8 再起動
- 9. ノードのハードウェア要件 • IPMIでの電源ON/OFF/状態取得 – または同等の機構+対応したPowerManager – 例)Moonshot対応 • 当初IPMIを使用する予定だったが、アクセス方法が特殊 （IPMI double bridge）だったため、IPMIを使用せずSSHイ ンターフェイスで実装 • https://github.com/virtualtech/nova • PXE起動ができること – BIOS設定で最優先にしておく • CPU・メモリ・ディスクなどのスペックは問わな い • が、スケジューリングの面から全ノード同じス ペックに揃えるのが無難（次のスライド） 9
- 10. スケジューリング • スケジューリング=インスタンスをどのノードに割り当て るか • nova-schedulerが決定 – computeは自分が持っているリソースの量をschedulerに通知 – ベアメタルの場合は管理下にある各物理ノードのスペック を送る • デフォルトでは最もメモリの多いノードが選択される – VMを想定した動作のためBMには向かないことがある – 小さいインスタンスタイプなのに大きいノードが空いてい るとそれを使ってしまう • 全ノードが均一のスペックであれば問題を回避できる • メモリの少ないノードを選択させるための設定（schedulerのnova.conf） 設定の変更で対応する場合 [DEFAULT] ram_weight_multiplier = -1 10
- 11. イメージの事前準備 • 必要になるイメージ – – – – – インスタンスのディスクイメージ インスタンスのカーネル インスタンスのRAMディスク ミニOSのカーネル ミニOSのRAMディスク • いずれもdiskimage-builderで作成可能 – https://github.com/openstack/diskimage-builder 11
- 12. イメージの作成・登録例 $ export DIB_DISTRIBUTION_MIRROR=http://jp.archive.ubuntu.com/ubuntu/ $ disk-image-create ubuntu baremetal image.qcow2 (A:ディスクイメージ) image.vmlinuz (B:カーネル) image.initrd (C:RAMディスク) $ ramdisk-image-create ubuntu deploy -o deploy deploy.kernel (D:ミニOSカーネル) deploy.initramfs (E:ミニOS RAMディスク) A〜EをGlanceに登録 $ glance image-create --name ubuntu-vmlinuz --public --disk-format aki < image.vmlinuz $ glance image-create --name ubuntu-initrd --public --disk-format ari < image.initrd $ glance image-create --name ubuntu --public --disk-format qcow2 --container-format bare < image.qcow2 $ glance image-create --name deploy-vmlinuz --public --disk-format aki < deploy.kernel $ glance image-create --name deploy-initrd --public --disk-format ari < deploy.initramfs イメージのプロパティでカーネル,RAMディスクを指定 $ glance image-update AのイメージID --property kernel_id=同B --property ramdisk_id=同C ミニOSのイメージIDはnova.confに書いておく [baremetal] deploy_kernel=DのイメージID deploy_ramdisk=EのイメージID
- 13. イメージの互換性 • インスタンスがVMかBMかを気にせず同じイメージを使 いたい • ドライバ（カーネルモジュール）がイメージに含まれて いるかがポイント – BMインスタンスには実ハードウェアのドライバが必要 – VMインスタンスには仮想ハードウェアのドライバが必要 • VM用イメージには実ハードウェアのドライバがないこと が多い – Ubuntuでいうとlinux-virtualパッケージ • BM用イメージには両方のドライバが含まれていることが 多い – Ubuntuでいうとlinux-genericパッケージ • BM用イメージならVMインスタンスでも使える 13 • アプリケーション側での対応は不要なことが多い
- 14. ボリュームの利用 • ボリューム（Cinder）も利用可能 ※アタッチ・デタッチ時にインスタンス内での操作が必 要 • ボリュームはCinderからiSCSI等でエクスポートされてい る • 利用時には2段階でアタッチ 1. ホスト(compute)がボリュームに接続 2. ホスト - インスタンス間を接続 – VMの場合はVirtIO：自動認識 – ベアメタルの場合はiSCSI：手動アタッチが必要（iscsiadm） 自動 VM nova 自動 VirtIO VMインス タンス Cinder iSCSI BM nova 手動 iSCSI BMインス タンス
- 15. ネットワークの互換性 • Nova-networkのFlatDHCPが利用可能 • Neutronも一応利用可能 – 仮想ネットワーク機能は利用できないため nova-networkを使うのとあまり違いがない • 仮想ネットワーク対応は今後の課題 • ノードと接続している物理スイッチを制御 する方法が必要 – 過去にはOpenFlowスイッチ+Quantum NECプ ラグインでの実験に成功 15
- 16. Ironic • 次世代のベアメタルプロビジョニング実装 • 現在はNova内で実行されている処理を外に出す – ノードDB,IPMI,PXE等 – NovaとIronicはHTTPで通信 • 機能的には現在のベアメタルプロビジョニングと 同等 • 現在は開発段階 – Nova側のドライバがまだ存在しないため実際の利用は できない • Icehouse期間中のリリース • リリース後は現在のベアメタルプロビジョニング は利用非推奨（Deprecated）となる – 移行プログラムが提供される 16 ※いずれも予定
- 17. まとめ • ベアメタルインスタンスは高パフォー マンス • 制限は多いので用途に合うかは要確認 – インスタンス数 – インスタンスの機能 – ネットワーク要件 17
Login to see the comments