Enterprise Advanced 配置を計画するときに最初に行うアーキテクチャ上の決定は、 MongoDB が仮想マシン、物理サーバー、またはKubernetesで実行される場所です。
このページでは、各プラットフォームが適切である場合に、この決定が重要な理由を説明し、プラットフォーム間の主要な違いをまとめています。インストールは対象外です。プラットフォームを選択した後は、「 Ops Manager とKubernetes用のMongoDB Controls（MCK）ドキュメント」を参照し、インストールと設定のプロセス手順を説明します。
選択が重要な理由
VM、物理サーバー、 Kubernetes はすべて Enterprise Advanced 配置で完全にサポートされているプラットフォームですが、それらは明確に異なります。選択したプラットフォームによって、 MongoDB が提供するオートメーションのレベル、使用できる機能、および後で選択を変更するのがどれだけであるかが決まります。
プラットフォームを選択します
Kubernetes
このパスでは、 MongoDB Kubernetes演算子である MCK がインフラストラクチャとMongoDB構成の両方を宣言的に管理します。つまり、1 つまたは少数の構成ファイルによってMongoDBデプロイが定義され、 MongoDB のオートメーションにより、インフラストラクチャとMongoDB構成の管理が行われます。
どのように動作:
希望する配置を宣言します。 MCK は、ステートメントセット、ポッド、ストレージ、ネットワークなど、 MongoDBが使用するKubernetesリソースを配置および管理します。 MCK は Ops Manager と調整し、配置を構成します。
Ops Manager は、オートメーション、バックアップ、モニタリングに引き続き必要です。 MCK と Ops Manager は連携します。 MCK はインフラストラクチャを自動化し、Ops Manager はMongoDB をサービスとして実行するために必要なサービスを提供します。代替として使用することはできません。
トレードオフと利点は次のとおりです。
配置、スケーリング、シャーディングの変更、アップグレードは、インフラストラクチャと Ops Manager の操作を行う必要があるのではなく、宣言型の構成変更になります。
配置およびアップグレードには、ホスト全体にバイナリをインストールまたは再インストールする必要はありません。
マルチリージョン配置:レプリカセットまたはシャーディングされたクラスターのノードは、異なる場所にある複数のKubernetesクラスターにまたがることができ、 Kubernetesクラスターとリージョン全体で回復力と高可用性を確保します。 1 つのクラスターまたはサイトがダウンしても、他のKubernetesクラスターに新しいMongoDBノードを自動的に作成することで、ノードを別のクラスターで再作成できます。
Enterprise Advanced Search ノードに必要です。検索がスコープ内にある場合、 Kubernetes は少なくとも検索ノードの配置の一部である必要がありますが、必ずしもデータベースノードである必要はありません。
Kubernetes は、 MongoDB がインフラストラクチャ レイヤーのオートメーションを提供できる唯一のプラットフォームです。例、検索ノードの負荷分散の自動プロビジョニング。
VM と同様に、基礎となるインフラストラクチャとそのアーキテクチャと設定は、ユーザーが引き続き責任を負います。これには、 Kubernetesクラスターのステートメントストレージのプロビジョニングと、 Kubernetesインフラストラクチャを管理および維持する関連する内部チームのサポートが含まれます。 MongoDB を実行中ための要件によっては、個々のMongoDB配置を複数の場所に配置する場合、 Kubernetesクラスター間の接続、および複数のKubernetesクラスターに接続する必要があるなどの懸念事項に拡張される可能性があります。
正しい選択を行った場合、次のようになります。
&引用符を実行したい組織は、 MongoDB as a Service」最小の運用オーバーヘッドで。
新しい Enterprise Advanced 配置。
インフラストラクチャとデータベース管理の一元化されたインターフェイスと、検索を含む Enterprise Advanced 機能への完全なアクセスを検討するチーム。
VM または物理サーバー
このパスでは、 MongoDB配置のインフラストラクチャのライフサイクルの管理はユーザーの責任となります。 MongoDB Agent は各ホストで実行され、Ops Manager を通じてMongoDBを構成できます。
どのように動作:
VM または物理サーバーは自分でプロビジョニングします。 MongoDB、 VMレイヤーのインフラストラクチャは管理されません。オートメーションや既存のツールを使用して、VM またはサーバーをプロビジョニングできます。
MongoDB Agent を各ホストにインストールし、それが Ops Manager に点。
Ops Manager は、これらのホストで実行中配置の構成、バックアップ、およびモニタリングを行います。
トレードオフと利点は次のとおりです。
VM で を実行すると、すでに使用されているインフラストラクチャのプロビジョニングツールを再利用して、 MongoDBのホストを作成できます。
ただし、インフラストラクチャとMongoDB構成の両方への変更に関係するすべての操作は、配置やスケーリングを含む 2 ステップの操作であることを平均。 VM の追加やRAMや CPU の追加など、インフラストラクチャをプロビジョニングまたはサイズ変更し、Ops Manager で対応する構成変更を行います。 2 つのシステムが同じ配置、インフラストラクチャ、構成の異なる部分を制御し、それらを整合性を維持します。 2 つのシステムを一致させるのはユーザーの責任です。必要に応じてその整合性を自動化して維持する必要があります。
MongoDB はインフラストラクチャを回復できません。例、サイトがダウンした場合、レプリカセットまたはシャード ノードを別の場所で再作成するには、新しいホストをプロビジョニングし、エージェントを構成して 、それらをクラスターに再接続する必要があります。
正しい選択を行った場合、次のようになります。
既存のインフラストラクチャ ツールと VMオートメーションを使用して VM プロパティを確立します。
Kubernetes の導入が不可能な組織。
VM ベースの配置は完全にサポートされており、現在、大規模な Enterprise Advanced カスタマーの多くがこの方法で実行されています。これはレガシーや非推奨パスではなく、基礎のプラットフォームに関係なく、セルフホスト型MongoDBのオーバーヘッドと複雑さを軽減するためにMongoDB へのプロジェクトが継続されています。
注意
データベースが VM で実行されている場合でも、検索にはKubernetesが必要です。後で検索を追加すると、検索層用にKubernetes環境が導入されます。データベースと MongoDB Ops Manager は移動する必要がありません。
ReCap
VM、物理サーバー、 Kubernetes はすべて、 MongoDBを実行中ための完全にサポートされているプラットフォームです。 Kubernetes は、クラスターに対するインフラストラクチャのプロビジョニングやライフサイクル管理を含む最高レベルのオートメーションを提供し、検索をサポートする唯一のプラットフォームです。また、基礎のKubernetesクラスターやステートメントストレージ の提供と管理にも引き続き責任を負います。
Kubernetes が組織の範囲内 でない場合は、Ops Manager を使用した VM ベースの配置は完全にサポートされています。バックアップ、モニタリング、オーケストレーション、サポートなど、Enterprise Advanced の主要値は引き続き利用できます。