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

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

계획 단계에서 시스템 설계자, 관리자 및 기타 핵심 관계자는 비즈니스 요구 사항과 배포 시 아키텍처 요구 사항 외에 특히 고가용성과 사이트 복구에 대한 요구 사항을 확인해야 합니다.During the planning phase, the system architects, administrators, and other key stakeholders should identify the business requirements and the architectural requirements for the deployment; in particular, the requirements about high availability and site resilience.

이러한 기능 배포를 위해 충족해야 할 일반적인 요구 사항뿐 아니라, 마찬가지로 충족해야 할 하드웨어, 소프트웨어 및 네트워킹 요구 사항도 있습니다.There are general requirements that must be met for deploying these features, as well as hardware, software, and networking requirements that must also be met.

일반 요구 사항General requirements

DAG(데이터베이스 사용 가능 그룹)를 배포하고 사서함 데이터베이스 복사본을 생성하기 전에 먼저 다음과 같은 시스템 전반의 권장 사항을 충족해야 합니다.Before deploying a database availability group (DAG) and creating mailbox database copies, make sure that the following system-wide recommendations are met:

  • DNS(Domain Name System)를 실행해야 합니다. 이상적으로 DNS 서버는 동적 업데이트를 허용해야 합니다. DNS 서버가 동적 업데이트를 허용하지 않는 경우 각 Exchange 서버에 대한 DNS 호스트 (A) 레코드를 만들어야 합니다. 그렇지 않으면 Exchange가 제대로 작동하지 않습니다.Domain Name System (DNS) must be running. Ideally, the DNS server should accept dynamic updates. If the DNS server doesn't accept dynamic updates, you must create a DNS host (A) record for each Exchange server. Otherwise, Exchange won't function properly.

  • DAG의 각 사서함 서버는 같은 도메인의 구성원 서버여야 합니다.Each Mailbox server in a DAG must be a member server in the same domain.

  • 디렉터리 서버이기도 한 Exchange 2013 사서함 서버는 DAG에 DAG에 추가할 수 없습니다.Adding an Exchange 2013 Mailbox server that's also a directory server to a DAG isn't supported.

  • DAG에는 유효하고 사용 가능하며 15자 이하의 고유한 컴퓨터 이름을 지정해야 합니다.The name you assign to the DAG must be a valid, available, and unique computer name of 15 characters or less.

하드웨어 요구 사항Hardware requirements

일반적으로 DAG나 사서함 데이터베이스 복사본에 한정되는 특별한 하드웨어 요구 사항은 없습니다.Generally, there are no special hardware requirements specific to DAGs or mailbox database copies. 사용 되는 서버는 exchange 2013 필수 구성 요소exchange 2013 시스템 요구 사항에 대 한 항목에 설정 된 모든 요구 사항을 충족 해야 합니다.The servers used must meet all of the requirements set forth in the topics for Exchange 2013 prerequisites and Exchange 2013 system requirements.

저장소 요구 사항Storage requirements

일반적으로 DAG나 사서함 데이터베이스 복사본에 한정되는 특별한 저장소 요구 사항은 없습니다. DAG는 클러스터 관리 공유 저장소를 필요로 하거나 사용하지 않습니다. 클러스터 관리 공유 저장소는 Exchange 2013에 기본적으로 제공되는 타사 복제 API를 활용하는 솔루션을 사용하도록 DAG가 구성된 경우에만 DAG에서 사용할 수 있습니다.Generally, there are no special storage requirements specific to DAGs or mailbox database copies. DAGs don't require or use cluster-managed shared storage. Cluster-managed shared storage is supported for use in a DAG only when the DAG is configured to use a solution that leverages the Third Party Replication API built into Exchange 2013.

소프트웨어 요구 사항Software requirements

DAG는 Exchange 2013 Standard 및 Exchange 2013 Enterprise에서 모두 사용할 수 있습니다. 또한 DAG에는 Exchange 2013 Standard 및 Exchange 2013 Enterprise를 실행 중인 서버가 혼합되어 포함될 수 있습니다.DAGs are available in both Exchange 2013 Standard and Exchange 2013 Enterprise. In addition, a DAG can contain a mix of servers running Exchange 2013 Standard and Exchange 2013 Enterprise.

DAG의 각 구성원은 같은 운영 체제를 실행해야 합니다. Exchange 2013은 Windows Server 2008 R2, Windows Server 2012 및 Windows Server 2012 R2 운영 체제에서 지원됩니다. 특정 DAG의 모든 구성원이 동일한 운영 체제를 실행해야 합니다. Windows Server 2012 R2는 Exchange 2013 서비스 팩 1 이상을 실행하는 DAG 구성원에만 지원됩니다.Each member of the DAG must also be running the same operating system. Exchange 2013 is supported on the Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 operating systems. All members of a specific DAG must run the same operating system. Windows Server 2012 R2 is supported only for DAG members that are running Exchange 2013 Service Pack 1 or later.

Exchange 2013 을 설치하기 위한 선행 조건 외에도 반드시 충족해야 하는 운영 체제 요구 사항이 있습니다. DAG에서는 Windows 장애 조치(failover) 클러스터링 기술을 사용하므로 Windows Server 2008 R2의 Enterprise 또는 Datacenter 버전이나 Windows Server 2012 운영 체제의 Standard 또는 Datacenter 버전 또는 Windows Server 2012 R2 운영 체제가 필요합니다.In addition to meeting the prerequisites for installing Exchange 2013, there are operating system requirements that must be met. DAGs use Windows Failover Clustering technology, and as a result, they require the Enterprise or Datacenter version of Windows Server 2008 R2, or the Standard or Datacenter version of the Windows Server 2012 or Windows Server 2012 R2 operating systems.

네트워크 요구 사항Network requirements

각 DAG 및 각 DAG 구성원에 대해 충족해야 할 특정 네트워킹 요구 사항이 있습니다.There are specific networking requirements that must be met for each DAG and for each DAG member. 각 DAG에는 DAG 구성원이 다른 서버와 통신 하는 데 사용 되는 단일 MAPI 네트워크(예: 다른 Exchange 2013 서버 또는 디렉터리 서버)와 0 개 이상의 복제 네트워크(로그 전용 네트워크)가 있어야 합니다. 배송 및 시드Each DAG must have a single MAPI network, which is used by a DAG member to communicate with other servers (for example, other Exchange 2013 servers or directory servers), and zero or more Replication networks, which are networks dedicated to log shipping and seeding.

