Exchange Server 데이터베이스 가용성 그룹 관리

  • 아티클

DAG(데이터베이스 가용성 그룹)는 데이터베이스/서버/네트워크 오류에서 데이터베이스 수준 자동 복구를 제공하는 최대 16개 Exchange 사서함 서버 집합입니다. DAG는 연속 복제 및 Windows 장애 조치(failover) 클러스터링 기술의 하위 집합을 사용하여 고가용성 및 사이트 복구를 제공합니다. DAG의 사서함 서버는 오류가 있는지 상호 모니터링합니다. 사서함 서버가 DAG에 추가되면 해당 서버는 DAG의 다른 서버와 함께 작동하여 데이터베이스 오류로부터 자동 데이터베이스 수준 복구를 제공합니다.

DAG를 만든 경우 초기에는 비어 있습니다. DAG에 첫 번째 서버를 추가하는 경우 해당 DAG에 대한 장애 조치(failover) 클러스터가 자동으로 만들어집니다. 또한 서버에서 네트워크 또는 서버 오류를 모니터링하는 인프라가 시작됩니다. 장애 조치(failover) 클러스터 하트비트 메커니즘 및 클러스터 데이터베이스는 데이터베이스 탑재 상태, 복제 상태 및 마지막으로 탑재된 위치와 같이 빠르게 변경될 수 있는 DAG에 대한 정보를 추적하고 관리하는 데 사용됩니다.

DAG 만들기

DAG는 EAC(Exchange 관리 센터)의 새 데이터베이스 가용성 그룹 마법사를 사용하거나 Exchange 관리 셸에서 New-DatabaseAvailabilityGroup cmdlet을 실행하여 만들 수 있습니다. DAG를 만들 때 DAG의 이름과 선택적 미러링 모니터 서버 및 감시 디렉터리 설정을 제공합니다. 또한 고정 IP 주소를 사용하거나, DAG에서 DHCP(Dynamic Host Configuration Protocol)를 통해 필요한 IP 주소를 자동으로 할당하도록 하여 DAG에 IP 주소를 하나 이상 할당할 수 있습니다. DatabaseAvailabilityGroupIpAddresses 매개 변수를 사용하여 DAG에 IP 주소를 수동으로 할당할 수 있습니다. 이 매개 변수를 생략하면 DAG는 네트워크에서 DHCP 서버를 사용하여 IP 주소를 가져옵니다.

Windows Server 2012 R2를 실행하는 사서함 서버를 포함하는 DAG를 만드는 경우 클러스터 관리 액세스 지점 없이 DAG를 만드는 옵션도 있습니다. 이 경우 클러스터에 Active Directory에 CNO(클러스터 이름 개체)가 없으며 클러스터 핵심 리소스 그룹에는 네트워크 이름 리소스 또는 IP 주소 리소스가 포함되지 않습니다.

DAG를 만드는 방법에 대한 자세한 단계는 데이터베이스 가용성 그룹 만들기를 참조하세요.

DAG를 만들 때 지정한 이름으로 DAG를 나타내는 빈 개체와 msExchMDBAvailabilityGroup 의 개체 클래스가 Active Directory에 만들어집니다.

DAG는 Windows Server 2008 R2 이상에서 클러스터 하트비트, 클러스터 네트워크 및 클러스터 데이터베이스와 같은 Windows 장애 조치(failover) 클러스터링 기술의 하위 집합을 사용합니다(데이터베이스 상태가 활성에서 수동 또는 역방향으로 변경되거나 탑재에서 분리 또는 역방향으로 변경되거나 변경될 수 있는 데이터를 저장하기 위해). 따라서 Windows 장애 조치(failover) 클러스터링 포함하는 지원되는 Windows 버전에 설치된 Exchange 사서함 서버에서만 DAG를 만들 수 있습니다.

참고

DAG에서 만들어 사용하는 장애 조치(failover) 클러스터는 해당 DAG 전용으로 사용해야 합니다. 해당 클러스터를 기타 고가용성 솔루션이나 다른 용도로 사용할 수 없습니다. 예를 들어, 장애 조치(failover) 클러스터를 다른 응용 프로그램이나 서비스를 클러스터링하는 데 사용할 수 없습니다. DAG 이외의 목적으로 DAG의 기본 장애 조치(failover) 클러스터를 사용하는 것은 지원되지 않습니다.

DAG 미러링 모니터 서버 및 감시 디렉터리

DAG를 만들 때 Active Directory 포리스트 내에서 고유한 15자를 초과하지 않는 DAG의 이름을 지정해야 합니다. 또한 각 DAG는 미러링 모니터 서버 및 감시 디렉터리로 구성됩니다. 미러링 모니터 서버 및 해당 디렉터리 는 DAG에 짝수 멤버가 있는 경우에만 사용되며 쿼럼 용도로만 사용됩니다. 감시 디렉터리를 미리 만들 필요는 없습니다. Exchange는 미러링 모니터 서버에서 사용자에게 필요한 디렉터리를 자동으로 만들고 보안합니다. 미러링 모니터 서버 이외의 용도로 미러링 모니터 서버는 사용하지 않아야 합니다.

참고

데이터베이스 미러링 토폴로지에서 "미러링 모니터 서버"라는 세 번째 서버를 가질 수 있습니다. 미러링 모니터 서버는 보안 주 서버에서 미러 서버로 자동 장애 조치(failover)를 사용하도록 설정하거나 그 반대의 경우도 마찬가지입니다. 보안 주 서버 및 미러 서버와 달리 미러링 모니터 서버는 데이터베이스를 제공하지 않습니다. 미러링 모니터 서버의 역할은 지정된 파트너 서버가 작동 중인지 여부를 확인하는 것입니다. 자동 장애 조치(failover)를 지원하는 것은 미러링 모니터 서버의 유일한 함수이며 주 복사본을 보유하는 서버와 데이터베이스의 미러 복사본을 보유하는 서버를 식별합니다.

미러링 모니터 서버에 대한 요구 사항은 다음과 같습니다.

  • 미러링 모니터 서버는 DAG의 구성원일 수 없습니다.

  • 미러링 모니터 서버는 DAG와 동일한 Active Directory 포리스트에 있어야 합니다.

  • 미러링 모니터 서버가 Windows Server 2008 이상을 실행해야 합니다.

  • 단일 서버는 여러 DAG에 대한 감시 역할을 할 수 있습니다. 그러나 각 DAG에는 자체 미러링 모니터 서버 디렉터리가 필요합니다.

미러링 모니터 서버로 사용되는 서버와 관계없이 의도한 미러링 모니터 서버에서 Windows 방화벽을 사용하도록 설정한 경우 파일 및 프린터 공유에 Windows 방화벽 예외를 사용하도록 설정해야 합니다. 미러링 모니터 서버는 SMB 포트 445를 사용합니다.

중요

지정한 미러링 모니터 서버가 Exchange 2010 이상 서버가 아닌 경우 DAG를 만들기 전에 미러링 모니터 서버의 로컬 관리자 그룹에 EXCHANGE 신뢰할 수 있는 하위 시스템 유니버설 보안 그룹(USG)을 추가해야 합니다. Exchange에서 필요에 따라 미러링 모니터 서버에 디렉터리를 만들고 공유할 수 있도록 하려면 이러한 보안 권한이 필요합니다.

