AI 에이전트의 경우: 문서 인덱스는 https://www.mongodb.com/ko-kr/docs/llms.txt에서 사용할 수 있으며, 모든 페이지의 마크다운 버전은 어떤 URL 경로에 .md를 추가하여 사용할 수 있습니다.
Docs Menu
Docs Home
Docs Home
Docs Home

Ops Manager 리소스 계획하기

MongoDB MongoDB Ops Manager MongoDB deployment를 관리, 백업 및 모니터링하는 엔터프라이즈 애플리케이션 입니다. MongoDB Ops Manager 사용하면 MongoDB 확장하다 및 업그레이드 , 쿼리를 최적화하고, 특정 시점 복원을 수행하고, 성능 경고를 받고, 배포를 모니터 수 있습니다. MongoDB Ops Manager 와 기본 데이터베이스 관리 및 유지 관리하기 위해 Kubernetes Operator용 MongoDB 컨트롤러를 사용하여 MongoDB Ops Manager Kubernetes 의 컨테이너 에 배포된 리소스 로 실행 .

다음 방법 중 하나로 MongoDB Ops Manager 리소스를 배포할 수 있습니다.

  • 단일 Kubernetes 클러스터 모드. 단일 MongoDB Ops Manager 인스턴스를 배포하여 리소스의 단일 클러스터 Kubernetes 배포를 지원할 수 MongoDB 있습니다.

  • 다중 Kubernetes 클러스터 모드. 여러 Kubernetes 클러스터에 여러 MongoDB Ops Manager 및 애플리케이션 데이터베이스 인스턴스를 배포할 수 있습니다. 이 모드에서 MongoDB Ops Manager 리소스의 다중 클러스터는 여러 Kubernetes 클러스터에 MongoDB Ops Manager 애플리케이션 및 애플리케이션 데이터베이스의 배포를 지원합니다.

단일 또는 여러 Kubernetes 클러스터에 MongoDB Ops Manager 리소스를 배포하기 전에 MongoDB Ops Manager 리소스 아키텍처 및 고려 사항을 검토하고 전제 조건을 완료합니다.

아키텍처

MongoDB Ops Manager 리소스 아키텍처에 대한 자세한 내용은 다음을 참조하세요.

MongoDBOpsManager 사용자 지정 리소스 정의

Kubernetes Operator는 리소스 배포 각 Kubernetes 클러스터 에서 MongoDBOpsManager 사용자 지정 리소스 사용하여 MongoDB Ops Manager 배포를 관리합니다. Kubernetes Operator는 리소스의 사양이 변경되는지 감시합니다. 사양이 변경되면 Kubernetes Operator는 변경 사항의 유효성을 검사하고 MongoDB Ops Manager 구성 요소를 배포 하는 각 Kubernetes 클러스터의 리소스 를 적절하게 업데이트합니다.

MongoDBOpsManager 사용자 지정 리소스사양은 다음과 같은 MongoDB Ops Manager 구성 요소를 정의합니다.

  • 애플리케이션 데이터베이스

  • MongoDB Ops Manager 애플리케이션

  • 백업 데몬

다음 다이어그램은 MongoDB Ops Manager 배포의 관련 구성 요소를 설명합니다.

  • 단일 클러스터 배포에서는 Kubernetes Operator를 설치한 것과 동일한 Kubernetes 클러스터에 이러한 구성 요소를 배포합니다. 이 클러스터를 "운영자 클러스터"라고 합니다.

  • 멀티 클러스터 배포에서는 다음을 수행할 수 있습니다.

    • 각 구성 요소를 '멤버 클러스터'라고 하는 서로 다른 Kubernetes 클러스터에 배포합니다. 단일 멤버 Kubernetes 클러스터를 사용하여 간소화된 멀티 클러스터 배포를 배포할 수도 있습니다. 자세한 내용은 단일 및 다중 클러스터 모드를 참조하세요.

    • Kubernetes Operator가 다른 모든 멤버 클러스터를 관리하는 '운영자 클러스터'로 알려진 하나의 Kubernetes 클러스터에 Kubernetes Operator를 설치합니다. 연산자 클러스터는 MongoDB Ops Manager 구성 요소를 호스팅할 수 있으므로 멤버 클러스터로 간주될 수도 있습니다. 멀티 클러스터 아키텍처 다이어그램을 참조하세요.

MongoDB Enterprise Kubernetes Operator(단일 Kubernetes 클러스터)의 상위 수준 아키텍처를 보여주는 다이어그램

MongoDB Ops Manager 리소스용 애플리케이션 데이터베이스

