데이터베이스 복사본 레이아웃 디자인

 

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

마지막으로 수정된 항목: 2010-11-11

사서함 서버에 대해 고가용성 솔루션을 디자인할 때 다음을 포함한 다양한 인프라 구성 요소를 위한 고가용성을 지원해야 합니다.

  • Active Directory 및 DNS(Domain Name System)와 같은 인프라 서비스

  • DAG(데이터베이스 가용성 그룹) 구성원 서버

  • 디스크, 저장소 컨트롤러 및 저장소 선반과 같은 개별 저장소 구성 요소

  • 라우터, 스위치 및 집계기와 같은 개별 네트워크 구성 요소

  • 서버 및 저장소 랙

  • 전원 버스

  • 데이터 센터

각 구성 요소 영역은 오류 발생 가능성이 있는 지점을 표시하며, 오류 도메인이라고도 합니다. 따라서, 최종적으로 DAG의 가용성 수준은 솔루션 디자인 방법에 따라 달라져 이들 도메인 중 하나의 오류가 DAG 환경에 있을 수 있는 부정적인 영향을 격리하고 최소화합니다. 오류 도메인 간에 독립을 유지하려면 각 오류 도메인에 데이터베이스 복사본이 하나 있어야 합니다. 또한 오류로 인해 여러 개의 복사본을 사용할 수 없으므로 각 오류 도메인 당 둘 이상의 복사본이 필요하지 않습니다.

예를 들어, 시나리오에 데이터베이스 복사본이 두 개가 있다고 가정해 보겠습니다. 각 복사본은 별도의 디스크 집합에 저장되지만 두 개 모두 동일 저장소 배열 내에 있습니다. 어떤 이유로 저장소 배열이 실패하거나 사용할 수 없게 되는 경우 두 복사본 모두 사용할 수 없게 됩니다. 이 예에서 오류 도메인은 저장소 배열입니다. 각 사서함 데이터베이스의 단일 복사본만이 해당 배열에 있어야 합니다. 그렇지 않은 경우, 배열이 실패하면 데이터베이스의 여러(아마도 모든) 개의 복사본을 사용할 수 없게 됩니다.

사서함 아키텍처 계획 시 다음 추가 디자인 지점을 고려하십시오.

  • 여러 개의 데이터베이스 복사본을 배포하시겠습니까?

  • 얼마나 많은 데이터베이스 복사본을 배포하시겠습니까?

  • 사이트 복구 아키텍처가 있습니까?

  • 배포할 사서함 서버 복구 모델 종류는 무엇입니까?

  • 얼마나 많은 사서함 서버를 배포하시겠습니까?

  • 사용할 백업 모델은 무엇입니까?

  • 사용할 저장소 아키텍처는 무엇입니까?

다음 질문 내용을 계획하는 방법에 대한 자세한 내용은 고가용성 요소 이해를 참조하십시오.

목차

불안정한 데이터베이스 복사본 레이아웃

균형 조정된 데이터베이스 복사본 레이아웃 디자인

서버 오류 동안 예제 시나리오에서의 활성 데이터베이스 배포

디자인 시나리오

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

불안정한 데이터베이스 복사본 레이아웃

데이터베이스 복사본을 DAG 내에 분산해야 하는 방법을 이해하려면 고가용성을 갖춘 사서함 서버 솔루션을 위해 Contoso, Ltd가 계획한 DAG 디자인을 고려하십시오. Contoso는 다음으로 구성된 DAG를 구축합니다.

  • 사서함 서버 4개

  • 사서함 데이터베이스 20개

  • 각 사서함 데이터베이스의 복사본 2개

모든 서버가 단일 데이터 센터에 배포되며 각 서버에는 자체 전용 저장소가 있으며 각 서버는 자체 서버 랙에 배포됩니다.

Contoso는 고가용성을 갖춘 데이터베이스 복사본(예를 들어 지연되지 않음) 2개를 항상 사용할 수 있고 해당 솔루션이 데이터베이스 가용성에 부정적인 영향을 주지 않고 두 번의 동시 DAG 구성원 중단에도 지속되어야 합니다.

