깡민쓰~IT Story

개요

• 기본 AVS 토폴로지
• AVS SDDC에 타사 방화벽 NVA를 삽입하는 과제
• 계층화된 네트워크 토폴로지
  • 환승 구간 또는 환승 구간
  • 정적 경로
  • 교통 흐름 분석
• 기타 고려 사항
  • 보안 권장 사항
  • NVA 고가용성
  • 알려진 제한 사항

이전 블로그 게시물 시리즈(게시글: 1 , 2 , 3 )에서는 Azure에 타사 방화벽 네트워크 가상 어플라이언스(NVA)를 구축하여 허브앤스포크 네트워크 토폴로지에 Azure VMware 솔루션(AVS) 배포를 통합하는 방법을 다루었습니다. 이 설정은 AVS 환경(N/S )에서 송수신 되는 트래픽 에 대한 트래픽 필터링을 지원하지만 , AVS 워크로드(E/W) 간에는 필터링 기능을 제공하지 않습니다. 이를 위해 권장되는 방법은 NSX-T 분산 방화벽 기능을 활용하는 것입니다.

이 블로그 게시물에서는 NSX-T 분산 방화벽 기능에 의존하지 않고 AVS 워크로드 간 트래픽 필터링을 제공하기 위해 AVS SDDC 자체에 타사 방화벽 NVA를 배포하는 방법을 다룹니다.

AVS SDDC에 3 차 방화벽 NVA를 구축하는 이유에 대해서는 여기서 설명하지 않겠습니다 . 다만, 온프레미스 데이터센터에서 사용해 온 것과 동일한 방화벽 기술을 AVS에서도 계속 사용하고자 하는 고객들의 일반적인 요청이라는 점만 말씀드리겠습니다.

이 주제는 이전 블로그 게시물에서도 몇몇 동료가 다루었습니다.

• Amit Aneja (Microsoft) 가 만든 Azure VMware 솔루션의 타사 방화벽 NVA .
• Kenyon Hensler (Microsoft) 가 제시한 AVS의 타사 방화벽 .
• Azure VMware 솔루션: 타사 네트워킹 및 보안 플랫폼 연결 작성자: Gourav Bhardwaj (VMware), Trevor Davis (Microsoft), Jeffrey Moore (VMware).

이러한 솔루션을 배포하는 데 도움이 되는 몇 가지 세부 정보를 제공하려고 노력하겠습니다.

기본 AVS 토폴로지

기본적으로 AVS SDDC는 사전 프로비저닝된 NSX-T Tier-0 및 Tier-1 게이트웨이와 함께 배포됩니다. Tier-0 게이트웨이는 AVS SDDC를 ToR(Top-of-Rack) 및 Azure SDN에 연결하는 데 사용되며, Microsoft에서 완벽하게 관리합니다. 기본 Tier-1 게이트웨이는 네트워크 세그먼트를 배포하는 데 사용할 수 있으며, 고객이 직접 관리합니다. 고객은 필요한 경우 Tier-1 게이트웨이를 추가로 생성할 수도 있습니다.

AVS SDDC에 타사 방화벽 NVA를 삽입하는 과제

AVS SDDC에 타사 NVA를 삽입할 때 고려해야 할 첫 번째 한계는 NSX -T 서비스 삽입 기능을 사용할 수 없다는 것입니다 . 이 한계는 주로 Azure VMware 솔루션의 " 관리형 " 특성 에서 비롯됩니다 .

고려해야 할 두 번째 한계는 AVS SDDC에 구축된 타사 NVA가 단일 VM에 연결할 수 있는 가상 네트워크 인터페이스 수에 의해 제한된다는 것입니다. 가상 머신당 사용 가능한 NIC가 10개뿐이므로 워크로드 세그먼트가 9개 이상인 배포 환경에 NVA를 직접 연결하는 것은 불가능합니다.

가능한 완화책은 트랜짓 세그먼트를 사용하는 것입니다 . 이 트랜짓 세그먼트는 추가 Tier-1 게이트웨이에 연결되며, 추가 Tier-1 게이트웨이를 통해 NVA와 워크로드 세그먼트 간의 트래픽을 라우팅하는 데 사용됩니다. 이 토폴로지에서 새로운 제한은 AVS SDDC에 배포할 수 있는 최대 Tier-1 게이트웨이 수 및/또는 트랜짓 서브넷 주소 계획의 크기를 기반으로 합니다. 이를 통해 필요한 경우 수백 개의 워크로드 세그먼트를 프로비저닝할 수 있습니다.

계층화된 네트워크 토폴로지

AVS SDDC에 타사 방화벽 NVA를 구축하려면 계층형 네트워크 토폴로지를 구축해야 합니다. 이 토폴로지는 3개의 계층으로 구성됩니다.