미러링 모니터 서버 또는 감시 디렉터리는 모두 내결함성을 갖출 필요가 없으며 중복성 또는 고가용성 형식을 사용하지 않아도 됩니다. 미러링 모니터 서버의 경우 클러스터된 파일 서버와 기타 복구 양식을 사용하지 않아도 됩니다. 여기에는 다양한 원인이 있습니다. DAG 규모가 큰 경우(예: 6명 이상) 오류가 여러 개 있어야 미러링 모니터 서버가 필요합니다. 구성원이 6명인 DAG는 쿼럼을 손실하지 않고 최대 2개의 Voter 오류를 감당할 수 있으므로 3 Voter가 실패하면 미러링 모니터 서버가 쿼럼을 유지 관리해야 합니다. 또한 현재 미러링 모니터 서버에 영향을 미치는 오류가 발생하는 경우(예: 하드웨어 오류로 인해 미러링 모니터 서버 손실) Set-DatabaseAvailabilityGroup cmdlet을 사용하여 쿼럼이 있는 경우 새 미러링 모니터 서버와 감시 디렉터리를 구성합니다.

참고

미러링 모니터 서버에서 저장소가 손실되었거나 사용자가 감시 디렉터리 또는 공유 권한을 변경한 경우 Set-DatabaseAvailabilityGroup cmdlet을 사용하여 원래 위치에 미러링 모니터 서버와 감시 디렉터리를 구성할 수도 있습니다.

미러링 모니터 서버 배치 고려 사항

DAG의 미러링 모니터 서버 배치는 비즈니스 요구 사항과 조직에서 사용 가능한 옵션에 따라 달라집니다. 이제 Exchange에는 권장되지 않거나 Exchange 2010에서 사용할 수 없는 새 DAG 구성 옵션에 대한 지원이 포함됩니다. 이러한 옵션에는 세 번째 데이터 센터, 지점 또는 Microsoft Azure 가상 네트워크와 같은 세 번째 위치 사용이 포함됩니다.

다음 표에는 다양한 배포 시나리오에 대한 일반적인 미러링 모니터 서버 배치 권장 사항이 나열되어 있습니다.

배포 시나리오 권장 사항
단일 데이터 센터에 배포된 단일 DAG DAG 구성원과 동일한 데이터 센터에 미러링 모니터 서버 찾기
두 데이터 센터에 배포된 단일 DAG(추가 위치 사용 불가능) 자동 데이터 센터 장애 조치(failover)를 사용하도록 설정하기 위해 Microsoft Azure 가상 네트워크에서 미러링 모니터 서버 찾기 또는

기본 데이터 센터에 미러링 모니터 서버 찾기
단일 데이터 센터에 배포된 여러 DAG DAG 구성원과 동일한 데이터 센터에서 미러링 모니터 서버 찾기. 추가 옵션:
  • 여러 DAG에 동일한 미러링 모니터 서버 사용
  • 다른 DAG에 하나의 미러링 모니터 서버 역할을 하는 한 개의 DAG 구성원 사용
두 데이터 센터에 배포된 여러 DAG 자동 데이터 센터 장애 조치(failover)를 사용하도록 설정하기 위해 Microsoft Azure 가상 네트워크에서 미러링 모니터 서버 찾기 또는

각 DAG에 대해 기본으로 간주되는 데이터 센터에서 미러링 모니터 서버 찾기. 추가 옵션:

  • 여러 DAG에 동일한 미러링 모니터 서버 사용
  • 다른 DAG에 하나의 미러링 모니터 서버 역할을 하는 한 개의 DAG 구성원 사용
셋 이상의 데이터 센터에 배포된 단일 또는 여러 DAG 이 구성에서 미러링 모니터 서버는 쿼럼 응답의 대부분이 있기를 원하는 데이터 센터에 배치해야 함

두 데이터 센터에 DAG가 배포된 경우 이제 미러링 모니터 서버 호스팅에 세 번째 위치를 사용할 수 있습니다. organization DAG가 배포되는 두 데이터 센터에 영향을 주는 네트워크 오류로부터 격리된 네트워크 인프라가 있는 세 번째 위치가 있는 경우 해당 세 번째 위치에 DAG의 감시 서버를 배포하여 데이터 센터 수준 오류 이벤트에 대응하여 데이터베이스를 다른 데이터 센터에 자동으로 장애 조치(failover)하는 기능을 사용하여 DAG를 구성할 수 있습니다. organization 두 개의 물리적 위치만 있는 경우 Microsoft Azure 가상 네트워크를 세 번째 위치로 사용하여 감시 서버를 배치할 수 있습니다.

DAG를 만드는 동안 미러링 모니터 서버 및 감시 디렉터리 지정

DAG를 만들 때 DAG의 이름을 제공해야 합니다. 선택적으로 미러링 모니터 서버와 디렉터리를 지정할 수도 있습니다.

DAG를 만들 때 다음과 같은 옵션과 동작 조합을 사용할 수 있습니다.

  • DAG의 이름만 지정하고 미러링 모니터 서버 및 미러링 모니터 서버 디렉터리 필드를 비워 둘 수 있습니다. 이 시나리오에서 마법사는 로컬 Active Directory 사이트에서 사서함 서버가 설치되지 않은 클라이언트 액세스 서버를 검색하고 해당 서버에서 기본 디렉터리(%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) 및 기본 공유(<DAGFQDN>)를 자동으로 만들고 해당 클라이언트 액세스 서버를 미러링 모니터 서버로 사용합니다. 예를 들어 운영 체제가 C 드라이브에 설치된 미러링 모니터 서버 CAS3을 고려합니다. contoso.com 도메인의 DAG1이라는 DAG는 \CAS3\DAG1.contoso.com 공유되는 C:\DAGFileShareWitnesses\DAG1.contoso.com 기본 미러링 모니터 서버 디렉터리를 사용합니다.

  • 미러링 모니터 서버에 만들고 공유할 디렉터리, 사용할 미러링 모니터 서버 및 DAG의 이름을 지정할 수 있습니다.

  • DAG의 이름을 지정하고 사용할 미러링 모니터 서버를 지정하고 감시 디렉터리 필드를 비워 둡니다. 이 시나리오에서 마법사는 지정된 미러링 모니터 서버에 기본 디렉터리를 만듭니다.

  • DAG의 이름을 지정하고, 미러링 모니터 서버 필드를 비워 두고, 미러링 모니터 서버에서 만들고 공유할 디렉터리를 지정할 수 있습니다. 이 시나리오에서 마법사는 사서함 서버 역할이 설치되지 않은 클라이언트 액세스 서버를 검색하고, 해당 서버에 지정된 DAG를 자동으로 만들고 해당 디렉터리를 공유하며, 이 클라이언트 액세스 서버를 미러링 모니터 서버로 사용합니다.

DAG가 구성되면 처음에는 노드 과반수 쿼럼 모델이 사용됩니다. 두 번째 사서함 서버가 DAG에 추가되면 쿼럼은 자동으로 노드 및 파일 공유 과반수 쿼럼 모델로 변경됩니다. 이러한 변경이 발생하면 DAG의 클러스터는 쿼럼을 유지 관리하기 위해 미러링 모니터 서버를 사용하기 시작합니다. 감시 디렉터리가 없는 경우 Exchange에서 자동으로 감시 디렉터리를 만들고, 공유하고, 이 공유에 DAG CNO 컴퓨터 계정에 대한 모든 권한을 프로비전합니다.

