다음을 통해 공유

관리 그룹 디자인 계획

  • 아티클

개요

관리 그룹은 단일 운영 데이터베이스, 하나 이상의 관리 서버 및 하나 이상의 모니터링되는 에이전트 및 디바이스로 식별됩니다. 관리 그룹을 연결하면 경고 및 기타 모니터링 데이터를 단일 콘솔에서 보고 편집할 수 있습니다. 로컬 관리 그룹에서 작업을 시작하여 연결된 관리 그룹의 관리되는 개체에서 실행할 수도 있습니다.

가장 간단한 Operations Manager 구현은 단일 관리 그룹입니다. 각 추가 그룹에는 최소한 자체 운영 데이터베이스 및 관리 서버가 필요합니다. 또한 각 그룹은 자체 구성 설정, 관리 팩 및 다른 모니터링 및 ITSM 솔루션과의 통합으로 별도로 유지 관리되어야 합니다.

MG 단일 서버 예제의 다이어그램

분산 관리 그룹 구현은 Operations Manager 배포의 99%를 기초로 합니다. 이를 통해 여러 서버에서 기능 및 서비스를 배포하여 이러한 기능 중 일부에 대한 확장성 및 중복성을 허용할 수 있습니다. 모든 Operations Manager 서버 역할을 포함할 수 있으며 게이트웨이 서버를 사용하여 트러스트 경계를 넘어 디바이스 모니터링을 지원합니다.

다음 그림에서는 분산 관리 그룹 토폴로지에 대해 가능한 옵션을 하나 표시합니다.

예제 OM 분산 MG의 다이어그램

참고 항목

운영 콘솔과 데이터베이스 간에는 직접 통신이 없습니다. 모든 통신은 포트 TCP 5724를 통해 특정 관리 서버로 이동한 다음, TCP 1433에서 OLE DB를 사용하는 데이터베이스 서버 또는 SQL Server 데이터베이스 엔진 인스턴스를 설치하는 동안 SQL 관리자가 지정한 사용자 정의 포트로 전달됩니다. 그러나 애플리케이션 진단 콘솔(웹 콘솔과 공동 배치됨)과 운영 및 데이터 웨어하우스 데이터베이스를 호스트하는 SQL Server 간에 직접 통신이 있습니다.

사용자 환경에 배포한 관리 그룹은 Microsoft OMS(Operations Management Suite)와 통합될 수 있으며 Log Analytics를 활용하여 성능, 이벤트 및 경고에 대한 상관 관계를 추가로 지정, 시각화 및 수행할 수 있습니다. 이렇게 하면 온-프레미스 또는 클라우드에서 호스트되는 시스템과 애플리케이션 간에 데이터를 상호 연결하기 위해 전체 데이터 세트에서 사용자 지정 검색을 수행할 수 있으므로 가시성이 향상됩니다.

Microsoft OMS와 OM 통합의 그림.

Operations Manager와의 통합은 BMC 구제, IBM, Netcool 또는 조직에서 사용하는 기타 엔터프라이즈 관리 솔루션과 같은 다른 제품으로 확장됩니다. 이러한 솔루션과의 상호 운용성 계획에 대한 자세한 내용은 다른 관리 솔루션과의 통합을 확인 하세요.

관리 그룹 구성 요소

관리 서버

Operations Manager 2007에서 RMS(루트 관리 서버)는 관리 그룹의 특수한 유형의 관리 서버였으며 관리 그룹에 설치된 첫 번째 관리 서버였습니다. RMS는 관리 그룹 구성 관리, 에이전트 관리 및 통신, 관리 그룹의 운영 데이터베이스 및 기타 데이터베이스와 통신하기 위한 초점이었습니다. RMS는 운영 콘솔의 대상과 웹 콘솔의 기본 대상으로도 사용되었습니다. System Center 2012 R2 – Operations Manager에서 루트 관리 서버 역할이 제거되었고 이제 모든 관리 서버가 피어입니다. 이 구성은 System Center 2016 이상 - Operations Manager에 계속 존재합니다.

모든 관리 서버가 이전에 RMS에서만 호스팅한 서비스를 호스트하기 때문에 RMS는 더 이상 단일 실패 지점이 아닙니다. 역할은 모든 관리 서버로 분산됩니다. 한 관리 서버를 사용할 수 없게 되면 담당 작업이 자동으로 다시 분산됩니다. RMS 에뮬레이터 역할은 RMS를 대상으로 하는 이전 버전의 관리 팩과의 호환성을 제공합니다. 이전에 RMS를 대상으로 한 관리 팩이 없는 경우 RMS 에뮬레이터를 사용할 필요가 없습니다.

