すべての Red Hat Ceph Storage クラスターには、以下の項目を定義する設定があります。

Ansible などのデプロイメントツールは、通常、初期の Ceph 設定ファイルを作成します。ただし、デプロイメントツールを使用して Red Hat Ceph Storage クラスターをブートストラップする場合には、独自に作成することができます。

Ceph Monitor は、Ceph オプションの設定データベースを管理します。これにより、ストレージクラスター全体の設定オプションを格納することで、設定の管理を一元化します。Ceph の設定をデータベースに一元化することで、ストレージクラスターの管理に役立ちます。ローカルの Ceph 設定ファイル (デフォルトでは /etc/ceph/ceph.conf) で定義できる Ceph オプションはまだいくつかあります。これらのいくつかの Ceph 設定オプションは、他の Ceph コンポーネントが Ceph Monitor に接続して認証し、データベースから設定情報を取得する方法を制御します。

Ceph では、実行時にデーモンの設定を変更することができます。この機能は、デバッグ設定の有効化/無効化によりログ出力を増減する場合に役立ちます。さらに、ランタイムの最適化にも使用できます。

マスクには 2 つの形式があります。

Ceph 設定ファイルは起動時に Ceph デーモンを設定し、これによりデフォルト値が上書きされます。

Ceph のデフォルト設定ファイルの場所は /etc/ceph/ceph.conf です。以下を使用して、別のパスを設定してその場所を変更できます。

