MongoDBシャーディングされたクラスターは、複数のKubernetesクラスターに分散できます。マルチクラスター機能を使用すると、次のことが可能になります。
配置の回復力を高めるには、それぞれが異なる地理的リージョンにある複数のKubernetesクラスターに分散する必要があります。
指定されたシャードのプライマリ ノードを、そのデータに依存するアプリケーションまたはクライアントの近くに配置することで、地理Kubernetesシャーディング用に構成し、レイテンシを削減します。
パフォーマンスを向上させるには、配置を調整してください。例、 は、別のKubernetesクラスター内のすべてのシャードまたは指定されたシャードの読み取り専用分析ノードを、またはカスタマイズされたリソース割り当てを使用して配置できます。
さらに、シャード、mongos、コンフィギュレーションサーバーの詳細をさまざまなレベルで構成できます。つまり、シャード、コンフィギュレーションサーバー、mongos の最上位のデフォルト構成を定義し、 Kubernetesクラスターごとに個別にカスタマイズできます。さらに、特定のニーズに合わせて個々のシャードをカスタマイズすることもできます。
重要
マルチクラスターのシャーディングされたシャーディングされたクラスター機能により、複数の地理的リージョンの複数のKubernetesクラスターにMongoDBリソースを配置できます。ただし、そうすると、レプリケーション操作のレイテンシが増加する可能性があります。
マルチクラスターのシャーディングされたクラスターのトポロジーの具体的な構成オプションの詳細については、シャーディングされたクラスターの参照を参照してください。
制限
Hashi書込み Vault サポートはKubernetes Secret インジェクションでは利用できません。
ノードクラスターに障害が発生した場合は、まず障害クラスターを手動で 0 に増やすダウンして、正常でないプロセスを排除する必要があります。次に、中央クラスターに配置された CRDリソースを更新することで、残りの正常なKubernetesクラスターにリソースを手動で再分配できます。詳細については、「障害復旧」を参照してください。
前提条件
マルチクラスター配置用のKubernetesクラスターを準備します。
お使いのKubernetesクラスターの 1 つに、マルチクラスター配置用にKubernetes Operator をインストールして構成します。
オプション 1: ノード クラスター全体にサービス キャッシュを配置します。MongoDB Ops Managerマルチクラスター配置ガイド のステップ 1 - 6 には詳細な手順があります。この手順は独自であり、多くの可能な構成の 1 つであることに注意してください。
オプション 2: 非サービス メトリクス配置用にKubernetesクラスターを構成します。
MongoDB Ops ManagerまたはCloud ManagerとMongoDBプロジェクトの詳細を含むコンフィギュレーション マップを中央クラスターに配置します。これは、 Kubernetes Operator がMongoDBデータベースリソースを配置するために必要です。
シャードクラスタの配置例
以下の例では、中央クラスターに適用すると、次のように構成された 3 シャードを含むシャーディングされたMongoDBクラスターが配置されます。
各シャードには、すべてのKubernetesクラスターに分散されたノードがあります(クラスターあたり 1ノード)。
デフォルトでは、各シャードのレプリカセットは次のようになります。
3 クラスター(各クラスターの 1ノード)に配置された合計で 3 の投票ノードがある
プライマリシャードは
kind-e2e-cluster-1にあることが推奨されています。
シャード
sc-0のshardOverrideでは、デフォルト値(spec.shardで指定)を次のように変更します。合計 5 メンバー
の 2 メンバー
kind-e2e-cluster-1の 2 メンバー
kind-e2e-cluster-2の 1 メンバー
kind-e2e-cluster-3可能であれば、プライマリシャードの場所にあることが推奨されます:
kind-e2e-cluster-2
次で定義されているように、すべてのクラスター内のすべてのシャードのカスタマイズされたデフォルトストレージ設定
spec.shardPodSpec3 ノード(各クラスターに 1 ノード)を持つコンフィギュレーションサーバーのレプリカセット
合計で配置された 3 mongos インスタンスと、各クラスターに 1インスタンス
デフォルト構成は 3 つのシャードで構成されており、3 つのクラスターそれぞれに 1 つのノードがあり、シャードあたり合計 3 つのノードがあります。ただし、オーバーライドでは、シャード sc-0 のノードが 5 つ、クラスター 1 が 2 つ、クラスター 2 が 2 つ、クラスター 3 がデフォルトのごとに 1 つのシャードを含むように変更します。
注意
一方向のスケーリングのみがサポートされます。
シャード、コンフィギュレーションサーバー、または mongos レプリカを増やす場合 、スケーリングの正確性を確保するために、 リソースを増やすアップまたはスケールダウンするのみです。このルールは、単一のKubernetesクラスター配置と複数のKubernetesクラスターに分散された配置の両方に適用されます。さらに、マルチクラスター配置では、一方向のスケーリング ルールがすべてのリソースタイプに適用されます。例、コンフィギュレーションサーバーまたは mongos を同時に削除(スケールダウン)している間は、シャードにノードを追加(スケールアップ)することはできません。ノードの合計数を変更せずに、あるクラスターから別のクラスターにノードを「移動」することはできなくなりました。そうではなく、最初にスケールアップ操作を実行し、次にスケールダウンのための別の変更を実行する必要があります。
この構成例では、シャード sc-0 のプライマリをクラスター 2 に(shardOverrides を使用して)移行します。これにより、クラスター 2 が配置されるリージョンで操作しているユーザーのレイテンシを軽減できます。この方法では、クラスター(およびそのリージョン)全体では引き続き回復力がありますが、シャード 0 のデータがクラスター 2 が配置されているユーザーに最も関連するデータである場合は、レイテンシが低くなります。
apiVersion: mongodb.com/v1kind: MongoDBmetadata: name: scspec: topology: MultiCluster type: ShardedCluster # this deployment will have 3 shards shardCount: 3 # you cannot specify mongodsPerShardCount, configServerCount and mongosCount # in MultiCluster topology version: 8.0.3 opsManager: configMapRef: name: my-project credentials: my-credentials persistent: true
shardPodSpec: # applies to all shards on all clusters persistence: single: # all pods for all shards on all clusters will use that storage size in their # PersistentVolumeClaim unless overridden in spec.shard.clusterSpecList or # spec.shardOverrides. storage: 10G
configSrvPodSpec: # applies to all config server nodes in all clusters persistence: multiple: data: storage: 2G journal: storage: 1G logs: storage: 1G
# consider this section as a default configuration for ALL shards shard: clusterSpecList: - clusterName: kind-e2e-cluster-1 # each shard will have only one mongod process deployed in this cluster members: 1 memberConfig: - votes: 1 priority: "20" # we increase the priority to have primary in this cluster - clusterName: kind-e2e-cluster-2 # one member in this cluster, no votes and priority defined means it'll get # the default values votes=1, priority="1" members: 1 - clusterName: kind-e2e-cluster-3 members: 1 # one member in this cluster
shardOverrides: # here you specify customizations for specific shards # here you specify to which shard names the following configuration will # apply - shardNames: - sc-0 clusterSpecList: - clusterName: kind-e2e-cluster-1 # all fields here are optional # shard "sc-0" will have two members instead of one, which was defined as the # default for all shards in spec.shard.clusterSpecList[0].members members: 2 memberConfig: - votes: 1 # shard "sc-0" should not have primary in this cluster like every other shard priority: "1" - votes: 1 priority: "1" - clusterName: kind-e2e-cluster-2 members: 2 # shard "sc-0" will have two members instead of one memberConfig: - votes: 1 # both processes of shard "sc-0" in this cluster will have the same # likelihood to become a primary member priority: "20" - votes: 1 priority: "20" # We need to specify the list of all clusters on which this shard will be # deployed. - clusterName: kind-e2e-cluster-3 # If the clusterName element is omitted here, it will be considered as an # override for this shard, so that the operator shouldn't deploy any member # to it. # No fields are mandatory in here, though. In case a field is not set, it's # not overridden and the default value is taken from a top level spec.shard # settings.
configSrv: # the same configuration fields are available as in # spec.shard.clusterSpecList. clusterSpecList: - clusterName: kind-e2e-cluster-1 members: 1 - clusterName: kind-e2e-cluster-2 members: 1 - clusterName: kind-e2e-cluster-3 members: 1
mongos: # the same configuration fields are available as in # spec.shard.clusterSpecList apart from storage and replica-set related # fields. clusterSpecList: - clusterName: kind-e2e-cluster-1 members: 1 - clusterName: kind-e2e-cluster-2 members: 1 - clusterName: kind-e2e-cluster-3 members: 1シャード オーバーライド
クラスターを複数のKubernetesクラスターに配置するには、クラスター構成(MongoDBカスタムリソースyaml)を中央クラスター(MongoDB演算子インスタンスが配置されているKubernetesクラスター)に適用します。この構成のspec.shard定義は、配置のベースシャード定義と見なされます。
特定のKubernetesクラスター上の特定のシャードをカスタマイズする場合は、シャード オーバーライドを使用して、特定のシャードの基本シャード定義を更新できます。
次の表では、基本シャード定義を更新または拡張するために定義できるフィールドを一覧にしています。フィールドは優先順位順に表示されます。特定の表の最上位のフィールドは優先順位が最も低い設定を表し、最下位のフィールドが定義されている場合は、他のすべてのフィールド(例:(特定のクラスター上の特定のシャード)。
さらに、各フィールド型に示される上書きポリシーは、そのフィールドが新しく定義された値によって上書きされるか、そのフィールドが定義されている完全なオブジェクトが上書きされるかどうかを示します。オブジェクト全体がオーバーライドされると、オーバーライド定義で明示的に定義されていない、基本シャード定義で定義されているフィールドも削除されます。merge 値は 1 つのフィールドが更新されたことを示し、replace 値は次が更新されたことを示します:完全な親オブジェクトが上書きされます。
永続性とステートフルセット設定をカスタマイズする
ShardedClusterSpec フィールド | を指定するには | に適用されます |
|---|---|---|
| 永続性と ポッド テンプレート | すべてのポッド |
| 永続性と ポッド テンプレート | すべてのポッド |
| 永続性(ポッド テンプレートフィールドは無視されます) | クラスター内のすべてのシャード |
| Pod Template | クラスター内のすべてのシャード |
| 永続性(ポッド テンプレートフィールドは無視されます) | クラスター内のすべてのシャード |
| Pod Template | クラスター内の 1 つのシャード |
| 永続性(ポッド テンプレートフィールドは無視されます) | 特定のクラスター内の 1 つのシャード |
| Pod Template | 特定のクラスター内の 1 つのシャード |
注意
ShardSpecificPedSpec の廃止
ShardSpecificPodSpecフィールドは非推奨ですが、引き続きサポートされます。以前は、単一の シャーシャーディングされたクラスターのシャードごとに 永続性 と ポッド テンプレート パラメーターを指定するために使用されていました。ShardOverrides.PodSpec非推奨になったため、 とShardOverrides.StatefulSetConfiguration に移行する必要があります。単一クラスター配置の shardSpecificPodSpec と shardOverrides からの更新に関するガイダンスについては、提供されている YAMLファイルの例を参照してください。
でポッド テンプレートと永続性設定を上書き clusterSpecList
次の例では、clusterSpecList でカスタム ポッド テンプレートと永続性設定を無効にする方法を説明しています。
shardPodSpec: # applicable to all shards in all clusters persistence: single: storage: "5G" podTemplate: spec: containers: - name: mongodb-enterprise-database resources: requests: cpu: 0.5 memory: 1.0G limits: cpu: 1.0 memory: 2.0G shard: clusterSpecList: - clusterName: kind-e2e-cluster-1 members: 2 # The below statefulset override is applicable only to pods in kind-e2e-cluster-1 # Specs will be merged, the "request" field defined above will still be # applied to containers in this cluster. # However, limits will be replaced with below values, because # clusterSpecList.statefulSet.spec.template has a # higher priority than shardPodSpec.podTemplate statefulSet: spec: template: spec: containers: - name: mongodb-enterprise-database resources: limits: cpu: 1.0 memory: 2.5G # In clusterSpecList.podSpec, only persistence field must be used, the # podTemplate field is ignored. # In kind-e2e-cluster-1, we replace the persistence settings defined in # shardPodSpec podSpec: persistence: multiple: journal: storage: "6G" data: storage: "7G" logs: storage: "6G" - clusterName: kind-e2e-cluster-2 members: 1詳細については、 完全なファイルを確認してください 。
を使用してカスタム ポッド テンプレートと永続性設定を定義します shardOverrides
次の例では、shardOverrides でカスタム ポッド テンプレートと永続性設定を定義する方法を説明しています。
# In clusterSpecList.podSpec, only persistence field must be used, the # podTemplate field is ignored. # In kind-e2e-cluster-1, we define custom persistence settings podSpec: persistence: multiple: journal: storage: "5G" data: storage: "5G" logs: storage: "5G" - clusterName: kind-e2e-cluster-2 members: 1
shardOverrides: - shardNames: [ "pod-template-shards-1-2" ] # This override will apply to shard of index 2 # Statefulset settings defined at this level (shardOverrides.statefulSet) # apply to members of shard 2 in ALL clusters. # This field has higher priority than shard.clusterSpecList.statefulSet, but # lower than shardOverrides.clusterSpecList.statefulSet # It has a merge policy, which means that the limits defined above for the # mongodb-enterprise-database container field still apply to all members in # that shard, except if overridden. statefulSet: spec: template: spec: containers: - name: sidecar-shard-2 image: busybox command: [ "sleep" ] args: [ "infinity" ] clusterSpecList: - clusterName: kind-e2e-cluster-1 members: 2 - clusterName: kind-e2e-cluster-2 members: 1 # The below statefulset override is applicable only to members of shard 2, in cluster 1 # Specs will be merged, the "limits" field defined above will still be applied # to containers in this cluster together with the requests field below. statefulSet: spec: template: spec: containers: - name: mongodb-enterprise-database resources: requests: # We add a requests field in shard 2, cluster 1 cpu: 0.5 memory: 1.0G
podSpec: # In shardOverrides.clusterSpecList.podSpec, only persistence field must be # used, the podTemplate field is ignored. persistence: # we assign additional disk resources in shard 2, cluster 1 multiple: journal: storage: "6G" data: storage: "6G" logs: storage: "6G"詳細については、 完全なファイルを確認してください 。
非推奨の shardSpecificPodSpecフィールドからの移行
次の例では、非推奨の shardSpecificPodSpecフィールドから新しい shardOverridesフィールドに更新する方法を説明しています。
# This file is an example of how to migrate from the old deprecated# ShardSpecificPodSpec field to the new shardOverrides fields# for single cluster deployments.# The settings specified in shardOverrides are the exact equivalent to the# ones in shardSpecificPodSpec, showing how to replicate themapiVersion: mongodb.com/v1kind: MongoDBmetadata: name: shardspecificpodspec-migration namespace: mongodb-testspec: # There are 4 shards in this cluster, but the shardSpecificPodSpec field # doesn't need to have on entry per shard, it can have less shardCount: 4 mongodsPerShardCount: 2 mongosCount: 1 configServerCount: 3 topology: SingleCluster type: ShardedCluster version: 8.0.3 opsManager: configMapRef: name: my-project credentials: my-credentials persistent: true
shardPodSpec: # default persistence configuration for all shards in all clusters persistence: single: storage: "5G" shardSpecificPodSpec: # deprecated way of overriding shards (array) - persistence: # shard of index 0 single: storage: "6G" # Specify resources settings to enterprise database container in shard 0 podTemplate: spec: containers: - name: mongodb-enterprise-database resources: requests: cpu: 0.5 memory: 1G limits: cpu: 1.0 memory: 2.0G - persistence: # shard of index 1 single: storage: "7G" - persistence: # shard of index 2 single: storage: "7G"
# The below shardOverrides replicate the same shards configuration as the one # specified above in shardSpecificPodSpec shardOverrides: - shardNames: [ "shardspecificpodspec-migration-0" ] # overriding shard #0 podSpec: persistence: single: storage: "6G" statefulSet: spec: template: spec: containers: - name: mongodb-enterprise-database resources: requests: cpu: 0.5 memory: 1G limits: cpu: 1.0 memory: 2.0G
# The ShardSpecificPodSpec field above has the same configuration for shards # 1 and 2. It is possible to specify both shard names in the override and not # duplicate that configuration - shardNames: [ "shardspecificpodspec-migration-1", "shardspecificpodspec-migration-2" ] podSpec: persistence: single: storage: "7G"詳細については、 完全なファイルを確認してください 。
外部アクセスの構成
フィールド | どのクラスター | どのシャード |
|---|---|---|
| すべて | すべて |
| 1 つの | すべて |
| 1 つの | すべて |
メンバー、メンバー構成、追加の MongodConfig、エージェント構成
ShardedClusterSpec フィールド | を指定するには | に適用されます |
|---|---|---|
| 該当なし | 該当なし |
| 適用されます | 適用されます |
| 適用されます | 適用されます |
| 該当なし | 該当なし |
| 適用されます | 適用されます |
コンフィギュレーションサーバーの上書き
ShardedClusterSpec フィールド | を指定するには | に適用されます |
|---|---|---|
| 該当なし | 該当なし |
| 適用されます | 適用されます |
| 該当なし | 該当なし |
| 適用されます | 無視 |
| 該当なし | 適用されます |
configSrv: clusterSpecList: - clusterName: kind-e2e-cluster-1 members: 2 # The below statefulset override is applicable only to pods in kind-e2e-cluster-1 # Specs will be merged, the "request" field defined above will still be applied to containers in this cluster # However, limits will be replaced with below values, because clusterSpecList.statefulSet.spec.template has a # higher priority than configSrvPodSpec.podTemplate statefulSet: spec: template: spec: containers: - name: mongodb-enterprise-database resources: limits: cpu: 1.0 memory: 2.5G # In clusterSpecList.podSpec, only persistence field must be used, the podTemplate field is ignored. podSpec: # In kind-e2e-cluster-1, we replace the persistence settings defined in configSrvPodSpec persistence: multiple: journal: storage: "6G" data: storage: "7G" logs: storage: "6G" - clusterName: kind-e2e-cluster-2 members: 1 # doc-highlight-end: configSrv mongos: clusterSpecList: - clusterName: kind-e2e-cluster-1 members: 2 - clusterName: kind-e2e-cluster-2 members: 1
shard: clusterSpecList: - clusterName: kind-e2e-cluster-1 members: 2 - clusterName: kind-e2e-cluster-2 members: 1詳細については、 完全なファイルを確認してください 。
Mongos の上書き
ShardedClusterSpec フィールド | を指定するには | に適用されます |
|---|---|---|
| 該当なし | 該当なし |
| 適用されます | 該当なし |
| 該当なし | 適用されます |
| 無視 | 該当なし |
| 適用されます | 該当なし |