OpenStack + Ceph 連携

こんにちは。最近 OpenStack の導入に向けて保守性や可用性について調査している @jedipunkz です。

OpenStack は MySQL のダンプや OS イメージ・スナップショットのバックアップをとっ ておけばコントローラの復旧も出来ますし、Grizzly 版の Quantum では冗長や分散が 取れるので障害時に耐えられます。また Quantum の復旧は手動もで可能です。最後の 悩みだった Cinder の接続先ストレージですが、OpenStack のスタンスとしては高価な ストレージの機能を使ってバックアップ取るか、Ceph, SheepDog のようなオープンソー スを使うか、でした。で、今回は Ceph を OpenStack に連携させようと思いました。

この作業により Cinder の接続先ストレージが Ceph になるのと Glance の OS イメー ジ・スナップショットの保管先が Ceph になります。

下記の参考資料が完成度高く、ほぼ内容はそのままです。若干付け足していますが。

参考資料

http://ceph.com/docs/master/rbd/rbd-openstack/

前提の構成

+-------------+-------------+--------------------------------------------- Public/API Network
|             |             |             
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
|           | |           | |vm|vm|..   | |           | |           | |           |
| controller| |  network  | +-----------+ |  ceph01   | |  ceph01   | |  ceph01   |
|           | |           | |  compute  | |           | |           | |           |
|           | |           | |           | |           | |           | |           |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
|             |     |       |     |       |             |             |
+-------------+-----)-------+-----)-------+-------------+-------------+-- Management/API Network
                    |             |                       
                    +-------------+-----------------------------------+-- Data Network
  • Ceph は OpenStack の Management Network 上に配置
  • Ceph は3台構成 (何台でも可)
  • OpenStack も3台構成 (何台でも可)
  • 連携処理するのは controller, compute ノード

では早速手順ですが、OpenStack と Ceph の構築手順は割愛します。私の他の記事を参 考にしていただければと思います。

Ceph + OpenStack 連携手順

OpenStack 用に Ceph Pool を作成する

ceph01% sudo ceph pool create volumes 128
ceph01% sudo ceph pool create images 128

sudoers の設定

controller, compute ノードにて sudoers の設定

jedipunkz ALL = (root) NOPASSWD:ALL

ceph パッケージのインストール

controller, compute ノードに ceph をインストールする。

controller% wget -q -O- 'https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc' | sudo apt-key add -
controller% echo deb http://ceph.com/debian/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list
controller% sudo apt-get update && sudo apt-get install -y python-ceph ceph-common

/etc/ceph 作成

controller% sudo mkdir /etc/ceph
compute   % sudo mkdir /etc/ceph

ceph コンフィギュレーションのコピー

controller, compute ノードに ceph コンフィギュレーションをコピーする。尚、接続 先の OpenStack ノードでの sudoers 設定は予め済ませること。

ceph01% sudo -i
ceph01# ssh <controller> sudo tee /etc/ceph/ceph.conf </etc/ceph/ceph.conf
ceph01# ssh <compute> sudo tee /etc/ceph/ceph.conf </etc/ceph/ceph.conf

認証設定

nova, cinder, glance 用にユーザを作成する。

ceph01% sudo ceph auth get-or-create client.volumes mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=volumes, allow rx pool=images'
ceph01% sudo ceph auth get-or-create client.images mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=images'

キーリングの作成

Ceph キーリングの作成を行う。Glance, Cinder が起動しているホスト controller ノードに キーリングを配置する。

ceph01% sudo ceph auth get-or-create client.images | ssh {your-glance-api-server} sudo tee /etc/ceph/ceph.client.images.keyring
ceph01% ssh {your-glance-api-server} sudo chown glance:glance /etc/ceph/ceph.client.images.keyring
ceph01% sudo ceph auth get-or-create client.volumes | ssh {your-volume-server} sudo tee /etc/ceph/ceph.client.volumes.keyring
ceph01% ssh {your-volume-server} sudo chown cinder:cinder /etc/ceph/ceph.client.volumes.keyring

compute ノードにて libvirt に secret key を格納する。ここで登場する uuid は後 に利用するためメモをとっておくこと。

ceph01 % sudo ceph auth get-key client.volumes | ssh 10.200.10.59 tee client.volumes.key

compute% cat > secret.xml <<EOF
<secret ephemeral='no' private='no'>
  <usage type='ceph'>
    <name>client.volumes secret</name>
  </usage>
</secret>
EOF
comupte% sudo virsh secret-define --file secret.xml
<uuid of secret is output here>
compute% sudo virsh secret-set-value --secret {uuid of secret} --base64 $(cat client.volumes.key) && rm client.volumes.key secret.xml

OpenStack 連携のための設定

controller:/etc/glance/glance-api.conf に下記を追記。

default_store=rbd
rbd_store_user=images
rbd_store_pool=images
show_image_direct_url=True

controller:/etc/cinder/cinder.conf に下記を追記。先ほど登場した uuid を入力す る。

volume_driver=cinder.volume.driver.RBDDriver
rbd_pool=volumes
rbd_user=volumes
rbd_secret_uuid={uuid of secret}

controller:/etc/init/cinder-volume.conf の冒頭に下記の記述を追記する。

env CEPH_ARGS="--id volumes"

OpenStack の各サービスを再起動もしくはホストの再起動を行う。

sudo service glance-api restart
sudo service nova-compute restart
sudo service cinder-volume restart

確認

実際にインスタンスを作成して Volume をアタッチしディスクを消費していくと Ceph のディスク使用量が増えていきます。

% cinder create --display-name test 5
% nova volumeattach <instance_id> <volume_id> auto

まとめ

Cinder は分散ストレージですので各ファイルのレプリカが全て失われない限りデータ はロストしません。ただし Ceph 自体の完成度は以前に比べ高くはなったものの、運用 に耐えられるかどうかまだ私にも分かりません。先日の OpenStack Day に来日してい たファウンデーションの方が「ベンダロックインするな」と言っていました。僕もオー プンソースでなんとかしたいと思っています。OpenStack を導入するためには今、Ceph は欠かすことが出来ないコンポーネントな気がしています。皆で Ceph も盛り上げて行 きたいです。