• Tier-1 게이트웨이의 첫 번째 계층(기본적으로 배포된 것과 같음)과 NVA 업링크에 연결된 루트 세그먼트입니다 .
• NVA 다운링크 및 ​​Tier-1 게이트웨이의 두 번째 계층에 연결된 하나 이상의 Transit-segment
• 가상 머신이 배포될 워크로드 세그먼트입니다.

환승 구간 또는 환승 구간

배치할 Transit-segment 수와 관련하여 두 가지 가능한 전략이 있습니다 .

1. 여러 개의 Transit-segment를 사용하면 최대 8개의 Tier-1 게이트웨이를 추가로 구축할 수 있습니다. 각 Tier-1 게이트웨이는 최대 1000개의 워크로드 세그먼트에 연결할 수 있습니다.

• 이러한 설정은 확장성을 제공 하지만 단일 Tier-1 게이트웨이에 연결된 세그먼트는 NVA를 통해 서로 통신하지 않습니다 .
• 이러한 설정은 유지 관리가 더 복잡할 수 있으며 NVA 수준에서 E/W 트래픽 필터링이 필요한 경우 확장성에 제한이 있습니다.

1. 단일 Transit-segment를 사용하면 더 많은 Tier-1 게이트웨이(100개)를 배포하고 워크로드 세그먼트당 1개의 Tier-1 게이트웨이를 전용으로 지정할 수 있습니다 .

• "작업 부하 세그먼트당 1개의 Tier-1 게이트웨이" 설정은 E/W 트래픽 필터링과 관련하여 위에서 언급한 문제를 완화합니다.
• 이러한 설정은 보안 권장 사항 섹션 에서 언급한 것과 같은 보안 문제를 고려할 수도 있습니다 .
• 확장성은 전송 서브넷 크기 에 따라 제한됩니다 . IP 주소가 부족해지지 않도록 적절한 계획이 필요합니다.

참고 : 이 블로그 게시물에서는 두 가지 전략을 설명하려고 합니다.

정적 경로

여러 세그먼트 간의 트래픽을 라우팅하려면 Tier-1 게이트웨이에 정적 경로를 구성해야 합니다. 다음 표는 Tier-1 게이트웨이에 구성해야 하는 정적 경로에 대한 개요를 제공합니다.

다음은 내 연구실 환경에 적용된 예입니다.

교통 흐름 분석

세그먼트 내 트래픽

이미 짐작하셨겠지만, 동일한 워크로드 세그먼트에 배포된 가상 머신의 트래픽 흐름은 NVA 삽입의 영향을 받지 않습니다. 트래픽은 L2 레벨에서 가상 머신 간에 직접 라우팅됩니다.

참고 : NSX-T 분산 방화벽 기능을 활용하면 동일 세그먼트에 있는 가상 머신 간 트래픽을 필터링할 수 있습니다 .

동서, 구간 간 교통량, 동일 Tier-1

동일한 Tier-1 게이트웨이에 연결된 서로 다른 워크로드 세그먼트에 배포된 가상 머신 간의 트래픽 흐름은 NVA 삽입의 영향을 받지 않으며 트래픽은 Tier-1 게이트웨이를 통해서만 전달됩니다.

이러한 종류의 네트워크 트래픽을 필터링하려면 NSX-T 분산 방화벽 이나 게이트웨이 방화벽 기능을 사용할 수 있습니다 .

동서, 구간 간 교통, 다양한 Tier-1

서로 다른 Tier-1 게이트웨이에 연결된 여러 워크로드 세그먼트에 배포된 가상 머신 간의 트래픽 흐름은 NVA 삽입의 영향을 받습니다. 트래픽은 NVA와 Tier-1 게이트웨이를 통해 라우팅됩니다.

이는 NVA 삽입을 통해 달성하고자 하는 교통 흐름의 가장 대표적인 구성입니다.

이 구성을 일반화하려면 워크로드 세그먼트별로 Tier-1 게이트웨이를 배포해야 합니다 .

남북 교통

남북 트래픽도 NVA 삽입의 영향을 받습니다. 트래픽은 NVA를 통해 라우팅되어 NVA 북쪽에 있는 모든 대상에 도달합니다. 기본 Tier-0/Tier-1 게이트웨이의 남쪽에 직접 배포된 가상 머신 또는 다음과 같이 기본 Tier-0/Tier-1 게이트웨이를 통해 도달 가능한 다른 대상에 도달합니다.

• Azure 기반 리소스
• ExpressRoute 또는 VPN을 통한 온프레미스 리소스
• 인터넷

기타 고려 사항

보안 권장 사항

NVA 뒤에 여러 라우팅 장치(Tier-1 게이트웨이)가 배치되어 있는 경우, 트래픽이 NVA를 우회하지 않도록 하는 것이 중요합니다. 분산 방화벽 수준에서 ICMP 리디렉션을 차단하고 NVA를 다음과 같이 구성하는 것이 좋습니다.

• ICMP 리디렉션 무시
• ICMP 리디렉션을 보내지 않음