관리 그룹은 여러 관리 서버를 포함하여 추가 용량 및 지속적인 가용성을 제공할 수 있습니다. 관리 그룹에 둘 이상의 관리 서버가 추가되면 관리 서버는 자동으로 세 가지 기본 리소스 풀의 일부가 되고 작업은 풀의 멤버에 분산됩니다. 사용자 지정 정의 리소스 풀의 경우 멤버가 수동으로 추가됩니다. 리소스 풀의 멤버가 실패하면 리소스 풀의 다른 멤버가 해당 멤버의 작업을 가져옵니다. 새 관리 서버가 추가되면 새 관리 서버는 리소스 풀의 기존 멤버에서 일부 작업을 자동으로 선택합니다. 리소스 풀 디자인 고려 사항을 검토하여 해당 기능 및 디자인 계획에 영향을 주는 권장 사항에 대해 자세히 알아봅니다.

어떤 이유로든 관리 서버를 사용할 수 없는 경우 기본적으로 관리 서버를 사용하는 에이전트는 자동으로 다른 관리 서버로 장애 조치(failover)됩니다. 관리 서버의 수와 배치를 선택할 때 고가용성이 요구 사항인 경우 이 장애 조치(failover) 기능을 고려해야 합니다.

에이전트는 관리 서버에 연결하여 다른 모든 Operations Manager 구성 요소와 통신합니다. 관리 서버에서 수행하는 작업 중 일부는 에이전트가 보낸 운영 데이터를 가져와서 운영 데이터베이스 및 데이터 웨어하우스에 삽입하는 프로세스입니다.

일반적인 관리 서버는 약 3,000개의 에이전트를 처리합니다. 실제 서버 성능은 수집된 운영 데이터의 양에 따라 달라집니다. 그러나 관리 서버는 일반적으로 상대적으로 많은 양의 운영 데이터를 사용하더라도 각각 3,000개의 에이전트를 지원할 수 있습니다.

관리 그룹당 최대 관리 서버 수에는 제한이 없습니다. 그러나 확장성, 고가용성 및 재해 복구 제약 조건을 해결한 후 가능한 한 적은 수의 관리 서버를 사용하는 것이 좋습니다.

관리 서버는 이러한 저장소에 대용량 데이터를 자주 전송하기 때문에 Operations Manager 데이터베이스 및 데이터 웨어하우스에 대한 네트워크 연결이 우수해야 합니다. 일반적으로 이러한 SQL Server 연결은 더 많은 대역폭을 사용하며 네트워크 대기 시간에 더 민감합니다. 따라서 모든 관리 서버는 운영 데이터베이스 및 데이터 웨어하우스 데이터베이스와 동일한 로컬 영역 네트워크에 있어야 하며 광역 네트워크를 통해 배포되지 않아야 합니다. 관리 서버와 Operations Manager 데이터베이스를 호스트하는 SQL Server 인스턴스 사이에는 10밀리초 미만의 대기 시간이 있어야 합니다.

게이트웨이 서버

Operations Manager는 에이전트와 관리 서버 간에 정보를 교환하기 전에 상호 인증을 수행해야 합니다. 둘 간의 인증 프로세스를 보호하기 위해 프로세스가 암호화됩니다. 에이전트와 관리 서버가 트러스트 관계를 설정한 Active Directory 도메인의 동일한 Active Directory에 있는 경우 Active Directory에서 제공하는 Kerberos V5 인증 메커니즘을 활용합니다. 에이전트 및 관리 서버가 동일한 신뢰 경계 내에 있지 않은 경우 보안 상호 인증 요구 사항을 충족하기 위해 다른 메커니즘을 사용해야 합니다.

