본 게시글은 아래 Microsoft 공식 문서를 참조하여 작성하였습니다.

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-peering-gateway-transit

네트워크 구성도는 다음과 같습니다.

S2S 구성은 실습 환경의 한계로 제외하였습니다.

Gateway Transit과 관련된 Peering 설정을 보면

Hub-RM에서 Gateway VPN을 통해 외부와 연결되고 있으며,

Hub-RM에서 Peering 설정 시 gateway transit을 통해 외부와 Spoke-RM 및 Spoke-Classic을 연결해주는 역할을 합니다.

만일, gateway transit 설정을 하지 않으면 Spoke VNet과 외부 네트워크와 연결이 되지 않습니다.

* Spoke-RM 및 Spoke-Classic을 Spoke VNet이라고 칭하겠습니다.

* 실습요약

1.Hub-RM과 Spoke-RM간 Peering 설정

2.Hub-RM과 Spoke-Classic간 Peering 설정

3.외부와 Transit Gateway 연결 확인

1.Hub-RM과 Spoke-RM간 Peering 설정

HubRM에서 가상 네트워크 게이트웨이 설정을 선택합니다.

Spoke-RM에서는 Hub-RM의 가상 네트워크 게이트웨이를 사용해야 하므로,

원격 가상 네트워크 게이트웨이 또는 Route Server 사용을 체크합니다.

잠시 후, 피어링이 연결됩니다.

Hub-RM과 Spoke-RM이 성공적으로 연결되었습니다.

Hub-RM의 게이트웨이 전송은 사용되고 있습니다.

Spoke-RM 과 Hub-RM 간 연결이 성공적으로 되었습니다.

Spoke-RM에서 게이트웨이 전송은 사용하지 않습니다.

2.Hub-RM과 Spoke-Classic간 Peering 설정

위의 과정과 마찬가지로 Hub-RM에서는 이 가상 네트워크의 게이트웨이 사용을 선택합니다.

Spoke-Classic에서는 Hub-RM의 가상 네트워크 게이트웨이를 사용해야 하므로,

원격 가상 네트워크 게이트웨이 또는 Route Server 사용을 체크합니다.

Hub-RM과 Spoke-Classic이 성공적으로 연결되었습니다.

Hub-RM의 게이트웨이 전송은 사용되고 있습니다.

Spoke-Classic과 Hub-RM 간 연결이 성공적으로 되었습니다.

Spoke-Classic에서 게이트웨이 전송은 사용하지 않습니다.

3.외부와 Transit Gateway 연결 확인

OtherVNet에 접속하여 VNET간 연결된 Hub-RM을 통해 Spoke VNet으로 ping이 성공적으로 전송되었습니다.

Client PC에서 Azure VPN을 통해 Spoke VNet으로 ping이 성공적으로 전송되었습니다.

* 참고자료

https://docs.microsoft.com/ko-kr/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal

VNet 간

VNet-VNet 연결 구성은 간단하게 VNet을 연결할 수 있는 방법입니다. VNet-VNet 연결 형식(VNet2VNet)을 사용하여 가상 네트워크를 다른 가상 네트워크에 연결하는 것은 온-프레미스 위치에 사이트 간 IPsec 연결을 설정하는 것과 비슷합니다. 두 연결 형식 모두 VPN 게이트웨이를 사용하여 IPsec/IKE를 통한 보안 터널을 제공하며 둘 다 동일한 방식으로 통신합니다. 그러나 로컬 네트워크 게이트웨이를 구성하는 방법이 다릅니다.

VNet-VNet 연결을 설정할 때 로컬 네트워크 게이트웨이 주소 공간이 자동으로 생성되고 채워집니다. 한 VNet의 주소 공간을 업데이트하면 다른 VNet이 자동으로 업데이트된 주소 공간으로 라우팅됩니다. 일반적으로 사이트 간 연결보다는 VNet-VNet 연결이 더 빠르고 쉽습니다.

- 출처 : Microsoft -

* 사전준비

- 네트워크 구성도는 아래와 같이 구성한 상태에서 VNET간 VPN Gateway 설정을 통해 연결해보겠습니다.

* 실습요약

1. Virtual Network Gateway 생성

2. Virtual Network Gateway Connect 생성

1. Virtual Network Gateway 생성

vnet1gw

vnet2gw

