[ English | Indonesia | Deutsch | 日本語 ]

RabbitMQ トラブルシューティング

このセクションは一般的な RabbitMQ の問題を解決するヒントを提供します。

RabbitMQ サービス停止

RabbitMQサービスを再起動するか止めた際にハングすることはすっかり一般的になっています。このため、各コントロールノード上のRabbitMQを手動で再起動することを強くお勧めします。

注釈

RabbitMQサービス名はあなたのオペレーションシステムかRabbitMQサービスを提供しているベンダに強く依存しているかもしれません。

  1. 最初のコントローラノード上でRabbitMQサービスを再起動します。 service rabbitmq-server restart 再起動コマンドはある状況下ではうまく動作しないかもしれません、ですので次のコマンドを使うと良いでしょう。

    # service rabbitmq-server stop
# service rabbitmq-server start

  2. もしサービスが停止できない場合は、 pkill コマンドでサービスを停止しましょう。その後サービスを再起動します。

    # pkill -KILL -u rabbitmq
# service rabbitmq-server start

  3. RabbitMQ プロセスが動作していることを確認します。

    # ps -ef | grep rabbitmq
# rabbitmqctl list_queues
# rabbitmqctl list_queues 2>&1 | grep -i error

  4. エラーがある場合、cluster_status コマンドを実行して、パーティションがないことを確認します。

    # rabbitmqctl cluster_status

    詳細は RabbitMQ のドキュメント を参照してください。

  5. 初めのステップに戻り、RabbitMQサービスをまた再起動しましょう。もしまだエラーが出る場合は、RabbitMQサービスの停止と起動の間に /var/lib/rabbitmq/mnesia/ ディレクトリ内のコンテンツを直接削除しましょう。

  6. エラーがなければ、次のコントローラーノードで RabbitMQ サービスを再起動します。

Libertyリリース以降、OpenStackサービスは自動でRabbitMQの停止から復旧するようになりました。RabbitMQハートビート機能がオンになっているかどうか、またOpenStackサービスがRabbtMQのキューからメッセージを取得していないこと、を確認した後にのみOpenStackサービスの再起動を考慮すればいいでしょう。

RabbitMQ アラート

RabbitMQ のアラートを受けとった場合、以下の手順を実行して、問題を調査および解決します。

  1. RabbitMQ のアラームが発生しているサーバーを特定します。

  2. 影響のある環境において、nova インスタンスを起動できるか試します。

  3. インスタンスを起動できない場合、問題のトラブルシューティングを続けます。

  4. 影響のある環境の各コントローラーノードにログインして、報告された問題に対して /var/log/rabbitmq ログファイルを確認します。

  5. ログファイルにおいて、識別された接続の問題を探します。

  6. For each controller node in your environment, view the /etc/init.d directory to check it contains nova*, cinder*, neutron*, or glance*. Also check RabbitMQ message queues that are growing without being consumed which will indicate which OpenStack service is affected. Restart the affected OpenStack service.

  7. For each compute node your environment, view the /etc/init.d directory and check if it contains nova*, cinder*, neutron*, or glance*, Also check RabbitMQ message queues that are growing without being consumed which will indicate which OpenStack services are affected. Restart the affected OpenStack services.

  8. OpenStack Dashboard を開き、インスタンスを起動します。インスタンスが起動すると、問題が解決されています。

  9. インスタンスを起動できない場合、報告された接続の問題に対して /var/log/rabbitmq ログファイルを確認します。

  10. すべてのコントローラーにおいて RabbitMQ サービスを再起動します。

    # service rabbitmq-server stop
# service rabbitmq-server start

    注釈

    すでに OpenStack コンポーネントのみを再起動して、RabbitMQ サービスに接続できない場合、この手順が適用されます。

  11. 手順 7-8 を繰り返します。

Excessive database management memory consumption

Since the Liberty release, OpenStack with RabbitMQ 3.4.x or 3.6.x has an issue with the management database consuming the memory allocated to RabbitMQ. This is caused by statistics collection and processing. When a single node with RabbitMQ reaches its memory threshold, all exchange and queue processing is halted until the memory alarm recovers.

この問題の解決手順:

  1. メモリー消費を確認します。

    # rabbitmqctl status

  2. Edit the /etc/rabbitmq/rabbitmq.config configuration file, and change the collect_statistics_interval parameter between 30000-60000 milliseconds. Alternatively you can turn off statistics collection by setting collect_statistics parameter to "none".

File descriptor limits when scaling a cloud environment

A cloud environment that is scaled to a certain size will require the file descriptor limits to be adjusted.

rabbitmqctl status を実行して、現在のファイル記述子の制限を表示します。

"{file_descriptors,
     [{total_limit,3996},
      {total_used,135},
      {sockets_limit,3594},
      {sockets_used,133}]},"

/etc/security/limits.conf 設定ファイルにおいて、適切な制限を調整します。