플랫폼 선택: VM 또는 Kubernetes

Kubernetes

이 경로에서 MongoDB Kubernetes 연산자 MCK는 인프라와 MongoDB 구성을 모두 선언적으로 관리합니다. 즉, 하나 또는 소수의 구성 파일이 MongoDB deployment 정의하고 MongoDB 자동화 인해 인프라 및 MongoDB 구성을 관리 할 수 있습니다.

작동 방식:

• 원하는 배포서버 선언합니다. 그런 다음 MCK는 StatefulSets, 파드, 저장 , 네트워킹 등 MongoDB 사용하는 Kubernetes 리소스를 배포하고 관리합니다. MCK는 Ops Manager 와 함께 조정하고 배포서버 구성합니다.

• 자동화, 백업 및 모니터링 에는 여전히 Ops Manager 필요합니다. MCK와 Ops Manager 함께 작동합니다. MCK는 인프라를 자동화하고, Ops Manager MongoDB 서비스로 실행 데 필요한 서비스를 제공합니다. 이는 대안이 아닙니다.

장단점 및 이점:

• 배포, 확장, 샤딩 변경 및 업그레이드는 인프라와 Ops Manager 운영의 내부 조정이 필요하지 않고 선언적 구성 변경이 됩니다.

• 배포 및 업그레이드 시 호스트 전체에 바이너리를 설치하거나 다시 설치할 필요가 없습니다.

• 다중 리전 배포: 복제본 세트 또는 샤딩된 클러스터 의 멤버는 서로 다른 위치에 있는 여러 Kubernetes 클러스터에 걸쳐 있을 수 있으므로, Kubernetes 클러스터 및 리전 전반에서 회복 탄력성 과 고가용성 보장합니다. 한 클러스터 또는 사이트 다운되면 다른 Kubernetes 클러스터에서 새 MongoDB 노드를 자동으로 생성하여 다른 클러스터 또는 사이트에서 멤버를 다시 만들 수 있습니다.

• Enterprise Advanced 검색 노드에 필요합니다. 검색이 범위 내에 있는 경우, Kubernetes 최소한 검색 노드에 대한 배포서버 의 일부여야 하지만 데이터베이스 노드일 필요는 없습니다.

• Kubernetes MongoDB 인프라 계층 자동화 제공할 수 있는 유일한 플랫폼입니다. 검색 노드에 대한 로드 밸런싱의 자동 프로비저닝 그 예시 입니다.

• VM과 마찬가지로 기본 인프라와 해당 아키텍처 및 설정 에 대한 책임은 사용자에게 있습니다. 여기에는 Kubernetes 클러스터를 위한 상태 저장 저장 프로비저닝 과 Kubernetes 인프라를 관리 하고 유지 관리하는 관련 내부 팀의 지원 이 포함됩니다. MongoDB 실행 에 대한 요구 사항에 따라 개별 MongoDB 배포를 여러 위치에 배포하고 따라서 여러 Kubernetes 클러스터에 배포 하려는 경우 Kubernetes 클러스터 간의 연결과 같은 문제로 확장될 수 있습니다.

올바른 선택인 경우:

• & quot; MongoDB as a Service " 운영 오버헤드 최소화합니다.

• 새로운 Enterprise Advanced 배포.

• 인프라 및 데이터베이스 관리 위한 통합 인터페이스와 검색을 포함한 전체 Enterprise Advanced 기능 액세스 원하는 팀.

VM 또는 물리적 서버

이 과정에서 MongoDB deployment에 대한 인프라 수명 주기 관리 사용자의 책임입니다. MongoDB Agent 각 호스팅하다 에서 실행되며 Ops Manager 통해 MongoDB 구성할 수 있습니다.

작동 방식:

• VM 또는 물리적 서버를 직접 프로비저닝합니다. MongoDB VM 계층에서 인프라를 관리 하지 않습니다. 자동화 또는 기존 도구를 사용하여 VM 또는 서버를 프로비저닝할 수 있습니다.

• 각 호스팅하다 에 MongoDB Agent 설치하고 Ops Manager 점 .

• Ops Manager 해당 호스트에서 실행 배포에 대한 구성, 백업 및 모니터링 처리합니다.

장단점 및 이점:

• VM에서 실행하면 이미 익숙한 인프라 프로비저닝 도구를 재사용하여 MongoDB 용 호스트를 만들 수 있습니다.

• 그러나 이는 인프라와 MongoDB 구성 모두를 변경하는 모든 작업이 배포 또는 확장 포함하여 2단계 작업임을 MEAN 합니다. VM 추가 또는 RAM 및 CPU 추가와 같은 인프라를 프로비저닝하거나 크기를 조정하고 Ops Manager 에서 해당 구성을 변경합니다. 두 시스템이 동일한 배포서버, 인프라 및 구성의 서로 다른 부분을 제어하고 이를 정렬된 상태로 유지합니다. 두 시스템을 정렬하는 것은 사용자의 책임이며, 필요한 경우 해당 정렬을 자동화하고 유지 관리해야 합니다.

• MongoDB 인프라를 복구할 수 없습니다. 예시 를 들어 사이트 다운된 경우 다른 위치 에 복제본 세트 또는 샤드 멤버를 다시 생성하려면 새 호스트를 프로비저닝하고 에이전트 구성한 다음 클러스터 에 다시 연결해야 합니다.

올바른 선택인 경우:

• 기존 인프라 도구 및 VM 자동화 통해 VM 자산을 구축했습니다.

• Kubernetes 채택이 불가능한 조직.

VM 기반 배포서버 완벽하게 지원되며, 현재 많은 대규모 Enterprise Advanced 고객이 이러한 방식으로 실행 . 이는 레거시 또는 더 이상 사용되지 않는 경로가 아니며 기본 플랫폼에 관계없이 자체 호스팅 MongoDB 의 오버헤드 와 복잡성을 줄이기 위해 지속적인 MongoDB 투자가 이루어지고 있습니다.