데이터 센터에서 얻은 교훈: Managed Availability

최초 문서 게시일: 2012년 9월 22일 토요일

모니터링은 모든 Exchange 배포를 성공으로 이끌기 위한 핵심 구성 요소입니다. 이전 릴리스에서는 Exchange 환경에 대한 포괄적인 경고 솔루션을 제공하기 위해 상관 관계 엔진을 개발하는 데 집중 투자했으며 System Center Operations Manager(SCOM) 제품 그룹과 긴밀하게 협력했습니다.

기존의 모니터링은 데이터를 수집하고 필요한 경우 수집된 데이터에 기반하여 작업을 수행하는 것으로 이루어졌습니다. 예를 들어 SCOM에서는 다음과 같은 다양한 메커니즘을 사용하여 Exchange Management Pack을 통해 데이터가 수집되었습니다.

Exchange Server 2013의 모니터링 목표

Exchange 2013의 개발을 시작할 때 중점을 둔 영역 중 하나는 매우 작은 규모의 온-프레미스 배포에서 세계 최대 배포인 Office 365에 이르는 모든 Exchange 배포에 대한 종단 간 모니터링을 향상시키는 것이었으며, 다음과 같은 세 가지 목표를 염두에 두었습니다.

1. Office 365 서비스에서 얻은 지식과 경험을 온-프레미스 고객에게 제공  Exchange 제품 그룹은 6년 가까이 Exchange Online을 운영해 왔으며, DevOps(개발자 운영 모델)라는 운영 모델을 사용합니다. 이 모델에서는 서비스 내에서 특정 기능이 제대로 작동하지 않거나 고객이 알려지지 않은 문제를 보고하고 그 문제가 에스컬레이션되는 경우, 해당 기능의 개발자에게 직접 문제가 에스컬레이션됩니다. 문제가 어디에서 발생했든지 개발자에게 직접 에스컬레이션하면 소프트웨어의 결함이 지적되어 더욱 책임 있는 소프트웨어 개발이 이루어집니다.

   이 모델을 사용하면서 많은 것을 알게 되었습니다. 일례로 Exchange 2010 Management Pack에는 1100개에 달하는 경고가 있는데 이러한 경고 중 약 150개만 Office 365에서 유용하다는 것을 몇 년에 걸쳐 알게 되었으며 이에 따라 나머지는 이제 사용하지 않도록 설정했습니다. 또한 개발자가 에스컬레이션을 받으면 더욱 책임감을 갖고 코드 수정, 새로운 복구 워크플로 작성, 경고 미세 조정 등을 통해 문제를 해결하기 위해 노력한다는 것도 알게 되었습니다. 같은 문제를 해결하도록 계속해서 요청을 받고 다른 업무에 방해를 받는 것을 원치 않기 때문이겠죠. DevOps 모델 내에는 매주 당직자들이 지난 주에 발생한 문제를 검토하는 이관 모임을 갖습니다. 이러한 모임을 통해 IIS 응용 프로그램 풀 재설정 등과 같은 사내 복구 워크플로가 개발됩니다. Exchange 2013 이전에는 자체 사내 엔진을 사용하여 이러한 복구 워크플로를 처리했지만 이 지식을 온-프레미스 제품에 구현하지 않았습니다. Exchange 2013에서는 복구 워크플로 엔진을 구성 요소에 포함하여 그 동안 얻은 지식과 경험을 온-프레미스 고객과 공유할 수 있도록 했습니다.

2. 최종 사용자의 경험에 기반한 모니터링  또한 모니터링에 사용한 많은 방법이 실제로 환경 운영에 도움이 되지 않는다는 사실을 알게 되었습니다. 이에 따라 모니터링에 대한 접근 방식을 고객 중심적인 비전으로 전환하고 있습니다.

   이전 릴리스에서 각 구성 요소 팀은 시스템 내의 다양한 구성 요소를 모두 명확히 나타내는 방식으로 상태 모델을 개발했습니다. 예를 들어 전송은 SMTP-IN, SMTP-OUT, 전송 에이전트, 분류기, 라우팅 엔진, 저장소 드라이버 등으로 구성됩니다. 구성 요소 팀은 이러한 각 구성 요소에 대한 경고를 작성했습니다. 그에 따라 Management Pack에는 저장소 드라이버에 오류가 발생했음을 알리는 경고가 있습니다. 하지만 이 경고는 종단 간 사용자 경험이나 사용자 경험에서 끊긴 부분에 대해 알려주지 않습니다. 따라서Exchange 2013에서는 이 모델을 뒤집어 놓으려고 합니다. 시스템 수준 모니터링을 없애는 것은 아닙니다. 이것도 중요합니다. 그러나 서비스를 관리하려는 경우 정말 중요한 것은 사용자의 경험이므로 모델을 뒤집어서 사용자 경험을 모니터링하는 데 중점을 두려고 합니다.

