고가용성 및 재해 복구

중요

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

System Center – Operations Manager 서버 및 기능이 잠재적으로 실패하여 Operations Manager 기능에 영향을 미칠 수 있습니다. 오류가 발생하는 경우 손실되는 데이터 및 기능의 양은 각 오류 시나리오마다 다릅니다. 실패한 기능의 역할과 실패한 기능을 복구하는 데 걸리는 시간에 따라 달라집니다.

고가용성

고가용성 요구 사항은 Operations Manager 운영 및 데이터 웨어하우스 데이터베이스, 게이트웨이 및 관리 서버와 특정 워크로드에 대한 관리 그룹에 중복성을 구축하여 해결됩니다. 이러한 워크로드에는 네트워크 디바이스 모니터링, 플랫폼 간 모니터링 및 이전에 루트 관리 서버에서 관리한 관리 그룹별 워크로드가 포함됩니다.

여러 서버, 단일 관리 그룹 구성에서는 SQL Server Always On을 사용하여 Operations Manager 데이터베이스의 고가용성 및 서비스 연속성을 제공할 수 있습니다. 관리 서버 내결함성은 두 개 이상의 관리 서버를 설치하고 UNIX 서버, Linux 서버 및 네트워크 디바이스 모니터링에 리소스 풀을 사용하는 방식으로 제공됩니다. 기본 및 보조 관리 서버로 에이전트 기반 Windows 관리 서버를 구성하여 관리 서버가 실패한 경우 에이전트 통신을 리디렉션할 수 있습니다.

RMS 에뮬레이터도 이를 호스트하는 관리 서버를 사용할 수 없는 경우 다른 관리 서버로 이동할 수 있습니다.

운영 콘솔 연결은 데이터 액세스 서비스에 대한 고가용성을 구성하여 가용성을 높일 수 있습니다. 이 작업은 Microsoft NLB(네트워크 부하 분산)를 설치하거나 하드웨어 기반 부하 분산 장치 또는 DNS 별칭을 사용하여 수행할 수 있습니다. 하나 이상의 관리 서버가 NLB 풀의 구성원으로 추가되며, 두 콘솔 중 하나를 열 때 부하 분산된 관리 서버의 DNS에 등록된 가상 이름을 참조합니다.

참고

네트워크 Load Balancer Operations Manager 웹 콘솔 서버에 지원되지 않습니다.

트러스트 경계에 걸쳐 여러 게이트웨이 서버를 배포하여 트러스트 경계에 걸쳐 있는 에이전트에 대해 중복 경로를 제공할 수 있습니다. 에이전트가 주 관리 서버와 하나 이상의 보조 관리 서버 간의 장애 조치(fail over)할 수 있는 것처럼 게이트웨이 서버 간에도 장애 조치할 수 있습니다. 또한 여러 게이트웨이 서버를 사용하여 에이전트 없는 관리 컴퓨터 및 관리 네트워크 디바이스를 관리하는 작업을 배포할 수 있습니다.

게이트웨이 서버는 에이전트 게이트웨이 장애 초지를 통해 중복을 제공할 수 있을 뿐 아니라, 여러 관리 서버를 사용할 수 있는 경우 관리 그룹의 관리 서버 간에 장애 조치하도록 게이트웨이 서버를 구성할 수도 있습니다.

SQL Server Reporting Services 단일 보고서 서버 데이터베이스를 공유하는 여러 보고서 서버 인스턴스를 실행할 수 있는 스케일 아웃 배포 모델을 지원하지만 Operations Manager에서는 지원되지 않습니다. Operations Manager Reporting은 웹 팜에서 복제할 수 없는 프런트 엔드 구성 요소 설정의 일부로 사용자 지정 보안 확장을 설치합니다.

재해 복구

재해 복구는 치명적인 오류(예: 기본 인프라를 호스팅하는 전체 데이터 센터의 손실)가 발생한 경우 작업을 다시 시작할 수 있도록 하기 위해 취해지는 조치와 관련이 있습니다. 모든 배포에서 고려해야 하는 중요한 요소이며 재해 복구 계획에서 내린 결정은 Operations Manager가 중요한 IT 서비스의 성능 및 가용성에 대한 사전 모니터링 및 보고를 계속 지원할 수 있는 방법에 영향을 줍니다. 이 섹션에서는 재해 복구 및 복원력의 권장 전략과 원활한 복구를 위한 단계에 중점을 둡니다.