새로운 정적 경로를 도입하면 트래픽 라우팅이 NVA를 우회할 수도 있습니다. Tier-1 게이트웨이에서 정적 경로를 올바르게 구성하는 것이 중요합니다.

NVA 고가용성

여기서는 단일 NVA 인스턴스로 필터링되는 트래픽 흐름을 설계하고 구성하는 기능만 설명했습니다. 운영 환경에서는 NVA의 고가용성을 고려하는 것이 중요합니다. 여러 NVA 인스턴스를 배포하고 VRRP(Virtual Router Redundancy Protocol) 그룹화 및 로드 밸런싱을 통해 NVA의 고가용성을 확보할 수 있습니다.

알려진 제한 사항

이 설계 토폴로지의 잘 알려진 한계 중 하나는 HCX와 MON( Mobility Optimized Network )의 동작 예측이 어렵다는 점입니다. 이것이 Microsoft가 타사 NVA 설정을 사용하는 AVS에서 Mobility Optimized Network를 지원하지 않는 이유입니다 .

개요

• Azure VMware 솔루션 모니터링에 대한 기타 리소스
• Azure Data Explorer를 사용하여 AVS에서 Grafana로
  • Azure Event Hub에 Azure VMware Solution 메트릭 구성
  • Azure Data Explorer 데이터베이스 및 테이블 준비
  • Azure Event Hub를 사용하도록 Azure Data Explorer 구성
  • Azure Data Explorer 메트릭을 시각화하도록 Grafana 구성

프로덕션 워크로드에 Azure VMware 구독을 배포할 때는 환경의 상태를 모니터링해야 합니다. Azure Well-Architected Framework 에서 이러한 활동은 운영 우수성(Operational Excellence ) 의 중요한 부분입니다 .

Azure VMware Solution은 환경을 모니터링하는 데 사용할 수 있는 메트릭과 로그 세트를 제공합니다. 이 문서에서는 Azure Data Explorer와 Grafana를 사용하여 이러한 메트릭과 로그를 수집하고 시각화하는 방법을 살펴보겠습니다.

Azure VMware 솔루션 모니터링에 대한 기타 리소스

Azure VMware Solution 모니터링은 광범위한 주제입니다. 이 문서에서는 Azure Data Explorer로 데이터를 전달하고 Grafana를 통해 시각화하는 방법, 그리고 기본적으로 제공되는 메트릭에 대해 중점적으로 설명합니다.

더 자세히 알고 싶으시다면 다음 기사를 읽어보시기 바랍니다.

• 프라이빗 클라우드 모니터링
• Azure VMware 솔루션 메트릭
• Azure용 클라우드 도입 프레임워크: Azure VMware 솔루션 관리
• Azure용 클라우드 도입 프레임워크: Azure VMware Solution 엔터프라이즈 규모 시나리오에 대한 관리 및 모니터링
• Azure VMware 솔루션에 대한 VMware syslog 구성
• Azure VMware 솔루션 고급 모니터링(Telegraf 포함)

Azure Data Explorer를 사용하여 AVS에서 Grafana로

Azure VMware 솔루션은 사용자 환경을 모니터링하는 데 사용할 수 있는 메트릭과 로그 세트를 제공합니다. 이러한 메트릭과 로그는 Azure Portal과 Azure Monitor를 통해 사용할 수 있으며, 다음과 같은 여러 솔루션으로 전달할 수 있습니다.

• Azure 로그 분석
• Azure 이벤트 허브
• 블롭 스토리지

Azure Event Hub를 사용하면 최신 게시물인 " Azure VMware Solution과 VMware Aria Operations for Logs Cloud 서비스 통합" 에서 언급한 것처럼 더 많은 솔루션이 Azure VMware Solution 메트릭(및 로그)을 구독할 수 있습니다 .

이 문서에서는 Azure Data Explorer를 사용하여 메트릭을 사용하는 방법 과 시각화를 위해 Grafana 대시보드를 연결하는 방법 을 살펴보겠습니다 .

시각화 대시보드를 호스팅하기 위해 인프라 관리를 최소화하기 위해 Azure Managed Grafana 솔루션을 선택했습니다 . 하지만 Grafana를 자체 인프라에 배포하거나 기존 인스턴스를 재사용할 수도 있습니다.

필수 조건 : 이 문서에서는 Azure Event Hub , Azure Data Explorer 및 Grafana 의 배포에 대해서는 다루지 않습니다 . 이러한 서비스에 대한 자세한 내용은 다음 링크에서 확인할 수 있습니다.

• Azure 이벤트 허브
• Azure 데이터 탐색기
• Azure 관리형 Grafana

Azure Event Hub에 Azure VMware Solution 메트릭 구성

첫 번째 단계는 Azure VMware Solution이 메트릭을 Azure Event Hub로 전달하도록 구성하는 것입니다. 이 작업은 Azure Portal의 Azure VMware Solution 리소스 진단 설정 창에서 수행됩니다.