애플리케이션 데이터베이스의 경우, Kubernetes Operator는 MongoDB 복제본 세트를 StatefulSet로 배포합니다.

애플리케이션 데이터베이스의 각 Pod에는 다음과 같은 컨테이너가 있습니다.

  • mongod.

  • MongoDB Agent. MongoDB Agent 버전을 재정의하려면 $AGENT_IMAGE 환경 변수 또는 Kubernetes Operator 설치에 사용하는 Helm 차트의 agent.version 를 사용합니다.

  • 모니터링 에이전트. 모니터링 에이전트의 버전을 재정의할 수 없습니다. Kubernetes Operator가 사용하는 버전은 MongoDB Ops Manager 버전과의 이전 버전과의 호환성을 보장합니다.

    모니터링 에이전트의 버전을 보려면 다음과 같이 하세요:

    • Kubernetes Operator의 경우 파드 내부의 /usr/local/om_version_mapping.json 또는 Kubernetes Operator의 경우 이미지를 검사합니다.

    • 애플리케이션 데이터베이스를 배포하는 파드에서 모니터링 에이전트의 컨테이너 이미지를 확인합니다.

멀티 클러스터 배포서버에서( spec.applicationDatabase.topology 를 MultiCluster 로 설정하는 경우), Kubernetes Operator는 spec.applicationDatabase.clusterSpecList 의 애플리케이션 데이터베이스에 대해 지정된 각 Kubernetes 클러스터에 StatefulSet를 생성합니다.

애플리케이션 데이터베이스에 대한 MongoDB 복제본 세트 노드를 호스팅하는 각 멤버 Kubernetes 클러스터에서 다음 조치가 수행됩니다.

  • Kubernetes는 애플리케이션 데이터베이스 복제본 세트를 구성하는 각 노드에 대해 StatefulSet에 하나의 파드를 생성합니다. StatefulSet의 각 파드는 mongod 와 MongoDB Agent를 실행합니다.

    각 MongoDB Agent StatefulSet의 해당 파드에서 mongod 을(를) 시작 활성화하려면 spec.applicationDatabase.version 설정을 사용하여 애플리케이션 데이터베이스에 대한 특정 MongoDB Server 버전을 지정해야 합니다. 이 설정에서 지정하는 버전은 컨테이너 레지스트리의 태그를 지정하다 와 일치해야 합니다.

  • 각 MongoDB Agent 는 해당 애플리케이션 데이터베이스 파드에서 mongod을(를) 시작합니다. MongoDB Agent가 애플리케이션 데이터베이스 복제본 세트 에 mongod 프로세스를 추가합니다.

    MongoDBOpsManager 사용자 지정 리소스의 spec.applicationDatabase 컬렉션에 있는 애플리케이션 데이터베이스 복제본 세트에 대한 복제본 수 및 기타 구성 옵션을 구성합니다. Kubernetes Operator는 Kubernetes Operator가 애플리케이션 데이터베이스 StatefulSet의 각 파드에 마운트하는 시크릿 을 사용하여 이 구성을 MongoDB Agent에 전달합니다.

    멀티 클러스터 애플리케이션 데이터베이스 배포서버(여기서 spec.applicationDatabase.topology 가 MultiCluster 로 설정됨)에서는 spec.applicationDatabase.clusterSpecList 의 각 멤버 클러스터에 대해 각 멤버 클러스터의 노드 수를 개별적으로 지정합니다. 멀티 클러스터 배포에서는 spec.applicationDatabase 의 replicas 설정이 무시됩니다.

  • spec.applicationDatabase collection을 업데이트할 때마다 Kubernetes Operator는 MongoDB Agent 구성 및 StatefulSet 사양(해당되는 경우)에 변경 사항을 적용합니다. StatefulSet 사양이 변경되면 Kubernetes는 순차적으로 파드를 업그레이드하고 각 파드를 재시작합니다.

  • 애플리케이션 데이터베이스를 호스팅하는 각 Kubernetes 클러스터 내에서 각 애플리케이션 데이터베이스 파드에 대한 연결을 제공하기 위해 Kubernetes Operator는 헤드리스 서비스를 생성합니다. 애플리케이션 데이터베이스의 멀티 클러스터 배포에서 Kubernetes Operator는 또한 <om_resource_name>-db-N-svc 라는 이름의 서비스를 파드당 하나씩 생성하고(metadata.name에 해당), <om_resource_name>-db-0.<namespace>.svc.cluster.local과 같은 해당 FQDN을 호스트 이름으로 사용하여 특정 mongod에 연결합니다.

  • Kubernetes Operator를 배포 StorageClass 또는 환경에 따라 Kubernetes 동적 볼륨 프로비저닝 사용하여 영구 볼륨을 생성할 수 있습니다.

    또는 를 spec.applicationDatabase.podSpec.persistence.single 사용하여 애플리케이션 데이터베이스 파드에 대한 영구 볼륨 클레임을 사용자 지정할 수 spec.applicationDatabase.podSpec.persistence.multiple 있습니다.