また、この構成の際のOpenStack 全体の保全について考えると…

  • MySQL のデータさえダンプの取得すれば OK
  • OS イメージ・スナップショットは Ceph 上にあるのでバックアップ不要
  • Ceph はなんとしても守る。バックアップ取るのは難しい
  • Network ノードは分散・冗長可能, データのバックアップは不要
  • Compute ノード上のインスタンスデータは Ceph のスナップショットから復旧

といったことが考えられます。つまり MySQL のデータさえダンプしておけば OpenStack 全体が復旧できることになります。実際にやってみましたが可能でした。

Chef Cookbook でユーザ・グループ追加

こんにちは。@jedipunkz です。 今回は Opscode Chef でユーザ・グループを作成する方法をまとめます。

‘users’ Cookbook を使います。

% cd ${YOUR_CHEF_REPO}
% ${EDITOR} Berksfile
cookbook 'users'
% berks install --path ./cookbooks

data_bag を使ってユーザ・グループの管理をしたいので管理ディレクトリを作成しま す。

% mkdir -p data_bags/users

data_bags/users/jedipunkz.json ファイルを作成します。必要に応じて内容を書き換えてください。

{
  "id": "jedipunkz",
  "ssh_keys": "ssh-rsa AAAABx92tstses jedipunkz@somewhere
  "groups": [ "sysadmin", "sudo" ],
  "uid": 2001,
  "shell": "\/usr\/bin\/zsh",
  "comment": "jedipunkz sysadmin",
  "password": "$1$s%H8BMHlB$7s3h30y9IB1SklftZXYhvssJ"

}

json ファイルの説明です。

  • id : ユーザ名
  • ssh_keys : SSH 公開鍵
  • groups : 所属させるグループ
  • uid : unix id
  • sheell : ログインシェル
  • comment : コメント
  • passwd : ハッシュ化したパスワード

特にハッシュ化したパスワードは下記のコマンドで生成出来ます。

% openssl passwd -1 'yourPassword'

data_bag を作成し json ファイルを読み込みます。

% knife data bag create users
% knife data bag from file data_bags/users/jedipunkz.json

現在 (2013/05/18 現在) 、’users’ Cookbook に不具合があるらしく groups に記した グループにユーザが所属してくれませんでした。なので下記の対処をします。 sysadmins.rb を今回は利用します。このファイルに下記の行を追記します。僕は sudo グループに所属させたかったので (先ほど groups: に記した) こうしましたが、他の グループが良ければ変更してください。また、Ubuntu Server を扱うことがメインの僕 なので group_id は 27 にしています。適宜変更してください。

% ${EDITOR} cookbooks/users/sysadmins.rb
# 下記の行を追記
users_manage "sudo" do
  group_id 27
end

cookbook を Chef サーバにアップロードします。

% knife cookbook upload users

適用したいノードの run_list に Recipe ‘users::sysadmins’ を追加します。

% knife node run_list add ${YOUR_NODE_NAME} users::sysadmins

chef-client の次回実行時にユーザ ‘jedipunkz’ が作成されているはずです。SSH で ログインして確認してみてください。待ちきれなかったら knife ssh して chef-client を実行してください。

この ‘users’ cookbook は他の Cookbook からも呼び出して利用することが出来るので 応用が利きますね。

Ceph-Deploy で Ceph 分散ストレージ構築

今回は ceph-deploy というツールを使って Ceph ストレージを簡単に構築することが 出来るので紹介します。Ceph は分散ストレージでオブジェクトストレージとしてもブ ロックストレージとしても動作します。今回の構築ではブロックストレージとしてのみ の動作です。

Ceph が公開しているのが ceph-deploy なわけですが、マニュアル操作に代わる構築方 法として公開しているようです。その他にも Chef Cookbook も公開されているようで す。

それでは早速。

今回の構成

+--------+ +--------+ +--------+
| ceph01 | | ceph02 | | ceph03 |
|  osd   | |  osd   | |  osd   |
|  mon   | |  mon   | |  mon   |
|  mds   | |  mds   | |  mds   |
+--------+ +--------+ +--------+
| 10.0.0.1 | 10.0.0.2 | 10.0.0.3
|          |          |          
+----------+----------+
|
| 10.0.0.10
+-------------+
| workstation |
+-------------+

特徴は

  • すべてのホストで osd, mon, mds を動作
  • ceph データ格納用ディスクデバイスを /dev/sdb として利用
  • workstation は ceph-deploy を実行するホスト

です。osd は object store daemon で実際にファイルを格納していくデーモン。mon はモニタリング用デーモン, mds は metadata server で POSIX 互換のファイルシステ ムをクライアントに提供するためのデーモンです。

ceph-deploy を使うまでの準備

ceph-deploy を使うまでのターゲットのホスト ceph01-03 と workstation と共に準備 が必要です。

ceph01-03 の準備

‘ceph’ ユーザの作成を行う。

% ssh user@ceph-server
% sudo useradd -d /home/ceph -m ceph
% sudo passwd ceph

sudoers の設定を行う。

% echo "ceph ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/ceph
% sudo chmod 0440 /etc/sudoers.d/ceph

workstation の準備

ノンパスフレーズの SSH 公開鍵・秘密鍵を生成する。

