고가용성 및 사이트 복구High availability and site resilience

적용 대상: Exchange Server 2013Applies to: Exchange Server 2013

사서함 서버 및 데이터베이스를 고가용성과 사이트 복구를 위해 구성하여 Exchange Server 2013 사서함 데이터베이스 및 포함된 데이터를 보호할 수 있습니다. Exchange 2013은 높은 수준의 서비스 및 데이터 가용성과 대용량 사서함 지원을 제공하면서 가용성이 뛰어난 복구 가능 메시징 솔루션을 배포할 때 수반되는 비용과 복잡성을 최소화합니다.You can protect your Exchange Server 2013 mailbox databases and the data they contain by configuring your Mailbox servers and databases for high availability and site resilience. Exchange 2013 minimizes the cost and complexity of deploying a highly available and resilient messaging solution while providing high levels of service and data availability and support for very large mailboxes.

Exchange 2013에서는 규모나 업종에 관계없이 모든 고객이 Exchange 2010에 포함된 기본 복제 기능 및 고가용성 아키텍처를 기반으로 하여 조직의 메시징 연속성 서비스를 경제적으로 배포할 수 있습니다. Exchange 2010 및 Exchange 2007에서 달라진 변경 내용 목록은 이전 버전에 비해 달라진 고가용성 및 사이트 복구 기능를 참조하세요.Exchange 2013 enables customers of all sizes and in all segments to economically deploy a messaging continuity service in their organization by building on the native replication capabilities and high availability architecture introduced in Exchange 2010. For a list of changes over Exchange 2010 and Exchange 2007, see Changes to high availability and site resilience over previous versions.

주요 용어Key terminology

