고가용성 Ops Manager 애플리케이션 구성

이 페이지의 내용

고려 사항

로드 밸런서
Ops Manager Application Database용 복제본 세트
gen.key 파일
업그레이드 모드
멀티 리전 배포서버의 성능
전제 조건
절차
Ops Manager 애플리케이션 호스팅 풀로 로드 밸런서를 구성합니다.
로드 밸런서를 사용하도록 Ops Manager를 구성합니다.
각 Ops Manager 애플리케이션 호스트를 복제 호스트 정보로 업데이트합니다.
MongoDB Agent 구성 파일에서 Ops Manager URL을 로드 밸런서 URL로 변경합니다.
Ops Manager 애플리케이션 중 하나를 시작합니다.
gen.key 파일을 각 Ops Manager 호스트에 복사합니다.
나머지 Ops Manager 애플리케이션을 시작합니다.
추가 정보

애플리케이션은 로드 밸런서 뒤에서 여러 애플리케이션 서버를 사용하고 를 호스팅하다 하는 복제본 MongoDB Ops Manager MongoDB Ops Manager 세트 를 사용하여 고가용성 을 Ops Manager Application Database 제공합니다.

고려 사항

로드 밸런서

Ops Manager 애플리케이션의 구성 요소는 요청 간에 상태가 저장되지 않습니다. 모든 서버가 동일한 Ops Manager Application Database를 읽는 한, 모든 Ops Manager 애플리케이션 서버가 요청을 처리할 수 있습니다. 하나의 Ops Manager 애플리케이션을 사용할 수 없게 되면 다른 애플리케이션이 요청을 처리합니다.

고가용성을 위해 이 기능을 활용하려면 원하는 로드 밸런서를 구성하여 Ops Manager 애플리케이션 호스트 풀 사이에 균형을 맞추세요. Ops Manager에서 이 작업을 수행하려면 다음 단계에 따릅니다.

URL to Access Ops Manager 속성을 로드 밸런서 URL로 설정합니다.
Load Balancer Remote IP Header 속성을 X-Forwarded-For로 설정합니다. 이 필드는 로드 밸런서가 원래 클라이언트의 IP 주소를 식별하는 데 사용하는 HTTP 헤더 필드입니다.
참고
기본적으로 을(를) 지원하지 않는 계층- 로드4 밸런서를 사용하는 경우 를 X-Forwarded-For X-Forwarded-For 활성화하거나 프록시 프로토콜 을 사용합니다. .

Ops Manager 애플리케이션은 클라이언트의 IP 주소를 사용하여 API에 대해 액세스 목록을 감사, 로깅 및 설정합니다 .

로드 밸런서를 구성하고 시작한 후에는 개별 호스트 URL에서 Ops Manager 애플리케이션에 로그인해서는 안 됩니다.

참고

각 Ops Manager 애플리케이션 서버에 대한 액세스를 허용하지 않으려면 방화벽 규칙을 적절히 구성하세요.

예시

다음 URL을 제공하는 두 개의 Ops Manager 호스트가 있는 경우

ops1.example.com
ops2.example.com

다음 URL의 로드 밸런서 뒤에 배치합니다.

opsmanager.example.com

로드 밸런서를 구성하고 시작한 후에는 ops1.example.com에 로그인하지 않아야 합니다. 대신 opsmanager.example.com에 로그인합니다.

참고

구성 파일을 사용하여 이러한 매개변수를 설정하는 경우 mms.remoteIp.header를 로드 밸런서의 URL로 변경하고 mms.centralUrl을 Ops Manager 호스트 및 포트의 URL로 변경합니다.

파일 시스템 스냅샷에는 공유 파일 시스템이 필요합니다.

또는 HTTPS HTTP 로드 밸런서 뒤에서 여러 애플리케이션 서버를 사용하고 MongoDB Ops Manager MongoDB Ops Manager 파일 시스템 스냅샷 을 사용하도록 를 구성하는 경우, FCV 4.2 이상의 백업 스냅샷 작업은 하나 이상의 서버에서 병렬로 실행됩니다. 각 MongoDB Ops Manager 서버에 공유 파일 시스템이 마운트되어 있는지 확인합니다. MongoDB Ops Manager 애플리케이션 서버는 동일한 파일의 서로 다른 오프셋을 열고 쓸 수 있습니다. 공유 파일 시스템에서 이를 허용하는지 확인합니다. 그렇지 않으면 액세스 오류가 발생합니다.

