메일 저장소 유지 관리 절차 수행

이 절에서는 메일 저장소의 유지 관리 및 복구 작업을 수행하는 데 사용되는 유틸리티에 대해 설명합니다. 관리자는 항상 포스트마스터 메일을 읽어 서버가 보낼 수 있는 주의와 경고를 확인해야 합니다. 또한 로그 파일에서 서버의 작동 상태에 대한 정보를 모니터해야 합니다. 로그 파일에 대한 자세한 내용은 21 장, 로깅 관리을 참조하십시오.

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

• 메일함 관리

• 할당량 제한 모니터

• 디스크 공간 모니터

• stored 유틸리티 사용

• 동일한 메일의 중복 저장에 따른 저장소 크기 줄이기

메일 저장소에 물리적 디스크 추가

Messaging Server 메일 저장소는 특정 Messaging Server 인스턴스에 대한 사용자 메일함을 포함합니다. 메일함, 폴더 및 로그 파일 수가 늘어나면 메일 저장소의 크기가 늘어납니다.

시스템에 다른 사용자를 추가하면 디스크 저장소 요구 사항이 증가합니다. 서버가 지원하는 사용자 수에 따라 메일 저장소는 하나 또는 여러 개의 물리적 디스크가 필요할 수 있습니다. Messaging Server를 사용하면 필요에 따라 저장소를 추가할 수 있습니다. 저장소를 추가하는 한 가지 방법은 저장 장치를 사용하는 것입니다. Messaging Server를 사용하여 Network Appliance 저장 장치를 구성하는 방법은 을 참조하십시오.

메일함 관리

이 절에서는 mboxutil, hashdir, readership과 같은 메일함 관리 및 모니터링 유틸리티에 대해 설명합니다.

mboxutil 유틸리티

mboxutil 명령을 사용하여 메일함에 대한 일반적인 유지 관리 작업을 수행하십시오. mboxutil 작업은 다음을 포함됩니다.

• 메일함 나열

• 고아 및 비활성 메일함 나열 및 제거

• 메일함 작성

• 메일함 이름 바꾸기

• 한 분할 영역에서 다른 분할 영역으로 메일함 이동

• 연결되지 않은 또는 비활성 메일함 삭제

• 또한 mboxutil 명령을 사용하여 할당량에 대한 정보를 볼 수 있습니다. 자세한 내용은 할당량 제한 모니터를 참조하십시오.

mboxutil 프로세스를 실행 도중에 종료해서는 안 된다는 것을 유의하십시오. SIGKILL(kill -9)을 사용하여 중지할 경우 모든 서버를 다시 시작하고 복구를 수행해야 할 수 있습니다.

표 18–11에서는 mboxutil 명령을 나열합니다. 자세한 구문 및 사용 요구 사항에 대해서는 Sun Java System Messaging Server 6 2005Q4 Administration Reference를 참조하십시오.

POSIX 정규식을 mboxutil 명령에서 사용할 수 있습니다.

메일함 이름 지정 규칙

메일함 이름은 user/userid/mailbox 형식으로 지정해야 합니다. 여기서 userid는 메일함을 소유한 사용자이고 mailbox는 메일함 이름입니다. 호스트된 도메인의 경우 userid는 uid@domain입니다.

예를 들어, 다음 명령은 사용자 아이디가 crowe인 사용자에 대해 INBOX라는 메일함을 만듭니다. INBOX는 사용자 crowe에게 전달되는 메일의 기본 메일함입니다.

mboxutil -c user/crowe/INBOX

중요: INBOX라는 이름은 각 사용자의 기본 메일함으로 준비되어 있습니다. INBOX는 대소문자를 구분하지 않는 유일한 폴더 이름입니다. 다른 모든 폴더 이름은 대소문자를 구분합니다.

예

모든 사용자의 모든 메일함을 나열하려면 다음을 수행합니다.

mboxutil -l

모든 메일함을 나열하고 또한 경로와 ACL 정보를 포함하려면 다음을 수행합니다.

mboxutil -l -x

사용자 daphne에 대해 INBOX라는 기본 메일함을 만들려면 다음을 수행합니다.

mboxutil -c user/daphne/INBOX

사용자 delilah에 대해 projx라는 메일 폴더를 삭제하려면 다음을 수행합니다.

