ストレージに関する問題のトラブルシューティング

このガイドを参考にして、CubeCOSのストレージに関する一般的な問題を診断してください。 まだお読みでない場合は、まず トラブルシューティングの概要 を確認し、クラスタ全体の問題ではないことを確認してください。

始める前に

一部のチェックでは、admin ユーザーとしてクラスタノードに SSH 経由でアクセスする必要があります。 接続が完了したら、storage コマンドを使用して、Ceph クラスタおよび OSD の正常性を確認してください。

Connect to a cluster node

ssh admin@<cluster-vip>

Ceph クラスタから HEALTH_WARN が報告されています

1. クラスタ全体のステータスを確認してください。

   Check storage cluster status

   cc1> storage status

2. health の行と、その下に表示される N osds down や Degraded data redundancy などのメッセージを確認してください。 OSDテーブルのSTATE列には、どのOSDが影響を受けているかが表示されます。正常なOSDにはexists,upと表示され、障害が発生しているOSDにはupを含まないexistsと表示されます。

3. 特定のOSDがダウンしている場合は、以下の「OSDがダウンしている場合」(#an-osd-is-down) を参照してください。

4. OSDのダウンは確認されないにもかかわらず、クラスタが依然として配置グループの性能低下を報告している場合、クラスタは直近の変更からの回復過程にある可能性があります。 数分後に storage status を再度実行し、HEALTH_OK に戻っていることを確認してください。

OSDがダウンしています

1. すべてのOSDを一覧表示し、down状態のもの、またはup状態がないものを探します。

   List all OSDs

   cc1> storage list_osd

2. 正常に動作していないOSDのディスク状態を確認してください。

   Get details for a specific OSD

   cc1> storage list_osd <osd-id>

   詳細については、「OSDの状態を確認する」(../storage/check_osd.md ) を参照してください。

3. 対象のディスクに障害が発生した場合は、そのOSDを取り外し、クラスタがそのディスクを除外した状態でリバランスを行えるようにしてください。

   Remove a failed OSD

   cc1> storage remove_osd

   手順の詳細については、「ストレージプールからOSDを削除する」[(../storage/remove_osd.md ) ]を参照してください。

4. ディスクを物理的に交換する必要がある場合は、まずクラスタからそのディスクを取り外してください。

   Remove a failed disk

   cc1> storage remove_disk

   :::危険

   「強制モード」ではデータ移行が省略されるため、データ破損のリスクが高くなります。 リスクを理解しており、かつディスクを直ちに削除する必要がある場合を除き、セーフモードを使用してください。 「ハードディスクの取り外し」こちらを参照してください。

   :::

ボリュームが「作成中」ステータスで停止しています

1. ボリュームの状態を直接確認してください。

   Check volume status

   openstack volume show <volume-id> -c status

2. Cephクラスタのステータスを確認してください。 基盤となるストレージプールがデグレード状態にある場合やリバランス中である場合、ボリュームは「作成中」の状態のままになることがあります。

   Check storage cluster status

   cc1> storage status

ボリュームがインスタンスにアタッチまたはデタッチできない

1. ボリュームの状態と現在の接続状況を確認してください。

   Check volume attachments

   openstack volume show <volume-id> -c status -c attachments

2. 対象インスタンスのステータスが Active であることを確認してください。 構築中、サイズ変更中、またはエラー状態にあるインスタンスでは、ボリュームの接続や切断を行うことはできません。

3. 「Compute > Instances > More > Related Resources > Attach Volume」 から、操作を再実行してください。 手順の詳細については、「ボリュームの作成とアタッチ」(../storage/block/volume.md )を参照してください。

ボリュームを拡張しても、ゲストOS内では新しいサイズが反映されません

CubeCOS でボリュームを拡張すると、基盤となるブロックデバイスは拡大されますが、新しい領域を使用するには、ゲスト OS 側でも独自のパーティションとファイルシステムを拡張する必要があります。 「パーティションの拡張」を参照してください（../operating_system/extend_partition.md）。

ディスクの再バランス調整や削除に時間がかかる、あるいは失敗する

• セーフモードでの削除では、ディスクを削除する前に既存のデータを別の場所へ移行するため、データ量が多いディスクほど処理に時間がかかります。 再試行するよりも、そのまま終了させるべきだ。
• クラスタにデータを移行するのに十分な残存容量やフォールトドメインがないために、セーフモードでの削除に失敗した場合は、まず容量を追加するか、フォースモードのリスクを受け入れる必要があります。 「ハードディスクの取り外し」こちらを参照してください。
• storage rebalance コマンドでレプリケーション係数を変更し、クラスタの回復処理が長期間続いている場合は、回復が停滞していると判断する前に、storage status で現在の回復率を確認してください。

オブジェクトストレージまたはS3の操作が失敗する

1. そのプロジェクトで有効な EC2/S3 の認証情報を使用していること、およびコンテナのアクセスポリシーで実行しようとしている操作が許可されていることを確認してください。
2. コンテナが存在し、「プロジェクト」＞「ストレージ」＞「オブジェクトストレージ」 に表示されていることを確認してください。

設定および使用方法の詳細については、オブジェクトストレージ（Swift API） および オブジェクトストレージ（S3 API） を参照してください。

ファイル共有がマウントされない

1. 共有ステータスが Active であることを確認してください。
2. 共有ネットワークおよびアクセスルールで、クライアントのIPアドレスまたはネットワークが許可されていることを確認してください。

設定の詳細については、テナント共有を参照してください。