게이트웨이 서버는 방화벽이 에이전트를 관리 서버에서 분리하거나 에이전트가 신뢰할 수 없는 별도의 도메인에 있을 때 사용됩니다. 게이트웨이 서버는 에이전트와 관리 서버 간의 프록시 역할을 합니다. 게이트웨이 서버가 없으면 에이전트는 관리 서버로 인증서 인증을 계속 수행할 수 있지만, MOMCertImport.exe 도구를 사용하여 각 에이전트에 X.509 인증서를 발급하고 설치해야 하며, 각각 방화벽을 통해 관리 서버에 액세스해야 합니다. 에이전트가 게이트웨이 서버와 동일한 도메인에 있거나 신뢰할 수 있는 도메인에 있는 경우 Kerberos 인증을 사용할 수 있습니다. 이 경우 게이트웨이 서버와 연결된 관리 서버만 인증서가 필요합니다. 여기에는 Operations Manager 관리 그룹을 지원하는 역할과 동일한 신뢰할 수 있는 영역에 조인되지 않은 Operations Manager(즉, 하이브리드 클라우드 모니터링)를 사용하여 Microsoft Azure IaaS(Infrastructure as a Service)에서 실행되는 가상 머신의 모니터링 또는 Azure IaaS(운영 데이터베이스를 호스팅하는 SQL Server가 있는 가상 머신 및 관리 서버 역할을 호스트하는 하나 이상의 가상 머신)에서 Operations Manager를 배포하고 신뢰할 수 없는 상태를 모니터링하는 작업이 포함됩니다. 온-프레미스 워크로드.

다음은 Azure IaaS 리소스를 모니터링하는 Operations Manager 배포 예제를 제공합니다.
Azure 리소스를 모니터링하는 OpsMgr의 그림.

다음은 Azure IaaS에서 호스트되는 Operations Manager 배포의 예입니다.
Azure Iaas에서 호스트되는 OpsMgr의 일러스트레이션.

일반적으로 게이트웨이 서버는 대역폭 사용률을 관리하는 데 사용되지 않습니다. 이는 에이전트에서 관리 서버로 전송되는 데이터의 전체 볼륨이 게이트웨이 서버 사용 여부와 유사하기 때문입니다. 게이트웨이 서버의 목적은 신뢰할 수 없는 도메인의 에이전트에 대한 인증서를 관리하는 데 필요한 노력을 줄이고 방화벽을 통해 허용해야 하는 통신 경로 수를 줄이는 것입니다.

  • 게이트웨이 서버당 2,000개 이상의 에이전트가 있으면 게이트웨이 서버가 관리 서버와 통신하지 못하게 하는 지속적인 중단 시 복구 기능에 부정적인 영향을 줄 수 있습니다. 2,000개 이상의 에이전트가 필요한 경우 여러 게이트웨이 서버를 사용하는 것이 좋습니다. 게이트웨이 서버 복구 시간이 중요한 경우 게이트웨이 서버와 관리 서버 간의 지속적인 중단 후 게이트웨이 서버가 큐를 신속하게 비울 수 있는지 확인하기 위해 시스템을 테스트하는 것이 대안입니다. 또한 게이트웨이 서버의 들어오는 큐가 채워지면 큐의 데이터가 우선 순위에 따라 삭제되므로 이 시나리오에서 지속적인 게이트웨이 서버 중단으로 인해 데이터가 손실될 수 있습니다.
  • 게이트웨이 서버를 통해 연결된 에이전트가 많은 경우 모든 게이트웨이 서버에 전용 관리 서버를 사용하는 것이 좋습니다. 모든 게이트웨이 서버가 연결된 다른 에이전트가 없는 단일 관리 서버에 연결하면 지속적인 중단이 발생할 경우 복구 시간을 단축할 수 있습니다. 관리 서버의 유효 로드는 직접 또는 게이트웨이 서버를 통해 보고하는 총 에이전트 수입니다.
  • 게이트웨이 서버가 고가용성을 위해 여러 관리 서버 간에 장애 조치(failover)하도록 구성된 경우를 포함하여 관리 서버와의 통신을 시작하지 못하도록 하기 위해 게이트웨이 승인 도구에는 /ManagementServerInitiatesConnection 명령줄 인수가 포함됩니다. 이렇게 하면 시스템이 DMZ 또는 다른 네트워크 환경에 배포되고 인트라넷에서만 통신을 시작할 수 있는 경우 Operations Manager가 고객의 보안 정책을 준수할 수 있습니다.

웹 콘솔 서버

웹 콘솔은 웹 브라우저를 통해 액세스할 수 있는 관리 그룹에 대한 인터페이스를 제공합니다. 운영 콘솔의 전체 기능이 없으며 모니터링 및 내 작업 영역 보기에만 액세스할 수 있습니다. 웹 콘솔은 운영 콘솔에서 모니터링되는 컴퓨터에 대해 실행할 수 있는 작업인 모든 모니터링 데이터 및 작업에 대한 액세스를 제공합니다. 웹 콘솔의 데이터에 대한 액세스에는 운영 콘솔의 콘텐츠에 대한 액세스와 동일한 제한 사항이 있습니다.

