次の図は、MongoDB Ops Managerアプリケーション、アプリケーションデータベース、バックアップデーモン、および複数のKubernetesクラスターに配置された対応する永続ボリュームを示しています。
この図では、次のことが行われます。
には
Member Cluster 0kubernetes 構成ファイル が保存されています。このファイルは、ノード クラスター、ユーザー、コンテキストのKubernetes構成を記述します。kubectl mongodbプラグインを使用してKubernetes Operator をマルチクラスター配置用に構成すると、次のリソースが作成されます。mongodb-enterprise-operator-multi-cluster-kubeconfigシークレット。Kubernetes 演算子 がマネージドするすべての Kubernetes クラスターの認証情報が含まれています。中央クラスターをノードクラスターとして使用する場合、このシークレットには、Kubernetes 演算子をインストールするのと同じクラスターの認証情報が含まれる可能性があります。
Kubernetes Operator がマルチクラスター モードで実行されると、ConfigMap や管理するクラスターに関するシークレットなど、必要なリソースが保存されます。 これらのリソースは、Kubernetes Operator と同じ名前空間に属します。 Kubernetes Operator はこれらのリソースを使用して、 MongoDB Ops Managerアプリケーションとアプリケーション データベースを複数のKubernetesクラスターに配置します。
Kubernetes Operator は、管理対象のMongoDB Ops Managerアプリケーションおよびアプリケーション データベース配置ごとに、追加のマルチクラスター配置状態 ConfigMap を作成して維持します。
Member Cluster 0は、次の ConfigMap を含むこの構成を保存します。<om_resource_name>-cluster-mappingConfigMap には、spec.clusterSpecListにリストされているメンバークラスター名と、このドキュメントではcluster_indexとして参照されているクラスター インデックス（Cluster 0やCluster 1など）へのマッピングが含まれています。 Kubernetes Operator はこれらのインデックスを各クラスター名に割り当てます。<om_resource_name>-db-cluster-mappingConfigMap には、spec.applicationDatabase.clusterSpecListにリストされているノードクラスター名とクラスター インデックスへのマッピングが含まれています。<om_resource_name>-db-member-specConfigMap には、各ノード クラスターに対して構成されたアプリケーション データベースのレプリカの数が含まれています。 この情報を取得することで、Kubernetes Operator は、ノード クラスター全体が失われた後など、障害復旧の一環としてレプリカセットを正しくスケーリングまたは再構成することができます。
MongoDBOpsManagerリソースの構成は、マルチクラスターのMongoDB Ops Manager配置を説明するユーザーが作成するファイルです。 Kubernetes Operator はこのファイルを使用してMongoDB Ops Managerコンポーネントを配置します。次の例は、この図で説明されているKubernetes MongoDB Ops Managerコンポーネントを Operator が配置するための構成を示しています。この例では、 TLS構成など、この図に関連しない設定は省略されています。
apiVersion: mongodb.com/v1kind: MongoDBOpsManagermetadata: name: om namespace: om-nsspec: replicas: 1 # You can set this value and use it as a global or default # setting for all clusters. The spec.clusterSpecList.members # setting overrides this setting. topology: MultiCluster version: 8.0.0 adminCredentials: om-admin-secret clusterSpecList: - clusterName: "Member Cluster 1" # Ops Manager settings for "Member Cluster 1" members: 2 backup: # Backup settings for "Member Cluster 1" members: 2 # Overrides spec.backup.members - clusterName: "Member Cluster 2" # Ops Manager settings for "Member Cluster 2" members: 1 backup: # Backup settings for "Member Cluster 2" members: 2 # Overrides spec.backup.members applicationDatabase: # Global {+appdb+} settings topology: MultiCluster version: 8.0.0 members: 3 # In multi-cluster mode, the Operator ignores this field. # The Operator sets the number of members for the Application # Database in spec.applicationDatabase.clusterSpecList.members. clusterSpecList: - clusterName: "Member Cluster 1" members: 3 - clusterName: "Member Cluster 2" members: 2 backup: # Global settings for the Backup Daemon enabled: true members: 1 # Set this value and use it as a global or default setting. # To override this value, set the value for # spec.clusterSpecList.backup.members. # The Backup Daemon's configuration for each cluster isn't # stored here. Use the Ops Manager's spec.clusterSpecList.backup to # specify the Backup Daemon configuration for each member cluster.Kubernetes Operator は、次のいずれかを参照するMongoDB Ops Managerインスタンスに接続します。
MongoDB Ops Manager リソースのために作成するサービスのデフォルトの FQDN 、
<om_resource_name>-svc.<namespace>.svc.cluster.local、またはspec.opsManagerURLで指定した URL。配置によっては、Kubernetes 演算子をインストールしたクラスターがサービス メッシュに接続されていない場合など、デフォルトのサービス FQDN にアクセスできない場合があります。この場合、Kubernetes 演算子はMongoDBOpsManagerリソースのステータスをFailedとして報告し、接続エラーを示しています。このような場合を考慮して、spec.opsManagerURLで Ops Manager への URL を提供します。この URL は、外部に公開されている Ops Manager インスタンスのホスト名である可能性があります。詳細を学ぶには、「ネットワーキングの概要」を参照してください。
2 つのノード クラスターはMongoDB Ops Manager Applicationをホストします。 各クラスターに、Kubernetes Operator は
<om_resource_name>-<cluster_index>という名前のステートメントセットを配置します。ステートフルセットは、 MongoDB Ops Managerアプリケーションの 2 つのインスタンスを
Member Cluster 1に、1 つのインスタンスをMember Cluster 2に配置します。インスタンスの数を
spec.clusterSpecList.membersで定義します。 このクラスターは MongoDB Ops Manager アプリケーション インスタンスを配置しないように、 インスタンスの数を 0 に設定することができます。 これは、たとえばこのクラスターをバックアップデーモン インスタンスのみのホストに使用する場合に便利です。spec.clusterSpecListからクラスターを削除する場合、これはspec.clusterSpecList.membersとspec.clusterSpecList[*].backup.membersで 0 のメンバーを指定するのと同じになります。Kubernetes Operator は、各クラスター内の各ステートメントセットに対して、クラスターのエンドポイントリスト上のすべてのポッドを含むタイプ
ClusterIPのサービス（<om_resource_name>-svc）を構成します。このサービスの FQDN 、<om_resource_name>-svc.<namespace>.svc.cluster.localは、 Kubernetes Operator がMongoDB Ops Managerアプリケーションの配置エンドポイントにアクセスするために使用するデフォルトのホスト名です。spec.externalConnectivityを指定すると、Kubernetes Operator は各クラスターに対して<om_resource_name>-svc-extという名前の外部 KubernetesLoadBalancerタイプのサービスも作成します。 各クラスターで、spec.clusterSpecList.externalConnectivityを使用して、この外部サービスの独自の構成を指定できます。 たとえば、サービスのタイプを変更したり、注釈を定義したりできます。
アプリケーション データベース。 Kubernetes Operator は、アプリケーション データベースを 2 つのクラスターに配置します。
spec.applicationDatabase設定を使用してアプリケーション データベースの構成を定義します。 Kubernetes Operator は、各ノードクラスターで、spec.applicationDatabase.clusterSpecList.membersで定義されたノードクラスターの数に応じて<om_resource_name>-db-<cluster_index>という名前のステートメントセットを作成します。 マルチクラスター モードでは、Kubernetes Operator はspec.applicationDatabase.membersフィールドに設定した値を無視します。 Kubernetes Operator は、すべてのノード クラスター全体に配置されたmongodプロセスから作成された 1 つのレプリカセットを構成します。<statefulset_name>-<pod_index>の各 Pod で、<om_resource_name>-db-<cluster_index>-<pod_index>という名前の MongoDB プロセスをホストしている場合、Kubernetes 演算子は、個別のmongodプロセスに、その FQDN である<om_resource_name>-db-<cluster_index>-<pod_index>-svcを使用してアクセスするための KubernetesClusterIP型サービスを作成します。レプリカセット内の各mongodプロセスは、一意にアドレス指定可能である必要があります。レプリカセット構成のプロセスは、その Pod サービスの FQDN にプロセスホスト名を設定する必要があります:
<om_resource_name>-db-<cluster_index>-<pod_index>-svc.<namespace>.svc.cluster.local。すべての
mongodプロセスからレプリカセットを作成するには、各プロセスがレプリケーション目的で相互にプロセスに接続する必要があります。 これを実現するには、アプリケーション データベースを同じサービス ノードのすべてのノード クラスターに含めます。サービス メッシュは、クラスター間の DNS クエリを取り扱い、それに応じてトラフィックをルーティングします。サービスメッシュは、すべてのクラスターで各 Pod サービスの FQDN
<om_resource_name>-db-<cluster_index>-<pod-index>-svc.<namespace>.svc.cluster.localの解決を支援し、公開されているmongodポート (デフォルトでは 27017) での接続を可能にします。たとえば、
Member Cluster 1のom-db-1-0ポッドで実行されているmongodプロセスがMember Cluster 2のom-db-2-1ポッドで実行されているmongodに接続する場合、最初のmongodプロセスはオートメーション からのホスト名を使用します。構成、om-db-2-1-svc.om-ns.svc.cluster.local:27017、およびサービス メッシュは、このリクエストをMember Cluster 2にルーティングしてom-db-2-1-svcサービスにルーティングします。 サービス メトリクスがない場合、KubernetesMember Cluster 1はMember Cluster 2に配置されたom-db-2-1-svcサービスに関する情報を持たず、om-db-2-1-svc.om-ns.svc.cluster.localの DNS 解決は失敗します。アプリケーション データベースとMongoDB Ops Managerのアプリケーション インスタンスが
Running状態にある場合、 Kubernetes演算子はアプリケーション データベースのステートメントに追加の監視コンテナを追加します。 これにより、すべてのクラスター内のすべてのアプリケーション データベース ポッドがローリング再起動されます。 Kubernetes Operator は、すべてのクラスターのステートメントを順番に更新するため、ローリング再起動プロセス中に各クラスターで 1 つのレプリカセットのノードのみが一時的に使用できなくなります。モニタリングエージェントは MongoDB Ops Manager アプリケーション インスタンスに、MongoDB Ops Manager サービスの FQDN、
<om_resource_name>-svc.<namespace>.svc.cluster.local、または指定した場合はspec.opsManagerURLの値を使用して接続します。MongoDB Ops Managerアプリケーションとバックアップデーモンは、すべてのレプリカセット ノードを含むアプリケーションデータベースへの接続stringを常に使用します。 接続stringは常に、サービスごとの FQDN を使用して構築されます。
spec.backup.enabledをtrueに設定すると、Kubernetes 演算子はバックアップデーモンのステートメントを配置します。spec.clusterSpecListにリストされている各ノードクラスター上に、Kubernetes Operator は 1 つのバックアップデーモンのステートメントセットを作成し、バックアップデーモンのインスタンス数を<om_resource_name>-backup-daemon-<cluster_index>spec.backup.membersに設定します。あるいは、
spec.clusterSpecList[*].backup.membersで各クラスターのバックアップデーモン インスタンスの数を構成することもできます。バックアップデーモン インスタンスは、 アプリケーション インスタンスと同じ接続 を使用して、アプリケーションstring データベースMongoDB Ops Manager レプリカセットにのみ接続します。
さらに、この図では、サービス メトリクスとコンポーネント間のネットワーク接続を確認できます。
図を囲むドットラインは、すべてのクラスターのネットワーク構成を含む単一のサービス メトリクスを示しています。
ノードクラスター全体でMongoDB Ops Managerアプリケーションを囲むドットラインは、これらのインスタンスがステートレスであり、トラフィックはすべてのインスタンスに均等に分散できることを示しています（例: ラウンドロギングのロード バランサーを使用する場合など）。
ノードクラスターにわたってアプリケーションデータベースを囲むドットラインは、これらのインスタンスが相互に通信し、単一の MongoDB レプリカセットを形成することを示します。