2.2. Red Hat Ceph Storage の基本的な考慮事項
Red Hat Ceph Storage を使用するための最初の考慮事項は、データのストレージストラテジーの開発についてです。ストレージストラテジーとは、特定のユースケースに対応するためのデータを保管する手法を指します。OpenStack などのクラウドプラットフォームのボリュームおよびイメージを保存する必要がある場合は、ジャーナル用に Solid State Drives(SSD) を使用する高速な Serial Attached SCSI(SAS) ドライブにデータを保存することができます。一方、S3 または Swift 準拠のゲートウェイのオブジェクトデータを保存する必要がある場合は、従来の Serial Advanced Technology Attachment(SATA) ドライブなど、より経済的な方法を使用できます。Red Hat Ceph Storage は、同じストレージクラスターの両方のシナリオに対応しますが、クラウドプラットフォーム用に高速ストレージストラテジーと、オブジェクトストア用に従来のストレージを提供する手段が必要です。
Ceph のデプロイメントを正常に実行するための最も重要な手順の 1 つとして、クラスターのユースケースとワークロードに適した価格性能比のプロファイルを特定します。ユースケースに適したハードウェアを選択することが重要です。たとえば、コールドストレージアプリケーション用に IOPS が最適化されたハードウェアを選択すると、ハードウェアのコストが必要以上に増加します。また、IOPS が重視されるワークロードにおいて、より魅力的な価格帯に対して容量が最適化されたハードウェアを選択すると、パフォーマンスの低下に不満を持つユーザーが出てくる可能性が高くなります。
Red Hat Ceph Storage は、複数のストレージストラテジーをサポートできます。健全なストレージ戦略を策定するには、ユースケース、費用対効果、パフォーマンスのトレードオフ、データの耐久性などを考慮する必要があります。
ユースケース
Ceph は大容量のストレージを提供し、多くのユースケースをサポートします。
- Ceph Block Device クライアントは、クラウドプラットフォーム向けの代表的なストレージバックエンドで、ボリュームやイメージに対して制限なくストレージを提供し、コピーオンライトクローニングなど、高パフォーマンス機能を備えています。
- Ceph Object Gateway クライアントは、音声、ビットマップ、ビデオなどのオブジェクト向けの RESTful S3 準拠のオブジェクトおよび Swift 準拠のオブジェクトストレージを提供するクラウドプラットフォームの主要なストレージバックエンドです。
- 従来のファイルストレージである Ceph ファイルシステム。
コスト vs．パフォーマンス
速度、サイズ、耐久性など高いほうが優れています。ただし、優れた品質にはそれぞれコストがかかるので、費用対効果の面でトレードオフがあります。パフォーマンスの観点からでは、以下のユースケースを考慮してください。SSD は、比較的小規模なデータおよびジャーナリングのために非常に高速ストレージを提供できます。データベースやオブジェクトインデックスの保存には、非常に高速な SSD のプールが有効ですが、他のデータの保存にはコストがかかりすぎてしまいます。SSD ジャーナリングのある SAS ドライブは、ボリュームやイメージを安価かつ高速なパフォーマンスで提供できます。SSD ジャーナリングのない SATA ドライブは、全体的なパフォーマンスは低くなりますが、ストレージの価格を安価に抑えることができます。OSD の CRUSH 階層を作成する場合は、ユースケースと許容コスト/パフォーマンスのトレードオフを考慮する必要があります。
データの持続性
大規模なクラスターでは、ハードウェア障害は想定されており、例外ではありません。ただし依然として、データの損失および中断は受け入れられません。そのため、データの持続性は非常に重要になります。Ceph は、オブジェクトの複数のレプリカコピー、またはイレイジャーコーディングおよび複数のコーディングのチャンクでデータの持続性に対応します。複数のコピーまたはコーディングチャンクにより、さらに費用対効果の面でのトレードオフが分かります。コピーやコーディングのチャンクが少ない場合にはコストがかかりませんが、パフォーマンスが低下した状態で、書き込み要求に対応できなくなる可能性があります。通常、追加のコピーまたはコーディングチャンクが 2 つあるオブジェクトを使用すると、ストレージクラスターが復旧する間に、パフォーマンスが低下した状態でクラスターの書き込みを行うことができます。
レプリケーションでは、ハードウェア障害に備えて、障害ドメインをまたいで 1 つ以上のデータの冗長コピーを保存します。しかし、データの冗長コピーは、規模が大きくなるとコスト高になります。たとえば、1 ペタバイトのデータを 3 つのレプリケーションで保存するには、少なくとも容量が 3 ペタバイトあるストレージクラスターが必要になります。
イレイジャーコーディングでは、データをデータチャンクとコーディングチャンクに分けて保存します。データチャンクが失われた場合には、イレイジャーコーディングにより、残りのデータチャンクとコーディングチャンクで失われたデータチャンクを回復できます。イレイジャーコーディングはレプリケーションに比べて大幅に経済的です。たとえば、データチャンク 8 つとコーディングチャンク 3 つのイレイジャーコーディングを使用すると、データのコピーが 3 つある状態と同じ冗長性が得られます。ただし、このようなエンコーディングスキームでは、初期のデータ保存量が約 1.5 倍になるのに対し、レプリケーションでは 3 倍になります。
CRUSH アルゴリズムは、Ceph が、ストレージクラスター内の異なる場所に追加のコピーまたはコーディングチャンクを保存して、このプロセスをサポートします。これにより、1 つのストレージデバイスまたはホストに障害が発生しても、データ損失を回避するために必要なコピーやコーディングチャンクがすべて失われないようにします。費用対効果の面でのトレードオフやデータの耐性を考慮してストレージ戦略を計画し、ストレージプールとして Ceph クライアントに提示します。
データストレージプールのみがイレイジャーコーディングを使用できます。サービスデータやバケットインデックスを格納するプールはレプリケーションを使用します。
Ceph のオブジェクトコピーやコーディングチャンクを使用すると、RAID ソリューションが古く感じられます。Ceph はすでにデータの持続性に対応しており、質の低い RAID ではパフォーマンスに悪影響があり、RAID を使用してデータを復元すると、ディープコピーや消失訂正を使用するよりもはるかにスピードが遅くなるので、RAID は使用しないでください。
関連情報
- 詳細は、Red Hat Ceph Storage インストールガイドの Red Hat Ceph Storage の最小ハードウェア要件 セクションを参照してください。
2.2.1. Ceph デーモンの共存とその利点
コンテナー化された Ceph デーモンを同じホストの同じ場所に配置できます。Ceph のデーモンの一部を共存する利点を以下に示します。
- 小規模での総所有コスト (TCO) を大幅に改善します。
- 全体的なパフォーマンスを向上させることができます。
- 最小設定の物理ホストの量を減らします。
- リソースの使用率が向上します。
- Red Hat Ceph Storage のアップグレードが容易です。
コンテナーを使用すると、以下のリストの 1 つのデーモンを Ceph OSD デーモン (ceph-osd) と同じ場所に配置できます。さらに、Ceph Object Gateway (radosgw)、Ceph Metadata Server (ceph-mds)、および Grafana の場合は、Ceph OSD デーモンに加えて、以下のリストのデーモンと併置できます。
-
Ceph メタデータサーバー (
ceph-mds) -
Ceph Monitor (
ceph-mon) -
Ceph Manager (
ceph-mgr) -
NFS Ganesha (
nfs-ganesha) -
Ceph マネージャー (
ceph-grafana)
| ホスト名 | デーモン | デーモン | デーモン |
|---|---|---|---|
| host1 | OSD | Monitor および Manager | Prometheus |
| host2 | OSD | Monitor および Manager | RGW |
| host3 | OSD | Monitor および Manager | RGW |
| host4 | OSD | メタデータサーバー | |
| host5 | OSD | メタデータサーバー |
ceph-mon と ceph-mgr は密接に連携するため、コロケーションの観点では 2 つの別のデーモンとはみなされません。
Ceph デーモンを共存させるには、コマンドラインインターフェイスから ceph orch コマンドに --placement オプションを指定するか、サービス仕様 YAML ファイルを使用することができます。
コマンドラインの例
[ceph: root@host01 /]# ceph orch apply mon --placement="host1 host2 host3"
サービス仕様の YAML ファイルの例
service_type: mon placement: hosts: - host01 - host02 - host03
[ceph: root@host01 /]# ceph orch apply -i mon.yml
Red Hat は、Ceph Object Gateway を Ceph OSD コンテナーと併置してパフォーマンスを向上することを推奨します。追加のハードウェアコストを発生せずに最高のパフォーマンスを実現するには、ホストごとに 2 つの Ceph Object Gateway デーモンを使用します。
Ceph Object Gateway のコマンドラインの例
[ceph: root@host01 /]# ceph orch apply rgw example --placement="6 host1 host2 host3"
Ceph Object Gateway サービス仕様の YAML ファイルの例
service_type: rgw service_id: example placement: count: 6 hosts: - host01 - host02 - host03
[ceph: root@host01 /]# ceph orch apply -i rgw.yml
以下のダイアグラムは、同じ場所に置かれたデーモンと、同じ場所に置かれていないデーモンを使用するストレージクラスターの相違点を示しています。
図2.1 同じ場所に配置されたデーモン
図2.2 同じ場所に配置されていないデーモン
関連情報
-
--placementオプションの使用に関する詳細は、Red Hat Ceph Storage Operations Guide の Management of services using the Ceph Orchestrator の章を参照してください。 - 詳細は、Red Hat Ceph Storage RGW deployment strategies and sizing guidance のアーティクルを参照してください。