Ceph 設定ファイルには、ini スタイルの構文を使用します。コメントの前にシャープ記号 (#) またはセミコロン (;) を記入して、コメントを追加できます。

# <--A pound sign (#) sign precedes a comment.
# Comments always follow a semi-colon (;) or a pound (#) on each line.
# The end of the line terminates a comment.
# We recommend that you provide comments in your configuration file(s).
; A comment may be anything.

設定ファイルは、Ceph ストレージクラスター内のすべての Ceph デーモン、または特定タイプのすべての Ceph デーモンを起動時に設定できます。一連のデーモンを設定するには、以下のように設定を受け取るプロセスのセクションに設定を含める必要があります。

    [mon.host01]
     `host = host01`
     `mon_addr = 10.0.0.101`
    [mon.host02]
     `host = host02`
     `mon_addr = 10.0.0.102`

グローバル設定は、Ceph ストレージクラスターの全デーモンのすべてのインスタンスに影響します。[global] の見出しは、Ceph Storage クラスターのすべてのデーモンに共通する値に使用します。以下のように各 [global] オプションを上書きできます。

または

特定のデーモンでオーバーライドするプロセスを除き、グローバル設定を上書きすると、すべての子プロセスが影響を受けます。

一般的なグローバル設定には、認証のアクティブ化が含まれます。

[global]
#Enable authentication between hosts within the cluster.
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx

特定の種類のデーモンに適用される設定を指定できます。特定のインスタンスを指定せずに [osd] または [mon] で設定を指定すると、設定はすべての OSD またはモニターのデーモンにそれぞれ適用されます。デーモン全体の設定の一例としては、osd メモリーターゲットがあります。

[osd]
osd_memory_target = 5368709120

デーモンの特定インスタンスの設定を指定できます。タイプとインスタンス ID をピリオド (.) で区切って入力することにより、インスタンスを指定することができます。Ceph OSD デーモンのインスタンス ID は常に数値ですが、Ceph モニターの場合は英数字である場合があります。

[osd.1]
# settings affect osd.1 only.

[mon.a]
# settings affect mon.a only.

一般的な Ceph 設定ファイルには、少なくとも以下の設定があります。

[global]
fsid = UNIQUE_CLUSTER_ID
mon_initial_members = NODE_NAME[, NODE_NAME]
mon_host = IP_ADDRESS[, IP_ADDRESS]

#All clusters have a front-side public network.
#If you have two NICs, you can configure a back side cluster
#network for OSD object replication, heart beats, backfilling,
#recovery, and so on
public_network = PUBLIC_NET[, PUBLIC_NET]
#cluster_network = PRIVATE_NET[, PRIVATE_NET]

#Clusters require authentication by default.
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx

#Choose reasonable numbers for your number of replicas
#and placement groups.
osd_pool_default_size = NUM  # Write an object n times.
osd_pool_default_min_size = NUM # Allow writing n copy in a degraded state.
osd_pool_default_pg_num = NUM
osd_pool_default_pgp_num = NUM

#Choose a reasonable crush leaf type.
#0 for a 1-node cluster.
#1 for a multi node cluster in a single rack
#2 for a multi node, multi chassis cluster with multiple hosts in a chassis
#3 for a multi node cluster with hosts across racks, and so on
osd_crush_chooseleaf_type = NUM

[global]
cluster network = 10.74.250.101/21
fsid = 3e07d43f-688e-4284-bfb7-3e6ed5d3b77b
mon host = [v2:10.0.0.101:3300/0,v1:10.0.0.101:6789/0] [v2:10.0.0.102:3300/0,v1:10.0.0.102:6789/0] [v2:10.0.0.103:3300/0,v1:10.0.0.103:6789/0]
mon initial members = host01, host02, host03
osd pool default crush rule = -1
public network = 10.74.250.101/21

[osd]
osd memory target = 4294967296

[mon]
    [mon.host01]
     host = host01
     mon_addr = 10.0.0.101
    [mon.host02]
     host = host02
     mon_addr = 10.0.0.102

メタ変数は、Ceph ストレージクラスターの設定を大幅に簡素化します。メタ変数が設定値に設定されると、Ceph はそのメタ変数を具体的な値に展開します。

メタ変数は、Ceph 設定ファイルの [global] セクション、[osd] セクション、[mon] セクション、または [client] セクション内で使用すると非常に強力です。しかし、管理用ソケットでも使用可能です。Ceph メタ変数は、Bash のシェル拡張に似ています。

Ceph は以下のメタ変数をサポートしています。

Ceph 設定ファイルは、ブート時および実行時に表示することができます。

Red Hat Ceph Storage の設定設定は、Ceph Monitor ノードから実行時に確認することができます。

ランタイム設定を指定する一般的な方法は 2 つあります。

tell および injectargs コマンドを使用してモニターと通信すると、Ceph ランタイム設定オプションを設定できます。

BlueStore は、osd_memory_target 設定オプションを使用して、OSD ヒープメモリーの使用を指定されたターゲットサイズで保持します。

osd_memory_target オプションは、システムで利用可能な RAM に基づいて OSD メモリーを設定します。デフォルトでは、Ansible は値を 4 GB に設定します。デーモンをデプロイする際に、/usr/share/ceph-ansible/group_vars/all.yml ファイルで、バイト単位で示している値を変更できます。ceph.conf ファイルの Ceph オーバーライドを使用して、osd memory target をたとえば 6 GB に手動で設定することもできます。

ceph_conf_overrides:
  osd:
    osd memory target: 6442450944

Ceph OSD のメモリーキャッシングは、ブロックデバイスが低速である場合に重要となります (例えば、従来のハードドライブの場合)。キャッシュヒットのメリットがソリッドステートドライブの場合よりもはるかに大きいからです。ただし、ハイパーコンバージドインフラストラクチャー (HCI) や他のアプリケーションなど、他のサービスと OSD を共存させる場合には、この点を考慮する必要があります。

MDS サーバーは、そのメタデータを別のストレージプール (cephfs_metadata) に保持し、Ceph OSD のユーザーです。Ceph File System の場合、MDS サーバーはストレージクラスター内の単一のストレージデバイスだけでなく、Red Hat Ceph Storage クラスター全体をサポートする必要があるため、特にワークロードが小/中サイズのファイルで設定されている場合 (データに対するメタデータの比率が高い)、メモリー要件が大きくなる可能性があります。

例: mds_cache_memory_limit を 2 GiB に設定します

ceph_conf_overrides:
  osd:
    mds_cache_memory_limit: 2147483648

高性能な Red Hat Ceph Storage クラスターを構築するには、ネットワークの設定が重要です。Ceph ストレージクラスターは、Ceph クライアントに代わって要求のルーティングやディスパッチを実行しません。代わりに、Ceph クライアントは Ceph OSD デーモンに直接要求を出します。Ceph OSD は Ceph クライアントに代わってデータレプリケーションを実行するため、レプリケーションおよび他の要素によって Ceph ストレージクラスターのネットワークに追加の負荷がかかります。

すべての Ceph ク ラスターは、パブリックネットワークを使用する必要があります。ただし、内部のクラスターネットワークを指定しない限り、Ceph は 1 つのパブリックネットワークを想定します。Ceph はパブリックネットワークでのみ機能しますが、大規模なストレージクラスターの場合は、クラスター関連のトラフィックのみを伝送する第 2 のプライベートネットワークを使用すると、パフォーマンスが大幅に向上します。

2 つのネットワークをサポートするには、各 Ceph Node に複数のネットワークインターフェイスカード (NIC) が必要になります。

2 つの別々のネットワークを運用することを検討する理由はいくつかあります。

ネットワーク設定の定義は必要ありません。Ceph はパブリックネットワークでのみ機能するので、Ceph デーモンを実行するすべてのホストでパブリックネットワークが設定されている必要があります。しかし、Ceph では、複数の IP ネットワークやサブネットマスクなど、より具体的な条件をパブリックネットワークに設定することができます。また、OSD ハートビート、オブジェクトのレプリケーション、およびリカバリートラフィックを処理するために、別のクラスターネットワークを構築することもできます。

設定で定義する IP アドレスと、ネットワーククライアントがサービスにアクセスする際に使用する公開用の IP アドレスを混同しないようにしてください。通常、内部 IP ネットワークは 192.168.0.0 または 10.0.0.0 です。

ネットワークの設定が完了したら、クラスターの再起動や各デーモンの再起動を行います。Ceph デーモンは動的にバインドするので、ネットワーク設定を変更してもクラスター全体を一度に再起動する必要はありません。

Ceph には、すべてのデーモンに適用される 1 つのネットワーク設定要件があります。Ceph 設定ファイルは、各デーモンに host を指定する必要があります。

ホスト名を指定して、デーモンがある場所の host 名と IP アドレスを設定できます。

[mon.a]
    host = host01
    mon_addr = 10.0.0.101:6789, 10.0.0.101:3300

[osd.0]
    host = host02

デーモンにノード IP アドレスを設定する必要はありません。これは任意の設定です。静的 IP 設定でパブリックネットワークとプライベートネットワークの両方を実行している場合、Ceph 設定ファイルで各デーモンのノードの IP アドレスを指定する場合があります。デーモンに静的 IP アドレスを設定するには、Ceph 設定ファイルのデーモンインスタンスセクションに記述する必要があります。

[osd.0]
    public_addr = 10.74.250.101/21
    cluster_addr = 10.74.250.101/21

2 つのネットワークを持つクラスターに、単一の NIC を持つ OSD ホストを強制的にデプロイすることができます。Ceph 設定ファイルの [osd.n] セクションに public addr エントリーを追加することにより、OSD ホストを強制的にパブリックネットワークで操作できます。n は、1 つの NIC を持つ OSD の数を示します。さらに、パブリックネットワークとクラスターネットワークは互いにトラフィックをルーティングできる必要がありますが、セキュリティー上の理由から Red Hat は推奨していません。

メッセンジャーは Ceph ネットワーク層の実装です。Red Hat は 2 種類のメッセンジャーをサポートしています。

Red Hat Ceph Storage 3 以降では、async がデフォルトの messenger タイプです。messenger タイプを変更するには、Ceph 設定ファイルの [global] セクションに ms_type 設定を指定します。

パブリックネットワークの設定では、特にパブリックネットワークの IP アドレスとサブネットを定義することができます。特定のデーモンの public addr 設定を使用して、静的 IP アドレスまたは public network 設定をオーバーライドできます。

[global]
    ...
    public_network = PUBLIC-NET/NETMASK

クラスターネットワークを宣言した場合、OSD はハートビート、オブジェクトのレプリケーション、およびリカバリートラフィックをクラスターネットワーク上でルーティングします。これにより、単一のネットワークを使用する場合と比較して、パフォーマンスが向上します。

クラスターネットワーク設定により、クラスターネットワークを宣言し、特にクラスターネットワークの IP アドレスおよびサブネットを定義できます。特定の OSD デーモンの cluster addr 設定を使用して、静的 IP アドレスを割り当てるか、cluster network 設定を上書きすることができます。

[global]
    ...
    cluster_network = CLUSTER-NET/NETMASK

デフォルトでは、デーモンは 6800:7100 範囲内のポートにバインドされます。この範囲は、ユーザーの判断で設定することができます。ファイアウォールを設定する前に、デフォルトのファイアウォール設定を確認してください。

Ceph モニターはデフォルトでポート 3300 および 6789 をリッスンします。さらに、Ceph モニターは常にパブリックネットワーク上で動作します。

デフォルトでは、Ceph OSD は、ポート 6800 から順に Ceph ノードで最初に利用可能なポートにバインドします。ノード上で動作する各 OSD に対して、6800 番ポート以降の少なくとも 4 つのポートを開くようにしてください。

ポートはノードごとに異なります。ただし、プロセスが再起動されてバインドされたポートが解放されない場合には、その Ceph ノードで実行されている Ceph デーモンが必要とするポート数よりも多くのポートを開く必要があるかもしれません。デーモンに障害が発生し、ポートを解放せずに再起動した場合に、再起動したデーモンが新しいポートにバインドするように、さらにいくつかのポートを開くことを検討してください。また、各 OSD ノードでポート範囲 6800:7300 を開くことを検討してください。

パブリックネットワークとクラスターネットワークを別々に設定した場合、クライアントはパブリックネットワークを使用して接続し、他の Ceph OSD デーモンはクラスターネットワークを使用して接続するため、パブリックネットワークとクラスターネットワークの両方にルールを追加する必要があります。

クラスターネットワークを別のゾーンに配置した場合は、そのゾーン内のポートを適切に開きます。

最大伝送単位 (MTU) 値は、リンク層で送信される最大パケットのサイズ (バイト単位) です。MTU のデフォルト値は 1500 バイトです。Red Hat は、Red Hat Ceph Storage クラスターには、MTU 値が 9000 バイトのジャンボフレームを使用することを推奨します。

Ceph Monitor の設定方法を理解することは、信頼性の高い Red Hat Ceph Storage クラスターを構築する上で重要なことです。すべてのストレージクラスターには少なくとも 1 つのモニターがあります。通常、Ceph Monitor の設定はほぼ一定のままですが、ストレージクラスター内の Ceph Monitor を追加、削除、または交換することができます。

Ceph モニターは、クラスターマップのマスターコピーを維持します。つまり、1 つの Ceph モニターに接続して最新のクラスターマップを取得するだけで、Ceph クライアントはすべての Ceph モニターと Ceph OSD の位置を把握することができます。

Ceph クライアントが Ceph OSD に対して読み取り/書き込みを行うには、まず Ceph Monitor に接続する必要があります。クラスターマップの現在のコピーと CRUSH アルゴリズムを使用して、Ceph クライアントは任意のオブジェクトの位置を計算できます。オブジェクトの位置を計算できることで、Ceph クライアントは Ceph OSD と直接対話できるます。このことは、Ceph の高いスケーラビリティーとパフォーマンスを実現する上で非常に重要な要素となります。

Ceph Monitor の主なロールは、クラスターマップのマスターコピーを維持することです。Ceph Monitor は、認証とログサービスも提供します。Ceph Monitor は、モニターサービスのすべての変更を 1 つの Paxos インスタンスに書き込み、Paxos はその変更をキー/値ストアに書き込んで強い一貫性を持たせます。Ceph Monitor は、同期操作中にクラスターマップの最新バージョンにクエリーを行うことができます。Ceph Monitor は、rocksdb データベースを使用したキー値ストアのスナップショットやイテレーターを使用して、ストア全体の同期を実行します。

クラスターマップは、モニターマップ、OSD マップ、および配置グループマップなどのマップを合成したものです。クラスターマップは、多くの重要なイベントを追跡します。

例えば、Ceph OSD がダウンしたり、配置グループがデグレード状態に陥ったりするなど、クラスターの状態に大きな変化があった場合。クラスターマップが更新され、クラスターの現在の状態が反映されます。さらに、Ceph モニターはクラスターの以前の状態の履歴も保持します。モニターマップ、OSD マップ、および配置グループマップは、それぞれのマップバージョンの履歴を保持します。各バージョンは エポック と呼ばれます。

Red Hat Ceph Storage クラスターを運用する場合、これらの状態を追跡することはクラスター管理の重要な部分です。

クラスターは、1 台のモニターで十分に動作します。しかし、1 台のモニターは単一故障点になります。本番環境の Ceph ストレージクラスターで高可用性を確保するには、複数のモニターで Ceph を実行し、1 つのモニターの故障がストレージクラスター全体の障害にならないようにします。

Ceph ストレージクラスターが高可用性のために複数の Ceph Monitor を実行している場合、Ceph Monitor は Paxos アルゴリズムを使用してマスタークラスターマップに関する合意を確立します。コンセンサスを得るには、大半のモニターが動作していて、クラスターマップに関するコンセンサスのためのクォーラムを確立する必要があります。例えば、1、3 つのうちの 2 つ、5 つのうちの 3 つ、6 つのうちの 4 つ等。

Red Hat では、高可用性を確保するために、少なくとも 3 つの Ceph Monitor で本番環境の Red Hat Ceph Storage クラスターを実行することを推奨しています。複数のモニターを実行する場合、クォーラムを確立するためにストレージクラスターのメンバーでなければならない初期モニターを指定することができます。これにより、ストレージクラスターがオンラインになるまでの時間が短縮される場合があります。

[mon]
mon_initial_members = a,b,c

Ceph 設定ファイルにモニター設定を追加する場合、Ceph Monitor モニターのアーキテクチャー的な側面をいくつか知っておく必要があります。Ceph は、クラスター内で別の Ceph Monitor を検出する際に、Ceph Monitor に厳格な一貫性要件を課します。Ceph クライアントおよびその他の Ceph デーモンは、Ceph 設定ファイルを使用してモニターを検出し、Ceph 設定ファイルではなくモニターマップ (monmap) を使用して相互を検出します。

Ceph Monitor が Red Hat Ceph Storage クラスター内の他の Ceph Monitor を検出する場合、常にモニターマップのローカルコピーを参照します。Ceph 設定ファイルではなくモニターマップを使用することで、クラスターが壊れる可能性のあるエラーを回避できます。例えば、Ceph 設定ファイルでモニターのアドレスやポートを指定する際のタイプミスなどです。モニターは検出のためにモニターマップを使用し、クライアントや他の Ceph デーモンとモニターマップを共有するため、モニターマップは、モニターのコンセンサスが有効であることをモニターに対して厳格に保証します。

Ceph Monitor がモニターマップではなく Ceph 設定ファイルを介してお互いを検出する場合、Ceph 設定ファイルは自動的に更新および配布されないため、新たなリスクが発生する可能性があります。Ceph Monitor が誤って古い Ceph 設定ファイルを使用し、Ceph Monitor の識別に失敗し、クォーラムから外れたり、Paxos がシステムの現在の状態を正確に判断できなかったりする状況が発生する可能性があります。

ほとんどの設定とデプロイメントの場合、Ansible などの Ceph をデプロイするツールは、モニターマップを生成して Ceph モニターのブートストラップを支援することがあります。

Ceph モニターには、いくつかの明示的な設定が必要です。

クラスター全体に設定を適用するには、[global] セクションに設定設定を入力します。クラスター内のすべてのモニターに設定を適用するには、[mon] セクションに設定設定を入力します。特定のモニターに設定を適用するには、モニターインスタンスを指定します。

慣習的に、モニターインスタンス名にはアルファ表記が使用されます。

[global]

[mon]

[mon.a]

[mon.b]

[mon.c]

Ceph 設定ファイルの Ceph モニターの最低限のモニター設定には、各モニターのホスト名 (DNS に設定されていない場合) とモニターアドレスが含まれます。これらの設定は、[mon] の下、または特定のモニターのエントリーの下で設定できます。

[mon]
mon_host = hostname1,hostname2,hostname3
mon_addr = 10.0.0.10:6789,10.0.0.11:6789,10.0.0.12:6789,10.0.0.10:3300,10.0.0.11:3300,10.0.0.12:3300

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

[mon.a]
host = hostname1
mon_addr = 10.0.0.10:6789, 10.0.0.10:3300

DNS ルックアップ用に Ceph クラスターを設定するには、Ceph 設定ファイルの mon_dns_srv_name 設定を設定します。

設定が完了したら、DNS の設定を行います。DNS ゾーンにモニターの IPv4 (A) または IPv6 (AAAA) いずれかのレコードを作成します。

#IPv4
mon1.example.com. A 192.168.0.1
mon2.example.com. A 192.168.0.2
mon3.example.com. A 192.168.0.3

#IPv6
mon1.example.com. AAAA 2001:db8::100
mon2.example.com. AAAA 2001:db8::200
mon3.example.com. AAAA 2001:db8::300

ここで、example.com は DNS 検索ドメインになります。

次に、3 つのモニターを指す mon_dns_srv_name 設定名で SRV TCP レコードを作成します。以下の例では、デフォルトの ceph-mon 値を使用しています。

_ceph-mon._tcp.example.com. 60 IN SRV 10 60 6789 mon1.example.com.
_ceph-mon._tcp.example.com. 60 IN SRV 10 60 6789 mon2.example.com.
_ceph-mon._tcp.example.com. 60 IN SRV 10 60 6789 mon3.example.com.
_ceph-mon._tcp.example.com. 60 IN SRV 10 60 3300 mon1.example.com.
_ceph-mon._tcp.example.com. 60 IN SRV 10 60 3300 mon2.example.com.
_ceph-mon._tcp.example.com. 60 IN SRV 10 60 3300 mon3.example.com.

モニターはデフォルトでポート 6789 と 3300 で稼働し、その優先度と重みはすべて前述の例でそれぞれ 10 および 60 に設定されます。

各 Red Hat Ceph Storage クラスターには固有の ID (fsid) があります。指定した場合には、通常は設定ファイルの [global] セクションに表示されます。デプロイメントツールは通常、fsid を生成してモニターマップに保存するため、値は設定ファイルに表示されない可能性があります。fsid を使用すると、同じハードウェア上で複数のクラスターに対してデーモンを実行できます。

Ceph では、Ceph モニターがデータを保存するデフォルトのパスが用意されています。

Ceph モニターは fsync() 関数を頻繁に呼び出します。これは、Ceph OSD ワークロードに干渉する可能性があります。

Ceph モニターは、データをキー/値ペアとして保存します。データストアを使用すると、他のメリットに加えて、復旧中の Ceph モニターが Paxos と通じて破損したバージョンを実行することを防ぎ、1 つのアトミックバッチで複数の修正操作が可能になります。

Red Hat Ceph Storage クラスターが最大容量 (mon_osd_full_ratio パラメーターにより指定) に近くなると、データの損失を防ぐために安全対策として Ceph OSD への書き込みができなくなります。そのため、本番環境の Red Hat Ceph Storage クラスターをそのフル比率に近づけてしまうことは、高可用性が犠牲になってしまうのでグッドプラクテイスとは言えません。デフォルトのフル比率は、.95 (容量の 95%) です。これは、OSD の数が少ないテストクラスター用の非常に厳しい設定です。

テストクラスターの一般的なシナリオでは、システム管理者が Red Hat Ceph Storage クラスターから Ceph OSD を削除してクラスターの再バランスを観察します。その後、別の Ceph OSD を削除し、Red Hat Ceph Storage クラスターが最終的にフル比率に達してロックアップするまでこれを繰り返します。

理想的には、Ceph OSD を直ちに置き換えることなく、クラスターが active + clean な状態に復元できる Ceph OSD の一連の障害を計画する必要があります。クラスターを active + degraded の状態で実行できますが、これは通常の動作条件には理想的ではありません。

次の図は、33 台の Ceph Node が含まれる単純化した Red Hat Ceph Storage クラスターを示しています。ホストごとに 1 つの Ceph OSD があり、各 Ceph OSD デーモンは 3 TB のドライブに対して読み取りおよび書き込を行います。つまり、この例の Red Hat Ceph Storage クラスターの最大実容量は 99 TB です。mon osd full ratio が 0.95 の場合は、Red Hat Ceph Storage クラスターが空き容量が 5 TB になると、Ceph クライアントはデータの読み取りと書き込みを許可しません。そのため、Red Hat Ceph Storage クラスターの運用上の容量は 99 TB ではなく 95 TB となります。

このようなクラスターでは、1 つまたは 2 つの OSD が故障するのが普通です。頻度は低いが妥当なシナリオとしては、ラックのルーターや電源が故障し、複数の OSD が同時にダウンすることが挙げられます (例: OSD 7 - 12)。このようなシナリオでは、さらに OSD のあるホストを短い順序で追加する場合でも、動作し続け、active + clean な状態を実現するクラスターを試す必要があります。容量利用率が高すぎると、データを失うことはないかもしれませんが、クラスターの容量利用率がフル比率を超えた場合、障害ドメイン内の障害を解決している間データの可用性が犠牲になる可能性があります。このため、Red Hat では、少なくとも大まかな容量計画を立てることを推奨しています。

クラスターに関する 2 つの数字を把握します。

クラスター内の OSD の平均容量を求めるには、クラスターの総容量をクラスター内の OSD の数で割ります。この数に、通常の運用で同時に故障すると予想される OSD の数 (比較的小さい数) を乗じます。最後に、クラスターの容量にフル比率を掛けて、運用上の最大容量を算出します。そして、失敗すると予想される OSD からデータ量を差し引いて、合理的なフル比率を算出します。前述のプロセスを、より多くの OSD 故障数 (例えば、OSD のラック) で繰り返し、ほぼフル比率のための妥当な数を算出します。

Ceph モニターは、各 OSD からのレポートを要求し、隣接する OSD の状態に関するレポートを OSD から受け取ることで、クラスターについて把握します。Ceph では、モニターと OSD の間の相互作用について妥当なデフォルト設定が用意されていますが、必要に応じて変更することができます。

複数のモニターを持つ本番環境用のクラスターを運用する場合 (推奨される設定)、各モニターは隣接するモニターがより新しいバージョンのクラスターマップを持っているかどうかを確認します。例えば、隣接するモニターのマップのエポックナンバーが、インスタントモニターのマップの最新のエポックより 1 つ以上高い場合。定期的に、クラスター内のあるモニターが他のモニターから遅れをとることがあります。その場合、そのモニターはクォーラムから離脱し、同期をとってクラスターに関する最新の情報を取得した後、再びクォーラムに参加しなければなりません。

これらのロールにより、リーダーは同期のタスクをプロバイダーに委譲しすることができ、同期の要求によりリーダーが過負荷になることを防ぎ、パフォーマンスが向上します。次の図では、リクエスターが他のモニターに遅れをとっていることを認識しています。リクエスターはリーダーに同期を依頼し、リーダーはリクエスターにプロバイダーとの同期を指示します。

同期が完了すると、Ceph ではクラスター全体のトリミングが必要になります。トリミングを行うには、配置グループが active + clean である必要があります。

Ceph デーモンは、クリティカルなメッセージを相互に渡します。このメッセージは、デーモンがタイムアウトのしきい値に達する前に処理する必要があります。Ceph モニターのクロックが同期していないと、さまざまな異常が発生する可能性があります。

以下に例を示します。

NTP では、遅れによる悪影響が出ていなくても、クロックドリフトが目立つことがあります。NTP が適切なレベルの同期を維持していても、Ceph のクロックドリフトとクロックスキューの警告が発生することがあります。このような状況では、クロックドリフトを増やすことが許容できるかもしれません。しかし、ワークロード、ネットワークレイテンシー、デフォルトのタイムアウトに対するオーバーライド設定、およびその他の同期オプションなど、多くの要因が、Paxos の保証を損なうことなく許容できるクロックドリフトのレベルに影響を与えます。

cephx プロトコルはデフォルトで有効になっています。暗号認証には多少の計算コストがかかりますが、一般的には非常に低いものです。クライアントとホストを結ぶネットワーク環境が安全と考えられ、認証の計算コストがかけられない場合は、無効にすることができます。Ceph Storage クラスターをデプロイする際に、デプロイメントツールは client.admin ユーザーおよびキーリングを作成します。

cephx が有効な場合には、Ceph はデフォルトの検索パス /etc/ceph/$cluster.$name.keyring を含む) でキーリングを探します。Ceph 設定ファイルの [global] セクションに keyring オプションを追加することで、この場所を上書きすることができますが、これは推奨されません。

