고가용성 요소 이해

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2015-03-09

고가용성 사서함 서버 및 데이터베이스 아키텍처 계획 시 다음과 같은 디자인 결정 사항을 고려해야 합니다.

• 여러 데이터베이스 복사본을 배포할 것인지 여부

• 배포할 데이터베이스 복사본의 개수

• 사이트 복구를 제공하는 아키텍처를 보유할 것인지 여부

• 배포할 사서함 서버 복구 모델의 유형

• 배포할 사서함 서버의 개수

• 데이터베이스 복사본을 배포하는 방법

• 사용할 백업 모델

• 사용할 저장소 아키텍처

Microsoft Exchange Server 2010에서는 사서함 복구를 위해 구성된 사서함 서버 또는 독립 실행형 사서함 서버를 사용하여 사서함 서버 인프라를 배포할 수 있습니다. 사서함 복구를 위해 구성된 사서함 서버는 DAG 전체에 효율적으로 배포된 여러 데이터베이스 복사본이 포함된 DAG(데이터베이스 가용성 그룹)를 적용합니다. 여러 데이터베이스 복사본을 배포하는 경우는 다음과 같은 장점이 있습니다.

• 백업 사용에 대한 일반적인 문제를 완화해 주는 솔루션을 디자인할 수 있습니다. 데이터베이스 복사본이 하드웨어, 소프트웨어 및 데이터 센터 오류로부터 보호합니다.

• 백업에서 복원하는 대신 다른 데이터베이스 복사본을 이용한 복구 메커니즘을 사용하여 데이터베이스 크기가 2테라바이트까지 증가합니다.

• 데이터베이스 복사본을 세 개 이상 배포하는 경우 JBOD(Just a Bunch Of Disk) 등의 일반 RAID 구성에 대한 대체 저장소 아키텍처를 고려할 수 있습니다. JBOD와 저렴한 디스크를 조합하여 사용하면 조직에서 비용을 절감할 수 있습니다.

DAG에 참가하는 모든 서버에 활성 데이터베이스를 배포하면 하드웨어 효율을 극대화할 수 있습니다.

자세한 내용은 고가용성 및 사이트 복구 계획 및 백업, 복원 및 재해 복구 이해를 참조하십시오.

목차

배포할 데이터베이스 복사본 수 계획

데이터베이스 복사본 유형

사이트 복구

사서함 서버 복구 모델 계획

배포할 사서함 서버 수 계획

데이터베이스 복사본 레이아웃 계획

백업 모델 아키텍처 계획

저장소 모델 아키텍처 계획

고가용성과 관련된 관리 작업에 대한 자세한 내용은 고가용성 및 사이트 복구 관리를 참조하십시오.

배포할 데이터베이스 복사본 수 계획

사서함 데이터베이스 복사본 이해에서 설명된 대로 DAG 구성원은 각 사서함 데이터베이스의 복사본 하나를 호스트할 수 있으며 Enterprise Edition 제품에는 서버당 최대 100개의 데이터베이스가 포함됩니다(활성 및 수동 복사본 모두 이 제한에 포함됨). 즉, 16개 구성원 DAG에서 지원되는 데이터베이스는 1,600개로 제한됩니다(서버당 100개의 데이터베이스 복사본 × DAG당 16개의 서버 ÷ 데이터베이스당 복사본 1개 = DAG당 1,600개의 데이터베이스).

고가용성 구성에서는 데이터 중복성을 제공하지 않기 때문에 데이터베이스의 단일 복사본 배포에 대한 값이 없습니다. 수식을 사용하여 특정 DAG가 지원할 수 있는 데이터베이스 수를 결정합니다. 예를 들어 배포할 데이터베이스 수를 D로, 각 데이터베이스 복사본 수를 C로, 서버 수를 S로 선택하면 다음과 같이 적용됩니다.

• D × C = DAG의 총 데이터베이스 복사본 수

• (D × C) ÷ S = 서버당 데이터베이스 복사본 수

예를 들어 6개의 서버와 84개의 사서함 데이터베이스가 포함된 DAG와 각 데이터베이스의 복사본 3개가 있다고 가정합니다. (6개의 서버는 3개 복사본의 정수 배수입니다.) 다음 사항이 적용됩니다.

