문서 메뉴
문서 홈
/
MongoDB Ops Manager
/

자동화

이 페이지의 내용

  • 자동화는 64비트 아키텍처에서만 실행됩니다.
  • 자체 하드웨어 사용
  • Networking
  • 자동화 구성
  • 크기 조정
  • 빈번한 연결 시간 초과
  • 배포
  • MongoDB MongoDB Agent 권한
  • 문제가 있는 MongoDB 호스트 제거
  • TLS 인증서에 주체 대체 이름이 포함되어 있는지 확인
  • 기존 클러스터의 메모리에 구성 파일 저장

Ops Manager 자동화를 사용하면 Ops Manager UI를 통해 MongoDB deployment를 배포, 구성 및 관리할 수 있습니다. Ops Manager 자동화는 배포의 모든 서버에 설치되어야 하는 MongoDB Agent를 사용합니다. MongoDB Agent는 주기적으로 Ops Manager 서비스를 폴링하여 현재 목표를 결정하고, 그 상태를 Ops Manager에 지속적으로 보고합니다.

Ops Manager는 64비트 버전의 MongoDB Agent만 다운로드할 수 있습니다.

  • 자동화를 수동으로 배포하는 경우 모든 서버에 MongoDB Agent가 하나씩 있어야 합니다.

  • 에이전트를 수동으로 배포하는 경우 MongoDB의 dbPath 및 MongoDB 바이너리용 디렉토리를 만들고 에이전트를 실행하는 사용자가 이러한 디렉토리를 소유하는지 확인해야 합니다.

    rpm 패키지를 사용하여 설치하는 경우 에이전트는 mongod 사용자로 실행되고, deb 패키지를 사용하는 경우 에이전트는 mongodb 사용자로 실행됩니다. tar.gz 아카이브 파일을 사용하여 설치하는 경우 어느 사용자로든 에이전트를 실행할 수 있습니다.

모든 호스트는 MongoDB 포트 간 통신을 허용할 수 있어야 합니다. 기본값은 27017이지만 Ops Manager 인터페이스에서 대체 포트 범위를 구성할 수 있습니다.

MongoDB Agent는 포트 8080 (HTTP) 또는 포트 8443 (HTTPS)에서 Ops Manager에 연결할 수 있어야 합니다 . 포트 및 IP 주소 액세스에 대한 자세한 내용은 보안 개요를 참조하세요.

롤링 업데이트를 수행할 때 MongoDB Agent는 다운타임을 피하려고 합니다. 클러스터의 다른 멤버로부터 상태를 수집해야 합니다. 호스트 이름 확인 또는 잘못 구성된 방화벽과 같은 연결 문제( mongodmongos사이)로 인해 MongoDB Agent가 원격 프로세스 상태를 확인하고 변경을 완료하지 못할 수 있습니다.

다음을 수행하여 클러스터의 모든 노드가 서로 통신할 수 있도록 합니다.

  1. 비샤드 클러스터:

    1. mongod 에 로그인합니다.

    2. 해당 mongod 호스트에서 복제본 세트의 다른 모든 멤버에 로그인합니다.

  2. 샤드 클러스터:

    1. mongod 에 로그인합니다.

    2. 해당 mongod 호스트에서 샤드의 다른 모든 멤버에 로그인합니다.

    3. mongos 에 로그인합니다.

    4. mongos 호스트에서 다음을 수행합니다.

      1. 다른 mongos 호스트에 로그인합니다.

      2. 각 샤드의 다른 모든 노드에 로그인합니다.

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 상태로 유지되면 배너가 표시됩니다.

이 시점에는 다음과 같은 네 가지 옵션이 있습니다.

  1. View Diagnostics를 클릭합니다.

    View Diagnostics 모달은 배포 중에 발생할 수 있는 모든 오류를 표시합니다.

  2. 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 메뉴를 클릭하여 다른 에이전트 로그를 선택합니다.

  3. View Agent Logs를 클릭합니다.

    새 브라우저 창이 열리고 Deployment > Agents > Agent Logs 화면에서 MongoDB Agent 로그의 내용이 표시됩니다. View 메뉴를 클릭하여 다른 에이전트 로그를 선택합니다.

  4. Allow Override & Edit Configuration를 클릭합니다.

    오류를 진단하고 배포 구성을 수정해야 하는 경우 배포 수정 절차에 따라 배포를 수정합니다.

배포를 종료했는데도 여전히 해결 방법을 찾을 수 없는 경우, Ops Manager에서 배포를 제거합니다.

MongoDB Agent의 자동화 모듈이 Ops Manager 애플리케이션 API endpoint 또는 MongoDB Server 프로세스와 통신할 수 없는 경우, Ops Manager는 프로젝트에 경고 배너를 표시합니다. MongoDB Agent가 통신할 것으로 예상되는지 여부에 따라 다음 두 가지 방법 중 하나로 이 문제를 해결할 수 있습니다.

