Join us Sept 17 at .local NYC! Use code WEB50 to save 50% on tickets. Learn more >
MongoDB Event
Docs Menu
Docs Home
/
Enterprise Kubernetes 演算子
/

マルチクラスターシャードクラスタ

MongoDBシャーディングされたクラスターは、複数のKubernetesクラスターに分散できます。マルチクラスター機能を使用すると、次のことが可能になります。

  • 配置の回復力を高めるには、それぞれが異なる地理的リージョンにある複数のKubernetesクラスターに分散する必要があります。

  • 指定されたシャードのプライマリ ノードを、そのデータに依存するアプリケーションまたはクライアントの近くに配置することで、地理Kubernetesシャーディング用に構成し、レイテンシを削減します。

  • パフォーマンスを向上させるには、配置を調整してください。例、 は、別のKubernetesクラスター内のすべてのシャードまたは指定されたシャードの読み取り専用分析ノードを、またはカスタマイズされたリソース割り当てを使用して配置できます。

さらに、シャード、mongos、コンフィギュレーションサーバーの詳細をさまざまなレベルで構成できます。つまり、シャード、コンフィギュレーションサーバー、mongos の最上位のデフォルト構成を定義し、 Kubernetesクラスターごとに個別にカスタマイズできます。さらに、特定のニーズに合わせて個々のシャードをカスタマイズすることもできます。

重要

マルチクラスターのシャーディングされたシャーディングされたクラスター機能により、複数の地理的リージョンの複数のKubernetesクラスターにMongoDBリソースを配置できます。ただし、そうすると、レプリケーション操作のレイテンシが増加する可能性があります。

マルチクラスターのシャーディングされたクラスターのトポロジーの具体的な構成オプションの詳細については、シャーディングされたクラスターの参照を参照してください。

  • Hashi書込み Vault サポートはKubernetes Secret インジェクションでは利用できません。

  • Kubernetes Operator は、障害のあるKubernetesクラスターから正常なクラスターにリソースを自動的に移行しません。ノード クラスターに障害が発生した場合は、中央クラスターに配置された CRDリソースを更新して、残りの正常なKubernetesクラスター全体にリソースを手動で再分配する必要があります。

  • ノードクラスターに障害が発生した場合は、まず障害クラスターを手動で 0 に増やすダウンして、正常でないプロセスを排除する必要があります。次に、中央クラスターに配置された CRDリソースを更新することで、残りの正常なKubernetesクラスターにリソースを手動で再分配できます。詳細については、「障害復旧」を参照してください。

以下の例では、中央クラスターに適用すると、次のように構成された 3 シャードを含むシャーディングされたMongoDBクラスターが配置されます。

  • 各シャードには、すべてのKubernetesクラスターに分散されたノードがあります(クラスターあたり 1ノード)。

  • デフォルトでは、各シャードのレプリカセットは次のようになります。

    • 3 クラスター(各クラスターの 1ノード)に配置された合計で 3 の投票ノードがある

    • プライマリシャードはkind-e2e-cluster-1 にあることが優先されます。

  • シャード sc-0shardOverride では、デフォルト値(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 が配置されているユーザーに最も関連するデータである場合は、レイテンシが低くなります。

1apiVersion: mongodb.com/v1
2kind: MongoDB
3metadata:
4 name: sc
5spec:
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 フィールド
を指定するには
に適用されます

spec.shardPodSpec

永続性と ポッド テンプレート

すべてのポッド

spec.shardSpecificPodSpec (非推奨)

永続性と ポッド テンプレート

すべてのポッド

spec.shard.clusterSpecList.podSpec

永続性(ポッド テンプレートフィールドは無視されます)

クラスター内のすべてのシャード

spec.shard.clusterSpecList.statefulSet

Pod Template

クラスター内のすべてのシャード

spec.shardOverrides.podSpec

永続性(ポッド テンプレートフィールドは無視されます)

クラスター内のすべてのシャード

spec.shardOverrides.statefulSet

Pod Template

クラスター内の 1 つのシャード

spec.shardOverrides.clusterSpecList.podSpec

永続性(ポッド テンプレートフィールドは無視されます)

特定のクラスター内の 1 つのシャード

spec.shardOverrides.clusterSpecList.statefulSet

Pod Template

特定のクラスター内の 1 つのシャード

注意

ShardSpecificPedSpec の廃止

ShardSpecificPodSpecフィールドは非推奨ですが、引き続きサポートされます。以前は、単一の シャーシャーディングされたクラスターのシャードごとに 永続性 と ポッド テンプレート パラメーターを指定するために使用されていました。ShardOverrides.PodSpec非推奨になったため、 とShardOverrides.StatefulSetConfiguration に移行する必要があります。単一クラスター配置の shardSpecificPodSpecshardOverrides からの更新に関するガイダンスについては、提供されている YAMLファイルの例を参照してください。

次の例では、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 でカスタム ポッド テンプレートと永続性設定を定義する方法を説明しています。

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フィールドから新しい 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
6apiVersion: mongodb.com/v1
7kind: MongoDB
8metadata:
9 name: shardspecificpodspec-migration
10 namespace: mongodb-test
11spec:
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"

詳細については、完全なファイルを確認してください

フィールド
どのクラスター
どのシャード

spec.externalAccess

すべて

すべて

spec.shard.externalAccess

1 つの

すべて

spec.shard.clusterSpecList.externalAccess

1 つの

すべて

ShardedClusterSpec フィールド
を指定するには
に適用されます

spec.shard

該当なし

該当なし

spec.shard.clusterSpecList

適用されます

適用されます

spec.shardOverrides (単一クラスターのみ)

適用されます

適用されます

spec.sharOverrides

該当なし

該当なし

spec.shardOverrides.clusterSpecList

適用されます

適用されます

ShardedClusterSpec フィールド
を指定するには
に適用されます

spec.configSrv

該当なし

該当なし

spec.configSrv

適用されます

適用されます

spec.configSrv.clusterSpecList

該当なし

該当なし

spec.configSrv.clusterSpecList.podSpec

適用されます

無視

spec.configSrv.clusterSpecList.statefulSet

該当なし

適用されます

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

詳細については、完全なファイルを確認してください

ShardedClusterSpec フィールド
を指定するには
に適用されます

ConfigSrvSpec

該当なし

該当なし

ConfigSrvPodSpec

適用されます

該当なし

ConfigSrvSpec.ClusterSpecList

該当なし

適用されます

ConfigSrvSpec.ClusterSpecList.PodSpec

無視

該当なし

ConfigSrvSpec.ClusterSpecList.StatefulSetConfiguration

適用されます

該当なし

戻る

Kubernetesの外部からの接続

項目一覧