• 84개의 데이터베이스 × 3개의 복사본 = 총 252개의 데이터베이스

• 252개의 데이터베이스 ÷ 6개의 서버 = 서버당 42개의 데이터베이스 복사본

다른 예에서는 4개의 서버와 136개의 사서함 데이터베이스가 포함된 DAG와 각 데이터베이스의 복사본 3개가 있습니다. 다음 사항이 적용됩니다.

• 136개의 데이터베이스 × 3개의 복사본 = 총 408개의 데이터베이스

• 408개의 데이터베이스 ÷ 4개의 서버 = 서버당 102개의 데이터베이스 복사본

102는 100보다 크므로 제안된 시나리오는 유효한 DAG 디자인이 아닙니다.

맨 위로 이동

데이터베이스 복사본 유형

두 가지 유형의 데이터베이스 복사본이 있습니다.

• 고가용성의 데이터베이스 복사본

• 지연된 데이터베이스 복사본

고가용성 데이터베이스 복사본은 재생 지연 시간이 0으로 구성된 복사본입니다. 이름이 암시하듯이 고가용성 데이터베이스 복사본은 시스템에 의해 최신 상태로 유지되고 자동으로 시스템에서 활성화할 수 있으며 사서함 서비스 및 데이터에 대한 고가용성을 제공하는 데 사용됩니다.

지연된 데이터베이스 복사본은 일정 시간 동안 트랜잭션 로그 재생을 지연하도록 구성된 복사본입니다. 지연된 데이터베이스 복사본은 지정 시간 보호를 제공하도록 디자인되었으며, 저장소 논리적 손상, 관리 오류(예: 연결이 끊어진 사서함 삭제 또는 제거) 및 자동화 오류(예: 연결이 끊어진 사서함 일괄 제거)로부터 복구하는 데 사용할 수 있습니다.

일반적으로 지연된 데이터베이스 복사본은 Active Manager 최적 복사본 선택 알고리즘으로 인해 활성화되지 않습니다. 지연된 데이터베이스 복사본은 운영 위험을 완화하기 위해 배포되는 것이므로 활성화되지 않아야 합니다. 활성화된 경우 및 mount 요청이 실행된 경우 로그 재생이 시작되어 데이터베이스를 최신 상태 및 완전하게 종료된 상태로 만들기 위해 필요한 모든 로그 파일이 재생되므로 지정 시간 기능이 손실됩니다.

사서함 서버 수준에서 활성화를 차단하거나 하나 이상의 데이터베이스 복사본에 대한 활성화를 일시 중단하여 데이터베이스 복사본(예: 지연된 데이터베이스 복사본)이 자동으로 활성화되지 않도록 하는 방법에 대한 자세한 내용은 Set-MailboxServer 및 Suspend-MailboxDatabaseCopy를 참조하십시오.

맨 위로 이동

사이트 복구

사용자 환경은 여러 데이터 센터로 구성되어 있을 수 있습니다. Exchange 2010 디자인의 일부로 단일 데이터 센터에서 Exchange 인프라를 배포할 것인지 또는 두 개 이상의 데이터 센터에서 해당 인프라를 배포할 것인지 결정합니다. 조직의 SLA(서비스 수준 계약)는 기본 데이터 센터 오류를 처리하는 데 어느 수준의 서비스가 필요한지 정의해야 합니다.

Exchange 배포가 사이트 복구 목표를 지원하기 위해 여러 데이터 센터에서 배포되는 경우 어느 사용자 배포 모델을 적용할지 고려합니다. 데이터 센터 관련 사서함 위치에 따라 다음과 같은 두 가지 유형의 사서함 배포 모델이 있습니다.

• 활성/수동 사용자 배포 모델

• 활성/활성 사용자 배포 모델

사용자 사서함이 기본적으로 단일 데이터 센터에 있고(또는 사용자가 단일 데이터 센터를 통해 해당 데이터를 액세스하는 경우) 사용자가 일반 작업 시 기본 데이터 센터를 통해 해당 데이터를 계속 액세스해야 하는 SLA 요구 사항이 있는 경우 사용자 아키텍처는 활성/수동 사용자 배포 모델입니다.