다음 요구 사항을 기반으로 사용된 데이터베이스 복사본 레이아웃이 다음 그림에 표시됩니다.

초기 데이터베이스 복사본 레이아웃

데이터베이스 복사본 레이아웃 표 1

처음에 4개의 DAG 구성원에서 각 데이터베이스의 활성 복사본을 확산하기 때문에 디자인은 괜찮아 보입니다. 그러나 이 디자인에는 몇 가지 고려해야 할 부분이 있습니다. 레이아웃은 서버 리소스 측면에서 최적이지 않습니다. 예를 들어, 단일 서버가 실패하면 다음 그림에서와 같이 데이터베이스가 균등하지 않게 배포됩니다.

단일 서버 오류 후의 데이터베이스 복사본 레이아웃

단일 서버 오류 후 데이터베이스 복사본 레이아웃

Server4가 실패하면 나머지 세 개의 서버에서 배포되지 않고 데이터베이스 DB16에서 DB20까지가 Server1에서 활성화됩니다. 결과적으로 활성화된 사서함 데이터베이스를 균등하기 않게 배포하며 서버 리소스를 균등하지 않게 활용합니다. 나머지 다른 두 서버(Server2 및 Server3)와 비교하면 Server1의 활용이 두 배가 됩니다.

또 다른 문제는 모든 경우에 두 번의 동시 서버 중단에도 지속될 수 있도록 충분한 복사본이 DAG에 없다는 것입니다. 다른 서버 오류가 발생하면 데이터베이스의 50%를 사용할 수 없게 됩니다. Server1 및 Server4에서 오류가 발생하거나 서로 잠시 사용할 수 없게 되는 경우, 다음 그림에서와 같이 데이터베이스 10개를 사용할 수 없습니다.

이중 서버 오류 후의 데이터베이스 복사본 레이아웃

이중 서버 오류 후 데이터베이스 복사본 레이아웃

이 디자인은 이중 서버 오류에도 지속될 수 있도록 하는 핵심 요구사항을 충족하지 않습니다. 이중 서버 오류에도 지속되고 모든 활성 데이터베이스를 유지 관리하려면 세 번째 복사본이 배포되고 새 레이아웃을 만들어야 합니다.

맨 위로 이동

균형 조정된 데이터베이스 복사본 레이아웃 디자인

균형 조정된 데이터베이스 복사본 레이아웃을 디자인하려면 최적의 디자인을 구성하도록 몇몇 디자인 결정을 다시 검토해야 합니다. 데이터베이스 복사본 레이아웃을 계획할 때 다음 디자인 원칙을 사용합니다.

  • 각 복사본을 다른 복사본에서 분리하고 각기 다른 오류 도메인에 배치하여 사서함 데이터베이스의 여러 데이터베이스 복사본 오류를 최소화해야 합니다. 예를 들어, 특정 사서함 데이터베이스의 데이터베이스 복사본 두 개 이상을 동일한 서버 랙 또는 동일한 저장소 배열에 배치하지 마십시오.

  • 오류 후 활성 사서함 데이터베이스가 고르게 배포되도록 일관성 있는 배포 방식으로 데이터베이스 복사본의 레이아웃을 지정합니다. 특정 서버에서 각 데이터베이스 복사본의 활성화 기본 설정의 합계가 동일하거나 거의 동일해야 합니다. 이런 경우 복제본이 정상이고 최신이라고 가정하면, 오류 후 거의 동일하게 배포됩니다.

구성 요소

이전 디자인 원칙을 준수하려면 모든 활성 복사본이 가능한 많은 서버에 대칭적으로 배포되도록 데이터베이스 복사본을 특정 배열로 배치하는 것이 좋습니다. 데이터베이스 복사본의 배열은 구성 요소 개념을 기반으로 합니다.