참고

DFS(분산 파일 시스템) 네임스페이스의 일부인 파일 공유는 사용할 수 없습니다.

DAG가 만들어지기 전에 Windows 방화벽이 미러링 모니터 서버에서 활성화되면 DAG의 생성을 방해할 수 있습니다. Exchange는 Windows WMI(Windows Management Instrumentation)를 사용하여 미러링 모니터 서버에 디렉터리 및 파일 공유를 만듭니다. Windows 방화벽이 미러링 모니터 서버에서 활성화되고 WMI에 방화벽 예외가 구성되어 있지 않으면 New-DatabaseAvailabilityGroup cmdlet은 오류로 인해 실패합니다. 미러링 모니터 서버가 아닌 미러링 모니터 서버 디렉터리를 지정하면 다음 오류 메시지가 표시됩니다.

The task was unable to create the default witness directory on server <Server Name>. Please manually specify a witness directory.

미러링 모니터 서버 및 미러링 모니터 서버 디렉터리를 지정하면 다음과 같은 경고 메시지가 표시됩니다.

Unable to access file shares on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: The network path was not found.

DAG가 만들어진 후 서버가 추가되기 전에 미러링 모니터 서버에서 Windows 방화벽이 활성화되면 DAG 구성원의 추가나 제거를 방해할 수 있습니다. 미러링 모니터 서버에서 Windows 방화벽을 사용하도록 설정하고 WMI에 대해 구성된 방화벽 예외가 없는 경우 Add-DatabaseAvailabilityGroupServer cmdlet에 다음 경고 메시지가 표시됩니다.

Failed to create file share witness directory 'C:\DAGFileShareWitnesses\DAG_FQDN' on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: WMI exception occurred on server '<ServerName>': The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

이전 오류 및 경고를 resolve 다음 단계 중 하나를 수행합니다.

  • 미러링 모니터 서버에 감시 디렉터리를 수동으로 생성하여 공유하고 해당 디렉터리 및 공유의 DAG 모든 권한에 대해 CNO를 지정합니다.

  • Windows 방화벽에서 WMI 예외를 허용하도록 설정합니다.

  • Windows 방화벽을 사용하지 않도록 설정합니다.

DAG 구성원

DAG를 만든 후에는 EAC의 데이터베이스 가용성 그룹 관리 마법사 또는 Exchange Management Shell의 Add-DatabaseAvailabilityGroupServer 또는 Remove-DatabaseAvailabilityGroupServer cmdlet을 사용하여 DAG에서 서버를 추가하거나 제거할 수 있습니다. DAG 멤버 자격을 관리하는 방법에 대한 자세한 단계는 데이터베이스 가용성 그룹 멤버 자격 관리를 참조하세요.

참고

DAG의 구성원인 각 사서함 서버는 DAG에 사용되는 기본 클러스터의 노드이기도 합니다. 따라서 사서함 서버는 언제든지 하나의 DAG 멤버일 수 있습니다.

DAG에 추가할 사서함 서버에 장애 조치(failover) 클러스터링 구성 요소가 설치되어 있지 않은 경우 서버를 추가하기 위해 사용되는 방법(예: Add-DatabaseAvailabilityGroupServer cmdlet 또는 데이터베이스 가용성 그룹 관리 마법사)을 통해 장애 조치(failover) 클러스터링 기능이 설치됩니다.

첫 번째 사서함 서버가 DAG에 추가되면 다음 이벤트가 발생합니다.

  • Windows 장애 조치(failover) 클러스터링 구성 요소가 아직 설치되지 않았으면 설치됩니다.

  • 장애 조치(failover) 클러스터가 DAG 이름을 사용하여 만들어집니다. 이 장애 조치(failover)는 DAG에서 단독으로 사용되며 해당 클러스터는 DAG에 전용으로 사용되어야 합니다. 기타 다른 목적을 위해 클러스터를 사용하는 것은 지원되지 않습니다.

  • CNO는 기본 컴퓨터 컨테이너에서 만들어집니다.

  • DAG의 이름 및 IP 주소가 DNS(Domain Name System)의 호스트 (A) 레코드로 등록됩니다.

  • Active Directory에서 서버가 DAG 개체에 추가됩니다.

  • 클러스터 데이터베이스가 추가된 서버에 탑재된 데이터베이스의 정보로 업데이트됩니다.

대규모 또는 다중 사이트 환경에서, 특히 DAG가 다중 Active Directory 사이트로 확장된 경우, 첫 번째 DAG 구성원을 포함하는 DAG 개체의 Active Directory 복제가 완료될 때까지 기다려야 합니다. 이 Active Directory 개체가 환경 전체에 복제되지 않으면 두 번째 서버를 추가하면 DAG에 대한 새 클러스터(및 새 CNO)가 만들어질 수 있습니다. 이 생성은 DAG 개체가 추가되는 두 번째 멤버의 관점에서 비어 있는 것처럼 표시되어 Add-DatabaseAvailabilityGroupServer cmdlet이 이러한 개체가 이미 존재하더라도 DAG에 대한 클러스터 및 CNO를 만들기 때문입니다. 첫 번째 DAG 서버를 포함하는 DAG 개체가 복제되었는지 알아보려면 추가되는 두 번째 서버에서 Get-DatabaseAvailabilityGroup cmdlet을 사용하여, 추가한 첫 번째 서버가 DAG의 구성원으로 표시되는지를 확인합니다.

두 번째 및 후속 서버가 DAG에 추가되면 다음 이벤트가 발생합니다.

  • 서버가 DAG용 Windows 장애 조치(failover) 클러스터에 가입됩니다.

  • 쿼럼 모델이 자동으로 조정됩니다.

    • 구성원이 홀수인 DAG에 노드 과반수 쿼럼 모델이 사용됩니다.

    • 구성원이 짝수인 DAG에 노드 및 파일 공유 과반수 쿼럼 모델이 사용됩니다.

  • 감시 디렉터리 및 공유가 필요한 경우 Exchange에 의해 자동으로 만들어집니다.

  • Active Directory에서 서버가 DAG 개체에 추가됩니다.

  • 클러스터 데이터베이스가 탑재된 데이터베이스에 대한 정보로 업데이트됩니다.

참고

쿼럼 모델 변경은 자동으로 수행되어야 합니다. 그러나 쿼럼 모델이 적절한 모델로 자동으로 변경되지 않는 경우 IDENTITy 매개 변수만 사용하여 Set-DatabaseAvailabilityGroup cmdlet을 실행하여 DAG의 쿼럼 설정에서 수정할 수 있습니다.

DAG에 대한 클러스터 이름 개체 미리 준비

CNO는 Active Directory에 만들어지고 클러스터의 이름 리소스와 연결되는 컴퓨터 계정입니다. 클러스터의 이름 리소스는 CNO에 연결되며, 클러스터의 ID로 동작하고 클러스터의 보안 컨텍스트를 제공하는 Kerberos 사용 가능 개체입니다. 첫 번째 구성원이 DAG에 추가될 때 DAG의 기본 클러스터 및 해당 클러스터에 대한 CNO 형성이 수행됩니다. 첫 번째 서버가 DAG에 추가되면 원격 Powershell은 추가 작업이 진행 중인 사서함 서버의 Microsoft Exchange 복제 서비스를 실행합니다. Microsoft Exchange 복제 서비스는 장애 조치(failover) 클러스터링 기능을 설치하고(아직 설치되지 않은 경우) 클러스터 생성 프로세스를 시작합니다. Microsoft Exchange 복제 서비스는 LOCAL SYSTEM 보안 컨텍스트에서 실행되며 이는 클러스터 생성이 수행되는 컨텍스트입니다.

