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 クラスターがある。
  • ノードへのルートレベルのアクセス。

手順

  1. インタラクティブモードで ceph ユーティリティーを実行するには、以下を行います。

    1. ベアメタル デプロイメント:

      [root@mon ~]# ceph
      ceph> health
      ceph> status
      ceph> quorum_status
      ceph> mon_status

    2. コンテナー デプロイメント:

      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 クラスターがある。
  • ノードへのルートレベルのアクセス。

手順

  1. Ceph Storage クラスターの正常性を確認するには、以下を使用します。

    [root@mon ~]# ceph health
  2. 設定またはキーリングにデフォルト以外の場所を指定した場合は、その場所を指定できます。

    [root@mon ~]# ceph -c /path/to/conf -k /path/to/keyring health

Ceph クラスターの起動時に、HEALTH_WARN XXX num placement groups stale などの正常性警告が生じる可能性があります。しばらく待ってから再度確認します。ストレージクラスターの準備が整ったら、ceph healthHEALTH_OK などのメッセージを返すはずです。この時点で、クラスターの使用を開始するのは問題ありません。

3.2.4. ストレージクラスターイベントの監視

コマンドラインインターフェイスを使用して、Ceph Storage クラスターで発生しているイベントを監視することができます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスターがある。
  • ノードへのルートレベルのアクセス。

手順

  1. コマンドラインでクラスターの進行中のイベントを確認するには、新しい端末を開き、以下を入力します。

    [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 rationear 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 の複雑な関数です。

関連情報

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 における変更の最小値および最大値。

関連情報

3.2.8. Red Hat Ceph Storage クラスターのステータスの確認

コマンドラインインターフェイスから Red Hat Ceph Storage クラスターのステータスを確認することができます。status サブコマンドまたは -s 引数は、ストレージクラスターの現在のステータスを表示します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスターがある。
  • ノードへのルートレベルのアクセス。

手順

  1. ストレージクラスターのステータスを確認するには、以下を実行します。

    [root@mon ~]# ceph status

    または、以下を実行します。

    [root@mon ~]# ceph -s
  2. インタラクティブモードで 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 クラスターがある。
  • ノードへのルートレベルのアクセス。

手順

  1. 監視マップを表示するには、以下を実行します。

    [root@mon ~]# ceph mon stat

    または

    [root@mon ~]# ceph mon dump
  2. ストレージクラスターのクォーラムステータスを確認するには、以下を実行します。

    [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 クラスターがある。
  • ノードへのルートレベルのアクセス。

手順

  1. ソケットを使用するには、以下を実行します。

    構文

    [root@mon ~]# ceph daemon TYPE.ID COMMAND

    以下を置き換えます。

    • TYPE を、Ceph デーモンのタイプ (monosdmds) に置き換えます。
    • ID を、デーモン ID に置き換えます。
    • COMMAND を、実行するコマンドに置き換えます。指定のデーモンで利用可能なコマンドを一覧表示するには、help を使用します。

      mon.0 という名前の Ceph Monitor の Monitor ステータスを表示するには、以下を実行します。

      [root@mon ~]# ceph daemon mon.0 mon_status
  2. または、ソケットファイルを使用して Ceph デーモンを指定します。

    ceph daemon /var/run/ceph/SOCKET_FILE COMMAND
  3. osd.2 という名前の Ceph OSD のステータスを表示するには、以下のコマンドを実行します。

    [root@mon ~]# ceph daemon /var/run/ceph/ceph-osd.2.asok status
  4. Ceph プロセスのソケットファイルの一覧を表示するには、以下のコマンドを実行します。

    [root@mon ~]# ls /var/run/ceph

関連情報

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 にある場合は問題があり、クラスターは正常な状態になりません。

OSD States

ceph healthceph -sceph -w などのコマンドを実行すると、クラスターが常に HEALTH OK をエコーバックしないことが分かります。慌てないでください。OSD に関連して、予想される状況でクラスターが HEALTH OK をエコー しない ことが予想されます。

  • クラスターを起動していないと、応答しません。
  • クラスターを起動または再起動したばかりで、配置グループが作成されつつあり、OSD がピアリング中であるため、準備はできていません。
  • OSD を追加または削除したのみです。
  • クラスターマップを変更しただけです。

OSD の監視の重要な要素は、クラスターの起動時および稼働時にクラスター のすべての OSD が 稼働 していることを確認することです。

すべての OSD が実行中かどうかを確認するには、以下を実行します。

[root@mon ~]# ceph osd stat

または

[root@mon ~]# ceph osd dump

結果により、マップのエポック (eNNNN)、OSD の総数 (x)、いくつの yup で、いくつの zin であるかが分かります。

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

3.2.12. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.