|
| Sun ONE Directory Server 5.2 설치 및 조정 설명서 |
이 장에서는 Netscape Directory Server 4.x 및 iPlanet Directory Server 5.x를 Sun ONE Directory Server 5.2로 업그레이드하는 방법에 대해 설명합니다.
주 Innosoft Distributed Directory Server 4.5.1에서 업그레이드하는 방법은 포함되어 있지 않습니다.
이 장에서는 이전 서버의 디렉토리 데이터를 새 서버로 이전하는 방법을 중점적으로 설명합니다. 이전 서버에서 새 서버로 이전되는 구성 속성에 대한 자세한 내용은 Sun ONE Directory Server Reference Manual을 참조하십시오.
업그레이드 시 주의 사항
업그레이드하기 전에 먼저 "관련 자료"에 설명된 Sun ONE Directory Server 5.2의 새 기능을 살펴보십시오. 기존 디렉토리 서비스를 구현할 때 사용했던 설계 설정을 확인해 보는 것도 좋습니다.
단일 서버 인스턴스 업그레이드
서버 인스턴스를 업그레이드하려면 기존 서버를 그대로 두고 다른 serverID와 다른 관리 서버 및 Directory Server 포트 번호를 사용하여 다른 ServerRoot에 새 서버를 설치한 다음, 이전 서버를 중지하고 구성 및 디렉토리 데이터를 이전하여 클라이언트가 새 서버로 요청을 보내도록 설정해야 합니다.
Sun ONE Directory Server 5.2는 서버 인스턴스 데이터를 이전할 수 있도록 도와주는 스크립트를 제공합니다. 이전 스크립트는 다음 작업을 순서대로 수행합니다.
- 기존 서버를 중지하고 현재 구성을 백업합니다.
- 스키마 구성 파일을 확인하여 표준 스키마 구성 파일과 기존 서버에서 사용한 스키마 구성 파일 간의 차이점을 알려줍니다.
(4.x를 5.2로 업그레이드하는 경우에만 해당) 기존 4.x 서버가 ServerRoot/slapd-serverID/config의 기본 위치에 설치되지 않은 사용자 정의 스키마를 사용하는 경우 디렉토리 데이터를 이전하기 전에 수동으로 구성을 조정해야 합니다.
- 이전 서버에 저장된 각 접미사에 대한 데이터베이스를 작성합니다.
(4.x를 5.2로 업그레이드하는 경우에만 해당) 4.x 서버는 한 데이터베이스에서 여러 개의 접미사를 지원했습니다. 이전 스크립트는 각 접미사에 대한 데이터베이스를 새 서버에 작성합니다.
- 서버 및 데이터베이스 구성 매개 변수를 이전합니다.
4.x 서버는 slapd.conf에 이러한 매개 변수를 저장하고 5.x 서버는 dse.ldif에 저장합니다.
주 이 스크립트는 o=NetscapeRoot 데이터를 이전하지 않습니다.
Sun ONE Messaging Server와 같이 이 접미사의 데이터를 사용하는 서버를 배포하는 경우에는 해당 서버와 함께 제공된 도구를 이용하거나 수동으로 o=NetscapeRoot 데이터를 이전해야 합니다.
(4.x를 5.2로 업그레이드하는 경우에만 해당) 이전 스크립트는 4.x 서버 매개 변수 중 일부만 이전하므로 4.x 속성 값을 수동으로 이전해야 하는 경우도 있습니다. 자세한 내용은 Sun ONE Directory Server Reference Manual의 현재 버전을 참조하십시오.
사용자 정의된 스키마 개체를 이전합니다.
색인을 이전합니다.
표준 서버 플러그 인을 이전합니다.
사용자 정의 플러그 인은 수동으로 이전해야 하며, 최소한 모든 사용자 정의 플러그 인을 다시 컴파일해야 합니다. 플러그 인 API 변경 사항에 대한 자세한 목록은 Sun ONE Directory Server Plug-In API Programming Guide를 참조하십시오.
(5.x를 5.2로 업그레이드하는 경우에만 해당) 복제 계약을 이전합니다.
주 5.2 Directory Server에서 5.1 서버로 복제하기 전에 cn=config의 nsslapd-schema-repl-useronly를 on으로 설정하십시오. 그렇지 않으면 5.2 스키마가 5.1 서버로 푸시(push)되고 복제 개체로 인해 5.1 서버가 다시 시작되지 않습니다.
- 인증서 데이터베이스와 SSL 매개 변수를 이전합니다.
- (5.x를 5.2로 업그레이드하는 경우에만 해당) 데이터베이스 링크를 이전합니다.
- (5.x를 5.2로 업그레이드하는 경우에만 해당) 복제 항목을 이전합니다.
- SNMP 구성을 이전합니다.
이전 스크립트가 완료되면 클라이언트에서 새 서버로 요청을 보낼 수 있습니다.
여러 개의 복제된 서버 업그레이드
여러 개의 서버를 업그레이드하려면 각 서버를 개별적으로 업그레이드해야 합니다. 그러나 서버 업그레이드 순서는 기존 서버의 소프트웨어 버전과 복제 토폴로지에 따라 달라집니다.
5.x를 5.2로 업그레이드하는 경우 표준 프로세스는 상향식으로 진행됩니다. 먼저 고객을 이전한 다음 허브를 업그레이드하고 마지막으로 마스터를 업그레이드합니다. 특정 인스턴스에서 이러한 작업을 수행하는 방법은 "5.x 업그레이드 시나리오 예"를 참조하십시오.
4.x를 5.2로 업그레이드하는 경우 먼저 4.x 마스터를 업그레이드한 다음, 복제 측면에서 마스터와 가장 가까운 소비자부터 시작하여 마스터에서 복제되는 각 소비자 분기를 업그레이드합니다. 특정 인스턴스에서 이러한 작업을 수행하는 방법은 "4.x 업그레이드 시나리오 예"를 참조하십시오.
기존 환경에 여러 개의 복제된 서버가 포함되어 있으면 업그레이드를 시작하기 전에 이 장에 소개된 모든 관련 절을 주의깊게 읽어 보십시오. 불필요한 시스템 중단 시간을 줄이려면 완벽하게 업그레이드 계획을 세워야 합니다.
업그레이드 지원
중요한 디렉토리 서비스를 업그레이드하는 경우 Sun Professional Services의 도움을 받을 수 있습니다.
연락처 정보는 http://www.sun.com/service/sunps/sunone/을 참조하십시오.
단일 서버 업그레이드
이 절에서는 기존의 단일 서버를 단일 5.2 서버로 업그레이드하는 프로세스에 대해 설명합니다.
주 기존 4.x 서버가 사용자 정의 스키마를 사용하는 경우 데이터를 이전하기 전에 이전 스크립트가 사용자 정의 스키마를 찾을 수 있는지 확인합니다. 자세한 내용은 "(4.x를 5.2로 업그레이드하는 경우) 사용자 정의 스키마 처리"를 참조하십시오.
이전 스크립트가 사용자 정의 스키마를 인식하지 못하면 스키마가 이전되지 않으며, 새 서버로 데이터가 이전된 후 표준 스키마 파일이 적용됩니다. 사용자 정의 스키마를 따르는 항목에 표준 스키마를 적용하면 항목을 수정할 수 없게 되므로 업그레이드된 디렉토리가 읽기 전용으로 설정됩니다.
새 서버 설치
1장 "Sun ONE Directory Server 설치"에 설명된 지침에 따라 기존 서버와 같은 호스트에 새 서버를 설치합니다.
주 새 서버를 설치하기 전에 기존 서버가 백업되어 있는지 확인합니다.
새 서버가 설치되는 ServerRoot는 기존 서버의 위치와 달라야 합니다. 또한 새 서버는 다른 serverID로 식별되어야 합니다.
초기 설치에 제공했던 대부분의 구성 정보를 다시 사용하도록 선택할 수 있지만 기존 포트 번호는 다시 사용하지 마십시오. 기존 데이터를 이전한 후 새 서버의 포트 번호를 변경할 수 있습니다.
(4.x를 5.2로 업그레이드하는 경우) 사용자 정의 스키마 처리
데이터 이전 스크립트는 표준 slapd.user_oc.conf 및 slapd.user_at.conf 파일에 있는 사용자 정의 스키마와 다른 파일에 있지만 useroc 및 userat 지시문을 사용하여 slapd.conf 파일에 추가된 사용자 정의 스키마만 인식합니다. 예를 들어, slapd.at.conf 또는 slapd.oc.conf 파일에 직접 추가된 사용자 정의 스키마는 이전 스크립트에서 인식하지 못합니다.
업그레이드를 수행하기 전에 다음 단계를 완료합니다.
- slapd.at.conf 또는 slapd.oc.conf 파일과 새 서버의 ServerRoot/bin/slapd/install/version4/에 있는 표준 파일을 비교하여 사용자 정의 스키마 요소를 slapd.user_oc.conf 및 slapd.user_at.conf 파일에 추가합니다.
사용자 정의 개체 클래스 간에 상속 관계가 있으면 스키마 구성 파일에서 상위 개체 클래스가 하위 개체 클래스보다 앞에 오게 하십시오.
- slapd.oc.conf 파일의 표준 개체 클래스에 사용자 정의 속성을 추가한 경우 slapd.user_oc.conf 파일에 해당 속성을 포함하는 새 개체 클래스를 작성하고 기존 디렉토리에서 이 사용자 정의 속성을 사용하는 모든 항목에 새 개체 클래스를 추가합니다.
- 다른 파일에 대한 include 문 근처에서 useroc 및 userat 지시문을 사용하여 기존 서버의 slapd.conf 파일에 slapd.user_oc.conf 및 slapd.user_at.conf 파일을 추가합니다.
이제 기존 서버에서 사용한 모든 사용자 정의 스키마는 slapd.user_oc.conf 또는 slapd.user_at.conf 파일에 있어야 하고 slapd.conf 파일에는 useroc 및 userat 지시문을 사용하여 두 파일이 추가되어 있어야 합니다.
기존 데이터 이전
사용자 정의 스키마를 처리한 후 다음 단계를 수행하여 기존 데이터를 새 서버로 이전합니다.
- 오프라인 상태로 파일을 사용하여 새 Directory Server에서 복제를 초기화하려면 먼저 파일을 확보합니다.
Directory Server 데이터 내보내기에 대한 자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.
- 새 Directory Server를 실행 중인지 확인합니다.
- 이전 서버와 새 서버에서 데이터베이스 내보내기와 가져오기를 시작, 중지 및 실행할 수 있는 권한이 있는 사용자로 작업합니다.
예를 들어, 수퍼유저가 되거나 Administrator로 로그온합니다.
- 표 2-1에 표시된 것처럼 환경 변수를 설정합니다.
표 2-1 이전 환경 변수
변수
값
PATH
(UNIX) ServerRoot/bin/slapd/admin/bin:$PATH
(Windows) ServerRoot/bin/slapd/admin/bin;%PATH%
PERL5LIB
ServerRoot/bin/slapd/admin/bin
- 아래 명령을 실행하여 새 서버 인스턴스의 이전 스크립트를 실행합니다.
# cd ServerRoot/bin/slapd/admin/bin
# perl migrateInstance5 -p port52 -D "cn=directory manager" -w password -o oldServ -n newServ
여기서 oldServ는 /usr/iplanet/servers/slapd-ldap 또는 /usr/iplanet/ds5/slapd-ldap와 같이 이전 서버 인스턴스에 대한 전체 경로를 나타내고 newServ는 /var/ds/v5.2/slapd-dirserv와 같이 새 서버 인스턴스에 대한 전체 경로를 나타냅니다.
스크립트가 실행되면서 출력이 생성됩니다. 이전이 완료된 후에 확인할 수 있도록 이 출력을 파일로 리디렉션할 수 있습니다.
기존 데이터를 새 서버로 이전한 후에 이전 서버를 삭제하십시오.
(4.x를 5.2로 업그레이드하는 경우에만 해당) 복제 계약 작성
기존 4.x 서버가 복제에 관련되어 있는 경우 소프트웨어를 업그레이드하려면 데이터를 이전한 후 복제 계약을 다시 작성해야 합니다. 업그레이드 프로세스를 수행하기 전에 먼저 "(4.x를 5.2로 업그레이드하는 경우) 복제된 서버 업그레이드"를 읽어 보십시오.
5.2 서버 복제 구성에 대한 자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.
(선택 사항) 기존 포트 번호 다시 사용
이전 서버의 데이터를 새 서버로 이전한 후 이전 서버를 삭제하고 새 서버가 이전 서버와 같은 포트에서 수신하도록 선택할 수 있습니다. 같은 포트를 사용하면 구성을 변경하지 않아도 클라이언트 응용 프로그램이 계속 작동할 수 있습니다.
서버 포트 변경에 대한 자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오. 새 서버가 이전 포트에서 수신을 시작하기 전에 이전 서버를 중지해야 합니다.
(4.x를 5.2로 업그레이드하는 경우) 복제된 서버 업그레이드
복제된 4.x 서버를 업그레이드하는 경우 먼저 새 마스터에 복제한 다음, 복제 토폴로지를 통해 분기별로 업그레이드합니다. 이 방법을 사용하면 서버 동기화 트래픽 양이 제한됩니다.
주 복제 구성 및 초기화에 대한 자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.
새 마스터 준비
업그레이드 중에 5.2 서버는 마스터로 구성되지만 4.x 토폴로지에서 레거시 소비자로 작동합니다. 업그레이드가 끝나면 4.x 소비자 기능이 비활성화되고 새 서버는 5.2 토폴로지에서 마스터로 작동합니다.
이 과정에서 새 마스터 서버를 수동으로 구성해야 하므로 기존 마스터와 다른 호스트에 새 마스터를 설치할 수 있습니다.
- 1장 "Sun ONE Directory Server 설치"에 설명된 지침에 따라 새 서버를 설치합니다.
- 새 서버에 4.x 마스터 구성을 수동으로 복제합니다.
- 새 서버를 5.2 토폴로지의 마스터로 설정합니다.
자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.
- 새 서버를 4.x 토폴로지의 4.x 마스터 레거시 소비자로 설정합니다.
자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.
- 4.x 마스터로부터 새 서버로의 복제를 초기화합니다.
이 프로세스는 Netscape Directory Server Administration Guide의 Chapter 13, "Managing Replication"에 설명되어 있습니다. "Manual Consumer Initialization" 절을 참조하십시오.
이제 소비자를 업그레이드할 수 있습니다.
소비자 업그레이드
아래 절차에는 소비자 업그레이드 방법이 요약되어 있습니다. 자세한 내용은 이후 절차를 참조하십시오.
- 4.x 토폴로지의 모든 분기를 업그레이드합니다.
- 5.2 토폴로지에 필요한 서버를 추가합니다.
- 새 마스터에서 레거시 소비자 계약을 비활성화하여 새 토폴로지를 이전 토폴로지에서 분리합니다.
이 절차를 수행하면 업데이트 프로세스가 완료됩니다.
분기 업그레이드
기존 4.x 복제 토폴로지를 마스터가 루트 요소가 되는 하나의 트리로 가정해 보십시오. 여기서 분기는 복제 흐름이 루트 노드 공급자에서 시작되어 트리 중앙의 소비자를 통과하고 마지막으로 리프 노드 소비자 서버에 도착하는 트리에서 복제된 서버의 한 집합을 나타냅니다.
분기를 업그레이드하려면 하향식으로 분기의 이전 서버를 모두 새 서버로 교체합니다.
주 서버를 업그레이드하는 동안 분기의 모든 다운스트림 서버에 대한 복제 흐름은 중지됩니다. 업그레이드하는 동안에는 클라이언트 요청을 다른 분기로 리디렉션하십시오.
- "단일 서버 업그레이드"에 설명된 지침에 따라 분기의 최상위 서버를 업그레이드합니다.
이렇게 하면 분기에 대한 복제 흐름이 끊겨 분기의 다운스트림 서버에 대한 복제 업데이트가 일시적으로 중지됩니다.
- 5.2 분기의 새 서버에서 복제 계약을 구성하여 복제 토폴로지에서 새 마스터에 더 가까이 있는 5.2 서버의 업데이트를 받습니다.
예를 들어, 새 분기의 최상위 서버가 5.2 마스터의 업데이트를 받도록 구성합니다.
- 5.2 공급자로부터 5.2 서버로의 복제를 초기화합니다.
네트워크 성능 및 업데이트와 디렉토리 데이터 용량 간의 비율에 따라 오프라인 초기화가 온라인 초기화보다 빠를 수 있습니다.
- 모든 리프 소비자에 대해 단계를 완료할 때까지 분기를 따라 단계 1, 단계 2 및 단계 3을 반복적으로 수행합니다.
복제 계약 구성 및 복제 초기화에 대한 자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.
이제 분기에 대한 업데이트 프로세스가 완료되었습니다. 나머지 4.x 분기에 대해 이 절차를 반복하십시오.
서버 추가
4.x 토폴로지를 5.2 토폴로지로 업그레이드한 후 새 토폴로지에 필요한 마스터, 허브 및 소비자를 추가할 수 있습니다.
추가할 각 서버에 대해 다음 단계를 수행합니다.
- 1장 "Sun ONE Directory Server 설치"에 설명된 지침에 따라 새 서버를 설치합니다.
- 계획한 토폴로지에 맞게 새 서버의 복제 계약을 조정합니다.
자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.
- 새 서버에서 복제를 초기화합니다.
자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.
4.x 업그레이드 시나리오 예
소비자 한 개가 있는 분기와 허브에서 소비자 두 개를 공급하는 분기로 복제되는 4.x 마스터의 업그레이드를 가정해 보십시오. 이 절에서는 새로운 다중 마스터 토폴로지로 업그레이드할 때 수행되는 단계를 보여줍니다.
그림 2-1은 업그레이드 전의 4.x 토폴로지입니다.
그림 2-1 기존의 4.x 토폴로지 예
그림 2-2는 4.x 마스터의 레거시 소비자 기능을 하는 5.2 마스터가 추가된 상태를 보여줍니다.
그림 2-2 새 서버가 추가된 4.x 토폴로지 예
그림 2-3은 4.x 분기 교체의 첫 단계를 보여줍니다.
업그레이드하는 동안에는 전체 분기의 복제 업데이트 수신이 중지됩니다. 업데이트 수신은 업스트림 4.x 소비자가 업그레이드를 위해 중지된 때부터 4.x 소비자가 다시 시작될 때까지 중단됩니다.
지침에 설명된 것처럼 클라이언트에 최신 업데이트가 필요하면 클라이언트 요청을 다른 분기의 소비자로 보내도록 선택할 수 있습니다.
그림 2-3 업그레이드 중의 4.x 분기 예 - 1단계
그림 2-4는 4.x 분기 교체의 다음 단계를 보여줍니다.
그림 2-4 업그레이드 중의 4.x 분기 예 - 2단계
그림 2-5는 4.x 분기 교체의 다음 단계를 보여줍니다.
그림 2-5 업그레이드 중의 4.x 분기 예 - 3단계
그림 2-6은 다른 4.x 분기로 교체된 상태를 보여줍니다.
그림 2-6 업그레이드 중의 4.x 분기 예 - 다음 분기
그림 2-7은 두 토폴로지를 나란히 보여줍니다.
그림 2-7 업그레이드 중의 4.x 및 5.2 토폴로지 예
그림 2-8은 새 토폴로지에 마스터, 허브 및 새로운 복제 계약이 추가된 상태를 보여줍니다.
그림 2-8 5.2 토폴로지에 서버 추가
업그레이드 프로세스를 완료한 후 새 서버를 추가할 수도 있습니다.
그림 2-9는 이전 4.x 마스터로부터 새 5.2 마스터로의 복제 계약이 제거된 상태를 보여줍니다.
그림 2-9 복제 계약 제거
클라이언트 요청을 리디렉션하고 복제 계약을 제거한 후에는 4.x 서버를 비활성화할 수 있습니다.
그림 2-10은 완성된 5.2 토폴로지입니다.
그림 2-10 완성된 5.2 토폴로지
이제 클라이언트 요청이 5.2 토폴로지로 보내집니다.
(5.x를 5.2로 업그레이드하는 경우) 복제된 서버 업그레이드
복제된 5.x 서버를 업그레이드하는 경우 일반적으로 소비자, 허브, 마스터 순으로 업그레이드합니다. 이 상향식 방법에서는 복제 토폴로지의 전체 분기를 중단하지 않고 한 번에 한 개의 서버만 중단하므로 마스터와 소비자 간의 잠재적 사용자 정의 스키마 동기화 문제를 방지할 수 있습니다.
주 여기에 설명된 절차는 일반적인 5.x 토폴로지 업그레이드 방법을 사용합니다.
그러나 이 상향식 업그레이드 방법이 사용자의 특정 요구 사항에 적합하지 않으면 다른 방법을 계획하십시오.
5.x 서버 업그레이드
- "단일 서버 업그레이드"에 설명된 지침에 따라 기존 토폴로지의 각 소비자를 업그레이드합니다.
- 같은 지침에 따라 기존 토폴로지의 각 허브를 업그레이드합니다.
- 같은 지침에 따라 기존 토폴로지의 각 마스터를 업그레이드합니다.
서버 추가
5.x 토폴로지를 5.2 토폴로지로 업그레이드한 후 새 토폴로지에 필요한 마스터, 허브 및 소비자를 추가할 수 있습니다.
추가할 각 서버에 대해 다음 단계를 수행합니다.
- 1장 "Sun ONE Directory Server 설치"에 설명된 지침에 따라 새 서버를 설치합니다.
- 계획한 토폴로지에 맞게 새 서버의 복제 계약을 조정합니다.
- 새 서버에서 복제를 초기화합니다.
복제 계약 구성 및 복제 초기화에 대한 자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.
이 절차를 수행하면 업데이트 프로세스가 완료됩니다. 클라이언트가 업그레이드된 복제 토폴로지의 서버를 사용할 수 있습니다.
5.x 업그레이드 시나리오 예
두 소비자를 공급하는 두 개의 허브로 복제되는 5.x 이중 마스터의 업그레이드를 가정해 보십시오. 이 절에서는 5.2 서버를 사용하도록 토폴로지를 업그레이드할 때 수행되는 단계를 보여줍니다.
그림 2-11은 업그레이드 전의 5.x 토폴로지입니다.
그림 2-11 기존의 5.x 토폴로지 예
첫 단계에서는 소비자를 업그레이드합니다. 그림 2-12는 완성된 토폴로지입니다.
그림 2-12 5.x 소비자 업그레이드 단계 예
다음 단계에서는 허브를 업그레이드합니다. 그림 2-13은 완성된 토폴로지입니다.
그림 2-13 5.x 허브 업그레이드 단계 예
다음 단계에서는 마스터를 업그레이드합니다. 그림 2-14는 완성된 토폴로지입니다.
그림 2-14 5.x 마스터 업그레이드 예 - 3단계
그림 2-15는 업그레이드 후의 5.2 토폴로지입니다. 이제 이전 토폴로지의 서버를 삭제할 수 있으며 5.2 토폴로지에 새 서버가 추가되었습니다.
그림 2-15 업그레이드 후의 5.2 토폴로지 예
이제 클라이언트 요청이 5.2 토폴로지로 보내집니다.