MongoDBシャーディングされたクラスターは、複数のKubernetesクラスターに分散できます。マルチクラスター機能を使用すると、次のことが可能になります。
配置の回復力を高めるには、それぞれが異なる地理的リージョンにある複数のKubernetesクラスターに分散する必要があります。
指定されたシャードのプライマリ ノードを、そのデータに依存するアプリケーションまたはクライアントの近くに配置することで、地理Kubernetesシャーディング用に構成し、レイテンシを削減します。
パフォーマンスを向上させるには、配置を調整してください。例、 は、別のKubernetesクラスター内のすべてのシャードまたは指定されたシャードの読み取り専用分析ノードを、またはカスタマイズされたリソース割り当てを使用して配置できます。
さらに、シャード、mongos、コンフィギュレーションサーバーの詳細をさまざまなレベルで構成できます。つまり、シャード、コンフィギュレーションサーバー、mongos の最上位のデフォルト構成を定義し、 Kubernetesクラスターごとに個別にカスタマイズできます。さらに、特定のニーズに合わせて個々のシャードをカスタマイズすることもできます。
重要
マルチクラスターのシャーディングされたシャーディングされたクラスター機能により、複数の地理的リージョンの複数のKubernetesクラスターにMongoDBリソースを配置できます。ただし、そうすると、レプリケーション操作のレイテンシが増加する可能性があります。
マルチクラスターのシャーディングされたクラスターのトポロジーの具体的な構成オプションの詳細については、シャーディングされたクラスターの参照を参照してください。
制限
Hashi書込み Vault サポートはKubernetes Secret インジェクションでは利用できません。
Kubernetes Operator は、障害のあるKubernetesクラスターから正常なクラスターにリソースを自動的に移行しません。ノード クラスターに障害が発生した場合は、中央クラスターに配置された CRDリソースを更新して、残りの正常なKubernetesクラスター全体にリソースを手動で再分配する必要があります。
ノードクラスターに障害が発生した場合は、まず障害クラスターを手動で 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データベースリソースを配置するために必要です。
Manager またはCloud Managerインスタンスと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.shardPodSpec
3 ノード(各クラスターに 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
が配置されているユーザーに最も関連するデータである場合は、レイテンシが低くなります。
1 apiVersion: mongodb.com/v1 2 kind: MongoDB 3 metadata: 4 name: sc 5 spec: 6 topology: MultiCluster 7 type: ShardedCluster 8 # this deployment will have 3 shards 9 shardCount: 3 10 # you cannot specify mongodsPerShardCount, configServerCount and mongosCount 11 # in MultiCluster topology 12 version: 8.0.3 13 opsManager: 14 configMapRef: 15 name: my-project 16 credentials: my-credentials 17 persistent: true 18 19 shardPodSpec: # applies to all shards on all clusters 20 persistence: 21 single: 22 # all pods for all shards on all clusters will use that storage size in their 23 # PersistentVolumeClaim unless overridden in spec.shard.clusterSpecList or 24 # spec.shardOverrides. 25 storage: 10G 26 27 configSrvPodSpec: # applies to all config server nodes in all clusters 28 persistence: 29 multiple: 30 data: 31 storage: 2G 32 journal: 33 storage: 1G 34 logs: 35 storage: 1G 36 37 # consider this section as a default configuration for ALL shards 38 shard: 39 clusterSpecList: 40 - clusterName: kind-e2e-cluster-1 41 # each shard will have only one mongod process deployed in this cluster 42 members: 1 43 memberConfig: 44 - votes: 1 45 priority: "20" # we increase the priority to have primary in this cluster 46 - clusterName: kind-e2e-cluster-2 47 # one member in this cluster, no votes and priority defined means it'll get 48 # the default values votes=1, priority="1" 49 members: 1 50 - clusterName: kind-e2e-cluster-3 51 members: 1 # one member in this cluster 52 53 shardOverrides: # here you specify customizations for specific shards 54 # here you specify to which shard names the following configuration will 55 # apply 56 - shardNames: 57 - sc-0 58 clusterSpecList: 59 - clusterName: kind-e2e-cluster-1 60 # all fields here are optional 61 # shard "sc-0" will have two members instead of one, which was defined as the 62 # default for all shards in spec.shard.clusterSpecList[0].members 63 members: 2 64 memberConfig: 65 - votes: 1 66 # shard "sc-0" should not have primary in this cluster like every other shard 67 priority: "1" 68 - votes: 1 69 priority: "1" 70 - clusterName: kind-e2e-cluster-2 71 members: 2 # shard "sc-0" will have two members instead of one 72 memberConfig: 73 - votes: 1 74 # both processes of shard "sc-0" in this cluster will have the same 75 # likelihood to become a primary member 76 priority: "20" 77 - votes: 1 78 priority: "20" 79 # We need to specify the list of all clusters on which this shard will be 80 # deployed. 81 - clusterName: kind-e2e-cluster-3 82 # If the clusterName element is omitted here, it will be considered as an 83 # override for this shard, so that the operator shouldn't deploy any member 84 # to it. 85 # No fields are mandatory in here, though. In case a field is not set, it's 86 # not overridden and the default value is taken from a top level spec.shard 87 # settings. 88 89 configSrv: 90 # the same configuration fields are available as in 91 # spec.shard.clusterSpecList. 92 clusterSpecList: 93 - clusterName: kind-e2e-cluster-1 94 members: 1 95 - clusterName: kind-e2e-cluster-2 96 members: 1 97 - clusterName: kind-e2e-cluster-3 98 members: 1 99 100 mongos: 101 # the same configuration fields are available as in 102 # spec.shard.clusterSpecList apart from storage and replica-set related 103 # fields. 104 clusterSpecList: 105 - clusterName: kind-e2e-cluster-1 106 members: 1 107 - clusterName: kind-e2e-cluster-2 108 members: 1 109 - clusterName: kind-e2e-cluster-3 110 members: 1
シャード オーバーライド
シャーディングされたクラスターを複数のKubernetesクラスターに配置するには、シャーディングされたクラスター構成(MongoDBカスタムリソースYAML)を演算子クラスター( MongoDB Operatorインスタンスが配置される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
でカスタム ポッド テンプレートと永続性設定を無効にする方法を説明しています。
1 shardPodSpec: # applicable to all shards in all clusters 2 persistence: 3 single: 4 storage: "5G" 5 podTemplate: 6 spec: 7 containers: 8 - name: mongodb-enterprise-database 9 resources: 10 requests: 11 cpu: 0.5 12 memory: 1.0G 13 limits: 14 cpu: 1.0 15 memory: 2.0G 16 shard: 17 clusterSpecList: 18 - clusterName: kind-e2e-cluster-1 19 members: 2 20 # The below statefulset override is applicable only to pods in kind-e2e-cluster-1 21 # Specs will be merged, the "request" field defined above will still be 22 # applied to containers in this cluster. 23 # However, limits will be replaced with below values, because 24 # clusterSpecList.statefulSet.spec.template has a 25 # higher priority than shardPodSpec.podTemplate 26 statefulSet: 27 spec: 28 template: 29 spec: 30 containers: 31 - name: mongodb-enterprise-database 32 resources: 33 limits: 34 cpu: 1.0 35 memory: 2.5G 36 # In clusterSpecList.podSpec, only persistence field must be used, the 37 # podTemplate field is ignored. 38 # In kind-e2e-cluster-1, we replace the persistence settings defined in 39 # shardPodSpec 40 podSpec: 41 persistence: 42 multiple: 43 journal: 44 storage: "6G" 45 data: 46 storage: "7G" 47 logs: 48 storage: "6G" 49 - clusterName: kind-e2e-cluster-2 50 members: 1
詳細については、完全なファイルを確認してください。
を使用してカスタム ポッド テンプレートと永続性設定を定義します shardOverrides
次の例では、shardOverrides
でカスタム ポッド テンプレートと永続性設定を定義する方法を説明しています。
1 # In clusterSpecList.podSpec, only persistence field must be used, the 2 # podTemplate field is ignored. 3 # In kind-e2e-cluster-1, we define custom persistence settings 4 podSpec: 5 persistence: 6 multiple: 7 journal: 8 storage: "5G" 9 data: 10 storage: "5G" 11 logs: 12 storage: "5G" 13 - clusterName: kind-e2e-cluster-2 14 members: 1 15 16 shardOverrides: 17 - shardNames: [ "pod-template-shards-1-2" ] 18 # This override will apply to shard of index 2 19 # Statefulset settings defined at this level (shardOverrides.statefulSet) 20 # apply to members of shard 2 in ALL clusters. 21 # This field has higher priority than shard.clusterSpecList.statefulSet, but 22 # lower than shardOverrides.clusterSpecList.statefulSet 23 # It has a merge policy, which means that the limits defined above for the 24 # mongodb-enterprise-database container field still apply to all members in 25 # that shard, except if overridden. 26 statefulSet: 27 spec: 28 template: 29 spec: 30 containers: 31 - name: sidecar-shard-2 32 image: busybox 33 command: [ "sleep" ] 34 args: [ "infinity" ] 35 clusterSpecList: 36 - clusterName: kind-e2e-cluster-1 37 members: 2 38 - clusterName: kind-e2e-cluster-2 39 members: 1 40 # The below statefulset override is applicable only to members of shard 2, in cluster 1 41 # Specs will be merged, the "limits" field defined above will still be applied 42 # to containers in this cluster together with the requests field below. 43 statefulSet: 44 spec: 45 template: 46 spec: 47 containers: 48 - name: mongodb-enterprise-database 49 resources: 50 requests: # We add a requests field in shard 2, cluster 1 51 cpu: 0.5 52 memory: 1.0G 53 54 podSpec: 55 # In shardOverrides.clusterSpecList.podSpec, only persistence field must be 56 # used, the podTemplate field is ignored. 57 persistence: # we assign additional disk resources in shard 2, cluster 1 58 multiple: 59 journal: 60 storage: "6G" 61 data: 62 storage: "6G" 63 logs: 64 storage: "6G"
詳細については、完全なファイルを確認してください。
非推奨の shardSpecificPodSpec
フィールドからの移行
次の例では、非推奨の shardSpecificPodSpec
フィールドから新しい shardOverrides
フィールドに更新する方法を説明しています。
1 # This file is an example of how to migrate from the old deprecated 2 # ShardSpecificPodSpec field to the new shardOverrides fields 3 # for single cluster deployments. 4 # The settings specified in shardOverrides are the exact equivalent to the 5 # ones in shardSpecificPodSpec, showing how to replicate them 6 apiVersion: mongodb.com/v1 7 kind: MongoDB 8 metadata: 9 name: shardspecificpodspec-migration 10 namespace: mongodb-test 11 spec: 12 # There are 4 shards in this cluster, but the shardSpecificPodSpec field 13 # doesn't need to have on entry per shard, it can have less 14 shardCount: 4 15 mongodsPerShardCount: 2 16 mongosCount: 1 17 configServerCount: 3 18 topology: SingleCluster 19 type: ShardedCluster 20 version: 8.0.3 21 opsManager: 22 configMapRef: 23 name: my-project 24 credentials: my-credentials 25 persistent: true 26 27 shardPodSpec: 28 # default persistence configuration for all shards in all clusters 29 persistence: 30 single: 31 storage: "5G" 32 shardSpecificPodSpec: # deprecated way of overriding shards (array) 33 - persistence: # shard of index 0 34 single: 35 storage: "6G" 36 # Specify resources settings to enterprise database container in shard 0 37 podTemplate: 38 spec: 39 containers: 40 - name: mongodb-enterprise-database 41 resources: 42 requests: 43 cpu: 0.5 44 memory: 1G 45 limits: 46 cpu: 1.0 47 memory: 2.0G 48 - persistence: # shard of index 1 49 single: 50 storage: "7G" 51 - persistence: # shard of index 2 52 single: 53 storage: "7G" 54 55 # The below shardOverrides replicate the same shards configuration as the one 56 # specified above in shardSpecificPodSpec 57 shardOverrides: 58 - shardNames: [ "shardspecificpodspec-migration-0" ] # overriding shard #0 59 podSpec: 60 persistence: 61 single: 62 storage: "6G" 63 statefulSet: 64 spec: 65 template: 66 spec: 67 containers: 68 - name: mongodb-enterprise-database 69 resources: 70 requests: 71 cpu: 0.5 72 memory: 1G 73 limits: 74 cpu: 1.0 75 memory: 2.0G 76 77 # The ShardSpecificPodSpec field above has the same configuration for shards 78 # 1 and 2. It is possible to specify both shard names in the override and not 79 # duplicate that configuration 80 - shardNames: [ "shardspecificpodspec-migration-1", "shardspecificpodspec-migration-2" ] 81 podSpec: 82 persistence: 83 single: 84 storage: "7G"
詳細については、完全なファイルを確認してください。
外部アクセスの構成
フィールド | どのクラスター | どのシャード |
---|---|---|
| すべて | すべて |
| 1 つの | すべて |
| 1 つの | すべて |
メンバー、メンバー構成、追加の MongodConfig、エージェント構成
ShardedClusterSpec フィールド | を指定するには | に適用されます |
---|---|---|
| 該当なし | 該当なし |
| 適用されます | 適用されます |
| 適用されます | 適用されます |
| 該当なし | 該当なし |
| 適用されます | 適用されます |
コンフィギュレーションサーバーの上書き
ShardedClusterSpec フィールド | を指定するには | に適用されます |
---|---|---|
| 該当なし | 該当なし |
| 適用されます | 適用されます |
| 該当なし | 該当なし |
| 適用されます | 無視 |
| 該当なし | 適用されます |
1 configSrv: 2 clusterSpecList: 3 - clusterName: kind-e2e-cluster-1 4 members: 2 5 # The below statefulset override is applicable only to pods in kind-e2e-cluster-1 6 # Specs will be merged, the "request" field defined above will still be applied to containers in this cluster 7 # However, limits will be replaced with below values, because clusterSpecList.statefulSet.spec.template has a 8 # higher priority than configSrvPodSpec.podTemplate 9 statefulSet: 10 spec: 11 template: 12 spec: 13 containers: 14 - name: mongodb-enterprise-database 15 resources: 16 limits: 17 cpu: 1.0 18 memory: 2.5G 19 # In clusterSpecList.podSpec, only persistence field must be used, the podTemplate field is ignored. 20 podSpec: # In kind-e2e-cluster-1, we replace the persistence settings defined in configSrvPodSpec 21 persistence: 22 multiple: 23 journal: 24 storage: "6G" 25 data: 26 storage: "7G" 27 logs: 28 storage: "6G" 29 - clusterName: kind-e2e-cluster-2 30 members: 1 31 # doc-highlight-end: configSrv 32 mongos: 33 clusterSpecList: 34 - clusterName: kind-e2e-cluster-1 35 members: 2 36 - clusterName: kind-e2e-cluster-2 37 members: 1 38 39 shard: 40 clusterSpecList: 41 - clusterName: kind-e2e-cluster-1 42 members: 2 43 - clusterName: kind-e2e-cluster-2 44 members: 1
詳細については、完全なファイルを確認してください。
Mongos の上書き
ShardedClusterSpec フィールド | を指定するには | に適用されます |
---|---|---|
| 該当なし | 該当なし |
| 適用されます | 該当なし |
| 該当なし | 適用されます |
| 無視 | 該当なし |
| 適用されます | 該当なし |