第12章 メンテナンス、故障およびデバッグ

クラウドコントローラーやストレージプロキシのメンテナンスを計画する一つの方法は、単に午前 1 時や 2 時のような利用の少ない時間帯に実行することです。この戦略はあまり多くのユーザーに影響を与えません。クラウドコントローラーやストレージプロキシが、いかなる時間帯においても、サービスが利用できないことによる影響が大きければ、高可用性オプションについて検討する必要があります。

多くの場合、「reboot」コマンドを発行するだけです。オペレーティングシステムが正常にサービスをシャットダウンし、自動的に再起動します。万全を期したい場合、再起動する前にバックアップジョブを実行してください。

クラウドコントローラーを再起動した後、すべての必要なサービスが正常に起動したことを確認します。

# ps aux | grep nova-
# grep AMQP /var/log/nova/nova-*.log
# ps aux | grep glance-
# ps aux | grep keystone
# ps aux | grep cinder

また、すべてのサービスが正しく機能していることを確認します。

# source openrc
# glance index
# nova list
# keystone tenant-list

ストレージプロキシの場合、Object Storage サービスが再開していることを確認します。

# ps aux | grep swift

また、正しく機能していることを確認します。

# swift stat

残念ながら、これはひどい状況です。クラウドコントローラーはクラウドの不可欠な部分です。コントローラーが一つだけならば、多くのサービスが失われます。

この状況を避けるために、高可用なクラウドコントローラークラスターを作成します。このことは、このドキュメントの範囲外ですが、ドラフト版の OpenStack High Availability Guide が http://docs.openstack.org/trunk/openstack-ha/content/ch-intro.html にあります。

次に最も優れている方法は、クラウドコントローラーを自動的に構築するために Puppet のような構成管理ツールを使用することです。利用可能な予備サーバーがあれば、15 分もかかりません。コントローラーを再構築後、取得したすべてのバックアップを復元します (バックアップとリカバリー の章を参照してください)。

実際には、コンピュートノードの nova-compute サービスがときどき、コントローラー上で動作している rabbitmq に正しく再接続されない場合があります。時間のかかるリブートから戻ってきた場合や、コンピュートノードのnova サービスを再起動する必要がある場合です。

(ソフトウェアやハードウェアのアップグレードのように) 計画されたメンテナンスのために、コンピュートノードを再起動する必要があれば、まずホストしている全インスタンスがノード外に移動していることを確認します。クラウドが共有ストレージを利用していれば、nova live-migration コマンドを使用します。初めに、移動させる必要があるインスタンスの一覧を取得します。

# nova list --host c01.example.com --all-tenants

次に、それらを一つずつマイグレーションします。

# nova live-migration <uuid> c02.example.com

共有ストレージを使用していない場合、--block-migrate オプションを使用できます。

# nova live-migration --block-migrate <uuid> c02.example.com

すべてのインスタンスをマイグレーションした後、nova-compute サービスが停止していることを確認します。

# stop nova-compute

Puppet などの構成管理システムを使って、nova-compute サービスが確実に実行されているようにしている場合、init ファイルを一時的に移動します。

# mkdir /root/tmp
# mv /etc/init/nova-compute.conf /root/tmp
# mv /etc/init.d/nova-compute /root/tmp

続けて、コンピュートノードを停止し、メンテナンスを実行し、ノードを元に戻します。先のコマンドを逆に実行することにより、nova-compute サービスを再び有効化できます。

# mv /root/tmp/nova-compute.conf /etc/init
# mv /root/tmp/nova-compute /etc/init.d/

そして nova-compute サービスを起動します。

# start nova-compute

インスタンスを元のコンピュートノードにマイグレーションすることもできます。

コンピュートノードを再起動した場合、まず正常に起動したことを確認します。これには nova-compute サービスが実行していることを確認することが含まれます。

# ps aux | grep nova-compute
# status nova-compute

AMQP サーバーに正常に接続できることも確認します。