주의

DAG 구성원이 Windows Server 2012를 실행 중인 경우에는 첫 번째 서버를 DAG에 추가하기 전에 CNO를 미리 준비해야 합니다. DAG 멤버가 Windows Server 2012 R2를 실행하고 클러스터 관리 액세스 지점 없이 DAG를 만드는 경우 CNO가 만들어지지 않으며 DAG에 대한 CNO를 만들 필요가 없습니다.

컴퓨터 계정 생성이 제한되는 환경이나 컴퓨터 계정이 기본 컴퓨터 컨테이너가 아닌 컨테이너에 만들어지는 환경에서는 CNO를 미리 준비하고 프로비전할 수 있습니다. CNO에 대한 컴퓨터 계정을 만들고 사용하지 않도록 설정한 다음, 다음 단계 중 하나를 수행합니다.

  • DAG에 추가하려는 첫 번째 사서함 서버의 컴퓨터 계정에 대한 컴퓨터 계정의 모든 권한 할당

  • Exchange Trusted Subsystem USG에 대한 컴퓨터 계정의 모든 권한 할당

DAG에 추가 중인 첫 번째 사서함 서버의 컴퓨터 계정에 컴퓨터 계정에 대한 모든 권한을 할당하면 LOCAL SYSTEM 보안 컨텍스트가 미리 준비된 컴퓨터 계정을 관리할 수 있습니다. Exchange Trusted Subsystem USG에는 도메인에 있는 모든 Exchange 서버의 컴퓨터 계정을 포함하므로 Exchange Trusted Subsystem USG에 컴퓨터 계정에 대한 모든 권한을 할당하는 것으로 대신할 수 있습니다.

DAG에 대해 CNO를 미리 준비하고 프로비전하는 방법에 대한 자세한 내용은 데이터베이스 가용성 그룹에 대한 클러스터 이름 개체 미리 준비를 참조하십시오.

DAG에서 서버 제거

EAC의 데이터베이스 가용성 그룹 관리 마법사 또는 Exchange 관리 셸의 Remove-DatabaseAvailabilityGroupServer cmdlet을 사용하여 DAG에서 사서함 서버를 제거할 수 있습니다. DAG에서 사서함 서버를 제거하려면 먼저 복제된 모든 사서함 데이터베이스를 서버에서 제거해야 합니다. 복제된 사서함 데이터베이스가 포함된 사서함 서버를 DAG에서 제거하려면 작업이 실패합니다.

특정 작업을 수행하기 전에는 사서함 서버를 DAG에서 제거해야 한다는 시나리오가 있습니다. 이러한 시나리오는 다음과 같습니다.

  • 서버 복구 작업 수행: DAG의 멤버인 사서함 서버가 손실되거나 실패하거나 복구할 수 없고 교체가 필요한 경우 Setup /m:RecoveryServer 스위치를 사용하여 서버 복구 작업을 수행할 수 있습니다. 하지만 복구 작업을 수행하려면 먼저 Remove-DatabaseAvailabilityGroupServer cmdlet을 ConfigurationOnly 매개 변수와 함께 사용하여 DAG에서 서버를 제거해야 합니다.

  • 데이터베이스 가용성 그룹 제거: DAG를 제거해야 하는 상황이 있을 수 있습니다(예: 타사 복제 모드를 사용하지 않도록 설정하는 경우). DAG를 제거해야 하는 경우 먼저 DAG에서 모든 서버를 제거해야 합니다. 구성원이 포함된 DAG를 제거하면 작업이 실패합니다.

DAG 속성 구성

서버가 DAG에 추가된 후 EAC 또는 Exchange 관리 셸을 사용하여 DAG에서 사용하는 미러링 모니터 서버 및 감시 디렉터리 및 DAG에 할당된 IP 주소를 포함하여 DAG의 속성을 구성할 수 있습니다.

구성 가능한 속성은 다음과 같습니다.

  • 미러링 모니터 서버: 파일 공유 감시에 대한 파일 공유를 호스트하려는 서버의 이름입니다. 미러링 모니터 서버로 클라이언트 액세스 서버를 지정하는 것이 좋습니다. 이 이름을 지정하면 시스템에서 필요에 따라 공유를 자동으로 구성, 보안 및 사용할 수 있으며 메시징 관리자가 미러링 모니터 서버의 가용성을 인식할 수 있습니다.

  • 미러링 모니터 서버 디렉터리: 파일 공유 감시 데이터를 저장하는 데 사용할 디렉터리의 이름입니다. 이 디렉터리는 지정된 미러링 모니터 서버에서 시스템에 의해 자동으로 만들어집니다.

  • 데이터베이스 가용성 그룹 IP 주소: DAG 멤버가 Windows Server 2012 R2를 실행하고 IP 주소 없이 DAG를 만드는 경우가 아니면 하나 이상의 IP 주소를 DAG에 할당해야 합니다. 그렇지 않으면 DAG의 IP 주소는 수동으로 할당된 고정 IP 주소를 사용하여 구성되거나, 조직의 DHCP 서버를 사용하여 DAG에 자동으로 할당될 수 있습니다.

Exchange 관리 셸을 사용하면 EAC에서 사용할 수 없는 DAG 속성(예: DAG IP 주소)을 구성할 수 있습니다. 네트워크 암호화 및 압축 설정; 네트워크 검색; 복제에 사용되는 TCP 포트입니다. 및 대체 미러링 모니터 서버 및 미러링 모니터 서버 디렉터리 설정; 및 을 사용하여 데이터 센터 활성화 조정 모드를 사용하도록 설정합니다.

DAG 속성을 구성하는 방법에 대한 자세한 단계는 데이터베이스 가용성 그룹 속성 구성을 참조하십시오.

DAG 네트워크 암호화

DAG는 Windows Server 운영 체제의 암호화 기능을 활용하여 암호화 사용을 지원합니다. DAG는 Exchange 서버 간에 Kerberos 인증을 사용합니다. Microsoft Kerberos SSP(보안 지원 공급자) EncryptMessage 및 DecryptMessage API는 DAG 네트워크 트래픽의 암호화를 처리합니다. Microsoft Kerberos SSP는 여러 암호화 알고리즘을 지원합니다. 전체 목록은 Kerberos 프로토콜 확장의 "암호화 형식" 섹션 3.1.5.2를 참조하세요. Kerberos 인증 핸드셰이크는 목록에서 지원되는 가장 강력한 암호화 프로토콜을 선택합니다. 일반적으로 AES(Advanced Encryption Standard) 256비트이며, 잠재적으로 데이터의 무결성을 유지하기 위해 SHA 해시 기반 메시지 인증 코드(HMAC)를 사용합니다. 자세한 내용은 HMAC를 참조하세요.

