관리되는 가용성Managed Availability

적용 대상: Exchange Server 2013 SP1Applies to: Exchange Server 2013 SP1

메시징 시스템 관리자의 기본적인 목표는 사용자에게 항상 효율적인 전자 메일 환경을 제공하는 것입니다. Microsoft Exchange Server 2013 조직의 가용성과 안정성을 보장하려면 시스템의 모든 측면을 적극적으로 모니터링하고 확인된 문제를 신속하게 해결해야 합니다. 이전 Exchange 버전에서는 중요 시스템 구성 요소를 모니터링할 때 대개 Microsoft System Center 2012 Operations Manager와 같은 외부 응용 프로그램을 사용하여 데이터를 수집한 다음 수집된 데이터 분석을 통해 확인된 문제에 대한 복구 작업을 제공했습니다. Exchange 2010 이하 버전에서는 상태 매니페스트 및 상관 관계 엔진이 관리 팩 형태로 포함되어 있었습니다. Operations Manager에서는 이러한 구성 요소를 통해 특정 구성 요소의 상태가 정상인지 여부를 확인했습니다. 또한 Operations Manager는 Exchange 2010에서 기본 제공되는 진단 cmdlet 인프라를 사용하여 다양한 시스템 측면에 대해 가상 트랜잭션을 실행했습니다.Ensuring that users have a good email experience has always been the primary objective for messaging system administrators. To help ensure the availability and reliability of your Microsoft Exchange Server 2013 organization, all aspects of the system must be actively monitored, and any detected issues must be resolved quickly. In previous versions of Exchange, monitoring critical system components typically involved using an external application such as Microsoft System Center 2012 Operations Manager to collect data, and to provide recovery action for problems detected as a result of analyzing the collected data. Exchange 2010 and previous versions included health manifests and correlation engines in the form of management packs. These components enabled Operations Manager to make a determination as to whether a particular component was healthy or unhealthy. In addition, Operations Manager also used the diagnostic cmdlet infrastructure built into Exchange 2010 to run synthetic transactions against various aspects of the system.

Exchange 2013에서는 모니터링 및 복구 작업을 기본적으로 제공 하는 관리 되는 가용성 이라는 기능을 사용 하 여 최종 사용자 환경을 기본적으로 모니터링 하 고 보존 하는 새로운 방법을 제공 합니다.Exchange 2013 takes a new approach to monitoring and preserving the end user experience natively using a feature called Managed Availability that provides built-in monitoring and recovery actions.

관리되는 가용성Managed Availability

활성 모니터링 또는 로컬 활성 모니터링이 라고도 하는 관리 되는 가용성은 Exchange 고가용성 플랫폼과 기본 제공 되는 모니터링 및 복구 작업을 통합 한 것입니다.Managed availability, also known as Active Monitoring or Local Active Monitoring, is the integration of built-in monitoring and recovery actions with the Exchange high availability platform. 이 기능은 문제가 발생하여 시스템에서 검색되면 바로 복구를 진행하도록 설계되었습니다.It's designed to detect and recover from problems as soon as they occur and are discovered by the system. 이전의 Exchange용 외부 모니터링 솔루션 및 기술과 달리, 관리되는 가용성은 문제의 근본 원인을 식별하고 전달하려고 하지 않습니다.Unlike previous external monitoring solutions and techniques for Exchange, managed availability doesn't try to identify or communicate the root cause of an issue. 대신, 사용자 환경의 세 가지 주요 영역을 해결하는 복구 측면에 중점을 둡니다.It's instead focused on recovery aspects that address three key areas of the user experience:

  • 가용성: 사용자가 서비스에 액세스할 수 있나요?Availability: Can users access the service?

  • 대기 시간: 사용자의 경험을 어떻게 제공 하나요?Latency: How is the experience for users?

  • 오류: 사용자가 원하는 작업을 수행할 수 있습니까?Errors: Are users able to accomplish what they want?

Exchange 2013에서는 서버 역할이 통합되고 아키텍처의 기타 측면이 변경되어 이전 Exchange 버전에서 사용되었던 모니터링 방법 및 상태 모델과는 다른 새로운 방식이 필요합니다. 관리되는 가용성은 기본적인 상태 모니터링 및 복구 솔루션을 제공하여 이와 같이 변경된 아키텍처의 문제를 처리하도록 설계되었습니다. 관리되는 가용성은 개별 시스템 부분의 모니터링 방식을 종단 간 사용자 환경 모니터링 방식으로 전환하며, 복구 지향 작업을 통해 최종 사용자 환경을 보호합니다.The server role consolidation and other architectural changes in Exchange 2013 require a new approach to the monitoring methodologies and health model used in previous versions of Exchange. Managed availability is designed to address these changes by providing a native health monitoring and recovery solution. It moves away from monitoring individual separate slices of the system to monitoring the end-to-end user experience, and protecting the end user's experience through recovery-oriented actions.

