Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
See how MongoDB 9.0 delivers up to 2x higher throughput.
MongoDB Branding Shape
Register now >
Docs Menu

Implementar un clúster particionado

Nota

En cualquier lugar de esta página donde diga Ops Manager, puedes sustituir Cloud Manager.

Importante

  • Puedes usar el Operador de Kubernetes para implementar recursos de MongoDB con Cloud Manager y con Ops Manager versión 6.0.x o posterior.

  • Puedes usar el Atlas Operator para implementar recursos de MongoDB en Atlas.

Advertencia

El operador de Kubernetes no es compatible con nodos árbitros.

cluster fragmentado proporciona escalado horizontal para conjuntos de datos grandes y posibilita operaciones de alto rendimiento a través de la distribución del conjunto de datos entre un grupo de servidores.

Para aprender más sobre particionado, consulta Introducción al particionado en el manual de MongoDB.

Utiliza este procedimiento para implementar un nuevo clúster particionado que Ops Manager gestiona. Posteriormente, puede usar Ops Manager para agregar particiones y realizar otras operaciones de mantenimiento en el clúster.

Debido a la traducción de red de Kubernetes, un agente de supervisión fuera de Kubernetes no puede supervisar instancias de MongoDB dentro de Kubernetes. Por esta razón, no se admiten implementaciones k8s y no k8s en el mismo proyecto. Utiliza proyectos separados.

Cuando implemente su clúster fragmentado a través del Operador de Kubernetes, debe elegir si cifra las conexiones utilizando certificados TLS.

El siguiente procedimiento para TLS-Encrypted conexiones:

  • Establece conexiones TLS-cifradas entre particiones del clúster.

  • Establece conexiones cifradas mediante TLSentre aplicaciones cliente y implementaciones de MongoDB.

  • Requiere certificados válidos para el cifrado TLS.

El siguiente procedimiento para Non-Encrypted Connections:

  • No cifra las conexiones entre particiones del clúster.

  • No cifra las conexiones entre las aplicaciones cliente y las implementaciones de MongoDB.

  • Tiene menos requisitos de configuración que una implementación con conexiones cifradas TLS.

Nota

No puedes asegurar una instancia autónoma de MongoDB en un clúster de Kubernetes.

Para configurar el TLS cifrado para un conjunto de réplicas, consulte Implementar un conjunto de réplicas.

Seleccione la pestaña apropiada dependiendo de si desea cifrar sus conexiones de set de réplicas con TLS.

Para implementar un clúster particionado utilizando un objeto, debes:

Nota

Para evitar almacenar secretos en implementaciones de Kubernetes de un solo clúster, puedes migrar todos los secretos a una herramienta de almacenamiento de secretos. Las implementaciones en múltiples clústeres de Kubernetes no admiten el almacenamiento de secretos en herramientas de almacenamiento de secretos, como HashiCorp Vault.

  • Genera un certificado TLS para cada uno de los siguientes componentes:

    • Cada partición en su clúster. Asegúrese de agregar SANes para cada pod de Kubernetes que aloje un nodo de la partición al certificado.

      En tus certificados TLS, el SAN para cada pod partición debe utilizar el siguiente formato:

      <pod-name>.<metadata.name>-sh.<namespace>.svc.cluster.local
    • Tus servidores de configuración. Asegúrese de agregar SANs para cada pod de Kubernetes que aloje sus servidores de configuración al certificado.

      En tus certificados TLS, el SAN para cada pod de servidor de configuración debe usar el siguiente formato:

      <pod-name>.<metadata.name>-cs.<namespace>.svc.cluster.local
    • Sus instancias mongos. Asegúrese de agregar SANpara cada pod de Kubernetes que aloje una instancia mongos al certificado.

      En sus certificados TLS, el SAN para cada pod mongos debe usar este formato:

      <pod-name>.<metadata.name>-svc.<namespace>.svc.cluster.local
    • El MongoDB Agent de tu proyecto. Para el certificado del agente MongoDB, asegúrese de cumplir los siguientes requisitos:

      • El Nombre común en el certificado TLS no está vacío.

      • El conjunto de Organización y Unidad Organizacional en cada certificado TLS difiere del conjunto de Organización y Unidad Organizacional en el certificado TLS para los miembros del set de réplicas.

  • Debes tener en tu poder el certificado CA y la clave que has utilizado para firmar tus certificados TLS.

