깡민쓰~IT Story

개요

• Azure CLI
• ARM 배포
• 결론
  • 크레딧

Azure Arc 지원 VMware vSphere 에 대한 이 시리즈의 처음 두 게시물에서는 VMware 기반 리소스에서 Azure 거버넌스 및 관리 기능을 확장하고 Azure Portal에서 VMware 가상 머신을 만드는 방법을 보여주었습니다.

만약 당신이 첫 번째 게시물 2개를 놓쳤다면:

• Azure Arc 지원 VMware vSphere – 1부
• Azure Arc 지원 VMware vSphere – 2부

다음 섹션에서는 Azure 도구를 통해 VMware 리소스를 관리하는 데 사용할 수 있는 자동화 솔루션의 예를 살펴보겠습니다.

Azure CLI

Azure Arc 지원 VMware vSphere는connectedvmware Azure CLI를 통해 VMware 리소스를 관리하기 위한 Azure CLI 확장 기능을 제공합니다 . 확장 설명서에는 사용 가능한 명령과 인수에 대한 전체 참조가 나와 있습니다.

이 확장 프로그램을 사용하여 달성할 수 있는 작업의 몇 가지 예는 다음과 같습니다.

Azure Arc에 등록된 vCenter 서버 나열:

az connectedvmware vcenter list --output table --query "[].{resourceGroup:resourceGroup, name:name, location:location, version:version}"
ResourceGroup    Name               Location    Version
---------------  -----------------  ----------  ---------
arc-RG           north-eu-avs-vcsa  westeurope  6.7.0

vCenter 서버에서 모든 인벤토리 항목을 나열합니다.

az connectedvmware vcenter inventory-item list --output table --resource-group "arc-RG" --vcenter "north-eu-avs-vcsa" --query "[].{kind:kind, name:moName}"
Kind                    Name
----------------------  --------------------------------------------------------------
VirtualNetwork          VM-tests-110
Host                    esx19-r18.p01.**********************.northeurope.avs.azure.com
VirtualMachineTemplate  Arc-Template
ResourcePool            Resources
...

Azure Arc에 등록된 가상 머신 나열:

az connectedvmware vm list --output table --query "[].{resourceGroup:resourceGroup, name:name, location:location, instanceUuid:instanceUuid}"
ResourceGroup    Name        Location    InstanceUuid
---------------  ----------  ----------  ------------------------------------
arc-RG           Ubuntu04    westeurope  67bc57b8-6464-4658-8e04-7cc9d6d5cb04
arc-RG           Windows01   westeurope  caccc302-e28b-4c70-b2c0-24a614d470e6
arc-RG           Ubuntu03    westeurope  39f8ef01-efd5-4268-88a0-2831bece69e7
arc-RG           Windows03   westeurope  f111aa56-f755-494d-9871-72154779792b
arc-RG           Windows02   westeurope  1fba47c2-dba5-4ee3-b295-3bdbd043fbb8

가상 머신을 다시 시작합니다

az connectedvmware vm restart --name Windows02 --resource-group arc-RG
 \ Running ..

ARM 배포

Microsoft 문서 에 따르면 :

Azure Resource Manager 는 Azure의 배포 및 관리 서비스입니다. Azure 계정에서 리소스를 생성, 업데이트 및 삭제할 수 있는 관리 계층을 제공합니다. 배포 후에는 액세스 제어, 잠금, 태그와 같은 관리 기능을 사용하여 리소스를 보호하고 구성할 수 있습니다.

ARM은 API, UI 및 Azure 도구에서 Azure 리소스를 관리하는 데 사용되는 핵심 엔진이며, 리소스를 배포하고 유지 관리하는 선언적 Infrastructure-as-Code 언어를 제공합니다. ARM 템플릿이 바로 그것입니다. ARM 템플릿은 JSON 또는 Bicep 구문을 사용할 수 있습니다.

다른 리소스와 마찬가지로 VMware 인프라의 Azure 지원 구성 요소는 ARM 및 ARM 템플릿을 통해 관리할 수 있습니다.

VMware 가상 머신을 배포하기 위한 최소 ARM 템플릿을 살펴보겠습니다. Bicep 파일을 다운로드하세요.

curl https://vuptime.io/images/arc-vmware/vmware-vm-template.bicep > ./vmware-vm-template.bicep
# edit the file to set proper resources ids and customize your deployment parameters

# Start the deployment
az deployment group create --name vm-creation --resource-group arc-RG --template-file ./vmware-vm-template.bicep --parameters VMName=Ubuntu08

# Display some information about the deployed VM
az connectedvmware vm show --output table --resource-group "arc-RG" --name "Ubuntu06" --query "{resourceGroup:resourceGroup, name:name, location:location, instanceUuid:instanceUuid}"
ResourceGroup    Name      Location    InstanceUuid
---------------  --------  ----------  ------------------------------------
arc-RG           Ubuntu08  westeurope  18f07c4f-88f9-4cfd-adc7-0dc13007984c

결론

Azure Arc 지원 VMware vSphere 에 대한 지난 3개 게시물에서는 Azure Arc를 사용하여 Azure Resource Manager의 도움으로 VMware 리소스를 관리하는 이점에 대해 알아보았습니다.

Azure 거버넌스 정책을 Azure 기본 범위를 벗어나는 인프라 구성 요소로 확장하면 글로벌 보안 태세를 유지하고 셀프 서비스 VMware 리소스를 쉽게 제공하며 Azure 도구를 활용하여 VMware 환경을 관리할 수 있습니다.

Azure Arc 지원 VMware vSphere 기능 은 아직 미리보기 단계 이므로 글로벌 출시 전에 많은 변경 사항과 개선 사항이 적용될 예정입니다.

이 시리즈의 처음 두 게시물을 놓치셨다면:

• Azure Arc 지원 VMware vSphere – 1부
• Azure Arc 지원 VMware vSphere – 2부

개요

• Azure UI에서 vCenter 인벤토리 탐색
  • 리소스풀
  • VM 템플릿
  • 네트워크
  • 데이터 저장소
• Azure를 통한 VMware 가상 머신 관리
  • Azure Arc 지원 서버
  • 기존 VM 등록
  • VM 만들기
• VMware 기반 리소스에 대한 Azure 거버넌스
  • 그룹화 및 태그 지정
  • RBAC
  • 잠그다
• 다가오는
  • 크레딧

이전 게시물(1부) 에서는 Azure Arc 지원 VMware vSphere 의 기능에 대해 다루었습니다 . 이는 Azure 거버넌스 및 관리 정책을 VMware 기반 워크로드로 확장하는 솔루션입니다.

또한 VMware 환경과 Azure를 연결하기 위해 리소스 브리지를 구축했습니다 . 이제 Azure를 통해 vCenter 인벤토리를 탐색하고 가상 머신을 관리할 수 있습니다.

Azure UI에서 vCenter 인벤토리 탐색

vCenter와 Resource Bridge가 Azure Arc에 연결되면 해당 콘텐츠와 연결 상태를 살펴볼 수 있습니다.

Azure에서 리소스를 사용하려면 활성화가 필요합니다. Azure에서 활성화를 사용하여 Azure에서 기존 VMware 리소스를 활성화하세요. 모든 Azure 기반 리소스와 마찬가지로, RBAC 전략을 적용하여 Azure 지원 리소스에 대한 액세스를 제공하거나 제한할 수 있습니다.

ResourcePool, Networks, Templates 및 Datastores는 활성화 과정에서 선택하는 Azure ResourceGroup 에 숨겨진 리소스 로 표시됩니다 . 이러한 리소스는 VM 생성 과정에 사용되지만 Azure에서 편집할 수는 없습니다.

리소스풀

VMware ResourcePool은 생성, 편집 또는 제거할 수 없지만 VM 생성 시나리오에 등록할 수 있습니다. 기본적으로 모든 resourcePool은 인벤토리 목록에 표시됩니다(클러스터 및 호스트 resourcePool 표현 포함). Azure에서 ResourcePool을 활성화하려면 해당 ResourcePool을 선택하고 " Azure에서 사용" 을 클릭합니다. Azure ResourceGroup 첨부 파일을 입력하라는 메시지가 표시되고 , 해당 resourcePool과 세부 정보를 살펴볼 수 있는 링크가 표시됩니다.

VM 템플릿

VMware VM 템플릿은 생성, 편집 또는 제거할 수 없지만 VM 생성 시나리오에 등록할 수 있습니다. 기본적으로 모든 VM 템플릿은 인벤토리 목록에 표시됩니다. Azure에서 VM 템플릿을 선택하고 " Azure에서 사용" 을 클릭하여 활성화할 수 있습니다. Azure ResourceGroup 첨부 파일을 입력하라는 메시지가 표시되고 , 템플릿과 함께 세부 정보를 살펴볼 수 있는 링크가 표시됩니다.

참고 : 현재 콘텐츠 라이브러리의 템플릿은 사용할 수 없습니다. Azure Arc 지원 VMware vSphere 에서는 vCenter VM 폴더 인벤토리의 VM 템플릿만 사용할 수 있습니다 .

네트워크

