리소스 풀 설계 고려 사항

아티클
03/13/2023

중요

이 버전의 Operations Manager는 지원이 종료되었습니다. Operations Manager 2022로 업그레이드하는 것이 좋습니다.

리소스 풀은 관리 서버 및/또는 게이트웨이 서버 간에 작업을 배포하고 실패한 멤버의 작업을 이어받는 데 사용되는 관리 서버 또는 게이트웨이 서버의 논리 그룹입니다. 즉, 워크플로의 고가용성 및 확장성을 제공합니다. 관리 그룹을 설계할 때 네트워크 디바이스, Linux/UNIX 시스템 및 리소스 풀을 활용하도록 설계된 다른 워크로드를 모니터링할 시점을 고려해야 합니다.

개요

리소스 풀은, 풀 구성원 중 하나를 사용할 수 없는 경우 모니터링 워크플로를 인수할 수 있는 관리 서버 및/또는 게이트웨이 서버를 여러 구성원에 제공하여 모니터링 연속성을 유지합니다. 특정 목적을 위해 리소스 풀을 만들 수 있습니다. 예를 들어 기본 데이터 센터에서 관리 서버 리소스 풀을 만들어 네트워크 디바이스를 모니터링할 수 있습니다.

리소스 풀은 "과반수 노드 집합"(<풀의 멤버인 노드 수>/2 + 1) 클러스터링과 유사한 논리를 적용합니다. 풀의 가용성을 유지하려면 풀에 쿼럼 투표 구성원의 50%가 넘게 있어야 하므로 쿼럼을 유지하려면 풀에 구성원이 최소한 세 개는 있어야 합니다. 풀의 멤버가 두 개뿐이고 한 멤버만 사용할 수 없는 경우 쿼럼이 손실됩니다.

운영 콘솔에서 만든 모든 리소스 풀에 대해 쿼럼에 도달할 수 있도록 풀에 멤버 수가 짝수인 경우에도 기본 관찰자라고 하는 Operations Manager 데이터베이스에 항상 투표가 제공됩니다. 또한 이 문서의 뒷부분에서 설명하는 관리 그룹을 처음 만들 때 기본적으로 만든 세 개의 리소스 풀에도 적용됩니다. PowerShell cmdlet NewSCOM ResourcePool을 사용하여 생성된 모든 리소스 풀에 대해서는 기본적으로 사용하지 않도록 설정됩니다. Operations Manager 데이터베이스를 기본 관찰자로 포함하면 리소스 풀의 고가용성을 유지하기 위해 최소 두 개의 관리 서버만을 배포하도록 요구하므로 관리 그룹의 복잡성이 줄어듭니다.

리소스 풀을 지원하는 다른 역할은 관찰자입니다. 풀에 대한 워크플로 로드에 참여하지 않는 관리 서버 또는 게이트웨이 서버입니다. 그러나 쿼럼 결정에 참여합니다. 정상적인 상황에서는 사용되지 않으므로 고려하지 않아야 합니다.

멤버 자격에는 두 가지 유형이 있습니다.

자동
수동

리소스 풀을 만들 때 해당 멤버 자격은 수동으로 설정되며 자동으로 다시 구성할 수 없습니다. System Center – Operations Manager 관리 그룹이 생성될 때 기본적으로 자동 멤버 자격의 리소스 풀 세 개가 생성됩니다. 다음 표에서는 이 세 가지 리소스 풀에 대해 설명합니다.

리소스 풀 이름	Description
모든 관리 서버 리소스 풀	그룹 계산, 가용성, 분산된 모니터링 상태 롤업 및 데이터베이스 정리 워크플로를 수행합니다.
알림 리소스 풀	경고 구독 서비스는 경고 알림을 지원하기 위해 이 리소스 풀을 대상으로 지정합니다.
AD 할당 리소스 풀	AD 통합 워크플로는 관리 서버에 대한 자동 에이전트 할당을 지원하기 위해 이 리소스 풀을 대상으로 지정합니다.

모든 관리 서버 리소스 풀의 멤버 자격은 자동이기 때문에 시작되는 모든 관리 서버는 자동으로 이 리소스 풀의 구성원이 됩니다. 지리적으로 분산된 대체 작업의 통합과 같은 특정 아키텍처 및 디자인 고려 사항에서는 모든 관리 서버 리소스 풀에 대한 자동 할당이 바람직하지 않을 수 있습니다. 이러한 경우 멤버 자격 할당을 자동에서 수동으로 변경할 수 있습니다. 마찬가지로 수동 할당을 통해 모든 관리 서버 리소스 풀에 관리 서버를 추가해야 합니다.

