온라인 상태로 사용자 메일함을 다른 Messaging Server로 마이그레이션하는 방법 (Sun Java System Messaging Server 6.3 관리 설명서)

Sun Java System Messaging Server 6.3 관리 설명서

온라인 상태로 사용자 메일함을 다른 Messaging Server로 마이그레이션하는 방법

시작하기 전에

이 마이그레이션 유형에 대한 요구 사항은 다음과 같습니다.

원본(이전) Messaging Server와 대상(새) Messaging Server 모두에서 stored를 실행해야 합니다.
원본 시스템과 대상 시스템이 공존할 경우 두 시스템 간에 메시지를 라우팅할 수 있어야 합니다. 이렇게 해야 전달 상태 알림 메시지를 대상 시스템에서 생성하여 원본 시스템으로 전달하는 등의 작업을 수행할 수 있습니다.

주 –

일부 단계는 Messaging Server를 최신 버전으로 업그레이드하는 경우에만 적용됩니다. 이 단계는 다른 메시지 저장소로 메일함 마이그레이션만 수행하는 경우에는 적용되지 않을 수도 있습니다. 전체 시스템 마이그레이션에 적용되는 단계는 별도의 설명이 있습니다.

원본 시스템에서 backup-groups.conf 파일을 사용하여 이동할 사용자 항목을 동일한 백업 그룹 수로 분할합니다.

이 단계는 해당 절차의 뒤에 나오는 메일함 마이그레이션 단계 8에 대한 준비 과정입니다. 자세한 내용은 20.12.2 백업 그룹 만들기을 참조하십시오.

파일에 사용자 아이디를 넣고 imsbackup 명령에 -u 옵션을 사용할 수도 있습니다.

이동 대상인 사용자에게 이동이 완료될 때까지 메일함에 액세스할 수 없음을 알립니다.

데이터를 이동하기 전에 이동할 사용자가 메일 시스템에서 로그아웃했는지 확인합니다. ( 20.13 사용자 액세스 모니터링 참조)

백엔드 메시지 저장소와 MMP 시스템에서 인증 캐시 시간 초과를 0으로 설정하고 MTA에서 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 0으로 설정합니다.
1. 이동할 메일함이 있는 백엔드 메시지 저장소에서 인증 캐시 시간 초과를 0으로 설정합니다.
  configutil -o service.authcachettl -v 0
  이 단계와 단계 7(mailUserStatus를 hold로 변경)에서는 마이그레이션 중에 사용자의 메일함 액세스를 즉시 차단합니다.
2. 모든 MMP에서 LDAP 및 인증 캐시 시간 초과를 0으로 설정합니다.
  
  ImapProxyAService.cfg 및 PopProxyAService.cfg는 LdapCacheTTL과 AuthCacheTTL을 모두 0으로 설정합니다.
3. 마이그레이션할 메일함에 메시지를 삽입하는 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에 있습니다.
4. 캐시가 재설정된 시스템을 다시 시작합니다.
  
  변경 사항을 적용하려면 시스템을 다시 시작해야 합니다. 자세한 내용은 4.4 서비스 시작 및 중지를 참조하십시오.

원본 Messaging Server와 대상 Messaging Server가 모두 실행 중인지 확인합니다.

원본 Messaging Server는 받는 메시지를 새 대상 서버에 라우팅할 수 있어야 합니다.

메일함을 이동할 모든 사용자 항목에서 LDAP 속성 mailUserStatus를 active에서 hold로 변경합니다.

속성을 변경하면 받는 메시지가 hold 대기열에 보관되고 IMAP, POP 및 HTTP를 통한 액세스가 금지됩니다. 일반적으로 사용자는 사용자 그룹으로 이동됩니다. 단일 도메인의 모든 메일함을 이동할 경우 mailDomainStatus 속성을 사용할 수 있습니다.