VMware 네트워크는 생성, 편집 또는 제거할 수 없지만 VM 생성 시나리오에 등록할 수 있습니다. 기본적으로 모든 네트워크(NSX-T 세그먼트, PortGroups 및 DvPortGroups)가 인벤토리 목록에 표시됩니다. Azure에서 네트워크를 활성화하려면 해당 네트워크를 선택하고 " Azure에서 활성화" 를 클릭합니다. Azure ResourceGroup 첨부 파일을 입력하라는 메시지가 표시되고 , 템플릿과 함께 세부 정보를 볼 수 있는 링크가 표시됩니다.

데이터 저장소

VMware 데이터 저장소는 생성, 편집 또는 제거할 수 없지만 VM 생성 시나리오에 등록할 수 있습니다. 기본적으로 모든 데이터 저장소는 인벤토리 목록에 표시됩니다. Azure에서 데이터 저장소를 활성화하려면 해당 데이터 저장소를 선택하고 "Azure에서 활성화" 를 클릭합니다. Azure ResourceGroup 첨부 파일을 입력하라는 메시지가 표시되고 , 데이터 저장소와 함께 세부 정보를 살펴볼 수 있는 링크가 표시됩니다.

Azure를 통한 VMware 가상 머신 관리

이 게시물의 이전 부분에서 언급했듯이 ResourcePool, Networks, Templates 및 Datastores는 Azure(UI, API, ARM 등)를 통해 생성, 편집 또는 삭제할 수 없지만 가상 머신 배포 종속성을 제공하기 위해 ReadOnly 액세스로 등록할 수 있습니다.

Azure를 통해 VMware Virtual Machines에 사용할 수 있는 작업 세트는 다음과 같은 점에서 더욱 중요합니다.

• 전원 작동(시작/중지/재시작)
• 가상 머신 재구성:
  • CPU/메모리(전원이 꺼진 VM용)
  • 디스크 - 추가/제거/크기 조정
  • 네트워크 - 네트워크 연결 추가/제거/변경
• Arc 기반 게스트 관리 활성화 및 확장 프로그램 설치
• RBAC 및 태그 정책 적용

VMware Arc 기반 게스트 확장 기능은 현재 Log Analytics 에이전트와 cCustom 스크립트 실행의 두 가지 확장 기능으로 제한됩니다.

Azure Arc 지원 서버

Azure Arc 지원 VMware vSphere 기반 게스트 에이전트가 현재 2개의 확장으로 제한되어 있더라도 일반 Arc 프로세스를 사용하여 Azure를 통해 배포된 서버의 게스트 OS 관리를 통합하고 ( Arc 설명서 에 언급된 대로) 다음과 같은 Azure Arc의 모든 기능을 활용할 수 있습니다 .

• 기존의 비 Azure 및/또는 온-프레미스 리소스를 Azure Resource Manager에 투영하여 전체 환경을 함께 관리합니다.
• Azure에서 실행되는 것처럼 가상 머신, Kubernetes 클러스터 및 데이터베이스를 관리합니다.
• 어디에 있든 익숙한 Azure 서비스와 관리 기능을 사용하세요.
• 기존 ITOps를 계속 사용하는 동시에 환경에서 새로운 클라우드 네이티브 패턴을 지원하기 위해 DevOps 방식을 도입합니다.
• Azure Arc 지원 Kubernetes 클러스터 및 클러스터 확장 위에 추상화 계층으로 사용자 지정 위치를 구성합니다.

개인적인 경험 : 저는 Azure Arc 지원 VMware vSphere 와 Azure Arc 지원 서버를 조합하여 Azure, VMware Virtual Machine 객체 및 해당 게스트 OS를 완벽하게 관리합니다. 이 솔루션은 두 가지 솔루션 중 가장 뛰어난 성능을 제공합니다.

기존 VM 등록

Azure에서 가상 머신을 활성화하려면 해당 가상 머신을 선택하고 " Azure에서 활성화" 를 클릭하세요. Azure ResourceGroup 첨부 파일을 입력하라는 메시지가 표시되고 , 해당 가상 머신과 함께 세부 정보를 살펴볼 수 있는 링크가 표시됩니다.

VM 만들기

VM 개체는 Azure(UI 또는 API)에서도 완전히 생성될 수 있습니다.

1. Arc Virtual Machines 또는 Arc에 등록된 vCenter의 VM 목록에서 ' 만들기' 버튼을 클릭하여 VM 생성 마법사를 시작합니다.

1. VM을 연결할 ResourceGroup을 선택한 다음 VM 배포에 대한 세부 정보를 제공할 수 있습니다.

• 이름
• 사용자 지정 위치 및 개체 유형( VMware )
• 대상 리소스 풀
• 사용할 VM 템플릿
• 템플릿 설정을 재정의하도록 선택한 경우 VM CPU 및 메모리 구성
• 생성 프로세스 중에 게스트 관리를 활성화하도록 선택한 경우 관리자 로그인 및 비밀번호

1. 마법사의 두 번째 단계는 가상 디스크 구성(이름, 크기, 컨트롤러 및 지속성)입니다.

1. 마법사의 세 번째 단계에서는 네트워크 설정 구성(네트워크 연결, IP 설정 등)을 제공합니다.

1. 네 번째 단계에서는 VM 개체에 태그/값을 추가할 수 있습니다(태그는 Azure 측에만 적용되며 VMware 측에는 적용되지 않습니다).

1. 마지막 단계에서는 요청된 변경 사항을 검증하고 배포를 시작할 수 있는 창을 제공합니다.

1. 배포 프로세스가 완료되면 결과를 보고 배포된 리소스를 표시할 수 있습니다.

이제 vCenter와 Azure UI에서 동일한 VM 개체에 대한 보기를 비교할 수 있습니다.

VMware 기반 리소스에 대한 Azure 거버넌스

Azure에서 VMware 리소스를 관리하는 주요 이점 중 하나는 다음과 같은 표준 Azure 거버넌스 전략을 적용할 수 있다는 것입니다.

그룹화 및 태그 지정

Azure에서 활성화된 VMware 리소스는 Azure ResourceGroups 에 연결될 수 있으며 리소스 개체(RBAC, 잠금 등)에 대한 거버넌스 상속으로부터 이점을 얻을 수 있습니다.

검색 작업에서 리소스를 필터링하거나 리소스 비용 및 속성을 관리하기 위해 VMware 리소스에 태그를 지정할 수도 있습니다.

RBAC

Azure에서 활성화된 VMware 리소스에 Azure RBAC 전략을 적용하여 리소스에 대한 읽기 전용, 기여 또는 소유권을 제공할 수 있습니다.

잠그다

Azure Lock과 구독 또는 ResourceGroup의 종속성을 사용하여 삭제 또는 수정을 방지할 수도 있습니다.

다가오는

배포 마지막 화면에서 보셨겠지만, 진행 중인 배포를 나타내는 ARM 템플릿을 가져오거나 다운로드할 수 있습니다. Azure Arc 지원 VMware vSphere 에서 제공하는 자동화 기능에 대한 다음 게시물에서 이에 대해 다룰 예정입니다 .

• Azure Arc 지원 VMware vSphere – 3부

이 시리즈의 첫 번째 부분을 놓쳤다면:

• Azure Arc 지원 VMware vSphere – 2부

개요

• Azure Cloud 도구를 통해 VMware 데이터 센터를 관리하세요
  • 어떻게 작동하나요?
  • 이익
• 리소스 브리지 배포
  • 필수 조건
  • 리소스 요구 사항
  • vCenter 리소스 브리지 만들기
• 다가오는
  • 크레딧

Azure Cloud 도구를 통해 VMware 데이터 센터를 관리하세요

2021년 11월 Microsoft Ignite 에서 비공개 미리보기 단계 로 발표된 Azure Arc 와 VMware vSphere 통합은 이제 2022년 3월 31 일부터 공개 미리보기로 제공됩니다 .

아직 개발 중인 이 기능은 이제 Azure Arc 지원 VMware vSphere 로 명명되었으며 , Azure Arc를 통해 VMware VM의 수명 주기 및 게스트 OS 운영을 위한 통합 거버넌스 및 관리 솔루션을 제공합니다.

Azure VMware Solutions 프라이빗 클라우드는 표준화된 VMware SDDC를 사용하므로 Azure Arc 지원 VMware vSphere를 사용하여 AVS 기반 워크로드를 운영 할 수도 있습니다 .

어떻게 작동하나요?

Azure Arc 지원 VMware vSphere는 대상 환경(또는 대상 환경에 네트워크로 액세스할 수 있는 VMware 환경)에 배포된 리소스 브리지 어플라이언스 를 사용합니다 . 이 브리지는 Azure Arc가 vCenter API에서 데이터를 가져오고 관리하는 액세스 지점 역할을 합니다.

현재 Resource Bridge에는 인터넷(특히 HTTPS(443)를 통한 Azure API)에 대한 아웃바운드 연결이 필요하며 VMware 환경에만 배포할 수 있습니다.

어플라이언스가 완전히 배포되고 Azure Arc API에 보고되면 인벤토리를 탐색하고 일부 VMware 구성 요소를 Azure 객체로 액세스할 수 있도록 설정할 수 있습니다. VMware 환경의 Azure 지원 리소스는 다음에 연결됩니다.

