ベアメタルプロビジョニング - OpenStack最新情報セミナー 2014年2月
Upcoming SlideShare
Loading in...5
×
 

ベアメタルプロビジョニング - OpenStack最新情報セミナー 2014年2月

on

  • 7,158 views

講師:日本仮想化技術 野津 ...

講師:日本仮想化技術 野津
日時:2014/02/06
タイトル:Moonshot System対応ベアメタルプロビジョニングのご紹介
概要:
OpenStackのベアメタルプロビジョニング技術と、HP社のMoonshot Systemのベアメタル対応について解説いたします。

Statistics

Views

Total Views
7,158
Slideshare-icon Views on SlideShare
1,721
Embed Views
5,437

Actions

Likes
1
Downloads
40
Comments
0

7 Embeds 5,437

http://virtualtech.jp 5322
http://enterprisecloud.jp 98
http://www.google.co.jp 7
http://webcache.googleusercontent.com 4
https://www.google.co.jp 3
https://twitter.com 2
http://translate.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    ベアメタルプロビジョニング - OpenStack最新情報セミナー 2014年2月 ベアメタルプロビジョニング - OpenStack最新情報セミナー 2014年2月 Presentation Transcript

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