Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes 演算子
/ / /

マルチクラスター アーキテクチャ図: MongoDB Ops Managerとアプリケーション データベース

次の図は、MongoDB Ops Manager アプリケーション、アプリケーション データベース、バックアップデーモン、および対応する 永続ボリューム Kubernetesを示しています。 複数の クラスターに配置。

MongoDB Ops Manager複数のKubernetes クラスター上に 、その UI アプリケーション、アプリケーション データベース、およびバックアップデーモンの高レベルの配置を示す図。この図には、コンポーネント間のネットワーク接続も表示されています。
クリックして拡大します

この図では、次のことが行われます。

  1. Member Cluster 0は、Kubernetes 演算子をインストールするため、「演算子クラスター」でもあります。 これは「ノードクラスター」でもあり、任意のマルチクラスター カスタム リソースをホストできます。

  2. は kubeconfig ファイルを保存 します は、Member Cluster 0 Kubernetes の構成 を説明します で、ノードクラスター、ユーザー、コンテキストが対象となります。kubectl mongodbプラグインを使用して Kubernetes Operator をマルチクラスター配置用に構成すると、次のリソースが作成されます。

    • Kubernetes Operator が管理するすべての Kubernetes クラスターへの認証情報を含むmongodb-enterprise-operator-multi-cluster-kubeconfigシークレット。 演算子クラスターをノード クラスターとして使用する予定の場合、このシークレットには Kubernetes Operator をインストールするのと同じクラスターへの認証情報が含まれることがあります。

    Kubernetes Operator がマルチクラスター モードで実行されると、ConfigMap や管理するクラスターに関するシークレットなど、必要なリソースが保存されます。 これらのリソースは、Kubernetes Operator と同じ名前空間に属します。 Kubernetes Operator はこれらのリソースを使用して、 MongoDB Ops Managerアプリケーションとアプリケーション データベースを複数のKubernetesクラスターに配置します。

  3. Kubernetes Operator は、管理対象のMongoDB Ops Managerアプリケーションおよびアプリケーション データベース配置ごとに、追加のマルチクラスター配置状態 ConfigMap を作成して維持します。 Member Cluster 0は、次の ConfigMap を含むこの構成を保存します。

    • <om_resource_name>-cluster-mapping ConfigMap には、 spec.clusterSpecListにリストされているメンバークラスター名と、このドキュメントではcluster_indexとして参照されているクラスター インデックス( Cluster 0Cluster 1など)へのマッピングが含まれています。 Kubernetes Operator はこれらのインデックスを各クラスター名に割り当てます。

    • <om_resource_name>-db-cluster-mapping ConfigMap には、 spec.applicationDatabase.clusterSpecListにリストされているノードクラスター名とクラスター インデックスへのマッピングが含まれています。

    • <om_resource_name>-db-member-spec ConfigMap には、各ノード クラスターに対して構成されたアプリケーション データベースのレプリカの数が含まれています。 この情報を取得することで、Kubernetes Operator は、ノード クラスター全体が失われた後など、障害復旧の一環としてレプリカセットを正しくスケーリングまたは再構成することができます。

  4. MongoDBOpsManager リソースの構成は、マルチクラスターのMongoDB Ops Manager配置を説明するユーザーが作成するファイルです。 Kubernetes Operator はこのファイルを使用してMongoDB Ops Managerコンポーネントを配置します。

    次の例は、この図で説明されているKubernetes MongoDB Ops Managerコンポーネントを Operator が配置するための構成を示しています。この例では、 TLS構成など、この図に関連しない設定は省略されています。

    1apiVersion: mongodb.com/v1
    2kind: MongoDBOpsManager
    3metadata:
    4 name: om
    5 namespace: om-ns
    6spec:
    7 replicas: 1 # You can set this value and use it as a global or default
    8 # setting for all clusters. The spec.clusterSpecList.members
    9 # setting overrides this setting.
    10 topology: MultiCluster
    11 version: 6.0.22
    12 adminCredentials: om-admin-secret
    13 clusterSpecList:
    14 - clusterName: "Member Cluster 1" # Ops Manager settings for "Member Cluster 1"
    15 members: 2
    16 backup: # Backup settings for "Member Cluster 1"
    17 members: 2 # Overrides spec.backup.members
    18 - clusterName: "Member Cluster 2" # Ops Manager settings for "Member Cluster 2"
    19 members: 1
    20 backup: # Backup settings for "Member Cluster 2"
    21 members: 2 # Overrides spec.backup.members
    22 applicationDatabase: # Global {+appdb+} settings
    23 topology: MultiCluster
    24 version: 6.0.5-ent
    25 members: 3 # In multi-cluster mode, the Operator ignores this field.
    26 # The Operator sets the number of members for the Application
    27 # Database in spec.applicationDatabase.clusterSpecList.members.
    28 clusterSpecList:
    29 - clusterName: "Member Cluster 1"
    30 members: 3
    31 - clusterName: "Member Cluster 2"
    32 members: 2
    33 backup: # Global settings for the Backup Daemon
    34 enabled: true
    35 members: 1 # Set this value and use it as a global or default setting.
    36 # To override this value, set the value for
    37 # spec.clusterSpecList.backup.members.
    38 # The Backup Daemon's configuration for each cluster isn't
    39 # stored here. Use the Ops Manager's spec.clusterSpecList.backup to
    40 # specify the Backup Daemon configuration for each member cluster.
  5. Kubernetes Operator は、次のいずれかを参照するMongoDB Ops Managerインスタンスに接続します。

    • MongoDB Ops Manager リソース( <om_resource_name>-svc.<namespace>.svc.cluster.local )用に作成されるサービスのデフォルトFQDN 、または

    • spec.opsManagerURLで指定する URL 。 Kubernetes Operator をインストールしたクラスターがサービス キャッシュにアタッチされていない場合など、一部の配置では、デフォルトのサービスFQDNに到達できない可能性があります。 この場合、Kubernetes Operator はMongoDBOpsManagerリソースのステータスをFailedとして報告し、接続エラーを示します。 このような場合を考慮するには、 spec.opsManagerURLに MongoDB Ops Manager への URL を指定します。 この URL は、外部に公開される MongoDB Ops Manager インスタンスのホスト名になる場合があります。 詳しくは、「ネットワーキングの概要 」を参照してください。

  6. 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.membersspec.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という名前の外部 Kubernetes LoadBalancerタイプのサービスも作成します。 各クラスターで、 spec.clusterSpecList.externalConnectivityを使用して、この外部サービスの独自の構成を指定できます。 たとえば、サービスのタイプを変更したり、注釈を定義したりできます。

  7. アプリケーション データベース。 Kubernetes Operator は、アプリケーション データベースを 2 つのクラスターに配置します。

    • Member Cluster 1にはアプリケーション データベース用の 3 つのmongodプロセスが含まれ、 Member Cluster 2には 2 つのmongodプロセスが含まれています。

    • 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>という名前の MongoDB プロセスをホストしている<om_resource_name>-db-<cluster_index>-<pod_index> の各ポッドに対して、Kubernetes Operator は、ClusterIP FQDN 、 によって個々のmongod プロセスにアクセスするための Kubernetes<om_resource_name>-db-<cluster_index>-<pod_index>-svc タイプのサービスを作成します。レプリカセット内の各mongodプロセスは、一意にアドレス指定できる必要があります。

      レプリカセット構成内のプロセスは、そのポッド サービスのFQDN : <om_resource_name>-db-<cluster_index>-<pod_index>-svc.<namespace>.svc.cluster.localにプロセス ホスト名を構成する必要があります。

    • 各ポッドには 永続的なボリューム要求 を介して接続された 永続的 なボリュームがあります Kubernetes Operator によって作成される

    • すべてのmongodプロセスからレプリカセットを作成するには、各プロセスがレプリケーション目的で相互にプロセスに接続する必要があります。 これを実現するには、アプリケーション データベースを同じサービス ノードのすべてのノード クラスターに含めます。

      サービス メトリクスはクロスクラスター DNS クエリを処理し、それに応じてトラフィックをルーティングします。 サービス メトリクスは、すべてのクラスターにわたって各 ポッド サービスのFQDN <om_resource_name>-db-<cluster_index>-<pod-index>-svc.<namespace>.svc.cluster.localの解決を支援し、公開されたmongodポート(デフォルトでは27017 )での接続を可能にします。

      たとえば、 Member Cluster 1om-db-1-0ポッドで実行されているmongodプロセスがMember Cluster 2om-db-2-1ポッドで実行されているmongodに接続する場合、最初のmongodプロセスはオートメーション からのホスト名を使用します。構成、 om-db-2-1-svc.om-ns.svc.cluster.local:27017 、およびサービス メッシュは、このリクエストをMember Cluster 2にルーティングしてom-db-2-1-svcサービスにルーティングします。 サービス メトリクスがない場合、Kubernetes Member Cluster 1Member 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 サービスのFQDN<om_resource_name>-svc.<namespace>.svc.cluster.local 、またはspec.opsManagerURLの値(指定されている場合)を使用して MongoDB Ops Manager アプリケーション インスタンスに接続します。

      MongoDB Ops Managerアプリケーションとバックアップデーモンは、すべてのレプリカセット ノードを含むアプリケーションデータベースへの接続stringを常に使用します。 接続stringは常に、サービスごとの FQDN を使用して構築されます。

  8. spec.backup.enabledtrueに設定すると、Kubernetes 演算子はバックアップデーモンのステートメントを配置します。

さらに、この図では、サービス メトリクスとコンポーネント間のネットワーク接続を確認できます。

  • 図を囲むドットラインは、すべてのクラスターのネットワーク構成を含む単一のサービス メトリクスを示しています。

  • ノードクラスター全体でMongoDB Ops Managerアプリケーションを囲むドットラインは、これらのインスタンスがステートレスであり、トラフィックはすべてのインスタンスに均等に分散できることを示しています(例: ラウンドロギングのロード バランサーを使用する場合など)。

  • ノードクラスターにわたってアプリケーションデータベースを囲むドットラインは、これらのインスタンスが相互に通信し、単一の MongoDB レプリカセットを形成することを示します。

戻る

複数の Kubernetes クラスターでの配置