고가용성 또는 사이트 복구 기능을 이해하려면 다음의 주요 용어를 알고 있어야 합니다.The following key terms are important to understand high availability or site resilience:

  • Active Manager: DAG (데이터베이스 사용 가능 그룹) 내에서 장애 조치 (failover)를 통한 오류 모니터링 및 정정 작업을 담당 하는 Microsoft exchange 복제 서비스 내에서 실행 되는 내부 Exchange 구성 요소입니다.Active Manager: An internal Exchange component which runs inside the Microsoft Exchange Replication service that's responsible for failure monitoring and corrective action through failover within a database availability group (DAG).

  • AutoDatabaseMountDial: 탑재 중인 복사본에서 누락 된 로그 파일 수에 따라 수동 데이터베이스 복사본이 새 활성 복사본으로 자동 탑재 될 지 여부를 결정 하는 사서함 서버의 속성 설정입니다.AutoDatabaseMountDial: A property setting of a Mailbox server that determines whether a passive database copy will automatically mount as the new active copy, based on the number of log files missing by the copy being mounted.

  • 연속 복제 차단 모드: 블록 모드에서 각 업데이트가 활성 데이터베이스 복사본의 활성 로그 버퍼에 기록 됨에 따라 블록 모드의 각 수동 사서함 복사본에 대 한 로그 버퍼에도 제공 됩니다.Continuous replication - block mode: In block mode, as each update is written to the active database copy's active log buffer, it's also shipped to a log buffer on each of the passive mailbox copies in block mode. 로그 버퍼가 꽉 차면 각 데이터베이스 복사본이 다음 로그 파일을 작성 및 검사하며 생성 시퀀스에 만듭니다.When the log buffer is full, each database copy builds, inspects, and creates the next log file in the generation sequence.

  • 연속 복제-파일모드: 파일 모드에서 닫힌 트랜잭션 로그 파일은 활성 데이터베이스 복사본에서 하나 이상의 수동 데이터베이스 복사본으로 푸시됩니다.Continuous replication - file mode: In file mode, closed transaction log files are pushed from the active database copy to one or more passive database copies.

  • 데이터베이스 사용 가능 그룹: 복제 된 데이터베이스 집합을 호스트 하는 최대 16 개 Exchange 2013 사서함 서버의 그룹입니다.Database availability group: A group of up to 16 Exchange 2013 Mailbox servers that hosts a set of replicated databases.

  • 데이터베이스 이동성: exchange 2013 사서함 데이터베이스를 다른 Exchange 2013 사서함 서버에 복제 및 탑재 하는 기능입니다.Database mobility: The ability of an Exchange 2013 mailbox database to be replicated to and mounted on other Exchange 2013 Mailbox servers.

  • 데이터 센터: 일반적으로 Active Directory 사이트를 나타냅니다. 그러나 실제 사이트를 참조할 수도 있습니다.Datacenter: Typically this refers to an Active Directory site; however, it can also refer to a physical site. 이 설명서의 문맥에서 데이터 센터는 Active Directory 사이트와 같은 의미입니다.In the context of this documentation, datacenter equals Active Directory site.

  • 데이터 센터 활성화 조정 모드: DAG 설정의 속성으로,이 옵션을 사용 하면 Microsoft Exchange 복제 서비스가 시작 시에 데이터베이스를 탑재 하기 위한 권한을 얻도록 합니다.Datacenter Activation Coordination mode: A property of the DAG setting that, when enabled, forces the Microsoft Exchange Replication service to acquire permission to mount databases at startup.

  • 재해 복구: 수동으로 오류를 복구 하는 데 사용 되는 모든 프로세스입니다.Disaster recovery: Any process used to manually recover from a failure. 단일 항목에 영향을 주는 오류 또는 전체 물리적 위치에 영향을 주는 오류일 수 있습니다.This can be a failure that affects a single item, or it can be a failure that affects an entire physical location.

  • Exchange 타사 복제 api: 연속 복제 대신 타사 동기 복제를 DAG에 사용할 수 있도록 하는 EXCHANGE 제공 API입니다.Exchange third-party replication API: An Exchange-provided API that enables use of third-party synchronous replication for a DAG instead of continuous replication.

  • 고가용성: 서비스 가용성, 데이터 가용성 및 서비스나 데이터에 영향을 주는 오류 (예: 네트워크, 저장소 또는 서버 오류) 로부터의 자동 복구를 제공 하는 솔루션입니다.High availability: A solution that provides service availability, data availability, and automatic recovery from failures that affect the service or data (such as a network, storage, or server failure).

  • 증분 배포: Exchange 2013이 설치 된 후 고가용성 및 사이트 복구를 배포 하는 기능입니다.Incremental deployment: The ability to deploy high availability and site resilience after Exchange 2013 is installed.

  • 지연 된 사서함 데이터베이스 복사본: 로그 재생 지연 시간이 0 보다 큰 수동 사서함 데이터베이스 복사본입니다.Lagged mailbox database copy: A passive mailbox database copy that has a log replay lag time greater than zero.

  • 사서함 데이터베이스 복사본: 활성 또는 수동 인 사서함 데이터베이스 (.edb 파일 및 로그)입니다.Mailbox database copy: A mailbox database (.edb file and logs), which is either active or passive.

  • 사서함 복구: Exchange 2013에서 통합 된 고가용성 및 사이트 복구 솔루션의 이름입니다.Mailbox resiliency: The name of a unified high availability and site resilience solution in Exchange 2013.

  • 관리 되는 가용성: 모든 서버 역할과 모든 프로토콜에 걸쳐 모니터링과 고가용성을 통합 하는 프로브, 모니터 및 응답자를 구성 하는 내부 프로세스 집합입니다.Managed availability: A set of internal processes made up of probes, monitors, and responders that incorporate monitoring and high availability across all server roles and all protocols.

  • ** *over** ("별모양 초과"로 발음): 전환장애 조치 (failover)를 위해 짧게*over (pronounced "star over"): Short for switchovers and failovers. 전환은 하나 이상의 데이터베이스 복사본에 대한 수동 활성화입니다.A switchover is a manual activation of one or more database copies. 장애 조치는 오류 후 하나 이상의 데이터베이스 복사본에 대한 자동 활성화입니다.A failover is an automatic activation of one or more database copies after a failure.

  • 보안 네트워크: 이전에 전송 휴지통 알려진이 기능은 X 일 동안 모든 메시지의 복사본을 저장 하는 전송 서비스의 기능입니다.Safety Net: Formerly known as transport dumpster, this is a feature of the transport service that stores a copy of all messages for X days. 기본 설정은 2일입니다.The default setting is 2 days.

  • 섀도 중복성: 메시지가 전송 되는 동안 전체 시간 동안 메시지에 대 한 중복성을 제공 하는 전송 서버 기능입니다.Shadow redundancy: A transport server feature that provides redundancy for messages for the entire time they're in transit.

  • 사이트 복구: 메시징 인프라를 여러 Active Directory 사이트로 확장 하 여 사이트 중 하나에 영향을 주는 오류가 발생 하는 경우 메시징 시스템에 대 한 작업 연속성을 제공 하는 구성입니다.Site resilience: A configuration that extends the messaging infrastructure to multiple Active Directory sites to provide operational continuity for the messaging system in the event of a failure affecting one of the sites.

데이터베이스 가용성 그룹Database availability groups

