Office 365용 ExpressRoute 구현

참고:  사용자 언어로 가능한 한 빨리 가장 최신의 도움말 콘텐츠를 제공하고자 합니다. 이 페이지는 자동화를 통해 번역되었으며 문법 오류나 부정확한 설명을 포함할 수 있습니다. 이 목적은 콘텐츠가 사용자에게 유용하다는 것입니다. 이 페이지 하단의 정보가 도움이 되었다면 알려주세요. 쉽게 참조할 수 있는 영어 문서 가 여기 있습니다.

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 관리자, 보안, 최종 사용자 지원, 프로젝트 관리 및 경영진의 후원을 포함하여 조직에 있는 여러 영역의 팀 구성원도 종종 포함됩니다. 계획 프로세스에 투자하면 배포 실패로 인해 가동 중지 시간이 발생하거나 복잡하고 비용이 많이 드는 문제 해결을 수행해야 할 가능성이 줄어듭니다.

이 구현 가이드를 시작하기 전에 다음 필수 조건을 완료해야 합니다.

  1. ExpressRoute가 권장되어 승인되었는지 결정하기 위해 네트워크 평가를 완료했습니다.

  2. ExpressRoute 네트워크 서비스 공급자를 선택했습니다. ExpressRoute 파트너 및 피어링 위치에 대한 세부 정보를 찾으세요.

  3. 이미 읽은 및 express 경로 설명서 이해 내부 네트워크는 express 경로 필수 끝에 맞출 수 있습니다.

  4. 팀에는 모든 공용 가이드 및 https://aka.ms/expressrouteoffice365, https://aka.ms/ert문서 읽기 및 채널 9 파악 한 Office 365 교육 용 Azure express 경로 시리즈가 조사 중요 한 기술적인 세부 사항이 포함:

    • SaaS 서비스의 인터넷 종속성.

    • 비대칭 경로를 방지하고 복잡한 라우팅을 처리하는 방법.

    • 주변 보안, 가용성 및 응용 프로그램 수준 컨트롤 통합 하는 방법입니다.

요구 사항을 수집하여 시작

조직에서 채택하려고 계획하는 기능과 서비스를 파악합니다. 사용할 여러 다른 Office 365 서비스의 기능 및 이 기능을 사용하는 사람들을 호스트할 네트워크의 위치를 파악해야 합니다. 시나리오 카탈로그가 있으면 각 시나리오에 필요한 네트워크 특성을 추가해야 합니다. 예를 들어 인바운드와 아웃바운드 네트워크 트래픽 흐름 및 ExpressRoute를 통해 Office 365 끝점이 사용 가능한지 등입니다.

조직의 요구 사항을 수집하려면 다음 단계를 따르세요.

  • 조직에서 사용 중인 Office 365 서비스의 인바운드 및 아웃바운드 네트워크 트래픽을 카탈로그로 작성합니다. 다른 Office 365 시나리오에 필요한 흐름의 설명은 Office 365 URL 및 IP 주소 범위 페이지를 참조하세요.

  • 내부 WAN 백본 및 토폴로지, 위성 사이트 연결, 최종 사용자 연결, 네트워크 주변 송신 지점으로 라우팅, 프록시 서비스 등의 세부 정보를 표시하는 기존 네트워크 토폴로지 문서를 수집합니다.

    • Office 365와 다른 Microsoft 서비스가 연결할 네트워크 다이어그램의 인바운드 서비스 끝점을 식별하여 인터넷과 제안된 ExpressRoute 연결 경로를 모두 표시합니다.

    • 사용자의 모든 지리적 위치 및 위치 사이의 WAN 연결과 함께 현재 인터넷에 송신되는 위치와 ExpressRoute 피어링 위치에 송신되도록 제안된 위치를 식별합니다.

    • 프록시, 방화벽 등의 모든 종단 장치를 식별하고 인터넷과 ExpressRoute를 통해 이동하는 흐름과의 관계를 카탈로그로 작성합니다.

    • 최종 사용자가 인터넷과 ExpressRoute 흐름을 위해 Office 365 서비스에 액세스하는 데 직접 라우팅을 통하는지 아니면 간접 응용 프로그램 프록시를 통하는지 문서화합니다.

  • 테넌트의 위치와 meet-me 위치를 네트워크 다이어그램에 추가합니다.

  • 주요 사용자 위치에서 Office 365까지 예상 및 관측된 네트워크 성능 및 대기 시간 특성을 계산합니다. Office 365는 전역이며 서비스와 사용자의 분산 집합이 테넌트의 위치와 다를 수 있는 위치에 연결됩니다. 따라서 ExpressRoute와 인터넷 연결을 통해 Microsoft 전역 네트워크의 가장 가까운 가장자리와 사용자 사이의 대기 시간을 측정하여 이에 맞게 최적화하는 것이 좋습니다. 네트워크 평가의 검색 결과를 사용하여 이 작업을 지원할 수 있습니다.

  • 새로운 ExpressRoute 연결을 통해 만족시켜야 하는 회사 네트워크 보안 및 고가용성 요구 사항을 나열합니다. 예를 들어 사용자가 인터넷 송신 또는 ExpressRoute 회로 실패가 발생할 때 Office 365에 계속 액세스하는 방법이 포함됩니다.

  • 되는 인바운드 및 아웃 바운드 Office 365 네트워크 흐름 문서 인터넷 경로 사용 하면 및 express 경로 사용 됩니다. 사용자의 지리적 위치 및 온-프레미스 네트워크 토폴로지와의 세부 정보 세부 사항 계획에 다른 사용자 한 위치에서 다른 필요할 수 있습니다.