• Azure의 VMware 데이터 센터를 나타내는 사용자 지정 위치
• 리소스를 구성하고 RBAC(역할 기반 액세스 제어) 전략을 적용할 수 있는 기능을 제공하는 리소스 그룹

이익

Azure Arc의 경우, Azure Arc 지원 VMware vSphere 의 주요 목표는 Azure가 아닌 환경, 즉 VMware vSphere 인프라로 Azure 거버넌스 및 관리 기능을 확장하는 것입니다.

이를 통해 Azure 및 VMware vSphere 인프라 전반에 걸쳐 다음과 같은 일관된 관리 환경이 제공됩니다.

• VMware 가상 머신(VM) 수명 주기 작업: 생성/등록, 시작/중지, 크기 조정 및 삭제.
• RBAC 전략을 적용하여 사용자와 애플리케이션 팀이 셀프 서비스 VM 작업을 수행할 수 있도록 합니다.
• 게스트 관리(Azure 정책, 업데이트 관리, 모니터링 등)를 활성화하여 Azure 및 VMware VM에서 Azure 거버넌스 전략을 적용합니다.
• Azure Resource Manager 기반 API를 사용하여 VMware 워크로드(ARM 또는 Bicep 템플릿, Azure API 및 CLI 도구)를 관리합니다.

리소스 브리지 배포

면책 조항 : 이 배포 프로세스 연습은 Azure Arc 지원 VMware vSphere 에 대한 Microsoft 설명서를 대체하지 않습니다 . 이 블로그 게시물은 Azure Arc 지원 VMware vSphere 기능 의 개발 현황과 동기화되는 주요 업데이트를 받지 않으며 , 특정 시점의 프로세스만 반영합니다.

필수 조건

Azure Arc 지원 VMware vSphere 기능 에 모두 액세스하려면 다음 Azure 리소스 공급자를 내 구독에 등록해야 했습니다.

• Microsoft.ConnectedVMwarevSphere
• Microsoft.HybridCompute
• Microsoft.GuestConfiguration

Azure CLI를 사용했습니다 .

export AZURE_SUBSCRIPTION_ID='********-****-****-****-************'
az provider register --wait --subscription "${AZURE_SUBSCRIPTION_ID}" --namespace Microsoft.ConnectedVMwarevSphere
az provider register --wait --subscription "${AZURE_SUBSCRIPTION_ID}" --namespace Microsoft.HybridCompute
az provider register --wait --subscription "${AZURE_SUBSCRIPTION_ID}" --namespace Microsoft.GuestConfiguration

리소스 요구 사항

Resource Bridge 어플라이언스에는 다음과 같은 리소스 할당이 필요합니다.

• 4개의 vCPU
• 16GB 램
• 100GB의 여유 디스크 공간

vCenter 리소스 브리지 만들기

Azure Portal에서 Azure Arc 제품을 선택한 후 다음을 수행합니다.

1. VMware vCenter(미리 보기)
2. (+) 추가

다음 사항을 요청드립니다.

1. 리소스 브리지를 구독, 리소스 그룹, 지역(현재는 미국 동부와 유럽 서부만 이용 가능)에 연결합니다 .
2. 사용자 정의 위치 에 대한 이름을 제공하세요

사용자 지정 위치는 Azure에서 vCenter 배포 위치를 나타냅니다.

1. Azure에서 vCenter에 대한 이름을 제공하세요.

마법사의 다음 화면에서는 새 리소스에 태그를 첨부할 수 있습니다 . 세 번째 단계에서는 PowerShell 기반(Windows) 또는 Azure CLI 기반(Linux) 버전의 스크립트를 다운로드하라는 메시지가 표시됩니다.

귀하의 구독이 모든 필수 리소스 공급자에게 등록되어 있지 않은 경우, 등록 버튼이 나타납니다.

다운로드한 스크립트는 리소스 브리지가 배포될 vCenter에 직접 또는 프록시 방식으로 액세스할 수 있는 워크스테이션이나 점프 서버 에서 실행해야 합니다 .

마지막 마법사 단계에서는 리소스 브리지 배포 상태에 대한 통찰력을 제공하지만 리소스 생성에는 영향을 미치지 않습니다.

(Windows) PowerShell 스크립트

Azure PowerShell 모듈이 필요합니다.

스크립트의 PowerShell(Windows) 버전을 선택하는 경우:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Install-Module -Name Az -Scope CurrentUser -Repository PSGallery
Connect-AzAccount
./resource-bridge-onboarding-script.ps1

(Linux) Azure CLI 스크립트

Azure CLI 가 필요합니다.

스크립트의 PowerShell(Windows) 버전을 선택하는 경우:

az login
bash resource-bridge-onboarding-script.sh

배포 스크립트 실행

배포 스크립트는 리소스 브리지 어플라이언스 를 배포하고 구성하기 위해 일련의 정보를 요청합니다 .

• 현재 워크스테이션에 대한 프록시 설정
• 대상 vCenter FQDN, 사용자 이름, 비밀번호
• VM 배포 세부 정보:
  • VMware 논리 데이터 센터
  • 회로망
  • 리소스풀
  • 데이터 저장소
  • VM 폴더
  • 기기 IP 설정

스크립트는 리소스 브리지 어플라이언스를 다운로드, 배포 및 구성하는 데 약 15분 동안 실행됩니다. 배포가 완료되면 UI 마법사의 확인 단계에서 Azure API와 어플라이언스가 서로 통신하고 있음을 확인하는 녹색 확인 표시가 나타납니다.

다가오는

향후 게시물에서는 Azure, UI 또는 자동화 도구를 사용하여 VMware 리소스를 관리하는 기능적 기능에 대해 다루겠습니다.

• Azure Arc 지원 VMware vSphere – 2부
• Azure Arc 지원 VMware vSphere – 3부

• 7단계 – AVS에 허브 기본 경로 광고
  • 경로 분석(s7)
  • AVS 이동 중 UDRbgp-subnet
  • 테스트(s7)
• 8단계 – 온프레미스의 AVS
  • 테스트(s8)
  • 경로 분석(s8)
• 9단계 – 허브 vNet의 Azure 서버
  • 경로 분석(s9)
  • 테스트(s9)
  • Azure Route Server를 통한 AVS 연결에 대한 추가 정보
• 3부 – 결론

이전 블로그 게시물( 1부 및 2부 )에서는 Azure VMware Solution(AVS) 배포를 포함한 허브 앤 스포크 토폴로지의 기본 구성 요소 배포에 대해 다루었습니다.

첫 번째 게시물에서는 허브 앤 스포크 환경의 모형을 구축하고 구성했습니다. 두 번째 게시물에서는 AVS 환경을 AVS 트랜짓 가상 네트워크(vNet) 에 연결 하고 AVS 워크로드에 기본 경로를 알렸습니다. 이 기본 경로는 아직 저희 어플라이언스를 사용하지 않고 , 인터넷에 연결하기 위해 hub-vna배포된 어플라이언스를 사용했습니다.avs-transit-vnet

avs-transit-vnet이 단계에서는 전체 h&s 토폴로지를 통합 하고 hub-nvaVM을 사용하여 다음을 포함한 모든 필수 필터링을 관리합니다.

• 스포크 투 스포크
• 스포크 투 온프레미스(또는 그 반대)
• 인터넷 브레이크아웃

AVS가 스포크처럼 동작하기를 원하므로 이 규칙을 AVS에도 적용할 것입니다 avs-transit-vnet.

이 블로그 게시물에 설명된 구성 요소와 네트워크 설계는 데모 목적으로만 제공됩니다. 프로덕션 환경에서 사용하기 위한 것이 아니며 Azure 모범 사례를 나타내는 것도 아닙니다. 모의 및 학습 목적으로만 있는 그대로 제공됩니다.

7단계 – AVS에 허브 기본 경로 광고

먼저, 에 적용되는 새 UDR에 몇 가지 경로를 추가해야 합니다 nva-subnet. 추가된 경로는 hub-nva를 통해 AVS 관련 트래픽을 전파할 수 있도록 합니다 avs-bgp-vm. 랩 설정에서는 두 개의 접두사에 대해 이 작업을 수행합니다.

• AVS 관리:10.100.100.0/22
• AVS 작업 부하:10.100.110.0/24

또한 어플라이언스 를 통해 기본 경로를 추가하려면 bgp-subnet내부 에 적용된 UDR을 업데이트해야 합니다 .avs-transit-vnethub-nva

경로 분석(s7)

NIC 에 적용 가능한 새로운 경로를 확인할 수 있습니다 hub-nva.

az network nic show-effective-route-table \
  --ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/hub-nva-nic \
  -o table
Source    State    Address Prefix    Next Hop Type     Next Hop IP
--------  -------  ----------------  ----------------  -------------
Default   Active   10.100.200.0/24   VnetLocal
Default   Active   10.100.202.0/24   VNetPeering
Default   Active   10.100.201.0/24   VNetPeering
Default   Active   10.100.203.0/24   VNetPeering
Default   Active   0.0.0.0/0         Internet
...
User      Active   10.100.110.0/24   VirtualAppliance  10.100.203.68 # <--- AVS workload
User      Active   10.100.100.0/22   VirtualAppliance  10.100.203.68 # <--- AVS management

AVS 이동 중 UDRbgp-subnet

