Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

Clúster particionado multi-clúster

Puedes distribuir los clústeres fragmentados de MongoDB en varios clústeres de Kubernetes. Con la funcionalidad de múltiples clústeres, puedes:

  • Mejora la resiliencia de tu implementación distribuyéndolo en múltiples clústeres de Kubernetes, cada uno en una región geográfica diferente.

  • Configura tu implementación para particionado geográfico implementando nodos primarios de particiones específicas en diferentes clústeres de Kubernetes que estén ubicados más cerca de la aplicación o de los clientes que dependen de esos datos, reduciendo la latencia.

  • Optimiza tu implementación para mejorar el rendimiento. Por ejemplo, puedes implementar nodos analíticos de solo lectura para todas o algunas particiones en diferentes clústeres de Kubernetes, o con asignaciones de recursos personalizadas.

Además, puedes configurar los detalles de la partición, mongos y el servidor de configuración en diferentes niveles. Esto significa que puedes definir una configuración por defecto de nivel superior para particiones, el servidor de configuración y mongos, y personalizarla para cada clúster de Kubernetes de forma independiente. Además, es posible personalizar particiones individuales para adaptar a tus necesidades específicas.

Importante

La funcionalidad de clúster particionado multinodo permite implementar recursos de MongoDB en varios clústeres de Kubernetes en diversas regiones geográficas. Sin embargo, hacerlo probablemente aumente la latencia de las operaciones de replicación.

Para aprender más sobre las opciones de configuración específicas de la topología de clúster segmentado multi-clúster, consulta la referencia de clúster.

  • El soporte para Hashicorp Vault no está disponible para la inyección de secretos de Kubernetes.

  • El operador de Kubernetes no transfiere automáticamente los recursos de los clústeres de Kubernetes fallidos a otros saludables. En caso de que falle un clúster de nodos, debes redistribuir manualmente los recursos entre los clústeres de Kubernetes saludables restantes actualizando el recurso CRD implementado en el clúster de operadores.

  • En caso de un fallo en el clúster nodo, primero debe escalar manualmente a cero los clústeres que fallaron para remover los procesos no saludables. Luego puedes redistribuir los recursos manualmente entre los clústeres de Kubernetes restantes y saludables actualizando el recurso CRD desplegado en el clúster operador. Consulta Recuperación ante desastres para obtener más información.

Cuando se aplica a su clúster de operador, el siguiente ejemplo implementa un clúster de MongoDB particionado con 3 particiones que se configuran de la siguiente manera:

  • Cada partición tiene nodos distribuidos en todos los clústeres de Kubernetes (1 nodo por clúster).

  • Por defecto, el set de réplicas de cada partición:

    • Tiene 3 miembros con derecho a voto en total repartidos en 3 clústeres (1 nodo en cada clúster)

    • Se prefiere que la partición primaria esté en kind-e2e-cluster-1.

  • Con un shardOverride para la partición sc-0, cambiamos los valores por defecto (especificados en spec.shard) a los siguientes:

    • 5 miembros en total

    • 2 nodos en kind-e2e-cluster-1

    • 2 nodos en kind-e2e-cluster-2

    • 1 nodo en kind-e2e-cluster-3

    • Cuando sea posible, se prefiere que la partición primaria esté en kind-e2e-cluster-2

  • Configuraciones de almacenamiento por defecto personalizadas para todas las particiones en todos los clústeres, según lo definido en spec.shardPodSpec

  • Un set de réplicas de servidor de configuración con 3 nodos, con 1 nodo en cada clúster

  • 3 instancias mongos desplegadas en total, con 1 instancia en cada clúster

La configuración predeterminada consta de tres particiones, cada una con un nodo en cada uno de los tres clústeres, para un total de tres nodos por partición. Pero en las anulaciones cambiamos la partición sc-0 para que tenga cinco nodos: dos en el clúster 1, dos en el clúster 2 y el clúster 3 sigue teniendo una partición como por defecto.

Nota

Solo se admite el escalado unidireccional.

Cuando escale las réplicas de particiones, servers de configuración o mongos, solo puede escalar los recursos hacia arriba o hacia abajo para garantizar la exactitud del escalado. Esta regla se aplica tanto a implementaciones individuales de clústeres de Kubernetes como a aquellas que se distribuyen entre varios clústeres de Kubernetes. Además, en implementaciones de múltiples clústeres, la regla de escalado unidireccional se aplica a todos los tipos de recursos. Por ejemplo, no puedes agregar más nodos (escalando hacia arriba) a los shards mientras simultáneamente remueves (escalando hacia abajo) servidores de configuración o mongos. Ya no se puede "mover" un nodo de un clúster a otro sin cambiar el número total de miembros. Es decir, primero se debe realizar una operación de escalado y luego ejecutar un cambio por separado para reducir la escala.

Esta configuración de ejemplo también desplaza (con shardOverrides) el primario al clúster 2, para la partición sc-0, lo que puede reducir la latencia para los usuarios que operan en la región donde se encuentra el clúster 2. De este modo, sigue tendiendo resiliencia en los clústeres (y sus regiones), pero si los datos en partición 0 son los más relevantes para los usuarios en el clúster en el que se implementa 2, experimentarán una menor latencia.

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