認証が無効になっているクラスターで cephx を有効にするには、以下の手順を実行します。ご自身またはデプロイメントユーティリティーがすでにキーを生成している場合は、キーの生成に関する手順を省略できます。

以下の手順では、Cephx を無効にする方法を説明します。クラスター環境が比較的安全であれば、認証を実行するための計算コストを相殺することができます。

しかし、セットアップやトラブルシューティングの際には、一時的に認証を無効にした方が簡単な場合もあります。

認証が有効な Ceph を実行する場合には、Ceph Storage クラスターにアクセスするために ceph 管理コマンドおよび Ceph クライアントに認証キーが必要です。

ceph 管理コマンドおよびクライアントにこれらの鍵を提供する最も一般的な方法は、/etc/ceph/ ディレクトリーの下に Ceph キーリングを追加することです。ファイル名は通常 ceph.client.admin.keyring または $cluster.client.admin.keyring です。/etc/ceph/ ディレクトリーにキーリングを含める場合は、Ceph 設定ファイルで keyring エントリーを指定する必要はありません。

それを行うには、以下のコマンドを実行します。

# scp USER@HOSTNAME:/etc/ceph/ceph.client.admin.keyring /etc/ceph/ceph.client.admin.keyring

USER を、ホストで使用されるユーザー名に client.admin キーを使用し、HOSTNAME をそのホストのホスト名に置き換えます。