스포크-투-스포크와 인터넷 브레이크아웃에 의존하고자 하므로 , 내부 에 적용된 UDR을 변경하여 통과를 보장 hub-nva해야 합니다 .bgp-subnetavs-transit-vnethub-nva

그리고 효과적인 경로에 대한 결과는 다음과 같습니다.

az network nic show-effective-route-table \
  --ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/avs-bgp-nic \
  -o table
Source                 State    Address Prefix     Next Hop Type          Next Hop IP
---------------------  -------  -----------------  ---------------------  -------------
Default                Active   10.100.203.0/24    VnetLocal
Default                Active   10.100.200.0/24    VNetPeering
VirtualNetworkGateway  Active   10.100.100.64/26   VirtualNetworkGateway  10.24.132.60
VirtualNetworkGateway  Active   10.100.109.0/24    VirtualNetworkGateway  10.24.132.60
VirtualNetworkGateway  Active   10.100.101.0/25    VirtualNetworkGateway  10.24.132.60
VirtualNetworkGateway  Active   10.100.100.0/26    VirtualNetworkGateway  10.24.132.60
VirtualNetworkGateway  Active   10.100.110.0/24    VirtualNetworkGateway  10.24.132.60
VirtualNetworkGateway  Active   10.100.111.0/24    VirtualNetworkGateway  10.24.132.60
VirtualNetworkGateway  Active   10.100.113.0/24    VirtualNetworkGateway  10.24.132.60
VirtualNetworkGateway  Active   10.100.114.0/24    VirtualNetworkGateway  10.24.132.60
VirtualNetworkGateway  Active   10.100.100.192/32  VirtualNetworkGateway  10.24.132.60
VirtualNetworkGateway  Active   10.100.103.0/26    VirtualNetworkGateway  10.24.132.60
VirtualNetworkGateway  Active   10.100.101.128/25  VirtualNetworkGateway  10.24.132.60
VirtualNetworkGateway  Active   10.100.102.0/25    VirtualNetworkGateway  10.24.132.60
VirtualNetworkGateway  Invalid  0.0.0.0/0          VirtualNetworkGateway  10.100.203.68
User                   Active   0.0.0.0/0          VirtualAppliance       10.100.200.68 # <--- Default route via hub-nva

마지막 줄에서 기본 경로가 이제 hub-nvaVM( 10.100.200.68)을 통해 이동하고 있음을 알 수 있습니다.

테스트(s7)

이 단계에서 AVS를 오가는 트래픽은 와 hub-nva를 통과합니다 avs-bgp-vm. 각 라우팅 어플라이언스를 스누핑하거나 traceroute스포크 VM으로의 의 결과를 확인하여 이를 쉽게 확인할 수 있습니다.

ubuntu@avs-vm-100-10:~$ mtr 10.100.201.4 --report
HOST: avs-vm-100-10              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- _gateway                   0.0%    10    0.2   0.2   0.1   0.2   0.0
  2.|-- 100.64.176.0               0.0%    10    0.2   0.2   0.2   0.3   0.0
  3.|-- 100.72.18.17               0.0%    10    0.8   0.8   0.7   1.1   0.1
  4.|-- 10.100.100.237             0.0%    10    1.1   1.2   1.1   1.4   0.1
  5.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  6.|-- 10.100.203.68              0.0%    10    3.1   3.1   2.7   5.6   0.9 # <--- avs-bgp-vm
  7.|-- 10.100.200.68              0.0%    10    4.5   4.8   3.4   7.6   1.6 # <--- hub-nva
  8.|-- 10.100.201.4               0.0%    10    4.1   6.6   4.1   9.3   1.8 # <--- spoke-vm

여기서 우리는 홉 6 과 7avs-bgp-vm 에서 ( 10.100.203.68)와 hub-nva( ) 의 IP 주소를 볼 수 있습니다 10.100.200.68. 인터넷 대상에서도 동일한 동작을 재현할 수 있습니다.

안타깝게도 온프레미스(VPN) 리소스에서는 두 avs-transit-vnet리소스 모두 사용할 수 없습니다. 해당 대상에 대해 광고된 경로가 없기 때문입니다.

8단계 – 온프레미스의 AVS

이전 단계에서 발견한 대로 온프레미스 리소스에는 두 AVS 리소스 중 어느 하나와도 통신하기 위해 광고된 경로가 없습니다 avs-transit-vnet.

현재 단계에서는 다음을 추가하여 이러한 부족함을 완화할 것입니다.

1. UDR의 새로운 경로 avs-transit-vnet와 AVS 리소스 GatewaySubnet.
   • 랩 설정에서 경로를 단순화하기 위해 Azure 리소스(AVS 리소스 포함)의 글로벌 접두사를 단일 경로로 광고합니다.10.100.0.0/16
   • 이 UDR은 VPN 게이트웨이에서 리소스에 대한 네트워크 경로를 찾는 데 사용됩니다.
2. VPN 구성에서 사용자 지정 경로를 사용하면 VPN 클라이언트가 대상 리소스에 대한 네트워크 트래픽이 VPN을 통과해야 함을 지정할 수 있습니다.
   • UDR의 경우 모든 리소스에 대한 글로벌 접두사를 사용하여 설정에서 사용자 지정 경로 알림을 간소화합니다.10.100.0.0/16

테스트(s8)

VPN 클라이언트에서 10.100.0.0/16VPN 경로에 사용자 지정 경로( )가 추가된 것을 쉽게 볼 수 있습니다.

AVS 기반 VM을 사용하여 P2S VPN 클라이언트의 연결을 확인하면 다음과 같습니다.

ubuntu@vpn-client:~$ ping 10.100.110.10 -c3
# output
PING 10.100.110.10 (10.100.110.10) 56(84) bytes of data.
64 bytes from 10.100.110.10: icmp_seq=1 ttl=57 time=52.3 ms
64 bytes from 10.100.110.10: icmp_seq=2 ttl=57 time=30.1 ms
64 bytes from 10.100.110.10: icmp_seq=3 ttl=57 time=52.9 ms
--- 10.100.110.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 30.097/45.119/52.947/10.625 ms

경로 분석(s8)

이 온프레미스 에서 AVS 로의 교환에서는 다음 라우팅 구성 요소가 사용됩니다.

1. VPN 클라이언트 측에서 사용자 지정 경로는 Azure 글로벌 접두사 및/또는 AVS 리소스와 일치하는 리소스에 대한 경로를 광고합니다.
2. VPN 게이트웨이는 연결된 UDR을hub-nva 사용하여 다음 홉으로 사용합니다 .
3. AVS 기반 리소스에 대한 경로를 찾기 위해 UDR hub-nva을 다음 홉으로 사용합니다 .avs-bgp-vm
4. vNET 피어링은 리소스 간 통신을 가능하게 합니다 hub-vnet.avs-transit-vnet
5. 에서 avs-transit-vnetAVS 리소스에 대한 경로는 AVS에 연결된 Express Route Gateway 에서 직접 광고되고 AVS BGP 경로를 전파합니다.

반대 방향으로:

1. Azure Route 서버avs-gbp-vm 와 조합하면 AVS 기반 워크로드에 대한 기본( ) 경로가 제공됩니다 .0.0.0.0/0
   • 6a) 기본 경로는 BGP를 통해 발표됩니다.avs-transit-vnet
   • 6b) Azure Route Server는 Azure SDN에서 경로 광고를 전파하고 경로는 Express Route 회로를 통해 AVS 워크로드에 광고될 수 있습니다.
2. vNET 피어링은 리소스 간 통신을 가능하게 합니다 hub-vnet.avs-transit-vnet
3. 에서 hub-vnetVPN 기반 워크로드로의 경로는 VPN 게이트웨이 에서 직접 광고됩니다 .

9단계 – 허브 vNet의 Azure 서버

hub-nvaBGP 기능과 Azure Route Server를 함께 사용하면 Azure에서 사용되는 네트워크 접두사를 VPN 가상 네트워크 게이트웨이 에 광고하고 . 의 경로 테이블을 유지 관리하지 않아도 됩니다 GatewaySubnet.

이전 설정과 비교해서 다음이 제거되었습니다 .

• VPN 구성의 사용자 지정 경로
• GatewaySubnet 에 연결된 UDR

그리고 우리는 이렇게 덧붙였습니다 .

• 새로운 Azure Route 서버
• hub-nva(랩의 글로벌 Azure 접두사를 사용했지만 이는 더 구체적인 공지일 수 있음) 에서 광고된 BGP 경로
• Azure Route Serverhub-nva 간의 BGP 피어링

경로 분석(s9)

Azure Route Server 에서 BGP 피어가 예상 경로를 주입하고 있는 것을 확인할 수 있습니다.

$routes = @{
    RouteServerName = 'HubRouterServer'
    ResourceGroupName = 'nva-testing-RG'
    PeerName = 'hub-rs-bgp-connection'
}
Get-AzRouteServerPeerLearnedRoute @routes | ft
# output
LocalAddress  Network       NextHop       SourcePeer    Origin AsPath Weight
------------  -------       -------       ----------    ------ ------ ------
10.100.200.36 10.100.0.0/16 10.100.200.68 10.100.200.68 EBgp   65001  32768
10.100.200.37 10.100.0.0/16 10.100.200.68 10.100.200.68 EBgp   65001  32768

