메시지 라우팅 이해

  • 아티클

 

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2016-11-28

조직에서 허브 전송 및 Edge 전송 서버의 기본 작업은 사용자 및 외부 원본으로부터 받은 메시지를 최종 대상으로 라우팅하는 것입니다. 이 항목에서는 Microsoft Exchange Server 2010이 조직에서 메시지를 라우팅하는 방법에 대해 설명합니다.

전송 서버 관리와 관련된 관리 작업에 대한 자세한 내용은 전송 서버 관리를 참조하십시오.

목차

Exchange 2010 메시지 라우팅 개요

라우팅 구성 요소

라우팅에 Active Directory 사이트 사용

Exchange 2010 라우팅 테이블

라우팅을 위한 메시지 받기

메시지 라우팅

다시 라우팅 및 연결할 수 없는 큐

Exchange 2010 메시지 라우팅 개요

라우팅 결정은 메시지를 분류하는 동안 이루어집니다. 분류기는 받는 메시지를 모두 처리하고 받는 사람에 대한 정보에 따라 메시지로 수행할 작업을 결정하는 Microsoft Exchange 전송 서비스의 구성 요소입니다. 분류기는 서로 종속되는 여러 단계에 걸쳐 메시지를 처리하며, 이러한 메시지 처리 작업 중에 Microsoft Exchange 전송 서비스의 다른 구성 요소도 사용합니다. Exchange 2010 전송 서버에서 메시지를 받고 SMTP 수신 중에 수행되는 사전 처리가 완료되고 나면 해당 메시지는 전송 큐로 배달됩니다. 그런 후 메시지가 다음과 같은 단계로 분류기를 통해 전송 큐에서 이동합니다.

  1. **에이전트를 통해 전송 메시지 처리   **분류 작업을 위해 메시지를 받으면 허브 전송 서버의 일부 에이전트를 통해 메시지가 처리됩니다. 이 단계에 적용되는 에이전트에는 옵션인 Microsoft Forefront Protection for Exchange Server 바이러스 백신 에이전트 및 저널링 에이전트가 있습니다.

  2. **받는 사람 확인   **이 단계 동안 받는 사람이 Exchange 조직 내에 사서함을 가지고 있는지 아니면 외부 전자 메일 주소를 사용하는지를 확인하기 위해 받는 사람의 전자 메일 주소가 확인됩니다.

  3. **라우팅   **받는 사람에 대한 정보가 확인되고 나면 분류기의 라우팅 구성 요소가 메시지의 최종 대상 및 해당 대상에 대한 경로를 확인하고, 메시지 릴레이를 위한 다음 세그먼트 또는 홉을 선택하여 실제 서버와 IP 주소 목록에 대해 다음 홉 정보를 확인합니다.

  4. 내용 변환   메시지를 다음 홉으로 릴레이하기 전에 받는 사람이 읽을 수 있는 형식으로 해당 메시지가 보내지도록 내용 변환을 수행합니다. 내용 변환은 메일 흐름이나 저장을 위해 MAPI에서 MIME으로 또는 UUENCODE에서 base64 인코딩으로, 또는 전자 메일 클라이언트에 맞는 적절한 렌더링을 위해 HTML, RTF(서식 있는 텍스트), 일반 텍스트 등과 같이 전자 메일 메시지를 한 형식에서 다른 형식으로 변환합니다.

  5. 에이전트를 통해 라우팅된 메시지 처리   특정 메시지에 대해 라우팅 결정이 이루어지면 전송 규칙 에이전트 및 저널링 에이전트가 허브 전송 서버에 적용됩니다. 저널링 에이전트는 메시지가 전송될 때와 라우팅될 때 모두 적용되므로 전송 규칙 에이전트가 배달 주소를 수정하거나 메시지별 저널링 요구 사항을 적용하는 등 메시지에 대해 수행하는 모든 변경 내용이 저널링 에이전트에 반영됩니다.

  6. 메시지 패키징 및 DSN 생성   최종적으로 분류된 메시지가 조합되어 배달 큐로 이동합니다. 이 단계에서 DSN(배달 상태 알림)도 생성될 수 있습니다.

그런 다음 메시지는 SMTP 송신, 저장소 드라이버, 배달 에이전트 또는 외부 게이트웨이 연결 처리기에 의해 처리됩니다. 사용되는 구성 요소는 최종 대상에 따라 다릅니다. 각 홉에 대한 배달 큐가 동적으로 생성되고, 메시지는 라우팅 결정이 내려진 후 이들 배달 큐에 대기합니다. 받는 사람에 대한 경로를 찾을 수 없는 경우 메시지는 연결할 수 없는 큐에 대기합니다.

다음 그림에서는 서로 다른 라우팅 단계에서 메시지 처리 작업이 수행되는 방법 및 다음 홉 대상으로의 배달을 위해 메시지가 대기하는 방법을 보여줍니다.

메일 흐름에서의 라우팅 컨텍스트

맨 위로 이동

라우팅 구성 요소

Exchange 2010이 라우팅 결정을 내리기 위해서는 Active Directory에 저장된 구성 정보에 액세스해야 합니다. Edge 전송 서버에서 구성 정보는 로컬 서버의 AD LDS(Active Directory Lightweight Directory Services) 인스턴스에 저장되고 여기서 액세스됩니다. MicrosoftWindows와 Exchange 2010 서비스가 함께 구성 데이터의 매핑을 만듭니다. 이러한 매핑은 라우팅 테이블에서 캐시되며, Exchange 2010에서는 라우팅 결정을 내릴 때 이 테이블을 참조합니다. 라우팅 토폴로지가 변경되면 캐시가 업데이트됩니다. 메시지 전송 중에 사용되는 Exchange 서비스는 허브 전송 서버 역할 및 Edge 전송 서버 역할에서 모두 같습니다. 그러나 Edge 전송 서버 역할은 Active Directory 토폴로지에 대한 정보를 캐시하지 않습니다.

메시지 라우팅의 경우 다음과 같은 구성 및 서비스 구성 요소가 중요한 역할을 합니다.

  • Active Directory 사이트   Active Directory 사이트는 허브 전송 서버의 라우팅 경계를 나타냅니다. 허브 전송 서버는 사서함 서버, 메일 그룹 확장 서버 및 로컬 Active Directory 사이트에 있는 커넥터의 원본 서버와 해당 사이트에 구독된 Edge 전송 서버로 메시지를 직접 배달합니다. 그러나 허브 전송 서버는 받는 사람, 확장 서버 및 원격 Active Directory 사이트에 있는 커넥터의 다른 허브 전송 서버로 메시지를 릴레이해야 합니다. 허브 전송 서버 역할은 다른 Exchange 2010 서버 역할을 포함하는 각 Active Directory 사이트에 배포되어야 합니다.

  • Active Directory IP 사이트 링크   Active Directory IP 사이트 링크는 Active Directory 사이트 간의 논리 경로를 정의합니다. Exchange 2010에서는 IP 사이트 링크 개체를 참조하여 원격 Active Directory 사이트의 최소 비용 라우팅 경로를 결정합니다.

  • 송신 커넥터   송신 커넥터는 SMTP 호스트로 메시지를 보내는 데 사용됩니다. 송신 커넥터의 주소 공간 구성은 라우팅 결정을 내리는 데 사용됩니다. 일반적으로 메시지를 외부 도메인으로 배달할 때의 라우팅 대상은 송신 커넥터입니다. 여러 전자 메일 도메인에 대해 메시지를 수락하는 Exchange 조직에서는 각 주소 공간에서 전용으로 사용되는 송신 커넥터를 만들도록 결정할 수 있습니다. 외부 도메인에 메시지를 라우팅하기 위한 송신 커넥터 선택에 대한 자세한 내용은 외부 메시지 라우팅을 참조하십시오.

  • 배달 에이전트   배달 에이전트는 메시지 전송에 SMTP 프로토콜을 사용하지 않는 외부 시스템에 메시지를 라우팅하는 데 사용됩니다. 배달 에이전트의 주소 공간 및 프로토콜 구성은 라우팅 결정을 내리는 데 사용됩니다.

  • 외부 커넥터   외부 커넥터는 Drop 디렉터리를 사용하여 메시지 전송에 SMTP 프로토콜을 사용하지 않는 외부 시스템에 메시지를 보냅니다. Exchange는 라우팅 결정을 내릴 때 외부 커넥터의 구성을 사용합니다.

  • 라우팅 그룹   라우팅 그룹은 Exchange Server 2003의 라우팅 경계를 나타냅니다. 기존 Exchange 2003 조직에 Exchange 2010을 배포한 경우 Exchange 2003에 상주하는 커넥터 또는 사서함으로 메시지를 배달하려면 라우팅 과정에서 라우팅 그룹 내 서버 위치를 고려해야 합니다. Exchange 2003과의 호환성을 구현하기 위해, 조직에 배포된 Exchange 2010을 실행하고 있는 모든 컴퓨터는 하나의 글로벌 라우팅 그룹에 속합니다.

  • 라우팅 그룹 커넥터   라우팅 그룹 커넥터는 Exchange 라우팅 그룹 간의 논리 경로를 정의합니다. Exchange 2010을 기존 Exchange 2003 조직에 배포한 경우 메시지는 라우팅 그룹 커넥터를 통해 서버 버전 간에 라우팅됩니다. 첫 번째 허브 전송 서버를 배포하면 설치 프로세스를 수행할 때 Exchange 2010 글로벌 라우팅 그룹에서 레거시 라우팅 그룹으로의 라우팅 그룹 커넥터를 만들라는 메시지가 표시됩니다. 여러 버전의 Exchange가 배포된 환경에서의 메시지 라우팅에 대한 자세한 내용은 내부 메시지 라우팅을 참조하십시오.

  • Microsoft Exchange Transport Service   MicrosoftExchange Transport Service는 Exchange 2010을 위한 SMTP 공급자이며 SMTP IN에서 SMTP OUT까지 메시지 처리의 모든 구성 요소를 제어합니다. 일련의 구성 가능한 SMTP 수신 에이전트는 여러 SMTP 이벤트 발생 시 트리거됩니다. MicrosoftExchange 전송 서비스를 사용하면 메시지가 SMTP 전송을 통과할 때 이러한 에이전트가 메시지를 처리할 수 있으며 메시지가 분류기로 전송되기 전에 스팸 방지, 바이러스 백신 및 기타 작업을 수행할 수 있습니다. 또한 MicrosoftExchange 전송 서비스는 Exchange 토폴로지 검색에 토폴로지 검색 모듈을 사용합니다.

  • Microsoft Exchange Active Directory 토폴로지 서비스   MicrosoftExchange Active Directory 토폴로지 서비스는 Exchange 2010이 Active Directory에서 구성 및 받는 사람 데이터를 검색하는 데 사용할 수 있는 글로벌 카탈로그 서버 및 도메인 컨트롤러를 찾습니다. 또한 Microsoft Exchange Active Directory 토폴로지 서비스는 Exchange 2010 서버의 Active Directory 사이트 선호도를 최신 상태로 유지합니다.

  • 라우팅 테이블   라우팅 테이블에는 라우팅 구성 요소가 라우팅 결정을 내리는 데 사용하는 정보가 보관됩니다. 라우팅 테이블은 토폴로지 구성 요소 맵 및 각 구성 요소 간의 관계로 구성됩니다.

  • DNS Exchange 2010은 MicrosoftExchange 전송 서비스의 구성 요소인 향상된 DNS(Domain Name System) 클라이언트를 사용하여 대상 서버 이름 목록에 대해 다음 홉 선택 항목을 확인합니다. IP 주소에 대한 해당 서버 이름 목록을 확인하는 작업에는 표준 DNS 클라이언트가 사용됩니다. 또한 향상된 DNS는 라운드 로빈 방식을 사용하여 Exchange 2010 전송 서버에 부하 분산 기능을 제공합니다.

  • SMTP SMTP는 SMTP 서버 간에 메시지가 릴레이될 때의 통신에 사용됩니다. SMTP 서버는 허브 전송 서버, Edge 전송 서버, Exchange 2003 서버 또는 스마트 호스트일 수 있습니다. 허브 전송 서버는 RPC(원격 프로시저 호출)를 사용하여 해당 허브 전송 서버와 동일한 Active Directory 사이트 구성원 자격이 있는 사서함 서버로 메시지를 직접 배달합니다.