3. 복구 중심적 컴퓨팅을 통해 사용자 경험 보호  이전 Exchange 릴리스에서는 모니터링이 최종 사용자 경험을 자동으로 복구 및 복원하는 방법이 아닌 시스템과 구성 요소에 중점을 두었습니다.

Exchange Server 2013 모니터링 - Managed Availability

Managed Availability는 Exchange의 고가용성 솔루션과 통합되는 모니터링 및 복구 인프라입니다. Managed Availability는 문제가 발생할 때와 발견될 때 문제를 감지하고 복구합니다.

Managed Availability는 사용자 중심적입니다. 이것은 세 가지 주요 측면, 즉 가용성, 경험(대부분의 클라이언트 프로토콜에서 대기 시간으로 측정됨) 및 오류 발생 여부를 측정합니다. 이러한 세 가지 측면을 이해할 수 있도록 Outlook Web App(OWA)을 사용하는 사용자를 예로 들어 보겠습니다.

가용성 측면은 단지 사용자가 OWA 양식 기반 인증 웹 페이지에 액세스할 수 있는지 여부입니다. 액세스할 수 없는 경우 경험이 끊기고 지원 센터 에스컬레이션으로 이어집니다. 경험 측면은 OWA에 로그인할 수 있는 경우 경험이 어떤지, 즉 인터페이스가 로드되며 메일에 액세스할 수 있는지를 측정합니다. 마지막 측면인 대기 시간은 사용자가 인터페이스에 로그인하여 액세스할 수 있는 경우 브라우저에 메일이 얼마나 빨리 렌더링되는지를 측정합니다. 이러한 영역이 최종 사용자 경험을 구성합니다.

이전 릴리스와 Exchange 2013 간의 주요 차이점은 Exchange 2013에서는 모니터링 솔루션이 근본 원인을 알리려고 하지 않는다는 점입니다. 이는 로그에 근본 원인 데이터가 기록되지 않거나 덤프가 생성되지 않거나 근본 원인을 발견할 수 없다는 것이 아닙니다. 이전 릴리스에서는 근본 원인을 알리는 데 전혀 효과적이지 못했습니다. 알린 내용이 맞을 때도 있었지만 틀릴 때도 많았습니다.

Managed Availability의 구성 요소

Managed Availability는 Exchange 2013의 두 가지 서버 역할에 기본 제공되며, 세 가지 주요 비동기 구성 요소를 포함하고 있습니다. 첫 번째 구성 요소는 프로브 엔진입니다. 프로브 엔진의 기능은 서버에 대한 측정을 수행하는 것입니다. 이 측정 결과는 두 번째 구성 요소인 모니터에 넘겨집니다. 모니터에는 정상으로 간주되는 상태를 인코딩하는 비즈니스 논리가 포함되어 있으며, 이는 패턴 인식 엔진으로 생각할 수 있습니다. 즉, 서로 다른 측정 결과 내에서 여러 가지 패턴을 찾아 해당 항목을 정상으로 간주할지 여부를 결정할 수 있습니다. 마지막으로, 아래 다이어그램에 복구라는 레이블로 표시된 응답기 엔진이 있습니다. 무언가가 정상이 아닐 때 이 엔진은 첫째로 응용 프로그램 풀을 다시 시작하고, 둘째로 서비스를 다시 시작하고, 셋째로 서버를 다시 시작하고, 마지막으로 더 이상 트래픽을 받지 않도록 서버를 오프라인 상태로 설정합니다. 이러한 시도가 실패하면 Managed Availability는 이벤트 로그 알림을 통해 사람에게 문제를 에스컬레이션합니다.

또한 몇 가지를 분산시켰습니다. 이전에는 각 서버에 SCOM 에이전트를 두어 모든 측정 결과를 중앙 SCOM 서버로 보냈습니다. SCOM 서버는 모든 측정 결과를 평가하여 항목이 정상인지 여부를 결정합니다. 대규모 환경에서는 복잡한 상관 관계가 과다하게 실행되므로 경고 생성 등에 시간이 오래 걸립니다. 모든 것을 중앙의 한 곳으로 집중시키니 확장이 어려웠습니다. 이에 따라 각 서버가 독립적으로 자체 프로브를 실행하고 스스로를 모니터링하며 자체 복구 작업을 수행하고 필요한 경우 에스컬레이션하도록 변경했습니다.