# grep AMQP /var/log/nova/nova-compute
2013-02-26 09:51:31 12427 INFO nova.openstack.common.rpc.common [-] Connected to AMQP server on 199.116.232.36:5672

コンピュートノードが正常に実行された後、そのコンピュートノードでホストされているインスタンスはどれも動作していないので、そのコンピュートノードにおいてホストされているインスタンスを処理する必要があります。ユーザーや顧客に対する SLA によっては、各インスタンスを開始し、正常に起動していることを確認する必要がある場合もあるでしょう。

以下のコマンドを実行することにより、コンピュートノードにおいてホストされているインスタンスの一覧を作成できます。

# nova list --host c01.example.com --all-tenants

一覧を取得した後、各インスタンスを起動するために nova コマンドを使用できます。

# nova reboot <uuid>

	注記
	予期せずシャットダウンしたときは、ブートに問題があるかもしれません。たとえば、インスタンスがルートパーティションにおいて fsck を実行する必要があるかもしれません。もしこうなっても、これを修復するためにダッシュボード VNC コンソールを使用できます。

インスタンスがブートしなければ、つまりブートしようとしても virsh list がインスタンスを表示しなければ、コンピュートノードにおいて以下のとおり実行します。

# tail -f /var/log/nova/nova-compute.log

再び nova reboot コマンドを実行してみてください。インスタンスがなぜブートできないかについて、エラーメッセージを確認すべきです。

多くの場合、libvirt の XML ファイル (/etc/libvirt/qemu/instance-xxxxxxxx.xml) の何かがすでに存在しないことで、エラーが発生する。次のとおり実行することにより、インスタンスを再起動するのと同時に、強制的に XML ファイルを再作成できます。

# nova reboot --hard <uuid>

いくつかのシナリオでは、インスタンスが実行中であるにも関わらず、SSH 経由でアクセスできず、あらゆるコマンドに反応がありません。VNC コンソールがブート失敗やカーネルパニックのエラーメッセージを表示している可能性があります。これは仮想マシン自身においてファイルシステム破損の意味する可能性があります。ファイルを復旧したりインスタンスの中身を調査したりする必要があれば、qemu-nbd を使ってディスクをマウントできます。

	注記
	ユーザーのコンテンツやデータにアクセスしたり表示したりする場合は、まず承認をもらってください!

インスタンスのディスク (/var/lib/nova/instances/instance-xxxxxx/disk) にアクセスするには、以下の手順に従う必要があります。

手順 4-6 を省略すると、OpenStack Compute がインスタンスを管理できなくなります。OpenStack Compute により発行されるすべてのコマンドに対する応答が失敗し、シャットダウンしているように見えます。

ディスクファイルをマウントすると、それにアクセスでき、ファイルとディレクトリ構造を持つ通常のディレクトリのように取り扱えます。しかしながら、どのファイルの編集も操作もしないことをお薦めします。なぜなら、それにより ACL が変更されたり、起動できるインスタンスが起動できなくなってします場合があるからです。

影響のあったインスタンスがボリュームを接続していれば、まずインスタンスとボリュームの UUID 一覧を生成します。

mysql> select nova.instances.uuid as instance_uuid, cinder.volumes.id as volume_uuid, cinder.volumes.status, 
cinder.volumes.attach_status, cinder.volumes.mountpoint, cinder.volumes.display_name from cinder.volumes
inner join nova.instances on cinder.volumes.instance_uuid=nova.instances.uuid 
 where nova.instances.host = 'c01.example.com';

以下のような結果を確認できます。

+---------------+-------------+--------+---------------+------------+--------------+ 
| instance_uuid | volume_uuid | status | attach_status | mountpoint | display_name | 
+---------------+-------------+--------+---------------+------------+--------------+ 
| 9b969a05      | 1f0fbf36    | in-use | attached      | /dev/vdc   | test         | 
+---------------+-------------+--------+---------------+------------+--------------+ 
1 row in set (0.00 sec)