Importante

El Operador de Kubernetes utiliza kubernetes.io/tls secretos para almacenar certificados TLS y llaves privadas para recursos de Ops Manager y MongoDB. A partir de la versión 1.17.0 del operador de Kubernetes, el operador de Kubernetes ya no admite archivos PEM concatenados almacenados como secretos opacos.

Para implementar un clúster particionado utilizando un objeto, debes:

Nota

Para evitar almacenar secretos en implementaciones de Kubernetes de un solo clúster, puedes migrar todos los secretos a una herramienta de almacenamiento de secretos. Las implementaciones en múltiples clústeres de Kubernetes no admiten el almacenamiento de secretos en herramientas de almacenamiento de secretos, como HashiCorp Vault.

1

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los comandos de kubectl en el namespace que creó.

Nota

Si estás implementando un recurso de Ops Manager en una implementación de MongoDB multidispositivo en clústeres de Kubernetes:

  • Defina context como el nombre del clúster operador, por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Establece el --namespace en el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo: kubectl config --namespace "mongodb".

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Ejecuta este comando kubectl para crear un nuevo secreto que almacene los certificados de las particiones del clúster:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-0-cert \
--cert=<shard-0-tls-cert> \
--key=<shard-0-tls-key>
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-cert \
--cert=<shard-1-tls-cert> \
--key=<shard-1-tls-key>

Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.

3

Ejecute este comando kubectl para crear un nuevo secreto que almacene el certificado de los servidores de configuración del clúster fragmentado:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-cert \
--cert=<config-tls-cert> \
--key=<config-tls-key>

Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.

4

Ejecute este comando kubectl para crear un nuevo secreto que almacene el clúster fragmentado mongos certificado:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-mongos-cert \
--cert=<mongos-tls-cert> \
--key=<mongos-tls-key>

Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.

5

Ejecute este comando kubectl para crear un nuevo secreto que almacene el certificado TLS del agente:

kubectl create secret tls <prefix>-<metadata.name>-agent-certs \
--cert=<agent-tls-cert> \
--key=<agent-tls-key>

Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.

6

Ejecute este comando kubectl para vincular su CA a su clúster fragmentado y especifique el archivo de certificado de CA que siempre debe nombrar ca-pem para el recurso MongoDB:

kubectl create configmap custom-ca --from-file=ca-pem=<your-custom-ca-file>
7

Cambie la configuración de este archivo YAML para que coincida con la configuración de su clúster.

Cambia la configuración para que coincida con la configuración deseada del clúster fragmentado.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5 name: <my-sharded-cluster>
6spec:
7 shardCount: 2
8 mongodsPerShardCount: 3
9 mongosCount: 2
10 configServerCount: 3
11 version: "8.0.0"
12 opsManager:
13 configMapRef:
14 name: <configMap.metadata.name>
15 # Must match metadata.name in ConfigMap file
16 credentials: <mycredentials>
17 type: ShardedCluster
18 persistent: true
19...
19 security:
20 tls:
21 ca: <custom-ca>
22 certsSecretPrefix: <prefix>
23...
8

Abre tu editor de texto preferido y pega la especificación del objeto en un nuevo archivo de texto.

9
Clave
Tipo
Descripción
Ejemplo

string

Etiqueta para este clúster objeto de Kubernetes.

Los nombres de recursos deben tener 44 caracteres o menos.

Para aprender más, consulta metadata.name y la documentación de Kubernetes sobre nombres.

myproject

entero

Cantidad de particiones a implementar.

2

entero

Número de nodos de partición por partición.

3

entero

Número de routers de particiones que se van a implementar.

2

entero

Número de nodos del set de réplicas del servidor de configuración.

3

string

Versión de MongoDB que debería ejecutar este clúster.

El formato debe ser X.Y.Z para la Community Edition y X.Y.Z-ent para la edición Enterprise.