VPN 게이트웨이 에서도 광고된 경로를 볼 수 있습니다.

az network vnet-gateway list-learned-routes -n hub-vpn-gateway -g nva-testing-RG -o table
# output
Network            NextHop        Origin    SourcePeer     AsPath    Weight
-----------------  -------------  --------  -------------  --------  --------
10.100.200.0/24                   Network   10.100.200.5             32768
10.100.201.0/24                   Network   10.100.200.5             32768
10.100.202.0/24                   Network   10.100.200.5             32768
10.100.204.0/25                   Network   10.100.200.5             32768
10.100.204.128/25  10.100.200.4   IBgp      10.100.200.4             32768
10.100.204.128/25  10.100.200.4   IBgp      10.100.200.36            32768
10.100.204.128/25  10.100.200.4   IBgp      10.100.200.37            32768
10.100.0.0/16      10.100.200.68  IBgp      10.100.200.36  65001     32768 # <--- BGP route from hub-nva
10.100.0.0/16      10.100.200.68  IBgp      10.100.200.37  65001     32768 # <--- BGP route from hub-nva
10.100.200.0/24                   Network   10.100.200.4             32768
10.100.201.0/24                   Network   10.100.200.4             32768
10.100.202.0/24                   Network   10.100.200.4             32768
10.100.204.128/25                 Network   10.100.200.4             32768
10.100.204.0/25    10.100.200.5   IBgp      10.100.200.5             32768
10.100.204.0/25    10.100.200.5   IBgp      10.100.200.36            32768
10.100.204.0/25    10.100.200.5   IBgp      10.100.200.37            32768
10.100.0.0/16      10.100.200.68  IBgp      10.100.200.36  65001     32768 # <--- BGP route from hub-nva
10.100.0.0/16      10.100.200.68  IBgp      10.100.200.37  65001     32768 # <--- BGP route from hub-nva

VPN 클라이언트에서도 vNET 피어링 간의 경로를 사용할 수 있습니다.

테스트(s9)

VPN 클라이언트에서 AVS 기반 VM에 도달하면 토폴로지의 구성 요소를 볼 수 있습니다.

ubuntu@vpn-client:~$ mtr 10.100.110.10 -r
# output
Start: 2023-02-09T17:21:35+0100
HOST: vpn-client                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- vpn-client                 0.0%    10    0.5   0.5   0.3   1.0   0.3
  2.|-- 10.100.200.68              0.0%    10   21.0  53.3  20.6 307.4  89.7
  3.|-- 10.100.203.68              0.0%    10   25.4  44.5  21.6 207.4  57.8
  4.|-- 10.100.203.4               0.0%    10   36.0  42.4  21.9 120.7  29.9
  5.|-- 10.100.100.233             0.0%    10   54.0  32.0  23.8  59.9  13.5
  6.|-- 10.100.100.65              0.0%    10   49.3  39.8  24.6  55.8  12.5
  7.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- 10.100.110.10              0.0%    10   60.5  37.4  22.7  64.9  18.2

mtr다음 다이어그램에서 추적 의 홉 번호를 일치시켰습니다 (홉 세트는 AVS 네트워크 스택의 일부이며 여기에 문서화되지 않음을 고려):

Azure Route Server를 통한 AVS 연결에 대한 추가 정보

Azure Route Server에 대해 자세히 알아보려면 다음 게시물을 꼭 읽어보세요.

• Azure Route Server: 캡슐화할지 말지, 그것이 문제 이며 BGP 슈퍼히어로에 합류할 Azure Firewall의 조력자 Jose Moreno
• Cynthia Treger의 Azure Route Server, VxLAN(또는 IPSec) 및 BGP를 갖춘 NVA Routing 2.0
• Azure 설명서의 Azure Route Server

3부 – 결론

이 시리즈의 마지막 3개 게시물에서는 Azure VMware 솔루션 배포에 허브 및 스포크 토폴로지를 도입하는 맥락에서 Azure 네트워킹과 관련된 많은 주제를 다루었습니다 .

Azure 제품(예: Azure Route Server)의 성능과 기능(예: UDR의 경로 전파)을 보여주기 위해 이 모형 설정을 단계별로 만들었습니다.

마지막 단계에서는 hub-nvaAVS 환경, 스포크 vNet 및 온프레미스 리소스에서 트래픽을 라우팅하고 필터링할 수 있는 중앙 VM을 갖춘 작업 설정이 있습니다.

참고 : 이 게시물에 설명된 설정은 구성 요소의 고가용성 및 중복성 부족으로 인해 프로덕션 환경에서 사용하기에 적합하지 않습니다. Azure 네트워킹 제품과 기능의 성능을 보여주기 위한 모형일 뿐입니다.

이 시리즈를 즐겁게 읽으시고 Azure 네트워킹에 대해 새로운 것을 배우셨기를 바랍니다. 앞으로 이 시리즈를 확장하여 다음과 같은 새로운 주제와 사용 사례를 담은 게시물이 더 많이 올라올 예정입니다.

• 구성 요소의 높은 가용성 및 중복성
• hub-nvaBGP 를 사용한 동적 라우팅avs-spoke-nva

• 4단계 – GatewaySubnet의 사용자 정의 경로
  • 경로 분석(s4)
  • Azure UDR에 대한 추가 정보
• 5단계 – AVS 전송 vNet 소개
  • 경로 분석(s5)
  • AVS 연결에 대한 추가 정보
• 6단계 – AVS에 기본 경로 광고
  • AVS 인터넷 연결 설정
  • 경로 분석(s6)
  • 테스트(s6)
  • Azure Route Server를 통한 AVS 연결에 대한 추가 정보
• 2부 – 결론

이전 블로그 게시물 에서는 허브 앤 스포크 토폴로지에서 Azure VMware Solution(AVS) 환경의 모의 구축을 시작하기 위한 기본 환경을 배포하는 방법을 살펴보았습니다. 마지막 섹션 에서는 VPN과 스포크 VM 간의 트래픽을 조회할 때 매트릭스 결함을 발견했습니다. 이 블로그 게시물에서는 이 문제를 해결하는 방법을 살펴보겠습니다 .

또한 AVS 배포에서 Express Route 회로를 연결하기 위한 AVS 전송 vNet의 첫 번째 구성 요소를 소개하고 VMware 워크로드에 기본 BGP 경로를 주입하는 방법 도 소개합니다 .

이 블로그 게시물에 설명된 구성 요소와 네트워크 설계는 데모 목적으로만 제공됩니다. 프로덕션 환경에서 사용하기 위한 것이 아니며 Azure 모범 사례를 나타내는 것도 아닙니다. 모의 및 학습 목적으로만 있는 그대로 제공됩니다.

실험실 환경과 이미 다룬 3가지 첫 단계에 대한 자세한 내용은 1부를 참조하세요 .

4단계 – GatewaySubnet의 사용자 정의 경로

비대칭 라우팅 문제를 완화하기 위해 GatewaySubnetVPN 클라이언트에서 들어오는 트래픽이 NVA 어플라이언스로 라우팅되도록 사용자 정의 경로를 추가합니다 .

사용자 정의 경로(UDR)는 GatewaySubnet아래와 같이 구성됩니다.

• 10.100.201.0/24(일명 spoke1-vnet)를 통해nva-vm.nic[0].ipaddress
• 10.100.202.0/24(일명 spoke2-vnet)를 통해nva-vm.nic[0].ipaddress

Azure Portal에서는 다음과 같습니다.

물론, 사용된 IP 주소 계획에 따라 여러 경로를 공통 접두사 아래에 단순화하고 그룹화하는 것이 가능합니다.

경로 분석(s4)

이 지점에서 우리는 VPN 클라이언트-스포크와 스포크-VPN 대상지 모두가 hub-nva어플라이언스를 통과하는 것을 볼 수 있습니다.

예: VPN 클라이언트에서 ping 세션이 진행되는 동안 에코 요청 과 에코 응답이spoke-1-vm 모두 : 를 통해서만 전송되는 것을 볼 수 있습니다 .hub-nva

ubuntu@hub-nva:~$ sudo tcpdump -nni eth0  icmp
# output
IP 10.100.204.2 > 10.100.201.4: ICMP echo request, id 1002, seq 1, length 64
IP 10.100.200.68 > 10.100.201.4: ICMP echo request, id 1002, seq 1, length 64
IP 10.100.201.4 > 10.100.200.68: ICMP echo reply, id 1002, seq 1, length 64
IP 10.100.201.4 > 10.100.204.2: ICMP echo reply, id 1002, seq 1, length 64

이제 모든 네트워크 트래픽이 .를 통과합니다 hub-nva. 즉, 비대칭 라우팅 문제가 해결되었습니다.

Azure UDR에 대한 추가 정보

Azure의 UDR에 대해 자세히 알아보려면 다음 게시물을 꼭 읽어보세요.

• Azure 설명서의 사용자 정의 경로
• Azure 설명서에서 Azure가 경로를 선택하는 방법
• Jose Moreno의 Azure Routes에 물리지 마세요

5단계 – AVS 전송 vNet 소개

