アーキテクチャーガイド

Red Hat Ceph Storage 4

Red Hat Ceph Storage アーキテクチャーガイド

Red Hat Ceph Storage Documentation Team

概要

本書では、Ceph Storage クラスターおよびそのクライアントのアーキテクチャー情報を提供します。

第1章 Ceph アーキテクチャー

Red Hat Ceph Storage クラスターは、優れたパフォーマンス、信頼性、スケーラビリティーを提供するために設計された分散データオブジェクトストアです。非構造化データに対応しており、クライアントは最新のオブジェクトインターフェースとレガシーインターフェースを同時に使用できるため、分散オブジェクトストアは将来のストレージストアになります。

以下に例を示します。

  • 多くの言語(C/C++、Java、Python)の API
  • RESTful インターフェース(S3/Swift)
  • ブロックデバイスインターフェース
  • filesystem インターフェース

Red Hat Ceph Storage クラスターの機能は、組織の IT インフラストラクチャーを変換し、特に RHEL OSP などのクラウドコンピューティングプラットフォームで大量のデータを管理する機能を提供できます。Red Hat Ceph Storage クラスターは、ペタバイトからエクサバイト以上のデータにアクセスする数千のクライアントという 並外れた スケーラビリティーを提供します。

すべての Ceph デプロイメントの中心となるのは、Red Hat Ceph Storage クラスターです。これは、3 種類のデーモンで構成されます。

  • Ceph OSD デーモン: Ceph OSD は、Ceph クライアントの代わりにデータを格納します。また、Ceph OSD は Ceph ノードの CPU、メモリー、およびネットワークを使用して、データのレプリケーション、イレイジャーコーディング、リバランス、復旧、監視、レポート機能を実行します。
  • Ceph Monitor: Ceph Monitor は、Red Hat Ceph Storage クラスターの現在の状態を備えた Red Hat Ceph Storage クラスターのマッピングのマスターコピーを維持します。モニターには高度な一貫性が必要で、Paxos を使用して Red Hat Ceph Storage クラスターの状態に関する合意を確認します。
  • Ceph Manager: Ceph Monitor の代わりに、Ceph Manager は配置グループ、プロセスメタデータ、およびホストのメタデータの詳細情報を維持します。これにより、パフォーマンスが大幅に向上します。Ceph Manager は、配置グループの統計など、読み取り専用の Ceph CLI クエリーの実行を処理します。Ceph Manager は RESTful モニタリング API も提供します。
デーモン

Ceph クライアントインターフェースが、Red Hat Ceph Storage クラスターからデータの読み取りおよび書き込みを行います。Red Hat Ceph Storage クラスターと通信するには、クライアントに以下のデータが必要です。

  • Ceph 設定ファイル、またはクラスター名 (通常は ceph) およびモニターアドレス
  • プール名
  • ユーザー名および秘密鍵へのパス。

Ceph クライアントは、オブジェクト ID とオブジェクトを格納するプール名を維持します。ただし、Object-to-OSD インデックスを維持したり、オブジェクトの場所を検索するために集中型のオブジェクトインデックスと通信したりする必要はありません。データを保管して取得するには、Ceph クライアントが Ceph Monitor にアクセスし、Red Hat Ceph Storage クラスターマップの最新コピーを取得します。次に、Ceph クライアントは librados にオブジェクト名とプール名を提供します。これは、CRUSH (Controlled Replication Under Scalable Hashing) アルゴリズムを使用して、オブジェクトの配置グループと、データの保存と取得のための主要な OSD を計算します。Ceph クライアントはプライマリー OSD に接続し、読み取りおよび書き込み操作を行う可能性があります。クライアントと OSD には中間サーバー、ブローカー、またはバスがありません。

OSD がデータを保存すると、Ceph クライアントからデータを受け取ります。クライアントが Ceph Block Device、Ceph Object Gateway、Ceph Filesystem または別のインターフェースであるかどうか。また、データはオブジェクトとして保存されます。

注記

オブジェクト ID は、OSD のストレージメディアだけでなく、クラスター全体で一意です。

Ceph OSD は、すべてのデータをフラットな namespace にオブジェクトとして格納します。ディレクトリーの階層はありません。オブジェクトには、クラスター全体の一意の ID、バイナリーデータ、および名前と値のペアのセットで構成されるメタデータがあります。

オブジェクト

Ceph クライアントは、クライアントのデータフォーマットのセマンティクスを定義します。たとえば、Ceph ブロックデバイスは、ブロックデバイスイメージをクラスター全体に保管されている一連のオブジェクトにマッピングします。

注記

一意の ID、データ、および名前と値のペアのメタデータで構成されるオブジェクトは、構造化データと非構造化データの両方、レガシーおよび主要なエッジデータストレージインターフェースを表すことができます。

第2章 Ceph のコアコンポーネント

Red Hat Ceph Storage クラスターには、無制限のスケーラビリティー、高可用性、およびパフォーマンスを実現するために、多数の Ceph ノードを持つことができます。それぞれのノードは、プロプライエタリーハードウェアとインテリジェントな Ceph デーモンを活用して、以下を行います。

  • データの書き込みおよび読み取り
  • データの圧縮
  • データの複製またはイレイジャーコーディングによる永続性の確保
  • クラスターの正常性の監視および報告「ハートビート」とも呼ばれています。
  • データを動的に再配布 -「バックフィル」とも呼ばれています。
  • データの整合性を確保します。および
  • 失敗から復旧します。

データの読み取りと書き込みを行う Ceph クライアントインターフェースの場合、Red Hat Ceph Storage クラスターは、データを保管する単純なプールのようになります。ただし、librados およびストレージクラスターは、クライアントインターフェースから完全に透過的な方法で多くの複雑な操作を実行します。Ceph クライアントと Ceph OSD の両方で CRUSH(Scalable Hashing の制御)アルゴリズムを使用します。以下の項では、CRUSH が Ceph がこれらの操作をシームレスに実行できるようにする方法について詳しく説明します。

2.1. 前提条件

  • 分散ストレージシステムの基本を理解する。

2.2. Ceph プール

Ceph Storage クラスターは、データオブジェクトを 'Pools' と呼ばれる論理パーティションに保存します。 Ceph 管理者は、ブロックデバイス、オブジェクトゲートウェイ、または単にあるユーザーのグループを別のグループから分離するなどの、特定タイプのデータのプールを作成することができます。

Ceph クライアントの観点から見ると、ストレージクラスターは非常にシンプルです。Ceph クライアントが I/O コンテキストを使用してデータの読み取りまたは書き込みを行う場合は、常に Ceph ストレージクラスター内のストレージプールに接続します。クライアントはプール名、ユーザー、および秘密鍵を指定するため、プールはデータオブジェクトのアクセス制御を持つ論理パーティションとして機能します。

実際の Ceph プールは、オブジェクトデータを格納する論理パーティションではありません。プールは、Ceph Storage クラスターがデータを分散し、保管する方法において重要な役割を果たします。ただし、これらの複雑な操作は完全に Ceph クライアントに対して透過的です。

Ceph プールは以下を定義します。

  • プールタイプ: Ceph の初期バージョンでは、1 つのプールがオブジェクトの複数のディープコピーを保持するだけです。本リリースでは、Ceph はオブジェクトのコピーを複数維持するか、またはイレイジャーコーディングを使用して永続性を確保することができます。データ永続性メソッドはプール全体にわたり、プールの作成後は変更されません。プールタイプは、プールの作成時にデータ永続性メソッドを定義します。プールタイプはクライアントに対して完全に透過的です。
  • 配置グループ: エクサバイトスケールストレージクラスターでは、Ceph プールには、数百万以上のデータオブジェクトが格納される可能性があります。Ceph は、レプリカまたはイレイジャーコードチャンクを使用したデータ永続性、スクラビングまたは CRC チェック、レプリケーション、リバランス、およびリカバリーによるデータの整合性など、さまざまな種類の操作を処理する必要があります。そのため、オブジェクトごとにデータを管理すると、スケーラビリティーとパフォーマンスのボトルネックが発生します。Ceph は、プールを配置グループにシャード化することで、このボトルネックに対応します。CRUSH アルゴリズムは、オブジェクトを保存する配置グループを計算し、配置グループの OSD の Acting Set を計算します。CRUSH は各オブジェクトを配置グループに配置します。次に、CRUSH は各配置グループを OSD のセットに保存します。システム管理者は、プールを作成または変更する際に配置グループ数を設定します。
  • CRUSH Ruleset: CRUSH は別の重要な役割を果たします。CRUSH は障害ドメインおよびパフォーマンスドメインを検出できます。CRUSH は、ストレージメディアタイプで OSD を特定し、OSD をノード、ラック、および行に階層的に編成できます。CRUSH により、Ceph OSD は障害ドメイン全体にオブジェクトコピーを保存できます。たとえば、オブジェクトのコピーは、異なるサーバー部屋、aisles、racks、およびノードに保存されている場合があります。ラックなど、クラスターの大部分が失敗すると、クラスターが復旧するまで、クラスターの状態が低下した状態で動作し続けることができます。