보고 서버

System Center에 대한 보고 – Operations Manager는 SQL Server Reporting Services(사용 중인 Operations Manager 버전에서 지원됨)에 설치되며 Operations Manager Reporting에서 지원하는 Reporting Services의 유일한 유효한 구성은 기본 모드입니다.

참고 항목

System Center 설치 – Operations Manager Reporting Services는 SQL Reporting Services 인스턴스의 보안을 Operations Manager 역할 기반 보안과 통합합니다. SQL Server의 동일한 인스턴스에 다른 Reporting Services 애플리케이션을 설치하지 마세요.

Operations Manager 보고서 서버 구성 요소는 SQL Server 2014 또는 2016 Reporting Services를 실행하는 동일한 서버 또는 다른 컴퓨터에 설치할 수 있습니다. 최적의 성능을 위해, 특히 대화형 또는 예약된 보고서가 동시에 처리되는 동안 사용자가 대량의 병렬 보고서를 생성하는 엔터프라이즈 환경에서는 더 많은 동시 사용자와 더 큰 보고서 실행 로드를 처리하도록 확장해야 합니다. Operations Manager Reporting Service는 데이터 웨어하우스 데이터베이스를 호스팅하는 동일한 SQL Server에 공동 배치되지 않고 전용 시스템에 설치하는 것이 좋습니다.

운영 데이터베이스

운영 데이터베이스는 관리 그룹에 대한 모든 운영 데이터, 구성 정보 및 모니터링 규칙을 보유하는 SQL Server 데이터베이스입니다. Operations Manager 데이터베이스는 관리 그룹에 대한 단일 오류 원본이므로 지원되는 클러스터링 구성을 사용하여 고가용성으로 만들 수 있습니다.

이 데이터베이스를 일관된 크기로 유지하기 위해 Operations Manager의 그루밍 설정은 데이터를 보존할 수 있는 시간을 지정합니다. 기본적으로 이 기간은 7일입니다.

보고 데이터 웨어하우스 데이터베이스

보고 데이터 웨어하우스는 장기 보고를 위해 운영 데이터를 수집하고 저장하는 SQL Server 데이터베이스입니다. 이 데이터는 데이터를 수집하여 보고하는 규칙과 운영 데이터베이스의 데이터 동기화 프로세스에서 직접 작성됩니다. 집계, 그루밍 및 최적화를 비롯한 데이터 웨어하우스의 유지 관리는 Operations Manager에서 자동으로 수행됩니다.

다음 표에서는 데이터 웨어하우스 데이터베이스를 처음 설치한 후의 기본 데이터 형식 및 보존 기간을 강조 표시합니다.

데이터 세트 집계 유형 보존 기간(일)
경고 Raw 400
클라이언트 모니터링 Raw 30
클라이언트 모니터링 일간 400
이벤트 Raw 100
성능 Raw 10
성능 매시간 400
성능 일간 400
State(상태) Raw 180
State(상태) 매시간 400
State(상태) 일간 400

데이터 웨어하우스는 여러 관리 그룹을 제공할 수 있습니다. 이렇게 하면 단일 보고서가 조직 전체의 모든 컴퓨터에서 데이터를 통합할 수 있습니다.

Operations Manager 데이터베이스와 마찬가지로 데이터 웨어하우스 데이터베이스는 고가용성을 위해 클러스터될 수 있습니다. 클러스터되지 않은 경우 문제를 신속하게 해결할 수 있도록 신중하게 모니터링해야 합니다.

ACS 수집기

ACS 수집기는 ACS 전달자로부터 이벤트를 받아서 처리한 다음 이 데이터를 ACS 데이터베이스로 보냅니다. 이 처리에는 ACS 데이터베이스 내의 여러 테이블에 분산될 수 있도록 데이터를 디스어셈블하고, 데이터 중복을 최소화하고, 불필요한 이벤트가 ACS 데이터베이스에 추가되지 않도록 필터를 적용하는 것이 포함됩니다.

ACS 데이터베이스

ACS 데이터베이스는 ACS 배포 내에서 감사 정책에 따라 생성되는 이벤트의 중앙 리포리토지입니다. ACS 데이터베이스는 ACS 수집기와 같은 컴퓨터에 있을 수 있지만 최상의 성능을 위해서는 각각 전용 서버에 설치해야 합니다. 기본적으로 데이터는 14일 동안 보존됩니다.