애플리케이션 데이터베이스 토폴로지

프라이머리 노드를 선택하려면 애플리케이션 데이터베이스 복제본 세트 노드의 과반수를 사용할 수 있어야 합니다. 복제본 세트의 노드 과반수가 실패하면 복제본 세트는 프라이머리 노드를 선출하기 위한 과반수 투표를 구성할 수 없습니다. 자세한 내용은 복제본 세트 배포 아키텍처를 참조하세요.

가능하면 홀수의 멤버 Kubernetes 클러스터를 사용하고 애플리케이션 데이터베이스 노드를 데이터 센터, 구역 또는 Kubernetes 클러스터에 분산합니다. 자세한 내용은 둘 이상의 데이터 센터에 분산된 복제본 세트를 참조하세요.

애플리케이션 데이터베이스의 토폴로지에 대한 다음 예를 고려하세요.

멤버가 5개인 애플리케이션 데이터베이스의 경우 가능한 멤버 분포는 다음과 같습니다.

  • 클러스터 2개: Cluster 1 에 3개, Cluster 2 에 2개.

    • Cluster 2 가 실패하면 Cluster 1 는 프라이머리 노드 를 선택하기에 충분한 수의 애플리케이션 데이터베이스의 복제본 세트 멤버를 호스팅합니다.

    • Cluster 1 가 실패하면 Cluster 2 에 프라이머리 노드를 선택할 수 있는 애플리케이션 데이터베이스의 노드가 충분하지 않습니다.

  • 클러스터 3개: Cluster 1 에 멤버 2개, Cluster 2 에 멤버 2개, Cluster 3 에 멤버 1개.

    • 단일 cluster에 장애가 발생하면 나머지 cluster에 프라이머리 노드를 선택할 수 있는 충분한 구성원이 있습니다.

    • 두 cluster가 실패하면 나머지 cluster의 구성원이 충분하지 않아 프라이머리 노드를 선출할 수 없습니다.

7개 멤버로 구성된 애플리케이션 데이터베이스의 경우 다음과 같은 멤버 분포를 고려하세요.

  • 클러스터 2개: Cluster 1 에 4개, Cluster 2 에 3개 클러스터.

    • Cluster 2 이(가) 실패하면 Cluster 1 에 프라이머리 노드 를 선택할 수 있는 노드가 충분합니다.

    • Cluster 1 이(가) 실패하면 Cluster 2 의 멤버가 부족하여 프라이머리 노드 를 선택할 수 있습니다.

Cluster 2 이(가) 애플리케이션 데이터베이스의 멤버 최소 3개를 충족하지만, 프라이머리 노드 를 선택하려면 애플리케이션 데이터베이스의 멤버 7개 중 과반수가 사용할 수 있어야 합니다.

자세한 내용 은 MongoDB Ops Manager의 재해 복구 및 AppDB 리소스를 참조하세요.

Ops Manager 애플리케이션 서버

애플리케이션 데이터베이스가 Running 상태에 도달하면 Kubernetes Operator가 MongoDB Ops Manager 애플리케이션 배포를 시작합니다.

  • 각 멤버 Kubernetes 클러스터에서 StatefulSet를 구성합니다.

  • 배포하려는 각 MongoDB Ops Manager 복제본 세트에 대해 Kubernetes 는 StatefulSet에 하나의 파드를 생성합니다.

  • 각 Pod에는 하나의 MongoDB Ops Manager 애플리케이션 프로세스가 포함되어 있습니다.

단일 MongoDB Ops Manager 클러스터 MongoDB Ops Manager 배포서버 가 단일 Pod 장애에 대해 복원력을 갖도록 하려면 를 spec.replicas 사용하여 애플리케이션을 호스팅하는 복제본 수를 늘립니다.

멀티 클러스터 MongoDB Ops Manager 배포가 전체 데이터 센터 또는 구역 장애에 대해 복원력을 갖도록 하려면 및 를 로 설정하여 여러 클러스터에 MongoDB Ops Manager 애플리케이션을 Kubernetes spec.topology spec.applicationDatabase.topology MultiCluster배포합니다. MongoDB Ops Manager 및 AppDB 리소스에 대한 재해 복구도 참조하세요.