IMPORTANTE: Asegúrate de elegir una versión compatible del servidor MongoDB. Las versiones compatibles varían según la imagen base que utiliza el recurso de la base de datos MongoDB.

Para obtener más información sobre el versionado de MongoDB, consulta versionado de MongoDB en el manual de MongoDB.

Para obtener los mejores resultados, utilice la última versión disponible de MongoDB Enterprise que sea compatible con su versión de Ops Manager.

string

Nombre del ConfigMap con la configuración de conexión de Ops Manager. La configuración spec.cloudManager.configMapRef.name es un alias de esta configuración y se puede usar en su lugar.

Este valor debe existir en el mismo espacio de nombres que el recurso que quieres crear.

IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio en el ConfigMap y reconcilia el estado del recurso MongoDB.

<myproject>

string

Nombre del secreto que creaste como Ops Manager API credenciales de autenticación para que el operador de Kubernetes pueda comunicarse con Ops Manager.

El objeto secreto de Kubernetes de Ops Manager que contiene las credenciales debe estar en el mismo namespace que el recurso que se quiere crear.

IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio realizado en el Secreto y reconcilia el estado del recurso MongoDB.

<mycredentials>

string

Tipo de recurso MongoDB que se va a crear.

ShardedCluster

string

Opcional.

Indicador que muestra si este recurso MongoDB debe usar Los volúmenes persistentes para almacenamiento. Los volúmenes persistentes no se eliminan cuando el recurso MongoDB se detiene o se reinicia.

Si este valor es true, entonces los siguientes valores se establecen en su valor por defecto de 16Gi:

Para cambiar la <a class=\" \" target=\" \"href=\" \" rel=\"noopener noreferrer\"> Solicitud de volumen persistente <svg class=\" \" height=\" \" width=\" \" role=\" \" aria-hidden=\" \" alt=\" \" viewbox=\" \"><path d=\" \" fill=\" \"> <path d=\" \" fill=\" \"> configuración, configura las siguientes colecciones para cumplir con tus requisitos de implementación:

ADVERTENCIA: Otorga a tus contenedores permiso para guardar en tu volumen persistente. El operador de Kubernetes establece fsGroup = 2000, runAsUser = 2000 y runAsNonRoot = true en securityContext. El Kubernetes Operator establece fsgroup igual a runAsUser para que el volumen sea escribible para un usuario que ejecute el proceso principal en el contenedor. Para obtener más información, consulte Configuración de un contexto de seguridad para un pod o un contenedor y el debate relacionado en la documentación de Kubernetes. Si volver a implementar el recurso no resuelve los problemas con tu Volumen Persistente, comunícate con el Soporte de MongoDB.

Si no usas Volúmenes persistentes, los gráficos Disk Usage y Disk IOPS no se pueden mostrar ni en la pestaña Processes en la página Deployment, ni en la página Metrics al revisar los datos de esta implementación.

true

10

Para habilitar TLS en su implementación, configure los siguientes ajustes en su objeto de Kubernetes:

Clave
Tipo
Necesidad
Descripción
Ejemplo

spec.security
.tls.ca

string

Requerido

Agrega el nombre del ConfigMap que almacena la CA personalizada que usaste para firmar los certificados TLS de tu implementación.

<custom-ca>

spec.security
.certsSecretPrefix

string

Requerido

Agrega el <prefix> del nombre secreto que contiene los certificados TLS de tu implementación de MongoDB.

Por ejemplo, si llama a su despliegue my-deployment y establece el prefijo en mdb, debe nombrar el secreto TLS para las comunicaciones TLS del cliente como mdb-my-deployment-cert. Además, debe nombrar el secreto TLS para la autenticación interna del clúster (si está habilitada) como mdb-my-deployment-clusterfile.

devDb

11

También puede agregar cualquiera de los siguientes ajustes opcionales al archivo de especificaciones objeto para una implementación de clúster:

Advertencia

Debe establecer spec.clusterDomain si su clúster Kubernetes tiene un dominio por defecto diferente al por defecto cluster.local. Si no utilizas la opción por defecto ni estableces la opción spec.clusterDomain, el Operador Kubernetes podría no funcionar como se espera.

For config server

Para enrutadores de particiones

Para los nodos de la partición

12
13

