6.2. 일반적인 복제 시나리오
다음 일반적인 시나리오를 사용하여 필요에 가장 적합한 복제 토폴로지를 빌드할 수 있습니다.
6.2.1. 단일 공급 업체 복제
단일 제공 복제 시나리오에서는 공급자 서버가 디렉토리 데이터(읽기-쓰기 복제본)의 주요 복사본을 유지 관리하고 이 데이터의 업데이트를 하나 이상의 소비자 서버로 보냅니다. 모든 디렉터리 수정은 공급자 서버의 읽기-쓰기 복제본에서 수행되며 소비자 서버에는 데이터의 읽기 전용 복제본이 포함됩니다.
공급자 서버는 공급자 복제본의 모든 변경 사항을 기록하는 변경 로그를 유지합니다.
다음 다이어그램은 단일 공급 업체 복제 시나리오를 보여줍니다.
그림 6.1. 단일 공급 업체 복제
단일 공급자 서버가 관리할 수 있는 총 소비자 서버 수는 네트워크의 속도와 매일 수정된 총 항목 수에 따라 달라집니다.
6.2.2. 다중 제공 복제
다중 제공 복제 환경에서는 동일한 정보의 주요 사본이 여러 서버에 존재할 수 있으며 디렉터리 데이터를 다른 위치에서 동시에 업데이트할 수 있습니다. 각 서버에서 발생하는 변경 사항은 다른 서버에 복제되므로 각 서버가 공급업체와 소비자 역할을 합니다.
여러 서버에서 동일한 데이터를 수정하면 복제 충돌이 발생합니다. 충돌 해결 절차를 사용하여 Directory Server는 최근 변경 사항을 유효한 작업으로 사용합니다.
멀티 공급 업체 환경에서 각 공급 업체는 소비자와 다른 공급 업체를 가리키는 복제 계약이 있어야합니다. 예를 들어 두 공급업체, provider A 및 provider B 와 소비자 C 및 소비자 D 두 개로 복제를 구성합니다. 또한 하나의 공급업체가 하나의 소비자만 업데이트한다고 결정합니다. 공급업체 A에서 및 공급업체 B소비자 C 를 가리키는 복제 계약을 생성합니다. 공급업체 B에서 및 공급업체 A소비자 D 를 가리키는 복제 계약을 생성합니다. 다음 다이어그램에서는 복제 계약을 보여줍니다.
그림 6.2. 두 공급업체를 통한 멀티 공급 업체 복제
Red Hat Directory Server는 모든 복제 환경에서 최대 20개의 공급자 서버와 무제한의 허브 및 소비자 서버를 지원합니다.
많은 공급업체를 사용하려면 다양한 복제 계약을 생성해야 합니다. 또한 각 공급업체는 서로 다른 토폴로지로 구성할 수 있으므로 디렉터리 서버 환경에 20개의 디렉토리 트리와 스키마 차이가 있을 수 있습니다. 다른 많은 변수는 토폴로지 선택에 직접적인 영향을 미칠 수 있습니다.
공급업체는 다른 모든 공급 업체 또는 일부 공급 업체에 업데이트를 보낼 수 있습니다. 업데이트가 모든 공급업체에 전송되면 변경 사항이 더 빨라지고 전체 시나리오가 장애 허용성이 향상됩니다. 그러나 공급업체 구성의 복잡성이 증가하고 높은 네트워크 및 높은 서버 수요를 도입합니다. 공급업체의 하위 집합에 업데이트를 보내는 것은 네트워크 및 서버 로드를 구성하고 줄이는 것이 훨씬 쉽지만 여러 서버 오류가 발생하면 데이터 손실 위험이 증가합니다.
완전히 연결된 메시 토폴로지
다음 다이어그램은 4개의 공급업체 서버가 다른 모든 공급자 서버에 데이터를 복제하는 완전히 연결된 메시 토폴로지를 보여줍니다. 하나의 복제 계약에는 하나의 공급업체와 하나의 소비자 간의 관계를 설명하기 때문에 총 4개의 공급자 서버 간에 복제 계약이 존재합니다.
20개의 공급업체가 있는 경우 총 20개의 공급업체(각각 19개의 공급업체)에 380개의 복제 계약을 생성해야 합니다.
두 개 이상의 서버가 동시에 실패할 가능성이 적거나 특정 공급 업체 간의 연결이 작으면 부분적으로 연결된 토폴로지를 사용하는 것이 좋습니다.
부분적으로 연결된 토폴로지
다음 다이어그램은 각 공급자 서버가 두 공급자 서버에 데이터를 복제하는 토폴로지를 보여줍니다. 이전 예제 토폴로지에 비해 4개의 공급업체 서버 간에는 8개의 복제 계약만 존재합니다.
6.2.3. 계단식 복제
계단식 복제 시나리오에서는 허브 서버가 공급자 서버에서 업데이트를 수신하고 이러한 업데이트를 소비자 서버로 보냅니다. 허브 서버는 일반적인 소비자 서버와 같은 읽기 전용 복제본을 보유하고 있으며 일반적인 공급자 서버와 같은 변경 로그를 유지 관리하기 때문에 하이브리드입니다.
Hub 서버는 공급자 데이터를 소비자에게 전달하고 디렉터리 클라이언트의 업데이트 요청을 공급자에게 참조합니다.
다음 다이어그램에서는 계단식 복제 시나리오를 보여줍니다.
그림 6.3. 계단식 복제 시나리오
다음 다이어그램은 각 서버에 복제본을 구성하는 방법과 변경 로그를 유지 관리하는 서버(읽기-쓰기 또는 읽기 전용)를 보여줍니다.
그림 6.4. cascading 복제의 복제 트래픽 및 변경 로그
계단식 복제는 다음과 같은 경우에 유용합니다.
- 많은 트래픽 부하를 분산합니다. 복제 토폴로지의 공급자는 모든 업데이트 트래픽을 관리하므로 소비자에게 복제 트래픽을 지원하기 위해 많은 부하가 있을 수 있습니다. 많은 수의 소비자에 대한 복제 업데이트를 서비스할 수 있는 허브로 복제 트래픽을 리디렉션할 수 있습니다.
- 지리적으로 분산된 환경에서 로컬 허브 공급업체를 사용하여 연결 비용을 절감하려면 다음을 수행하십시오.
- 디렉터리 서비스의 성능을 높이기 위해 다음을 수행합니다. 모든 읽기 작업을 소비자에게 전달하고 모든 업데이트 작업을 공급자에게 보내는 경우 허브 서버에서 모든 인덱스(시스템 인덱스 제외)를 제거할 수 있습니다. 이렇게 하면 공급자와 허브 서버 간 복제 속도가 크게 증가합니다.
6.2.4. 혼합 시나리오
복제 시나리오를 네트워크 및 디렉터리 환경의 요구 사항에 맞게 결합할 수 있습니다. 일반적인 조합 중 하나는 계단식 구성과 함께 다중 제공 구성을 사용하는 것입니다.
다음 다이어그램은 혼합 시나리오에 대한 예제 토폴로지를 보여줍니다.
그림 6.5. Multi-supplier 및 cascading 복제