Azure VMware 솔루션(AVS)은 Express Route 회로 기반 외부 연결을 제공합니다. 이를 위해서는 AVS 환경 외부로 Express Route 회로를 '연결'해야 합니다. 가장 일반적인 방법은 AVS Express Route 회로를 기존 온프레미스 Express Route 회로에 매핑하고 Express Route Global Reach를 통해 두 회로 간의 연결을 제공하는 것 입니다 . 즉, 전이적 연결(transitive connection)을 구현합니다.

하지만 이 설정은 AVS 배포를 허브-스포크 토폴로지의 스포크로 간주할 수 있는 방법을 제공하지 않습니다. AVS와 온프레미스 간의 네트워크 트래픽이 .를 우회하기 때문입니다 hub-nva. 이 문제를 해결하기 위해 AVS 배포에서 Express Route 회로를 연결하고 AVS와 온프레미스 간의 트래픽이 .를 통해 라우팅되도록 트랜짓 vNet을hub-nva 도입합니다 .

여기에서는 avs-transit-vnetAVS 배포에서 Express Route 회로를 착륙시키기 위해 Express Route Gateway가 필요합니다.

경로 분석(s5)

vNet 생성이 완료되고 AVS ER 회로 설정이 완료되면 이 단계에서 AVS 기반 VM과 통신할 수 있는 가능성이 있는지 확인하기 위해 효과적인 경로를 살펴볼 수 있습니다.

az network nic show-effective-route-table \
  --ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/hub-nva-nic \
  -o table
# output
Source                 State    Address Prefix    Next Hop Type          Next Hop IP
---------------------  -------  ----------------  ---------------------  -------------
Default                Active   10.100.200.0/24   VnetLocal
Default                Active   10.100.202.0/24   VNetPeering
Default                Active   10.100.201.0/24   VNetPeering
Default                Active   10.100.203.0/24   VNetPeering
VirtualNetworkGateway  Active   10.100.204.0/24   VirtualNetworkGateway  20.160.147.74

물론, 경로가 없으면 연결도 없습니다.

ubuntu@hub-nva:~$ ping 10.100.100.2 -c3
# output
PING 10.100.100.2 (10.100.100.2) 56(84) bytes of data.
--- 10.100.100.2 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2029ms

AVS 연결 설정 에 따라 Express Route 연결에서 발표된 경로를 사용하여 인터넷이나 다른 Azure 리소스에 도달하는 경우 발표된 경로가 없기 때문에 AVS 외부 리소스와 통신할 수 없습니다.

AVS 연결에 대한 추가 정보

AVS 연결에 대해 자세히 알아보려면 다음 게시물을 꼭 읽어보세요.

• Azure 설명서의 Azure VMware 솔루션 네트워킹 및 상호 연결 개념
• Azure 설명서의 Azure VMware Solution 네트워크 설계 고려 사항
• Jose Moreno의 Azure VMware 솔루션 네트워킹 부두

6단계 – AVS에 기본 경로 광고

현재 단계에서는 AVS에 기본 경로(0.0.0.0/0)를 공지할 예정입니다. 이 블로그 게시물 시리즈의 핵심 주제대로, 단계별로 진행하며 가장 간단한 해결책인 AVS에서 기본 경로 공지부터 시작할 것입니다 avs-transit-vnet. 그리고 허브 앤 스포크 토폴로지의 이전 구성 요소는 일시적으로 무시하겠습니다.

첫째, AVS 트랜짓 토폴로지 에 몇 가지 추가 구성 요소를 추가해야 합니다 .

• VM avs-bgp-vm에서:
  • BGP 경로 발표 시작
  • AVS에서 들어오는 트래픽을 라우팅합니다.
• Azure SDN에서 경로 공지를 전파하기 위한 Azure Route Server( ARS )
  • 이 ARS 구성 요소는 가상 네트워크 게이트웨이를avs-bgp-vm 통해 BGP 피어에서 AVS로 들어오는 경로를 제공하고 피어링 됩니다 .
• . 에서 광고하는 기본 경로를 재정의하는 경로 테이블 ( UDR) avs-bgp-vm입니다. 그렇지 않으면 VM은 자신을 전체 vNET의 기본 경로로 광고하고, VM에서 보낸 트래픽을 포함하여 인터넷으로 향하는 트래픽을 계속 전송합니다 .

avs-transit-vnet앞서 언급했듯이 이는 첫 번째이자 임시 단계입니다. AVS 배포를 위해 인터넷 연결이 이루어진 이 설정을 검증하면 다음 단계를 이해하고 준비하는 데 도움이 됩니다.

AVS 인터넷 연결 설정

Azure VMware 솔루션은 인터넷 연결을 위한 세 가지 옵션을 제공합니다.

• Microsoft에서 관리하는 SNAT
• NSX-T 에지까지의 공용 IP 주소
• Express Route 회로 경로 안내를 통한 맞춤형 인터넷 연결

이 블로그 게시물 시리즈에서는 AVS가 Express Route 회로를 통해 발표된 기본 경로에서 인터넷 연결을 받도록 구성되어 있다고 생각해 보겠습니다 .

경로 분석(s6)

새로운 구성 요소와 연결 생성이 완료되면 다음과 같은 효과적인 경로를 살펴보고 결과를 확인할 수 있습니다.

배포된 Azure Route Server 에서 BGP 피어를 볼 수 있습니다.

az network routeserver peering show -g nva-testing-RG \
  -n avs-rs-bgp-connection --routeserver AVSTransitRouterServer \
  -o table
# output
Name                   PeerAsn    PeerIp         ProvisioningState    ResourceGroup
---------------------  ---------  -------------  -------------------  ---------------
avs-rs-bgp-connection  65002      10.100.203.68  Succeeded            nva-testing-RG

그리고 BGP 피어가 광고한 학습된 경로를 확인 해야 합니다 .

az network routeserver peering list-learned-routes \
  -g nva-testing-RG -n avs-rs-bgp-connection \
  --routeserver AVSTransitRouterServer -o table
# output
Issue: no route displayed there!

PowerShell을 사용하면 광고된 경로가 표시됩니다.

$routes = @{
    RouteServerName = 'AVSTransitRouterServer'
    ResourceGroupName = 'nva-testing-RG'
    PeerName = 'avs-rs-bgp-connection'
}
Get-AzRouteServerPeerLearnedRoute @routes | ft
LocalAddress  Network   NextHop       SourcePeer    Origin AsPath Weight
------------  -------   -------       ----------    ------ ------ ------
10.100.203.36 0.0.0.0/0 10.100.203.68 10.100.203.68 EBgp   65002   32768
10.100.203.37 0.0.0.0/0 10.100.203.68 10.100.203.68 EBgp   65002   32768

avs-bgp-vm이 (가) 자신을 기본 경로의 다음 홉으로 광고하고 있음 을 알 수 있습니다 . 이는 예상되는 동작입니다.

테스트(s6)

AVS에 호스팅된 VM에서 다음을 통해 인터넷에 접속할 수 있습니다 avs-bgp-vm.

ubuntu@avs-vm-100-10:~$ mtr 1.1.1.1 --report
HOST: avs-vm-100-10                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- _gateway                   0.0%    10    0.1   0.2   0.1   0.2   0.0
  2.|-- 100.64.176.0               0.0%    10    0.2   0.3   0.2   0.3   0.0
  3.|-- 100.72.18.17               0.0%    10    0.9   0.8   0.7   0.9   0.1
  4.|-- 10.100.100.233             0.0%    10    1.0   1.0   0.9   1.1   0.1
  5.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  6.|-- 10.100.203.68              0.0%    10    3.2   4.0   2.6   7.3   2.0 # <--- avs-bgp-vm
  7.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 10.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 12.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 13.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 14.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 15.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 16.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 17.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 18.|-- one.one.one.one            0.0%    10    5.7   4.9   3.9   9.6   1.7

이전 경로 추적 보고서에서는 이 시나리오에서 예상한 대로 라우터나 NVA처럼 작동하는 10.100.203.68IP가 있습니까 ?avs-bgp-vm

하지만 분명히 이는 h&s 토폴로지의 나머지 부분에 대한 표준 스포크 동작과는 다릅니다. 이 단계는 앞으로 필요한 일부 구성 요소를 준비하기 위한 것일 뿐입니다.

Azure Route Server를 통한 AVS 연결에 대한 추가 정보

Azure에서 Azure Route Server를 통한 AVS 연결에 대해 자세히 알아보려면 다음 게시물을 꼭 읽어보세요.

• Azure 설명서의 Azure Route Server를 사용하여 Azure VMware 솔루션에 경로 주입
• Azure 설명서에서 모든 네트워크 트래픽을 검사하기 위한 Azure Virtual Network의 네트워크 가상 어플라이언스

2부 – 결론

두 번째 부분에서는 VPN Gateway에 적용 가능한 새로운 경로 테이블을 구성하여 비대칭 라우팅 문제를 완화하는 방법을 살펴보았고 , Azure Route Server 의 도움으로 Azure VMware Solution 배포 에 BGP 경로를 광고하기 위한 네트워크 구성 요소를 생성했습니다 .