관리되는 가용성은 모든 Exchange 2013 서버에서 실행되는 내부 프로세스입니다. 이 프로세스에서는 초당 수백 개의 상태 메트릭을 폴링 및 분석합니다. 잘못된 항목이 발견되면 대부분의 경우에는 자동으로 수정됩니다. 그러나 관리되는 가용성이 자체적으로 수정할 수 없는 문제도 발생합니다. 이러한 경우 관리되는 가용성은 이벤트 로깅을 통해 해당 문제를 관리자에게 에스컬레이션합니다.Managed availability is an internal process that runs on every Exchange 2013 server. It polls and analyzes hundreds of health metrics every second. If something is found to be wrong, most of the time it will be fixed automatically. But there will always be issues that managed availability won't be able to fix on its own. In those cases, managed availability will escalate the issue to an administrator by means of event logging.

관리되는 가용성은 다음의 두 서비스 형식으로 구현됩니다.Managed availability implemented in the form of two services:

  • Exchange Health Manager 서비스 (msexchangehmhost.exe): 작업자 프로세스를 관리 하는 데 사용 되는 컨트롤러 프로세스입니다.Exchange Health Manager Service (MSExchangeHMHost.exe): This is a controller process used to manage worker processes. 필요에 따라 작업자 프로세스를 작성, 실행, 시작 및 중지하는 데 사용됩니다.It's used to build, execute, and start and stop the worker process, as needed. 프로세스의 작동이 실패할 경우 단일 실패 지점이 되지 않도록 작업자 프로세스를 복구하는 데도 사용됩니다.It's also used to recover the worker process in case that process fails, to prevent the worker process from being a single point of failure.

  • Exchange Health Manager 작업자 프로세스 (msexchangehmworker.exe): 관리 되는 가용성 프레임 워크 내에서 런타임 작업 수행을 담당 하는 작업자 프로세스입니다.Exchange Health Manager Worker process (MSExchangeHMWorker.exe): This is the worker process responsible for performing run-time tasks within the managed availability framework.

관리되는 가용성의 기능은 영구 저장소를 사용하여 수행됩니다.Managed availability uses persistent storage to perform its functions:

  • \Bin\모니터링\구성 폴더의 XML 파일은 일부 프로브 및 모니터 작업 항목의 구성 설정을 저장 하는 데 사용 됩니다.XML files in the \bin\Monitoring\config folder are used to store configuration settings for some of the probe and monitor work items.

  • Active Directory는 전역 재정의를 저장하는 데 사용됩니다.Active Directory is used to store global overrides.

  • Windows 레지스트리는 책갈피 및 로컬(서버별) 재정의와 같은 런타임 데이터를 저장하는 데 사용됩니다.The Windows registry is used to store run-time data, such as bookmarks, and local (server-specific) overrides.

  • Windows 크림슨 채널 이벤트 로그 인프라는 작업 항목 결과를 저장하는 데 사용됩니다.The Windows crimson channel event log infrastructure is used to store the work item results.

  • 상태 사서함은 프로브 활동에 사용됩니다. 서버의 각 사서함 데이터베이스에 대해 여러 상태 사서함이 만들어집니다.Health mailboxes are used for probe activity. Multiple health mailboxes will be created on each mailbox database that exists on the server.

다음 그림에 나와 있는 것처럼 관리되는 가용성은 계속해서 작업을 수행하는 세 가지 주요 비동기 구성 요소를 포함합니다.As illustrated in the following drawing, managed availability includes three main asynchronous components that are constantly doing work.

관리되는 가용성 구성 요소Managed Availability Components

Exchange Server 2013의 관리되는 가용성Managed Availability in Exchange Server 2013

첫 번째 구성 요소를 프로브라고 합니다.The first component is called a Probe. 프로브는 서버에서 측정을 수행 하 고 데이터를 수집 하는 일을 담당 합니다.Probes are responsible for taking measurements on the server and collecting data. 이러한 측정 결과가 두 번째 구성 요소인 모니터로전달 됩니다.The results of those measurements flow into the second component, the Monitor. 이 모니터에는 수집 된 데이터에 대해 정상 상태로 간주 되는 사항을 기반으로 시스템에서 사용 하는 모든 비즈니스 논리가 포함 됩니다.The monitor contains all of the business logic used by the system based on what is considered healthy on the data collected. 패턴 인식 엔진과 마찬가지로, 모니터는 수집 된 모든 측정 단위에서 다양 한 패턴을 찾은 다음 정상적인 것으로 간주 되는지 여부를 결정 합니다.Similar to a pattern recognition engine, the monitor looks for the various different patterns on all the collected measurements, and then it decides whether something is considered healthy. 마지막으로, 복구 및 에스컬레이션 작업을 담당 하는 응답자가 있습니다.Finally, there are Responders, which are responsible for recovery and escalation actions. 문제가 비정상적인 경우 첫 번째 작업은 해당 구성 요소 복구를 시도 하는 것입니다.When something is unhealthy, the first action is to attempt to recover that component. 여기에는 다단계 복구 작업이 포함 될 수 있습니다. 예를 들어 첫 번째 시도는 응용 프로그램 풀을 다시 시작 하 여 서비스를 다시 시작 하 고, 세 번째 시도는 서버를 다시 시작 해야 할 수 있으며, 이후 시도는 더 이상 트래픽을 허용 하지 않도록 서버를 오프 라인으로 설정 하는 것입니다.This could include multi-stage recovery actions; for example, the first attempt may be to restart the application pool, the second may be to restart the service, the third attempt may be to restart the server, and the subsequent attempt may be to take the server offline so that it no longer accepts traffic. 복구 작업이 실패 하면 시스템은 이벤트 로그 알림을 통해 문제를 사용자에 게 전달 합니다.If the recovery actions are unsuccessful, the system escalates the issue to a human through event log notifications.