맨 위로 이동

라우팅에 Active Directory 사이트 사용

Active Directory 사이트는 네트워크의 물리적 측면을 기반으로 하는 논리적 구성 요소입니다. Active Directory 사이트를 만드는 주요 목적은 네트워크에서 Active Directory 복제 트래픽을 최적으로 제어할 수 있는 방식으로 연결되어 있는 서브넷을 정의하기 위한 것입니다. Active Directory 사이트는 Exchange 2010의 라우팅 경계를 나타냅니다. 허브 전송 서버 역할이 설치된 컴퓨터는 Active Directory 사이트 토폴로지를 기반으로 라우팅 결정을 내립니다.

사이트 구성원 확인

기본적으로 Active Directory 포리스트에는 Active Directory 사이트가 하나만 포함되어 있습니다. 이 Active Directory 사이트의 기본 이름은 Default-First-Site-Name입니다. 다른 Active Directory 사이트를 만들지 않으면 포리스트에 있는 모든 도메인 구성원 컴퓨터가 Default-First-Site-Name의 구성원이 됩니다. 따라서 서브넷과 사이트 간 연결을 구성할 필요가 없습니다. Active Directory 사이트를 추가로 만드는 경우에는 해당 Active Directory 사이트에 할당되는 서브넷을 지정해야 합니다.

각 Active Directory 사이트는 하나 이상의 IP 서브넷에 연결됩니다. 관리자는 도메인 컨트롤러 및 글로벌 카탈로그 서버로 구성된 컴퓨터에 Active Directory 사이트 구성원 자격을 할당합니다. Exchange 서버 등의 다른 도메인 구성원 컴퓨터는 Active Directory 사이트에 연결된 IP 서브넷에 있는 IP 주소를 사용하도록 구성될 때 자동으로 Active Directory 사이트 구성원 자격을 할당받습니다. 동일한 Active Directory 사이트 구성원 자격이 있는 컴퓨터의 경우 네트워크에 제대로 연결된 것으로 간주합니다. 서버는 항상 하나의 Active Directory 사이트에 속한 구성원이 됩니다.

응용 프로그램이 설치된 컴퓨터 및 포리스트에 있는 다른 컴퓨터의 Active Directory 사이트 구성원 자격을 결정할 수 있고, 해당 정보를 사용하여 통신 흐름을 제어할 수 있는 경우 이 응용 프로그램을 사이트 인식 응용 프로그램이라고 합니다. 사이트 인식 응용 프로그램이 도메인 컨트롤러나 글로벌 카탈로그 서버 등 다른 서버의 서비스를 사용해야 하는 경우 해당 서비스를 요청하는 컴퓨터와 동일한 Active Directory 구성원 자격이 있는 서버에 우선 순위가 주어집니다.

Exchange 2010은 사이트 인식 응용 프로그램이며 다른 Exchange 2010 서버 역할이 설치되어 있는 컴퓨터에서 실행되는 서버와의 통신 및 메시지 라우팅에 Active Directory 토폴로지를 사용합니다. Active Directory 사이트는 라우팅 경계일 뿐 아니라 서비스 검색 경계이기도 합니다.

도메인 구성원 컴퓨터에 대한 사이트 구성원 자격을 결정하는 작업은 로컬 IP 주소를 정의된 서브넷과 비교한 다음 적절한 사이트 구성원 자격 연결을 결정하는 일련의 DNS 쿼리에 따라 달라집니다. DNS 쿼리와 연관된 오버헤드를 줄이기 위해 Exchange 2010 Active Directory 스키마 추가 사항에는 Exchange 서버 개체에 대한 msExchServerSite 특성이 포함되어 있습니다. 이 특성의 값은 Exchange 서버의 Active Directory 사이트 고유 이름입니다. 이 특성은 각 Exchange 서버 개체의 속성입니다. 사이트 구성원 자격 선호도가 서버 개체의 특성으로 저장될 때 DNS 쿼리를 사용하는 대신 현재 토폴로지를 Active Directory에서 직접 읽을 수 있으며, 가입된 Edge 전송 서버와 같은 비도메인 컴퓨터에 대해 사이트 구성원 자격 연결을 사용할 수 있습니다.

msExchServerSite 특성의 값은 Microsoft Exchange Active Directory 토폴로지 서비스에 의해 사용되고 최신 상태로 유지됩니다. Windows 기반 컴퓨터가 시작되면 네트워크 로그온 서비스가 해당 컴퓨터의 사이트 구성원 자격을 확인합니다. 네트워크 로그온 서비스는 해당 정보를 사용하여 로컬 컴퓨터와 동일한 Active Directory 사이트에 있는 도메인 컨트롤러를 찾은 다음 해당 서버에 대해 권한 부여 및 인증 요청을 지시합니다. Microsoft Exchange Active Directory 토폴로지 서비스는 DsGetSiteName API 호출을 사용하여 Net Logon 서비스에서 사이트 구성원 값을 검색하고 Active Directory 사이트의 고유 이름을 Active Directory에 있는 Exchange 서버 개체의 msExchServerSite 특성에 씁니다.

다음 표에서는 조직에서 Active Directory 사이트를 정의하는 방법을 보여줍니다. 이 예제에서는 세 개의 Active Directory 사이트를 정의하며 각 Active Directory 사이트는 둘 이상의 IP 서브넷에 연결되어 있습니다.

Active Directory 사이트와 서브넷 간 연결 예

Active Directory 사이트 이름 연결된 IP 서브넷

사이트 A

192.168.1.0/24

192.168.2.0/24

사이트 B

192.168.3.0/24

192.168.4.0/24

사이트 C

192.168.5.0/24

192.168.6.0/24

HubTransportA 서버의 IP 주소가 192.168.1.1인 경우 이 서버는 사이트 A의 구성원입니다. 서버의 IP 주소를 변경하면 사이트 구성원 자격도 변경할 수 있습니다. HubTransportA의 IP 주소를192.168.2.1로 변경해도 해당 서버의 Active Directory 사이트 구성원 자격은 변경되지 않습니다. 해당 서브넷은 사이트 A에도 연결되어 있기 때문입니다. 그러나 서버를 이동하여 IP 주소가 192.168.3.1로 변경된 경우 해당 서버는 사이트 B의 구성원으로 간주됩니다.

서브넷 연결을 Active Directory 사이트로 변경하는 경우에도 사이트 구성원 자격이 변경될 수 있습니다. 예를 들어, 서브넷 192.168.3.0을 사이트 B와의 연결에서 제거하고 사이트 A에 연결하면 IP 주소가 192.168.3.1인 서버의 사이트 구성원 자격도 사이트 A로 변경됩니다. 사이트 구성원 자격이 변경될 때마다 Exchange 2010은 구성 데이터를 업데이트하여 Exchange 2010에서 라우팅 결정을 내릴 때 변경 내용이 반영되도록 해야 합니다. Active Directory 사이트 구성원 자격이 변경되고 토폴로지 변경 내용이 완전히 전파되는 사이에 약간의 대기 시간이 발생합니다. 토폴로지 변경 내용을 전파하려면 다음 통신이 다음과 같은 순서로 수행되어야 합니다.

  1. 사이트 구성원 자격 변경 내용이 도메인 컨트롤러에 기록됩니다. 업데이트된 정보가 포리스트에 있는 각 Active Directory 사이트의 도메인 컨트롤러 간에 복제됩니다. 변경 내용이 포리스트 전체로 완전히 전파되는 데 필요한 시간은 사이트 링크에서 정의한 Active Directory 복제 토폴로지 및 일정에 따라 달라집니다.

  2. Net Logon 서비스는 모든 Windows 기반 컴퓨터에서 실행되고 Active Directory 사이트 구성원 자격의 변경 내용을 자주 폴링합니다. 네트워크 로그온 서비스는 5분 간격으로 폴링합니다. 따라서 네트워크 로그온 서비스에서 5분 내에 업데이트를 받는 로컬 도메인 컨트롤러의 변경 내용을 검색합니다.

  3. MicrosoftExchange Active Directory 토폴로지 서비스가 15분 간격으로 네트워크 로그온 서비스를 쿼리하여 로컬 Exchange 서버의 Active Directory 사이트 구성원 자격을 확인합니다. 변경 내용이 검색되면 MicrosoftExchangeActive Directory 토폴로지 서비스에서 MsExchServerSite 특성을 업데이트합니다.

  4. 그러면 Exchange 서버 구성 개체의 변경된 사이트 특성 값이 조직 전체로 복제되고 조직의 Exchange 서버에서 이 변경 내용을 검색합니다. 그런 다음 라우팅 테이블이 새 Active Directory 사이트 구성원 자격 특성 값으로 업데이트됩니다.