각 가상 네트워크에 위와 같이 설정하여 Virtual Network Gateway를 생성합니다.

2. Virtual Network Gateway Connect 생성

'vnet1-to-vnet2' 라는 이름의 Virtual Network Gateway Connect를 위와 같이 생성합니다.

'vnet2-to-vnet1' 라는 이름의 Virtual Network Gateway Connect를 위와 같이 생성합니다.

위와 같이 연결 두 개가 생성되었고 상태가 '연결됨' 으로 바뀌었습니다.

(연결까지 3~5분 소요)

vnet1-vnet2 연결을 보면 가상 네트워크가 연결된 것을 볼 수 있으며,

데이터의 흐름에 따라 입력과 출력값을 확인할 수 있습니다.

vm-test-01 가상머신으로 원격 데스크톱 연결하여 vm-test-02의 사설IP 주소인 10.41.0.4 로 ping을 보냈을 때 정상적으로 연결되는 것을 확인할 수 있습니다.

지금까지 VNET간 VPN Gateway를 통해 간단하게 VNET을 연결해봤습니다!

● BGP (Border Gateway Protocol) 란?

BGP는 소규모 네트워크 망을 위한 프로토콜이 아닌 대규모 네트워크 망에 적합한 라우팅 프로토콜 입니다. 그리고 OSPF, RIB, EIGRP 와 같은 IGP (Inter Gateway Protocol)는 Fast Convergence에 중점을 두지만 BGP는 Fast Convergence가 아닌 안정성에 더 중점을 두고 맞춰서 설계된 라우팅 프로토콜 입니다.

● BGP (Border Gateway Protocol) 특징

• TCP를 이용한 신뢰성 있는 라우팅 업데이트 수행
  - TCP Port 179을 사용하여 Neighbor 사이 신뢰 관계를 맺고, 업데이트가 누락되지 않도록 합니다. 
  
  
• KeepAlive를 이용한 Neighbor 상태 확인
  - KeepAlive를 이용하여 Neighbor의 상태를 확인 합니다. 기본적인 Timer는 Hello TIme 60초, Hold Time 180초 이며 Hold TIme 이내 Hello 메시지가 들어오지 않으면 Neighbor가 죽은 것으로 판단 합니다. 
  
  
• 주기적인 BGP 업데이트 수행
  - iBGP는 5초, eBGP는 30초 간격으로 BGP 업데이트가 수행 됩니다. 라우팅에 변화가 생길 때 마다 업데이트가 발생하게 되면 네트워크 자원소모가 많기 때문에 일정 주기로 업데이트가 수행 됩니다. 업데이트 간격 사이에 발생하는 변화는 반영하지 않고 최종 상태만 업데이트를 수행 합니다. 
  
  
• 최적 경로 선출을 위한 다양한 기준 
  - IGP와 달리 BGP는 최적 경로 선출을 위해 CISCO 기준 11개의 기준이 있으며 해당 값을 비교하여 최적 경로로 선출 된 항목만 라우팅 테이블에 내려 갑니다. 최적 경로로 선출되지 못하더라도 BGP Table에는 존재 합니다.
  
  
• 다양한 경로 속성 (Well-Known속성과 Optional 속성)
  - BGP는 경로 정보 전달 시 다양한 정보를 전달 합니다. 경로 정보에 포함되는 정보는 Well-Known 속성과 Optional 속성이 존재 합니다.  Well-Known 속성은 다시 Mandatory과 Discretionary로 분류 되며 모든 장비에서 지원 합니다. Optional 속성은 전달 가능한 속성 (Transitive Optional Attribute)와 전달 하지 못하는 속성 (Non-Transitive Optional Attribute)로 나뉘며 장비에 따라 지원여부를 확인해 보아야 합니다. 
  
  
• BGP 경로 속성을 이용한 트래픽 조절
  - Local AS에서 외부로 경로를 전송할 때는 다양한 방법(Weight, Local Preference, ETC...)으로 제어가 가능하지만 유입되는 트래픽을 조절 할 수 있는 방법이 AS Path를 추가하는 방법만 존재 합니다. 
  
  
• 인접하지 않아도 BGP Neighbor 관계 수립 가능
  - 다른 라우팅 프로토콜과 달리 BGP는 인접하지 않은 라우터와도 BGP Neighbor 관계를 맺을 수 있습니다. Neighbor를 맺기 위해 사용되는 IP까지 도달할 수 있다면 Neighbor 관계를 맺는데 문제가 없습니다. 
  
  
