고가용성 및 재해 복구

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

고가용성

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

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

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

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

참고 항목

네트워크 부하 분산 장치는 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(장애 조치(failover) 클러스터 인스턴스)는 기본 데이터 센터에 배포되고, 보조 데이터 센터의 독립 실행형 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 데이터 액세스, System Center 구성 관리 및 Microsoft Monitoring Agent 서비스를 중지하고 수동 또는 비활성화로 설정하고 재해 복구 시나리오에서만 시작해야 합니다.

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

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

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

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