次に、ボリュームを手動で切断し、再接続します。

# nova volume-detach <instance_uuid> <volume_uuid>
# nova volume-attach <instance_uuid> <volume_uuid> /dev/vdX

ここで、X には適切なマウントポイントを指定します。上記を実行する前に、インスタンスが正常に起動し、ログイン画面になっていることを確認します。

コンピュートノードが故障し、2〜3時間もしくはそれ以上たっても復旧できないと見込まれる場合、/var/lib/nova/instances に共有ストレージを使用していれば、故障したノードで動作していたインスタンスをすべて再スタートすることができます。

これを実行するために、nova データベースにおいて以下のクエリーを実行することにより、故障したノードにおいてホストされているインスタンスの UUID の一覧を生成します。

mysql> select uuid from instances where host = 'c01.example.com' and deleted = 0;

次に、c01.example.com においてホストされていたすべてのインスタンスが、今度は c02.example.com でホストされることを Nova に教えます。

mysql> update instances set host = 'c02.example.com' where host = 'c01.example.com' and deleted = 0;

その後、nova コマンドを使って、c01.example.com にあったすべてのインスタンスを再起動します。起動する際にインスタンスの XML ファイルを再生成します。

# nova reboot --hard <uuid>

最後に、ボリュームの節で説明されているのと同じ方法を用いて、ボリュームを再接続します。

コンピュートノードの故障の話題に関連して、このディレクトリについては説明しておく価値があるでしょう。このディレクトリには、コンピュートノードにホストされているインスタンス用の libvirt KVM のファイル形式のディスクイメージが置かれます。共有ストレージ環境でクラウドを実行していなければ、このディレクトリはコンピュートノード全体で一つしかありません。

/var/lib/nova/instances には 2 種類のディレクトリがあります。

一つ目は _base ディレクトリです。ここには、そのコンピュートノードで起動されたそれぞれのイメージに関して、glance から取得したすべてのベースイメージのキャッシュが置かれます。_20 (または他の番号) で終わるファイルは一時ディスクのベースイメージです。

もう一つのディレクトリは instance-xxxxxxxx という名前です。これらのディレクトリはコンピュートノードにおいて実行中のインスタンスと対応します。中にあるファイルは _base ディレクトリにあるファイルのどれかと関連があります。これらは基本的に、元々の _base ディレクトリからの変更点のみ含む、差分ベースのファイルです。

/var/lib/nova/instances にあるすべてのファイルとディレクトリは一意に名前が付けられています。_base にあるファイルは元となった glance イメージに対応する一意に名前が付けられています。また、instance-xxxxxxxx という名前が付けられたディレクトリは特定のインスタンスに対して一意にタイトルが付けられています。たとえば、あるコンピュートノードにある /var/lib/nova/instances のすべてのデータを他のノードにコピーしたとしても、ファイルを上書きすることはありませんし、また同じ一意な名前を持つイメージにダメージを与えることもありません。同じ一意な名前を持つものは本質的に同じファイルだからです。

この方法はドキュメントに書かれておらず、サポートされていない方法ですが、コンピュートノードが完全にオフラインになってしまったが、インスタンスがローカルに保存されているときに、この方法を使用できます。

ストレージノードの再起動が必要ならば、単に再起動します。そのノードにホストされているデータに対する要求は、サーバーが再起動している間、他のコピーに転送されます。

ストレージノードを少し長い間 (1 日以上) シャットダウンする必要があれば、ノードをストレージリングから削除することを検討します。例:

# swift-ring-builder account.builder remove <ip address of storage node>
# swift-ring-builder container.builder remove <ip address of storage node>
# swift-ring-builder object.builder remove <ip address of storage node>
# swift-ring-builder account.builder rebalance
# swift-ring-builder container.builder rebalance
# swift-ring-builder object.builder rebalance   

次に、ring ファイルを他のノードに再配布します。