Active Directory 사이트 구성원 자격 변경 내용이 적용되는 시간과 업데이트된 정보를 다른 Exchange 2010 서버에서 사용할 수 있는 시간 사이에는 약간의 대기 시간이 발생합니다. Exchange 2010에서 이러한 유형의 구성 변경 내용을 처리하는 방법에 대한 자세한 내용은 이 항목 뒷부분의 "다시 라우팅 및 연결할 수 없는 큐"를 참조하십시오.

IP 사이트 링크

사이트 링크는 Active Directory 사이트 간의 논리 경로입니다. 사이트 링크 개체는 지정된 사이트 간 전송을 통해 같은 순위로 통신할 수 있는 사이트 집합을 나타냅니다. 사이트 링크는 실제 네트워크에서 네트워크 패킷이 이동하는 실제 경로에 해당하지 않습니다. 그러나 관리자가 사이트 링크에 할당하는 순위는 대개 기본 네트워크 안정성, 속도 및 사용 가능한 대역폭과 관련되어 있습니다. 예를 들어, Active Directory 관리자는 속도가 100Mbps(메가비트/초)인 네트워크 연결에 대해 속도가 10Mbps인 네트워크 연결보다 낮은 순위를 할당할 수도 있습니다.

기본적으로 모든 사이트 링크는 전이적입니다. 즉, 사이트 A에 사이트 B에 대한 링크가 있고 사이트 B에는 사이트 C에 대한 링크가 있는 경우 사이트 A는 사이트 C에 전이적으로 연결되어 있습니다. 사이트 A와 사이트 C 간의 전이적 링크를 사이트 링크 브리지라고도 합니다.

Active Directory 사이트 링크는 IP 또는 SMTP 중 하나를 통신을 위한 전송 프로토콜로 사용하도록 구성될 수 있습니다. SMTP 사이트 링크는 해당 프로토콜을 사용하여 복제할 수 있는 데이터 형식으로 제한되며, 신뢰할 수 있는 네트워크 링크가 없는 Active Directory 사이트 간의 복제에 축적 전송 메커니즘을 제공하도록 설계되었습니다. 반면 IP 사이트 링크는 해당 링크 전반에서 복제할 수 있는 데이터 유형으로 제한되지 않습니다. Exchange 2010에서는 라우팅 토폴로지를 결정할 때 IP 사이트 링크만 사용합니다. IP 사이트 링크에 할당되는 비용은 라우팅 테이블을 계산할 때 Exchange 2010의 라우팅 구성 요소에 의해 고려됩니다. 이러한 비용은 메시지를 최종적으로 배달할 대상에 대한 최소 비용 라우팅 경로를 계산하는 데 사용됩니다.

모든 Active Directory 사이트는 하나 이상의 IP 사이트 링크에 연결되어야 합니다. 단일 기본 IP 사이트 링크의 이름은 DEFAULTIPSITELINK입니다. Active Directory 사이트를 만들 때는 해당 사이트를 IP 사이트 링크에 연결해야 합니다. IP 사이트 링크를 추가로 만들어 원하는 토폴로지를 구현하거나 모든 Active Directory 사이트를 DEFAULTIPSITELINK에 연결할 수 있습니다. IP 사이트 링크에 속하는 각 Active Directory 사이트는 동일한 비용으로 해당 링크에 있는 다른 모든 사이트와 직접 통신할 수 있습니다.

다음 그림에서는 포리스트에 네 개의 Active Directory 사이트가 구성되어 있습니다. 각 사이트는 DEFAULTIPSITELINK에 연결되어 있습니다. 따라서 각 Active Directory 사이트는 동일한 순위 메트릭을 사용하여 다른 모든 사이트와 직접 통신합니다. 여러 통신 경로가 표시되어 있지만 IP 사이트 링크는 하나만 정의되어 있습니다.

단일 IP 사이트 링크를 사용한 풀 메시 토폴로지

다음 그림에서는 포리스트에 네 개의 Active Directory 사이트가 구성되어 있습니다. 그러나 이 토폴로지의 경우 관리자가 Active Directory 사이트의 허브 및 스포크 토폴로지를 만들도록 IP 사이트 링크를 구성했습니다. 각 스포크 사이트는 중앙 사이트와 직접 통신할 수 있으며 전이적 IP 사이트 링크를 사용하여 서로 통신할 수 있습니다.

Active Directory IP 사이트 링크의 허브 및 스포크 토폴로지

Exchange는 최소 비용 경로를 결정할 때만 사이트 링크를 사용하고 항상 대상 허브 전송 서버로 메시지를 직접 배달하려고 시도한다는 점에 유의해야 합니다. 예를 들어, 위 그림에 나온 토폴로지에서 사이트 B의 사용자가 사이트 C의 다른 사용자에게 메시지를 보내는 경우 사이트 B의 허브 전송 서버는 사이트 C의 허브 전송 서버에 직접 연결합니다. 만일 메시지가 사이트 A를 거쳐 가게 하려면 사이트 A를 허브 사이트로 설정해야 합니다. 허브 사이트에 대한 자세한 내용은 이 항목 뒷부분에 있는 "허브 사이트 구현"을 참조하십시오.

Active Directory 관리자는 포리스트의 연결성 및 통신 요구 사항을 가장 효율적으로 나타내는 토폴로지를 구현합니다. Exchange 2010에서도 이러한 토폴로지를 사용하므로 현재 토폴로지가 효율적인 메시지 통신을 지원하는지를 확인해야 합니다.

사이트 링크의 기본 비용은 100이며 유효한 사이트 링크 비용은 1부터 99,999 사이의 숫자입니다. 중복 링크를 지정하는 경우에는 가장 낮은 비용이 할당된 링크가 항상 기본적으로 사용됩니다. Exchange 조직 관리자는 Exchange 관련 비용을 IP 사이트 링크에 할당할 수 있습니다. Exchange 순위를 IP 사이트 링크에 할당하는 경우 Exchange 2010에서 이 순위를 사용합니다. 그렇지 않은 경우에는 Active Directory 순위가 사용됩니다. IP 사이트 링크에 대해 Exchange 순위를 설정하는 방법에 대한 자세한 내용은 이 항목 뒷부분의 "IP 사이트 링크 순위 제어"를 참조하십시오. Enterprise Administrators 그룹의 구성원인 관리자는 IP 사이트 링크를 추가로 만들 수 있습니다.

Active Directory 사이트 구성에 대한 자세한 내용은 사이트 토폴로지 디자인를 참조하십시오.

IP 사이트 링크 순위 제어

Active Directory IP 사이트 링크 비용은 WAN의 모든 네트워크 연결과 비교한 상대적 네트워크 속도를 기반으로 하며 안정적이고 효율적인 복제 토폴로지를 제공하도록 설계되었습니다. 따라서 대부분의 경우 기존 IP 사이트 링크 비용은 Exchange 2010 메시지 라우팅에 적합해야 합니다. 그러나 기존 Active Directory 사이트 및 IP 사이트 링크 토폴로지를 문서화한 후에 Active Directory IP 사이트 링크 비용과 트래픽 흐름 패턴이 Exchange 2010에 대해 최적 상태가 아니라고 생각되면 Exchange에서 평가한 비용을 조정할 수 있습니다. Active Directory 도구를 사용하여 IP 사이트 링크에 할당된 비용을 변경하면 전체 환경에 영향을 줄 수 있으므로, 대신 Exchange 관리 셸에서 Set-AdSiteLink cmdlet을 사용하여 IP 사이트 링크에 Exchange 관련 비용을 할당합니다. 예를 들어, IP 사이트 링크 SITELINKAB에 메시지 라우팅에 대한 다른 비용을 설정하려면 셸에서 다음 명령을 실행합니다.

Set-AdSiteLink -Identity SITELINKAB -ExchangeCost 25

Exchange 비용이 IP 사이트 링크에 할당되면 Exchange 비용은 메시지 라우팅에 대한 Active Directory 비용만 다시 정의하며, 라우팅 과정에서 최소 비용 라우팅 경로를 평가할 때는 Exchange 비용만 고려됩니다.

IP 사이트 링크 비용 조정은 메시지 라우팅 토폴로지가 Active Directory 복제 토폴로지와 달라야 하는 경우에 유용합니다. Exchange 비용은 모든 메시지 경로에서 허브 사이트를 강제 사용하도록 하는 데 사용할 수 있습니다. 또한 Exchange 비용은 Active Directory 사이트에 대한 통신이 실패하는 경우 메시지 대기 위치를 제어하는 데에도 사용할 수 있습니다. 다음 그림에서는 네 개의 사이트를 가진 Active Directory 토폴로지를 보여줍니다.

IP 사이트 링크에 Exchange 비용이 구성된 토폴로지

위 그림에서 사이트 C와 사이트 D 간의 네트워크 연결은 Active Directory 복제용으로만 사용되며 메시지 라우팅에 사용해서는 안 되는 낮은 대역폭 연결입니다. 그러나 이 링크는 Active Directory IP 사이트 링크 비용으로 인해 다른 Active Directory 사이트에서 사이트 D로의 최소 비용 라우팅 경로에 포함됩니다. 따라서 메시지는 사이트 C의 사이트 D 큐로 배달됩니다. Exchange 관리자는 최소 비용 라우팅 경로에 사이트 B를 대신 포함하여 사이트 D를 사용할 수 없는 경우 메시지가 사이트 B에 대기하도록 설정하고자 합니다. 이때 사이트 C와 사이트 D 간의 IP 사이트 링크에 높은 Exchange 비용을 구성하면 해당 IP 사이트 링크가 사이트 D에 대한 최소 비용 라우팅 경로에 포함되지 않습니다.