さらに、CRUSH を使用すると、クライアントは SSD、SSD ジャーナルを使用したハードドライブ、データと同じドライブにあるジャーナルを持つハードドライブなど、特定のタイプのハードウェアにデータを書き込むことができます。CRUSH ルールセットは、プールの障害ドメインおよびパフォーマンスドメインを決定します。管理者は、プールの作成時に CRUSH ルールセットを設定します。

注記

管理者は、プールの作成後にプールのルールセットを変更 できません

  • 耐久性: エクサバイトスケールストレージクラスターでは、ハードウェア障害は予想され、例外ではありません。データオブジェクトを使用してブロックデバイスなどの大きなストレージインターフェースを表す場合、その大きなインターフェースのデータオブジェクトが失われると、大きなストレージエンティティーの整合性が低下する可能性があります。使用できなくなる可能性があります。そのため、データ損失は耐えません。Ceph では、2 つの方法で高データ永続性が提供されます。

    • レプリカプールは、CRUSH 障害ドメインを使用してオブジェクトの複数のディープコピーを、別のデータオブジェクトから物理的に分離します。つまり、コピーは個別の物理ハードウェアに分散されます。これにより、ハードウェア障害時の耐久性が向上します。
    • イレイジャーコーディングされたプールは各オブジェクトを K+M チャンクとして格納します。K はデータチャンクを表し、M はコーディングチャンクを表します。合計は、オブジェクトを保存するために使用される OSD 数を表し、M の値は失敗する可能性がある OSD 数を表します。M の値は、OSD が失敗するとデータが復元する回数を表します。

クライアントの観点から見ると、Ceph はシンプルです。クライアントはプールから読み書きを行うだけです。ただし、プールはデータ永続性、パフォーマンス、高可用性で重要な役割を果たします。

2.3. Ceph の認証

ユーザーを特定し、中間者攻撃から保護するために、Ceph は cephx 認証システムを提供し、ユーザーおよびデーモンを認証します。

注記

cephx プロトコルは、ネットワーク経由で転送されるデータや OSD に保存されるデータの暗号化には対応しません。

cephx は認証に共有シークレットキーを使用します。つまり、クライアントとモニタークラスターの両方にクライアントの秘密鍵のコピーがあります。認証プロトコルを使用すると、実際に鍵のコピーがあることを相互に証明することができます。これにより相互認証が提供されます。これは、ユーザーが秘密鍵を所有することを意味します。また、ユーザーはクラスターに秘密鍵のコピーがあることが確認できます。

Cephx

cephx 認証プロトコルは、Kerberos と同様に動作します。

ユーザー/アクターは、Ceph クライアントを呼び出してモニターに接続します。Kerberos とは異なり、各モニターはユーザーを認証して鍵を配布できるため、cephx を使用する際に単一障害点やボトルネックはありません。monitor は、Ceph サービスの取得に使用するセッションキーが含まれる Kerberos チケットと同様の認証データ構造を返します。このセッションキー自体はユーザーの永続的な秘密鍵で暗号化されるため、ユーザーのみが Ceph モニターからサービスを要求することができます。次にクライアントはセッションキーを使用してモニターから必要なサービスを要求し、監視はクライアントにデータを実際に処理する OSD に対してクライアントを認証するチケットを提供します。Ceph 監視および OSD はシークレットを共有するため、クライアントはクラスター内の OSD またはメタデータサーバーを使用してモニターによって提供されるチケットを使用することができます。攻撃者は、Kerberos のように cephx チケットの有効期限が切れるため、攻撃者は取得した期限切れのチケットまたはセッションキーを誤って使用できません。この形式の認証により、通信メディアにアクセスできる攻撃者は、ユーザーの秘密鍵が期限切れになる前に、別のユーザーの正当なメッセージを変更することや、別のユーザーの正当なメッセージを変更することができなくなります。

cephx を使用するには、管理者は最初にユーザーを設定する必要があります。以下の図では、client.admin ユーザーはコマンドラインから ceph auth get-or-create-key を呼び出して、ユーザー名およびシークレットキーを生成します。Ceph の auth サブシステムはユーザー名およびキーを生成し、モニターでコピーを保存し、ユーザーのシークレットを client.admin ユーザーに送り返します。つまり、クライアントとモニターが秘密鍵を共有します。

注記

client.admin ユーザーは、安全にユーザー ID とシークレットキーを提供する必要があります。

CephX

2.4. Ceph の配置グループ

クラスターに数千単位のオブジェクトを保存し、それらを個別に管理する場合には、リソース集約型です。そのため、Ceph は配置グループ(PG)を使用して、大量のオブジェクトをより効率的に管理します。

PG は、オブジェクトのコレクションを格納するためのプールのサブセットです。Ceph はプールを一連の PG にシャード化します。次に、CRUSH アルゴリズムはクラスターマップとクラスターのステータスを考慮して、PG を均等に、クラスターの OSD に均等に分散します。

以下に、その仕組みを説明します。

システム管理者がプールを作成すると、CRUSH はプールのユーザー定義の数を作成します。通常、PG 数はデータの合理的な粒度の細かいサブセットになります。たとえば、1 プールの 1 OSD あたり 100 PG は、各 PG にプールのデータの約 1% が含まれていることを意味します。

Ceph が OSD を 1 つの OSD から別の OSD に移動する必要がある場合に、PG 数はパフォーマンスに影響します。プールに数%の PG がない場合、Ceph は同時にデータの割合が同時に移動し、ネットワークの負荷はクラスターのパフォーマンスに悪影響を与えます。プールに PG が多すぎると、データのほぼパーセントを移動すると、Ceph は CPU および RAM を使用します。これにより、クラスターのパフォーマンスに悪影響を与えます。パフォーマンスを最適化するために PG 数を計算する方法は、「PG 数」を参照してください。

Ceph は、オブジェクトのレプリカを保存するか、オブジェクトのイレイジャーコードチャンクを保存することで、データ損失を回避します。Ceph は PG 内のオブジェクトのオブジェクトまたはイレイジャーコードチャンクを保存するため、Ceph は各 PG を OSD のセットに複製します。これは、オブジェクトの各コピーまたはオブジェクトの消去コードチャンクについて「Acting Set」と呼ばれています。システム管理者は、プール内の PG 数と、レプリカまたはイレイジャーコードチャンクの数を確認できます。ただし、CRUSH アルゴリズムは、特定の PG に対して有効なセットにある OSD を計算します。

CRUSH アルゴリズムおよび PG は Ceph を動的にします。クラスターマップまたはクラスターの状態を変更すると、Ceph が 1 つの OSD から別の OSD に自動的に移行する可能性があります。

以下にいくつか例を示します。

  • クラスターの拡張: 新規ホストとその OSD をクラスターに追加すると、クラスターマップが変更されます。CRUSH と擬似グループがクラスター全体で OSD に均等に分散されるため、新しいホストとその OSD を追加すると、CRUSH がプールの配置グループの一部をそれらの新規 OSD に再割り当てすることを意味します。つまり、システム管理者はクラスターを手動でリバランスする必要はありません。また、新規 OSD には他の OSD と同じ量のデータが含まれることを意味します。これは、新規 OSD に新規に作成された OSD が含まれず、クラスター内の「hot スポット」を防ぎます。
  • OSD 失敗: OSD が失敗すると、クラスターの状態が変わります。Ceph は一時的にレプリカまたはイレイジャーコードチャンクを失い、別のコピーを作成する必要があります。アクティビティーセットのプライマリー OSD が失敗すると、アクティビティーセットの次の OSD がプライマリーになり、CRUSH は新規 OSD を計算して追加のコピーまたは消去コードチャンクを保存します。