推奨されていない key 設定を使用して、Ceph 設定ファイルにキー自体を指定したり、keyfile 設定を使用してキーファイルへのパスを指定することができます。

管理ユーザーやデプロイメントツールは、ユーザーキーリングの生成と同じ方法で、デーモンキーリングを生成することがあります。デフォルトでは、Ceph はデーモンのキーリングをデータディレクトリー内に保存します。デフォルトのキーリングの場所や、デーモンが機能するために必要な機能など。

デーモンデータのディレクトリーの位置は、デフォルトでは以下の形式のディレクトリーになります。

/var/lib/ceph/$type/CLUSTER-ID

/var/lib/ceph/osd/ceph-12

これらの場所を上書きすることもできますが、お勧めできません。

Ceph にはきめ細かな制御機能があり、クライアントと Ceph の間のサービスメッセージの署名を有効または無効にすることができます。Ceph デーモン間のメッセージに対する署名を有効または無効にすることができます。

プールを作成し、プールの配置グループの数を設定するとき、特にデフォルトをオーバーライドしない場合、Ceph はデフォルト値を使用します。

これらの値は、pool コマンドの実行時に設定できます。Ceph 設定ファイルの [global] セクションに新規のものを追加して、デフォルト値を上書きすることもできます。

[global]

# By default, Ceph makes 3 replicas of objects. If you want to set 4
# copies of an object as the default value--a primary copy and three replica
# copies--reset the default values as shown in 'osd pool default size'.
# If you want to allow Ceph to write a lesser number of copies in a degraded
# state, set 'osd pool default min size' to a number less than the
# 'osd pool default size' value.