참고: 메트릭 범주 만 선택하면 Azure Event Hub로 전송할 이벤트 수를 제한할 수 있습니다. 이는 솔루션 비용을 제한하려는 경우 유용합니다. 여러 진단 설정을 만들어 다양한 진단 데이터(로그 및/또는 메트릭)를 각기 다른 대상으로 전송할 수 있습니다.

Azure Data Explorer 데이터베이스 및 테이블 준비

두 번째 단계는 메트릭을 저장할 데이터베이스와 테이블을 만들어 Azure 이벤트 허브로 전송된 메트릭을 수신할 Azure Data Explorer를 준비하는 것입니다. 이 작업은 Azure Portal, Azure Data Explorer 리소스의 Data Explorer 창 또는 kusto 쿼리를 사용하여 수행됩니다(데이터베이스 생성은 Azure Portal을 통해서만 가능합니다).

다음 Kusto 명령은 Azure VMware Solution에서 Azure Event Hub로 전송된 메트릭을 저장하기 위한 테이블과 매핑을 만듭니다.

// Create table command
.create table ['avs-metrics']  (['count']:int, ['total']:long, ['minimum']:long, ['maximum']:long, ['average']:long, ['resourceId']:string, ['time']:datetime, ['metricName']:string, ['timeGrain']:string)

// Ingestion Batching Policy Alter Command
.alter table ['avs-metrics'] policy ingestionbatching @'{"MaximumBatchingTimeSpan":"00:00:30"}'

// Create mapping command
.create table ['avs-metrics'] ingestion json mapping 'avs-metrics_mapping' '[{"column":"count", "Properties":{"Path":"$[\'count\']"}},{"column":"total", "Properties":{"Path":"$[\'total\']"}},{"column":"minimum", "Properties":{"Path":"$[\'minimum\']"}},{"column":"maximum", "Properties":{"Path":"$[\'maximum\']"}},{"column":"average", "Properties":{"Path":"$[\'average\']"}},{"column":"resourceId", "Properties":{"Path":"$[\'resourceId\']"}},{"column":"time", "Properties":{"Path":"$[\'time\']"}},{"column":"metricName", "Properties":{"Path":"$[\'metricName\']"}},{"column":"timeGrain", "Properties":{"Path":"$[\'timeGrain\']"}}]'

Azure Event Hub를 사용하도록 Azure Data Explorer 구성

다음 단계는 Azure 이벤트 허브로 전송된 메트릭을 사용하도록 Azure Data Explorer를 구성하는 것입니다. 이 작업은 Azure Portal의 Azure Data Explorer 리소스의 데이터 연결 창에서 수행됩니다.

기존 데이터베이스와 대상 테이블이 필요합니다.

1. 새 데이터 연결 만들기
2. 데이터 소스로 이벤트 허브를 선택하세요
3. 데이터 연결에 대한 이름을 제공하세요
4. Azure 이벤트 허브 인스턴스(구독, 네임스페이스 및 이벤트 허브)를 선택하세요.
5. 사용할 소비자 그룹을 선택하세요
6. Azure Data Explorer에서 대상 테이블을 선택하세요
7. 데이터 형식을 선택하세요: JSON
8. 사용할 매핑의 이름을 입력하세요(이전 단계에서 생성):avs-metrics_mapping
9. 만들기 를 클릭하세요

최소 5분 후 대상 테이블에 데이터가 표시됩니다. 다음 Kusto 쿼리를 사용하여 데이터를 쿼리하면 마지막 항목을 확인할 수 있습니다.

["avs-metrics"]
| order by ['time'] desc
| limit 10

Azure VMware Solution에서 Azure Event Hub로 보낸 메트릭의 마지막 값을 가져와야 합니다.

Azure Data Explorer 메트릭을 시각화하도록 Grafana 구성

마지막 단계는 Azure Data Explorer에 저장된 메트릭을 시각화하도록 Grafana를 구성하는 것입니다.

Azure Data Explorer 플러그인

Grafana는 Azure Data Explorer의 데이터를 사용하기 위해 Azure Data Explorer 플러그인을 사용합니다 . 이 플러그인은 Azure Managed Grafana에 기본적으로 설치됩니다. 다른 종류의 Grafana 인스턴스를 사용하는 경우 수동으로 설치해야 합니다.

Grafana에 대한 앱 등록을 만듭니다.

설치가 완료되면 Grafana에서 새 데이터 소스를 만들어 Azure Data Explorer 데이터베이스에 연결해야 합니다.

먼저, 다음과 같이 새로운 AAD 애플리케이션을 만듭니다.

az ad sp create-for-rbac -n "Grafana2ADX"
# Keep the appId, password and tenantId for later

다음 Kusto 명령을 사용하여 Azure Data Explorer 데이터베이스에 AAD 애플리케이션 뷰어 액세스 권한을 추가합니다.

.add database your_db_name viewers ('aadapp=your_app_client_id;your_app_tenant_id')

Grafana에서 새 데이터 소스 만들기