진단 아카이브

Ops Manager 진단 아카이브에 생성 시간을 제공하려면 로드 밸런서의 HTTP idle timeout 매개변수를 180초로 설정합니다.

어플라이언스 네트워크 계층 지원

모든 로드 밸런싱 어플라이언스는 계층 를 7 지원해야 합니다.(애플리케이션 계층) 입니다 .

Ops Manager Application Database용 복제본 세트

독립형이 아닌 복제본 세트 를 배포하여 Ops Manager Application Database 를 호스팅합니다. 복제본 세트는 프라이머리 를 사용할 수 없는 경우 자동으로 페일오버 됩니다.

복제본 세트의 멤버가 여러 시설에 있는 경우, 필요한 경우 단일 시설에 프라이머리 를 선택할 수 있는 충분한 투표가 있는지 확인합니다. 핵심 애플리케이션 시스템을 호스팅하는 시설을 선택합니다. 투표 멤버의 과반수와 프라이머리가 될 수 있는 모든 멤버를 이 시설에 배치합니다. 그렇지 않으면 네트워크 파티션으로 인해 세트가 과반수를 구성하지 못할 수 있습니다. 복제본 세트가 프라이머리를 선택하는 방법에 대한 자세한 내용은 복제본 세트 투표를 참조하세요.

파일 시스템 스냅샷 을 사용하여 복제본 세트를 백업할 수 있습니다. 파일 시스템 스냅샷은 시스템 수준 도구를 사용하여 복제본 세트의 데이터 파일을 보관하는 장치의 복사본을 만듭니다.

Ops Manager Application Database를 호스팅하는 복제본 세트를 배포하려면 MongoDB 인스턴스 백업을 참조하세요.

`gen.key` 파일

gen.key 파일은 Ops Manager의 백업 데이터베이스와 사용자 자격 증명을 암호화하고 해독하는 데 사용되는 24바이트 바이너리 파일입니다. 고가용성 Ops Manager 배포의 일부인 모든 서버에 동일한 gen.key 파일을 저장해야 합니다.

gen.key 파일은 자동 또는 수동으로 생성할 수 있습니다.

Ops Manager에서 파일을 생성하도록 하려면 다음을 수행합니다.

Ops Manager 서버 하나를 시작합니다. gen.key 파일이 없는 경우 Ops Manager가 파일을 만듭니다.

파일을 수동으로 생성하려면 다음 단계에 따릅니다.

24바이트 바이너리 파일을 생성합니다.

예시

다음은 openssl을 사용하여 gen.key 파일을 만듭니다.

openssl rand 24 > /<keyPath>/gen.key

gen.key 파일을 다른 중요한 파일처럼 보호하세요. Ops Manager를 실행하는 사용자로 소유자를 변경하고 소유자에 대해서만 읽기 및 쓰기 권한을 설정합니다.

자동 또는 수동으로 만든 gen.key 파일이 있으면 다른 Ops Manager 서버를 시작하기 전에 현재 서버의 적절한 디렉토리와 다른 Ops Manager 서버의 적절한 디렉토리에 파일을 복사합니다.

/etc/mongodb-mms/ RPM 또는 Ubuntu 설치의 경우
${HOME}/.mongodb-mms/ 아카이브(.tar) 파일 설치의 경우

중요

gen.key 파일을 저장하는 모든 공유 스토리지 리소스는 잠재적인 단일 장애 지점이 발생하지 않도록 고가용성을 제공하도록 구성해야 합니다.
gen.key 파일이 설치되지 않은 Ops Manager 서버는 데이터베이스 백업에 연결할 수 없고 HA Ops Manager 인스턴스의 일부가 될 수 없습니다.
첫 번째 Ops Manager 서버에서 Ops Manager 인스턴스에 대한 gen.key를 생성한 후 gen.key 파일을 안전한 위치에 백업합니다.

업그레이드 모드