mboxutil -d user/delilah/projx

사용자 druscilla에 대해 INBOX라는 기본 메일함과 모든 메일 폴더를 삭제하려면 다음을 수행합니다.

mboxutil -d user/druscilla/INBOX

사용자 desdemona에 대해 메일 폴더 memos의 이름을 memos-april로 바꾸려면 다음을 수행합니다.

mboxutil -r user/desdemona/memos user/desdemona/memos-april

사용자 dimitria에 대한 메일 계정을 새 분할 영역으로 이동하려면 다음을 수행합니다.

mboxutil -r user/dimitria/INBOX user/dimitria/INBOX partition

여기서 partition은 새 분할 영역의 이름을 지정합니다.

사용자 dimitria에 대해 personal이라는 메일 폴더를 새 분할 영역으로 이동하려면 다음을 수행합니다.

mboxutil -r user/dimitria/personal user/dimitria/personal partition

고아 계정 제거

고아 계정(LDAP에 해당 항목이 없는 메일함)을 검색하려면 다음 명령을 사용합니다.

mboxutil -o

명령 출력은 다음과 같습니다.

  mboxutil: Start checking for orphaned mailboxes
  user/annie/INBOX
  user/oliver/INBOX
  mboxutil: Found 2 orphaned mailbox(es)
  mboxutil: Done checking for orphaned mailboxes

고아 메일함을 삭제하여 스크립트 파일로 변환될 수 있는 고아 메일함을 나열하는 orphans.cmd라는 이름의 파일을 만들려면 다음 명령을 사용합니다.

mboxutil -o -w orphans.cmd

명령 출력은 다음과 같습니다.

  mboxutil: Start checking for orphaned mailboxes
  mboxutil: Found 2 orphaned mailbox(es)
  mboxutil: Done checking for orphaned mailboxes

다음 명령을 사용하여 고아 파일을 삭제합니다.

mboxutil -d -f orphans.cmd

hashdir 유틸리티

메일 저장소의 메일함은 빠른 검색을 위해 해시 구조에 저장됩니다. 결과적으로 특정 사용자의 메일함을 포함하는 디렉토리를 찾으려면 hashdir 유틸리티를 사용합니다.

이 유틸리티는 특정 계정의 메일 저장소를 포함하는 디렉토리를 식별합니다. 이 유틸리티는 메일 저장소에 상대적인 경로(예: d1/a7/)를 보고합니다. 이 경로는 사용자 아이디 기반 디렉토리의 바로 앞에 있는 디렉토리 수준에 상대적입니다. 이 유틸리티는 경로 정보를 표준 출력으로 보냅니다.

예를 들어, 사용자 crowe에 대한 메일함의 상대 경로를 찾으려면 다음을 수행합니다.

hashdir crowe

readership 유틸리티

readership 유틸리티는 공유 IMAP 폴더의 메일을 읽은 메일함 소유자 이외의 사용자 수를 보고합니다.

IMAP 폴더 소유자는 폴더의 메일을 읽는 권한을 다른 사용자에게 부여할 수 있습니다. 다른 사용자가 액세스하도록 허가된 폴더를 공유 폴더라고 합니다. 관리자는 readership 유틸리티를 사용하여 공유 폴더를 액세스하는 소유자 이외의 사용자 수를 확인할 수 있습니다.

이 유틸리티는 모든 메일함을 스캔한 후 공유 폴더별로 한 행씩의 출력을 생성하여 읽은 사람 수(뒤에 공백과 메일함 이름이 옴)를 보고합니다.

각 읽은 사람은 이전의 지정된 일 수 동안 공유 폴더를 선택했던 고유한 인증 아이디입니다. 자신의 고유한 메일함을 읽을 때는 사용자가 계산되지 않습니다. 폴더 소유자 외에 최소 한 명 이상의 읽은 사람이 존재하지 않을 경우 개인 메일함은 보고되지 않습니다.

예를 들어, 다음 명령은 마지막 15일 동안에 공유 IMAP 폴더를 선택한 모든 아이디를 읽은 사람으로 계산합니다.

readership -d 15

할당량 제한 모니터