Exchange 2010은 Active Directory IP 사이트 링크에 최대 메시지 크기 제한을 구성하기 위한 지원을 제공합니다. 기본적으로 Exchange 2010은 서로 다른 Active Directory 사이트에 있는 허브 전송 서버 간에 릴레이되는 메시지에 대해 최대 크기 제한을 적용하지 않습니다. Set-AdSiteLink cmdlet을 사용하여 Active Directory IP 사이트 링크에 최대 메시지 크기를 구성하면 라우팅 시 최소 비용 라우팅 경로의 Active Directory 사이트 링크에 구성되어 있는 최대 메시지 크기 제한보다 큰 메시지에 대해서는 NDR(배달 못 함 보고서)이 생성됩니다. 이러한 구성은 대역폭이 낮은 연결을 통해 통신해야 하는 원격 Active Directory 사이트로 보내는 메시지의 크기를 제한하는 데 유용합니다. 자세한 내용은 메시지 크기 제한 이해를 참조하십시오.

허브 사이트 구현

Exchange 조직에서 특정 Active Directory 사이트를 통해 모든 메시지 배달이 릴레이되도록 해야 할 수도 있습니다. 이 시나리오에서는 연결이 사이트 간의 직접 SMTP 릴레이를 방해할 수 있습니다. 따라서 메시지가 대상에 보내지기 전에 중간 사이트를 통해 메시지를 릴레이해야 합니다. Exchange 조직의 내부 정책으로 인해 관리자가 특정 사이트를 통해 모든 메시지를 릴레이하기를 원하는 경우 셸 cmdlet을 사용하여 Active Directory 사이트를 허브 사이트로 지정할 수 있습니다. Active Directory 사이트를 허브 사이트로 지정하면 더 많은 서버가 메시지 배달에 참여하게 되므로 전체적인 오버헤드가 추가될 수 있습니다. 예를 들어, 사이트 A에서 사이트 E로 메시지를 보낸다고 가정해 봅시다. 최소 비용 라우팅 경로가 사이트 A-사이트 B-사이트 C-사이트 D-사이트 E이고 사이트 C를 허브 사이트로 지정하는 경우 메시지는 사이트 A에서 사이트 C로 릴레이된 다음 사이트 C에서 사이트 E로 릴레이됩니다.

Set-AdSite cmdlet을 사용하여 Active Directory 사이트를 허브 사이트로 지정합니다. 허브 사이트가 메시지 배달을 위한 최소 비용 라우팅 경로에 있을 때는 메시지는 최종 대상으로 릴레이되기 전에 허브 사이트의 허브 전송 서버에 의해 대기 및 처리됩니다.

최소 비용 라우팅 경로를 선택하면 라우팅 과정에서 허브 사이트가 해당 라우팅 경로에 있는지 확인합니다. 허브 사이트가 구성되어 있는 경우 메시지는 대상 위치로 릴레이되기 전에 허브 사이트의 허브 전송 서버에서 중지됩니다. 최소 비용 라우팅 경로에 둘 이상의 허브 사이트가 있으면 메시지는 라우팅 경로의 각 허브 사이트에서 중지됩니다.

이 같은 직접 릴레이 라우팅의 변형은 허브 사이트가 최소 비용 라우팅 경로에 있을 때만 유효합니다. 다음 그림에서는 올바른 허브 사이트 사용법을 보여줍니다. 이 다이어그램에서는 사이트 B가 허브 사이트로 구성되어 있습니다. 사이트 A에서 사이트 D로 릴레이되는 메시지는 먼저 사이트 B로 릴레이된 다음 사이트 D로 릴레이됩니다.

허브 사이트를 사용한 메시지 배달

다음 그림에서는 IP 사이트 링크 비용이 허브 사이트에 대한 라우팅에 어떤 영향을 미치는지 보여줍니다. 이 시나리오에서는 사이트 B가 허브 사이트로 지정되어 있습니다. 그러나 이 사이트는 다른 사이트 간의 최소 비용 라우팅 경로에 있지 않기 때문에 메시지가 대상으로 배달되기 전에 사이트 B에 대기되지 않습니다. Active Directory 사이트는 서로 다른 두 사이트 간의 최소 비용 라우팅 경로에 있지 않으면 허브 사이트로 사용되지 않습니다.

잘못 구성된 허브 사이트

모든 Active Directory 사이트를 허브 사이트로 구성할 수 있습니다. 그러나 이 구성이 제대로 작동하도록 하려면 허브 사이트에 적어도 하나 이상의 허브 전송 서버를 배포해야 합니다.

토폴로지 검색

Exchange 2010 토폴로지는 Active Directory 사이트 토폴로지를 필요로 하며 자체 구성이 없습니다. 다음과 같은 필수 요소가 있어야 Active Directory 토폴로지를 Exchange 2010에서 사용할 수 있습니다.

  • Microsoft ExchangeActive Directory 토폴로지 서비스

  • Microsoft Exchange 전송 서비스 내의 토폴로지 검색 모듈

Microsoft ExchangeActive Directory 토폴로지 서비스는 Edge 전송 서버 역할을 제외한 모든 Exchange 2010 서버 역할에서 실행됩니다. 이러한 Exchange 2010 서버는 Microsoft ExchangeActive Directory 토폴로지 서비스를 사용하여 Exchange 서버가 Active Directory 데이터를 읽고 쓰는 데 사용할 수 있는 글로벌 카탈로그 서버 및 도메인 컨트롤러를 검색합니다. Exchange 2010은 Exchange에서 Active Directory에 대한 읽기 또는 쓰기 작업을 수행해야 할 때마다 확인된 디렉터리 서버에 바인딩됩니다.

MicrosoftExchange 전송 서비스의 일부인 토폴로지 검색 모듈은 Active Directory 토폴로지에 대한 정보를 Exchange 서버에 제공합니다. 이 API는 조직에서 Exchange 서버 및 역할을 검색하며 Active Directory 구성 개체에 대한 각 항목의 관계를 결정합니다. 구성 데이터는 Active Directory에서 검색되어 해당 컴퓨터에서 실행 중인 Exchange 서비스에서 액세스할 수 있도록 캐시됩니다.

토폴로지 검색 모듈은 다음 단계를 수행하여 Exchange 라우팅 토폴로지를 생성합니다.

  1. Active Directory에서 데이터를 읽습니다. 다음 개체가 모두 검색됩니다.

    • Active Directory 사이트

    • IP 사이트 링크

    • 모든 Exchange 서버 여기에는 이러한 서버에 배포되는 Exchange 2010 서버 역할에 대한 정보가 포함됩니다.

  2. 1단계에서 검색된 데이터는 초기 토폴로지를 만들고 관련 구성 개체를 연결 및 매핑하는 데 사용됩니다.

  3. Active Directory에 저장된 Exchange 서버 개체에서 사이트 특성 값을 검색하여 Exchange 서버를 Active Directory 사이트에 일치시킵니다.

  4. 검색된 정보 모음으로 라우팅 테이블을 업데이트합니다.

이 프로세스를 통해 모든 Exchange 2010 서버는 조직의 다른 Exchange 서버를 인식하고 또 각 Exchange 서버 간의 거리가 어느 정도 가까운지 인식할 수 있게 됩니다.

맨 위로 이동

Exchange 2010 라우팅 테이블

MicrosoftExchange Transport Service는 시작 시 Active Directory 또는 Edge 전송 서버의 AD LDS에서 검색된 정보 스냅숏을 기반으로 하는 라우팅 테이블 집합을 계산합니다. AD LDS에 저장된 구성 정보에는 사용 가능한 커넥터 및 허용 도메인은 포함되지만 토폴로지 데이터는 포함되지 않습니다.

라우팅 구성 요소는 라우팅 테이블을 참조하여 메시지를 받는 사람에게 라우팅하는 방법을 결정합니다. 구성이 변경되면 라우팅 테이블은 다시 작성됩니다. 그러면 새 라우팅 테이블이 새로 받는 메시지를 라우팅하는 데 사용됩니다. 라우팅 구성 요소에 구성 변경 내용이 적용되면 원격 배달 큐에 있는 메시지도 다시 라우팅됩니다. 메시지 다시 라우팅에 대한 자세한 내용은 이 항목 뒷부분의 "다시 라우팅 및 연결할 수 없는 큐"를 참조하십시오.

Active Directory에서 검색되어 허브 전송 서버의 라우팅 구성 요소에서 사용할 수 있는 구성 데이터는 다음과 같습니다.

  • Active Directory 사이트

  • Active Directory IP 사이트 링크

  • Exchange 서버 및 Active Directory 사이트에 대한 해당 서버의 관계

  • SMTP 커넥터

  • 비 SMTP 커넥터

    참고

    비 SMTP 커넥터에는 Exchange 2010 배달 에이전트 커넥터, 외부 커넥터 및 함께 사용 시나리오에서 Exchange 2003이 호스트하는 모든 비 SMTP 커넥터가 포함됩니다.

  • 라우팅 그룹

  • 라우팅 그룹 커넥터

  • 사서함 저장소(개인 MDB(메시지 데이터베이스))

  • 공용 폴더 저장소(공용 MDB)

  • 공용 폴더 계층

이 데이터를 기반으로 MicrosoftExchange 전송 서비스의 라우팅 구성 요소가 라우팅 테이블을 채워 라우팅 결정을 효율적으로 수행할 수 있도록 합니다. 라우팅 테이블은 토폴로지 맵을 만드는 데 사용되는 데이터와 연관됩니다. 이 토폴로지 맵에는 다음 요소가 포함됩니다.

  • 연결된 커넥터 맵   이 맵은 로컬 서버의 수신 커넥터 식별자를 연결된 송신 커넥터와 연관시킵니다.

  • 서버 맵   조직의 모든 Exchange 2010 및 Exchange 2007 허브 전송 서버, Edge 전송 서버, 사서함 서버 및 Exchange 2003 서버가 서버 맵에 포함됩니다. 이 맵은 각 Exchange 서버의 고유 이름을 서버 라우팅 데이터에 연관시킵니다. 해당 서버에 도달하는 총 순위가 여기에 포함됩니다.

  • 레거시 서버 맵   조직의 모든 Exchange Server 2007 허브 전송 서버, Edge 전송 서버, 사서함 서버 및 Exchange 2003 서버가 레거시 서버 맵에 포함됩니다. 이 맵은 각 Exchange 서버의 레거시 고유 이름을 서버 라우팅 데이터에 연관시킵니다. 해당 서버에 도달하는 전체 순위가 여기에 포함됩니다. 이 맵에서는 저장소 대체 기능이 지원됩니다. 저장소 대체 기능은 공용 폴더에만 사용할 수 있습니다. 자세한 내용은 내부 메시지 라우팅에서 "공용 폴더에 대한 라우팅"를 참조하십시오.

  • MDB 맵   조직의 모든 MDB가 MDB 맵에 포함됩니다. 이 맵은 각 MDB의 고유 이름을 서버 라우팅 데이터에 연관시킵니다. 해당 서버에 도달하는 전체 순위가 여기에 포함됩니다.

  • Active Directory 사이트 맵   이 맵은 각 Active Directory 사이트를 로컬 사이트에서 다른 모든 사이트로의 최소 비용 라우팅 경로를 포함하는 구조에 연관시킵니다. 이 맵에는 최소 비용 라우팅 경로에 있는 모든 허브 사이트가 포함됩니다. 각 라우팅 경로 홉도 향상된 DNS 구성 요소에서 사용될 해당 사이트의 모든 허브 전송 서버를 표시합니다.

  • 라우팅 그룹 맵   이 맵은 Exchange 2010 라우팅 그룹에서 각 레거시 라우팅 그룹으로의 최소 비용 라우팅 경로에 대해 전체 비용과 첫 번째 홉 라우팅 그룹 커넥터를 연결합니다.

  • 송신 커넥터 맵   이 맵은 조직에 구성되어 있는 송신 커넥터와 각 커넥터의 원본 서버를 식별합니다.