• 다양한 프로토콜 지원 (MP-BGP)
  - RFC 2858번이 추가 되면서 BGP는 IP 이외 다른 프로토콜들도 지원 할 수 있게 되면서 MP BGP라는 이름으로 얻게 되었습니다. address family identifier (AFI)는 IPv4, IPv6와 관련이 있고, subsequent addressfamily identifier (SAFI)를 이용하여 유니캐스트 또는 멀티캐스트 트래픽 전송이 가능해졌습니다. 
  
  원래 BGP는 IPv4만 수용 가능했기에 BGP Database Table을 하나만 관리 했으나 AFI 와 SAFI 기능이 추가 되면서 BGP Database는 address family와 sub-address family 기준으로 별도로 생성되고 관리 됩니다. 

● BGP (Border Gateway Protocol) Design

BGP를 구성하는 방법은 일반적으로 Single-Homing, Dual-Homing, Multi-Homing 3가지를 소개합니다. 시간이 지나며 용어의 변경이 발생하여 Dual-Homing은 모두 Multi-Homing 방법으로 소개 되고 있으며, Single-Homing 방법은 굳이 BGP를 사용할 필요가 없어 소개 되지 않습니다. 

Redundancy와 Traffic Handling 목적으로 BGP 세션을 추가로 맺습니다. BGP 세션을 맺는 방법에 따라 4가지의 시나리오를 생각할 수 있습니다.

  ○ BGP (Border Gateway Protocol) Multi-Homing Design 종류

● BGP Transit Network 

Transit Netwok란 고객의 네트워크가 SP 네트워크 처럼 동작되어 다른 네트워크 트래픽이 우리 네트워크를 경유해서 전달되는 것을 의미 합니다. 고객은 SP와 eBGP를 연결할 때 Transit Network가 되지 않도록 네트워크 필터링을 설정 해 주어야 합니다. 

회사 BGP 네트워크가 위와 같은 환경으로 구성되어 있을 경우 SP3은 10.64.1.0/24 네트워크 정보를 2가지 경로를 통해 학습 합니다. 하나는 SP1 - SP2 - SP4의 경로를 통해 학습하고 다른 하나는 SP4 - AS500을 통해 학습 합니다. BGP 최적 경로 선출 알고리즘에 의해 AS PATH가 짧은 SP4 - AS500 의 경로가 최적 경로로 선출 되고 고객 네트워크인 AS500이 의도치 않게 Transit Network로 동작 하게 됩니다. 

Transit Network로 동작하지 않도록 하기 위해 SP와 연결하는 라우터는 필터링을 통해서 Transit Network로 동작하지 않도록 해야 합니다. 일반적으로 SP와 연결 할 때 정규식(Regular Expression)을 이용하여 Local AS만 광고하고 SP로 부터는 BGP 정보를 받지 않는 정책을 가장 많이 사용 합니다.

● BGP (Border Gateway Protocol) Types (iBGP & eBGP)

BGP Session 관계를 맺는 AS에 따라 iBGP와 eBGP 2가지 타입으로 분류가 되며 서로 다른 특성을 부여 받게 됩니다. 

• Internal BGP (iBGP)
  - 같은 AS 번호 아래에 있는 라우터와 BGP 관계를 맺거나 같은 BGP Confederation 에 참여하고 라우터와 BGP 관계를 맺을 때 iBGP라고 합니다. iBGP에게 전달 받은 경로의 AD (Administrative Distance)는 200으로 Routing Table에 표기 됩니다. 
• External BGP (eBGP)
  - 다른 AS 번호에 소속 되어 있는 라우터와 BGP 관계를 맺을 때 eBGP라고 합니다. eBGP에게 전달 받은 경로의 AD는 20으로 Routing Table에 표기 됩니다. 

  ○ iBGP

같은 AS내에서 BGP 관계가 필요한 이유는 다양한 라우팅 정책이 필요하거나 AS 번호 사이에서 경로 정보를 전달 할 때 누락되지 않아야 하기 때문입니다. 

AS 65100과 AS 65300 사이에 위치한 "AS 65200"은 BGP로 전달 받은 경로 정보를 누락없이 전달해야 하기 때문에 BGP 관계를 맺어 전달하는 것이 가장 안전 합니다. R2와 R4는 iBGP 관계를 맺어 eBGP로 받은 경로 정보를 안정적으로 전달 할 수 있습니다. 