workstation% ssh-keygen
Generating public/private key pair.
Enter file in which to save the key (/ceph-client/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /ceph-client/.ssh/id_rsa.
Your public key has been saved in /ceph-client/.ssh/id_rsa.pub.

公開鍵をターゲットホスト (ceph01-03) に配置

workstation% ssh-copy-id ceph@ceph01
workstation% ssh-copy-id ceph@ceph02
workstation% ssh-copy-id ceph@ceph03

ceph-deploy の取得を行う。

workstation% git clone https://github.com/ceph/ceph-deploy.git ~/ceph-deploy

‘python-virtualenv’ パッケージをインストールする。

workstation% sudo apt-get update ; sudo apt-get -y install python-virtualenv

ceph-deploy をブートストラップする

workstation% cd ~/ceph-deploy
workstation% ./bootstrap

PATH を通す。自分の shell に合わせて登録してください。

workstation% ${EDITOR} ~/.zshrc
export PATH=$HOME/ceph-deploy:$PATH

ホスト名の解決を行う。

workstation% sudo ${EDITOR} /etc/hosts
10.0.0.1    ceph01
10.0.0.2    ceph02
10.0.0.3    ceph03

これで準備は終わり。

3台構成構築

3台 (ceph01-03) を新規に構築する方法を書きます。すべて workstaiton 上からの操 作です。

ceph サーバ・クライアント間通信のための鍵の生成とコンフィギュレーションの生成 を下記の操作で行う。

workstation% ceph-deploy new ceph01 ceph02 ceph03

下記の操作で ceph パッケージのインストールを各 Ceph サーバにて行う。–testing 等と引数を渡せば RC 版の利用が行える。何も渡さなければ stable 版。

workstation% ceph-deploy install ceph01 ceph02 ceph03

MON daemon のデプロイを行う。

workstation% ceph-deploy mon create ceph01 ceph02 ceph03

鍵のデプロイを行う。Ceph サーバ間・クライアント間での共有鍵である。1 Cluster に対して1つの鍵を保有する。

workstation% ceph-deploy gatherkeys create ceph01 ceph02 ceph03

OSD daemon のデプロイを行う。下記の様にパーティションを指定しなければツールが 自動でパーティショニングを行なってくれる。

workstation% ceph-deploy osd create create ceph01:/dev/sdb ceph02:/dev/sdb ceph03:/dev/sdb

MDS deamon のデプロイを行う。

cephcleint% ceph-deploy mds create ceph01 ceph02 ceph03

これで終わりです。これらの操作が終わるとすべてのホスト ceph01-03 で mon, osd, mds の各デーモンが起動していることが分かると思います。超カンタン!

マウントしてみよう!

さぁ~、クライアントからマウントしてみましょう。ここでは workstaion ホストを利 用します。Linux 系のマシンで同じネットワークセグメントに属していれば大抵マウン ト出来ると思います。mds が稼働しているホストに対してであればどこにでもマウント 出来ます。

Block Device としてマウントする方法

ストレージ上に block device を生成しそれをマウントする。

workstation% rbd create foo --size 4096
workstation% sudo modprobe rbd
workstation% sudo rbd map foo --pool rbd --name client.admin
workstation% sudo mkfs.ext4 -m0 /dev/rbd/rbd/foo
workstation% sudo mkdir /mnt/myrbd
workstation% sudo mount /dev/rbd/rbd/foo /mnt/myrbd

Kernel Driver を用いてマウントする方法

kernel Driver を用いてストレージをマウントする。

workstation% sudo mkdir /mnt/mycephfs
workstation% sudo mount -t ceph 10.0.0.1:6789:/ /mnt/mycephfs -o \
            name=admin,secret=`sudo ceph-authtool -p /etc/ceph/ceph.keyring`

Fuse Driver (ユーザランド) を用いてマウントする方法

ユーザランドソフトウェア FUSE を用いてマウントする。

workstation% sudo mkdir /home/<username>/cephfs
workstation% sudo ceph-fuse -m 10.0.0.1:6789 /home/<username>/cephfs

まとめ

もし導入するのであればマニュアルでの構築も一度体験した方が良いかもしれません。 ツールを使うと一体どんな作業がされているのか理解出来ないので。ただ今ではマニュ アル操作で構築している途中に ‘ceph-deploy を使ってください’ と warning が出る ので、開発元としてもこちらの構築方法を薦めたいのでしょう。あと Ceph はドキュメ ントが非常に充実しています。ドキュメントの全てに大事なことが書いてあるので一度 読むことをオススメします。また Ceph が Chef Cookbook も公開しているようで、そ ちらの方法もドキュメントにチラっと書いてありました。私はまだ試していませんが時 間があればやってみたいです。あとあと!ceph-deploy はまだ未完成な域を脱していま せん。上記の通り新規構築系の操作はひと通り出来るのですが、ホストの削除系の実装 がまだされていませんでした。ホスト追加系の操作に関しても削除系程ではないのです が完成度が上がっていません。手作業で少しカバーしてあげる必要があります。

OpenStack の Cinder の先のストレージについて最近考えていました。LVM 管理のロー カルディスクでもいいのですが運用のことを考えるとバックアップを取らなくちゃい けないのだけど logcal volume が存在しないのでスナップショットバックアップが出 来なそう。Cinder は比較的高価なストレージも扱えるのでそちらの機能でバックアッ プ取るのもいいけど、ここはオープンソースでなんとかしたい!と思って Ceph を検討 してみました。

Ceph は分散ストレージでオブジェクトストレージとしてもブロックストレージとして も動作が可能。OpenStack と組み合わせると Cinder の先のストレージとしても Glance のイメージ置き場としても利用可能らしい。Cinder の接続先ストレージとして の動作方法はまた別の機会にブログに書きます。

Quantum Network ノードの分散・冗長

こんにちは。Grizzly がリリースされてから暫く経ちました。今回は Folsom リリース まであった Quantum ノードのボトルネックと単一障害点を解決する新しい機能につい て評価した結果をお伝えします。

Folsom までは

  • Quantum L3-agent が落ちると、その OpenStack 一式の上にある仮想マシン全ての通 信が途絶える
  • Quantum L3-agent に仮想マシンの全てのトラフィックが集まりボトルネックとなる。

という問題がありました。Folsom リリース時代にもし僕が職場で OpenStack を導入す るのであればこれらを理由に nova-network を選択していたかもしれません。 nova-network は compute ノードが落ちればその上の仮想マシンも同時に落ちるが、他 の compute ノード上の仮想マシンの通信には影響を与えないからです。もちろん仮想 ルータ・仮想ネットワークの生成等を API でユーザに提供したいなどの要望があれば Quantum を選択するしかありませんが。これに対して Grizzly リリースの Quantum は 改善に向けて大きな機能を提供してくれています。L3-agent, DHCP-agent の分散・冗 長機能です。

下記の構成が想定出来ます。ここでは Network ノードを2台用意しました。それ以上の 台数に増やすことも出来ます。

+-------------+-------------+-------------------------- Public/API Network
|             |             |
+-----------+ +-----------+ +-----------+ +-----------+
|           | |           | |           | |vm|vm|..   |
| controller| |  network  | |  network  | +-----------+
|           | |           | |           | |  compute  |
+-----------+ +-----------+ +-----------+ +-----------+
|             |     |       |     |       |     |
+-------------+-----)-------+-----)-------+-----)------ Management/API Network
                    |             |             |
                    +-------------+-------------+------ Data Network

