第3章 モニタリング
クラスターを実行したら、ストレージクラスターのモニタリングを開始し、Ceph Monitor および OSD デーモンがハイレベルで実行されるようにします。Ceph ストレージクラスターのクライアントは Ceph モニターに接続し、最新バージョンの Ceph クラスターマップを取得してから、ストレージクラスターの Ceph プールにデータを読み書きできます。そのため、モニタークラスターには、Ceph クライアントがデータの読み取りおよび書き込みが可能になる前に、クラスターの状態に関する合意が必要です。
Ceph OSD は、セカンダリー OSD の配置グループのコピーと、プライマリー OSD 上の配置グループをピアにする必要があります。障害が発生した場合、ピアリングは active + clean 状態以外のものを反映します。
3.1. ハイレベルのモニタリング
ストレージクラスターの高レベルのモニタリングには、通常、Ceph OSD および Monitor デーモンのステータスを確認し、それらが稼働していることを確認します。また、高レベルのモニタリングには、ストレージクラスター容量を確認して、クラスターが完全な比率を超えないようにします。Ansible Tower または Red Hat Storage Console ノードの Calamari インスタンスは、高レベルのモニタリングを実行する最も一般的な方法です。ただし、コマンドライン、管理ソケット、または Ceph API を使用してストレージクラスターを監視することもできます。
3.1.1. インタラクティブモード
インタラクティブモードで ceph ユーティリティーを実行するには、引数なしでコマンドラインに ceph と入力します。以下に例を示します。
# ceph ceph> health ceph> status ceph> quorum_status ceph> mon_status
3.1.2. クラスターのヘルスチェク
Ceph Storage クラスターを起動してからデータの読み書きを開始する前に、ストレージクラスターの健全性を確認します。Ceph Storage クラスターの正常性を確認するには、以下を使用します。
# ceph health
設定またはキーリングにデフォルト以外の場所を指定した場合は、その場所を指定できます。
# ceph -c /path/to/conf -k /path/to/keyring health
Ceph クラスターの起動時に、HEALTH_WARN XXX num placement groups stale などの正常性警告が生じる可能性があります。しばらく待ってから再度確認します。ストレージクラスターの準備が整ったら、ceph health は HEALTH_OK などのメッセージを返すはずです。この時点で、クラスターの使用を問題なく開始することができます。
3.1.3. クラスターの監視
コマンドラインでクラスターの続行中のイベントを監視するには、新しいターミナルを開きます。次に、以下を入力します。
# 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 のステータス
- 配置グループマップバージョン
- 配置グループとプールの数
- 保存されるデータの 想定 量および保存されるオブジェクト数
- 保存されるデータの合計量
Ceph によるデータ使用量の計算方法
使用される 値は、使用される生のストレージの 実際 の量を反映します。xxx GB / xxx GB の値は、クラスターの全体的なストレージ容量のうち、2 つの数字の小さい方の利用可能な量を意味します。概念番号は、複製、クローン、またはスナップショットを作成する前に、保存したデータのサイズを反映します。したがって、Ceph はデータのレプリカを作成し、クローン作成やスナップショットのためにストレージ容量を使用することもあるため、実際に保存されるデータの量は、通常、保存された想定される量を上回ります。
3.1.4. クラスターの使用統計の確認
クラスターのデータの使用状況とプール間のデータ分散を確認するには、df オプションを使用します。これは Linux の df に似ています。以下のコマンドを実行します。
# ceph df
出力の GLOBAL セクションは、ストレージクラスターがデータに使用するストレージ容量の概要を示します。
- SIZE: ストレージクラスターの全体的なストレージ容量。
- AVAIL: ストレージクラスターで利用可能な空き容量。
- RAW USED: 使用されている raw ストレージの量。
-
% RAW USED: 使用されている raw ストレージの割合。この数字は、
full ratioとnear full ratioで使用して、ストレージクラスターの容量に達しないようにします。
出力の POOLS セクションは、プールの一覧と、各プールの概念的な使用目的を提供します。このセクションの出力には、レプリカ、クローン、またはスナップショットを反映 しません。たとえば、1MB のデータを持つオブジェクトを保存する場合、概念上の使用量は 1MB ですが、実際の使用量はレプリカの数 (例: size = 3、クローンおよびスナップショット) に応じて 3 MB 以上になる場合があります。
- NAME: プールの名前。
- ID: プール ID。
- USED: メガバイトの場合は M、ギガバイトの場合は G を付加しない限り、キロバイト単位で保存されたデータの想定量。
- %USED: プールごとに使用されるストレージの概念パーセンテージ。
- Objects: プールごとに格納されているオブジェクトの想定数。
POOLS セクションの数字は概念的です。レプリカ、スナップショット、またはクローンの数が含まれません。その結果、USED と %USED の量の合計は、出力の GLOBAL セクションの RAW USED と %RAW USED の量に加算されません。詳しくは、Ceph によるデータ使用量の計算方法 を参照してください。
3.1.5. クラスターステータスの確認
クラスターのステータスを確認するには、以下を実行します。
# ceph status
または以下を実行します。
# ceph -s
インタラクティブモードで、status と入力し、Enter を押します。
ceph> status
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 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+clean3.1.6. モニターステータスの確認
ストレージクラスターに複数のモニターがある場合、これは実稼働用の Ceph ストレージクラスターの高可用性に必要です。Ceph ストレージクラスターの起動後に、データの読み書きの前に Ceph Monitor クォーラムのステータスを確認する必要があります。複数のモニターを実行している場合はクォーラムが存在する必要があります。また、Ceph Monitor ステータスを定期的に確認して、それらが稼働していることを確認する必要があります。ストレージクラスターの状態で合意できないような問題が Monitor で発生した場合、問題によって Ceph クライアントがデータを読み書きできない可能性があります。
監視マップを表示するには、以下を実行します。
# ceph mon stat
または
# ceph mon dump
ストレージクラスターのクォーラムステータスを確認するには、以下を実行します。
# ceph quorum_status -f json-pretty
Ceph はクォーラムのステータスを返します。たとえば、3 つのモニターで構成される Ceph ストレージクラスターは、以下を返す可能性があります。
{ "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.1.7. 管理ソケットの使用
管理ソケットを使用して、UNIX ソケットファイルを使用して、指定したデーモンと直接対話します。たとえば、ソケットを使用すると以下を行うことができます。
- ランタイム時に Ceph 設定を一覧表示します。
-
Monitor にリレーせずに起動時に値を直接設定します。これは、モニターが
ダウンしている場合に便利です。 - ダンプの履歴操作
- 操作優先度キューの状態をダンプします。
- 再起動しないダンプ操作
- パフォーマンスカウンターのダンプ
さらに、Monitor または OSD に関連する問題のトラブルシューティングを行う場合は、ソケットの使用に役立ちます。詳細は、Red Hat Ceph Storage 3『Troubleshooting Guide』を参照してください。
ソケットを使用するには、以下を実行します。
ceph daemon <type>.<id> <command>
以下を置き換えます。
-
<type>は、Ceph デーモンのタイプ (mon、osd、mds) に置き換えます。 -
<id>をデーモン ID に置き換えます。 -
<command>を実行するコマンドに置き換えます。指定のデーモンで利用可能なコマンドを一覧表示するには、helpを使用します。
たとえば、mon.0 という名前の Monitor ステータスを表示するには、以下を実行します。
# ceph daemon mon.0 mon_status
または、ソケットファイルを使用してデーモンを指定します。
ceph daemon /var/run/ceph/<socket-file> <command>
たとえば、osd.2 という名前の OSD のステータスを表示するには、以下を実行します。
# ceph daemon /var/run/ceph/ceph-osd.2.asok status
Ceph プロセスのソケットファイルの一覧を表示するには、以下のコマンドを実行します。
$ ls /var/run/ceph
3.1.8. 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 が実行中かどうかを確認するには、以下を実行します。
# ceph osd stat
または
# ceph osd dump
結果により、マップのエポック (eNNNN)、OSD の総数 (x)、いくつの y が up で、いくつの z が in であるかが分かります。
eNNNN: x osds: y up, z in
クラスター内である in の OSD の数が up の OSD の数よりも多い場合、以下のコマンドを実行して、稼働していない ceph-osd デーモンを特定します。
# 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 Console を使用して OSD ノードを再起動するか、以下のようにコマンドラインを使用できます。
# systemctl start ceph-osd@<osd_id>
