Exchange Queue & A:부하 분산, Edge 전송 및 기타 정보

아티클
08/24/2016

Exchange Queue & A부하 분산, Edge 전송 및 기타 정보

Henrik Walther

Q 회사 프로덕션 환경에 배포된 Microsoft® Office SharePoint® Server를 여러 대의 서버에서 실행하고 있습니다.그리고 각 서버는 새로 배포된 Exchange Server 2007 인프라의 HT(허브 전송) 서버를 통해 보내는 메시지를 릴레이해야 합니다.SharePoint 서버의 경우 그림 1과 같이 중앙 관리 | 작업 | 보내는 전자 메일 설정 페이지에서 단일 SMTP(Exchange) 서버의 FQDN(정규화된 도메인 이름)만 지정할 수 있는데, 이러한 단일 지점 장애를 없애려면 어떻게 해야 합니까?

그림 1 SharePoint 중앙 관리 페이지의 보내는 전자 메일 설정(더 크게 보려면 이미지를 클릭하십시오.)

A 좋은 질문입니다. 고가용성에 중점을 두고 회사 프로덕션 환경 전반에서 단일 지점 장애를 허용하지 않는 조직이 많습니다.메시징 및 공동 작업 서비스와 관련해서는 특히 더 그렇습니다.

Exchange 2007 HT 서버는 기본적으로 탄력적입니다.즉, Active Directory® 사이트에 HT 서버가 두 대 이상 있고 해당 Active Directory 사이트의 HT 서버 중 한 대를 사용할 수 없으면 메시지를 전달하려 하는 원본 HT 서버가 Active Directory 사이트에 있는 사용 가능한 다음 HT 서버로 연결을 시도합니다.이러한 동작은 목록의 첫 번째 HT 서버가 응답하지 않으면 다음 서버에 대한 연결을 시도하는 라운드 로빈 DNS 메커니즘을 사용하여 이루어집니다.

이는 Exchange 2007의 기본 기능이므로 모든 HT 간 통신과 사서함 서버-HT 간(조직 내) 통신과 관련해서는 고가용성(또는 부하 분산)에 대해서 신경 쓸 필요가 없습니다.하지만 사서함 서버 역할이 설치된 컴퓨터에 HT 서버 역할까지 설치하는 경우 Microsoft Exchange 메일 전송 서비스에서 메시지를 전송할 때 항상 Active Directory 사이트의 다른 HT 서버보다 로컬 HT 서버가 사서함 서버 역할에 우선 사용된다는 점을 유의해야 합니다.

SharePoint 서버와 관련해서는 위 정보가 그다지 유용하지 않지만 앞으로 설명할 내용을 이해하는 데 있어서 중요합니다.HT 서버는 기본적으로 탄력적이므로 하드웨어 부하 분산 장치나 WNLB(Windows® 네트워크 부하 분산) 기능을 사용한 Exchange 2007의 HT 서버 간 조직 내 부하 분산 통신이 지원되지 않습니다.

사실 Exchange 2007 RTM 버전을 기준으로 보면 HT 서버로의 부하 분산 인바운드 SMTP 트래픽 지원은 전혀 제공되지 않습니다.하지만 Exchange 2007 SP1에서는 지원 기능이 추가될 예정입니다.SP1 버전에서도 하드웨어 부하 분산 장치나 WNLB 기능을 사용한 조직 내 통신 부하 분산(굳이 그렇게 할 이유도 없지만)은 지원되지 않지만, HT 서버의 기본 클라이언트 수신 커넥터를 사용하여 Exchange 2007 조직에 아웃바운드 메시지를 전송하는 IMAP 또는 POP 클라이언트와 같은 Exchange 클라이언트와 SharePoint 서버와 같은 Exchange 이외의 인프라를 사용하면 인바운드 SMTP 트래픽의 부하를 분산시킬 수 있습니다.

따라서 Exchange 2007 SP1 조직을 통해 메시지를 릴레이하는 SharePoint 서버를 구성하려면 Active Directory DNS에 DNS 레코드를 만들고 하드웨어 부하 분산 장치로 연결 대상을 지정하여 여러 HT 서버에 걸쳐 트래픽을 분산하거나 WNLB 기능을 이용하여 목표를 달성할 수 있습니다.후자의 방법을 사용하려면 가상 IP 주소와 FQDN(예: mail.contoso.com)을 사용하여 WNLB 클러스터를 구성하고 포트 규칙 탭에서 포트 25(비Exchange 서버로부터 전송되는 인바운드 SMTP 트래픽) 및 587(IMAP, POP 등의 Exchange 클라이언트로부터 전송되는 인바운드 SMTP)을 추가하면 됩니다.그림 2에서는 이렇게 구성된 포트 규칙 탭을 보여 줍니다.이때 모든 IP 주소를 선택하는 대신 두 가지 규칙에 특정 가상 NLB 클러스터 IP 주소를 할당해야 합니다.

그림 2 정의된 포트 규칙(더 크게 보려면 이미지를 클릭하십시오.)

NLB 클러스터를 구성한 후에는 새 수신 커넥터를 만들어 포트 25에서 수신하고 이 커넥터를 필요로 하는 서버만 해당 커넥터를 사용하여 메시지를 릴레이할 수 있도록 구성해야 합니다.또한 이 커넥터에는 반드시 앞서 만든 가상 NLB 클러스터 IP 주소를 사용해야 합니다.

