AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu
Docs Home
/ /
アーキテクチャ
Docs Home
/
管理
/
Kubernetes 演算子のコントローラー
/
アーキテクチャ
Docs Home
/
管理
/
Kubernetes 演算子のコントローラー
/
アーキテクチャ

Ops Manager リソースのアーキテクチャ

MongoDB Ops Manager は、エンタープライズ MongoDB 配置に必要なコンポーネントです。MongoDB Ops Manager は、MongoDB データベースの自動化、モニター、バックアップを実行します。MongoDBOpsManager カスタム リソースは、次の 3 つのコンポーネントを定義します。

Kubernetes Operator は、MongoDBOpsManager リソースの仕様をマネージドします。仕様が変更されると、Kubernetes 演算子が変更を検証し、MongoDB Ops Manager コンポーネントを配置する各 Kubernetes クラスターで適切な更新を適用します。

次の図は、単一の Kubernetes クラスター上の MongoDB Ops Manager 配置のアーキテクチャを示しています。

単一の Kubernetes クラスター上の MongoDB Enterprise Kubernetes Operator の高レベルのアーキテクチャを示す図

アプリケーション データベース

アプリケーションデータベースの場合、Kubernetes Operator はMongoDBレプリカセットをステートフルセットとして配置します。各ポッドには次のコンテナがあります。

  • mongod — データベース プロセス。

  • MongoDB Agent — mongod ライフサイクルを管理します。MongoDB Agent のバージョンは、$AGENT_IMAGE 環境変数または Helm チャートの agent.version を使用して上書きできます。

  • モニタリングエージェント — モニタリングデータをMongoDB Ops Managerに送信します。バージョンは後方互換性のために自動的に選択されるため、上書きすることはできません。

Kubernetes 演算子は、各 Pod にマウントされた Secret (<om_resource_name>-db-config) を介してエージェントにアプリケーションデータベース構成を渡します。

Kubernetes はノードごとに 1 つの Pod を作成します。各 MongoDB Agent は mongod を起動し、レプリカセットに追加します。Kubernetes 演算子 は各 Pod の PersistentVolumeClaims を作成します。これらは spec.applicationDatabase.podSpec.persistence を使用してカスタマイズできます。

Kubernetes 演算子は、内部接続のためにヘッドレスサービスを作成します。マルチクラスター配置では、Kubernetes 演算子は、個別の mongod アドレス可能性のために、Pod (<om_resource_name>-db-N-svc)ごとに 1 つのサービスも作成します。

アプリケーションデータベースのトポロジーに関する考慮事項

プライマリを選出するには、アプリケーションデータベース レプリカセットのノードの過半数が使用可能である必要があります。可能であれば、奇数のノード Kubernetes クラスターを使用し、ノードをデータセンター、ゾーン、またはクラスターに分散します。

次の配布例を参照してください。

  • 5 ノードのアプリケーションデータベース、2 クラスター: 3 ノードをクラスター 1 に配置し、2 ノードをクラスター 2 に配置します。クラスター 2 が失敗した場合、クラスター 1 には過半数があります。クラスター 1 が失敗した場合、クラスター 2 には過半数がありません。

  • 5ノードのアプリケーションデータベース、3つのクラスター: クラスター1と2にそれぞれ2ノードを配置し、クラスター3に1ノードを配置します。クラスターが1つ失敗しても、過半数のノードが残ります。

  • 7ノードのアプリケーションデータベース、2クラスター: 4をクラスター1に、3をクラスター2に配置します。クラスター2の損失のみが過半数を維持します。

詳細については、「 レプリカセット配置アーキテクチャ および「 MongoDB Ops Managerと AppDB リソースの障害復旧 を参照してください。

Ops Managerアプリケーションリソース