첫 번째 구성 요소(수준 1 구성 요소라고도 함)는 활성 데이터베이스 복사본을 호스트하는 사서함 서버의 수를 기반으로 합니다. 이 수를 N이라고 가정합니다. N은 사서함 서버의 수뿐만 아니라 구성 요소 내의 데이터베이스 수도 정의합니다. 활성 데이터베이스 복사본 하나는 각 서버에 대각선 패턴을 이루면서 배포됩니다. 이전 예에서와 같이 사서함 서버 4개가 있고 사서함 데이터베이스 20개가 있습니다. 다음 그림에서와 같이 첫 번째 수준 1 구성 요소의 크기는 4입니다.

수준 1 구성 요소

수준 1 구성 요소

동일한 패턴이 나머지 각 수준 1 구성 요소 집합에 대해 반복됩니다. 20개의 데이터베이스가 있기 때문에 다음 그림에서와 같이 수준 1 구성 요소 집합이 다섯 개가 있습니다.

데이터베이스 20개에 대해 수준 1 구성 요소 5개

데이터베이스 20개에 대해 수준 1 구성 요소 5개

두 번째 데이터베이스 복사본을 추가하면 각 구성 요소 집합에 다르게 배치합니다. 하나의 서버가 이미 활성 복사본을 호스트하기 때문에 N – 1 서버가 두 번째 데이터베이스 복사본을 호스트할 수 있습니다. 이러한 각 N – 1 서버를 한 번 사용하면 더 큰 새 구성 요소를 이루는 완전한 대칭 배포가 이루어집니다. 그러므로 새 구성 요소(수준 2 구성 요소라고 하는) 크기는 N × (N – 1) 데이터베이스가 됩니다. 이는 첫 번째 데이터베이스의 두 번째 데이터베이스 복사본이 두 번째 서버에 배치되며 각 두 번째 복사본이 구성 요소 내에 대각선 패턴으로 배포됨을 의미합니다. 첫 번째 수준 1 구성 요소 집합 내에서 해당 패턴이 완성되면 다음 블록의 두 번째 복사본의 시작 위치가 하나씩 오프셋되어 두 번째 복사본이 세 번째 서버에서 시작됩니다.

예에서 이제 구성 요소 크기가 4× (4 – 1) = 4× 3 = 12가 되며, 12개의 데이터베이스는 각 수준 2 구성 요소 집합을 구성합니다. 수준 1 구성 요소 집합 1(DB1-DB4)의 경우 DB1의 두 번째 복사본이 Server2에 배치되며, 수준 1 구성 요소 집합 2(DB5-DB8)의 경우 DB5의 두 번째 복사본이 Server3에 배치됩니다. 각 수준 1 구성 요소 집합의 시작 서버 배치는 이전 수준 1 구성 요소 집합에서 한 서버씩 오프셋됩니다. DB9의 두 번째 복사본을 Server4에 배치하여 이 레이아웃을 계속 수행합니다. 이렇게 하면 Server1 오류로 인해 동일 서버에서 여러 데이터베이스가 활성화되지 않고 나머지 모든 3개의 서버에서 두 번째 복사본이 활성화됩니다.

수준 1 구성 요소가 3개인 수준 2 구성 요소

수준 1 구성 요소가 3개인 수준 2 구성 요소 1개

나머지 각 두 번째 구성 요소 집합에 대해 이 패턴이 반복됩니다. 20개의 데이터베이스가 있기 때문에 이 예에는 수준 2 구성 요소 집합이 두 개가 있습니다. DB13의 두 번째 복사본이 Server2에 배치되어야 합니다.

나머지 수준 1 구성 요소가 2개인 수준 2 구성 요소

나머지 2개의 구성 요소가 있는 수준 2 구성 요소

이 논리를 더 잘 이해하려면 DB1, DB5 및 DB9의 데이터베이스 복사본 배치를 비교해 보십시오. 각 데이터베이스에는 활성 복사본이 Server1에서 호스트됩니다. Server1에서 오류가 발생하는 경우, 두 번째 데이터베이스 복사본을 나머지 다른 서버에서 활성화하여 균등하게 부하를 배포할 수 있습니다. DB1의 두 번째 데이터베이스 복사본을 Server2에 배치하고, DB5의 두 번째 데이터베이스 복사본을 Server3에 배치하고, DB9의 두 번째 데이터베이스 복사본을 Server4에 배치하여 이를 달성할 수 있습니다. DB13에서부터 이 패턴을 반복합니다. 다음 그림에서와 같이 나머지 데이터베이스 복사본은 대각선 패턴으로 추가됩니다.