다음 정보를 제공하여 Grafana에서 연결을 구성합니다.

• ADX 클러스터 URL
• 인증: 앱 등록
• AAD 애플리케이션 ID
• AAD 테넌트 ID
• AAD 신청 비밀

원하는 경우 기본 데이터베이스를 선택할 수도 있습니다.

데이터 소스를 저장한 후 새 대시보드를 만들고 새 패널을 추가하여 메트릭을 시각화할 수 있습니다.

대시보드

이제 Azure VMware Solution 메트릭에 대한 시각화를 탐색하고 만들 수 있습니다.

예를 들어 vSAN 데이터 저장소의 사용률을 알아보려면 다음 쿼리를 사용할 수 있습니다.

# Get disk usage percentage and rename series to "disk"
['avs-metrics']
| where $__timeFilter(['time']) and metricName == "DiskUsedPercentage"
| project ['time'], Disk=average
| order by ['time'] asc

이 솔루션을 통해 다음과 같은 측정 항목을 사용할 수 있습니다.

grafana의 알림 기능을 사용하여 이러한 메트릭을 기반으로 알림을 만들고 특정 임계값에 도달하면 관리자에게 알릴 수도 있습니다(Azure Monitor에서도 마찬가지로 할 수 있습니다).

대시보드 예시

다음은 이러한 측정항목을 사용하여 만들 수 있는 대시보드의 몇 가지 예입니다.

메트릭을 결합, 필터링 및 집계하여 고유한 대시보드를 만들고 Azure VMware Solution 환경에 대한 글로벌 뷰를 제공할 수 있습니다.

개요

• 우리는 무엇에 대해 이야기하지 않을 것인가
• 실험실 설정
• 기본 네트워크 연결
• VM을 클라우드 환경으로 마이그레이션
  • 세그먼트 연결성
• 모빌리티 최적화 네트워크 활성화
  • 세그먼트 연결성
• 라우터 위치 변경
  • 백스테이지에서 무슨 일이 일어났나요?
  • 비대칭 라우팅
• 정책 경로를 사용자 지정해 보겠습니다.
  • 모든 정책 경로 제거
  • 매우 구체적인 정책 경로를 추가합니다.
• 인터넷 연결을 위한 정책 경로 사용
  • 기본 정책 경로를 사용한 인터넷 이탈
  • 특정 정책 경로를 사용한 인터넷 이탈
• 균형의 예술

아니요, Savage Garden 의 "To the Moon & Back" 노래를 논의하기 위해 음악 블로그 장르로 전환하려는 것이 아닙니다 (이런 내용을 기대하셨다면 죄송합니다). 제목에 오타는 없습니다. VMware HCX 네트워크 확장 기능과 MON 기능( Mobility Optimized Network 라고도 함)을 살펴보겠습니다 .

HCX에 대해 잘 모르시는 분들을 위해 설명드리자면, HCX는 온프레미스에서 클라우드로, 또는 클라우드에서 클라우드로 워크로드를 마이그레이션할 수 있는 VMware 솔루션입니다. 또한 마이그레이션 소스에서 목적지까지 네트워크를 확장할 수 있습니다. HCX는 마이그레이션 프로젝트를 가속화하기 위해 다양한 시나리오에서 사용할 수 있는 매우 강력한 솔루션입니다.

이 글에서는 HCX의 네트워크 확장 부분에 초점을 맞추고, 특히 잘 이해되지 않는 기능인 모빌리티 최적화 네트워크에 대해 알아보겠습니다 .

우리는 무엇에 대해 이야기하지 않을 것인가

이 글에서는 HCX 네트워크 확장 생성에 대해 자세히 다루지 않겠습니다. 이 주제는 공식 문서를 포함하여 인터넷에 이미 잘 정리되어 있으므로 HCX에 익숙하다면 자세한 설명은 필요하지 않을 것입니다.

실험실 설정

이 게시물을 문서화하기 위해 다음 토폴로지를 기반으로 랩을 만들었습니다.

이 연구실에는 다음이 있습니다.

• vCenter와 하이퍼바이저를 갖춘 온프레미스 환경: 호스팅:
  • 네트워크( 10.100.115.0/24)
  • 라우팅 장치( gw@ 10.100.115.1)와 그 북쪽 연결(인터넷+클라우드 연결)
  • 클라우드로 마이그레이션할 가상 머신 세트:migration-vm-X
• 클라우드 환경(Azure 기반):
  • ExpressRoute 회로의 착륙
  • 내 워크스테이션을 위한 지점 간 VPN 게이트웨이
  • vNET:10.100.2.0/24
  • 이 vNET의 Azure 네이티브 VM: azure-vm@10.100.2.36
  • Azure VMware 솔루션 SDDC에는 다음이 포함됩니다.
    • 익스프레스 루트(ER) + 글로벌 리치 연결
    • HCX Enterprise 배포 및 구성
    • 테스트 VM과 직접 AVS 연결이 가능한 기본 NSX-T 세그먼트 10.100.110.0/24:Ubuntu01

