Microsoft 365용 ExpressRoute 구현
이 문서는 Microsoft 365 Enterprise 적용됩니다.
Microsoft 365용 ExpressRoute는 많은 인터넷 연결 Microsoft 365 서비스에 대한 대체 라우팅 경로를 제공합니다. Microsoft 365용 ExpressRoute 아키텍처는 해당 IP 접두사를 네트워크에 후속 재배포하기 위해 인터넷을 통해 이미 프로비전된 ExpressRoute 회로에 액세스할 수 있는 Microsoft 365 서비스의 공용 IP 접두사를 보급하는 것을 기반으로 합니다. ExpressRoute를 사용하면 여러 Microsoft 365 서비스에 대해 인터넷을 통해 ExpressRoute를 통해 여러 가지 라우팅 경로를 효과적으로 사용하도록 설정합니다. 네트워크의 이러한 라우팅 상태는 내부 네트워크 토폴로지 설계 방식에 큰 변화를 나타낼 수 있습니다.
참고
대부분의 경우 서비스에 가장 적합한 연결 모델을 제공하지 않으므로 Microsoft 365용 ExpressRoute는 권장되지 않습니다. 따라서 이 연결 모델을 사용하려면 Microsoft 권한 부여가 필요합니다. Microsoft는 필요한 드문 시나리오에서만 모든 고객 요청을 검토하고 Microsoft 365용 ExpressRoute에 권한을 부여합니다. 자세한 내용은 Microsoft 365용 ExpressRoute 가이드 를 읽고 생산성, 네트워크 및 보안 팀이 포함된 문서를 포괄적으로 검토한 후 필요한 경우 Microsoft 계정 팀과 협력하여 예외를 제출하세요. Microsoft 365에 대한 경로 필터를 만들려고 하는 권한이 없는 구독에는 오류 메시지가 표시됩니다.
핵심 네트워크와 인터넷에 삽입된 경로가 있는 전용 회로를 통해 라우팅을 사용할 수 있는 네트워크 복잡성을 수용하기 위해 Microsoft 365용 ExpressRoute 구현을 신중하게 계획해야 합니다. 사용자와 팀이 이 가이드에서 자세한 계획 및 테스트를 수행하지 않는 경우 ExpressRoute 회로를 사용하도록 설정할 때 간헐적으로 또는 Microsoft 365 서비스에 대한 연결이 완전히 끊어질 위험이 높습니다.
성공적인 구현을 위해서는 인프라 요구 사항을 분석하고, 자세한 네트워크 평가 및 디자인을 살펴보고, 단계적 및 제어된 방식으로 롤아웃을 신중하게 계획하고, 자세한 유효성 검사 및 테스트 계획을 빌드해야 합니다. 대규모 분산 환경의 경우 구현이 몇 개월에 걸쳐 있는 것을 보는 것은 드문 일이 아닙니다. 이 가이드는 미리 계획하는 데 도움이 되도록 설계되었습니다.
대규모 성공적인 배포는 계획하는 데 6개월이 걸릴 수 있으며 네트워킹, 방화벽 및 프록시 서버 관리자, Microsoft 365 관리자, 보안, 최종 사용자 지원, 프로젝트 관리 및 임원 후원을 포함하여 organization 여러 영역의 팀 구성원을 포함할 수 있습니다. 계획 프로세스에 투자하면 배포 실패로 인해 가동 중지 시간 또는 복잡하고 비용이 많이 드는 문제 해결이 발생할 가능성이 줄어듭니다.
이 구현 가이드를 시작하기 전에 다음 필수 구성 요소가 완료될 것으로 예상합니다.
ExpressRoute가 권장되고 승인되었는지 확인하기 위해 네트워크 평가를 완료했습니다.
ExpressRoute 네트워크 서비스 공급자를 선택했습니다. ExpressRoute 파트너 및 피어링 위치에 대한 세부 정보를 찾습니다.
ExpressRoute 설명서를 이미 읽고 이해했으며 내부 네트워크는 ExpressRoute 필수 구성 요소를 종단 간 충족할 수 있습니다.
팀은 , https://aka.ms/ert에서 모든 공개 지침 및 설명서를 읽었으며 채널 9에서 https://aka.ms/expressrouteoffice365Microsoft 365용 Azure ExpressRoute 교육 시리즈를 시청하여 다음을 비롯한 중요한 기술 세부 정보를 이해했습니다.
SaaS 서비스의 인터넷 종속성입니다.
비대칭 경로를 방지하고 복잡한 라우팅을 처리하는 방법입니다.
경계 보안, 가용성 및 애플리케이션 수준 컨트롤을 통합하는 방법입니다.
먼저 요구 사항을 수집합니다.
먼저 organization 내에서 채택할 기능 및 서비스를 결정합니다. 사용할 다른 Microsoft 365 서비스의 기능과 해당 기능을 사용하여 사용자를 호스트할 네트워크의 위치를 결정해야 합니다. 시나리오 카탈로그를 사용하면 각 시나리오에 필요한 네트워크 특성을 추가해야 합니다. 인바운드 및 아웃바운드 네트워크 트래픽 흐름 및 Microsoft 365 엔드포인트를 ExpressRoute를 통해 사용할 수 있는지 여부와 같은 경우
organization 요구 사항을 수집하려면 다음을 수행합니다.
organization 사용 중인 Microsoft 365 서비스에 대한 인바운드 및 아웃바운드 네트워크 트래픽을 카탈로그화합니다. 다양한 Microsoft 365 시나리오에 필요한 흐름에 대한 설명은 Microsoft 365 URL 및 IP 주소 범위 페이지를 참조하세요.
내부 WAN 백본 및 토폴로지, 위성 사이트 연결, 마지막 마일 사용자 연결, 네트워크 경계 송신 지점으로 라우팅 및 프록시 서비스에 대한 세부 정보를 보여 주는 기존 네트워크 토폴로지에 대한 설명서를 수집합니다.
Microsoft 365 및 기타 Microsoft 서비스가 연결할 네트워크 다이어그램에서 인터넷 및 제안된 ExpressRoute 연결 경로를 모두 보여 주는 인바운드 서비스 엔드포인트를 식별합니다.
현재 인터넷에 송신이 있는 위치와 ExpressRoute 피어링 위치로 송신하도록 제안된 위치와 함께 위치 간의 모든 지리적 사용자 위치 및 WAN 연결을 식별합니다.
프록시, 방화벽 등과 같은 모든 에지 디바이스를 식별하고 인터넷 및 ExpressRoute를 통해 이동하는 흐름과의 관계를 카탈로그화합니다.
최종 사용자가 인터넷 및 ExpressRoute 흐름 모두에 대한 직접 라우팅 또는 간접 애플리케이션 프록시를 통해 Microsoft 365 서비스에 액세스할지 여부를 문서화합니다.
네트워크 다이어그램에 테넌트 및 meet-me 위치의 위치를 추가합니다.
주요 사용자 위치에서 Microsoft 365까지 예상되는 네트워크 성능 및 대기 시간 특성을 예측합니다. Microsoft 365는 전역적이고 분산된 서비스 집합이며 사용자는 테넌트 위치와 다를 수 있는 위치에 연결합니다. 이러한 이유로 ExpressRoute 및 인터넷 연결을 통해 사용자와 Microsoft 글로벌 네트워크의 가장 가까운 에지 간의 대기 시간을 측정하고 최적화하는 것이 좋습니다. 네트워크 평가의 결과를 사용하여 이 작업을 도울 수 있습니다.
새 ExpressRoute 연결에서 충족해야 하는 회사 네트워크 보안 및 고가용성 요구 사항을 나열합니다. 예를 들어 사용자가 인터넷 송신 또는 ExpressRoute 회로 오류가 발생할 경우 Microsoft 365에 계속 액세스하려면 어떻게 해야 할까요?
인터넷 경로를 사용할 인바운드 및 아웃바운드 Microsoft 365 네트워크 흐름과 ExpressRoute를 사용하는 것을 문서화합니다. 사용자의 지리적 위치에 대한 세부 정보와 온-프레미스 네트워크 토폴로지의 세부 정보를 사용하려면 계획이 한 사용자 위치와 다른 사용자 위치와 달라야 할 수 있습니다.
아웃바운드 및 인바운드 네트워크 트래픽 카탈로그
라우팅 및 기타 네트워크 복잡성을 최소화하려면 규정 요구 사항 또는 네트워크 평가의 결과로 전용 연결을 통과하는 데 필요한 네트워크 트래픽 흐름에만 Microsoft 365용 ExpressRoute를 사용하는 것이 좋습니다. 또한 ExpressRoute 라우팅의 scope 스테이징하고 구현 프로젝트의 서로 다른 고유한 단계로 아웃바운드 및 인바운드 네트워크 트래픽 흐름에 접근하는 것이 좋습니다. 사용자가 시작한 아웃바운드 네트워크 트래픽 흐름에만 대해 Microsoft 365용 ExpressRoute를 배포하고 인터넷을 통해 인바운드 네트워크 트래픽 흐름을 그대로 두면 토폴로지 복잡성의 증가와 추가 비대칭 라우팅 가능성을 도입할 위험을 제어하는 데 도움이 될 수 있습니다.
네트워크 트래픽 카탈로그에는 온-프레미스 네트워크와 Microsoft 간에 가질 모든 인바운드 및 아웃바운드 네트워크 연결 목록이 포함되어야 합니다.
아웃바운드 네트워크 트래픽 흐름은 Microsoft 서비스의 대상이 있는 내부 클라이언트 또는 서버와 같은 온-프레미스 환경에서 연결이 시작되는 모든 시나리오입니다. 이러한 연결은 Microsoft 365 경로의 프록시 서버, 방화벽 또는 기타 네트워킹 디바이스를 통과하는 경우와 같이 Microsoft 365 또는 간접 연결일 수 있습니다.
인바운드 네트워크 트래픽 흐름은 Microsoft 클라우드에서 온-프레미스 호스트로의 연결이 시작되는 모든 시나리오입니다. 이러한 연결은 일반적으로 고객 보안 정책이 외부에서 시작된 흐름에 필요한 방화벽 및 기타 보안 인프라를 통과해야 합니다.
경로 대칭 확인 섹션을 읽어 인바운드 트래픽을 보낼 서비스를 확인하고 Microsoft 365 엔드포인트 참조 문서에서 Microsoft 365용 ExpressRoute로 표시된 열을 찾아 나머지 연결 정보를 확인합니다.
아웃바운드 연결이 필요한 각 서비스에 대해 네트워크 라우팅, 프록시 구성, 패킷 검사 및 대역폭 요구 사항을 포함하여 서비스에 대한 계획된 연결을 설명하려고 합니다.
인바운드 연결이 필요한 각 서비스에 대해 몇 가지 추가 정보가 필요합니다. Microsoft 클라우드의 서버는 온-프레미스 네트워크에 대한 연결을 설정합니다. 연결이 올바르게 이루어지도록 하려면 다음을 포함하여 이 연결의 모든 측면을 설명해야 합니다. 이러한 인바운드 연결을 허용하는 서비스에 대한 공용 DNS 항목, CIDR 형식의 IPv4 IP 주소, ISP 장비가 관련되어 있으며 이러한 연결에 대해 인바운드 NAT 또는 원본 NAT가 처리되는 방식.
인터넷 또는 ExpressRoute를 통해 연결하는지 여부에 관계없이 인바운드 연결을 검토하여 비대칭 라우팅이 도입되지 않았는지 확인해야 합니다. 경우에 따라 Microsoft 365 서비스가 인바운드 연결을 시작하는 온-프레미스 엔드포인트도 다른 Microsoft 및 비 Microsoft 서비스에서 액세스해야 할 수 있습니다. Microsoft 365용으로 이러한 서비스에 대한 ExpressRoute 라우팅을 사용하도록 설정해도 다른 시나리오가 중단되지 않는 것이 가장 중요합니다. 대부분의 경우 고객은 ExpressRoute를 사용하도록 설정한 후에도 Microsoft의 인바운드 흐름이 대칭으로 유지되도록 원본 기반 NAT와 같은 내부 네트워크에 대한 특정 변경 내용을 구현해야 할 수 있습니다.
다음은 필요한 세부 수준의 샘플입니다. 이 경우 Exchange 하이브리드는 ExpressRoute를 통해 온-프레미스 시스템으로 라우팅됩니다.
| 연결 속성 | 값 |
|---|---|
| 네트워크 트래픽 방향 |
인바운드 |
| 서비스 |
Exchange 하이브리드 |
| 공용 Microsoft 365 엔드포인트(원본) |
Exchange Online(IP 주소) |
| 공용 온-프레미스 엔드포인트(대상) |
5.5.5.5 |
| 공용(인터넷) DNS 항목 |
Autodiscover.contoso.com |
| 이 온-프레미스 엔드포인트는 다른(타사 365) Microsoft 서비스에서 사용할 수 있나요? |
아니요 |
| 이 온-프레미스 엔드포인트는 인터넷의 사용자/시스템에서 사용되나요? |
예 |
| 퍼블릭 엔드포인트를 통해 게시된 내부 시스템 |
Exchange Server 클라이언트 액세스 역할(온-프레미스) 192.168.101, 192.168.102, 192.168.103 |
| 퍼블릭 엔드포인트의 IP 보급 |
인터넷: 5.5.0.0/16 ExpressRoute로: 5.5.5.0/24 |
| 보안/경계 컨트롤 |
인터넷 경로: DeviceID_002 ExpressRoute 경로: DeviceID_003 |
| 고가용성 |
2개 지역 중복/ExpressRoute 회로에서 활성/활성 - 시카고 및 댈러스 |
| 경로 대칭 컨트롤 |
방법: 원본 NAT 인터넷 경로: 192.168.5.5 ExpressRoute 경로에 대한 원본 NAT 인바운드 연결: 192.168.1.0(시카고) 및 192.168.2.0(댈러스)에 대한 원본 NAT 연결 |
아웃바운드 전용인 서비스의 샘플은 다음과 같습니다.
| 연결 속성 | 값 |
|---|---|
| 네트워크 트래픽 방향 |
아웃바운드 |
| 서비스 |
SharePoint |
| 온-프레미스 엔드포인트(원본) |
사용자 워크스테이션 |
| 공용 Microsoft 365 엔드포인트(대상) |
SharePoint(IP 주소) |
| 공용(인터넷) DNS 항목 |
*.sharepoint.com(및 기타 FQDN) |
| CDN 조회 |
cdn.sharepointonline.com(및 더 많은 FQDN) - CDN 공급자가 유지 관리하는 IP 주소) |
| 사용 중인 IP 광고 및 NAT |
인터넷 경로/원본 NAT: 1.1.1.0/24 ExpressRoute 경로/원본 NAT: 1.1.2.0/24(시카고) 및 1.1.3.0/24(댈러스) |
| 연결 방법 |
인터넷: 계층 7 프록시를 통해(.pac 파일) ExpressRoute: 직접 라우팅(프록시 없음) |
| 보안/경계 컨트롤 |
인터넷 경로: DeviceID_002 ExpressRoute 경로: DeviceID_003 |
| 고가용성 |
인터넷 경로: 중복 인터넷 송신 ExpressRoute 경로: 2개의 지역 중복 ExpressRoute 회로에서 활성/활성 '핫 포테이토' 라우팅 - 시카고 및 댈러스 |
| 경로 대칭 컨트롤 |
메서드: 모든 연결에 대한 원본 NAT |
지역 연결이 있는 네트워크 토폴로지 디자인
서비스와 연결된 네트워크 트래픽 흐름을 이해한 후에는 이러한 새로운 연결 요구 사항을 통합하고 Microsoft 365용 ExpressRoute를 사용하기 위해 변경한 내용을 보여 주는 네트워크 다이어그램을 만들 수 있습니다. 다이어그램에는 다음이 포함되어야 합니다.
Microsoft 365 및 기타 서비스에 액세스할 수 있는 모든 사용자 위치입니다.
모든 인터넷 및 ExpressRoute 송신 지점.
라우터, 방화벽, 애플리케이션 프록시 서버 및 침입 검색/방지를 포함하여 네트워크 내/외부 연결을 관리하는 모든 아웃바운드 및 인바운드 디바이스입니다.
ADFS 웹 애플리케이션 프록시 서버의 연결을 허용하는 내부 ADFS 서버와 같은 모든 인바운드 트래픽에 대한 내부 대상입니다.
보급될 모든 IP 서브넷의 카탈로그
사용자가 Microsoft 365에 액세스할 각 위치를 식별하고 ExpressRoute에 사용할 meet-me 위치를 나열합니다.
ExpressRoute에서 학습한 Microsoft IP 접두사가 허용, 필터링 및 전파되는 내부 네트워크 토폴로지의 위치 및 부분입니다.
네트워크 토폴로지는 각 네트워크 세그먼트의 지리적 위치와 ExpressRoute 및/또는 인터넷을 통해 Microsoft 네트워크에 연결하는 방법을 보여 줍니다.
아래 다이어그램은 사용자가 Microsoft 365로의 인바운드 및 아웃바운드 라우팅 광고와 함께 Microsoft 365를 사용할 각 위치를 보여 줍니다.
아웃바운드 트래픽의 경우 사람들은 다음 세 가지 방법 중 하나로 Microsoft 365에 액세스합니다.
캘리포니아에있는 사람들을위한 북아메리카 모임 - 나 위치를 통해.
홍콩 특별 행정구에서 홍콩 특별 행정구의 모임 위치를 통해 홍콩 특별 행정구에 있는 사람들을 위한 장소.
더 적은 수의 사람들이 있고 ExpressRoute 회로가 프로비전되지 않은 방글라데시의 인터넷을 통해.
마찬가지로 Microsoft 365의 인바운드 네트워크 트래픽은 다음 세 가지 방법 중 하나로 반환됩니다.
캘리포니아에있는 사람들을위한 북아메리카 모임 - 나 위치를 통해.
홍콩 특별 행정구에서 홍콩 특별 행정구의 모임 위치를 통해 홍콩 특별 행정구에 있는 사람들을 위한 장소.
더 적은 수의 사람들이 있고 ExpressRoute 회로가 프로비전되지 않은 방글라데시의 인터넷을 통해.
적절한 모임 위치 확인
ExpressRoute 회로가 네트워크를 Microsoft 네트워크에 연결하는 물리적 위치인 meet-me 위치 선택은 사람들이 Microsoft 365에 액세스할 위치의 영향을 받습니다. SaaS 제품으로서 Microsoft 365는 Azure와 동일한 방식으로 IaaS 또는 PaaS 지역 모델에서 작동하지 않습니다. 대신 Microsoft 365는 사용자가 여러 데이터 센터 및 지역의 엔드포인트에 연결해야 할 수 있는 분산된 공동 작업 서비스 집합으로, 사용자의 테넌트가 호스트되는 위치나 지역에 반드시 있을 필요는 없습니다.
즉, Microsoft 365용 ExpressRoute에 대한 meet-me 위치를 선택할 때 가장 중요한 고려 사항은 organization 사용자가 연결하는 위치입니다. 최적의 Microsoft 365 연결에 대한 일반적인 권장 사항은 라우팅을 구현하여 Microsoft 365 서비스에 대한 사용자 요청이 가장 짧은 네트워크 경로를 통해 Microsoft 네트워크로 전달되도록 하는 것입니다. 이는 종종 '핫 포테이토' 라우팅이라고도 합니다. 예를 들어 대부분의 Microsoft 365 사용자가 하나 또는 두 개의 위치에 있는 경우 해당 사용자의 위치와 가장 가까운 meet-me 위치를 선택하면 최적의 디자인이 만들어집니다. 회사에 여러 지역에 많은 사용자 인구가 있는 경우 여러 ExpressRoute 회로 및 meet-me 위치가 있는 것을 고려할 수 있습니다. 일부 사용자 위치의 경우 Microsoft 네트워크 및 Microsoft 365의 최단/최적 경로는 내부 WAN 및 ExpressRoute meet-me 지점이 아니라 인터넷을 통해서일 수 있습니다.
사용자와 상대적으로 근접한 지역 내에서 선택할 수 있는 여러 모임 위치가 있는 경우가 많습니다. 다음 표를 작성하여 결정을 안내합니다.
캘리포니아와 뉴욕의 계획된 ExpressRoute meet-me 위치
| 위치 |
인원 |
인터넷 송신을 통해 Microsoft 네트워크에 예상되는 대기 시간 |
ExpressRoute를 통해 Microsoft 네트워크에 대한 예상 대기 시간 |
|---|---|---|---|
| Los Angeles |
10,000 |
~15ms |
~10ms(실리콘밸리 경유) |
| 워싱턴 DC |
15,000 |
~20ms |
~10ms(뉴욕 경유) |
| 달라스 |
5,000 |
~15ms |
~40ms(뉴욕 경유) |
Microsoft 365 지역, ExpressRoute 네트워크 서비스 공급자 meet-me 위치 및 위치별 사용자 수량을 보여 주는 글로벌 네트워크 아키텍처가 개발되면 최적화를 수행할 수 있는지 식별하는 데 사용할 수 있습니다. 또한 meet-me 위치를 가져오기 위해 트래픽이 먼 위치로 라우팅되는 전역 헤어핀 네트워크 연결을 표시할 수도 있습니다. 전역 네트워크의 헤어핀이 발견되면 계속하기 전에 수정해야 합니다. 다른 meet-me 위치를 찾거나 선택적 인터넷 브레이크아웃 송신 지점을 사용하여 헤어핀을 방지합니다.
첫 번째 다이어그램은 북아메리카 두 개의 물리적 위치가 있는 고객의 예를 보여줍니다. Office 위치, Microsoft 365 테넌트 위치 및 ExpressRoute meet-me 위치에 대한 몇 가지 선택에 대한 정보를 볼 수 있습니다. 이 예제에서 고객은 다음 두 가지 원칙에 따라 meet-me 위치를 순서대로 선택했습니다.
organization 있는 사람들과 가장 가깝습니다.
Microsoft 365가 호스트되는 Microsoft 데이터 센터와 가장 가깝습니다.
이 개념을 약간 더 확장하면 두 번째 다이어그램은 유사한 정보와 의사 결정에 직면한 다국적 고객의 예를 보여줍니다. 이 고객은 방글라데시에 소규모 사무실을 두고 있으며, 10명으로 구성된 소규모 팀만이 이 지역에서 자신의 발자국을 늘리는 데 집중했습니다. 첸나이에는 meet-me 위치와 첸나이에서 호스팅되는 Microsoft 365가 있는 Microsoft 데이터 센터가 있으므로 모임 위치가 합리적입니다. 그러나 10명에게는 추가 회로 비용이 부담스럽습니다. 네트워크를 살펴보면 네트워크를 통해 네트워크 트래픽을 보내는 데 관련된 대기 시간이 다른 ExpressRoute 회로를 획득하기 위해 자본을 소비하는 것보다 더 효과적인지 확인해야 합니다.
또는 방글라데시의 10명은 소개 다이어그램에 나와 있고 아래에서 재현한 것처럼 내부 네트워크에서 라우팅하는 것보다 인터넷을 통해 Microsoft 네트워크로 전송되는 네트워크 트래픽으로 더 나은 성능을 경험할 수 있습니다.
Microsoft 365용 ExpressRoute 구현 계획 Create
구현 계획에는 ExpressRoute 구성의 기술 세부 정보와 네트워크의 다른 모든 인프라 구성 세부 정보(예: 다음)가 모두 포함됩니다.
ExpressRoute와 인터넷 간에 분할되는 서비스를 계획합니다.
대역폭, 보안, 고가용성 및 장애 조치(failover)를 계획합니다.
다양한 위치에 대한 적절한 라우팅 경로 최적화를 포함하여 인바운드 및 아웃바운드 라우팅 디자인
ExpressRoute 경로를 네트워크에 보급할 시간과 클라이언트가 인터넷 또는 ExpressRoute 경로를 선택하는 메커니즘을 결정합니다. 예를 들어 직접 라우팅 또는 애플리케이션 프록시입니다.
보낸 사람 정책 프레임워크 항목을 포함하여 DNS 레코드 변경 내용을 계획합니다.
아웃바운드 및 인바운드 원본 NAT를 포함한 NAT 전략을 계획합니다.
인터넷 및 ExpressRoute 네트워크 경로를 모두 사용하여 라우팅 계획
초기 배포의 경우 인바운드 메일 또는 하이브리드 연결과 같은 모든 인바운드 서비스가 인터넷을 사용하는 것이 좋습니다.
PAC/WPAD 파일, 기본 경로, 프록시 서버 및 BGP 경로 보급 알림 구성과 같은 최종 사용자 클라이언트 LAN 라우팅을 계획합니다.
프록시 서버, 방화벽 및 클라우드 프록시를 포함한 경계 라우팅을 계획합니다.
대역폭, 보안, 고가용성 및 장애 조치(failover) 계획
각 주요 Microsoft 365 워크로드에 필요한 대역폭 계획을 Create. Exchange Online, SharePoint 및 비즈니스용 Skype Online 대역폭 요구 사항을 별도로 예측합니다. Exchange Online 및 비즈니스용 Skype 위해 제공한 추정 계산기를 시작 위치로 사용할 수 있습니다. 그러나 organization 대역폭 요구 사항을 완전히 이해하려면 사용자 프로필 및 위치의 대표적인 샘플이 포함된 파일럿 테스트가 필요합니다.
각 인터넷 및 ExpressRoute 송신 위치에서 보안을 처리하는 방법을 계획에 추가하고 Microsoft 365에 대한 모든 ExpressRoute 연결은 공용 피어링을 사용하며 외부 네트워크에 연결하는 회사 보안 정책에 따라 계속 보호되어야 합니다.
중단 유형과 해당 사용자가 가장 간단한 방식으로 전체 용량으로 작업을 수행할 수 있는 방법에 대한 세부 정보를 계획에 추가합니다.
지터, 대기 시간, 혼잡 및 헤드룸에 대한 비즈니스용 Skype 요구 사항을 포함한 대역폭 요구 사항 계획
비즈니스용 Skype Online에는 비즈니스용 Skype Online의 미디어 품질 및 네트워크 연결 성능 문서에 자세히 설명된 특정 추가 네트워크 요구 사항도 있습니다.
Azure ExpressRoute에 대한 대역폭 계획 섹션을 읽어보세요. 파일럿 사용자와 함께 대역폭 평가를 수행할 때 기준 및 성능 기록을 사용하여 가이드 Microsoft 365 성능 튜닝을 사용할 수 있습니다.
고가용성 요구 사항 계획
요구 사항을 충족하고 이를 업데이트된 네트워크 토폴로지 다이어그램에 통합하기 위한 고가용성 계획을 Create. Azure ExpressRoute를 사용하여 고가용성 및 장애 조치(failover) 섹션을 읽어보세요.
네트워크 보안 요구 사항 계획
네트워크 보안 요구 사항을 충족하고 이를 업데이트된 네트워크 토폴로지 다이어그램에 통합하는 계획을 Create. Microsoft 365 시나리오용 Azure ExpressRoute에 보안 컨트롤 적용 섹션을 읽어보세요.
아웃바운드 서비스 연결 디자인
Microsoft 365용 ExpressRoute에는 익숙하지 않을 수 있는 아웃바운드 네트워크 요구 사항이 있습니다. 특히 Microsoft 365에 대한 사용자 및 네트워크를 나타내고 Microsoft에 대한 아웃바운드 네트워크 연결의 원본 엔드포인트 역할을 하는 IP 주소는 아래에 설명된 특정 요구 사항을 따라야 합니다.
엔드포인트는 ExpressRoute 연결을 제공하는 회사 또는 이동 통신 사업자에 등록된 공용 IP 주소여야 합니다.
엔드포인트는 Microsoft에 보급되고 ExpressRoute에서 유효성을 검사/수락해야 합니다.
엔드포인트는 동일하거나 더 선호되는 라우팅 메트릭을 사용하여 인터넷에 보급되어서는 안 됩니다.
ExpressRoute를 통해 구성되지 않은 Microsoft 서비스에 연결하는 데 엔드포인트를 사용하면 안 됩니다.
네트워크 디자인이 이러한 요구 사항을 충족하지 않는 경우 사용자가 경로 블랙 홀링 또는 비대칭 라우팅으로 인해 Microsoft 365 및 기타 Microsoft 서비스에 대한 연결 오류가 발생할 위험이 높습니다. 이 문제는 Microsoft 서비스에 대한 요청이 ExpressRoute를 통해 라우팅되지만 응답이 인터넷을 통해 다시 라우팅되거나 그 반대로 라우팅되고 방화벽과 같은 상태 저장 네트워크 디바이스에서 응답이 삭제되는 경우에 발생합니다.
위의 요구 사항을 충족하는 데 사용할 수 있는 가장 일반적인 방법은 네트워크의 일부로 구현되거나 ExpressRoute 통신 사업자가 제공하는 원본 NAT를 사용하는 것입니다. 원본 NAT를 사용하면 ExpressRoute 및 에서 인터넷 네트워크의 세부 정보 및 개인 IP 주소를 추상화할 수 있습니다. 적절한 IP 경로 보급 알림과 함께 경로 대칭을 보장하는 쉬운 메커니즘을 제공합니다. ExpressRoute 피어링 위치와 관련된 상태 저장 네트워크 디바이스를 사용하는 경우 경로 대칭을 보장하려면 각 ExpressRoute 피어링에 대해 별도의 NAT 풀을 구현해야 합니다.
ExpressRoute NAT 요구 사항에 대해 자세히 알아보세요.
아웃바운드 연결에 대한 변경 내용을 네트워크 토폴로지 다이어그램에 추가합니다.
인바운드 서비스 연결 디자인
대부분의 엔터프라이즈 Microsoft 365 배포에서는 Exchange, SharePoint 및 ADFS 인프라를 사용한 비즈니스용 Skype 하이브리드 시나리오, 사서함 마이그레이션 및 인증과 같은 Microsoft 365에서 온-프레미스 서비스로의 인바운드 연결을 가정합니다. ExpressRoute에서 아웃바운드 연결을 위해 온-프레미스 네트워크와 Microsoft 간에 추가 라우팅 경로를 사용하도록 설정하면 이러한 흐름이 인터넷을 계속 사용하려는 경우에도 이러한 인바운드 연결이 비대칭 라우팅의 영향을 받을 수 있습니다. 아래에 설명된 몇 가지 예방 조치는 Microsoft 365에서 온-프레미스 시스템으로의 인터넷 기반 인바운드 흐름에 영향을 주지 않도록 하는 것이 좋습니다.
인바운드 네트워크 트래픽 흐름에 대한 비대칭 라우팅의 위험을 최소화하려면 모든 인바운드 연결은 ExpressRoute에 대한 라우팅 가시성이 있는 네트워크 세그먼트로 라우팅되기 전에 원본 NAT를 사용해야 합니다. 원본 NAT 없이 ExpressRoute에 대한 라우팅 표시 유형이 있는 네트워크 세그먼트에 들어오는 연결이 허용되는 경우 Microsoft 365에서 시작된 요청은 인터넷에서 입력되지만 Microsoft 365로 돌아가는 응답은 ExpressRoute 네트워크 경로를 Microsoft 네트워크로 다시 사용하는 것을 선호하므로 비대칭 라우팅이 발생합니다.
다음 구현 패턴 중 하나를 고려하여 이 요구 사항을 충족할 수 있습니다.
인터넷에서 온-프레미스 시스템으로의 경로에서 방화벽 또는 부하 분산 장치와 같은 네트워킹 장비를 사용하여 요청이 내부 네트워크로 라우팅되기 전에 원본 NAT를 수행합니다.
인터넷 연결을 처리하는 프런트 엔드 서버 또는 역방향 프록시 시스템과 같은 인바운드 서비스가 있는 네트워크 세그먼트에 ExpressRoute 경로가 전파되지 않는지 확인합니다.
네트워크에서 이러한 시나리오를 명시적으로 고려하고 인터넷을 통해 모든 인바운드 네트워크 트래픽 흐름을 유지하면 비대칭 라우팅의 배포 및 운영 위험을 최소화하는 데 도움이 됩니다.
ExpressRoute 연결을 통해 일부 인바운드 흐름을 전달하도록 선택할 수 있는 경우가 있을 수 있습니다. 이러한 시나리오의 경우 다음과 같은 추가 고려 사항을 고려합니다.
Microsoft 365는 공용 IP를 사용하는 온-프레미스 엔드포인트만 대상으로 지정할 수 있습니다. 즉, 온-프레미스 인바운드 엔드포인트가 ExpressRoute를 통해 Microsoft 365에만 노출되더라도 여전히 연결된 공용 IP가 있어야 합니다.
Microsoft 365 서비스에서 온-프레미스 엔드포인트를 resolve 위해 수행하는 모든 DNS 이름 확인은 공용 DNS를 사용하여 발생합니다. 즉, 인터넷의 IP 매핑에 인바운드 서비스 엔드포인트의 FQDN을 등록해야 합니다.
ExpressRoute를 통해 인바운드 네트워크 연결을 받으려면 이러한 엔드포인트에 대한 공용 IP 서브넷을 ExpressRoute를 통해 Microsoft에 보급해야 합니다.
이러한 인바운드 네트워크 트래픽 흐름을 신중하게 평가하여 회사 보안 및 네트워크 정책에 따라 적절한 보안 및 네트워크 제어가 적용되도록 합니다.
온-프레미스 인바운드 엔드포인트가 ExpressRoute를 통해 Microsoft에 보급되면 ExpressRoute는 Microsoft 365를 포함한 모든 Microsoft 서비스에 대해 해당 엔드포인트에 대한 기본 라우팅 경로가 됩니다. 즉, 이러한 엔드포인트 서브넷은 Microsoft 365 서비스와의 통신에만 사용해야 하며 Microsoft 네트워크의 다른 서비스는 사용하지 않아야 합니다. 그렇지 않으면 디자인으로 인해 다른 Microsoft 서비스의 인바운드 연결이 ExpressRoute를 통해 인바운드를 라우팅하는 것을 선호하는 반면 반환 경로는 인터넷을 사용하는 비대칭 라우팅이 발생합니다.
ExpressRoute 회로 또는 meet-me 위치가 다운된 경우 별도의 네트워크 경로를 통해 요청을 수락하기 위해 온-프레미스 인바운드 엔드포인트를 계속 사용할 수 있는지 확인해야 합니다. 이는 여러 ExpressRoute 회로를 통해 해당 엔드포인트에 대한 서브넷을 보급하는 것을 의미할 수 있습니다.
특히 이러한 흐름이 방화벽과 같은 상태 저장 네트워크 디바이스를 통과하는 경우 ExpressRoute를 통해 네트워크에 들어오는 모든 인바운드 네트워크 트래픽 흐름에 원본 NAT를 적용하는 것이 좋습니다.
ADFS 프록시 또는 Exchange 자동 검색과 같은 일부 온-프레미스 서비스는 Microsoft 365 서비스와 인터넷 사용자 모두에서 인바운드 요청을 받을 수 있습니다. 이러한 요청의 경우 Microsoft 365는 인터넷을 통해 사용자 요청과 동일한 FQDN을 대상으로 합니다. 인터넷에서 온-프레미스 엔드포인트로의 인바운드 사용자 연결을 허용하는 동시에 Microsoft 365 연결에서 ExpressRoute를 사용하도록 강제하는 것은 상당한 라우팅 복잡성을 나타냅니다. ExpressRoute를 통해 이러한 복잡한 시나리오를 구현하는 대부분의 고객은 운영 고려 사항으로 인해 권장되지 않습니다. 이러한 추가 오버헤드에는 비대칭 라우팅의 위험 관리가 포함되며 여러 차원의 라우팅 광고 및 정책을 신중하게 관리해야 합니다.
비대칭 경로를 방지하는 방법을 보여 주도록 네트워크 토폴로지 계획 업데이트
비대칭 라우팅을 방지하여 organization 사용자가 인터넷에서 Microsoft 365 및 기타 중요한 서비스를 원활하게 사용할 수 있도록 합니다. 고객에게는 비대칭 라우팅을 유발하는 두 가지 일반적인 구성이 있습니다. 이제 사용하려는 네트워크 구성을 검토하고 이러한 비대칭 라우팅 시나리오 중 하나가 있을 수 있는지 검사.
먼저 다음 네트워크 다이어그램과 관련된 몇 가지 다른 상황을 살펴보겠습니다. 이 다이어그램에서는 ADFS 또는 온-프레미스 하이브리드 서버와 같은 인바운드 요청을 수신하는 모든 서버가 뉴저지 데이터 센터에 있으며 인터넷에 보급됩니다.
경계 네트워크는 안전하지만 들어오는 요청에 사용할 수 있는 원본 NAT는 없습니다.
뉴저지 데이터 센터의 서버는 인터넷 및 ExpressRoute 경로를 모두 볼 수 있습니다.
문제를 해결하는 방법에 대한 제안도 있습니다.
문제 1: 인터넷을 통해 클라우드-온-프레미스 연결
다음 다이어그램에서는 네트워크 구성이 인터넷을 통해 Microsoft 클라우드의 인바운드 요청에 NAT를 제공하지 않을 때 수행되는 비대칭 네트워크 경로를 보여 줍니다.
Microsoft 365의 인바운드 요청은 공용 DNS에서 온-프레미스 엔드포인트의 IP 주소를 검색하고 요청을 경계 네트워크로 보냅니다.
이 잘못된 구성에서는 트래픽이 전송되는 경계 네트워크에서 원본 NAT를 구성하거나 사용할 수 없으므로 실제 원본 IP 주소가 반환 대상으로 사용됩니다.
네트워크의 서버는 사용 가능한 ExpressRoute 네트워크 연결을 통해 반환 트래픽을 Microsoft 365로 라우팅합니다.
그 결과 Microsoft 365로의 흐름에 대한 비대칭 경로가 생성되어 연결이 끊어집니다.
해결 방법 1a: 원본 NAT
원본 NAT를 인바운드 요청에 추가하기만 하면 잘못 구성된 네트워크가 해결됩니다. 다음은 이 다이어그램에 대한 설명입니다.
들어오는 요청은 뉴저지 데이터 센터의 경계 네트워크를 통해 계속 입력됩니다. 이번에는 원본 NAT를 사용할 수 있습니다.
서버의 응답은 원래 IP 주소 대신 원본 NAT와 연결된 IP로 다시 라우팅되어 응답이 동일한 네트워크 경로를 따라 반환됩니다.
해결 방법 1b: 경로 범위 지정
또는 ExpressRoute BGP 접두사를 보급하지 않도록 선택하여 해당 컴퓨터의 대체 네트워크 경로를 제거할 수 있습니다. 다음은 이 다이어그램에 대한 설명입니다.
들어오는 요청은 뉴저지 데이터 센터의 경계 네트워크를 통해 계속 입력됩니다. 이번에는 ExpressRoute 회로를 통해 Microsoft에서 보급된 접두사를 뉴저지 데이터 센터에서 사용할 수 없습니다.
서버의 응답은 사용 가능한 유일한 경로를 통해 원래 IP 주소와 연결된 IP로 다시 라우팅되어 응답이 동일한 네트워크 경로를 따라 반환됩니다.
문제 2: ExpressRoute를 통해 클라우드-온-프레미스 연결
다음 다이어그램에서는 네트워크 구성이 ExpressRoute를 통해 Microsoft 클라우드의 인바운드 요청에 NAT를 제공하지 않을 때 수행되는 비대칭 네트워크 경로를 보여 줍니다.
Microsoft 365의 인바운드 요청은 DNS에서 IP 주소를 검색하고 요청을 경계 네트워크로 보냅니다.
이 잘못된 구성에서는 트래픽이 전송되는 경계 네트워크에서 원본 NAT를 구성하거나 사용할 수 없으므로 실제 원본 IP 주소가 반환 대상으로 사용됩니다.
네트워크의 컴퓨터는 사용 가능한 ExpressRoute 네트워크 연결을 통해 반환 트래픽을 Microsoft 365로 라우팅합니다.
결과는 Microsoft 365에 대한 비대칭 연결입니다.
해결 방법 2: 원본 NAT
원본 NAT를 인바운드 요청에 추가하기만 하면 잘못 구성된 네트워크가 해결됩니다. 다음은 이 다이어그램에 대한 설명입니다.
들어오는 요청은 뉴욕 데이터 센터의 경계 네트워크를 통해 계속 입력됩니다. 이번에는 원본 NAT를 사용할 수 있습니다.
서버의 응답은 원래 IP 주소 대신 원본 NAT와 연결된 IP로 다시 라우팅되어 응답이 동일한 네트워크 경로를 따라 반환됩니다.
용지는 네트워크 디자인에 경로 대칭이 있는지 확인합니다.
이 시점에서 구현 계획이 Microsoft 365를 사용하는 다양한 시나리오에 대한 경로 대칭을 제공하는지 종이에 확인해야 합니다. 사용자가 서비스의 다른 기능을 사용할 때 수행해야 하는 특정 네트워크 경로를 식별합니다. 온-프레미스 네트워크 및 WAN 라우팅에서 경계 디바이스, 연결 경로까지 ExpressRoute 또는 인터넷 및 온라인 엔드포인트에 대한 연결.
이전에 organization 채택할 서비스로 식별된 모든 Microsoft 365 네트워크 서비스에 대해 이 작업을 수행해야 합니다.
그것은 두 번째 사람과 경로의이 종이 연습을 수행하는 데 도움이됩니다. 각 네트워크 홉이 다음 경로를 가져올 것으로 예상되는 위치를 설명하고 라우팅 경로에 대해 잘 알고 있는지 확인합니다. ExpressRoute는 항상 Microsoft 서버 IP 주소로 더 범위가 지정된 경로를 제공하여 인터넷 기본 경로보다 낮은 경로 비용을 제공합니다.
클라이언트 연결 구성 디자인
인터넷 바인딩된 트래픽에 프록시 서버를 사용하는 경우 네트워크의 클라이언트 컴퓨터가 프록시 서버를 전송하지 않고 Microsoft 365로 원하는 ExpressRoute 트래픽을 보내도록 올바르게 구성되고 일부 Microsoft 365 트래픽을 포함한 나머지 트래픽이 관련 프록시로 전송되도록 PAC 또는 클라이언트 구성 파일을 조정해야 합니다. Microsoft 365 엔드포인트 관리 가이드(예: PAC 파일)를 읽어보세요.
참고
엔드포인트는 매주 자주 변경됩니다. 최신 상태를 유지하는 데 필요한 변경 횟수를 줄이기 위해 organization 채택한 서비스 및 기능에 따라 변경해야 합니다. 변경 내용이 발표되고 레코드가 모든 과거 변경 내용을 보관하는 RSS 피드의 유효 날짜 에 주의하세요. 공지된 IP 주소는 유효 날짜에 도달할 때까지 광고되지 않거나 광고에서 제거될 수 있습니다.
경로 대칭 확인
Microsoft 365 프런트 엔드 서버는 인터넷과 ExpressRoute 모두에서 액세스할 수 있습니다. 이러한 서버는 둘 다 사용할 수 있는 경우 ExpressRoute 회로를 통해 온-프레미스로 다시 라우팅하는 것을 선호합니다. 이 때문에 네트워크의 트래픽이 인터넷 회로를 통해 라우팅하는 것을 선호하는 경우 비대칭 경로가 발생할 수 있습니다. 상태 저장 패킷 검사를 수행하는 디바이스는 이후의 아웃바운드 패킷과 다른 경로를 따르는 반환 트래픽을 차단할 수 있으므로 비대칭 경로가 문제입니다.
인터넷 또는 ExpressRoute를 통해 Microsoft 365에 대한 연결을 시작하든 관계없이 원본은 공개적으로 라우팅 가능한 주소여야 합니다. 많은 고객이 Microsoft와 직접 피어링하므로 고객 간에 중복이 가능한 개인 주소를 사용할 수 없습니다.
다음은 Microsoft 365에서 온-프레미스 네트워크로의 통신이 시작되는 시나리오입니다. 네트워크 디자인을 간소화하려면 인터넷 경로를 통해 다음을 라우팅하는 것이 좋습니다.
온-프레미스 호스트에 대한 Exchange Online 테넌트의 메일 또는 SharePoint에서 온-프레미스 호스트로 전송된 SharePoint 메일과 같은 SMTP 서비스 SMTP 프로토콜은 ExpressRoute 회로를 통해 공유되는 경로 접두사보다 Microsoft 네트워크 내에서 더 광범위하게 사용되며 ExpressRoute를 통해 온-프레미스 SMTP 서버를 보급하면 이러한 다른 서비스에서 오류가 발생합니다.
로그인에 대한 암호 유효성 검사 중 ADFS.
이러한 양방향 트래픽 흐름에 대해 Microsoft가 네트워크로 다시 라우팅하려면 온-프레미스 디바이스에 대한 BGP 경로를 Microsoft와 공유해야 합니다. ExpressRoute를 통해 Microsoft에 경로 접두사를 보급하는 경우 다음 모범 사례를 따라야 합니다.
공용 인터넷 및 ExpressRoute를 통해 동일한 공용 IP 주소 경로 접두사를 보급하지 마세요. ExpressRoute를 통해 Microsoft에 대한 IP BGP 경로 접두사 광고는 인터넷에 전혀 보급되지 않는 범위에서 제공하는 것이 좋습니다. 사용 가능한 IP 주소 공간으로 인해 이를 달성할 수 없는 경우 인터넷 회로보다 ExpressRoute를 통해 보다 구체적인 범위를 보급해야 합니다.
ExpressRoute 회로당 별도의 NAT IP 풀을 사용하고 인터넷 회로와 분리합니다.
Microsoft에 보급된 모든 경로는 ExpressRoute를 통해 네트워크에 보급되는 경로뿐만 아니라 Microsoft 네트워크의 모든 서버에서 네트워크 트래픽을 유치합니다. 라우팅 시나리오가 정의되고 팀에서 잘 이해되는 서버로만 경로를 보급합니다. 네트워크에서 여러 ExpressRoute 회로 각각에 별도의 IP 주소 경로 접두사를 보급합니다.
Azure ExpressRoute를 사용하는 고가용성 및 장애 조치(failover)
ExpressRoute를 사용하여 각 송신에서 ExpressRoute 공급자로 두 개 이상의 활성 회로를 프로비전하는 것이 좋습니다. 고객에게 오류가 표시되는 가장 일반적인 위치이며 활성/활성 ExpressRoute 회로 쌍을 프로비전하여 쉽게 방지할 수 있습니다. 많은 Microsoft 365 서비스는 인터넷을 통해서만 사용할 수 있으므로 두 개 이상의 활성/활성 인터넷 회로를 사용하는 것이 좋습니다.
네트워크의 송신 지점 내에는 사람들이 가용성을 인식하는 방식에 중요한 역할을 하는 다른 많은 디바이스와 회로가 있습니다. 연결 시나리오의 이러한 부분은 ExpressRoute 또는 Microsoft 365 SLA에서 다루지 않지만 organization 사용자가 인식하는 엔드투엔드 서비스 가용성에서 중요한 역할을 합니다.
Microsoft 365를 사용하고 운영하는 사용자에 초점을 맞춥니다. 한 구성 요소의 실패가 서비스를 사용하는 사람들의 경험에 영향을 미치는 경우 영향을 받는 사람들의 총 비율을 제한하는 방법을 찾습니다. 장애 조치(failover) 모드가 운영상 복잡한 경우 복구에 오랜 시간이 걸린 사람들의 경험을 고려하고 운영적으로 간단하고 자동화된 장애 조치(failover) 모드를 찾습니다.
네트워크 외부에서 Microsoft 365, ExpressRoute 및 ExpressRoute 공급자는 모두 서로 다른 수준의 가용성을 갖습니다.
서비스 가용성
Microsoft 365 서비스는 개별 서비스에 대한 작동 시간 및 가용성 메트릭을 포함하는 잘 정의된 서비스 수준 계약의 적용을 받습니다. Microsoft 365가 이러한 고가용성 수준을 유지할 수 있는 한 가지 이유는 개별 구성 요소가 글로벌 Microsoft 네트워크를 사용하여 많은 Microsoft 데이터 센터 간에 원활하게 장애 조치(failover)할 수 있기 때문입니다. 이 장애 조치(failover)는 데이터 센터 및 네트워크에서 여러 인터넷 송신 지점으로 확장되며 서비스를 사용하는 사람들의 관점에서 원활하게 장애 조치(failover)를 가능하게 합니다.
ExpressRoute는 Microsoft Network Edge와 ExpressRoute 공급자 또는 파트너 인프라 간의 개별 전용 회로에서 99.9%의 가용성 SLA를 제공합니다 . 이러한 서비스 수준은 각 피어링 위치의 중복 Microsoft 장비와 네트워크 공급자 장비 간의 두 가지 독립적인 상호 연결 로 구성된 ExpressRoute 회로 수준에서 적용됩니다.
공급자 가용성
- Microsoft의 서비스 수준 준비는 ExpressRoute 공급자 또는 파트너에서 중지됩니다. 또한 가용성 수준에 영향을 주는 선택을 할 수 있는 첫 번째 위치이기도 합니다. ExpressRoute 공급자가 네트워크 경계와 각 Microsoft 피어링 위치에서 공급자 연결 간에 제공하는 아키텍처, 가용성 및 복원력 특성을 면밀히 평가해야 합니다. 중복성, 피어링 장비, 통신 사업자 제공 WAN 회로 및 NAT 서비스 또는 관리되는 방화벽과 같은 추가 가치 추가 서비스의 논리적 및 물리적 측면에 주의하세요.
가용성 계획 디자인
Microsoft 365의 엔드 투 엔드 연결 시나리오에 고가용성 및 복원력을 계획하고 설계하는 것이 좋습니다. 디자인에는 다음이 포함되어야 합니다.
인터넷 및 ExpressRoute 회로를 포함하여 단일 실패 지점이 없습니다.
대부분의 예상 실패 모드에 영향을 받는 사용자 수와 영향을 받는 기간을 최소화합니다.
대부분의 예상 실패 모드에서 간단하고 반복 가능하며 자동 복구 프로세스에 최적화합니다.
상당한 성능 저하 없이 중복 경로를 통해 네트워크 트래픽 및 기능의 전체 요구를 지원합니다.
연결 시나리오에는 Microsoft 365에 대한 여러 독립적이고 활성적인 네트워크 경로에 최적화된 네트워크 토폴로지를 포함해야 합니다. 이렇게 하면 개별 디바이스 또는 장비 수준에서 중복성에만 최적화된 토폴로지보다 더 나은 엔드 투 엔드 가용성을 얻을 수 있습니다.
팁
사용자가 여러 대륙 또는 지리적 지역에 분산되어 있고 각 위치가 중복 WAN 회로를 통해 단일 ExpressRoute 회로가 있는 단일 온-프레미스 위치에 연결하는 경우 사용자는 서로 다른 지역을 가장 가까운 피어링 위치에 연결하는 독립적인 ExpressRoute 회로를 포함하는 네트워크 토폴로지 디자인보다 엔드투엔드 서비스 가용성이 낮습니다.
각 회로가 서로 다른 지리적 피어링 위치로 연결되는 ExpressRoute 회로를 두 개 이상 프로비전하는 것이 좋습니다. 사용자가 Microsoft 365 서비스에 ExpressRoute 연결을 사용하는 모든 지역에 대해 이 활성-활성 회로 쌍을 프로비전해야 합니다. 이렇게 하면 데이터 센터 또는 피어링 위치와 같은 주요 위치에 영향을 주는 재해 중에 각 지역이 연결된 상태를 유지할 수 있습니다. 에서 활성/활성으로 구성하면 최종 사용자 트래픽을 여러 네트워크 경로에 분산할 수 있습니다. 이렇게 하면 디바이스 또는 네트워크 장비 가동 중단 시 영향을 받는 사람들의 scope 줄어듭니다.
인터넷과 함께 단일 ExpressRoute 회로를 백업으로 사용하지 않는 것이 좋습니다.
예: 장애 조치(failover) 및 고가용성
Contoso의 다중 지리적 디자인은 라우팅, 대역폭, 보안에 대한 검토를 거쳤으며 이제 고가용성 검토를 거쳐야 합니다. Contoso는 고가용성을 세 가지 범주를 다루는 것으로 생각합니다. 복원력, 안정성 및 중복성.
복원력을 통해 Contoso는 오류에서 신속하게 복구할 수 있습니다. 안정성을 통해 Contoso는 시스템 내에서 일관된 결과를 제공할 수 있습니다. 중복성을 통해 Contoso는 하나 이상의 미러된 인프라 인스턴스 간에 이동할 수 있습니다.
각 에지 구성 내에서 Contoso에는 중복 방화벽, 프록시 및 IDS가 있습니다. 북아메리카 경우 Contoso는 댈러스 데이터 센터에서 하나의 에지 구성과 버지니아 데이터 센터의 다른 에지 구성을 가지고 있습니다. 각 위치의 중복 장비는 해당 위치에 대한 복원력을 제공합니다.
Contoso의 네트워크 구성은 몇 가지 주요 원칙에 따라 빌드됩니다.
각 지리적 지역 내에는 여러 Azure ExpressRoute 회로가 있습니다.
지역 내의 각 회로는 해당 지역 내의 모든 네트워크 트래픽을 지원할 수 있습니다.
라우팅은 가용성, 위치 등에 따라 하나 또는 다른 경로를 분명히 선호합니다.
Azure ExpressRoute 회로 간의 장애 조치(failover)는 Contoso에 필요한 추가 구성 또는 작업 없이 자동으로 수행됩니다.
인터넷 회로 간의 장애 조치(failover)는 Contoso에 필요한 추가 구성 또는 작업 없이 자동으로 발생합니다.
이 구성에서 Contoso는 물리적 및 가상 수준의 중복성을 통해 신뢰할 수 있는 방식으로 로컬 복원력, 지역 복원력 및 글로벌 복원력을 제공할 수 있습니다. Contoso는 지역당 단일 Azure ExpressRoute 회로와 인터넷 장애 조치(failover) 가능성을 평가한 후 이 구성을 선택했습니다.
Contoso가 지역당 여러 Azure ExpressRoute 회로를 가질 수 없는 경우 아시아 태평양의 Azure ExpressRoute 회로에 북아메리카 시작된 라우팅 트래픽은 허용할 수 없는 대기 시간 수준을 추가하고 필요한 DNS 전달자 구성은 복잡성을 추가합니다.
인터넷을 백업 구성으로 사용하는 것은 권장되지 않습니다. 이로 인해 Contoso의 안정성 원칙이 중단되어 연결을 사용하는 환경이 일관되지 않습니다. 또한 구성된 BGP 보급 알림, NAT 구성, DNS 구성 및 프록시 구성을 고려하여 장애 조치(failover)하려면 수동 구성이 필요합니다. 이렇게 하면 장애 조치(failover) 복잡성이 증가하여 복구 시간이 늘어나고 관련 단계를 진단하고 문제를 해결하는 기능이 줄어듭니다.
트래픽 관리 또는 Azure ExpressRoute를 계획하고 구현하는 방법에 대한 질문이 있나요? 나머지 네트워크 및 성능 지침 또는 Azure ExpressRoute FAQ를 읽어보세요.
Microsoft 365 시나리오용 Azure ExpressRoute에 보안 컨트롤 적용
Azure ExpressRoute 연결 보안은 인터넷 연결 보안과 동일한 원칙으로 시작됩니다. 많은 고객이 온-프레미스 네트워크를 Microsoft 365 및 기타 Microsoft 클라우드에 연결하는 ExpressRoute 경로를 따라 네트워크 및 경계 컨트롤을 배포하도록 선택합니다. 이러한 컨트롤에는 방화벽, 애플리케이션 프록시, 데이터 누출 방지, 침입 감지, 침입 방지 시스템 등이 포함될 수 있습니다. 대부분의 경우 고객은 온-프레미스에서 Microsoft로 가는 트래픽과 Microsoft에서 시작된 트래픽, 온-프레미스에서 시작된 트래픽과 일반 인터넷 대상으로 가는 온-프레미스에서 시작된 트래픽에 대해 서로 다른 수준의 제어를 적용합니다.
다음은 배포하도록 선택한 ExpressRoute 연결 모델 과 보안을 통합하는 몇 가지 예입니다.
| ExpressRoute 통합 옵션 | 네트워크 보안 경계 모델 |
|---|---|
| 클라우드 교환에 공동 배치됨 |
ExpressRoute 연결이 설정된 공동 배치 시설에 새 보안/경계 인프라를 새로 설치하거나 사용합니다. 공동 배치 시설을 전적으로 라우팅/상호 연결 목적으로 사용하고 공동 배치 시설에서 온-프레미스 보안/경계 인프라로의 역운행 연결을 사용합니다. |
| 지점 및 지점 이더넷 |
기존 온-프레미스 보안/경계 인프라 위치에서 지점 및 지점 간의 ExpressRoute 연결을 종료합니다. ExpressRoute 경로와 관련된 새 보안/경계 인프라를 설치하고 지점 및 지점 간의 연결을 종료합니다. |
| 모든 IPVPN |
Microsoft 365 연결용 ExpressRoute에 사용되는 IPVPN으로 송신하는 모든 위치에서 기존 온-프레미스 보안/경계 인프라를 사용합니다. Microsoft 365용 ExpressRoute에 사용되는 IPVPN을 보안/경계로 지정된 특정 온-프레미스 위치로 모발 고정합니다. |
일부 서비스 공급자는 Azure ExpressRoute와의 통합 솔루션의 일부로 관리되는 보안/경계 기능도 제공합니다.
Microsoft 365 연결용 ExpressRoute에 사용되는 네트워크/보안 경계 옵션의 토폴로지 배치를 고려할 때는 다음과 같은 추가 고려 사항이 있습니다.
깊이 및 유형 네트워크/보안 컨트롤은 Microsoft 365 사용자 환경의 성능 및 확장성에 영향을 미칠 수 있습니다.
아웃바운드(온-프레미스->Microsoft) 및 인바운드(Microsoft-온->프레미스) [사용하도록 설정된 경우] 흐름에는 다른 요구 사항이 있을 수 있습니다. 일반 인터넷 대상에 대한 아웃바운드와 다를 수 있습니다.
포트/프로토콜 및 필요한 IP 서브넷에 대한 Microsoft 365 요구 사항은 트래픽이 Microsoft 365용 ExpressRoute를 통해 라우팅되는지 아니면 인터넷을 통해 라우팅되는지 여부와 동일합니다.
고객 네트워크/보안 컨트롤의 토폴로지 배치는 사용자와 Microsoft 365 서비스 간의 최종 종단 간 네트워크를 결정하며 네트워크 대기 시간 및 정체에 상당한 영향을 미칠 수 있습니다.
고객은 중복성, 고가용성 및 재해 복구 모범 사례에 따라 Microsoft 365용 ExpressRoute에서 사용할 보안/경계 토폴로지를 설계하는 것이 좋습니다.
다음은 위에서 설명한 경계 보안 모델과 다른 Azure ExpressRoute 연결 옵션을 비교하는 Contoso의 예입니다.
예: Azure ExpressRoute 보안
Contoso는 Azure ExpressRoute 구현을 고려하고 있으며 Microsoft 365용 ExpressRoute에 대한 최적의 아키텍처를 계획한 후 위의 지침을 사용하여 대역폭 요구 사항을 이해한 후 경계를 보호하는 최상의 방법을 결정합니다.
여러 대륙에 위치하는 다국적 organization Contoso의 경우 보안이 모든 경계에 걸쳐 있어야 합니다. Contoso에 대한 최적의 연결 옵션은 각 대륙에 있는 직원의 요구를 충족하기 위해 전 세계 여러 피어링 위치와 다중 지점 연결입니다. 각 대륙에는 대륙 내의 중복 Azure ExpressRoute 회로가 포함되며 보안은 이러한 모든 회로에 걸쳐 있어야 합니다.
Contoso의 기존 인프라는 안정적이며 추가 작업을 처리할 수 있으므로 Contoso는 Azure ExpressRoute 및 인터넷 경계 보안에 인프라를 사용할 수 있습니다. 그렇지 않은 경우 Contoso는 기존 장비를 보완하거나 다른 유형의 연결을 처리하기 위해 더 많은 장비를 구매하도록 선택할 수 있습니다.
Azure ExpressRoute에 대한 대역폭 계획
모든 Microsoft 365 고객은 각 위치의 사용자 수, 각 Microsoft 365 애플리케이션의 활성 상태 및 온-프레미스 또는 하이브리드 장비 사용 및 네트워크 보안 구성과 같은 기타 요인에 따라 고유한 대역폭 요구 사항이 있습니다.
대역폭이 너무 적으면 정체, 데이터 재전송 및 예측할 수 없는 지연이 발생합니다. 대역폭이 너무 많으면 불필요한 비용이 발생합니다. 기존 네트워크에서 대역폭은 회로에서 사용 가능한 헤드룸의 양에 대해 백분율로 참조되는 경우가 많습니다. 헤드룸이 10%이면 혼잡이 발생할 수 있으며 일반적으로 80%의 헤드룸이 있는 것은 불필요한 비용을 의미합니다. 일반적인 헤드룸 대상 할당은 20%에서 50%입니다.
적절한 수준의 대역폭을 찾기 위해 가장 좋은 메커니즘은 기존 네트워크 사용량을 테스트하는 것입니다. 이는 모든 네트워크 구성 및 애플리케이션이 어떤 면에서 고유하기 때문에 진정한 사용량 측정값을 얻을 수 있는 유일한 방법입니다. 측정할 때 네트워크 요구 사항을 이해하기 위해 총 대역폭 사용량, 대기 시간 및 TCP 정체에 주의해야 합니다.
모든 네트워크 애플리케이션을 포함하는 예상 기준이 있으면 실제 사용량을 확인하기 위해 organization 사용자의 다양한 프로필을 구성하는 소규모 그룹으로 Microsoft 365를 파일럿하고 두 측정값을 사용하여 각 사무실 위치에 필요한 대역폭의 양을 예측합니다. 테스트에 대기 시간 또는 TCP 정체 문제가 있는 경우 Microsoft 365를 사용하여 송신을 사용자에게 더 가깝게 이동하거나 SSL 암호 해독/검사와 같은 집중적인 네트워크 검사를 제거해야 할 수 있습니다.
권장되는 네트워크 처리 유형에 대한 모든 권장 사항은 ExpressRoute 및 인터넷 회로 모두에 적용됩니다. 성능 튜닝 사이트에 대한 나머지 지침도 마찬가지입니다.
배포 및 테스트 절차 빌드
구현 계획에는 테스트 및 롤백 계획이 모두 포함되어야 합니다. 구현이 예상대로 작동하지 않는 경우 문제가 발견되기 전에 최소 사용자 수에 영향을 주도록 계획을 설계해야 합니다. 다음은 계획에서 고려해야 할 몇 가지 개략적인 원칙입니다.
네트워크 세그먼트 및 사용자 서비스 온보딩을 스테이징하여 중단을 최소화합니다.
별도의 인터넷 연결 호스트에서 추적 경로 및 TCP 연결을 사용하여 경로를 테스트할 계획입니다.
가급적 인바운드 및 아웃바운드 서비스 테스트는 테스트 Microsoft 365 테넌트를 사용하는 격리된 테스트 네트워크에서 수행해야 합니다.
또는 고객이 아직 Microsoft 365를 사용하지 않거나 파일럿 중인 경우 프로덕션 네트워크에서 테스트를 수행할 수 있습니다.
또는 테스트 및 모니터링 전용으로 설정된 프로덕션 중단 중에 테스트를 수행할 수 있습니다.
또는 각 계층 3 라우터 노드에서 각 서비스에 대한 경로를 확인하여 테스트를 수행할 수 있습니다. 이 대체는 물리적 테스트가 부족하여 위험이 발생하므로 다른 테스트가 불가능한 경우에만 사용해야 합니다.
배포 절차 빌드
배포 절차는 대규모 사용자 그룹에 배포하기 전에 테스트를 허용하도록 단계별로 소규모 사용자 그룹에 배포해야 합니다. 다음은 ExpressRoute 배포를 준비하는 여러 가지 방법입니다.
Microsoft 피어링을 사용하여 ExpressRoute를 설정하고 단계적 테스트를 위해 단일 호스트에만 경로 보급 알림을 전달합니다.
처음에는 ExpressRoute 네트워크에 대한 경로를 단일 네트워크 세그먼트로 보급하고 네트워크 세그먼트 또는 지역별로 경로 광고를 확장합니다.
Microsoft 365를 처음으로 배포하는 경우 몇 명의 사용자를 위해 ExpressRoute 네트워크 배포를 파일럿으로 사용합니다.
프록시 서버를 사용하는 경우 더 추가하기 전에 몇 명의 사용자를 테스트 및 피드백으로 ExpressRoute로 보내도록 테스트 PAC 파일을 구성할 수도 있습니다.
구현 계획에는 수행해야 하는 각 배포 절차 또는 네트워킹 구성을 배포하는 데 사용해야 하는 명령이 나열되어야 합니다. 네트워크 중단 시간이 도착하면 미리 작성되고 피어를 검토한 서면 배포 계획에서 변경되는 모든 변경 내용이 있어야 합니다. ExpressRoute의 기술 구성에 대한 지침을 참조하세요.
전자 메일을 계속 보낼 온-프레미스 서버의 IP 주소를 변경한 경우 SPF TXT 레코드를 업데이트합니다.
새 NAT 구성을 수용하도록 IP 주소를 변경한 경우 온-프레미스 서버에 대한 DNS 항목을 업데이트합니다.
라우팅 또는 프록시 구성을 유지하기 위해 Microsoft 365 엔드포인트 알림에 대한 RSS 피드를 구독했는지 확인합니다.
ExpressRoute 배포가 완료되면 테스트 계획의 절차를 실행해야 합니다. 각 프로시저에 대한 결과를 기록해야 합니다. 테스트 계획 결과가 구현에 성공하지 못했음을 나타내는 경우 원래 프로덕션 환경으로 롤백하기 위한 절차를 포함해야 합니다.
테스트 프로시저 빌드
테스트 절차에는 ExpressRoute를 사용하는 Microsoft 365의 각 아웃바운드 및 인바운드 네트워크 서비스에 대한 테스트와 그렇지 않은 테스트가 포함되어야 합니다. 이 절차에는 회사 LAN에 온-프레미스가 아닌 사용자를 포함하여 각 고유한 네트워크 위치의 테스트가 포함되어야 합니다.
테스트 작업의 몇 가지 예는 다음과 같습니다.
온-프레미스 라우터에서 네트워크 운영자 라우터로 Ping.
온-프레미스 라우터에서 500+ Microsoft 365 및 CRM Online IP 주소 알림을 수신하는지 확인합니다.
ExpressRoute와 내부 네트워크 간에 인바운드 및 아웃바운드 NAT가 작동하고 있는지 확인합니다.
NAT에 대한 경로가 라우터에서 보급되고 있는지 확인합니다.
ExpressRoute가 보급된 접두사를 수락했는지 확인합니다.
- 다음 cmdlet을 사용하여 피어링 광고를 확인합니다.
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering공용 NAT IP 범위가 이전 예제와 같이 더 큰 범위의 특정 하위 집합이 아니면 다른 ExpressRoute 또는 공용 인터넷 네트워크 회로를 통해 Microsoft에 보급되지 않는지 확인합니다.
ExpressRoute 회로는 쌍을 이루며 두 BGP 세션이 모두 실행되고 있는지 확인합니다.
NAT 내부에 단일 호스트를 설정하고 ping, tracert 및 tcpping을 사용하여 새 회로에서 호스트 outlook.office365.com 대한 연결을 테스트합니다. 또는 미러 포트에서 MSEE로의 Wireshark 또는 Microsoft Network Monitor 3.4와 같은 도구를 사용하여 outlook.office365.com 연결된 IP 주소에 연결할 수 있는지 확인할 수 있습니다.
Exchange Online 애플리케이션 수준 기능을 테스트합니다.
테스트 Outlook은 Exchange Online 연결하고 전자 메일을 보내고 받을 수 있습니다.
테스트 Outlook은 온라인 모드를 사용할 수 있습니다.
스마트폰 연결 및 송신/수신 기능을 테스트합니다.
- SharePoint에 대한 애플리케이션 수준 기능 테스트
비즈니스용 OneDrive 동기화 클라이언트를 테스트합니다.
SharePoint 웹 액세스를 테스트합니다.
- 비즈니스용 Skype 호출 시나리오에 대한 애플리케이션 수준 기능 테스트:
인증된 사용자로 전화 회의에 참가합니다.[최종 사용자가 시작한 초대].
전화 회의에 사용자 초대 [MCU에서 보낸 초대].
비즈니스용 Skype 웹 애플리케이션을 사용하여 익명 사용자로 회의에 참가합니다.
유선 PC 연결, IP 전화 및 모바일 장치에서 통화에 참가합니다.
페더레이션된 사용자 호출 o PSTN 유효성 검사 호출: 호출이 완료되고 통화 품질이 허용되며 연결 시간이 허용됩니다.
테넌트 및 페더레이션된 사용자 모두에 대해 연락처의 현재 상태 상태 업데이트되었는지 확인합니다.
일반적인 문제
비대칭 라우팅은 가장 일반적인 구현 문제입니다. 다음은 찾을 수 있는 몇 가지 일반적인 원본입니다.
원본 NAT가 없는 개방형 또는 플랫 네트워크 라우팅 토폴로지 사용.
SNAT를 사용하여 인터넷 및 ExpressRoute 연결을 통해 인바운드 서비스로 라우팅하지 않습니다.
광범위하게 배포하기 전에 테스트 네트워크에서 ExpressRoute에서 인바운드 서비스를 테스트하지 않습니다.
네트워크를 통해 ExpressRoute 연결 배포
한 번에 네트워크의 한 세그먼트에 배포를 준비하여 각 새 네트워크 세그먼트에 대해 롤백할 계획을 사용하여 네트워크의 다른 부분에 대한 연결을 점진적으로 롤아웃합니다. 배포가 Microsoft 365 배포와 일치하는 경우 먼저 Microsoft 365 파일럿 사용자에게 배포하고 여기에서 확장합니다.
먼저 테스트에 대해 다음을 수행합니다. 그런 다음 프로덕션용:
배포 단계를 실행하여 ExpressRoute를 사용하도록 설정합니다.
네트워크 경로가 예상대로 표시되는지 테스트합니다.
각 인바운드 및 아웃바운드 서비스에서 테스트를 수행합니다.
문제가 발견되면 롤백합니다.
테스트 네트워크 세그먼트를 사용하여 ExpressRoute에 대한 테스트 연결 설정
이제 완료된 계획을 종이에 추가했으므로 이제 소규모로 테스트할 차례입니다. 이 테스트에서는 Microsoft 피어링을 사용하여 온-프레미스 네트워크의 테스트 서브넷에 단일 ExpressRoute 연결을 설정합니다. 테스트 서브넷과 연결하여 평가판 Microsoft 365 테넌트 구성 및 테스트 서브넷의 프로덕션에서 사용할 모든 아웃바운드 및 인바운드 서비스를 포함할 수 있습니다. 테스트 네트워크 세그먼트에 대한 DNS를 설정하고 모든 인바운드 및 아웃바운드 서비스를 설정합니다. 테스트 계획을 실행하고 각 서비스 및 경로 전파에 대한 라우팅에 대해 잘 알고 있는지 확인합니다.
배포 및 테스트 계획 실행
위에서 설명한 항목을 완료하면 완료한 영역을 검사 배포 및 테스트 계획을 실행하기 전에 사용자와 팀이 검토했는지 확인합니다.
네트워크 변경과 관련된 아웃바운드 및 인바운드 서비스 목록입니다.
인터넷 송신 및 ExpressRoute meet-me 위치를 모두 보여 주는 글로벌 네트워크 아키텍처 다이어그램
배포된 각 서비스에 사용되는 다양한 네트워크 경로를 보여 주는 네트워크 라우팅 다이어그램
필요한 경우 변경 내용 및 롤백을 구현하는 단계가 포함된 배포 계획입니다.
각 Microsoft 365 및 네트워크 서비스를 테스트하기 위한 테스트 계획입니다.
인바운드 및 아웃바운드 서비스에 대한 프로덕션 경로의 종이 유효성 검사를 완료했습니다.
가용성 테스트를 포함하여 테스트 네트워크 세그먼트에서 완료된 테스트입니다.
전체 배포 계획 및 테스트 계획을 실행할 수 있을 만큼 긴 중단 기간을 선택하고, 문제 해결에 사용할 수 있는 시간과 필요한 경우 롤백하는 데 시간이 있습니다.
주의
인터넷과 ExpressRoute를 통해 라우팅하는 복잡한 특성으로 인해 복잡한 라우팅 문제 해결을 처리하기 위해 이 창에 추가 버퍼 시간을 추가하는 것이 좋습니다.
비즈니스용 Skype Online에 대한 QoS 구성
QoS는 비즈니스용 Skype Online에 대한 음성 및 모임 혜택을 얻는 데 필요합니다. ExpressRoute 네트워크 연결이 다른 Microsoft 365 서비스 액세스를 차단하지 않도록 보장한 후 QoS를 구성할 수 있습니다. QoS에 대한 구성은 비즈니스용 Skype Online의 ExpressRoute 및 QoS 문서에 설명되어 있습니다.
구현 문제 해결
먼저 이 구현 가이드의 단계를 살펴보세요. 구현 계획에서 누락된 항목이 있나요? 가능한 경우 더 작은 네트워크 테스트를 돌아가기 실행하여 오류를 복제하고 디버그합니다.
테스트 중에 실패한 인바운드 또는 아웃바운드 서비스를 식별합니다. 실패한 각 서비스에 대한 IP 주소 및 서브넷을 구체적으로 가져옵니다. 계속 진행하여 네트워크 토폴로지 다이어그램을 종이에 표시하고 라우팅의 유효성을 검사합니다. ExpressRoute 라우팅이 보급되는 위치를 구체적으로 확인합니다. 가능한 경우 추적을 사용하여 가동 중단 중에 해당 라우팅을 테스트합니다.
각 고객 엔드포인트에 대한 네트워크 추적을 사용하여 PSPing을 실행하고 원본 및 대상 IP 주소를 평가하여 예상대로 유효성을 검사합니다. 포트 25에서 노출하는 모든 메일 호스트에 텔넷을 실행하고 SNAT가 필요한 경우 원래 원본 IP 주소를 숨기고 있는지 확인합니다.
ExpressRoute 연결을 사용하여 Microsoft 365를 배포하는 동안 ExpressRoute에 대한 네트워크 구성이 모두 최적으로 설계되고 클라이언트 컴퓨터와 같은 네트워크의 다른 구성 요소도 최적화해야 합니다. 이 계획 가이드를 사용하여 놓친 단계를 해결하는 것 외에도 Microsoft 365에 대한 성능 문제 해결 계획을 작성했습니다.
다음의 간단한 링크를 사용할 수 있습니다. https://aka.ms/implementexpressroute365
관련 주제
Microsoft 365용 Azure ExpressRoute
비즈니스용 Skype Online의 미디어 품질 및 네트워크 연결 성능
비즈니스용 Skype Online의 ExpressRoute 및 QoS
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기