Ex2010 Transport HA part3

자 오늘은 Mailbox submission 에 대해서 다뤄보도록 하겠습니다.

우선, 현재 버전인 Exchange 2007에서는 어떤 식으로 핸들링 했는지를 잠깐 살펴보도록 하겠습니다. 먼저, 아래 그림을 보도록 합시다.

상단은 HUB Server 또는 Hub 모듈이 있고, 하단은 Mailbox Server 입니다. 동작 메커니즘을 설명드리면 다음과 같습니다

1. Mailbox Server에 있는 mail submission 서비스는 Assistant Infrastructure 를 통해서 Store events 관련 notification을 받습니다.

2. Mail submission 서비스는 그 이벤트를 처리할 Hub 서버를 선택하게 됩니다. Hub 서버가 여러대 있을 경우, DNS 라운드 로빈 방식을 사용하게 됩니다.

3. 그림에서 보이는 바와 같이 Mail Submission 서비스에 있는 RPC Client 모듈이 선택된 HUB서버에게 RPC Call을 맺게 되며, 새로운 메시지가 왔다는 이벤트 관련 정보를 넘기게 됩니다.

4. 이젠 Hub Server 로 넘어가면, Hub Server는 이 RPC 호출을 받고, 이벤트와 관련한 정보를 MailitemSubmitter 에게 넘깁니다.

5. MailitemSubmitter 는 XSO 를 이용하여 Store 로부터 직접 메시지를 로드합니다.

6. 그리고 MAPI 형태의 메시지를 MIME 형태로 Convert 합니다.

7. 그런 후에 메시지를 submission queue로 보냅니다

8. MailitemSubmitter는 XSO를 이용하여 STORE에게 “메시지에 대한 처리 완료” 를 알립니다. 그러면, Store는 메시지에 대한 처리가 Hub 서버에서 완료된 것으로 보고, submission folder 에서 Sent items folder 로 메시지를 이동시킵니다.

9. Hub 서버상의 트래킹 로그에 STOREDRIVER RECEIVE를 찍습니다.

10. 위 과정 후에, Mail Submission 서비스는 Mailbox Server 상의 트랙킹 로그에 STOREDRIVER SUBMIT 이벤트를 남깁니다.

그러면, 이 내용이 Exchange 2010에서는 어떤 식으로 변경이 되었을 지 알아 보겠습니다.

1. MailSubmission 서비스는 유저의 outbox 에 메시지가 있음을 알려주는 event notification 을 받습니다.

2. MailSubmission 서비스는 BridgeHeadPicker 컴포넌트를 이용하여 어떤 Hub Server가 해당 이벤트를 처리할 지를 결정합니다.

3. MailSubmission 서비스는 선택한 HUB 서버에 RPC를 통해서 event를 notification 합니다.

4. Hub 서버는 다음 홉으로 메시지를 전달하고 copy 본을 Shadow 로 변환합니다.

5. Hub서버는 RPC 호출을 통해서 Mailbox 에게 이벤트가 정상 처리 되었음을 알려줍니다.

만약, 여러대의 Hub 중, contact 하려는 허브가 문제가 있을 경우, 이벤트는 처리 된 것으로 mark 되지 않고, 다른 Hub 서버로 재전송됩니다.

이 과정에서 mailSubmission서비스의 BridgeHeadPicker 컴포넌트는 현재 Available 한 Hub 서버를 감지하는 데 사용되는 일종의 heart beat 역할을 한다고 볼 수 있습니다.

일반적으로, 메시지를 전송하는 Mailbox Server는 Hub가 메시지를 받아서 다음홉으로 넘길 때까지 메시지의 Copy 본을 가지고 있습니다. 그리고 Mailbox Server상의 Mail Submission 서비스는 해당 메시지에 대해서 Hub 가 이제 신경쓰지 않아도 좋다라는 “Discard notification”을 보낸 이후에야 shadow copy 본을 무시하게 됩니다. 만약, mailbox Server로부터 메시지를 수신 한 후에 Hub서버상에 문제(Server failure)가 발생된다면, Mail submission 서비스는 그 실패를 감지하고, 다른 available 한 Hub 서버로 메시지를 재 전송하게 됩니다.

이 특징은 다음 두 위치에서 구현되게 됩니다.

Ø 첫번째로, Mailbox Server상의 Mail Submission 서비스

n Message ID 나 Hub 와 같은 메시지에 대한 Shadow meta-data를 유지합니다.

n Shadow message를 계속 keeping할지를 결정하는 데 사용하는 Discard에 대한 업데이트 된 것을 확인하기 위해서 Hub에 쿼리하며, 실패 역시 감지합니다.

n Hub 서버가 다음 홉으로 메시지를 했음을 Confirm 해 주면, Shadow data는 무시됩니다.

n Hub 서버가 fail 되면, Message를 재 전송합니다.

Ø 두번째로, Hub Server상의 Transport process 입니다.

n MSRMC(Mail Submission Redundancy Manager Component) 로 discard notification을 리턴 해 주는 역할을 합니다. MSRMC 야 당연히 Mailbox Server 에 있는 것으로, 쉽게 생각하면, “내가 너한테 받은 메시지는 다음 홉으로 잘 처리했으니, 넌 이상 그 메시지를 keep할 필요 없어” 라는 내용을 Mailbox 에게 보내는 것입니다.

위에서 언급한 내용을 그림으로 확인해 보도록 하죠.

이 그림을 보시면서, 설명한 내용을 이해하시면 될 것입니다.

추가로, 위의 Mailbox Server 서버의 컴포넌트 중에서 Redundancy의 핵심이 되는 MSRMC에 대해서 다뤄보도록 하겠습니다. MSRMC는 아래의 역할을 담당합니다.

Ø 자기로부터 전송된 모든 메시지에 대한 Shadow 복사본을 추적 관리 합니다

Ø 어떤 shadow 메시지가 어떤 hub 서버를 위하여 shadow 되었는지를 추적 관리합니다.

Ø Heartbeat 를 통해서 Hub Server의 상태를 추적 관리합니다. 이 때의 Hub 서버는 당연히 Mailbox Server가 그것을 위해서 Shadow message를 가진 것에 해당 하는 Hub 서버입니다. 말이 좀 어렵나요. ^^ 내가 보낸 메시지를 받은 Hub서버의 상태를 계속 heartbeat을 이용하여 지속 관리한다고 보시면 됩니다.

Ø HUB 서버로부터 받은 “Discard Notification”을 처리하여, 해당 shadow message에 해당하는 meta-data를 삭제하는 역할을 합니다.

Ø 관련된 성능카운터도 관리합니다.

언뜻 보면, redundant transport 기능과 redundant mail submission이 비슷해 보이기는 하지만, 다음과 같은 측면에서 차이가 있습니다.

ü Mail submission 서비스에는 Queue라는 개념이 없기 때문에, Shadow copy retention이 다릅니다.

ü Shadow meta-data 에 대한 영속성. Redundant transport에서 이 shadow meta-data는 Shadow queue에 존재하고 있는 동안에 메시지 property 의 일부분으로 있게 된다.

ü 메시지에 대한 Fan-out 은 없다. 즉, 허브 서버는 Mailbox Server에 대해서 항상 next single hop이기 때문에 fan-out 이 필요 없습니다.

ü Redundant 지원과 heartbeat 정보는 Mailbox와 HUB사이 에서는 RPC protocol을 사용하지만, Transport Redundant 에서는 SMTP protocol을 사용합니다.