네트워크 암호화는 DAG 네트워크의 속성이 아니라 DAG의 속성입니다. Exchange 관리 셸에서 Set-DatabaseAvailabilityGroup cmdlet을 사용하여 DAG 네트워크 암호화를 구성할 수 있습니다. DAG 네트워크 통신에 사용할 수 있는 암호화 설정은 다음 표에 나와 있습니다.

설정 설명
사용 안 함 네트워크 암호화가 사용되지 않습니다.
사용 모든 DAG 네트워크에서 네트워크 암호화가 복제 및 시드용으로 사용됩니다.
InterSubnetOnly 여러 서브넷에서 복제 시 DAG 네트워크에서 네트워크 암호화가 사용됩니다. 이 설정은 기본 설정입니다.
SeedOnly 모든 DAG 네트워크에서 네트워크 암호화가 시드용으로만 사용됩니다.

DAG 네트워크 압축

DAG는 기본 제공 압축 기능도 지원합니다. 압축을 사용하도록 설정하면 DAG 네트워크 통신은 XPRESS를 사용하며, 이는 Microsoft의 LZ77 알고리즘으로 구현됩니다. 이 압축은 많은 Microsoft 프로토콜, 특히 Microsoft Outlook과 Exchange 간의 MAPI RPC 압축에 사용되는 것과 동일한 유형의 압축입니다.

네트워크 암호화와 마찬가지로 네트워크 압축은 DAG 네트워크가 아닌 DAG의 속성이기도 합니다. Exchange 관리 셸에서 Set-DatabaseAvailabilityGroup cmdlet을 사용하여 DAG 네트워크 압축을 구성합니다. DAG 네트워크 통신에 대한 가능한 압축 설정은 다음 표에 나와 있습니다.

설정 설명
사용 안 함 네트워크 압축이 사용되지 않습니다.
사용 모든 DAG 네트워크에서 네트워크 압축이 복제 및 시드용으로 사용됩니다.
InterSubnetOnly 여러 서브넷에서 복제 시 DAG 네트워크에서 네트워크 압축이 사용됩니다. 이 설정은 기본 설정입니다.
SeedOnly 모든 DAG 네트워크에서 네트워크 압축이 시드용으로만 사용됩니다.

DAG 네트워크

DAG 네트워크는 복제 트래픽 또는 MAPI 트래픽용으로 사용되는 하나 이상의 서브넷 모음입니다. 각 DAG는 최대 한 개의 MAPI 네트워크와 0개 이상의 복제 네트워크를 포함합니다. 단일 네트워크 어댑터 구성에서는 MAPI 및 복제 트래픽을 위해서 해당 네트워크가 사용됩니다. 단일 네트워크 어댑터 및 경로가 지원되더라도 각 DAG는 최소 2개의 DAG 네트워크를 보유하는 것이 좋습니다. 네트워크 2개 구성에서 한 개의 네트워크는 일반적으로 복제 트래픽 전용이며, 다른 한 개의 네트워크는 주로 MAPI 트래픽용으로 사용됩니다. 각 DAG 구성원에 네트워크 어댑터를 추가할 수도 있으며 추가 DAG 네트워크를 복제 네트워크로 구성할 수 있습니다.

참고

복제 네트워크를 여러 개 사용할 때 우선 사용되도록 네트워크 순위를 지정할 수 있는 방법은 없습니다. Exchange는 복제 네트워크 그룹에서 로그를 전달하는 데 사용할 복제 네트워크를 임의로 선택합니다.

Exchange 2010에서는 많은 시나리오에서 DAG 네트워크를 수동으로 구성해야 했습니다. 기본적으로 이후 버전의 Exchange에서는 DAG 네트워크가 시스템에서 자동으로 구성됩니다. DAG 네트워크를 만들거나 수정하려면 먼저 다음 명령을 실행하여 수동 DAG 네트워크 제어를 사용하도록 설정해야 합니다.

Set-DatabaseAvailabilityGroup <DAGName> -ManualDagNetworkConfiguration $true

수동 DAG 네트워크 구성을 사용하도록 설정한 후 Exchange 관리 셸에서 New-DatabaseAvailabilityGroupNetwork cmdlet을 사용하여 DAG 네트워크를 만들 수 있습니다. DAG 네트워크를 만드는 방법에 대한 자세한 단계는 데이터베이스 가용성 그룹 네트워크를 만들기를 참조하십시오.

Exchange 관리 셸에서 Set-DatabaseAvailabilityGroupNetwork cmdlet을 사용하여 DAG 네트워크 속성을 구성할 수 있습니다. DAG 네트워크 속성을 구성하는 방법에 대한 자세한 단계는 데이터베이스 가용성 그룹 네트워크 속성 구성을 참조하십시오. 각 DAG 네트워크에서는 다음 필수 매개 변수 및 선택적 매개 변수를 구성해야 합니다.

  • 네트워크 이름: 최대 128자의 DAG 네트워크에 대한 고유한 이름입니다.

  • 네트워크 설명: 최대 256자의 DAG 네트워크에 대한 선택적 설명입니다.

  • 네트워크 서브넷: IPAddress/Bitmask 형식을 사용하여 입력한 하나 이상의 서브넷(예: 인터넷 프로토콜 버전 4(IPv4) 서브넷의 경우 192.168.1.0/24, 인터넷 프로토콜 버전 6(IPv6) 서브넷의 경우 2001:DB8:0:C000::/64).

  • 복제 사용: EAC에서 DAG 네트워크를 복제 트래픽에 바치고 MAPI 트래픽을 차단하는 확인란을 선택합니다. 복제가 DAG 네트워크를 사용하지 못하도록 하고 MAPI 트래픽을 사용하도록 설정하려면 확인란의 선택을 취소합니다. Exchange 관리 셸에서 Set-DatabaseAvailabilityGroupNetwork cmdlet의 ReplicationEnabled 매개 변수를 사용하여 복제를 사용하도록 설정하고 사용하지 않도록 설정합니다.

참고

MAPI 네트워크에서 복제를 사용하지 않도록 설정하더라도 시스템이 복제를 위해 MAPI 네트워크를 사용하지 않음을 보장하지 않습니다. 구성된 모든 복제 네트워크가 오프라인 또는 장애가 있거나 그렇지 않다면 이용할 수 없어서 MAPI 네트워크만이 존재하는 경우(복제에 대해 사용 안 함으로 구성됨), 해당 시스템은 복제를 위해 MAPI 네트워크를 사용합니다.

시스템이 만든 초기 DAG 네트워크(예: MapiDagNetwork 및 ReplicationDagNetwork01)는 클러스터 서비스에서 열거한 서브넷을 기반으로 합니다. 각 DAG 구성원의 네트워크 어댑터 수는 동일해야 하며 각 네트워크 어댑터는 고유한 서브넷에서 IPv4 주소(IPv6 주소는 선택적임)를 가져야만 합니다. 여러 DAG 구성원이 동일한 서브넷에서 IPv4 주소를 가질 수 있지만 특정 DAG 구성원의 각 네트워크 어댑터와 IP 주소 쌍은 고유한 서브넷상에 존재해야 합니다. 또한 MAPI 네트워크를 위해서 사용하는 어댑터만 기본 게이트웨이를 사용하여 구성해야 합니다. 복제 네트워크는 기본 게이트웨이를 사용하여 구성하면 안 됩니다.