참고

모든 관리 서버 리소스 풀의 멤버는 읽기 전용입니다. 해당 멤버 자격을 자동에서 수동으로 변경하려면 풀 멤버 자격 수정을 참조하세요.

리소스 풀이 도입되면 모든 멤버가 짧은 대기 시간 네트워크(10ms 미만)로 연결되는 것이 좋습니다. 리소스 풀은 여러 데이터 센터 또는 Microsoft Azure와 같은 하이브리드 클라우드 환경에 배포해서는 안 됩니다.

리소스 풀 가용성 예제

다음 예제에서는 관리 서버만 또는 게이트웨이 서버만을 사용하며, 다음 구성을 기반으로 하는 리소스 풀 가용성의 개념을 보여 줍니다.

단일 관리 서버

두 개의 구성원만 있고 쿼럼에 도달하지 않으므로 기본 관찰자가 기본적으로 사용되며 별다른 이점을 제공하지는 않습니다.
관리 서버가 단일 실패 지점이므로 고가용성이 없습니다.

두 개의 관리 서버

기본 관찰자가 기본적으로 사용됩니다.
3개의 투표 멤버(관리 서버 2개와 기본 관찰자)가 있기 때문에 풀에 대한 고가용성이 있습니다.
기본 관찰자를 사용하지 않도록 설정하는 경우 풀에 대한 고가용성이 손실됩니다.

세 개의 관리 서버

기본 관찰자가 기본적으로 사용됩니다.
3개의 관리 서버와 기본 관찰자인 4명의 투표 멤버가 있기 때문에 풀에 대한 고가용성이 있습니다.
기본적으로 사용 불가능한 관리 서버가 하나만 있을 때 쿼럼이 유지됩니다. 두 개의 관리 서버를 사용할 수 없는 경우 정확히 50%의 투표 멤버가 있고 리소스 풀이 더 이상 모니터링 워크로드를 관리하지 않습니다.
기본 관찰자는 다운되어도 고가용성을 유지할 수 있는 관리 서버의 수를 늘리지 않으므로 풀 가용성을 늘리지 않습니다.
이 시나리오에서는 기본 관찰자를 제거해볼 수 있습니다.

네 개의 관리 서버

기본 관찰자가 기본적으로 사용됩니다.
4개의 관리 서버와 기본 관찰자인 5명의 투표 멤버가 있기 때문에 풀에 대한 고가용성이 있습니다.
기본적으로 사용 불가능한 관리 서버가 두 개만 있을 때 쿼럼이 유지됩니다. 세 개의 관리 서버가 다운된 경우 투표 멤버의 50% 미만이고 리소스 풀이 더 이상 모니터링 워크로드를 관리하지 않습니다.
이 시나리오에서 기본 관찰자는 다운되어도 고가용성을 유지할 수 있는 관리 서버의 수를 늘리기 때문에 상당한 가치를 제공 합니다. 기본 관찰자가 없으면 쿼럼 구성원이 네 개 뿐이므로 한 개의 구성원만 사용 불가능할 때 고가용성이 유지됩니다.

다섯 개의 관리 서버관리 서버

기본 관찰자가 기본적으로 사용됩니다.
5개의 관리 서버와 기본 관찰자 - 6명의 투표 멤버가 있기 때문에 풀에 대한 고가용성이 있습니다.
기본적으로 사용 불가능한 관리 서버가 두 개만 있을 때 쿼럼이 유지됩니다. 세 개의 관리 서버를 사용할 수 없는 경우 정확히 투표 구성원의 50%만 남게 되고 리소스 풀은 더 이상 모니터링 워크로드를 관리하지 못합니다.
기본 관찰자는 다운되어도 고가용성을 유지할 수 있는 관리 서버의 수를 늘리지 않으므로 풀 가용성을 늘리지 않습니다.
이 시나리오에서는 기본 관찰자를 제거해볼 수 있습니다.

풀에 홀수의 멤버가 있는 리소스 풀에서 세 개 이상의 관리 서버에 도달하면 기본 관찰자 를 멤버로 제거하는 것이 좋습니다. 5개의 관리 서버에 도달하면 운영 데이터베이스에 상당한 부하가 발생할 가능성이 있으므로 리소스 풀 계산에 영향을 줄 수 있는 충분한 대기 시간을 생성할 수 있습니다.