다음 (그리고 아마도 마지막) 부분에서는 이 AVS 전송 토폴로지를 허브 앤 스포크 토폴로지에서 일반 스포크로 구성하는 방법을 살펴보겠습니다. 또한 Azure Route Server를 활용하여 온프레미스 연결 구성을 간소화하는 방법도 다룹니다 .

개요

• 재료
  • Azure VMware 솔루션 배포
• 0단계 – 기본 설정
  • 경로 분석
  • Azure 라우팅에 대한 추가 정보
• 1단계 – 스포크 피어링
  • 경로 분석(s1)
  • Azure Peering에 대한 추가 정보
• 2단계 – 스포크의 사용자 정의 경로/GW 전파가 참임
  • 경로 분석(s2)
  • Azure UDR에 대한 추가 정보
• 3단계 – 스포크의 사용자 정의 경로/GW 전파가 거짓입니다.
  • 경로 분석(s3)
  • 게이트웨이 경로 전파에 대한 추가 정보
• 1부 – 결론

Azure에서 VMware 워크로드를 실행하기 위해 Azure VMware Solution을 사용하는 경우 , 안전하고 효율적인 방식으로 다른 Azure 리소스와 연결하는 방법이 궁금할 수 있습니다. 한 가지 방법은 허브 앤 스포크 네트워크 토폴로지를 사용하는 것입니다. 허브 앤 스포크 토폴로지는 여러 스포크 가상 네트워크 의 게이트웨이 역할을 하는 중앙 가상 네트워크( 허브 ) 로 구성된 디자인 패턴입니다 . 이 블로그 게시물에서는 Azure VMware Solution을 허브 앤 스포크 토폴로지와 함께 사용하는 방법과 이러한 접근 방식의 문제점을 살펴보겠습니다.

Azure VMware Solution과 허브 앤 스포크 토폴로지를 사용하면 보안 강화 및 클라우드 호스팅 워크로드 격리 등 여러 이점을 얻을 수 있습니다. 하지만 복잡성, 지연 시간, 대역폭 제한, 라우팅 복잡성, 방화벽 규칙 관리 등과 같은 몇 가지 과제도 고려해야 합니다. 따라서 특정 요구 사항에 따라 네트워크 설계를 신중하게 계획하는 것이 중요합니다.

Azure 공식 설명서에는 Azure VMware Solution의 네트워크 연결과 관련된 시나리오가 이미 제공되어 있습니다. 여기에서 확인할 수 있습니다 . 이 블로그 게시물 시리즈에서는 Azure Virtual Network의 네트워크 가상 어플라이언스에서 매우 가까운 모의 시나리오를 단계별로 재현하여 모든 네트워크 트래픽을 검사해 보겠습니다 .

이 블로그 게시물에 설명된 구성 요소 및 네트워크 설계는 데모 목적으로만 제공됩니다. 프로덕션 환경에서 사용하기 위한 것이 아니며 Azure 모범 사례를 나타내는 것도 아닙니다. 모의 및 학습 목적으로만 있는 그대로 제공됩니다.

재료

이 블로그 게시물 시리즈를 설명하기 위해 여기에 설명된 프로세스의 각 단계를 재현하기 위해 Terraform 코드를 호스팅하는 GitHub 저장소를 만들었습니다 .

이 Terraform 콘텐츠를 사용하면 Azure에서 동일한 환경을 배포하는 반복 가능한 방법이 제공되지만 이 블로그 게시물에 설명된 모든 단계는 Azure Portal이나 Azure CLI를 사용하여 재현할 수도 있습니다.

Azure VMware 솔루션 배포

Azure VMware Solution의 배포 및 구성은 이 블로그 게시물의 범위를 벗어납니다. AVS 환경은 이미 배포 및 구성되어 있다고 가정합니다. 허브 앤 스포크 토폴로지의 필수 설정은 이 시리즈의 다른 섹션에서 다루겠습니다.

0단계 – 기본 설정

첫 번째 단계로, 다음과 같은 매우 기본적인 구성 요소를 사용하여 실험실 설정을 시작하겠습니다.

• 허브 vNET:hub-vnet
  • VM(NVA가 될 예정)
  • 가상 네트워크 게이트웨이
    • 비용이 많이 드는 Express Route 회로를 사용할 수 없이 온프레미스 동작을 시뮬레이션하기 위해 VPN을 선택합니다.
• 2개의 스포크 vNET: spoke1-vnet및spoke2-vnet
  • 각각에 스포크 VM이 있음
• P2S VPN 서브넷은 온프레미스 기반 워크로드로 작동합니다.

경로 분석

이러한 설정이 구축되면 구성 요소 간 라우팅 구성을 살펴볼 수 있습니다.

유효 경로 hub-nva.nic[0]:

az network nic show-effective-route-table \
    --ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/hub-nva-nic \
    -o table
# output
Source                 State    Address Prefix    Next Hop Type          Next Hop IP
-------------------- - ------ - ----------------  -------------------- - ------------ -
Default                Active   10.100.200.0/24   VnetLocal
VirtualNetworkGateway  Active   10.100.204.0/24   VirtualNetworkGateway  20.16.121.157
Default                Active   0.0.0.0/0         Internet

UI에서:

유효 경로 spoke-1-vm.nic[0]:

az network nic show-effective-route-table \
    --ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/spoke-1-vnet-vm-nic \
    -o table
# output
Source    State    Address Prefix    Next Hop Type    Next Hop IP
--------  ------ - ----------------  -------------- - ------------ -
Default   Active   10.100.201.0/24   VnetLocal
Default   Active   0.0.0.0/0         Internet

UI에서:

다이어그램과 경로 목록에서 이미 추측할 수 있듯이, 서로 다른 vNet 간의 통신은 불가능합니다. 예를 들어, from에서 hub-nvato로 spoke-1-vm:

ubuntu@hub-nva:~$ ping 10.100.201.4 -c3
# output
PING 10.100.201.4 (10.100.201.4) 56(84) bytes of data.
-- - 10.100.201.4 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2036ms

스포크 간 통신을 시도하면 결과는 똑같습니다. 즉, vNet 간에 연결이 없습니다.

Azure 라우팅에 대한 추가 정보

Azure의 네트워크 및 라우팅에 대해 자세히 알아보려면 다음의 훌륭한 블로그 게시물을 꼭 읽어보세요.

• Azure 네트워킹은 Jose Moreno의 온프레미스 네트워크와 다릅니다.
• Cynthia Treger의 NIC 라우팅 및 Azure 경로

1단계 – 스포크 피어링

spoke1-vnet이 단계에서는 및 간의 피어링을 추가하여 spoke2-vnet통신 hub-vnet을 활성화합니다.

경로 분석(s1)

이러한 설정이 구축되면 구성 요소 간 라우팅 구성을 살펴볼 수 있습니다.

유효 경로 hub-nva.nic[0]:

az network nic show-effective-route-table \
    --ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/hub-nva-nic \
    -o table
# output
Source                 State    Address Prefix    Next Hop Type          Next Hop IP
---------------------  -------  ----------------  ---------------------  -------------
Default                Active   10.100.200.0/24   VnetLocal
Default                Active   10.100.201.0/24   VNetPeering
Default                Active   10.100.202.0/24   VNetPeering
VirtualNetworkGateway  Active   10.100.204.0/24   VirtualNetworkGateway  20.16.121.157
Default                Active   0.0.0.0/0         Internet

유효 경로 spoke-1-vm.nic[0]:

az network nic show-effective-route-table \
    --ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/spoke-1-vnet-vm-nic \
    -o table
# output
Source                 State    Address Prefix    Next Hop Type          Next Hop IP
-------------------- - ------ - ----------------  -------------------- - ------------ -
Default                Active   10.100.201.0/24   VnetLocal
Default                Active   10.100.200.0/24   VNetPeering
VirtualNetworkGateway  Active   10.100.204.0/24   VirtualNetworkGateway  20.16.121.157
Default                Active   0.0.0.0/0         Internet

이제 hub-vnet의 VM은 피어링된 네트워크의 VM을 ping할 수 있습니다. 예: from hub-nvato spoke-1-vm:

ubuntu@hub-nva:~$ ping 10.100.201.4 -c3
# output
PING 10.100.201.4 (10.100.201.4) 56(84) bytes of data.
64 bytes from 10.100.201.4: icmp_seq=1 ttl=64 time=1.74 ms
64 bytes from 10.100.201.4: icmp_seq=2 ttl=64 time=1.14 ms
64 bytes from 10.100.201.4: icmp_seq=3 ttl=64 time=0.975 ms

-- - 10.100.201.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.975/1.284/1.744/0.331 ms

하지만 다른 스포크에 있는 VM은 서로 통신할 수 없습니다. 예를 들어, from spoke-1-vmto spoke-2-vm:

ubuntu@spoke-1-vm:~$ ping 10.100.202.4 -c3
# output
PING 10.100.202.4 (10.100.202.4) 56(84) bytes of data.

-- - 10.100.202.4 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2029ms

VPN 클라이언트에서 이제 모든 네트워크로 가는 경로를 볼 수 있습니다.

• 10.100.202.0/24:spoke2-vnet
• 10.100.201.0/24:spoke1-vnet
• 10.100.200.0/24:hub-vnet
• 10.100.204.0/24:VPN client range

Azure Peering에 대한 추가 정보