MongoDB Ops Manager 리소스용 백업 디먼

이(가) spec.backup.enabled true Kubernetes 이면 Kubernetes 각 멤버 클러스터에서 MongoDB Ops Manager 애플리케이션이 실행 중 단계에 도달한 후 Operator가 백업 데몬을 시작합니다. 백업 데몬의 경우, Kubernetes Operator는 각 멤버 Kubernetes 클러스터에 StatefulSet를 배포합니다. 각 멤버 클러스터에서 Kubernetes는 spec.backup.members 에 지정된 수만큼 StatefulSet에 백업 데몬 파드를 생성합니다. 단일 클러스터 배포에서 이러한 조치는 Kubernetes Operator를 설치하고 MongoDB Ops Manager 구성 요소를 배포하는 데 사용하는 연산자 클러스터에서 수행됩니다.

백업을 활성화하는 경우, 각 Kubernetes 멤버 클러스터가 아닌 글로벌 수준에서 oplog 저장소,블록 저장소 또는 S 스냅샷3 저장소 를 구성합니다.spec.backup

백업 작업을 암호화 할 수도 있지만 동일한 Kubernetes 연산자 인스턴스가 MongoDBOpsManager 와 MongoDB 사용자 지정 리소스를 모두 관리하지 않는 배포에는 제한 이 적용됩니다.

백업 활성화 Kubernetes Operator는 각 멤버 Kubernetes 클러스터 에서 백업 데몬의 헤드 데이터베이스 에 대한 영구 볼륨 클레임을 생성합니다. spec.backup.headDB 설정을 사용하여 헤드 데이터베이스 구성할 수 있습니다.

Kubernetes Operator는 MongoDB Ops Manager API를 호출하여 MongoDB Ops Manager 애플리케이션의 백업 구성이 각 멤버 Kubernetes 클러스터의 사용자 지정 리소스 정의에 정의한 구성과 일치하는지 확인합니다.

고려 사항

암호화 키

Kubernetes Operator는 MongoDB Ops Manager 애플리케이션 데이터베이스의 민감한 정보를 보호하기 위해 암호화 키 생성합니다. Kubernetes Operator는 이 키를 MongoDB Ops Manager 리소스 와 동일한 네임스페이스 의 시크릿에 저장합니다. Kubernetes Operator는 시크릿의 이름을 <om-resource-name>-gen-key로 지정합니다.

참고

단일 클러스터 Kubernetes 배포에 시크릿이 저장되지 않도록 하려면 모든 시크릿 을 시크릿 저장 도구로 마이그레이션 할 수 있습니다. 여러 Kubernetes 클러스터에 대한 배포는 HashiCorp Vault와 같은 시크릿 저장 도구에 시크릿을 저장하는 것을 지원하지 않습니다.

MongoDB Ops Manager 리소스 제거 도 키는 Kubernetes 클러스터 의 시크릿에 저장된 상태로 유지됩니다. 애플리케이션 데이터베이스를 영구 볼륨에 저장하고 동일한 이름으로 다른 MongoDB Ops Manager 리소스 생성하는 경우, Kubernetes Operator는 시크릿을 재사용합니다. 다른 이름으로 MongoDB Ops Manager 리소스 생성하는 경우, Kubernetes Operator는 새 시크릿과 애플리케이션 데이터베이스를 생성하며, 이전 시크릿은 재사용되지 않습니다.

애플리케이션 데이터베이스

토폴로지

모니터링

Kubernetes 연산자는 Ops Manager 애플리케이션을 지원하는 애플리케이션 데이터베이스를 모니터링하도록 Ops Manager를 자동으로 구성합니다. Kubernetes 연산자는 애플리케이션 데이터베이스 배포를 모니터링할 수 있도록 <ops-manager-deployment-name>-db 이라는 이름의 프로젝트를 생성합니다.

Ops Manager는 애플리케이션 데이터베이스 배포를 모니터링하지만 Ops Manager는 이를 managed하지 않습니다. Ops Manager 애플리케이션에서는 애플리케이션 데이터베이스의 구성을 변경할 수 없습니다.

중요

<ops-manager-deployment-name>-db 프로젝트에 Ops Manager UI에 애플리케이션 데이터베이스의 에이전트가 오래되었다는 경고가 표시될 수 있습니다. 이러한 경고는 무시해도 됩니다.

인증

Kubernetes Operator는 애플리케이션 데이터베이스에서 SCRAM-SHA-256 인증 을 시행합니다.

Kubernetes 연산자는 Ops Manager가 애플리케이션 데이터베이스에 연결하는 데 사용하는 데이터베이스 사용자를 생성합니다. 이 데이터베이스 사용자에게는 다음과 같은 속성이 있습니다.