동일한 애플리케이션 데이터베이스를 가리키는 둘 이상의 Ops Manager 호스트가 있는 Ops Manager가 설치되어 있는 경우 모니터링 다운타임 없이 Ops Manager를 최신 버전으로 업그레이드할 수 있습니다. 고가용성 Ops Manager 배포의 Ops Manager 호스트 중 하나의 업그레이드를 완료하면 해당 배포가 업그레이드 모드라는 상태로 전환됩니다. 이 상태에서는 업그레이드 중에 Ops Manager를 사용할 수 있습니다. 이 모드는 업그레이드 프로세스 전반에 걸쳐 다음과 같은 장점을 제공합니다.

경고 및 운영 모니터링
Ops Manager 인스턴스를 계속 활성 상태로 유지
Ops Manager 애플리케이션을 읽기 전용 모드로 액세스
데이터를 쓰거나 삭제하는 Ops Manager API가 비활성화됨

Ops Manager 인스턴스는 모든 Ops Manager 호스트가 업그레이드되고 다시 시작될 때까지 업그레이드 모드로 유지됩니다. 한 번에 두 개 이상의 Ops Manager 호스트를 업그레이드해서는 안 됩니다.

멀티 리전 배포서버의 성능

애플리케이션 데이터베이스와 Ops Manager 인스턴스의 지리적 분포는 Ops Manager 애플리케이션의 성능에 영향을 미칠 수 있습니다.

멀티 리전 애플리케이션 데이터베이스 성능

애플리케이션 데이터베이스를 멀티 리전에 복제하려는 경우 대부분의 Ops Manager 쓰기 (write) 워크로드 작업에서 w:2 쓰기 고려 (write concern)를 사용한다는 점을 생각하세요. 이 경우 각 쓰기 (write) 작업에 대해 복제본 세트의 프라이머리 멤버와 세컨더리 멤버 한 개의 승인이 필요합니다.

따라서 애플리케이션 데이터베이스의 세컨더리 복제본 멤버가 프라이머리 멤버와 동일한 리전에 있으면 읽기 및 쓰기 (write) 성능이 향상될 수 있습니다.

예를 들어 애플리케이션 데이터베이스 복제본 세트 멤버 세 개를 리전 세 개에 1-1-1 방식으로 배포하는 경우, 리전 한 개에서 애플리케이션 데이터베이스 복제본 세트 멤버 두 개를 호스팅하고 다른 리전에서 세 번째 복제본 세트 멤버를 호스팅하는 2-1 방식으로 리전 두 개에 애플리케이션 데이터베이스 복제본 세트 멤버 세 개를 배포하는 것보다 성능이 저하될 수 있습니다.

Ops Manager UI의 성능

애플리케이션 데이터베이스 복제본 세트의 애플리케이션 데이터베이스 프라이머리 멤버와 동일한 리전에 배포된 Ops Manager 애플리케이션 인스턴스에 연결하면 Ops Manager UI의 성능이 향상됩니다.

즉 인스턴스 자체가 지연 시간이 길고 멀리 떨어진 다른 리전에서 호스팅되는 프라이머리 애플리케이션 데이터베이스 복제본 세트 멤버에 연결해야 하는 가까운 Ops Manager 애플리케이션 인스턴스에 연결하는 것보다 복제본 세트의 애플리케이션 데이터베이스 프라이머리 멤버와 동일한 리전에서 호스팅되는 Ops Manager 애플리케이션 인스턴스에 연결하는 것이 더 나은 사용자 환경을 제공할 수 있습니다.

전제 조건

Ops Manager Application Database 를 제공하는 복제본 세트 를 배포합니다. 복제본 세트 를 배포 하려면 MongoDB 매뉴얼 의 복제본 세트 배포 를 참조하세요.

절차

다음 절차에서는 Ops Manager 애플리케이션 호스트 중 하나를 사용하여 첫 번째 gen.key를 생성했다고 가정합니다. gen.key를 직접 생성하는 경우 Ops Manager 애플리케이션을 시작하기 전에 Ops Manager 호스트에 배포하세요.

중요

Ops Manager 애플리케이션 서버 앞에 배치된 로드 밸런서는 캐시된 콘텐츠를 반환하지 않아야 합니다. 밸런서에 캐싱이 비활성화되어 있어야 합니다.

로드 밸런싱을 사용하여 여러 개의 Ops Manager 애플리케이션을 구성하려면 다음을 따릅니다.

Ops Manager 애플리케이션 호스팅 풀로 로드 밸런서를 구성합니다.