Ejecute el siguiente comando de Kubernetes para crear su clúster fragmentado:

kubectl apply -f <sharded-cluster-conf>.yaml

Verifica el registro después de ejecutar este comando. Si la creación fue exitosa, deberías ver un mensaje similar al siguiente:

2018-06-26T10:30:30.346Z INFO operator/shardedclusterkube.go:52 Created! {"sharded cluster": "my-sharded-cluster"}
14

Para verificar el estado de su MongoDB recurso, utilice el siguiente comando:

kubectl get mdb <resource-name> -o yaml -w

Con la bandera -w (observar) activada, cuando la configuración cambia, la salida se actualiza inmediatamente hasta que la fase de estado alcanza el estado Running. Para obtener más información sobre el estado de implementación de recursos, consulta Solucionar problemas con el operador de Kubernetes.

Después de cifrar tu recurso de base de datos con TLS, puedes proteger lo siguiente:

Renueva sus certificados TLS periódicamente utilizando el siguiente procedimiento:

1

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los comandos de kubectl en el namespace que creó.

Nota

Si estás implementando un recurso de Ops Manager en una implementación de MongoDB multidispositivo en clústeres de Kubernetes:

  • Defina context como el nombre del clúster operador, por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Establece el --namespace en el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo: kubectl config --namespace "mongodb".

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Ejecute este comando kubectl para renovar un secreto existente que almacena los certificados de las particiones del clúster fragmentado:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-0-cert \
--cert=<shard-0-tls-cert> \
--key=<shard-0-tls-key> \
--dry-run=client \
-o yaml |
kubectl apply -f -
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-cert \
--cert=<shard-1-tls-cert> \
--key=<shard-1-tls-key> \
--dry-run=client \
-o yaml |
kubectl apply -f -
3

Ejecuta este comando kubectl para renovar un secreto que almacena los certificados del servidor de configuración del clúster fragmentado:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-cert \
--cert=<config-tls-cert> \
--key=<config-tls-key> \
--dry-run=client \
-o yaml |
kubectl apply -f -
4

Ejecute este comando kubectl para renovar un secret existente que almacene los certificados de mongos del clúster sharded:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-mongos-cert \
--cert=<mongos-tls-cert> \
--key=<mongos-tls-key> \
--dry-run=client \
-o yaml |
kubectl apply -f -
1

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los comandos de kubectl en el namespace que creó.

Nota

Si estás implementando un recurso de Ops Manager en una implementación de MongoDB multidispositivo en clústeres de Kubernetes:

  • Defina context como el nombre del clúster operador, por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Establece el --namespace en el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo: kubectl config --namespace "mongodb".

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Cambie la configuración de este archivo YAML para que coincida con la configuración de su clúster.

Este es un archivo YAML que puedes modificar para adaptarlo a la configuración que desees. Cambia la configuración para que coincida con la configuración deseada del clúster fragmentado.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5 name: <my-sharded-cluster>
6spec:
7 shardCount: 2
8 mongodsPerShardCount: 3
9 mongosCount: 2
10 configServerCount: 3
11 version: "8.0.0"
12 opsManager:
13 configMapRef:
14 name: <configMap.metadata.name>
15 # Must match metadata.name in ConfigMap file
16 credentials: <mycredentials>
17 type: ShardedCluster
18 persistent: true
19...
3

Abre tu editor de texto preferido y pega la especificación del objeto en un nuevo archivo de texto.

4
Clave
Tipo
Descripción
Ejemplo

string

Etiqueta para este clúster objeto de Kubernetes.

Los nombres de recursos deben tener 44 caracteres o menos.

Para aprender más, consulta metadata.name y la documentación de Kubernetes sobre nombres.

myproject

entero

Cantidad de particiones a implementar.

2

entero

Número de nodos de partición por partición.

3

entero

Número de routers de particiones que se van a implementar.

2

entero

Número de nodos del set de réplicas del servidor de configuración.

3

string

Versión de MongoDB que debería ejecutar este clúster.

El formato debe ser X.Y.Z para la Community Edition y X.Y.Z-ent para la edición Enterprise.