라우팅 및 기타 네트워크 복잡성을 최소화 하기 위해만 사용 하는 express 경로 Office 365에 대 한 규정 요구 사항으로 인해 또는 네트워크 평가의 결과로 전용된 연결을 통해 이동 하는 데 필요한 네트워크 트래픽에 흐름에 대 한 것이 좋습니다. 또한 구현 프로젝트의 다양 한 개별 단계도 express 경로 라우팅과 방식으로 아웃 바운드 및 인바운드 네트워크 트래픽 흐름의 범위를 준비 하는 것이 좋습니다. 단지 사용자가 주도하는 아웃 바운드 네트워크 트래픽에 흐름과 나가기 인터넷에서 인바운드 네트워크 트래픽을 흐름 토폴로지 복잡성과 추가 소개에 따른 위험 증가 제어 하기 위해 할 수 있습니다에 대 한 Office 365 용 express 경로 배포 비대칭 라우팅 가능성이 있습니다.

네트워크 트래픽에 카탈로그 온-프레미스 네트워크와 Microsoft 해야 하는 모든 인바운드 및 아웃 바운드 네트워크 연결의 목록이 포함 되어야 합니다.

  • 아웃바운드 네트워크 트래픽 흐름은 내부 클라이언트나 서버와 같이 온-프레미스 환경에서 Microsoft 서비스로 연결되는 시나리오입니다. 이 경우 Office 365에 직접 연결되거나, Office 365와의 연결 경로에 있는 프록시 서버, 방화벽 또는 기타 네트워킹 장치를 통한 경우와 같이 간접적으로 연결될 수 있습니다.

  • 인바운드 트래픽 흐름은 연결이 Microsoft 클라우드에서 시작되어 온-프레미스 호스트로 연결되는 시나리오입니다. 일반적으로 이러한 연결은 외부에서 시작된 흐름을 위해 고객 보안 정책상 필요한 방화벽 및 기타 보안 인프라를 통과해야 합니다.

Office 365용 ExpressRoute로 라우팅 문서에서 경로 대칭 확인 섹션을 읽고 인바운드 트래픽을 보낼 서비스를 결정하고 Office 365 끝점 참조 문서에 Office 365용 ExpressRoute로 표시된 열을 찾아 나머지 연결 정보를 결정합니다.

아웃바운드 연결이 필요한 각 서비스의 네트워크 라우팅, 프록시 구성, 패킷 검사 및 대역폭 요구 사항과 같이 서비스에 계획된 연결을 설명할 수 있습니다.

인바운드 연결이 필요한 각 서비스에는 추가 정보가 필요합니다. Microsoft 클라우드의 서버가 온-프레미스 네트워크와의 연결을 설정합니다. 올바르게 연결하기 위해 인바운드 연결을 수락할 서비스의 공용 DNS 항목, CIDR 서식의 IPv4 IP 주소, 관련된 ISP 장비 및 이러한 연결을 위해 인바운드 NAT 또는 원본 NAT를 처리하는 방식 등 이 연결과 관련된 모든 요소를 설명할 수 있습니다.

인터넷을 통해 연결되는지 아니면 ExpressRoute를 통해 연결되는지에 상관없이 인바운드 연결을 검토하여 비대칭 라우팅이 도입되지 않게 해야 합니다. 다른 Microsoft 서비스와 비 Microsoft 서비스가 Office 365 서비스에서 인바운드 연결을 시작하는 온-프레미스 끝점에 액세스해야 하는 경우도 있습니다. 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

Express 경로를: 5.5.5.0/24

보안/경계 컨트롤

인터넷 경로: DeviceID_002

Express 경로 경로: DeviceID_003

고가용성

두 개의 지역 중복에서 활성/활성

ExpressRoute 회로 – 시카고 및 댈러스

경로 대칭 컨트롤

방법: 원본 NAT

인터넷 경로: 원본 NAT 인바운드 192.168.5.5에 연결

Express 경로 경로: 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

Express 경로 경로/원본 NAT: 1.1.2.0/24 (시카고) 및 1.1.3.0/24 (댈러스)

연결 방법

인터넷: 계층 7 프록시(.pac 파일)를 통함

Express 경로: 직접 라우팅 (프록시 없음)

보안/경계 컨트롤

인터넷 경로: DeviceID_002

Express 경로 경로: DeviceID_003

고가용성

인터넷 경로: 중복 인터넷 송신

Express 경로 경로: ' 핫 감자 ' 액티브/액티브 2 지리 중복 express 경로 회로 – 시카고 및 댈러스 간에 라우팅

경로 대칭 컨트롤

방법: 모든 연결에 대 한 NAT 원본

서비스와 연결된 네트워크 트래픽 흐름을 이해하고 나면 새로운 연결 요구 사항을 통합하고 Office 365용 ExpressRoute를 사용하기 위해 변경한 내용을 설명하는 네트워크 다이어그램을 만들 수 있습니다. 다이어그램에는 다음이 포함되어야 합니다.

  1. Office 365 및 기타 서비스를 액세스할 모든 사용자 위치.

  2. 모든 인터넷 및 ExpressRoute 송신 지점.

  3. 라우터, 방화벽, 응용 프로그램 프록시 서버 및 침입 검색/방지 등의 네트워크 내부 및 외부의 연결을 관리하는 모든 아웃바운드 및 인바운드 장치.

  4. ADFS 웹 응용 프로그램 프록시 서버로부터의 연결을 수락하는 내부 ADFS 서버와 같은 모든 인바운드 트래픽의 내부 대상.

  5. 광고할 모든 IP 서브넷의 카탈로그

  6. Office 365에 액세스할 각 사용자 위치를 식별하고 ExpressRoute에 사용할 meet-me 위치를 나열합니다.

  7. ExpressRoute에서 얻은 Microsoft IP 접두사가 수락되고 필터링되며 전파되는 내부 네트워크 토폴로지의 위치 및 부분.

  8. 네트워크 토폴로지는 각 네트워크 세그먼트의 지리적 위치와 ExpressRoute 및/또는 인터넷을 통해 Microsoft 네트워크에 연결하는 방법을 설명해야 합니다.

아래 다이어그램은 Office 365를 사용하는 각 사용자 위치와 Office 365로의 인바운드 및 아웃바운드 라우팅 광고를 보여줍니다.