imqutoacheck를 사용하여 할당량 사용 및 제한을 모니터링한 다음 정의된 할당량과 제한을 나열하는 보고서를 생성하고 할당량 사용과 관련한 정보를 제공합니다. 할당량과 사용량 수치는 KB로 보고됩니다. 이 유틸리티는 메일함 크기를 사용자의 할당량과 비교할 수도 있습니다. 옵션으로 지정된 할당량 비율을 초과한 사용자에게 전자 메일 알림을 보낼 수 있습니다.

imquotacheck에서 일부 기능이 변경되었습니다. Messaging Server 6.x에서 imquotacheck 유틸리티가 quotacheck 유틸리티를 대체했습니다. Messaging Server 5.x에서는 quotacheck 유틸리티를 사용하여 사용자 목록을 검색할 때 quotacheck는 로컬 mboxlist 데이터베이스를 검색했습니다. 이 기능은 mboxutil 유틸리티의 검색 기능과 중복되었습니다.

Messaging Server 6.x에서는 이 중복된 기능이 imquotacheck 유틸리티에서 제거되었습니다. imquotacheck를 사용하여 사용자 검색을 수행할 경우 로컬 mboxlist 데이터베이스가 아닌 LDAP 디렉토리에 대해 검색이 수행됩니다. 로컬 mboxlist 데이터베이스에서 사용자 목록을 검색하려면 mboxutil 유틸리티를 사용합니다.

할당량이 규칙 파일의 최소 임계값을 초과하는 모든 사용자에 대한 사용량을 나열하려면 다음을 수행합니다.

imquotacheck

도메인 siroe.com에 대한 할당량 정보를 나열합니다.

imquotacheck -d siroe.com

기본 규칙 파일에 따라 모든 사용자에게 알림을 보내려면 다음을 수행합니다.

imquotacheck -n

지정된 rulefile, myrulefile 및 지정된 메일 템플리트 파일 mytemplate.file에 따라 모든 사용자에게 알림을 보내려면 다음을 수행합니다(자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 imquotacheck 참조).

imquotacheck -n -r myrulefile -t mytemplate.file

모든 사용자에 대한 사용량을 나열하고 규칙 파일을 무시하려면 다음을 수행합니다.

imquotacheck -i

사용자 user1에 대한 폴더별 사용량을 나열하려면 다음을 수행합니다(규칙 파일 무시).

imquotacheck -u user1 -e

디스크 공간 모니터

시스템이 디스크 공간과 분할 영역 사용을 모니터해야 하는 빈도와 경고를 보내야 하는 상황을 지정할 수 있습니다. 자세한 내용은 디스크 공간 모니터링을 참조하십시오.

stored 유틸리티 사용

stored 유틸리티는 서버에 대한 다음 모니터링 및 유지 관리 작업을 수행합니다.

• 백그라운드 및 일상적인 메시징 작업

• 교착 상태 감지 및 교착 상태에 빠진 데이터베이스 트랜잭션의 롤백

• 시작 시 임시 파일 정리

• 에이징 정책 구현

• 서버 상태, 디스크 공간, 서비스 응답 시간 등의 정기적인 모니터링( stored 참조)

• 필요한 경우 경보 발생

• 필요에 따른 데이터베이스 복구( 메일 저장소 시작 및 복구 참조)

stored 유틸리티는 매일 오후 11시에 정리 및 만료 작업을 자동으로 수행합니다. 추가 정리 및 만료 작업을 실행하도록 선택할 수 있습니다.

표 18–12에는 일부 stored 옵션이 나열되어 있습니다. 다음 표에는 몇 가지 일반적인 사용 예가 나와 있습니다. 자세한 구문 및 사용 요구 사항에 대해서는 Sun Java System Messaging Server 6 2005Q4 Administration Reference를 참조하십시오.

상태를 출력하려면 다음을 입력합니다.

stored -t -v

자동 정리 및 만료 작업 시간을 변경하려면 다음과 같이 configutil 유틸리티를 사용합니다.

configutil -o store.expirestart -v 21

경우에 따라 stored 유틸리티를 다시 시작해야 할 수 있습니다(예: 메일함 목록 데이터베이스가 손상된 경우). UNIX에서 stored를 다시 시작하려면 명령줄에서 다음 명령을 사용합니다.

msg_svr_base/sbin/stop-msg store
msg_svr_base/sbin/start-msg store