프로브에는 세 가지 주요 범주인 되풀이 프로브, 알림 및 확인이 있습니다.There are three primary categories of probes: recurrent probes, notifications, and checks. 되풀이 프로브는 시스템에서 종단 간 사용자 환경을 테스트 하기 위해 수행 하는 가상 트랜잭션입니다.Recurrent probes are synthetic transactions performed by the system to test the end-to-end user experience. 검사는 사용자 트래픽을 비롯한 성능 데이터를 수집하고, 사용자 오류에서 스파이크를 확인하기 위해 설정된 임계값을 기준으로 수집된 데이터를 측정하는 인프라입니다.Checks are the infrastructure that perform the collection of performance data, including user traffic, and measure the collected data against thresholds that are set to determine spikes in user failures. 이를 통해 검사 인프라는 사용자에게 문제가 발생하면 그것을 인식할 수 있게 됩니다.This enables the checks infrastructure to become aware when users are experiencing issues. 마지막으로 알림 논리는 프로브에 의해 수집된 데이터의 결과를 기다리지 않고도 시스템이 중요 이벤트를 기반으로 즉시 조치를 취할 수 있도록 합니다.Finally, the notification logic enables the system to take action immediately based on a critical event, without having to wait for the results of the data collected by a probe. 일반적으로 대규모 샘플 집합 없이도 검색 및 인식될 수 있는 예외나 조건에 해당합니다.These are typically exceptions or conditions that can be detected and recognized without a large sample set.

되풀이 프로브는 몇 분 마다 실행 되며 서비스 상태의 일부를 확인 합니다.Recurrent probes run every few minutes and check some aspect of service health. 이러한 프로브는 Exchange ActiveSync를 통해 전자 메일을 모니터링 사서함으로 전송 하 여 RPC 끝점에 연결 하거나 클라이언트 액세스-사서함 연결을 확인할 수 있습니다.These probes might transmit an email via Exchange ActiveSync to a monitoring mailbox, they might connect to an RPC endpoint, or they might verify Client Access-to-Mailbox connectivity.

모든 프로브는 Health Manager 서비스 시작 시 ActiveMonitoring\ProbeDefinition 크림슨 채널에서 정의 됩니다.All probes are defined on Health Manager service startup in the Microsoft.Exchange.ActiveMonitoring\ProbeDefinition crimson channel. 각 프로브 정의에는 여러 속성이 있지만 가장 관련성이 높은 속성은 다음과 같습니다.Each probe definitions has many properties, but the most relevant properties are:

  • Name: 프로브의 SampleMask 로 시작 하는 프로브 이름입니다.Name: The name of the probe, which begins with a SampleMask of the probe's monitor.

  • TypeName: 프로브 논리가 포함 된 프로브의 코드 개체 형식입니다.TypeName: The code object type of the probe that contains the probe's logic.

  • ServiceName:이 프로브를 포함 하는 상태 집합의 이름입니다.ServiceName: The name of the health set that contains this probe.

  • TargetResource: 프로브에서 유효성을 검사 하는 개체입니다.TargetResource: The object the probe is validating. 이 파일을 실행 하 여 프로브 결과 Resultname 이 되는 프로브 이름에 추가 됩니다.This is appended to the name of the probe when it is executed to become a probe result ResultName

  • RecurrenceIntervalSeconds: 검색을 실행 하는 빈도입니다.RecurrenceIntervalSeconds: How often the probe executes.

  • Timeoutseconds: 프로브에서 오류가 발생할 때까지 대기 하는 시간입니다.TimeoutSeconds: How long the probe will wait before failing.

수많은 되풀이 프로브를 사용할 수 있습니다.There are hundreds of recurrent probes. 이러한 프로브 중 상당수는 데이터베이스 수가 증가 함에 따라 다를 수 있기 때문에 프로브 수가 늘어납니다.Many of these probes are per-database, so as the number of databases increases, so does the number of probes. 대부분의 프로브는 코드에서 정의 되므로 직접 검색할 수 없습니다.Most probes are defined in code and are therefore not directly discoverable.

되풀이 프로브의 기본 사항은 다음과 같습니다. 모든 RecurrenceIntervalSeconds 을 시작 하 고 상태에 따라 확인 (또는 프로브)을 수행 합니다.The basics of a recurrent probe are as follows: start every RecurrenceIntervalSeconds and check (or probe) some aspect of health. 구성 요소가 정상 상태인 경우 프로브에서는\ ResultType 이 3 인 ActiveMonitoring ProbeResult 채널에 정보 이벤트를 전달 하 고 기록 합니다.If the component is healthy, the probe passes and writes an informational event to the Microsoft.Exchange.ActiveMonitoring\ProbeResult channel with a ResultType of 3. 확인이 실패 하거나 시간이 초과 되 면 프로브에 오류가 발생 하 여 동일한 채널에 오류 이벤트가 기록 됩니다.If the check fails or times out, the probe fails and writes an error event to the same channel. ResultType 은 검사가 실패 하 고 resulttype 1로 제한 시간이 초과 되었음을 의미 합니다. 대부분의 프로브는 MaxRetryAttempts 속성의 값까지 시간이 초과 되 면 다시 실행 됩니다.A ResultType of 4 means the check failed and a ResultType of 1 means that it timed out. Many probes will re-run if they timeout, up to the value of the MaxRetryAttempts property.

참고

참고 사항 ProbeResult 크림슨 채널은 몇 분 마다 수백 개의 프로브를 실행 하 고 이벤트를 로깅하 며, 프로덕션 환경에서 이벤트 로그에 대해 비싼 쿼리를 시도 하는 경우 Exchange 서버의 성능에 실질적인 영향을 줄 수 있습니다.Note The ProbeResult crimson channel can get very busy with hundreds of probes running every few minutes and logging an event, so there can be a real impact on the performance of your Exchange server if you try expensive queries against the event logs in a production environment.

알림은 상태 관리자 프레임 워크에서 실행 되지 않지만 서버에 있는 다른 서비스의 프로브입니다.Notifications are probes that are not run by the health manager framework, but by some other service on the server. 이러한 서비스는 자체 모니터링을 수행한 다음 프로브 결과를 직접 작성 하 여 관리 되는 가용성 프레임 워크에 데이터를 공급 합니다.These services perform their own monitoring, and then feed their data into the Managed Availability framework by directly writing probe results. 이 채널은 관리 되는 가용성 프레임 워크에 의해 실행 되는 프로브만 설명 하므로 ProbeDefinition 채널에서 이러한 프로브를 볼 수 없습니다.You won't see these probes in the ProbeDefinition channel, as this channel only describes probes that will be run by the Managed Availability framework. 예를 들어 ServerOneCopyMonitor 모니터는 MSExchangeDAGMgmt 서비스에 의해 작성 된 프로브 결과에 의해 트리거됩니다.For example, the ServerOneCopyMonitor Monitor is triggered by probe results written by the MSExchangeDAGMgmt service. 이 서비스는 자체 모니터링을 수행 하 고, 문제가 있는지 여부를 확인 하 고 프로브 결과를 기록 합니다.This service performs its own monitoring, determines whether there is a problem, and logs a probe result. 대부분의 알림 프로브에는 모니터를 비정상으로 설정 하는 빨간색 이벤트와 모니터를 다시 정상 상태로 만드는 녹색 이벤트가 모두 기록 됩니다.Most notification probes have the capability to log both a red event that turns the monitor unhealthy and a green event that makes the monitor healthy again.

성능 카운터가 정의 된 임계값을 초과 하거나 그 아래를 지날 때 이벤트만 기록 되는 검사를 수행 합니다.Checks are probes that only log events when a performance counter passes above or below a defined threshold. 서버에 대 한 성능 카운터를 모니터링 하 고 구성 된 임계값이 충족 될 때 ProbeResult 채널에 이벤트를 로깅하는 서비스 이기 때문에 실제로는 알림 프로브의 특수 한 경우입니다.They are really a special case of notification probes, as there is a service monitoring the performance counters on the server and logging events to the ProbeResult channel when the configured threshold is met.

비정상 인 것으로 간주 되는 카운터 및 임계값을 찾기 위해 모니터에서이 검사를 확인할 수 있습니다.To find the counter and threshold that is considered unhealthy, you can look at the monitor for this check. OverallConsecutiveSampleValueAboveThresholdMonitor 또는 ActiveMonitoring 형식의 모니터에서 조사 중인 검색이 검사 프로브 임을 의미 합니다. 라는 것을 나타내는 것 입니다.Monitors of the type Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor or Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor mean that the probe they watch is a check probe

모니터는 프로브에 수집된 데이터를 쿼리하여 미리 정의된 규칙 집합에 따라 조치를 취해야 하는지를 결정합니다. 규칙이나 문제의 특성에 따라, 모니터는 응답자를 시작하거나 이벤트 로그 항목을 통해 담당자에게 문제를 에스컬레이션할 수 있습니다. 또한 모니터는 장애가 발생한 다음 응답자가 실행되기까지 걸리는 시간과 복구 작업의 워크플로를 정의합니다. 모니터는 다양한 상태를 갖습니다. 시스템 상태 관점에서 모니터는 다음 두 가지 상태로 존재합니다.Monitors query the data collected by probes to determine if action needs to be taken based on a predefined rule set. Depending on the rule or the nature of the issue, a monitor can either initiate a responder or escalate the issue to a human via an event log entry. In addition, monitors define how much time after a failure that a responder is executed, as well as the workflow of the recovery action. Monitors have various states. From a system state perspective, monitors have two states:

  • 정상: 모니터가 올바르게 작동 중 이며 수집 된 모든 메트릭이 정상 작동 매개 변수 내에 있습니다.Healthy: The monitor is operating properly and all collected metrics are within normal operating parameters

  • 비정상상태: 모니터가 정상이 아니며, 응답자를 통해 복구를 시작 했거나 에스컬레이션을 통해 관리자에 게 알렸습니다.Unhealthy: The monitor isn't healthy and has either initiated recovery through a responder or notified an administrator through escalation.

관리적 관점에서 볼 때 모니터는 셸에 다음과 같은 추가 상태로 나타납니다.From an administrative perspective, monitors have additional states that appear in the Shell:

  • 성능 저하됨: 모니터가 정상적인 상태가 0 ~ 60 초 이면 성능이 저하 된 것으로 간주 됩니다.Degraded: When a monitor is in an unhealthy state from 0 through 60 seconds, it's considered Degraded. 모니터가 60초를 넘게 비정상 상태이면 비정상 상태로 간주됩니다.If a monitor is unhealthy for more than 60 seconds, it is considered Unhealthy.

  • 사용 안 함: 관리자가 명시적으로 모니터를 사용 하지 않도록 설정 했습니다.Disabled: The monitor has been explicitly disabled by an administrator.

  • 사용할 수 없음: Microsoft Exchange 상태 서비스가 각 모니터의 상태를 주기적으로 쿼리 합니다.Unavailable: The Microsoft Exchange Health service periodically queries each monitor for its state. 쿼리에 응답하지 못하면 모니터 상태는 사용할 수 없음이 됩니다.If it doesn't get a response to the query, the monitor state becomes Unavailable.

  • 복구: 관리자가 정정 작업이 진행 중임을 시스템에 표시 하도록 설정 하 여 시스템 및 사용자가 수정 작업을 수행 하는 동안에 발생할 수 있는 다른 오류 (예: 데이터베이스 복사본 다시 시드 작업)를 구별할 수 있도록 합니다.Repairing: An administrator sets the Repairing state to indicate to the system that corrective action is in process by a human, which allows the system and humans to differentiate between other failures that may occur at the same time corrective action is being taken (such as a database copy reseed operation).

모든 모니터의 정의에는 SampleMask 속성이 포함 되어 있습니다.Every monitor has a SampleMask property in its definition. 모니터가 실행 되 면 ProbeResult 채널에서 해당 모니터의 SampleMask일치 하는 resultname 을 갖는 이벤트를 찾습니다.As the monitor executes, it looks for events in the ProbeResult channel that have a ResultName that matches the monitor's SampleMask. 이러한 이벤트는 되풀이 프로브, 알림 또는 검사에서 발생할 수 있습니다.These events could be from recurrent probes, notifications, or checks. 모니터의 임계값이 달성 되 면 비정상 상태가 됩니다.If the monitor's thresholds are achieved, it becomes Unhealthy. 모니터 측면에서 세 가지 프로브 유형은 각각 ProbeResult 채널에 대 한 로그와 동일 합니다.From the monitor's perspective, all three probe types are the same as they each log to the ProbeResult channel.

단일 프로브 오류가 반드시 서버에 문제가 있음을 나타내는 것은 아닙니다.It is worth noting that a single probe failure does not necessarily indicate that something is wrong with the server. 수정 해야 하는 실질적인 문제가 있을 때 올바르게 식별 되는 모니터의 디자인입니다.It is the design of monitors to correctly identify when there is a real problem that needs fixing. 이는 대부분의 모니터가 정상이 되기 전에 여러 프로브 오류에 대 한 임계값을 갖는 이유입니다.This is why many monitors have thresholds of multiple probe failures before becoming Unhealthy. 그러나 이러한 문제는 대부분의 경우 응답자에 의해 자동으로 해결할 수 있으므로 수동 개입이 필요한 문제를 찾기 위한 최상의 위치는 Microsoft의 ManagedAvailability\모니터링 크림슨 채널에 있습니다.Even then, many of these problems can be fixed automatically by responders, so the best place to look for problems that require manual intervention is in the Microsoft.Exchange.ManagedAvailability\Monitoring crimson channel. 여기에는 가장 최근 프로브 오류가 포함 됩니다.This will include the most recent probe error.

이름에서 알 수 있듯이 응답자는 모니터에서 생성된 경고에 대한 일종의 응답을 실행합니다. 응답자는 응용 프로그램 작업자 풀 다시 설정, 서버 다시 시작 등의 다양한 복구 작업을 수행합니다. 다음과 같은 여러 유형의 응답자가 있습니다.As their name implies, responders execute some sort of response to an alert that was generated by a monitor. Responders take a variety of recovery actions, such as resetting an application worker pool to restarting a server. There are several types of responders:

  • 응답자 다시 시작: 서비스를 종료 하 고 다시 시작 합니다.Restart Responder: Terminates and restarts a service

  • AppPool 응답자 다시 설정: IIS (인터넷 정보 서비스)에서 응용 프로그램 풀을 중지 하 고 다시 시작 합니다.Reset AppPool Responder: Stops and restarts an application pool in Internet Information Services (IIS)

  • 장애 조치 (Failover) 응답자: 데이터베이스 또는 서버 장애 조치 (failover) 시작Failover Responder: Initiates a database or server failover

  • 버그 확인 응답자: 서버의 버그 확인을 시작 하 여 서버를 다시 부팅 합니다.Bugcheck Responder: Initiates a bugcheck of the server, thereby causing a server reboot

  • 오프 라인 응답기: 서버에서 프로토콜을 사용 하지 않습니다 (클라이언트 요청 거부).Offline Responder: Takes a protocol on a server out of service (rejects client requests)

  • 온라인 응답자: 서버의 프로토콜을 다시 프로덕션 상태로 설정 합니다 (클라이언트 요청 수락).Online Responder: Places a protocol on a server back into production (accepts client requests)

  • 응답기 승격: 이벤트 로깅을 통해 관리자에 게 문제를 전달 합니다.Escalate Responder: Escalates the issue to an administrator via event logging

일부 구성 요소에는 위에 나와 있는 응답자 외에도 구성 요소별로 고유한 특수 응답자가 있습니다.In addition to the above listed responders, some components also have specialized responders that are unique to their component.

모든 응답자는 응답자 작업 제어를 위한 시퀀스 메커니즘이 기본 제공되는 제한 동작을 포함합니다. 제한 동작은 응답자 복구 작업으로 인해 시스템이 손상되거나 성능이 저하되지 않도록 하기 위한 것입니다. 모든 응답자는 특정 방식으로 제한됩니다. 제한이 수행되면 응답자 작업에 따라 응답자 복구 작업이 지연되거나 작업 자체를 건너뛸 수 있습니다. 예를 들어 버그 확인 응답자가 제한되면 해당 작업은 지연되지 않고 작업 자체를 건너뜁니다.All responders include throttling behavior, which provide a built-in sequencing mechanism for controlling responder actions. The throttling behavior is designed to ensure that the system isn't compromised or made worse as a result of responder recovery actions. All responders are throttled in some fashion. When throttling occurs, the responder recovery action may be skipped or delayed, depending on the responder action. For example, when the Bugcheck Responder is throttled, its action is skipped, and not delayed.

상태 집합Health Sets

보고 측면에서 볼 때 관리되는 가용성에는 두 가지 상태 보기(내부/외부)가 있습니다.From a reporting perspective, managed availability has two views of health, one internal and one external. 내부 보기에서는 상태 집합을 사용 합니다.The internal view uses health sets. Outlook Web App, Exchange ActiveSync, 정보 저장소 서비스, 콘텐츠 인덱싱, 전송 서비스 등 Exchange 2013의 각 구성 요소는 프로브, 모니터 및 응답자를 사용하여 관리되는 가용성을 통해 모니터링됩니다.Each component in Exchange 2013 (for example, Outlook Web App, Exchange ActiveSync, the Information Store service, content indexing, transport services, etc.) is monitored by managed availability using probes, monitors, and responders. 지정 된 구성 요소에 대 한 프로브, 모니터 및 응답자 그룹을 상태 집합이라고 합니다.A group of probes, monitors and responders for a given component is called a health set. 즉, 상태 집합은 해당 구성 요소가 정상 상태인지를 확인하는 프로브, 모니터 및 응답자의 그룹입니다.A health set is a group of probes, monitors, and responders that determine if that component is healthy. 상태 집합의 현재 상태(예: 정상/비정상 상태)는 상태 집합 모니터의 상태를 통해 결정됩니다.The current state of a health set (e.g., whether it is healthy or unhealthy) is determined by using the state of the health set's monitors. 상태 집합의 모든 모니터가 정상 상태이면 해당 상태 집합도 정상 상태입니다.If all of a health set's monitors are healthy, then the health set is in a healthy state. 모니터 중 하나라도 정상 상태가 아니면 상태 집합의 상태는 상태가 가장 좋지 않은 모니터에 의해 결정됩니다.If any monitor is not in a healthy state, then the health set state will be determined by its least healthy monitor.

서버 상태 또는 상태 집합 상태를 확인 하는 자세한 단계는 상태 집합 및 서버 상태 관리를 참조 하세요.For detailed steps to view server health or health sets state, see Manage health sets and server health.

상태 그룹Health Groups

관리 되는 가용성의 외부 보기는 상태 그룹으로 구성 됩니다.The external view of managed availability is composed of health groups. 상태 그룹은 System Center Operations Manager 2007 R2 및 System Center Operations Manager 2012를 통해 표시됩니다.Health groups are exposed to System Center Operations Manager 2007 R2 and System Center Operations Manager 2012.

기본 상태 그룹은 다음의 4가지입니다.There are four primary health groups:

  • 고객 터치 포인트: 프로토콜, 정보 저장소 등 실시간 사용자 상호 작용에 영향을 주는 구성 요소Customer Touch Points: Components that affect real-time user interactions, such as protocols, or the Information Store

  • 서비스 구성 요소: Microsoft Exchange 사서함 복제 서비스 또는 OABGen (오프 라인 주소록 생성 프로세스)와 같은 직접적인 실시간 사용자 상호 작용 없이 구성 요소Service Components: Components without direct, real-time user interactions, such as the Microsoft Exchange Mailbox Replication service, or the offline address book generation process (OABGen)

  • 서버 구성 요소: 디스크 공간, 메모리, 네트워킹 등 서버의 실제 리소스Server Components: The physical resources of the server, such as disk space, memory and networking

  • 종속성 가용성: 서버에서 Active DIRECTORY, DNS 등의 필요한 종속성에 액세스할 수 있는 기능입니다.Dependency Availability: The server's ability to access necessary dependencies, such as Active Directory, DNS, etc.

Exchange 관리 팩을 설치 하면 System Center Operations Manager (SCOM)가 Exchange 환경과 관련 된 정보를 볼 수 있는 상태 포털 역할을 합니다.When the Exchange Management Pack is installed, System Center Operations Manager (SCOM) acts as a health portal for viewing information related to the Exchange environment. SCOM 대시보드에는 Exchange 서버 상태의 3개 보기가 포함되어 있습니다.The SCOM dashboard includes three views of Exchange server health:

  • 활성 경고: 문제 제기 응답자는 SCOM 내에서 모니터에 사용 되는 Windows 이벤트 로그에 이벤트를 기록 합니다.Active Alerts: Escalation Responders write events to the Windows event log that are consumed by the monitor within SCOM. 이러한 이벤트는 활성 경고 보기에 경고로 표시됩니다.These appear as alerts in the Active Alerts view.

  • 조직 상태: Exchange 조직 상태에 대 한 전반적인 상태의 롤업 요약이이 보기에 표시 됩니다.Organization Health: A rollup summary of the overall health of the Exchange organization health is displayed in this view. 이러한 롤업에는 개별 데이터베이스 가용성 그룹의 상태와 특정 Active Directory 사이트 내의 상태가 표시됩니다.These rollups include displaying health for individual database availability groups, and health within specific Active Directory sites.

  • 서버 상태: 관련 상태 집합이 상태 그룹으로 결합 되어이 보기에 요약 되어 있습니다.Server Health: Related health sets are combined into health groups and summarized in this view.

재정의Overrides

관리자는 재정의 기능을 사용하여 관리되는 가용성 프로브, 모니터 및 응답자의 일부 측면을 구성할 수 있습니다. 재정의를 통해 관리되는 가용성에서 사용되는 일부 임계값을 미세 조정할 수 있습니다. 또한 기본 제공되는 기본값과는 다른 구성 설정을 사용해야 할 수도 있는 예기치 않은 이벤트에 대해 긴급 작업을 수행하도록 설정할 수도 있습니다.Overrides provide an administrator with the ability to configure some aspects of the managed availability probes, monitors, and responders. Overrides can be used to fine tune some of the thresholds used by managed availability. They can also be used to enable emergency actions for unexpected events that may require configuration settings that are different from the out-of-box defaults.

재정의를 만들어 단일 서버에 적용 하거나 (이를 서버 재정의라고 함) 서버 그룹에 적용할 수 있습니다 (이는 전역 재정의라고도 함).Overrides can be created and applied to a single server (this is known as a server override), or they can be applied to a group of servers (this is known as a global override). 서버 재정의 구성 데이터는 재정의가 적용되는 서버의 Windows 레지스트리에 저장됩니다.Server override configuration data is stored in the Windows registry on the server on which the override is applied. 전역 재정의 구성 데이터는 Active Directory에 저장됩니다.Global override configuration data is stored in Active Directory.

재정의는 무기한으로 적용되도록 구성할 수도 있고 특정 기간에만 적용되도록 구성할 수도 있습니다. 또한 전역 재정의가 모든 서버에 적용되거나 특정 Exchange 버전을 실행 중인 서버에만 적용되도록 구성할 수도 있습니다.Overrides can be configured to last indefinitely, or they can be configured for a specific duration. In addition, global overrides can be configured to apply to all servers, or only servers running a specific version of Exchange.

재정의를 구성해도 즉시 적용되지는 않습니다. Microsoft Exchange Health Manager Service는 10분마다 업데이트된 구성 데이터를 확인합니다. 또한 전역 재정의는 Active Directory 목제 대기 시간에 따라서도 달라집니다.When you configure an override, it will not take effect immediately. The Microsoft Exchange Health Manager service checks for updated configuration data every 10 minutes. In addition, global overrides will be dependent on Active Directory replication latency.

서버 또는 전역 재정의를 보거나 구성 하는 자세한 단계는 관리 되는 가용성 재정의 구성을참조 하세요.For detailed steps to view or configure server or global overrides, see Configure managed availability overrides.

관리 작업 및 cmdletManagement Tasks and Cmdlets

관리자는 관리되는 가용성과 관련하여 대개 다음의 세 가지 기본 운영 작업을 수행합니다.There are three primary operational tasks that administrators will typically perform with respect to managed availability:

  • 시스템 상태 추출 또는 보기Extracting or viewing system health

  • 상태 집합 및 프로브/모니터/응답자 세부 정보 보기Viewing health sets, and details about probes, monitors and responders

  • 재정의 관리Managing overrides

관리되는 가용성에 기본적으로 사용되는 두 가지 관리 도구는 Windows 이벤트 로그 및 셸입니다. 관리되는 가용성은 Exchange ActiveMonitoring 및 ManagedAvailability 크림슨 채널 이벤트 로그에 다음과 같은 많은 정보를 기록합니다.The two primary management tools for managed availability are the Windows Event Log and the Shell. Managed availability logs a large amount of information in the Exchange ActiveMonitoring and ManagedAvailability crimson channel event logs, such as:

  • 개별 *Definition 이벤트 로그에 기록되는 프로브/모니터/응답자 정의Probe, monitor, and responder definitions, which are logged in the respective *Definition event logs.

  • 개별 *Results 이벤트 로그에 기록되는 프로브/모니터/응답자 결과Probe, monitor, and responder results, which are logged in the respective *Results event logs.

  • 복구 작업 시작 시간과 작업이 완료된 것으로 간주된 시간(성공 여부는 관계없음)을 포함하는, RecoveryActionResults 이벤트 로그에 기록되는 응답자 복구 작업 관련 세부 정보Details about responder recovery actions, including when the recovery action is started, and it is considered complete (whether successful or not), which are logged in the RecoveryActionResults event log.

다음 표에서는 관리되는 가용성에 사용되는 12개 cmdlet에 대해 설명합니다.There are 12 cmdlets used for managed availability, which are described in the following table.

#A0Cmdlet 설명Description

ServerHealthGet-ServerHealth

상태 집합과 현재 상태 (정상 또는 비정상), 상태 집합 모니터, 서버 구성 요소, 프로브에 대 한 대상 리소스, 프로브 또는 모니터 시작/중지 시간 및 상태 전환과 관련 된 타임 스탬프와 같은 원시 서버 상태 정보를 가져오는 데 사용 됩니다. 자주.Used to get raw server health information, such as health sets and their current state (healthy or unhealthy), health set monitors, server components, target resources for probes, and timestamps related to probe or monitor start or stop times, and state transition times.

HealthReportGet-HealthReport

상태 집합 및 현재 상태를 포함 하는 요약 상태 보기를 가져오는 데 사용 됩니다.Used to get a summary health view that includes health sets and their current state.

Get-monitoringitemidentityGet-MonitoringItemIdentity

특정 상태 집합과 관련 된 프로브, 모니터 및 응답자를 확인 하는 데 사용 됩니다.Used to view the probes, monitors, and responders associated with a specific health set.

MonitoringItemHelpGet-MonitoringItemHelp

프로브, 모니터 및 응답자의 일부 속성에 대 한 설명을 확인 하는 데 사용 됩니다.Used to view descriptions about some of the properties of probes, monitors, and responders.

Add-servermonitoringoverride 추가Add-ServerMonitoringOverride

프로브, 모니터 또는 응답자의 서버별 로컬 재정의를 만드는 데 사용 됩니다.Used to create a local, server-specific override of a probe, monitor, or responder.

Add-servermonitoringoverrideGet-ServerMonitoringOverride

지정 된 서버의 로컬 재정의 목록을 확인 하는 데 사용 됩니다.Used to view a list of local overrides on the specified server.

Add-servermonitoringoverride을 제거 합니다.Remove-ServerMonitoringOverride

특정 서버에서 로컬 재정의를 제거 하는 데 사용 됩니다.Used to remove a local override from a specific server.

Get-globalmonitoringoverride 추가Add-GlobalMonitoringOverride

서버 그룹에 대 한 전역 재정의를 만드는 데 사용 됩니다.Used to create a global override for a group of servers.

Get-globalmonitoringoverrideGet-GlobalMonitoringOverride

조직에 구성 된 전역 재정의 목록을 확인 하는 데 사용 됩니다.Used to view a list of global overrides configured in the organization.

Get-globalmonitoringoverride을 제거 합니다.Remove-GlobalMonitoringOverride

전역 재정의를 제거 하는 데 사용 됩니다.Used to remove a global override.

Set-servercomponentstateSet-ServerComponentState

하나 이상의 서버 구성 요소 상태를 구성 하는 데 사용 됩니다.Used to configure the state of one or more server components.

Set-servercomponentstateGet-ServerComponentState

하나 이상의 서버 구성 요소 상태를 확인 하는 데 사용 됩니다.Used to view the state of one or more server components.