R3은 BGP Neighbor 관계를 맺고 있지 않기 때문에 외부 AS로 가는 경로를 알지 못합니다. R3이 외부 AS경로를 학습하기 위해서는 BGP 라우터의 재분배를 통해 경로정보를 학습할 수 있지만 유연성이 저해되고, BGP 정책이 누락 되기 때문에 재분배 대신 BGP를  사용하는 것이 일반적 입니다.

다만, iBGP는 학습한 경로를 1 HOP 떨어진 iBGP로만 전달 할 수 있는 제약이 있습니다. (R2가 광고하는 외부 경로 정보는 R3까지 전달되고 R4까지 전달 되지 않습니다.) 이런 제약을 극복하기 위해 iBGP Full-Mesh 구조로 구성하거나 RR (Route Reflector)를 구성하여 사용 합니다.

  ○ eBGP

서로 다른 AS에 속해 있는 라우터간 Neighbor 관계를 맺으면 eBGP가 됩니다. 외부와 연결되는 eBGP는 iBGP와 비교하여 아래와 같은 차이점이 존재 합니다. 

• eBGP의 TIme-To-Live (TTL)값은 1이 기본값 입니다. Multi-Hop eBGP Neighbor 관계를 맺기 위해 TTL값을 늘려줘야 합니다. iBGP의 TTL값은 255 입니다.
• eBGP가 경로를 광고하면 Local AS 번호가 추가 됩니다. eBGP는 수신한 경로 정보에 Local AS 번호가 포함되어 있으면 Routing Loop라고 판단하고 해당 경로정보를 버립니다.
• eBGP Neighbor 관계를 맺을 때는 물리 인터페이스에 부여된 주소를 사용하고 iBGP Neighbor 관계를 맺을 때는 Loopback 인터페이스 주소를 사용하는 것이 일반적 입니다. 

iBGP와 eBGP 구성을 위한 설정의 근간은 remote-as를 제외하고 크게 다르지 않으나, 세부적으로 Neighbor 관계를 맺기 위한 인터페이스 선정, Next-Hop 문제, TTL, AD, iBGP Update Issue 및 기타등등 등이 존재하기 때문에 이 부분을 고려하여 설정 하여야 합니다.

● BGP (Border Gateway Protocol) 최적 경로 선출

BGP 최적 경로 선출기준은 IGP 보다 풍부하며 또한 선출 기준에 따라 우선순위가 있습니다. 또한 최적 경로 선택 알고리즘은 AS로 들어오는 트래픽 또는 나가는 트래픽에 영향을 줍니다.

● BGP (Border Gateway Protocol) 최적 경로 선출 기준

BGP 경로 광고에는 Network Layer Reachability Information (NLRI)와 Path Attributes (PAs)가 포함되어 있습니다. NLRI는 Network Prefix, Network Prefix Length와 AS Path, Origin 같은 정보들로 이루어져 있습니다. BGP Table에는 동일한 목적지에 대해 여러개의 경로가 있으며, 경로에 포함된 속성들이 최적 경로 선출에 영향을 주게 됩니다. 

해당 속성들을 이용하여 BGP는 최적 경로를 선출하게 됩니다. 최적 경로 선출에 사용되는 기준은 총 11가지가 있습니다. 우선순위가 높은 기준이 먼저소개 됩니다. (오름차순)

1. Longest Matching Rule 적용
   - 가장 상세한 경로정보를 우선시 하는 기준으로 최적 경로 선출시 가장 먼저 적용됩니다. 다음과 같이 경로 정보를 수신한다면 192.168.0.0/16 보다 192.168.1.0/24 경로 정보를 우선 시 하게 됩니다. /24보다는 /25 를 더 우선 합니다.
   
   
2. Weight (Cisco Only)
   - Cisco 장비에서만 적용되는 우선순위로 Local BGP 라우터에서 수신한 BGP경로가 다수 있을 때 최적 경로 선출에 사용되는 기준이며, 해당 값은 다른 BGP 라우터에게 전달 되지 않습니다.
   - Weight 값의 범위는 0 부터 65,535 까지이며 Weight 값은 inbound route-map을 통해 설정하거나 특정 Neighbor에게 Weight 값을 설정하여 사용 합니다. 
   
   
