3.2. Ceph Storage クラスターのハイレベル監視
ストレージ管理者は、Ceph デーモンの正常性を監視し、それらが稼働していることを確認します。また、高レベルのモニタリングには、ストレージクラスター容量を確認して、ストレージクラスターが 完全な比率
を超えないようにします。Red Hat Ceph Storage ダッシュボード は、高レベルのモニタリングを実行する最も一般的な方法です。ただし、コマンドラインインターフェイス、Ceph 管理ソケットまたは Ceph API を使用してストレージクラスターを監視することもできます。
3.2.1. 前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
3.2.2. Ceph コマンドラインインターフェイスの対話形式の使用
ceph
コマンドラインユーティリティーを使用して、Ceph ストレージクラスターと対話的にインターフェイスで接続することができます。
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- ノードへのルートレベルのアクセス。
手順
インタラクティブモードで
ceph
ユーティリティーを実行するには、以下を行います。ベアメタル デプロイメント:
例
[root@mon ~]# ceph ceph> health ceph> status ceph> quorum_status ceph> mon_status
コンテナー デプロイメント:
Red Hat Enterprise Linux 7
docker exec -it ceph-mon-MONITOR_NAME /bin/bash
Red Hat Enterprise Linux 8
podman exec -it ceph-mon-MONITOR_NAME /bin/bash
- 置き換え
MONITOR_NAME は、Ceph Monitor コンテナーの名前に置き換えます。
docker ps
コマンドまたはpodman ps
コマンドを実行します。例
[root@container-host ~]# podman exec -it ceph-mon-mon01 /bin/bash
この例では、
mon01
で対話的なターミナルセッションを開き、Ceph インタラクティブシェルを起動することができます。
3.2.3. ストレージクラスターの正常性の確認
Ceph Storage クラスターを起動してからデータの読み取りまたは書き込みを開始する前に、ストレージクラスターの正常性を確認します。
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- ノードへのルートレベルのアクセス。
手順
Ceph Storage クラスターの正常性を確認するには、以下を使用します。
[root@mon ~]# ceph health
設定またはキーリングにデフォルト以外の場所を指定した場合は、その場所を指定できます。
[root@mon ~]# ceph -c /path/to/conf -k /path/to/keyring health
Ceph クラスターの起動時に、HEALTH_WARN XXX num placement groups stale
などの正常性警告が生じる可能性があります。しばらく待ってから再度確認します。ストレージクラスターの準備が整ったら、ceph health
は HEALTH_OK
などのメッセージを返すはずです。この時点で、クラスターの使用を開始するのは問題ありません。
3.2.4. ストレージクラスターイベントの監視
コマンドラインインターフェイスを使用して、Ceph Storage クラスターで発生しているイベントを監視することができます。
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- ノードへのルートレベルのアクセス。
手順
コマンドラインでクラスターの進行中のイベントを確認するには、新しい端末を開き、以下を入力します。
[root@mon ~]# ceph -w
Ceph は各イベントを出力します。たとえば、1 台のモニターで設定され、2 つの OSD で設定される小さな Ceph クラスターが以下のように出力されます。
cluster b370a29d-9287-4ca3-ab57-3d824f65e339 health HEALTH_OK monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1 osdmap e63: 2 osds: 2 up, 2 in pgmap v41338: 952 pgs, 20 pools, 17130 MB data, 2199 objects 115 GB used, 167 GB / 297 GB avail 952 active+clean 2014-06-02 15:45:21.655871 osd.0 [INF] 17.71 deep-scrub ok 2014-06-02 15:45:47.880608 osd.1 [INF] 1.0 scrub ok 2014-06-02 15:45:48.865375 osd.1 [INF] 1.3 scrub ok 2014-06-02 15:45:50.866479 osd.1 [INF] 1.4 scrub ok 2014-06-02 15:45:01.345821 mon.0 [INF] pgmap v41339: 952 pgs: 952 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail 2014-06-02 15:45:05.718640 mon.0 [INF] pgmap v41340: 952 pgs: 1 active+clean+scrubbing+deep, 951 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail 2014-06-02 15:45:53.997726 osd.1 [INF] 1.5 scrub ok 2014-06-02 15:45:06.734270 mon.0 [INF] pgmap v41341: 952 pgs: 1 active+clean+scrubbing+deep, 951 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail 2014-06-02 15:45:15.722456 mon.0 [INF] pgmap v41342: 952 pgs: 952 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail 2014-06-02 15:46:06.836430 osd.0 [INF] 17.75 deep-scrub ok 2014-06-02 15:45:55.720929 mon.0 [INF] pgmap v41343: 952 pgs: 1 active+clean+scrubbing+deep, 951 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail
出力には以下が含まれます。
- クラスター ID
- クラスターの正常性ステータス
- モニターマップエポックおよびモニタークォーラムのステータス
- OSD マップエポックおよび OSD のステータス
- 配置グループマップバージョン
- 配置グループとプールの数
- 保存されるデータの 想定 量および保存されるオブジェクト数
- 保存されるデータの合計量
3.2.5. Ceph のデータ使用量の計算方法
使用される
値は、使用される生のストレージの 実際 の量を反映します。xxx GB / xxx GB
の値は、クラスターの全体的なストレージ容量のうち、2 つの数字の小さい方の利用可能な量を意味します。概念番号は、複製、クローン、またはスナップショットを作成する前に、保存したデータのサイズを反映します。したがって、Ceph はデータのレプリカを作成し、クローン作成やスナップショットのためにストレージ容量を使用することもあるため、実際に保存されるデータの量は、通常、保存された想定される量を上回ります。
3.2.6. ストレージクラスターの使用統計について
クラスターのデータ使用状況とプール間でのデータ分散を確認するには、df
オプションを使用します。これは Linux df
コマンドに似ています。ceph df
コマンドまたは ceph df detail
コマンドのいずれかを実行できます。
例
[root@mon ~]# ceph df RAW STORAGE: CLASS SIZE AVAIL USED RAW USED %RAW USED hdd 90 GiB 84 GiB 100 MiB 6.1 GiB 6.78 TOTAL 90 GiB 84 GiB 100 MiB 6.1 GiB 6.78 POOLS: POOL ID STORED OBJECTS USED %USED MAX AVAIL .rgw.root 1 1.3 KiB 4 768 KiB 0 26 GiB default.rgw.control 2 0 B 8 0 B 0 26 GiB default.rgw.meta 3 2.5 KiB 12 2.1 MiB 0 26 GiB default.rgw.log 4 3.5 KiB 208 6.2 MiB 0 26 GiB default.rgw.buckets.index 5 2.4 KiB 33 2.4 KiB 0 26 GiB default.rgw.buckets.data 6 9.6 KiB 15 1.7 MiB 0 26 GiB testpool 10 231 B 5 384 KiB 0 40 GiB
ceph df detail
コマンドは、quota objects、quota bytes、used compression、および under compression など、その他のプール統計に関する詳細情報を提供します。
例
[root@mon ~]# ceph df detail RAW STORAGE: CLASS SIZE AVAIL USED RAW USED %RAW USED hdd 90 GiB 84 GiB 100 MiB 6.1 GiB 6.78 TOTAL 90 GiB 84 GiB 100 MiB 6.1 GiB 6.78 POOLS: POOL ID STORED OBJECTS USED %USED MAX AVAIL QUOTA OBJECTS QUOTA BYTES DIRTY USED COMPR UNDER COMPR .rgw.root 1 1.3 KiB 4 768 KiB 0 26 GiB N/A N/A 4 0 B 0 B default.rgw.control 2 0 B 8 0 B 0 26 GiB N/A N/A 8 0 B 0 B default.rgw.meta 3 2.5 KiB 12 2.1 MiB 0 26 GiB N/A N/A 12 0 B 0 B default.rgw.log 4 3.5 KiB 208 6.2 MiB 0 26 GiB N/A N/A 208 0 B 0 B default.rgw.buckets.index 5 2.4 KiB 33 2.4 KiB 0 26 GiB N/A N/A 33 0 B 0 B default.rgw.buckets.data 6 9.6 KiB 15 1.7 MiB 0 26 GiB N/A N/A 15 0 B 0 B testpool 10 231 B 5 384 KiB 0 40 GiB N/A N/A 5 0 B 0 B
出力の RAW STORAGE セクションは、ストレージクラスターがデータに使用するストレージ容量の概要を説明します。
- CLASS: 使用されるデバイスのタイプ。
SIZE: ストレージクラスターが管理する全ストレージ容量。
上記の例では、
SIZE
が 90 GiB の場合、レプリケーション係数 (デフォルトでは 3) を考慮しない合計サイズです。レプリケーション係数を考慮した使用可能な合計容量は 90 GiB/3 = 30 GiB です。フル比率 (デフォルトでは 85%) に基づくと、使用可能な最大容量は 30 GiB * 0.85 = 25.5 GiB です。AVAIL: ストレージクラスターで利用可能な空き容量。
上記の例では、
SIZE
が 90 GiB、USED
容量が 6 GiB の場合、AVAIL
容量は 84 GiB になります。レプリケーション係数 (デフォルトでは 3) を考慮した使用可能な合計容量は、84 GiB/3 = 28 GiB です。USD: ユーザーデータ、内部オーバーヘッド、または予約済み容量に消費される、ストレージクラスター内の使用済み領域の量。
上記の例では、100 MiB がレプリケーション係数を考慮した後で利用可能な合計領域です。実際に使用可能なサイズは 33 MiB です。
-
RAW USED: USED 領域の合計と、BlueStore パーティション
db
およびwal
に割り当てられた領域の合計。 -
% RAW USED: RAW USED の割合。この数字は、
full ratio
とnear full ratio
で使用して、ストレージクラスターの容量に達しないようにします。
出力の POOLS セクションは、プールの一覧と、各プールの概念的な使用目的を提供します。このセクションの出力には、レプリカ、クローン、またはスナップショットを 反映しません。たとえば、1 MB のデータでオブジェクトを保存する場合、概念的な使用量は 1 MB になりますが、実際の使用量は、size = 3
のクローンやスナップショットなどのレプリカ数によっては 3 MB 以上になる場合があります。
- POOL: プールの名前。
- ID: プール ID。
- STOERD: ユーザーがプールに格納する実際のデータ量。
- OBJECTS: プールごとに保存されるオブジェクトの想定数。
-
USED: メガバイトの場合は M、ギガバイトの場合は G を付加しない限り、キロバイト単位で保存されたデータの想定量。これは、
STORED
サイズ * レプリケーション係数です。 - %USED: プールごとに使用されるストレージの概念パーセンテージ。
MAX AVAIL: このプールに書き込むことができる想定データ量の推定。これは、最初の OSD がフルになる前に使用できるデータの量です。CRUSH マップからディスクにまたがるデータの予測分布を考慮し、フルにする最初の OSD をターゲットとして使用します。
上記の例では、レプリケーション係数 (デフォルトでは 3) を考慮しない
MAX AVAIL
は 153.85 です。MAX AVAIL
の値を計算するには、ナレッジベースのアーティクル ceph df MAX AVAIL is incorrect for simple replicated pool を参照してください。- QUOTA OBJECTS: クォータオブジェクトの数。
- QUOTA BYTES: クォータオブジェクトのバイト数。
- USED COMPR: 圧縮データに割り当てられる領域の量これには、圧縮データ、割り当て、レプリケーション、およびイレイジャーコーディングのオーバーヘッドが含まれます。
- UNDER COMPR: 圧縮に渡されるデータの量で、圧縮された形式で保存することが十分に有益です。
POOLS セクションの数字は概念的です。レプリカ、スナップショット、またはクローンの数は含まれていません。その結果、USED と %USED の量の合計は、出力の GLOBAL セクションの RAW USED と %RAW USED の量に加算されません。
MAX AVAIL の値は、使用されるレプリケーションまたはイレイジャージャーコード、ストレージをデバイスにマッピングする CRUSH ルール、それらのデバイスの使用率、および設定された mon_osd_full_ratio
の複雑な関数です。
関連情報
- 詳細は、Ceph のデータ使用量の計算方法 を参照してください。
- 詳細は、 OSD の使用状況の統計について を参照してください。
3.2.7. OSD の使用状況の統計について
ceph osd df
コマンドを使用して、OSD 使用率の統計を表示します。
[root@mon]# ceph osd df ID CLASS WEIGHT REWEIGHT SIZE USE DATA OMAP META AVAIL %USE VAR PGS 3 hdd 0.90959 1.00000 931GiB 70.1GiB 69.1GiB 0B 1GiB 861GiB 7.53 2.93 66 4 hdd 0.90959 1.00000 931GiB 1.30GiB 308MiB 0B 1GiB 930GiB 0.14 0.05 59 0 hdd 0.90959 1.00000 931GiB 18.1GiB 17.1GiB 0B 1GiB 913GiB 1.94 0.76 57 MIN/MAX VAR: 0.02/2.98 STDDEV: 2.91
- ID: OSD の名前。
- CLASS: OSD が使用するデバイスのタイプ。
- WEIGHT: CRUSH マップの OSD の重み。
- REWEIGHT: デフォルトの再重み値です。
- SIZE: OSD の全体的なストレージ容量
- USE: OSD の容量
- DATA: ユーザーデータが使用する OSD 容量
-
OMAP: オブジェクトマップ (
omap
) データを保存するために使用されているbluefs
ストレージの推定値 (rocksdb
に保存されたキー/値のペア)。 -
META: 内部メタデータに割り当てられた
bluefs
の領域、またはbluestore_bluefs_min
パラメーターで設定された値のうちいずれか大きい方の値で、bluefs
に割り当てられた領域の合計から推定omap
データサイズを差し引いた値として計算されます。 - AVAIL: OSD で利用可能な空き容量
- %USE: OSD で使用されるストレージの表記率
- VAR: 平均の使用率を上回るまたは下回る変動。
- PGS: OSD 内の配置グループ数
- MIN/MAX VAR: すべての OSD における変更の最小値および最大値。
関連情報
- 詳細 h、Ceph のデータ使用量の計算方法 を参照してください。
- 詳細は、OSD の使用状況の統計について を参照してください。
- 詳細は、Red Hat Ceph Storage ストレージ戦略ガイドの CRUSH の重み を参照してください。
3.2.8. Red Hat Ceph Storage クラスターのステータスの確認
コマンドラインインターフェイスから Red Hat Ceph Storage クラスターのステータスを確認することができます。status
サブコマンドまたは -s
引数は、ストレージクラスターの現在のステータスを表示します。
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- ノードへのルートレベルのアクセス。
手順
ストレージクラスターのステータスを確認するには、以下を実行します。
[root@mon ~]# ceph status
または、以下を実行します。
[root@mon ~]# ceph -s
インタラクティブモードで
status
と入力して、Enter を押します。[root@mon ~]# ceph> status
たとえば、1 台のモニターで設定される小さな Ceph クラスターと、2 つの OSD が以下のように出力されます。
cluster b370a29d-9287-4ca3-ab57-3d824f65e339 health HEALTH_OK monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1 osdmap e63: 2 osds: 2 up, 2 in pgmap v41332: 952 pgs, 20 pools, 17130 MB data, 2199 objects 115 GB used, 167 GB / 297 GB avail 1 active+clean+scrubbing+deep 951 active+clean
3.2.9. Ceph Monitor ステータスの確認
ストレージクラスターに複数の Ceph Monitor がある場合 (実稼働環境用の Red Hat Ceph Storage クラスターに必要)、ストレージクラスターの起動後に Ceph Monitor クォーラム (定足数) のステータスを確認し、データの読み取りまたは書き込みを実施する前に、Ceph Monitor クォーラムのステータスを確認します。
複数のモニターを実行している場合はクォーラムが存在する必要があります。
Ceph Monitor ステータスを定期的にチェックし、実行していることを確認します。Ceph Monitor に問題があり、ストレージクラスターの状態に関する合意ができない場合は、その障害により Ceph クライアントがデータを読み書きできなくなる可能性があります。
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- ノードへのルートレベルのアクセス。
手順
監視マップを表示するには、以下を実行します。
[root@mon ~]# ceph mon stat
または
[root@mon ~]# ceph mon dump
ストレージクラスターのクォーラムステータスを確認するには、以下を実行します。
[root@mon ~]# ceph quorum_status -f json-pretty
Ceph はクォーラムのステータスを返します。3 つのモニターで設定される Red Hat Ceph Storage クラスターは、以下を返す場合があります。
例
{ "election_epoch": 10, "quorum": [ 0, 1, 2], "monmap": { "epoch": 1, "fsid": "444b489c-4f16-4b75-83f0-cb8097468898", "modified": "2011-12-12 13:28:27.505520", "created": "2011-12-12 13:28:27.505520", "mons": [ { "rank": 0, "name": "a", "addr": "127.0.0.1:6789\/0"}, { "rank": 1, "name": "b", "addr": "127.0.0.1:6790\/0"}, { "rank": 2, "name": "c", "addr": "127.0.0.1:6791\/0"} ] } }
3.2.10. Ceph 管理ソケットの使用
管理ソケットを使用して、UNIX ソケットファイルを使用して、指定したデーモンと直接対話します。たとえば、ソケットを使用すると以下を行うことができます。
- ランタイム時に Ceph 設定を一覧表示します。
-
Monitor に依存せずに直接ランタイムに設定値を設定します。これは、モニターが
ダウン
している場合に便利です。 - ダンプの履歴操作
- 操作優先度キューの状態をダンプします。
- 再起動しないダンプ操作
- パフォーマンスカウンターのダンプ
さらに、Monitor または OSD に関連する問題のトラブルシューティングを行う場合は、ソケットの使用に役立ちます。
管理ソケットは、デーモンの実行中にのみ利用できます。デーモンを正常にシャットダウンすると、管理ソケットが削除されます。ただし、デーモンが突然終了すると、管理ソケットが永続化される可能性があります。
デーモンが実行されていない場合でも、管理ソケットの使用を試みる際に以下のエラーが返されます。
Error 111: Connection Refused
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- ノードへのルートレベルのアクセス。
手順
ソケットを使用するには、以下を実行します。
構文
[root@mon ~]# ceph daemon TYPE.ID COMMAND
以下を置き換えます。
-
TYPE
を、Ceph デーモンのタイプ (mon
、osd
、mds
) に置き換えます。 -
ID
を、デーモン ID に置き換えます。 COMMAND
を、実行するコマンドに置き換えます。指定のデーモンで利用可能なコマンドを一覧表示するには、help
を使用します。例
mon.0
という名前の Ceph Monitor の Monitor ステータスを表示するには、以下を実行します。[root@mon ~]# ceph daemon mon.0 mon_status
-
または、ソケットファイルを使用して Ceph デーモンを指定します。
ceph daemon /var/run/ceph/SOCKET_FILE COMMAND
osd.2
という名前の Ceph OSD のステータスを表示するには、以下のコマンドを実行します。[root@mon ~]# ceph daemon /var/run/ceph/ceph-osd.2.asok status
Ceph プロセスのソケットファイルの一覧を表示するには、以下のコマンドを実行します。
[root@mon ~]# ls /var/run/ceph
関連情報
- 詳細は、Red Hat Ceph Storage トラブルシューティングガイド を参照してください。
3.2.11. Ceph OSD のステータスについて
OSD のステータスは、クラスター内 (in
) またはクラスター外 (out
) のいずれかになります。これは、稼働中 (up
) が、ダウンしているか (down
) のいずれかになります。OSD が up
の場合は、データの読み取りおよび書き込みが可能なストレージクラスターにある (in
) か、ストレージクラスターの外 (out
) にあるかのいずれかになります。クラスター内 (in
) にあり、最近クラスターの外 (out
) に移動すると、Ceph は配置グループを他の OSD に移行します。OSD がクラスター 外
の場合、CRUSH は配置グループを OSD に割り当てません。OSD が down
している場合は、それも out
となるはずです。
OSD が down
して in
にある場合は問題があり、クラスターは正常な状態になりません。
ceph health
、ceph -s
、ceph -w
などのコマンドを実行すると、クラスターが常に HEALTH OK
をエコーバックしないことが分かります。慌てないでください。OSD に関連して、予想される状況でクラスターが HEALTH OK
をエコー しない ことが予想されます。
- クラスターを起動していないと、応答しません。
- クラスターを起動または再起動したばかりで、配置グループが作成されつつあり、OSD がピアリング中であるため、準備はできていません。
- OSD を追加または削除したのみです。
- クラスターマップを変更しただけです。
OSD の監視の重要な要素は、クラスターの起動時および稼働時にクラスター 内
のすべての OSD が 稼働
していることを確認することです。
すべての OSD が実行中かどうかを確認するには、以下を実行します。
[root@mon ~]# ceph osd stat
または
[root@mon ~]# ceph osd dump
結果により、マップのエポック (eNNNN
)、OSD の総数 (x
)、いくつの y
が up
で、いくつの z
が in
であるかが分かります。
eNNNN: x osds: y up, z in
クラスターにある (in
) OSD の数が、稼働中 (up
) の OSD 数を超える場合。以下のコマンドを実行して、実行していない ceph-osd
デーモンを特定します。
[root@mon ~]# ceph osd tree
例
# id weight type name up/down reweight -1 3 pool default -3 3 rack mainrack -2 3 host osd-host 0 1 osd.0 up 1 1 1 osd.1 up 1 2 1 osd.2 up 1
適切に設計された CRUSH 階層で検索する機能は、物理ロケーションをより迅速に特定してストレージクラスターをトラブルシューティングするのに役立ちます。
OSD がダウンしている (down
) 場合は、ノードに接続して開始します。Red Hat Storage コンソールを使用して OSD ノードを再起動するか、コマンドラインを使用できます。
例
[root@mon ~]# systemctl start ceph-osd@OSD_ID