ACS 전달자

ACS 전달자에서 실행되는 서비스는 Operations Manager 에이전트에 포함되어 있습니다. 따라서 이 서비스는 기본적으로 Operations Manager 에이전트를 설치할 때 함께 설치되지만 사용하도록 설정되지는 않습니다. 감사 컬렉션 사용 태스크 또는 PowerShell을 사용하여 한 번에 여러 에이전트 컴퓨터에 이 서비스를 사용하도록 설정할 수 있습니다. 이 서비스를 사용하도록 설정하고 나면 로컬 보안 로그 외에 ACS 수집기에도 모든 보안 이벤트가 전송됩니다.

디자인 고려 사항

단일 또는 여러 관리 그룹을 구현하기로 결정할 때 다음 요소를 고려해야 합니다.

  • 용량이 증가했습니다. Operations Manager에는 단일 관리 그룹이 지원할 수 있는 에이전트 수에 대한 기본 제공 제한이 없습니다. 사용하는 하드웨어와 관리 그룹에 대한 모니터링 부하(배포된 관리 팩이 많을수록 모니터링 부하가 높아집니다)에 따라 허용 가능한 성능을 유지하려면 여러 관리 그룹이 필요할 수 있습니다.
  • 통합 뷰. 환경을 모니터링하는 데 여러 관리 그룹을 사용하는 경우 모니터링 및 경고 데이터에 대한 통합 보기를 제공하는 메커니즘이 필요합니다. 이 작업은 다른 모든 관리 그룹의 모든 데이터에 액세스할 수 있는 추가 관리 그룹(모니터링 책임이 있을 수도 있고 없을 수도 있는)을 배포하여 수행할 수 있습니다. 그런 다음 이러한 관리 그룹을 연결했다고 합니다. 데이터의 통합 보기를 제공하는 데 사용되는 관리 그룹을 로컬 관리 그룹이라고 하며, 데이터를 제공하는 다른 그룹을 연결된 관리 그룹이라고 합니다.
  • 보안 및 관리. 보안 및 관리상의 이유로 관리 그룹을 분할하는 것은 Active Directory 조직 구성 단위 또는 도메인을 통해 관리 권한을 다른 관리 그룹으로 위임하는 개념과 비슷합니다. 회사에는 각각 고유한 책임 영역이 있는 여러 IT 그룹이 포함될 수 있습니다. 이 영역은 특정 지리적 영역 또는 비즈니스 부서일 수 있습니다. 예를 들어 지주 회사의 경우 자회사 중 하나일 수 있습니다. 중앙 집중식 IT 그룹에서 이러한 유형의 전체 관리 권한 위임이 있는 경우 각 영역에서 관리 그룹 구조를 구현하는 것이 유용할 수 있습니다. 그런 다음 중앙 집중식 IT 데이터 센터에 있는 로컬 관리 그룹에 연결된 관리 그룹으로 구성할 수 있습니다.
  • 설치된 언어입니다. Operations Manager 서버 역할이 설치된 모든 서버는 동일한 언어로 설치해야 합니다. 즉, 영어 버전의 Operations Manager 2012 R2를 사용하여 관리 서버를 설치한 다음 일본어 버전을 사용하여 운영 콘솔을 배포할 수 없습니다. 모니터링이 여러 언어에 걸쳐 있어야 하는 경우 운영자의 각 언어에 대해 추가 관리 그룹이 필요합니다.
  • 프로덕션 및 사전 프로덕션 기능. Operations Manager에서는 프로덕션 애플리케이션을 모니터링하는 데 사용되는 프로덕션 구현과 프로덕션 환경과의 상호 작용을 최소화하는 사전 프로덕션 구현을 사용하는 것이 좋습니다. 사전 프로덕션 관리 그룹은 프로덕션 환경으로 마이그레이션되기 전에 관리 팩 기능을 테스트하고 조정하는 데 사용됩니다. 또한 일부 회사는 새로 빌드된 서버가 프로덕션에 배치되기 전에 번인 기간 동안 배치되는 서버에 스테이징 환경을 사용합니다. 사전 프로덕션 관리 그룹을 사용하여 프로덕션 출시 전에 서버의 상태를 확인하기 위해 스테이징 환경을 모니터링할 수 있습니다.
  • 전용 ACS 기능. 요구 사항에 Windows Audit Security 로그 이벤트 또는 UNIX/Linux 보안 이벤트를 수집해야 하는 경우 ACS(Audit Collection Service)를 구현하게 됩니다. 회사의 보안 요구 사항에 따라 나머지 프로덕션 환경을 관리하는 관리 그룹이 아닌 관리 그룹에서 ACS 함수를 제어하고 관리하도록 요구하는 경우 ACS 기능을 독점적으로 지원하는 관리 그룹을 구현하는 것이 도움이 될 수 있습니다.
  • 재해 복구 기능. Operations Manager에서 Operations Manager 데이터베이스와의 모든 상호 작용은 데이터베이스에 커밋되기 전에 트랜잭션 로그에 기록됩니다. 이러한 트랜잭션 로그는 Microsoft SQL Server를 실행하는 다른 서버로 전송되고 해당 서버의 Operations Manager 데이터베이스 복사본에 커밋할 수 있습니다. 이 기능은 동일한 관리 그룹의 두 SQL Server 간에 Operations Manager 운영 데이터베이스의 중복성을 제공하는 옵션입니다. 제어된 장애 조치(failover)를 수행해야 하는 경우 관리 그룹의 관리 서버는 보조 SQL Server를 참조하고 통신하기 위해 레지스트리를 변경해야 합니다. 기본 관리 그룹(관리 팩, 재정의, 알림 구독, 보안 등)의 정확한 구성과 일치하는 장애 조치(failover) 관리 그룹을 배포할 수 있으며 에이전트는 두 관리 그룹에 모두 보고하도록 구성됩니다. 어떤 이유로든 주 관리 그룹 전체를 사용할 수 없게 되면 모니터링 환경의 가동 중지 시간이 없습니다. 이 솔루션은 관리 그룹의 서비스 연속성과 운영 모니터링 손실이 없도록 합니다.