Exchange의 이전 버전에서는 DAG에 대해 네트워크를 두 개 이상(MAPI 네트워크와 복제 네트워크 각각 하나씩) 사용하는 것이 좋습니다.In previous versions of Exchange, we recommended at least two networks (one MAPI network and one Replication network) for DAGs. Exchange 2013에서는 여러 네트워크가 지원되지만 실제 네트워크 토폴로지에 따라 권장 사항이 달라집니다.In Exchange 2013, multiple networks are supported, but our recommendation depends on your physical network topology. DAG 구성원 간에 물리적으로 서로 완전히 분리된 실제 네트워크가 여러 개 있는 경우 별도의 MAPI 및 복제 네트워크를 사용하면 중복성을 높일 수 있습니다.If you have multiple physical networks between DAG members that are physically separate from one another, then using a separate MAPI and Replication network provides additional redundancy. 부분 물리적으로 분리 되었지만 단일 단일 네트워크에 수렴 되는 여러 네트워크가 있는 경우 (예: 하나의 WAN 링크) 단일 네트워크 (가능 하면 10 gigabit Ethernet)를 MAPI 및 복제 트래픽에 사용 하는 것이 좋습니다.If you have multiple networks that are partially physically separate but converge into a single physical network (for example, a single WAN link), then using a single network (preferably 10 gigabit Ethernet) for both MAPI and Replication traffic is recommended. 그러면 네트워크와 네트워크 경로를 단순하게 유지할 수 있습니다.This provides simplicity for the network and the network path.

DAG 네트워크 인프라를 디자인할 때는 다음과 같은 사항을 고려하십시오.Consider the following when designing the network infrastructure for your DAG:

  • 각 DAG 구성원에는 다른 모든 DAG 구성원과 통신할 수 있는 네트워크 어댑터가 하나 이상 있어야 합니다.Each member of the DAG must have at least one network adapter that's able to communicate with all other DAG members. 단일 네트워크 경로를 사용 하는 경우에는 최소 1 개의 gigabit Ethernet을 사용 하는 것이 좋지만,이 경우에는 10 gigabit Ethernet을 사용할 것을 권장 합니다.If you're using a single network path, we recommend that you use a minimum of 1 gigabit Ethernet, but preferably 10 gigabit Ethernet. 또한 각 DAG 구성원에 하나의 네트워크 어댑터를 사용하는 경우에는 해당 네트워크 어댑터와 경로를 고려하여 전체적인 솔루션을 디자인하는 것이 좋습니다.In addition, when using a single network adapter in each DAG member, we recommend that you design the overall solution with the single network adapter and path in mind.

  • 각 DAG 구성원에 두 개의 네트워크 어댑터를 사용하면 MAPI 네트워크와 복제 네트워크가 각각 하나씩 제공되며, 복제 네트워크의 중복성 및 다음 복구 동작이 지원됩니다.Using two network adapters in each DAG member provides you with one MAPI network and one Replication network, with redundancy for the Replication network and the following recovery behaviors:

    • MAPI 네트워크에 영향을 주는 오류가 발생하면 활성화할 수 있는 정상 상태의 사서함 데이터베이스 복사본이 있다는 가정 하에 서버 장애 조치(failover)가 수행됩니다.In the event of a failure affecting the MAPI network, a server failover will occur (assuming there are healthy mailbox database copies that can be activated).

    • 복제 네트워크에 영향을 주는 오류가 발생 하는 경우 MAPI 네트워크가 실패의 영향을 받지 않으면 mapi 네트워크의 ReplicationEnabled 속성이 False로 설정 된 경우에도 로그 전달 및 시드 작업이 mapi 네트워크를 사용 하도록 복원 됩니다. .In the event of a failure affecting the Replication network, if the MAPI network is unaffected by the failure, log shipping and seeding operations will revert to use the MAPI network, even if the MAPI network has it's ReplicationEnabled property set to False. 오류가 발생한 복제 네트워크가 정상으로 복원되어 로그 전달 및 시드 작업을 다시 시작할 준비가 되면 수동으로 복제 네트워크로 전환해야 합니다.When the failed Replication network is restored to health and ready to resume log shipping and seeding operations, you must manually switch over to the Replication network. MAPI 네트워크에서 복원된 복제 네트워크로 복제를 변경하려면 Suspend-MailboxDatabaseCopyResume-MailboxDatabaseCopy cmdlet을 사용하여 연속 복제를 일시 중단한 후 계속해서 다시 시작하거나, Microsoft Exchange Replication Service를 다시 시작합니다.To change replication from the MAPI network to a restored Replication network, you can either suspend and resume continuous replication by using the Suspend-MailboxDatabaseCopy and Resume-MailboxDatabaseCopy cmdlets, or restart the Microsoft Exchange Replication service. Microsoft Exchange Replication Service를 다시 시작해서 작업이 잠시 중단되는 상황이 발생하지 않도록 하려면 작업을 일시 중단한 후 다시 시작하는 것이 좋습니다.We recommend using suspend and resume operations to avoid the brief outage caused by restarting the Microsoft Exchange Replication service.

  • 각 DAG 구성원에 같은 수의 네트워크가 포함되어야 합니다. 예를 들어, 한 DAG 구성원의 네트워크 어댑터를 하나만 사용하려면 모든 DAG 구성원도 한 네트워크 어댑터를 사용해야 합니다.Each DAG member must have the same number of networks. For example, if you plan on using a single network adapter in one DAG member, all members of the DAG must also use a single network adapter.

  • 각 DAG에는 MAPI 네트워크가 하나만 있어야 합니다. MAPI 네트워크에서는 Active Directory와 DNS 등의 다른 Exchange 서버 및 서비스에 연결할 수 있어야 합니다.Each DAG must have no more than one MAPI network. The MAPI network must provide connectivity to other Exchange servers and other services, such as Active Directory and DNS.

  • 필요에 따라 복제 네트워크는 추가할 수 있습니다. 또한 네트워크 어댑터 팀 또는 유사한 기술을 활용하여 개별 네트워크 어댑터가 단일 실패 지점이 되는 것을 방지할 수도 있습니다. 그러나 팀을 사용한다 해도 네트워크 자체가 단일 실패 지점이 되는 것을 방지할 수는 없습니다. 또한 DAG에 불필요한 복잡성이 추가됩니다.Additional Replication networks can be added, as needed. You can also prevent an individual network adapter from being a single point of failure by using network adapter teaming or similar technology. However, even when using teaming, this doesn't prevent the network itself from being a single point of failure. Moreover, teaming adds unnecessary complexity to the DAG.

  • 각 DAG 구성원 서버의 각 네트워크는 자체 네트워크 서브넷에 있어야 합니다. DAG의 각 서버는 서로 다른 서브넷에 있을 수 있지만, MAPI와 복제 네트워크는 라우팅이 가능해야 하고 다음과 같은 연결을 제공해야 합니다.Each network in each DAG member server must be on its own network subnet. Each server in the DAG can be on a different subnet, but the MAPI and Replication networks must be routable and provide connectivity, such that:

    • 각 DAG 구성원 서버의 각 네트워크는 이 서버의 다른 네트워크가 사용하는 서브넷과 별개인 자체 네트워크 서브넷에 있습니다.Each network in each DAG member server is on its own network subnet that's separate from the subnet used by each other network in the server.

    • 각 DAG 구성원 서버의 MAPI 네트워크는 다른 DAG 구성원의 MAPI 네트워크와 서로 통신할 수 있습니다.Each DAG member server's MAPI network can communicate with each other DAG member's MAPI network.

    • 각 DAG 구성원 서버의 복제 네트워크는 다른 DAG 구성원의 복제 네트워크와 서로 통신할 수 있습니다.Each DAG member server's Replication network can communicate with each other DAG member's Replication network.

    • 한 DAG 구성원 서버의 복제 네트워크에서 다른 DAG 구성원 서버의 MAPI 네트워크로, 또는 그 반대로, 또는 DAG의 여러 복제 네트워크 간에 하트비트 트래픽을 허용하는 직접 라우팅은 없습니다.There is no direct routing that allows heartbeat traffic from the Replication network on one DAG member server to the MAPI network on another DAG member server, or vice versa, or between multiple Replication networks in the DAG.

  • 다른 DAG 구성원과 관련된 물리적 위치에 상관없이 각 DAG 구성원은 상호 간의 왕복 네트워크 대기 시간이 500밀리초를 넘지 않아야 합니다. 데이터베이스 복사본을 호스트하는 두 사서함 서버 간의 왕복 대기 시간이 늘어나면 복제 작업이 최신 상태로 진행되지 않을 가능성도 커집니다. 솔루션 대기 시간에 상관없이 고객은 모든 DAG 구성원 간의 네트워크가 배포에 관한 데이터 보호 및 가용성 목표를 충족할 수 있는지 확인해야 합니다. 대기 시간 값이 높은 구성에서 원하는 목표를 달성하려면 데이터베이스 수를 늘리거나 데이터베이스별 사서함 수를 줄이는 등 DAG, 복제 및 네트워크 매개 변수를 특별히 조정해야 할 수 있습니다.Regardless of their geographic location relative to other DAG members, each member of the DAG must have round trip network latency no greater than 500 milliseconds between each other member. As the round trip latency between two Mailbox servers hosting copies of a database increases, the potential for replication not being up to date also increases. Regardless of the latency of the solution, customers should validate that the networks between all DAG members is capable of satisfying the data protection and availability goals of the deployment. Configurations with higher latency values may require special tuning of DAG, replication, and network parameters, such as increasing the number of databases or decreasing the number of mailboxes per database, to achieve the desired goals.

  • 왕복 대기 시간 요구 사항은 다중 데이터 센터 구성에 대한 가장 엄격한 네트워크 대역폭 및 대기 시간 요구 사항이 아닐 수 있습니다. 클라이언트 액세스, Active Directory, 전송, 연속 복제 및 기타 응용 프로그램 트래픽을 포함한 전체 네트워크 부하를 평가하여 환경에 필요한 네트워크 요구 사항을 결정해야 합니다.Round trip latency requirements may not be the most stringent network bandwidth and latency requirement for a multi-datacenter configuration. You must evaluate the total network load, which includes client access, Active Directory, transport, continuous replication, and other application traffic, to determine the necessary network requirements for your environment.

  • DAG 네트워크는 IPv4(인터넷 프로토콜 버전 4) 및 IPv6을 지원합니다. IPv6은 IPv4를 함께 사용하는 경우에만 지원되며, 순수한 IPv6 환경은 지원되지 않습니다. IPv6 주소와 IP 주소 범위 사용은 IPv6 및 IPv4 모두를 해당 컴퓨터에서 사용하도록 설정되어 있고, 네트워크가 두 IP 주소 버전을 모두 지원하는 경우에만 지원됩니다. 이 구성에서 Exchange 2013을 배포하면 모든 서버 역할에서 IPv6 주소를 사용하는 장치, 서버 및 클라이언트와 데이터를 주고받을 수 있습니다.DAG networks support Internet Protocol version 4 (IPv4) and IPv6. IPv6 is supported only when IPv4 is also used; a pure IPv6 environment isn't supported. Using IPv6 addresses and IP address ranges is supported only when both IPv6 and IPv4 are enabled on that computer, and the network supports both IP address versions. If Exchange 2013 is deployed in this configuration, all server roles can send data to and receive data from devices, servers, and clients that use IPv6 addresses.

  • APIPA(자동 개인 IP 주소)는 네트워크에서 DHCP(Dynamic Host Configuration Protocol) 서버를 사용할 수 없을 때 IP 주소를 자동으로 할당하는 Windows의 기능입니다. APIPA 주소(APIPA 주소 범위에서 수동으로 할당된 주소 포함)는 DAG 또는 Exchange 2013에서 사용할 수 없습니다.Automatic Private IP Addressing (APIPA) is a feature of Windows that automatically assigns IP addresses when no Dynamic Host Configuration Protocol (DHCP) server is available on the network. APIPA addresses (including manually assigned addresses from the APIPA address range) aren't supported for use by DAGs or by Exchange 2013.

