관리 그룹 설계 계획

중요

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

개요

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

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

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

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

참고

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

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

Operations Manager와의 통합은 BMC Remedy, 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에서 Operations Manager를 배포한 경우(SQL Server 운영 데이터베이스 및 관리 서버 역할을 호스트하는 하나 이상의 가상 머신을 호스팅하고 신뢰할 수 없는 온-프레미스 워크로드를 모니터링합니다.

다음은 Azure IaaS 리소스를 모니터링하는 Operations Manager 배포의 예를 보여 줍니다.

다음은 Azure IaaS에서 호스트되는 Operations Manager 배포의 예입니다.

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

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

웹 콘솔 서버

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

보고 서버

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

참고

System Center – Operations Manager Reporting Services를 설치하면 SQL Reporting Services 인스턴스의 보안이 Operations Manager 역할 기반 보안과 통합됩니다. SQL Server 동일한 instance 다른 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
시스템 상태	Raw	180
시스템 상태	시간별	400
시스템 상태	매일	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에서는 프로덕션 애플리케이션을 모니터링하는 데 사용되는 프로덕션 구현과 프로덕션 환경과의 상호 작용을 최소화하는 사전 프로덕션 구현을 사용하는 것이 좋습니다. 사전 프로덕션 관리 그룹은 프로덕션 환경으로 마이그레이션되기 전에 관리 팩 기능을 테스트하고 조정하는 데 사용됩니다. 또한 일부 회사에서는 프로덕션에 배치하기 전 번인(burn-in) 기간 동안 새로 빌드된 서버를 배치할 스테이징 환경을 사용합니다. 사전 프로덕션 관리 그룹을 사용하여 프로덕션 출시 전에 서버 상태를 확인하기 위해 스테이징 환경을 모니터링할 수 있습니다.
• 전용 ACS 기능. 요구 사항에 Windows Audit Security 로그 이벤트 또는 UNIX/Linux 보안 이벤트를 수집해야 하는 필요성이 포함된 경우 ACS(Audit Collection Service)를 구현하게 됩니다. 회사의 보안 요구 사항에 따라 프로덕션 환경의 나머지 부분을 관리하는 관리 그룹 외 다른 관리 그룹에서 ACS 기능을 제어 및 관리해야 하는 경우 ACS 기능을 배타적으로 지원하는 관리 그룹을 구현하는 것이 좋을 수 있습니다.
• 재해 복구 기능. Operations Manager에서 Operations Manager 데이터베이스와의 모든 상호 작용은 데이터베이스에 커밋되기 전에 트랜잭션 로그에 기록됩니다. 이러한 트랜잭션 로그는 Microsoft SQL Server 실행하는 다른 서버로 전송하고 해당 서버의 Operations Manager 데이터베이스 복사본에 커밋할 수 있습니다. 이 기능은 동일한 관리 그룹에 있는 두 SQL 서버 간에 Operations Manager 운영 데이터베이스의 중복성을 제공하는 옵션입니다. 제어된 장애 조치를 수행해야 하는 경우 관리 그룹의 관리 서버에서 보조 SQL Server를 참조하고 통신하기 위해 레지스트리를 변경해야 합니다. 기본 관리 그룹(관리 팩, 재정의, 알림 구독, 보안 등)의 정확한 구성과 일치하는 장애 조치(failover) 관리 그룹을 배포할 수 있으며 에이전트는 두 관리 그룹에 모두 보고하도록 구성됩니다. 어떤 이유로든 기본 관리 그룹 전체를 사용할 수 없게 되면 모니터링 환경의 가동 중지 시간이 없습니다. 이 솔루션은 관리 그룹의 서비스 연속성 및 작업 모니터링의 무손실을 보장합니다.

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

연결된 관리 그룹

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

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

Operations Manager 관리 그룹을 연결하면 다음 작업을 수행하는 동안 중앙 모니터링 기능을 유지 관리할 수 있습니다.

• 단일 관리 그룹으로 여러 관리 개체 모니터
• 논리적 업무 단위(예: 마케팅) 또는 실제 위치(예: 로마)에 따른 모니터링 작업 구분

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

설치 언어

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