IMPORTANTE: Asegúrate de elegir una versión compatible del servidor MongoDB. Las versiones compatibles varían según la imagen base que utiliza el recurso de la base de datos MongoDB.

Para obtener más información sobre el versionado de MongoDB, consulta versionado de MongoDB en el manual de MongoDB.

Para obtener los mejores resultados, utilice la última versión disponible de MongoDB Enterprise que sea compatible con su versión de Ops Manager.

string

Nombre del ConfigMap con la configuración de conexión de Ops Manager. La configuración spec.cloudManager.configMapRef.name es un alias de esta configuración y se puede usar en su lugar.

Este valor debe existir en el mismo espacio de nombres que el recurso que quieres crear.

IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio en el ConfigMap y reconcilia el estado del recurso MongoDB.

<myproject>

string

Nombre del secreto que creaste como Ops Manager API credenciales de autenticación para que el operador de Kubernetes pueda comunicarse con Ops Manager.

El objeto secreto de Kubernetes de Ops Manager que contiene las credenciales debe estar en el mismo namespace que el recurso que se quiere crear.

IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio realizado en el Secreto y reconcilia el estado del recurso MongoDB.

<mycredentials>

string

Tipo de recurso MongoDB que se va a crear.

ShardedCluster

string

Opcional.

Indicador que muestra si este recurso MongoDB debe usar Los volúmenes persistentes para almacenamiento. Los volúmenes persistentes no se eliminan cuando el recurso MongoDB se detiene o se reinicia.

Si este valor es true, entonces los siguientes valores se establecen en su valor por defecto de 16Gi:

Para cambiar la <a class=\" \" target=\" \"href=\" \" rel=\"noopener noreferrer\"> Solicitud de volumen persistente <svg class=\" \" height=\" \" width=\" \" role=\" \" aria-hidden=\" \" alt=\" \" viewbox=\" \"><path d=\" \" fill=\" \"> <path d=\" \" fill=\" \"> configuración, configura las siguientes colecciones para cumplir con tus requisitos de implementación:

ADVERTENCIA: Otorga a tus contenedores permiso para guardar en tu volumen persistente. El operador de Kubernetes establece fsGroup = 2000, runAsUser = 2000 y runAsNonRoot = true en securityContext. El Kubernetes Operator establece fsgroup igual a runAsUser para que el volumen sea escribible para un usuario que ejecute el proceso principal en el contenedor. Para obtener más información, consulte Configuración de un contexto de seguridad para un pod o un contenedor y el debate relacionado en la documentación de Kubernetes. Si volver a implementar el recurso no resuelve los problemas con tu Volumen Persistente, comunícate con el Soporte de MongoDB.

Si no usas Volúmenes persistentes, los gráficos Disk Usage y Disk IOPS no se pueden mostrar ni en la pestaña Processes en la página Deployment, ni en la página Metrics al revisar los datos de esta implementación.

true

5

También puede agregar cualquiera de los siguientes ajustes opcionales al archivo de especificaciones objeto para una implementación de clúster:

Advertencia

Debe establecer spec.clusterDomain si su clúster Kubernetes tiene un dominio por defecto diferente al por defecto cluster.local. Si no utilizas la opción por defecto ni estableces la opción spec.clusterDomain, el Operador Kubernetes podría no funcionar como se espera.

For config server

Para enrutadores de particiones

Para los nodos de la partición

6
7

Ejecute el siguiente comando de Kubernetes para crear su clúster fragmentado:

kubectl apply -f <sharded-cluster-conf>.yaml

Verifica el registro después de ejecutar este comando. Si la creación fue exitosa, deberías ver un mensaje similar al siguiente:

2018-06-26T10:30:30.346Z INFO operator/shardedclusterkube.go:52 Created! {"sharded cluster": "my-sharded-cluster"}
8

Para verificar el estado de su MongoDB recurso, utilice el siguiente comando:

kubectl get mdb <resource-name> -o yaml -w

Con la bandera -w (observar) activada, cuando la configuración cambia, la salida se actualiza inmediatamente hasta que la fase de estado alcanza el estado Running. Para obtener más información sobre el estado de implementación de recursos, consulta Solucionar problemas con el operador de Kubernetes.