Azure의 네트워크 피어링에 대해 자세히 알아보려면 다음 게시물을 꼭 읽어보세요.

• VNet 피어링 설정, Jose Moreno의 친숙한 낯선 사람들
• Azure 설명서의 가상 네트워크 피어링

2단계 – 스포크의 사용자 정의 경로/GW 전파가 참임

이 단계에서는 스포크 간 통신을 활성화하기 위해 spoke1-vnetUDR 을 추가합니다 .spoke2-vnet

각 스포크 서브넷에 대해 다음 구성을 사용하여 UDR을 추가합니다.

• 0.0.0.0/0을 통해nva-vm.nic[0].ipaddress
• disable_bgp_route_propagation = false

UI에서 보면 다음과 같습니다.

hub-nva다음 홉 주소는 hub-vnet의 VM NIC 의 IP 주소입니다 .

또한 다음 게이트웨이 경로 전파 구성을 설정했습니다.

경로 분석(s2)

유효 경로 spoke-1-vm.nic[0]:

az network nic show-effective-route-table --ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/spoke-1-vnet-vm-nic -o table
# output
Source                 State    Address Prefix    Next Hop Type          Next Hop IP
---------------------  -------  ----------------  ---------------------  -------------
Default                Active   10.100.201.0/24   VnetLocal
Default                Active   10.100.200.0/24   VNetPeering
VirtualNetworkGateway  Active   10.100.204.0/24   VirtualNetworkGateway  20.16.121.157
Default                Invalid  0.0.0.0/0         Internet
User                   Active   0.0.0.0/0         VirtualAppliance       10.100.200.68 # <--- via hub-nva

다른 스포크에 있는 VM은 서로 통신할 수 있습니다. 예를 들어, from spoke-1-vmto spoke-2-vm:

ubuntu@spoke-1-vnet-vm:~$ ping 10.100.202.4 -c3
# output
PING 10.100.202.4 (10.100.202.4) 56(84) bytes of data.
64 bytes from 10.100.202.4: icmp_seq=1 ttl=63 time=4.05 ms
64 bytes from 10.100.202.4: icmp_seq=2 ttl=63 time=1.59 ms
64 bytes from 10.100.202.4: icmp_seq=3 ttl=63 time=2.18 ms

-- - 10.100.202.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 1.587/2.604/4.049/1.049 ms

VM 에서 hub-nva다음을 통해 트래픽이 이동하는 것을 볼 수 있습니다.

IP 10.100.201.4 > 10.100.202.4: ICMP echo request, id 8, seq 1, length 64
IP 10.100.200.68 > 10.100.202.4: ICMP echo request, id 8, seq 1, length 64
IP 10.100.202.4 > 10.100.200.68: ICMP echo reply, id 8, seq 1, length 64
IP 10.100.202.4 > 10.100.201.4: ICMP echo reply, id 8, seq 1, length 6

VPN 연결을 통해 다음과 같은 스포크 리소스에 접근할 수 있습니다.

ubuntu@vpn-client:~$ ping 10.100.201.4 -c3
# output
PING 10.100.201.4 (10.100.201.4) 56(84) bytes of data.
64 bytes from 10.100.201.4: icmp_seq=1 ttl=63 time=24.1 ms
64 bytes from 10.100.201.4: icmp_seq=2 ttl=63 time=22.7 ms
64 bytes from 10.100.201.4: icmp_seq=3 ttl=63 time=24.9 ms

하지만 VM에서 보면 hub-nva이 네트워크 트래픽에 맞는 것이 없습니다. 즉, 스포크 VM의 유효 경로 테이블에서 알 수 있듯이 트래픽은 스포크 VM에서 VPN 게이트웨이로 직접 이동하고, 그 반대의 경우도 마찬가지입니다.

다음 단계에서는 트래픽이 VM을 통과하도록 강제하여 이 문제를 완화하려고 노력할 것입니다 hub-nva.

Azure UDR에 대한 추가 정보

Azure의 UDR에 대해 자세히 알아보려면 다음 게시물을 꼭 읽어보세요.

• Azure 설명서의 사용자 정의 경로
• Azure 설명서에서 Azure가 경로를 선택하는 방법
• Jose Moreno의 Azure Routes에 물리지 마세요

3단계 – 스포크의 사용자 정의 경로/GW 전파가 거짓입니다.

이 단계에서는 NVA 장치를 우회하여 VPN과 관련된 네트워크 트래픽에 대해 이전 단계에서 발생했던 문제를 완화하기 시작할 것입니다.

가장 먼저 시도해 볼 수 있는 방법은 이전 단계에서 생성한 UDR에서 게이트웨이 경로 전파를 비활성화하는 것입니다 .

각 스포크 서브넷에 대해 다음 구성을 사용하여 UDR을 추가합니다.

• 0.0.0.0/0을 통해nva-vm.nic[0].ipaddress
• disable_bgp_route_propagation = true

UI에서 보면 다음과 같습니다.

경로 분석(s3)

유효 경로 spoke-1-vm.nic[0]:

az network nic show-effective-route-table \
    --ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/spoke-1-vnet-vm-nic \
    -o table
# output
Source    State    Address Prefix    Next Hop Type     Next Hop IP
--------  ------ - ----------------  ----------------  ------------ -
Default   Active   10.100.201.0/24   VnetLocal
Default   Active   10.100.200.0/24   VNetPeering
Default   Invalid  0.0.0.0/0         Internet
User      Active   0.0.0.0/0         VirtualAppliance  10.100.200.68 # <--- via hub-nva

새로운 UDR 설정에 따르면, VPN 서브넷 경로는 더 이상 spoke-1-vmNIC의 유효 경로에 직접 게시되지 않습니다. spoke-1-vmVPN 기반 리소스와 통신해야 하는 경우, 기본 0/0경로가 사용되며 hub-nvaVM을 통과합니다.

VPN 클라이언트에서 ping을 시도하면 spoke-1-vm작동합니다.

ubuntu@vpn-client:~$ ping 10.100.201.4 -c3
# output
PING 10.100.201.4 (10.100.201.4) 56(84) bytes of data.
64 bytes from 10.100.201.4: icmp_seq=1 ttl=62 time=23.6 ms
64 bytes from 10.100.201.4: icmp_seq=2 ttl=62 time=48.0 ms
64 bytes from 10.100.201.4: icmp_seq=3 ttl=62 time=64.1 ms

-- - 10.100.201.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 23.609/45.235/64.094/16.643 ms

… 하지만 매트릭스에는 결함이 있습니다.

보시다시피, spoke-1-vmVPN에서 들어오는 트래픽만 를 통과합니다 hub-nva. 반대로, VPN 클라이언트에서 들어오는 트래픽은 스포크 VM으로 직접 이동하므로 비대칭 네트워크 패턴이 발생합니다.

예를 들어, VPN 클라이언트에서 ping을 수행할 때 tcpdump를 수행할 때만 echo 응답이 전송되는 것을 spoke-1-vm볼 수 있습니다 .hub-nva

ubuntu@hub-nva:~$ sudo tcpdump -nni eth0  icmp
# output
IP 10.100.201.4 > 10.100.200.68: ICMP echo reply, id 1002, seq 1, length 64
IP 10.100.201.4 > 10.100.204.2: ICMP echo reply, id 1002, seq 1, length 64

에코 요청이 없습니다. VPN 클라이언트의 흐름이 hub-nva를 통과하지 않습니다.

게이트웨이 경로 전파에 대한 추가 정보

Gateway 경로 전파 기능 에 대한 자세한 내용을 알고 싶으시다면 다음 게시물을 참조하세요.

• Azure 설명서의 Border Gateway Protocol
• Jose Moreno가 Azure에서 가상 네트워크 게이트웨이 라우팅을 설명합니다.
• Cynthia Treger가 작성한 가상 네트워크 게이트웨이(ER 또는 VPN) 추가의 연결성 영향

1부 – 결론

이전 단계에서는 Azure 내에서 허브 앤 스포크 토폴로지를 초기화하는 방법을 살펴보았습니다. 현재 단계에서는 Azure 호스팅 스포크 vNet이 허브 vNet을 전송 네트워크로 사용하고 있으며, UDR(사용자 정의 경로)에 구성된 기본 경로를 활용합니다.

VPN 연결(온프레미스 워크로드로 작동)과 관련하여 비대칭 라우팅 문제가 발생하고 있음을 확인했습니다. VPN 클라이언트에서 Azure 호스팅 VM으로 향하는 트래픽이 허브 vNet에 배포된 NVA VM을 통과하지 못하고 있습니다.

알림으로써, 이 게시물에 설명된 단계를 재현하려면 다음 GitHub 저장소의 콘텐츠를 활용할 수 있습니다: hub-and-spoke-avs-transit-step-by-step .

다음 게시물에서는 새로운 사용자 정의 경로 구성을 활용하여 이 문제를 완화하는 방법을 살펴보겠습니다. 또한 Azure VMware Solution(AVS)을 이 허브 앤 스포크 토폴로지에 연결하는 방법도 소개합니다.

개요

• 기본 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의 기본 게이트웨이를 클라우드 측 게이트웨이로 변경하는 것이 네트워크 흐름을 최적화하는 좋은 방법이 될 수 있습니다.