복제 및 서버 토폴로지
네트워크의 HCLDomino® 서버 수가 증가하면, 네트워크를 통해 정보를 분배하는 데 필요한 복제 양도 증가합니다. 복제에는 메모리 및 처리 시간이 필요하므로 서버가 복제를 수행하기 위해 연결하는 방법을 계획하십시오. 서버의 임의 복제를 허용할 경우, 지정된 서버가 여러 서버에서 단일 데이터베이스를 복제하거나 다른 서버에서 다른 데이터베이스를 복제할 수도 있기 때문에, 서버는 복제 요청으로 인해 과부하 상태가 되어 클라이언트 요청에 대해서는 응답하지 못하게 될 수 있습니다.
효과적으로 복제하려면 일부 서버를 복제 전용 서버로 설정하십시오. 데이터베이스 서버는 지정된 데이터베이스의 복사본을 유지관리하는 모든 서버로 복제하지 않고 복제 서버만으로 복제해야 하기 때문에, 전용 서버를 사용하여 복제를 처리하면 데이터베이스 서버가 복제에 전념하는 작업량이 크게 줄어듭니다. 복제를 제어하려면 복제할 서버와 시기를 지정하는 연결 문서를 작성하십시오.
메일 라우팅을 위해 작성된 기존의 연결 문서를 몇 번까지 재사용할 것인지 및 실제 네트워크 레이아웃 및 조직의 크기를 포함한 많은 요소에 따라, 복제를 위한 서버 연결 방법이 결정됩니다. 서버 간에 복제가 수행되는 방법을 제어할 수 있는 다음과 같은 여러 가지 설정 또는 토폴로지가 있습니다.
- 허브 앤 스포크
- 피어 투 피어
- 링
가장 효율적인 복제 성능을 제공하는 복제 전략을 선택하십시오. 대부분의 경우, 네트워크의 여러 부분에서 다양한 토폴로지를 사용할 수 있습니다.
허브 앤 스포크 토폴로지를 사용하여 복제 관리
일반적으로 허브 앤 스포크 토폴로지는 특히 대규모 조직에서 네트워크 트래픽을 최소화하기 때문에 가장 효율적인 공용 복제 토폴로지입니다. 허브 앤 스포크 복제는 하나의 중앙 서버를 허브로 설정하고, 여기서 다른 모든 서버나 스포크의 복제를 예약한 후 시작합니다. 스포크는 복제(및 메일 라우팅)를 통해 허브 서버를 업데이트하고, 허브에서 차례로 각 스포크를 업데이트합니다. 허브 서버는 서로 복제하거나 조직 내에서 두 개 이상의 허브를 사용하는 조직의 마스터 허브 서버를 복제합니다. 다시 말하면, 허브 서버가 시스템의 트래픽 관리자로 시스템 자원을 관리하고 차례로 각 스포크에 복제를 수행하여 모든 스포크 서버에 변경사항을 복제합니다.
허브 앤 스포크 시스템에 복제를 설정하려면, 각 허브 앤 스포크 연결에 대한 연결 문서를 작성합니다. 스포크가 아닌 허브에서 대부분의 복제 태스크를 항상 수행하려면 각 연결 문서에서 허브 서버를 소스 서버로, 스포크 서버를 대상 서버로, 그리고 pull-push를 복제 방법으로 지정합니다.
허브 앤 스포크 토폴로지는 대기업, 다중 서버 사이트에 유용하거나, 전화나 전용 회선을 통해 소규모 조직에 연결하여 업무를 처리하는 중앙 집중식 사무실에 특히 유용합니다. 규모가 큰 경우, 토폴로지를 조합하여 사용할 수 있습니다. 예를 들어, 두 허브 서버 간에 두 개의 허브 앤 스포크와 한 개의 피어 투 피어 토폴로지를 같이 사용합니다.
허브 앤 스포크 토폴로지는 허브가 작동하지 않을 때 항상 실패하는 단점이 있습니다. 허브를 복제하고 기본 허브가 다운될 때 허브 서버로 빨리 재설정될 수 있는 백업 서버를 배치하면 이 문제를 해결할 수 있습니다.
허브 앤 스포크 토폴로지 장점
- 허브 서버에 여러 개의 프로토콜을 설치하여 두 개 이상의 프로토콜을 사용하는 Domino® 시스템에서 통신할 수 있습니다. 이렇게 하면 다중 HCLNotes® 지정 네트워크에 허브 서버가 설치됩니다. 허브 서버는 단일 허브 서버와 해당 스포크 서버가 하나의 Notes® 지정 네트워크를 구성하는 다중 Notes® 지정 네트워크에 연결할 수 있습니다.
- 예를 들어, LAN 및 WAN과 같이 네트워크 부분을 구성합니다.
- Domino® 디렉토리의 관리를 중앙 집중화하고, 데이터베이스 ACL을 표준화하며, 허브에 대한 액세스를 제한합니다. 허브에는 관리자 권한을 스포크에는 독자 권한을 지정하여 복제본(허브 상)의 변경사항을 스포크와 동기화시킬 수 있습니다.
- 허브의 역할을 지정합니다. 예를 들어, 복제 허브와 메일 허브입니다.
- MTA와 같은 서버 프로그램을 허브에 설치하여 서버에 쉽게 액세스하도록 합니다.
- 허브 서버를 사용하여 원격 사이트에 연결합니다.
- 네트워크 트래픽은 최소화하고, 네트워크 효율성은 최대화합니다.
- 허브에서 데이터 백업을 중앙 집중화합니다. 허브의 데이터베이스만 백업하여 스포크 서버의 자원을 보존합니다.
- 서버 로드 밸런싱이 향상되지만, 허브 LAN 세그먼트에서 네트워크 트래픽은 증가합니다. 허브별로 26대 이상의 서버를 사용하는 경우, 허브를 층으로 쌓습니다. 허브가 다운된 경우 허브를 수리하거나 교체하기 전까지 허브와 해당 스포크를 복제할 수 없습니다.
피어 투 피어 토폴로지를 사용하여 복제 관리
피어 투 피어 토폴로지에서는 모든 서버가 다른 모든 서버에 연결되는 허브 앤 스포크 설정보다 복제를 집중화하지 않습니다. 피어 투 피어 복제는 변경 내용을 모든 서버에 빨리 배포하므로, 소규모 조직이나 소수의 서버 간에 로컬로 데이터베이스를 공유할 때 가장 좋은 방법입니다. 그러나 데이터베이스가 위치한 서버 수가 많아지면 비효율적일 수 있습니다.
피어 투 피어 토폴로지를 사용하면 두 대의 서버에서만 복제가 이루어지므로 복제 시 발생될 문제도 줄어들고 허브 또는 중계 서버도 필요하지 않습니다. 그러나 피어 투 피어 복제는 많은 연결 문서가 필요하고, 복제 스케줄의 중복을 피하기 위한 관리 태스크를 증가시키며 ACL 요구사항을 표준화할 수 없습니다.
기타 토폴로지 방식
다른 복제 관리 방법은 클러스터 복제를 사용하는 것입니다. 한 서버의 데이터는 하나 이상의 해당 클러스터에 복제되므로 이 방법을 사용하면 데이터에 항상 액세스할 수 있습니다. 기본 서버가 사용 불가능할 경우, 데이터를 클러스터의 다른 서버에서 얻을 수 있습니다.
기타 복제 토폴로지는 다음과 같습니다.
- 엔드 투 엔드 - 체인 토폴로지라고 하며 두 개 이상의 서버를 체인으로 연결합니다. 정보는 서버 간의 한쪽 방향으로 이동하고 다른 방향으로 돌아오는 방식입니다. 이 복제는 링 복제보다 비효율적이지만 정보를 전송해야 할 경우에 유용합니다.
- 링 - 엔드 투 엔드 토폴로지와 비슷하지만 원으로 서버를 연결하기 때문에 복제가 닫힌 루프 안에서 발생합니다. 링 복제는 허브 서버 사이에서 정보를 복제하기 때문에 대규모 조직에서 유용합니다.
- 바이너리 트리 - 피라미드 형식으로 서버를 연결합니다. 맨 위의 서버가 아래의 두 서버에 연결하고 이 서버 각각이 다시 아래의 두 서버에 연결합니다. 정보는 하향 전달된 후 상향 전달됩니다.
복제에 기존의 메일 라우팅 연결 사용
복제를 계획할 때, Notes® 메일 라우팅에 대해 이미 설정했을 수 있는 연결을 다시 사용하십시오. 메일 라우팅에 대한 연결 문서를 이전에 작성한 경우 해당 문서에서 복제 태스크를 쉽게 사용할 수 있습니다.
한 방향으로 수행되고 양방향 라우팅을 사용 가능하게 하려면 한 쌍의 연결 문서가 필요한 메일 라우팅과 달리, 서버 간 복제는 양쪽 방향에서 수행되고 한 쌍의 서버마다 연결 문서를 하나만 요구합니다. 복제를 시작하는 서버가 복제 태스크 중 많은 부분을 맡고 있기 때문에, 두 개의 서버 간 메일 라우팅에 이미 사용된 연결 문서 중 하나에 복제를 추가하려는 경우, 둘 중 더 강력한 서버의 문서에 복제 태스크를 추가하십시오.