osd_pool_default_size = 4  # Write an object 4 times.
osd_pool_default_min_size = 1 # Allow writing one copy in a degraded state.

# Ensure you have a realistic number of placement groups. We recommend
# approximately 100 per OSD. E.g., total number of OSDs multiplied by 100
# divided by the number of replicas (i.e., osd pool default size). So for
# 10 OSDs and osd pool default size = 4, we'd recommend approximately
# (100 * 10) / 4 = 250.

osd_pool_default_pg_num = 250
osd_pool_default_pgp_num = 250

すべての Ceph クラスターには、以下の項目を定義する設定があります。

Red Hat Ceph Storage Console または Ansible などのデプロイメントツールは、通常、初期の Ceph 設定ファイルを作成します。ただし、デプロイメントツールを使用してクラスターをブートストラップする場合には、独自に作成することができます。

便宜上、各デーモンにはデフォルト値のセットがあります。その多くは ceph/src/common/config_opts.h スクリプトで設定されます。これらの設定は、Ceph 設定ファイル、またはランタイム時にモニターの tell コマンドを使用するか、Ceph ノード上のデーモンソケットに直接接続して上書きできます。

Ceph は、オブジェクトの複数のコピーを作成するだけでなく、配置グループをスクラビングすることでデータの整合性を確保します。Ceph のスクラブは、オブジェクトストレージ層の fsck コマンドに似ています。