VM 마이그레이션을 준비하기 위해 HCX 네트워크 확장을 사용하여 온프레미스 네트워크를 클라우드로 확장했습니다. 10.100.115.0/24이제 확장된 네트워크( )를 클라우드에서 사용할 수 있습니다.

기본 네트워크 연결

VM 마이그레이션을 시작하기 전에 온프레미스의 기본 네트워크 연결을 살펴보겠습니다.

migration-vm-X온프레미스 gw장치와 기본 경로를 사용하여 인터넷에 접속합니다 (↔ 분홍색) . 이 gw장치는 ExpressRoute 회로 (↔ 주황색) 를 통해 클라우드 환경에 접속하는 데에도 사용됩니다. Azure VMware Solution 기반 VM에 접속하려면 Global Reach 및 AVS ER 회로 (↔ 빨간색) 와 함께 ER 회로가 사용됩니다 .

VM을 클라우드 환경으로 마이그레이션

HCX를 사용하여 클라우드 환경으로 마이그레이션해 보겠습니다 migration-vm-2. 마이그레이션이 성공적으로 완료되어 VM이 클라우드 환경에서 실행 중입니다. VM은 gw기본 게이트웨이가 아직 .으로 구성되어 있으므로 온프레미스 장치를 사용하여 인터넷과 클라우드 환경에 접속하고 있습니다 10.100.115.1.

인터넷 (↔ 분홍색) 또는 클라우드 기반 리소스 (↔ 주황색) 에 접속하는 네트워크 경로는 최적이 아니며, AVS의 다른 NSX-T 세그먼트 (↔ 빨간색) 에 있는 VM에 접속하는 경로를 살펴보면 이는 더욱 분명하게 드러납니다 . 이러한 상황을 (w) 네트워크 트롬보닝 이라고 합니다 .

세그먼트 연결성

NSX-T에서 네트워크 확장이 생성되면 동일한 서브넷 설정을 가진 세그먼트가 생성되고 L2E_접두사가 붙은 이름이 지정됩니다.

스크린샷에서 볼 수 있듯이 이 세그먼트는 비활성화된 gateway connectivity 상태로 구성되어 있습니다 . 즉, 이 세그먼트는 NSX-T 패브릭의 다른 구성 요소에 광고되지 않으며, L3 연결에 T1 게이트웨이를 사용할 수 없습니다.

모빌리티 최적화 네트워크 활성화

네트워크 경로를 개선하기 위해 HCX의 모빌리티 최적화 네트워크 기능을 활성화할 예정입니다. 이 기능은 HCX UI의 네트워크 확장 섹션에서 사용할 수 있으며, 네트워크별로 활성화할 수 있습니다.

이 기능을 활성화하고 기본 설정을 변경하지 않으면 세그먼트의 연결이 활성화되고 이제 T1 게이트웨이를 L3 연결에 사용할 수 있습니다 .

아시다시피, 마이그레이션된 VM의 네트워크 경로는 변경되지 않습니다. 이는 router-location의 기본 설정 때문 입니다 .hcx-enterprise

router -location hcx-enterprise 설정 값은 온-프레미스 gw장치가 마이그레이션된 VM의 기본 게이트웨이로 계속 사용된다는 것을 의미합니다.

세그먼트 연결성

Mobility Optimized Network 기능을 활성화한 후 세그먼트 연결성을 살펴보겠습니다.

gateway connectivity이제 L2E 세그먼트에서 이 기능이 활성화 되었으며, T1 게이트웨이를 L3 연결에 사용할 수 있습니다( 라우터 위치 설정에 따라 다름).

/32Express Route 회로의 BGP 광고에서 NSX-T에서 광고된 새로운 경로도 볼 수 있습니다 .

• 10.100.115.1/32: 확장된 네트워크의 게이트웨이.

라우터 위치 변경

마이그레이션된 VM의 네트워크 경로를 개선하기 위해 마이그레이션된 VM에 클라우드 측 게이트웨이를 사용하도록 라우터 위치 설정을 변경하는 것이 좋습니다 .

네트워크 경로에 다음 변경 사항이 적용됩니다.

• VM/OS에 구성된 기본 게이트웨이는 변경되지 않습니다. 10.100.115.1하지만...
• 별도의 NSX-T 세그먼트에 있는 VM에 도달하려면 트래픽이 온프레미스 gw장치 (↔ 빨간색) 가 아닌 세그먼트의 T1 게이트웨이를 통해 라우팅되어야 합니다 .
• 인터넷에 도달하려면 트래픽이 온프레미스 gw장치 (↔ 분홍색) 가 아닌 세그먼트의 T1 게이트웨이를 통해 라우팅됩니다 .
• 네이티브 클라우드 환경에서 VM에 도달하려면 트래픽이 온프레미스 gw장치 (⇠ 주황색) 를 통해 라우팅됩니다 .
  • 하지만 복귀 경로는 해당 구간의 T1 게이트웨이 (⇠ 주황색) 를 통해 이루어집니다 .

