다음을 통해 공유

리소스 풀 디자인 고려 사항

  • 아티클

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

개요

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

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

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

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

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

  • 자동
  • 수동

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

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

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

참고 항목

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

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

리소스 풀 가용성 예제

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

단일 관리 서버

  • 기본 관찰자는 기본적으로 사용하도록 설정되며 멤버가 두 개만 있고 쿼럼에 도달하지 않으므로 아무런 이점을 제공하지 않습니다.
  • 관리 서버가 단일 실패 지점이므로 고가용성이 없습니다.

두 개의 관리 서버

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

세 개의 관리 서버

  • 기본 관찰자는 기본적으로 사용하도록 설정됩니다.
  • 3개의 관리 서버와 기본 관찰자 - 4명의 투표 멤버가 있기 때문에 풀에 대한 고가용성이 있습니다.
  • 기본적으로 쿼럼을 유지 관리할 수 없는 관리 서버는 하나만 사용할 수 있습니다. 두 개의 관리 서버를 사용할 수 없는 경우 투표 멤버의 50%가 더 이상 모니터링 워크로드를 관리하지 않습니다.
  • 기본 관찰자는 다운될 수 있는 관리 서버 수를 늘리지 않으므로 풀 가용성을 증가하지 않습니다.
  • 이 시나리오에서는 기본 관찰자를 제거하는 것이 좋습니다.

4개의 관리 서버

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

5개의 관리 서버

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

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

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

단일 게이트웨이 서버

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

게이트웨이 서버 2개

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

게이트웨이 서버 3개

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

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

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

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

참고 항목

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

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

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

다음 단계

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