数百から数千にもなる PG のコンテキスト内で数百万のオブジェクトを管理することで、Ceph ストレージクラスターは拡張、縮小、および障害から効率的に復旧できます。

Ceph クライアントの場合は、librados を介した CRUSH アルゴリズムにより、オブジェクトの読み取りおよび書き込みプロセスが非常にシンプルになります。Ceph クライアントは単にオブジェクトをプールに書き込むか、またはプールからオブジェクトを読み取ります。有効なセットの主な OSD は、Ceph クライアントの代わりに有効なセットでオブジェクトのオブジェクトまたはイレイジャーコードチャンクをセカンダリー OSD に書き込むことができます。

クラスターマップまたはクラスターの状態が変わる場合、PGD を保存する OSD を保存する CRUSH 計算も変わります。たとえば、Ceph クライアントはオブジェクト foo をプール bar に書き込むことができます。CRUSH はオブジェクトを PG 1.a に割り当て、これを OSD 5 に保存します。これにより、OSD 10 および OSD 15 のレプリカがそれぞれ作成されます。OSD 5 が失敗すると、クラスターの状態が変わります。Ceph クライアントがプール bar からオブジェクト foo を読み込むと、librados 経由のクライアントは新しいプライマリー OSD として OSD 10 から自動的に取得されます。

librados を使用する Ceph クライアントは、オブジェクトの書き込みおよび読み取り時に、動作するセット内でプライマリー OSD に直接接続します。I/O 操作は集中ブローカーを使用しないため、通常、ネットワークのオーバーサブスクリプションは Ceph の問題ではありません。

以下の図は、CRUSH がオブジェクトを PG に割り当てる方法と、PG を OSD に割り当てる方法を示しています。CRUSH アルゴリズムは、有効なセットの各 OSD が別の障害ドメインにあることなどの OSD を OSD に割り当てます。通常、OSD は常に別々のサーバーホストにあり、場合によっては別々のラックに置かれます。

配置グループ

2.5. Ceph CRUSH ルールセット

Ceph は CRUSH ルールセットをプールに割り当てます。Ceph クライアントがプール内のデータを保存または取得する場合、Ceph は CRUSH ルールセット、ルールセット内のルール、データの保存および取得のためのルール内のトップレベルのバケットを特定します。Ceph が CRUSH ルールを処理するため、オブジェクトの配置グループが含まれるプライマリー OSD を特定します。これにより、クライアントは OSD に直接接続して配置グループにアクセスし、オブジェクトデータの読み取りまたは書き込みが可能になります。

配置グループを OSD にマップするために、CRUSH マップはバケットタイプの階層的な一覧を定義します。バケットタイプの一覧は、生成された CRUSH マップの types の下にあります。バケット階層を作成する目的は、ドライブタイプ、ホスト、シャーシ、ラック、電力分散ユニット、Pod、行、部屋、データセンターなど、障害ドメインやパフォーマンスドメインによってリーフノードを分離することです。

OSD を表すリーフノードを除き、階層の残りの部分は任意です。管理者は、デフォルトタイプが要件に適さない場合に、ニーズに応じて定義することができます。CRUSH は、Ceph OSD ノードをモデル化する直接のレガシーグラフ(通常は階層内)をサポートします。そのため、Ceph 管理者は単一の CRUSH マップで、複数のルートノードを持つ複数の階層をサポートすることができます。たとえば、管理者は高パフォーマンスのために高コスト SSD を表す階層と、中程度のパフォーマンスを実現する SSD ジャーナルを使用した低コストハードドライブの別個の階層を作成できます。

2.6. Ceph による入出力操作

Ceph クライアントは Ceph monitor から「Cluster Map」を取得し、プールにバインドし、プール内の配置グループ内のオブジェクトで入出力(I/O)を実行します。プールの CRUSH ルールセットと配置グループの数は、Ceph がデータを配置する方法を決定する主要な要素です。クラスターマップの最新バージョンでは、クライアントはクラスター内のすべてのモニターおよび OSD とその現在の状態を認識します。ただし、クライアントはオブジェクトの場所について何も知りません。

クライアントで必要な入力のみがオブジェクト ID およびプール名です。単純な方法: Ceph は名前付きプールにデータを格納します。クライアントがプールに名前付きオブジェクトを保存する場合、オブジェクト名、ハッシュコード、プール名、およびプール名を入力として取り込む場合、CRUSH(Controlled Replication under Scalable Hashing)は配置グループの ID と配置グループのプライマリー OSD を計算します。

Ceph クライアントは、以下の手順に従って PG ID を計算します。

  1. クライアントはプール ID とオブジェクト ID を入力します。たとえば、pool = liverpool および object-id = john です。
  2. CRUSH はオブジェクト ID を取得し、ハッシュ化します。
  3. CRUSH は、PG 数のハッシュモジュロを計算し、PG ID を取得します。たとえば 58 です。
  4. CRUSH は、PG ID に対応するプライマリー OSD を計算します。
  5. クライアントは、プール名を指定するプール ID を取得します。たとえば、プール「liverpool」はプール番号 4 です。
  6. クライアントはプール ID を PG ID の先頭に追加します。たとえば 4.58 です。
  7. クライアントは、Acting Set のプライマリー OSD と直接通信して、書き込み、読み取り、または削除などのオブジェクト操作を実行します。

Ceph Storage クラスターのトポロジーおよび状態は、セッション時に比較的安定しています。librados を介して Ceph クライアントにオブジェクトの場所を計算する権限を付与することは、クライアントが読み取り/書き込み操作ごとにチャットセッションを介してストレージクラスターにクエリーを実行することを要求するよりもはるかに高速です。CRUSH アルゴリズムにより、クライアントはオブジェクトが 保存される 場所を計算でき、クライアントが有効なセットのプライマリー OSD に直接アクセスできる ようにし、オブジェクト内のデータを保存または取得できるようにします。エクサバイトスケールのクラスターには数千の OSD があるため、クライアントと Ceph OSD 間のサブスクリプションにおけるネットワークは大きな問題ではありません。クラスターの状態が変更すると、クライアントは Ceph monitor からクラスターマッピングに更新をリクエストできます。

Red Hat Ceph Storage 2 以前のリリースでは、クラスターマップのサイズが大きすぎると、非常に大規模なクラスターのデーモンによりパフォーマンスが遅くなる可能性があります。たとえば、OSD が 10000 個あるクラスターには OSD あたり 100 PG が含まれる可能性があるため、データを効率的に分散するために約 1 MB の PG が発生する可能性があります。​また、クラスターマップには多数のエポックがあります。そのため、デーモンは、非常に大きなクラスターを持つ Red Hat Ceph Storage 2 の CPU および RAM をさらに使用します。Red Hat Ceph Storage 3 以降のリリースでは、デーモンは、Red Hat Ceph Storage 2 以前のリリースのようにクラスターの現在の状態を受け取ります。ただし、Ceph Manager (ceph-mgr) デーモンは PG のクエリーを処理するようになり、大規模でパフォーマンスが大幅に改善されました。

重要

Red Hat は、数千もの OSD を持つ非常に大きなクラスターには、Red Hat Ceph Storage 3 以降リリースを使用することを推奨します。

2.7. Ceph のレプリケーション

Ceph OSD は Ceph クライアントと同様に、Ceph モニターに問い合わせて、クラスターマップの最新コピーを取得できます。Ceph OSD も CRUSH アルゴリズムを使用しますが、これを使用してオブジェクトのレプリカを保存する場所を算出します。通常の書き込みシナリオでは、Ceph クライアントは CRUSH アルゴリズムを使用して、オブジェクトの Acting Set で配置グループ ID とプライマリー OSD を計算します。クライアントがプライマリー OSD にオブジェクトを書き込む際に、プライマリー OSD は保存する必要のあるレプリカの数を検出します。値は osd_pool_default_size 設定にあります。次に、プライマリー OSD はオブジェクト ID、プール名、およびクラスターマップを取得し、CRUSH アルゴリズムを使用して、有効なセットのセカンダリー OSD の ID を計算します。プライマリー OSD はオブジェクトをセカンダリー OSD に書き込みます。プライマリー OSD がセカンダリー OSD から確認応答を受信し、プライマリー OSD 自体がその書き込み操作を完了すると、Ceph クライアントへの書き込み操作が正常に承認されます。

