Cluster fragmentado de vários clusters
Você pode distribuir clusters fragmentados do MongoDB em vários clusters Kubernetes. Com a funcionalidade de vários clusters, você pode:
Melhore a resiliência de sua implantação distribuindo-a em vários clusters Kubernetes, cada um em uma região geográfica diferente.
Configure sua implantação para fragmentação geográfica implantando nós primários de fragmentos especificados em diferentes clusters Kubernetes localizados mais próximos do aplicação ou dos clientes que dependem desses dados, reduzindo a latência.
Ajuste seu sistema para melhorar o desempenho. Por exemplo, você pode implantar nós analíticos somente leitura para todos ou para shards especificados em diferentes clusters Kubernetes ou com alocações de recursos personalizadas.
Além disso, você pode configurar detalhes de shards, mongos e servidor de configuração em diferentes níveis. Isso significa que você pode definir uma configuração padrão de nível superior para shards, servidor de configuração e mongos, e personalizá-los para cada cluster do Kubernetes independentemente. Além disso, é possível personalizar shards individuais para atender às suas necessidades específicas.
Importante
A funcionalidade de cluster fragmentado torna possível distribuir recursos do MongoDB em vários clusters Kubernetes em várias regiões geográficas; no entanto, isso provavelmente aumentará a latência para as operações de replicação.
Para saber mais sobre as opções de configuração específicas da topologia de cluster fragmentado de vários clusters, consulte a referência de cluster fragmentado.
Limitações
O suporte do HashiCorp Vault não está disponível para injeção de segredo do Kubernetes.
O Operador Kubernetes não transfere automaticamente recursos de clusters Kubernetes com falha para clusters saudáveis. No caso de falha de um cluster de membros, você deve redistribuir recursos entre clusters Kubernetes íntegros restantes manualmente, atualizando o recurso CRD implantado no cluster central.
No caso de uma falha no cluster de membros, você deve primeiro reduzir manualmente os clusters com falha para zero para remover os processos não íntegros. Em seguida, você pode redistribuir os recursos entre os clusters Kubernetes restantes manualmente, atualizando o recurso CRD distribuído no cluster central. Consulte Recuperação de desastres para saber mais.
Pré-requisitos
Prepare seus clusters Kubernetes para um sistema de vários clusters.
Instale e configure o Kubernetes Operator para sistemas de vários clusters em um de seus clusters Kubernetes.
Opção 1: Implementar uma malha de serviço entre clusters de membros. Você pode encontrar um procedimento detalhado nas etapas 1 a 6 do Guia de sistema de vários clusters do Ops Manager. Observe que este procedimento é obrigatório e apenas uma das muitas configurações possíveis.
Opção 2: configure seus clusters do Kubernetes para uma implantação de rede sem serviço.
Implante um mapa de configuração com detalhes do projeto Ops Manager ou Cloud Manager e MongoDB em seu cluster central, que o Kubernetes Operator exige para distribuir o recurso de banco de dados MongoDB .
Crie credenciais para Ops seu gerente ou instância do Cloud Manager e sua organização e projeto MongoDB .
Exemplo de implantação de cluster fragmentado
Quando aplicado ao cluster central, o exemplo abaixo implementa um cluster MongoDB fragmentado com 3 fragmentos configurados da seguinte forma:
Cada shard tem nós distribuídos em todos os clusters do Kubernetes (1 nó por cluster).
Por padrão, o conjunto de réplicas de cada shard:
Tem 3 membros votantes no total distribuídos em 3 clusters (1 nó em cada cluster)
Preferencialmente, o fragmento primário está em
kind-e2e-cluster-1
.
Com um
shardOverride
para o shardsc-0
, alteramos os valores padrão (especificados nospec.shard
) para o seguinte:5 membros no total
2 membros em
kind-e2e-cluster-1
2 membros em
kind-e2e-cluster-2
1 nó em
kind-e2e-cluster-3
Quando possível, é preferível que o fragmento primário esteja em
kind-e2e-cluster-2
Configurações de armazenamento padrão personalizadas para todos os shards em todos os clusters, conforme definido em
spec.shardPodSpec
Um conjunto de réplicas de servidor de configuração com 3 membros, com 1 membro em cada cluster
3 instâncias mongos implantadas no total, com 1 instância em cada cluster
A configuração padrão consiste em três fragmentos, cada um com um membro em cada um dos três clusters, para um total de três membros por fragmento. Mas nas substituições, alteramos o fragmento sc-0
para ter cinco membros, dois no cluster 1
, dois no cluster 2
e o cluster 3
ainda tem um fragmento conforme o padrão.
Observação
Somente o dimensionamento unidirecional é suportado.
Ao escalar réplicas de shard, servidor de configuração ou mongos, você só pode aumentar ou diminuir os recursos para garantir a correção do dimensionamento. Esta regra se aplica tanto a sistemas de cluster Kubernetes únicos quanto aquelas distribuídas entre vários clusters Kubernetes. Além disso, em sistemas de vários clusters, a regra de dimensionamento unidirecional se aplica a todos os tipos de recursos. Por exemplo, você não pode adicionar mais nós (aumento) a shards e, ao mesmo tempo, remover servidores de configuração ou mongos (redução). Não é mais possível "mover" um nó de um cluster para outro sem alterar o número total de membros. Em vez disso, você deve primeiro executar uma operação de expansão e, em seguida, executar uma alteração separada para a redução.
Essa configuração de exemplo também muda (com shardOverrides
) o primário para o cluster 2
, para o fragmento sc-0
, o que pode reduzir a latência para usuários que operam na região onde o cluster 2
está localizado. Dessa forma, você ainda tem resiliência nos clusters (e suas regiões), mas se os dados no fragmento 0
forem dados mais relevantes para os usuários no qual o cluster 2
está implantado, eles terão uma latência mais baixa.
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
Substituições de fragmentos
Para implantar um cluster fragmentado em vários clusters Kubernetes, você aplica a configuração de cluster fragmentado (recurso personalizado MongoDB yaml) ao cluster do operador - o cluster Kubernetes no qual sua instância do MongoDB Operator está distribuída. A definição spec.shard
desta configuração é considerada a definição base de shard do seu sistema.
Se quiser personalizar shards específicos em clusters específicos do Kubernetes, você pode usar substituições de shards para atualizar a definição de shard base para um determinado shard.
As tabelas a seguir listam campos que você pode definir para atualizar ou estender sua definição base de shard. Os campos estão listados em ordem de precedência. O campo mais alto em uma determinada tabela representa a configuração com a menor precedência, e o campo mais baixo , se definido, substitui todos os outros campos (por exemplo fragmento específico, em um cluster específico).
Além disso, a política de substituição indicada para cada tipo de campo descreve se esse campo específico é substituído pelo valor recém-definido ou se o objeto completo no qual esse campo está definido é substituído. Se o objeto inteiro for substituído, todos os campos definidos na definição de shard base que também não estejam explicitamente definidos na definição de substituição serão removidos. O valor merge
indica que um único campo é atualizado, e o valor replace
indica que o objeto pai completo é substituído.
Personalizar configurações de persistência e statefulset
Campo ShardedClusterSpec | Para especificar | Aplica-se a |
---|---|---|
| Modelo de persistência e pod | Todos os pods |
| Modelo de persistência e pod | Todos os pods |
| Persistência ( o campo Modelo do Pod é ignorado) | Todos os shards no cluster |
| Pod Template | Todos os shards no cluster |
| Persistência ( o campo Modelo do Pod é ignorado) | Todos os shards no cluster |
| Pod Template | Um shard no cluster |
| Persistência ( o campo Modelo do Pod é ignorado) | Um fragmento em um cluster específico |
| Pod Template | Um fragmento em um cluster específico |
Observação
Descontinuação do ShardSpecificPodSpec
O campo ShardSpecificPodSpec
está obsoleto, mas ainda é suportado. Ele foi usado anteriormente para especificar os parâmetros Persistence e Pod Template, por shards, para cluster fragmentado de cluster único. Agora que está obsoleto, você deve migrar para ShardOverrides.PodSpec
e ShardOverrides.StatefulSetConfiguration
. Consulte o exemplo de arquivo YAML fornecido para obter orientações sobre como atualizar do shardSpecificPodSpec
e shardOverrides
para sistemas de um único cluster.
Substituir o modelo de pod e as configurações de persistência em clusterSpecList
O exemplo seguinte ilustra como substituir modelos de pod personalizados e configurações de persistência no 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 saber mais, você pode revisar o arquivo completo.
Defina modelos de pod personalizados e configurações de persistência com shardOverrides
O exemplo seguinte ilustra como definir modelos de pod personalizados e configurações de persistência no 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 saber mais, você pode revisar o arquivo completo.
Migrando do campo shardSpecificPodSpec
obsoleto
O exemplo seguinte ilustra como atualizar do campo shardSpecificPodSpec
obsoleto para o novo 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 saber mais, você pode revisar o arquivo completo.
Configuração de acesso externo
Campo | Quais clusters | Quais shards |
---|---|---|
| todos | todos |
| um | todos |
| um | todos |
Membros, MemberConfig, MongodConfig adicional, AgentConfig
Campo ShardedClusterSpec | Para especificar | Aplica-se a |
---|---|---|
| Não aplicável | Não aplicável |
| aplica-se | aplica-se |
| aplica-se | aplica-se |
| Não aplicável | Não aplicável |
| aplica-se | aplica-se |
Substituições de servidor de configuração
Campo ShardedClusterSpec | Para especificar | Aplica-se a |
---|---|---|
| Não aplicável | Não aplicável |
| aplica-se | aplica-se |
| Não aplicável | Não aplicável |
| aplica-se | ignorado |
| Não aplicável | aplica-se |
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 saber mais, você pode revisar o arquivo completo.
Substituições de Mongos
Campo ShardedClusterSpec | Para especificar | Aplica-se a |
---|---|---|
| Não aplicável | Não aplicável |
| aplica-se | Não aplicável |
| Não aplicável | aplica-se |
| ignorado | Não aplicável |
| aplica-se | Não aplicável |