DAG는 Exchange 2013에서 기본 제공되는 고가용성 및 사이트 복구의 기본 구성 요소입니다.A DAG is the base component of the high availability and site resilience framework built into Exchange 2013. DAG는 데이터베이스 집합을 호스트하는 최대 16개의 사서함 서버를 포함하는 그룹으로, 개별 데이터베이스, 네트워크 또는 서버에 영향을 주는 오류가 발생할 경우 데이터베이스 수준에서 자동으로 복구할 수 있도록 합니다.A DAG is a group of up to 16 Mailbox servers that host a set of databases and provides automatic, database-level recovery from failures that affect individual databases, networks, or servers. DAG의 서버는 DAG의 다른 서버로부터 사서함 데이터베이스의 복사본을 호스트할 수 있습니다.Any server in a DAG can host a copy of a mailbox database from any other server in the DAG. 서버를 DAG에 추가하면 DAG의 다른 서버와 함께, 사서함 데이터베이스에 영향을 준 오류(예: 디스크 오류 또는 서버 오류)로부터 자동 복구를 수행합니다.When a server is added to a DAG, it works with the other servers in the DAG to provide automatic recovery from failures that affect mailbox databases, such as a disk failure or server failure. Dag에 대 한 자세한 내용은 Database availability groups (dag)을 참조 하십시오.For more information about DAGs, see Database availability groups (DAGs).

사서함 데이터베이스 복사본Mailbox database copies

Exchange 2010에서 처음 도입된 고가용성 및 사이트 복구 기능이 Exchange 2013에서는 데이터베이스 복사본을 만들고 유지 관리하는 데도 사용됩니다. Exchange 2013에서는 데이터베이스 이동성의 개념, 즉 Exchange에서 관리되는 데이터베이스 수준의 장애 조치(failover) 기능도 활용합니다.The high availability and site resilience features used first introduced in Exchange 2010 are used in Exchange 2013 to create and maintain database copies. Exchange 2013 also leverages the concept of database mobility, which is Exchange-managed database-level failovers.

데이터베이스 이동성은 서버에서 데이터베이스의 연결을 끊고 단일 데이터베이스의 최대 16개 복사본에 대한 지원을 추가합니다. 또한 데이터베이스의 복사본을 만들기 위한 기본 환경을 제공합니다.Database mobility disconnects databases from servers and adds support for up to 16 copies of a single database. It also provides a native experience for creating copies of a database.

데이터베이스 복사본을 활성 사서함 데이터베이스로 설정하는 것을 전환이라고 합니다.Setting a database copy as the active mailbox database is known as a switchover. 데이터베이스 또는 데이터베이스 액세스에 영향을 주는 오류가 발생하여 새 데이터베이스가 활성 복사본이 되는 프로세스를 장애 조치(failover) 라고 합니다.When a failure affecting a database or access to a database occurs and a new database becomes the active copy, this process is known as a failover. 또한 이 프로세스는 실패한 서버에서 이전에 온라인 상태였던 데이터베이스를 하나 이상의 서버에서 온라인 상태로 만드는 서버 오류라고도 합니다.This process also refers to a server failure in which one or more servers bring online the databases previously online on the failed server. 전환 또는 장애 조치(failover)가 발생할 경우 다른 Exchange 2013 서버는 전환을 거의 즉시 인식하고 클라이언트 및 메시징 트래픽을 새 활성 데이터베이스로 리디렉션합니다.When either a switchover or failover occurs, other Exchange 2013 servers become aware of the switchover almost immediately and redirect client and messaging traffic to the new active database.

예를 들어 기본 저장소 오류로 인해 DAG의 활성 데이터베이스가 실패할 경우 Active Manager는 DAG에 있는 다른 사서함 서버의 데이터베이스 복사본으로 장애 조치하여 자동으로 복구합니다. Exchange 2013의 관리되는 가용성 기능에는 프로토콜에서 데이터베이스에 액세스할 수 없게 될 경우 이를 복구하는 동작이 새로 추가되었습니다. 여기에는 응용 프로그램 작업자 풀을 재순환하고, 서비스와 서버를 다시 시작하고, 데이터베이스 장애 조치(failover)를 시작하는 과정이 포함됩니다.For example, if an active database in a DAG fails because of an underlying storage failure, Active Manager will automatically recover by failing over to a database copy on another Mailbox server in the DAG. In Exchange 2013, managed availability adds new behaviors to recover from loss of protocol access to a database, including recycling application worker pools, restarting services and servers, and initiating database failovers.

사서함 데이터베이스 복사본에 대한 자세한 내용은 사서함 데이터베이스 복사본를 참조하십시오.For more information about mailbox database copies, see Mailbox database copies.

Active ManagerActive Manager

Exchange 2013은 Exchange 2010에서 도입된 Active Manager 구성 요소를 활용하여 데이터베이스, 데이터베이스 복사본 상태, 현재 상태, 연속 복제 및 기타 사서함 서버 고가용성 기능을 관리합니다. Active Manager에 대한 자세한 내용은 Active Manager를 참조하십시오.Exchange 2013 leverages the Active Manager component introduced in Exchange 2010 to manage the database and database copy health, status, continuous replication, and other aspects of Mailbox server high availability. For more information about Active Manager, see Active Manager.