라우팅 테이블은 전송 서버가 시작된 다음 구성 변경 내용을 받아 다시 계산될 때마다 작성됩니다. 구성 변경 내용은 다음 방식으로 검색할 수 있습니다.

  • Active Directory 변경 알림   알림을 받는 시간과 변경 내용이 라우팅 테이블에 기록되는 시간 사이에는 지연 시간이 있습니다. 이 지연 시간 동안 라우팅 구성 요소는 변경 내용을 일괄 처리하고 단일 작업으로 여러 변경 내용을 처리할 수 있습니다. 기본적으로 각 알림은 라우팅 구성 요소의 처리 작업을 5초 동안 지연시킵니다. 예를 들어, 정확히 1초 간격으로 5개의 알림을 받는 경우 라우팅 과정에서 총 9초 동안 변경 내용 처리가 지연됩니다.

  • 서비스 제어 명령에 의한 구성 다시 로드 라우팅 구성 요소는 Microsoft Exchange 전송 서비스가 다시 시작되면 구성 데이터를 다시 로드합니다.

  • Active Directory 알림에서 지원하지 않는 변경 내용을 추적하기 위해 주기적으로 다시 로드   기본적으로 라우팅 과정에서는 모든 변경 내용을 추적할 수 있도록 주기적으로 구성 데이터가 다시 로드됩니다. 구성은 6시간 간격으로 다시 로드됩니다.

라우팅 테이블의 정보는 라우팅 로그에 로깅됩니다. 기본적으로 이러한 로그는 C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\Routing 폴더에 있습니다. 라우팅 테이블이 계산될 때마다 새 로그가 생성됩니다. 허브 전송 서버가 Active Directory에 연결할 수 없는 경우에도 라우팅은 현재 캐시된 데이터를 기반으로 하여 라우팅 결정 작업을 계속합니다. 이는 데이터가 최신 상태가 아닌 경우에도 적용됩니다. 자세한 내용은 라우팅 테이블 로깅 이해를 참조하십시오.

맨 위로 이동

라우팅을 위한 메시지 받기

메시지는 다음 중 한 가지 방법으로 허브 전송 서버에 도착할 수 있습니다.

  • Exchange 조직의 받는 사람 또는 내부 릴레이 허용 도메인의 받는 사람에게 배달하기 위해 인터넷 연결 SMTP 서버로부터 전자 메일을 받습니다.

  • 해당 Active Directory 사이트의 사서함 서버에 있는 받는 사람 사서함에 배달하기 위해 Exchange 조직의 다른 허브 전송 서버로부터 전자 메일을 받습니다.

  • SMTP 클라이언트로부터 전자 메일을 받습니다. 이 SMTP 클라이언트는 일반적으로 해당 환경에 있는 POP3 또는 IMAP4 사용자입니다.

  • 허브 전송 서버의 Pickup 디렉터리 및 Replay 디렉터리로부터 전자 메일을 받습니다. 이들 디렉터리는 Exchange 인프라에 메시지를 전송하기 위해 주로 외부 커넥터에서 사용합니다.

  • 허브 전송 서버가 Exchange 2010 사서함 서버에서 전자 메일을 검색합니다.

  • Exchange 2010 사서함 서버에 있는 받는 사서함에 배달하기 위해 Exchange 2007 또는 Exchange 2003 서버로부터 전자 메일을 받습니다.

분류를 위해 허브 전송 서버가 받은 모든 전자 메일의 처리는 전송 큐에서 시작됩니다.

Edge 전송 서버, 다른 Exchange 허브 전송 서버 및 SMTP 클라이언트로부터 메시지 받기

이 시나리오에서는 표준 SMTP 연결을 사용하여 Edge 전송 서버, 허브 전송 서버 또는 타사 SMTP 호스트로부터 메시지를 받습니다. 원격 호스트는 SMTP 연결을 시작하고 허브 전송 서버로 메시지를 전송합니다. 허브 전송 서버는 들어오는 SMTP 연결을 수락하기 위해 수신 커넥터를 사용합니다. 각 허브 전송 서버에는 설치 중에 만들어진 수신 커넥터가 두 개 있습니다. 이들 커넥터 중 하나는 다른 Exchange 서버로부터 인증된 SMTP 연결을 받는 데 사용되고, 나머지 하나는 조직의 POP3 또는 IMAP4 사용자에 의해 사용되는 SMTP 클라이언트로부터 SMTP 연결을 받는 데 사용됩니다. 이 두 개의 수신 커넥터는 각자의 용도에 적합하도록 구성된 서로 다른 사용 권한을 가집니다. 수신 커넥터에 대한 자세한 내용은 수신 커넥터 이해를 참조하십시오.

기본적으로 허브 전송 서버는 인증되지 않은 익명 연결을 수락하지 않습니다. 이 기능을 사용하려면 익명 연결을 처리할 별도의 수신 커넥터를 만드는 것이 좋습니다. 자세한 내용은 수신 커넥터에서 익명 릴레이 허용를 참조하십시오.

Pickup 및 Replay 디렉터리에서 메시지 수집

전송 프로토콜로 SMTP를 사용하지 않는 메시징 시스템은 외부 커넥터를 사용하여 Exchange 조직에 연결할 수 있습니다. 메시지가 원격 시스템으로부터 Exchange 사용자에게 보내지면 외부 커넥터는 Pickup 디렉터리라는 허브 전송 서버의 특별 디렉터리에 이 메시지를 씁니다. 허브 전송 서버는 새 메시지의 Pickup 디렉터리에서 새 메시지를 정기적으로 확인합니다. 새 메시지가 검색되면 허브 전송 서버는 새 메시지를 Exchange 전자 메일 메시지로 변환하고 일반 메시지처럼 라우팅합니다. Pickup 및 Replay 디렉터리의 사용 방법에 대한 자세한 내용은 Pickup 및 Replay 디렉터리 이해를 참조하십시오.

사서함 서버에서 메시지 검색

이 시나리오에서는 사서함 서버에서 실행되는 Microsoft Exchange 메일 전송 서비스가 동일한 Active Directory 사이트에 있는 허브 전송 서버에 보낸 사람의 보낸 편지함에서 메시지를 검색할 준비가 되었음을 알립니다. 각 사서함 서버는 동일한 Active Directory 사이트에 있는 허브 전송 서버의 목록을 유지 관리합니다. 이 허브 전송 서버 목록을 전송 서버 목록이라고 합니다. 서버 검색 프로세스는 목록을 최신 상태로 유지하기 위해 10분마다 반복됩니다.

메일을 검색할 준비가 되었다는 알림을 전송하는 사서함 서버와 동일한 Active Directory 사이트에 둘 이상의 허브 전송 서버가 있으면 다음 프로세스를 사용하여 서버를 선택합니다.

  • 로컬 사서함 서버에서도 허브 전송 서버 역할을 실행 중이고 DAG(데이터베이스 가용성 그룹)에 참여하고 있지 않으면 로컬 서버에 알립니다. 로컬 Microsoft Exchange Transport Service가 실행 중이 아니거나 리소스 조정으로 인해 로컬 허브 전송 서버에서 새 메일 전송을 처리할 수 없는 경우에는 사용 가능한 다른 허브 전송 서버에 알립니다. 리소스 조정에 대한 자세한 내용은 역 압력의 이해를 참조하십시오.

  • 로컬 사서함 서버에서도 허브 전송 서버 역할을 실행 중이고 DAG에도 참여하고 있으면 로컬 허브 전송 서버에 알리기 전에 사이트의 허브 전송 서버에 먼저 알립니다. 이렇게 하면 동일한 서버 하드웨어에 중복된 메시지 복사본이 생성되는 것을 방지할 수 있습니다. DAG 사용 시 사서함 및 허브 전송 서버 역할의 동시 사용에 대한 자세한 내용은 DAG를 사용할 때 허브 전송 및 사서함 서버 역할 동시 사용을 참조하십시오.

  • 로컬 사서함 서버에서 허브 전송 서버 역할을 실행하고 있지 않으면 라운드 로빈을 사용하여 허브 전송 서버 간에 알림 부하가 분산됩니다.

  • 선택한 허브 전송 서버에 연결할 수 없는 경우 Microsoft Exchange 메일 전송 서비스는 동일한 Active Directory 사이트에 있는 다른 허브 전송 서버로 장애 조치됩니다. 실패한 서버가 비활성으로 표시되고, 전송 서버 목록의 다음 허브 전송 서버가 선택됩니다. 로컬 Active Directory 사이트의 허브 전송 서버를 사용할 수 없는 경우 전송 서버 목록이 비어 있습니다. 이 경우 이벤트가 로깅되고 메일 전송 알림이 일시적으로 중지됩니다. 비활성으로 표시된 허브 전송 서버가 5분 후에 다시 시도됩니다.