DAG 이름 및 IP 주소 요구 사항DAG name and IP address requirements

DAG가 만들어질 때 각 DAG에는 고유한 이름이 지정되고, 하나 이상의 고정 IP 주소에 할당되거나 DHCP를 사용하도록 구성됩니다. 고정 주소 또는 동적으로 할당된 주소 중 무엇을 사용하든 상관없이 DAG에 할당된 IP 주소는 MAPI 네트워크에 있어야 합니다.During creation, each DAG is given a unique name, and either assigned one or more static IP addresses, or configured to use DHCP. Regardless of whether you use static or dynamically assigned addresses, any IP address assigned to the DAG must be on the MAPI network.

Windows Server 2008 R2 또는 Windows Server 2012에서 실행되는 각 DAG에는 MAPI 네트워크의 IP 주소가 하나 이상 필요합니다. MAPI 네트워크가 여러 서브넷으로 확장될 경우 DAG는 추가 IP 주소를 필요로 하게 됩니다. Windows Server 2012 R2에서 실행되며 클러스터 관리 액세스 포인트 없이 작성된 DAG에는 IP 주소가 필요하지 않습니다.Each DAG running on Windows Server 2008 R2 or Windows Server 2012 requires a minimum of one IP address on the MAPI network. A DAG requires additional IP addresses when the MAPI network is extended across multiple subnets. DAGs running on Windows Server 2012 R2 that are created without a cluster administrative access point do not require an IP address.

다음 그림은 DAG의 모든 노드가 같은 서브넷에 MAPI 네트워크가 있는 DAG를 나타냅니다.The following figure illustrates a DAG where all nodes in the DAG have the MAPI network on the same subnet.

같은 서브넷에 MAPI 네트워크가 있는 DAGDAG with MAPI network on same subnet

