적용 대상:
2016 2019 Subscription Edition
Exchange 2016 이상의 부하 분산은 Exchange 2013에서 제공되는 Microsoft 고가용성 및 네트워크 복원력 플랫폼을 기반으로 합니다. 타사 부하 분산 솔루션(하드웨어 및 소프트웨어 모두)의 가용성과 결합된 경우 Exchange organization 부하 분산을 구현하기 위한 여러 옵션이 있습니다.
Exchange 2013에서 도입된 Exchange 아키텍처 변경으로 인해 사서함 서버 및 클라이언트 액세스 서버 역할이 도입되었습니다. 이를 클라이언트 액세스, 사서함, 허브 전송 및 통합 메시지가 별도의 서버에서 실행된 Exchange 2010과 비교합니다.
최소 서버 역할을 사용하여 Exchange 2016 및 2019는 다음을 제공합니다.
클라이언트 액세스 서비스 및 Edge 전송 서버 역할을 실행하는 사서함 서버를 사용하여 배포를 간소화했습니다.
사서함 서버의 전송 서비스 범주로 메시지를 라우팅하는 서비스, 연결, 큐 및 구성 요소의 컬렉션인 전송 파이프라인에서 관리되는 메일 흐름입니다.
부하 분산 장치를 배포하여 클라이언트 트래픽을 분산하여 고가용성.
Exchange 2013에 도입된 HTTP 프로토콜 표준은 Exchange 2016 및 Exchange 2019에서 세션 선호도가 더 이상 필요하지 않음을 의미합니다. 세션 선호도는 메시징 사용 서비스에 대한 영구 연결을 허용하므로 사용자가 사용자 이름과 암호를 여러 번 다시 입력할 필요가 없습니다.
이전에는 Exchange 2007 및 Exchange 2010에서 Outlook Anywhere용 HTTP를 통해 RPC를 지원했습니다. Exchange 2013은 기본적으로 사용하도록 설정되지는 않았지만 HTTP를 통해 MAPI를 도입했습니다. 이제 Exchange 2016 및 Exchange 2019에서 기본적으로 사용하도록 설정됩니다.
HTTP 프로토콜을 사용하는 경우 모든 네이티브 클라이언트는 Exchange Server HTTP 및 HTTP를 사용하여 연결합니다. 이 표준 프로토콜은 부하 분산이 연결을 다른 서버로 리디렉션할 때마다 사용자 자격 증명에 대한 새로운 프롬프트를 방지하기 위해 이전에 필요했던 선호도의 필요성을 제거합니다.
Exchange Server 서버 역할
Exchange 2016 및 Exchange 2019의 서버 역할 수가 감소하면 Exchange 구현 및 하드웨어 요구 사항이 간소화됩니다. Exchange 2016 및 2019의 서버 역할 수는 사서함 서버와 Edge 전송 서버의 7개에서 2개로 줄어듭니다. 사서함 서버 역할에는 클라이언트 액세스 서비스가 포함되며, Edge 전송 서버는 이전 버전의 Exchange에서와 마찬가지로 Exchange 2016 및 Exchange 2019에서 보안 메일 흐름을 제공합니다.
Exchange 2013에서 클라이언트 액세스 서버 역할은 사용자가 사서함에 액세스하려고 할 때 서버가 사용자의 사서함을 적극적으로 제공하는 사서함 서버로 요청을 다시 프록시했는지 확인했습니다. 즉, 웹용 Outlook(이전에는 Outlook Web App라고도 함)와 같은 서비스가 사서함 자체의 사용자에 대해 렌더링되어 선호도가 필요하지 않습니다.
Exchange 2016 및 Exchange 2019에도 동일한 기능이 유지됩니다. 두 사서함 서버가 서로 다른 사서함을 호스트하는 경우 필요한 경우 서로에 대한 트래픽을 프록시할 수 있습니다. 사서함의 활성 복사본을 호스트하는 사서함 서버는 사용자가 다른 사서함 서버에 연결하더라도 사서함에 액세스하는 사용자에게 서비스를 제공합니다.
아키텍처를 Exchange Server 문서에서 Exchange Server 서버 역할 변경에 대해 자세히 알아보세요.
| 서버 역할 | 서비스 |
|---|---|
| 사서함 서버 | EdgeSync를 사용하여 Active Directory에서 Edge 전송 서버의 AD LDS instance 수신 및 구성 정보의 단방향 복제를 관리합니다. Edge 전송이 안티스팜을 수행하고 엔드 투 엔드 메일 흐름을 사용하도록 설정하는 데 필요한 정보만 복사합니다. |
| Edge 전송 | 다음을 사용하여 모든 인바운드 및 아웃바운드 인터넷 메일 흐름을 관리합니다.
Active Directory 포리스트의 멤버가 아닙니다. |
필수는 아니지만 Edge 전송 서버는 이전 Exchange 버전과 같이 경계 네트워크에 배치되어 Exchange organization 안전한 인바운드 및 아웃바운드 메일 흐름을 제공합니다.
에지 전송 서버의 전송 서비스 이해 문서에서 전송 서비스에 대해 자세히 알아보세요.
Exchange Server 프로토콜
Exchange 2016부터 모든 네이티브 Exchange 클라이언트는 HTTP 프로토콜을 사용하여 클라이언트 액세스 서비스 SSL 인증서를 사용하여 암호화된 로그인 시 사용자에게 제공되는 HTTP 쿠키를 사용하여 지정된 서비스에 연결합니다. 로그인한 사용자는 다시 인증하지 않고 클라이언트 액세스 서비스를 실행하는 다른 사서함 서버에서 세션을 다시 시작할 수 있습니다. 동일한 SSL 인증서를 사용하는 서버는 클라이언트 인증 쿠키의 암호를 해독할 수 있습니다.
HTTP를 사용하면 Exchange 네트워크에서 서비스 또는 애플리케이션 상태 검사를 사용할 수 있습니다. 부하 분산 장치 솔루션에 따라 상태 프로브를 구현하여 시스템의 여러 구성 요소를 검사 수 있습니다.
클라이언트에 대한 HTTP 전용 액세스의 효과는 부하 분산도 더 간단하다는 것입니다. 원하는 경우 DNS를 사용하여 Exchange 트래픽 부하를 분산할 수 있습니다. 클라이언트에 모든 사서함 서버의 IP 주소를 제공하고 HTTP 클라이언트는 집안일을 처리합니다. Exchange 서버가 실패하면 프로토콜이 다른 서버에 연결을 시도합니다. 그러나 DNS에 대한 부하 분산에는 단점이 있으며, Exchange Server 부하 분산 옵션 섹션에 설명되어 있습니다.
EXCHANGE SERVER HTTP를 통한 MAPI 문서에서 HTTP 및 Exchange Server 대해 자세히 알아보세요.
Exchange Server 부하 분산 옵션
여기에 표시된 예제에서 DAG(데이터베이스 가용성 그룹)에 구성된 여러 서버는 클라이언트 액세스 서비스를 실행하는 사서함 서버를 호스트합니다. 이렇게 하면 Exchange 서버 공간이 작은 고가용성을 제공합니다. 클라이언트는 Exchange 서버에 직접 연결하지 않고 부하 분산 장치에 연결합니다. 부하 분산 장치 쌍에 대한 요구 사항은 없지만 네트워크 복원력을 개선하기 위해 클러스터에 배포하는 것이 좋습니다.
DAG는 Microsoft Clustering Services를 사용합니다. 이러한 서비스는 NLB(Windows 네트워크 부하 분산)와 동일한 서버에서 사용하도록 설정할 수 없습니다. 따라서 WINDOWS NLB는 DAG를 사용할 때 옵션이 아닙니다. 이 경우 타사 소프트웨어 및 가상 어플라이언스 솔루션이 있습니다.
DNS를 사용하는 것은 Exchange 트래픽 부하를 분산하는 가장 간단한 옵션입니다. DNS 부하 분산을 사용하면 클라이언트에 모든 사서함 서버의 IP 주소만 제공해야 합니다. 그런 다음 DNS 라운드 로빈은 해당 트래픽을 사서함 서버에 배포합니다. 하나의 Exchange 서버가 완전히 실패하는 경우 HTTP 클라이언트는 다른 서버에 연결할 수 있을 만큼 스마트합니다.
단순성은 가격이 책정되지만, 이 경우 DNS 라운드 로빈은 각 서버가 트래픽의 공정한 몫을 얻을 수 있도록 프로그래밍 방식으로 방법이 없기 때문에 트래픽을 실제로 부하 분산하지 않습니다. 또한 단일 서비스가 실패하면 클라이언트가 사용 가능한 서비스로 자동으로 리디렉션되지 않도록 서비스 수준 모니터링이 없습니다. 예를 들어 웹용 Outlook 오류 모드인 경우 클라이언트에 오류 페이지가 표시됩니다.
외부에 게시할 때 DNS 부하 분산에는 더 많은 외부 IP 주소가 필요합니다. 즉, organization 각 개별 Exchange 서버에는 외부 IP 주소가 필요합니다.
전송 계층 4 또는 애플리케이션 계층 7을 사용하여 클라이언트 트래픽을 분산하는 하드웨어와 같이 트래픽 부하를 분산하는 더 세련된 솔루션이 있습니다. 부하 분산 장치는 각 Exchange 클라이언트 연결 서비스를 모니터링하고, 서비스 오류가 있는 경우 부하 분산 장치는 트래픽을 다른 서버로 전송하고 문제 서버를 오프라인으로 전환할 수 있습니다. 또한 일부 수준의 부하 분산은 단일 사서함 서버가 대부분의 클라이언트 액세스를 프록시하지 않도록 합니다.
부하 분산 서비스는 계층 4 또는 계층 7 또는 조합을 사용하여 트래픽을 관리할 수 있습니다. 각 솔루션에는 이점과 단점이 있습니다.
계층 4 부하 분산 장치는 전송 계층에서 작동하여 콘텐츠를 검사하지 않고 트래픽을 전달합니다.
트래픽 콘텐츠를 검사하지 않으므로 계층 4 부하 분산 장치는 전송 시간을 절약합니다. 그러나, 이것은 장만과 함께 제공됩니다. 계층 4 부하 분산 장치는 IP 주소, 프로토콜 및 TCP 포트만 알고 있습니다. 단일 IP 주소만 알고 있으면 부하 분산 장치는 단일 서비스만 모니터링할 수 있습니다.
계층 4 부하 분산의 이점은 다음과 같습니다.
더 적은 리소스가 필요합니다(콘텐츠 검사 없음).
전송 계층에서 트래픽을 분산합니다.
계층 4 솔루션의 위험은 서비스가 실패하지만 서버를 계속 사용할 수 있는 경우 클라이언트가 실패한 서비스에 연결할 수 있다는 것입니다. 즉, 복원력 있는 계층 4 구현에는 서비스 수준 모니터링을 허용하는 서비스당 별도의 HTTP 네임스페이스(예: owa.contoso.com, eas.contoso.com, mapi.contoso.com)로 구성된 여러 IP 주소가 필요합니다.
계층 7 부하 분산 장치는 애플리케이션 계층에서 작동하며 트래픽 콘텐츠를 검사하고 그에 따라 지시할 수 있습니다.
계층 7 부하 분산 장치는 단일 네임스페이스(예: mail.contoso.com 및 서비스별 모니터링)의 단순성을 위해 계층 4 부하 분산의 원시 성능 이점을 포기합니다. 계층 7 부하 분산 장치는 /owa 또는 /Microsoft-Server-ActiveSync 또는 /mapi와 같은 HTTP 경로를 이해하고 모니터링 데이터를 기반으로 트래픽을 작업 서버로 전송할 수 있습니다.
계층 7 부하 분산의 이점은 다음과 같습니다.
단일 IP 주소만 필요합니다.
콘텐츠를 검사하고 트래픽을 전송할 수 있습니다.
오프라인으로 전환할 수 있는 실패한 서비스에 대한 알림을 제공합니다.
부하 분산 장치 SSL 종료를 처리합니다.
애플리케이션 계층에서 트래픽을 분산하고 대상 URL을 이해합니다.
SSL은 SSL 공격을 수정하기 위한 중앙 집중식 위치를 제공하기 때문에 부하 분산 장치에서 종료되어야 합니다.
부하 분산이 필요한 포트에는 EXCHANGE organization 사용되지 않을 수도 있는 IMAP4 또는 POP3용 포트와 같은 일부 포트가 포함됩니다.
| TCP 포트 | 역할 | 사용 |
|---|---|---|
| 25 | 메일함 | 인바운드 SMTP |
| 587 | 메일함 | 클라이언트에 대한 인바운드 SMTP |
| 110 | 메일함 | POP3 클라이언트 |
| 143 | 메일함 | IMAP4 클라이언트 |
| 443 | 메일함 | HTTPS(웹용 Outlook, 자동 검색, 웹 서비스, ActiveSync, HTTP를 통한 MAPI, HTTP를 통한 RPC, OAB, EAC) |
| 993 | 메일함 | IMAP4 클라이언트 보안 |
| 995 | 메일함 | POP3 클라이언트 보안 |
Exchange Server 배포 시나리오 부하 분산
Exchange 2016은 네임스페이스 및 부하 분산 아키텍처에 상당한 유연성을 도입했습니다. 간단한 DNS에서 정교한 타사 계층 4 및 계층 7 솔루션에 이르기까지 Exchange organization 부하 분산을 배포하기 위한 다양한 옵션을 사용하여 organization 요구 사항에 따라 모두 검토하는 것이 좋습니다.
다음 시나리오에는 이점과 제한 사항이 있으며 각 시나리오를 이해하는 것이 Exchange organization 가장 적합한 솔루션을 구현하는 데 핵심적인 요소입니다.
시나리오 A 단일 네임스페이스, 세션 선호도 없음: 계층 4 또는 계층 7
시나리오 B 단일 네임스페이스, 세션 선호도 없음: 계층 7
시나리오 C 세션 선호도가 있는 단일 네임스페이스, 계층 7
시나리오 D 여러 네임스페이스 및 세션 선호도 없음, 계층 4
시나리오 A 단일 네임스페이스, 세션 선호도 없음: 계층 4 또는 계층 7
이 계층 4 시나리오에서는 HTTP 프로토콜 클라이언트에 대해 단일 네임스페이스(mail.contoso.com)가 배포됩니다. 부하 분산 장치는 세션 선호도를 유지하지 않습니다. 계층 4 솔루션이므로 부하 분산 장치는 RPC 요청과 웹용 Outlook 요청을 구분할 수 없으므로 단일 가상 디렉터리의 상태를 검사 구성됩니다.
이 예제의 부하 분산 장치 관점에서 상태는 지정된 네임스페이스에 대한 프로토콜당이 아니라 서버당 입니다. 관리자는 상태 프로브를 대상으로 지정할 가상 디렉터리를 선택해야 합니다. 많이 사용되는 가상 디렉터리를 선택하는 것이 좋습니다. 예를 들어 대부분의 사용자가 웹용 Outlook 사용하는 경우 상태 프로브에서 웹용 Outlook 가상 디렉터리를 선택합니다.
웹용 Outlook 상태 프로브 응답이 정상인 경우 부하 분산 장치는 대상 사서함 서버를 부하 분산 풀에 유지합니다. 그러나 어떤 이유로든 웹용 Outlook 상태 프로브가 실패하면 부하 분산 장치는 해당 네임스페이스와 연결된 모든 요청에 대한 부하 분산 풀에서 대상 사서함 서버를 제거합니다. 즉, 상태 프로브가 실패하면 프로토콜에 관계없이 해당 네임스페이스에 대한 모든 클라이언트 요청이 다른 서버로 전달됩니다.
시나리오 B 단일 네임스페이스, 세션 선호도 없음: 계층 7
이 계층 7 시나리오에서는 모든 HTTP 프로토콜 클라이언트에 대해 mail.contoso.com 단일 네임스페이스가 배포됩니다. 부하 분산 장치는 세션 선호도를 유지하지 않습니다. 부하 분산 장치가 계층 7에 대해 구성되었으므로 SSL 종료가 있고 부하 분산 장치는 대상 URL을 알고 있습니다.
Exchange 2016 및 Exchange 2019에 대해 이 구성을 사용하는 것이 좋습니다. 부하 분산 장치는 부하 분산 풀에서 대상 사서함 서버의 상태를 검사 구성되며 각 가상 디렉터리에 상태 프로브가 구성됩니다.
예를 들어 웹용 Outlook 상태 프로브 응답이 정상인 경우 부하 분산 장치는 대상 사서함 서버를 웹용 Outlook 부하 분산 풀에 유지합니다. 그러나 어떤 이유로든 웹용 Outlook 상태 프로브가 실패하면 부하 분산 장치는 웹용 Outlook 요청에 대한 부하 분산 풀에서 대상 사서함 서버를 제거합니다. 이 예제에서 상태는 프로토콜당 입니다. 즉, 상태 프로브가 실패하면 영향을 받는 클라이언트 프로토콜만 다른 서버로 전달됩니다.
시나리오 C 세션 선호도가 있는 단일 네임스페이스, 계층 7
이 계층 7 시나리오에서는 모든 HTTP 프로토콜 클라이언트에 대해 mail.contoso.com 단일 네임스페이스가 배포됩니다. 부하 분산 장치는 계층 7에 대해 구성되므로 SSL 종료가 있고 부하 분산 장치는 대상 URL을 알고 있습니다. 부하 분산 장치는 부하 분산 풀에서 대상 사서함 서버의 상태를 검사 구성됩니다. 상태 프로브는 각 가상 디렉터리에 구성됩니다.
그러나 세션 선호도를 사용하도록 설정하면 용량과 사용률이 감소합니다. 더 많은 선호도 옵션, 쿠키 기반 부하 분산 또는 SSL(Secure Sockets Layer) 세션 ID가 더 많은 처리 및 리소스가 필요하기 때문입니다. 세션 선호도가 부하 분산 확장성에 미치는 영향에 대해 공급업체와 검사 것이 좋습니다.
이전 시나리오와 마찬가지로 웹용 Outlook 상태 프로브 응답이 정상인 한 부하 분산 장치는 대상 사서함 서버를 웹용 Outlook 부하 분산 풀에 유지합니다. 그러나 어떤 이유로든 웹용 Outlook 상태 프로브가 실패하면 부하 분산 장치는 웹용 Outlook 요청에 대한 부하 분산 풀에서 대상 사서함 서버를 제거합니다. 여기서 상태는 프로토콜당 입니다. 즉, 상태 프로브가 실패하면 영향을 받는 클라이언트 프로토콜만 다른 서버로 전달됩니다.
시나리오 D 여러 네임스페이스 및 세션 선호도 없음
여러 네임스페이스가 있고 세션 선호도가 없는 이 마지막 시나리오는 프로토콜별 상태 검사 및 계층 4 전원을 제공합니다. 고유한 네임스페이스는 각 HTTP 프로토콜 클라이언트에 대해 배포됩니다. 예를 들어 HTTP 프로토콜 클라이언트를 mail.contoso.com, mapi.contoso.com 및 eas.contoso.com 구성합니다.
이 시나리오에서는 복잡한 부하 분산 논리가 필요하지 않지만 프로토콜별 상태 검사를 제공합니다. 부하 분산 장치는 계층 4를 사용하며 세션 선호도를 유지하도록 구성되지 않았습니다. 부하 분산 장치 구성은 부하 분산 풀에서 대상 사서함 서버의 상태를 확인합니다. 이 설정에서는 각 가상 디렉터리에 고유한 네임스페이스가 있으므로 상태 프로브가 각 가상 디렉터리의 상태를 대상으로 지정하도록 구성됩니다. 계층 4에 대해 구성되었으므로 부하 분산 장치는 URL에 액세스하고 있는지 알지 못하며 결과는 마치 알고 있는 것처럼 표시됩니다. 상태는 프로토콜당이므로 상태 프로브가 실패하면 영향을 받는 클라이언트 프로토콜만 다른 서버로 전달됩니다.
Exchange Server 부하 분산 및 관리되는 가용성
사용 가능한 서버 및 서비스를 모니터링하는 것이 고가용성 네트워크의 핵심입니다. 일부 부하 분산 솔루션은 대상 URL 또는 요청 내용에 대해 전혀 알지 못하므로 Exchange 상태 프로브의 복잡성이 발생할 수 있습니다.
Exchange 2016 및 Exchange 2019에는 관리되는 가용성이라고 하는 기본 제공 모니터링 솔루션이 포함되어 있습니다. 활성 모니터링 또는 로컬 활성 모니터링이라고도 하는 관리되는 가용성은 Exchange 고가용성 플랫폼과 기본 제공 모니터링 및 복구 작업의 통합입니다.
관리되는 가용성에는 오프라인 응답자가 포함됩니다. 오프라인 응답자가 호출되면 영향을 받는 프로토콜(또는 서버)이 서비스에서 제거됩니다.
부하 분산 장치가 관리 가용성이 오프라인으로 표시된 사서함 서버로 트래픽을 라우팅하지 않도록 하려면 부하 분산 장치 상태 프로브를 가상 디렉터리>/healthcheck.htm 검사 <구성해야 합니다(예: <https://mail.contoso.com/owa/healthcheck.htm>).
관리되는 가용성의 관리되는 가용성에 대해 자세히 알아보세요.