レプリケートされた IO

Ceph クライアントの代わりにデータのレプリケーションを実行する機能により、Ceph OSD デーモンは Ceph クライアントをそこから再命名し、高可用性とデータの安全性を確保します。

注記

通常、プライマリー OSD とセカンダリー OSD は、別の障害ドメインになるように設定されます。CRUSH は、障害ドメインを考慮してセカンダリー OSD の ID を計算します。

データのコピー

レプリケートされたストレージプールでは、動作が低下するために、Ceph ではオブジェクトのコピーが複数必要になります。理想的には、Ceph ストレージクラスターを使用すると、有効なセットの OSD のいずれかが失敗した場合でも、クライアントがデータの読み取りおよび書き込みが可能です。このため、Ceph は書き込み操作に対して最低でも 2 つのコピーでオブジェクトのコピーを作成します。2 つの OSD に障害が発生しても、Ceph はデータは保存されます。ただし、書き込み操作を中断します。

消去されたプールでは、Ceph は複数の OSD にオブジェクトのチャンクを保存する必要があります。これにより、パフォーマンスが低下した状態で動作できるようにする必要があります。レプリケートされたプールと同様に、イレイジャーコーディングされたプールにより、Ceph クライアントはパフォーマンスが低下した状態での読み取りおよび書き込みが可能です。

重要

Red Hat は、k および m に以下の jerasure コーディング値をサポートしています。

  • k=8 m=3
  • k=8 m=4
  • k=4 m=2

2.8. Ceph イレイジャーコーディング

Ceph は多くのイレイジャーコードアルゴリズムの 1 つを読み込むことができます。Reed-Solomon アルゴリズムが最も早く一般的に使用されるものになります。イレイジャーコードは、実際に FEC(forward error Correction)コードです。EFC コードは、K チャンクのメッセージを N チャンクの「コード単語」と呼ばれる長いメッセージに変換します。これにより、Ceph は N チャンクのサブセットから元のメッセージを復元できます。

具体的には、変数 K が元のデータチャンク量である N = N = K+M です。変数 M は、余分または冗長なチャンクを表し、イレイジャーコードアルゴリズムが障害から保護します。変数 N は、イレイジャーコーディングプロセス後に作成されたチャンクの合計数です。M の値は N-K です。これは、アルゴリズムが K の元のデータチャンクから N-K 冗長チャンクを計算することを意味します。このアプローチにより、Ceph は元のすべてのデータにアクセスできることを保証します。システムが任意の N-K の障害に対して回復性があります。たとえば、16 の N 設定のうち 10 K、またはイレイジャーコーディング 10/16 の場合、イレイジャーコードアルゴリズムは 10 ベースチャンク K に 6 つの追加チャンクを追加します。たとえば、M = K-N または 16-10 = 6 の設定では、Ceph は 16 チャンク N を 16 OSD に分散します。元のファイルは、6 個の OSD が失敗しても 10 回検証された N チャンクから再構築できます。これにより、Red Hat Ceph Storage クラスターではデータが失われないようにするため、非常に高いレベルのフォールトトレランスを確保します。

レプリケートされたプールと同様に、イレイジャーコーディングされたプールでは、up セットのプライマリー OSD がすべて書き込み操作を受け取ります。レプリケートされたプールでは、Ceph はセット内のセカンダリー OSD の配置グループ内の各オブジェクトの詳細なコピーを作成します。イレイジャーコーディングでは、プロセスは若干異なります。コード化されたプールは各オブジェクトを K+M チャンクとして格納します。これは K データチャンクと M コーディングチャンクに分割されます。プールには K+M のサイズが設定され、これにより Ceph が各チャンクを有効なセットの OSD に保管することができます。Ceph は、チャンクの範囲をオブジェクトの属性として格納します。プライマリー OSD はペイロードを K+M チャンクにエンコードし、それらを他の OSD に送信します。また、プライマリー OSD は配置グループのログの権威バージョンを維持します。

たとえば、通常の設定では、システム管理者は 5 つの OSD を使用してイレイジャーコーディングされたプールを作成し、2 つの OSD が失われる状態を維持します。つまり、(K+M = 5) であり、(M = 2) になります。

Ceph が、ABCDEFGHI を含むオブジェクト NYAN をプールに書き込むと、イレイジャーエンコーディングアルゴリズムは、コンテンツを 3 つに分割するだけで、コンテンツを 3 つのデータチャンクに分割します (* ABC, * DEF * GHI)。コンテンツの長さが K の倍数でない場合は、アルゴリズムによりコンテンツをパディングします。この関数は、2 つのコーディングチャンクも作成します。4 つ目は YXY で、5 つ目は GQC が付きます。Ceph は、有効なセット内の OSD 上にそれぞれのチャンクを保存します。ここで、NYAN の名前を持つオブジェクトにチャンクが保管されますが、異なる OSD にあります。アルゴリズムは、名前に加えて、チャンクをオブジェクト shard_t の属性として作成した順番を保持する必要があります。たとえば、チャンク 1 には ABC が含まれ、Ceph はこれを OSD5 に格納されます。一方、チャンク 4 には YXY が含まれ、OSD3 に格納されます。

イレイジャーコード IO

リカバリーのシナリオでは、クライアントはチャンク 1 から 5 を読み取ることで、イレイジャーコーディングされたプールからオブジェクト NYAN を読み込もうとします。OSD はアルゴリズムに 2 と 5 がないことを通知します。これらの不足しているチャンクは 'erasures' と呼ばれます。たとえば、OSD4 が除外されているため、プライマリー OSD はチャンク 5 を読み取ることができませんでした。また、OSD2 は最も遅く、そのチャンクを考慮していなかったため、チャンク 2 を読み取ることができませんでした。ただし、アルゴリズムにチャンクが 3 つあると、すぐに 3 つのチャンク (ABC を含むチャンク 1、GHI を含むチャンク 3、YXY を含むチャンク 4) を読み取ります。次に、オブジェクト ABCDEFGHI の元のコンテンツと、GQC を含むチャンク 5 の元のコンテンツを再構築します。

データをチャンクに分割することは、オブジェクトの配置とは異なります。CRUSH ルールセットと、erasure-coded プールプロファイルは、OSD 上のチャンクの配置を決定します。たとえば、イレイジャーコードプロファイルで Locally Repairable Code (lrc) プラグインを使用すると、追加のチャンクが作成され、回復に必要な OSD が少なくなります。たとえば、lrc プロファイル構成 K=4 M=2 L=3 では、アルゴリズムは、jerasure プラグインと同じように 6 つのチャンク (K+M) を作成しますが、局所性の値 (L=3) は、ローカルにさらに 2 つのアルゴリズムを作成する必要があります。アルゴリズムは、(K+M)/L などの追加チャンクを作成します。チャンク 0 を含む OSD が失敗すると、チャンク 1、2 および最初のローカルチャンクを使用してこのチャンクを復元できます。この場合、アルゴリズムでは 5 ではなく、リカバリーに 3 つのチャンクのみが必要になります。

注記

イレイジャーコーディングされたプールを使用すると、オブジェクトマップが無効になります。

関連情報

2.9. Ceph ObjectStore

Objectstore は、OSD の raw ブロックデバイスに低レベルのインターフェースを提供します。クライアントがデータの読み取りまたは書き込みを行うと、ObjectStore インターフェースと対話します。Ceph 書き込み操作は、基本的に ACID トランザクションです。つまり、原子性一貫性分離、および 耐久性 を提供します。ObjectStore は、トランザクション原子性 を提供するために、オールオアナッシングになるようにします。ObjectStore は、オブジェクトセマンティクスも処理します。ストレージクラスターに保存されているオブジェクトには、一意の識別子、オブジェクトデータ、メタデータがあります。したがって、ObjectStore は Ceph オブジェクトセマンティクスが正しいことを確認して 整合性 を提供します。ObjectStore は、書き込み操作で Sequencer を呼び出して ACID トランザクションの 分離 部分も提供し、Ceph 書き込み操作が順次発生するようにします。対照的に、OSD のレプリケーションまたはイレイジャーコーディング機能は、ACID トランザクションの 耐久性 コンポーネントを提供します。ObjectStore は、ストレージメディアへの低レベルのインターフェースであるため、パフォーマンスの統計も提供します。