L3-agent の分散は仮想ルータ単位で行います。それに対し DHCP-agent は仮想 ネットワーク単位で行います。

agent 一覧の取得

上記の構成を構築すると下記のように agent 一覧が取得出来ます。

% quantum agent-list # 'admin' ユーザでアクセス
+--------------------------------------+--------------------+-----------------------+-------+----------------+
| id                                   | agent_type         | host                  | alive | admin_state_up |
+--------------------------------------+--------------------+-----------------------+-------+----------------+
| 44795822-2d9f-434e-ba98-748f7411442f | DHCP agent         | grizzly03.example.com | :-)   | True           |
| a5150a40-0405-4399-ac1a-be012f55d9f5 | DHCP agent         | grizzly02.example.com | :-)   | True           |
| b7bf4e59-06ac-475c-84ab-413d8d29f293 | Open vSwitch agent | grizzly04.example.com | :-)   | True           |
| cc5a6b94-6ddd-4109-8f2f-1b28c6aaf5e6 | L3 agent           | grizzly03.example.com | :-)   | True           |
| d39803cf-19d3-47d7-8205-cf9a143dd0ea | Open vSwitch agent | grizzly02.example.com | :-)   | True           |
| d8e59803-9aad-4c62-a47a-519bc788e0fb | Open vSwitch agent | grizzly03.example.com | :-)   | True           |
| f6f747cf-ffb0-446c-a455-2947fd3e87e8 | L3 agent           | grizzly02.example.com | :-)   | True           |
+--------------------------------------+--------------------+-----------------------+-------+----------------+

ホスト名は下記。

  • controller : grizzly01.exmaple.com
  • network01 : grizzly02.exmaple.com
  • network02 : grizzly03.exmaple.com
  • compute : grizzly04.exmaple.com

L3-agent の分散方法 (ノード移動)

仮想ルータ (ここでは ‘router-test01’ とする) がどの L3-agent に属しているか確 認を取る。

% quantum l3-agent-list-hosting-router router-demo
+--------------------------------------+-----------------------+----------------+-------+
| id                                   | host                  | admin_state_up | alive |
+--------------------------------------+-----------------------+----------------+-------+
| f6f747cf-ffb0-446c-a455-2947fd3e87e8 | grizzly02.example.com | True           | :-)   |
+--------------------------------------+-----------------------+----------------+-------+

1台目の Network ノード (grizzly02.example.com) 上の L3-agent に属していること が確認取れた。次にこの親子関係を削除する。

% quantum l3-agent-router-remove f6f747cf-ffb0-446c-a455-2947fd3e87e8 router-test01
Removed Router router-demo to L3 agent

最後に仮想ルータ ‘router-test01’ を2台目の Network ノード上の L3-agent の管理 下に設定する。

% quantum l3-agent-router-add cc5a6b94-6ddd-4109-8f2f-1b28c6aaf5e6 router-demo
Added router router-demo to L3 agent
% quantum l3-agent-list-hosting-router router-demo
+--------------------------------------+-----------------------+----------------+-------+
| id                                   | host                  | admin_state_up | alive |
+--------------------------------------+-----------------------+----------------+-------+
| cc5a6b94-6ddd-4109-8f2f-1b28c6aaf5e6 | grizzly0404.cpi.ad.jp | True           | xxx   |
+--------------------------------------+-----------------------+----------------+-------+

DHCP-Agent の分散方法 (ノード移動)

仮想マシンが所属しているネットワーク (ここでは ‘int_net’) がどの DHCP-agent に所属しているか確認する。

% quantum dhcp-agent-list-hosting-net int_net
+--------------------------------------+-----------------------+----------------+-------+
| id                                   | host                  | admin_state_up | alive |
+--------------------------------------+-----------------------+----------------+-------+
| a5150a40-0405-4399-ac1a-be012f55d9f5 | grizzly02.example.com | True           | :-)   |
+--------------------------------------+-----------------------+----------------+-------+

1台目のノードに所属しているのが確認できる。次に ‘int_net’ が所属する DHCP-agent を削除行う。

% quantum dhcp-agent-network-remove a5150a40-0405-4399-ac1a-be012f55d9f5 int_net
Removed network int_net to DHCP agent

2台目のノードの DHCP-agent を仮想ネットワーク ‘int_net’ に紐付ける。

% quantum dhcp-agent-network-add 44795822-2d9f-434e-ba98-748f7411442f int_net
Added network int_net to DHCP agent
% quantum dhcp-agent-list-hosting-net int_net
+--------------------------------------+-----------------------+----------------+-------+
| id                                   | host                  | admin_state_up | alive |
+--------------------------------------+-----------------------+----------------+-------+
| 44795822-2d9f-434e-ba98-748f7411442f | grizzly0404.cpi.ad.jp | True           | :-)   |
+--------------------------------------+-----------------------+----------------+-------+

まとめ

この様に仮想ルータ, 仮想ネットワーク単位で Network ノードの agent の分散が行え る。上記のように仮想ルータ・ネットワークが1つずつでは分散という意味では無いが 運用の過程で仮想ルータ・ネットワークは増えることが想定出来るのでその際にはトラ フィック・DHCP 機能を分散することが可能になる、と言える。また片系の Network ノー ドに寄せておいてからの障害テスト -> もう片系への移動も行なってみたが作業ととも に仮想マシンの通信が復旧した。このテストを行う前まで ‘agent の移動だけ行えるの であって仮想ルータ自体が移動するわけではないので冗長という意味はない’ と考えて いたのだが、実際には上記の操作で namespace が移動していることが判り (Quantum の仮想ルータの実体は Linux Namespace) 障害テストの結果、うまくいった。 OpenStack を導入するという意味で、この機能は非常に大きな前進だと僕は思っていま す。

Chef for OpenStack: Grizzly Roadmap

以前にも話題にしたことがある Chef For OpenStack ですが今週新しい情報が入って来 ました。#ChefConf 2013 というイベントがあったのですがここで Opscode の Matt Ray さんらが集まり OpenStack を Chef で構築する ‘Chef for OpenStack’ について 語られた模様です。その時の資料が SlideShare に上がっていたので見てみました。