사용자 이름

mongodb-ops-manager

인증 데이터베이스.

admin

역할

MongoDB Ops Manager 데이터베이스 사용자의 이름과 역할은 수정할 수 없습니다. 데이터베이스 사용자의 비밀번호를 설정하기 위한 시크릿을 생성 합니다. 시크릿을 편집하여 비밀번호를 업데이트합니다. 시크릿을 생성하지 않거나 기존 시크릿을 삭제하지 않으면 Kubernetes Operator가 비밀번호를 생성하여 저장합니다.

비밀 저장의 다른 옵션에 대해 학습하려면 비밀 저장소 구성을 참조하세요. 멀티 클러스터 배포는 HashiCorp Vault에 시크릿을 저장하는 것을 지원 하지 않습니다.

오프라인 배포

Kubernetes Operator에서는 MongoDB Enterprise 오프라인 배포를 포함한 MongoDB Ops Manager 리소스의 모든 배포를 활성화하기 위해 애플리케이션 데이터베이스 이미지의 버전을 지정해야 합니다.

간소화된 구성

MongoDB Ops Manager를 배포한 후에는 구성해야 합니다. 일반 절차에는 구성 마법사 를 통해 MongoDB Ops Manager를 설정하는 작업이 포함됩니다. 배포하기 전에 객체 사양에 몇 가지 필수 설정을 설정하면 구성 마법사를 건너뛸 수 있습니다.

Ops Manager 객체 사양의 spec.configuration 블록에서 다음을 수행해야 합니다.

예시

Ops Manager 구성 마법사를 비활성화하려면 spec.configuration 블록에서 다음 설정을 구성합니다.

1spec:
2  configuration:
3    mms.ignoreInitialUiSetup: "true"
4    automation.versions.source: "remote"
5    mms.adminEmailAddr: cloud-manager-support@mongodb.com
6    mms.fromEmailAddr: cloud-manager-support@mongodb.com
7    mms.mail.hostname: email-smtp.us-east-1.amazonaws.com
8    mms.mail.port: "465"
9    mms.mail.ssl: "true"
10    mms.mail.transport: smtp
11    mms.minimumTLSVersion: TLSv1.2
12    mms.replyToEmailAddr: cloud-manager-support@mongodb.com

예시 값을 Ops Manager에서 사용하려는 값으로 바꿉니다.

백업

Kubernetes Operator는 기본값으로 백업 을 활성화합니다. Kubernetes Operator는 하나의 파드로 구성된 StatefulSet를 배포하여 백업 디먼 서비스를 호스팅하다 한 다음 백업 데몬의 헤드 데이터베이스 에 대한 영구 볼륨 클레임 및 영구 볼륨을 생성합니다. Kubernetes Operator는 MongoDB Ops Manager API 사용하여 백업 디먼 활성화 하고 헤드 데이터베이스 구성합니다.

중요

백업을 구성하려면 oplog 저장소 및 다음 중 하나에 대한 MongoDB 리소스 또는 MongoDBMultiCluster 리소스를 만들어야 합니다.

  • oplog 저장 또는 S3 oplog 저장. oplog 저장과 S3 oplog 저장을 모두 배포하는 경우 MongoDB Ops Manager는 백업에 사용할 저장을 무작위로 선택합니다.

  • S3 스냅샷 저장소 또는 블록 저장소 . S3 스냅샷 저장소 와 블록 저장소를 모두 배포하는 경우 MongoDB Ops Manager는 백업에 사용할 스냅샷 저장소를 무작위로 선택합니다.

Ops Manager 리소스는 이러한 백업 리소스를 구성할 때까지 Pending 상태로 유지됩니다.

백업 작업을 암호화 할 수도 있지만 동일한 Kubernetes 연산자 인스턴스가 MongoDBOpsManager 와 MongoDB 사용자 지정 리소스를 모두 관리하지 않는 배포에는 제한 이 적용됩니다.

Oplog 저장소

oplog 슬라이스를 저장하려면 3명의 멤버로 구성된 복제본 세트를 배포해야 합니다.

Oplog 데이터베이스는 SCRAM 인증 메커니즘만 지원합니다. 다른 인증 메커니즘은 활성화할 수 없습니다.

oplog 데이터베이스에서 SCRAM 인증을 활성화하는 경우 다음을 수행해야 합니다.

  • MongoDB 사용자 리소스를 생성하여 Ops Manager를 oplog 데이터베이스에 연결합니다.

  • Ops Manager 리소스 정의에서 사용자의 name 를 지정합니다.