임의의 서버 데몬이 충돌된 경우 stored를 비롯한 모든 데몬을 중지했다가 다시 시작해야 합니다.

동일한 메일의 중복 저장에 따른 저장소 크기 줄이기

하나의 메일이 여러 수신자에 전송될 때 해당 메일은 각 수신자의 메일함마다 놓이게 됩니다. 일부 메시징 시스템에서는 각 수신자의 메일함에 같은 메일의 사본을 별도로 저장합니다. 그러나 이와 반대로, Sun Java System Messaging Server에서는 해당 메일이 있는 메일함의 수에 관계 없이 메일 사본을 하나만 유지합니다. 이는 해당 메일을 포함하는 메일함에 메일에 대한 하드 링크를 작성하는 방법으로 이루어집니다.

다른 메시징 시스템을 Sun Java Messaging Server로 마이그레이션할 때는 마이그레이션 과정을 통해 이러한 여러 메일 사본이 복사될 수 있습니다. 이는 규모가 큰 메일 저장소의 경우 불필요하게 많은 메일이 중복되는 것을 의미합니다. 또한 일반적인 서버 작업(예: IMAP append 작업이나 기타 소스의 작업)에 같은 메일 사본이 여러 개 누적될 수 있습니다.

Messaging Server는 relinker라는 이름의 새 명령을 제공하는데, 이 명령은 과도한 메일 사본을 제거하고 하나의 사본에 대한 하드 링크로 대체합니다.

relinker작동 원리

재연결 기능은 이 명령이나 실시간 모드에서 실행할 수 있습니다. relinker 명령을 실행할 때는 이 명령이 메일 저장소 분할 영역 전체를 스캔하고 MD5 메일 다이제스트 저장소(하드 링크에 해당)를 작성 또는 업데이트하며 필요한 하드 링크를 만듭니다.

다이제스트 저장소는 메일 저장소의 메일에 대한 하드 링크로 이루어져 있습니다. 이는 디렉토리 계층 partition_path/=md5에 저장됩니다. 이 디렉토리는 사용자 메일함 계층 partition_path /=user(그림 18–1 참조)와 병행합니다. 다이제스트 저장소의 메일은 MD5 다이제스트에서 고유하게 식별합니다. 예를 들어, fredb/00/1.msg의 다이제스트가 4F92E5673E091B43415FFFA05D2E47인 경우 partition/=user/hashdir/hashdir /=fredb/00/1.msg는 partition/=md5/hashdir/hashdir/4F92E5673E091B43415FFFA05D2E47EA.msg에 링크됩니다. 다른 메일함에 이와 같은 메일이 있을 때(예: partition_path/=user/hashdir/hashdir/gregk/00/17.msg) 해당 메일은 partition_path/=md5/4F/92/4F92E5673E091B43415FFFA05D2E47EA.msg에 대해 하드 링크로 연결됩니다. 이 프로세스는 그림 18–5에 표시되어 있습니다.

그림 18–5 메일 저장소 다이제스트 저장소

이 메일의 경우 링크 수는 3이 됩니다. 두 메일 모두 fredb 및 gregk의 메일함에서 삭제되면 링크 수는 하나가 되고 해당 메일을 삭제할 수 있습니다.

relinker 프로세스는 같은 기능에 대해 실시간으로 실행될 수 있습니다. 자세한 내용은 실시간 모드에서 relinker 사용을 참조하십시오.

명령줄 모드에서 relinker 사용

relinker는 메일 저장소 분할 영역 전체를 스캔하고 MD5 메일 저장소(하드 링크에 해당)를 작성 또는 업데이트하며 과도한 메일 파일을 삭제합니다. relinker가 저장소 분할 영역을 스캔한 후에는 재연결 이전과 이후 해당 분할 영역의 크기와 고유한 메일의 수에 대한 통계를 산출합니다. 이미 해시된 저장소에 대한 실행 속도를 높이기 위해 relinker는 아직 =md5에 없는 메일의 다이제스트만 계산합니다. 또한 전체 다이제스트 저장소(사용자 메일함에 영향을 주지 않는 범위에서)를 지우는 옵션도 있습니다.

이 명령의 구문은 다음과 같습니다.

relinker [-p partitionname] [-d]