Ceph は、データを保管するための具体的な方法を実装します。

  • FileStore: オブジェクトデータを保存するファイルシステムを使用した実稼働グレードの実装。
  • BlueStore: オブジェクトデータを保存するために raw ブロックデバイスを使用した実稼働グレードの実装。
  • Memstore: RAM で読み取り/書き込み操作を直接テストするための開発者の実装。
  • K/V Store: Ceph がキー/値データベースを使用する内部実装。

管理者は通常 BlueStore にのみ対応するため、以下のセクションではこれらの実装についてのみ詳しく説明します。

2.10. Ceph BlueStore

BlueStore は Ceph の次世代ストレージ実装です。ストレージデバイスの市場にはソリッドステートドライブ、SSD、PCI Express または NVMe 経由の不揮発性メモリーが含まれるようになったため、Ceph での使用により、FileStore ストレージの実装の制限の一部が示されます。FileStore には、SSD ストレージおよび NVMe ストレージを容易にするために多くの改良がありますが、他の制限は残ります。配置グループの増加は計算的に高価であり、二重書き込みペナルティーはそのまま残ります。FileStore はブロックデバイスのファイルシステムと対話し、BlueStore はその間接状態をなくし、オブジェクトストレージ用に raw ブロックデバイスを直接使用します。BlueStore は、k/v データベース用に小規模なパーティションで非常に軽量な BlueFS ファイルシステムを使用します。BlueStore では、配置グループを表すディレクトリー (オブジェクトを表すファイルおよびメタデータを表すファイルの) の XATTR がなくなります。BlueStore では FileStore の 2 回の書き込みペナルティーが解消されるため、ほとんどのワークロードで BlueStore を使用する場合に、書き込み操作はほぼ 2 倍速くなります。

BlueStore は以下のようにデータを保存します。

  • オブジェクトデータ: BlueStore では、Ceph はオブジェクトを raw ブロックデバイスに直接ブロックとして保存します。オブジェクトデータを格納する raw ブロックデバイスの一部には、ファイルシステムが含まれません。ファイルシステムが省略されるため、間接のレイヤーが削除されるため、パフォーマンスを向上させます。ただし、BlueStore のパフォーマンスのほとんどは、ブロックデータベースと write-ahead ログにより向上されます。
  • ブロックデータベース: BlueStore では、整合性 を保証するために、ブロックデータベースがオブジェクトのセマンティクスを処理します。オブジェクトの一意の識別子は、ブロックデータベースのキーです。ブロックデータベースの値は、保存されたオブジェクトデータ、オブジェクトの配置グループ、およびオブジェクトのメタデータを参照する一連のブロックアドレスで構成されます。ブロックデータベースは、オブジェクトデータを格納する同じ raw ブロックデバイス上の BlueFS パーティションに存在する場合もあれば、別のブロックデバイスに存在する場合もあります。通常、ハードディスクドライブがプライマリーリブロックデバイスであり、SSD または NVMe によってパフォーマンスが向上します。ブロックデータベースでは、FileStore に対する多くの改善が行われています。つまり、BlueStore のキー/値のセマンティクスはファイルシステム XATTR の制限に悪い影響を与えません。BlueStore は、FileStore のように、ファイルをディレクトリーから別のディレクトリーに移動するオーバーヘッドなしに、ブロックデータベース内の他の配置グループにオブジェクトをすぐに割り当てることができます。BlueStore には新機能も導入されています。ブロックデータベースは、保存されたオブジェクトデータとそのメタデータのチェックサムを保存できるため、読み取りごとに完全なデータチェックサム操作が可能になります。これは、ビットローテーションの検出に定期的にスクラビングするよりも効率的です。BlueStore はオブジェクトを圧縮でき、ブロックデータベースはオブジェクトの圧縮に使用するアルゴリズムを格納できます。読み取り操作が圧縮解除に適したアルゴリズムを選択するようにします。
  • 先行書き込みログ: BlueStore では、FileStore のジャーナリング機能と同様に、先行書き込みログによって 原子性 が保証されます。FileStore と同様に、BlueStore は各トランザクションのすべての要素をログに記録します。ただし、BlueStore の先行書き込みログまたは WAL は、この機能を同時に実行できるため、FileStore の二重書き込みペナルティーがなくなります。その結果、BlueStore は、ほとんどのワークロードの書き込み操作で FileStore のほぼ2倍の速度になります。BlueStore は、オブジェクトデータの格納のために同じデバイスに WAL をデプロイするか、プライマリーブロックデバイスがハードドライブで、SSD または NVMe のパフォーマンスを向上させる場合に、別のデバイスに WAL をデプロイすることもできます。
注記

個別のデバイスがプライマリーストレージデバイスよりも高速である場合に、ブロックデバイスにブロックデータベースまたは write-ahead ログのみを保存することが役立ちます。たとえば、SSD デバイスおよび NVMe デバイスは通常 HDD よりも高速です。ブロックデータベースと WAL を別のデバイスに配置すると、ワークロードの相違点によりパフォーマンスが向上する可能性があります。

2.11. Ceph の自己管理操作

Ceph クラスターは、多くの自己監視および管理操作を自動的に実行します。たとえば、Ceph OSD はクラスターの正常性を確認し、Ceph モニターに戻すことができます。CRUSH を使用してオブジェクトを配置グループおよび配置グループに割り当てると、Ceph OSD は CRUSH アルゴリズムを使用してクラスターをリバランスしたり、OSD の障害からのリカバリーを動的に実行することができます。

2.12. Ceph heartbeat

Ceph OSD はクラスターに参加し、それらのステータスで Ceph Monitor に報告します。最下位レベルでは、Ceph OSD ステータスは up または down で、実行中で Ceph クライアント要求を処理できるかどうかを反映しています。Ceph OSD が down で、Ceph Storage クラスターの in (内) にある場合、このステータスは、Ceph OSD の失敗を示す可能性があります。Ceph OSD が実行されていない場合など、クラッシュします。Ceph OSD は、Ceph Monitor に down していることを通知できません。Ceph Monitor は、Ceph OSD デーモンを定期的に ping して、これが稼働していることを確認することができます。ただし、ハートビートにより、Ceph OSD は、隣接 OSD が down しているかどうかを判断し、クラスターマップを更新して、Ceph モニターに報告することができます。つまり、Ceph Monitors は軽量な重みプロセスを維持します。

2.13. Ceph ピアリング

Ceph は、複数の OSD にある配置グループのコピーを保存します。配置グループの各コピーには、ステータスがあります。これらの OSD は「ピア」または相互にチェックし、PG の各コピーのステータスに同意していることを確認します。通常、ピアリングの問題は自己解決します。

注記

Ceph モニターが配置グループを保存する OSD の状態に基づいて合意した場合、配置グループのコンテンツが最新の状態にあるわけではありません。

Ceph が配置グループを有効な OSD セットに保存する場合は、それらを プライマリーセカンダリー などとして参照します。通常、プライマリー有効なセット の最初の OSD になります。配置グループの最初のコピーを保存する プライマリー は、その配置グループのピアプロセスを調整する役割を果たします。プライマリー は、指定した配置グループのオブジェクトに対してクライアントが開始する書き込みを許可する 唯一 の OSD で、プライマリー として機能します。

有効なセット は、配置グループを格納する一連の OSD です。有効なセット は、現在配置グループを担当している Ceph OSD デーモンや、あるエポックの時点で特定の配置グループを担当していた Ceph OSD デーモンを指す場合があります。

有効なセット に含まれる Ceph OSD デーモンは常に up であるとは限りません。有効なセット の OSD が up であると、これは Up Set の一部になります。OSD に障害が発生した場合に Ceph は PG を他の Ceph OSD に再マッピングできるため、Up Set は重要な違いです。

注記

osd.25osd.32、および osd.61 を含む PG の Acting Set では、最初の OSD osd.25プライマリー です。OSD が失敗すると、セカンダリー では、osd.32プライマリー になり、Ceph は Up Set から osd.25 を削除します。