프로덕션 환경에서 System Center Operations Manager를 배포하기 전에 관리 그룹의 디자인을 계획합니다. 계획 단계에서 IT 서비스 구성 요소(즉, 인프라 및 애플리케이션 수준)와 이를 지원하는 시스템 및 디바이스 수, 인시던트 및 문제 관리 프로세스를 통합 및 지원하는 방법, 다양한 인시던트 에스컬레이션 지원 계층, 엔지니어링, 서비스 소비자 및 관리에 대한 데이터를 시각화하는 방법을 이해합니다.

연결된 관리 그룹

여러 지리적 위치에 서버가 있는 많은 기업에서는 해당 서버에 대한 중앙 모니터링이 필요합니다. 아래 이미지에 설명된 연결된 관리 그룹 구성은 계층적 시스템 관리 인프라를 만들도록 설계된 워크플로 프로세스 집합입니다.

연결된 관리 그룹 예제의 다이어그램

이 구성을 사용하여 중앙 집중식 모니터링을 수행할 수 있습니다. 경고 및 모니터링 데이터 보기를 지원하고 연결된 관리 그룹의 관리되는 개체에 대해 작업을 시작하도록 설계되었습니다.

Operations Manager 관리 그룹을 연결하면 중앙 집중식 모니터링 기능을 유지하면서 동시에 다음을 사용하도록 설정할 수 있습니다.

  • 단일 관리 그룹에서 가능한 것보다 많은 수의 관리 개체를 모니터링합니다.
  • "마케팅"과 같은 논리적 사업부 또는 로마와 같은 물리적 위치에 따라 모니터링 활동을 격리합니다.

관리 그룹을 연결할 경우 새로운 서버를 배포하는 것이 아니며, 로컬 관리 그룹에서 연결된 관리 그룹에 있는 경고 및 검색 정보에 액세스하도록 허용하는 것입니다. 이러한 방식으로 단일 운영 콘솔에서 여러 관리 그룹으로부터 얻은 모든 경고 및 기타 모니터링 데이터를 보고 사용할 수 있습니다. 또한 연결된 관리 그룹의 모니터링 대상 컴퓨터에서 작업을 실행할 수 있습니다. 관리 그룹을 연결하는 방법을 알아보려면 Operations Manager에서 관리 그룹 연결을 참조하세요.

설치된 언어

Operations Manager 관리 그룹은 설치된 언어를 하나만 지원합니다. 모니터링해야 하는 전반적인 IT 환경에 설치 언어가 두 가지 이상인 경우 언어당 별도의 관리 그룹이 필요합니다.