사이트 복구Site resilience

Exchange 2013에서도 사서함 서버 역할 고가용성 및 사이트 복구에 DAG와 Windows 장애 조치(failover) 클러스터링을 계속 사용하지만 Exchange 2013의 사이트 복구 기능에는 차이점이 있습니다. Exchange 2013의 사이트 복구 기능은 단순화되었으므로 훨씬 더 우수합니다. Exchange 2013에서 구현된 기본 아키텍처 변경 사항은 사이트 복구 구성의 복구 측면에 상당한 영향을 줍니다.Although Exchange 2013 continues to use DAGs and Windows Failover Clustering for Mailbox server role high availability and site resilience, site resilience isn't the same in Exchange 2013. Site resilience is much better in Exchange 2013 because it has been simplified. The underlying architectural changes that were made in Exchange 2013 have significant impact on the recovery aspects of a site resilience configuration.

Exchange 2010에서는 사서함(DAG)과 클라이언트 액세스(클라이언트 액세스 서버 배열) 복구가 서로 결합되어 있었습니다. 클라이언트 액세스 서버 전체, 배열의 VIP 또는 DAG의 중요 부분이 손실된 경우에는 데이터 센터 전환을 수행해야 했습니다. 데이터 센터 전환은 잘 문서화되어 있고 일반적으로 이해하기 쉽지만 수행하는 데 시간이 걸리며 사용자의 개입이 있어야만 프로세스를 시작할 수 있습니다.In Exchange 2010, mailbox (DAG) and client access (Client Access server array) recovery were tied together. If you lost all of your Client Access servers, the VIP for the array, or a significant portion of your DAG, you were in a situation where you needed to do a datacenter switchover. This is a well-documented and generally well-understood process, although it takes time to perform, and requires human intervention to begin the process.

Exchange 2013에서는 부하 분산 장치 오류를 비롯한 어떤 이유로든 클라이언트 액세스 서버 배열이 손실될 경우 데이터 센터 전환을 수행할 필요가 없습니다. 올바른 구성을 사용하면 장애 조치(failover)가 클라이언트 수준에서 자동으로 발생하며, 클라이언트는 작동하는 클라이언트 액세스 서버가 있는 두 번째 데이터 센터로 자동 리디렉션됩니다. 또한 작동하는 클라이언트 액세스 서버는 통신을 다시 사용자의 사서함 서버로 프록시 처리하여 중단으로 인한 영향을 받지 않도록 합니다. 서비스 복구는 자체적으로 수행되므로 서비스 복구 작업을 수행하는 대신 실패한 부하 분산 장치를 교체하는 등 핵심 문제를 해결하는 데 초점을 맞출 수 있습니다.In Exchange 2013, if you lose your Client Access server array for whatever reason (for example, the load balancer fails), you don't need to perform a datacenter switchover. With the proper configuration, failover happens at the client level and clients are automatically redirected to a second datacenter that has operating Client Access servers, and those operating Client Access servers proxy the communication back to the user's Mailbox server, which remains unaffected by the outage (because you don't do a switchover). Instead of working to recover service, the service recovers itself and you can focus on fixing the core issue (for example, replacing the failed load balancer).

또한 네임스페이스 단순화, 서버 역할 통합, Active Directory 사이트 서버 역할 요구 사항의 분리, 클라이언트 액세스 서버 배열과 DAG 복구의 분리, 부하 분산 변경과 함께 Exchange 2013에서는 클라이언트 액세스 서버 및 DAG 복구를 사이트 간에 분리하고 자동화할 수 있으므로 3개의 위치가 있는 경우 데이터 센터 장애 조치(failover) 시나리오가 제공됩니다.Furthermore, with the namespace simplification, consolidation of server roles, de-coupling of Active Directory site server role requirements, separation of Client Access server array and DAG recovery, and load balancing changes, there are changes in Exchange 2013 that now enable both Client Access server and DAG recovery to be separate and automatic across sites, thereby providing datacenter failover scenarios, if you have three locations.

Exchange 2010에서는 두 데이터 센터에 DAG를 배포하고, 세 번째 데이터 센터에서 미러링 모니터 서버를 호스트하고, 두 데이터 센터 중 하나의 사서함 서버 역할에 대해 장애 조치(failover)를 사용할 수 있었습니다. 그러나 사서함 서버 역할이 아닌 서버 역할에 대해서는 여전히 수동으로 네임스페이스를 변경해야 했으므로 솔루션 자체를 위한 장애 조치(failover)는 아니었습니다.In Exchange 2010, you could deploy a DAG across two datacenters and host the witness in a third datacenter and enable failover for the Mailbox server role for either datacenter. But you didn't get failover for the solution itself, because the namespace still needed to be manually changed for the non-Mailbox server roles.

Exchange 2013에서는 DAG와 함께 네임스페이스를 이동하지 않아도 됩니다. Exchange는 다중 IP 주소, 부하 분산(필요한 경우 서비스 실행 상태 및 서비스 중지 상태로 서버를 사용하는 기능)을 통해 네임스페이스에 기본 제공되는 내결함성을 활용합니다. 최신 HTTP 클라이언트는 자동으로 이 중복성 기능과 함께 작동합니다. HTTP 스택은 FQDN(정규화된 도메인 이름)에 대해 다중 IP 주소를 허용할 수 있으며, 시도한 첫 IP 주소가 실패할 경우(연결할 수 없는 경우) 목록에 있는 다음 IP 주소를 시도합니다. 장치가 패킷을 누락하고 있어 서비스 중지 상태로 사용되어야 하는 등의 일시적인 서비스 문제로 인해 세션 설정 이후에 연결이 손실된 경우에는 사용자가 브라우저를 새로 고치면 됩니다.In Exchange 2013, the namespace doesn't need to move with the DAG. Exchange leverages fault tolerance built into the namespace through multiple IP addresses, load balancing (and if need be, the ability to take servers in and out of service). Modern HTTP clients work with this redundancy automatically. The HTTP stack can accept multiple IP addresses for a fully qualified domain name (FQDN), and if the first IP address it tries fails hard (that is, it can't connect), it will try the next IP address in the list. In a soft failure (connection is lost after the session is established, perhaps due to an intermittent failure in the service where, for example, a device is dropping packets and needs to be taken out of service), the user might need to refresh their browser.