![단일 서브넷의 DAG] (images/Dd638104.bcb7ef68-6d18-4516-a736-b936991c82cb(EXCHG.150).gif "단일 서브넷의 DAG")DAG on single subnet

이 예에서는 각 DAG 구성원의 MAPI 네트워크가, 172.19.18에 있습니다. x 서브넷In this example, the MAPI network in each DAG member is on the 172.19.18.x subnet. 결과적으로 DAG에는 해당 서브넷의 IP 주소 하나만 필요합니다.As a result, the DAG requires a single IP address on that subnet.

다음 그림은 두 서브넷, 172.19.18.x 및 172.19.19.x에서 확장되는 MAPI 네트워크가 있는 DAG를 보여 줍니다.The next figure illustrates a DAG that has a MAPI network that extends across two subnets: 172.19.18.x and 172.19.19.x.

여러 서브넷에 MAPI 네트워크가 있는 DAGDAG with MAPI network on multiple subnets

![여러 서브넷에서 확장 된 DAG] (images/Dd638104.ffb57c64-3cb1-435c-8148-1b7154d1575c(EXCHG.150).gif "여러 서브넷에서 확장 된 DAG")DAG extended across multiple subnets

이 예에서, 각 DAG 구성원의 MAPI 네트워크는 별도의 서브넷에 있습니다. 따라서 DAG는 MAPI 네트워크의 각 서브넷에 하나씩, 두 개의 IP 주소를 필요로 합니다.In this example, the MAPI network in each DAG member is on a separate subnet. As a result, the DAG requires two IP addresses, one for each subnet on the MAPI network.

DAG의 MAPI 네트워크가 추가 서브넷으로 확장될 때마다 해당 서브넷에 대한 추가 IP 주소를 DAG에 구성해야 합니다. DAG에 구성한 각 IP 주소는 DAG의 기본 장애 조치(failover) 클러스터에 할당되어 사용됩니다. DAG의 이름은 기본 장애 조치(failover) 클러스터의 이름으로도 사용됩니다.Each time the DAG's MAPI network is extended across an additional subnet, an additional IP address for that subnet must be configured for the DAG. Each IP address that's configured for the DAG is assigned to and used by the DAG's underlying failover cluster. The name of the DAG is also used as the name for the underlying failover cluster.

특정 시점에서, DAG의 클러스터는 할당된 IP 주소 중 하나만을 사용하게 됩니다. 클러스터 IP 주소 및 네트워크 이름 리소스가 온라인 상태가 되면 Windows 장애 조치(failover) 클러스터링은 이 IP 주소를 DNS에 등록합니다. IP 주소와 네트워크 이름 사용 외에, CNO(클러스터 이름 개체)가 Active Directory에 만들어집니다. 클러스터의 이름과 IP 주소, CNO는 DAG 보안 및 내부 통신용으로 시스템에서 내부적으로 사용합니다. 따라서 관리자와 최종 사용자는 DAG 이름 또는 IP 주소에 연결할 필요가 없습니다.At any specific time, the cluster for the DAG will use only one of the assigned IP addresses. Windows Failover Clustering registers this IP address in DNS when the cluster IP address and Network Name resources are brought online. In addition to using an IP address and network name, a cluster name object (CNO) is created in Active Directory. The name, IP address, and CNO for the cluster are used internally by the system to secure the DAG and for internal communication purposes. Administrators and end users don't need to interface with or connect to the DAG name or IP address.

참고