균등한 배포를 위한 데이터베이스 복사본 배치

균등한 배포를 위한 데이터베이스 복사본 배치

두 번째 구성 요소(DB13-DB20)에는 12개가 아닌 8개의 데이터베이스만이 포함됩니다. 단일 오류가 발생한 경우 이 디자인은 완전히 대칭되지 않습니다. 완전히 대칭으로 배포하기 위해 데이터베이스의 개수가 가장 큰 구성 요소 크기의 배수가 되도록 아키텍처를 계획하십시오. (이 예에서 가장 적합한 수는 24, 36, 48 또는 60개 등의 데이터베이스입니다.)

세 번째 데이터베이스 복사본을 추가하면, N × (N – 1) 데이터베이스의 각 그룹에 대해 다시 다르게 배치해야 합니다. N – 2 서버만을 세 번째 데이터베이스 복사본 배치를 위해 선택할 수 있기 때문에 N – 2 변형을 생성합니다. 새 구성 요소(수준 3 구성 요소라고 하는)는 N × (N – 1) × (N – 2) 데이터베이스가 됩니다. 그러므로, 첫 번째 데이터베이스의 세 번째 데이터베이스 복사본이 세 번째 서버에 배치되며 이 새 구성 요소 내의 시작 위치에 따라 각 세 번째 복사본이 대각선 패턴으로 배포됩니다. 해당 패턴이 첫 번째 수준 1 구성 요소 집합 내에서 완성된 후 세 번째 복사본이 네 번째 위치에 배치되도록 시작 위치가 하나씩 오프셋됩니다.

이 예에서 이제 구성 요소는 4 × (4 – 1) × (4 – 2) = 4 × 3 × 2 = 24가 되며, 24개의 데이터베이스가 각 수준 3 구성 요소 집합으로 구성된다는 것을 의미합니다. 대칭 데이터베이스 배치 패턴을 제공하기 위해 DB1의 세 번째 데이터베이스 복사본을 Server3(Server1이 첫 번째 복사본을 호스트하고 Server2가 두 번째 복사본을 호스트하기 때문에 첫 번째로 사용 가능한 서버임)에 배치하고 수준 1 구성 요소 집합 1의 끝에 도달할 때까지 각 추가 복사본이 하나씩 오프셋됩니다. 다음 구성 요소 집합의 경우 세 번째 데이터베이스 복사본을 사용 가능한 다음 서버(Server4)에 다시 배치하고 DB12에 도달할 때까지 같은 방식으로 계속되며, 이는 수준 2 구성 요소 집합 1의 끝을 표시합니다. DB13-DB20의 경우, 동일 패턴을 따르지만 세 번째 데이터베이스 복사본이 하나씩 오프셋되어 DB1-DB12에서와 같은 동일 서버가 아닙니다.

데이터베이스 복사본이 3개이고 서버가 4개인 균형 조정된 레이아웃

복사본이 3개이고 서버가 4개인 균형 조정된 레이아웃

다시 이 논리를 더 잘 이해하려면 데이터베이스 DB1-DB13의 데이터베이스 복사본 배치를 비교해 보십시오. 이러한 데이터베이스에는 Server1에서 호스트된 활성 데이터베이스 복사본이 있으며 Server2에서 호스트된 두 번째 데이터베이스가 있습니다. 서버에서 오류가 발생하는 경우, 세 번째 데이터베이스 복사본을 나머지 다른 서버에서 활성화하여 균등하게 부하를 배포할 수 있습니다. DB1의 세 번째 데이터베이스 복사본을 Server3에 배치하고 DB13의 세 번째 데이터베이스를 Server4에 배치하여 균등하게 이를 달성할 수 있습니다. 유사한 쌍이 DB2와 DB14, DB3과 DB15 등으로 이루어집니다. DB25에서부터 이 패턴을 반복합니다(이 예에서는 여러 데이터베이스를 처리하지 않습니다).

