Exchange Queue & A알 수 없는 첨부 파일 크기 증가, 공용 폴더 복제 등
Henrik Walther
Q 회사에서 Exchange Server 2007을 기반으로 한 메시징 인프라를 사용하고 있습니다. 또한 메시지 크기를 12MB로 엄격히 제한하고 있습니다.
그런데 메시지의 첨부 파일 크기와 관련이 있는 듯한 이상한 현상이 발생했습니다. 예를 들어 외부 사용자에게 11MB의 파일이 첨부된 전자 메일 메시지를 보내면 메시지가 받는 사람에게는 정상적으로 배달되지만 메시지(첨부 파일 포함)를 인터넷 네트워크에서 보낸 사람에게 다시 전달하면 보낸 사람이 배달 못함 보고서(NDR)를 받게 됩니다. 보고서의 내용은 메시지가 현재 시스템의 메시지 크기 제한보다 크거나 받는 사람의 사서함이 꽉 찼다는 것입니다.
문제를 면밀히 조사해보니 회사 외부로 메시지를 보내고 얼마 후 첨부 파일 크기가 약 30% 커진다는 사실이 발견되었습니다. 인터넷을 통해 전자 메일 메시지를 보내고 받는 동안 첨부 파일 크기가 커지는 이유는 무엇입니까? 정상적인 현상입니까?
A 정상적인 현상입니다. Exchange Server 2007뿐만 아니라 이전 버전의 Exchange Server는 물론 MIME(Multipurpose Internet Mail Extensions)을 지원하고 Base64를 사용하여 첨부 파일을 인코딩하는 기타 메시징 시스템에서 이와 같은 동작을 보이는 경우가 많습니다. 내부 Exchange 사용자가 Exchange 조직 내의 받는 사람에게 메시지를 보내면 메시지의 내용을 변환할 필요가 없으므로 배달된 메시지나 첨부 파일의 크기가 증가하지 않습니다. 그러나 외부의 받는 사람에게 보낸 메시지는 내용 변환이 필요합니다.
표준 SMTP 메시지(일반 텍스트 메시지)는 메시지 봉투와 메시지 내용(메시지 헤더 및 메시지 본문)으로 구성됩니다. 이러한 요소는 일반 7비트 US-ASCII 텍스트를 기반으로 하는데 일반 US-ASCII 텍스트 이외의 요소가 메시지에 포함되어 있으면 해당 요소를 인코딩해야 합니다. 이렇게 첨부 파일과 같이 텍스트가 아닌 내용을 처리할 때 MIME가 인코딩에 사용됩니다. Exchange 2007과 이전 버전의 Exchange Server는 Base64 알고리즘을 사용하여 첨부 파일을 인코딩합니다. 그런데 Base64는 첨부 파일 크기를 33% 증가시키는 단점이 있습니다.
Exchange 2007에서는 Outlook Web Access를 사용하는 경우를 제외하고 대부분의 전송 관련 내용 변환이 허브 전송 서버에서 이루어집니다. 자세한 내용은 "내용 변환 이해"(technet.microsoft.com/library/bb232174) 문서를 참조하시기 바랍니다.
Q Exchange 2003에서 Exchange 2007로 전환하는 중입니다. 사용자 사서함은 모두 Exchange 2007 사서함 서버로 이전하고 CCR(클러스터 연속 복제)를 사용하여 구성했습니다. 현재는 모든 공용 폴더를 기존 Exchange 2003 공용 폴더 서버에서 CCR 기반 사서함 서버로 복제하고 있습니다. 하지만 테스트를 하던 중에 CCR 클러스터에서 손실 장애 조치가 발생하면 다른 노드의 공용 폴더 데이터베이스가 온라인으로 연결되지 않는 문제가 발견되었습니다. 또한 장애 조치 후에 수동으로 탑재할 수도 없습니다.
프로덕션 환경의 Exchange 2007 인프라를 미러링한 테스트 환경에서도 같은 문제가 발생했습니다. CCR 클러스터의 사서함에서는 손실 장애 조치(가 발생해도 이 문제가 발생하지 않으므로 CCR 클러스터의 공용 폴더 데이터베이스와 관련된 문제인 것 같습니다. 공용 폴더 데이터베이스를 비롯한 모든 데이터베이스를 중복 구축할 예정인데, 이러한 문제가 발생하는 원인이 무엇이라고 생각하십니까?
A Exchange 2007에서 CCR에 사용되는 복제 방법과 공용 폴더 복제에 사용되는 복제 방법은 큰 차이가 있습니다. 때문에 CCR 기반 사서함 서버를 사용하는 Exchange 조직의 경우 공용 폴더 데이터베이스 중 하나가 CCR 기반 사서함 서버에서 호스트된다면 여러 공용 폴더 데이터베이스를 결합하지 않는 것이 좋습니다. 전환 시에 이러한 구축이 가능하고 Exchange 제품 그룹에서도 CCR 기반 사서함 서버(예: Exchange 2003 서버)에서 호스트되는 공용 폴더 데이터베이스를 지원하는 것이 사실입니다. 그러나 모든 공용 폴더 데이터를 복제한 후에 CCR 기반이 아닌 사서함 서버에서 공용 폴더 데이터베이스를 제거하는 것이 좋습니다.
현재 Exchange 메시징 환경에서 발생하는 문제는 정상적인 현상입니다. 공용 폴더 데이터베이스가 여러 개이고 그 중 하나를 CCR 기반 사서함 서버에서 호스트하는 경우 손실 장애 조치를 실행하는 동안(즉, 계획되지 않은 중단이 발생한 동안) CCR 기반 사서함 서버의 공용 폴더 데이터베이스가 온라인으로 연결되지 않습니다.
이 경우 사실 이전 액티브 노드를 다시 가동하기 전까지는 공용 폴더 데이터베이스를 온라인으로 연결할 수 없습니다. 뿐만 아니라 공용 폴더 데이터베이스가 호스트되는 저장소 그룹에 대한 모든 트랜잭션 로그 파일도 사용 가능한 상태여야 합니다.
로그 파일 중 일부를 사용할 수 없는 상황이면 먼저 마지막 올바른 백업에서 공용 폴더 저장소를 복원하는 조치를 취하고 사용 가능한 로그를 모두 확인한 후 복원된 데이터베이스에서 다른 노드를 다시 시드해야 합니다. 또는 공용 폴더 저장소를 다시 새로 만들 수도 있습니다. 이 경우 원래 액티브 노드를 복구하고 새 공용 폴더 데이터베이스를 만들고 Exchange 조직의 다른 공용 폴더 서버에서 공용 폴더 데이터를 복제해야 합니다.
무손실(계획한) 중단을 수행할 때는 공용 폴더 데이터베이스가 온라인으로 연결된다는 점이 다시 의아할 수 있습니다. 이 역시 정상적인 동작입니다. 자세한 내용은 "클러스터 연속 복제 계획"에서 "클러스터 연속 복제 및 공용 폴더 데이터베이스"를 참조하시기 바랍니다.
Q Exchange 2007 기반 메시징 인프라 내의 모든 사서함 서버를 CCR을 사용하여 구성했습니다. CCR에 대해서는 만족하지만 한 가지 궁금한 점이 있습니다.
야간에 온라인 유지 관리를 진행하는 동안 온라인 조각 모음 작업도 실행하고 있습니다. 온라인 유지 관리를 실행하는 동안 CCR 클러스터의 패시브 노드에 있는 데이터베이스가 조각 모음되도록 하려면 어떻게 해야 합니까?
A 제거하도록 표시된 항목을 모두 삭제하여 해당 항목에 사용된 공간을 공백으로 바꾸는 온라인 조각 모음 작업 프로세스를 실행하는 동안에는 새 트랜잭션 로그 파일이 생성됩니다. 액티브 CCR 노드에서 생성된 트랜잭션 로그 파일은 패시브 노드에 복제되기 때문에 패시브 노드의 데이터베이스도 변경됩니다.
이 점을 고려하여 백업 시간대와 충돌하지 않도록 온라인 유지 관리 일정을 계획하시기 바랍니다. 백업 시간대와 온라인 유지 관리 시간대가 겹치면 온라인 조각 모음이 중지됩니다. 조각 모음을 꼭 매일, 매주 또는 격주로 수행할 필요는 없습니다. 이전에는 Exchange 제품 그룹에서 최소한 격주로 온라인 조각 모음을 실행하도록 지침을 정했었지만 조직마다 환경이 다르기 때문에 Exchange Server 2007 SP1부터 지침이 바뀌었습니다. 새 지침에 대한 자세한 내용은 Microsoft Exchange 팀 블로그의 게시물을 참조하시기 바랍니다.
Q 사서함 서버를 중복 구축하기 위해 Exchange 2007 CCR을 사용할 계획입니다. 현재 액티브 CCR 노드에서 패시브 노드로의 손실 장애 조치를 실행하는 동안 메시지가 손실되지 않도록 Transport Dumpster를 CCR과 함께 사용하는 방안을 고려하고 있습니다. 저희가 알아야 할 Transport Dumpster 관련 문제가 있습니까?
A Transport Dumpster는 CCR을 사용하는 Exchange 2007 사서함 서버에서 노드 간 손실 장애 조치를 실행하는 동안 데이터 손실을 최소화합니다. 이는 최근에 사서함 서버로 전송된 메시지를 다시 배달하는 방법으로 이루어집니다. 손실 장애 조치를 실행하는 동안에는 실제로 일부 트랜잭션 로그 파일이 손실될 가능성이 있으며, 그 때문에 실제 데이터도 손실될 수 있습니다. 앞서 설명했듯이 Transtport Dumpster는 최근에 사서함 서버로 전송된 메시지를 다시 배달하므로 손실 장애 조치를 실행하는 동안 손실된 데이터가 복원됩니다. 그러나 Transport Dumpster 허브 전송 서버를 통해 배달된 메시지만 해당되므로 손실 장애 조치 직전에 만든 작업 및 일정 항목과 같은 데이터는 손실됩니다.
Q Exchange 2003 조직에서 새 Active Directory 포리스트의 Exchange 2007 조직으로 포리스트 간 마이그레이션을 계획하고 있습니다. 포리스트 간 마이그레이션에 대한 "단일 포리스트에서 포리스트 간으로 전환하는 방법"이라는 문서를 통해 포리스트 간 외부 트러스트가 아니라 포리스트 트러스트를 만들어야 한다는 사실을 알게 되었습니다. 외부 트러스트를 사용할 수 없는 이유는 무엇입니까?
A TechNet의 Exchange 2007 관련 문서에서는 외부 트러스트 대신 포리스트 트러스트를 사용해야 한다고 설명하고 있지만 그렇다고 외부 트러스트를 사용할 수 없는 것은 아닙니다. 사실 외부 트러스트를 사용해도 포리스트 간 Exchange 마이그레이션을 수행하는 데 아무 문제가 없습니다. 단, 할당된 사용 권한에 관계없이 로그온한 사용자의 자격 증명은 사용할 수 없기 때문에 연결된 사서함을 만들 때 트러스트된 포리스트의 도메인 컨트롤러에 액세스하려면 적절한 사용 권한이 있는 계정을 지정해야 한다는 단점이 있습니다(그림 1 참조).
그림 1 연결된 사서함을 만들 때 마스터 계정 페이지에서 계정 지정
Q Exchange 2007로 전환한 후 지금까지 한 가지를 제외하면 새 버전에 매우 만족하고 있습니다. Exchange 2003 SP2를 사용할 때는 사용자 사서함의 단순한 표시 이름이 보내는 메시지에 보낸 사람으로 표시되도록 환경을 구성할 수 있었습니다. 그러나 Exchange 2007에서는 이와 유사한 기능을 찾을 수 없어 당황스럽습니다. Exchange 2007에서는 이 기능이 제공되지 않습니까?
A 이 기능은 Exchange 2007 RTM에서는 제공되지 않았으며 2008년 10월에 발표된 Exchange 2007 SP1 롤업 업데이트 4(RU4)에서 추가되었습니다. SP1 RU4를 설치하면 Exchange 2003 SP2와 마찬가지로 보내는 메시지에 단순한 표시 이름이 표시되도록 Exchange를 구성할 수 있습니다. 이러한 구성 작업은 Windows PowerShell Set-RemoteDomain cmdlet를 –UseSimpleDisplayName 매개 변수와 함께 사용하여 수행합니다. 예를 들어 contoso.com 도메인에 보내는 메시지에 단순한 표시 이름을 표시하려면 그림 2에 나와 있는 명령을 사용하면 됩니다.
그림 2 보내는 메시지에 단순한 표시 이름 사용
Q Exchange 2007-CCR 기반 사서함 서버에서 패시브 노드의 데이터베이스 복사본을 조각 모음하는 최상의 방법은 무엇입니까? CCR의 노드 중 하나에 있는 데이터베이스만 조각 모음하고 나머지 노드에서는 조각 모음하지 않으면 Exchange에서 문제가 발생합니까?
A 오프라인으로 조각 모음해야 할 경우 CCR 클러스터의 액티브 노드에서 조각 모음을 수행해야 하며 패시브 노드에서 수행해서는 안 됩니다. 또한 액티브 노드에서 하나 이상의 데이터베이스에 대해 오프라인 조각 모음을 수행하면 해당 데이터베이스 전체를 패시브 노드로 다시 시드해야 합니다.
따라서 200GB 데이터베이스(CCR을 사용하는 경우 1GB 네트워크를 통해 복제할 때 권장 데이터베이스 크기는 200GB)를 조각 모음하는 데 몇 시간(대개 시간 당 2-4GB)이 걸립니다. 게다가 조각 모음 프로세스가 끝난 후에 200GB의 데이터를 다시 패시브 노드에 복제해야 합니다. 때문에 공용 네트워크를 통한 로그 파일 전달이 발생하면 이러한 작업이 최종 사용자의 환경에서 전반적인 네트워크 성능에 영향을 줄 수 있습니다.
대부분의 경우 오프라인 조각 모음은 데이터베이스에서 공백을 제거하여 데이터베이스 크기를 줄이기 위해 수행하게 됩니다. 하지만 공백은 데이터베이스 크기가 더 커기지 전에 다시 사용되므로 이러한 오프라인 조각 모음이 필요한 경우는 드뭅니다. 또한 데이터베이스나 디스크 자체에 사용 가능한 공간이 남아 있는 것이 문제될 것도 없습니다.
데이터베이스에 몇 기가바이트에 달하는 공백이 있고 그러한 공백을 제거하려는 경우에는 모든 사서함을 해당 데이터베이스에서 새 데이터베이스로 옮기는 편이 훨씬 낫습니다.
Henrik Walther는 Microsoft Certified Master로서, 14년 이상의 IT 비즈니스 경력을 자랑하는 Exchange 2007 및 Exchange MVP이기도 합니다. 현재 Interprise Consulting(덴마크에 위치한 Microsoft 골드 파트너)에서 기술 설계자로 근무하면서 Biblioso Corp(미국에 위치한 문서 관리 및 지역화 서비스를 전문 업체)에서 테크니컬 라이터로도 활동하고 있습니다.