[ English | Indonesia | Deutsch | 日本語 ]

クラウドコントローラーとストレージプロキシの故障とメンテナンス

想定内の場合も想定外の場合も停止時間が発生した場合の挙動が、クラウドコントローラーとストレージプロキシは互いに似ています。クラウドコントローラーとストレージプロキシはそれぞれクラウドで一つ実行されるので、動作していない場合、非常に目立ちます。

クラウドコントローラーの場合、良いニュースとしては、クラウドが FlatDHCP マルチホスト HA ネットワークモードを使用していれば、既存のインスタンスとボリュームはクラウドコントローラーがオフラインの間も動作を継続するという点があります。しかしながら、ストレージプロキシの場合には、サーバーが元に戻され動作状態になるまで、ストレージとの通信ができません。

計画メンテナンス

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

クラウドコントローラーとストレージプロキシの再起動

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

クラウドコントローラーの再起動後、すべての必要なサービスが正常に起動されたことを確認します。以下のコマンドは、 ps と grep を使用して、nova、glance、keystone が現在動作していることを確認しています。

# ps aux | grep nova-
# ps aux | grep glance-
# ps aux | grep keystone
# ps aux | grep cinder

また、すべてのサービスが正しく機能していることを確認します。以下のコマンド群は、 openrc ファイルを読み込みます。そして、いくつかの基本的な glance、nova、openstack コマンドを実行します。コマンドが期待したとおりに動作すれば、それらのサービスが動作状態にあると確認できます。

# . openrc
# openstack image list
# openstack server list
# openstack project list

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

# ps aux | grep swift

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

# swift stat

全体的なクラウドコントローラーの故障

クラウドコントローラーは、例えばマザーボードがおかしくなった場合に、完全に故障するでしょう。これはクラウド環境の中核的な機能を提供しているため、ユーザーはクラウドコントローラーの損失にすぐに気づくでしょう。お使いのインフラ監視機能が、クラウド環境の障害のアラートを上げなかった場合でも、ユーザーは絶対に気づきます。残念ながら、これは大まかな状況です。クラウドコントローラーは、クラウドの必須部分です。コントローラーが 1 つだけの場合、ダウンした際に多くのサービスが失われるでしょう。

この状況を避けるために、高可用なクラウドコントローラークラスターを作成します。このことは、このドキュメントの範囲外ですが、 OpenStack High Availability Guide に情報があります。

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

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