3. Local Preference (LOCAL_PREF or LP)
   - Local Preference는 Well-Known Discretionary Path Attribute이며 BGP 업데이트 메시지에 포함되는 속성 입니다. Local Preference는 eBGP에게 전달 되지 않으며 iBGP에서 최적 경로 선출 목적으로 사용 됩니다. 
   - 0부터 4,294,967,295사이의 값을 가질 수 있으며 기본값은 100 입니다. LP 값이 높은 경로가 최적 경로로 선출 됩니다.
   
   
4. Local Originated (Network Statement, Redistribution, Aggregation)
   - 외부 Peer에 의해 BGP 테이블에 삽입된 경로 보다, Locally Router가 Network 명령어를 통해 BGP 테이블에 삽입한 경로를 우선시 합니다. 
   
   
5. AIGP (Accumulated  Interior Gateway Protocol)
   - Accumulated IGP (AIGP) 는 Optional Non-Transitive 경로 속성이며, AS 내부에서만 전달이 되는 값 입니다.IGP의 경로를 BGP에 재분배하고, IGP의 메트릭 값을 이용하여 BGP가 최적 경로 선출에 사용 합니다. AIGP를 BGP Peer에게 전달하기 위해 Route-Map을 사용해야 합니다. 
   
   다수의 BGP AS를 관리하는 환경에서 사용 가능하며, IGP에 사용되는 IP 주소체계가 겹치지 않고 고유해야 하는 제약사항이 있습니다. 일반적인 엔터프라이즈 환경에서 적합하지 않습니다.
   
   
6. Shortest AS Path
   - 목적지로 향하는 다양한 경로가 존재할 경우, 가장 짧은 AS 길이를 가진 경로를 선호 합니다. BGP에서 AS는 HOP Count와 같으며 짧을 수록 우선순위가 높습니다. 해당 규칙을 이용하여 BGP 트래픽 유입을 제어할 수 있습니다. AS Prepending을 사용하여 AS를 추가할 수 있습니다.
   
   
7. Origin Type
   - Well-known mandatory BGP 속성 입니다. Network 명령어를 통해서 광고한 경로는 IGP or i 의 코드를 받고 재분배 네트워크는 imcomplete or ? 코드를 받습니다. IGP를 더 선호 합니다. 
   
   
8. Lowest MED (Multiple-Exit Discriminator)
   - Optional Non-Transitive 속성이며 32 bit 값 (0 to 4,294,967,295)으로 표현하며 메트릭 이라고 부릅니다. BGP에서 네트워크를 광고 또는 재분배 할 때 IGP 경로 메트릭을 자동으로 설정하며 eBGP에게 경로를 학습할 때 MED값을 전달 받지 못한다면 기본값은 0 입니다. 만약 MED를 eBGP에게 수신한다면 다른 iBGP Peer에게 전달 하지만 다시 eBGP에게 전달하진 않습니다. 
   
   MED값을 MED 사용의 목적은 다른 Inbound Traffic을 제어하기 위한 목적으로 사용되며 낮은 MED를 더 선호 합니다.
   
   
9. eBGP Over iBGP
   - BGP 경로를 학습하는 방법은 iBGP, eBPG, Confederation AS에게 받는 3가지 방법이 있으며, 이중에서 eBGP Peer에게 받은 경로를 가장 선호 합니다. eBGP > Confederation AS > iBGP 우선순위를 가집니다. 
   
   
10. Lowest IGP Next-Hop Metric
    - BGP Next-Hop 주소의 IGP 메트릭 값이 가장 낮은 것을 선호 합니다. 낮은 것을 선호하는 이유는 Next Hop의 IGP Metric값이 낮으면 Next-Hop까지 더 빨리 도달하기 때문 입니다. 
11. Oldest Path Prefer eBGP 
    - 상기 조건까지 모두 동일하다면 BGP 테이블에 먼저 학습된 경로를 선호 합니다. 가장 오래된 eBGP 경로이기 때문에 더 안정적이라 판단 합니다. 
    
    
12. Lowest BGP Router ID
    - 가장 낮은 Router ID를 가진 eBGP 라우터를 더 선호합니다. 만약 경로를 Route Reflextor로 부터 받았다면 Router ID 대신 Originator ID를 사용 합니다. 
    
    