気にあった点を幾つか挙げていきます。

  • https://github.com/osops で管理される
  • 各コンポーネントの cookbook の名前には ‘-cookbook’ を最後に付ける
  • quantum, cinder, ceilometer, heat 等、比較的新しいコンポーネントも加わる
  • gerrit でコードレビューされ CI も提供される
  • Chef11 が用いられる
  • Ruby 1.9.x に対応した chef-client が用いられる
  • Foodcritic で可能な限りテストされる
  • chef-solo はサポートされない
  • 5月に ‘2013.1.0’ がリリースされる (openstack 2013.1 対応と思われる)
  • chef-repo の形で提供される
  • Ubuntu 12.04 が前提
  • HyperVisor は KVM, LXC がサポートされる

以上です。恐らく chef-repo で提供されるということは spiceweasel を使った構成構 築が出来るような形になるでしょう。楽しみです。またコントリビュートする方法も掲 載されているので興味が有る方は協力してみるのも楽しいかもしれません。

OpenStack Grizzy で非 Virtio OS 稼働

こんにちは jedipunkz です。

Virtio に対応していない OS を OpenStack で稼働させることが今まで出来なかったの ですが Grizzly から非 Virtio な OS イメージが扱えるようになった。今まで NetBSD やら古い FreeBSD やら virtio ドライバを OS イメージに入れることに苦労していたの だけど、これで問題無くなった。

最初、この機能のこと調べるのに「どうせ libvirt が生成する xml を書き換えるのだ から nova 周りの設定なんだろうー」と思っていたら全く方法が見つからず…。結局 OS イメージを格納している Glance の設定にありました。

ここでは FreeBSD7.4 Release を例に挙げて説明していきます。

前提とする環境

  • OpenStack Grizzly が稼働していること
  • ホスト OS に Ubuntu 12.04.2 LTS が稼働していること
  • ゲスト OS に FreeBSD 7.4 Release を用いる

とします。OS のバージョンはホスト・ゲスト共に、上記以外でも構いません。Grizzly さえ動いていれば OK です。

OS イメージ作成

KVM で OS イメージを作成します。もちろん virtio なインターフェースは指定せず

  • IDE ディスクインターフェース
  • e1000 (intel) ネットワークインターフェース

を指定してあげてください。

% kvm-img create -f qcow2 <IMAGE_NAME> 5G
% sudo kvm -m 1024 --cdrom FreeBSD-7.4-RELEASE-amd64-disc1.iso --drive \
  file=./<IMAGE_NAME> -boot d -net nic,model=e1000 -net user -nographic \
  -vnc :9

VNC クライアントソフトを用いてホスト :9 番に接続し OS をインストールする。

Glance への登録

OpenStack API に接続する環境変数等を合わせ下記のコマンドを実行します。

% glance image-create --name="FreeBSD7.4" --is-public \
  true --container-format bare --disk-format qcow2 < <IMAGE_NAME>
% glance image-update --property hw_vif_model=e1000 "FreeBSD7.4"
% glance image-update --property hw_disk_bus=ide "FreeBSD7.4"

–property オプションでディスク・ネットワークインターフェースの指定を変更して います。

VM の稼働

あとは普段通り nova boot コマンドで VM を稼働させるだけです。

% nova boot --nic net-id=<network_id> --image <image_id> --flavor <flavor_number> <vm_name>

OpenStack Grizzly 構築スクリプト

OpenStack Grizzly がリリースされて2週間ほど経過しました。皆さん動かしてみまし たか?今回、毎度の構築 Bash スクリプトを開発したので公開します。

下記のサイトで公開しています。

https://github.com/jedipunkz/openstack_grizzly_install

このスクリプト、複数台構成とオールインワン構成の両方が構成出来るようなっていま すが、今回は簡単なオールインワン構成の組み方をを簡単に説明したいと思います。

前提の環境

  • Ubuntu 12.04 LTS が稼働している
  • Cinder のためのディスクを OS 領域と別に用意 (/dev/sdb1 など)
  • オールインワン構成の場合は 2 NICs 準備

Ubuntu 13.04 の daily build も完成度上がっている時期ですが OVS 側の対応が OpenStack 構成に問題を生じさせるため 12.04 LTS + Ubuntu Cloud Archive の組み合 わせで構築するのが主流になっているようです。また、Cinder 用のディスクは OS 領 域を保持しているディスクとは別 (もしくはパーティションを切ってディスクデバイス を別けても可) が必要です。オールインワン構成の場合は NIC を2つ用意する必要があ ります。通常 OpenStack を複数台構成する場合は

  • コントローラノード x 1 台
  • ネットワークノード x 1 台
  • コンピュートノード x n 台

で組み、VM はコンピュートノードからネットワークノードを介してインターネットに 接続します。よってそのため更に NIC が必要になるのですが、オールインワン構成の 場合は

  • マネージメントネットワーク, API ネットワーク(内部通信用)
  • パブリックネットワーク (VM のためのブリッジインターフェース)

の計2つを用意してください。

実行前の準備

OS のインストール

OS のインストール方法は割愛しますが

  • ‘openssh-server’ のみをインストール
  • ディスクが1つしかない場合は cinder 用のパーティションを用意

の条件が満たされていれば OK です。

Cinder 用のディスクデバイスパーティショニング

Cinder 用に信頼性のあるディスクを用意している場合は fdisk 等を用いてパーティショ ニングしてください。近々 loopback デバイスでも構築できるようスクリプトの改修を する予定です。ディスクが一つしかない場合は先程述べたとおり、OS インストール時 にパーティショニングしたディスクデバイスを使います。

% sudo fdisk /dev/sdb

ネットワークインターフェースの設定

下記のように2つのネットワークインターフェースを設定してください。

% sudo ${EDITOR} /etc/network/interfaces
auto lo
iface lo inet loopback

# this NIC will be used for VM traffic to the internet
auto eth0
iface eth0 inet static
    up ifconfig $IFACE 0.0.0.0 up
    up ip link set $IFACE promisc on
    down ip link set $IFACE promisc off
    down ifconfig $IFACE down
    address 10.200.9.10
    netmask 255.255.255.0
    dns-nameservers <DNS_RESOLVER1> <DNS_RESOLVER>
    dns-search example.com