이는 네임스페이스가 Exchange 2010에서처럼 더 이상 단일 실패 지점이 아님을 의미합니다. Exchange 2010에서 메시징 시스템의 가장 큰 단일 실패 지점은 사용자에게 할당된 FQDN입니다. 이는 FQDN이 사용자에게 이동할 위치를 알려 주기 때문입니다. Exchange 2010 패러다임에서 FQDN이 이동할 위치를 변경하는 작업은 DNS를 변경한 다음 DNS 대기 시간을 처리해야 하기 때문에 쉽지 않으며, 어떤 부분에 있어서는 아주 어렵습니다. 또한 브라우저에는 대개 약 30분 이상인 이름 캐시가 있으며 이 이름 캐시도 처리해야 합니다.This means the namespace is no longer a single point of failure as it was in Exchange 2010. In Exchange 2010, perhaps the biggest single point of failure in the messaging system is the FQDN that you give to users because it tells the user where to go. In the Exchange 2010 paradigm, changing where that FQDN goes isn't easy because you have to change DNS, and then handle DNS latency, which in some parts of the world is challenging. And you have name caches in browsers that are typically about 30 minutes or more that also have to be handled.

Exchange 2013에서 변경된 사항 중 하나는 클라이언트가 이동할 위치를 둘 이상 얻을 수 있다는 것입니다. 클라이언트가 이동할 위치를 둘 이상 사용할 수 있어(Exchange 2013의 거의 모든 클라이언트 액세스 프로토콜은 Outlook, 외부에서 Outlook 사용, EAS, EWS, OWA, EAC 등 HTTP 기반이며 지원되는 모든 HTTP 클라이언트는 다중 IP 주소를 사용할 수 있음) 클라이언트 쪽에서 장애 조치(failover)가 제공될 경우 이름 확인 중에 클라이언트에 여러 IP 주소를 전달하도록 DNS를 구성할 수 있습니다. 예를 들어 클라이언트는 mail.contoso.com에 요청하여 두 개 또는 네 개의 IP 주소를 받습니다. 그러나 클라이언트가 받는 많은 IP 주소는 클라이언트에 의해 안정적으로 사용됩니다. 그러므로 IP 주소 중 하나가 실패하더라도 클라이언트는 하나 이상의 다른 IP 주소에 연결을 시도할 수 있으므로 안정성이 좋아집니다. 클라이언트는 하나의 IP 주소로 시도하여 실패할 경우 약 20초간 기다렸다가 목록의 다음 IP 주소로 다시 시도합니다. 따라서 클라이언트 액세스 서버 배열의 VIP가 손실된 경우 약 21초 내에 클라이언트에 대한 복구가 자동으로 수행됩니다.One of the changes in Exchange 2013 is to enable clients to have more than one place to go. Assuming the client has the ability to use more than one place to go (almost all the client access protocols in Exchange 2013 are HTTP based (examples include Outlook, Outlook Anywhere, EAS, EWS, OWA, and EAC), and all supported HTTP clients have the ability to use multiple IP addresses), thereby providing failover on the client side. You can configure DNS to hand multiple IP addresses to a client during name resolution. The client asks for mail.contoso.com and gets back two IP addresses, or four IP addresses, for example. However many IP addresses the client gets back will be used reliably by the client. This makes the client a lot better off because if one of the IP addresses fails, the client has one or more other IP addresses to try to connect to. If a client tries one and it fails, it waits about 20 seconds and then tries the next one in the list. Thus, if you lose the VIP for the Client Access server array, recovery for the clients happens automatically, and in about 21 seconds.