사용자 사서함이 여러 데이터 센터에 분산되어 있고 사용자가 일반 작업 시 기본 데이터 센터를 통해 해당 데이터를 계속 액세스해야 하는 SLA 요구 사항이 있는 경우 사용자 아키텍처는 활성/활성 사용자 배포 모델입니다.

활성/수동 사용자 배포 모델에서는 다음 그림과 같이 아키텍처를 배포할 수 있습니다. 여기서 활성 사서함은 기본 데이터 센터에서 호스트되지만 데이터베이스 복사본은 보조 데이터 센터에서 배포됩니다.

두 개의 데이터 센터가 포함된 활성/수동 사용자 배포 모델

다음 그림에 나오는 아키텍처는 활성/활성 사용자 배포 모델에 사용할 수 있습니다.

두 개의 데이터 센터가 포함된 활성/활성 사용자 배포 모델

하지만 위의 그림에 나오는 아키텍처에는 위험이 있습니다. WAN(Wide Area Network)은 DAG에 대한 단일 오류 지점입니다. WAN이 손실되면 두 번째 데이터 센터의 DAG 구성원에 대한 쿼럼이 손실됩니다. 이 예에서 Windows 장애 조치(failover) 클러스터에는 총 5개의 응답(4개의 DAG 구성원과 미러링 모니터 서버)이 있으며 장애 조치(failover) 클러스터가 작동 상태를 유지하기 위해서는 항상 세 개의 응답을 사용할 수 있어야 합니다. 세 개의 응답은 Redmond 데이터 센터에 있으며 두 개의 응답은 Portland 데이터 센터에 있습니다. WAN 연결이 손실되면 Portland 데이터 센터가 두 개의 응답만 호스트하게 되며 이는 쿼럼을 유지 관리하는 데 충분하지 않습니다. Redmond 데이터 센터에는 3개의 응답이 있으므로 그러한 3개의 응답이 작동하는 한 쿼럼을 유지 관리하고 계속 활성 사서함을 서비스할 수 있습니다.

활성/활성 사용자 배포 모델에 대한 이러한 위험을 완화하려면 다음 그림과 같이 두 개의 DAG를 배포하는 것이 좋습니다.

활성/활성 사용자 배포 모델에 대한 두 개의 DAG

DAG1은 Redmond 데이터 센터에 대한 활성 사서함을 호스트하며 수동 데이터베이스 복사본이 Portland 데이터 센터에 배포된 활성/수동 사용자 배포 모델로 구현됩니다. DAG2는 Portland 데이터 센터에 대한 활성 사서함을 호스트하며 수동 데이터베이스 복사본이 Redmond 데이터 센터에 배포된 활성/수동 사용자 배포 모델로 구현됩니다.

이 아키텍처는 다음과 같이 WAN 손실을 복구할 수 있습니다.

• Redmond 데이터 센터에서 DAG2에 대한 사서함 서버 구성원은 쿼럼 손실로 인해 실패 상태가 되지만 DAG1에 대한 활성 사서함 서버 구성원은 작동 상태를 유지하여 사용자를 서비스합니다.

• Portland 데이터 센터에서 DAG1에 대한 사서함 서버 구성원은 쿼럼 손실로 인해 실패 상태가 되지만 DAG2에 대한 활성 사서함 서버 구성원은 작동 상태를 유지하고 사용자를 서비스합니다.

자세한 내용은 고가용성 및 사이트 복구 계획를 참조하십시오.

맨 위로 이동

사서함 서버 복구 모델 계획

Exchange 2010 사서함 서버 용량 계획에서 중요한 부분은 사서함 복구를 구성할 때 서버별로 활성화할 데이터베이스 복사본의 수를 결정하는 것입니다. 다양한 디자인을 사용할 수 있지만 다음 섹션에 나오는 두 가지 모델이 권장됩니다.

모든 데이터베이스 복사본 활성화 디자인

서버 아키텍처가 호스트된 데이터베이스 복사본 모두가 활성화되는 상황을 100% 처리하도록 디자인할 수 있습니다. 예를 들어 서버에서 호스트하는 데이터베이스 복사본이 35개이면 사용자 작업이 가장 많은 기간에 35개의 데이터베이스가 모두 활성화되는 상황을 감당할 수 있도록 프로세서 및 메모리를 디자인합니다. 이 솔루션은 일반적으로 쌍으로 배포됩니다. 예를 들어 네 개의 서버를 배포하는 경우 하나의 쌍은 서버 1과 2이고 두 번째 쌍은 서버 3과 4입니다. 또한 이 시나리오에 대한 설계 시 일반 런타임 작업에 사용 가능한 40% 이하의 리소스에 대한 각 서버의 크기를 지정합니다.

