GlusterFSを使用したlive-migrationが失敗する

[ikushin]

いつもお世話になっています。

金です。

これがなければクラウドの意味が無いだろう、ということで、マイグレーションの検証を行なっています。

環境は、Ubuntu12.04 + folsom + GlusterFS(Ubuntu 12.04のパッケージ)です。

↓を参考に、GlusterFSを使用してlive-migrationの実験をしているのですが、上手く行かずに困っています。

http://docs.openstack.org/folsom/openstack-compute/admin/content/configuring-migrations.html

GlusterFS/FUSE上でVMを起動すると、kvmのdiskオプションは、「cache=writethrough」で起動されます。

defultは「cache=none」なのですが、↓のバグに対応したもののようです。

https://bugs.launchpad.net/nova/+bug/959637

ところが、いざlive-migrationを実行してみると、libvirtdに以下のように怒られてしまいます。

「cache=none」以外の場合はエラーになってしまいます。

=====

error : qemuMigrationIsSafe:854 : Unsafe migration: Migration may lead to data corruption if disks use cache != none

=====

仕方がないので、GlusterFSをNFSでマウントしてみたところ、今度はインスタンス自体が起動しなくなりました。

/var/lib/nova/instances/_base ディレクトリは作成されるものの、何故かディスクイメージが何時まで経っても作成されません…

同様の環境で、live-migrationが成功している方はいらっしゃいますでしょうか？

よろしくお願いいたします。

# 余談ですが、GlusterFSを諦めて単にNFSにしてもインスタンスの起動に失敗しました。

# これは、単に設定ミスだと思いますが。

[ikushin]

いつもお世話になっています。

金です。

検証経過を共有させて頂きます。

なんとかマイグレーション（liveでなくとも良い）を実現させるべく、以下の方法を検討

いたしましたが、なかなかスッキリした解決にはいたっていません。

1. GlusterFS/FUSE

2. GlusterFS/NFS

3. GLusterFS + nfs-kernel-server

4. nfs-kernel-server 単体

5. Block live migration

6. Hardware gateway

1. GlusterFS/FUSE

前述のとおり、マイグレーションをしようとするとlibvirtdに怒られます。

これは、FUSE(Filesystem in Userspace)がシステムコールのO_DIRECTフラグをサポートしていないからだそうです。

しかし、Linux3.4からはO_DIRECTをサポートしているそうなので、そのうち解決するのかもしれません。

http://kernelnewbies.org/Linux_3.4

2. GlusterFS/NFS

インスタンス起動時、_base下がいつまで経っても作成されない……

よくわからないので放置

3. GLusterFS + nfs-kernel-server

上手く行くかとおもいきや、マイグレート先で起動失敗。

よくわからないので放置

4. nfs-kernel-server 単体

5. Block live migration

インスタンスのマイグレーションには成功したものの、FloatingIPで通信出来ない。

↓のバグにハマった模様。

https://bugs.launchpad.net/nova/+bug/966529

以上のように、できそうでなかなか出来ないという状況に陥っています。

そこで、HA Options for NetworkingのHardware gatewayに注目してみました。

FloatingIPは廃止して、NATは外部のFW等に丸投げしてしまい、

nova-networkはDHCPとしてのみ使用してはどうかというアイデアです。

間接的に、上記のバグを回避できるように思えるのですが、現在のところ机上の空論です。

もともと、nova-networkでNATしたものをFW等で再度NAT（多重NAT）することに

いささか違和感が有ったので、それも一挙解決出来るのではと期待しています。

突っ込みどころがありましたら、歓迎致します。

以上、長文失礼いたしました。

2012年12月7日金曜日 13時01分55秒 UTC+9 ikushin:

[powered.by.solaris]

金さん

お世話になります。中島です。

live-migrationを使ったことが無いので、あまり有益なアドバイスはできませんが・・・

＞2. GlusterFS/NFS
＞インスタンス起動時、_base下がいつまで経っても作成されない……
＞よくわからないので放置

に関してです。
_base はGlanceからDLされるイメージが、キャッシュされるディレクトリになります。

複数ノードで /var/lib/nova/instances を共有している環境では、
このディレクトリへの書き込みが競合してしまうことがあります。

これを避けるには、nova.conf で base_dir_name を
_base_$nodename 等にしてやってキャッシュディレクトリを分けてやる必要があります。

githubにある最新 nova.conf.sample に設定例が記載されていますので、
参考にしてみてください。

以上。よろしくお願い致します。


2012年12月11日 12:36 ikushin <xuhuan...@gmail.com>:

[ishikawa84g]

金さん、中島さん

石川です。

_base ディレクトリについてです。

このディレクトリへの書き込み競合は

_base に起動したいイメージが存在せず、複数台の

コンピュートノードからリクエストが同時に起こった場合に発生します。

例えば、max_count を 2 以上にした場合がこれに該当します。

(イメージ取得の最終処理.part のリネームでエラーが出るはず)

現段階では中島さんのおっしゃる通り

base_dir_name を変更して _base 以外のディレクトリに