Para implementar un clúster fragmentado en varios clústeres de Kubernetes, aplica la configuración de clúster fragmentado (archivo yaml de recurso personalizado de MongoDB) a tu clúster operador, es decir, el clúster de Kubernetes en el que se implementa tu instancia de MongoDB Operator. La definición spec.shard de esta configuración se considera la definición de partición base de tu implementación.

Si desea personalizar particiones específicas en clústeres específicos de Kubernetes, puede utilizar anulaciones de particiones para actualizar la definición básica de partición para una partición determinada.

Las siguientes tablas enumeran los campos que se pueden definir para actualizar o ampliar la definición base de partición. Los campos se enumeran en orden de precedencia. El campo más alto en una tabla dada representa el ajuste con la prioridad más baja, y el campo más bajo, si está definido, sobrescribe todos los demás campos (por ejemplo, partición específica, en un clúster específico).

Además, la política de anulación indicada para cada tipo de campo describe si ese campo específico se anula con el valor recién definido, o si se anula el objeto completo en el que se define ese campo. Si se reemplaza el objeto completo, se eliminan todos los campos definidos en la definición base de partición que no se definan explícitamente también en la definición de reemplazo.El valor merge indica que se actualiza un solo campo, y el valor replace indica que se sobreescribe el objeto principal completo.

Campo ShardedClusterSpec
Especificar
Se aplica a

spec.shardPodSpec

Persistencia y plantilla de pod

Todos los pods

spec.shardSpecificPodSpec (deprecated)

Persistencia y plantilla de pod

Todos los pods

spec.shard.clusterSpecList.podSpec

Persistencia (el campo de plantilla Pod se ignora)

Todas las particiones en el clúster

spec.shard.clusterSpecList.statefulSet

Pod Template

Todas las particiones en el clúster

spec.shardOverrides.podSpec

Persistencia (el campo de plantilla Pod se ignora)

Todas las particiones en el clúster

spec.shardOverrides.statefulSet

Pod Template

Una partición en el clúster

spec.shardOverrides.clusterSpecList.podSpec

Persistencia (el campo de plantilla Pod se ignora)

Una partición en un clúster específico

spec.shardOverrides.clusterSpecList.statefulSet

Pod Template

Una partición en un clúster específico

Nota

Obsolescencia de ShardSpecificPodSpec

El campo ShardSpecificPodSpec está obsoleto, pero aún es compatible. Anteriormente se utilizaba para especificar la Persistencia y los parámetros de la Plantilla de Pods, por cada partición, para un clúster particionado de clúster único. Ahora que está en desuso, debes migrar a ShardOverrides.PodSpec y ShardOverrides.StatefulSetConfiguration. Consulte el archivo YAML de ejemplo proporcionado para recibir orientación sobre cómo actualizar desde shardSpecificPodSpec y shardOverrides para implementaciones de clúster único.

El siguiente ejemplo ilustra cómo sobrescribir plantillas de pods personalizadas y configuraciones de persistencia en 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

Para obtener más información, puedes consultar el archivo completo.

El siguiente ejemplo ilustra cómo definir plantillas de pods personalizadas y configuraciones de persistencia en 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"

Para obtener más información, puedes consultar el archivo completo.

El siguiente ejemplo ilustra cómo actualizar del campo obsoleto shardSpecificPodSpec al nuevo campo 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"

Para obtener más información, puedes consultar el archivo completo.

Campo
Qué clústeres
Qué particiones

spec.externalAccess

Todo

Todo

spec.shard.externalAccess

uno

Todo

spec.shard.clusterSpecList.externalAccess

uno

Todo

Campo ShardedClusterSpec
Especificar
Se aplica a

spec.shard

no aplica

no aplica

spec.shard.clusterSpecList

aplicar

aplicar

spec.shardOverrides (solo un clúster)

aplicar

aplicar

spec.sharOverrides

no aplica

no aplica

spec.shardOverrides.clusterSpecList

aplicar

aplicar

Campo ShardedClusterSpec
Especificar
Se aplica a

spec.configSrv

no aplica

no aplica

spec.configSrv

aplicar

aplicar

spec.configSrv.clusterSpecList

no aplica

no aplica

spec.configSrv.clusterSpecList.podSpec

aplicar

ignorado

spec.configSrv.clusterSpecList.statefulSet

no aplica

aplicar

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

Para obtener más información, puedes consultar el archivo completo.

Campo ShardedClusterSpec
Especificar
Se aplica a

ConfigSrvSpec

no aplica

no aplica

ConfigSrvPodSpec

aplicar

no aplica

ConfigSrvSpec.ClusterSpecList

no aplica

aplicar

ConfigSrvSpec.ClusterSpecList.PodSpec

ignorado

no aplica

ConfigSrvSpec.ClusterSpecList.StatefulSetConfiguration

aplicar

no aplica

Volver

Conéctate desde fuera de Kubernetes

En esta página