기본 관찰자가 역할을 수행하는 방식을 통해 풀의 각 관리 서버는 자체 로컬 SDK 서비스를 쿼리합니다. 이를 통해 기본 관찰자에 대한 운영 데이터베이스의 테이블을 쿼리할 수 있습니다. SDK 서비스 또는 데이터베이스가 부하 상태에 있으면 원래 없던 대기 시간이 발생할 수 있습니다.

단일 게이트웨이 서버

기본 관찰자가 기본적으로 사용됩니다.
게이트웨이 서버가 단일 실패 지점이므로 고가용성이 없습니다.
게이트웨이 서버에 로컬 SDK 서비스가 없으므로 운영 데이터베이스를 쿼리할 수 없으므로 여기서 기본 관찰자 를 사용하면 안 됩니다.

두 개의 게이트웨이 서버

기본 관찰자가 기본적으로 사용됩니다.
게이트웨이 서버가 운영 데이터베이스와 직접 통신하지 않으므로 풀의 멤버가 두 개뿐이고 기본 관찰자 가 참가자가 아니므로 고가용성이 없습니다. 풀 쿼럼을 유지하려면 세 개의 게이트웨이 서버가 있어야 합니다.

세 개의 게이트웨이 서버

기본 관찰자가 기본적으로 사용됩니다.
3개의 투표 멤버(게이트웨이 서버 3개)가 있기 때문에 풀에 대한 고가용성이 있습니다.
기본적으로 하나의 게이트웨이 서버만 쿼럼을 유지 관리할 수 없습니다. 두 개의 게이트웨이 서버가 다운되면 투표 구성원의 50% 미만으로 남게 되고 리소스 풀은 더 이상 모니터링 워크로드를 관리하지 못합니다.
게이트웨이 서버에 로컬 SDK 서비스가 없으므로 운영 데이터베이스를 쿼리할 수 없으므로 여기서 기본 관찰자 를 사용하면 안 됩니다.

리소스 풀을 지원하는 모니터링 시나리오

다음 워크플로는 Operations Manager의 리소스 풀에서 호스트됩니다.

네트워크 디바이스 관리
UNIX/Linux 에이전트 관리
웹 애플리케이션 URL 모니터링

참고

Windows 에이전트는 리소스 풀에 보고하지 않습니다.

Operations Manager에서 네트워크를 모니터링하려면 별도의 전용 리소스 풀이 필요합니다. 네트워크 모니터링 워크플로는 에이전트가 아니라 관리 서버(SNMP 모듈)에서 실행되기 때문입니다. 이로 인해 특히 디바이스에서 사용 가능한 대부분의 활성 포트를 선택한 경우 네트워크 포트 모니터링을 포함하여 관리 서버에 과부하가 발생합니다. 성능 향상을 위해서는 네트워크 모니터링에 전용 리소스 풀의 전용 관리 서버를 사용하는 것이 좋습니다. 또한 이 풀의 구성원인 관리 서버를 모든 관리 서버, 알림 및 AD 할당 풀에서 제거해야 합니다.

필요한 경우 고가용성 모니터링 및 에이전트 관리를 지원하기 위해 Operations Manager의 Linux/UNIX 모니터링을 전용 리소스 풀에 할당할 수 있지만 필수 사항은 아닙니다. Operations Manager는 인증서를 사용하여 관리하는 컴퓨터에 대한 액세스를 인증합니다. 검색 마법사가 에이전트를 배포하면 에이전트에서 인증서를 검색하고, 인증서에 서명하고, 에이전트에 인증서를 다시 배포한 후 에이전트를 다시 시작합니다. 고가용성을 지원하려면 UNIX 및 Linux 컴퓨터의 에이전트에 배포된 인증서에 설명하는 데 사용하는 모든 루트 인증서가 리소스 풀의 각 관리 서버에 있어야 합니다. 그렇지 않으면 관리 서버를 사용할 수 없게 되면 다른 관리 서버는 실패한 서버에서 서명한 인증서를 신뢰할 수 없습니다.

다음 단계

리소스 풀을 만들고 관리하는 방법을 알아보려면 리소스 풀을 관리하는 방법을 참조하세요.