기본적으로 Microsoft Exchange 메일 전송 서비스는 사이트의 허브 전송 서버 간에 알림 이벤트의 부하를 분산하므로 각 허브 전송 서버는 처리할 알림 이벤트를 동일하게 받습니다. 경우에 따라 동일하게 배포하는 것이 최적의 솔루션이 아닐 수도 있습니다. 모든 허브 전송 서버의 용량이 동일한 것은 아니므로 일부 메시지에는 추가 처리가 필요할 수 있습니다. 예를 들어, 허브 전송 서버에서 큰 첨부 파일이 있거나 받는 사람이 많은 메시지를 처리하는 시간은 받는 사람이 한 명뿐인 작은 메시지를 처리하는 시간보다 더 오래 걸립니다. 사서함 서버에서 알려야 할 허브 전송 서버의 고정 목록을 만들려는 경우 셸에서 Set-MailboxServer cmdlet을 사용할 수 있습니다. SubmissionServerOverrideList 매개 변수를 사용하여 로컬 사서함 서버에 검색할 메일이 있는 경우 알릴 허브 전송 서버의 목록을 지정합니다. 이 설정을 구성하는 방법에 대한 자세한 내용은 Set-MailboxServer를 참조하십시오.

허브 전송 서버는 사서함 서버로부터 메일 전송 알림을 받으면 저장소 드라이버를 사용하여 사서함 데이터베이스에서 메시지를 검색하고 허브 전송 서버의 전송 큐에 검색한 메시지를 넣습니다. 사서함 서버에서 허브 전송 서버로의 메시지가 전송은 Exchange RPC를 사용하여 수행됩니다.

레거시 Exchange 서버에서 메시지 받기

Exchange 2010의 XSO(Exchange 서버 개체) 모델 변경 사항으로 인해 Exchange 2010 허브 전송 서버는 Exchange 2007 사서함 서버에서 메시지를 선택하고 메시지를 배달할 수 없습니다. 마찬가지로 Exchange 2007 허브 전송 서버는 Exchange 2010 사서함 서버와 통신할 수 없습니다. Exchange 2007 받는 사람이 보낸 모든 메시지는 먼저 Exchange 2007 허브 전송 서버에 의해 사서함 서버로부터 선택된 후 Exchange 2010 허브 전송 서버로 릴레이됩니다. Exchange 2007을 함께 사용할 때 메시지 라우팅에 대한 자세한 내용은 Exchange 2007 전송에서 업그레이드를 참조하십시오.

Active Directory 사이트와 달리 Exchange 2003은 라우팅 그룹을 사용하여 메시지를 라우팅합니다. 라우팅 그룹은 라우팅 그룹 커넥터를 사용하여 서로 연결됩니다. 이러한 두 개의 라우팅 토폴로지 간에 함께 사용을 지원하기 위해, Exchange 2003 조직에 Exchange 2010을 설치할 때 모든 Exchange 2010 서버가 단일 라우팅 그룹에 자동으로 추가됩니다. Exchange 2003 사서함에서 보낸 모든 메시지는 Exchange 2010 라우팅 그룹과 Exchange 2003 라우팅 그룹 간의 라우팅 그룹 커넥터를 통해 Exchange 2010 환경으로 배달됩니다. Exchange 2003을 함께 사용할 때 메시지 라우팅에 대한 자세한 내용은 Exchange 2003 전송에서 업그레이드를 참조하십시오.

맨 위로 이동

메시지 라우팅

허브 전송 서버 또는 Edge 전송 서버는 메시지를 받은 후 최종 대상을 확인하고 Exchange 토폴로지 및 커넥터 구성을 사용하여 최소 비용 라우팅 경로를 결정합니다. 라우팅 경로가 결정되면 메시지는 라우팅 경로의 다음 홉으로 배달됩니다.

이 항목에서는 Exchange에서 라우팅 결정을 내리는 방법을 개괄적으로 설명하지만 다음 두 항목은 특정 라우팅 시나리오에 대한 추가 정보를 제공합니다. 내부 메시지 라우팅 항목에서는 사서함 서버, 공용 폴더 및 레거시 서버로의 메시지 배달에 대해 소개합니다. 외부 메시지 라우팅 항목에서는 Exchange 조직 외부의 받는 사람에게 메시지를 라우팅하는 것에 대해 소개하고, 송신 커넥터, 배달 에이전트 커넥터 및 외부 커넥터의 역할에 대해서도 함께 설명합니다.

최종 대상 결정

앞 섹션에서는 허브 전송 서버가 메시지를 받을 수 있는 다양한 원본에 대해 설명했습니다. 허브 전송 서버가 메시지를 받을 때 해당 메시지가 분류되어야 합니다. 메시지 분류의 첫 단계는 받는 사람 확인입니다. 받는 사람을 확인하고 나면 최종 대상을 결정할 수 있습니다. 다음 단계인 라우팅에서는 가장 효율적으로 해당 대상에 도달하는 방법을 결정합니다. 이 단계에서는 결정적인 하나의 경로를 선택합니다. 라우팅 구성이 변경되는 경우가 아니면 이 경로는 다시 계산되지 않습니다.

보내는 서버의 측면에서 볼 때 각 배달 큐는 특정 메시지의 대상을 나타냅니다. 허브 전송 서버 또는 Edge 전송 서버에서 메시지의 대상을 선택하면 해당 대상은 받는 사람에 대해 NextHopSolutionKey 특성으로 스탬프 처리됩니다. 하나의 메시지를 여러 받는 사람에게 보내는 경우 각 받는 사람에게 NextHopSolutionKey 특성이 적용됩니다. 받는 서버에서도 메시지 분류를 수행하고 메시지를 배달용으로 대기시킵니다. 메시지가 대기 상태가 되고 나면 특정 큐의 배달 유형을 확인하여 해당 메시지가 다음 홉 대상에 도달했을 때 다시 릴레이할 것인지를 결정할 수 있습니다.

메시지의 대상은 다음 배달 유형 중 하나로 분류될 수 있습니다.

  • DNS 커넥터 배달   로컬 서버가 원본 서버인 SMTP 송신 커넥터를 사용하여 외부 받는 사람에게 배달되도록 대기 중인 메시지의 배달 유형입니다. 이 커넥터는 DNS를 사용하여 받는 사람 주소를 확인하도록 구성됩니다.

  • 스마트 호스트 커넥터 배달   로컬 서버가 원본 서버인 SMTP 송신 커넥터를 사용하여 외부 받는 사람에게 배달되도록 대기 중인 메시지의 배달 유형입니다. 커넥터는 배달에 스마트 호스트를 사용하도록 구성됩니다.

  • Edge 전송 서버에 대한 Active Directory 사이트의 SMTP 릴레이   로컬 Active Directory 사이트에 구독된 Edge 전송 서버가 원본 서버인 SMTP 송신 커넥터를 사용하여 외부 받는 사람에게 배달되도록 대기 중인 메시지의 배달 유형입니다.

  • 허브 전송 서버에 대한 Active Directory 사이트의 SMTP 릴레이   로컬 서버와 동일한 Active Directory 사이트에 있는 허브 전송 서버로 배달되도록 대기 중인 메시지의 배달 유형입니다. 대상 서버는 Exchange 2007 허브 전송 서버, 송신 커넥터의 원본 서버, 배달 에이전트 커넥터 또는 외부 커넥터, 라우팅 그룹 커넥터의 원본 서버 또는 메일 그룹 확장 서버 중 하나일 수 있습니다.

  • 원격 Active Directory 사이트에 대한 SMTP 릴레이   원격 Active Directory 사이트에 있는 허브 전송 서버로 배달되도록 대기 중인 메시지의 배달 유형입니다. 원격 Active Directory 사이트의 최종 대상 서버는 다음 중 하나일 수 있습니다.

    • 외부 받는 사람에게 메시지를 전송하도록 구성된 커넥터의 원본 서버

    • 라우팅 그룹 커넥터의 원본 서버

    • 메일 그룹 확장 서버

    • 원격 Active Directory 사이트에 있는 사서함 서버

    메시지는 대상 사이트에 있는 허브 전송 서버 중 하나로 배달됩니다. 받는 서버는 필요한 경우 Active Directory 사이트 내에서 메시지를 릴레이합니다.

  • 레거시 라우팅 그룹에 대한 SMTP 릴레이   Exchange 2003 라우팅 그룹에 도달하기 위해 사용한 첫 번째 홉 라우팅 그룹 커넥터로 배달되도록 대기 중인 메시지의 배달 유형입니다. 최종 대상 서버는 다음 중 하나일 수 있습니다.

    • 커넥터의 원본 서버

    • 확장 서버

    • 라우팅 그룹의 사서함 받는 사람으로 주소가 지정된 메시지를 배달하는 Exchange 2003 브리지헤드 서버

  • MAPI 배달 로컬 Active Directory 사이트의 사서함 서버에 있는 공용 폴더 저장소, 공용 폴더 또는 받는 사람의 사서함으로 배달되도록 대기 중인 메시지의 배달 유형입니다.

  • 비 SMTP 게이트웨이 배달   로컬 서버가 원본 서버인 배달 에이전트 커넥터 또는 외부 커넥터를 사용하여 외부 받는 사람에게 배달되도록 대기 중인 메시지의 배달 유형입니다. 이 배달 유형은 메시지를 로컬 서버의 배달 에이전트 커넥터 또는 외부 커넥터 Drop 디렉터리로 배달하는 경우에만 사용합니다.

  • 연결할 수 없음 받는 사람에 대한 경로를 찾을 수 없고 메시지가 연결할 수 없는 큐에 있는 경우입니다.

최소 비용 라우팅 경로 결정

원격 Active Directory 사이트에 대한 최소 비용 라우팅 경로는 두 사이트 사이에 있는 Active Directory IP 사이트 링크에 할당된 모든 비용을 계산하여 결정됩니다. 이 링크는 브리지되며, 직접 연결됩니다. Exchange 2010 허브 전송 서버는 항상 최소 비용의 결정적 단일 라우팅 경로를 선택합니다. 라우팅 경로를 선택할 때 기존 연결 또는 대상 서버의 가용성은 전혀 고려되지 않으며, 대체 라우팅 경로도 고려되지 않습니다.

최소 비용 라우팅 경로 계산은 다음 홉으로 메시지를 배달하지 못한 경우 백오프 경로를 결정하는 데 사용됩니다. Exchange 2010에서 백오프는 네트워크 문제 또는 서버 오프라인 상태와 같은 이유로 직접 릴레이에 실패하는 경우 최소 비용 라우팅 경로의 중간 홉에서 메시지를 배달하는 데 사용되는 메커니즘입니다. 라우팅 구성 요소는 연결이 될 때까지 최소 순위 라우팅 경로를 따라 홉 바이 홉으로 백오프를 수행하여 가능한 한 대상에 가까이 메시지를 전달합니다. 먼저 대상 Active Directory 사이트에 있는 각 허브 전송 서버에 대한 연결이 시도됩니다. Active Directory 사이트에 있는 허브 전송 서버가 응답하지 않으면 배달 사이트에서 어떤 방법으로 백오프를 시작할지 결정하기 위해 최소 비용 라우팅 경로를 확인합니다. 이 작업은 가능한 한 대상에 가까이 메시지를 배달하고 해당 Active Directory 사이트의 허브 전송 서버에 메시지를 대기시키기 위해 수행합니다.

