온라인 상태에서 사용자 메일함을 다른 Messaging Server로 마이그레이션하는 방법
시작하기 전에
이 마이그레이션 유형의 요구 사항은 다음과 같습니다.
-
stored가 소스(이전) 메시징 서버와 대상(신규) 메시징 서버 모두에서 실행되고 있어야 합니다.
-
소스 시스템과 대상 시스템이 공존할 경우 두 시스템이 메일을 서로 라우팅할 수 있어야 합니다. 예를 들어, 전달 상태 알림 메일이 대상 시스템에서 생성되어 소스 시스템으로 전달되도록 하려면 두 시스템이 메일을 서로 라우팅할 수 있어야 합니다.
주 –
일부 단계는 메시징 서버를 이전 버전에서 이후 버전으로 업그레이드한 경우에만 적용됩니다. 이 단계는 메일함을 한 메일 저장소에서 다른 메일 저장소로 마이그레이션하는 경우에는 적용되지 않을 수 있습니다. 전체 시스템을 마이그레이션하는 데 적용되는 단계가 명시됩니다.
단계
-
소스 시스템에서 backup-groups.conf 파일을 사용하여 이동할 사용자 항목을 동일한 백업 그룹 수로 분할합니다.
이 단계는 이 절차의 뒤에 나오는 메일함 마이그레이션 단계 8의 준비 과정입니다. 자세한 내용은 백업 그룹 만들기를 참조하십시오.
파일에 사용자 이름을 넣고 imsbackup 명령에 -u 옵션을 사용할 수도 있습니다.
-
이동할 사용자에게 이동 프로세스가 완료될 때까지 메일함에 액세스할 수 없다는 사실을 알립니다.
데이터 이동을 수행하기 전에 사용자들이 메일 시스템에서 로그아웃하도록 합니다. ( 사용자 액세스 모니터링 참조)
-
백엔드 메일 저장소 및 MMP 시스템에서 인증 캐시 시간 초과 값을 0으로 설정하고 MTA에서 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 0으로 설정합니다.
-
이동할 메일함이 포함된 백엔드 메일 저장소에서 인증 캐시 시간 초과 값을 0으로 설정합니다.
configutil -o service.authcachettl -v 0
이 단계와 단계 7(mailUserStatus를 hold로 변경)에서는 마이그레이션하는 동안 사용자가 메일함에 액세스하지 못하도록 즉시 조치합니다.
-
모든 MMP에서 인증 캐시 시간 초과 값을 0으로 설정합니다.
ImpProxyAService.cfg 및 PopProxyAService.cfg에서 LdapCacheTTL을 0으로 설정합니다.
-
마이그레이션할 메일함에 메일을 삽입하는 MTA를 호스트하는 모든 Messaging Server에서 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 0으로 설정합니다.
마이그레이션하는 메일함에 메일을 삽입하는 MTA를 호스트하는 Messaging Server가 일반적으로 백엔드 메일 저장소가 됩니다. 그러나, LMTP를 사용하는 시스템은 인바운드 MTA가 됩니다. 구성을 확인합니다.
/msg_svr_base/config/option.dat에서 ALIAS_ENTRY_CACHE_TIMEOUT을 재설정하면 MTA가 캐시를 건너뛰고 LDAP 항목을 직접 조회하여 중간 채널 대기열(예: conversion 또는 reprocess 채널)에 캐시된 이전 정보 대신 이동 중인 사용자의 새 mailUserStatus(hold)가 표시되도록 합니다. ALIAS_ENTRY_CACHE_TIMEOUT은 option.dat에 있습니다.
-
캐시를 재설정한 시스템을 다시 시작합니다.
변경 사항을 적용하려면 시스템을 다시 시작해야 합니다. 자세한 내용은 서비스 시작 및 중지를 참조하십시오.
-
-
소스 Messaging Server와 대상 Messaging Server가 모두 시작되고 실행 중인지 확인합니다.
소스 Messaging Server는 받는 메일을 새 대상 서버로 라우팅할 수 있어야 합니다.
-
메일함을 이동할 모든 사용자 항목의 LDAP 속성 mailUserStatus를 active에서 hold로 변경합니다.
속성을 변경하면 받는 메일이 hold 대기열에 보관되고 IMAP, POP 및 HTTP를 통한 메일함 액세스가 금지됩니다. 일반적으로 사용자는 사용자 그룹으로 이동됩니다. 단일 도메인의 모든 메일함을 이동할 경우 mailDomainStatus 속성을 사용할 수 있습니다.
mailUserStatus에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Schema Reference의 mailUserStatus를 참조하십시오.
-
이동 중인 메일함에 전달되는 메일이 ims-ms 또는 tcp_lmtp*(LMTP가 배포된 경우) 채널 대기열에 고착되지 않는지 확인합니다.
다음 명령을 사용하여 메일이 채널 대기열 디렉토리 트리에 있는지 및 마이그레이션할 사용자에게 전달되는 held 상태(.HELD 파일 표시)인지를 확인합니다.
imsimta qm directory -to=<user_address_to_be_migrated> -directory_tree imsimta qm directory -to=<user_address_to_be_migrated> -held -directory_tree
메일이 대기열에 있는 경우 나중에 이 명령을 다시 실행하여 MTA가 메일을 대기열에서 제거했는지 확인합니다. 대기열에서 제거되지 않는 메일이 있는 경우 마이그레이션하기 전에 이 문제를 해결해야 합니다. 이런 경우가 드물기는 하지만 가능한 원인으로는 수신자 메일함의 할당량이 초과된 경우, 사용자가 로그인한 상태에서 메일을 이동하여 메일함이 잠긴 경우, LMTP 백엔드 서버가 응답하지 않는 경우 및 네트워크 또는 이름 서버 문제 등이 있습니다.
-
이동할 사용자 항목과 모든 메일 그룹 항목에서 LDAP 속성 mailHost를 변경합니다*.
ldapmodify 명령을 사용하여 항목을 새 메일 서버로 변경합니다. Messaging Server 또는 Directory Server와 함께 제공된 ldapmodify를 사용합니다. Solaris OS ldapmodify 명령을 사용하지 마십시오.
* 이전 메일 호스트가 종료된 경우 메일 그룹 항목에서 mailHost 속성을 변경하기만 하면 됩니다. 이 속성을 새 메일 호스트 이름으로 변경하거나 속성을 함께 제거할 수 있습니다. 메일 그룹은 mailHost 속성을 선택적으로 가질 수 있습니다. mailHost가 있으면 해당 호스트만 그룹 확장을 수행할 수 있고, mailHost가 없으면(보다 일반적인 경우) 모든 MTA가 그룹 확장을 수행할 수 있습니다. 메일 그룹 항목에는 마이그레이션할 메일함이 없고 일반적으로 mailhost 속성이 없습니다.
mailhost에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Schema Reference의 mailHost를 참조하십시오.
-
메일함 데이터를 소스 Messaging Server 메일 저장소에서 대상 Messaging Server 메일 저장소로 이동하고 시작된 시간을 기록합니다.
imsbackup 유틸리티를 사용하여 메일함을 백업하고 imsrestore 유틸리티를 사용하여 새 Messaging Server에 복원합니다. 예를 들어, oldmail.siroe.com이라는 Messaging Server 5.2 시스템의 메일함을 newmail.siroe.com으로 마이그레이션하려면 oldmail.siroe.com에서 다음 명령을 실행합니다.
/server-root/bin/msg/store/bin/imsbackup -f- /instance/group \ | rsh newmail.siroe.com /opt/SUNWmsgsr/lib/msg/imsrestore.sh \ -f- -cy -v1
여러 백업 및 복원 세션(그룹마다 하나씩)을 동시에 실행하여 새 메일 저장소로의 전송 속도를 최대화할 수 있습니다. imsbackup 및 imsrestore 유틸리티에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 Command Descriptions와 메일 저장소 백업 및 복원를 참조하십시오.
주 –나중에 전달 확인을 위해 imsbackup이 실행된 시간의 타임스탬프를 기록합니다.
-
(시스템 업그레이드를 위한 조건부 단계) 메일함 마이그레이션이 이전 버전 Messaging Server를 현재 버전으로 업그레이드하는 과정에 포함되는 경우 이 현재 버전 Messaging Server를 시스템의 새 기본 Messaging Server로 설정합니다.
oldmail.siroe.com의 DNS A 레코드를 변경하여 newmail.siroe.com(이전에 oldmail.siroe.com에서 호스트되던 도메인을 담당하는 서버)을 가리키도록 합니다.
-
새 메일 저장소에 대한 사용자 액세스를 활성화합니다.
LDAP 속성 mailUserStatus 또는 mailDomainStatus(해당되는 경우)를 hold로 변경되기 이전의 값(예: active)으로 설정합니다.
-
모든 소스 Messaging Servers에서 held 상태인 메일을 해제합니다.
받는 메일을 보관 중인 모든 시스템에서 다음 명령을 실행하여 모든 사용자 메일을 해제해야 합니다.
imsimta qm release -channel=hold -scope
여기서 scope는 all(모든 메일 해제), user(사용자 아이디) 또는 domain(사용자가 위치한 도메인)입니다.
-
인증 캐시 시간 초과 및 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 기본값이나 원하는 값으로 재설정하고 시스템을 다시 시작합니다.
이제 마이그레이션해야 할 모든 사용자 메일을 마이그레이션했습니다. 계속하기 전에 이전 시스템에서 LDAP에 mailhost로 작성된 새 항목이 있는지 확인하고 있을 경우 해당 항목을 마이그레이션합니다. 또한, 준비 시스템을 수정하여 그런 항목이 만들어지지 않는지 확인합니다.
preferredmailhost 속성을 새 메일 호스트의 이름으로 변경할 수도 있습니다.
백엔드 메일 저장소의 경우 인증 캐시 시간 초과를 다음과 같이 설정합니다.
configutil -o service.authcachettl -v 900
MMP의 경우 ImpProxyAService.cfg 및 PopProxyAService.cfg에서 LdapCacheTTL 옵션을 0으로 설정합니다.
MTA의 경우 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 600으로 설정합니다. ALIAS_ENTRY_CACHE_TIMEOUT은 option.dat에 있습니다.
변경 사항을 적용하려면 시스템을 다시 시작해야 합니다. 자세한 내용은 서비스 시작 및 중지를 참조하십시오.
-
사용자 클라이언트가 새 메일 서버를 가리키는지 확인합니다.
업그레이드가 끝나면 사용자가 메일 클라이언트 프로그램을 통해 새 서버를 가리키도록 합니다. 이 예에서는 사용자가 oldmail.siroe.com에서 newmail.siroe.com을 가리킵니다.
그 대안은 사용자가 클라이언트에게 새 메일 서버를 직접 가리킬 필요가 없도록 Messaging Multiplexor(MMP)를 사용하는 것입니다. MMP는 LDAP 사용자 항목에 저장되는 mailHost 속성에서 해당 정보를 가져오고 클라이언트를 새 서버로 자동으로 리디렉션합니다.
-
모든 작업이 완료되면 마이그레이션 후에 이전 메일 저장소에 전달된 메일이 없는지 확인합니다.
이전 메일 저장소로 이동하여 mboxutil -l를 실행하여 메일함을 나열합니다. 마지막 메일 전달 타임스탬프를 확인합니다. 마이그레이션 타임스탬프(imsbackup 명령을 실행한 날짜) 이후에 전달된 메일이 있는 경우 backup 및 restore 명령을 사용하여 해당 메일을 마이그레이션합니다. 제공된 준비 단계로 인해 마이그레이션 후에 전달된 메일을 확인하는 것은 매우 드문 경우입니다.
이론적으로, 메일은 notices 채널 키워드에 지정된 날짜 또는 시간 동안 대기열에 고착될 수 있습니다( 알림 메일 전달 간격 설정 참조).
-
relinker 명령을 실행하여 새 메일 저장소에서 중복 메일을 제거합니다.
이 명령은 새 메일 저장소에서 디스크 공간을 비울 수 있습니다. 동일한 메일의 중복 저장에 따른 저장소 크기 줄이기를 참조하십시오.
-
마이그레이션한 소스 저장소에서 이전 메일을 제거하고 이전 저장소의 데이터베이스에서 사용자를 삭제합니다.
mboxutil -d 명령을 실행합니다. ( mboxutil 유틸리티 참조)
- © 2010, Oracle Corporation and/or its affiliates