はじめに
デフォルト状態のNovaでは、マイグレーションは1台ずつしか実行されない。
例えば、host-evacutionで特定コンピュートノードから全てのインスタンスをマイグレーションさせようとしても、一台ずつ実行なので非常に長い時間がかかってしまう。それこそ、NWやStorageの能力的にまだまだ余力があるのだとしたら、これはとても非効率。
というわけで、Novaの設定変更で何とかする。
環境
QueensベースのRedHat OpenStack Platform v13で動作確認。
設定変更
/etc/nova/nova.confのmax_concurrent_live_migrationsを変更する。デフォルトは1に設定されている。そのせいでマイグレーションは1台ずつ実行される。
- max_concurrent_live_migrations=1
+ max_concurrent_live_migrations=3
そしてnovaのプロセスを再起動させればOK
この場合、3並列でマイグレーションがされることになる。ハードウェアの能力にもよるだろうが、50台のインスタンスを10分程度でマイグレーションできたりするので、非常に高速化される。
RHOSP v13の場合はコンピュートノードの/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.confを変更してnova_computeコンテナを再起動させればOK
当然、オーバークラウドの再デプロイやアップデートをかけると設定が元に戻ってしまうので、環境ファイル側でもオーバーライドするように構成する必要がある。
使用帯域幅の調整
マイグレーション中にNICのトラフィックを見て頂ければよく分かるが、マイグレーションはかなりNW帯域を消費する。これもインスタンスの稼働状態などにもよるので、一概には言えないが、3並列で実行して4~8Gbps程度はコンスタントに使っている。下手すると、10Gbpsに張り付いたりする。
当然ながら、マイグレーションのトラフィックでNWが使い潰されてしまっては、他のトラフィックに影響が出てしまう可能性がある。そんな場合には、nova.confには、live_migration_bandwidthという設定もあって、この値を調整すると良い。
デフォルトは、0に設定されており、この場合は自動調整されるらしい。が、10GbpsのNW構成だから他トラフィックに影響でないように8Gbps抑えて欲しいな♪なんて人間の希望をエスパーしてくれるような機能ではない。個人的には、この値も調整した方が良いと考えている。
live_migration_bandwidthはMiB(メビバイト)で記述する必要がある。メガビットでもメガバイトでもない。"メビバイト 変換"とググるとGoogle大先生の計算ツールが表示されるので、それを使うのが便利。
- live_migration_bandwidth=0
+ live_migration_bandwidth=1073
10Gbps構成ならば、他トラフィック用に1Gbpsぐらい空けておけば良いのではないだろうか。もちろんこれはそれぞれの環境に合わせて調整して欲しい。
あとがき
今までずっとデフォルト状態で運用していて、マイグレーションの待ち時間が長くて苦労していた。今回、記事にした2点を調整しただけで劇的に高速化されたので、非常に満足している。