S3 Oplog 스토어

S3 oplog 저장소를 구성하려면 데이터베이스 Backup Oplog를 저장할 AWS S3 또는 S3 호환 버킷을 생성해야 합니다.

Ops Manager 리소스 정의의 spec.backup.s3OpLogStores.mongodbResourceRef.name 설정을 사용하여 MongoDB 리소스와 MongoDBMultiCluster 리소스 모두에 대해 oplog 저장소를 구성할 수 있습니다.

블록 저장소

블록 저장소 를 구성하려면 스냅샷을 저장할 복제본 세트를 배포해야 합니다.

S3 Snapshot Store

S 스냅샷3 저장소 를 구성하려면 데이터베이스 백업 스냅샷 을 저장할 Amazon Web Services S3또는 S3호환 버킷을 만들어야 합니다.

기본 구성은 애플리케이션 데이터베이스에 스냅샷 메타데이터를 저장합니다. 스냅샷 메타데이터를 저장하는 복제본 세트를 배포한 다음, Ops Manager 리소스 정의의 spec.backup.s3Stores.mongodbResourceRef.name 설정을 사용하여 구성할 수도 있습니다.

MongoDB 리소스와 MongoDBMultiCluster 리소스 모두에 대해 S3 스냅샷 저장소를 구성할 수 있습니다.

Operator가3 관리하지 않는 추가 S 구성 설정 Kubernetes 은 MongoDB Ops Manager 애플리케이션을 통해 업데이트할 수 있습니다.

백업 비활성화

백업을 활성화한 후 비활성화하려면 다음을 수행합니다.

  1. MongoDB Ops Manager Kubernetes 객체 spec.backup.enabled 설정을 로 false 설정합니다.

  2. MongoDB Ops Manager 애플리케이션에서 백업을 비활성화합니다 .

  3. 백업 디먼 서비스 StatefulSet를 삭제합니다.

    kubectl delete statefulset <metadata.name> -backup-daemon \
     -n <metadata.namespace>

중요

백업 디먼 서비스 StatefulSet를 삭제 백업 데몬의 헤드 데이터베이스 에 대한 영구 볼륨 클레임 및 영구 볼륨은 삭제되지 않습니다. 이러한 Kubernetes 리소스를 삭제 전에 저장된 데이터를 조회 할 수 있습니다.

영구 볼륨 회수에 대해 학습하려면 Kubernetes 설명서를 참조하세요.

KMIP 백업 암호화 수동 구성

동일한 Kubernetes 연산자 인스턴스가 MongoDBOpsManager 와 MongoDB 사용자 지정 리소스를 모두 관리 하지 않는 배포의 경우, 다음 절차를 사용하여 Ops Manager에서 KMIP 백업 암호화 클라이언트 설정을 수동으로 구성해야 합니다. Kubernetes 연산자 가 두 리소스를 모두 관리하는 경우 대신 Ops Manager에 대한 KMIP 백업 암호화 구성 을 참조하세요.

전제 조건
절차

  1. TLS 시크릿을 MongoDBOpsManager 사용자 지정 리소스에 마운트합니다. 예를 들면 다음과 같습니다.

    apiVersion: mongodb.com/v1
    kind: MongoDBOpsManager
    metadata:
      name: ops-manager-pod-spec
    spec:
      < ... omitted ... >
      statefulSet:
        spec:
          template:
            spec:
              volumes:
              - name: kmip-client-test-prefix-mdb-latest-kmip-client
                secretName: test-prefix-mdb-latest-kmip-client
              containers:
                - name: mongodb-ops-manager
                  volumeMounts:
                  - mountPath: /mongodb-ops-manager/kmip/client/test-prefix-mdb-latest-kmip-client
                    name: kmip-client-test-prefix-mdb-latest-kmip-client
                    readOnly: true
      ...

  2. KMIP 를 사용하도록 프로젝트 구성하기 의 절차에 따라 MongoDB Ops Manager에서 프로젝트에 대한 KMIP 설정을 구성합니다.

HTTPS를 통해 실행되도록 Ops Manager 구성

Kubernetes 연산자를 통해 생성된 Ops Manager 인스턴스가 HTTP 대신 HTTPS 를 통해 실행되도록 구성할 수 있습니다.

HTTPS 를 통해 실행되도록 Ops Manager 인스턴스를 구성하려면 다음을 수행합니다.

  1. TLS 인증서와 비공개 키가 포함된 시크릿을 생성합니다.

  2. 이 시크릿을 Ops Manager 구성 객체에 추가합니다.

자세한 지침 은 Ops Manager 리소스 배포를 참조하세요.