各配置グループについて、Ceph はすべてのオブジェクトのカタログを生成し、各プライマリーオブジェクトとそのレプリカを比較して、オブジェクトの欠落や不一致がないことを確認します。

ライトスクラビング (毎日) では、オブジェクトのサイズや属性をチェックします。ディープスクラビング (毎週) は、データを読み込んでチェックサムでデータの整合性を確保します。

スクラビングはデータの整合性を保つために重要ですが、パフォーマンスを低下させる可能性があります。以下の設定を調整して、スクラブ動作を増減させます。

Ceph OSD をクラスターに追加したり、クラスターから削除したりすると、CRUSH アルゴリズムは、配置グループを Ceph OSD に移動させたり、Ceph OSD から移動させたりしてバランスを回復させ、クラスターのバランスを取り戻します。配置グループとそれに含まれるオブジェクトを移行するプロセスは、クラスターの運用パフォーマンスを大幅に低下させます。運用パフォーマンスを維持するために、Ceph はこの移行をバックフィルプロセスで実行します。これにより、Ceph はバックフィル操作をデータの読み取りまたは書き込みの要求よりも低い優先度に設定できます。

クラスターが起動したとき、または Ceph OSD が予期せず終了して再起動したとき、OSD は書き込み操作を行う前に他の Ceph OSD とのピアリングを開始します。