mailUserStatus에 대한 자세한 내용은 Sun Java Communications Suite 5 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 Communications Suite 5 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- -c y -v 1
여러 백업 및 복원 세션(그룹마다 하나씩)을 동시에 실행하여 새 메시지 저장소로의 전송 속도를 최대화할 수 있습니다. imsbackup 및 imsrestore 유틸리티에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration Reference의 Command Descriptions과 20.12 메시지 저장소 백업 및 복원을 참조하십시오.

주 –
나중의 전달 확인을 위해 imsbackup이 실행된 시간의 타임스탬프를 기록합니다.

(시스템 업그레이드를 위한 조건부 단계) 메일함 마이그레이션을 이전 버전 Messaging Server에서 현재 버전으로 업그레이드하는 과정의 일부로 수행하는 경우 현재 버전 Messaging Server를 시스템에 대한 새 기본 Messaging Server로 설정합니다.

oldmail.siroe.com의 DNS A 레코드를 변경하여 newmail.siroe.com(이전에 oldmail.siroe.com에서 호스트되던 도메인을 담당하는 서버)을 가리키도록 합니다.

새 메시지 저장소에 대한 사용자 액세스를 활성화합니다.

LDAP 속성 mailUserStatus 또는 mailDomainStatus(해당하는 경우)를 hold 상태로 변경되기 이전의 값(예: active)으로 설정합니다.

모든 원본 Messaging Server에서 메시지를 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의 경우 ImapProxyAService.cfg와 PopProxyAService.cfg에서 LdapCacheTTL과 AuthCacheTTL 옵션을 900으로 설정합니다.

MTA의 경우 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 600으로 설정합니다. ALIAS_ENTRY_CACHE_TIMEOUT은 option.dat에 있습니다.

변경 사항을 적용하려면 시스템을 다시 시작해야 합니다. 자세한 내용은 4.4 서비스 시작 및 중지를 참조하십시오.

사용자 클라이언트가 새 메일 서버를 가리키는지 확인합니다.

업그레이드가 끝나면 사용자가 메일 클라이언트 프로그램을 통해 새 서버를 가리키도록 합니다. 이 예에서는 oldmail.siroe.com에서 newmail.siroe.com을 가리킵니다.

대안은 MMP(Messaging Multiplexor)를 사용하는 것입니다. 그러면 사용자가 새 메일 서버를 클라이언트로 직접 가리킬 필요가 없습니다. MMP는 LDAP 사용자 항목에 저장된 mailHost 속성으로부터 정보를 가져와서 클라이언트를 새 서버로 자동으로 리디렉션합니다.

모든 작업이 완료되면 마이그레이션 이후에 이전 메시지 저장소로 전달된 메시지가 없는지 확인합니다.

이전 메시지 저장소로 이동한 후 mboxutil -l을 실행하여 메일함을 나열합니다. 마지막 메시지 전달 타임스탬프를 확인합니다. 마이그레이션 타임스탬프(imsbackup 명령을 실행한 날짜 스탬프) 이후에 전달된 메시지가 있는 경우 백업 및 복원 명령을 사용하여 해당 메시지를 마이그레이션합니다. 준비 단계를 수행했기 때문에 마이그레이션 이후에 전달된 메시지가 표시되는 경우는 극히 드뭅니다.

이론적으로는 메시지가 notices 채널 키워드에 지정된 날짜 또는 시간 동안 대기열에 고착될 수 있습니다( 10.10.4.3 알림 메일 전달 간격 설정 참조).

새 메시지 저장소에서 중복 메시지를 제거하고 relinker 명령을 실행합니다.

이 명령은 새 메시지 저장소에서 디스크 공간을 비울 수 있습니다. 20.11.7 동일한 메시지의 중복 저장에 따른 저장소 크기 줄이기를 참조하십시오.

마이그레이션한 원본 저장소에서 이전 메시지를 제거하고 이전 저장소의 데이터베이스에서 사용자를 삭제합니다.

mboxutil -d 명령을 실행합니다. ( 20.11.2.1 mboxutil 유틸리티 참조)