여러 Kubernetes 클러스터에 MongoDB Sharded Clusters를 배포할 수 있습니다. 멀티 클러스터 기능을 사용하면 다음을 수행할 수 있습니다.
각각 다른 지리적 리전 에 있는 여러 Kubernetes 클러스터에 배포하여 배포서버 의 회복 탄력성 개선합니다.
해당 데이터에 의존하는 애플리케이션 또는 클라이언트에 더 가까운 다양한 Kubernetes 클러스터에 지정된 샤드의 프라이머리 노드를 배포하여 지리적 샤딩 위한 배포서버 구성하고 지연 시간 줄입니다.
성능 향상을 위해 배포서버 조정합니다. 예시 를 들어, 다른 Kubernetes 클러스터의 모든 또는 지정된 샤드에 대해 또는 사용자 지정된 리소스 할당을 사용하여 읽기 전용 분석 노드를 배포 할 수 있습니다.
또한 다양한 수준에서 샤드, mongos 및 config 서버 세부 정보를 구성할 수 있습니다. 즉, 샤드, config 서버 및 mongos 에 대한 기본값 기본 구성을 정의하고 각 Kubernetes 클러스터 에 대해 독립적으로 사용자 지정할 수 있습니다. 또한 특정 요구 사항에 맞게 개별 샤드를 사용자 지정할 수 있습니다.
중요
멀티 클러스터 샤딩된 클러스터 기능을 사용하면 여러 지리적 리전의 여러 Kubernetes 클러스터에 MongoDB 리소스를 배포 수 있습니다. 그러나 이렇게 하면 복제 작업의 지연 시간 이 늘어날 수 있습니다.
멀티 클러스터 샤딩된 클러스터 토폴로지 의 특정 구성 옵션에 대해 자세히 학습 샤딩된 클러스터 참조를 확인하세요.
제한 사항
Kubernetes 시크릿 인젝션에는 Hashicorp Vault 지원 사용할 수 없습니다.
Kubernetes Operator는 실패한 Kubernetes 클러스터에서 정상 클러스터로 리소스를 자동으로 이동하지 않습니다. 멤버 클러스터 장애가 발생하는 경우 중앙 클러스터 에 배포된 CRD 리소스 업데이트하여 나머지 정상 Kubernetes 클러스터에 수동으로 리소스를 재배포해야 합니다.
멤버 클러스터 에 장애가 발생하면 먼저 장애가 발생한 클러스터를 0으로 수동으로 확장하다 하여 비정상 프로세스를 제거 해야 합니다. 그런 다음 중앙 클러스터 에 배포된 CRD 리소스 업데이트하여 나머지 정상 Kubernetes 클러스터에 수동으로 리소스를 재배포할 수 있습니다. 자세한 학습은 재해 복구 를 참조하세요.
전제 조건
멀티 클러스터 배포서버 위해 Kubernetes 클러스터를 준비합니다.
Kubernetes 클러스터 중 하나에 멀티 클러스터 배포를 위해 Kubernetes Operator를 설치하고 구성합니다.
옵션 1: 노드 클러스터 전체에 서비스 메시를 배포합니다. 자세한 절차는 MongoDB Ops Manager 멀티 클러스터 배포 가이드의 1 ~ 6 단계에서 찾을 수 있습니다. 이 절차는 독단적인 절차이며 가능한 많은 구성 중 하나에 불과합니다.
옵션: 비서비스 2메시 배포서버 위해 Kubernetes 클러스터를 구성합니다.
Ops 관리자 또는 Cloud Manager 인스턴스와 MongoDB 조직 및 프로젝트에 대한 자격 증명 생성 합니다.
샤드 클러스터 배포 예시
아래 예시 에서는 중앙 클러스터 에 적용하는 경우 다음과 같이 구성된 3 샤드를 사용하여 샤딩된 MongoDB cluster 배포합니다.
각 샤드 에는 모든 Kubernetes 클러스터에 분산된 노드가 있습니다( 클러스터 당 1 노드 ).
기본값 으로 각 샤드의 복제본 세트는 다음과 같습니다.
3 클러스터에 배포된 총 3 투표 멤버가 있음(각 클러스터 의 1 노드 )
프라이머리 샤드
kind-e2e-cluster-1
에 있는 것이 좋습니다.
샤드
sc-0
에shardOverride
를 사용하여 기본값 (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 멤버가 있는 config 서버 복제본 세트, 각 클러스터 에 1 멤버가 있음
총 3 mongos 인스턴스 배포, 각 클러스터 에 1 인스턴스
기본값 구성은 3개의 샤드로 구성되며, 각 샤드에는 3개의 클러스터 각각에 하나의 멤버가 있으며 샤드 당 총 3개의 멤버가 있습니다. 그러나 재정의에서는 기본값 에 따라 sc-0
샤드 클러스터 1
에 2개, 클러스터 2
에 2개, 클러스터 3
에 여전히 하나의 샤드 를 포함하여 5개의 멤버를 갖도록 변경합니다.
참고
단방향 확장 만 지원됩니다.
샤드, config 서버 또는 mongos 복제본을 확장하다 때는 확장 의 정확성을 보장하기 위해서만 리소스를 확장하다 하거나 축소할 수 있습니다. 이 규칙은 단일 Kubernetes 클러스터 배포와 여러 Kubernetes 클러스터에 분산된 배포 모두에 적용됩니다. 또한 멀티 클러스터 배포에서는 단방향 확장 규칙이 모든 리소스 유형에 적용됩니다. 예시 들어 샤드에 노드를 더 추가(확장 )하면서 config 서버 또는 mongos 제거( 확장 )할 수 없습니다. 더 이상 총 멤버 수를 변경하지 않고는 한 클러스터 에서 다른 클러스터로 한 노드 '이동'할 수 없습니다. 대신 먼저 확장 작업을 수행한 다음 확장 를 위한 별도의 변경을 실행해야 합니다.
이 예시 구성은 또한 샤드 sc-0
에 대해 프라이머리 클러스터 2
로 (shardOverrides
사용) 이동시켜 클러스터 2
이 위치한 리전 에서 작업하는 사용자의 지연 시간 줄일 수 있습니다. 이러한 방식으로 클러스터(및 해당 리전) 전체에서 여전히 회복 탄력성 유지할 수 있지만, 샤드 0
의 데이터가 클러스터 2
이 배포된 사용자와 가장 관련성이 높은 데이터인 경우 지연 시간 단축됩니다.
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
샤드 재정의
샤딩된 클러스터 여러 Kubernetes 클러스터에 배포 하려면 샤딩된 클러스터 구성(MongoDB 사용자 지정 리소스 yaml)을 연산자 클러스터 ( MongoDB Operator 인스턴스 배포된 Kubernetes 클러스터) 에 적용 . 이 구성의 spec.shard
정의는 배포의 기본 샤드 정의로 간주됩니다.
특정 Kubernetes 클러스터에서 특정 샤드를 사용자 지정하려면 샤드 재정의를 사용하여 지정된 샤드 에 대한 기본 샤드 정의를 업데이트 수 있습니다.
다음 표에는 기본 샤드 정의를 업데이트 하거나 확장하기 위해 정의할 수 있는 필드가 나열되어 있습니다. 필드는 우선 순위에 따라 나열됩니다. 지정된 테이블의 맨 위에 있는 필드 우선 순위가 가장 낮은 설정을 나타내며, 가장 아래에 있는 필드 정의된 경우 다른 모든 필드를 재정의합니다(예: 특정 샤드, 특정 클러스터).
또한 각 필드 유형에 대해 표시된 재정의 정책은 특정 필드 새로 정의된 값으로 재정의되는지, 또는 해당 필드 정의된 전체 객체 재정의되는지 여부를 설명합니다. 전체 객체 재정의되면 기본 샤드 정의에 정의된 필드 중 재정의 정의에 명시적으로 정의되지 않은 모든 필드가 제거됩니다. merge
값은 단일 필드 업데이트됨을 나타내고 replace
값은 다음을 나타냅니다. 완전한 상위 객체 재정의됩니다.
지속성 및 Statefulset 설정 사용자 지정
ShardedClusterSpec 필드 | 지정하려면 | 적용 대상 |
---|---|---|
| 지속성 및 파드 템플릿 | 모든 pod |
| 지속성 및 파드 템플릿 | 모든 pod |
| 지속성(Pod Template 필드 무시됨) | 클러스터 의 모든 샤드 |
| Pod Template | 클러스터 의 모든 샤드 |
| 지속성(Pod Template 필드 무시됨) | 클러스터 의 모든 샤드 |
| Pod Template | 클러스터 내 샤드 1개 |
| 지속성(Pod Template 필드 무시됨) | 특정 클러스터 의 샤드 1개 |
| Pod Template | 특정 클러스터 의 샤드 1개 |
참고
ShardSpecificPodSpec 지원 중단
ShardSpecificPodSpec
필드 더 이상 사용되지 않지만 여전히 지원됩니다. 이전에는 단일 클러스터 샤딩된 클러스터 에 대해 샤드당 지속성 및 파드 템플릿 매개변수를 지정하는 데 사용되었습니다. 이제 더 이상 사용되지 않으므로 ShardOverrides.PodSpec
및(으)로 마이그레이션 해야 ShardOverrides.StatefulSetConfiguration
합니다. 단일 클러스터 배포를 위해 shardSpecificPodSpec
및 shardOverrides
에서 업데이트하는 방법에 대한 지침 제공된 예시 YAML 파일 참조하세요.
다음에서 pod 템플릿 및 지속성 설정을 재정의합니다. clusterSpecList
다음 예시 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
다음 예시 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
필드에서 마이그레이션
다음 예시 더 이상 사용되지 않는 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 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"
자세한 학습 은 전체 파일검토 참조하세요.
외부 액세스 구성
필드 | 클러스터 | 어떤 샤드 |
---|---|---|
| 모두 | 모두 |
| one | 모두 |
| one | 모두 |
Members, MemberConfig, 추가 MongodConfig, AgentConfig
ShardedClusterSpec 필드 | 지정하려면 | 적용 대상 |
---|---|---|
| 해당 사항 없음 | 해당 사항 없음 |
| 적용 | 적용 |
| 적용 | 적용 |
| 해당 사항 없음 | 해당 사항 없음 |
| 적용 | 적용 |
config 서버 재정의
ShardedClusterSpec 필드 | 지정하려면 | 적용 대상 |
---|---|---|
| 해당 사항 없음 | 해당 사항 없음 |
| 적용 | 적용 |
| 해당 사항 없음 | 해당 사항 없음 |
| 적용 | 무시됨 |
| 해당 사항 없음 | 적용 |
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
자세한 학습 은 전체 파일검토 참조하세요.
Mongos 재정의
ShardedClusterSpec 필드 | 지정하려면 | 적용 대상 |
---|---|---|
| 해당 사항 없음 | 해당 사항 없음 |
| 적용 | 해당 사항 없음 |
| 해당 사항 없음 | 적용 |
| 무시됨 | 해당 사항 없음 |
| 적용 | 해당 사항 없음 |