MongoDB Agent가 Ops Manager 호스트 또는 MongoDB 인스턴스와 통신해야 하는 경우, 각 MongoDB Agent에 대해 다음을 확인합니다.

  1. 에이전트가 각 호스트에서 실행 중입니다.

  2. 에이전트와 MongoDB Ops Manager 애플리케이션 API 엔드포인트통신할 수 있습니다.

MongoDB Agent의 자동화 모듈이 Ops Manager 애플리케이션 API endpoint 또는 MongoDB Server 프로세스와 통신해야 하는 경우, 자동화된 각 MongoDB Server 배포에 대해 다음을 확인합니다.

  1. 경고 배너에서 Allow Editing & Override Current Configuration 링크를 클릭합니다.

  2. 불필요한 MongoDB Agent를 제공하는 호스트에서 실행 중인 모든 프로세스 (mongod mongos)를 제거합니다.

권한 문제로 인해 자동화가 변경을 완료하지 못할 수 있습니다. View Status 또는 View Diagnostics에서 권한 관련 오류(예: open /data/db/mongod.lock: permission denied)를 보고하는 경우 MongoDB Agent 사용자가 dbpathlogpath 파일을 소유하고 있으며 이에 대한 읽기 및 쓰기 권한이 있는지 확인하세요.

콘솔 또는 API를 사용하여 오래된 호스트, 고장난 호스트 또는 문제가 있는 호스트를 자동화에서 제거할 수 있습니다. 여기에는 MongoDB Agent에 연결할 수 없는 상황이 포함될 수 있습니다.

문제가 있는 호스트를 콘솔을 사용하여 제거하려면 다음을 수행합니다.

  1. 프로젝트로 이동합니다.

  2. Servers를 클릭합니다.

  3. 문제가 있는 호스트를 찾습니다.

  4. 을 클릭한 다음 Remove Server를 클릭합니다.

    Ops Manager가 Are you sure you want to remove this server> 모달을 표시합니다.

  5. 제공된 호스트 이름을 Enter the host name 필드에 입력하고 이 서버를 제거하려면 Remove를 클릭합니다.

    경고

    Remove를 클릭하면 Ops Manager가 이 호스트에 대한 모든 모니터링 데이터를 제거합니다. Ops Manager는 이 조치에 대한 확인 또는 취소를 제공하지 않습니다.

    서버를 제거하지 않으려면 Cancel를 클릭합니다.

  6. 변경 사항을 검토하려면 Review & Deploy 을(를) 클릭합니다.

    Ops Manager가 제안된 변경 사항을 표시합니다.

    • 만족하면 Confirm & Deploy을(를) 클릭합니다.

      Ops Manager 이때 모든 프로세스와 에이전트를 제거합니다.

    • 구성을 추가로 변경하려면 Cancel를 클릭합니다.

문제가 있는 호스트를 API를 사용하여 제거하려면 다음과 같이 하세요:

  1. 현재 자동화 구성을 가져옵니다.

  2. 자동화 구성 JSON 파일을 편집합니다.

  3. 프로세스복제본 세트에서 오래된 노드를 제거합니다.

  4. 자동화 구성 파일을 업데이트합니다.

  5. 몇 분간 기다립니다.

  6. Agents 뷰를 확인합니다.

  7. 호스트가 에이전트 목록에 더 이상 나타나지 않는지 확인합니다.

경고

버전 11.12.0.7384의 MongoDB Agent에서는 TLS 인증서에 주체 대체 이름 필드에 값이 포함되어야 합니다. 11.12.0.7384로 업그레이드하기 전에 MongoDB deployment에 사용된 모든 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 사용해야 합니다 . 자세한 내용 은 이 주제에 대한 프레이저 트위데일의 블로그 게시물을 참조하세요.

Ops Manager 버전 4.2 또는 버전 4.4.0~4.4.6을 사용하는 경우, enableLocalConfigurationServertrue로 설정하고 MongoDB Agent를 다시 시작할 때 오류가 발생할 수 있습니다.

이 문제는 클러스터 생성 후 enableLocalConfigurationServertrue로 설정된 기존 클러스터에만 영향을 줍니다. 클러스터를 만들기 전에 이 값을 설정해도 이 문제가 발생하지 않습니다.

기존 클러스터에 대해 이 설정을 안전하게 변경하려면 다음 안내를 따르세요.

  1. MongoDB Agent 구성 파일 끝에 다음을 추가합니다.

    enableLocalConfigurationServer=true
  2. MongoDB Agent가 관리하는 각 프로세스를 종료합니다.

  3. 다음 명령을 실행하여 MongoDB Agent를 다시 시작합니다.

    service mongodb-mms-automation-agent restart
  4. 종료한 MongoDB 프로세스를 다시 시작합니다.

  5. automation-mongod.conf 파일에 __rest 확장 지시문이 있는지 확인합니다.

구성 파일을 메모리에 저장하는 방법에 대한 자세한 내용은 MongoDB Agent가 구성 파일 및 암호를 관리하는 방법 구성을 참조하세요.

돌아가기

인증

다음

모니터링