예를 들어, 두 명의 구성원이 있고 각 구성원은 두 개의 네트워크 어댑터(하나는 MAPI 네트워크 전용, 다른 하나는 복제 네트워크 전용)를 가지는 DAG인 DAG1이 있다고 간주합니다. 예제 IP 주소 구성 설정은 다음 표에 나와 있습니다.

네트워크 어댑터 설정 예

서버-네트워크 어댑터 IP 주소/서브넷 마스크 기본 게이트웨이
EX1-MAPI 192.168.1.15/24 192.168.1.1
EX1-Replication 10.0.0.15/24 해당 없음
EX2-MAPI 192.168.1.16 192.168.1.1
EX2-Replication 10.0.0.16 해당 없음

다음 구성에는 두 개의 서브넷, 192.168.1.0 및 10.0.0.0이 DAG에 구성되어 있습니다. EX1 및 EX2가 DAG에 추가되는 경우 두 개의 서브넷이 열거되고 두 개의 DAG 네트워크, MapiDagNetwork(192.168.1.0) 및 ReplicationDagNetwork01(10.0.0.0)이 만들어집니다. 다음 표와 같이 이러한 네트워크가 구성됩니다.

단일-서브넷 DAG에 대해 열거되는 DAG 네트워크 설정

이름 서브넷 인터페이스 MAPI 액세스 사용 복제 사용
MapiDagNetwork 192.168.1.0/24 EX1(192.168.1.15)
EX2(192.168.1.16)		 True True
ReplicationDagNetwork01 10.0.0.0/24 EX1(10.0.0.15)
EX2(10.0.0.16)		 거짓 참

전용 복제 네트워크로 ReplicationDagNetwork01의 구성을 완료하려면 다음 명령을 실행하여 MapiDagNetwork에 대한 복제를 사용하지 않도록 설정합니다.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\MapiDagNetwork -ReplicationEnabled:$false

MapiDagNetwork에 대해 복제를 사용하지 않도록 설정하면 Microsoft Exchange 복제 서비스는 연속 복제를 위해 ReplicationDagNetwork01을 사용합니다. ReplicationDagNetwork01에 장애가 발생하는 경우 Microsoft Exchange 복제 서비스는 연속 복제를 위해 MapiDagNetwork를 다시 사용합니다. MapiDagNetwork로의 반환은 고가용성을 유지하기 위해 시스템에서 의도적으로 수행됩니다.

DAG 네트워크 및 다중 서브넷 배포

이전 예제에서는 DAG가 사용하는 두 개의 다른 서브넷(192.168.1.0 및 10.0.0.0)이 존재해도 각 구성원이 MAPI 네트워크를 형성하기 위해 동일한 서브넷을 사용하므로 DAG는 단일-서브넷 DAG로 간주됩니다. DAG 구성원이 MAPI 네트워크를 위해 다른 서브넷을 사용하는 경우 DAG는 다중-서브넷 DAG로 간주됩니다. 다중 서브넷 DAG에서는 적절한 서브넷이 각 DAG 네트워크에 자동으로 연결됩니다.

예를 들어, 두 개의 구성원이 있고 각 구성원은 두 개의 네트워크 어댑터(하나는 MAPI 네트워크 전용, 다른 하나는 복제 네트워크 전용)를 갖고 있으며, 각 DAG 구성원이 별도의 Active Directory 사이트에 위치해 있고 다른 서브넷상에 해당 MAPI 네트워크가 있는 DAG2가 있다고 간주합니다. 예제 IP 주소 구성 설정은 다음 표에 나와 있습니다.

다중-서브넷 DAG에 대한 네트워크 어댑터 설정 예

서버-네트워크 어댑터 IP 주소/서브넷 마스크 기본 게이트웨이
EX1-MAPI 192.168.0.15/24 192.168.0.1
EX1-Replication 10.0.0.15/24 해당 없음
EX2-MAPI 192.168.1.15 192.168.1.1
EX2-Replication 10.0.1.15 해당 없음

다음 구성에는 네 개의 서브넷, 192.168.0.0, 192.168.1.0, 10.0.0.0 및 10.0.1.0이 DAG에 구성되어 있습니다. DAG에 EX1 및 EX2가 추가되는 경우 네 개의 서브넷이 열거되지만 두 개의 DAG 네트워크인 MapiDagNetwork(192.168.0.0, 192.168.1.0) 및 ReplicationDagNetwork01(10.0.0.0, 10.0.1.0)만 만들어집니다. 이러한 네트워크는 다음 표와 같이 구성됩니다.

다중-서브넷 DAG에 대해 열거되는 DAG 네트워크 설정

이름 서브넷 인터페이스 MAPI 액세스 사용 복제 사용
MapiDagNetwork 192.168.0.0/24
192.168.1.0/24		 EX1(192.168.0.15)
EX2(192.168.1.15)		 True True
ReplicationDagNetwork01 10.0.0.0/24
10.0.1.0/24		 EX1(10.0.0.15)
EX2(10.0.1.15)		 거짓 참

DAG 네트워크 및 iSCSI 네트워크

기본적으로 DAG는 기본 클러스터에서 사용하기 위해 감지되고 구성된 모든 네트워크의 검색을 수행합니다. 이 검색에는 하나 이상의 DAG 멤버에 대해 iSCSI 스토리지를 사용한 결과로 사용 중인 모든 iSCSI(인터넷 SCSI) 네트워크가 포함됩니다. 최적의 방법으로 iSCSI 저장소는 전용 네트워크 및 네트워크 어댑터를 사용해야 합니다. 이러한 네트워크는 DAG 또는 해당 클러스터에서 관리하거나 DAG 네트워크(MAPI 또는 복제)로 사용해서는 안 됩니다. 대신 이러한 네트워크는 iSCSI 스토리지 트래픽에 전용으로 사용할 수 있도록 DAG에서 수동으로 사용하지 않도록 설정해야 합니다. iSCSI 네트워크가 DAG 네트워크로 감지되고 사용되지 않도록 설정하려면 다음 예외 같이 Set-DatabaseAvailabilityGroupNetwork cmdlet을 사용하여 DAG가 현재 감지되는 iSCSI 네트워크를 무시하도록 구성합니다.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true

또한 이 명령은 클러스터에서 네트워크를 사용하지 않도록 설정합니다. iSCSI 네트워크가 계속해서 DAG 네트워크로 나타나지만 위의 명령을 실행한 후에는 MAPI 또는 복제 트래픽에 iSCSI 네트워크가 사용되지 않습니다.

DAG 구성원 구성

DAG의 구성원인 사서함 서버는 다음 섹션의 설명과 같이 구성해야 하는 고가용성에 특정한 일부 속성을 갖고 있습니다.

자동 데이터베이스 탑재 다이얼