세 번째 구성 요소(DB1-DB20)는 24개의 데이터베이스가 아닌 20개의 데이터베이스여야 합니다. 결과적으로 이중 오류가 발생한 경우 이 디자인은 완전히 대칭되지 않습니다. 다시 완전히 대칭으로 배포하기 위해 데이터베이스의 개수가 가장 큰 구성 요소 크기의 배수가 되도록 아키텍처를 계획하십시오. (이 예에서 가장 적합한 수는 24, 48 또는 72개 등의 데이터베이스입니다.)

네 번째 데이터베이스 복사본을 추가하면 N × (N – 1) × (N – 2) 데이터베이스의 각 그룹에 대해 다르게 배치해야 합니다. 새 구성 요소는 N × (N – 1) × (N – 2) × (N – 3) 데이터베이스가 됩니다. 동일한 논리 방법을 따르며 세 개의 서버에서 오류가 발생하는 경우 데이터베이스 배포가 새 구성 요소 내에서 균등해야 합니다.

4개의 서버 예는 네 번째 데이터베이스 복사본을 배치하기 위한 하나의 변형만을 남깁니다(나머지 한 서버만을 사용할 수 있음). 그러므로 실제 남은 구성 요소 크기는 24입니다. 구성 요소 크기에 대한 공식을 사용할 때도 분명합니다. 4 × 3 × 2 × (4 – 3) = 4 × 3 × 2 × 1 = 24.

계속 데이터베이스 복사본을 추가하면 구성 요소 크기의 일반 공식이 Perm(N,M) = N × (N – 1) … (NM + 1) = N!/(NM)! = CNMM!이 되도록 구성 요소가 계속 커집니다, 여기서 N은 서버의 수이며 M은 데이터베이스 복사본의 수입니다. 사용 가능한 N 서버에서 가능한 모든 M 데이터베이스 복사본의 순열을 선택하여 데이터베이스 복사본의 완전한 대칭 배포가 이루어진다고 생각하면 분명해집니다.

이 방식을 사용하는 데 있어 몇몇 경고가 있습니다.

  • 가장 큰 구성 요소 크기의 배수가 아닌 데이터베이스의 수를 배포하면 오류 이벤트 동안 활성 데이터베이스가 대칭되지 않게 배포됩니다.

  • 여러 도메인 오류를 줄이도록 아키텍처를 배포하면 오류 이벤트 동안 활성 데이터베이스가 대칭되지 않게 배포될 수 있습니다. 오류 도메인 정의가 데이터베이스 복사본 배치에 대한 제한을 적용해야 하기 때문이며, 패턴의 대칭이 깨집니다.

  • 기본 데이터 센터 서버 오류 이벤트 동안 *이벤트에서 사이트 외부 데이터베이스가 되는 사이트 복구 솔루션을 배포하면 두 번째 데이터 센터에서 활성화된 데이터베이스를 비대칭적으로 배포할 수 있습니다.

맨 위로 이동

서버 오류 동안 예제 시나리오에서의 활성 데이터베이스 배포

이전 예를 사용하는 단일 서버 오류의 경우(예를 들어 Server4의 오류), 활성 사서함 데이터베이스는 다음 그림에서와 같이 배포됩니다. 두 번째 복사본은 활성으로 지정한 DB4, DB8, DB12, DB16 및 DB20에 대해 주황색으로 활성화됩니다.

단일 서버 오류 후의 활성 데이터베이스 복사본 배포

오류 후 활성 데이터베이스 복사본 배포

이중 서버 오류가 발생하면(세 번째 복사본이 몇몇 데이터베이스에 대해 활성화되며 녹색의 활성으로 지정됨), 나머지 서버 2개, Server1 및 Server3이 활성화된 사서함 데이터베이스와 같은 수가 됩니다.

이중 서버 오류 후의 활성 데이터베이스 복사본 배포

