3.6. トラブルシューティング
バックアップサービスで発生する問題の多くは、以下の 2 つの一般的なシナリオで説明します。
-
cinder-backupサービスが起動すると、設定したバックエンドに接続し、これをバックアップのターゲットとして使用します。この接続の問題により、サービスが失敗する場合があります。 - バックアップが要求されると、バックアップサービスはボリュームサービスに接続し、要求されたボリュームを割り当てます。この接続の問題は、バックアップ時にのみ明らかになります。
いずれの場合も、ログにはエラーを説明するメッセージが含まれます。
ログファイルとサービスの詳細については、Logging, Monitoring and Troubleshooting Guideの Log Files for OpenStack Services を参照してください。
ログの位置に関する一般的な情報やトラブルシューティングの提案については、ロギング・モニタリング・トラブルシューティングガイドの ブロックストレージ (cinder) のログファイル を参照してください。
3.6.1. サービスの確認 リンクのコピーリンクがクリップボードにコピーされました!
多くの問題を診断するには、サービスが利用可能であることを確認し、ログファイルでエラーメッセージを確認します。キーサービスおよびその相互作用の詳細は、「バックアップおよび復元の仕組み」 を参照してください。
サービスの状態を確認したら、cinder-backup.log を確認します。Block Storage Backup サービスログは、/var/log/containers/cinder]/cinder-backup.log にあります。
手順
ボリュームで
cinder showコマンドを実行して、ホストに保存されているかどうかを確認します。cinder show
# cinder showCopy to Clipboard Copied! Toggle word wrap Toggle overflow cinder service-listを実行して、実行中のサービスを表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 期待されるサービスが利用可能であることを確認します。
3.6.2. トラブルシューティングのヒント リンクのコピーリンクがクリップボードにコピーされました!
バックアップは非同期です。ブロックストレージバックアップサービスは、API リクエストを受信すると、不正なボリュームリファレンス (missing) や、インスタンスに in-use またはアタッチされているボリュームの確認など、少数の静的チェックを実行します。in-use の場合は、--force を使用する必要があります。
--force を使用すると、I/O が静止せず、ボリュームイメージが破損する可能性があります。
API が要求を受け入れると、バックアップがバックグラウンドで発生します。通常、バックアップに失敗したり、障害が近づいていても、CLI はすぐに戻ります。cinder バックアップ API を使用して、バックアップのステータスをクエリーできます。エラーが発生した場合は、ログを確認して原因を特定します。
3.6.3. Pacemaker リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Pacemaker は Block Storage バックアップサービスをデプロイします。Pacemaker は、定義された OpenStack クラスターリソースセットが実行中で、利用可能になるように、仮想 IP アドレス、コンテナー、サービス、およびその他の機能をクラスターのリソースとして設定します。クラスター内のサービスノードまたは全ノードが停止した場合には、Pacemaker はリソースの再起動、クラスターからのノードの削除、ノードの再起動を実行することができます。大半のサービスへの要求は HAProxy を経由します。
トラブルシューティングに Pacemaker を使用する方法については、High Availability Deployment and Usageの Managing high availability services with Pacemaker を参照してください。