HA 및 DR 솔루션은 시스템 오류 또는 시스템 손실로부터 보호를 제공하지만 우발적, 의도하지 않은 데이터 손실 또는 악의적인 데이터 손실 또는 손상으로부터 보호하기 위해 의존해서는 안 됩니다. 이러한 경우 복사되거나 지연된 복제 복사본을 복원 작업에 사용해야 할 수 있습니다. 대부분의 경우 복원 작업은 DR의 가장 적합한 형식입니다. 한 가지 예로, 우선 순위가 낮은 보고 데이터베이스 또는 분석 데이터를 들 수 있습니다. 대부분의 경우 시스템 또는 애플리케이션 수준에서 멀티 사이트 DR을 사용하는 비용은 데이터의 가치보다 훨씬 큽니다. 장애 또는 사이트 DR이 과도한 경우 데이터의 단기적 가치가 낮고 데이터에 액세스해야 할 필요성이 중대한 비즈니스 영향 없이 지연될 경우 비용 절감 면에서 DR에 간단한 백업 및 복원 프로세스를 사용하는 것이 좋습니다.

가동 중지 시간의 영향 및 허용치를 이해하면 Operations Manager의 아키텍처와 재해 복구를 지원하는 데 필요한 복잡성 수준 및 비용을 적절히 설계하기 위한 사항을 결정하는 데 도움이 됩니다. 또한 IT 조직이 비즈니스 결과 없이 허용할 수 있는 데이터 손실 모니터링 범위를 고려하세요. 이는 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)의 두 가지 측면에서 가장 잘 설명됩니다.

Operations Manager에 대한 두 가지 가장 일반적인 재해 복구 설계 구성은 다음과 같습니다.

• 보조 데이터 센터에 배포된 중복 관리 그룹을 만들어 주 관리 그룹의 규모와 구성이 중복됩니다.
• 보조 데이터 센터에 운영 및 데이터 웨어하우스 데이터베이스를 지원하는 추가 서버를 배포하고, 복구 작업을 수행해야 할 때까지 관리 그룹에 참여하지 않는 콜드 대기 구성으로 관리 서버를 배포합니다.

중복 관리 그룹을 배포하는 것은 가동 중지 시간에 대한 허용 오차가 없는 경우 옵션입니다. 그러나 가장 복잡한 옵션입니다. 둘 사이의 구성은 일관성이 있어야 하므로 잘라내면 모니터링, 경고 또는 보고, 표시 및 마지막으로 에스컬레이션되는 항목에 차이가 없습니다. System Center - Service Manager, 해결 방법 또는 ServiceNow와 같은 다른 모니터링 플랫폼 또는 ITSM 플랫폼과의 통합도 존재해야 하며 인시던트, 구성 항목 등의 중복을 방지하기 위해 활성/수동 상태로 구성되어야 합니다. 에이전트는 관리 그룹 간에 멀티홈되므로 데이터가 중복됩니다.

다음 다이어그램은 이 설계 시나리오의 예입니다.

Operations Manager 배포에 즉각적인 복구가 필요하지 않고 중복 관리 그룹의 복잡성을 방지하려는 경우 관리 그룹의 기능을 유지하기 위해 보조 데이터 센터에 추가 관리 그룹 구성 요소를 배포할 수도 있습니다. 최소한 SQL Server 2014 또는 2016 Always On 가용성 그룹을 구현하여 둘 이상의 데이터 센터 간에 운영 및 데이터 웨어하우스 데이터베이스 복구를 제공하는 것이 좋습니다. 이 경우 2노드 FCI(장애 조치 클러스터 인스턴스)가 기본 데이터 센터에 배포되고 독립 실행형 SQL Server가 단일 WSFC(Windows Server 장애 조치 클러스터)의 일부로 보조 데이터 센터에 배포됩니다. Always On 가용성 그룹의 보조 복제본은 다음 다이어그램과 같이 비 FCI 독립 실행형 인스턴스에 있습니다.

이 예제에서는 하드웨어 구성 및 컴퓨터 이름이 동일한 하나 이상의 Windows Server를 배포하고, /Recover 매개 변수를 사용하여 관리 서버를 다시 설치해야 합니다. 다음은 샘플입니다.