ExpressRoute 지역 지리적 모임 장소

아웃바운드 트래픽에서는 사용자가 다음 세 가지 방법 중 하나로 Office 365에 액세스합니다.

  1. 캘리포니아에 있는 사용자는 북미의 meet-me 위치를 통해 액세스합니다.

  2. 홍콩에 있는 사용자는 홍콩의 meet-me 위치를 통해 액세스합니다.

  3. 사용자가 적고 ExpressRoute 회로가 프로비전되지 않은 방글라데시에서는 인터넷을 통해 액세스합니다.

지역 다이어그램의 아웃바운드 연결

마찬가지로 Office 365의 인바운드 네트워크 트래픽은 다음 세 가지 방법 중 하나로 반환됩니다.

  1. 캘리포니아에 있는 사용자는 북미의 meet-me 위치를 통해 액세스합니다.

  2. 홍콩에 있는 사용자는 홍콩의 meet-me 위치를 통해 액세스합니다.

  3. 사용자가 적고 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 회로와 meet-me 위치를 여러 개 보유하는 것이 좋습니다. 일부 사용자 위치에서는 내부 WAN 및 ExpressRoute meet-me 지점이 아니라 인터넷을 통해 Microsoft 네트워크와 Office 365에 최단/최적의 경로로 연결할 수 있습니다.

사용자와 비교적 가까운 지역에 여러 개의 meet-me 위치가 있는 경우가 많습니다. 결정을 내리는 데 도움이 되도록 다음 표를 입력하세요.

캘리포니아와 뉴욕에 계획된 ExpressRoute meet-me 위치

위치

사용자 수

인터넷 송신을 통한 Microsoft 네트워크의 예상 대기 시간

ExpressRoute를 통한 Microsoft 네트워크의 예상 대기 시간

Los Angeles

10,000

~15ms

~10ms(실리콘 밸리 경유)

Washington DC

15,000

~20ms

~10ms(뉴욕 경유)

댈러스

5,000

~15ms

~40ms(뉴욕 경유)

Office 365 지역, ExpressRoute 네트워크 서비스 공급자 meet-me 위치 및 위치별 사용자 수를 표시하는 전역 네트워크 아키텍처를 개발하고 나면 최적화가 가능한지 식별하는 데 사용할 수 있습니다. meet-me 위치에 도달하기 위해 먼 위치로 트래픽을 라우팅하는 전역 hairpin 네트워크 연결도 표시할 수 있습니다. 전역 네트워크에서 hairpin을 발견하면 계속하기 전에 이 문제를 해결해야 합니다. 다른 meet-me 위치를 찾거나 선택적 인터넷 분리 송신 지점을 사용하여 hairpin을 방지하세요.

첫 번째 다이어그램은 북미에 두 개의 실제 위치가 있는 고객의 예를 보여줍니다. 사무실 위치, Office 365 테넌트 위치 및 여러 ExpressRoute meet-me 위치 선택 사항에 대한 정보를 볼 수 있습니다. 이 예에서는 고객이 다음 두 개의 원칙을 차례대로 따라 meet-me 위치를 선택했습니다.

  1. 조직의 사용자에게 가장 근접.

  2. Office 365에서 호스트 되는 Microsoft 데이터 센터에 가까이에 가장 가까운 합니다.

ExpressRoute 미국 지리적 모임 장소

이 개념을 조금 더 확장한 두 번째 다이어그램에서는 비슷한 정보와 의사결정에 직면한 다국적 고객의 예를 보여줍니다. 이 고객은 지역에서의 영향력을 높이는 데 중점을 둔 10명의 소규모 팀만 있는 작은 사무실이 방글라데시에 있습니다. 케나이에 meet-me 위치가 있으며 케나이에서 호스트되는 Office 365가 포함된 Microsoft 데이터 센터가 있으므로 meet-me 위치는 적절합니다. 그러나 10명의 직원에 비해 추가 회로 비용은 부담이 됩니다. 네트워크 전체에서 네트워크 트래픽을 보내는 데 관련된 대기 시간이 다른 ExpressRoute 회로를 확보하는 데 드는 자본에 비해 더 효율적인지 결정해야 합니다.

또는 방글라데시에 있는 10명의 직원이 도입부의 다이어그램에 표시되고 아래에 재현된 대로 내부 네트워크에서 라우팅하는 것보다 인터넷을 통해 Microsoft 네트워크에 네트워크 트래픽을 전송하면 성능이 향상될 수 있습니다.

지역 다이어그램의 아웃바운드 연결

Office 365용 ExpressRoute 구현 계획 만들기

구현 계획에는 ExpressRoute를 구성하는 자세한 기술 정보 외에도 네트워크에 있는 다른 모든 인프라를 구성하는 세부 정보도 모두 포함해야 합니다. 예를 들어 다음과 같습니다.

  • ExpressRoute와 인터넷을 구분하는 서비스 계획.

  • 대역폭, 보안, 고가용성 및 장애 조치 계획.

  • 여러 다른 위치에 맞는 라우팅 경로 최적화를 포함하여 인바운드 및 아웃바운드 라우팅 디자인

  • ExpressRoute 라우팅이 얼마나 멀리까지 네트워크에 광고되는지와 클라이언트가 인터넷 또는 ExpressRoute를 선택하는 메커니즘(예: 직접 라우팅 또는 응용 프로그램 프록시)을 결정합니다.

  • Sender Policy Framework 항목 등의 DNS 레코드 변경 계획.

  • 아웃 바운드 및 인바운드 원본 NAT.를 포함 하 여 NAT 전략 계획

  • 초기 배포에서 인바운드 전자 메일 또는 하이브리드 연결과 같은 모든 인바운드 서비스에서는 인터넷을 사용하는 것이 좋습니다.

  • 최종 사용자 클라이언트 LAN 라우팅을 PAC/WPAD 파일을 구성하는 등, 기본 경로, 프록시 서버 및 BGP 경로 알림에 계획 합니다.

  • 프록시 서버, 방화벽 및 클라우드 프록시 등의 경계 라우팅 계획.

