Exchange 2013 Architecture
이전 버전의 Exchnage는 Client Access, Hub Transport, Mailbox, Unified messaging 그리고 Edge Transport 이렇게 무려 5개의 Role 서버로 나눠 졌었습니다. 이렇게 많은 Server Role을 가졌던 이유를 굳이 찾아 보자면 Exchange 2007이나 Exchange 2010 제품 개발 당시 있었던 기술적인 제약들을 고려하여 구조화 되고 최적화 되었기 때문이라고 할 수 있겠죠. 예를 들면 Exchange 2007 개발 당시 주요 제약사항은 CPU의 성능이었고, 이에 최적화된 Architecture가 Exchange 2010에서도 거의 비슷한 구조를 유지했었습니다.
[Exchange 2010 Main Server Role]
시대는 변하여 더 이상 CPU 마력은 문제가 되지 않고 있고, 손쉬운 확장과, 하드웨어 Utilization의 증대 및 문제 발생시 문제의 영향력을 최소화하여 시스템을 안정적으로 운영하는 것이 Architecture 설계상의 중요한 쟁점이 되었습니다. 이러한 이유로 Exchange 2013은 Client Access Serer Role과 Mailbox Server Role 이렇게 2개의 Role을 가집니다. 특별히 Exchange 2013에서 Edge Transport Server Role은 없으며, 만약 edge transport role을 사용하고 싶다면, Exchange 2007이나, Exchange 2010 Edge transport server를 배포 할 수 있습니다.
Exchange 2013환경에 Edge Transport Role을 배포와 관련된 더 자세한 내용은 여기를 눌러 확인하세요.
기존 Exchnage Server의 Client Access Protocols, Transport Service, Mailbox Database, Unified Messaging과 관련된 대부분의 구성요소는 Exchange 2013 Mailbox Server에 포함되었습니다. Mailbox Server는 서버상의 Active Mailbox를 위한 모든 Activity를 제어합니다. Client Access Server는 인증을 제공하고 제한된 Redirection과 Proxy Service를 제공하며 Client Access Server 자체는 어떤 Data rendering도 하지 않는 가벼운 stateless 서버입니다. Client Access Server는 HTTP, POP, IMAP 및 SMTP와 같은 Client Access Protocol을 제공하지만 어떤 것도 CAS에 Queuing되거나 저장되지 않습니다.
새 Architecture에서 CAS서버와 MBX서버는 “loosely coupled”되었습니다. 특정 메일 박스에 대한 처리는 메일박스에 대한 Active Database를 호스팅 하고 있는 Mailbox 서버에서 발생합니다. CAS와 MBX서버간의 Version 호환성 관련 문제를 해결하고자 모든 데이터 렌더링 및 데이터 전송은 Active Database Copy를 가진 로컬에서 수행됩니다.
[Exchange 2013 Architecture]
Exchange 2013 Architecture 변화의 이점
- Version Upgrade flexibility: Client Access서버는 Mailbox Server와 독립적이면서 순서와 상관없이 업그레이드 가능합니다.
- Session Indifference: Exchange Server 2010까지 Client Access 서버에서 제공하는 많은 프로토콜들은 Load Balancing을 위해 Session affinity를 요구했습니다. Exchange 2013에서 CAS서버는 모든 사용자 연결에 대해 간단하게 Mailbox Server로 Proxying하기 때문에 더 이상 Session affinity를 요구하지 않으며, Client Access와 Mailbox구성요소는 동일한 Mailbox Server에 존재 합니다. 바꾸어 말씀 드리면 이제 Client Access서버로 들어오는 연결을 Load balancing할 때 단순이 least Connection이나 Round-robin과 같은 기술을 이용할 수 있다는 의미가 됩니다.
- Deployment simplicity: Site-resilient 기반 Design을 사용했던 Exchange 2010에서 최대 8개의 다른 이름이 필요했었습니다. 두 개는 Internet Protocol을 위해, 두 개는 Outlook Web App 을 위해, 두 개는 RPC Client Access를 위해 그리고 Autodiscover와 SMTP를 위해 각각 하나의Namespace가 필요했죠. Exchange 2013에서는 Client Protocol을 위해 하나 그리고 Autodiscover를 위해 하나로 최소 두개의 Namespace가 필요하며 SMTP Namespace가 필요할 수 있습니다.
이러한 Arthitecture의 변화로 Client의 connectivity에는 약간의 변화가 생겼습니다.
먼저, RPC는 더 이상 Direct Access Protocol로 지원되지 않습니다. 즉 Outlook Client는 Outlook Anywhere로 알려져 있는 RPC Over HTTP를 이용해야 합니다. 무엇보다도 이 변화는 CAS서버가 더 이상 RPC Client Access Service를 가질 필요가 없다는 장점을 제공합니다.
두 번째 변화는 Outlook Client가 더 이상 Server FQDN으로 연결하지 않는다는 것입니다. Outlook은 Mailbox GUID와 @기호 및 사용자의 Primary SMTP주소의 도메인으로 구성된 새로운 Connection Point를 생성하기 위해 Autodiscover를 사용합니다. 따라서 사용자의 사서함이 다른 Database로 옮겨졌을 때 사용자에게 나타났던 오류메시지는 더 이상 사용자에게 나타나지 않게 되겠죠
Exchange 2013의 추가적인 변화로는 DAG(Database Availability Group)가 있습니다. 기본적인 DAG의 구성과 운용은 Exchange 2010과 동일하지만 Exchange 2013에서는 Transaction Log 코드의 개선과 Passive DB에서의 Deeper Checkpoint를 이용하여 장애조치 시간을 줄였습니다.
Exchange Store Service는 managed code로 새로 쓰여졌습니다. 새로이 만들어진 Store Service에서 각 Database는 자신의 process하에서 실행되며, 이는 각 Store의 문제가 개별 Database에 만 영향을 미치는 형태가 되기 때문에 장애에 대한 영향을 줄이고 더욱 안정적으로 시스템을 운영할 수 있게 합니다.
Managed Store에 대한 내용을 보려면 여기를 누르세요.
이렇게 변경된 Exchange 2013의 archtecture에 대해 알아 보았습니다. 큰 그림상에서만 이야기 했기 때문에 좀더 구체적인 내용이 필요할 것이라고 생각됩니다. 앞으로 차근차근 구체적인 내용에 대해서는 살펴보도록 하죠
다음 글에서는 Mail Flow의 변경된 부분에 대해 이야기 하도록 하겠습니다.