보시다시피, AVS 호스팅 또는 인터넷 리소스에 대한 네트워크 경로가 최적화된 것처럼 보이더라도 네이티브 클라우드 리소스에 대한 경로는 그렇지 않고 비대칭적입니다. 이는 모빌리티 최적화 네트워크 기능의 설정 범주인 ' 정책 경로' 때문입니다 . 다음 섹션에서 이 설정에 대해 살펴보겠습니다.

백스테이지에서 무슨 일이 일어났나요?

라우터 위치 설정을 변경했을 때 다음 변경 사항이 적용되었습니다.

T1 게이트웨이의 라우팅 테이블을 살펴보면 마이그레이션된 VM에 대한 새 항목이 추가되었습니다.

Express Route 회로에서는 NSX-T에서 BGP를 통해 광고되는 2개의 새로운 경로도 표시됩니다.

• 10.100.115.1/32: 네트워크 게이트웨이가 이제 AVS에서 광고됩니다( 이 경로는 MON 활성화 이후 이미 광고되었습니다 )
• 10.100.115.12/32: MON이 활성화되고 라우터 위치가 HCX 클라우드 인스턴스로 설정된 마이그레이션된 VM입니다 .

비대칭 라우팅

클라우드 기반 리소스 (사설 네트워크) 로 향하는 네트워크 흐름 에서 볼 수 있듯이 , 비대칭 라우팅이 존재합니다. 트래픽은 온프레미스 장치를 통해 클라우드 기반 리소스에 도달하지만, 그 반대 경로는 클라우드 측 세그먼트의 T1 게이트웨이 (⇠ 주황색)gw 를 통과합니다 .

NSX-T가 마이그레이션된 VM의 경로를 게시함에 따라 /32클라우드 리소스는 이제 세그먼트의 T1 게이트웨이를 통해 마이그레이션된 VM에 직접 도달할 수 있습니다. 이것이 클라우드 리소스에서 AVS로의 경로가 T1 게이트웨이를 통과하는 이유입니다.

migration-vm-X온프레미스 gw장치를 사용하여 클라우드 기반 리소스에 접근하는 이유는 MON이 활성화된 경우 기본 정책 경로가 설정되기 때문입니다.

기본적으로 정책 경로는 RFC1918 주소 공간과 일치하는 트래픽에 대한 기본 게이트웨이로 온-프레미스 장치를 사용하도록 구성 되었습니다 .gw

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

이를 통해 마이그레이션된 VM은 온프레미스 장치를 기본 게이트웨이로 사용하여 온프레미스 네트워크의 다른 리소스에 도달할 수 있지만 gw, 사용자 지정하지 않은 경우 클라우드 기반 리소스에 대한 트래픽에 대한 비대칭 라우팅도 도입됩니다.

정책 경로를 사용자 지정해 보겠습니다.

모든 정책 경로 제거

정책 경로의 영향을 이해하는 좋은 예는 미리 구성된 정책 경로를 모두 제거하여 테스트를 수행하는 것입니다.

인터넷 (↔ 분홍색) 또는 AVS 기반 리소스 (↔ 빨간색) 의 경우 네트워크 경로는 여전히 이전 섹션의 경로입니다.

네이티브 클라우드 리소스 (↔ 주황색) 의 경우 , 마이그레이션된 VM이 세그먼트의 T1 게이트웨이를 사용하여 L2 브로드캐스트 도메인 외부의 모든 리소스에 도달하므로 네트워크 경로가 이제 대칭적입니다.

이러한 설정은 마이그레이션된 VM이 온프레미스 리소스에 도달하기에는 최적이 아닐 수 있지만 , 온프레미스 리소스에 대한 보다 구체적인 일치 기준을 포함하는 새 정책 경로를 추가하여 사용자 지정할 수 있습니다.

매우 구체적인 정책 경로를 추가합니다.

MON이 활성화된 네트워크 확장에서 정책 경로가 작동하는 방식을 보여주는 또 다른 좋은 예는 최적의 경로로 특정 리소스에 도달하기 위해 매우 구체적인 정책 경로를 추가하는 것입니다.

예제에서는 기본 정책 경로를 다시 만들고 Azure 호스팅 리소스와 일치하는 규칙이 /32있는 경로를 추가합니다 .denyazure-vm

• 10.0.0.0/8: HCX로 소스로 보내기: 허용
• 172.16.0.0/12: HCX로 소스로 보내기: 허용
• 192.168.0.0/16: HCX로 소스로 보내기: 허용
• 10.100.2.36/32: HCX로 소스로 보내기: 거부

이 새로운 설정에서는 Azure 호스팅 리소스에 대한 네트워크 경로가 azure-vm이제 양방향으로 최적화되었습니다.

