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, puede configurar los detalles de los fragmentos, Mongos y el servidor de configuración en diferentes niveles. Esto significa que puede definir una configuración predeterminada de nivel superior para los fragmentos, el servidor de configuración y Mongos, y personalizarla para cada clúster de Kubernetes de forma independiente. Además, es posible personalizar fragmentos individuales para adaptarlos a sus necesidades específicas.
Importante
La funcionalidad de clúster fragmentado de múltiples clústeres permite implementar recursos de MongoDB en múltiples clústeres de Kubernetes en múltiples regiones geográficas; sin embargo, esto probablemente aumentará la latencia de las operaciones de replicación.
Para obtener más información sobre las opciones de configuración específicas para la topología de clúster fragmentado de múltiples clústeres, consulte la referencia de clúster particionado.
Limitaciones
El soporte de 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 fallo de un clúster miembro, primero debe reducir manualmente los clústeres fallidos a cero para eliminar los procesos en mal estado. Después, puede redistribuir manualmente los recursos entre los clústeres de Kubernetes restantes en buen estado actualizando el recurso CRD implementado en el clúster del operador.Consulte Recuperación ante desastres para obtener más información.
Requisitos previos
Prepara tus clústeres de Kubernetes para una implementación multiclúster.
Instala y configura el Operador de Kubernetes para implementaciones multi-cluster en uno de tus clústeres de Kubernetes.
Opción 1: Implementar una malla de servicios en los clústeres nodos. Puedes encontrar un procedimiento detallado en los pasos 1 - 6 de la Guía de implementación de Ops Manager en múltiples clústeres. Tenga en cuenta que este procedimiento es subjetivo y es solo una de las muchas configuraciones posibles.
Opción:2 Configure sus clústeres de Kubernetes para una implementación de malla que no sea de servicio.
Implementar un mapa de configuración con detalles del proyecto de Ops Manager o Cloud Manager y MongoDB en tu clúster de operadores, que el Operador de Kubernetes requiere para implementar el recurso de la base de datos de MongoDB.
Cree credenciales para Ops, su instancia de Manager o Cloud Manager y su organización y proyecto de MongoDB.
Ejemplo de implementación de clúster fragmentado
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).
De forma predeterminada, el conjunto de réplicas de cada fragmento:
Tiene 3 miembros con derecho a voto en total implementados en 3 clústeres (1 nodos en cada clúster)
Se prefiere que el fragmento principal esté en
kind-e2e-cluster-1.
Con un
shardOverridepara el fragmentosc-0, cambiamos los valores predeterminados (especificados enspec.shard) a los siguientes:5 miembros en total
2 miembros en
kind-e2e-cluster-12 miembros en
kind-e2e-cluster-21 nodo en
kind-e2e-cluster-3Cuando 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.shardPodSpecUn conjunto de réplicas del servidor de configuración con 3 miembros, con 1 miembro 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
Sólo se admite el escalado unidireccional.
Al escalar un fragmento, un servidor de configuración o réplicas de Mongos, solo se pueden escalar los recursos verticalmente o horizontalmente para garantizar un escalado correcto. Esta regla se aplica tanto a implementaciones de un solo clúster de Kubernetes como a las distribuidas en varios clústeres. Además, en implementaciones multiclúster, la regla de escalado unidireccional se aplica a todos los tipos de recursos. Por ejemplo, no se pueden agregar más nodos (escalado vertical) a los fragmentos mientras se eliminan simultáneamente (escalado vertical) 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. En su lugar, primero se debe realizar una operación de escalado vertical y luego un cambio independiente para el escalado vertical.
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.
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
Anulaciones de fragmentos
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 fragmentos específicos en clústeres de Kubernetes específicos, puede usar anulaciones de fragmentos para actualizar la definición de fragmento base para un fragmento determinado.
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.
Personaliza la persistencia y los ajustes de StatefulSet
Campo ShardedClusterSpec | Especificar | Se aplica a |
|---|---|---|
| Persistencia y plantilla de pod | Todos los pods |
| Persistencia y plantilla de pod | Todos los pods |
| Persistencia (el campo Plantilla de Pod se ignora) | Todos los fragmentos del clúster |
| Pod Template | Todos los fragmentos del clúster |
| Persistencia (el campo Plantilla de Pod se ignora) | Todos los fragmentos del clúster |
| Pod Template | Una partición en el clúster |
| Persistencia (el campo Plantilla de Pod se ignora) | Una partición en un clúster específico |
| 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á obsoleto, deberías migrar a ShardOverrides.PodSpec, y ShardOverrides.StatefulSetConfiguration. Consulte el archivo YAML de ejemplo proporcionado para obtener orientación sobre la actualización de shardSpecificPodSpec y shardOverrides para implementaciones de un único clúster.
Anula la plantilla del pod y la configuración de persistencia en clusterSpecList
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.
Defina plantillas de pod personalizadas y configuraciones de persistencia con shardOverrides
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.
Migrar desde el campo obsoleto shardSpecificPodSpec
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 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"
Para obtener más información, puedes consultar el archivo completo.
Configuración de acceso externo
Campo | ¿Qué clústeres? | Qué particiones |
|---|---|---|
| Todo | Todo |
| uno | Todo |
| uno | Todo |
Miembros, MemberConfig, MongodConfig adicional, AgentConfig
Campo ShardedClusterSpec | Especificar | Se aplica a |
|---|---|---|
| no aplica | no aplica |
| aplicar | aplicar |
| aplicar | aplicar |
| no aplica | no aplica |
| aplicar | aplicar |
Anulaciones del servidor de configuración
Campo ShardedClusterSpec | Especificar | Se aplica a |
|---|---|---|
| no aplica | no aplica |
| aplicar | aplicar |
| no aplica | no aplica |
| aplicar | ignorado |
| 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.
Anulaciones de Mongos
Campo ShardedClusterSpec | Especificar | Se aplica a |
|---|---|---|
| no aplica | no aplica |
| aplicar | no aplica |
| no aplica | aplicar |
| ignorado | no aplica |
| aplicar | no aplica |