개별 메시지 라우팅 시나리오에 따라, 최소 비용 라우팅 경로 선택에 영향을 줄 수 있는 요인은 다음과 같습니다.

  • 연결된 커넥터   메시지를 받는 수신 커넥터가 송신 커넥터에 연결되어 있는 경우 메시지는 순위에 관계없이 해당 송신 커넥터로 라우팅됩니다. 이 구성은 항상 우선적으로 적용됩니다.

  • 대상에 도달하기 위해 통과해야 하는 IP 사이트 링크 및 라우팅 그룹 커넥터에 할당된 순위 원본 서버와 대상 서버 간에 라우팅 경로가 여러 개 있는 경우 집계 순위가 가장 낮은 라우팅 경로가 선택됩니다.

  • 송신 커넥터에 할당된 주소 공간   대상에 일치하는 가장 구체적인 주소 공간이 할당되어 있는 송신 커넥터가 선택됩니다.

  • 송신 커넥터에 구성되어 있는 주소 공간에 할당된 순위 같은 주소 공간에 여러 개의 송신 커넥터가 할당되어 있는 경우 라우팅 구성 요소는 주소 공간에 할당된 순위를 비교합니다. 그런 다음 순위가 가장 낮은 송신 커넥터가 선택됩니다.

  • 커넥터 범위   커넥터는 자신의 원본 전송 서버와 동일한 Active Directory 사이트에 있는 Exchange 2010 서버에서만 사용되도록 제한될 수 있습니다. 이전 버전의 Exchange에서는 커넥터 범위를 동일한 라우팅 그룹 구성원이 있는 서버로 제한할 수 있었습니다.

  • 메시지 크기 제한   커넥터에 대해 지정된 메시지 크기 제한이 라우팅 중인 메시지의 크기보다 커야 합니다. 커넥터에 적용된 메시지 크기 제한이 실제 메시지 크기보다 작은 경우 해당 커넥터는 라우팅 과정에서 고려되지 않습니다.

  • 보내는 서버에 대한 대상의 근접성   라우팅에서는 로컬 서버, 동일한 Active Directory 사이트에 있는 서버, 원격 Active Directory 사이트 또는 라우팅 그룹에 있는 서버의 순서로 가장 가까운 서버가 우선 사용됩니다.

  • Active Directory 사이트에 할당된 이름 여러 개의 라우팅 경로에 지정된 집계 순위가 같은 경우 라우팅 구성 요소는 각 라우팅 경로에 있는 대상 사이트 앞에 오는 Active Directory 사이트의 이름을 영숫자순으로 비교합니다. 그런 다음 대상에 가장 가까운 Active Directory 사이트가 영숫자순으로 가장 낮은 순위인 라우팅 경로가 사용됩니다.

  • 라우팅 그룹 커넥터에 할당된 이름   여러 개의 라우팅 경로에 지정된 집계 순위가 같은 경우 라우팅 구성 요소는 각 라우팅 경로에 있는 대상 앞에 오는 라우팅 그룹 커넥터의 이름을 영숫자순으로 비교합니다. 그런 다음 대상에 가장 가까운 라우팅 그룹 커넥터가 영숫자순으로 가장 낮은 순위인 라우팅 경로가 사용됩니다.

  • 커넥터 상태   Exchange 2010 라우팅 구성 요소는 라우팅 경로를 계산할 때 사용하도록 설정된 커넥터만을 고려합니다. 그러나 이전 버전의 Exchange는 커넥터 상태를 고려하지 않습니다.

라우팅 경로를 선택하는 데 사용되는 논리는 다음과 같습니다.

  1. 먼저 IP 사이트 링크의 비용과 대상에 도달하기 위해 통과해야 하는 모든 라우팅 그룹 커넥터의 비용을 합하여 최소 비용 라우팅 경로를 계산합니다. 대상이 커넥터인 경우 주소 공간에 할당된 순위가 선택한 커넥터에 도달하기 위한 순위에 더해집니다. 사용 가능한 라우팅 경로가 여러 개인 경우 집계 순위가 가장 낮은 라우팅 경로만 사용됩니다.

  2. 집계 순위가 같은 여러 라우팅 경로가 있는 경우에는 각 경로의 홉 수를 평가하여 홉 수가 가장 적은 라우팅 경로가 사용됩니다.

  3. 여러 개의 라우팅 경로를 사용할 수 있는 경우에는 대상 앞의 Active Directory 사이트 또는 라우팅 그룹 커넥터에 지정된 이름이 고려됩니다. 그런 다음 대상에 가장 가까운 Active Directory 사이트가 영숫자순으로 가장 낮은 순위인 라우팅 경로가 사용됩니다. 대상에 가장 가까운 사이트가 평가 중인 모든 라우팅 경로에서 동일한 경우에는 이전 사이트 이름을 검토합니다.

아래 그림에서는 Exchange 조직의 라우팅 토폴로지를 보여줍니다. 이 토폴로지를 통해 다음 예에서 라우팅 알고리즘이 최소 비용 라우팅 경로를 선택하는 데 사용되는 논리를 설명합니다.

2010 Exchange 라우팅 토폴로지

예 1   사이트 A에서 사이트 D로 릴레이되고 있는 메시지는 사이트 A-사이트 B-사이트 D와 사이트 A-사이트 C-사이트 D의 두 가지 라우팅 경로 중 하나를 선택할 수 있습니다. 각 라우팅 경로의 IP 사이트 링크에 할당된 비용을 더하여 메시지를 라우팅하는 데 필요한 전체 비용을 결정합니다. 이 예제에서 사이트 A-사이트 B-사이트 D 라우팅 경로의 집계 순위는 20이고, 사이트 A-사이트 C-사이트 D 라우팅 경로의 집계 순위는 10입니다. 따라서 라우팅 과정에서 사이트 A-사이트 C-사이트 D 경로가 선택됩니다.

예제 2   사이트 B에서 사이트 D로 릴레이되고 있는 메시지는 사이트 B-사이트 D(비용 15), 사이트 B-사이트 E-사이트 C-사이트 D(비용 15), 사이트 B-사이트 A-사이트 C-사이트 D(비용 15)의 세 가지 라우팅 경로 중 하나를 선택할 수 있습니다. 둘 이상의 라우팅 경로의 비용이 동일하기 때문에 라우팅 과정에서는 홉 수가 가장 적은 사이트 B-사이트 D 라우팅 경로가 선택됩니다.

예제 3   사이트 A에서 사이트 E로 릴레이되는 메시지의 경우 사이트 A-사이트 B-사이트 E(비용 10)와 사이트 A-사이트 C-사이트 E(비용 10)의 두 가지 라우팅 경로 중 하나를 선택할 수 있습니다. 두 라우팅 경로의 비용과 홉 수가 모두 같으므로 사이트 E 바로 앞에 오는 Active Directory 사이트 이름을 영숫자순으로 비교합니다. 사이트 B의 영숫자가 사이트 C보다 낮으므로 라우팅 과정에서는 사이트 A-사이트 B-사이트 E 라우팅 경로가 선택됩니다.

최소 비용 라우팅 경로를 결정하고 나면 Exchange 2010 라우팅 구성 요소는 대체 라우팅 경로를 고려하지 않습니다.

다음 홉 선택

Exchange 2010 허브 전송 서버는 최소 비용 라우팅 경로에 있는 각 Active Directory 사이트로 릴레이하지 않습니다. 라우팅 경로가 결정되고 나면 메시지는 원본 서버에서 다음 홉으로 직접 릴레이됩니다. 다음 홉 선택에서는 최종 대상과 최대한 가까운 위치로 메시지를 배달하려고 합니다. 최종 대상에 도달하려면 사이트 간 릴레이를 추가로 수행해야 할 수 있습니다. 레거시 라우팅 그룹으로 라우팅할 때는 첫 번째 홉 라우팅 그룹 커넥터의 원본 서버가 있는 Active Directory 사이트에 대한 직접 릴레이가 수행됩니다. 메시지가 레거시 환경으로 릴레이되고 나면 표준 레거시 라우팅이 수행됩니다.

다음 그림에서는 간단한 Exchange 토폴로지와 여러 Exchange 라우팅 구성 요소를 보여줍니다.

Exchange 토폴로지 및 라우팅 구성 요소

위 그림을 참조하면 사이트 A의 Mailbox1에서 외부 받는 사람인 joe@contoso.com에 보내는 메시지가 다음과 같이 처리됩니다.

  1. Mailbox1에서 실행되는 Microsoft Exchange 사서함 전송 서비스가 전송할 새 메일 항목과 동일한 Active Directory 사이트에 있는 Exchange 2010 허브 전송 서버로 알림을 보냅니다.

  2. 동일한 Active Directory 사이트에 있는 Exchange 2010 허브 전송 서버의 저장소 드라이버 구성 요소가 RPC를 사용하여 메시지를 검색한 다음 로컬 서버의 전송 큐에 넣습니다.

  3. 메시지가 분류를 통해 전송 큐에서 이동합니다. 분류기는 먼저 받는 사람 확인을 수행한 다음 joe@contoso.com이 외부 받는 사람임을 확인합니다.

  4. 라우팅 구성 요소가 메시지를 가장 효율적으로 라우팅할 커넥터를 선택하고 해당 커넥터에 대한 최소 비용 라우팅 경로를 계산합니다. 이 예제에서는 송신 커넥터가 라우팅 구성 요소에 의해 선택된 커넥터이며 *.contoso.com이라는 주소 공간을 가집니다. 이 송신 커넥터의 모든 원본 서버는 사이트 B에 있습니다.

  5. 라우팅 구성 요소가 송신 커넥터의 원본 서버에 도달하는 데 필요한 다음 홉을 결정합니다. 사이트 A의 허브 전송 서버가 사이트 B로의 SMTP 배달을 위해 메시지를 대기시킵니다.

  6. 사이트 B의 받는 서버가 송신 커넥터의 원본 서버인 경우 해당 받는 서버는 해당 송신 커넥터로의 배달을 위해 메시지를 대기시킵니다. 받는 서버가 *.contoso.com 송신 커넥터의 원본 서버가 아니면 메시지는 SMTP를 사용하여 커넥터의 원본 서버인 사이트 B의 허브 전송 서버로 릴레이됩니다.