각 주요 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의 대역폭 계획 섹션을 참조하세요.

파일럿 사용자와 대역폭 평가를 수행할 때 Microsoft의 가이드, 기준선과 성능 기록을 사용하여 Office 365 성능 조정을 사용할 수 있습니다.

고가용성 요구 사항 계획

요구 사항에 맞는 고가용성 계획을 마련하여 업데이트된 네트워크 토폴로지 다이어그램에 통합합니다. Office 365용 ExpressRoute를 통한 네트워크 계획Azure ExpressRoute를 통한 고가용성 및 장애 조치 섹션을 참조하세요.

네트워크 보안 요구 사항에 대 한 계획

네트워크 보안 요구 사항에 맞는 계획을 마련하여 업데이트된 네트워크 토폴로지 다이어그램에 통합합니다. Office 365용 ExpressRoute를 통한 네트워크 계획Office 365용 Azure ExpressRoute에 보안 컨트롤 적용 시나리오 섹션을 참조하세요.

Office 365용 ExpressRoute에는 익숙하지 않을 수도 있는 아웃바운드 네트워크 요구 사항이 있습니다. 특히 Office 365에 사용자와 네트워크를 표시하며 Microsoft와 아웃바운드 네트워크 연결의 원본 끝점 역할을 하는 IP 주소는 아래 간략하게 설명된 구체적인 요구 사항을 따라야 합니다.

  1. 끝점은 회사 또는 ExpressRoute 연결을 제공하는 통신사에 등록된 공개 IP 주소여야 합니다.

  2. 끝점은 Microsoft에 광고되며 ExpressRoute를 통해 유효성을 검사하고 허용해야 합니다.

  3. 끝점은 기본 라우팅 메트릭이 같거나 많은 인터넷에 광고하지 않아야 합니다.

  4. 끝점은 ExpressRoute를 통해 구성되지 않은 Microsoft 서비스에 연결하는 데 사용하지 않아야 합니다.

네트워크 디자인이 이러한 요구 사항을 만족하지 않으면 라우팅이 블랙홀 목록에 들어가거나 비대칭 라우팅으로 인해 사용자가 Office 365와 기타 Microsoft 서비스에 연결하는 데 실패할 위험이 큽니다. 이 문제는 Microsoft 서비스 요청이 ExpressRoute를 통해 라우팅되지만 응답이 인터넷을 통해 다시 라우팅되고(또는 그 반대의 경우) 응답이 방화벽과 같은 상태 저장 네트워크 장치에서 삭제되는 경우 발생합니다.

위의 요구 사항을 만족시키기 위해 사용할 수 있는 가장 일반적인 방법은 네트워크의 일부로 구현되었거나 ExpressRoute 통신사를 통해 제공된 원본 NAT를 사용하는 것입니다. 원본 NAT를 사용하면 ExpressRoute에서 시작되는 인터넷 네트워크의 세부 정보와 개인용 IP 주소 지정을 추상화하고, 적절한 IP 경로 광고와 함께 결합하여 경로가 대칭이 되게 하는 쉬운 메커니즘을 제공할 수 있습니다. ExpressRoute 피어링 위치에 특정한 상태 저장 네트워크 장치를 사용 중이면 경로가 대칭이 되도록 각 ExpressRoute 피어링의 개별 NAT 풀을 구현해야 합니다.

ExpressRoute NAT 요구 사항에 관한 자세한 정보를 참조하세요.

네트워크 토폴로지 다이어그램에 아웃바운드 연결의 변경 내용을 추가합니다.

대부분의 엔터프라이즈 Office 365 배포에서는 Office 365에서 온-프레미스 서비스(예: Exchange, SharePoint 및 비즈니스용 Skype 하이브리드 시나리오, 사서함 마이그레이션 및 ADFS 인프라를 사용한 인증)로의 인바운드 연결이 설정된다고 가정합니다. 아웃바운드 연결을 위해 ExpressRoute를 통해 온-프레미스 네트워크와 Microsoft 사이의 추가 라우팅 경로를 사용하도록 설정하면, 인바운드 연결 흐름에서 계속 인터넷을 사용하게 하려는 경우에도 비대칭 라우팅으로 인해 인바운드 연결에 불리한 영향을 미칠 수 있습니다. Office 365에서 온-프레미스 시스템으로의 인터넷 기반 인바운드 흐름에 영향을 미치지 않도록 아래 설명된 몇 가지 예방 조치를 수행하는 것이 좋습니다.

인바운드 네트워크 트래픽 흐름이 비대칭으로 라우팅되는 위험을 최소화하려면, ExpressRoute로 라우팅되는 네트워크 세그먼트로 인바운드 연결이 라우팅되기 전에 모든 인바운드 연결에서 원본 NAT를 사용해야 합니다. 원본 NAT를 사용하지 않고, ExpressRoute로 라우팅되는 네트워크 세그먼트로 들어오는 연결이 허용되는 경우에는, Office 365에서 시작되는 요청이 인터넷을 통해 들어가지만 Office 365로 다시 돌아가는 응답은 Microsoft 네트워크로 되돌아가는 ExpressRoute 네트워크 경로를 선호하게 되어 비대칭 라우팅이 초래됩니다.

이 요구 사항을 충족시키기 위해 다음 구현 패턴 중 하나를 고려할 수 있습니다.

  1. 인터넷에서 온-프레미스 시스템으로 연결된 경로에서 방화벽 또는 부하 분산 장치와 같은 네트워크 장치를 사용하여 내부 네트워크에 요청을 라우팅하기 전에 원본 NAT를 수행합니다.

  2. 프런트 엔드 서버 또는 역방향 프록시 시스템과 같이 인터넷 연결을 처리하는 인바운드 서비스가 있는 네트워크 세그먼트에 ExpressRoute 라우팅이 전파되지 않게 합니다.