Ceph OSD がクラッシュしてオンラインに戻ると、通常、配置グループのオブジェクトのより新しいバージョンが含まれる他の Ceph OSD との同期が取れなくなります。このような場合、Ceph OSD はリカバリーモードに入り、データの最新コピーを取得してマップを最新の状態に戻そうとします。Ceph OSD が停止していた時間によっては、OSD のオブジェクトや配置グループが大幅に古くなっている可能性があります。また、障害ドメイン (例: ラックなど) ダウンした場合、複数の Ceph OSD が同時にオンラインに戻る可能性があります。そのため、復旧作業には時間とリソースが必要になります。

運用パフォーマンスを維持するために、Ceph はリカバリー要求数、スレッド数、およびオブジェクトチャンクサイズを制限してリカバリーを実行し、これにより Ceph は劣化した状態でも適切なパフォーマンスを発揮することができます。

Ceph の初期設定が完了したら、Ceph をデプロイして実行することができます。ceph health、ceph -s などのコマンドを実行すると、Ceph Monitor は Ceph Storage クラスターの現在の状態を報告します。Ceph Monitor は、各 Ceph OSD デーモンからのレポートを要求し、隣接する Ceph OSD デーモン の状態に関するレポートを Ceph OSD デーモンから受け取ることで、Ceph ストレージクラスターについて把握します。Ceph Monitor がレポートを受信しない場合、または Ceph ストレージクラスターの変更のレポートを受信した場合、Ceph Monitor は Ceph クラスターマップのステータスを更新します。

