7.2. Ceph
CephFS でのストレッチクラスターのパフォーマンスが低下する
マルチサイトの Data Foundation クラスターにメタデータサーバー (MDS) を任意に配置するため、小さなメタデータ操作が多数あるワークロードでは、パフォーマンスが低下する可能性があります。
非常に多くのファイルによる SELinux の再ラベル付けの問題
Red Hat OpenShift Container Platform でボリュームを Pod にアタッチすると、Pod が起動しないか、起動に過度に時間がかかることがあります。この動作は一般的なもので、Kubelet による SELinux の再ラベル付けの処理方法に関係しています。この問題は、ファイル数が非常に多いファイルシステムベースのボリュームで発生します。OpenShift Data Foundation では、非常に多くのファイルがある CephFS ベースのボリュームを使用すると、この問題が発生します。この問題の回避にはさまざまな方法があります。ビジネスニーズに応じて、ナレッジベースソリューション https://access.redhat.com/solutions/6221251 から回避策の 1 つを選択できます。
クラッシュまたはシャットダウンテストの実行後、Ceph にアクセスできなくなります
ストレッチクラスターでは、モニターが復活し、他のモニターが
MonitorMap
やOSDMap
などの最新情報を受信するためのプローブ段階にある場合に、プローブ段階ではstretch_mode
に入ることができません。これにより、elector のdisallowed_leaders
リストを正しく設定できなくなります。復活したモニターのスコアが実際に一番高いと仮定すると、現在の選出でリーダーに最適であると認識し、自身がリーダーに適していると提案し、生存しているモニターにより
disallowed_leaders
リストをもとに拒否され続けるため、モニターの選出フェーズを停止させる原因になります。これにより、モニターが選択中に停止し、最終的に Ceph が応答しなくなります。この問題を回避するには、選択中にスタックして Ceph が応答しなくなったときに、次のコマンドを使用して各モニターの接続スコアをリセットします。
`ceph daemon mon.{name} connection scores reset`
これが機能しない場合は、モニターを 1 つずつ再起動します。その後、選出の停滞が解消され、モニターがリーダーを選出して定足数を形成できるようになり、Ceph は再び応答できるようになります。
Ceph がワークロードのデプロイ後に
アクティブなマネージャーを報告しません
ワークロードのデプロイメント後に、Ceph マネージャーは MON への接続を失うか、liveness プローブに応答できなくなります。
これが原因で、ODF クラスターのステータスがアクティブなマネージャーが存在しないと報告し、また、Ceph マネージャーを使用してリクエスト処理を行う複数の操作が失敗します。たとえば、ボリュームのプロビジョニング、CephFS スナップショットの作成などです。
ODF クラスターのステータスを確認するには、コマンド
oc get cephcluster -n openshift-storage
を使用します。クラスターにこの問題がある場合、ステータス出力のstatus.ceph.details.MGR_DOWN
フィールドに "no active mgr" というメッセージが表示されます。この問題を回避するには、以下のコマンドを使用して Ceph Manager Pod を再起動します。
# oc scale deployment -n openshift-storage rook-ceph-mgr-a --replicas=0
# oc scale deployment -n openshift-storage rook-ceph-mgr-a --replicas=1
これらのコマンドを実行すると、ODF クラスターのステータスは正常なクラスターを報告し、
MGR_DOWN
に関する警告やエラーは表示されません。
StorageCluster でカスタム deviceClass が使用されている場合に CephBlockPool の作成が失敗します
既知の問題により、StorageCluster でカスタム deviceClass が使用されると、CephBlockPool の作成に失敗します。