# this NIC must be on management network
auto eth1
iface eth1 inet static
    address 10.200.10.10
    netmask 255.255.255.0
    gateway 10.200.10.1
    dns-nameservers <DNS_RESOLVER1> <DNS_RESOLVER>

eth0 が VM のためのブリッジインターフェースになります。eth1 はマネージメントネッ トワーク用・内部 API 通信用の兼務です。

スクリプトの取得とパラメータ設定

スクリプトの取得を行います。

% git clone git://github.com/jedipunkz/openstack_grizlly_install.git
% cd openstack_grizzly_install

パラメータを設定するため setup.conf 内の各パラメータを設定変更します。数多くの パラメータがありますが、最低限のパラメータということで…

HOST_IP='10.200.10.10'
HOST_PUB_IP='10.200.9.10'
PUBLIC_NIC='eth0'

を設定してください。HOST_IP は eth1 の IP アドレス、HOST_PUB_IP は eth0 の IP アドレス、PUBLIC_NIC は eth0 (HOST_PUB_IP のインターフェース名) を指定します。

スクリプトの実行

いよいよスクリプトを実行します。

% sudo ./setup.sh allinone

しばらくすると構築が完了します。あとは

http://${HOST_IP}/horizon/

にブラウザでアクセスすると WEB I/F である Horizon のログイン画面が表示されます。 パラメータをいじっていなければユーザ : demo, パスワード : demo でアクセス出来 ます。

各 API にコマンドでアクセスする

API にアクセスするためにコマンドを用いることも出来ます。スクリプトを実行した結 果、下記のファイルが生成されているはずです。

~/openstackrc-demo # 'demo' ユーザで API にアクセス
~/openstackrc      # 'admin' ユーザで API にアクセス

‘demo’ ユーザでアクセスするためには

% source ~/openstackrc-demo

を実行してください。環境変数が設定され API にアクセス出来るようになります。例 として下記のコマンドを実行してみてください。

% glnace image-list
+--------------------------------------+---------------------+-------------+------------------+------------+--------+
| ID                                   | Name                | Disk Format | Container Format | Size       | Status |
+--------------------------------------+---------------------+-------------+------------------+------------+--------+
| 1a7943a5-8f8f-4c02-9763-5a6d519c31bb | Cirros 0.3.0 x86_64 | qcow2       | bare             | 9761280    | active |
+--------------------------------------+---------------------+-------------+------------------+------------+--------+

OS イメージ一覧が取得出来ます。スクリプトで予め Glance に登録した Cirros とい う小さな OS イメージが確認出来るはずです。

まとめ

本格的な構成を組むのであれば上記の URL にも知る指定ある複数台構成を組んでみて ください。同じくスクリプトで構築出来ます。また今回から Quantum に実装された LBaaS も組めるようになっています。構築出来た OpenStack で LB を組んでみてくだ さい。LBaaS の説明については OpenStack ユーザ会の中島さんのブログが参考になり ます。

http://aikotobaha.blogspot.jp/2013/04/use-full-function-of-openstack-grizzly.html

LBaaS で組める負荷分散方式が ‘ROUND_ROBIN’ 以外にも選択出来るぽいのでもう少し 調べたら、僕のブログでも紹介しようかと思います。また Grizzly になって数多くの 機能が新たに実装されているので引き続き紹介していこうかと思います。

OpenStack は多くの機能がありますし構成の仕方も様々。予め理解しなければいけない 技術も多岐にわたるのでブログだけではなかなか説明し切れないところです。 OpenStack のコミュニティが書いた ‘OpenStack Operations Guide’ なるドキュメント が最近リリースされました。

http://docs.openstack.org/ops/

日本のユーザ会でもこのドキュメントを翻訳しようという活動がされている最中です。 興味があるかたは一度読むことをオススメしますし、もし更に興味が有る方は翻訳活動 に協力するのはいかがでしょうか。ユーザ会の ML で現在話が進んでいます。

引き続き、OpenStack ネタはアップしていきますー。

Chef 11 サーバのローカルネットワーク上構築

chef-solo を使うの?Chef サーバを使うの?という議論は結構前からあるし、答えは 「それぞれの環境次第」だと思うのだが、僕は個人的に Chef サーバを使ってます。ホ ステッド Chef を使いたいけどお金ないし。会社で導入する時はホステッド Chef を契 約してもらうことを企んでます。(・∀・) 何故なら cookbooks を開発することがエン ジニアの仕事の本質であって Chef サーバを運用管理することは本質ではないから。そ れこそクラウド使えという話だと思う。

でも!Chef に慣れるには無料で使いたいし、継続的に Cookbooks をターゲットノード で実行したい。ということで Chef サーバを構築して使っています。

Chef 10 の時代は Chef サーバの構築方法は下記の通り3つありました。

  • 手作業!
  • Bootstrap 構築
  • Opscode レポジトリの Debian, Ubuntu, CentOS パッケージ構築

それが Chef 11 では

  • Ubuntu, RHEL のパッケージ (パッケージインストールですべて環境が揃う)

http://www.opscode.com/chef/install/

この方法1つだけ。でも簡単になりました。

‘Chef Server’ タブを選択するとダウンロード出来る。じっくりは deb ファイルの中 身を見たことがないけど、チラ見した時に chef を deb の中で実行しているように見 えた。徹底してるw

Chef 10 時代のパッケージと違って行う操作は下記の2つのコマンドだけ。

% sudo dpkg -i chef-server_11.0.6-1.ubuntu.12.04_amd64.deb # ダウンロードしたもの
% sudo chef-server-ctl reconfigure

簡単。でも… この状態だと https://<サーバの FQDN> でサーバが Listen している。 IP アドレスでアクセスしてもリダイレクトされる。つまり、ローカルネットワーク上 に構築することが出来ない。安易に hosts で解決も出来ない。何故ならターゲットノー ドは通常まっさらな状態なので bootstrap するたびに hosts を書くなんてアホらしい しやってはいけない。

今日の本題。ローカルネットワーク上に Chef 11 サーバを構築する方法を調べました。

修正箇所

  • /var/opt/chef-server/chef-pedant/etc/pedant_config.rb

URL を IP アドレスに変更する。

chef_server "https://chef.example.com"
  • /var/opt/chef-server/erchef/etc/app.config