이점은 다음과 같습니다.The benefits include the following:

  • Exchange 2010의 경우 기본 데이터 센터에서 부하 분산 장치에 오류가 발생했고 해당 사이트에 다른 부하 분산 장치가 없는 경우 데이터 센터 전환을 수행해야 했습니다. Exchange 2013에서는 기본 사이트의 부하 분산 장치에 오류가 발생할 경우 장치(또는 VIP)를 끈 다음 이를 수리하거나 교체하면 됩니다. 보조 데이터 센터에서 아직 VIP를 사용하고 있지 않은 클라이언트는 네임스페이스나 DNS를 변경하지 않고 보조 VIP에 대해 자동으로 장애 조치(failover)를 수행합니다. 이는 더 이상 전환을 수행할 필요가 없음을 의미하는 동시에 보통은 데이터 센터 전환 복구와 관련된 시간을 허비할 필요가 없음을 의미합니다. Exchange 2010에서는 DNS 지연 시간을 처리해야 했습니다. 따라서 TTL(Time to Live)을 5분으로 설정하고 장애 복구(failback) URL을 사용하도록 권장되었습니다. Exchange 2013에서는 VIP(데이터 센터) 간 네임스페이스의 장애 조치(failover)가 20초 내에 신속하게 수행되므로 그러한 설정이 필요하지 않습니다.In Exchange 2010, if you lose the load balancer in your primary datacenter and you don't have another one in that site, you had to do a datacenter switchover. In Exchange 2013, if you lose the load balancer in your primary site, you simply turn it off (or maybe turn off the VIP) and repair or replace it. Clients that aren't already using the VIP in the secondary datacenter will automatically fail over to the secondary VIP without any change of namespace, and without any change in DNS. Not only does that mean you no longer have to perform a switchover, but it also means that all of the time normally associated with a datacenter switchover recovery isn't spent. In Exchange 2010, you had to handle DNS latency (hence, the recommendation to set the Time to Live (TTL) to 5 minutes, and the introduction of the failback URL). In Exchange 2013, you don't need to do that because you get fast failover (20 seconds) of the namespace between VIPs (datacenters).

  • 데이터 센터 간 네임스페이스에 대한 장애 조치(failover)를 수행할 수 있기 때문에 데이터 센터 장애 조치(failover)에 필요한 것은 데이터 센터 간 사서함 서버 역할의 장애 조치(failover)를 위한 메커니즘뿐입니다.Because you can fail over the namespace between datacenters, all that's needed to achieve a datacenter failover is a mechanism for failover of the Mailbox server role across datacenters. DAG에 대한 자동 장애 조치(failover)를 수행하려면 DAG가 두 데이터 센터 간에 균등하게 분할되고, DAG 구성원을 포함하는 데이터 센터 간의 네트워크 상태에 상관없이 두 데이터 센터의 DAG 구성원이 미러링 모니터 서버를 중재할 수 있도록 세 번째 위치에 이를 배치하는 솔루션을 구성합니다.To get automatic failover for the DAG, you simply architect a solution where the DAG is evenly split between two datacenters, and then place the witness server in a third location so that it can be arbitrated by DAG members in either datacenter, regardless of the state of the network between the datacenters that contain the DAG members. 데이터 센터가 두 개 뿐 이며, 세 번째 물리적 위치를 사용할 수 없는 경우에는 미러링 모니터 서버를 Microsoft Azure 가상 컴퓨터에 배치할 수 있습니다.If you only have two datacenters and a third physical location isn't available, you can place the witness server on a Microsoft Azure virtual machine. 자세한 내용은 Microsoft AZURE VM을 DAG 미러링 모니터 서버로 사용 을 참조 하십시오.See Using a Microsoft Azure VM as a DAG witness server for more information.

  • 이 시나리오에서 관리자의 역할은 문제를 해결하는 데 집중되며 서비스를 복원하는 데 초점이 있지 않습니다. 즉, 관리자는 장애가 있는 대상만 해결하면 됩니다. 그동안에도 서비스는 실행되고 데이터 무결성은 유지 관리됩니다. 고장 난 장치를 수리할 때의 긴급함과 스트레스 수준은 서비스를 복원하는 동안에 느끼는 긴급함과 스트레스 수준에 비하면 아무 것도 아닙니다. 이는 최종 사용자에게도 더 낫고 관리자의 부담도 훨씬 적습니다.In this scenario, the administrator's efforts are geared toward simply fixing the problem, and not spent restoring service. You simply fix the thing that failed; while service has been running and data integrity has been maintained. The urgency and stress level you feel when fixing a broken device is nothing like the urgency and stress you feel when you're working to restore service. It's better for the end user, and less stressful for the administrator.