네트워크에서 이러한 시나리오를 명시적으로 설명하고 인터넷을 통해 모든 인바운드 네트워크 트래픽 흐름을 유지하면 비대칭 라우팅으로 인한 배포 및 운영 위험을 완화할 수 있습니다.

경우에 따라 ExpressRoute 연결을 통해 인바운드 흐름을 연결하도록 선택할 수 있습니다. 이러한 시나리오에서는 다음과 같은 추가 내용을 고려하세요.

  1. Office 365는 공개 IP를 사용하는 온-프레미스 끝점만 대상으로 지정할 수 있습니다. 즉, 온-프레미스 인바운드 끝점이 ExpressRoute를 통해 Office 365에만 노출된 경우에도 여전히 공개 IP가 연결되어야 합니다.

  2. Office 365 서비스가 온-프레미스 끝점을 해결하기 위해 수행하는 모든 DNS 이름 분석은 공개 DNS를 사용하여 수행합니다. 즉, 인터넷에서 인바운드 서비스 끝점의 FQDN과 IP 매핑을 등록해야 합니다.

  3. ExpressRoute를 통해 인바운드 네트워크 연결을 받으려면 해당 끝점의 공개 IP 서브넷을 ExpressRoute를 통해 Microsoft에 광고해야 합니다.

  4. 회사 보안 및 네트워크 정책을 따라 적절한 보안 및 네트워크 컨트롤을 적용할 수 있도록 이러한 인바운드 네트워크 트래픽 흐름을 신중하게 평가하세요.

  5. 온-프레미스 인바운드 끝점을 ExpressRoute를 통해 Microsoft에 광고하고 나면 ExpressRoute가 Office 365를 비롯한 모든 Microsoft 서비스의 끝점을 향한 선호 라우팅 경로가 됩니다. 즉, 해당 끝점 서브넷은 Microsoft 네트워크의 다른 서비스가 아니라 Office 365 서비스와 통신하는 데만 사용해야 합니다. 그러지 않으면 디자인상 다른 Microsoft 서비스의 인바운드 연결이 ExpressRoute를 통한 인바운드 라우팅을 선호하는 반면, 반환 경로는 인터넷을 사용하는 비대칭 라우팅이 발생합니다.

  6. ExpressRoute 회로 또는 meet-me 위치가 작동하지 않는 경우 온-프레미스 인바운드 끝점에서 개별 네트워크 경로를 통해 여전히 요청을 수락할 수 있는지 확인해야 합니다. 즉, 여러 ExpressRoute 회로를 통해 해당 끝점의 서브넷을 광고할 수 있습니다.

  7. 이러한 흐름이 방화벽과 같은 상태 저장 네트워크 장치를 통과할 때 특히 ExpressRoute를 통해 네트워크에 들어오는 모든 인바운드 네트워크 트래픽 흐름의 원본 NAT를 적용하는 것이 좋습니다.

  8. ADFS 프록시 또는 Exchange 자동 검색과 같은 온-프레미스 서비스에서는 인터넷의 사용자와 Office 365 서비스의 인바운드 요청을 받을 수 있습니다. 이러한 요청의 경우 Office 365에서는 인터넷을 통한 사용자 요청과 동일한 FQDN을 대상으로 지정합니다. Office 365에서 ExpressRoute를 사용하게 하면서 인터넷에서 온-프레미스 끝점으로의 인바운드 사용자 연결을 허용하면 라우팅이 매우 복잡하게 됩니다. 운영 고려 사항으로 인해 대다수의 고객에게 ExpressRoute를 통해 이와 같이 복잡한 시나리오를 구현하는 것은 권장되지 않습니다. 이 추가 오버헤드에는 비대칭 라우팅 위험 관리가 포함되며 사용자가 여러 차원에 걸쳐 라우팅 광고와 정책을 신중하게 관리해야 합니다.

조직의 사용자가 Office 365 외에도 인터넷의 기타 중요한 서비스를 원활하게 사용할 수 있도록 비대칭 라우팅을 방지해야 합니다. 고객의 구성 중 비대칭 라우팅을 초래하는 가장 일반적인 구성은 두 가지입니다. 지금 사용할 네트워크 구성을 검토하고 비대칭 라우팅 시나리오 중 하나가 있는지 확인하는 것이 좋습니다.

먼저 다음 네트워크 다이어그램과 관련된 몇 가지 서로 다른 상황을 살펴보겠습니다. 이 다이어그램에서는 ADFS나 온-프레미스 하이브리드 서비스와 같이 인바운드 요청을 받는 모든 서버가 뉴저지 센터에 있으며 인터넷에 광고됩니다.

  1. 경계 네트워크는 안전하지만 들어오는 요청에 사용할 수 있는 원본 NAT가 없습니다.

  2. 뉴저지 데이터 센터에 있는 서버에서는 인터넷과 ExpressRoute 라우팅을 모두 볼 수 있습니다.

ExpressRoute 연결 개요

수정 방법에 대한 권장 사항도 있습니다.

문제 1: 인터넷을 통해 클라우드와 온-프레미스 연결

다음 다이어그램에서는 네트워크 구성에서 인터넷을 통해 Microsoft 클라우드에서 들어오는 인바운드 요청에 NAT를 제공하지 않는 경우 사용하는 비대칭 네트워크 경로를 설명합니다.

  1. Office 365의 인바운드 요청은 공개 DNS에서 온-프레미스 끝점의 IP 주소를 검색하여 경계 네트워크에 요청을 보냅니다.

  2. 이 잘못된 구성에서는 트래픽이 전송되는 경계 네트워크에서 구성되었거나 사용 가능한 원본 NAT가 없으므로, 실제 원본 IP 주소가 반환 대상으로 사용됩니다.

    • 네트워크의 서버가 사용 가능한 ExpressRoute 네트워크 연결을 통해 반환 트래픽을 Office 365로 라우팅합니다.

    • 결과적으로 Office 365로 향하는 해당 흐름의 비대칭 경로가 생기므로 연결이 끊깁니다.

