Sun Java System Calendar Server 6.3 관리 설명서

5.1 Calendar Server 버전 6.3용 CLD 플러그 인 배경 정보

이 절에서는 CLD 플러그 인을 실제로 활성화하고 구성하기 전에 이해하면 도움이 되는 유용한 개요 및 배경 정보를 제공합니다.

이 절은 다음 내용으로 구성되어 있습니다.

5.1.1 Calendar Server 버전 6.3용 CLD 플러그 인 개요

달력 조회 데이터베이스(CLD) 플러그 인에서는 단일 달력 인스턴스에서 사용자 및 자원 달력을 여러 백엔드 서버에 분산할 수 있게 함으로써 달력 데이터베이스의 수평 확장성을 제공합니다. 달력 데이터베이스가 여러 백엔드 서버에 분산된 경우 Calendar Server는 CLD 플러그 인을 사용하여 달력이 실제로 저장된 서버를 확인합니다.

Calendar Server는 데이터 와이어 프로토콜(DWP)을 사용하여 백엔드 서버의 달력 데이터에 액세스합니다. DWP는 csdwpd 서비스로 실행되는 내부 프로토콜이며 달력 데이터베이스를 위한 네트워킹 기능을 제공합니다.

5.1.2 Calendar Server 버전 6.3용 CLD 플러그 인 작동 방법

Calendar Server는 다음과 같이 백엔드 서버의 달력 데이터에 액세스합니다.

  1. 최종 사용자가 Communications Express를 통해 달력에 액세스하면 CLD 플러그 인은 달력의 calid에서 userid를 추출한 후 LDAP 디렉토리 데이터베이스 또는 CLD 데이터 캐시(활성화된 경우)에서 달력 소유자를 조회합니다. 프런트엔드 시스템을 구성하는 방법에 대한 자세한 내용은 CLD를 위한 프런트엔드 서버 구성을 참조하십시오.

  2. 이 플러그 인은 달력 소유자를 찾은 후 소유자의 icsDWPHost LDAP 속성 값을 사용하여 달력이 있는 백엔드 서버의 호스트 이름을 확인합니다. 이 이름은 DNS(Domain Name Service)에서 유효한 IP 주소로 확인할 수 있어야 합니다.

  3. 이 호스트 이름을 사용하는 Calendar Server는 데이터베이스 와이어 프로토콜(DWP)을 사용하여 백엔드 서버의 달력 데이터에 액세스합니다.

  4. Calendar Server는 DWP를 사용하여 달력 데이터가 사용자 인터페이스 중 하나에서 렌더링될 수 있도록 사용자가 로그인한 서버로 해당 데이터를 보냅니다.


정보 –

사이트에서 CLD 플러그 인을 사용하는 경우에는 같은 사용자에 대해 만든 모든 달력이 LDAP 사용자 항목의 icsDWPHost LDAP 속성에 표시된 서버와 동일한 백엔드 서버에 있어야 합니다. 다른 백엔드 서버에서 달력을 만들려고 할 경우 Calendar Server는 오류를 반환합니다.


5.1.3 Calendar Server 버전 6.3용 CLD 플러그 인에서 지원되는 구성

이 절에서는 CLD 플러그 인에 대한 개요 정보를 제공합니다.

CLD 플러그 인은 다음 Calendar Server 구성을 지원합니다.


정보 –

이 모든 구성에서 각 프런트엔드 서버 및 백엔드 서버는 다음 조건을 만족해야 합니다.


5.1.3.1 Calendar Server 버전 6.3의 여러 프런트엔드 서버 및 백엔드 서버

그림 5–1에서는 단일 Calendar Server 인스턴스가 실행되는 두 대의 프런트엔드 서버와 두 대의 백엔드 서버를 보여 줍니다. 또한 필요에 따라 3대 이상의 프런트엔드 또는 백엔드 서버를 구성할 수 있습니다.

이 구성에서 서버는 LDAP 및 달력 데이터베이스에 대한 액세스를 제한하는 방화벽으로 보호할 수 있습니다. 달력 데이터베이스는 2대의 백엔드 서버에 분산됩니다.

프런트엔드 서버는 CPU를 많이 사용하며, 최종 사용자용 달력 데이터를 렌더링하는 데 대부분의 CPU 시간이 소요됩니다. 백엔드 서버는 디스크를 많이 사용하며, 달력 데이터베이스에 액세스하는 데 대부분의 CPU 시간이 소요됩니다.

구성 지침에 대해서는 5.2 CLD 및 DWP를 위한 Calendar Server 구성을 참조하십시오.

그림 5–1 다중 프런트엔드 서버와 다중 백엔드 서버

이 예에서는 다중 백엔드 및 프런트엔드 서버를 모두 포함하는 시스템을 보여 줍니다.

5.1.3.2 Calendar Server 버전 6.3의 여러 시스템이 프런트엔드 및 백엔드 서버로 작동

그림 5–2에서는 프런트엔드 및 백엔드 서버 둘 다로 작동하는 세 대의 시스템을 보여 줍니다. 각 시스템은 달력 데이터베이스에 연결됩니다. 이 구성에서는 달력의 지역적인 분산이 가능합니다. 달력 소유자(최종 사용자)는 달력이 위치한 시스템에 로그인합니다. 구성 지침에 대해서는 서버를 프런트엔드 및 백엔드 둘 다로 구성하려면을 참조하십시오.

그림 5–2 프런트엔드/백엔드 둘 다로 작동하는 여러 서버

이 그림은 프런트엔드 및 백엔드 시스템 둘 다로 작동하는 시스템의 예를 보여 줍니다.

5.1.4 Calendar Server 6.3 저장소 요구 사항에 대한 간단한 크기 지정 방법

이 절에서는 보통 사용 프로필을 바탕으로 몇 가지 간단한 수식을 사용하여 크기를 지정하는 방법에 대해 설명합니다. 이를 통해 필요한 프런트엔드 및 백엔드 서버 수와 저장소 용량을 알 수 있습니다.

이 절은 다음 내용으로 구성되어 있습니다.

5.1.4.1 Calendar Server 6.3 배포를 위한 보통 사용 프로필의 정의

추정값을 계산하기 위해 다음과 같이 가정합니다.

5.1.4.2 프런트엔드 CPU의 수

수식은 다음과 같습니다.

CPU의 수 = 동시 사용자 수를 4800으로 나눈 값

5.1.4.3 백엔드 CPU의 수

수식은 다음과 같습니다.

CPU의 수 = 500,000명의 구성된 사용자당 CPU 4개

5.1.4.4 필요한 저장소 크기

수식은 다음과 같습니다.

사용자당 저장소 양 = 주당 100개의 전자 메일 * 연간 52주 * 전자 메일당 5K * 데이터를 온라인으로 유지해야 하는 년 수 * 온라인으로 유지해야 하는 복사본 수(5개의 백업 + 1개의 작업 복사본) = 100*52*5K*2*(5+1) = 사용자당 65MB의 저장소

즉, 연간 사용자당 온라인으로 유지해야 하는 복사본마다 2.6MB가 필요합니다.


주 –

최종 크기는 온라인으로 유지하는 핫 백업 또는 아카이브 백업의 수에 따라 달라집니다. 이 예에서는 백업 복사본이 5개 사용되었습니다.