그림 1: Managed Availability의 구성 요소

프로브

프로브 인프라는 다음과 같은 세 가지 고유한 프레임워크로 구성됩니다.

1. 프로브(Probe)는 각 구성 요소 팀이 만드는 가상 트랜잭션입니다. 이것은 이전 릴리스의 테스트 cmdlet과유사합니다. 프로브는 가상 종단 간 사용자 트랜잭션을 실행하여 서비스에 대한 인식을 측정합니다.
2. 확인(Check)은 수동적인 모니터링 메커니즘으로, 실제 고객 트래픽을 측정합니다.
3. 알림(Notify) 프레임워크는 프로브가 실행되기를 기다리지 않고 즉각적인 조치를 취할 수 있도록 합니다. 이를 통해, 오류가 감지될 경우 즉각적으로 조치를 취할 수 있습니다. 알림 프레임워크는 알림을 기반으로 합니다. 예를 들어 인증서가 만료되면 알림 이벤트가 트리거되어 인증서를 갱신해야 한다는 것을 알립니다.

모니터

프로브에서 수집된 데이터는 모니터에 넘겨집니다. 프로브와 모니터 간에 일대일 상관 관계가 있어야 하는 것은 아닙니다. 많은 프로브에서 단일 모니터로 데이터를 넘길 수 있습니다. 모니터는 프로브의 결과를 검토하여 결론을 도출합니다. 결론은 정상과 비정상, 둘 중의 하나입니다.

앞에서 언급했듯이 Exchange 2013 모니터링은 최종 사용자 경험에 중점을 둡니다. 이를 위해 환경 내 여러 계층을 모니터링해야 합니다.

그림 2: 사용자 환경을 검사하기 위한 여러 계층 모니터링

위의 다이어그램에서 볼 수 있듯이 네 가지 검사가 이루어집니다. 첫 번째 검사는 사서함 자체 테스트입니다. 이 프로브는 로컬 프로토콜 또는 인터페이스가 데이터베이스에 액세스할 수 있는지를 확인합니다. 두 번째 검사는 프로토콜 자체 테스트로서 사서함 서버의 로컬 프로토콜이 작동하는지 확인합니다. 세 번째 검사는 프록시 자체 테스트로서 클라이언트 액세스 서버에 대해 실행되어 프로토콜에 대한 프록시 기능이 작동하는지 확인합니다. 네 번째이자 마지막 검사는 프로토콜 프록시부터 저장소 기능까지 종단 간 환경을 확인하는 포괄적인 검사입니다. 각 검사는 서로 다른 간격으로 감지를 수행합니다.

의존 관계를 확인하기 위해 여러 계층이 모니터링됩니다. Exchange 2013에는 상관 관계 엔진이 없기 때문에 여러 가지 프로브에 해당하는 고유한 오류 코드와 해당 의존 관계를 포함하지 않는 프로브를 사용하여 의존 관계를 구별합니다. 예를 들어 사서함 자체 테스트와 프로토콜 자체 테스트 프로브가 동시에 실패할 경우 이것은 무엇을 의미합니까? 저장소가 다운되었다는 의미입니까? 그런 것은 아닙니다. 이는 사서함 서버의 로컬 프로토콜 인스턴스가 작동하지 않음을 의미합니다. 한편, 프로토콜 자체 테스트가 작동하지만 사서함 자체 테스트가 실패한 경우 이것은 무엇을 의미합니까? 이 시나리오는 "저장소" 계층에 문제가 있어 실제로 저장소 또는 데이터베이스가 오프라인 상태일 수 있음을 뜻합니다.

이에 따라 이제 모니터링 측면에서 생성되는 경고를 더욱 미세하게 제어할 수 있습니다. 예를 들어 OWA의 상태를 평가하는 경우 사서함 자체 테스트가 실패했지만 프로토콜 자체 테스트가 작동하는 시나리오에서는 경고 생성을 미룰 수 있습니다. 그러나 사서함 자체 테스트와 프로토콜 자체 테스트 모니터가 모두 비정상인 경우 경고를 생성할 수 있습니다.

응답기

응답기는 모니터에서 생성되는 경고에 따라 응답을 실행합니다. 모니터가 정상인 경우 응답기가 절대 실행되지 않습니다.

여러 가지 유형의 응답기를 사용할 수 있습니다.