ExpressRoute 비대칭 라우팅 문제 1

해결 방법 1a: 원본 NAT

인바운드 요청에 원본 NAT를 추가하기만 하면 이 잘못 구성된 네트워크 문제가 해결됩니다. 이 다이어그램에서는 다음이 수행됩니다.

  1. 들어오는 요청이 계속 뉴저지 데이터 센터의 경계 네트워크를 통과하여 입력됩니다. 이때 원본 NAT를 사용할 수 있습니다.

  2. 서버의 응답이 원래 IP 주소 대신 원본 NAT와 연관된 IP로 다시 라우팅되므로, 동일한 네트워크 경로를 따라 응답이 반환됩니다.

ExpressRoute 비대칭 라우팅 해결 방법 1

해결 방법 1b: 경로 범위 지정

또는 ExpressRoute BGP 접두사를 광고하지 못하게 선택하여 해당 컴퓨터의 대체 네트워크 경로를 제거할 수 있습니다. 이 다이어그램에서는 다음이 수행됩니다.

  1. 들어오는 요청이 계속 뉴저지 데이터 센터의 경계 네트워크를 통과하여 입력됩니다. 이때 ExpressRoute 회로를 통해 Microsoft에서 광고되는 접두사는 뉴저지 데이터 센터에서 사용할 수 없습니다.

  2. 서버의 응답이 사용 가능한 유일한 경로를 통해 원본 IP 주소와 연관된 IP로 다시 라우팅되므로, 동일한 네트워크 경로를 따라 응답이 반환됩니다.

ExpressRoute 비대칭 라우팅 해결 방법 2

문제 2: ExpressRoute를 통해 클라우드와 온-프레미스 연결

다음 다이어그램에서는 네트워크 구성에서 ExpressRoute를 통해 Microsoft 클라우드에서 들어오는 인바운드 요청에 NAT를 제공하지 않는 경우 사용하는 비대칭 네트워크 경로를 설명합니다.

  1. Office 365의 인바운드 요청은 DNS에서 IP 주소를 검색하여 경계 네트워크에 요청을 보냅니다.

  2. 이 잘못된 구성에서는 트래픽이 전송되는 경계 네트워크에서 구성되었거나 사용 가능한 원본 NAT가 없으므로, 실제 원본 IP 주소가 반환 대상으로 사용됩니다.

    • 네트워크의 컴퓨터가 사용 가능한 ExpressRoute 네트워크 연결을 통해 반환 트래픽을 Office 365로 라우팅합니다.

    • 결과적으로 Office 365에 비대칭으로 연결됩니다.

ExpressRoute 비대칭 라우팅 문제 2

해결 방법 2: 원본 NAT

인바운드 요청에 원본 NAT를 추가하기만 하면 이 잘못 구성된 네트워크 문제가 해결됩니다. 이 다이어그램에서는 다음이 수행됩니다.

  1. 들어오는 요청이 계속 뉴욕 데이터 센터의 경계 네트워크를 통과하여 입력됩니다. 이때 원본 NAT를 사용할 수 있습니다.

  2. 서버의 응답이 원래 IP 주소 대신 원본 NAT와 연관된 IP로 다시 라우팅되므로, 동일한 네트워크 경로를 따라 응답이 반환됩니다.

ExpressRoute 비대칭 라우팅 해결 방법 3

네트워크 디자인에 경로 대칭이 있음을 이론적으로 확인

이제 사용자의 구현 계획에서 Office 365를 사용할 다른 시나리오에 경로 대칭을 제공하는지 이론적으로 확인해야 합니다. 서비스의 다른 기능을 사용할 때 선택해야 하는 특정 네트워크 경로를 식별합니다. 온-프레미스 네트워크와 WAN 라우팅에서 경계 장치, 연결 경로, ExpressRoute 또는 인터넷, 온라인 끝점과의 연결까지입니다.

조직이 채택한 서비스로 이전에 식별된 Office 365 네트워크 서비스 모두에 대해 이 작업을 수행해야 합니다.

그러면 두 번째 사용자와 이론적으로 경로를 차례차례 확인하는 데 도움이 됩니다. 두 번째 사용자에게 각 네트워크 홉에서 다음 경로를 받을 위치를 설명하여 사용자 자신이 라우팅 경로를 잘 알고 있는지 확인합니다. ExpressRoute는 항상 Microsoft 서버 IP 주소에 더욱 한정된 경로를 제공하므로 인터넷 기본 경로에 비해 경로 비용이 절감됩니다.

클라이언트 연결 구성 디자인

ExpressRoute에서 PAC 파일 사용

사용 중인 경우 프록시 서버를 인터넷 트래픽을 바운드 다음 모든 PAC 조정 해야 하거나 네트워크에 있는 클라이언트 컴퓨터 수 있도록 클라이언트 구성 파일을 전송 하 하지 않고 Office 365에 원하는 express 경로 트래픽을 보내려면 올바르게 구성 프록시 서버 및 일부 Office 365 트래픽이 포함 하 여 나머지 트래픽을 관련 프록시로 전송 됩니다. PAC 파일 예를 들어 관리 Office 365 끝점에 는 가이드를 읽습니다.

참고: 끝점은 매주 변경되는 등 자주 변경됩니다. 최신 상태를 유지하는 데 필요한 변경 수를 줄이기 위해 조직이 채택한 서비스와 기능을 기반으로만 변경해야 합니다. 적용 날짜에 도달할 때까지 변경 사항이 공지되고 과거 모든 변경 사항의 레코드가 보관되며 공지된 IP 주소를 광고할 수 없거나 광고에서 제거되는 RSS 피드의 적용 날짜에 주의하세요.

배포 및 테스트 프로시저를 작성합니다.