이 항목에서 설명되는 두 모델 중에서 이 모델에 더 많은 서버 카운트가 있습니다.

오류 특화 시나리오 디자인

서버 아키텍처가 수용하도록 계획된 최악의 오류가 발생했을 때 활성 사서함 부하를 처리할 수 있게 디자인할 수 있습니다. 이 모델에서는 사이트 복구, RAID 저장소와 JBOD 비교, DAG 크기 및 데이터베이스 복사본 수를 포함한 다양한 요소를 고려해야 합니다. 이 용량 계획 모델은 자본 비용, 가용성 및 클라이언트 성능 특성 사이의 균형을 제공합니다.

데이터베이스 복사본은 무작위로 고르게 배포되어 있다고 가정합니다.

• 사서함 데이터베이스당 두 개의 고가용성 데이터베이스 복사본이 있는 두 구성원 또는 세 구성원 DAG 구성의 자동, 단일 구성원 서버 오류를 위한 디자인

• 사서함 데이터베이스당 세 개의 고가용성 데이터베이스 복사본이 있는 세 구성원 DAG 구성의 이중 구성원 서버 오류를 위한 디자인(두 번째 오류 이후 수동 활성화)

• DAG에 네 개 이상의 구성원이 있고 사서함 데이터베이스당 세 개 이상의 고가용성 데이터베이스 복사본이 있는 자동, 이중 구성원 서버 오류를 위한 디자인

이 용량 계획 모델을 선택할 경우 단일 서버가 오버로드되지 않고 클라이언트 환경이 저하되지 않게 서버별로 활성화할 수 있는 데이터베이스의 수를 제한하는 것이 좋습니다.

최대 활성 데이터베이스 설정을 구성하여 데이터베이스 수를 제한할 수 있습니다. Exchange 관리 셸에서 Set-MailboxServer -MaximumActiveDatabases를 실행하여 이 제한을 구성할 수 있습니다. DAG에서 배포가 지원하는 최대 활성 데이터베이스에 맞게 각 서버에 이 제한을 구성합니다.

자세한 내용은 데이터베이스 가용성 그룹 디자인 예를 참조하십시오.

맨 위로 이동

배포할 사서함 서버 수 계획

배포할 사서함 서버 수를 결정할 때에는 배포되는 데이터베이스 복사본 수의 배수를 사용합니다. 예를 들어 세 개의 데이터베이스 복사본을 배포하려고 계획하는 경우 3, 6, 9, 12 또는 15개의 서버로 디자인을 시작합니다.

DAG 내의 서버 수에 대한 시작 지점을 결정한 후 사서함 수, 오류 디자인 모델 및 필요한 사서함 서버 수를 늘리거나 줄일 수 있는 기타 디자인 제약 조건에 따라 적절하게 DAG 구성원을 조정합니다.

많은 조직에서 사용하는 디자인 제약 조건 중 하나는 서버에 배치할 수 있는 최대 사서함 수입니다. 예를 들어 조직에 20,000개의 사서함이 있고 오류 발생 시 25%만 영향을 받을 수 있는 경우 단일 서버에 배포할 수 있는 최대 사서함 수는 5,000개입니다. 여기에는 최소 4개의 사서함 서버 배포가 필요합니다.

또한 선택한 서버 하드웨어 및 저장소 모델에 따라 서버별로 배포하는 사서함 수 또는 데이터베이스 수를 조정해야 할 수 있으며, 이로 인해 사서함 서버의 총 개수가 영향을 받을 수 있습니다.

여러 역할 서버 및 독립 실행형 역할 서버 비교

Exchange Server 2007에서 클라이언트 액세스 및 허브 전송 서버 역할은 클러스터된 사서함 서버와 분리된 서버에 있어야 합니다. Exchange 2010에서는 클러스터된 사서함 서버가 더 이상 존재하지 않으므로 이 제한이 더 이상 적용되지 않습니다. 클라이언트 액세스 및 허브 전송 서버 역할을 DAG 구성원에서 호스트할 수 있으므로 향상된 배포 옵션이 제공됩니다.

