MongoDBOpsManagerカスタム リソース定義
KubernetesOperatorMongoDB Ops Manager は、MongoDBOpsManager カスタム リソース Kubernetesを使用して の配置を管理します リソースを配置する各 クラスターで。Kubernetes 演算子 は、リソースの仕様の変更を監視します。 仕様が変更されると、Kubernetes Operator は変更を検証し、 コンポーネントを配置する各 クラスターのKubernetes MongoDB Ops Managerリソースに適切な更新を行います。
MongoDBOpsManager カスタム リソース s 仕様 では、次のMongoDB Ops Manager コンポーネントが定義されます。
アプリケーション データベース
MongoDB Ops Managerアプリケーション
バックアップデーモン
以下の図では、 MongoDB Ops Managerの配置に関連するコンポーネントが説明されています。
単一クラスター配置では、Kubernetes Operator がインストールされるのと同じ Kubernetes クラスターにこれらのコンポーネントを配置します。 このクラスターは「演算子クラスター」と呼ばれます。
マルチクラスター配置では、次の操作を行います。
異なる Kubernetes クラスターに配置します。これは「ノードクラスター」と呼ばれます。 また、Kubernetes クラスターの単一ノードを使用した簡素化されたマルチクラスター配置を配置することもできます。 詳しくは、 の単一クラスターとマルチクラスター モードを参照してください。
Kubernetes Operator を、「オペレータークラスター」と呼ばれる 1 つの Kubernetes クラスターにインストールし、Kubernetes Operator が他のすべてのノードクラスターを管理します。 演算子クラスターは、 MongoDB Ops Managerコンポーネントもホストできるため、ノードクラスターと見なすこともできます。 「マルチクラスター アーキテクチャ図 」を参照してください。
アプリケーション データベース
アプリケーション データベースの場合、Kubernetes Operator は MongoDB レプリカセットを ステートフル セットとして配置します。 。
アプリケーション データベースの各ポッドには、次のコンテナがあります。
MongoDB Agent 。 MongoDB Agent のバージョンを上書きするには、
$AGENT_IMAGE環境変数または Kubernetes Operator のインストールに使用する Helm チャートのagent.versionを使用します。モニタリングエージェント。 モニタリングエージェントのバージョンを上書きすることはできません。 Kubernetes Operator が使用するバージョンは、 MongoDB Ops Managerバージョンとの下位互換性を確保します。
モニタリングエージェントのバージョンを表示するには、以下を行います。
Kubernetes Operator の ポッド または Kubernetes Operator の イメージ内の
/usr/local/om_version_mapping.jsonを調べます。アプリケーション データベースを配置するポッドで、モニタリングエージェントのコンテナのイメージを確認します。
マルチクラスター配置（ spec.applicationDatabase.topologyをMultiClusterに設定している場合）、Kubernetes Operator は、 spec.applicationDatabase.clusterSpecListのアプリケーション データベースに指定された各 Kubernetes クラスターにステートフルセットを作成します。
次のアクションは、アプリケーション データベースの MongoDB レプリカセット ノードをホストしている各ノードの Kubernetes クラスターで実行されます。
Kubernetes は、アプリケーション データベース レプリカセットを構成する各ノードに対して ステートメントを使用して 1 つのポッドを作成します。 ステートメントセット内の各ポッドは
mongodとMongoDB Agentを実行します。各MongoDB Agent
mongodがステートメントセット内のポッドで を起動できるようにするには、MongoDB Server 設定を使用してアプリケーションspec.applicationDatabase.versionデータベース用に特定の バージョンを指定する必要があります。この設定で指定するバージョンは、 コンテナ レジストリのタグに対応している必要があります。各 MongoDB Agent は、アプリケーション データベース ポッドで
mongodを開始します。 MongoDB Agent によるアプリケーション データベース レプリカセットへのmongodプロセスの追加MongoDBOpsManagerカスタム リソースのspec.applicationDatabaseコレクション内のアプリケーション データベース レプリカセットのレプリカセットの数とその他の構成オプションを構成します。 Kubernetes Operator は、 シークレット を使用してこの構成を MongoDB Agent の Kubernetes Operator がアプリケーション データベース ステートメント セット内の各ポッドにマウントするマルチクラスターのアプリケーション データベースの配置（
spec.applicationDatabase.topologyがMultiClusterに設定されている場合）では、spec.applicationDatabase.clusterSpecListの各ノードクラスターに対して各ノードクラスター内のノード数を個別に指定します。 マルチクラスター配置では、spec.applicationDatabaseのreplicas設定は無視されます。spec.applicationDatabaseコレクションを更新するたびに、Kubernetes Operator は MongoDB Agent の構成と Atlas Triggers 仕様に変更を適用します（該当する場合）。 ステートフルセットの仕様が変更された場合、Kubernetes はポッドを段階的にアップグレードし、各ポッドを再起動します。アプリケーション データベースをホストしている各 Kubernetes クラスター内から各アプリケーション データベース ポッドへの接続を提供するために、Kubernetes 演算子はヘッドレス サービス を作成します 。アプリケーション データベースのマルチクラスター配置では、Kubernetes 演算子は、
<om_resource_name>-db-N-svcという名前のポッドごとに 1 つのサービスも作成し（これはmetadata.nameに対応します）、<om_resource_name>-db-0.<namespace>.svc.cluster.localなどの FQDNをホスト名として使用します。特定のmongodに接続します。StorageClass に応じて または Kubernetes Operator を配置した環境によって、Kubernetes は 永続的なボリューム を作成する可能性があります。 動的ボリュームプロビジョニング を使用します。
永続的なボリューム要求 をカスタマイズできます アプリケーション データベース ポッドでは
spec.applicationDatabase.podSpec.persistence.singleまたはspec.applicationDatabase.podSpec.persistence.multipleを使用します。
アプリケーション データベースのトポロジー
プライマリを選択するには、アプリケーション データベースのレプリカセットのノードの過半数が利用可能である必要があります。 レプリカセットのノードの過半数が失敗した場合、レプリカセットはプライマリ ノードを選出するための投票過半数を形成できません。 詳細については、「レプリカセットの配置アーキテクチャ 」を参照してください。
可能であれば、奇数のメンバー Kubernetes クラスターを使用し、 アプリケーションデータベース ノードをデータセンター、ゾーン、または Kubernetes クラスターに分散します。 詳しくは、「 2 つ以上のデータセンターに分散されたレプリカセット 」を参照してください。
アプリケーション データベースのトポロジーの次の例について考えてみましょう。
5 つのノードからなるアプリケーションデータベースの場合、ノードの分布には次のようなものがあります。
2 つのクラスター: 3 つのノードから
Cluster 1への 2 つのノードで、Cluster 2への 2 つのノード。Cluster 2が失敗した場合、Cluster 1はプライマリ ノードを選択するのに十分な数のアプリケーション データベースのレプリカセット メンバーをホストします。Cluster 1が失敗した場合、Cluster 2にはプライマリ ノードを選択するのに十分なアプリケーション データベースのメンバーがありません。
3 つのクラスター:
Cluster 1に 2 つのノード、Cluster 2に 2 つのノード、Cluster 3に 1 つのノード。いずれかのクラスターが失敗した場合、残りのクラスターにプライマリ ノードを選択するのに十分なメンバーが存在します。
2 つのクラスターが失敗した場合、残りのクラスターにプライマリ ノードを選択するのに十分なノードがありません。
7 つのノードからなるアプリケーション データベースの場合、次のノードの分布を考慮してください。
2 つのクラスター: 4 つのノードから
Cluster 1への 3 つのノード、Cluster 2への 3 つのノード。Cluster 2が失敗した場合、Cluster 1にはプライマリ ノードを選択するのに十分なメンバーが存在します。Cluster 1が失敗した場合、プライマリ ノードを選択するのに十分なメンバーがCluster 2に存在しません。
Cluster 2はアプリケーション データベースの最小ノード 3 つを満たしていますが、アプリケーション データベースの 7 つのノードの過半数がプライマリ ノードの選択に使用できる必要があります。
MongoDB Ops Managerアプリケーション
アプリケーション データベースが実行状態に達すると、 Kubernetes Operator によってMongoDB Ops Managerアプリケーションの配置が開始されます。
これにより、Kubernetes クラスターの各ノードに ステートメントが構成されます。
配置するMongoDB Ops Managerレプリカセットごとに、 Kubernetesはステートフルセットに 1 つのポッドを作成します。
各ポッドには 1 つのMongoDB Ops Managerアプリケーション プロセスが含まれています。
MongoDB Ops Managerの単一クラスターの配置を単一の ポッド障害に対して回復性のあるものにするには、 を使用してMongoDB Ops Manager spec.replicasアプリケーションをホストするレプリカの数を増やします。
マルチクラスターのMongoDB Ops Manager 配置をデータセンターまたはゾーン全体の障害に対して回復性のあるものにするには、MongoDB Ops Manager と を に設定して アプリケーションを複数のKubernetes spec.topologyspec.applicationDatabase.topologyMultiClusterクラスターに配置します。「 MongoDB Ops Managerと AppDB リソースの障害復旧 」も参照してください。
バックアップデーモン
がspec.backup.enabled true の場合、各ノードのKubernetes クラスターでは、Kubernetes アプリケーションがMongoDB Ops Manager 実行中 のステージに達した後に Operator はバックアップデーモンを起動します。バックアップデーモンの場合、Kubernetes Operator はステートフルセットを各ノードの Kubernetes クラスターにデプロイします。 各ノード クラスターに、Kubernetes はspec.backup.membersで指定された数のバックアップ デーモン ポッドを Atlas App Services に作成します。 単一クラスター配置では、これらのアクションはKubernetes Operator のインストールとMongoDB Ops Managerコンポーネントの配置に使用するオペレータークラスターで行われます。
バックアップを有効にする場合は、Kubernetes ノードごとではなく、グローバル レベルで oplog ストア 、 ブロックストア 、または S3 スナップショット ストア を構成します。spec.backup
バックアップジョブを暗号化 することもできますが、同じ Kubernetes Operator インスタンスが MongoDPOsManager と MongoDB カスタム リソースの両方を管理していない配置には 制限が 適用されます。
バックアップを有効にすると、Kubernetes Operator は 永続的なボリューム要求 を作成します 各ノード Kubernetes クラスター上のバックアップデーモンの ヘッドデータベース 用。spec.backup.headDB設定を使用してヘッドデータベースを構成できます。
Kubernetes Operator はMongoDB Ops Manager API を呼び出して、 MongoDB Ops Managerアプリケーションのバックアップ構成が、各ノードのKubernetesクラスターのカスタム リソース定義で定義したバックアップ構成と一致することを確認します。