중요

기존 배포가 있는 경우 HTTPS 를 활성화한 후 수동으로 다시 시작해야 합니다. 배포를 다시 시작하지 않으려면 managed 리소스를 배포하기 전에 HTTPS 를 구성하세요.

자세한 내용은 배포 후 HTTPS 활성화를 참조하세요.

Ops Manager 애플리케이션 액세스

기본적으로 Kubernetes 연산자는 Kubernetes cluster 외부에서 발생하는 트래픽을 Ops Manager 애플리케이션으로 라우팅하는 Kubernetes 서비스를 생성하지 않습니다.

Ops Manager 애플리케이션에 액세스하려면 다음을 수행합니다.

  • Kubernetes 서비스를 생성하도록 Kubernetes 연산자를 구성합니다.

  • Kubernetes 서비스를 수동으로 생성합니다. MongoDB는 클라우드 공급자가 지원하는 경우 LoadBalancer Kubernetes 서비스를 사용할 것을 권장합니다.

  • OpenShift 사용하는 경우 경로를 사용하세요.

  • Istio와 같은 타사 서비스를 사용합니다.

가장 간단한 방법은 외부 트래픽을 MongoDB Ops Manager 애플리케이션 으로 라우팅하는 Kubernetes 서비스를 생성하도록 Kubernetes Operator를 구성하는 것입니다. MongoDB Ops Manager 배포서버 절차에서는 서비스를 생성하도록 Kubernetes Operator를 구성하는 객체 사양에 다음 설정을 추가하도록 지시합니다.

이 외에도 여러 Kubernetes 클러스터에 배포하는 경우 다중 클러스터 아키텍처를 참조하십시오.

원격 또는 로컬 모드에서 Ops Manager 배포

환경에서 클러스터의 Kubernetes 호스트에 인터넷 액세스 권한을 부여할 수 없는 경우, Operator를 사용하여 단일 MongoDB Ops Manager 클러스터가 로컬 또는 원격 모드에서 작동하도록 구성할 수 있습니다.Kubernetes 이러한 모드에서 백업 데몬과 관리되는 MongoDB 리소스는 인터넷이 아닌 MongoDB Ops Manager에서 설치 아카이브를 다운로드합니다.

외부 MongoDB 배포 관리하기

Kubernetes 연산자로 Ops Manager를 배포하면 Ops Manager가 배포된 MongoDB 데이터베이스 리소스를 managed합니다.

  • Ops Manager와 동일한 Kubernetes cluster로.

  • Kubernetes cluster 외부.

Ops Manager가 Ops Manager와 다른 Kubernetes cluster 또는 Kubernetes cluster 외부에 배포된 MongoDB database 리소스를 managed하는 경우, 다음을 수행해야 합니다.

  1. Ops Manager 리소스 사양의 spec.configuration 에 mms.centralUrl 설정을 추가합니다.

    Ops Manager가 Kubernetes cluster 외부에 노출되는 URL로 값을 설정합니다.

    spec:
      configuration:
        mms.centralUrl: https://a9a8f8566e0094380b5c257746627b82-1037623671.us-east-1.elb.example.com:8080/

  2. Kubernetes Operator를 사용하여 배포한 Kubernetes cluster 내부의 모든 MongoDB database 리소스에서 참고 하는 ConfigMap을 업데이트합니다 .

    data.baseUrl 를 Ops Manager 리소스 사양 spec.configuration.mms.centralUrl 설정과 동일한 값으로 설정합니다.

    중요

    MongoDB database 여기에는 oplog 및 스냅샷 저장소에대해 리소스가 참조하는 ConfigMap이 포함됩니다.

멀티 클러스터에 MongoDB Ops Manager 배포

다중 클러스터 아키텍처를 참조하세요.

비밀 저장소

Kubernetes 에 시크릿이 저장되지 않도록 하려면 Kubernetes Operator가 생성하는 모든 Kubernetes 시크릿 을 시크릿 저장 도구로 마이그레이션 . 멀티 클러스터 배포는 HashiCorp Vault와 같은 비밀 저장 도구에 비밀을 저장하는 것을 지원하지 않습니다.