여러 역할 서버(동일한 서버의 사서함, 클라이언트 액세스 및 허브 전송 서버 역할) 배포 시 대부분의 아키텍처가 단순화됩니다. Edge 전송 및 통합 메시징 서버 이외의 모든 Exchange 2010 서버가 동일할 수 있습니다. 이러한 서버는 동일한 하드웨어, 소프트웨어 설치 프로세스 및 구성 옵션을 가질 수 있습니다. 서버 간의 일관성을 통해 Exchange 구현 관리가 단순화될 수 있습니다.

여러 역할 서버(확장성이 높은 환경)는 하이 메가사이클 기능을 제공하는 하이 코어 카운트 서버를 보다 효율적으로 사용할 수 있게 합니다. 개별적으로 배포 시 각 역할에는 권장되는 최대 2개의 채워진 프로세서 소켓이 있습니다. 역할 결합 시 프로세서 소켓의 권장되는 최대 개수는 네 개입니다. 서버는 더 큰 작업을 가질 수 있으며 그러면 조직의 전체 서버 수를 줄일 수 있습니다. 여러 역할 서버는 반복적으로 발생하는 운영 비용을 일회성 자본 비용으로 바꾸므로 더 적은 수의 서버를 배포하면 이러한 서버 관리 비용이 줄어듭니다. 서버 수가 줄어들면 전력, 냉각 및 데이터 센터 공간이 크게 감소하므로 반복적으로 발생하는 운영 비용을 줄일 수 있습니다.

여러 역할 개념이 효율적이긴 하지만 독립 실행형 서버 역할이 적절한 경우도 있습니다. 예를 들어 독립 실행형 역할 배포는 특정 가상화 환경에서나 특정 하드웨어 아키텍처(예: 하드웨어를 적절하게 격리할 수 없는 블레이드 서버 인프라)를 활용하고 있는 경우 적절할 수 있습니다.

여러 역할 서버 배포 시 프로세서 및 메모리 아키텍처를 적절하게 디자인해야 합니다. 프로세서 관점에서 사서함 서버 역할이 오류 상태 동안 사용 가능한 메가사이클의 40% 이상을 소비하지 않고 허브 전송 및 클라이언트 액세스 서버 역할을 위해 40%를 남겨 두도록 해야 합니다. 모든 서버 역할에 적절한 메모리를 사용할 수 있게 하려면 사서함 데이터베이스 캐시 이해에 정의된 메모리 지침을 따르십시오.

자세한 내용은 용량 계획에서의 다중 서버 역할 구성 이해를 참조하십시오.

맨 위로 이동

데이터베이스 복사본 레이아웃 계획

고가용성 디자인의 일부로 균형이 맞는 데이터베이스 복사본 레이아웃을 디자인해야 합니다. 데이터베이스 복사본 레이아웃 계획 시 다음 디자인 원칙을 사용해야 합니다.

• 각 복사본을 격리하여 특정 사서함 데이터베이스의 여러 데이터베이스 복사본 오류를 최소화해야 합니다. 예를 들어 동일한 서버 랙 내에서나 동일한 저장소 배열에서 특정 사서함 데이터베이스의 데이터베이스 복사본을 두 개 이상 배치하지 마십시오. 그렇지 않으면 랙 또는 배열 오류로 인해 동일한 데이터베이스의 여러 복사본 오류가 발생되며 이는 데이터베이스 가용성에 영향을 미칩니다.

• 일관된 분산 방식으로 데이터베이스 복사본을 레이아웃하여 활성 사서함 데이터베이스가 오류 후 균등하게 분산되도록 합니다. 특정 서버에서 각 데이터베이스 복사본의 활성화 기본 설정의 합은 동일하거나 거의 동일해야 하며, 그러면 복제가 정상이고 최신 상태라고 가정하여 오류 후 거의 동일하게 분산됩니다.

자세한 내용은 데이터베이스 복사본 레이아웃 디자인을 참조하십시오.

맨 위로 이동

백업 모델 아키텍처 계획