• 재시작 응답기  서비스를 종료하고 다시 시작
• 응용 프로그램 풀 재설정 응답기  IIS 응용 프로그램 풀 재설정
• 장애 조치(failover) 응답기  Exchange 2013 사서함 서버를 사용할 수 없게 만듦
• 버그 검사 응답기  서버의 버그 검사 시작
• 오프라인 응답기  컴퓨터의 프로토콜을 사용할 수 없게 만듦
• 에스컬레이션 응답기  문제를 에스컬레이션
• 전문 구성 요소 응답기 

오프라인 응답기는 클라이언트 액세스 서버에서 프로토콜이 사용되지 않도록 하는 데 사용됩니다. 이 응답기는 부하 분산 장치에 구애 받지 않도록 설계되었습니다. 이 응답기가 호출되면 프로토콜이 부하 분산 장치 상태 검사를 확인하지 않으므로 부하 분산 장치가 부하 분산 풀에서 해당 서버 또는 프로토콜을 제거할 수 있습니다. 마찬가지로 모니터가 다시 정상이 되면 비정상 상태의 연결된 모니터가 없다고 가정하고 해당 온라인 응답기가 자동으로 시작됩니다. 온라인 응답기는 단지 프로토콜이 부하 분산 장치 상태 검사에 응답할 수 있도록 하며, 이를 통해 부하 분산 장치가 해당 서버 또는 프로토콜을 다시 부하 분산 장치에 추가할 수 있습니다. 또한 오프라인 응답기는 Set-ServerComponentState cmdlet을 통해 수동으로 호출할 수 있으므로 관리자가 클라이언트 액세스 서버를 유지 관리 모드로 수동 설정할 수 있습니다.

에스컬레이션 응답기가 호출되면 Exchange 2013 Management Pack에서 인식하는 Windows 이벤트가 생성됩니다. 이는 일반적인 Exchange 이벤트가 아닙니다. 즉, OWA가 중단되었거나 하드 입출력이 발생한 이벤트가 아니라, 특정 상태 집합이 정상이거나 비정상인 Exchange 이벤트입니다. 이러한 단일 인스턴스 이벤트를 사용하여 SCOM 내에서 모니터를 조작합니다. 이는 제품 전반에 걸쳐 있는 이벤트가 아닌 에스컬레이션 응답기에서 생성된 이벤트를 기반으로 합니다. 다른 방식으로 생각하면 일정 수준의 간접 조작입니다. Managed Availability는 SCOM 내에서 모니터를 전환하는 경우를 결정합니다. Managed Availability는 에스컬레이션이 이루어져야 하는 경우, 다시 말해서 사람이 개입해야 하는 경우를 결정합니다.

또한 전체 서비스가 위험에 처하지 않도록 응답기가 스로틀될 수도 있습니다. 스로틀은 응답기에 따라 달라집니다.

• 일부 응답기는 DAG 또는 부하 분산되는 CAS 풀 내에서 최소 서버 수를 고려합니다.
• 일부 응답기는 실행 사이의 시간 간격을 고려합니다.
• 일부 응답기는 응답기가 시작된 횟수를 고려합니다.
• 일부 응답기는 위의 모든 조합을 사용할 수 있습니다.

응답기에 따라 스로틀이 발생할 때 응답기의 작업이 지연되거나 단순히 생략될 수 있습니다.

복구 시퀀스

모니터는 실행되는 응답기 유형과 실행되는 일정을 정의합니다. 이를 모니터의 복구 시퀀스라고 합니다. 예를 들어 OWA 프로토콜의 프로브 데이터, 즉 프로토콜 자체 테스트에서 모니터를 비정상 상태로 트리거할 경우 이 시점에 현재 시간이 저장됩니다. 이를 T라고 하겠습니다. 모니터는 현재 시간을 기반으로 복구 파이프라인을 시작합니다. 모니터는 복구 파이프라인 내에서 지정된 시간 간격으로 복구 작업을 정의할 수 있습니다. 사서함 서버에 대한 OWA 프로토콜 모니터의 경우 복구 시퀀스는 다음과 같습니다.

1. T=0일 때 IIS 응용 프로그램 풀 재설정 응답기가 실행됩니다.
2. T=5분일 때 모니터가 정상 상태로 복원되지 않은 경우 장애 조치 응답기가 시작되고 데이터베이스가 서버 외부로 이동합니다.
3. T=8분일 때 모니터가 정상 상태로 복원되지 않은 경우 버그 검사 응답기가 시작되고 서버가 강제로 재부팅됩니다.
4. T=15분일 때 모니터가 아직 정상 상태로 복원되지 않은 경우 에스컬레이션 응답기가 트리거됩니다.

