Exchange 2019 선호하는 아키텍처
온-프레미스 고객을 위한 새로운 Exchange Server 릴리스마다 기본 아키텍처를 업데이트하고 고객이 알고 싶은 변경 사항을 논의합니다. 2013년 Exchange Server 최신 Exchange 역사상 첫 번째 기본 아키텍처를 가져온 다음, 2016년 릴리스와 함께 제공된 변경 내용에 대한 개선 사항을 제공하여 2016년 Exchange Server 새로 고침을 진행했습니다. Exchange Server 2019에 대한 이 업데이트를 통해 이전 PA를 반복하여 새로운 기술과 개선 사항을 활용할 것입니다.
기본 설정 아키텍처
PA는 온-프레미스 환경에서 Exchange Server 2019에 가장 적합한 배포 아키텍처라고 생각하는 것에 대한 Exchange Server 엔지니어링 팀의 모범 사례 권장 사항입니다.
Exchange 2019는 온-프레미스 배포를 위한 다양한 아키텍처 선택을 제공하지만 여기서 설명하는 아키텍처는 가장 자세히 설명된 아키텍처입니다. 지원되는 다른 배포 아키텍처가 있지만 권장되는 방법은 아닙니다.
PA를 따르면 고객은 유사한 Exchange Server 배포를 사용하는 조직 커뮤니티의 구성원이 될 수 있습니다. 이 전략을 사용하면 지식 공유가 더 쉬워지고 예기치 않은 상황에 보다 신속하게 응답할 수 있습니다. 자체 지원 조직은 Exchange Server PA 배포가 어떤 모습인지 알고 있으며, 지원 사례 해결을 위해 함께 작업하기 전에 고객의 고도로 사용자 지정 환경을 학습하고 이해하는 데 긴 주기를 소비하지 못하게 합니다.
PA는 아키텍처에서 다음을 수행할 수 있어야 하는 요구 사항과 같은 여러 비즈니스 요구 사항을 염두에 두고 설계되었습니다.
데이터 센터 내의 고가용성 및 데이터 센터 간의 사이트 복원력 모두 포함
각 데이터베이스의 여러 복사본을 지원하여 빠른 활성화를 허용합니다.
메시징 인프라 비용 절감
실패 도메인을 최적화하고 복잡성을 줄여 가용성을 높입니다.
PA의 특정 규범적 특성은 모든 고객이 단어에 대한 단어를 배포할 수 있는 것은 아니라는 것을 의미합니다. 예를 들어 모든 고객에게 여러 데이터 센터가 있는 것은 아닙니다. 일부 고객은 서로 다른 비즈니스 요구 사항 또는 다른 배포 아키텍처가 필요한 준수해야 하는 내부 정책을 가질 수 있습니다. 이러한 범주에 속하고 Exchange 온-프레미스를 배포하려는 경우에도 PA를 최대한 밀접하게 준수하고 요구 사항이나 정책이 강제로 다른 곳에서만 벗어나는 이점이 있습니다. 또는 더 이상 많은 수의 서버를 배포하거나 관리하지 않아도 되는 Microsoft 365 또는 Office 365 항상 고려할 수 있습니다.
PA는 아키텍처를 예측 가능한 복구 모델로 구동하는 데 필요한 경우 복잡성과 중복성을 제거합니다. 오류가 발생하면 영향을 받는 데이터베이스의 다른 복사본이 활성화됩니다.
PA는 다음과 같은 네 가지 초점 영역을 다룹니다.
Exchange Server 2019의 경우 Exchange Server 2016 기본 아키텍처의 네 가지 범주 중 세 가지 범주에는 변경 내용이 없습니다. 네임스페이스 디자인, 데이터 센터 디자인 및 DAG 디자인 영역은 크게 변경되지 않습니다. 우리는 Exchange Server 2016 PA를 밀접하게 따르는 고객 배포에 만족했으며 해당 영역의 권장 사항에서 벗어날 필요가 없습니다.
Exchange Server 2019 PA에서 가장 주목할 만한 변화는 몇 가지 새롭고 흥미로운 기술로 인해 서버 디자인 영역에 중점을 둡니다.
네임스페이스 디자인
Exchange Server 2016의 네임스페이스 계획 및 부하 분산 원칙 문서에서 Ross Smith IV는 Exchange 2016에서 사용할 수 있는 다양한 구성 선택 사항을 설명했으며 이러한 개념은 Exchange Server 2019에 계속 적용됩니다. 네임스페이스의 경우 바인딩된 네임스페이스 (사용자가 특정 데이터 센터에서 작동하도록 기본 설정) 또는 언바운드 네임스페이스를 배포하는 것입니다(사용자가 기본 설정 없이 모든 데이터 센터에 연결하도록 함).
권장되는 방법은 바인딩되지 않은 모델을 사용하여 사이트 복원력 있는 데이터 센터 쌍에 대해 클라이언트 프로토콜당 단일 Exchange 네임스페이스를 배포하는 것입니다(각 데이터 센터는 자체 Active Directory 사이트를 나타내는 것으로 간주됩니다. 아래의 자세한 내용을 참조하세요). 예시:
자동 검색 서비스의 경우: autodiscover.contoso.com
HTTP 클라이언트의 경우: mail.contoso.com
IMAP 클라이언트의 경우: imap.contoso.com
SMTP 클라이언트의 경우: smtp.contoso.com
각 Exchange 네임스페이스는 세션 선호도를 사용하지 않는 계층 7 구성의 두 데이터 센터에서 부하가 분산되어 트래픽의 50%가 데이터 센터 간에 프록시됩니다. 트래픽은 라운드 로빈 DNS, 지역 DNS 또는 기타 유사한 솔루션을 통해 사이트 복원 쌍의 데이터 센터에 동일하게 분산됩니다. 우리의 관점에서, 간단한 솔루션은 가장 복잡하고 관리하기 쉽기 때문에 라운드 로빈 DNS를 사용하는 것이 좋습니다.
고객에게는 Exchange 아키텍처와 연결된 DNS 레코드에 낮은 TTL(Time to Live) 값을 할당해야 합니다. 라운드 로빈 DNS를 사용할 때 전체 데이터 센터 중단이 발생하는 경우 DNS 레코드를 신속하게 업데이트하는 기능을 유지해야 합니다. DNS 쿼리에 대해 반환되지 않도록 오프라인 데이터 센터에서 IP 주소를 제거해야 합니다. 예를 들어 DNS 레코드의 TTL 값이 24시간 더 긴 경우 다운스트림 DNS 캐시가 제대로 업데이트되는 데 최대 하루가 걸릴 수 있습니다. 이 단계를 수행하지 않으면 일부 클라이언트가 나머지 데이터 센터에서 여전히 사용 가능한 IP 주소로 제대로 전환할 수 없습니다. 이전에 오프라인 데이터 센터가 복구되어 서비스를 다시 호스트할 준비가 되면 DNS 레코드에 IP 주소를 다시 추가하는 것을 잊지 마세요.
데이터 센터 선호도는 Office Online Server 팜에 필요하므로 부하 분산 장치가 계층 7을 활용하고 쿠키 기반 지속성을 통해 세션 선호도를 유지 관리하는 데이터 센터별로 네임스페이스가 배포됩니다.
사용자 환경에 사이트 복원력이 있는 데이터 센터 쌍이 여러 개 있는 경우 전 세계 네임스페이스를 하나 만들 것인지 또는 지역 네임스페이스를 사용하여 각 특정 데이터 센터에 대한 트래픽을 제어할지 결정해야 합니다. 결정은 네트워크 토폴로지 및 언바운드 모델 사용과 관련된 비용에 따라 달라집니다. 예를 들어 북아메리카 남아프리카 공화국에 데이터 센터가 있는 경우 이러한 지역 간의 네트워크 연결은 비용이 많이 들 뿐만 아니라 대기 시간이 높아 사용자 고통과 운영 문제가 발생할 수 있습니다. 이 경우 각 지역에 대해 별도의 네임스페이스를 사용하여 바인딩된 모델을 배포하는 것이 좋습니다. 그러나 지리적 DNS와 같은 옵션은 비용이 많이 드는 네트워크 링크가 있는 경우에도 단일 통합 네임스페이스를 배포할 수 있는 기능을 제공합니다. geo-DNS를 사용하면 사용자가 클라이언트의 IP 주소를 기반으로 가장 가까운 데이터 센터로 전송되도록 할 수 있습니다.
사이트 복원력 있는 데이터 센터 쌍 디자인
고가용 성 및 사이트 복원력 아키텍처를 달성하려면 잘 연결된 두 개 이상의 데이터 센터가 있어야 합니다(이상적으로는 왕복 네트워크 대기 시간이 짧고, 그렇지 않으면 복제가 가능하고 클라이언트 환경이 부정적인 영향을 받음). 또한 다른 운영 통신 사업자가 제공하는 중복 네트워크 경로를 통해 데이터 센터를 연결해야 합니다.
여러 데이터 센터에서 Active Directory 사이트를 확장할 수 있도록 지원하지만 PA의 경우 각 데이터 센터가 자체 Active Directory 사이트인 것이 좋습니다. 두 가지 이유가 있습니다.
EXCHANGE SERVER Exchange Server 및 Safety Net의섀도 중복성을 통한 전송 사이트 복원력은 DAG에 둘 이상의 Active Directory 사이트에 멤버가 있는 경우에만 수행할 수 있습니다.
Active Directory는 왕복 대기 시간이 서브넷 간에 10ms보다 클 때 서브넷을 다른 Active Directory 사이트에 배치해야 한다는 지침을 게시 했습니다.
서버 디자인
PA에서 모든 서버는 물리적 서버이며 로컬로 연결된 스토리지를 사용합니다. 물리적 하드웨어는 다음 두 가지 이유로 가상화된 하드웨어가 아닌 배포됩니다.
서버는 최악의 실패 모드 동안 리소스의 80%를 사용하도록 확장됩니다.
가상화에는 약간의 성능 저하와 추가적인 관리 및 복잡성 계층이 추가되어 특히 Exchange Server 기본적으로 동일한 기능을 제공하기 때문에 가치를 추가하지 않는 추가 복구 모드가 도입됩니다.
상용 서버
상용 서버 플랫폼은 PA에서 사용됩니다. 현재 상용 플랫폼은 다음과 같습니다.
2U, 최대 48개의 물리적 프로세서 코어가 있는 이중 소켓 서버(Exchange 2016의 24개 코어에서 증가)
최대 256GB의 메모리(Exchange 2016의 192GB에서 증가)
배터리 기반 쓰기 캐시 컨트롤러
서버 섀시 내의 12개 이상의 드라이브 베이
동일한 섀시 내에서 기존 HDD(회전 플래터 스토리지)와 SSD(반도체 스토리지)를 혼합하는 기능입니다.
확장 이론
2019년 Exchange Server 허용되는 프로세서 및 메모리 용량을 늘렸음에도 불구하고 Exchange Server PG의 권장 사항은 확장보다는 스케일 아웃으로 유지됩니다. 스케일 아웃과 스케일 업은 최대 리소스를 사용하고 많은 수의 사서함으로 채워진 적은 수의 조밀한 서버보다는 서버당 리소스가 약간 적은 더 많은 서버를 배포하는 것을 훨씬 더 많이 볼 수 있습니다. 서버 내에서 적절한 수의 사서함을 찾으면 계획되거나 계획되지 않은 중단의 영향을 줄이고 다른 시스템 병목 상태를 검색할 위험을 줄입니다.
시스템 리소스의 증가로 인해 Exchange 2016의 최대 허용 리소스와 비교할 때 허용되는 최대 리소스를 사용하여 2019년 Exchange Server 선형 성능 향상을 볼 수 있다고 가정하면 안 됩니다. 각 새 버전의 Exchange는 새로운 프로세스와 업데이트를 제공하며, 이로 인해 현재 버전을 이전 버전과 비교하기가 어렵습니다. 서버 디자인을 결정할 때 Microsoft의 모든 크기 조정 지침을 따릅니다.
Storage
추가 드라이브 베이는 사서함 수, 사서함 크기 및 서버의 리소스 확장성에 따라 서버별로 직접 연결될 수 있습니다.
각 서버에는 운영 체제, Exchange 이진 파일, 프로토콜/클라이언트 로그 및 전송 데이터베이스에 대한 단일 RAID1 디스크 쌍이 있습니다.
나머지 스토리지는 JBOD(디스크 무리)로 구성됩니다. 일부 하드웨어 스토리지 컨트롤러는 쓰기 캐싱을 활용하기 위해 각 디스크를 단일 디스크 RAID0 그룹으로 구성해야 할 수 있습니다. 쓰기 캐시가 사용되도록 보장하는 시스템에 대한 적절한 구성을 확인하려면 하드웨어 제조업체에 문의하세요.
Exchange Server 2019 PA는 이전에 언급한 RAID1 디스크 쌍에 없는 모든 항목에 대해 두 가지 스토리지 클래스를 사용하는 것이 좋습니다.
기존 스토리지 클래스
이 스토리지 클래스에는 Exchange Server 데이터베이스 파일 및 Exchange Server 트랜잭션 로그 파일이 포함됩니다. 이러한 디스크는 대용량 7.2K RPM 직렬로 연결된 SCSI(SCSI) 디스크입니다. SATA 디스크도 사용할 수 있지만 SAS에 해당하는 를 사용하여 더 나은 IO 및 더 낮은 연간 실패율을 관찰합니다.
각 디스크의 용량과 IO를 최대한 효율적으로 사용하려면 디스크당 최대 4개의 데이터베이스 복사본이 배포됩니다. 일반적인 런타임 복사 레이아웃은 디스크당 단일 활성 데이터베이스 복사본을 초과하지 않도록 합니다.
기존 스토리지 디스크 풀에 하나 이상의 디스크가 핫 스페어로 예약되어 있습니다. AutoReseed 는 핫 스페어를 활성화하고 데이터베이스 복사 다시 설정을 시작하여 디스크 오류 후 데이터베이스 중복성을 사용하도록 설정하고 신속하게 복원합니다.
반도체 스토리지 클래스
이 스토리지 클래스에는 Exchange 2019의 새 MCDB(MetaCache Database) 파일이 포함되어 있습니다. 이러한 반도체 드라이브는 기존의 2.5"/3.5" SAS 연결 또는 M.2 PCIe 연결 드라이브와 같은 다양한 폼 팩터로 제공됩니다.
고객은 약 5~10%의 추가 스토리지를 반도체 스토리지로 배포해야 합니다. 예를 들어 단일 서버가 기존 스토리지에 28TB의 사서함 데이터베이스 파일을 보유해야 하는 경우 동일한 서버에 대한 추가 스토리지로 1.4-2.8TB의 반도체 스토리지를 추가로 사용하는 것이 좋습니다.
기존 및 반도체 디스크는 가능한 경우 3:1 비율로 배포해야 합니다. 서버 내의 기존 디스크 3개마다 단일 반도체 디스크가 배포됩니다. 이러한 반도체 디스크는 연결된 세 개의 기존 디스크 내의 모든 DB에 대한 MCDB를 보유합니다. 이 권장 사항은 반도체 드라이브 오류가 시스템에 부과할 수 있는 오류 도메인을 제한합니다. SSD가 실패하면 Exchange 2019는 해당 MCDB에 해당 SSD를 사용하여 모든 데이터베이스 복사본을 영향을 받는 데이터베이스에 대해 정상 MCDB 리소스가 있는 다른 DAG 노드로 장애 조치합니다. 데이터베이스 장애 조치(failover) 수를 제한하면 더 많은 데이터베이스가 더 적은 수의 반도체 드라이브를 공유하는 경우 사용자에게 영향을 줄 수 있습니다.
반도체 드라이브 오류 Exchange 고가용성 서비스가 있는 경우 는 영향을 받는 각 데이터베이스에 대해 정상 MCDB가 여전히 존재하는 다른 DAG 노드에 영향을 받는 데이터베이스를 탑재하려고 시도합니다. 어떤 이유로 영향을 받는 데이터베이스 중 하나에 대해 정상 MCDB가 없는 경우 Exchange 고가용성 서비스는 MCDB의 성능 이점 없이 로컬 영향을 받는 데이터베이스 복사본을 실행 상태로 둡니다.
예를 들어 고객이 20개 드라이브를 보유할 수 있는 시스템을 배포하려는 경우 다음과 같은 레이아웃이 있을 수 있습니다.
OS 미러, Exchange 이진 파일 및 전송 데이터베이스용 HDD 2개
Exchange Database 스토리지용 HDD 12개
1 HDD as the AutoReseed spare
누적 데이터베이스 스토리지 용량의 5~10%를 제공하는 Exchange MCDB용 SSD 4개
필요에 따라 고객은 예비 SSD 또는 두 번째 AutoReseed 드라이브를 추가하도록 선택할 수 있습니다.
이 구성은 다음 다이어그램을 사용하여 시각화할 수 있습니다.
위의 예제에서는 기존 데이터베이스 스토리지 공간의 약 6.4%인 120TB의 Exchange 데이터베이스 스토리지와 7.68TB의 MCDB 스토리지가 있습니다. 이러한 양의 MCBD 스토리지를 사용하면 5~10%의 지침 내에서 완벽하게 정렬됩니다. 각 10TB 드라이브는 4개의 데이터베이스 복사본을 보유하며 각 MCDB 드라이브는 12개의 MCDB를 보유합니다.
일반적인 스토리지 설정
기존 또는 반도체 상태이든 Exchange 데이터를 보관하는 모든 디스크는 ReFS 로 포맷되고(무결성 기능이 사용하지 않도록 설정됨) DAG는 AutoReseed가 ReFS를 사용하여 디스크의 형식을 지정하도록 구성됩니다.
Set-DatabaseAvailabilityGroup -Identity <DAGIdentity> -FileSystem ReFS
BitLocker 는 각 디스크를 암호화하는 데 사용되므로 미사용 데이터 암호화를 제공하고 데이터 도난 또는 디스크 교체와 관련된 문제를 완화합니다. 자세한 내용은 Exchange 서버에서 BitLocker 사용을 참조하세요.
데이터베이스 가용성 그룹 디자인
각 사이트 복원력 데이터 센터 쌍 내에는 하나 이상의 DAG가 있습니다. 두 개 이상의 데이터 센터에서 DAG를 확장하지 않는 것이 좋습니다.
DAG 구성
네임스페이스 모델과 마찬가지로 사이트 복원력 데이터 센터 쌍 내의 각 DAG는 DAG의 모든 서버에 동일하게 분산된 활성 복사본이 있는 언바운드 모델에서 작동합니다. 이 모델은 다음과 같습니다.
각 DAG 멤버의 전체 서비스 스택(클라이언트 연결, 복제 파이프라인, 전송 등)이 정상 작업 중에 유효성을 검사하는지 확인합니다.
오류 시나리오 중에 가능한 한 많은 서버에 부하를 분산하여 DAG 내의 나머지 멤버에서만 리소스 사용을 증분합니다.
각 데이터 센터는 대칭이며 각 데이터 센터에서 동일한 수의 DAG 멤버가 있습니다. 즉, 각 DAG에는 짝수의 서버가 있으며 쿼럼 유지 관리에 미러링 모니터 서버를 사용합니다.
DAG는 Exchange 2019의 기본 구성 요소입니다. DAG 크기와 관련하여 참여 멤버 노드 수가 많은 DAG는 더 많은 중복성과 리소스를 제공합니다. PA 내에서 목표는 일반적으로 8명으로 구성된 DAG부터 시작하여 요구 사항을 충족하는 데 필요한 서버 수를 늘리는 더 많은 수의 멤버 노드가 있는 DAG를 배포하는 것입니다. 확장성이 기존 데이터베이스 복사 레이아웃에 대한 우려를 야기하는 경우에만 새 DAG를 만들어야 합니다.
DAG 네트워크 디자인
PA는 클라이언트 연결 및 데이터 복제 모두에 단일 비팀 네트워크 인터페이스를 사용합니다. 단일 네트워크 인터페이스는 궁극적으로 서버 오류가 발생하든 네트워크 오류가 발생하든 관계없이 표준 복구 모델을 달성하는 것이 목표이므로 필요한 모든 것입니다. 결과는 동일합니다. 데이터베이스 복사본은 DAG 내의 다른 서버에서 활성화됩니다. 이러한 아키텍처 변경으로 네트워크 스택이 간소화되고 하트비트 교차 대화를 수동으로 제거할 필요가 없습니다.
미러링 모니터 서버 배치
미러링 모니터 서버의 배치는 아키텍처가 자동 데이터 센터 장애 조치(failover) 기능을 제공할 수 있는지 또는 사이트 오류가 있는 경우 서비스를 사용하도록 설정하기 위해 수동 활성화가 필요한지 여부를 결정합니다.
조직에 DAG가 배포된 사이트 복원력 데이터 센터 쌍에 영향을 주는 네트워크 오류로부터 격리된 네트워크 인프라가 있는 세 번째 위치가 있는 경우 해당 세 번째 위치에 DAG의 미러링 모니터 서버를 배포하는 것이 좋습니다. 이 구성을 통해 DAG는 중단된 데이터 센터에 관계없이 데이터 센터 수준 오류 이벤트에 대한 응답으로 데이터베이스를 다른 데이터 센터에 자동으로 장애 조치(failover)할 수 있습니다.
조직에 세 번째 위치가 없는 경우 Azure에 서버 감시를 배치하는 것이 좋습니다. 또는 사이트 복원력 있는 데이터 센터 쌍 내의 데이터 센터 중 하나에 미러링 모니터 서버를 배치합니다. 사이트 복원력 데이터 센터 쌍 내에 여러 DAG가 있는 경우 모든 DAG에 대한 미러링 모니터 서버(일반적으로 대부분의 사용자가 물리적으로 위치한 데이터 센터)에 배치합니다. 또한 각 DAG에 대한 PAM(기본 활성 관리자)도 동일한 데이터 센터에 있는지 확인합니다.
Exchange Server 2019 및 모든 이전 버전은 Windows Server 2016 장애 조치(failover) 클러스터에 처음 도입된 클라우드 감시 기능의 사용을 지원하지 않습니다.
데이터 복원력
데이터 복원력은 여러 데이터베이스 복사본을 배포하여 달성됩니다. PA에서 데이터베이스 복사본은 사이트 복원력 있는 데이터 센터 쌍에 분산되어 사서함 데이터가 소프트웨어, 하드웨어 및 데이터 센터 오류로부터 보호되도록 합니다.
각 데이터베이스에는 4개의 복사본이 있으며 각 데이터 센터에는 2개의 복사본이 있습니다. 즉, 최소한 PA에는 4개의 서버가 필요합니다. 이러한 4개의 복사본 중 3개는 고가용성으로 구성됩니다. 네 번째 복사본(활성화 기본 설정 번호가 가장 높은 복사본)은 지연된 데이터베이스 복사본으로 구성됩니다. 서버 디자인으로 인해 데이터베이스의 각 복사본은 다른 복사본과 격리되어 오류 도메인을 줄이고 DAG: "A" 외에도 솔루션의 전체 가용성을 높입니다.
지연된 데이터베이스 복사의 목적은 시스템 전체의 치명적인 논리적 손상의 드문 이벤트에 대한 복구 메커니즘을 제공하는 것입니다. 개별 사서함 복구 또는 사서함 항목 복구를 위한 것이 아닙니다.
지연된 데이터베이스 복사본은 7일간의 ReplayLagTime으로 구성됩니다. 또한 지연되지 않은 복사본의 손실로 인해 가용성이 손상될 때 지연된 복사본에 대한 동적 로그 파일 재생을 제공하도록 Replay Lag Manager도 사용할 수 있습니다.
이러한 방식으로 지연된 데이터베이스 복사본을 사용하면 지연된 데이터베이스 복사본이 보장된 특정 시점 백업이 아니라는 것을 이해하는 것이 중요합니다. 지연된 데이터베이스 복사본은 디스크 오류로 인해 지연된 복사본이 포함된 디스크가 손실되는 기간, 지연된 복사본이 HA 복사본이 되는 기간(자동 재생 중단으로 인해) 및 지연된 데이터베이스 복사본이 재생 큐를 다시 빌드하는 기간으로 인해 일반적으로 약 90%의 가용성 임계값을 갖습니다.
우발적이거나 악의적인 항목 삭제로부터 보호하기 위해 단일 항목 복구 또는 현재 위치 보존 기술이 사용되며 삭제된 항목 보존 기간은 정의된 항목 수준 복구 SLA를 충족하거나 초과하는 값으로 설정됩니다.
이러한 모든 기술이 작동하므로 기존 백업은 필요하지 않습니다. 따라서 PA는 Exchange Native Data Protection을 사용합니다.
Office Online Server 디자인
최소한 Exchange 2019 서버를 호스트하는 각 데이터 센터에 두 개 이상의 OOS 노드가 있는 OOS(Office Online Server) 팜을 배포하려고 합니다. 각 Office Online Server 8개 이상의 프로세서 코어, 32GB의 메모리 및 로그 파일 전용 40GB 이상의 공간이 있어야 합니다. Exchange 2019 사서함 서버는 사용자에게 파일 콘텐츠를 렌더링하기 위해 서버 간에 가능한 대기 시간 및 가능한 가장 높은 대역폭을 보장하기 위해 데이터 센터의 로컬 OOS 팜을 사용하도록 구성해야 합니다.
요약
Exchange Server 2019는 이전 버전의 Exchange에 도입된 투자를 지속적으로 개선하고 있으며 Microsoft 365 및 Office 365 사용하기 위해 처음 발명된 추가 기술을 소개합니다.
기본 아키텍처에 맞춰 이러한 변경 내용을 활용하고 가능한 최상의 온-프레미스 사용자 환경을 제공합니다. 신뢰할 수 있고 예측 가능하며 복원력이 뛰어난 Exchange 배포의 전통을 이어갈 것입니다.