구현 계획에는 테스트와 롤백 계획이 모두 포함되어야 합니다. 구현이 예상대로 작동하지 않으면 문제를 발견하기 전에 최소한의 사용자에게 영향을 미치도록 계획을 디자인해야 합니다. 다음은 계획에서 고려해야 하는 대략적인 원칙입니다.

  1. 혼란을 최소화하도록 네트워크 세그먼트와 사용자 서비스 온보딩을 미리 구성합니다.

  2. 별도로 인터넷에 연결된 호스트에서 추적 경로와 TCP 연결 경로를 테스트하도록 계획합니다.

  3. 가급적, 인바운드 및 아웃 바운드 서비스 테스트 테스트 Office 365 테 넌 트를 사용 하 여 격리 된 테스트 네트워크에서 수행 되어야 합니다.

    • 또는 고객이 아직 Office 365를 사용하지 않거나 파일럿인 경우 프로덕션 네트워크에서 테스트를 수행할 수 있습니다.

    • 또는 테스트와 모니터링만을 위해 별도로 설정된 프로덕션 중단 중에 테스트를 수행할 수 있습니다.

    • 또는 각 계층 3 라우터 노드에서 각 서비스의 경로를 확인하여 테스트를 수행할 수 있습니다. 실제 테스트가 부족하면 위험이 발생할 수 있으므로 다른 테스트를 수행할 수 없는 경우에만 이 대체 방법을 사용해야 합니다.

더 큰 사용자 그룹에 배포하기 전에 테스트할 수 있도록 여러 단계의 소규모 그룹에 배포 프로시저를 제공해야 합니다. 다음은 ExpressRoute의 배포를 준비하는 여러 방법입니다.

  1. Microsoft 피어링이 있는 ExpressRoute를 설정하고 준비된 테스트 용으로만 단일 호스트에 경로 광고를 전달하게 합니다.

  2. 처음에는 ExpressRoute 네트워크의 경로를 단일 네트워크 세그먼트에 광고하고 네트워크 세그먼트 또는 지역으로 경로 광고를 확장합니다.

  3. Office 365를 처음으로 배포하는 경우 ExpressRoute 네트워크 배포를 적은 수의 사용자를 위한 파일럿으로 사용합니다.

  4. 프록시 서버를 사용하는 경우 사용자를 더 많이 추가하기 전에 테스트 및 피드백과 함께 적은 수의 사용자를 ExpressRoute로 향하도록 테스트 PAC 파일을 구성할 수 있습니다.

구현 계획에는 수행해야 하는 각 배치 프로시저나 네트워킹 구성을 배포하는 데 사용해야 하는 명령이 나열되어야 합니다. 네트워크 중단 시간이 되면 미리 작성되어 동료가 검토한 서면으로 작성된 배포 계획으로 모든 변경 내용이 제공되어야 합니다. ExpressRoute의 기술 구성에 관한 지침을 참조하세요.

  • 계속 전자 메일을 보낼 온-프레미스 서버의 IP 주소를 변경한 경우 SPF TXT 레코드 업데이트.

  • 새로운 NAT 구성을 수용하기 위해 IP 주소를 변경한 경우 온-프레미스 서버의 DNS 항목 업데이트.

  • 라우팅 또는 프록시 구성을 유지하려면 Office 365 끝점 알림을 위한 RSS 피드를 구독했는지 확인합니다.

Express 경로 배포를 완료 한 후 테스트 계획에 나와 있는 절차를 실행 합니다. 각 프로시저에 대 한 결과 기록해 야 합니다. 테스트 계획 결과 따르면 구현 하지 못한 경우에 원래 프로덕션 환경에 롤백에 대 한 절차를 포함 해야 합니다.

테스트 프로시저에는 ExpressRoute를 사용할 Office 365의 각 아웃바운드 및 인바운드 네트워크 서비스와 ExpressRoute를 사용하지 않을 서비스 모두의 테스트가 포함되어야 합니다. 이 프로시저에는 회사 LAN의 온-프레미스에 없는 사용자를 비롯하여 각 고유 네트워크 위치에서 수행되는 테스트가 포함되어야 합니다.

테스트 활동의 예에는 다음이 포함됩니다.

  1. 네트워크 운영자 라우터를 온-프레미스 라우터에서 ping 합니다.

  2. 온-프레미스 라우터에서 500개 이상의 Office 365와 CRM Online IP 주소 광고를 수신하는지 확인합니다.

  3. ExpressRoute와 내부 네트워크 간에 인바운드 및 아웃바운드 NAT가 작동하는지 확인합니다.

  4. 라우터에서 NAT에 대 한 경로 보급 되 고 유효성을 검사 합니다.

  5. ExpressRoute가 광고된 접두사를 수락했는지 확인합니다.

    • 피어 링 광고 확인 하려면 다음 cmdlet을 사용 합니다.

    • Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
  6. 이전 예에서와 같이 범위가 큰 집합의 특정 부분 집합인 경우가 아니면 다른 ExpressRoute 또는 공개 인터넷 네트워크 회로를 통해 공개 NAT IP 범위가 Microsoft에 광고되지 않는지 확인합니다.

  7. ExpressRoute 회로는 쌍으로 연결되므로, 두 BGP 세션이 모두 실행 중인지 확인합니다.

  8. NAT 내부에 단일 호스트를 설정하고 ping, tracert 및 tcpping을 사용하여 새로운 회로를 지나 호스트 outlook.office365.com으로의 연결을 테스트합니다. 또는 MSEE에 미러링된 포트에서 Wireshark 또는 Microsoft Network Monitor 3.4와 같은 도구를 사용하여 outlook.office365.com과 연결된 IP 주소에 연결할 수 있는지 확인합니다.

  9. Exchange Online의 응용 프로그램 수준 기능을 테스트합니다.

    • Outlook에서 Exchange Online에 연결하여 전자 메일을 보내고 받을 수 있는지 테스트합니다.

    • Outlook에서 온라인 모드를 사용할 수 있는지 테스트합니다.

    • 스마트폰 연결 및 보내기/받기 기능을 테스트합니다.

  10. SharePoint Online의 응용 프로그램 수준 기능을 테스트합니다.

    • 비즈니스용 OneDrive 동기화 클라이언트를 테스트합니다.

    • SharePoint Online 웹 액세스를 테스트합니다.

  11. 다음과 같이 비즈니스용 Skype 통화 시나리오의 응용 프로그램 수준 기능을 테스트합니다.

    • 인증된 사용자로 전화 회의에 참여합니다[최종 사용자가 초대 시작].

    • 전화 회의에 사용자를 초대합니다[MCU에서 보낸 초대].

    • 비즈니스용 Skype 웹 응용 프로그램을 사용하여 익명의 사용자로 회의에 참여합니다.

    • 유선 PC 연결, IP 전화 및 모바일 장치에서 전화에 참여합니다.

    • 페더레이션된 사용자 o PSTN 유효성 검사에 전화 하려면 전화: 전화 완료, 통화 품질을 허용할 수, 연결 시간을 허용할 수 있습니다.

    • 페더레이션된 사용자와 테넌트의 구성원 모두에 대해 연락처의 현재 상태를 확인합니다.

