第15章 Ceph を使用したマルチサイトの耐障害性のあるメッセージングシステムの設定
大規模なエンタープライズメッセージングシステムには、通常、地理的に分散したデータセンターに個別のブローカークラスターがあります。データセンターが停止した場合に、システム管理者は既存のメッセージングデータを保持し、クライアントアプリケーションがメッセージを生成および消費できるようにする必要がある場合があります。特定のブローカートポロジーおよび Red Hat Ceph Storage ( ソフトウェア定義ストレージプラットフォーム ) を使用して、データセンターの停止時にメッセージングシステムの継続性を確保できます。このタイプのソリューションは、マルチサイトのフォールトトレランスアーキテクチャーと呼ばれます。
AMQP プロトコルサポートのみが必要な場合は、16章ブローカー接続を使用したマルチサイトのフォールトトレランスメッセージングシステムの設定 を検討してください。
以下のセクションでは、Red Hat Ceph Storage を使用して、メッセージングシステムをデータセンターの停止から保護する方法を説明します。
マルチサイトのフォールトトレランスは、データセンター内の高可用性 (HA) ブローカーの冗長性の代わりではありません。ライブバックアップグループに基づくブローカーの冗長性は、単一クラスター内の単一ブローカー障害に対する自動保護を提供します。これとは対照的に、マルチサイトのフォールトトレランスは、大規模なデータセンターの停止から保護します。
Red Hat Ceph Storage を使用してメッセージングシステムの継続を確保するには、共有ストアの高可用性 (HA) ポリシーを使用するようにブローカーを設定する必要があります。レプリケーション HA ポリシーを使用するようにブローカーを設定することはできません。これらのポリシーについての詳細は、Implementing High Availability を参照してください。
15.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? を参照してください。