アプリケーション データベースが実行状態に達すると、 Kubernetes Operator によってMongoDB Ops Managerアプリケーションの配置が開始されます。

  • Kubernetes Operator は、メンバー Kubernetes クラスターの各ノードに StatefulSet を構成します。

  • Kubernetes は、MongoDB Ops Manager レプリカごとに 1 つの Pod を作成します。

  • 各ポッドには 1 つのMongoDB Ops Managerアプリケーション プロセスが含まれています。

単一クラスター配置で Pod の障害に対する強韌性を高めるには、spec.replicas を増やします。複数クラスター配置でデータセンター障害に対する強韌性を高めるには、spec.topology を MultiCluster に設定し、Kubernetes クラスター間にインスタンスを分散させます。

バックアップデーモンリソース

spec.backup.enabled が true の場合、Kubernetes 演算子は、MongoDB Ops Manager アプリケーションが実行状態に達した後にバックアップデーモンを開始します。Kubernetes 演算子は、各ノードクラスターにバックアップデーモン用の StatefulSet を配置します。Kubernetes は、spec.backup.members で指定された数のバックアップデーモン Pod を作成します。

バックアップが有効になっている場合、Kubernetes 演算子は各ノードクラスター上のバックアップデーモンのヘッドデータベース用の PersistentVolumeClaim を作成します。spec.backup.headDB を介してヘッドデータベースを構成します。

Kubernetes 演算子 はMongoDB Ops Manager API を呼び出して、MongoDB Ops Managerアプリケーションのバックアップ構成がカスタム リソース定義と一致することを確認します。oplog ストア、ブロックストア、または S3 スナップショット ストアをクラスターごとではなく、グローバル spec.backup レベルで構成します。

バックアップジョブを暗号化 することもできますが、同じ Kubernetes Operator インスタンスが MongoDBOpsManager と MongoDB の両方のカスタムリソースを管理していない場合は、制限 が適用されます。

MongoDB Ops Manager の調整

次の図は、Kubernetes 演算子が MongoDBOpsManager CRD への変更を調整する方法を説明したものです。

MongoDB Ops Managerカスタムリソースの調停フローを示す図
クリックして拡大します

調整は次の手順で進められます。

  1. 作成または更新します <om_resource_name>-db-config MongoDB Agent がアプリケーション データベース レプリカセットを起動するために使用する構成を含むシークレット。

  2. 作成または更新します <om_resource_name>-db アプリケーションデータベース用の StatefulSet。この StatefulSet には少なくとも 3 つのポッドが含まれています。各ポッドは 1 つの MongoDB Agent を実行し、ポッドで mongod を起動します。構成 Secret は各ポッドにマウントされます。

    複数のクラスター配置では、StatefulSet の名前は <om_resource_name>-db-<cluster-idx> (例: om-db-1) です。

  3. 作成または更新します <om_resource_name> Ops Manager アプリケーションの StatefulSet。各レプリカはアプリケーションデータベースに接続します。変更の多くはローリングアップグレードをトリガーします。アプリケーションデータベースで TLS を有効にすると、接続文字列が変更されるため、ローリング再起動もトリガーされます。spec.backup への変更によってローリングアップグレードが trigger されることはありません。

    複数のクラスター配置では、StatefulSet の名前は <om_resource_name>-<cluster-idx> (例: om-1) です。

  4. MongoDB Ops Manager API を介して管理者ユーザーを作成し、認証情報を <om_resource_name>-admin-key シークレットに保存します。この手順は初回の配置のみで行われます。

  5. モニタリングを有効にするには、アプリケーションデータベース StatefulSet のローリングアップグレードを実行します。これは初期配置のみでも発生します。

  6. spec.backup.enabled が true の場合は、バックアップデーモンを配置します。StatefulSet の名前は <om_resource_name>-backup-daemon (マルチクラスター配置の場合は <om_resource_name>-backup-daemon-<cluster-idx>) です。

  7. MongoDB Ops Manager API を介してバックアップを構成します。これにより、バックアップ構成がカスタム リソース定義と一致することが保証されます。

戻る

MongoDB カスタム リソース アーキテクチャ

次へ

マルチクラスター アーキテクチャ

項目一覧