# for i in s01.example.com s02.example.com s03.example.com
> do
> scp *.ring.gz $i:/etc/swift
> done    

これらの操作はストレージノードをストレージクラスターから効率的に外せます。

ノードがクラスターに参加できるようになったら、ただリングに再度追加するだけです。swift-ring-builder を使用して Swift クラスターにノードを追加するための構文は、元々クラスターを作成したときに使用した元々のオプションに強く依存します。作成時に使用したコマンドをもう一度見てください。

Object Storage ノードのハードディスクが故障した場合、その交換は比較的簡単です。Object Storage 環境が正しく設定され、故障したディスクに保存されているデータが Object Storage 環境内の他のディスクにも複製されていることを前提にしています。

この例では、/dev/sdb が故障したと仮定します。

まず、ディスクをアンマウントします。

# umount /dev/sdb

次に、ディスクを物理的にサーバーから取り外し、正常なディスクと入れ替えます。

オペレーティングシステムが新しいディスクを認識していることを確認します。

# dmesg | tail

/dev/sdb に関するメッセージを確認したほうがいいです。

Swift ディスクではパーティションを使用しないことが推奨されるので、単にディスク全体をフォーマットします。

# mkfs.xfs /dev/sdb

最後に、ディスクをマウントします。

# mount -a

Swift は新しいディスクを認識します。また、データが存在しないことを認識します。そうすると、他の既存の複製からディスクにデータを複製しはじめます。

コンピューティングリソースのキャパシティ限界に達した、または達しそうとわかれば、さらなるコンピュートノードの追加を計画すべきです。さらなるノードを追加することは簡単です。ノードを追加する手順は、最初にコンピュートノードをクラウドに導入したときと同じです。自動配備システムを使ってベアメタルサーバーにオペレーティングシステムのインストールと起動を行い、次に構成管理システムによりOpenStack Compute サービスのインストールと設定を行います。他のコンピュートノードと同じ方法で Compute サービスのインストールと設定が終わると、自動的にクラウドに接続されます。クラウドコントローラーが新しいノードを検知し、そこにインスタンスを起動するようスケジュールし始めます。

OpenStack ブロックストレージノードがコンピュートノードから分離いる場合、同じキュー管理とポーリングのシステムが両方のサービスで使用されるので、同じ手順が適用できます。

新しいコンピュートノードとブロックストレージノードには、同じハードウェアを使用することを推奨します。最低限、ライブマイグレーションが失敗しないように、コンピュートノードでは CPU は同様のものにしてください。

新しいオブジェクトストレージノードの追加は、コンピュートノードやブロックストレージノードの追加とは異なります。サーバーの設定は、これまで通り自動配備システムと構成管理システムを使って行えます。完了した後、オブジェクトストレージノードのローカルディスクをオブジェクトストレージリングに追加する必要があります。これを実行するコマンドは、最初にディスクをリングに追加するのに使用したコマンドと全く同じです。オブジェクトストレージプロキシサーバーにおいて、このコマンドを、新しいオブジェクトストレージノードにあるすべてのディスクに対して、再実行するだけです。これが終わったら、リングの再バランスを行い、更新されたリングファイルを他のストレージノードにコピーします。

	注記
	新しいオブジェクトストレージノードのディスク数が元々のノードのディスク数と異なる場合には、新しいノードを追加するコマンドが元々のコマンドと異なります。これらのパラメーターは環境により異なります。

クラウドインフラなどの大規模環境では、ハードウェアの故障はよくあることです。作業内容を考慮し、可用性と時間の節約のバランスを取ります。たとえば、オブジェクトストレージクラスターは、十分な容量がある場合には、ある程度の期間は死んだディスクがあっても問題なく動作します。また、(クラウド内の) コンピュートノードに空きがある場合には、問題に対処する時間が取れるまで、ライブマイグレーションで RAM が故障したホストから他のホストへインスタンスを移動させることも考慮するとよいでしょう。