Ceph では、Ceph Monitor と OSD の連携について妥当なデフォルト設定が用意されています。ただし、デフォルト値を上書きできます。以下のセクションでは、Ceph ストレージクラスターを監視する目的で、Ceph Monitor と Ceph OSD デーモンがどのように相互作用するかを説明します。

各 Ceph OSD デーモンは、6 秒ごとに他の Ceph OSD デーモンのハートビートをチェックします。ハートビートの間隔を変更するには、Ceph 設定ファイルの [osd] セクションに osd heartbeat interval 設定を追加するか、ランタイム時にその値を変更します。

近傍の Ceph OSD デーモンが 20 秒の猶予期間内にハートビートパケットを送信しない場合、Ceph OSD デーモンは近傍の Ceph OSD デーモンが down であるとみなされる可能性があります。それを Ceph Monitor に報告して、Ceph クラスターマップを更新することができます。この猶予期間を変更するには、Ceph 設定ファイルの [osd] セクションに osd heartbeat grace 設定を追加するか、ランタイム時にの値を設定します。

デフォルトでは、異なるホスト の 2 つの Ceph OSD デーモンは、報告された Ceph OSD デーモンが down していることを Ceph モニターが確認する前に、別の CephOSD デーモンが down していることを Ceph モニターに報告する必要があります。

しかし、障害を報告するすべての OSD が、ラック内の異なるホストに設置されており、スイッチ不良により OSD 間の接続に問題が生じる場合があります。

誤報を避けるために、Ceph は障害を報告したピアを、同様に遅延しているサブクラスターの代理として考えます。これは必ずしもそうとは限りませんが、管理者が、パフォーマンスの低下しているシステムのサブセットに局所的に適切な補正を適用するのに役立つ場合があります。

Ceph は mon_osd_reporter_subtree_level 設定を使用して、CRUSH マップの共通の先復元タイプでピアを subcluster にグループ化します。

デフォルトでは、異なるサブツリーからわずか 2 つのレポートは、他の Ceph OSD デーモン down を報告する必要があります。管理者は、Ceph 設定ファイルの [mon] セクションの下で、mon_osd_min_down_reporters 設定および mon_osd_reporter_subtree_level 設定を追加するか、ランタイム時に値を設定することで、Ceph Monitor に Ceph OSD Daemon down を報告するために必要な固有のサブツリーと共通の祖先型からレポーターの数を変更することができます。

Ceph OSD デーモンが、その Ceph 設定ファイルまたはクラスターマップで定義された Ceph OSD デーモンのいずれともピアリングできない場合、30 秒ごとにクラスターマップの最新コピーを求めて Ceph Monitor に ping を実行します。Ceph Monitor ハートビートの間隔は、Ceph 設定ファイルの [osd] セクションに osd mon heartbeat interval 設定を追加するか、ランタイムに値を設定して変更できます。

Ceph OSD デーモンが Ceph Monitor に報告しない場合、Ceph Monitor は mon osd report timeout 後に down した Ceph OSD デーモンを考慮します。Ceph OSD デーモンは、障害、配置グループ統計の変更、up_thru の変更、または 5 秒以内にブートするなどの報告可能なイベント時に、Ceph Monitor にレポートを送信します。Ceph OSD Daemon の最小レポート間隔を変更するには、Ceph 設定ファイルの [osd] セクションに osd mon report interval min 設定を追加するか、ランタイムに値を設定します。

Ceph OSD デーモンは、目立った変更があったかどうかにかかわらず、120 秒ごとに Ceph Monitor にレポートを送信します。Ceph Monitor のレポート間隔を変更するには、Ceph 設定ファイルの [osd] セクションに osd mon report interval max 設定を追加するか、値をランタイムに設定します。

デバッグ設定は Ceph 設定ファイルでは必要ありませんが、ロギングを最適化するために追加することができます。Ceph のロギング設定の変更は通常、問題が発生した場合にランタイム時に発生しますが、Ceph 設定ファイルで変更することもできます。たとえば、クラスターの起動時に問題が発生した場合には、Ceph 設定ファイルでログ設定を増やすことを検討してください。問題が解決されたら、設定を削除したり、ランタイム操作に最適な設定を復元したりします。

デフォルトでは、/var/log/ceph の下にある Ceph ログファイルを表示します。

ロギングはリソース集約型です。クラスターの特定のエリアに問題がある場合は、クラスターのそのエリアのロギングを有効にします。たとえば、OSD は問題なく動作しているが、Ceph Object Gateway に問題がある場合は、問題が発生している特定のゲートウェイインスタンスのデバッグロギングを有効にして開始します。必要に応じて、各サブシステムのロギングを増減します。

Ceph ロギングが有効またはロギングレートを増やす場合は、OS ディスクの容量が十分にあることを確認してください。

クラスターが正常に実行されている場合は、不要なデバッグ設定を削除して、クラスターが最適に実行されるようにします。デバッグ出力メッセージのロギングは比較的遅くなります。また、クラスターの操作時にリソースが無駄になります。