Azure Resource Manager는 Azure의 배포 및 관리 서비스입니다. Azure 계정에서 리소스를 생성, 업데이트 및 삭제할 수 있는 관리 계층을 제공합니다. 배포 후에는 액세스 제어, 잠금, 태그와 같은 관리 기능을 사용하여 리소스를 보호하고 구성할 수 있습니다.
ARM은 API, UI 및 Azure 도구에서 Azure 리소스를 관리하는 데 사용되는 핵심 엔진이며, 리소스를 배포하고 유지 관리하는 선언적 Infrastructure-as-Code 언어를 제공합니다. ARM 템플릿이 바로 그것입니다. ARM 템플릿은JSON또는Bicep구문을 사용할 수 있습니다.
다른 리소스와 마찬가지로 VMware 인프라의 Azure 지원 구성 요소는 ARM 및 ARM 템플릿을 통해 관리할 수 있습니다.
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기능은아직 미리보기 단계이므로 글로벌 출시 전에 많은 변경 사항과 개선 사항이 적용될 예정입니다.
이전 게시물(1부)에서는Azure Arc 지원 VMware vSphere의 기능에 대해 다루었습니다. 이는 Azure 거버넌스 및 관리 정책을 VMware 기반 워크로드로 확장하는 솔루션입니다.
또한 VMware 환경과 Azure를 연결하기 위해리소스 브리지를구축했습니다 . 이제 Azure를 통해 vCenter 인벤토리를 탐색하고 가상 머신을 관리할 수 있습니다.
Azure UI에서 vCenter 인벤토리 탐색
vCenter와Resource Bridge가Azure Arc에 연결되면 해당 콘텐츠와 연결 상태를 살펴볼 수 있습니다.
Azure Portal의 vCenter 세부 정보
Azure에서 리소스를 사용하려면 활성화가 필요합니다.Azure에서 활성화를사용하여 Azure에서 기존 VMware 리소스를 활성화하세요. 모든 Azure 기반 리소스와 마찬가지로, RBAC 전략을 적용하여Azure 지원리소스에 대한 액세스를 제공하거나 제한할 수 있습니다.
ResourcePool, Networks, Templates 및 Datastores는 활성화 과정에서 선택하는 AzureResourceGroup 에숨겨진 리소스로 표시됩니다. 이러한 리소스는 VM 생성 과정에 사용되지만 Azure에서 편집할 수는 없습니다.
리소스풀
VMwareResourcePool은생성, 편집 또는 제거할 수 없지만 VM 생성 시나리오에 등록할 수 있습니다. 기본적으로 모든 resourcePool은 인벤토리 목록에 표시됩니다(클러스터 및 호스트 resourcePool 표현 포함). Azure에서 ResourcePool을 활성화하려면 해당 ResourcePool을 선택하고 "Azure에서 사용" 을 클릭합니다. AzureResourceGroup첨부 파일을 입력하라는 메시지가 표시되고, 해당 resourcePool과 세부 정보를 살펴볼 수 있는 링크가 표시됩니다.
Azure Portal의 ResourcePools 리소스
VM 템플릿
VMwareVM 템플릿은생성, 편집 또는 제거할 수 없지만 VM 생성 시나리오에 등록할 수 있습니다. 기본적으로 모든 VM 템플릿은 인벤토리 목록에 표시됩니다. Azure에서 VM 템플릿을 선택하고 "Azure에서 사용" 을 클릭하여 활성화할 수 있습니다. AzureResourceGroup첨부 파일을 입력하라는 메시지가 표시되고, 템플릿과 함께 세부 정보를 살펴볼 수 있는 링크가 표시됩니다.
참고: 현재 콘텐츠 라이브러리의 템플릿은 사용할 수 없습니다.Azure Arc 지원 VMware vSphere에서는 vCenter VM 폴더 인벤토리의 VM 템플릿만 사용할 수 있습니다 .
Azure Portal의 VM 템플릿
네트워크
VMware네트워크는생성, 편집 또는 제거할 수 없지만 VM 생성 시나리오에 등록할 수 있습니다. 기본적으로 모든 네트워크(NSX-T 세그먼트, PortGroups 및 DvPortGroups)가 인벤토리 목록에 표시됩니다. Azure에서 네트워크를 활성화하려면 해당 네트워크를 선택하고 "Azure에서 활성화" 를 클릭합니다. AzureResourceGroup첨부 파일을 입력하라는 메시지가 표시되고, 템플릿과 함께 세부 정보를 볼 수 있는 링크가 표시됩니다.
Azure Portal의 네트워크
데이터 저장소
VMware데이터 저장소는생성, 편집 또는 제거할 수 없지만 VM 생성 시나리오에 등록할 수 있습니다. 기본적으로 모든 데이터 저장소는 인벤토리 목록에 표시됩니다. Azure에서 데이터 저장소를 활성화하려면 해당 데이터 저장소를 선택하고"Azure에서 활성화" 를 클릭합니다. AzureResourceGroup첨부 파일을 입력하라는 메시지가 표시되고, 데이터 저장소와 함께 세부 정보를 살펴볼 수 있는 링크가 표시됩니다.
Azure Portal의 데이터 저장소
Azure를 통한 VMware 가상 머신 관리
이 게시물의 이전 부분에서 언급했듯이 ResourcePool, Networks, Templates 및 Datastores는 Azure(UI, API, ARM 등)를 통해 생성, 편집 또는 삭제할 수 없지만 가상 머신 배포 종속성을 제공하기 위해 ReadOnly 액세스로 등록할 수 있습니다.
Azure를 통해 VMware Virtual Machines에 사용할 수 있는 작업 세트는 다음과 같은 점에서 더욱 중요합니다.
전원 작동(시작/중지/재시작)
가상 머신 재구성:
CPU/메모리(전원이 꺼진 VM용)
디스크 - 추가/제거/크기 조정
네트워크 - 네트워크 연결 추가/제거/변경
Arc 기반 게스트 관리 활성화 및 확장 프로그램 설치
RBAC 및 태그 정책 적용
VMware Arc 기반 게스트 확장 기능은현재LogAnalytics 에이전트와 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에서 활성화" 를 클릭하세요. AzureResourceGroup첨부 파일을 입력하라는 메시지가 표시되고, 해당 가상 머신과 함께 세부 정보를 살펴볼 수 있는 링크가 표시됩니다.
Azure 지원 VMware 가상 머신의 세부 정보
VM 만들기
VM 개체는 Azure(UI 또는 API)에서도 완전히 생성될 수 있습니다.
Arc Virtual Machines 또는 Arc에 등록된 vCenter의 VM 목록에서 '만들기'버튼을 클릭하여 VM 생성 마법사를 시작합니다.
VMware 가상 머신 생성 프로세스 – 1단계
VM을 연결할 ResourceGroup을 선택한 다음 VM 배포에 대한 세부 정보를 제공할 수 있습니다.
이름
사용자지정 위치및 개체 유형(VMware)
대상리소스 풀
사용할VM템플릿
템플릿 설정을 재정의하도록 선택한 경우 VM CPU 및 메모리 구성
생성 프로세스 중에 게스트 관리를 활성화하도록 선택한 경우 관리자 로그인 및 비밀번호
VMware 가상 머신 생성 프로세스 – 2단계
마법사의 두 번째 단계는 가상 디스크 구성(이름, 크기, 컨트롤러 및 지속성)입니다.
VMware 가상 머신 생성 프로세스 – 3단계
마법사의 세 번째 단계에서는 네트워크 설정 구성(네트워크 연결, IP 설정 등)을 제공합니다.
VMware 가상 머신 생성 프로세스 – 4단계
네 번째 단계에서는 VM 개체에 태그/값을 추가할 수 있습니다(태그는 Azure 측에만 적용되며 VMware 측에는 적용되지 않습니다).
VMware 가상 머신 생성 프로세스 – 5단계
마지막 단계에서는 요청된 변경 사항을 검증하고 배포를 시작할 수 있는 창을 제공합니다.
VMware 가상 머신 생성 프로세스 – 6단계
배포 프로세스가 완료되면 결과를 보고 배포된 리소스를 표시할 수 있습니다.
VMware 가상 머신 생성 프로세스 – 6단계
이제 vCenter와 Azure UI에서 동일한 VM 개체에 대한 보기를 비교할 수 있습니다.
VMware 가상 머신 생성 프로세스 – 6단계
VMware 기반 리소스에 대한 Azure 거버넌스
Azure에서 VMware 리소스를 관리하는 주요 이점 중 하나는 다음과 같은 표준 Azure 거버넌스 전략을 적용할 수 있다는 것입니다.
그룹화 및 태그 지정
Azure에서 활성화된 VMware 리소스는 AzureResourceGroups에 연결될 수 있으며 리소스 개체(RBAC, 잠금 등)에 대한 거버넌스 상속으로부터 이점을 얻을 수 있습니다.
검색 작업에서 리소스를 필터링하거나 리소스 비용 및 속성을 관리하기 위해 VMware 리소스에 태그를 지정할 수도 있습니다.
VMware 리소스에 적용된 Azure ResourceGroup 및 태그
RBAC
Azure에서 활성화된 VMware 리소스에 Azure RBAC 전략을 적용하여 리소스에 대한 읽기 전용, 기여 또는 소유권을 제공할 수 있습니다.
VMware 리소스에 적용된 Azure RBAC
잠그다
Azure Lock과 구독 또는 ResourceGroup의 종속성을 사용하여 삭제 또는 수정을 방지할 수도 있습니다.
VMware 리소스에 적용된 잠금 삭제
다가오는
배포 마지막 화면에서 보셨겠지만, 진행 중인 배포를 나타내는 ARM 템플릿을 가져오거나 다운로드할 수 있습니다.Azure Arc 지원 VMware vSphere에서 제공하는 자동화 기능에 대한 다음 게시물에서 이에 대해 다룰 예정입니다 .
이전 블로그 게시물(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
AVS에 허브 기본 경로를 광고합니다.
경로 분석(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
AVS 전송 bgp-subnet의 UDR
그리고 효과적인 경로에 대한 결과는 다음과 같습니다.
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으로의 의 결과를 확인하여 이를 쉽게 확인할 수 있습니다.
이전 블로그 게시물에서는허브 앤 스포크 토폴로지에서 Azure VMware Solution(AVS) 환경의 모의 구축을 시작하기 위한 기본 환경을 배포하는 방법을 살펴보았습니다.마지막 섹션에서는 VPN과 스포크 VM 간의 트래픽을 조회할 때 매트릭스 결함을 발견했습니다. 이 블로그 게시물에서는이 문제를 해결하는 방법을살펴보겠습니다 .
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도입합니다 .
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
현재 단계에서는 AVS에 기본 경로(0.0.0.0/0)를 공지할 예정입니다. 이 블로그 게시물 시리즈의 핵심 주제대로, 단계별로 진행하며 가장 간단한 해결책인 AVS에서 기본 경로 공지부터 시작할 것입니다avs-transit-vnet. 그리고 허브 앤 스포크 토폴로지의 이전 구성 요소는 일시적으로 무시하겠습니다.
첫째, AVS 트랜짓토폴로지 에 몇 가지 추가 구성 요소를 추가해야 합니다.
VMavs-bgp-vm에서:
BGP 경로 발표 시작
AVS에서 들어오는 트래픽을 라우팅합니다.
Azure SDN에서 경로 공지를 전파하기 위한 Azure Route Server(ARS)
이 ARS 구성 요소는 가상 네트워크 게이트웨이를avs-bgp-vm통해 BGP 피어에서 AVS로 들어오는 경로를 제공하고피어링 됩니다.
. 에서 광고하는 기본 경로를 재정의하는경로 테이블( UDR)avs-bgp-vm입니다. 그렇지 않으면 VM은 자신을 전체 vNET의 기본 경로로 광고하고,VM에서 보낸 트래픽을 포함하여 인터넷으로 향하는트래픽을 계속 전송합니다 .
AVS에 기본 경로를 광고합니다.
avs-transit-vnet앞서 언급했듯이 이는 첫 번째이자 임시 단계입니다. AVS 배포를 위해인터넷 연결이 이루어진 이 설정을 검증하면 다음 단계를 이해하고 준비하는 데 도움이 됩니다.
두 번째 부분에서는 VPN Gateway에 적용 가능한 새로운 경로 테이블을구성하여 비대칭 라우팅 문제를 완화하는 방법을 살펴보았고 ,Azure Route Server의 도움으로Azure VMware Solution배포 에 BGP 경로를 광고하기 위한 네트워크 구성 요소를 생성했습니다.
다음 (그리고 아마도 마지막) 부분에서는 이 AVS 전송 토폴로지를 허브 앤 스포크 토폴로지에서 일반 스포크로 구성하는 방법을 살펴보겠습니다. 또한 Azure Route Server를활용하여 온프레미스 연결 구성을 간소화하는 방법도 다룹니다.
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 서브넷은 온프레미스 기반 워크로드로 작동합니다.
0단계의 허브 및 스포크 구성 요소
경로 분석
이러한 설정이 구축되면 구성 요소 간 라우팅 구성을 살펴볼 수 있습니다.
유효 경로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에서:
hub-nva.nic[0]의 유효 경로
유효 경로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에서:
spoke-1-vm.nic[0]의 유효 경로
다이어그램과 경로 목록에서 이미 추측할 수 있듯이, 서로 다른 vNet 간의 통신은 불가능합니다. 예를 들어, from에서hub-nvato로spoke-1-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.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
세게 때리다
hub-nva.nic[0]의 유효 경로
유효 경로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
세게 때리다
spoke-1-vm.nic[0]의 유효 경로
이제 hub-vnet의 VM은 피어링된 네트워크의 VM을 ping할 수 있습니다. 예: fromhub-nvatospoke-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은 서로 통신할 수 없습니다. 예를 들어, fromspoke-1-vmtospoke-2-vm:
이 단계에서는 스포크 간 통신을 활성화하기 위해spoke1-vnetUDR을 추가합니다 .spoke2-vnet
2단계의 허브 및 스포크 구성 요소
각 스포크 서브넷에 대해 다음 구성을 사용하여 UDR을 추가합니다.
0.0.0.0/0을 통해nva-vm.nic[0].ipaddress
disable_bgp_route_propagation = false
UI에서 보면 다음과 같습니다.
스포크 vNet의 UDR
hub-nva다음 홉 주소는 hub-vnet의 VM NIC의 IP 주소입니다 .
또한 다음게이트웨이 경로 전파구성을 설정했습니다.
스포크 vNet의 UDR 경로 전파 구성
비활성화+거짓
게이트웨이 경로 전파설정 과 관련하여 Azure UI와 Terraform 간에 문구 차이가 있을 수 있습니다. Azure UI에서는 이 옵션을Propagate gateway route.(으)로, Terraform, Bicep, ARM과 같은 API 기반 도구에서는 이 옵션을disableBgpRoutePropagation(ARM/Bicep) 또는disable_bgp_route_propagation(Terraform)으로 부릅니다.
이는 부울 값과 관련된 경우 혼동될 수 있습니다. 이 경우,Gatewayfalse구성 요소 의 경로가UDR과 연결된 서브넷으로 전파됨을 의미합니다.
경로 분석(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
세게 때리다
spoke-1-vm.nic[0]의 유효 경로
다른 스포크에 있는 VM은 서로 통신할 수 있습니다. 예를 들어, fromspoke-1-vmtospoke-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.
이 단계에서는 NVA 장치를 우회하여 VPN과 관련된 네트워크 트래픽에 대해 이전 단계에서 발생했던 문제를 완화하기 시작할 것입니다.
가장 먼저 시도해 볼 수 있는 방법은 이전 단계에서 생성한 UDR에서게이트웨이 경로 전파를비활성화하는 것입니다 .
3단계의 허브 및 스포크 구성 요소
각 스포크 서브넷에 대해 다음 구성을 사용하여 UDR을 추가합니다.
0.0.0.0/0을 통해nva-vm.nic[0].ipaddress
disable_bgp_route_propagation = true
UI에서 보면 다음과 같습니다.
스포크 vNet의 UDR 경로 전파 구성
비활성화+거짓
앞서 언급했듯이 자동화 도구를 사용하여 이 구성 값을 설정하는 경우, 용어가 혼동될 수 있습니다. Azure UI에서는 이 옵션을 .(으)로, Terraform, Bicep, ARM과 같은 API 기반 도구에서는 이 옵션을(ARM/Bicep) 또는(Terraform)Propagate gateway route으로 부릅니다 .disableBgpRoutePropagationdisable_bgp_route_propagation
이 경우,Gatewaytrue구성 요소 의 경로가UDR과 연결된 서브넷으로 전파되지 않음을 의미합니다.
경로 분석(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
세게 때리다
spoke-1-vm.nic[0]의 유효 경로
새로운 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 VMware Solution이 메트릭을 Azure Event Hub로 전달하도록 구성하는 것입니다. 이 작업은 Azure Portal의 Azure VMware Solution 리소스진단 설정창에서 수행됩니다.
Azure VMware 솔루션: 이벤트 허브 인스턴스에 메트릭을 전송하기 위한 진단 설정 구성
참고:메트릭범주 만 선택하면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로 전송된 메트릭을 저장하기 위한 테이블과 매핑을 만듭니다.
다음 단계는 Azure 이벤트 허브로 전송된 메트릭을 사용하도록 Azure Data Explorer를 구성하는 것입니다. 이 작업은 Azure Portal의 Azure Data Explorer 리소스의데이터 연결창에서 수행됩니다.
기존 데이터베이스와 대상 테이블이 필요합니다.
이벤트 허브를 사용하여 Azure Data Explorer 데이터 연결 만들기
새 데이터 연결 만들기
데이터 소스로이벤트 허브를선택하세요
데이터 연결에 대한 이름을 제공하세요
Azure 이벤트 허브 인스턴스(구독, 네임스페이스 및 이벤트 허브)를 선택하세요.
사용할 소비자 그룹을 선택하세요
Azure Data Explorer에서 대상 테이블을 선택하세요
데이터 형식을 선택하세요:JSON
사용할 매핑의 이름을 입력하세요(이전 단계에서 생성):avs-metrics_mapping
만들기를 클릭하세요
최소 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 애플리케이션 뷰어 액세스 권한을 추가합니다.
데이터 소스를 저장한 후 새 대시보드를 만들고 새 패널을 추가하여 메트릭을 시각화할 수 있습니다.
대시보드
이제 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
이 솔루션을 통해 다음과 같은 측정 항목을 사용할 수 있습니다.
메트릭 이름설명
TotalMbAverage
SDDC의 총 메모리
DiskUsedPercentage
vSAN 데이터 저장소의 디스크 사용률
UsedLatest
vSAN 데이터 저장소에서 사용된 총 디스크 양
UsageAverage
SDDC의 메모리 사용량 백분율
EffectiveMemAverage
클러스터에서 사용 가능한 총 머신 메모리 양
CapacityLatest
vSAN 데이터 저장소 총 용량
OverheadAverage
가상화 인프라에서 사용되는 호스트 물리적 메모리
EffectiveCpuAverage
SDDC의 CPU 사용률
grafana의 알림기능을 사용하여이러한 메트릭을 기반으로 알림을 만들고 특정 임계값에 도달하면 관리자에게 알릴 수도 있습니다(Azure Monitor에서도 마찬가지로 할 수 있습니다).
대시보드 예시
다음은 이러한 측정항목을 사용하여 만들 수 있는 대시보드의 몇 가지 예입니다.
AVS Grafana 대시보드 예시 1번: 각 리소스의 마지막 값을 기반으로 한 색상 통계
AVS Grafana 대시보드 예시 2: 각 리소스에 대한 게이지 시각화
AVS Grafana 대시보드 예시 3: 시계열 시각화
메트릭을 결합, 필터링 및 집계하여 고유한 대시보드를 만들고 Azure VMware Solution 환경에 대한 글로벌 뷰를 제공할 수 있습니다.
Azure VMware 솔루션(AVS)은 주로 하이퍼컨버지드 인프라(HCI)와 VMware vSAN을 활용하여 가상 머신(VM) 워크로드를 호스팅할 스토리지 용량을 제공하는 관리형 서비스입니다. 솔루션에 배포된 각 호스트는 분산 스토리지 용량에 로컬 스토리지 장치와 기능을 제공합니다.
기본적으로 이러한 HCI 솔루션의 확장성은 클러스터에 새로운 호스트를 추가하여 VM에서 사용할 수 있는 스토리지 용량과 컴퓨팅 리소스를 늘리는 데 기반합니다.
그러나 추가적인 컴퓨팅 리소스가 필요하지 않고 AVS 클러스터의 저장 용량을 확장해야 하는 경우도 있습니다.
AVS 저장 용량 확장
컴퓨팅 리소스를 확장하지 않고도 AVS 클러스터의 저장 용량을 확장하는 데 사용할 수 있는 다양한 옵션에 대해 간략히 살펴보겠습니다.
Azure NetApp 파일
스토리지 용량 확장을 위한 초기 솔루션은 Azure VMware Solution(AVS)의 스토리지 백엔드로 Azure NetApp Files(ANF)를 활용하는 것이었습니다. ANF 볼륨은 AVS 클러스터 내 ESXi 호스트에 NFS 데이터 저장소로 마운트됩니다. 네트워크 연결은 전용 Azure Virtual Network(vNet) 및 서브넷과 ExpressRoute 게이트웨이를 통해 관리됩니다.
이 게시물에서는 Azure Elastic SAN을 AVS와 통합하고 이를 통해 외부 스토리지 용량을 활용하는 방법을 살펴보겠습니다.
현지화
Azure Elastic SAN은여러 Azure 지역에서 사용할 수 있습니다. Azure Elastic SAN을 AVS와 통합할 때는 지연 시간을 최소화하고 성능을 최적화하기 위해 AVS 클러스터와 동일한 Azure 지역 및 가용성 영역(AZ)에 스토리지 서비스를 배포하는 것이 좋습니다.
네트워크 토폴로지
Azure Elastic SAN 및 AVS: 네트워크 토폴로지
이전 그림은 Azure Elastic SAN을 AVS와 통합할 때의 네트워크 토폴로지를 보여줍니다.
AVS 클러스터의 ESXi 호스트는 다음 구성 요소를 통해 Azure Elastic SAN 서비스에 연결됩니다.
ESXi 호스트당 새로운 VMKernel 인터페이스:외부 스토리지 블록
AVS와 함께 Elastic SAN을 사용하려면 SDDC의 외부 스토리지 블록을구성하기 위해 새로운 IP 주소 블록/범위를 프로비저닝해야 합니다. 주소 블록은 /24 네트워크여야 합니다(문서 참조).
새로운외부 스토리지 블록을구성할 때 AVS 클러스터의 각 ESXi 호스트에는 새 IP 주소 블록 내에 구성된 두 개의 VMKernel 인터페이스가 있습니다.
새로운 VMKernel 인터페이스
두 개의 새로운 네트워크 인터페이스는 새로 생성된 iSCSI 소프트웨어 어댑터를 사용하여 Azure Elastic SAN 서비스에 대한 iSCSI 연결을 시작하는 데 사용됩니다.
새로운 iSCSI 소프트웨어 어댑터
AVS 익스프레스 루트 회로
Azure VMware 솔루션은 Express Route 회로(ER) 개념을 사용하여 NSX-T 및 관리 네트워크 경계 외부로 연결을 제공합니다. Azure Elastic SAN과 같은 Azure 서비스에 대한 연결은 물론, 필요한 경우 온프레미스 환경과의 연결도 지원합니다.
외부 스토리지 리소스의 경우, 성능을 극대화하고 다른 서비스의 노이즈가 많은 이웃 효과를 제한하기 위해 전용 Express Route Gateway를 사용하는 것이 좋습니다.
Express Route 게이트웨이는 AVS ER을 Elastic SAN과의 연결을 설정할 수 있는 Azure vNet에 "연결"합니다. 스토리지 서비스의 성능을 보장하려면 예상 처리량 및 지연 시간 요구 사항에 따라 이 구성 요소의 크기를 조정하는 것이 중요합니다.
Azure Elastic SAN 서비스에 연결하려면 Azure vNet에 개인 엔드포인트를 만들어야 합니다.
성능과 안정성을 높이려면 호스트와 스토리지 서비스 간에 여러 세션을 설정하기 위해 여러 개의 프라이빗 엔드포인트를 생성해야 합니다. Azure 설명서에서는 스토리지 서비스 성능 최적화를 위한 권장 사항(구성 권장 사항)을 제공합니다 .
Elastic SAN에 액세스하기 위한 개인 엔드포인트 세트
Azure vNet 다이어그램에서는 개인 엔드포인트, 해당 네트워크 인터페이스 카드(NIC) 및 Azure Elastic SAN 서비스에 대한 연결을 볼 수 있습니다.
Azure UI 다이어그램의 Azure vNet 및 Private Endpoints 구성 요소
스토리지 구성
Azure VMware Solution에 Elastic SAN을 마운트하는 작업은 Azure Portal이나 API를 통해 관리되며 프로세스는 매우 간단합니다. Elastic SAN 서비스, 볼륨 그룹을 선택한 다음 마운트할 볼륨과 대상 클러스터를 선택하면 됩니다.
노드에 마운트하면 스토리지는 vCenter와 Azure Portal 모두에서 데이터 저장소로 표시됩니다.
AVS에 마운트된 Elastic SAN 볼륨: Azure Portal에서
AVS에 마운트된 Elastic SAN 볼륨: vCenter UI에서
결론
이제 워크로드를 이 새로운 스토리지 용량으로 마이그레이션하고 Azure Elastic SAN의 성능과 비용 최적화를 활용할 때입니다. 워크로드 런타임을 보존하기 위해Storage vMotion을사용하여 VM을 한 데이터 저장소에서 다른 데이터 저장소로 이동하는 것이 좋습니다.
vSAN 클러스터는 가장 낮은 지연 시간과 가장 높은 처리량이 필요한 VM에 가장 우수한 성능을 제공할 가능성이 높다는 점을 명심하세요. Azure Elastic SAN은 성능, 용량, 비용 최적화 간의 적절한 균형을 필요로 하는 VM에 적합한 후보입니다.
Azure Migrate 및 VMware HCX와 같은 도구를 사용하면 Azure, 특히 Azure VMware Solution으로의 워크로드 마이그레이션이 크게 간소화됩니다. 하지만 몇 가지 과제가 남아 있습니다. 가장 큰 과제 중 하나는 네트워크 흐름을 이해하고 마이그레이션 단계를 준비하는 것입니다. 많은 사용자가 Azure Migrate 종속성 분석 과정에서 수집된 데이터를 분석하고 실행 가능한 마이그레이션 단계로 구성하는 데 어려움을 겪습니다.
문제
Azure Migrate 종속성 분석을 수행할 때 사용자는 방대한 양의 네트워크 흐름 데이터와 이를 이해하는 데 어려움을 느끼는 경우가 많습니다. 이러한 데이터는 성공적인 마이그레이션을 계획하고 실행하는 데 필수적이지만, 적절한 도구가 없으면 데이터를 해석하고 효과적으로 활용하는 것이 어려울 수 있습니다.
해결책
이 문제를 해결하기 위해 저는 포괄적인 솔루션인Azure Migrate Network Flows Analysis(Github 저장소)를 개발했습니다. 이 도구는 네트워크 흐름 데이터를 읽기 쉬운 시각적 정보로 변환하여 사용자가 쉽게 이해할 수 있도록 지원합니다. 또한, 사용자가 마이그레이션을 더욱 효율적으로 계획하고 실행하여 오류와 가동 중지 시간을 줄일 수 있도록 지원합니다. 또한, 흐름 시각화, 필터링된 테이블, 내보내기 등의 기능을 제공하여 마이그레이션 프로세스를 더욱 원활하게 진행하고 성공 가능성을 높여줍니다.
특징
CSV 가져오기: Azure Migrate 종속성 분석에서 네트워크 흐름 데이터가 포함된 CSV 파일을 가져옵니다.
데이터는 전적으로 브라우저 내에 유지되며 서버에 업로드되지 않으므로 데이터 개인 정보 보호가 보장됩니다.
데이터 처리: 업로드된 CSV 파일에서 데이터를 추출하고 처리합니다.
시각화: 대화형 그래프를 사용하여 네트워크 흐름을 시각화합니다.
필터링: IP 주소, 포트, VLAN 등 다양한 기준에 따라 데이터를 필터링합니다.
CSV 다운로드: 필터링된 데이터를 CSV 파일로 다운로드합니다.
VLAN: CSV 파일과 흐름 그룹화에서 선택적 VLAN 데이터 열을 지원합니다.
HCX를 사용하는 Azure VMware 환경에서 성공적인 마이그레이션 계획을 위해서는 VLAN 또는 서브넷별로 항목을 그룹화하는 것이 매우 중요합니다. L2 확장을 활용하고 확장 전환을 준비하는 것은 워크로드를 효율적으로 마이그레이션하고 네트워크 문제를 방지하는 데 필수적인 단계입니다.
RFC1918이 아닌 IP: RFC1918이 아닌 IP 주소를 다시 그룹화하고 필터링합니다.
사용 방법
CSV 파일 업로드:
업로드 페이지로 이동합니다.
네트워크 흐름 데이터가 포함된 CSV 파일을 업로드합니다.
CSV 파일에는 다음과 같은 열이 있어야 합니다.
Source server name
Source IP
Source application
Source process
Destination server name
Destination IP
Destination application
Destination process
Destination port
Source VLAN(선택 과목)
Destination VLAN(선택 과목)
데이터 보기 및 필터링:
업로드 후 시각화 페이지로 이동하게 됩니다.
필터를 사용하여 소스 IP, 대상 IP, 포트 및 VLAN을 기준으로 데이터를 좁힙니다.
데이터는 표와 대화형 그래프로 표시됩니다.
그래프 상호작용:
연결을 클릭하면 흐름 통계에 대한 정보를 얻을 수 있습니다.
RFC1918이 아닌 IP 필터링 및 그룹화:
"RFC1918이 아닌 IP 주소 그룹화" 버튼을 사용하여 RFC1918이 아닌 IP 주소를 그룹화합니다.
검색 및 필터링을 간소화하기 위해 표가 업데이트됩니다.
이를 통해 인터넷 트래픽에 집중할 수 있습니다.
필터링된 데이터 다운로드:
"CSV 다운로드" 버튼을 클릭하면 필터링된 데이터를 CSV 파일로 다운로드할 수 있습니다.
선택적 VLAN 데이터
필터링을 돕기 위해 CSV 파일에 선택적 VLAN 데이터 열을 추가할 수 있습니다.
열에는 이름을 지정해야Source VLAN합니다Destination VLAN.
선택 열
이러한 열은 Azure Migrate 종속성 분석에서 내보낸 원본 CSV 파일의 일부가 아닙니다.
이 애플리케이션은 시각화에서 리소스를 필터링하고 그룹화하는 데 이 데이터를 사용합니다.
자신의 인스턴스를 실행하세요
이 애플리케이션은 JavaScript 애플리케이션이므로 로컬에서 실행하거나 자체 서버에 호스팅할 수 있습니다. 이 애플리케이션은Github 에서 제공되며,Docker 이미지를사용하여컨테이너에서 실행할 수도 있습니다.
테스트해보세요!
다음 통합은 테스트 데이터 세트를 사용하여 애플리케이션의 실시간 테스트를 제공합니다.az-mdv.az.vupti.me에서 애플리케이션에 직접 접속 하거나, 직접 데이터를 사용할 수도 있습니다. 피드백을 환영합니다!
다음은 무엇인가요?
더 많은 기능을 추가하고 사용자 경험을 향상시켜 도구를 지속적으로 개선해 나갈 계획입니다. 향후 업데이트에 대한 피드백과 제안을 환영합니다. 질문이나 의견이 있으시면 언제든지 연락주세요.
또한 워크로드를 그룹화하고 데이터를 기반으로 마이그레이션 주기를 제안하는 데 도움이 되는 AI 기반 기능을 추가해 볼 수도 있습니다. 이 기능은 도구에 큰 도움이 될 것입니다.
며칠 전, Microsoft는 Azure VMware 솔루션에 새로운 기능인NSX Edge에 대한 공용 IP 활성화기능을 출시했습니다 . 이 기회를 빌려 이 새로운 기능과 Azure VMware 솔루션에 인터넷 연결을 제공하기 위해 사용 가능한 다른 옵션(수신 및 발신 트래픽 모두)을 살펴보겠습니다.
Azure VMware 솔루션에 대한 인터넷 액세스 옵션
Azure VMware Solution 배포에 인터넷 액세스(인바운드 및/또는 아웃바운드)를 제공하기 위해 다음 3가지 옵션을 사용할 수 있습니다.
AVS에 기본 경로가 광고되지 않으면 VM은 인터넷에 액세스할 수 없습니다. 이 옵션은 AVS 배포 시 인터넷 액세스를 비활성화하는데에도 사용됩니다.
이 옵션은 인바운드 연결, SNAT 및 DNAT 규칙 제어, 연결 로그를 제공할 수 있지만 배포가 더 복잡하고 추가 비용(공용 IP 주소, 방화벽 또는 라우팅 장치 등)이 발생합니다.
NSX-T Edge에 공개된 공용 IP 주소
최근 Azure VMware Solution의 새로운 GA 기능으로 발표된 기능은 NSX-T Edge에 공용 IP 주소를 게시하는 기능입니다(문서 참조). 이는 Azure VMware Solution의 인터넷 연결을 위한 세 번째 옵션이며, 이전 두 가지 옵션 중 가장 뛰어난 기능을 제공합니다.
인바운드 및 아웃바운드 연결
SNAT 및 DNAT 규칙 제어
연결 로그
배포할 추가 구성 요소 없음(Azure Firewall, Azure vWAN, 타사 NVA)
이 외에도 이 새로운 기능을 사용하면 다음 작업도 가능합니다.
AVS 기본 구성 요소만을 기반으로 하는 통합 환경: Azure Resource Manager 및 NSX-T
최대 64개의 공용 IP 수신 가능(소프트 리미트)
필요한 경우 이 할당량은 요청에 따라 최대 1000개의 공용 IP로 할당될 수 있습니다.
DDoS 보안은 인터넷의 네트워크 트래픽을 보호합니다.
공용 인터넷을 통한 HCX 마이그레이션 지원.
가격 고려 사항
이 새로운 기능을 사용하면 AVS 인스턴스에 대해 게시된 공용 IP 주소는 다른 Azure 목적으로 사용되는 IP 주소로 AVS 인스턴스 자체와 별도로 요금이 청구됩니다.
NSX-T Edge에서 공용 IP를 제공하는 새로운 기능이 게시된 이후Azure Portal에서 AVS 인터넷 액세스 옵션을 관리하기 위한 새로운 섹션인인터넷 연결이 제공됩니다.
Azure Portal의 AVS 인터넷 연결 섹션
NSX-T Edge에서 공용 IP로 인터넷에 접속하려면 최소 하나의 공용 IP 블록이 필요합니다. 이름과 할당할 IP 개수를 입력하여 IP 블록을 생성할 수 있습니다.
공개 IP 차단 생성
차단 요청이 제출되면 새로운 인터넷 접속 설정을 저장할 수 있습니다. 차단이 생성되고, 차단이 AVS 배포에 광고되는 동안 백그라운드에서 IP가 할당됩니다.
새로운 인터넷 연결 옵션을 저장합니다
새 구성을 완료하는 데 약 10~15분이 소요될 수 있습니다. AVS 배포 환경에서 인터넷 접속이 이미 활성화된 경우, 재구성 과정에서 다운타임이 예상되며 NSX-T 구성이 필요합니다.
구성이 완료되면 공개 IP 블록 목록에서 새 블록을 사용할 수 있습니다.
현재 AVS 인스턴스에 대해 프로비저닝된 공용 IP 공간 목록
SNAT를 사용하여 아웃바운드 인터넷 액세스 활성화
아웃바운드 인터넷 액세스를 활성화하려면 NSX-T T1 라우터에서 (최소한) SNAT 규칙을 구성해야 합니다.
NSX-T 관리자에 로그인
네트워킹탭 에서NAT섹션에 액세스합니다.
SNAT 규칙을 프로비저닝할 적절한 T1 라우터를 선택하세요.
이름과 프로비저닝된 블록의 IP 주소를 사용하여 아웃바운드 연결에 사용할 새 SNAT 규칙을 만듭니다.
구하다
아웃바운드 인터넷 연결을 활성화하기 위한 NSX-T SNAT 규칙 생성
방화벽 구성
NSX-T의 방화벽 구성에 따라 트래픽 통과를 허용하기 위한 방화벽 규칙을 만들어야 할 수도 있습니다.
인바운드 인터넷 액세스 활성화
DNAT를 통한 인바운드 연결
인바운드 인터넷 액세스는 DNAT 규칙에 따라 공용 IP 주소에서 워크로드(VM 또는 네트워크 서비스)의 내부 IP 주소로 트래픽을 전달할 수 있습니다.
NSX-T 관리자에 로그인
네트워킹탭 에서NAT섹션에 액세스합니다.
DNAT 규칙을 프로비저닝하려면 적절한 T1 라우터를 선택하세요.
프로비저닝된 블록의 이름, 공용 IP 주소 및 트래픽을 전달할 내부 IP 주소를 제공합니다.
구하다
인바운드 인터넷 연결을 활성화하기 위한 NSX-T DNAT 규칙을 만듭니다.
방화벽 구성
NSX-T의 방화벽 구성에 따라 트래픽 통과를 허용하기 위한 방화벽 규칙을 만들어야 할 수도 있습니다.
DNAT 및 포트 리디렉션을 통한 인바운드 연결
DNAT 규칙을 사용하면 트래픽을 다른 포트로 리디렉션할 수도 있습니다. 예를 들어, 포트 80의 공용 IP 주소에서 내부 워크로드의 다른 포트(예: 8000)로 트래픽을 리디렉션할 수 있습니다.
이를 위해 DNAT 규칙을 생성하는 동안 내부 워크로드의 포트와 일치하는 서비스를지정해야 합니다(예에서는 8000).
포트 8000과 일치하는 dev-http 서비스 생성
그런 다음 변환된 포트로 지정하여 공용 IP 주소(예에서는 80)에 노출된 포트를 지정합니다.
포트 리디렉션을 통해 인바운드 인터넷 연결을 활성화하기 위한 NSX-T DNAT 규칙을 만듭니다.
NSX-T 로드 밸런서를 사용한 인바운드 연결
이제 공용 IP 주소가 NSX-T 에지에 직접 연결될 수 있으므로AVS 워크로드에 대한 인바운드 연결을 제공하기 위해 NSX-T부하 분산 장치를 설정할 수 있습니다.
첫 번째 단계는 NSX-T T1 게이트웨이에 연결된 로드 밸런서 서비스를 만들고 크기를 지정하는 것입니다.
로드 밸런서 서비스 생성
두 번째 단계는 로드 밸런서 서비스에 연결된 가상 서버를만들고워크로드의 포트와 IP 주소를 지정하는 것입니다.
가상 서버 생성
그런 다음서버 풀이생성되어가상 서버에 연결됩니다 . 여기에는 로드 밸런서 애플리케이션을 호스팅하는 작업자 목록이 포함됩니다.
서버 풀 생성
마지막으로서버 풀을모니터링하기 위해Active Monitor가생성됩니다 .
활성 모니터 생성
결론
AVS에서 NSX-T 엣지 기능까지새로운 공용 IP 주소를제공함으로써 AVS 워크로드의 인터넷 연결을 관리하는 새로운 기능을 사용할 수 있습니다. 가장 중요한 장점 중 하나는 NSX-T 구성 요소를 활용하여 인바운드 및 아웃바운드 인터넷 연결을 구성하고 보호할 수 있다는 것입니다. 또한 로드 밸런서나 VPN과 같은 NSX-T 서비스에서 공용 IP 주소를 직접 사용할 수도 있습니다.
물론, 이러한 설정은 생각할 수 있는 모든 인터넷 연결 요구 사항을 충족하지는 않지만 새로운 가능성을 제공하며 인터넷에 연결된 애플리케이션을 호스팅하거나 발신 인터넷 연결을 제어하는 데 있어 실제로 고려할 만한 자산입니다.
시나리오: 최근 계약 중에 한 고객이 기존 랜딩 존에 Azure VMware 솔루션을 배포하고 싶어했습니다. 이 LZ는 이미 여러 Azure 구독에 배포된 여러 스포크 환경을 제공하기 위해 배포되었습니다. 우리가 마주친 과제 중 하나는 고객이 기존 허브 앤 스포크 모델을 사용하고 허브 VNET에서 Azure 방화벽을 사용하여 기본적으로 이 방화벽을 활용하여 아웃바운드 통신을 위해 인터넷에 도달하는 것이었습니다.허브에 있는 Azure Firewall을 사용하려면 직면하게 될 과제는 AVS에 대한 기본 경로를 광고하는 것입니다. (0.0.0.0/0). 이 블로그는 이 특정 사용 사례를 다룹니다.
AVS를 배포하는 경우, 이탈/아웃바운드 트래픽을 위한 방화벽을 배포할 수 있는 방법은 여러 가지가 있습니다. 하나는 AVS 내부, 즉 타사 NGFW이거나, 다른 하나는 Azure LZ 외부입니다.
해결책: AVS는 VNET에 호스팅되지 않고 Azure에 자체 네트워킹 구조가 있습니다. 서브넷에 연결할 때처럼 UDR을 연결할 수 없습니다. AVS에는 UDR 개념이 없으므로 인터넷 바운드 트래픽을 Azure Firewall로 강제할 수 없습니다. AVS는 BGP를 통해 모든 경로를 동적으로 학습하므로 이러한 경로를 다른 방식으로 AVS에 푸시해야 합니다.
해결책은 허브 VNET에 Azure Route 서버를 두고 ARS와 BGP 피어링을 할 수 있는 NVA를 배포한 다음 NVA가 Azure Firewall을 가리키는 기본 경로를 푸시하는 것입니다. 이 NVA는 BGP가 가능한 모든 장치가 될 수 있습니다. Cisco, Palo Alto 또는 FortiGate 어플라이언스가 될 수 있습니다. 고객에게 3P NVA 어플라이언스가 없는 경우 Azure의 Linux VM에 오픈 소스 FRR을 배포할 수 있습니다.
타사(3P) NVA 옵션을 살펴보기 전에 AVS와 관련된 여러 네트워킹 시나리오가 문서화된 공식 문서를 공유하고 싶었습니다. 여기에는 Secure Hub를 사용한 vWAN 접근 방식, 기본적으로 Hub의 Azure Firewall이 포함되어 있습니다. 이것을 강조하는 이유는 배포가 그린필드이고 고객이 Azure Firewall로 진행하려는 경우 vWAN을 사용할 수 있고 BGP 피어를 수행하고 기본 경로를 푸시하기 위해 타사(3P) NVA 장치가 필요하지 않기 때문입니다. 이는 쉽게 수행할 수 있습니다.
저는 먼저 ARS에 대해 설명하고 AVS를 계획할 때 허브에 ARS가 필요한 이유에 대해 설명하려고 했습니다.
Hub VNET에 ARS를 배포하는 데는 몇 가지 주요 이유가 있습니다.
AVS를 배포하고 Hub VNET에 연결하려고 할 때 Hub VNET에 Express Route Gateway를 배포하고 AVS Dedicated ExR 회로에 연결합니다. AVS 내부에 있는 모든 네트워크 세그먼트를 Hub와 피어링된 모든 Spoke VNET에 광고하기 위해 ARS는 수동 개입 없이 동적으로 이를 수행합니다.
ARS는 기존 방화벽을 활용할 수 있도록 기본 경로(0.0.0.0/0)를 AVS에 게시하는 데도 도움이 됩니다. 또한, AVS에서 스포크 VNET으로 가는 모든 통신을 NGFW를 통해 전달하려는 경우에도 이를 구현할 수 있습니다.
Azure VPN Gateway를 사용하여 온-프레미스와 Azure 간에 VPN S2S IPSec 터널을 구축한 경우, 온-프레미스 경로를 AVS로 전파하고 AVS에 연결된 ExR Gateway와 VPN Gateway 간의 전송 연결을 활성화하려면 ARS가 필요합니다.
위의 모든 사항을 위해서는 허브 VNET에 Azure Route Server가 필요합니다.
참고: ARS를 배포할 때 배포가 완료될 때까지 잠시 다운타임이 발생하므로 이에 따라 계획하십시오. ARS에는 Active-Active VPN Gateway가 필요합니다. 이 배포 방법이 없는 VPN이 있는 경우 ARS를 배포하기 전에 먼저 Active-Active 모드를 활성화해야 합니다.
Azure 방화벽을 갖춘 AVS
이제 AVS 네트워킹 시나리오를 공유하고 ARS가 필요한 이유를 설명하는 기초 작업이 완료되었으므로 Azure Firewall과 함께 AVS를 살펴보고 실제로 어떻게 작동하는지 자세히 알아보겠습니다.
언급했듯이 AVS에 UDR을 연결하여 인터넷 트래픽이 Azure Firewall을 통과하도록 강제할 수는 없습니다. AVS는 무료인 전용 Express 경로 회로와 함께 배포됩니다. AVS에서 제공하는 ExR 회로에 연결할 수 있는 Express Route 게이트웨이를 만들어야 합니다. 이 작업이 완료되면 HUB VNET에 연결되고 이제 BGP를 통해 Express Route 게이트웨이를 통해 AVS에 경로를 푸시할 수 있습니다. 이 경로는 기본 경로 0.0.0.0/0 또는 다른 경로가 될 수 있습니다.
ARS에 연결하고 기본 경로를 광고하려면 타사 NVA 장치가 필요하며, 그런 다음 AVS에 광고됩니다. 그런 다음 경로는 T0 및 T1 게이트웨이에서 수신됩니다.
Cisco 또는 Fortigate SDWAN과 같은 SD-WAN 장치가 있는 경우 이러한 장치는 ARS와 BGP 피어링을 수행할 수 있습니다. 그러나 3P 장치가 없는 기본 VNET 설계가 있는 경우 두 개의 Linux VM에 FRR과 같은 오픈 소스 NVA를 배포하여 고가용성을 제공할 수 있습니다. FRR이 설치되면 ARS와 BGP 피어링을 수행한 다음 BGP를 통해 AVS에 정적 경로를 게시할 수 있습니다.
이 NVA는 경로를 광고하는 데만 필요하며, NVA는 데이터 경로에 포함되지 않는다는 점을 명심하세요. AVS의 VM은 Express Route 게이트웨이를 통해 방화벽과 직접 통신합니다. 따라서 높은 CPU와 메모리를 가진 VM의 크기를 조정할 필요가 없습니다. AVS에 경로를 광고하는 데만 사용되기 때문입니다.
Azure Route Server는 또한 경로를 학습하고 광고하는 데에만 사용됩니다. 데이터 트래픽 흐름에는 어디에도 나오지 않습니다.