이중 오류 후 활성 복사본 배포

그러나 이 예의 데이터베이스 수가 가장 큰 구성 요소 크기(24개의 데이터베이스)의 배수가 아니기 때문에 모든 이중 서버 오류 이벤트가 대칭적으로 배포되는 것은 아닙니다.

다른 이중 서버 오류 후의 활성 데이터베이스 복사본 배포

여러 오류 후 활성 복사본 배포

맨 위로 이동

디자인 시나리오

연관된 수학 공식을 포함한 데이터베이스 복사본 레이아웃의 디자인 원칙을 이해하려면 다른 두 아키텍처 레이아웃을 고려하십시오.

디자인 시나리오: 활성/수동 사용자 배포 사이트 복구 솔루션

이 시나리오에서 Contoso는 다음 아키텍처를 배포합니다.

  • DAG는 활성/수동 사용자 배포 모델에서 작동하는 두 개의 데이터 센터에서 확장됩니다.

  • 각 서버는 별도의 서버 랙에 배포됩니다.

  • 각 서버의 저장소는 데이터 센터 내의 다른 서버 저장소와 분리됩니다.

  • 데이터 센터 당 4개의 사서함 서버가 있습니다.

  • 총 24개의 사서함 데이터베이스가 있습니다.

  • 우리가 원하는 바는 고가용성 데이터베이스 복사본이 4개가 있고 이중 서버 오류 또는 단일 데이터 센터 오류에도 지속되도록 하는 것입니다.

이 예에서 수준 1 구성 요소는 4개이며, 데이터베이스는 4개 단위로 분류되며 활성 복사본이 구성 요소 내의 4개 서버에 배포됩니다.

한 구성 요소에 첫 번째 복사본을 고르게 배포

구성 요소에 데이터베이스를 고르게 배포

활성 복사본을 호스트하는 각 서버의 경우, 각 복사본이 다른 복사본과 분리되기 때문에 계속 대각선 패턴으로 두 번째 데이터베이스 복사본이 나머지 모든 구성원 서버에 가능한 한 고르게 배포됩니다. 이 예에서 수준 2 구성 요소가 12개가 되며, 12개의 데이터베이스마다 반복되는 집합이 됩니다.

한 구성 요소에 두 번째 복사본을 고르게 배포

구성 요소에 두 번째 복사본을 고르게 배포

이 사이트 복구 솔루션이 두 데이터 센터의 서버와 데이터베이스 복사본의 수와 같은 활성/수동 사용자 배포 모델이기 때문에, 세 번째 데이터베이스 복사본이 수준 1 구성 요소 값인 4를 사용하여 Server5와 Server6에 대각선 패턴으로 배치됩니다. 이렇게 되면 Server5와 Server6이 Server1에서 Server4까지의 첫 번째 데이터베이스 복사본 배치를 미러링합니다.

두 번째 구성 요소에 세 번째 복사본을 고르게 배포

구성 요소에 세 번째 복사본을 고르게 배포

이 사이트 복구 솔루션이 두 데이터 센터의 서버와 데이터베이스 복사본의 수와 같은 활성/수동 사용자 배포 모델이기 때문에, 네 번째 데이터베이스 복사본이 수준 2 구성 요소 값인 12를 사용하여 Server5와 Server6에 대각선 패턴으로 배치됩니다. 이렇게 되면 Server5와 Server6이 Server1에서 Server4까지의 두 번째 데이터베이스 복사본 배치를 미러링합니다.

두 번째 구성 요소에 네 번째 복사본을 고르게 배포

구성 요소에 네 번째 복사본을 고르게 배포

단일 서버 오류가 발생하면 기본 데이터 센터의 나머지 세 개의 서버가 활성화된 사서함 데이터베이스와 같은 수가 됩니다(서버당 8개).

단일 서버 오류 후의 활성 데이터베이스 복사본 배포

서버 오류 후 활성 복사본 배포