Exchange 2010을 올바르게 배포하고 구성할 경우, 기존 방식의 데이터 백업이 필요하지 않은 고유 데이터 보호를 제공하는 몇 가지 기능과 아키텍처 변경 사항을 사용할 수 있습니다. 다음 표를 사용하여 기존 백업 모델을 계속 활용해야 하는지 여부 또는 Exchange 2010에서 고유 데이터 보호 기능을 구현할 수 있는지 여부를 결정합니다.

논리적 손상은 일반적으로 지정 시간 백업이 필요한 시나리오입니다. 하지만 Exchange 2010에는 지정 시간 백업에 대한 필요성을 완화시킬 수 있는 여러 가지 사용 가능한 옵션이 있습니다.

• 단일 항목 복구에서 사용자가 사서함 폴더에 있는 항목의 특정 속성을 변경하는 경우 데이터베이스에 수정 사항이 기록되기 전에 해당 항목의 복사본이 복구할 수 있는 항목 폴더에 저장됩니다. 메시지 수정으로 복사본이 손상되는 경우 원래 항목을 복원할 수 있습니다.

• 일정 복구 도우미는 사서함 서버에 있는 사서함의 단일 모임 및 되풀이 모임 항목에 발생하는 불일치를 검색하고 수정하여 받는 사람이 모임 알림을 놓치거나 신뢰할 수 없는 모임 정보를 받지 않게 합니다.

• 사서함 이동 중에 Microsoft Exchange Mailbox Replication Service는 손상된 항목을 검색하고 대상 사서함 데이터베이스로 해당 항목을 이동하지 않습니다.

• Exchange 2010 SP1(서비스 팩 1)에는 New-MailboxRepairRequest cmdlet이 도입되어 검색 폴더의 손상, 항목 수, 폴더 보기 및 상위/하위 폴더 문제를 해결할 수 있습니다.

지정 시간 백업은 기존 백업 또는 지연된 데이터베이스 복사본일 수 있으며 둘 다 동일한 기능을 제공합니다. 둘 중에서의 선택은 복구 SLA에 의해 결정됩니다. 복구 SLA는 백업이 보존되어야 하는 기간뿐만 아니라 복구 지점 목표를 정의합니다(재해 발생 시 데이터가 특정 시간 내에 복원되어야 함). 복구 SLA가 14일 이하인 경우 지연된 데이터베이스 복사본을 활용할 수 있습니다. 복구 SLA가 14일 이상인 경우 기존 백업을 사용해야 합니다. Rogue 관리자 및 기업 또는 규정 준수 시나리오의 경우 지정 시간 백업은 일반적으로 기존 백업 솔루션을 결정하는 메시징 인프라 및 메시징 IT 직원과 별도로 유지 관리됩니다.

지정 시간 백업을 유지 관리하도록 선택하는 경우 디자인의 여러 측면에서 다음을 변경할 수 있습니다.

• 지연된 데이터베이스 복사본 배포에는 저장소 문제가 있습니다. ReplayLagTime 설정으로 인해 지연된 데이터베이스 복사본의 트랜잭션 로그에 추가 공간을 할당해야 합니다. 또한 지연된 데이터베이스 복사본의 배치가 저장소 아키텍처에 영향을 미칠 수 있습니다. (자세한 내용은 이 항목의 뒷부분에 나오는 "저장소 모델 아키텍처 계획"을 참조하십시오.)

• 하드웨어 기반 VSS 복제 솔루션은 데이터베이스 아키텍처당 두 개의 LUN을 필요로 하기 때문에 기존 백업 솔루션 배포에는 VSS(볼륨 섀도 복사본 서비스) 솔루션 유형에 따라 LUN(논리 단위 번호) 레이아웃에 대한 문제가 있습니다.

저장소 아키텍처에 따라 기존 백업 솔루션 활용 시 백업 및 복원 시간대 SLA를 충족시키기 위해 원하는 사용자 사서함 크기를 크게 줄여야 할 수 있습니다.

Exchange 고유 데이터 보호 배포 시 사서함 데이터베이스에서 순환 로깅을 사용합니다. 순환 로깅 사용 시 충분한 용량이 시스템에 제공되어 솔루션이 로그 자르기를 방지하는 재해 이벤트를 복구할 수 있게 해야 합니다. 최소한 3일 이상의 트랜잭션 로그 용량이 있어야 합니다(지연된 복사본 요구 사항 제외). 순환 로깅이 연속 복제에서 작동하는 방식에 대한 자세한 내용은 백업, 복원 및 재해 복구 이해를 참조하십시오.