모니터가 정상 상태가 되면 복구 시퀀스 파이프라인이 중지됩니다. 다음 지정된 시간의 작업이 시작되기 전에 마지막 지정된 시간의 작업이 완료되지 않아도 됩니다.  또한 모니터는 개수에 제한 없이 지정된 시간 간격을 가질 수 있습니다.

Systems Center Operations Manager(SCOM)

Systems Center Operations Manager(SCOM)는 Exchange 환경과 관련된 상태 정보를 확인하기 위한 포털로 사용됩니다. 에스컬레이션 응답기를 통해 응용 프로그램 로그에 기록된 이벤트에 의해 SCOM 포털 내에서 비정상 상태가 트리거됩니다. SCOM 대시보드는 더욱 개선되었으며 이제 세 가지 주요 영역을 갖습니다.

• 활성 경고
• 조직 상태
• 서버 상태

Exchange Server 2013 SCOM Management Pack은 SCOM 2007 R2와 SCOM 2012에서 지원됩니다.

재정의

어떤 환경이든지 기본값이 최적 상태가 아닌 경우가 있을 수 있으며 상황에 따라 긴급 작업이 필요할 수 있습니다. Managed Availability에는 전체 환경 또는 개별 서버에 대해 재정의를 사용할 수 있는 기능이 포함되어 있습니다. 지정된 기간 동안 또는 특정 서버 버전에 적용할 각 재정의를 설정할 수 있습니다. *-ServerMonitoringOverride 및 *-GlobalMonitoringOverride cmdlet을 사용하면 관리자가 재정의를 설정 또는 제거하거나 확인할 수 있습니다.

상태 결정

유사하거나 특정 구성 요소 아키텍처에 연결된 모니터는 함께 그룹화되어 상태 집합을 형성합니다. 상태 집합의 상태는 항상 상태 집합 내에 있는 여러 모니터에 대한 "최악" 평가로 결정됩니다. 예를 들어 상태 집합 내에 모니터가 9개 있고 모니터 1개가 비정상 상태일 경우 상태 집합이 비정상으로 간주됩니다. Get-MonitoringItemIdentity cmdlet을 사용하여 특정 상태 집합에 포함된 모니터 컬렉션과 그에 연결된 프로브 및 응답기를 파악할 수 있습니다.

상태를 보려면 Get-ServerHealth 및 Get-HealthReport cmdlet을 사용합니다. Get-ServerHealth는 원시 상태 데이터를 검색하는 데 사용되며, Get-HealthReport는 원시 상태 데이터에 대해 작동하여 현재 상태에 대한 간략한 요약 정보를 제공합니다. 이러한 cmdlet은 여러 계층에서 작동할 수 있습니다.

• 이러한 cmdlet은 특정 서버의 상태를 상태 집합별로 구분하여 표시할 수 있습니다.
• 이러한 cmdlet을 사용하여 특정 상태 집합을 자세히 확인하고 각 모니터의 상태를 볼 수 있습니다.
• 이러한 cmdlet을 사용하여 특정 서버 집합(DAG 구성원 또는 부하 분산된 CAS 어레이)의 상태를 요약할 수 있습니다.

상태 집합은 상태 그룹이라고 하는 기능 단위로 그룹화됩니다. 네 가지 상태 그룹이 있으며 이러한 그룹은 SCOM 관리 포털 내에서 보고에 사용됩니다.

1. 고객 접점 - 직접적인 실시간 고객 상호 작용이 있는 구성 요소(예: OWA)
2. 서비스 구성 요소 - 직접적인 실시간 고객 상호 작용이 없는 구성 요소(예: OAB 생성)
3. 서버 구성 요소 - 서버의 물리적 리소스(예: 디스크, 메모리)
4. 의존 관계 사용 가능성 - 서버가 의존 관계를 호출하는 기능(예: Active Directory).

결론

Managed Availability는 각 서버 내에서 다양한 상태 진단을 수행합니다. 이러한 주기적인 정규 테스트를 통해 다양한 구성 요소의 실행 가능성을 파악합니다. 즉, 사용자 부하가 있기 전과 있는 동안 서버 또는 서버 집합의 상태를 확인합니다. 문제가 감시되면 여러 단계의 문제 해결 조치를 취하여 서버를 작동 상태로 복원하며, 서버가 정상 상태로 복원되지 않을 경우 운영자에게 주목이 필요하다는 경고를 보낼 수 있습니다.

이와 같이 Managed Availability는 사용자 경험에 중점을 두어 문제가 발생하더라도 사용자 경험에 미치는 영향을 최소화합니다.

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Lessons from the Datacenter: Managed Availability를 참조하십시오.