전제 조건

  1. 아직 실행하지 않았다면 다음 명령을 실행하여 생성한 네임스페이스에서 kubectl 명령을 모두 실행합니다.

    kubectl config set-context $(kubectl config current-context) \
      -n <metadata.namespace>

    참고

    다중 Kubernetes 클러스터 MongoDB deployment에서 MongoDB Ops Manager 리소스를 배포하는 경우:

    • context 를 연산자 클러스터 의 이름으로 설정합니다(예: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME").

    • --namespace 를 다중 Kubernetes 클러스터 MongoDB 배포에 사용한 것과 동일한 범위 (예: kubectl config --namespace "mongodb" 로 설정합니다.

  2. Kubernetes Operator용 MongoDB 컨트롤러를 설치합니다.

  3. Ops Manager를 배포하려는 호스트의 메모리가 최소 5GB인지 확인합니다.

  1. MongoDB Ops Manager 리소스 와 동일한 네임스페이스 에 관리자에 대한 Kubernetes 시크릿 을 생성합니다. 다중 Kubernetes 클러스터 MongoDB deployment 에 MongoDB Ops Manager 배포하는 경우 다중 Kubernetes 클러스터 MongoDB deployment 범위에 설정하다 것과 동일한 네임스페이스 사용합니다.

    HashiCorp Vault를 시크릿 저장 도구로 사용하는 경우 대신 Vault Secret을 생성할 수 있습니다.

    시크릿 스토리지 옵션에 대한 자세한 내용은 시크릿 스토리지 구성을 참조하세요.

    MongoDB Ops Manager 리소스를 배포하면 MongoDB Ops Manager는 이러한 자격 증명을 가진 사용자를 생성하고 이 사용자에게 Global Owner 역할을 부여합니다. 이 자격 증명을 사용하여 MongoDB Ops Manager에 처음 로그인합니다. MongoDB Ops Manager를 배포한 후에는 비밀번호를 변경하거나 이 시크릿을 제거하세요.

    참고

    관리자의 비밀번호는 MongoDB Ops Manager 비밀번호 복잡성 요구 사항을 준수해야 합니다.

    kubectl create secret generic <adminusercredentials> \
      --from-literal=Username="<username>" \
      --from-literal=Password="<password>" \
      --from-literal=FirstName="<firstname>" \
      --from-literal=LastName="<lastname>"

  1. (선택 사항) MongoDB Ops Manager 데이터베이스 사용자의 비밀번호를 설정하려면 MongoDB Ops Manager 리소스와 동일한 네임스페이스 에 시크릿 을 생성합니다.

    HashiCorp Vault를 시크릿 저장 도구로 사용하는 경우 대신 Vault Secret을 생성할 수 있습니다.

    Kubernetes Operator는 MongoDB Ops Manager가 Ops Manager Application Database 에 연결하는 데 사용하는 데이터베이스 사용자를 생성합니다. 다음 명령을 호출하여 시크릿을 생성하여 이 데이터베이스 사용자의 비밀번호를 설정할 수 있습니다.

    kubectl create secret generic <om-db-user-secret-name> \
      --from-literal=password="<om-db-user-password>"

    참고

    Ops Manager 데이터베이스 사용자에 대한 암호를 생성하기로 선택한 경우 Ops Manager 리소스 정의에 암호의 name 를 지정해야 합니다. 기본적으로 Kubernetes 연산자는 password 키에서 비밀번호 값을 찾습니다. 비밀번호 값을 다른 키에 저장한 경우 Ops Manager 리소스 정의에서 해당 key 이름도 지정해야 합니다.

    시크릿을 생성하지 않으면 Kubernetes Operator가 자동으로 비밀번호를 생성하여 내부에 저장합니다. 자세한 내용은 인증을 참조하세요.

  2. (선택 사항). S 스냅샷3 저장소 에 백업을 구성하려면 MongoDB Ops Manager 리소스 와 동일한 네임스페이스 에 시크릿을 생성합니다.

    HashiCorp Vault를 시크릿 저장 도구로 사용하는 경우 대신 Vault Secret을 생성할 수 있습니다.

    이 비밀은 Kubernetes Operator가 Ops Manager를 AWS S3 또는 S3 호환 버킷에 연결할 수 있도록 S3 자격 증명을 저장합니다. 시크릿에는 다음과 같은 키-값 쌍이 포함되어야 합니다.

    키

    값

    accessKey

    S3 또는 S3 호환 버킷을 소유한 AWS 사용자의 고유 식별자입니다.

    secretKey

    S3 또는 S3 호환 버킷을 소유한 Amazon Web Services사용자의 비밀 키입니다.

    시크릿을 생성하려면 다음 명령을 호출합니다.

    kubectl create secret generic <my-aws-s3-credentials> \
      --from-literal=accessKey="<AKIAIOSFODNN7EXAMPLE>" \
      --from-literal=secretKey="<wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY>"

    S3 스냅샷 스토리지 관리에 대해 자세히 알아보려면 전제 조건을 참조하세요.

이 페이지의 내용