URL を IP アドレスに変更する。

{s3_url, "https://chef.example.com"},
  • /var/opt/chef-server/nginx/etc/nginx.conf

URL を IP アドレスに変更する。2箇所あるので注意。鍵ファイルにも FQDN が記され ているがそれらは変更しない。

server_name chef.example.com;
  • /etc/chef-server/chef-server-running.json

URL を IP アドレスに変更する。鍵ファイルにも FQDN が記されているがそれらは変更 しない。

"vip": "chef.example.com",
"api_fqdn": "chef.example.com",
"web_ui_fqdn": "chef.example.com",
"server_name": "chef.example.com",
"url": "https://chef.example.com",

最後に Chef サーバを再起動する。

% sudo chef-server-ctl restart

まとめ

会社で、この環境を使って色々試しています。今のところ不具合なく動作している。強 引ワザなのでもっと綺麗な方法を知っている方がいましたら教えて下さい。 m ( _ _ ) m

クラウドマネジメント勉強会レポ

クラウドマネジメント勉強会に参加してきた。今が旬なのか定員140名が埋まっていま した。クラウドフェデレーションサービス各種の話が聞ける貴重な勉強会の場でした。

場所 : スクエアエニックスさん
日程 : 2013年4月5日 19:00 -

少し長くなるので、早速。

クラウド運用管理研究会

クラウド利用推進機構が運営するクラウド運用管理研究会は下記の3つに分別されるそ うです。今回は一項目の ‘クラウドマネジメントツール研究会’ にあたるそう。別の研 究会も既に勉強会を実施しているそうです。

  • クラウドマネジメントツール研究会
  • デザインパターン研究会
  • 運用管理・監視研究会

AWS OpsWorks

アマゾンデータサービスジャパン AWS 片山さん, 船崎さん

OpsWorks は最近話題になった AWS 利用者に無料で提供されるクラウドフェデレーショ ンサービス。Web UI で操作し簡単デプロイを実現するサービスです。

OpsWorks が自動化するモノ

  • サーバ設定
  • ミドルウェア構築

特徴

  • Chef フレームワークを利用 (chef-solo を内部的に利用)
  • 任意の cookbooks を利用可能
  • LB, AP, DB などをレイヤ化, 任意のレイヤも作成可能

OpsWorks の流れ

  • Stack 作成
  • レイヤ作成 (LB, AP, DB, 任意)
  • レシピの作成
  • レイヤにインスタンス作成

下記をレイヤ化で区別する

  • Package インストール
  • OS 設定
  • アプリデプロイ

所感

AWS OpsWorks の登場で他のクラウドフェデレーションサービスがどうなるの?とさえ 思った。AWS はインターネット・ホスティング業界のあらゆるサービスを押さえようと している感がある。もう隙間がない!w OpsWorks に関してまだ問題は残っているそう だ。VPC, micro 現在未対応など。が解決に向けて作業しているそう。

Aeolus Conductor

RedHat 中井さん

概要

複数クラウドに対応したイメージ作成・アプリケーション環境構築の自動化ツール

  • アプリのデプロイ機能にフォーカス
  • Red Hat CoudForms が商用版
  • マルチクラウド (ユーザにクラウドが割り当てられる, Hybrid, EC2, RHEV)

自動化について中井さんの案 (手作り)

  • libvirt キック
  • kickstart 実行
  • post script にて puppet 実行
  • manifest は github で管理

これらは単一のサーバのみで実施できて、複数台構成等を前提に出来ない等の問題があ る。それらを解決するのが Aeolus Conductor。

Aeolus Conductor の要素

  • システムテンプレート用意 (XML) : OS 構成内容が記されている
  • マシンイメージ JEOS
  • アプリケーションブループリント (アプリデプロイ設計書) shell script である。puppet, chef を呼び出しても OK.
  • Config サーバを介して VM 間の構成を管理している : インテグレート! DB, Web

Aeolus Conductor の不便な点

  • 特定のクラウド特有の機能には未対応
  • 複数 VM デプロイ時のワークフロー処理が不十分

所感

画面を見させてもらったが AWS EC2, RHEV (RedHat の仮想化ソフト) とマルチクラウ ドに対応していた。ユーザにどのクラウドを割り当てるか?等の権限委譲が出来るもの ユニーク。

Scalr

Scalr ユーザ会 梶川さん (IDC フロンティア)

概要, 特徴

  • オープンソースのマルチクラウド管理ツール
  • 利用出来るクラウド : AWS, Eucalyptus, RackSpace, nimbula, OpenStack, …
  • 冗長化・オートスケール可能
  • モニタリングも自動で開始
  • DNS 管理, オートスケール時、自動的に修正が行われる
  • スクリプト実行 (任意のタイミングで可能、またタイミングを作成可能)
  • 各サービスのコンフィグプリセット管理 (ミドルウェアのパラメータ?)

所感

Scalr ユーザ会のメンバ募集中だそうだ。個人的にオープンソースの Scalr を試そう と思ったことがあるのだが、手順の wiki が解りづらかった。商用サービスを使わせる ためにわざと解りづらくしているのか?と思うほど。ユーザ拡大のために是非ドキュメ ントの整備をお願いしたい。

RightScale の利用効果と苦労話

So-net エンタテインメント 成田さん

利用効果

  • 1つのスクリプトを複数台に対して実行可能
  • 手作業が自動化へ
  • ベストプラクティスの利用が可能に
  • モニタリングの自動化へ
  • サーバ台数のスケジューリング化
  • セキュリティグループはマクロで作成
  • 権限分離による開発者・プロデューサに役割移譲
  • 履歴管理の自動記録
  • chef recipe が right スクリプトとして走らせられる

苦労話

  • Alert 設定のミスでメール大量受信
  • 自動化スクリプトのエラー対応
  • 計画メンテナンスの後は要注意 (仕様変更)
  • RightScale 上の表示を過信しない, 詳しくはクラウドサービス側を確認
  • LANG=ja_JP.UTF-8 するとコケる
  • メンテナンスは金曜日日中 (月に一回)

所感