2.14. Ceph のリバランスとリカバリー

管理者が Ceph OSD を Ceph Storage クラスターに追加すると、Ceph はクラスターマッピングを更新します。このクラスターマップへの変更は、変更されたクラスターマップが CRUSH 計算の入力を変更するため、オブジェクトの配置も変更します。CRUSH はデータを均等に配置しますが、擬似は無作為に配置されます。したがって、管理者が新規 OSD を追加すると、わずかなデータのみが移動します。データ量は通常、クラスター内のデータの合計量で分割された新規 OSD の数です。たとえば、50 個の OSD があるクラスターでは、OSD を追加すると、データの 1/50 または 2% が移動する可能性があります。

以下の図は、一部の PG を、図の既存の OSD、OSD 1、および 2 から新しい OSD、OSD 3 に移行するリバランスプロセスを示しています。をリバランスしても、CRUSH は安定しています。配置グループの多くは元の設定に残り、各 OSD は追加された容量を取得するため、クラスターのリバランス後に新しい OSD に負荷が急増しません。

リバランスおよびリカバリー

2.15. Ceph データの整合性

Ceph は、データの整合性を維持する一環で、不良なディスクセクターおよびビットローテーションに対して保護するメカニズムを多数提供します。

  • スクラブ: Ceph OSD デーモンは配置グループ内のオブジェクトをスクラブすることができます。つまり、Ceph OSD デーモンは、1 つの配置グループのオブジェクトメタデータを、他の OSD に保存されている配置グループ内のレプリカと比較できます。スクラブは、通常は毎日行いますが、バグまたはストレージエラーをキャッチします。また、Ceph OSD デーモンは、オブジェクトのビット単位のデータを比較することで、より深いスクラビングを実行します。ディープスクラブは、通常は毎週行いますが、軽量スクラブでは見られなかったドライブ上の不良セクターを見つけます。
  • CRC チェック: BlueStore を使用する場合の Red Hat Ceph Storage 4 では、Ceph は書き込み操作で CRC (cyclical redundancy check) を実行することにより、データの整合性を確保できます。次に、CRC 値をブロックデータベースに保存します。読み取り操作では、Ceph はブロックデータベースから CRC 値を取得し、取得したデータの生成された CRC と比較し、データの整合性を即時に確認することができます。

2.16. Ceph の高可用性

CRUSH アルゴリズムにより有効化された高いスケーラビリティーに加え、Ceph は高可用性も維持する必要があります。つまり、Ceph クライアントは、クラスターの状態が低下したり、モニターが失敗した場合でもデータの読み取りおよび書き込みが可能でなければなりません。

2.17. Ceph Monitor のクラスタリング

Ceph クライアントがデータの読み取りまたは書き込みを可能にする前に、Ceph Monitor に連絡して、クラスターマップの最新コピーを取得する必要があります。Red Hat Ceph Storage クラスターは単一のモニターで操作することができますが、これにより単一障害点が発生します。つまり、モニターがダウンすると、Ceph クライアントはデータの読み取りまたは書き込みができません。

信頼性および耐障害性を追加するために、Ceph はモニターのクラスターをサポートします。Ceph Monitor のクラスターでは、レイテンシーやその他の障害により、1 つ以上のモニターがクラスターの現在の状態のままになる可能性があります。このため、Ceph はストレージクラスターの状態に関するさまざまなモニターインスタンス間で合意を行う必要があります。Ceph は常に大半のモニターと Paxos アルゴリズムを使用して、ストレージクラスターの現在の状態についてのモニター間で合意を確立します。Ceph Monitors ノードには、クロックのドリフトを防ぐために NTP が必要です。

ストレージ管理者は通常、異常な数のモニターを持つ Ceph をデプロイするため、大多数のモニターが効率的です。たとえば、過半数は、1、2:3、3:5、4:6 などになります。

第3章 Ceph クライアントのコンポーネント

Ceph クライアントは、データストレージインターフェースをどのように提示するかによって、それぞれ異なります。Ceph ブロックデバイスは、物理ストレージドライブと同様にマウントされるブロックストレージを提示します。Ceph ゲートウェイは、独自のユーザー管理を持つ S3 準拠の RESTful インターフェースと Swift 準拠の RESTful インターフェースで、オブジェクトストレージサービスを提供します。ただし、すべての Ceph クライアントは Reliable Autonomic Distributed Object Store(RADOS)プロトコルを使用して Red Hat Ceph Storage クラスターと対話します。

基本的なニーズは、すべて同じです。

  • Ceph 設定ファイルおよび Ceph monitor アドレス
  • プール名。
  • ユーザー名および秘密鍵へのパス。

Ceph クライアントは、object-watch-notify や striping など、いくつかの同様のパケットを順守する傾向があります。以下のセクションでは、Ceph クライアントで使用される RADOS、librados、および一般的なパターンについて少し説明します。

3.1. 前提条件

  • 分散ストレージシステムの基本を理解する。

3.2. Ceph クライアントネイティブプロトコル

最新のアプリケーションには、非同期通信機能を備えた単純なオブジェクトストレージインターフェースが必要です。Ceph Storage Cluster は、非同期通信機能を備えたシンプルなオブジェクトストレージインターフェースを提供します。インターフェースは、クラスター全体でオブジェクトに直接並行して直接アクセスします。

  • プール操作
  • スナップショット
  • オブジェクトの読み取り/書き込み

    • 作成または削除
    • オブジェクト全体またはバイト範囲
    • append または Truncate
  • XATTR の作成/設定/取得/削除
  • キー/値のペアの作成/設定/取得/削除
  • 複合操作とデュアルパッケージのセマンティクス

3.3. Ceph クライアントオブジェクトの監視および通知

Ceph クライアントは、オブジェクトに永続的に関心をもたせることができ、セッションをプライマリー OSD 上に開くことができます。クライアントは通知メッセージとペイロードをすべてのウォッチャーに送信し、監視者が通知を受信すると通知を受け取ることができます。これにより、クライアントが任意のオブジェクトを同期/通信チャンネルとして使用できるようになります。

Ceph アーキテクチャーガイド 378927 1017 09

3.4. Ceph クライアントの 必須の排他的ロック

必須の排他的ロックは、複数のマウントが有効な場合に RBD を単一のクライアントにロックする機能です。これにより、複数のマウントされたクライアントが同じオブジェクトへの書き込みを試みる際に書き込みの競合状態に対応するのに役立ちます。この機能は、前セクションで説明した object-watch-notify で構築されます。そのため、あるクライアントが最初にオブジェクトに排他ロックを確立した場合、別のマウントされたクライアントは、書き込み前にピアがオブジェクトのロックを置くかどうかを確認します。

この機能を有効にすると、1 つのクライアントのみが一度に RBD デバイスを変更することができます。特に、スナップショットの作成/削除 などの操作中に内部 RBD 構造を変更する場合などです。また、障害のあるクライアントの保護も行います。たとえば、仮想マシンが応答しておらず、同じディスクでコピーを開始すると、最初のディスクが Ceph でブラックリストに登録され、新しいディスクが破損することができません。

必須の排他的ロックは、デフォルトでは有効になっていません。イメージの作成時に、--image-feature パラメーターを使用して明示的に有効にする必要があります。

[root@mon ~]# rbd create --size 102400 mypool/myimage --image-feature 5

ここで、数値の 5 は、14 の合計であり、1 は階層化サポートを有効にし、4 は排他的ロックサポートを有効にします。そのため、上記のコマンドは 100 GB の rbd イメージを作成し、階層化および排他ロックを有効にします。

必須の排他的ロックも オブジェクトマップ の前提条件となります。排他的ロックのサポートを有効にしないと、オブジェクトマップのサポートを有効にできません。

必須の排他的ロックは、ミラーリングの主な作業も行います。

3.5. Ceph クライアントオブジェクトマップ

オブジェクトマップは、クライアントが rbd イメージに書き込む際にバッキング RADOS オブジェクトの存在を追跡する機能です。書き込みが発生すると、書き込みはサポートする RADOS オブジェクト内のオフセットに変換されます。オブジェクトマップ機能が有効になると、これらの RADOS オブジェクトが存在することが追跡されます。したがって、オブジェクトが実際に存在しているかどうかを確認することができます。オブジェクトマップは librbd クライアントにインメモリー内に保持されるため、OSD が存在しないことを認識しているオブジェクトのクエリーを避けることができます。つまり、オブジェクトマップは実際に存在するオブジェクトのインデックスです。