두 개의 동시 서버 오류가 발생하면 기본 데이터 센터의 나머지 두 개의 서버가 활성화된 사서함 데이터베이스와 같은 수가 되며(서버당 10개) 4개의 데이터베이스가 두 번째 데이터 센터에서 활성화됩니다.

이중 서버 오류 후의 활성 데이터베이스 복사본 배포

이중 오류 후 활성 복사본 배포

디자인 시나리오: 다중 오류 도메인

이 예에서 Wingtip Toys는 다음 아키텍처를 배포합니다.

  • 모든 서버가 단일 데이터 센터에 배포됩니다.

  • 서버는 3개 단위로 분류됩니다.

  • 세 서버의 각각은 저장소가 있는 동일 랙에 배치됩니다.

  • 총 3개의 랙과 9개의 서버가 있습니다.

  • 총 18개의 사서함 데이터베이스가 있습니다.

  • 우리가 원하는 바는 고가용성 데이터베이스 복사본이 3개가 있고 두 구성원 서버 오류 또는 단일 랙 오류에도 지속되도록 하는 것입니다.

이 예에서 수준 1 구성 요소는 6개이며, 데이터베이스는 6개 단위로 분류되며 활성 복사본이 구성 요소 내의 6개 서버에 배포됩니다.

수준 1 구성 요소의 데이터베이스 복사본 레이아웃

수준 1 구성 요소의 데이터베이스 복사본 레이아웃

활성 복사본을 호스트하는 각 서버의 경우, 두 번째 데이터베이스 복사본이 나머지 모든 구성원 서버에 가능한 한 고르게 확산되며, 또한 동일 데이터베이스의 두 복사본이 같은 서버 랙에 배치되지 않습니다. 이 예에서 N × (N – 1)의 수준 2 구성 요소 공식 대신, N × (N – 2)의 공식이 사용되어 같은 데이터베이스의 두 복사본이 같은 랙에 배치되지 않습니다. 즉, 수준 2 구성 요소가 6 × 4 = 24개임을 의미합니다.

첫 번째 및 두 번째 복사본의 데이터베이스 복사본 레이아웃

첫 번째 및 두 번째 복사본을 위한 데이터베이스 복사본 레이아웃

세 번째 데이터베이스 복사본이 서버에서 대각선 패턴으로 배치되며, 동일한 데이터베이스의 여러 복사본이 같은 서버 랙에 배치되지 않습니다. 이 예에서 수준 3 구성 요소 공식 N × (N – 2) 대신, N × (N – 2) × (N – 4)의 공식이 사용되어 같은 데이터베이스의 두 복사본이 같은 랙에 배치되지 않습니다. 즉, 수준 3 구성 요소가 6 × 4 × 2 = 48개임을 의미합니다.

첫 번째, 두 번째 및 세 번째 복사본의 데이터베이스 복사본 레이아웃

세 개의 복사본을 위한 데이터베이스 복사본 레이아웃

단일 서버 오류가 발생하면 기본 데이터 센터의 나머지 다섯 개의 서버가 활성화된 사서함 데이터베이스와 거의 같은 수가 됩니다. 4개의 서버에는 서버당 10개의 활성화된 데이터베이스가 있으며 반면 한 서버(랙 파트너)에는 8개의 활성화된 데이터베이스가 있습니다.

단일 서버 오류 후의 활성 데이터베이스 수 및 레이아웃

오류 후 활성 데이터베이스 수 및 레이아웃

두 개의 동시 서버 오류가 발생하면(다른 랙) 나머지 4개의 서버에는 거의 같은 수의 활성화된 사서함 데이터베이스가 있습니다.

이중 서버 오류 후의 활성 데이터베이스 수 및 레이아웃(다른 랙)

이중 오류 후 활성 데이터베이스 수 및 레이아웃

두 개의 동시 서버 오류가 발생하면(같은 랙) 나머지 4개의 서버에는 같은 수의 활성화된 사서함 데이터베이스가 있습니다.

이중 서버 오류 후의 활성 데이터베이스 수 및 레이아웃(동일 랙)

이중 오류 후 활성 데이터베이스 수 및 레이아웃

맨 위로 이동

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