13. Minium Cluster list Length
    - The cluster list 는 non-transitive BGP 속성이며 최소 Cluster List 길이를 더 선호 합니다. Route Reflector가 Cluster ID를 Cluster List에 추가하며 Route Reflector는 해당 정보를 이용하여 Routing Loop가 발생하지 않도록 합니다. 
    
    
14. Lowest Neighbor Address
    - BGP Peer가 2개의 물리적인 링크를 통해 Neighbor 관계를 맺을 경우 가장 낮은 Neighbor 주소를 가진 경로를 더 선호 합니다. iBGP Peer 한정으로 적용되는 규칙으로 Neighbor 주소가 가장 낮은 것을 선호 합니다. (eBGP이 경우 오래된 경로를 우선 한다는 규칙이 있어 여기에는 해당 하지 않습니다.)

Azure Migrate Server Assessment를 사용한 Azure VMware 솔루션(AVS) 마이그레이션 및 용량 계획

https://www.youtube.com/watch?v=NoNG-hkksrA&ab_channel=HusamHilal

이 비디오에서는 Azure Migrate Server Assessment를 사용하여 Azure VMware Solution(AVS)에 대한 마이그레이션 및 용량 계획을 수행하는 단계를 안내합니다. 비디오 콘텐츠:
 00:00​ - 소개
 00:59​ - Azure Migrate Assessment 상위 수준 단계 
 02:37​ - 데모: Azure Migrate 프로젝트 만들기
 03:51​ - 데모: 온프레미스 VM 검색
 09:50​ - 데모: Azure Migrate Assessment 만들기
 11:53 - 데모: Azure Migrate Assessment 검토

평가 개요(Azure VMware 솔루션으로 마이그레이션)

https://docs.microsoft.com/en-us/azur...

일반적으로 사용 가능: Azure Migrate를 사용하여 Azure VMware 솔루션으로의 마이그레이션 계획 https://azure.microsoft.com/en-us/upd...

Azure VMware 솔루션(AVS) 평가 만들기

https://docs.microsoft.com/en-us/azur...

RVTools

https://www.robware.net/rvtools/

Azure 가격 계산기(Azure VMware 솔루션 검색)

https://azure.microsoft.com/en-us/pri...

Azure VMware 솔루션(AVS)과 Azure Application Gateway 통합

https://www.youtube.com/watch?v=BoQYvqzb6Y8&ab_channel=HusamHilal

이 비디오에서는 Azure Application Gateway를 Azure VMware Solution과 통합하는 사용 사례를 설명합니다. Azure Application Gateway는 Azure VMware Solution 내의 ESXi 호스트에서 호스팅되는 애플리케이션 및 워크로드에 대한 웹 트래픽 부하 분산 장치로 작동할 수 있습니다. 비디오 콘텐츠:
 0:00 - 소개
 0:52 - AVS의 부하 분산 장치 옵션
 1:40 - Azure App Gateway 구성 요소 및 트래픽 흐름
 3:11 - 데모: Azure Application Gateway 만들기
 7:05 - 데모: 예상 기능 테스트

이 비디오에서는 Azure VMware Solution(AVS) Private Cloud에 대한 vCenter CloudAdmin 및 NSX-T Admin의 비밀번호를 순환하기 위한 Azure Logic App 워크플로를 만드는 단계를 안내합니다. Azure Logic Apps는 최근에 릴리스된 리소스 작업 rotateVcenterPassword, rotateNSXTPassword를 호출하여 비밀번호를 재설정합니다. 또한 listAdminCredentials 리소스 작업은 검증 목적으로 실제 비밀번호 값을 검색하는 데 사용되었습니다

https://www.youtube.com/watch?v=cK1qY3knj88&ab_channel=HusamHilal

 00:00 - 소개 및 브리핑
 02:20 - 데모
 02:25 - Azure Logic App에 Azure 관리 ID 사용
 03:00 - Azure Logic App 시스템에 할당된 관리 ID에 권한 할당
 04:10 - Azure Logic App 워크플로 설계 및 빌드
 09:05 - 기존 vCenter CloudAdmin 및 NSX-T Manager 관리자 암호 가져오기
 10:00 - 워크플로 테스트 및 트리거
 11:19 - 새 암호의 값을 이전 값과 비교(확인)
 11:55 - 감사합니다