オブジェクトマップは、以下のような特定の操作に有益です。

  • サイズ変更
  • エクスポート
  • コピー
  • フラット化
  • 削除
  • 読み取り

縮小サイズ変更操作は、末尾のオブジェクトが削除されると部分的な削除に似ています。

エクスポート操作は、RADOS からどのオブジェクトを要求するかを認識します。

コピー操作は、どのオブジェクトが存在し、コピーする必要があるかを認識します。可能なオブジェクトは、数百、数千にも及ぼす必要はありません。

flatten 操作は、クローンに対するすべての親オブジェクトのコピーアップを実行し、クローンを親(例: 子クローンから親スナップショットへの参照)から切り離せるようにします。したがって、考えられるすべてのオブジェクトではなく、コピーアップは存在するオブジェクトに対してのみ行われます。

delete 操作は、イメージに存在するオブジェクトのみを削除します。

読み取り操作では、認識しているオブジェクトの読み取りはスキップされます。

したがって、サイズ変更、縮小のみ、エクスポート、コピー、フラット化、削除などの操作では、影響のあるすべての RADOS オブジェクト(存在する場合)に対して操作を発行する必要があります。オブジェクトマップが有効な場合は、そのオブジェクトが存在しない場合は、この操作を発行する必要はありません。

たとえば、1 TB のスパース RBD イメージがある場合、数百および数千のバッキング RADOS オブジェクトを使用できます。オブジェクトマップを有効にしない削除操作では、イメージの潜在的な オブジェクトごとに remove object 操作を実行する必要があります。ただし、オブジェクトマップが有効な場合は、存在するオブジェクトの remove object 操作のみを実行する必要があります。

オブジェクトマップは、実際のオブジェクトがなく、親からオブジェクトを取得するクローンに対して有用です。クローンイメージがある場合、クローンにはオブジェクトがなく、すべての読み込みが親にリダイレクトされます。そのため、オブジェクトマップはオブジェクトマップなしで読み取りを向上させることができます。まずは、クローンの OSD に読み取り操作を発行する必要があります。失敗すると、オブジェクトマップが有効な状態で別の読み取りが親に発行されます。認識しているオブジェクトの読み取りはスキップされます。

オブジェクトマップは、デフォルトでは有効になっていません。イメージの作成時に、--image-features パラメーターを使用して明示的に有効にする必要があります。また、必須の排他的ロックオブジェクトマップ の前提条件となります。排他的ロックのサポートを有効にしないと、オブジェクトマップのサポートを有効にできません。イメージの作成時にオブジェクトマップのサポートを有効にするには、以下を実行します。

[root@mon ~]# rbd -p mypool create myimage --size 102400 --image-features 13

ここで、数値の 13 は、148 の合計であり、1 は階層化サポートを有効にし、4 は排他的ロックサポートを有効にして、8 は、オブジェクトマップサポートを有効にします。そのため、上記のコマンドは 100 GB の rbd イメージを作成し、階層化、排他的ロック、およびオブジェクトマップを有効にします。

3.6. Ceph クライアントデータのストライピング

ストレージデバイスにはスループットの制限があり、パフォーマンスとスケーラビリティーに影響します。したがって、多くの場合、ストレージシステムはストライピングに対応します。複数のストレージデバイスに連続する情報の保存 -スループットとパフォーマンスが向上します。データストライピングの最も一般的な形式は、RAID から取得します。Ceph のストライピングに最もよく似た RAID タイプは RAID 0 または「ストライプ化ボリューム」です。 Ceph のストライピングは、RAID 0 のストライピングのスループット、n 方向の RAID ミラーリングの信頼性、および迅速なリカバリーを提供します。

Ceph は、Ceph Block Device、Ceph Filesystem、Ceph Object Storage の 3 種類のクライアントを提供します。Ceph Client は、これが提供する表現形式(ブロックデバイスイメージ、RESTful オブジェクト、CephFS ファイルシステムディレクトリーなど)から Ceph Storage クラスターのストレージ用のオブジェクトに変換します。

ヒント

Ceph Storage クラスターのオブジェクトストアはストライプ化されません。Ceph Object Storage、Ceph Block Device、および Ceph Filesystem は、複数の Ceph Storage Cluster オブジェクトにデータをストライプ化します。librados を使用して Ceph Storage クラスターに直接書き込む Ceph クライアントは、これらの利点を得るためにストライピングを実施し、並行 I/O を実行する必要があります。

最も単純な Ceph ストライピングフォーマットでは、ストライプ数 1 オブジェクトが関係します。Ceph Clients は、オブジェクトが最大容量になるまで Ceph Storage Cluster オブジェクトにストライプを書き込み、データの追加ストライプ用に別のオブジェクトを作成します。小規模なブロックデバイスイメージ(S3 または Swift オブジェクト)には、最も単純な形式のストライピングで十分です。ただし、この単純なフォームでは、Ceph の配置グループ間でデータを分散する機能を最大限に活用することはないため、パフォーマンスが大幅に向上しません。以下の図は、ストライピングの最も簡単な形式を示しています。

Ceph アーキテクチャーガイド 378927 1017 10

大規模なイメージサイズ、大きい S3、または Swift オブジェクト(ビデオなど)が予想される場合は、オブジェクトセット内の複数のオブジェクトにクライアントデータをストライプ化することで、読み取り/書き込みのパフォーマンスが大幅に向上する可能性があります。クライアントがストライプユニットを対応するオブジェクトに並行して書き込むと、大量の書き込みパフォーマンスが発生します。オブジェクトは異なる配置グループにマップされ、さらに異なる OSD にマップされるため、各書き込みは最大書き込み速度で並行して実行されます。単一のディスクへの書き込みは、ヘッドの動き、たとえばシークあたり 6 ミリ秒、およびその 1 つのデバイスの帯域幅 (たとえば 100MB/秒) によって制限されます。Ceph は、異なる配置グループや OSD にマッピングする複数のオブジェクトに書き込みを分散することで、ドライブごとのシーク数を減らし、複数のドライブのスループットを組み合わせて、書き込みまたは読み取りの速度を大幅に向上させることができます。

注記

ストライピングは、オブジェクトのレプリカとは独立しています。CRUSH は OSD 全体にオブジェクトを複製するため、ストライプは自動的に複製されます。

以下の図では、クライアントデータは、4 つのオブジェクトで構成されるオブジェクトセット (以下の図の object set 1) でストライプ化されます。最初のストライプユニットは、object 0stripe unit 0 です。4 番目のストライプユニットは、object 3stripe unit 3 です。4 番目のストライプを記述した後、クライアントはオブジェクトセットが満杯かどうかを判断します。オブジェクトセットが満杯でない場合は、クライアントが最初のオブジェクトにストライプを書き始め、以下の図の object 0 を参照してください。オブジェクトセットが満杯になると、クライアントは新しいオブジェクトセットを作成し、以下の図の object set 2 を参照し、ストライプユニットが 16 の状態で最初のストライプへの書き込みを開始します。新しいオブジェクトセットの最初のオブジェクトセットでは、以下の図の object 4 を参照してください。

Ceph アーキテクチャーガイド 378927 1017 11

3 つの重要な変数は、Ceph がデータのストライプ化方法を決定します。

  • オブジェクトサイズ: Ceph Storage クラスターのオブジェクトには、設定可能な最大サイズ (2 MB または 4 MB) があります。オブジェクトサイズは、多くのストライプユニットに対応するのに十分な大きさで、ストライプユニットの倍数でなければなりません。重要: Red Hat は、安全な最大値 16 MB を推奨します。
  • ストライプの幅: ストライプは、64 KB などの設定可能なユニットサイズがあります。Ceph Client は、オブジェクトに書き込みを行うデータを、最後のストライプユニットを除き、同じサイズのストライプ単位に分割します。オブジェクトに多くのストライプ単位を含めることができるように、ストライプ幅はオブジェクトサイズの一部になります。
  • ストライプ数: Ceph クライアントは、ストライプ数で決定される一連のオブジェクトに一連のストライプユニットを書き込みます。一連のオブジェクトはオブジェクトセットと呼ばれます。Ceph Client がオブジェクトセットの最後のオブジェクトに書き込まれると、オブジェクトセットの最初のオブジェクトに戻ります。