백업 계획에 대한 자세한 내용은 다음을 참조하십시오.

• Exchange 2010 LUN 아키텍처 이해

• 사서함 데이터베이스 및 로그 용량 요소 이해

• 일정 복구 이해

• 복구 가능한 항목 이해

맨 위로 이동

저장소 모델 아키텍처 계획

Exchange 2010은 저장소 디자인에 유연성을 제공합니다. Exchange 2010에는 조직이 다양한 저장소 장치에서 Exchange를 실행할 수 있게 하는 성능, 안정성 및 고가용성의 향상 기능이 포함되어 있습니다. Exchange 2007에 도입된 디스크 I/O(입출력)에 대한 향상 기능을 기반으로 최신 버전의 Exchange는 필요한 저장소 성능이 낮아졌으며 더 많은 저장소 오류를 허용합니다.

솔루션이 적절한 디스크 대기 시간 및 반응성이 우수한 사용자 환경을 제공하면서 용량 요구 사항과 I/O 요구 사항의 균형을 조정할 수 있는 저장소 플랫폼을 선택합니다.

RAID 또는 JBOD

RAID 기술 또는 JBOD 접근 방식을 사용하는 저장소 플랫폼을 구현할지 여부를 결정합니다. 이 경우 저장소 플랫폼이 JBOD 구성을 허용하는 것으로 가정합니다. Exchange 관점에서 JBOD는 데이터베이스 및 단일 디스크에 저장된 관련 로그를 둘 다 가지고 있음을 의미합니다. JBOD에서 배포하려면 최소한 세 개의 고가용성 데이터베이스 복사본을 배포해야 합니다. 디스크가 실패하는 경우 해당 디스크에 있는 데이터베이스 복사본이 손실되기 때문에 단일 디스크 사용은 단일 오류 지점에 해당합니다. 최소한 세 개의 데이터베이스 복사본이 있으면 하나의 복사본(또는 디스크) 실패 시 두 개의 추가 복사본이 있으므로 내결함성이 보장됩니다. 하지만 세 개의 고가용성 데이터베이스 복사본 배치 및 지연된 데이터베이스 복사본 사용은 저장소 디자인에 영향을 줄 수 있습니다. 다음 표에서는 RAID 또는 JBOD 고려 사항에 대한 지침을 보여 줍니다.

RAID 또는 JBOD 고려 사항

주 데이터 센터 서버가 포함된 JBOD에서 배포하려면 DAG 내에 세 개 이상의 고가용성 데이터베이스 복사본이 필요합니다. 고가용성 데이터베이스 복사본을 호스트하는 동일한 서버에서 지연된 복사본을 혼합하는 경우(예: 전용 지연된 데이터베이스 복사본 서버 사용 안 함) 두 개 이상의 지연된 데이터베이스 복사본이 필요합니다.

JBOD를 사용하기 위한 보조 데이터 센터 서버의 경우 보조 데이터 센터에 두 개 이상의 고가용성 데이터베이스 복사본이 있어야 합니다. 보조 데이터 센터의 복사본이 손실되어도 보조 데이터 센터가 활성화되는 경우 WAN에서 다시 시드를 필요로 하거나 단일 오류 지점을 가지게 하지 않습니다. 고가용성 데이터베이스 복사본을 호스트하는 동일한 서버에서 지연된 데이터베이스 복사본을 혼합하는 경우(예: 전용 지연된 데이터베이스 복사본 서버 사용 안 함) 두 개 이상의 지연된 데이터베이스 복사본이 필요합니다.

전용 지연된 데이터베이스 복사본 서버의 경우 JBOD를 사용하려면 데이터 센터 내에 두 개 이상의 지연된 데이터베이스 복사본이 있어야 합니다. 그렇지 않으면 디스크 손실로 인해 지연된 데이터베이스 복사본 손실 및 보호 메커니즘 손실이 발생하게 됩니다.

자세한 내용은 저장소 구성 이해를 참조하십시오.

맨 위로 이동

 © 2010 Microsoft Corporation. 모든 권리 보유.