다시 전환(장애 복구(failback)와 혼동되는 경우도 있음)을 수행할 필요 없이 장애 조치(failover)가 수행되도록 할 수 있습니다. 기본 데이터 센터에서 클라이언트 액세스 서버가 손실되고 이로 인해 클라이언트 서비스가 20초 동안 중단되더라도 장애 복구(failback)에 신경 쓸 필요가 없습니다. 이 시점에서 주요 관심사는 장애가 있는 부하 분산 장치를 교체하는 것과 같이 근본 문제를 해결하는 것입니다. 기본 데이터 센터가 다시 온라인 상태가 되어 작동하게 되면 일부 클라이언트는 해당 데이터 센터를 사용하기 시작하지만 다른 클라이언트는 여전히 두 번째 데이터 센터를 통해 작동하고 있을 수 있습니다.You can allow failover to occur without having to perform switchbacks (sometimes mistakenly referred to as failbacks). If you lose Client Access servers in your primary datacenter and that results in a 20 second interruption for clients, you might not even care about failing back. At this point, your primary concern would be fixing the core issue (for example, replacing the failed load balancer). After it's back online and functioning, some clients will start using it, and other clients might remain operational through the second datacenter.

Exchange 2013에서는 관리자가 일시적인 오류를 처리할 수 있는 기능도 제공됩니다. 예를 들면, 초기 TCP 연결에는 성공했지만 이후 아무 작업도 수행되지 않는 경우가 일시적인 오류에 해당합니다. 일시적인 오류는 교체 장치에서 서비스를 제공하도록 전환한 결과로 인해 발생할 수 있으므로 추가 관리 작업을 수행해야 합니다. 이 복구 프로세스가 진행되는 동안 장치의 전원을 켜고 일부 요청을 받을 수도 있지만 필요한 구성 단계가 수행되기 전까지는 장치에서 실제로 클라이언트에 서비스를 제공할 수 없습니다. 이 경우 관리자는 DNS에서 교체되는 장치의 VIP를 제거하여 네임스페이스 전환을 수행할 수 있습니다. 그러면 해당 서비스 기간 동안 클라이언트가 이 장치에 연결하지 않게 됩니다. 교체 프로세스가 완료된 후 관리자는 VIP를 다시 DNS에 추가할 수 있으며 그러면 클라이언트가 해당 장치를 사용하기 시작합니다.Exchange 2013 also provides functionality that enables administrators to deal with intermittent failures. An intermittent failure is where, for example, the initial TCP connection can be made, but nothing happens afterward. An intermittent failure requires some sort of extra administrative action to be taken because it might be the result of a replacement device being put into service. While this repair process is occurring, the device might be powered on and accepting some requests, but not really ready to service clients until the necessary configuration steps are performed. In this scenario, the administrator can perform a namespace switchover by simply removing the VIP for the device being replaced from DNS. Then during that service period, no clients will be trying to connect to it. After the replacement process has completed, the administrator can add the VIP back to DNS, and clients will eventually start using it.

사이트 복구 계획 및 배포에 대 한 자세한 내용은 고가용성 및 사이트 복구 계획고가용성 및 사이트 복구를 배포하는 방법에 대 한 자세한 내용을 참조 하십시오.For details about planning and deploying site resilience, see Planning for high availability and site resilience and Deploying high availability and site resilience.

타사 복제 APIThird-party replication API

