Office 365용 ExpressRoute 구현
이 문서는 Microsoft 365 Enterprise와 Office 365 Enterprise에 모두 적용됩니다.
Office 365 ExpressRoute는 많은 인터넷 연결 Office 365 서비스에 대한 대체 라우팅 경로를 제공합니다. Office 365 ExpressRoute의 아키텍처는 인터넷을 통해 이미 액세스할 수 있는 Office 365 서비스의 공용 IP 접두사가 프로비전된 ExpressRoute 회로에 보급되어 해당 IP 접두사가 네트워크에 다시 배포되는 것을 기반으로 합니다. ExpressRoute를 사용하면 여러 Office 365 서비스에 대해 인터넷 및 ExpressRoute를 통해 여러 다른 라우팅 경로를 효과적으로 사용하도록 설정합니다. 네트워크에서 이러한 라우팅 상태는 내부 네트워크 토폴로지를 설계하는 방식에 큰 변화를 나타낼 수 있습니다.
상태: 전체 가이드 v2
핵심 네트워크와 인터넷에 삽입된 경로가 있는 전용 회로를 통해 라우팅을 사용할 수 있는 네트워크 복잡성을 수용하기 위해 Office 365 구현을 위해 ExpressRoute를 신중하게 계획해야 합니다. 사용자와 팀이 이 가이드에서 자세한 계획 및 테스트를 수행하지 않는 경우 ExpressRoute 회로를 사용할 때 간헐적으로 또는 Office 365 서비스에 대한 연결이 완전히 손실될 위험이 높습니다.
성공적인 구현을 위해서는 인프라 요구 사항을 분석하고, 자세한 네트워크 평가 및 설계를 거치고, 단계적 및 제어된 방식으로 롤아웃을 신중하게 계획하고, 자세한 유효성 검사 및 테스트 계획을 수립해야 합니다. 분산된 대규모 환경의 경우 구현이 몇 개월에 걸쳐 있는 것을 보는 것은 드문 일이 아닙니다. 이 가이드는 미리 계획하는 데 도움이 되도록 설계되었습니다.
대규모 성공적인 배포는 계획하는 데 6개월이 걸릴 수 있으며 네트워킹, 방화벽 및 프록시 서버 관리자, Office 365 관리자, 보안, 최종 사용자 지원, 프로젝트 관리 및 임원 후원을 포함하여 조직의 여러 영역에서 팀 구성원을 포함할 수 있습니다. 계획 프로세스에 투자하면 배포 오류가 발생할 가능성이 줄어들어 가동 중지 시간 또는 복잡하고 비용이 많이 드는 문제 해결이 발생합니다.
이 구현 가이드를 시작하기 전에 다음 필수 구성 요소가 완료될 것으로 예상됩니다.
ExpressRoute가 권장되고 승인되었는지 확인하기 위해 네트워크 평가를 완료했습니다.
ExpressRoute 네트워크 서비스 공급자를 선택했습니다. ExpressRoute 파트너 및 피어링 위치에 대한 세부 정보를 찾습니다.
ExpressRoute 설명서를 이미 읽고 이해했으며 내부 네트워크는 ExpressRoute 필수 구성 요소를 종단 간 충족할 수 있습니다.
팀은 다음을 비롯한 중요한 기술 세부 정보를 이해하기 위해 Channel 9에서 https://aka.ms/expressrouteoffice365https://aka.ms/ert모든 공개 지침 및 설명서를 읽고 Channel 9의 Office 365 교육 시리즈를 위한 Azure ExpressRoute를 시청했습니다.
SaaS 서비스의 인터넷 종속성입니다.
비대칭 경로를 방지하고 복잡한 라우팅을 처리하는 방법입니다.
경계 보안, 가용성 및 애플리케이션 수준 컨트롤을 통합하는 방법입니다.
요구 사항 수집으로 시작
먼저 조직 내에서 채택할 기능 및 서비스를 결정합니다. 사용할 다양한 Office 365 서비스의 기능과 해당 기능을 사용하여 사용자를 호스트할 네트워크의 위치를 결정해야 합니다. 시나리오 카탈로그를 사용하면 각 시나리오에 필요한 네트워크 특성을 추가해야 합니다. 인바운드 및 아웃바운드 네트워크 트래픽 흐름 및 Office 365 엔드포인트를 ExpressRoute를 통해 사용할 수 있는지 여부와 같은 경우
조직의 요구 사항을 수집하려면 다음을 수행합니다.
조직에서 사용 중인 Office 365 서비스에 대한 인바운드 및 아웃바운드 네트워크 트래픽을 카탈로그화합니다. 다양한 Office 365 시나리오에 필요한 흐름에 대한 설명은 Office 365 URL 및 IP 주소 범위 페이지를 참조하세요.
내부 WAN 백본 및 토폴로지, 위성 사이트 연결, 마지막 마일 사용자 연결, 네트워크 경계 송신 지점으로 라우팅 및 프록시 서비스에 대한 세부 정보를 보여 주는 기존 네트워크 토폴로지에 대한 설명서를 수집합니다.
Office 365 및 기타 Microsoft 서비스 연결할 네트워크 다이어그램에서 인터넷 및 제안된 ExpressRoute 연결 경로를 모두 보여 주는 인바운드 서비스 엔드포인트를 식별합니다.
현재 인터넷에 송신이 있는 위치와 ExpressRoute 피어링 위치로 송신하도록 제안된 위치와 함께 위치 간의 모든 지리적 사용자 위치 및 WAN 연결을 식별합니다.
프록시, 방화벽 등과 같은 모든 에지 디바이스를 식별하고 인터넷 및 ExpressRoute를 통해 이동하는 흐름에 대한 관계를 카탈로그화합니다.
최종 사용자가 인터넷 및 ExpressRoute 흐름 모두에 대한 직접 라우팅 또는 간접 애플리케이션 프록시를 통해 Office 365 서비스에 액세스할지 여부를 문서화합니다.
네트워크 다이어그램에 테넌트 및 모임 위치의 위치를 추가합니다.
주요 사용자 위치에서 Office 365 예상 및 관찰된 네트워크 성능 및 대기 시간 특성을 예측합니다. Office 365 전역적이고 분산된 서비스 집합이며 사용자는 테넌트 위치와 다를 수 있는 위치에 연결됩니다. 따라서 ExpressRoute 및 인터넷 연결을 통해 사용자와 Microsoft 글로벌 네트워크의 가장 가까운 에지 간의 대기 시간을 측정하고 최적화하는 것이 좋습니다. 네트워크 평가의 결과를 사용하여 이 작업을 수행할 수 있습니다.
새 ExpressRoute 연결을 충족해야 하는 회사 네트워크 보안 및 고가용성 요구 사항을 나열합니다. 예를 들어 사용자가 인터넷 송신 또는 ExpressRoute 회로 오류 발생 시 Office 365 계속 액세스하는 방법입니다.
인터넷 경로를 사용하는 인바운드 및 아웃바운드 Office 365 네트워크 흐름과 ExpressRoute를 사용할 인바운드 및 아웃바운드 네트워크 흐름을 문서화합니다. 사용자의 지리적 위치와 온-프레미스 네트워크 토폴로지의 세부 정보에 대한 세부 정보는 계획이 한 사용자 위치와 다른 사용자 위치와 달라야 할 수 있습니다.
아웃바운드 및 인바운드 네트워크 트래픽 카탈로그
라우팅 및 기타 네트워크 복잡성을 최소화하려면 규정 요구 사항 또는 네트워크 평가의 결과로 전용 연결을 통해 이동하는 데 필요한 네트워크 트래픽 흐름에 Office 365 ExpressRoute만 사용하는 것이 좋습니다. 또한 ExpressRoute 라우팅 범위를 스테이징하고 아웃바운드 및 인바운드 네트워크 트래픽 흐름에 구현 프로젝트의 서로 다른 고유한 단계로 접근하는 것이 좋습니다. 사용자가 시작한 아웃바운드 네트워크 트래픽 흐름에만 Office 365 ExpressRoute를 배포하고 인터넷을 통해 인바운드 네트워크 트래픽 흐름을 유지하면 토폴로지 복잡성의 증가와 추가 비대칭 라우팅 가능성을 도입할 위험을 제어할 수 있습니다.
네트워크 트래픽 카탈로그에는 온-프레미스 네트워크와 Microsoft 간에 가질 모든 인바운드 및 아웃바운드 네트워크 연결 목록이 포함되어야 합니다.
아웃바운드 네트워크 트래픽 흐름은 Microsoft 서비스 대상인 내부 클라이언트 또는 서버와 같은 온-프레미스 환경에서 연결이 시작되는 시나리오입니다. 이러한 연결은 연결이 프록시 서버, 방화벽 또는 Office 365 경로의 다른 네트워킹 디바이스를 통과하는 경우와 같이 Office 365 또는 간접적으로 연결될 수 있습니다.
인바운드 네트워크 트래픽 흐름은 Microsoft 클라우드에서 온-프레미스 호스트로의 연결이 시작되는 모든 시나리오입니다. 이러한 연결은 일반적으로 고객 보안 정책이 외부에서 시작된 흐름에 필요한 방화벽 및 기타 보안 인프라를 통과해야 합니다.
Office 365 ExpressRoute를 사용하여 라우팅하는 문서의 경로 대칭 보장 섹션을 읽어 인바운드 트래픽을 보낼 서비스를 확인하고 Office 365 엔드포인트 참조 문서에서 Office 365 ExpressRoute 로 표시된 열을 찾아 나머지 연결 정보를 확인합니다.
아웃바운드 연결이 필요한 각 서비스에 대해 네트워크 라우팅, 프록시 구성, 패킷 검사 및 대역폭 요구 사항을 포함하여 서비스에 대한 계획된 연결을 설명하려고 합니다.
인바운드 연결이 필요한 각 서비스에 대해 몇 가지 추가 정보가 필요합니다. Microsoft 클라우드의 서버는 온-프레미스 네트워크에 대한 연결을 설정합니다. 연결이 올바르게 이루어지도록 하려면 다음을 포함하여 이 연결의 모든 측면을 설명하려고 합니다. 이러한 인바운드 연결을 수락할 서비스에 대한 공용 DNS 항목, CIDR 형식의 IPv4 IP 주소, ISP 장비가 관련된 주소 및 이러한 연결에 대해 인바운드 NAT 또는 원본 NAT가 처리되는 방식입니다.
비대칭 라우팅이 도입되지 않았는지 확인하기 위해 인터넷 또는 ExpressRoute를 통해 연결하는지 여부에 관계없이 인바운드 연결을 검토해야 합니다. 경우에 따라 Office 365 서비스가 인바운드 연결을 시작하는 온-프레미스 엔드포인트는 다른 Microsoft 및 비 Microsoft 서비스 액세스해야 할 수도 있습니다. Office 365 목적으로 이러한 서비스에 대한 ExpressRoute 라우팅을 사용하도록 설정해도 다른 시나리오가 중단되지 않는 것이 가장 중요합니다. 대부분의 경우 고객은 ExpressRoute를 사용하도록 설정한 후 Microsoft의 인바운드 흐름이 대칭으로 유지되도록 원본 기반 NAT와 같은 내부 네트워크에 대한 특정 변경 내용을 구현해야 할 수 있습니다.
다음은 필요한 세부 수준의 샘플입니다. 이 경우 Exchange 하이브리드는 ExpressRoute를 통해 온-프레미스 시스템으로 라우팅됩니다.
| 연결 속성 | 값 |
|---|---|
| 네트워크 트래픽 방향 |
인바운드 |
| 서비스 |
Exchange 하이브리드 |
| 공용 Office 365 엔드포인트(원본) |
Exchange Online(IP 주소) |
| 공용 온-프레미스 엔드포인트(대상) |
5.5.5.5 |
| 공용(인터넷) DNS 항목 |
Autodiscover.contoso.com |
| 이 온-프레미스 엔드포인트는 다른(Office 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 Online |
| 온-프레미스 엔드포인트(원본) |
사용자 워크스테이션 |
| 공용 Office 365 엔드포인트(대상) |
SharePoint Online(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 |
지역 연결을 사용한 네트워크 토폴로지 디자인
서비스와 연결된 네트워크 트래픽 흐름을 이해한 후에는 이러한 새로운 연결 요구 사항을 통합하고 Office 365 ExpressRoute를 사용하기 위해 변경한 내용을 보여 주는 네트워크 다이어그램을 만들 수 있습니다. 다이어그램에는 다음이 포함되어야 합니다.
Office 365 및 기타 서비스에 액세스할 모든 사용자 위치입니다.
모든 인터넷 및 ExpressRoute 송신 지점.
라우터, 방화벽, 애플리케이션 프록시 서버 및 침입 검색/방지를 포함하여 네트워크 내/외부 연결을 관리하는 모든 아웃바운드 및 인바운드 디바이스입니다.
ADFS 웹 애플리케이션 프록시 서버의 연결을 허용하는 내부 ADFS 서버와 같은 모든 인바운드 트래픽에 대한 내부 대상입니다.
보급될 모든 IP 서브넷의 카탈로그
사용자가 Office 365 액세스할 각 위치를 식별하고 ExpressRoute에 사용할 meet-me 위치를 나열합니다.
ExpressRoute에서 학습한 Microsoft IP 접두사가 허용, 필터링 및 전파되는 내부 네트워크 토폴로지의 위치 및 부분
네트워크 토폴로지는 각 네트워크 세그먼트의 지리적 위치와 ExpressRoute 및/또는 인터넷을 통해 Microsoft 네트워크에 연결하는 방법을 보여 줍니다.
아래 다이어그램은 사용자가 Office 365 인바운드 및 아웃바운드 라우팅 광고와 함께 Office 365 사용할 각 위치를 보여 줍니다.
아웃바운드 트래픽의 경우 다음 세 가지 방법 중 하나로 Office 365 액세스합니다.
캘리포니아에있는 사람들을위한 북아메리카 모임 위치를 통해.
홍콩의 사람들을 위해 홍콩의 만남의 위치를 통해.
적은 수의 사람들이 있고 ExpressRoute 회로가 프로비전되지 않은 방글라데시의 인터넷을 통해.
마찬가지로 Office 365 인바운드 네트워크 트래픽은 다음 세 가지 방법 중 하나로 반환됩니다.
캘리포니아에있는 사람들을위한 북아메리카 모임 위치를 통해.
홍콩의 사람들을 위해 홍콩의 만남의 위치를 통해.
적은 수의 사람들이 있고 ExpressRoute 회로가 프로비전되지 않은 방글라데시의 인터넷을 통해.
적절한 모임 위치 확인
ExpressRoute 회로가 네트워크를 Microsoft 네트워크에 연결하는 물리적 위치인 meet-me 위치의 선택은 사용자가 Office 365 액세스할 위치에 따라 영향을 받습니다. SaaS 제품인 Office 365 Azure와 동일한 방식으로 IaaS 또는 PaaS 지역 모델에서 작동하지 않습니다. 대신, Office 365 사용자가 여러 데이터 센터 및 지역의 엔드포인트에 연결해야 할 수 있는 분산된 공동 작업 서비스 집합으로, 사용자의 테넌트가 호스트되는 위치나 지역에 반드시 있을 필요는 없습니다.
즉, Office 365 ExpressRoute에 대한 meet-me 위치를 선택할 때 가장 중요한 고려 사항은 조직의 사용자가 연결하는 위치입니다. 최적의 Office 365 연결에 대한 일반적인 권장 사항은 라우팅을 구현하는 것이므로 Office 365 서비스에 대한 사용자 요청이 가장 짧은 네트워크 경로를 통해 Microsoft 네트워크로 전달되므로 종종 '핫 포테이토' 라우팅이라고도 합니다. 예를 들어 대부분의 Office 365 사용자가 하나 또는 두 개의 위치에 있는 경우 해당 사용자의 위치와 가장 가까운 meet-me 위치를 선택하면 최적의 디자인이 만들어집니다. 회사에 여러 지역에 많은 사용자 채우기가 있는 경우 여러 ExpressRoute 회로 및 모임 위치가 있는 것을 고려할 수 있습니다. 일부 사용자 위치의 경우 Microsoft 네트워크 및 Office 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(뉴욕 경유) |
Office 365 지역, ExpressRoute 네트워크 서비스 공급자 meet-me 위치 및 위치별 사용자 수량을 보여 주는 전역 네트워크 아키텍처가 개발되면 최적화를 수행할 수 있는지 식별하는 데 사용할 수 있습니다. 또한 모임 위치를 가져오기 위해 트래픽이 먼 위치로 라우팅되는 글로벌 헤어핀 네트워크 연결을 표시할 수도 있습니다. 글로벌 네트워크의 헤어핀이 발견되면 계속하기 전에 수정해야 합니다. 다른 meet-me 위치를 찾거나 선택적 인터넷 브레이크아웃 송신 지점을 사용하여 헤어핀을 방지합니다.
첫 번째 다이어그램은 북아메리카 두 개의 물리적 위치가 있는 고객의 예를 보여줍니다. Office 위치, Office 365 테넌트 위치 및 ExpressRoute meet-me 위치에 대한 몇 가지 선택에 대한 정보를 볼 수 있습니다. 이 예제에서 고객은 다음 두 가지 원칙에 따라 meet-me 위치를 순서대로 선택했습니다.
조직 내 사용자와 가장 가깝습니다.
Office 365 호스팅되는 Microsoft 데이터 센터와 가장 가깝습니다.
이 개념을 약간 더 확장하면 두 번째 다이어그램은 유사한 정보 및 의사 결정에 직면한 다국적 고객의 예를 보여줍니다. 이 고객은 방글라데시에 작은 사무실을 두고 있으며, 10명으로 구성된 소규모 팀만이 이 지역에서 자신의 발자국을 늘리는 데 집중했습니다. 첸나이에는 meet-me 위치와 첸나이에서 호스팅되는 Office 365 있는 Microsoft 데이터 센터가 있으므로 모임 위치가 합리적입니다. 그러나 10명에게는 추가 회로 비용이 부담스럽습니다. 네트워크를 살펴보면 네트워크를 통해 네트워크 트래픽을 보내는 데 관련된 대기 시간이 다른 ExpressRoute 회로를 획득하기 위해 자본을 지출하는 것보다 더 효과적인지 확인해야 합니다.
또는 방글라데시의 10명은 소개 다이어그램에 나와 있고 아래에서 재현한 것처럼 내부 네트워크에서 라우팅하는 것보다 인터넷을 통해 Microsoft 네트워크로 전송되는 네트워크 트래픽으로 더 나은 성능을 경험할 수 있습니다.
Office 365 구현 계획을 위한 ExpressRoute 만들기
구현 계획에는 ExpressRoute 구성의 기술 세부 정보와 네트워크의 다른 모든 인프라 구성 세부 정보(예: 다음)가 모두 포함됩니다.
ExpressRoute와 인터넷 간에 분할된 서비스를 계획합니다.
대역폭, 보안, 고가용성 및 장애 조치(failover)를 계획합니다.
다양한 위치에 대한 적절한 라우팅 경로 최적화를 포함하여 인바운드 및 아웃바운드 라우팅 디자인
ExpressRoute 경로가 네트워크에 보급되는 시간과 클라이언트가 인터넷 또는 ExpressRoute 경로를 선택하는 메커니즘을 결정합니다. 예를 들어 직접 라우팅 또는 애플리케이션 프록시입니다.
보낸 사람 정책 프레임워크 항목을 포함하여 DNS 레코드 변경 내용을 계획합니다.
아웃바운드 및 인바운드 원본 NAT를 포함한 NAT 전략을 계획합니다.
인터넷 및 ExpressRoute 네트워크 경로를 모두 사용하여 라우팅 계획
초기 배포의 경우 인바운드 메일 또는 하이브리드 연결과 같은 모든 인바운드 서비스가 인터넷을 사용하는 것이 좋습니다.
PAC/WPAD 파일, 기본 경로, 프록시 서버 및 BGP 경로 보급 알림 구성과 같은 최종 사용자 클라이언트 LAN 라우팅을 계획합니다.
프록시 서버, 방화벽 및 클라우드 프록시를 포함한 경계 라우팅을 계획합니다.
대역폭, 보안, 고가용성 및 장애 조치 계획
각 주요 Office 365 워크로드에 필요한 대역폭 계획을 만듭니다. Exchange Online, SharePoint Online 및 비즈니스용 Skype Online 대역폭 요구 사항을 별도로 예측합니다. Exchange Online 및 비즈니스용 Skype 위해 제공한 추정 계산기를 시작 지점으로 사용할 수 있습니다. 그러나 조직의 대역폭 요구 사항을 완전히 이해하려면 사용자 프로필 및 위치의 대표적인 샘플을 사용한 파일럿 테스트가 필요합니다.
각 인터넷 및 ExpressRoute 송신 위치에서 보안이 처리되는 방식을 계획에 추가하고, 공용 피어링을 사용하기 Office 365 모든 ExpressRoute 연결을 기억하고, 외부 네트워크에 연결하는 회사 보안 정책에 따라 보안이 유지되어야 합니다.
중단 유형 및 해당 사용자가 가장 간단한 방식으로 전체 용량으로 작업을 수행할 수 있는 방법에 대한 세부 정보를 계획에 추가합니다.
지터, 대기 시간, 정체 및 헤드룸에 대한 비즈니스용 Skype 요구 사항을 포함한 대역폭 요구 사항 계획
비즈니스용 Skype Online에는 비즈니스용 Skype Online의 미디어 품질 및 네트워크 연결 성능 문서에 자세히 설명된 특정 추가 네트워크 요구 사항도 있습니다.
Office 365 ExpressRoute를 사용하여 네트워크 계획에서 Azure ExpressRoute에 대한 대역폭 계획 섹션을 읽어보기.
파일럿 사용자와 함께 대역폭 평가를 수행할 때 가이드를 사용할 수 있습니다. 기준 및 성능 기록을 사용하여 성능 조정을 Office 365.
고가용성 요구 사항 계획
요구 사항에 맞게 고가용성을 위한 계획을 만들고 이를 업데이트된 네트워크 토폴로지 다이어그램에 통합합니다. Office 365 ExpressRoute를 사용하여 네트워크 계획에서 Azure ExpressRoute를 사용한 고가용성 및 장애 조치(failover) 섹션을 참조하세요.
네트워크 보안 요구 사항 계획
네트워크 보안 요구 사항을 충족하는 계획을 만들고 이를 업데이트된 네트워크 토폴로지 다이어그램에 통합합니다. Office 365 ExpressRoute를 사용하여 네트워크 계획에서 Office 365 시나리오에 대한 Azure ExpressRoute에 보안 컨트롤 적용 섹션을 읽어보십시오.
아웃바운드 서비스 연결 디자인
Office 365 ExpressRoute에는 익숙하지 않을 수 있는 아웃바운드 네트워크 요구 사항이 있습니다. 특히 Microsoft에 대한 아웃바운드 네트워크 연결의 원본 엔드포인트 역할을 Office 365 사용자 및 네트워크를 나타내는 IP 주소는 아래에 설명된 특정 요구 사항을 따라야 합니다.
엔드포인트는 회사 또는 ExpressRoute 연결을 제공하는 통신 사업자에 등록된 공용 IP 주소여야 합니다.
엔드포인트는 Microsoft에 보급되고 ExpressRoute에서 유효성을 검사/수락해야 합니다.
엔드포인트는 동일하거나 더 선호되는 라우팅 메트릭을 사용하여 인터넷에 보급해서는 안 됩니다.
ExpressRoute를 통해 구성되지 않은 Microsoft 서비스 연결에 엔드포인트를 사용하면 안 됩니다.
네트워크 디자인이 이러한 요구 사항을 충족하지 않는 경우 사용자가 경로 블랙 홀링 또는 비대칭 라우팅으로 인해 Office 365 및 기타 Microsoft 서비스 연결 오류가 발생할 위험이 높습니다. 이는 Microsoft 서비스 요청이 ExpressRoute를 통해 라우팅되지만 응답이 인터넷을 통해 다시 라우팅되거나 그 반대로 라우팅되고 방화벽과 같은 상태 저장 네트워크 디바이스에서 응답이 삭제되는 경우에 발생합니다.
위의 요구 사항을 충족하는 데 사용할 수 있는 가장 일반적인 방법은 네트워크의 일부로 구현되거나 ExpressRoute 통신 사업자가 제공하는 원본 NAT를 사용하는 것입니다. 원본 NAT를 사용하면 ExpressRoute에서 인터넷 네트워크의 세부 정보 및 개인 IP 주소를 추상화할 수 있습니다. 적절한 IP 경로 보급 알림과 함께 경로 대칭을 보장하는 쉬운 메커니즘을 제공합니다. ExpressRoute 피어링 위치와 관련된 상태 저장 네트워크 디바이스를 사용하는 경우 경로 대칭을 보장하려면 각 ExpressRoute 피어링에 대해 별도의 NAT 풀을 구현해야 합니다.
ExpressRoute NAT 요구 사항에 대해 자세히 알아보세요.
네트워크 토폴로지 다이어그램에 아웃바운드 연결에 대한 변경 내용을 추가합니다.
인바운드 서비스 연결 디자인
대부분의 엔터프라이즈 Office 365 배포에서는 Exchange, SharePoint 및 비즈니스용 Skype 하이브리드 시나리오, 사서함 마이그레이션 및 ADFS 인프라를 사용한 인증과 같이 Office 365 온-프레미스 서비스로의 인바운드 연결을 가정합니다. ExpressRoute에서 아웃바운드 연결을 위해 온-프레미스 네트워크와 Microsoft 간에 추가 라우팅 경로를 사용하도록 설정하면 이러한 흐름이 인터넷을 계속 사용하려는 경우에도 이러한 인바운드 연결이 실수로 비대칭 라우팅의 영향을 받을 수 있습니다. 아래에 설명된 몇 가지 예방 조치는 Office 365 온-프레미스 시스템으로의 인터넷 기반 인바운드 흐름에 영향을 주지 않도록 하는 것이 좋습니다.
인바운드 네트워크 트래픽 흐름에 대한 비대칭 라우팅의 위험을 최소화하려면 모든 인바운드 연결이 ExpressRoute에 대한 라우팅 가시성이 있는 네트워크 세그먼트로 라우팅되기 전에 원본 NAT를 사용해야 합니다. 들어오는 연결이 원본 NAT 없이 ExpressRoute에 대한 라우팅 표시 유형이 있는 네트워크 세그먼트에 허용되는 경우 Office 365 시작된 요청은 인터넷에서 입력되지만 Office 365 다시 가는 응답은 ExpressRoute 네트워크 경로를 Microsoft 네트워크로 다시 사용하는 것을 선호하므로 비대칭 라우팅이 발생합니다.
이 요구 사항을 충족하기 위해 다음 구현 패턴 중 하나를 고려할 수 있습니다.
인터넷에서 온-프레미스 시스템으로의 경로에서 방화벽 또는 부하 분산 장치와 같은 네트워킹 장비를 사용하여 요청이 내부 네트워크로 라우팅되기 전에 원본 NAT를 수행합니다.
프런트 엔드 서버 또는 역방향 프록시 시스템과 같은 인바운드 서비스가 있는 네트워크 세그먼트에 ExpressRoute 경로가 전파되지 않도록 하여 인터넷 연결을 처리합니다.
네트워크에서 이러한 시나리오를 명시적으로 고려하고 인터넷을 통해 모든 인바운드 네트워크 트래픽 흐름을 유지하면 비대칭 라우팅의 배포 및 운영 위험을 최소화하는 데 도움이 됩니다.
ExpressRoute 연결을 통해 일부 인바운드 흐름을 전달하도록 선택할 수 있는 경우가 있을 수 있습니다. 이러한 시나리오의 경우 다음과 같은 추가 고려 사항을 고려합니다.
Office 365 공용 IP를 사용하는 온-프레미스 엔드포인트만 대상으로 지정할 수 있습니다. 즉, 온-프레미스 인바운드 엔드포인트가 ExpressRoute를 통해 Office 365만 노출되더라도 공용 IP가 연결되어 있어야 합니다.
Office 365 서비스가 온-프레미스 엔드포인트를 확인하기 위해 수행하는 모든 DNS 이름 확인은 공용 DNS를 사용하여 발생합니다. 즉, 인터넷의 IP 매핑에 인바운드 서비스 엔드포인트의 FQDN을 등록해야 합니다.
ExpressRoute를 통해 인바운드 네트워크 연결을 받으려면 이러한 엔드포인트에 대한 공용 IP 서브넷을 ExpressRoute를 통해 Microsoft에 보급해야 합니다.
이러한 인바운드 네트워크 트래픽 흐름을 신중하게 평가하여 회사 보안 및 네트워크 정책에 따라 적절한 보안 및 네트워크 제어가 적용되도록 합니다.
온-프레미스 인바운드 엔드포인트가 ExpressRoute를 통해 Microsoft에 보급되면 ExpressRoute는 Office 365 포함하여 모든 Microsoft 서비스 대해 해당 엔드포인트에 대한 기본 라우팅 경로가 됩니다. 즉, 이러한 엔드포인트 서브넷은 Office 365 서비스와의 통신에만 사용해야 하며 Microsoft 네트워크의 다른 서비스는 사용하지 않아야 합니다. 그렇지 않으면 다른 Microsoft 서비스 인바운드 연결이 ExpressRoute를 통해 인바운드를 라우팅하는 것을 선호하는 반면 반환 경로는 인터넷을 사용하는 비대칭 라우팅이 발생합니다.
ExpressRoute 회로 또는 meet-me 위치가 다운된 경우 별도의 네트워크 경로를 통해 요청을 수락하기 위해 온-프레미스 인바운드 엔드포인트를 계속 사용할 수 있는지 확인해야 합니다. 이는 여러 ExpressRoute 회로를 통해 해당 엔드포인트에 대한 서브넷을 광고하는 것을 의미할 수 있습니다.
특히 이러한 흐름이 방화벽과 같은 상태 저장 네트워크 디바이스를 교차하는 경우 ExpressRoute를 통해 네트워크에 들어오는 모든 인바운드 네트워크 트래픽 흐름에 원본 NAT를 적용하는 것이 좋습니다.
ADFS 프록시 또는 Exchange 자동 검색과 같은 일부 온-프레미스 서비스는 인터넷에서 Office 365 서비스와 사용자 모두에서 인바운드 요청을 받을 수 있습니다. 이러한 요청의 경우 Office 365 인터넷을 통해 사용자 요청과 동일한 FQDN을 대상으로 합니다. 인터넷에서 온-프레미스 엔드포인트로의 인바운드 사용자 연결을 허용하는 동시에 Office 365 연결에서 ExpressRoute를 사용하도록 강제하는 것은 상당한 라우팅 복잡성을 나타냅니다. ExpressRoute를 통해 이러한 복잡한 시나리오를 구현하는 대부분의 고객은 운영 고려 사항으로 인해 권장되지 않습니다. 이러한 추가 오버헤드에는 비대칭 라우팅의 위험 관리가 포함되며 여러 차원의 라우팅 광고 및 정책을 신중하게 관리해야 합니다.
비대칭 경로를 방지하는 방법을 표시하도록 네트워크 토폴로지 계획을 업데이트합니다.
비대칭 라우팅을 방지하여 조직의 사용자가 인터넷의 다른 중요한 서비스뿐만 아니라 Office 365 원활하게 사용할 수 있도록 합니다. 고객에게는 비대칭 라우팅을 유발하는 두 가지 일반적인 구성이 있습니다. 이제 사용하려는 네트워크 구성을 검토하고 이러한 비대칭 라우팅 시나리오 중 하나가 존재할 수 있는지 확인하는 것이 좋습니다.
먼저 다음 네트워크 다이어그램과 관련된 몇 가지 다른 상황을 살펴보겠습니다. 이 다이어그램에서는 ADFS 또는 온-프레미스 하이브리드 서버와 같은 인바운드 요청을 받는 모든 서버가 뉴저지 데이터 센터에 있으며 인터넷에 보급됩니다.
경계 네트워크는 안전하지만 들어오는 요청에 사용할 수 있는 원본 NAT는 없습니다.
뉴저지 데이터 센터의 서버는 인터넷 및 ExpressRoute 경로를 모두 볼 수 있습니다.
또한 문제를 해결하는 방법에 대한 제안도 있습니다.
문제 1: 인터넷을 통해 클라우드-온-프레미스 연결
다음 다이어그램에서는 네트워크 구성이 인터넷을 통해 Microsoft 클라우드의 인바운드 요청에 NAT를 제공하지 않을 때 수행되는 비대칭 네트워크 경로를 보여 줍니다.
Office 365 인바운드 요청은 공용 DNS에서 온-프레미스 엔드포인트의 IP 주소를 검색하고 요청을 경계 네트워크로 보냅니다.
이 잘못된 구성에서는 트래픽이 전송되는 경계 네트워크에서 원본 NAT를 구성하거나 사용할 수 없으므로 실제 원본 IP 주소가 반환 대상으로 사용됩니다.
네트워크의 서버는 사용 가능한 ExpressRoute 네트워크 연결을 통해 반환 트래픽을 Office 365 라우팅합니다.
그 결과 해당 흐름이 Office 365 대한 비대칭 경로가 생성되어 연결이 끊어집니다.
솔루션 1a: 원본 NAT
원본 NAT를 인바운드 요청에 추가하기만 하면 잘못 구성된 네트워크가 해결됩니다. 다음은 이 다이어그램에 대한 설명입니다.
들어오는 요청은 뉴저지 데이터 센터의 경계 네트워크를 통해 계속 입력됩니다. 이번에는 원본 NAT를 사용할 수 있습니다.
서버의 응답은 원래 IP 주소 대신 원본 NAT와 연결된 IP로 다시 라우팅되어 응답이 동일한 네트워크 경로를 따라 반환됩니다.
솔루션 1b: 경로 범위 지정
또는 ExpressRoute BGP 접두사 보급을 허용하지 않도록 선택하여 해당 컴퓨터에 대한 대체 네트워크 경로를 제거할 수 있습니다. 다음은 이 다이어그램에 대한 설명입니다.
들어오는 요청은 뉴저지 데이터 센터의 경계 네트워크를 통해 계속 입력됩니다. 이번에는 ExpressRoute 회로를 통해 Microsoft에서 보급된 접두사는 뉴저지 데이터 센터에서 사용할 수 없습니다.
서버의 응답은 사용 가능한 유일한 경로를 통해 원래 IP 주소와 연결된 IP로 다시 라우팅되어 동일한 네트워크 경로를 따라 응답이 반환됩니다.
문제 2: ExpressRoute를 통해 클라우드-온-프레미스 연결
다음 다이어그램에서는 네트워크 구성이 ExpressRoute를 통해 Microsoft 클라우드의 인바운드 요청에 NAT를 제공하지 않을 때 수행되는 비대칭 네트워크 경로를 보여 줍니다.
Office 365 인바운드 요청은 DNS에서 IP 주소를 검색하고 요청을 경계 네트워크로 보냅니다.
이 잘못된 구성에서는 트래픽이 전송되는 경계 네트워크에서 원본 NAT를 구성하거나 사용할 수 없으므로 실제 원본 IP 주소가 반환 대상으로 사용됩니다.
네트워크의 컴퓨터는 사용 가능한 ExpressRoute 네트워크 연결을 통해 반환 트래픽을 Office 365 라우팅합니다.
결과는 Office 365 대한 비대칭 연결입니다.
솔루션 2: 원본 NAT
원본 NAT를 인바운드 요청에 추가하기만 하면 잘못 구성된 네트워크가 해결됩니다. 다음은 이 다이어그램에 대한 설명입니다.
들어오는 요청은 뉴욕 데이터 센터의 경계 네트워크를 통해 계속 입력됩니다. 이번에는 원본 NAT를 사용할 수 있습니다.
서버의 응답은 원래 IP 주소 대신 원본 NAT와 연결된 IP로 다시 라우팅되어 응답이 동일한 네트워크 경로를 따라 반환됩니다.
네트워크 디자인에 경로 대칭이 있는지 확인하는 용지
이 시점에서 구현 계획이 Office 365 사용할 다양한 시나리오에 대한 경로 대칭을 제공하는지 종이에 확인해야 합니다. 사용자가 서비스의 다른 기능을 사용할 때 수행해야 하는 특정 네트워크 경로를 식별합니다. 온-프레미스 네트워크 및 WAN 라우팅에서 경계 디바이스, 연결 경로로; ExpressRoute 또는 인터넷 및 온라인 엔드포인트에 대한 연결
조직에서 채택할 서비스로 이전에 식별된 모든 Office 365 네트워크 서비스에 대해 이 작업을 수행해야 합니다.
그것은 두 번째 사람과 경로의이 종이 연습을 수행하는 데 도움이됩니다. 각 네트워크 홉이 다음 경로를 가져올 것으로 예상되는 위치를 설명하고 라우팅 경로에 대해 잘 알고 있는지 확인합니다. ExpressRoute는 항상 인터넷 기본 경로보다 낮은 경로 비용을 제공하는 Microsoft 서버 IP 주소로 더 범위가 지정된 경로를 제공합니다.
클라이언트 연결 구성 디자인
인터넷 바인딩된 트래픽에 프록시 서버를 사용하는 경우 네트워크의 클라이언트 컴퓨터가 프록시 서버를 전송하지 않고 Office 365 ExpressRoute 트래픽을 보내도록 올바르게 구성되고 일부 Office 365 트래픽을 포함한 나머지 트래픽이 관련 프록시로 전송되도록 PAC 또는 클라이언트 구성 파일을 조정해야 합니다. OFFICE 365 엔드포인트(예: PAC 파일)를 관리하는 방법에 대한 가이드를 읽어보세요.
참고
엔드포인트는 매주 자주 변경됩니다. 조직에서 채택한 서비스 및 기능을 기반으로 변경하여 최신 상태를 유지하는 데 필요한 변경 횟수를 줄여야 합니다. 변경 내용이 발표되고 레코드가 모든 과거 변경 내용으로 유지되는 RSS 피드의 유효 날짜 에 주의하세요. 공지된 IP 주소는 유효 날짜에 도달할 때까지 광고되지 않거나 광고에서 제거될 수 있습니다.
배포 및 테스트 절차 빌드
구현 계획에는 테스트 및 롤백 계획이 모두 포함되어야 합니다. 구현이 예상대로 작동하지 않는 경우 문제가 발견되기 전에 최소 사용자 수에 영향을 주도록 계획을 설계해야 합니다. 다음은 계획에서 고려해야 하는 몇 가지 개략적인 원칙입니다.
네트워크 세그먼트 및 사용자 서비스 온보딩을 스테이징하여 중단을 최소화합니다.
별도의 인터넷 연결 호스트에서 추적 경로 및 TCP 연결을 사용하여 경로를 테스트할 계획입니다.
인바운드 및 아웃바운드 서비스의 테스트는 테스트 Office 365 테넌트가 있는 격리된 테스트 네트워크에서 수행해야 합니다.
또는 고객이 아직 Office 365 사용하지 않거나 파일럿 중인 경우 프로덕션 네트워크에서 테스트를 수행할 수 있습니다.
또는 테스트 및 모니터링 전용으로 설정된 프로덕션 중단 중에 테스트를 수행할 수 있습니다.
또는 각 계층 3 라우터 노드에서 각 서비스에 대한 경로를 확인하여 테스트를 수행할 수 있습니다. 이 대체는 물리적 테스트가 부족하여 위험이 발생하기 때문에 다른 테스트가 가능하지 않은 경우에만 사용해야 합니다.
배포 절차 빌드
배포 절차는 대규모 사용자 그룹에 배포하기 전에 테스트할 수 있도록 소규모 그룹의 사용자에게 단계적으로 배포해야 합니다. 다음은 ExpressRoute 배포를 준비하는 여러 가지 방법입니다.
Microsoft 피어링을 사용하여 ExpressRoute를 설정하고 단계적 테스트 목적으로만 경로 보급 알림을 단일 호스트로 전달하도록 합니다.
처음에는 ExpressRoute 네트워크에 대한 경로를 단일 네트워크 세그먼트로 보급하고 네트워크 세그먼트 또는 지역별로 경로 보급을 확장합니다.
Office 365 처음으로 배포하는 경우 몇 명의 사용자에 대한 파일럿으로 ExpressRoute 네트워크 배포를 사용합니다.
프록시 서버를 사용하는 경우 더 추가하기 전에 테스트 및 피드백을 사용하여 몇 명의 사용자를 ExpressRoute로 보내도록 테스트 PAC 파일을 구성할 수도 있습니다.
구현 계획에는 수행해야 하는 각 배포 절차 또는 네트워킹 구성을 배포하는 데 사용해야 하는 명령이 나열되어야 합니다. 네트워크 중단 시간이 도착하면 모든 변경 내용은 미리 작성되고 피어가 검토한 서면 배포 계획에서 수행해야 합니다. ExpressRoute의 기술 구성에 대한 지침을 참조하세요.
전자 메일을 계속 보낼 온-프레미스 서버의 IP 주소를 변경한 경우 SPF TXT 레코드를 업데이트합니다.
새 NAT 구성을 수용하도록 IP 주소를 변경한 경우 온-프레미스 서버에 대한 DNS 항목을 업데이트합니다.
라우팅 또는 프록시 구성을 유지하기 위해 Office 365 엔드포인트 알림에 대한 RSS 피드를 구독했는지 확인합니다.
ExpressRoute 배포가 완료되면 테스트 계획의 절차를 실행해야 합니다. 각 프로시저에 대한 결과를 기록해야 합니다. 테스트 계획 결과가 구현에 성공하지 못했음을 나타내는 경우 원래 프로덕션 환경으로 롤백하는 절차를 포함해야 합니다.
테스트 프로시저 빌드
테스트 절차에는 ExpressRoute를 사용할 Office 365 각 아웃바운드 및 인바운드 네트워크 서비스에 대한 테스트가 포함되어야 합니다. 이 절차에는 회사 LAN의 온-프레미스가 아닌 사용자를 포함하여 각 고유한 네트워크 위치에서의 테스트가 포함되어야 합니다.
테스트 작업의 몇 가지 예는 다음과 같습니다.
온-프레미스 라우터에서 네트워크 운영자 라우터로 Ping.
온-프레미스 라우터에서 500개 이상의 Office 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 대한 연결을 테스트합니다. 또는 미러된 포트의 Wireshark 또는 Microsoft Network Monitor 3.4와 같은 도구를 MSEE에 사용하여 outlook.office365.com 연결된 IP 주소에 연결할 수 있는지 확인할 수 있습니다.
Exchange Online 대한 애플리케이션 수준 기능을 테스트합니다.
테스트 Outlook Exchange Online 연결하고 전자 메일을 보내고 받을 수 있습니다.
테스트 Outlook 온라인 모드를 사용할 수 있습니다.
스마트폰 연결 및 송신/수신 기능을 테스트합니다.
- SharePoint Online에 대한 애플리케이션 수준 기능 테스트
비즈니스용 OneDrive 동기화 클라이언트를 테스트합니다.
온라인 SharePoint 웹 액세스를 테스트합니다.
- 비즈니스용 Skype 호출 시나리오에 대한 애플리케이션 수준 기능을 테스트합니다.
인증된 사용자로 전화 회의에 참가[최종 사용자가 초대]합니다.
전화 회의에 사용자를 초대합니다.[MCU에서 보낸 초대].
비즈니스용 Skype 웹 애플리케이션을 사용하여 익명 사용자로 회의에 참가합니다.
유선 PC 연결, IP 전화 및 모바일 장치에서 통화에 참가합니다.
페더레이션된 사용자에 대한 호출 o PSTN 유효성 검사 호출: 호출이 완료되고 통화 품질이 허용되며 연결 시간이 허용됩니다.
테넌트 및 페더레이션된 사용자 모두에 대해 연락처의 현재 상태가 업데이트되었는지 확인합니다.
일반적인 문제
비대칭 라우팅은 가장 일반적인 구현 문제입니다. 찾을 몇 가지 일반적인 원본은 다음과 같습니다.
원본 NAT가 없는 개방형 또는 플랫 네트워크 라우팅 토폴로지 사용
인터넷 및 ExpressRoute 연결을 통해 인바운드 서비스로 라우팅하는 데 SNAT를 사용하지 않습니다.
광범위하게 배포하기 전에 테스트 네트워크의 ExpressRoute에서 인바운드 서비스를 테스트하지 않습니다.
네트워크를 통해 ExpressRoute 연결 배포
한 번에 하나의 네트워크 세그먼트로 배포를 준비하여 각 새 네트워크 세그먼트에 대해 롤백하는 계획을 사용하여 네트워크의 다른 부분에 대한 연결을 점진적으로 롤아웃합니다. 배포가 Office 365 배포와 일치하는 경우 먼저 Office 365 파일럿 사용자에게 배포하고 여기에서 확장합니다.
먼저 테스트한 다음 프로덕션용으로 다음을 수행합니다.
배포 단계를 실행하여 ExpressRoute를 사용하도록 설정합니다.
네트워크 경로가 예상대로 표시되는지 테스트합니다.
각 인바운드 및 아웃바운드 서비스에서 테스트를 수행합니다.
문제가 발견되면 롤백합니다.
테스트 네트워크 세그먼트를 사용하여 ExpressRoute에 대한 테스트 연결 설정
이제 종이에 완료된 계획을 세웠으므로 이제 소규모로 테스트할 차례입니다. 이 테스트에서는 Microsoft Peering과 온-프레미스 네트워크의 테스트 서브넷에 대한 단일 ExpressRoute 연결을 설정합니다. 테스트 서브넷에 대한 연결을 사용하여 평가판 Office 365 테넌트 및 테스트 서브넷의 프로덕션에서 사용할 모든 아웃바운드 및 인바운드 서비스를 포함할 수 있습니다. 테스트 네트워크 세그먼트에 대한 DNS를 설정하고 모든 인바운드 및 아웃바운드 서비스를 설정합니다. 테스트 계획을 실행하고 각 서비스 및 경로 전파에 대한 라우팅에 대해 잘 알고 있는지 확인합니다.
배포 및 테스트 계획 실행
위에서 설명한 항목을 완료하면 완료한 영역을 확인하고 배포 및 테스트 계획을 실행하기 전에 사용자와 팀이 해당 항목을 검토했는지 확인합니다.
네트워크 변경과 관련된 아웃바운드 및 인바운드 서비스 목록입니다.
인터넷 송신 및 ExpressRoute meet-me 위치를 모두 보여 주는 글로벌 네트워크 아키텍처 다이어그램
배포된 각 서비스에 사용되는 다양한 네트워크 경로를 보여 주는 네트워크 라우팅 다이어그램
필요한 경우 변경 내용 및 롤백을 구현하는 단계가 포함된 배포 계획입니다.
각 Office 365 및 네트워크 서비스를 테스트하기 위한 테스트 계획입니다.
인바운드 및 아웃바운드 서비스에 대한 프로덕션 경로의 종이 유효성 검사를 완료했습니다.
가용성 테스트를 포함하여 테스트 네트워크 세그먼트에서 완료된 테스트입니다.
전체 배포 계획 및 테스트 계획을 실행할 수 있을 만큼 긴 중단 기간을 선택하고, 문제 해결에 사용할 수 있는 시간과 필요한 경우 롤백할 시간이 있습니다.
주의
인터넷과 ExpressRoute를 통해 라우팅하는 복잡한 특성으로 인해 복잡한 라우팅 문제를 처리하기 위해 이 창에 추가 버퍼 시간을 추가하는 것이 좋습니다.
비즈니스용 Skype Online용 QoS 구성
QoS는 비즈니스용 Skype Online에 대한 음성 및 모임 혜택을 얻는 데 필요합니다. ExpressRoute 네트워크 연결이 다른 Office 365 서비스 액세스를 차단하지 않도록 한 후에 QoS를 구성할 수 있습니다. QoS에 대한 구성은 비즈니스용 Skype Online의 ExpressRoute 및 QoS 문서에 설명되어 있습니다.
구현 문제 해결
먼저 이 구현 가이드의 단계를 살펴보는 것이 구현 계획에서 누락되었나요? 가능한 경우 더 작은 네트워크 테스트를 돌아가기 실행하여 오류를 복제하고 디버그합니다.
테스트 중에 실패한 인바운드 또는 아웃바운드 서비스를 식별합니다. 실패한 각 서비스에 대한 IP 주소 및 서브넷을 구체적으로 가져옵니다. 계속 진행하여 네트워크 토폴로지 다이어그램을 종이에 표시하고 라우팅의 유효성을 검사합니다. ExpressRoute 라우팅이 보급되는 위치를 구체적으로 확인하고, 가능한 경우 추적을 사용하여 가동 중단 중에 해당 라우팅을 테스트합니다.
각 고객 엔드포인트에 대한 네트워크 추적을 사용하여 PSPing을 실행하고 원본 및 대상 IP 주소를 평가하여 예상대로 유효한지 확인합니다. 포트 25에 노출하는 모든 메일 호스트에 텔넷을 실행하고 SNAT가 필요한 경우 원래 원본 IP 주소를 숨기고 있는지 확인합니다.
ExpressRoute 연결을 사용하여 Office 365 배포하는 동안 ExpressRoute에 대한 네트워크 구성을 모두 최적으로 설계하고 클라이언트 컴퓨터와 같은 네트워크의 다른 구성 요소도 최적화했는지 확인해야 합니다. 이 계획 가이드를 사용하여 누락되었을 수 있는 단계를 해결하는 것 외에도 Office 365 대한 성능 문제 해결 계획을 작성했습니다.
다음의 간단한 링크를 사용할 수 있습니다. https://aka.ms/implementexpressroute365
관련 주제
Office 365용 Azure ExpressRoute
Office 365 연결에 대한 ExpressRoute 관리
Office 365용 ExpressRoute를 사용한 라우팅
Office 365용 ExpressRoute를 사용한 네트워크 계획
Office 365 시나리오에 대해 ExpressRoute에서 BGP 커뮤니티 사용
비즈니스용 Skype Online의 미디어 품질 및 네트워크 연결 성능
비즈니스용 Skype Online의 ExpressRoute 및 QoS