로드 밸런서가 각 Ops Manager 상태 API 엔드포인트에서 상태 확인을 수행하도록 구성합니다.

http://<OpsManagerHost>:<OpsManagerPort>/monitor/health

Ops Manager가 다음 두 HTTP 코드 중 하나로 응답합니다.

HTTP Status Code	상태
200	Ops Manager 호스트 및 애플리케이션 데이터베이스가 정상으로 보입니다.
500	Ops Manager 호스트 또는 애플리케이션 데이터베이스가 비정상적으로 보입니다. 이 엔드포인트가 자주 `HTTP 500`를 반환하는 경우 문제 해결 섹션을 검토하세요.

밸런서는 캐시된 콘텐츠를 반환하지 않아야 합니다.

로드 밸런서를 사용하도록 Ops Manager를 구성합니다.

Ops Manager에서 Admin, General 탭, Ops Manager Config을 차례로 클릭합니다.
URL to Access Ops Manager 속성이 로드 밸런서 URL을 가리키도록 설정합니다.

Load Balancer Remote IP Header 속성을 로드 밸런서가 클라이언트의 IP 주소를 식별하는 데 사용하는 HTTP 헤더 필드의 이름으로 설정합니다.

Load Balancer Remote IP Header가 설정되고 나면 Ops Manager가 다음 HTTP 헤더를 활성화합니다.

HTTP 헤더	Ops Manager로의 포워딩
X-Forwarded-Host	클라이언트가 호스트 HTTP 요청 헤더에서 요청한 원본 호스트입니다.
X-Forwarded-Proto	HTTP 요청을 수행할 때 사용하는 프로토콜입니다.
X-Forwarded-Server	프록시 서버의 호스트 이름입니다.
X-Proxied-Https	요청의 HTTPS 상태입니다.

각 Ops Manager 애플리케이션 호스트를 복제 호스트 정보로 업데이트합니다.

각 호스팅하다 에서 conf-mms.properties 파일 을 편집하여 mongo.mongoUri 속성 을 의 연결 string Ops Manager Application Database 로 설정하다 합니다. 연결 mongo.mongoUri 에 최소 개의 호스트를 3 지정 해야 string 합니다.

mongo.mongoUri=mongodb://<mms0.example.net>:<27017>,<mms1.example.net>:<27017>,<mms2.example.net>:<27017>/?maxPoolSize=100

MongoDB Agent 구성 파일 에서 MongoDB Ops Manager URL 을 로드 밸런서 URL 로 URL URL 변경합니다.MongoDB Ops Manager MongoDB Agent

각 MongoDB Agent의 호스트에서 다음 단계를 완료합니다.

MongoDB Agent 구성 파일을 엽니다.
```
vi /path/to/configurationFile.config
```
자동화 구성 파일의 위치는 플랫폼에 따라 다릅니다.
/path/to/install/local.config
/etc/mongodb-mms/automation-agent.config
/etc/mongodb-mms/automation-agent.config
/path/to/install/local.config
mmsBaseUrl 속성이 로드 밸런서를 가리키도록 편집하고 변경 사항을 저장합니다.
```
mmsBaseUrl=<LOAD-BALANCER-URL>:<PORT>
```
MongoDB Agent를 다시 시작합니다.

Ops Manager 애플리케이션 중 하나를 시작합니다.

예시

rpm 또는 deb 패키지를 사용하여 Ops Manager 애플리케이션을 설치한 경우 다음을 실행합니다.

service mongodb-mms start

`gen.key` 파일 을 각 MongoDB Ops Manager 호스팅하다 MongoDB Ops Manager 에 복사합니다.

gen.key 파일은 패키지 관리자에서 설치하는 경우 /etc/mongodb-mms/에 있고, 아카이브에서 설치하는 경우 ${HOME}/.mongodb-mms/에 있습니다.

실행 중인 Ops Manager 애플리케이션 호스트의 gen.key 파일을 다른 Ops Manager 애플리케이션 호스트의 해당 디렉토리로 복사합니다.

나머지 Ops Manager 애플리케이션을 시작합니다.

추가 정보

Ops Manager 백업을 고가용성으로 설정하는 방법에 대한 자세한 내용은 고가용성 Ops Manager 백업 서비스 구성을 참조하세요.

돌아가기

데이터베이스 모니터링 활성화

고가용성 백업 배포