클러스터의 IP 주소와 네트워크 이름을 시스템에서 내부적으로 사용하기는 하지만 Exchange 2013에서 이러한 리소스를 사용해야 할 특별한 이유는 없습니다. 기본 클러스터의 관리 액세스 포인트(해당 IP 주소 및 네트워크 이름 리소스)가 오프라인 상태인 경우에도 DAG는 DAG 구성원의 서버 이름을 사용하여 계속해서 내부적으로 통신합니다. 그러나 이 리소스가 30일을 초과하여 오프라인 상태로 있지 않도록 리소스의 가용성을 정기적으로 모니터링하는 것이 좋습니다. 기본 클러스터가 30일을 초과하여 오프라인 상태일 경우 Active Directory의 가비지 수집 메커니즘으로 클러스터 CNO 계정의 유효성을 검사할 수도 있습니다.Although the cluster's IP address and network name are used internally by the system, there is no hard dependency in Exchange 2013 that these resources be available. Even if the underlying cluster's administrative access point (e.g., it's IP address and Network Name resources) is offline, internal communication still occurs within the DAG by using the DAG member server names. However, we recommend that you periodically monitor the availability of these resources to ensure that they aren't offline for more than 30 days. If the underlying cluster is offline for more than 30 days, the cluster CNO account may be invalidated by the garbage collection mechanism in Active Directory.

DAG 네트워크 어댑터 구성Network adapter configuration for DAGs

각 네트워크 어댑터는 의도한 용도에 맞게 적절하게 구성해야 합니다. MAPI 네트워크에 사용되는 네트워크 어댑터는 복제 네트워크에 사용되는 네트워크 어댑터와는 다르게 구성됩니다. 각 네트워크 어댑터를 올바르게 구성하는 것 외에도, Windows에서 MAPI 네트워크가 연결 순서의 맨 위로 가도록 네트워크 연결 순서를 구성해야 합니다. 네트워크 연결 순서를 수정하는 방법에 대한 자세한 단계는 프로토콜 바인딩 및 네트워크 공급자 순서 수정을 참조하세요.Each network adapter must be configured properly based on its intended use. A network adapter that's used for a MAPI network is configured differently from a network adapter that's used for a Replication network. In addition to configuring each network adapter correctly, you must also configure the network connection order in Windows so that the MAPI network is at the top of the connection order. For detailed steps about how to modify the network connection order, see Modify the protocol bindings and network provider order.

MAPI 네트워크 어댑터 구성MAPI network adapter configuration

MAPI 네트워크에서 사용할 네트워크 어댑터는 다음 표에 설명된 대로 구성해야 합니다.A network adapter intended for use by a MAPI network should be configured as described in the following table.

네트워킹 기능Networking features 설정Settings

Microsoft Networks용 클라이언트Client for Microsoft Networks

사용Enabled

QoS 패킷 스케줄러QoS Packet Scheduler

필요시 사용Optionally enabled

Microsoft Networks용 파일 및 프린터 공유File and Printer Sharing for Microsoft Networks

사용Enabled

TCP/IP v6(인터넷 프로토콜 버전 6)Internet Protocol version 6 (TCP/IP v6)

사용Enabled

TCP/IP v4(인터넷 프로토콜 버전 4)Internet Protocol version 4 (TCP/IP v4)

사용Enabled

링크 계층 토폴로지 검색 매퍼 I/O 드라이버Link-Layer Topology Discovery Mapper I/O Driver

사용Enabled

링크 계층 토폴로지 검색 응답자Link-Layer Topology Discovery Responder

사용Enabled

MAPI 네트워크 어댑터의 TCP/IP v4 속성은 다음과 같이 구성됩니다.The TCP/IP v4 properties for a MAPI network adapter are configured as follows:

  • DAG 구성원의 MAPI 네트워크에 대한 IP 주소는 수동으로 할당하거나 DHCP를 사용하도록 구성할 수 있습니다. DHCP를 사용할 경우 서버 IP 주소에는 영구 예약을 사용하는 것이 좋습니다.The IP address for a DAG member's MAPI network can be manually assigned or configured to use DHCP. If DHCP is used, we recommend using persistent reservations for the server's IP address.

  • 일반적으로 MAPI 네트워크는 기본 게이트웨이 하나를 사용하지만 필요하지는 않습니다.The MAPI network typically uses a default gateway, although one isn't required.

  • 하나 이상의 DNS 서버 주소를 구성해야 합니다. 중복성을 위해 여러 DNS 서버를 사용하는 것이 좋습니다.At least one DNS server address must be configured. Using multiple DNS servers is recommended for redundancy.

  • DNS에 이 연결의 주소를 등록 확인란을 선택해야 합니다.The Register this connection's addresses in DNS check box should be selected.

복제 네트워크 어댑터 구성Replication network adapter configuration

복제 네트워크에서 사용할 네트워크 어댑터는 다음 표에 설명된 대로 구성해야 합니다.A network adapter intended for use by a Replication network should be configured as described in the following table.

네트워킹 기능Networking features 설정Settings

Microsoft Networks용 클라이언트Client for Microsoft Networks

사용 안 함Disabled

QoS 패킷 스케줄러QoS Packet Scheduler

필요시 사용Optionally enabled

Microsoft Networks용 파일 및 프린터 공유File and Printer Sharing for Microsoft Networks

사용 안 함Disabled

TCP/IP v6(인터넷 프로토콜 버전 6)Internet Protocol version 6 (TCP/IP v6)

사용Enabled

TCP/IP v4(인터넷 프로토콜 버전 4)Internet Protocol version 4 (TCP/IP v4)

사용Enabled

링크 계층 토폴로지 검색 매퍼 I/O 드라이버Link-Layer Topology Discovery Mapper I/O Driver

사용Enabled

링크 계층 토폴로지 검색 응답자Link-Layer Topology Discovery Responder

사용Enabled

복제 네트워크 어댑터의 TCP/IP v4 속성은 다음과 같이 구성됩니다.The TCP/IP v4 properties for a Replication network adapter are configured as follows:

  • DAG 구성원의 복제 네트워크에 대한 IP 주소는 수동으로 할당하거나 DHCP를 사용하도록 구성할 수 있습니다. DHCP를 사용할 경우 서버 IP 주소에는 영구 예약을 사용하는 것이 좋습니다.The IP address for a DAG member's Replication network can be manually assigned or configured to use DHCP. If DHCP is used, we recommend using persistent reservations for the server's IP address.

  • 일반적으로 복제 네트워크에는 기본 게이트웨이가 없지만, MAPI 네트워크에 기본 게이트웨이가 있는 경우 다른 네트워크에 기본 게이트웨이가 있으면 안 됩니다. 복제 네트워크에서 네트워크 트래픽의 라우팅은 복제 네트워크 간을 라우팅할 수 있는 게이트웨이 주소를 사용하는 다른 DAG 구성원의 해당 네트워크에 대한 영구 고정 경로를 사용하여 구성할 수 있습니다. 이 경로와 일치하지 않는 다른 모든 트래픽은 MAPI 네트워크 어댑터에 구성된 기본 게이트웨이에서 처리합니다.Replication networks typically don't have default gateways, and if the MAPI network has a default gateway, no other networks should have default gateways. Routing of network traffic on a Replication network can be configured by using persistent, static routes to the corresponding network on other DAG members using gateway addresses that have the ability to route between the Replication networks. All other traffic not matching this route will be handled by the default gateway that's configured on the adapter for the MAPI network.

  • DNS 서버 주소는 구성하지 않아야 합니다.DNS server addresses shouldn't be configured.

  • DNS에 이 연결의 주소를 등록 확인란을 선택하면 안 됩니다.The Register this connection's addresses in DNS check box shouldn't be selected.

미러링 모니터 서버 요구 사항Witness server requirements

미러링 모니터 서버는 DAG 구성원이 짝수인 경우 쿼럼을 확보하고 유지 관리하는 데 사용되는 DAG 외부의 서버입니다.A witness server is a server outside a DAG that's used to achieve and maintain quorum when the DAG has an even number of members. 구성원이 홀수인 DAG는 미러링 모니터 서버를 사용하지 않습니다.DAGs with an odd number of members don't use a witness server. 구성원이 짝수인 DAG는 모두 미러링 모니터 서버를 사용해야 합니다.All DAGs with an even number of members must use a witness server. 미러링 모니터 서버는 Windows Server를 실행하는 모든 컴퓨터가 될 수 있습니다.The witness server can be any computer running Windows Server. 미러링 모니터 서버의 Windows Server 운영 체제 버전이 DAG 구성원에서 사용되는 운영 체제와 일치할 필요는 없습니다.There is no requirement that the version of the Windows Server operating system of the witness server matches the operating system used by the DAG members.

쿼럼은 DAG 아래에서 클러스터 레벨로 유지 관리됩니다. DAG는 구성원의 과반수가 온라인일 때 쿼럼을 갖게 되며 DAG의 다른 온라인 구성원과 통신할 수 있습니다. 이러한 쿼럼의 개념은 Windows 장애 조치(failover) 클러스터링에서의 쿼럼 개념이 갖는 한 측면입니다. 장애 조치(failover) 클러스터의 쿼럼에 관련되고 필수적인 측면이 쿼럼 리소스입니다. 쿼럼 리소스는 클러스터 상태 및 구성원 결정으로 이어지는 중재 수단을 제공하는 장애 조치(failover) 클러스터 내부의 리소스입니다. 또한 쿼럼 리소스는 구성 정보를 저장하는 영구 저장소도 제공합니다. 쿼럼 리소스와 함께 사용되는 쿼럼 로그는 클러스터에 대한 구성 데이터베이스입니다. 쿼럼 로그에는 클러스터의 구성원인 서버, 클러스터에 설치되어 있는 리소스 및 이러한 리소스의 상태(예: 온라인 또는 오프라인)와 같은 정보가 포함됩니다.Quorum is maintained at the cluster level, underneath the DAG. A DAG has quorum when the majority of its members are online and can communicate with the other online members of the DAG. This notion of quorum is one aspect of the concept of quorum in Windows failover clustering. A related and necessary aspect to quorum in failover clusters is the quorum resource. The quorum resource is a resource inside a failover cluster that provides a means for arbitration leading to cluster state and membership decisions. The quorum resource also provides persistent storage for storing configuration information. A companion to the quorum resource is the quorum log, which is a configuration database for the cluster. The quorum log contains information such as which servers are members of the cluster, what resources are installed in the cluster, and the state of those resources (for example, online or offline).

각 DAG 구성원이 DAG의 기본 클러스터 구성 방식에 대해 일관된 관점을 갖는 것이 중요합니다. 쿼럼은 클러스터와 관련 있는 모든 구성 정보를 위한 가장 확실한 리포지토리 역할을 합니다. 또한 쿼럼은 분할 브레인 현상을 방지하기 위한 연결 분리기로도 사용됩니다. 분할 브레인 현상은 DAG 구성원이 서로 통신할 수는 없지만 실행 중인 경우에 발생하는 상황입니다. 브레인 신드롬 분할은 항상 DAG 구성원의 과반수(DAG 구성원 수가 짝수인 경우 DAG 미러링 모니터 서버)를 사용 가능한 상태로 유지하고, DAG가 작동하도록 상호 작용하게 함으로써 방지할 수 있습니다.It's critical that each DAG member have a consistent view of how the DAG's underlying cluster is configured. The quorum acts as the definitive repository for all configuration information relating to the cluster. The quorum is also used as a tie-breaker to avoid split-brain syndrome. Split brain syndrome is a condition that occurs when DAG members can't communicate with each other but are running. Split brain syndrome is prevented by always requiring a majority of the DAG members (and in the case of DAGs with an even number of member, the DAG witness server) to be available and interacting for the DAG to be operational.

사이트 복구 계획Planning for site resilience

날마다 점점 더 많은 기업들이 안정적이고 가용성 높은 메시징 시스템을 갖추는 것이 비즈니스를 성공으로 이끄는 필수 요소라는 사실을 인식하고 있습니다. 상당수의 조직에서 메시징 시스템은 업무 지속 계획의 일부이며, 메시징 서비스 배포 또한 사이트 복구를 고려하여 디자인됩니다. 기본적으로 대부분의 사이트 복구 솔루션은 보조 데이터 센터에서의 하드웨어 배포를 포함합니다.Every day, more businesses recognize that access to a reliable and available messaging system is fundamental to their success. For many organizations, the messaging system is part of the business continuity plans, and their messaging service deployment is designed with site resilience in mind. Fundamentally, many site resilient solutions involve the deployment of hardware in a second datacenter.

궁극적으로, DAG 구성원의 수와 사서함 데이터베이스 복사본의 수를 비롯한 DAG의 전체 디자인은 다양한 오류 시나리오에 적용될 수 있는 각 조직의 복구 SLA(서비스 수준 계약)에 따라 달라집니다. 계획 단계에서 솔루션 설계자와 관리자는 사이트 복구를 위한 특정 요구 사항을 포함하여, 배포에 필요한 요구 사항을 확인합니다. 즉 사용할 위치와 필요한 복구 SLA 대상을 확인합니다. SLA는 고가용성 및 사이트 복구를 제공하는 솔루션 디자인에 대한 기본 사항인 두 가지 특정 요소, 복구 시간 목표와 복구 지점 목표입니다. 이 값은 모두 분 단위 시간으로 정해집니다. 복구 시간 목표는 서비스를 복원하는 데 걸리는 시간을 의미하고, 복구 지점 목표는 복구 작업이 완료된 후 데이터가 얼마나 최신 상태인지를 나타냅니다. 또한 SLA는 문제가 해결된 후 기본 데이터 센터가 완전한 서비스를 제공하도록 복원하기 위해서도 정의됩니다.Ultimately, the overall design of a DAG, including the number of DAG members and the number of mailbox database copies, will depend on each organization's recovery service level agreements (SLAs) that cover various failure scenarios. During the planning stage, the solution's architects and administrators identify the requirements for the deployment, including in particular the requirements for site resilience. They identify the locations to be used and the required recovery SLA targets. The SLA will identify two specific elements that should be the basis for the design of a solution that provides high availability and site resilience: the recovery time objective and the recovery point objective. Both of these values are measured in minutes. The recovery time objective is how long it takes to restore service. The recovery point objective refers to how current the data is after the recovery operation has completed. An SLA may also be defined for restoring the primary datacenter to full service after its problems are corrected.

솔루션 설계자와 관리자는 사이트 복구 보호가 필요한 사용자 집합을 확인하고, 다중 사이트 솔루션을 활성/수동 상태로 구성할지, 활성/활성 상태로 구성할지 결정합니다. 활성/수동 구성의 경우, 일반적으로 대기 데이터 센터에서는 사용자를 호스트하지 않습니다. 활성/활성 구성에서는 사용자를 두 곳에서 호스트하고, 솔루션에 포함된 데이터베이스 중 일부의 기본 설정 활성 위치가 보조 데이터 센터에 있습니다. 한 데이터 센터의 사용자에 대한 서비스가 실패하면 이 사용자들은 다른 데이터 센터에서 활성화됩니다.The solution's architects and administrators will also identify which set of users require site resilience protection, and determine if the multiple site solution will be an active/passive or active/active configuration. In an active/passive configuration, no users are normally hosted in the standby datacenter. In an active/active configuration, users are hosted in both locations, and some percentage of the total number of databases within the solution has a preferred active location in a second datacenter. When service for the users of one datacenter fails, those users are activated in the other datacenter.

적절한 SLA를 구성하려면 다음 기본 질문에 답해야 합니다.Constructing the appropriate SLAs often requires answering the following basic questions:

  • 기본 데이터 센터에 오류가 발생할 경우 필요한 서비스 수준은 무엇입니까?What level of service is required after the primary datacenter fails?

  • 사용자에게 자신의 데이터가 필요합니까 아니면 메시징 서비스만 필요합니까?Do users need their data or just messaging services?

  • 어느 정도나 빠르게 데이터가 필요합니까?How rapidly is data required?

  • 지원해야 하는 사용자 수는 몇 명입니까?How many users must be supported?

  • 사용자가 자신의 데이터에 어떻게 액세스합니까?How will users access their data?

  • 대기 데이터 센터 활성화 SLA란 무엇입니까?What is the standby datacenter activation SLA?

  • 서비스를 기본 데이터 센터로 다시 이동하는 방법은 무엇입니까?How is service moved back to the primary datacenter?

  • 리소스가 사이트 복구 솔루션 전용입니까?Are the resources dedicated to the site resilience solution?

이러한 질문에 답함으로써 메시징 솔루션을 위한 사이트 복구 디자인의 기본 틀을 갖출 수 있습니다. 사이트 오류 복구의 핵심 요구 사항은 백업 메시징 서비스를 호스트하는 백업 데이터 센터로 필요한 메시징 데이터를 가져오는 솔루션을 만드는 것입니다.By answering these questions, you begin to shape a site resilient design for your messaging solution. A core requirement of recovery from site failure is to create a solution that gets the necessary data to the backup datacenter that hosts the backup messaging service.

인증서 계획Certificate planning

단일 데이터 센터에 DAG를 배포하는 경우에는 인증서 디자인에 대해 특별히 고려할 점이 없습니다. 그러나 사이트 복구 구성에서 여러 데이터 센터로 DAG를 확장할 때는 인증서와 관련된 특정 고려 사항이 있습니다. 일반적으로 인증서 디자인은 사용 중인 클라이언트를 비롯하여, 인증서를 사용하는 다른 응용 프로그램에 의한 인증서 요구 사항에 따라 결정됩니다. 그러나 인증서의 유형과 개수에 관해 반드시 따라야 할 특정 권장 사항 및 모범 사례가 있습니다.There are no unique or special design considerations for certificates when deploying a DAG in a single datacenter. However, when extending a DAG across multiple datacenters in a site resilient configuration, there are some specific considerations with respect to certificates. Generally, your certificate design will depend on the clients in use, as well as the certificate requirements by other applications that use certificates. But there are some specific recommendations and best practices you should follow with respect to the type and number of certificates.

Exchange 서버 및 역방향 프록시 서버에 사용하는 인증서의 수를 최소화하는 것이 가장 좋습니다. 또한 각 데이터 센터에서 이들 서비스의 끝점에 한 인증서를 사용하는 것이 좋습니다. 이러한 접근 방식을 통해 필요한 인증서 수를 최소화하고, 솔루션의 비용과 복잡성을 동시에 줄일 수 있습니다.As a best practice, you should minimize the number of certificates you use for your Exchange servers and reverse proxy servers. We recommend using a single certificate for all of these service endpoints in each datacenter. This approach minimizes the number of certificates that are needed, which reduces both cost and complexity for the solution.

외부에서 Outlook 사용 클라이언트의 경우, 각 데이터 센터에 한 가지 SAN(주체 대체 이름)을 사용하고 인증서에 여러 호스트 이름을 포함하는 것이 좋습니다. 데이터베이스, 서버 또는 데이터 센터 전환 후 외부에서 Outlook 사용 연결을 확인하려면 각 인증서에 동일한 인증서 사용자 이름을 사용하고, Microsoft 표준 형식(msstd)에 동일한 사용자 이름으로 Outlook 공급자 구성 개체 Active Directory를 구성해야 합니다. 예를 들어, 인증서 사용자 이름 mail.contoso.com을 사용하는 경우 특성을 다음과 같이 구성합니다.For Outlook Anywhere clients, we recommend that you use a single subject alternative name (SAN) certificate for each datacenter, and include multiple host names in the certificate. To ensure Outlook Anywhere connectivity after a database, server, or datacenter switchover, you must use the same Certificate Principal Name on each certificate, and configure the Outlook Provider Configuration object in Active Directory with the same Principal Name in Microsoft-Standard Form (msstd). For example, if you use a Certificate Principal Name of mail.contoso.com, you would configure the attribute as follows.

Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

Exchange와 통합되는 일부 응용 프로그램에는 추가 인증서를 사용해야 할 수도 있는 특정 인증서 요구 사항이 있습니다. Exchange 2013은 OCS(Office Communications Server)와 함께 사용할 수 있습니다. OCS에는 인증서 사용자 이름에 OCS 서버 이름을 사용하는 1024비트 이상의 인증서가 필요합니다. 인증서 사용자 이름에 OCS 서버 이름을 사용하면 외부에서 Outlook 사용이 제대로 작동하지 않으므로, OCS 환경에 별도의 추가 인증서를 사용해야 합니다.Some applications that integrate with Exchange have specific certificate requirements that may require using additional certificates. Exchange 2013 can co-exist with Office Communications Server (OCS). OCS requires certificates with 1024-bit or greater certificates that use the OCS server name for the Certificate Principal Name. Because using an OCS server name for the Certificate Principal Name would prevent Outlook Anywhere from working properly, you would need to use an additional and separate certificate for the OCS environment.

네트워크 계획Network planning

각 DAG에서 충족해야 할 특정 네트워킹 요구 사항과 더불어, DAG의 구성원인 각 서버에 대해서는 사이트 복구 구성에 한정되는 일부 요구 사항과 권장 사항이 있습니다. 모든 DAG와 마찬가지로 DAG 구성원이 단일 사이트에 배포되어 있든, 여러 사이트에 배포되어 상관없이 DAG 구성원 간의 왕복 반환 네트워크 대기 시간은 500밀리초 이하여야 합니다. 또한 여러 사이트로 확장된 DAG에 권장되는 특정 구성 설정도 있습니다.In addition to the specific networking requirements that must be met for each DAG, as well as for each server that's a member of a DAG, there are some requirements and recommendations that are specific to site resilience configurations. As with all DAGs, whether the DAG members are deployed in a single site or in multiple sites, the round-trip return network latency between DAG members must be no greater than 500 milliseconds. In addition, there are specific configuration settings that are recommended for DAGs that are extended across multiple sites:

  • Mapi 네트워크를 복제 네트워크에서 격리 해야 합니다. windows 네트워크 정책, windows 방화벽 정책 또는 라우터 acl (액세스 제어 목록)을 사용 하 여 Mapi 네트워크나 복제 네트워크 간의 트래픽을 차단 해야 합니다.MAPI networks should be isolated from Replication networks: Windows network policies, Windows firewall policies, or router access control lists (ACLs) should be used to block traffic between the MAPI network and the Replication networks. 이 구성은 네트워크 하트비트 혼선을 막는 데 필요합니다.This configuration is necessary to prevent network heartbeat cross talk.

  • 클라이언트 연결 DNS 레코드는 TTL (Time To Live) 값을 5 분으로 설정 해야 합니다. 클라이언트 환경에서 전환이 일어나는 속도 뿐 아니라 DNS 복제가 발생 하는 속도와 쿼리를 수행 하는 시간에 대 한 의존도가 전적으로 좌우 됩니다. DNS 정보가 업데이트 되었습니다.Client-facing DNS records should have a Time to Live (TTL) value of 5 minutes: The amount of downtime that clients experience is dependent not just on how quickly a switchover can occur, but also on how quickly DNS replication occurs and the clients query for updated DNS information. Outlook Web App, Exchange ActiveSync, Exchange 웹 서비스, 외부에서 Outlook 사용, SMTP, POP3 및 IMAP4를 비롯 한 모든 Exchange 클라이언트 서비스에 대 한 DNS 레코드는 5 분의 TTL로 설정 해야 합니다.DNS records for all Exchange client services, including Outlook Web App, Exchange ActiveSync, Exchange Web services, Outlook Anywhere, SMTP, POP3, and IMAP4 in both the internal and external DNS servers should be set with a TTL of 5 minutes.

  • 고정 경로를 사용 하 여 복제네트워크 간의 연결을 구성 합니다. 각 복제 네트워크 어댑터 간에 네트워크 연결을 제공 하려면 영구 고정 경로를 사용 합니다.Use static routes to configure connectivity across Replication networks: To provide network connectivity between each of the Replication network adapters, use persistent static routes. 이는 고정 IP 주소를 사용할 때 각 DAG 구성원에게 수행되는 신속한 일회성 구성입니다.This is a quick and one-time configuration that's performed on each DAG member when using static IP addresses. DHCP를 사용하여 복제 네트워크의 IP 주소를 가져오는 중이면 DHCP를 복제 네트워크의 고정 경로를 지정하는 데에도 사용할 수 있으므로 구성 프로세스가 간소화됩니다.If you're using DHCP to obtain IP addresses for your Replication networks, you can also use it to assign static routes for the replication, thereby simplifying the configuration process.

일반 사이트 복구 계획General site resilience planning

고가용성의 경우 위에서 언급한 요구 사항 외에도, 사이트 복구 구성에 Exchange 2013을 배포(예: 여러 데이터 센터로 DAG 확장)하기 위한 다른 권장 사항이 있습니다. 계획 단계에서의 작업은 사이트 복구 솔루션의 성공과 직결됩니다. 예를 들어 네임스페이스 디자인이 부실하면 인증서와 관련된 문제를 유발할 수 있으며, 인증서 구성이 올바르지 않으면 사용자가 서비스에 액세스할 수 없습니다.In addition to the requirements listed above for high availability, there are other recommendations for deploying Exchange 2013 in a site resilient configuration (for example, extending a DAG across multiple datacenters). What you do during the planning phase will directly affect the success of your site resilience solution. For example, poor namespace design can cause difficulties with certificates, and an incorrect certificate configuration can prevent users from accessing services.

보조 데이터 센터를 활성화하는 데 걸리는 시간을 최소화하고, 보조 데이터 센터에서 오류가 발생한 데이터 센터의 서비스 끝점을 호스팅하려면 적절한 계획이 완료되어야 합니다. 예를 들면 다음과 같습니다.To minimize the time it takes to activate a second datacenter, and allow the second datacenter to host the service endpoints of a failed datacenter, the appropriate planning must be completed. The following are examples:

  • 사이트 복구 솔루션의 SLA 목표는 잘 파악하여 문서화해야 합니다.The SLA goals for the site resilience solution must be well understood and documented.

  • 보조 데이터 센터의 서버는 두 데이터 센터의 사용자를 호스트할 만큼의 충분한 용량을 갖추어야 합니다.The servers in the second datacenter must have sufficient capacity to host the combined user population of both datacenters.

  • 서비스가 사이트 복구 SLA의 일부로 포함되지 않은 경우 외에는 보조 데이터 센터가 기본 데이터 센터에서 제공하는 서비스를 모두 제공해야 합니다. 여기에는 Active Directory, 네트워킹 인프라(예: DNS, TCP/IP 등), 전화 통신 서비스(통합 메시징을 사용 중인 경우) 및 사이트 인프라(예: 전력, 냉각 등)가 포함됩니다.The second datacenter must have all services enabled that are provided in the primary datacenter (unless the service isn't included as part of the site resilience SLA). This includes Active Directory, networking infrastructure (for example, DNS or TCP/IP), telephony services (if Unified Messaging is in use), and site infrastructure (such as power or cooling).

  • 오류가 발생한 데이터 센터의 서비스 사용자에게 일부 서비스를 제공하려면 적절한 서버 인증서가 구성되어 있어야 합니다. POP3 및 IMAP4 등의 일부 서비스는 인스턴싱을 허용하지 않고 단일 인증서만 사용하도록 허용합니다. 이런 경우 인증서가 여러 이름이 포함된 SAN 인증서이거나, 조직의 보안 정책이 와일드카드 인증서를 사용하도록 허용한다는 가정하에 여러 이름이 와일드카드 인증서를 사용할 수 있을 정도로 아주 유사해야 합니다.For some services to be able to service users from the failed datacenter, they must have the proper server certificates configured. Some services don't allow instancing (for example, POP3 and IMAP4) and only allow the use of a single certificate. In these cases, either the certificate must be a SAN certificate that includes multiple names, or the multiple names must be similar enough so that a wildcard certificate can be used (assuming the security policies of the organization allows the use of wildcard certificates).

  • 필요한 서비스를 보조 데이터 센터에 정의해야 합니다.The necessary services must be defined in the second datacenter. 예를 들어 첫 번째 데이터 센터에 서로 다른 전송 서버에 세 개의 SMTP 대상이 있는 경우 두 번째 데이터 센터에 해당 구성을 정의 하 여 작업 부하를 호스트 하는 하나 이상의 전송 서버를 사용 하도록 설정 해야 합니다.For example, if the first datacenter has three different SMTP destinations on different transport servers, the appropriate configuration must be defined in the second datacenter to enable at least one (if not all three) transport server to host the workload.

  • 필요한 네트워크 구성은 데이터 센터 전환을 지원할 준비가 되어 있어야 합니다. 이는 부하 분산 구성이 준비되어 있고, 전역 DNS가 구성되어 있으며, 라우팅이 적절하게 구성된 인터넷에 연결할 수 있어야 한다는 의미입니다.The necessary network configuration must be in place to support the datacenter switchover. This might mean making sure that the load balancing configurations are in place, that global DNS is configured, and that the Internet connection is enabled with the appropriate routing configured.

  • 데이터 센터 전환에 필요한 DNS를 변경할 수 있도록 하는 전략을 이해해야 합니다. TTL 설정을 비롯한 특정 DNS 변경 사항은 시행 중인 SLA를 지원하도록 정의되고 문서화되어야 합니다.The strategy for enabling the DNS changes necessary for a datacenter switchover must be understood. The specific DNS changes, including their TTL settings, must be defined and documented to support the SLA in effect.

  • 솔루션 테스트 전략을 수립하고 SLA에 반영해야 합니다. 정기적으로 배포를 검사하는 것만이 오랫동안 배포 품질과 실행 가능성의 수준을 저하시키지 않는 유일한 방법입니다. 배포의 유효성을 검사한 후에는 솔루션의 성공에 직접적인 영향을 주는 구성 부분을 명시적으로 문서화하고, 해당 배포 요소에 대한 변경 관리 프로세스를 강화하는 것이 좋습니다.A strategy for testing the solution must also be established and factored into the SLA. Periodic validation of the deployment is the only way to guarantee that the quality and viability of the deployment doesn't degrade over time. After the deployment is validated, we recommend that the part of the configuration that directly affects the success of the solution be explicitly documented. In addition, we recommend that you enhance your change management processes around those segments of the deployment.