다음 표에서는 위 그림에 나와 있는 토폴로지를 기반으로 여러 받는 사람에 대한 다음 홉 선택의 예를 추가로 제공합니다. 이 표는 모든 라우팅 가능성에 대한 완전한 목록이 아니며, 위 그림에 나와 있는 것과 같이 토폴로지에서 가장 일반적인 예를 간단하게 소개합니다.

위 그림에서 다음 홉 선택의 예

받는 서버 최종 대상 다음 홉 큐 배달 유형

Hub1

Mailbox1

Mailbox1

MAPI 배달

Hub1

Mailbox2

Hub3

Active Directory 사이트의 SMTP 릴레이

Hub1

Mailbox3

사이트 B

원격 Active Directory 사이트에 대한 SMTP 릴레이

Hub1

Mailbox4

라우팅 그룹 커넥터

레거시 라우팅 그룹에 대한 SMTP 릴레이

Hub1

Recipient@fourthcoffee.com

Edge1

Edge 전송에 대한 SMTP 릴레이

Hub3

Mailbox1

Hub1 또는 Hub2

Active Directory 사이트의 SMTP 릴레이

Hub4

Mailbox1

사이트 A

원격 Active Directory 사이트에 대한 SMTP 릴레이

Hub4

Mailbox4

사이트 A

원격 Active Directory 사이트에 대한 SMTP 릴레이

Hub4

Recipient@contoso.com

Contoso SMTP 호스트

스마트 호스트 배달

Hub4

Recipient@fourthcoffee.com

사이트 A

원격 Active Directory 사이트에 대한 SMTP 릴레이

Edge1

Recipient@fourthcoffee.com

Fourth Coffee SMTP 호스트

DNS 배달

최소 비용 라우팅 경로를 계산하고 다음 홉 대상을 선택한 후, 허브 사이트가 최소 비용 라우팅 경로를 따라 구성되지 않은 경우에는 Exchange 2010 라우팅 과정에서 메시지를 대상으로 직접 릴레이하려고 시도합니다.

오류 시 큐에 대기

최소 비용 라우팅 경로 계산은 다음 홉으로 메시지를 배달하지 못한 경우 백오프 경로를 결정하는 데 사용됩니다. Exchange 2010은 연결이 될 때까지 최소 비용 라우팅 경로에서 홉 바이 홉으로 백오프를 수행하여 가능한 한 대상에 가까이 메시지 배달을 시도합니다. 이러한 작업을 오류 시 큐에 대기라고 합니다. 통신이 실패한 배달 경로 지점에 메시지가 대기되면 문제가 해결된 후 배달 속도가 빨라질 뿐 아니라 메시지 배달이 실패한 이유를 파악하는 데도 도움이 됩니다.

다음 그림에 나와 있는 토폴로지에서 메시지가 사이트 A에서 사이트 D로 배달 중인 경우, 최소 비용 라우팅 경로는 사이트 A-사이트 B-사이트 C-사이트 D가 될 것입니다. 먼저 사이트 A에서 사이트 D로 직접 배달이 시도됩니다. 사이트 D의 허브 전송 서버가 응답하지 않으면 사이트 C에 있는 허브 전송 서버로 배달이 시도됩니다. 이러한 방식으로 허브 전송 서버가 메시지를 수락할 때까지 프로세스가 계속됩니다. 중간 사이트를 모두 사용할 수 없는 경우에는 메시지가 원본 사이트에 대기됩니다. 메시지가 사이트 C에 대기되는 경우 사이트 D의 허브 전송 서버에서의 실패 또는 사이트 C와 사이트 D 간의 네트워크 연결을 조사할 수 있습니다.

오류 시 큐에 대기

메시지가 실패 지점에 대기되면 큐는 다시 시도 상태가 되고 배달이 성공하거나 메시지가 만료될 때까지 메시지 다시 시도 간격에 따라 배달을 계속 시도합니다. 큐는 기본 간격인 12시간이 지나면 재분류를 위해 자동으로 다시 전송됩니다. 다음 홉 대상으로 커넥터가 지정되어 있는 큐는 다시 전송 작업을 수행하도록 구성이 변경되는 경우가 아니면 자동으로 다시 전송되지 않습니다. 자세한 내용은 메시지 다시 라우팅 및 연결할 수 없는 큐을 참조하십시오.

메일 흐름 문제 해결사를 사용하여 메일 흐름 관련 문제를 진단할 수 있습니다. 이 도구는 MicrosoftExchange Troubleshooting Assistant의 구성 요소이며 Exchange 관리 콘솔의 도구 상자에서 실행할 수 있습니다.

보다 복잡한 토폴로지에서는 두 Active Directory 사이트 간의 최소 비용 라우팅 경로에 중간 Active Directory 사이트가 여러 개 포함될 수 있습니다. 라우팅 경로의 앞부분에서 네트워크 문제가 발생하는 경우, 경로 끝에서부터 사이트 단위로 백오프를 수행하여 각각의 중간 사이트로 메시지를 배달하는 것은 비효율적입니다. 라우팅 경로가 네 개 홉보다 긴 경우에는 네 개 이하의 사이트가 남을 때까지 이진 백오프를 구현합니다. 이진 백오프란 라우팅 경로의 중간 지점에서 다음 연결을 시도하는 것을 말합니다. 예를 들어, Active Directory 사이트 A에서 사이트 G로의 최소 비용 라우팅 경로가 A - B - C - D - E - F - G이고 사이트 B와 사이트 C 간의 링크에서 네트워크 오류가 발생하는 경우 사이트 G의 모든 허브 전송 서버에 첫 번째 연결이 시도됩니다. 이 연결 시도가 실패하면 사이트 A와 G 사이의 중간 지점인 사이트 D의 모든 허브 전송 서버에 다음 연결이 시도됩니다. 이 역시 실패하면 다른 네 링크보다 원본 사이트에 더 가까운 사이트 C와 사이트 B에 대해 연결이 시도됩니다. 결과적으로 메시지는 사이트 B와 C 간의 연결이 복원될 때까지 사이트 B의 허브 전송 서버에 대기됩니다.

지연된 팬아웃

하나의 전자 메일 메시지를 여러 받는 사람에게 보내도록 주소를 지정할 수 있습니다. 이러한 받는 사람은 내부 사서함을 가지고 있을 수도 있고 외부 받는 사람일 수도 있습니다. 단일 메시지를 여러 받는 사람에게 라우팅하기 위해 다음 단계가 수행됩니다.

  1. 받는 사람 확인   배달 대상에 대해 메시지를 받는 사람을 각각 확인합니다.

  2. 라우팅   각 받는 사람에 대한 비용 순위 라우팅 경로가 결정됩니다. 허브 사이트 구성 여부도 여기에 포함됩니다.

  3. 메시지 분할   배달 위치가 서로 다른 여러 받는 사람에게 메시지를 라우팅하려면 메시지를 여러 개의 복사본으로 분할해야 합니다.

각 받는 사람을 확인하고 각 배달 대상에 대한 라우팅 경로를 결정하고 나면 Exchange 2010에서 각 받는 사람에 대한 라우팅 경로를 비교합니다. 대역폭을 절약하기 위해 분기 작업 또는 메시지를 여러 개의 복사본으로 분할하는 작업은 라우팅 경로에서 포크가 발생할 때까지는 수행되지 않습니다.

예를 들어, 하나의 메시지를 받는 여러 사람이 최소 비용 라우팅 경로의 일부 또는 전체를 공유하는 경우 메시지가 포크가 발생하는 라우팅 경로 지점에 도달할 때까지는 메시지의 단일 복사본이 보내집니다. 라우팅 경로에 차이가 발생하면 메시지가 분할되어 각 받는 사람에 대해 별도의 복사본이 만들어집니다.

다음 그림에서는 하나의 메시지가 사이트 A에서 사이트 C, 사이트 D 및 사이트 E에 있는 받는 사람에게 보내집니다. 메시지가 사이트 B에 도달할 때까지는 최소 비용 라우팅 경로가 공유됩니다. 따라서 이 시나리오에서 받는 사람 모두를 포함하는 메시지의 단일 복사본이 사이트 B로 릴레이됩니다. 이는 라우팅 경로의 첫 번째 포크를 나타냅니다. 사이트 B에서는 하나의 메시지 복사본이 사이트 D의 받는 사람에게 라우팅되고, 다른 하나의 복사본이 사이트 C로 릴레이됩니다. 그리고 사이트 C에서 메시지가 다시 분할됩니다. 그런 다음 메시지 복사본이 사이트 C의 받는 사람에게 배달되고, 다른 복사본은 사이트 E로 릴레이되어 해당 사이트의 받는 사람에게 배달됩니다.

지연된 메시지 팬아웃

맨 위로 이동

다시 라우팅 및 연결할 수 없는 큐

라우팅 과정에서 올바른 받는 사람에 대한 경로를 확인할 수 없는 경우 메시지는 연결할 수 없는 큐에 배치됩니다. 이 큐에 있는 메시지는 구성 변경 내용이 처리되고 라우팅 테이블이 다시 계산되면 다시 라우팅됩니다. 다음 시나리오에서는 메시지가 다시 라우팅되는 대신 보낸 사람에게 NDR이 반환됩니다. 결과적으로 메시지는 연결할 수 없는 큐에 라우팅됩니다.

  • 받는 사람이 비 SMTP 주소이고 주소 공간에 일치하는 커넥터를 찾을 수 없는 경우

  • 메시지가 일치하는 커넥터의 메시지 크기 제한을 충족하지 않는 경우

일부 구성 변경의 경우에는 큐의 메시지를 다시 전송하지 않아도 됩니다. 예를 들어, 커넥터의 스마트 호스트 목록을 변경할 경우에는 메시지가 다시 라우팅되지 않습니다. 메시지를 다시 라우팅하는 방법에 대한 자세한 내용은 메시지 다시 라우팅 및 연결할 수 없는 큐를 참조하십시오.

맨 위로 이동

 © 2010 Microsoft Corporation. 모든 권리 보유.