AutoDatabaseMountDial 매개 변수는 데이터베이스 장애 조치(failover) 후 자동 데이터베이스 탑재 행동을 지정합니다. Set-MailboxServer cmdlet을 사용하여 다음 값을 가진 AutoDatabaseMountDial 매개 변수를 구성할 수 있습니다.

  • BestAvailability: 이 값을 지정하면 복사 큐 길이가 12보다 작거나 같은 경우 장애 조치 직후 데이터베이스가 자동으로 탑재됩니다. 복사 큐 길이는 복제해야 하는 수동 복사본에서 인식되는 로그 개수입니다. 복사 큐 길이가 12보다 크면 데이터베이스가 자동으로 탑재되지 않습니다. 복사 큐 길이가 12보다 작거나 같으면 Exchange는 나머지 로그를 수동 복사본에 복제하려고 시도하고 데이터베이스를 탑재합니다.

  • GoodAvailability: 이 값을 지정하면 복사 큐 길이가 6보다 작거나 같은 경우 장애 조치 직후 데이터베이스가 자동으로 탑재됩니다. 복사 큐 길이는 복제해야 하는 수동 복사본에서 인식되는 로그 개수입니다. 복사 큐 길이가 6보다 크면 데이터베이스가 자동으로 탑재되지 않습니다. 복사 큐 길이가 6 이하이면 Exchange에서는 나머지 로그를 수동 복사본에 복제하려고 시도하며 데이터베이스를 탑재합니다.

  • Lossless: 이 값을 지정하면 현재 복사본에 생성된 모든 로그가 수동 복사본에 복사될 때까지 데이터베이스가 자동으로 탑재되지 않습니다. 또한 이 설정은 Active Manager의 최상의 복사본 선택 알고리즘이 데이터베이스 복제의 복제 큐 길이가 아닌 활성화 선호값을 기반으로 활성화할 잠재적인 후보들을 정렬하도록 합니다.

기본값은 GoodAvailability입니다. 또는 GoodAvailability를 지정 BestAvailability 하고 활성 복사본의 모든 로그를 활성화 중인 수동 복사본에 복사할 수 없는 경우 일부 사서함 데이터가 손실될 수 있습니다. 그러나 기본적으로 사용하도록 설정되는 보안 네트워크 기능을 통해 보안 네트워크 큐에 있는 메시지를 다시 전송하여 대부분의 데이터 손실을 방지할 수 있습니다.

예: 자동 데이터베이스 탑재 다이얼 구성

다음 예제에서는 AutoDatabaseMountDial 설정을 사용하여 사서함 서버를 구성합니다 GoodAvailability.

Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability

데이터베이스 복사본 자동 활성화 정책

DatabaseCopyAutoActivationPolicy 매개 변수는 선택한 사서함 서버의 사서함 데이터베이스 복사본에 사용할 수 있는 자동 활성화 형식을 지정합니다. Set-MailboxServer cmdlet을 사용하여 다음 값을 가진 DatabaseCopyAutoActivationPolicy 매개 변수를 구성할 수 있습니다.

  • Blocked: 이 값을 지정하면 선택한 사서함 서버에서 데이터베이스를 자동으로 활성화할 수 없습니다.

  • IntrasiteOnly: 이 값을 지정하면 동일한 Active Directory 사이트의 서버에서 데이터베이스 복사본을 활성화할 수 있습니다. 이 활성화는 사이트 간 장애 조치(failover) 또는 활성화를 방지합니다. 이 속성은 들어오는 사서함 데이터베이스 복사본(예: 활성 복사본으로 설정되는 수동 복사본)에 사용됩니다. 다른 Active Directory 사이트에서 활성화된 데이터베이스 복사본에 대해 이 사서함 서버의 데이터베이스를 활성화할 수 없습니다.

  • Unrestricted: 이 값을 지정하는 경우 선택한 사서함 서버에서 사서함 데이터베이스 복사본을 활성화하는 데 특별한 제한이 없습니다.

예: 데이터베이스 복사본 자동 활성화 정책 구성

다음 예제에서는 DatabaseCopyAutoActivationPolicy 설정 Blocked이 인 사서함 서버를 구성합니다.

Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked

최대 활성 데이터베이스

MaximumActiveDatabases 매개 변수(Set-MailboxServer cmdlet과 함께 사용되기도 함)는 사서함 메일 서버에 탑재될 수 있는 데이터베이스 수를 지정합니다. 개인 사서함 서버가 오버로드되지 않도록 하여 배포 요구사항을 충족하도록 사서함 서버를 구성할 수 있습니다.

MaximumActiveDatabases 매개 변수는 숫자 값(정수)으로 설정됩니다. 최대 개수에 도달하면 장애 조치(failover) 또는 전환이 발생해도 서버의 데이터베이스 복사본이 활성화되지 않습니다. 서버에서 복사본이 이미 활성화되어 있으면 데이터베이스를 탑재할 수 없습니다.

예: 최대 활성 데이터베이스 구성

다음 예제에서는 최대 20개의 활성 데이터베이스를 지원하도록 사서함 서버를 구성합니다.

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

DAG 구성원에서 유지 관리 수행

DAG 멤버에서 모든 유형의 소프트웨어 또는 하드웨어 유지 관리를 수행하기 전에 먼저 DAG 멤버를 유지 관리 모드로 전환해야 합니다. 다음 스크립트에는 DAG 유지 관리 절차를 지원하기 위한 Exchange Server 제공됩니다.

  • StartDagServerMaintenance.ps1: 모든 활성 데이터베이스를 서버에서 이동하는 데 도움이 됩니다. 또한 PAM(기본 Active Manager) 역할과 같은 모든 중요한 DAG 지원 기능을 이동하고 유지 관리가 완료되기 전에 서버로 다시 이동하지 못하도록 차단합니다.

  • StopDagServerMaintenance.ps1: DAG 멤버를 유지 관리 모드에서 벗어나 모든 데이터베이스 및 모든 중요한 DAG 지원 기능에 대한 활성 대상으로 만드는 데 도움을 줍니다.