• 개인 RFC1918 범위(예: 10.0.0.0/8)의 온프레미스 리소스에 도달하려면 온프레미스 gw장치가 사용됩니다 (↔ 보라색) .
• 클라우드 기반 특정 리소스( 10.100.2.36/32)에 접근하기 위해서는 클라우드 측 게이트웨이 (↔주황색) 를 이용합니다 .

참고: 다이어그램을 단순화하기 위해 인터넷 연결을 제거했지만 인터넷에 도달하는 네트워크 경로에는 변화가 없습니다.

인터넷 연결을 위한 정책 경로 사용

이전 섹션에서는 정책 경로를 사용하여 특정 리소스에 도달하는 네트워크 경로를 최적화할 수 있다는 것을 살펴보았습니다. 또한, 정책 경로를 사용하여 인터넷(또는 0.0.0.0/0)에 도달하는 네트워크 경로를 최적화하거나 안내할 수도 있습니다.

기본 정책 경로를 사용한 인터넷 이탈

기본 정책 경로( 라우터 위치가 클라우드 측 게이트웨이로 설정됨) 를 사용하여 인터넷에 도달하는 네트워크 경로를 살펴보겠습니다 .

인터넷( 0.0.0.0/0)은 온프레미스 게이트웨이(기본 정책 경로 사용)를 사용하도록 구성된 RFC1918 주소 공간의 일부가 아니므로 마이그레이션된 VM은 T1 게이트웨이와 세그먼트의 Azure 송신 연결을 사용하여 인터넷 (↔ 분홍색) 에 도달합니다 .

참고 : 인터넷에 접속하는 Azure 이그레스 경로는 Azure VMware Solution SDDC 구성에 따라 달라질 수 있습니다. 이 예에서는 Azure 이그레스가 기본 Microsoft Managed SNAT 로 구성되어 있습니다 . AVS의 인터넷 연결에 대한 자세한 내용은 다음 게시물에서 확인할 수 있습니다. Azure VMware Solution – NSX-T Edge에서 공용 IP 사용 .

특정 정책 경로를 사용한 인터넷 이탈

온프레미스 gw장치를 통해 인터넷에 접속하기 위한 특정 정책 경로를 추가해 보겠습니다( 라우터 위치는 여전히 클라우드 측 게이트웨이로 설정됨):

• 0.0.0.0/0: HCX로 소스로 보내기: 허용

이 새로운 정책 경로를 통해 마이그레이션된 VM은 이제 온프레미스 gw장치를 사용하여 인터넷에 접속합니다 (↔ 분홍색) . 그런 다음 온프레미스 gw장치에 방화벽 규칙을 적용하여 마이그레이션된 VM의 인터넷 액세스를 제어할 수 있습니다.

추가 정책 경로 없이 모든 네트워크 흐름도 이 온프레미스 gw장치를 사용하게 됩니다. 다른 리소스에 도달하는 네트워크 경로를 최적화하기 위해 추가 정책 경로를 추가하지 않고 MON을 활성화하는 것은 역효과가 있을 수 있습니다.

균형의 예술

이전 예시는 설정 변경에 따른 MON 지원 리소스 및 네트워크 흐름의 동작을 설명하기 위해 제공되었습니다. 문제를 방지하고 네트워크 흐름 경로에서 예상 보안 수준을 유지하려면 배포 환경에 따라 전역 및/또는 특정 흐름 정책을 적용하는 방법을 신중하게 고려해야 할 것입니다.

예를 들어, 흐름이 NSX-T Tier1을 사용하면 온프레미스 방화벽으로 더 이상 보호되지 않으며 NSX-T 수준에서 일부 방화벽 규칙을 설정해야 할 수 있습니다.

또한 MON에는 몇 가지 제한 사항이 있으며 모든 사용 사례에 적합하지 않을 수 있습니다. MON 활성화를 진행하기 전에 기존 문서를 꼼꼼히 검토하는 것이 필수적입니다. AVS 관련 자료는 다음 문서 페이지를 참고하는 것이 좋습니다. VMware HCX 모빌리티 최적화 네트워킹(MON) 가이드 .

마지막으로, 네트워크 확장 컷오버 작업을 마이그레이션 프로젝트의 중요한 단계로 고려하고 신중하게 계획할 것을 강력히 권장합니다 . 모빌리티 최적화 네트워킹(Mobility Optimized Networking) 기능은 네트워크 흐름 경로를 최적화하고 네트워크 트롬보닝(Tromboning) 시나리오를 방지하거나 제한하는 데 큰 도움이 되지만, 모든 네트워크 문제를 해결하거나 네트워크 확장 컷오버 작업을 건너뛸 수 있는 마법 같은 기능이 아니라 마이그레이션 목표 달성을 위한 도구로 간주해야 합니다. 장기적인 네트워크 확장의 경우, 마이그레이션된 VM의 기본 게이트웨이를 클라우드 측 게이트웨이로 변경하는 것이 네트워크 흐름을 최적화하는 좋은 방법이 될 수 있습니다.