Docs Menu
Docs Home
/
MongoDB Ops Manager
/

FAQ: 자동화

이 페이지의 내용

  • Ops Manager는 어떤 버전의 MongoDB를 관리하나요?
  • Ops Manager 버전 1.8.x 및 2.0.x의 업그레이드 경로는 무엇인가요?
  • Ops Manager는 MongoDB 배포를 어떻게 관리하나요?
  • Ops Manager는 cluster 노드의 유지 관리를 어떻게 수행하나요?
  • 얼마나 많은 자동화가 필요합니까?
  • 자동화를 통해 MongoDB 데이터가 전송되나요?
  • Ops Manager가 업그레이드 중 장애를 처리하나요?
  • Ops Manager에서는 어떤 유형의 배포를 만들 수 있나요?

이로써 Ops Manager 및 자동화 기능에 대한 일반적인 질문에 대한 답변을 확인할 수 있습니다.

Ops Manager는 모니터링되는 MongoDB 프로세스의 관리 작업을 자동화하여 Ops Manager 인터페이스를 통해 MongoDB를 재구성, 중지 및 다시 시작할 수 있도록 합니다.

Ops Manager 자동화는 64비트 아키텍처에서만 실행할 수 있습니다.

특정 MongoDB Ops Manager 함수 및 지원되는 MongoDB 버전은 MongoDB 호환성 매트릭스를 참조하세요.

업그레이드 경로는 Ops Manager 업그레이드를 참조하세요.

MongoDB 배포서버 환경에서 Automation을 배포 한 후 각 에이전트 는 주기적으로 MongoDB Ops Manager 와 통신하고 필요한 작업을 수행합니다.

에이전트는 필요에 따라 작업을 조정하기 위해 환경을 지속적으로 재평가합니다. 에이전트는 이 일상적인 활동의 일부로 cluster 멤버에 대한 단기 연결을 자주 설정합니다. 에이전트에 네트워크 연결 문제나 Ops Manager 장애와 같은 문제가 발생하면 에이전트는 작업을 조정하여 보상하고 목표 상태에 안전하게 도달합니다.

상담원은 현재 상태에서 목표 상태로 이동하기 위한 계획을 만듭니다. 계획은 단계적으로 실행되며, 각 단계는 자율적이며 다른 단계와 독립적입니다.

예시

설치의 경우, MongoDB를 다운로드하고, 적절한 명령줄 옵션으로 프로세스를 시작하고, 복제본 세트를 초기화하고, 정상 과반수를 기다리는 것이 계획에 포함됩니다. 복제본 세트가 활성 상태이고 과반수가 정상이면 구성이 목표 상태에 도달합니다.

MongoDB Ops Manager는 클러스터의 노드에서 유지 관리를 수행할 때 롤링 재시작 을 수행합니다. 에이전트는 유지 관리 기간 동안 클러스터 가용성을 유지하기 위해 모든 노드가 업데이트될 때까지 클러스터의 노드를 하나씩 업데이트하면서 항상 프라이머리 노드를 유지 관리합니다.

클러스터의 각 세컨더리 노드에 대해 자동화는 다음을 수행합니다.

  1. 노드에서 실행 중인 mongod 프로세스를 standalone 모드로 다시 시작합니다.

  2. 유지 관리 작업을 수행합니다.

  3. 노드에서 실행 중인 mongod 프로세스를 replSet 모드로 다시 시작합니다.

세컨더리 노드가 업데이트된 후 자동화는 다음을 수행합니다.

  1. rs.stepDown() 명령을 사용하여 프라이머리를 강등합니다.

  2. 새 프라이머리 노드에 대한 투표를 트리거합니다.

  3. 이전 프라이머리 노드에서 유지 관리 작업을 수행합니다.

  4. 이전 프라이머리 노드에서 실행 중인 mongod 프로세스를 replSet 모드로 다시 시작하여 클러스터에 세컨더리 노드로 참여합니다.

MongoDB Ops Manager 에서 자동화는 다음을 포함한 유지 관리 작업을 위해 클러스터 노드에서 롤링 재시작을 수행합니다.

  • KMIP 키를 순환합니다.

  • 키 파일 회전.

  • mongod 구성 인수를 변경합니다.

  • TLS, auth 또는 clusterAuth 모드를 업그레이드하거나 다운그레이드하는 중입니다.

  • MongoDB 버전 변경.

  • oplog 크기 변경.

  • 복제본 세트에서 프로세스 제거.

  • 백업에서 복원을 취소합니다.

  • 프로파일러 활성화

다음도 참조하세요.

자동화를 사용하려면 managed MongoDB 인스턴스가 실행되는 모든 호스트에서 에이전트가 실행 중이어야 합니다.

에이전트는 MongoDB 배포에서 데이터 레코드를 전송하지 않습니다 . 에이전트는 배포 구성 정보와 MongoDB 로그만 통신합니다.

일반적으로 그렇습니다. Ops Manager의 관리 및 자동화 구성 요소 설계는 가능한 모든 장애를 고려하지 않습니다. 그러나 시스템 아키텍처는 다양한 유형의 장애를 해결할 수 있습니다.

Ops Manager를 사용하여 샤딩된 클러스터, 복제본 세트, 독립형 클러스터 등 모든 MongoDB 배포 유형을 구성할 수 있습니다.

샤딩된 클러스터의 샤드는 반드시 복제본 세트여야 합니다. 즉, 샤드는 독립형 mongod가 될 수 없습니다. 샤드를 단일 mongod로 실행해야 하는 경우(중복성 또는 페일오버를 제공하지 않음) 샤드를 단일 멤버 복제본 세트로 실행합니다.

참고

배포 서버에서 미러링된 mongod 인스턴스를 config 서버로 사용하는 경우 샤딩된 MongoDB 배포 서버를 버전 3.4로 업그레이드할 수 없습니다. 샤딩된 배포 서버를 업그레이드하려면 Config 서버 복제본 세트로 변환을 참조하세요. 변환하려면 샤딩된 배포 서버에서 MongoDB 버전3.2.4 이상을 실행해야 합니다. 이전 버전을 실행 중인 배포 서버는 버전 3.4로 업그레이드하기 전에 버전 3.2.4로 업그레이드해야 합니다.

돌아가기

FAQ: 관리