Q Exchange Server 2007을 기반으로 한 메시징 인프라를 사용하고 있습니다.Exchange 2007 사서함 서버를 하드웨어 수준과 저장소 수준에 중복 구축하기 위해 모두 CCR(클러스터 연속 복제) 기술을 기반으로 하는 클러스터된 사서함 서버로 구축했습니다.각 CCR 클러스터의 액티브 노드와 패시브 노드는 모두 같은 실제 데이터 센터에 위치하고 있습니다.그런데 Exchange 2007 서버를 SP1로 업그레이드하면서 서비스 및 데이터 가용성 기능을 활용하기 위해 Exchange 2007 SP1에 포함된 새로운 SCR(대기 연속 복제) 기술을 사용하여 사서함 데이터베이스를 다른 사이트에 있는 사서함 서버로 교체하려고 합니다.

SCR 인프라는 CCR 또는 SCC(단일 복사본 클러스터) 기술을 기반으로 하여 Exchange 2007 SP1 독립 실행형 사서함 서버나 CMS(클러스터된 사서함 서버)로 구축할 수 있다는 사실은 잘 알고 있지만,SCR 대상 서버의 경우에는 어떻게 됩니까?

A SCR 대상 서버(SCR 끝점이라고도 함)는 Windows 장애 조치(Failover) 클러스터(이전의 Microsoft Cluster Server)의 어떤 저장소 그룹이나 패시브 노드에 대해서도 LCR(로컬 연속 복제)을 사용하지 않도록 구성되고 사서함 서버 역할이 설치된 독립 실행형 사서함 서버여야 합니다. 따라서 장애 조치 클러스터를 구성한 다음 해당 장애 조치 클러스터 내의 패시브 노드에 사서함 서버 역할을 설치할 수 있지만 클러스터된 사서함 서버를 SCR 대상으로 사용할 수는 없습니다.

Q 조직에서 Exchange 2007을 메시징 플랫폼으로 사용하고 있습니다.그리고 여러 단계로 이루어진 메시지 보호 및 보안 기능을 활용할 수 있도록 경계 네트워크에 있는 기존 스팸 방지/바이러스 백신 솔루션을 Forefront™ Security for Exchange가 설치된 Exchange 2007 Edge 전송 서버 기반 솔루션으로 교체하려고 합니다.현재 계획으로는 곧 Edge 전송 서버를 최소한 2개 이상 더 배포하려고 합니다.

그런데 궁금한 점이 있습니다.부하를 분산하고 완전하게 중복되도록 하려면 Exchange 2007 Edge 전송 기반 메시지 관리 솔루션에 대한 인바운드 SMTP 연결은 어떻게 구축해야 합니까?

A 경계 네트워크에 있는 Edge 전송 서버가 인터넷에 연결된 SMTP 서버인 경우 Microsoft IT(Microsoft Information Technology) 그룹에서 사용하는 것과 비슷한 방식을 사용할 수 있습니다.Microsoft IT에서는 6대의 Edge 전송 서버(레드먼드에 3대, 실리콘 밸리에 3대)를 구축하여 매일 1,600만 개 이상의 인바운드 메시지를 처리하고 있습니다(그 중 1,300만 개 이상이 스팸으로 필터링됨).

Microsoft IT는 Microsoft.com 도메인에 총 3개의 MX(메일 교환기) 레코드를 사용하고 있습니다.구체적으로 열거하면maila.microsoft.com, mailb.microsoft.com, mailc.microsoft.com 등입니다(그림 3 참조).각 MX 레코드는 기본 설정이 10으로 구성되어 DNS 라운드 로빈 방식을 통해 무작위로 선택됩니다.또한 MX 레코드별로 IP 주소(메일 호스트)가 2개씩 연결되어 있습니다.

그림 3 Microsoft.com의 MX 레코드와 인터넷 메일 호스트(더 크게 보려면 이미지를 클릭하십시오.)

MX 레코드별로 IP 주소를 2개씩 사용하는 이유는 무엇일까요?일부 MTA(메시지 전송 에이전트)는 도메인에 대해 구성된 MX 레코드 수에 관계없이 항상 동일한 MX 레코드를 선택하기 때문입니다.이는 Exchange Server와 관련해서는 Exchange 2000 이후부터 수년 동안 문제가 되지 않았지만 어딘가에서는 이러한 설계상의 결함이 있는 MTA가 사용되고 있다는 것이 문제입니다.따라서 어느 MTA가 Microsoft.com 주소로 메시지를 전달하려 하는지에 관계없이 DNS 라운드 로빈 및 부하 분산을 사용하여 모든 SMTP 연결이 분산됩니다.

Q Windows Server® 2003 DC(도메인 컨트롤러)를 기반으로 한 Active Directory 도메인을 사용하고 있습니다.현재 Windows Server 2003 DC를 Windows Server 2008로 전환하고 Exchange 2003 메시징 환경을 Exchange Server 2007로 전환하기 위한 계획 단계에 있습니다.메시징 환경을 Exchange Server 2003에서 Exchange 2007로 전환하기 전에 Windows Server 2003을 실행하는 모든 서버를 Windows Server 2008로 업그레이드하는 방법으로 Active Directory 도메인을 Windows Server 2008로 전환할 수 있습니까?

A 예, 가능합니다. Exchange Server 2003 SP2는 전체가 Windows Server 2008 DC로 구성된 Active Directory 도메인을 완벽하게 지원하므로 계획대로 진행하시면 됩니다.단, Windows Server 2008 RODC(읽기 전용 도메인 컨트롤러)를 사용할 계획이라면 RODC를 사용하도록 Exchange RUS(받는 사람 업데이트 서비스)를 구성해서는 안 된다는 점만 유의하십시오.

Henrik Walther는 Microsoft Certified Architect로서,14년 이상의 IT 비즈니스 경력을 자랑하는 메시징(실습생) 및 Exchange MVP이기도 합니다.현재 Interprise Consulting에서 기술 설계자로 근무하면서 Biblioso Corp에서 테크니컬 라이터로도 활동하고 있습니다.

추가 리소스