Setup.exe /silent /AcceptEndUserLicenseAgreement:1 /recover /InstallPath:<Install Directory> /ManagementGroupName:MGNAME /SqlServerInstance:SQLServerName.domain.com /DatabaseName:OperationsManager /DWSqlServerInstance:SQLServerName.domain.com /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Always /SendCEIPReports:1 /UseMicrosoftUpdate:0

자세한 내용은 명령 프롬프트에서 Operations Manager 설치를 참조하세요.

이 시간 동안 에이전트는 관리 그룹의 관리 서버와의 통신을 다시 시작할 수 있을 때까지 수집된 데이터(경고, 이벤트, 성능 등)를 큐에 대기합니다. 이 방법을 사용하면 SQL Server의 새 인스턴스가 설치되지 않고 마지막으로 알려진 정상 백업에서 데이터베이스가 복원되지 않습니다. 그러나 이 복구 시나리오에서는 최소 모니터링 기능을 다시 시작하는 데 필요한 다른 역할을 배포해야 하므로 작동 가능한 상태로 돌아가는 데 더 긴 지연이 발생할 수 있습니다. 이 방법을 사용할 수 없는 경우 대기 복구를 위해 보조 데이터 센터에 관리 서버를 배포할 수 있습니다. 세 가지 기본 리소스 풀(모든 관리 서버 리소스 풀, 알림 및 AD 할당)의 멤버로 이를 제거합니다. 또한 기본 데이터 센터에서 호스트되는 관리 서버를 포함하고 복구 계획의 일부로 계속 작동해야 할 수 있는 사용자 지정 리소스 풀을 포함합니다. System Center Data Access, System Center Configuration Management 및 Microsoft Monitoring Agent 서비스를 중지하고 수동 또는 사용 안 함으로 설정하며 재해 복구 시나리오에서만 시작되도록 설정해야 합니다.

관리 서버가 통합을 지원하는 경우(관리 서버 또는 VMM, Orchestrator 또는 Service Manager 같은 다른 System Center 제품에서 직접 호스트되는 커넥터를 통해) 통합 구성 및 복구 단계의 순서에 따라 수동 또는 자동 복구 단계를 계획해야 합니다. 이렇게 하면 재해 복구 계획을 구현해야 하는 경우 관리 서버에 대한 다른 모든 종속성이 캡처되고 계획됩니다.

하나의 사이트가 오프라인 상태가 되면 에이전트는 다른 사이트의 관리 서버로 장애 조치됩니다(에이전트의 장애 조치 구성에서 이를 허용하는 경우). 보조 데이터 센터의 관리 서버로 장애 조치(failover)되어 복구 및 보고를 지연시키는 것을 방지하려면 기본 데이터 센터의 관리 서버만 캐시하도록 Windows 에이전트를 다시 구성합니다. 이 작업은 설치 중에 사전 구성하도록 스크립트(예: VBScript 또는 더 나은 PowerShell)를 사용하여 자동화된 방식으로 에이전트를 수동으로 배포하거나, 엔터프라이즈 구성 관리 솔루션으로 관리되는 스크립트 메서드를 사용하여 콘솔에서 에이전트를 푸시하는 경우 배포 후 수행할 수 있습니다.

관리 그룹의 연속성을 유지하기 위해 대체 재해 복구 옵션으로 Operations Manager를 Azure 가상 컴퓨터에 배포할 수 있습니다. 또한 관리 서버와 Operations Manager 데이터베이스를 호스트하는 SQL Server 간의 대기 시간이 관리 그룹의 성능에 부정적인 영향을 주기 때문에 하이브리드 구성이 아닌 Azure의 가상 머신에 SQL Server 배포해야 합니다.

Azure IaaS 또는 기타 퍼블릭 클라우드 공급자 내에서 이 시나리오를 적절하게 설계하기 위해 Microsoft Azure에 대한 모니터링 scope, 네트워크 토폴로지 및 네트워크 연결(즉, 사이트 간 VPN 또는 ExpressRoute), 통합 지점(즉, ITSM 솔루션, 기타 System Center 제품, 세 번째 부분 추가 기능 등), 콘솔 액세스, 규제 또는 관련 법률 또는 정책 등을 고려합니다.