가장 일반적일 구현 문제는 비대칭 라우팅입니다. 확인해야 할 일반적인 원인은 다음과 같습니다.

  • 원본 NAT가 없이 개방 또는 플랫(flat) 네트워크 라우팅 토폴로지 사용.

  • 인터넷과 ExpressRoute 연결을 통해 인바운드 서비스로 라우팅하는 데 SNAT를 사용하지 않음.

  • 인바운드 서비스를 광범위 하 게 배포 하기 전에 테스트 네트워크 express 경로에서 테스트 되지 않습니다.

네트워크를 통해 ExpressRoute 연결 배포

한 번에 하나의 네트워크 세그먼트로 배포를 준비하고, 새로운 각 네트워크 세그먼트에 롤백할 계획으로 네트워크의 여러 다른 부분에 점진적으로 연결을 배포합니다. 배포가 Office 365 배포에 맞지 않으면 Office 365 파일럿 사용자에게 먼저 배포한 다음 확장합니다.

먼저 테스트용으로 수행한 다음 프로덕션용으로 수행합니다.

  • 배포 단계를 실행하여 ExpressRoute를 사용하도록 설정합니다.

  • 네트워크 경로가 제대로 표시되는지 테스트합니다.

  • 각 인바운드 및 아웃바운드 서비스에서 테스트를 수행합니다.

  • 문제를 발견하면 롤백합니다.

이제 이론적으로 계획 작성을 완료했으므로 소규모로 테스트할 차례입니다. 이 테스트에서는 온-프레미스 네트워크의 테스트 서브넷에 Microsoft 피어링과의 단일 ExpressRoute 연결을 설정합니다. 테스트 서브넷과 연결하도록 평가판 Office 365 테넌트를 구성하고 테스트 서브넷에서 프로덕션에 사용할 아웃바운드 및 인바운드 서비스를 모두 포함합니다. 테스트 네트워크 세그먼트의 DNS를 설정하고 인바운드 및 아웃바운드 서비스를 모두 설정합니다. 테스트 계획을 실행하고 각 서비스와 경로 전파용 라우팅을 잘 알고 있는지 확인합니다.

위에 설명된 항목을 완료하면 완료된 영역을 확인하고 배포 및 테스트 계획을 실행하기 전에 사용자와 팀이 해당 계획을 검토해야 합니다.

  • 네트워크 변경에 관련된 아웃바운드 및 인바운드 서비스 목록.

  • 인터넷 송신 및 ExpressRoute meet-me 위치를 모두 보여 주는 전역 네트워크 아키텍처 다이어그램.

  • 배포된 각 서비스에 사용된 여러 다른 네트워크 경로를 설명하는 네트워크 라우팅 다이어그램.

  • 필요한 경우 변경과 롤백을 구현할 단계가 포함된 배포 계획.

  • 각 Office 365 및 네트워크 서비스를 테스트하는 테스트 계획.

  • 인바운드 및 아웃바운드 서비스의 프로덕션 경로가 유효한지 이론적으로 검사 완료.

  • 가용성 테스트를 비롯하여 테스트 네트워크 세그먼트 전체에서 완료된 테스트.

전체 배포 계획과 테스트 계획을 실행하는 데 충분하며 문제 해결 시간과 필요한 경우 롤백 시간을 충당할 수 있는 중단 기간을 선택합니다.

경고: 인터넷과 ExpressRoute를 모두 사용하여 라우팅하면 복잡하므로 복잡한 라우팅 문제 해결을 처리하도록 추가 버퍼 시간을 이 기간에 추가하는 것이 좋습니다.

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
Office 365 용 Azure express 경로
Office 365 연결에 대 한 express 경로 관리
Office 365 용 express 경로와 라우팅
네트워크 계획 Office 365 용 express 경로와
express 경로 (preview) Office 365 시나리오에서 사용 하 여 BGP 커뮤니티
미디어 품질 및 비즈니스용 Skype Online에서 네트워크 연결 성능을
Skype에 대 한 비즈니스 온라인 네트워크 최적화
express 경로 비즈니스용 Skype Online에서 QoS
흐름 express 경로 사용 하 여 전화 걸기
초기 계획을 사용 하 여Office 365 성능 조정 및 성능 기록
성능 문제 해결 Office 365 계획
Office 365 Url 및 IP 주소 범위
Office 365 네트워크 및 성능 조정

Office 기술 확장
교육 살펴보기
새로운 기능 우선 가져오기
Office Insider 참여

이 정보가 유용한가요?

의견 주셔서 감사합니다!

피드백을 주셔서 감사합니다. Office 지원 에이전트와 연락하는 것이 도움이 될 것 같습니다.

×