Exchange 2013에는 조직에서 기본 제공되는 연속 복제 기능 대신 타사 동기식 복제 솔루션을 사용할 수 있게 하는 타사 복제 API가 포함되어 있습니다. Microsoft는 해당 솔루션이 API를 사용한 결과로 사용할 수 없는 모든 기본 연속 복제 기능을 대체하는 데 필요한 기능을 제공한다면 이 API를 사용하는 타사 솔루션을 지원합니다. API가 DAG 내에서 사용되어 사서함 데이터베이스 복사본을 관리하고 활성화하는 경우에만 솔루션이 지원됩니다. 이러한 경계 외부에서의 API 사용은 지원되지 않습니다. 또한 솔루션은 관련 Windows 하드웨어 지원 요구 사항을 충족해야 합니다. 단, 지원을 위해 테스트 유효성 검사는 필요하지 않습니다.Exchange 2013 also includes a third-party replication API that enables organizations to use third-party synchronous replication solutions instead of the built-in continuous replication feature. Microsoft supports third-party solutions that use this API, provided that the solution provides the necessary functionality to replace all native continuous replication functionality that's disabled as a result of using the API. Solutions are supported only when the API is used within a DAG to manage and activate mailbox database copies. Use of the API outside of these boundaries isn't supported. In addition, the solution must meet the applicable Windows hardware support requirements. (Test validation isn't required for support.)

기본 타사 복제 API를 사용하는 솔루션을 배포하는 경우 솔루션 공급업체가 해당 솔루션에 대한 주 지원 공급자가 됩니다. Microsoft는 복제된 솔루션 및 복제되지 않은 솔루션 모두에 대한 Exchange 데이터를 지원합니다. 데이터 복제를 사용하는 솔루션은 Microsoft 기술 자료 문서 895847, Exchange Server의 다중 사이트 데이터 복제 기능 지원에서 설명한 데이터 복제에 대한 Microsoft의 지원 정책을 준수해야 합니다. 또한 Windows 장애 조치(failover) 클러스터 리소스 모델을 사용하는 솔루션은 Microsoft 기술 자료 문서 943984, Windows Server 2008 또는 Windows Server 2008 R2 장애 조치(failover) 클러스터에 대한 Microsoft 지원 정책 또는 Windows Server 2012 장애 조치(failover) 클러스터에 대한 Microsoft 지원 정책에서 설명한 Windows 클러스터 지원 가능성 요구 사항을 준수해야 합니다.When deploying a solution that uses the built-in third-party replication API, be aware that the solution vendor is responsible for primary support of the solution. Microsoft supports Exchange data for both replicated and non-replicated solutions. Solutions that use data replication must adhere to the Microsoft support policy for data replication, as described in Microsoft Knowledge Base article 895847, Multi-site data replication support for Exchange Server. In addition, solutions that utilize the Windows Failover Cluster resource model must meet Windows cluster supportability requirements as described in Microsoft Knowledge Base article 943984, The Microsoft Support Policy for Windows Server 2008 or Windows Server 2008 R2 Failover Clusters or The Microsoft Support Policy for Windows Server 2012 Failover Clusters.

타사 복제 API 기반 솔루션을 사용하는 배포의 경우 Microsoft의 백업 및 복원 지원 정책은 고유의 연속 복제 배포의 경우와 동일합니다.Microsoft's backup and restore support policy for deployments that use third-party replication API-based solutions is the same as for native continuous replication deployments.

타사 API에 대한 정보가 필요한 파트너는 Microsoft 담당자에게 문의하십시오.If you're a partner seeking information about the third-party API, contact your Microsoft representative.

고가용성 및 사이트 복구 설명서High availability and site resilience documentation

다음 표에는 Exchange 2013의 DAG, 사서함 데이터베이스 복사본, 백업 및 복원을 이해하고 관리하는 데 도움이 되는 항목으로 연결되는 링크가 포함되어 있습니다.The following table contains links to topics that will help you learn about and manage DAGs, mailbox database copies, and backup and restore for Exchange 2013.

항목Topic 설명Description

DAG(데이터베이스 사용 가능 그룹)Database availability groups (DAGs)

DAG, Active Manager, DAC(데이터 센터 활성화 조정) 모드 및 사서함 데이터베이스 복사본에 대해 알아봅니다.Learn about DAGs, Active Manager, Datacenter Activation Coordination (DAC) mode, and mailbox database copies.

고가용성 및 사이트 복원 계획Planning for high availability and site resilience

DAG에 대한 일반, 하드웨어, 네트워크, 소프트웨어, 미러링 모니터 서버 및 기타 요구 사항과 모범 사례를 알아봅니다.Learn about the general, hardware, network, software, witness server, and other requirements and best practices for DAGs.

고가용성 및 사이트 복구 배포Deploying high availability and site resilience

DAG 배포 및 구성을 위한 배포 시나리오 예를 살펴봅니다.Explore an example deployment scenario for deploying and configuring DAGs.

고가용성 및 사이트 복구 관리Managing high availability and site resilience

DAG 관리 작업, 전환 및 장애 조치(failover), 유지 관리 모드에 대해 알아봅니다.Learn about DAG management tasks, switchovers and failovers, and maintenance mode.

데이터베이스 사용 가능 그룹 모니터링Monitoring database availability groups

DAG와 데이터베이스 복사본을 모니터링하기 위한 기본 제공 cmdlet 및 스크립트에 대해 알아봅니다.Learn about the built-in cmdlets and scripts for monitoring DAGs and database copies.

백업, 복원 및 재해 복구Backup, restore, and disaster recovery

Exchange 데이터베이스 백업 및 복원, 복구 데이터베이스, 서버 복구에 대해 알아봅니다.Learn about backing up and restoring Exchange databases, recovery databases, and server recovery.