第17章 マルチサイトの耐障害性のあるメッセージングシステムの設定

大規模なエンタープライズメッセージングシステムには、通常、地理的に分散したデータセンターに個別のブローカークラスターがあります。データセンターが停止した場合に、システム管理者は既存のメッセージングデータを保持し、クライアントアプリケーションがメッセージを生成および消費できるようにする必要がある場合があります。特定のブローカートポロジーと Red Hat Ceph Storage のソフトウェア定義ストレージプラットフォームを使用して、データセンターの停止時にメッセージングシステムの継続性を確保できます。このタイプのソリューションは、マルチサイトのフォールトトレランスアーキテクチャーと呼ばれます。

以下のセクションでは、メッセージングシステムをデータセンター停止から保護する方法を説明します。これらのセクションでは、以下の情報を提供します。

注記

マルチサイトのフォールトトレランスは、データセンターの高可用性 (HA) ブローカーの冗長性の代わりではありません。ライブバックアップグループに基づくブローカーの冗長性は、単一クラスター内の単一ブローカー障害に対する自動保護を提供します。これとは対照的に、マルチサイトのフォールトトレランスは、大規模なデータセンターの停止から保護します。

注記

Red Hat Ceph Storage を使用してメッセージングシステムの継続を確保するには、共有ストアの高可用性 (HA) ポリシーを使用するようにブローカーを設定する必要があります。レプリケーション HA ポリシーを使用するようにブローカーを設定することはできません。これらのポリシーについての詳細は、Implementing High Availability を参照してください。

17.1. Red Hat Ceph Storage クラスターの仕組み

Red Hat Ceph Storage は、クラスター化されたオブジェクトストレージシステムです。Red Hat Ceph Storage は、オブジェクトおよびポリシーベースのレプリケーションのデータシャーディングを使用して、データの整合性とシステムの可用性を保証します。

Red Hat Ceph Storage は CRUSH (Controlled Replication Under Scalable Hashing) と呼ばれるアルゴリズムを使用して、データストレージの場所を自動的に計算してデータを保存および取得する方法を決定します。CRUSH マップ と呼ばれる Ceph アイテムを設定します。これは、クラスターのトポロジーの詳細と、ストレージクラスター全体でデータの複製方法を指定します。

CRUSH マップには、オブジェクトストレージデバイス (OSD) の一覧、デバイスを障害ドメイン階層に集約するためのバケットの一覧、および CRUSH に Ceph クラスターのプールでデータを複製する方法を指示するルールが含まれます。

インストールの基礎となる物理組織を反映することで、CRUSH マップはモデル化し、物理近接性、共有電源ソース、共有ネットワークなどの関連するデバイス障害の潜在的なソースとなります。この情報をクラスターマップにエンコードすることで、CRUSH は異なる障害ドメイン ( データセンターなど ) 間でオブジェクトレプリカを分離しつつ、ストレージクラスター全体でデータの擬似分散を維持できます。これは、データ損失を回避し、クラスターが動作が低下した状態で動作できるようにします。

Red Hat Ceph Storage クラスターでは、動作に多数のノード ( 物理または仮想 ) が必要です。クラスターには以下のタイプのノードが含まれている必要があります。

ノードの監視

各モニターノード (MON) は、クラスターマップのマスターコピーを維持する monitor デーモン (ceph-mon) を実行します。クラスターマップにはクラスタートポロジーが含まれます。Ceph クラスターに接続するクライアントは、モニターからクラスターマップの現在のコピーを取得します。これにより、クライアントがクラスターへのデータの読み取りおよび書き込みが可能になります。

重要

Red Hat Ceph Storage クラスターは 1 つの Monitor ノードで実行できますが、実稼働クラスターで高可用性を確保するために、Red Hat は 3 つ以上の Monitor ノードを持つデプロイメントのみをサポートします。少なくとも 3 つのモニターノードは、1 つのモニターに障害が発生したり、1 つのモニターが利用できなくなると、クラスター内の残りの Monitor ノードが新しいリーダーを選択するためにクォーラムが存在することを意味します。

Manager ノード

各 Manager (MGR) ノードは Ceph Manager デーモン ( ceph-mgr ) を実行します。これは、ストレージ使用率、現在のパフォーマンスメトリック、システム負荷など、ランタイムメトリクスと Ceph クラスターの現在の状態を追跡します。通常、Manager ノードは ( つまり、同じホストマシンにある ) モニター ノードの同じ場所に配置されます。

オブジェクトストレージデバイスノード

各 Object Storage Device (OSD) ノードは Ceph OSD デーモン (ceph-osd) を実行し、ノードに割り当てられている論理ディスクと相互作用します。Ceph は OSD ノードにデータを保存します。Ceph は、非常に少数の OSD ノード (デフォルトは 3) で実行できますが、実稼働クラスターでは、ストレージクラスターで中程度のスケール (たとえば OSD が 50 個) のパフォーマンスが実現されます。ストレージクラスターに複数の OSD を持つと、システム管理者は CRUSH マップ内に分離された障害ドメインを定義できます。

メタデータサーバーノード

各 Metadata Server (MDS) ノードは、Ceph ファイルシステム (CephFS) に保存されているファイルに関連する MDS デーモン (ceph-mds) を実行します。MDS デーモンは、共有クラスターへのアクセスも調整します。

関連情報

Red Hat Ceph Storage の詳細は、What is Red Hat Ceph Storage? を参照してください。