위의 스크립트는 모두 ServerName 매개 변수(DAG 멤버의 호스트 이름 또는 FQDN(정규화된 도메인 이름) 및 WhatIf 매개 변수를 허용합니다. 두 스크립트는 모두 로컬 또는 원격으로 실행할 수 있습니다. 스크립트가 실행되는 서버에는 Windows 장애 조치(failover) 클러스터 관리 도구(RSAT-Clustering)가 설치되어 있어야 합니다.

참고

RedistributeActiveDatabases.ps1 스크립트도 사용할 수 있습니다. 이 스크립트는 각 데이터베이스의 활성화 기본 설정 번호에 표시된 대로 특정 DAG 멤버에 사서함 데이터베이스를 탑재하는 데 도움이 됩니다. 그러나 Exchange 2016 CU2 이상에서는 PreferenceMoveFrequency 라는 새 DAG 속성이 DAG 간에 데이터베이스 복사본의 균형을 자동으로 조정합니다. 따라서 이 기능을 사용하지 않도록 설정했거나 데이터베이스 복사본의 균형을 수동으로 조정하려는 경우에만 RedistributeActiveDatabases.ps1 스크립트를 사용해야 합니다.

StartDagServerMaintenance.ps1 스크립트는 다음 작업을 수행합니다.

  • DAG 멤버Blocked의 DatabaseCopyAutoActivationPolicy 매개 변수 값을 로 설정하면 서버에서 데이터베이스 복사본이 활성화되지 않습니다.

  • 클러스터에서 노드를 일시 중지하여 노드가 PAM이 되는 것을 방지합니다.

  • 현재 DAG 멤버에 호스트된 모든 활성 데이터베이스를 다른 DAG 멤버로 이동합니다.

  • DAG 멤버가 현재 기본 클러스터 그룹을 소유하는 경우 스크립트는 기본 클러스터 그룹(따라서 PAM 역할)을 다른 DAG 멤버로 이동합니다.

이전 작업이 실패하면 성공적인 데이터베이스 이동을 제외한 모든 작업이 스크립트에 의해 실행 취소됩니다.

전송 큐 플러시 및 클라이언트 연결 일시 중단을 포함하여 DAG 멤버에서 유지 관리 절차를 시작하려면 다음 작업을 수행합니다.

  1. 전송 큐를 비우려면 다음 명령을 실행합니다.

    Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance

  2. 전송 큐의 드레이닝을 시작하려면 다음 명령을 실행합니다.

    Restart-Service MSExchangeTransport

  3. 모든 통합 메시징 호출을 드레이닝하는 프로세스를 시작하려면(Exchange 2016에서만 해당) 다음 명령을 실행합니다.

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance

  4. DAG 유지 관리 스크립트에 액세스하려면 다음 명령을 실행합니다.

    CD $ExScripts

  5. StartDagServerMaintenance.ps1 스크립트를 실행하려면 다음 명령을 실행합니다.

    .\StartDagServerMaintenance.ps1 -ServerName <ServerName> -MoveComment Maintenance -PauseClusterNode

    MoveComment 매개 변수의 값에 대해 원하는 표기법을 만들 수 있습니다. 위의 예제에서는 "유지 관리"를 사용합니다.

    참고

    이 스크립트를 실행하는 데 다소 시간이 걸릴 수 있으며 이 시간 동안 화면에 활동이 표시되지 않을 수 있습니다.

  6. 로컬 큐에서 배달 보류 중인 메시지를 Target 매개 변수로 지정된 Exchange 서버로 리디렉션하려면 다음 명령을 실행합니다.

    Redirect-Message -Server <ServerName> -Target <Server FQDN>

  7. 서버를 유지 관리 모드로 전환하려면 다음 명령을 실행합니다.

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance

서버가 유지 관리에 대한 준비가 되었는지 확인하려면 다음 작업을 수행합니다.

  1. 서버가 유지 관리 모드로 전환되었는지 확인하려면 다음 명령을 실행할 때 및 RecoveryActionsEnabled 만 Monitoring 활성 상태인지 확인합니다.

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

  2. 서버가 활성 데이터베이스 복사본을 호스트하지 않는지 확인하려면 다음 명령을 실행합니다.

    Get-MailboxServer <ServerName> | Format-List DatabaseCopyAutoActivationPolicy

  3. 클러스터 노드가 일시 중지되었는지 확인하려면 다음 명령을 실행합니다.

    Get-ClusterNode <ServerName> | Format-List

  4. 모든 전송 큐가 비워졌는지 확인하려면 다음 명령을 실행합니다.

    Get-Queue

유지 관리가 완료되고 DAG 멤버가 서비스로 돌아갈 준비가 되면 StopDagServerMaintenance.ps1 스크립트는 DAG 멤버를 유지 관리 모드에서 벗어나 프로덕션으로 되돌리는 데 도움이 됩니다. StopDagServerMaintenance.ps1 스크립트는 다음 작업을 수행합니다.

  • DAG 멤버에 대한 전체 클러스터 기능을 사용하도록 설정하는 클러스터의 노드를 다시 시작합니다.

  • DAG 멤버Unrestricted의 DatabaseCopyAutoActivationPolicy 매개 변수 값을 로 설정합니다.

  • DAG 멤버에서 호스트되는 각 데이터베이스 복사본에 대해 Resume-MailboxDatabaseCopy cmdlet을 실행합니다.

전송 큐 및 클라이언트 연결 재개를 포함하여 DAG 멤버를 전체 프로덕션 상태 복원할 준비가 되면 다음 작업을 수행합니다.

  1. 서버를 유지 관리 외 모드로 구성하고 클라이언트 연결을 수락할 준비가 되도록 구성하려면 다음 명령을 실행합니다.

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance

  2. 서버가 통합 메시징 호출을 수락하도록 허용하려면(Exchange 2016에서만 해당) 다음 명령을 실행합니다.

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance

  3. DAG 유지 관리 스크립트에 액세스하려면 다음 명령을 실행합니다.

    CD $ExScripts

  4. StopDagServerMaintenance.ps1 스크립트를 실행하려면 다음 명령을 실행합니다.

    .\StopDagServerMaintenance.ps1 -serverName <ServerName>

  5. 전송 큐가 메시지 수락 및 처리를 다시 시작할 수 있도록 하려면 다음 명령을 실행합니다.

    Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance

  6. 전송 작업을 다시 시작하려면 다음 명령을 실행합니다.

    Restart-Service MSExchangeTransport

서버가 프로덕션용으로 준비되었는지 확인하려면 다음 작업을 수행합니다.

  1. 서버가 유지 관리 모드가 아닌지 확인하려면 다음 명령을 실행합니다.

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

Exchange 업데이트를 설치하는 중 업데이트 프로세스가 실패하면 일부 서버 구성 요소가 비활성 상태로 남을 수 있으며, 이 상태는 위의 Get-ServerComponentState cmdlet의 출력에 표시됩니다. 이 문제를 resolve 다음 명령을 실행합니다.

  1. Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional

  2. Set-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester Functional

  3. Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional

DAG 구성원 종료

Exchange 고가용성 솔루션은 Windows 종료 프로세스와 통합됩니다. 관리자 또는 응용 프로그램이 DAG에서 하나 이상의 DAG 구성원에 복제되어 탑재된 데이터베이스를 보유한 Windows 서버 종료를 시작하는 경우 시스템은 종료 프로세스가 완료되기 전에 탑재된 데이터베이스의 다른 복사본을 활성화합니다.

그러나 이 새로운 동작은 종료되는 서버의 모든 데이터베이스에 활성화가 발생 lossless 한다는 것을 보장하지는 않습니다. 따라서 DAG의 구성원인 서버를 종료하기 전에 서버 전환을 수행하는 것이 좋은 방법입니다.

DAG 구성원에 업데이트 설치

DAG의 멤버인 서버에 Exchange 업데이트를 설치하는 것은 비교적 간단한 프로세스입니다. DAG 구성원인 서버에 업데이트를 설치할 때 모든 Exchange 서비스와 클러스터 서비스를 비롯하여 여러 서비스가 설치하는 동안 중지됩니다. DAG 구성원에 업데이트를 적용하는 일반적인 프로세스는 다음과 같습니다.

  1. 위에 설명한 단계를 사용하여 DAG 구성원을 유지 관리 모드로 설정합니다.

  2. 업데이트를 설치합니다.

  3. 위에 설명한 단계를 사용하여 DAG 구성원을 유지 관리 모드에서 해제하고 다시 프로덕션 모드로 설정합니다.

  4. 필요에 따라 RedistributeActiveDatabases.ps1 스크립트를 사용하여 DAG 전체에서 활성 데이터베이스 복사본의 균형을 조정합니다.

최신 Exchange 업데이트에 대한 자세한 내용은 빌드 번호 및 릴리스 날짜 Exchange Server 참조하세요.

참고

항상 동일한 버전의 Exchange 서버(누적 및 보안 업데이트 포함)에서 모든 DAG 멤버를 실행해야 합니다. 모든 DAG 멤버의 "롤링 업데이트"를 수행하고, 오랜 시간 동안 다른 Exchange 버전의 멤버와 함께 DAG를 실행하지 마세요.