重要

クラスターを実稼働環境に配置する前に、ストライピング設定のパフォーマンスをテストします。CANNOT は、データをストライプ化してオブジェクトに書き込むと、これらのストライピングパラメーターを変更します。

Ceph Client がストライプユニットにデータを取り除き、ストライプユニットをオブジェクトにマッピングすると、Ceph の CRUSH アルゴリズムはオブジェクトを配置グループにマッピングし、オブジェクトがストレージディスクにファイルとして保管される前に Ceph OSD デーモンに配置グループを追加します。

注記

クライアントは単一のプールに書き込むため、オブジェクトにストライプ化されたデータはすべて、同じプール内の配置グループにマップされます。そのため、同じ CRUSH マップと同じアクセス制御を使用します。

第4章 Ceph のオンディスク暗号化

LUKS ディスク暗号化およびその利点

Linux Unified Key Setup-on-disk-format(LUKS)メソッドを使用して、Linux システムのパーティションを暗号化できます。LUKS は、ブロックデバイス全体を暗号化するため、脱着可能なストレージメディアやノート PC のディスクドライブといった、モバイルデバイスのコンテンツを保護するのに適しています。

ceph-ansible ユーティリティーを使用して、暗号化された OSD ノードを作成して、保存したデータを保護します。詳細は、『Red Hat Ceph Storage 4 インストールガイド』の「Red Hat Ceph Storage クラスターのインストール」セクションを参照してください。

LUKS の詳細は、Red Hat Enterprise Linux 7 の『セキュリティーガイド』の「LUKS の概要」セクションを参照してください。

ceph-ansible で暗号化したパーティションの作成方法

OSD のインストール時に、ceph-ansible は暗号化されたパーティションを作成する ceph-disk ユーティリティーを呼び出します。

ceph-disk ユーティリティーは、データ (ceph data) パーティションおよびジャーナル (ceph journal) パーティションに加えて、小規模な ceph lockbox パーティションを作成します。また、ceph-disk は、cephx client.osd-lockbox を作成します。ceph lockbox パーティションには、client.osd-lockbox が、暗号化された ceph data および ceph journal パーティションを復号化するのに必要な LUKS 秘密鍵を取得するのに使用する鍵ファイルが含まれています。

次に、ceph-diskcryptsetup ユーティリティーを呼び出して、ceph data パーティションおよび ceph journal パーティション用に 2 つの dm-crypt デバイスを作成します。dm-crypt デバイスは、ceph data および ceph journal GUID を識別子として使用します。

重要

ceph-disk コマンドは、Red Hat Ceph Storage 4 では非推奨になりました。ceph-volume コマンドは、コマンドラインインターフェースから OSD をデプロイするのに推奨される方法です。現在、ceph-volume コマンドは lvm プラグインのみをサポートしています。

ceph-volume コマンドの使用に関する詳細は、『Red Hat Ceph Storage 管理ガイド』を参照してください。

ceph-ansible による LUKS 鍵の処理方法

ceph-ansible ユーティリティーは、LUKS 秘密鍵を Ceph Monitor の key-value ストアに保存します。各 OSD には、OSD データとジャーナルを含む dm-crypt デバイスを復号化する独自のキーがあります。暗号化したパーティションは、システムの起動時に自動的に復号化されます。

第5章 Ceph on-wire 暗号化

Red Hat Ceph Storage 4 以降では、バージョン 2 プロトコルの導入により、ネットワーク経由ですべての Ceph トラフィックの暗号化を有効にすることができます。メッセンジャー v2 の secure モード設定は、Ceph デーモンと Ceph クライアント間の通信を暗号化し、エンドツーエンドの暗号化を提供します。

Ceph の有線プロトコルの 2 つ目のバージョンである msgr2 には、以下の新機能が含まれています。

  • ネットワークを通過するすべてのデータを暗号化するセキュアなモード。
  • 認証ペイロードのカプセル化の向上。
  • アドバタイズメントおよびネゴシエーションの改善。

Ceph デーモンは複数のポートにバインドされ、レガシーの v1 互換と新しい v2 互換の Ceph クライアントの両方が同じストレージクラスターに接続できるようにします。Ceph Monitor デーモンに接続する Ceph クライアントまたはその他の Ceph デーモンは、まず v2 プロトコルの使用を試みますが、可能でない場合は古い v1 プロトコルが使用されます。デフォルトでは、メッセンジャープロトコル v1v2 の両方が有効です。新しい v2 ポートは 3300 で、レガシー v1 ポートはデフォルトで 6789 です。

msgr2 プロトコルは、以下の 2 つの接続モードをサポートします。

  • crc

    • cephx で接続を確立すると、強固な初期認証を提供します。
    • ビットフリップから保護する crc32c 整合性チェックを提供します。
    • は、悪意のある中間者攻撃に対する保護を提供しません。
    • 認証後トラフィックをすべて確認できないようにすることはありません。
  • secure

    • cephx で接続を確立すると、強固な初期認証を提供します。
    • 認証後のすべてのトラフィックの完全暗号化を提供します。
    • 暗号化の整合性チェックを提供します。

デフォルトのモードは crc です。

警告

secure モードを使用すると、ストレージクラスターでパフォーマンスが低下する可能性があります。パフォーマンスの低下の重大度は、複数の環境要因によって異なる場合があります。Red Hat は、実稼働環境に実装する前に、実稼働環境でパフォーマンスへの影響をテストすることを推奨します。

重要

現在、CephFS や krbd などの Ceph カーネルクライアントでは、secure モードの使用はサポートされていません。secure モードの使用は、OpenStack Nova、Glance、Cinder などの librbd を使用する Ceph クライアントでサポートされています。

アドレスの変更

どちらのバージョンが同じストレージクラスターに共存する場合、アドレスフォーマットが変更されました。

  • 古いアドレスの形式は、IP_ADDR : PORT / CLIENT_ID です (例: 1.2.3.4:5678/91011)。
  • 新しいアドレスの形式は、PROTOCOL_VERSION : IP_ADDR : PORT / CLIENT_ID です (例: v2:1.2.3.4:5678/91011)。たとえば、PROTOCOL_VERSIONv1 または v2 のいずれかになります。

Ceph デーモンは複数のポートにバインドされるため、デーモンは単一のアドレスではなく複数のアドレスを表示します。以下は、モニターマップのダンプの例です。

epoch 1
fsid 50fcf227-be32-4bcb-8b41-34ca8370bd17
last_changed 2019-12-12 11:10:46.700821
created 2019-12-12 11:10:46.700821
min_mon_release 14 (nautilus)
0: [v2:10.0.0.10:3300/0,v1:10.0.0.10:6789/0] mon.a
1: [v2:10.0.0.11:3300/0,v1:10.0.0.11:6789/0] mon.b
2: [v2:10.0.0.12:3300/0,v1:10.0.0.12:6789/0] mon.c

また、mon_host 設定オプション、-m を使用してコマンドラインでアドレスを指定することで、新しいアドレス形式がサポートされます。

接続フェーズ

暗号化した接続を確立するには、以下の 4 つのフェーズがあります。

バナー
接続時に、クライアントとサーバーの両方がバナーを送信します。現在、Ceph バナーは ceph 0 0n です。
認証の交換
送受信されたデータはすべて、接続期間のフレームに含まれます。サーバーは、認証が完了し、接続モードがどのように行われるかを決定します。frame 形式は修正され、使用される認証フラグに応じて 3 つの形式にすることができます。
メッセージフローハンドシェイクエクスチェンジ
ピアは相互を特定し、セッションを確立します。クライアントは最初のメッセージを送信し、サーバーは同じメッセージで応答します。クライアントが誤ったデーモンと通信すると、サーバーが接続を閉じることができます。新しいセッションでは、クライアントとサーバーはメッセージを交換し続けます。クライアントクッキーはセッションを識別するために使用され、既存のセッションに再接続できます。
メッセージの交換
クライアントとサーバーは、接続が閉じられるまでメッセージを交換します。

関連情報

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.