コンポーネントの設定ファイルを確認して、それぞれの OpenStack コンポーネントが対応するデータベースにどのようにアクセスするかを把握ください。sql_connection またはただの connection を探します。

# grep -hE "connection ?=" /etc/nova/nova.conf /etc/glance/glance-*.conf 
/etc/cinder/cinder.conf /etc/keystone/keystone.conf
	sql_connection = mysql://nova:nova@cloud.alberta.sandbox.cybera.ca/nova
	sql_connection = mysql://glance:password@cloud.example.com/glance 
	sql_connection = mysql://glance:password@cloud.example.com/glance 
    sql_connection=mysql://cinder:password@cloud.example.com/cinder 
	connection = mysql://keystone_admin:password@cloud.example.com/keystone

connection 文字列は以下の形式をとります。

mysql:// <username> : <password> @ <hostname> / <database name>

クラウドが大きくなるにつれて、MySQL がさらに使用されてきます。MySQL がボトルネックになってきたことが疑われる場合、MySQL 最適化の調査から始めるとよいでしょう。MySQL のマニュアルでは、Optimization Overview (http://dev.mysql.com/doc/refman/5.5/en/optimize-overview.html) というセクションがあり、一つのセクション全部をあててこの話題を扱っています。

最初に確認する場所は、実行しようとしているコマンドに関連するログファイルです。たとえば、nova list が失敗していれば、Nova ログファイルを tail 表示しながら、次のコマンドを再実行してください。

端末 1:

# tail -f /var/log/nova/nova-api.log

端末 2:

# nova list

何らかのエラーまたはトレースをログファイルで探します。詳細は ロギングとモニタリング の章を参照してください。

エラーから問題が他のコンポーネントにあることが分かる場合には、そのコンポーネントのログファイルに表示を切り替えます。nova が glance にアクセスできなければ、glance-api ログを確認します。

端末 1:

# tail -f /var/log/glance/api.log

端末 2:

# nova list

問題の根本となる原因を見つけるまで、洗い出し、精査し、繰り返します。

残念ながら、ときどきエラーがログファイルに表れない場合があります。このような場合、作戦を変更し、違うコマンドを使用します。おそらくコマンドラインにおいて直接サービスを実行することです。たとえば、glance-api サービスが起動しなかったり、実行状態にとどまらない場合は、コマンドラインからデーモンを起動してみます。

# sudo -u glance -H glance-api

これにより、エラーと問題の原因が表示されるかもしれません。

	注記
	sudo を用いてデーモンを実行するとき、-H フラグが必要です。いくつかのデーモンは、ユーザーのホームディレクトリーからの相対パスのファイルに書き込みを行うため、-H がないと、この書き込みが失敗してしまいます。

ある朝、あるノードでインスタンスの実行がすべて失敗するようになりました。ログファイルがすこしあいまいでした。特定のインスタンスが起動できなかったことを示していました。これは最終的に偽の手掛かりであることがわかりました。単にそのインスタンスがアルファベット順で最初のインスタンスだったので、nova-compute が最初に操作したのがそのインスタンスだったというだけでした。

さらなるトラブルシューティングにより、libvirt がまったく動作していないことがわかりました。これは大きな手がかりです。libvirt が動作していないと、KVM によるインスタンスの仮想化ができません。libvirt を開始させようとしても、libvirt は何も表示せずすぐに停止しました。libvirt のログでは理由がわかりませんでした。

次に、libvirtd デーモンをコマンドラインにおいて実行しました。最終的に次のような役に立つエラーメッセージが得られました。d-bus に接続できませんでした。このため、滑稽に聞こえるかもしれませんが、libvirt 、その結果として nova-compute も D-Bus に依存していて、どういう訳か D-Bus がクラッシュしました。単に D-Bus を開始するだけで、一連のプログラムがうまく動くようになり、すぐに全部が元に戻り動作状態になりました。