実際に運用している方の話はとても貴重。特に苦労ネタはなかなか知ることが出来ない ので。自動化のためにスクリプトを書くのがインフラ系エンジニアの仕事になると知ら せてくれた。Right スクリプトには Chef のレシピも走らせることが出来る、というも が魅力。またインフラ系エンジニア以外の職種の人にも権限委譲し UI を操作してもら える辺りは、業務の最適化のために大いに利用できると感じた。

Chef の話

Engine Yard @yando さん

Engine Yard とは

  • PaaS
  • AWS + Chef + サポート, 監視
  • chef-solo をキック
  • chef recipe の管理は Engine Yard が行う

Chef へのモチベーション

  • 冪等性
  • シェルスクリプトだと構築直後の状態しか保証されない

chef-solo の話

  • knife-solo でノードに SSH せずに実行

利用するにあたって直面する課題

  • レシピの実装 -> github 上のレシピを参照・利用
  • Vagrant の利用でレシピの複数プラットフォーム上でのテスト
  • レシピの配布方法 -> github, berkshelf, knife solo, nfs, chef-server
  • レシピの反映 -> capistrano, chef-client, cron

Engine Yard Local

  • クラウドと同じレシピでローカルに開発環境を構築出来るツール
  • クラウドはコストが掛かるし遅いので出来る事ならローカルで、という発想

所感

Chef 流行ってますね。うんうん、(・∀・)イイ!! 個人的には Chef の Cookbooks 開発 はインフラエンジニアにしてもらいたい。Engine Yard のような PaaS 使うならアレだ けどクラウド使うなら運用は引き続き必要だし、運用を意識した Cookbooks 開発は絶 対に必要になってくるからだ。Chef の関連技術がものすごいスピードで進化している のも魅力。より便利で旬な技術をすぐに利用し貢献する、という良いサイクルをうちの 会社でも実現したい。だって楽しいから。chef-solo 使うの?chef サーバ使うの?と いう話はここでも挙がってた。どこかでブログにしようかな。僕は chef サーバ使わな い理由がないと思ってる。

NetBSD on OpenStack

もう数日で OpenStack の次期バージョン版 Grizzly がリリースされるタイミングだが 現行バージョン Folsom の OpenStack の上に NetBSD を載せてみた。完全にお遊び だけど…。

結局、ほとんど何も特別な対応取ることなく NetBSD が動いた。もちろんハイパーバイ ザは KVM です。だけど少し条件がある。

qemu の不具合があり Ubuntu 12.04 LTS + Ubuntu Cloud Archives の組み合わせでは NetBSD が動作しなかった。下記のようなカーネルパニックが発生。

panic: pci_make_tag: bad request

この不具合に相当するんじゃないかと思ってる。

https://bugs.launchpad.net/qemu/+bug/897771

よって下記の組み合わせで動作を確認した。

  • Ubuntu 12.10 + OpenStack (Native Packages)
  • qemu, kvm : 1.2.0+noroms-0ubuntu2.12.10.3
  • NetBSD 6.1 RC2 amd64

前提条件

OpenStack Folsom が動作していること。

NetBSD OS イメージ作成

nova-compute が動作しているホストの qemu-kvm を利用する。OpenStack 上に何でも 良いので OS を動作させこの kvm プロセスのパラメータを参考に kvm コマンドを実行 し NetBSD をインストールさせた。一番確実な方法。

% cd ~/
% wget http://ftp.netbsd.org/pub/NetBSD/iso/6.1_RC2/NetBSD-6.1_RC2-amd64.iso
% kvm-img create -f qcow2 netbsd.img 5G
% /usr/bin/kvm -M pc-1.0 -cpu \
core2duo,+lahf_lm,+rdtscp,+hypervisor,+avx,+osxsave,+save,+aes,+popcnt,+sse4.2,+sse4.1,+cx16,+vmx,+pclmuldq,+ht,+ss,+ds \
-enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-drive file=~/netbsd.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
-net nic,model=virtio -vnc :9 -cdrom ~/NetBSD-6.1_RC2-amd64.iso

VNC :9 に接続して NetBSD を普通ににインストールする。

インストールが終わったら CDROM デバイスを外して起動。

% core2duo,+lahf_lm,+rdtscp,+hypervisor,+avx,+osxsave,+save,+aes,+popcnt,+sse4.2,+sse4.1,+cx16,+vmx,+pclmuldq,+ht,+ss,+ds \
-enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-drive file=~/netbsd.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
-net nic,model=virtio -vnc :9

VNC :9 に接続し下記の操作を行う。

vioif0 という virtio なネットワークインターフェースが起動するので下記のように 追記する。

# vi /etc/rc.conf # 下記を追記
ifconfig_vioif0=dhcp
sshd=YES

OpenStack の metadata server から nova の管理するキーペア鍵を取得し authorized_keys に配置する様、/etc/rc.local に追記する。curl とか便利なツール はもちろん!入っていないので ftp コマンドでなんとかする。

1
2
3
4
5
6
7
8
9
10
11
12
# vi /etc/rc.local # 下記を追記
if [ ! -d /root/.ssh ]; then
    mkdir -p /root/.ssh
fi
echo >> /root/.ssh/authorized_keys
cd /tmp
ftp http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
cat openssh-key | grep 'ssh-rsa' >> /root/.ssh/authorized_keys
echo "AUTHORIZED_KEYS:"
echo "*********************"
cat /root/.ssh/authorized_keys
echo "*********************"

nova のキーペアでログインしたいので sshd は root ユーザでログイン出来るように 修正行う。

# vi /etc/ssh/sshd_config
PermitRootLogin yes

OS をシャットダウンしてイメージ作成は終わり。

Glance へ登録

netbsd.img を Glance に接続できるホストへ移動しイメージ登録を行う。

% glance add name="NetBSD 6.1 RC2 amd64" is_public=true \
  container_format=ovf disk_format=qcow2 < ~/netbsd.img

まとめ

何も手を加えていない…。NetBSD 6.1 は最初から Virtio が有効になっているので何 も考えることなくイメージ作成が出来た。コツは nova-compute が実際に動作している ホストでイメージを作ること。ハイパーバイザの OS が若干古いホストでも作業してみ たのだが、OpenStack に載せた途端カーネルパニックに陥った。Qemu はものすごいス ピードで進化しているのでバージョンの差異は致命的であると共に、日に日に快適な環 境が整ってきているとも言える。