자동화
이 페이지의 내용
- Cloud Manager 에 대한 프로그래밍 방식의 액세스 를 위한 OAuth 2.0 인증 은 Preview 기능 으로 제공됩니다.
- 기능 및 해당 설명서는 미리 보기 기간에 언제든지 변경될 수 있습니다. OAuth 2.0 인증 을 사용하려면 Cloud Manager 공개 API 에 대한 요청에 사용할서비스 계정을 만듭니다.
Cloud Manager Automation을 사용하면 Cloud Manager UI를 통해 MongoDB deployments를 배포, 구성 및 managed할 수 있습니다. Cloud Manager 자동화는 배포의 모든 서버에 설치되어야 하는 MongoDB Agent를 사용합니다. MongoDB 에이전트는 Cloud Manager 서비스를 주기적으로 폴링하여 현재 목표를 결정하고 Cloud Manager에게 상태를 지속적으로 보고합니다.
자동화는 64비트 아키텍처에서만 실행됩니다.
Cloud Manager는 MongoDB Agent의 64비트 다운로드만 제공합니다.
자체 하드웨어 사용
자동화를 수동으로 배포하는 경우 모든 서버에 MongoDB Agent가 하나씩 있어야 합니다.
에이전트를 수동으로 배포하는 경우 MongoDB의
dbPath
및 MongoDB 바이너리용 디렉토리를 만들고 에이전트를 실행하는 사용자가 이러한 디렉토리를 소유하는지 확인해야 합니다.rpm
패키지를 사용하여 설치하는 경우 에이전트는mongod
사용자로 실행되고,deb
패키지를 사용하는 경우 에이전트는mongodb
사용자로 실행됩니다.tar.gz
아카이브 파일을 사용하여 설치하는 경우 어느 사용자로든 에이전트를 실행할 수 있습니다.
Networking
MongoDB 포트에 연결
모든 호스트는 MongoDB 포트 간 통신을 허용할 수 있어야 합니다. 기본값은 27017
이지만 Cloud Manager 인터페이스에서 대체 포트 범위를 구성할 수 있습니다.
MongoDB Agent는 cloud.mongodb.com
포트 443
(HTTPS)에서 에 연결할 수 있어야 합니다 . 포트 및 IP 주소 액세스에 대한 자세한 내용은 보안 개요를 참조하세요.
클러스터 내 연결 문제
롤링 업데이트 를 수행할 때 MongoDB Agent 는 다운타임을 피하려고 합니다. 클러스터 의 다른 구성원으로부터 상태 를 수집해야 합니다. 호스트 이름 확인 또는 잘못 구성된 방화벽 과 같은 연결 문제( mongod
와 mongos
사이)로 인해 MongoDB Agent 가 원격 프로세스 상태 를 확인하고 변경을 완료하지 못할 수 있습니다.
다음을 수행하여 클러스터의 모든 노드가 서로 통신할 수 있도록 합니다.
빈번한 자동화 연결
MongoDB Agent는 10초마다 클러스터의 각 노드로부터 상태를 수집하여 환경이 예상되는 상태인지 확인합니다. 이 평가의 일부로, MongoDB Agent는 연결을 생성하고 특정 파일을 검사하여 상태를 확인한 다음 연결을 닫습니다. 이처럼 빈번하고 수명이 짧은 연결은 MongoDB Agent의 일상적인 활동의 일부이므로 성능에 영향을 주지 않아야 합니다.
자동화 구성
자동화 구성을 완료한 후에는 배포 계획이 배포의 요구 사항을 충족하는지 확인하세요. 배포를 확인하기 전에 호스트 이름과 포트를 확인하세요.
크기 조정
MongoDB를 실행하고 데이터 세트의 요구 사항을 지원할 수 있는 충분한 공간을 호스트에 프로비저닝해야 합니다.
배포서버를 실행하기에 충분한 수의 호스트를 프로비저닝해야 합니다. 각
mongod
는 자체 호스트에서 실행되어야 합니다.
빈번한 연결 시간 초과
MongoDB Agent는 다음 중 하나 이상의 이유로 인해 연결 시간이 자주 초과될 수 있습니다.
연결 시간 초과
높은 네트워크 지연 시간
높은 서버 부하
대형 SSL 키
CPU 속도 부족
기본적으로 연결은 40초 후에 시간 초과됩니다. MongoDB는 dialTimeoutSeconds
MongoDB Agent 구성 설정의 값을 점진적으로 늘려 연결 시간 초과가 조기에 자주 발생하는 현상을 방지할 것을 권장합니다. 그러나 이 값을 늘리면 향후 구성 변경 사항을 배포하는 데 필요한 시간도 늘어납니다. 배포에 알맞는 최적의 값을 찾을 때까지 조금씩 해당 값을 늘리면서 실험해 보세요.
자세한 내용은 MongoDB Agent 연결 설정의 dialTimeoutSeconds
를 참조하세요.
배포
특정 조건이 적용되면 We have detected a potential problem while deploying...를 표시하는 배너가 나타납니다. 다음은 몇 가지 예입니다.
배포 변경을 완료할 수 없음/진행 중이 아님
배포를 추가하거나 다시 시작한 후 배포가 몇 분 동안 In Progress
상태로 유지되면 배너가 표시됩니다.
이 시점에는 다음과 같은 네 가지 옵션이 있습니다.
View Diagnostics를 클릭합니다.
View Diagnostics 모달은 배포 중에 발생할 수 있는 모든 오류를 표시합니다.
View Status를 클릭합니다.
Automation Status 모달은 배포 프로세스, 배포 상태를 마지막으로 보고한 시기, 완료하려는 작업, 배포 상태를 표시합니다. 다음과 같은 방법으로 결과를 필터링할 수 있습니다.
Filter processes 검색 창에 호스트 이름을 입력합니다.
Process Type 드롭다운에서 하나 이상의 프로세스 유형을 선택합니다.
Automation State 드롭다운에서 하나 이상의 자동화 상태를 선택합니다.
개별 프로세스의 상태에 대해 자세히 알아보려면 줄임표 아이콘을 클릭하고 View Details 또는 View Agent Logs를 선택합니다.
View Details 프로세스의 배포 계획이 무엇인지, MongoDB Agent가 해당 계획에서 현재 어느 단계에 있는지 보여 줍니다.
View Agent Logs 새 브라우저 창이 열리고 Deployment > Agents > Agent Logs 화면에서 MongoDB Agent 로그의 내용이 표시됩니다. View 메뉴를 클릭하여 다른 에이전트 로그를 선택합니다.
View Agent Logs를 클릭합니다.
새 브라우저 창이 열리고 Deployment > Agents > Agent Logs 화면에서 MongoDB Agent 로그의 내용이 표시됩니다. View 메뉴를 클릭하여 다른 에이전트 로그를 선택합니다.
Allow Override & Edit Configuration를 클릭합니다.
오류를 진단하고 배포 구성을 수정해야 하는 경우 배포 수정 절차에 따라 배포를 수정합니다.
배포를 종료했는데도 여전히 해결책을 찾을 수 없는 경우 Cloud Manager 에서 배포를 제거합니다 .
MongoDB Agent가 다운되었거나 통신이 되지 않음
MongoDB Agent의 자동화 모듈이 Cloud Manager API endpoint
또는 MongoDB Server와 통신할 수 없는 경우, Cloud Manager는 프로젝트에 경고 배너를 표시합니다. MongoDB 에이전트가 통신할 것으로 예상되는지 여부에 따라 두 가지 방법 중 하나로 이 문제를 해결할 수 있습니다.
통신이 필요한 MongoDB Agent
MongoDB Agent가 Cloud Manager 호스트 또는 MongoDB 인스턴스와 통신해야 하는 경우 각 MongoDB Agent에 대해 다음을 확인합니다.
에이전트가 각 호스트에서 실행 중입니다.
Agent와 Cloud Manager API 엔드포인트 는 통신할 수 있습니다.
통신이 필요 없는 MongoDB Agent
MongoDB Agent의 자동화 모듈이 Cloud Manager API endpoint
또는 MongoDB Server 프로세스와 통신해야 하는 경우 자동화된 각 MongoDB Server 배포에 대해 다음을 확인합니다.
MongoDB MongoDB Agent 권한
권한 문제로 인해 자동화가 변경을 완료하지 못할 수 있습니다. View Status 또는 View Diagnostics에서 권한 관련 오류(예: open /data/db/mongod.lock:
permission denied
)를 보고하는 경우 MongoDB Agent 사용자가 dbpath
및 logpath
파일을 소유하고 있으며 이에 대한 읽기 및 쓰기 권한이 있는지 확인하세요.
문제가 있는 MongoDB 호스트 제거
콘솔 또는 API를 사용하여 오래된 호스트, 고장난 호스트 또는 문제가 있는 호스트를 자동화에서 제거할 수 있습니다. 여기에는 MongoDB Agent에 연결할 수 없는 상황이 포함될 수 있습니다.
문제가 있는 호스트를 콘솔을 사용하여 제거하려면 다음을 수행합니다.
MongoDB Cloud ManagerGo MongoDB Cloud Manager 에서 프로젝트 의 Deployment 페이지로 고 (Go) 합니다.
이미 표시되어 있지 않은 경우 탐색 모음의 Organizations 메뉴에서 원하는 프로젝트가 포함된 조직을 선택합니다.
아직 표시되지 않은 경우 탐색 표시줄의 Projects 메뉴에서 원하는 프로젝트를 선택합니다.
Deployment 페이지가 아직 표시되지 않은 경우 사이드바에서 Deployment를 클릭합니다.
배포 페이지가 표시됩니다.
Processes 페이지로 이동합니다.
배포서버 의 Processes 탭 을 클릭합니다.
프로세스 페이지가 표시됩니다.
호스팅하다 를 제거합니다.
문제가 있는 호스트를 찾습니다.
을 클릭한 다음 Remove Server를 클릭합니다.
Cloud Manager가 Are you sure you want to remove this server> 모달을 표시합니다.
제공된 호스트 이름을 Enter the host name 필드에 입력하고 이 서버를 제거하려면 Remove를 클릭합니다.
경고
Remove 을(를) 클릭하면 Cloud Manager가 이 호스트에 대한 모든 모니터링 데이터를 제거합니다. Cloud Manager는 이 조치에 대한 확인 또는 취소를 제공하지 않습니다.
서버를 제거하지 않으려면 Cancel를 클릭합니다.
변경 사항을 검토하려면 Review & Deploy 을(를) 클릭합니다.
Cloud Manager가 제안된 변경 사항을 표시합니다.
만족하면 Confirm & Deploy을(를) 클릭합니다.
Cloud Manager는 현재 모든 프로세스와 에이전트를 제거합니다.
구성을 추가로 변경하려면 Cancel를 클릭합니다.
문제가 있는 호스트를 API를 사용하여 제거하려면 다음과 같이 하세요:
자동화 구성 JSON 파일을 편집합니다.
몇 분간 기다립니다.
MongoDB Cloud Manager 에서 프로젝트 의 Deployment 페이지로 Go 합니다.
이미 표시되어 있지 않은 경우 탐색 모음의 Organizations 메뉴에서 원하는 프로젝트가 포함된 조직을 선택합니다.
아직 표시되지 않은 경우 탐색 표시줄의 Projects 메뉴에서 원하는 프로젝트를 선택합니다.
Deployment 페이지가 아직 표시되지 않은 경우 사이드바에서 Deployment를 클릭합니다.
배포 페이지가 표시됩니다.
배포서버 의 Agents 탭 을 클릭합니다.
Agents (에이전트) 페이지가 표시됩니다.
호스트가 에이전트 목록에 더 이상 나타나지 않는지 확인합니다.
TLS 인증서에 주체 대체 이름이 포함되어 있는지 확인
경고
버전 11.11.0.7349-1 의 MongoDB 에이전트에서는 TLS 인증서에 주체 대체 이름 필드에 값을 포함해야 합니다. MongoDB 에이전트 11.11.0.7355 이상으로 업그레이드하기 전에 MongoDB 배포에 사용된 모든 TLS 인증서에 SAN 이 포함되어 있는지 확인합니다. [1]
[1] | MongoDB는 MongoDB Agent Go 언어를 작성했습니다. Go 1.17 은 X를 사용하는 기능을 제거했습니다.509 CommonName 필드를 호스트 이름으로 때 SAN 이 존재하지 않습니다.클라이언트가 TLS 인증서의 유효성을 검사할 때 클라이언트는 인증서의 SAN 또는 주체 DN(고유 이름) 필드의 값에서 인증서가 적용되는 호스트 이름을 확인합니다. TLS 인증서를 생성할 때 CN(주체 일반 이름) 필드를 사용하여 호스트 이름을 저장하는 경우도 있습니다. CN에는 호스트 이름을 저장하는 데 적합하지 않은 제한 사항이 있습니다. 이러한 제한에는 최대 64자 길이가 포함되며 이름 제약 조건은 지원되지 않습니다. RFC 2818 5월에 호스트 이름을 저장하기 위해 CN을 사용하여 더 이상 사용되지 2000 않습니다. 이 RFC는 인증서의 SAN 필드에 값이 없는 경우 클라이언트가 CN으로 되돌아가도록 요구했습니다. RFC 6125 2011.Go 에서 요구 사항을 1 제거했습니다.15 RFC 2818 준수를 비활성화합니다. RFC 를 사용합니다. CN을 선택 6125 사항으로 만드는 관행입니다. 실제로 이러한 변경을 수행하려면 SAN 값을 추가하거나 CNs.Go 1 사용을 활성화해야 합니다.17 은(는) SAN이 없는 경우 CN을 사용하는 대안을 제거합니다. 현재 버전의 MongoDB Agent에서는 SAN 을 사용해야 합니다 . 자세한 내용 은 이 주제에 대한 프레이저 트위데일의 블로그 게시물을 참조하세요. |
기존 클러스터의 메모리에 구성 파일 저장
Cloud Manager 버전 4.2 또는 버전 4.4.0~4.4.6을 사용하는 경우, enableLocalConfigurationServer
을(를) true
(으)로 설정하고 MongoDB Agent를 다시 시작할 때 오류가 발생할 수 있습니다.
이 문제는 클러스터 생성 후 enableLocalConfigurationServer
가 true
로 설정된 기존 클러스터에만 영향을 줍니다. 클러스터를 만들기 전에 이 값을 설정해도 이 문제가 발생하지 않습니다.
기존 클러스터에 대해 이 설정을 안전하게 변경하려면 다음 안내를 따르세요.
MongoDB Agent 구성 파일 끝에 다음을 추가합니다.
enableLocalConfigurationServer=true MongoDB Agent가 관리하는 각 프로세스를 종료합니다.
다음 명령을 실행하여 MongoDB Agent를 다시 시작합니다.
service mongodb-mms-automation-agent restart 종료한 MongoDB 프로세스를 다시 시작합니다.
automation-mongod.conf
파일에__rest
확장 지시문이 있는지 확인합니다.
구성 파일을 메모리에 저장하는 방법에 대한 자세한 내용은 MongoDB Agent가 구성 파일 및 암호를 관리하는 방법 구성을 참조하세요.