イメージをキャッシュするしか回避方法はない気がします。

ただし、それをすると同じイメージを複数持つためディスクが圧迫されます...

# AppArmor の設定変更も必要になります。

ではでは。

2012年12月13日木曜日 23時48分56秒 UTC+9 irix_jp:

[ishikawa84g]

再び石川です。

書き漏らしてました。。

AppArmor の設定は Ubuntu を使用している場合のみ必要です。

明示的に無効化していない限り有効になっています。

確認方法:

# apparmor_status

または

# aa-status

(おまけ)

RHEL / CentOS / Fedora で SELinux を使用している場合は、

/var/lib/nova 以下に nova_var_lib_t がつくので設定変更は不要です。

ではでは。

2012年12月14日金曜日 11時53分18秒 UTC+9 ishikawa84g:

[powered.by.solaris]

石川さん、金さん

お世話になります。中島です。

＞ただし、それをすると同じイメージを複数持つためディスクが圧迫されます...

こんなオプションもあるみたいです（使ったことはないですが

# remove_unused_base_images=true
#### (BoolOpt) Should unused base images be removed?

# remove_unused_resized_minimum_age_seconds=3600
#### (IntOpt) Unused resized base images younger than this will not be removed

ご参考までにー。

2012年12月14日 12:08 ishikawa84g <ishik...@gmail.com>:

[Hideki Saito]

さいとうです

folsomリリースでは、base_dir_nameが効力を発揮しません。

調べてみましたが、バグですね。

masterでは修正されているようですが、folsomでは2012.2.2でも直っていないので、ぼくは以下のように修正して動かしています。

ここにまとめておきました。

- http://d.hatena.ne.jp/pyde/20121216

ご参考まで。

2012年12月13日 23:48 powered.by.solaris <powered.b...@gmail.com>:

[Hideki Saito]

あ、以下が抜けちゃった。

これが以下です。

--- ここから ---

$ diff -u nova/virt/libvirt/imagebackend.py.org nova/virt/libvirt/imagebackend.py

--- nova/virt/libvirt/imagebackend.py.org 2012-12-16 21:45:04.858022776 +0900

+++ nova/virt/libvirt/imagebackend.py 2012-12-16 21:45:43.028039906 +0900

@@ -117,7 +117,7 @@

                 fetch_func(target=target, *args, **kwargs)

 

         if not os.path.exists(self.path):

-            base_dir = os.path.join(FLAGS.instances_path, '_base')

+            base_dir = os.path.join(FLAGS.instances_path, FLAGS.base_dir_name)

             if not os.path.exists(base_dir):

                 utils.ensure_tree(base_dir)

             base = os.path.join(base_dir, filename)

--- ここまで ---

2012年12月16日 22:32 Hideki Saito <s...@fgrep.org>:

[Akihiro MOTOKI]

バグと master の修正はこれですね。
https://bugs.launchpad.net/nova/+bug/1083447
https://github.com/openstack/nova/commit/cf2eed697732fec81523343d9b82b34096d1bedf

# folsom-backport-potential のタグもついているのに、
# どうして 2012.2.2 で backport されなかったのかなぁ？

[Hideki Saito]

あーそうそう、まさにコレです。
バックポート漏れちゃったんですかね

2012年12月17日 18:02 Akihiro MOTOKI <mot...@da.jp.nec.com>:

[ikushin]

金です。

皆さん、沢山のリプライありがとうございます。

その後、Live migrationについて検証していましたが、旧式のマシンから新型のマシンへmigrationしようとすると、「cpu doesn't have compatibility」と叱られる現象に嵌りました。

https://answers.launchpad.net/nova/+question/208232

この現象の解決策が分からなかったため、結局Live migrationは諦めて、単なるmigrationで満足することにしました。

公式ドキュメントには何故か記載が無いのですが、nova migrateというコマンドが存在していました。

動作としては、仮想マシンを一旦power offして、rsync+sshでコピーし、migration先で起動しているようです。

ドキュメントに記載が無いのがなんとも不気味ですが、さしあたってこれで良しと致します。

話題（？）のbase_dir_nameについては、おいおい試したいですね。

# 次はControllerのHA化だー

2012年12月11日火曜日 12時36分07秒 UTC+9 ikushin:

[Tomoaki nakajima]

金さん

お世話になります。中島です。

あまり有益な情報を提供できず申し訳ないです。

＞旧式のマシンから新型のマシンへmigrationしようとすると、「cpu doesn't have compatibility」と叱られる現象に嵌りました。

これはVMware/vCenterのvMotionでも起こる現象ですね。

同じx86_64系CPUでも、モデルや世代が大きく違う２台のマシン間ではLive Migrationはできないです。

でも解決策が見つかりよかったです ＞ nova migrate

HAについては今週末のハッカソンに詳しい方がいますので、

そこで聞いてみるといろいろ教えてもらえると思います。

以上。よろしくお願い致します。

2012年12月19日水曜日 14時27分06秒 UTC+9 ikushin: