이전 버전에 비해 달라진 고가용성 및 사이트 복구 기능Changes to high availability and site resilience over previous versions

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

Exchange 2013에서는 DAG 및 사서함 데이터베이스 복사본과 함께 단일 항목 복구, 보존 정책, 지연된 데이터베이스 복사본 등의 다른 기능을 사용하여 고가용성, 사이트 복구 및 Exchange 고유 데이터 보호가 제공됩니다. 고가용성 플랫폼인 Exchange 정보 저장소와 ESE(Extensible Storage Engine)는 모두 탁월한 가용성 및 관리 용이성을 제공하고 비용을 절감하도록 향상되었습니다. 향상된 기능은 다음과 같습니다.Exchange 2013 uses DAGs and mailbox database copies, along with other features such as single item recovery, retention policies, and lagged database copies, to provide high availability, site resilience, and Exchange native data protection. The high availability platform, Exchange Information Store and Extensible Storage Engine (ESE) have all been enhanced to provide greater availability and easier management, and to reduce costs. These enhancements include:

  • Exchange 2010에 비해 IOPS 감소:이를 통해 더 큰 디스크를 용량 및 IOPS 측면에서 최대한 효율적으로 활용할 수 있습니다.Reduction in IOPS over Exchange 2010: This enables you to leverage larger disks in terms of capacity and IOPS as efficiently as possible.

  • 관리되는 가용성: 관리되는 가용성을 통해 내부 모니터링 및 복구 지향 기능이 긴밀하게 통합되어 오류를 방지하거나, 서비스를 능동적으로 복원하거나, 서버 장애 조치(failover)를 자동으로 시작하거나, 관리자에게 조치를 취하도록 경고할 수 있습니다.Managed availability: With managed availability, internal monitoring and recovery-oriented features are tightly integrated to help prevent failures, proactively restore services, and initiate server failovers automatically or alert administrators to take action. 핵심은 서비스를 지속적으로 사용 가능한 상태로 유지할 수 있도록 서버 및 구성 요소의 작동 시간뿐만 아니라 최종 사용자 환경을 모니터링하고 관리하는 데 있습니다.The focus is on monitoring and managing the end-user experience rather than just server and component uptime to help keep the service continuously available.

  • 관리 되는 저장소: 관리 되는 저장소는 Exchange 2013에서 새로 다시 작성 된 정보 저장소 프로세스의 이름입니다.Managed Store: The Managed Store is the name of the newly rewritten Information Store processes in Exchange 2013. 새 관리 되는 저장소는 C# 로 작성 되며 Microsoft Exchange Replication Service (MSExchangeRepl)와 긴밀 하 게 통합 되어 향상 된 탄력성을 통해 가용성을 높일 수 있습니다.The new Managed Store is written in C# and tightly integrated with the Microsoft Exchange Replication service (MSExchangeRepl.exe) to provide higher availability through improved resiliency.

  • 디스크당 여러 데이터베이스 지원: Exchange 2013에는 동일한 디스크에서 여러 데이터베이스 (활성 및 수동 복사본 혼합)를 지원 하 여 용량 및 IOPS 측면에서 더 큰 디스크를 활용할 수 있도록 하는 향상 된 기능이 포함 되어 있습니다. 가능한 한 효율적입니다.Support for multiple databases per disk: Exchange 2013 includes enhancements that enable you to support multiple databases (mixtures of active and passive copies) on the same disk, thereby leveraging larger disks in terms of capacity and IOPS as efficiently as possible.

  • AutoReseed: 자동 다시 시드 기능을 사용 하면 디스크 오류 후 데이터베이스 중복성을 신속 하 게 복원할 수 있습니다.AutoReseed: Automatic reseeding capability enables you to quickly restore database redundancy after disk failure. 디스크 오류가 발생하면 해당 디스크에 저장된 데이터베이스 복사본이 활성 데이터베이스 복사본에서 동일한 서버의 예비용 디스크로 복사됩니다.If a disk fails, the database copy stored on that disk is copied from the active database copy to a spare disk on the same server. 여러 데이터베이스 복사본이 실패한 디스크에 저장된 경우 해당 복사본을 모두 자동으로 예비용 디스크에 다시 시드할 수 있습니다.If multiple database copies were stored on the failed disk, they can all be automatically reseeded on a spare disk. 이렇게 하면 활성 데이터베이스가 여러 서버에 있을 가능성이 높아지고 데이터가 병렬로 복사되므로 다시 시드 속도가 더 빨라집니다.This enables faster reseeds, as the active databases are likely to be on multiple servers and the data is copied in parallel.

  • 저장소 오류에서 자동 복구:이 기능은 Exchange 2010에 도입 된 혁신적인 기능을 계속 사용 하 여 시스템에서 복구 또는 중복성에 영향을 주는 오류를 복구할 수 있도록 합니다.Automatic recovery from storage failures: This feature continues the innovation introduced in Exchange 2010 to allow the system to recover from failures that affect resiliency or redundancy. Exchange 2010 버그 검사 동작 외에도 Exchange 2013에는 긴 I/O 시간, MSExchangeRepl.exe의 과도한 메모리 사용 및 시스템이 스레드를 예약할 수 없는 잘못된 상태에 있는 심각한 경우를 위한 추가 복구 동작이 포함되어 있습니다.In addition to the Exchange 2010 bugcheck behaviors, Exchange 2013 includes additional recovery behaviors for long I/O times, excessive memory consumption by MSExchangeRepl.exe, and severe cases where the system is in such a bad state that threads can't be scheduled.

  • 지연 된 사본 향상: 이제 자동 로그 재생을 사용 하 여 특정 범위로 지연 된 복사본을 처리할 수 있습니다.Lagged copy enhancements: Lagged copies can now care for themselves to a certain extent using automatic log play down. 지연된 복사본은 페이지 패치, 낮은 디스크 공간 시나리오 같은 다양한 상황에서 로그 파일의 재생 속도를 자동으로 늦춥니다.Lagged copies will automatically play down log files in a variety of situations, such as page patching and low disk space scenarios. 시스템이 지연된 복사본에 대한 페이지 패치가 필요하다고 감지하면 페이지 패치를 수행하기 위해 자동으로 로그가 지연된 복사본으로 재생됩니다.If the system detects that page patching is required for a lagged copy, the logs will be automatically replayed into the lagged copy to perform page patching. 지연된 복사본은 낮은 디스크 공간 임계값에 도달한 경우와 지연된 복사본이 특정 기간 동안 유일하게 사용할 수 있는 복사본으로 감지된 경우에도 이 자동 재생 기능을 호출합니다.Lagged copies will also invoke this auto replay feature when a low disk space threshold has been reached, and when the lagged copy has been detected as the only available copy for a specific period of time. 또한 지연된 복사본은 보안 네트워크를 이용하여 복구나 활성화를 훨씬 더 쉽게 만들 수 있습니다.In addition, lagged copies can leverage Safety Net, making recovery or activation much easier.

  • 단일 복사본 경고 기능 향상: Exchange 2010에 도입 된 단일 복사본 경고는 더 이상 별도의 예약 된 스크립트가 아닙니다.Single copy alert enhancements: The single copy alert introduced in Exchange 2010 is no longer a separate scheduled script. 이 기능은 이제 시스템 내의 관리되는 가용성 구성 요소에 통합되었으며 Exchange 내의 기본 기능입니다.It's now integrated into the managed availability components within the system and is a native function within Exchange.

  • DAG 네트워크 자동 구성: 시스템에서 구성 설정을 기반으로 DAG 네트워크를 자동으로 구성할 수 있습니다.DAG network auto-configuration: DAG networks can be automatically configured by the system based on configuration settings. 수동 구성 옵션 외에도 DAG가 자동으로 MAPI 네트워크와 복제 네트워크를 구분하고 DAG 네트워크를 구성할 수 있습니다.In addition to manual configuration options, DAGs can also distinguish between MAPI and replication networks and configure DAG networks automatically.

Exchange 2010에 비해 IOPS 감소Reduction in IOPS over Exchange 2010

Exchange 2010의 경우 수동 데이터베이스 복사본의 검사점 깊이가 매우 낮으며 이러한 검사점 깊이는 빠른 장애 조치(failover)를 위해 필요합니다. 또한 수동 복사본은 5MB의 검사점 깊이를 확보하기 위해 적극적인 데이터 미리 읽기를 수행합니다. 낮은 검사점 깊이를 사용하고 이러한 적극적 미리 읽기 작업을 수행한 결과, Exchange 2010에서는 수동 데이터베이스 복사본의 IOPS가 활성 복사본의 IOPS와 같았습니다.In Exchange 2010, passive database copies have a very low checkpoint depth, which is required for fast failover. In addition, the passive copy performs aggressive pre-reading of data to keep up with a 5-megabyte (MB) checkpoint depth. As a result of using a low checkpoint depth and performing these aggressive pre-read operations, IOPS for a passive database copy was equal to IOPS for an active copy in Exchange 2010.

Exchange 2013에서는 시스템이 수동 복사본에 대해 높은 검사점 깊이(100MB)를 사용하면서 빠른 장애 조치(failover)를 제공할 수 있습니다. 수동 복사본의 검사점 깊이가 100MB이므로 이전처럼 적극적이지 않도록 하향 조정되었습니다. Exchange 2013에서는 검사점 깊이가 늘어나고 적극적 미리 읽기가 하향 조정된 결과 수동 복사본의 IOPS가 활성 복사본 IOPS의 약 50%에 지나지 않습니다.In Exchange 2013, the system is able to provide fast failover while using a high checkpoint depth on the passive copy (100 MB). Because passive copies have 100-MB checkpoint depth, they've been de-tuned to no longer be so aggressive. As a result of increasing the checkpoint depth and de-tuning the aggressive pre-reads, IOPS for a passive copy is about 50 percent of the active copy IOPS in Exchange 2013.

수동 복사본의 검사점 깊이가 높아짐으로써 다른 사항도 변경되었습니다. Exchange 2010의 장애 조치(failover)에서는 데이터베이스가 수동 복사본에서 활성 복사본으로 변환될 때 데이터베이스 캐시가 플러시됩니다. Exchange 2013에서는 ESE 로깅이 다시 작성되었으므로 수동 복사본에서 활성 복사본으로의 변환을 통해 캐시가 유지됩니다. ESE는 캐시를 플러시할 필요가 없기 때문에 장애 조치(failover) 속도가 빠릅니다.Having a higher checkpoint depth on the passive copy also results in other changes. On failover in Exchange 2010, the database cache is flushed as the database is converted from a passive copy to an active copy. In Exchange 2013, ESE logging was rewritten so that the cache is persisted through the transition from passive to active. Because ESE doesn't need to flush the cache, you get fast failover.

그 밖의 변경 사항 중 하나는 BDM(백그라운드 데이터베이스 유지 관리) 프로세스에 대한 것입니다. 이제 BDM에서는 복사본 하나에 대해 초당 약 1~2MB를 처리합니다.One other change was made to the background database maintenance (BDM) process. BDM now processes around 1-2 MB per second per copy.

이러한 모든 변경 사항의 결과로 Exchange 2013의 IOPS는 Exchange 2010에 비해 훨씬 더 낮습니다.As a result of these changes, Exchange 2013 provides a significant reduction in IOPS over Exchange 2010.

관리되는 가용성Managed Availability

관리되는 가용성은 기본 제공 활성 모니터링과 Exchange 2013의 고가용성 플랫폼이 통합된 것입니다. 시스템에서는 관리되는 가용성을 통해 서비스 상태를 기준으로 데이터베이스의 장애 조치(failover) 시기를 결정할 수 있습니다. 관리되는 가용성은 Exchange 2013의 클라이언트 액세스 및 사서함 서버 역할에 배포되는 내부 인프라입니다. 관리되는 가용성에는 지속적으로 작업을 수행하는 세 가지 주요 비동기 구성 요소가 포함되어 있습니다. 첫 번째 구성 요소는 프로브 엔진으로, 서버에서 데이터를 측정하고 데이터를 수집합니다. 이러한 측정의 결과는 두 번째 구성 요소인 모니터로 전달됩니다. 모니터에는 수집된 데이터에서 정상적인 것으로 간주되는 상태를 기준으로 시스템에서 사용하는 모든 비즈니스 논리가 포함되어 있습니다. 패턴 인식 엔진과 마찬가지로, 모니터는 수집된 모든 측정 결과에서 다양한 패턴을 찾은 후 항목이 정상 상태인지를 결정합니다. 마지막으로 복구 작업을 담당하는 응답자 엔진이 있습니다. 무언가 비정상적인 상태인 경우 첫 번째로 수행하는 작업은 그 구성 요소의 복구를 시도하는 것입니다. 이 과정에는 여러 단계의 복구 작업이 포함될 수 있습니다. 예를 들어 첫 번째로는 응용 프로그램 풀을 다시 시작해 보고, 두 번째로 서비스를 다시 시작해 보고, 세 번째로 서버를 다시 시작해 본 다음, 더 이상 트래픽을 받아들이지 않도록 서버를 오프라인으로 전환할 수 있습니다. 복구 작업에 실패하면 문제가 이벤트 로그 알림을 통해 담당자에게 에스컬레이션됩니다.Managed Availability is the integration of built-in, active monitoring and the Exchange 2013 high availability platform. With Managed Availability, the system can make a determination on when to fail over a database based on service health. Managed Availability is an internal infrastructure that's deployed on the Client Access and Mailbox server roles in Exchange 2013. Managed Availability includes three main asynchronous components that are constantly doing work. The first component is the probe engine, which is 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 is the responder engine, which is responsible for recovery 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.

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

  • Exchange Health Manager 서비스 (msexchangehmhost.exe): 작업자 프로세스를 관리 하는 데 사용 되는 컨트롤러 프로세스입니다.Exchange Health Manager Service (MSExchangeHMHost.exe): This is a controller process that's 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 crashes, 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 that's responsible for performing the runtime tasks.

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

  • XML 구성 파일은 작업 프로세스를 시작하는 동안 작업 항목 정의를 초기화하는 데 사용됩니다.XML configuration files are used to initialize the work item definitions during startup of the worker process.

  • 레지스트리는 책갈피 같은 런타임 데이터를 저장하는 데 사용됩니다.The registry is used to store runtime data, such as bookmarks.

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

고가용성에 대한 자세한 내용은 관리되는 가용성 항목을 참조하세요.For more information about managed availability, see Managed Availability.

관리되는 저장소Managed Store

Exchange server 4.0에서 Exchange Server 2010까지 이전 버전의 Exchange Server는 모두 사서함 서버 역할에 대 한 정보 저장소 프로세스 (Store.exe)의 단일 인스턴스를 실행 하는 것이 지원 됩니다.All previous versions of Exchange Server, from Exchange Server 4.0 to Exchange Server 2010, have supported running a single instance of the Information Store process (Store.exe) on the Mailbox server role. 이 단일 저장소 인스턴스는 active, passive, 지연 된 및 recovery 서버의 모든 데이터베이스를 호스트 합니다.This single Store instance hosts all databases on the server: active, passive, lagged, and recovery. 이전 Exchange 아키텍처에서 사서함 서버에 호스트 되는 서로 다른 데이터베이스 간에 격리는 거의 없습니다.In the previous Exchange architectures, there is little, if any, isolation between the different databases hosted on a Mailbox server. 단일 사서함 데이터베이스에 문제가 있으면 다른 모든 데이터베이스에 부정적인 영향을 줄 수 있으며 사서함 손상으로 인해 발생 하는 충돌은 해당 서버에서 호스팅되는 데이터베이스의 모든 사용자에 대 한 서비스에 영향을 줄 수도 있습니다.An issue with a single mailbox database has the potential to negatively affect all other databases, and crashes resulting from a mailbox corruption can affect service for all users whose databases are hosted on that server.

이전 버전의 Exchange에서 단일 저장소 인스턴스를 사용 하는 경우에는 ESE (Extensible Storage Engine)가 8-12 프로세서 코어와 잘 확장 되지만 프로세서 간 통신 및 캐시 동기화 문제는 음수로 작동 하기 때문입니다. 분산.Another challenge with a single Store instance in previous versions of Exchange is that the Extensible Storage Engine (ESE) scales well to 8-12 processor cores, but beyond that, cross-processor communication and cache synchronization issues lead to negative scale. 사용할 수 있는 16 개 코어 시스템을 사용 하는 오늘날의 대규모 서버에서 제공 되는,이는 ESE에 대해 8-12 코어의 선호도를 관리 하 고 저장소 이외의 프로세스 (예: 보조자, Search Foundation)에 다른 코어를 사용 하는 것을 관리 하는 데 어려움이 있음을 의미 합니다. 관리 되는 가용성 등)Given today's much larger servers, with 16+ core systems available, this would mean impose the administrative challenge of managing the affinity of 8-12 cores for ESE and using the other cores for non-Store processes (for example, Assistants, Search Foundation, Managed Availability, etc.). 또한 이전 아키텍처는 스토어 프로세스에 대해 제한 된 범위를 사용 하 여 확장 됩니다.Moreover, the previous architecture restricted scale-up for the Store process.

Exchange Server 자체가 진화 되는 동안 Store.exe 프로세스가 크게 증가 되었지만 단일 프로세스에 따라 확장성이 제한 되며 단일 오류 지점을 나타냅니다.The Store.exe process has evolved considerably throughout the years as Exchange Server itself evolved, but as a single process, ultimately its scalability is limited, and it represents a single point of failure. 이러한 제한으로 인해 Exchange 2013에서 Store.exe가 손실 되 고 관리 되는 저장소로 대체 됩니다.Because of these limits, Store.exe is gone in Exchange 2013 and replaced by the Managed Store.

자세한 내용은 관리 되는 저장소를 참조 하세요.For more information, see Managed Store.

볼륨당 여러 개의 데이터베이스Multiple databases per volume

Exchange 2013에서 개선된 저장소 기능은 주로 JBOD(여러 디스크 모음) 구성을 위한 것이지만 지원되는 모든 저장소 구성에서 이 기능을 사용할 수 있습니다. 이러한 기능 중 하나는 여러 데이터베이스를 동일한 볼륨에서 호스트하는 기능입니다. 이 기능은 Exchange의 대용량 디스크 최적화와 관련이 있습니다. 이러한 최적화를 통해 대용량 디스크를 용량, IOPS 및 다시 시드 시간 측면에서 훨씬 더 효율적으로 사용할 수 있으며, JBOD 저장소 구성에서 실행하는 데 관련된 다음과 같은 여러 가지 과제를 처리할 수 있습니다.Although the storage improvements in Exchange 2013 are designed primarily for just a bunch of disks (JBOD) configurations, they're available for use by all supported storage configurations. One such feature is the ability to host multiple databases on the same volume. This feature is about Exchange optimizing for large disks. These optimizations result in a much more efficient use of large disks in terms of capacity, IOPS, and reseed times, and they're meant to address the challenges associated with running in a JBOD storage configuration:

  • 데이터베이스 크기는 관리가 용이해야 합니다.Database sizes must be manageable.

  • 다시 시드 작업은 빠르고 안정적이어야 합니다.Reseed operations must be fast and reliable.

  • 저장소 용량은 증가하고 있지만 IOPS는 그렇지 않습니다.Although storage capacity is increasing, IOPS aren't.

  • 수동 데이터베이스 복사본을 호스트하는 디스크는 IOPS 활용도가 떨어집니다.Disks hosting passive database copies are underutilized in terms of IOPS.

  • 지연된 복사본에는 비대칭적 저장소가 필요합니다.Lagged copies have asymmetric storage requirements.

  • 디스크 공간이 작을 때 복구 유연성이 제한적입니다.Limited agility exists to recover from low disk space conditions.

저장소 용량은 계속해서 증가하는 추세이며 조만간 8TB 드라이브가 상용화될 것으로 예상됩니다. Exchange 권장 사항인 최대 2TB의 데이터베이스 크기로 8TB 드라이브를 사용할 경우에는 5TB 이상의 디스크 공간이 낭비됩니다. 데이터베이스 크기를 증가시키면 간단히 이 문제를 해결할 수 있지만 다시 시드 시간이 길어 경우에 따라서는 다시 시드 시간을 작업으로 관리할 수 없는 등 관리 효율성이 떨어지는 단점이 있고, 네트워크를 통해 해당 양의 데이터를 복사하기 때문에 안정성 면에서도 불리합니다.The trend of increasing storage capacity is continuing, with 8-terabyte drives expected to be available soon. When using 8-terabyte drives in conjunction with the Exchange maximum database size best practices guidelines (2 terabytes), you would waste more than 5 terabytes of disk space. One solution would be to simply grow the databases larger, but that inhibits manageability because it introduces long reseed times, including in some cases, operationally unmanageable reseed times, and the reliability of copying that amount of data over the network is compromised.

또한 Exchange 2010 모델에서 수동 복사본을 저장하는 디스크는 IOPS 면에서 활용도가 낮습니다. 지연된 수동 복사본의 경우 IOPS 면에서 디스크의 활용도가 낮을 뿐 아니라, 활성 및 지연되지 않은 수동 복사본을 저장하는 데 사용되는 디스크와 비교할 때 크기 면에서 비대칭적입니다.In addition, in the Exchange 2010 model, the disk storing a passive copy is underutilized in terms of IOPS. In the case of a lagged passive copy, not only is the disk underutilized in terms of IOPS, but it's also asymmetric in terms of its size, relative to the disks used to store the active and non-lagged passive copies.

Exchange 2013은 Microsoft는 Exchange의 오랜 관행을 지속하면서 JBOD 구성에서 대용량 디스크(8TB)를 보다 효율적으로 사용할 수 있도록 최적화되었습니다. Exchange 2013에서는 디스크당 여러 데이터베이스가 지원되므로 동일한 크기의 디스크에 지연된 복사본을 포함하여 여러 데이터베이스 복사본을 저장할 수 있습니다. 이 기능의 목적은 기존의 여러 볼륨에 사용자를 분산할 수 있도록 하여 일반 작업 중에 각 DAG 구성원이 동일한 볼륨에서 활성 복사본, 수동 복사본 및 선택적인 지연된 복사본을 호스트하는 대칭적 디자인을 제공하는 것입니다.Continuing a long-standing practice, Exchange 2013 is optimized so that it can use large disks (8 terabytes) in a JBOD configuration more efficiently. In Exchange 2013, with multiple databases per disk, you can have the same size disks storing multiple database copies, including lagged copies. The goal is to drive the distribution of users across the number of volumes that exist, providing you with a symmetric design where during normal operations each DAG member hosts a combination of active, passive, and optional lagged copies on the same volumes.

아래 예에서는 볼륨당 여러 데이터베이스를 사용하는 구성을 보여 줍니다.An example of a configuration that uses multiple databases per volume is illustrated below.

볼륨당 여러 데이터베이스를 사용하는 구성Configuration that uses multiple databases per volume

![볼륨당 여러 데이터베이스] (images/Dn789066.c5e7d6c8-3e77-4f72-a873-5e9aaded9aa3(EXCHG.150).gif "볼륨당 여러 데이터베이스")Multiple databases per volume

위의 구성에서는 대칭적 디자인이 제공됩니다. 네 개의 서버가 모두 동일한 네 개의 데이터베이스를 사용하며 이러한 데이터베이스는 모두 각 서버의 단일 디스크에서 호스트됩니다. 중요한 점은 각 데이터베이스의 복사본 수가 디스크당 데이터베이스 복사본 수와 같아야 한다는 것입니다. 위의 예에서는 각 데이터베이스의 복사본이 네 개 있습니다. 하나는 활성 복사본이고, 두 개는 수동 복사본이며, 마지막 하나는 지연된 복사본입니다. 각 데이터베이스의 복사본이 네 개이므로 올바른 구성은 볼륨당 네 개의 복사본을 포함하는 구성입니다. 또한 활성화 기본 설정은 DAG와 각 서버 간에 균형을 이루도록 구성됩니다. 예를 들어, 활성 복사본의 활성화 기본 설정 값은 1이 되고, 첫 번째 수동 복사본과 두 번째 수동 복사본의 활성화 기본 설정 값은 각각 2와 3이 되며, 지연된 복사본의 활성화 기본 설정 값은 4가 됩니다.The above configuration provides a symmetrical design. All four servers have the same four databases all hosted on a single disk per server. The key is that the number of copies of each database that you have should be equal to the number of database copies per disk. In the above example, there are four copies of each database: one active copy, two passive copies, and one lagged copy. Because there are four copies of each database, the proper configuration is one that has four copies per volume. In addition, activation preference is configured so that it's balanced across the DAG and across each server. For example, the active copy will have an activation preference value of 1, the first passive copy will have an activation preference value of 2, the second passive copy will have an activation preference value of 3, and the lagged copy will have an activation preference value of 4.

기존 볼륨에 사용자를 보다 효율적으로 분산할 수 있다는 점 외에, 디스크당 여러 데이터베이스를 사용할 때의 또 다른 이점은 디스크 오류와 같이 다시 시드를 필요로 하는 오류가 발생할 경우 보호 데이터를 복원하는 데 소요되는 시간이 줄어든다는 점입니다.In addition to having a better distribution of users across the existing volumes, another benefit of using multiple databases per disk is that it reduces the amount of time to restore data protection in the event of a failure that necessitates a reseed (for example, disk failure).

데이터베이스 크기가 클수록 데이터베이스를 다시 시드하는 데 오래 걸립니다. 예를 들어, 2TB 데이터베이스를 다시 시드하는 데는 23시간이 소요되는 반면 8TB 데이터베이스를 다시 시드하는 데는 93시간(약 4일)이나 소요될 수 있습니다. 두 시드는 모두 초당 약 20MB로 발생합니다. 이는 일반적으로 초대형 데이터베이스를 작업상 합리적인 시간 내에 시드할 수 없음을 의미합니다.As a database gets bigger, reseeding the database takes longer. For example, a 2-terabyte database could take 23 hours to reseed, whereas an 8-terabyte database could take as long as 93 hours (almost 4 days). Both seeds would occur at about 20 MB per second. This generally means that a very large database can't be seeded within an operationally reasonable amount of time.

디스크당 단일 데이터베이스 복사본 시나리오의 경우에는 항상 단일 원본에서 디스크를 시드하므로 시드 작업이 사실상 원본의 제한을 받습니다. 볼륨을 여러 개의 데이터베이스 복사본으로 나누고 수동 데이터베이스의 활성 복사본을 별도의 DAG 구성원에 저장된 특정 볼륨에 두면 디스크를 다시 시드할 때 시스템이 더 이상 원본의 제한을 받지 않게 됩니다. 오류가 있는 디스크를 교체할 경우에는 디스크가 여러 원본에서 다시 시드될 수 있습니다. 따라서 시스템이 훨씬 더 짧은 시간으로 이러한 데이터베이스의 보호 데이터를 다시 시드하고 복원할 수 있습니다.In the case of a single database copy per disk scenario, the seeding operation is effectively source-bound, because it's always seeding the disk from a single source. By dividing the volume into multiple database copies, and by having the active copy of the passive databases on a specified volume stored on separate DAG members, the system is no longer source bound in the context of reseeding the disk. When a failed disk is replaced, it can be reseeded from multiple sources. This allows the system to reseed and restore data protection for these databases in a much shorter amount of time.

볼륨당 여러 데이터베이스를 사용할 경우 다음과 같은 모범 사례 및 요구 사항을 따르는 것이 좋습니다.When using multiple databases per volume, we recommend adhering to the following best practices and requirements:

  • 실제 디스크당 논리 디스크 파티션 하나를 사용해야 합니다. 디스크에 파티션을 여러 개 만들지 마세요. 각 데이터베이스 복사본과 해당 트랜잭션 로그, 콘텐츠 인덱스 등의 수반되는 파일은 단일 파티션의 고유 디렉터리에서 호스트되어야 합니다.A single logical disk partition per physical disk must be used. Don't create multiple partitions on the disk. Each database copy and its companion files (such as transaction logs and content index) should be hosted in a unique directory on the single partition.

  • 볼륨당 구성된 데이터베이스 복사본 수는 각 데이터베이스의 복사본 수와 같아야 합니다. 예를 들어, 데이터베이스 복사본이 네 개인 경우 볼륨당 네 개의 데이터베이스 복사본을 사용해야 합니다.The number of database copies configured per volume should be equal to the number of copies of each database. For example, if you have four copies of your databases, you should use four database copies per volume.

  • 데이터베이스 복사본은 동일한 환경을 가져야 합니다. 예를 들면, 데이터베이스 복사본은 모두 각 서버에서 동일한 디스크를 공유해야 합니다.Database copies should have the same neighbors. (For example, they should all share the same disk on each server.)

  • 특정 디스크의 각 데이터베이스 복사본이 고유한 활성화 기본 설정 값을 갖도록 DAG에서 활성화 기본 설정의 균형을 조정해야 합니다.Activation preference across the DAG should be balanced, such that each database copy on a specified disk has a unique activation preference value.

AutoReseedAutoReseed

AutoReseed는 일반적으로 데이터베이스 복사본을 다시 시드해야 하는 디스크 오류, 데이터베이스 손상 또는 그 밖의 문제가 발생할 경우 이에 대처하기 위해 관리자가 주도하는 작업을 대체하는 기능입니다. AutoReseed는 디스크 오류가 발생한 후 시스템에 프로비전된 예비용 디스크를 사용하여 데이터베이스 중복성을 자동으로 복원하기 위한 것입니다.Automatic reseed, or AutoReseed, is a feature that's the replacement for what is normally administrator-driven action in response to a disk failure, database corruption event, or other issue that necessitates a reseed of a database copy. AutoReseed is designed to automatically restore database redundancy after a disk failure by using spare disks that have been provisioned on the system.

자세한 내용은 AutoReseed을 참조하세요. 자세한 AutoReseed 구성 단계는 데이터베이스 가용성 그룹에 대 한 자동 다시 시드를 구성 합니다.을 참조하세요.For more information, see AutoReseed. For detailed steps to configure AutoReseed, see Configure AutoReseed for a database availability group.

저장소 오류 시 자동 복구Automatic recovery from storage failures

Exchange 2010에서 도입된 혁신적인 기능의 연속선상에 있는 저장소 오류 시 자동 복구 기능은 시스템이 복구 또는 중복성에 영향을 주는 오류로부터 복구될 수 있도록 합니다. Exchange 2010의 버그 확인 동작 외에도 Exchange 2013에는 I/O 시간이 길거나, Microsoft Exchange Replication Service(MSExchangeRepl.exe)의 메모리 소비량이 과도하거나, 스레드를 예약할 수 없는 심각한 경우를 위한 복구 동작이 추가로 포함되었습니다.Automatic recovery from storage failures continues the innovation introduced in Exchange 2010 to allow the system to recover from failures that affect resiliency or redundancy. In addition to the Exchange 2010 bugcheck behaviors, Exchange 2013 includes additional recovery behaviors for long I/O times, excessive memory consumption by the Microsoft Exchange Replication service (MSExchangeRepl.exe), and severe cases where threads can't be scheduled.

JBOD 환경에서도 저장소 배열 컨트롤러에 고장이나 중단 같은 문제가 발생할 수 있습니다. Exchange 2010에는 향상된 복구를 제공하는 중단 I/O 검색 및 복구 기능이 포함되어 있습니다. 다음 표에는 이러한 기능이 나열되어 있습니다.Even in JBOD environments, storage array controllers can have issues, such as crashing or hanging. Exchange 2010 included hung I/O detection and recovery features that provided enhanced resilience. These features are listed in the following table.

이름Name 수표Check 동작은Action 임계값Threshold

ESE 데이터베이스의 중단된 I/O 감지ESE Database Hung IO Detection

처리되지 않은 I/O에 대한 ESE 검사ESE checks for outstanding I/Os

크림슨 채널에 오류 항목을 생성하여 서버 다시 시작Generates a failure item in the crimson channel to restart the server

240초240 seconds

오류 항목 채널 하트비트Failure Item Channel Heartbeat

오류 항목을 Crimson 채널에 쓰고 Crimson 채널에서 읽을 수 있는지 확인Ensures failure items can be written to and read from crimson channel

Replication Service가 크림슨 채널을 하트비트하고 오류 시 서버 다시 시작Replication service heartbeats crimson channel and restart server on failures

30초30 seconds

시스템 디스크 하트비트System Disk Heartbeat

서버의 시스템 디스크 상태 확인Verifies server's system disk state

버퍼링되지 않은 I/O를 주기적으로 시스템 디스크에 전송하고 하트비트 시간이 초과되면 서버 다시 시작Periodically sends unbuffered I/O to system disk; restarts server on heartbeat time out

120초120 seconds

Exchange 2013에서는 다른 심각한 상태에 대한 동작이 새로 포함되어 서버 및 저장소 복구 기능이 향상되었습니다. 다음 표에서는 이러한 상태와 동작을 설명합니다.Exchange 2013 enhances server and storage resilience by including new behaviors for other serious conditions. These conditions and behaviors are described in the following table.

이름Name 수표Check 동작은Action 임계값Threshold

시스템 상태 불량System bad state

관리되지 않는 스레드를 포함한 어떤 스레드도 예약할 수 없음No threads, including non-managed threads, can be scheduled

서버 다시 시작Restart the server

302초302 seconds

긴 I/O 시간Long I/O times

I/O 작업 대기 시간 측정I/O operation latency measurements

서버 다시 시작Restart the server

41초41 seconds

Replication Service 메모리 사용Replication service memory use

MSExchangeRepl.exe의 작업 집합 측정Measure the working set of MSExchangeRepl.exe

  1. 크림슨 채널에 서비스 종료 요청과 함께 이벤트 4395 기록Log event 4395 in the crimson channel with a service termination request

  2. MSExchangeRepl.exe의 종료 시작Initiate termination of MSExchangeRepl.exe

  3. 서비스 종료에 실패할 경우 서버 다시 시작If service termination fails, restart the server

4GB4 gigabyte (GB)

시스템 이벤트 129(버스 재설정)System Event 129 (Bus reset)

시스템 이벤트 로그에서 이벤트 129 확인Check for Event 129 in System event log

서버 다시 시작Restart the server

이벤트가 발생할 경우When event occurs

클러스터 데이터베이스 중단Cluster database hang

글로벌 업데이트 관리자 업데이트가 차단됨Global Update Manager updates are blocked

서버 다시 시작Restart the server

이벤트가 발생할 경우When event occurs

지연된 복사본 기능 향상Lagged copy enhancements

지연된 복사본의 향상된 기능에는 보안 네트워크와의 통합과 특정 시나리오에서의 로그 파일 자동 재생이 있습니다. 보안 네트워크는 전송 휴지통이라고 하는 Exchange 2010의 기능을 대신하는 전송 기능입니다. 보안 네트워크는 사서함 서버의 전송 서비스와 연결된 배달 큐라는 점에서 전송 휴지통과 비슷합니다. 이 큐는 사서함 서버의 활성 사서함 데이터베이스에 배달된 메시지의 복사본을 저장합니다. 사서함 서버의 각 활성 사서함 데이터베이스마다 배달된 메시지의 복사본을 저장하는 고유한 큐가 있습니다. 보안 네트워크에 해당 복사본이 저장되는 기간을 지정할 수 있으며 이 기간이 지나면 해당 메시지 복사본은 만료되어 자동으로 삭제됩니다.Lagged copy enhancements include integration with Safety Net and automatic play down of log files in certain scenarios. Safety Net is a feature of transport that replaces the Exchange 2010 feature known as transport dumpster. Safety Net is similar to transport dumpster, in that it's a delivery queue that's associated with the Transport service on a Mailbox server. This queue stores copies of messages that were successfully delivered to the active mailbox database on the Mailbox server. Each active mailbox database on the Mailbox server has its own queue that stores copies of the delivered messages. You can specify how long Safety Net stores copies of the successfully delivered messages before they expire and are automatically deleted.

보안 네트워크는 DAG 환경의 섀도 중복성에서 일부 책임을 승계합니다. DAG 환경에서 섀도 중복성 기능은 배달된 메시지의 또 다른 복사본을 섀도 큐에 보관할 필요 없이 배달된 메시지가 DAG의 다른 사서함 서버에 있는 사서함 데이터베이스의 수동 복사본에 복제될 때까지 기다립니다. 배달된 메시지의 복사본은 이미 보안 네트워크에 저장되어 있으므로 필요한 경우 섀도 중복성 기능을 통해 메시지를 보안 네트워크에서 다시 배달할 수 있습니다.Safety Net takes some responsibility from shadow redundancy in DAG environments. In DAG environments, shadow redundancy doesn't need to keep another copy of the delivered message in a shadow queue while it waits for the delivered message to replicate to the passive copies of mailbox databases on the other Mailbox servers in the DAG. The copy of the delivered message is already stored in Safety Net, so shadow redundancy can redeliver the message from Safety Net if necessary.

보안 네트워크를 사용하면 지연된 데이터베이스 복사본을 활성화하기가 훨씬 쉬워집니다. 예를 들어, 재생 지연 시간이 2일인 지연된 복사본의 경우 2일의 기간에 대해 보안 네트워크도 구성하게 됩니다. 지연된 복사본을 사용해야 하는 상황이 발생할 경우 해당 복사본으로의 복제를 일시 중단하고 이를 두 번 복사하여 데이터베이스의 지연된 특성을 보존하고 필요한 경우 추가 복사본을 만들 수 있습니다. 그런 다음 복사본을 선택하고 필요한 범위의 로그 파일을 제외한 모든 로그 파일을 버립니다. 복사본을 탑재하면 최근 2일 동안의 메일을 다시 배달하라는 요청이 보안 네트워크에 자동으로 트리거됩니다. 보안 네트워크를 사용하면 손상이 시작된 지점을 찾을 필요가 없습니다. 손실 장애 조치(failover)에서 일반적으로 손실되는 데이터를 제외한 최근 2일 동안의 메일을 받습니다.With the introduction of Safety Net, activating a lagged database copy becomes significantly easier. For example, consider a lagged copy that has a 2-day replay lag. In that case, you would configure Safety Net for a period of 2 days. If you encounter a situation in which you need to use your lagged copy, you can suspend replication to it, and copy it twice (to preserve the lagged nature of the database and to create an extra copy in case you need it). Then, take a copy and discard all the log files, except for those in the required range. Mount the copy, which triggers an automatic request to Safety Net to redeliver the last two days of mail. With Safety Net, you don't need to hunt for where the point of corruption was introduced. You get the last two days mail, minus the data ordinarily lost on a lossy failover.

지연된 복사본은 이제 다음과 같은 특정 시나리오에서 자동 로그 재생을 호출하여 로그 파일을 재생함으로써 자동으로 복구될 수 있습니다.Lagged copies can now care for themselves by invoking automatic log replay to play down the log files in certain scenarios:

  • 디스크 공간 부족 임계값에 도달할 경우When a low disk space threshold is reached

  • 지연된 복사본에 물리적인 손상 부분이 있어 페이지를 패치해야 하는 경우When the lagged copy has physical corruption and needs to be page patched

  • 정상 상태의 사용 가능한 복사본(활성 또는 수동만 포함하며 지연된 데이터베이스 복사본은 계산에서 제외)이 24시간 이상 동안 3개 미만인 경우When there are fewer than three available healthy copies (active or passive only; lagged database copies are not counted) for more than 24 hours

Exchange 2010에서는 지연된 복사본에 페이지 패치를 사용할 수 없었습니다. Exchange 2013에서는 이 자동 재생 기능을 통해 지연된 복사본에 페이지 패치를 사용할 수 있습니다. 시스템이 지연된 복사본에 대한 페이지 패치가 필요하다고 감지하면 페이지 패치를 수행하기 위해 자동으로 로그가 지연된 복사본으로 재생됩니다. 지연된 복사본은 낮은 디스크 공간 임계값에 도달한 경우와 지연된 복사본이 특정 기간 동안 유일하게 사용할 수 있는 복사본으로 감지된 경우에도 이 자동 재생 기능을 호출합니다.In Exchange 2010, page patching wasn't available for lagged copies. In Exchange 2013, page patching is available for lagged copies through this automatic play down feature. If the system detects that page patching is required for a lagged copy, the logs are automatically replayed into the lagged copy to perform page patching. Lagged copies also invoke this auto replay feature when a low disk space threshold has been reached, and when the lagged copy has been detected as the only available copy for a specific period of time.

지연된 복사본 재생 동작은 기본적으로 사용하지 않도록 설정되어 있으며 다음 명령을 실행하면 이를 사용하도록 설정할 수 있습니다.Lagged copy play down behavior is disabled by default, and can be enabled by running the following command.

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

재생 동작을 사용하도록 설정한 후 복사본 수가 3개 미만이면 재생이 발생합니다. 다음 DWORD 레지스트리 값을 수정하면 기본값 3을 변경할 수 있습니다.After being enabled, play down occurs when there are fewer than three copies. You can change the default value of 3, by modifying the following DWORD registry value.

HKLM\Software\Microsoft\set-exchangeserver\v 15의\Replay\매개\변수 ReplayLagManagerNumAvailableCopiesHKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

디스크 공간 부족 임계값에 도달할 경우 재생을 사용하도록 설정하려면 다음 레지스트리 항목을 추가로 구성해야 합니다.To enable play down for low disk space thresholds, you must configure the following registry entry.

HKLM\Software\Microsoft\set-exchangeserver\v 15의\Replay\매개\변수 ReplayLagLowSpacePlaydownThresholdInMBHKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

이러한 레지스트리 설정을 구성한 후에 Microsoft Exchange DAG Management Service를 다시 시작하여 변경 내용을 적용합니다.After configuring either of these registry settings, restart the Microsoft Exchange DAG Management service for the changes to take effect.

예를 들어 지정 된 데이터베이스에 4 개의 복사본 (고가용성 복사본 및 1 지연 된 복사본)이 있고 기본 설정이 ReplayLagManagerNumAvailableCopies에 사용 되는 환경을 가정해 봅니다.As an example, consider an environment where a given database has 4 copies (3 highly available copies and 1 lagged copy), and the default setting is used for ReplayLagManagerNumAvailableCopies. 지연되지 않은 복사본이 어떤 이유(예: 일시 중단 등)로 인해 작동되지 않으면 지연된 복사본이 24시간 후에 자동으로 로그 파일을 재생합니다.If a non-lagged copy is out-of-service for any reason (for example, it is suspended, etc.) then the lagged copy will automatically play down its log files in 24 hours.

단일 복사본 경고 기능 향상Single copy alert enhancements

서버가 안정적으로 작동 중인지, 사서함 데이터베이스 복사본이 정상적인 상태인지 확인하는 것은 일상적인 Exchange 2013 메시징 작업의 기본 목표입니다. 하드웨어, Windows 운영 체제 및 Exchange 서비스도 활발히 모니터링해야 합니다. 그러나 Exchange 2013 사서함 복구 환경에서 실행할 때는 DAG와 사서함 데이터베이스 복사본의 상태를 모니터링하는 것이 중요합니다. 특히 데이터 중복성 위험 관리 작업을 수행하고 복제된 데이터베이스가 단일 복사본으로만 존재하는 기간을 모니터링하는 것은 매우 중요합니다. 이는 RAID(Redundant Array of Independent Disks)를 사용하지 않는 대신 JOBD 구성을 배포하는 환경에서 특히 중요합니다. RAID 환경에서는 단일 디스크 오류가 활성 사서함 데이터베이스 복사본에 영향을 주지 않습니다. 그러나 JBOD 환경에서는 단일 디스크 오류로 인해 데이터베이스 장애 조치(failover)가 트리거됩니다.Ensuring that your servers are operating reliably and that your mailbox database copies are healthy are primary objectives of daily Exchange 2013 messaging operations. You must actively monitor the hardware, the Windows operating system, and the Exchange services. But when running in an Exchange 2013 mailbox resiliency environment, it's important that you monitor the health and status of the DAG and your mailbox database copies. It's especially vital to perform data redundancy risk management and monitor for periods in which a replicated database is down to just a single copy. This is particularly critical in environments that don't use Redundant Array of Independent Disks (RAID) and instead deploy JBOD configurations. In a RAID environment, a single disk failure doesn't affect an active mailbox database copy. However, in a JBOD environment, a single disk failure will trigger a database failover.

Exchange 2010에서는 CheckDatabaseRedundancy.ps1 스크립트를 도입했습니다. 이름에서 알 수 있듯이, 이 스크립트의 용도는 정상적인 최신 복사본이 두 개 이상 구성되어 있는지 확인하여 복제된 사서함 데이터베이스의 중복성을 모니터링하고, 복제된 데이터베이스의 정상적인 복사본이 하나만 있을 경우 이벤트 로그를 생성하여 관리자에게 경고하는 것입니다. 이런 경우, 중복성을 확인할 때 활성 및 수동 복사본 모두가 합산됩니다.In Exchange 2010, the script CheckDatabaseRedundancy.ps1 was introduced. As its name implies, the purpose of the script was to monitor the redundancy of replicated mailbox databases by validating that there is at least two configured, healthy, and current copies, and to alert an administrator through event log generation when only a single healthy copy of a replicated database exists. In this case, both active and passive copies are counted when determining redundancy.

복사본이 하나만 존재하게 되는 경우의 예는 다음과 같습니다.Single copy conditions include, but aren't limited to:

  • 활성 복사본을 수동 복사본에 복제하지 못했습니다.Failure of an active copy to replicate to any passive copy.

  • 모든 수동 복사본에 오류가 있습니다. 여기에는 FailedAndSuspended 및 Failed 상태뿐 아니라 정상 상태지만 복사본의 로그 복사 또는 재생이 늦은 경우도 포함됩니다. 지연된 복사본의 로그 재생이 지연 기간에 대해 10분 이내 범위에서 이루어지는 경우에는 지연된 복사본이 늦은 것으로 간주되지 않습니다.Failure of all passive copies, which includes FailedAndSuspended and Failed states in addition to healthy states where the copy is behind in log copying or replay. Note that lagged copies aren't considered behind if they're within ten minutes in replaying their logs to their lag period.

  • 시스템에서 활성 복사본의 최신 로그 생성을 정확히 알지 못합니다.Failure of the system to accurately know the current log generation of the active copy.

관리자는 최우선적으로 정상 상태의 데이터베이스 복사본이 하나만 존재하는 시기를 알아야 하므로 CheckDatabaseRedundancy.ps1 스크립트는 관리되는 가용성 DataProtection 상태 집합의 일부인 통합된 기본 기능으로 대체되었습니다.Because it's a top priority for administrators to know when they're down to a single healthy copy of a database, the CheckDatabaseRedundancy.ps1 script has been replaced with integrated, native functionality that's part of managed availability's DataProtection Health Set.

기본 기능은 여전히 이벤트 로그 알림을 통해 관리자에 게 경고 하 고 exchange 2013 알림을 Exchange 2010와 구별 하기 위해 exchange 2013은 다음과 같은 이벤트 Id를 사용 합니다.The native functionality still alerts administrators through event log notifications, and to distinguish Exchange 2013 alerts from Exchange 2010, Exchange 2013 uses the following Event IDs:

  • 이벤트 4138(빨간색 경고)Event 4138 (Red Alert)

  • 이벤트 4139(녹색 경고)Event 4139 (Green Alert)

Exchange 2013에서는 동일한 서버의 여러 데이터베이스가 단일 복사본 상태가 될 때 발생할 수 있는 경고 노이즈의 수준을 낮추도록 기본 기능이 향상되었습니다. Exchange 2010에서는 단일 복사본 경고가 데이터베이스 수준에서 생성되었습니다. 따라서 여러 데이터베이스와 여러 데이터베이스 복사본에 영향을 주는 서버 차원의 문제가 발생할 경우에는 경고 폭풍이 발생할 수 있었습니다. 컨트롤러 또는 메모리 문제 등 몇몇 오류는 서버 쪽에서 발생하므로 그러한 경고 폭풍이 서버 인시던트마다 발생할 가능성이 높았습니다. Exchange 2013에서는 이제 경고가 서버 단위로 생성됩니다. 서버 중단으로 인해 전체 서버가 영향을 받고 여러 데이터베이스 복사본에 대한 데이터 중복성에 위험이 생길 경우 이제는 서버별로 단일 경고가 생성됩니다.In Exchange 2013, the native functionality has been enhanced to reduce the level of alert noise that can occur when multiple databases on the same server enter into a single copy condition. In Exchange 2010, single copy alerts were generated on a per-database level. As a result, when there was a server-wide issue that affected multiple databases and multiple database copies, alert storms could occur. Because several failures, such as controller or memory problems, are server-wide, there was a moderately high probability that such an alert storm would occur for each server incident. In Exchange 2013, alerts are now generated on a per-server basis. When an outage affects an entire server and data redundancy becomes at risk for multiple database copies, a single alert per server is now generated.

DAG 네트워크 자동 구성DAG network auto-configuration

DAG 네트워크는 복제 트래픽 또는 MAPI 트래픽용으로 사용되는 하나 이상의 서브넷 모음입니다. 각 DAG는 최대 한 개의 MAPI 네트워크와 0개 이상의 복제 네트워크를 포함합니다. Exchange 2010에서 시스템이 만드는 초기 DAG 네트워크(예: DAGNetwork01 및 DAGNetwork02)는 클러스터 서비스에서 열거한 서브넷을 기반으로 했습니다. 여러 네트워크가 사용되며 특정 네트워크(예: MAPI 네트워크)의 여러 인터페이스가 동일한 서브넷에 있는 환경에서는 관리자가 수행해야 하는 추가 구성이 매우 드물었습니다. 그러나 특정 네트워크의 인터페이스가 여러 서브넷에 있는 환경에서는 관리자가 DAG 네트워크 축소라는 작업을 수행해야 했습니다.A DAG network is a collection of one or more subnets used for either replication traffic or MAPI traffic. Each DAG contains a maximum of one MAPI network and zero or more replication networks. In Exchange 2010, the initial DAG networks (for example, DAGNetwork01 and DAGNetwork02) were created by the system based on the subnets enumerated by the Cluster service. In environments where multiple networks are used and the interfaces for a specified network (for example, the MAPI network) were on the same subnet, there was little additional configuration that an administrator needed to perform. However, in environments where the interfaces for a specified network were on multiple subnets, the administrator had to perform a task referred to as collapsing DAG networks.

Exchange 2013에서는 DAG 네트워크 축소가 더 이상 필요하지 않습니다. Exchange 2013에서도 동일한 검색 메커니즘을 사용하여 MAPI 네트워크와 복제 네트워크를 구별하지만 이제 DAG 네트워크 축소는 적절하게 자동으로 수행됩니다.In Exchange 2013, collapsing DAG networks is no longer necessary. Exchange 2013 still uses the same detection mechanisms to distinguish between the MAPI and replication networks, but it now automatically collapses DAG networks as appropriate.

또한 DAG 네트워크는 기본적으로 시스템에서 자동으로 관리됩니다.In addition, by default, DAG networks are now automatically managed by the system. EAC (Exchange 관리 센터)를 사용 하 여 DAG 네트워크 속성을 보려면 EAC를 사용 하 여 DAG의 속성을 수정 하거나, Set DatabaseAvailabilityGroup cmdlet을 사용 하 여 DAG를 설정 하 여 수동 네트워크 제어를 구성 해야 합니다. ManualDagNetworkConfiguration 매개 변수 True를로To view DAG network properties using the Exchange admin center (EAC), you must configure the DAG for manual network control by modifying the properties of the DAG using EAC, or by using the Set-DatabaseAvailabilityGroup cmdlet to set the ManualDagNetworkConfiguration parameter to True.

최상의 복사본 선택을 위한 변경 사항Changes to best copy selection

BCS(최상의 복사본 선택)는 활성화할 수 있는 복사본과 해당 복사본의 상태가 목록으로 나열될 경우 개별 데이터베이스의 복사본 중 활성화할 최상의 복사본을 찾기 위한 내부 알고리즘 프로세스입니다. Active Manager는 기존 활성 데이터베이스 복사본이 실패하거나 관리자가 대상 없는 전환을 수행할 때 사용이 가능하고 차단되지 않은 최적의 복사본을 새 활성 데이터베이스 복사본으로 선택합니다. Exchange 2010에서는 BCS 프로세스가 각 데이터베이스 복사본의 여러 가지 요소를 평가하여 활성화하기에 최적의 복사본을 확인했습니다. 이러한 요소는 다음과 같습니다.Best copy selection (BCS) is an internal algorithm process for finding the best copy of an individual database to activate, given a list of potential copies for activation and their health and status. Active Manager selects the best available (and unblocked) copy to become the new active database copy when the existing active database copy fails or when an administrator performs a targetless switchover. In Exchange 2010, the BCS process evaluated several aspects of each database copy to determine the best copy to activate. These included:

  • 복사 큐 길이Copy queue length

  • 재생 큐 길이Replay queue length

  • 데이터베이스 상태Database status

  • 콘텐츠 인덱스 상태Content index status

Exchange 2013에서 Active Manager는 동일한 BCS 검사 및 단계를 수행하여 복제 상태를 확인하지만 내림차순 상태 제약 조건도 사용한다는 차이점이 있습니다. 이러한 변경의 결과로 BCS를 이제는 BCSS(최상의 복사 및 서버 선택)라고 합니다.In Exchange 2013, Active Manager performs the same BCS checks and phases to determine replication health, but it now also includes the use of a constraint of the decreasing order of health states. As a result of these changes, BCS is now called best copy and server selection (BCSS).

Exchange 2013의 경우 기본 제공 관리되는 가용성 모니터링 구성 요소의 일부인 몇 가지 새로운 상태 검사 기능이 BCSS에 포함되어 있습니다. Active Manager가 새로 수행하는 추가 확인은 네 가지이며 수행되는 순서대로 아래에 나열되어 있습니다.BCSS includes several new health checks that are part of the built in managed availability monitoring components in Exchange 2013. There are four new additional checks performed by Active Manager (listed in the order in which they're performed):

  1. 모두 정상: 모든 모니터링 구성 요소가 정상 상태인 영향을 받은 데이터베이스의 복사본을 호스트 하는 서버를 확인 합니다.All Healthy: Checks for a server hosting a copy of the affected database that has all monitoring components in a healthy state.

  2. **** 정상 정상 상태: 보통 우선 순위의 모든 모니터링 구성 요소가 정상 상태인 영향을 받은 데이터베이스의 복사본을 호스팅하는 서버가 있는지 확인 합니다.Up to Normal Healthy: Checks for a server hosting a copy of the affected database that has all monitoring components with Normal priority in a healthy state.

  3. 원본 보다 더 적합: 모니터링 구성 요소가 포함 된 영향을 받는 데이터베이스의 복사본을 호스트 하는 서버가 영향을 받은 복사본을 호스트 하는 현재 서버 보다 더 나은 상태에 있는지 확인 합니다.All Better than Source: Checks for a server hosting a copy of the affected database that has monitoring components in a state that's better than the current server hosting the affected copy.

  4. 원본과 동일: 모니터링 구성 요소가 영향을 받은 복사본을 호스트 하는 현재 서버와 동일한 상태에 있는 영향을 받는 데이터베이스의 복사본을 호스트 하는 서버를 확인 합니다.Same as Source: Checks for a server hosting a copy of the affected database that has monitoring components in a state that's the same as the current server hosting the affected copy.

BCSS는 예를 들면, 장애 조치(failover) 응답자를 통해 관리되는 가용성 모니터링 구성 요소가 트리거하는 장애 조치(failover)의 결과로 호출되며, 대상 서버의 구성 요소 상태가 장애 조치(failover)가 발생한 서버보다 양호해야 한다는 필수 제약 조건이 추가로 적용됩니다.If BCSS is invoked as a result of a failover that's triggered by a managed availability monitoring component (for example, via a Failover responder), an additional mandatory constraint is enforced where the target server's component health must be better than the server on which the failover occurred. 예를 들어 Outlook Web App의 장애가 장애 조치 응답자를 통해 관리 되는 가용성 장애 조치 (failover)를 트리거하는 경우 BCSS는 Outlook Web App이 정상 상태인 영향을 받은 데이터베이스의 복사본을 호스트 하는 서버를 선택 해야 합니다.For example, if a failure of Outlook Web App triggers a managed availability failover via a Failover responder, BCSS must select a server hosting a copy of the affected database on which Outlook Web App is healthy.

DAG Management ServiceDAG Management Service

Exchange 2013의 RTM(Release To Manufacturing) 버전용 CU2(누적 업데이트 2)에는 DAG의 구성원인 사서함 서버에 대한 새로운 서비스가 포함되어 있습니다. 이 서비스를 Microsoft Exchange DAG Management Service(MSExchangeDAGMgmt)라고 합니다. 이 새로운 서비스에는 이전에 Microsoft Exchange Replication Service(MSExchangeRepl) 내부에서 실행되었던 내부 DAG 모니터링 기능이 포함되어 있습니다.Cumulative Update 2 (CU2) for the Release to Manufacturing (RTM) version of Exchange 2013 contains a new service on Mailbox servers that are members of a DAG. This service is called the Microsoft Exchange DAG Management Service (MSExchangeDAGMgmt). This new service contains internal DAG monitoring functionality that previously executed inside the Microsoft Exchange Replication service (MSExchangeRepl).

클러스터 관리 액세스 포인트가 없는 DAGDAGs without a cluster administrative access point

Windows Server 2008 R2 또는 Windows Server 2012를 실행하는 모든 DAG에는 MAPI 네트워크에 포함된 모든 서브넷의 IP 주소가 하나 이상 필요합니다. DAG에 할당된 IP 주소는 클러스터 관리 액세스 포인트(클러스터 네트워크 이름이라고도 함)가 포함된 DAG 클러스터로 이름 확인 및 클러스터 이름을 사용한 클러스터 연결(구체적으로는 현재 클러스터 핵심 리소스 그룹을 소유한 클러스터 구성원에 연결)을 사용하도록 설정하는 데 사용됩니다. Windows Server 2012 R2에서는 관리 액세스 포인트가 없는 장애 조치(failover) 클러스터를 만들 수 있습니다. 관리 액세스 포인트가 없는 Windows 장애 조치(failover) 클러스터의 특징은 다음과 같습니다.All DAGs running Windows Server 2008 R2 or Windows Server 2012 require at least one IP address on every subnet included in the MAPI network. The IP address(es) assigned to the DAG are used by the DAG's cluster with the cluster's administrative access point (also known as the cluster network name) to enable name resolution and connectivity to the cluster (or more precisely, connectivity to the cluster member that currently owns the cluster core resource group) using the cluster name. Windows Server 2012 R2 enables you to create a failover cluster without an administrative access point. Windows failover clusters without administrative access points have the following characteristics:

  • 클러스터에 IP 주소가 할당되지 않으므로 클러스터 핵심 리소스 그룹에 IP 주소 리소스가 없습니다.There is no IP address assigned to the cluster, and therefore no IP Address Resource in the cluster core resource group.

  • 클러스터에 네트워크 이름이 할당되지 않으므로 클러스터 핵심 리소스 그룹에 네트워크 이름 리소스가 없습니다.There is no network name assigned to the cluster, and therefore no Network Name Resource in the cluster core resource group

  • 클러스터의 이름이 DNS에 등록되지 않으며 네트워크에서 확인할 수 없습니다.The name of the cluster is not registered in DNS, and it is not resolvable on the network.

  • CNO(클러스터 이름 개체)가 Active Directory에서 만들어지지 않습니다.A cluster name object (CNO) is not created in Active Directory.

  • Windows 장애 조치(failover) 클러스터는 장애 조치(failover) 클러스터 관리 도구를 사용하여 관리할 수 없습니다. 클러스터는 Windows PowerShell을 사용하여 관리해야 하며 개별 클러스터 구성원에 대해 PowerShell cmdlet을 실행해야 합니다.The Windows failover cluster cannot be managed using the Failover Cluster Management tool. It must be managed using Windows PowerShell, and the PowerShell cmdlets must be run against individual cluster members.

Windows Server 2012 R2 이상에서 실행하는 경우에는 Exchange 2013 SP1(서비스 팩 1) 이상을 설치하면 클러스터 관리 액세스 포인트가 없는 DAG를 만들 수 있습니다.When running on Windows Server 2012 R2 or later, Service Pack 1 (SP1) for Exchange 2013 and later enable you to create a DAG without a cluster administrative access point. Exchange 관리 센터를 사용 하거나 셸을 사용 하 여 관리 액세스 포인트가 없는 DAG를 만들 수 있습니다.You can create a DAG without an administrative access point using the Exchange admin center or by using the Shell. 자세한 내용은 Dag 만들기데이터베이스 사용 가능 그룹 만들기를 참조 하십시오.For more information, see Creating DAGs and Create a database availability group.