여기서 partitionname은 처리될 분할 영역(기본값: 모든 분할 영역)을 지정하고 -d는 다이제스트 저장소가 삭제됨을 지정합니다. 출력 예는 다음과 같습니다.

# relinker

Processing partition: primary
Scanning digest repository...
Processing user directories..............................
---------------------------------------------------------
Partition statistics           Before            After 
---------------------------------------------------------
Total messages                 4531898         4531898
Unique messages                4327531         3847029
Message digests in repository        0         3847029
Space used                       99210Mb         90481Mb
Space savings from single-copy    3911Mb         12640Mb
---------------------------------------------------------


# relinker -d 
Processing partition: primary
Purging digest repository...
---------------------------------------------------------
Partition statistics                 Before         After
---------------------------------------------------------
Message digests in repository       3847029             0
---------------------------------------------------------

특히 저장소에 메일이 하나도 없는 처음에는 relinker 실행에 시간이 많이 걸릴 수 있습니다. 이는 모든 메일마다 다이제스트를 계산(relinker 기준이 모든 메일을 포함하도록 구성된 경우)해야 하기 때문입니다. relinker 기준 구성에 대한 자세한 내용은 relinker 구성을 참조하십시오.예를 들어, 100GB의 메일 저장소를 처리하는 데는 6시간 정도가 걸립니다. 그러나 런타임 재연결을 활성화한 경우( 실시간 모드에서 relinker 사용 참조)에는 relinker 명령을 실행할 필요가 없습니다.

relinker 명령줄 모드가 예외적으로 사용되고 런타임 옵션이 아닌 경우에는 다이제스트 저장소( =md5)를 삭제할 필요가 있습니다. 그 외의 경우에는 저장소에서 삭제된 메일(=user)에 해당 다이제스트 저장소의 연결이 그대로 있으므로(고아 메일이 됨) 사용 가능한 디스크 공간이 되지 않습니다. relinker를 한 번만 실행할 수 있는 저장소의 일회 최적화를 수행하는 경우(예: 마이그레이션 후)에는 relinker -d를 사용하여 전체 저장소를 삭제하십시오. 반복된 삭제의 경우(마이그레이션 도중)에는 relinker 명령을 반복적으로 수행하는 것만으로도 충분합니다. 이 명령을 실행할 때마다 만료된 메일이나 고아 메일을 저장소에서 삭제하기 때문입니다.

처리되는 다른 분할 영역마다 병행하여 relinker의 여러 인스턴스를 실행(-p 옵션 사용)하는 것이 안전합니다. 메일은 같은 파티션 안에서만 재연결됩니다.

실시간 모드에서 relinker 사용

relinker 기능은 configutil 매개 변수 local.store.relinker.enabled를 yes로 설정함으로써 실시간 모드에서 활성화될 수 있습니다. 실시간 모드에서 relinker를 사용하면 구성된 relinker 기준( relinker 구성)에 맞게 배달된(또는 복원되거나 IMAP 추가된) 모든 메일의 다이제스트를 계산한 다음 해당 다이제스트가 이미 존재하는지 여부를 저장소에서 확인하게 됩니다. 이 다이제스트가 존재하는 경우에는 해당 메일의 새 사본을 만들지 않고 그에 대한 링크를 대상 메일함에 만듭니다. 다이제스트가 없을 때는 메일을 만들고 나중에 그에 대한 링크를 저장소에 추가합니다.

stored는 각 분할 영역의 다이제스트 저장소를 스캔하고 링크 수가 한 개인 메일(즉, relinker 기준에 맞지 않는 메일)을 삭제합니다. 스캔은 구성 가능한 시간 동안 한 번에 한 디렉토리씩 수행됩니다. 이로써 I/O 로드가 공평하게 분산되고 다른 서버 작업에 별다른 영향을 주지 않게 됩니다. 기본적으로 삭제 주기는 24시간이며 이는 저장소에서 메일이 삭제되거나 구성된 최대 캐시 사용 기간을 초과해도 최대 24시간까지는 그대로 남아 있다는 의미입니다. 이 작업은 relinker 실시간 모드가 활성화되어 있는 경우 사용 가능합니다.

relinker 구성

표 18–13은 relinker 기준을 설정하는 데 사용된 매개 변수를 보여 줍니다.