깡민쓰~IT Story

사용 사례

온프레미스 환경은 ExpressRoute를 통해 Azure에 연결되며, AVS와 온프레미스 환경 간의 통신을 설정해야 합니다. 이를 위해 권장되는 (그리고 가장 간단한) 방법은 ExpressRoute GlobalReach를 사용하는 것입니다. 

일반 정보

• ExpressRoute GlobalReach 연결은 프라이빗 클라우드 비용에 포함되어 있습니다.
• 온프레미스 위치가 여러 개이고 ExpressRoute를 통해 연결되어 있는 경우 여러 개의 Global Reach 연결을 설정할 수 있습니다. 
• 이 그래픽은 온프레미스와 AVS ExpressRoutes가 모두 동일한 ExpressRoute 게이트웨이에 연결되는 것을 보여 주지만, 이는 필수 사항은 아닙니다. 
• 이 연결이 설정되면 AVS는 온프레미스에서 광고되는 모든 경로를 학습하고 온프레미스에서는 AVS에 속한 모든 네트워크를 학습합니다.
• 아래에 설명된 수동 단계를 수행하는 대신 자동화된 배포 옵션이 있습니다.
  • 팔
  • AzureCLI
  • 이두근
  • 테라폼

구현 및 구성

1. 온프레미스에서 들어오는 ExpressRoute 회로로 이동합니다. "권한 부여"를 선택하고 이름을 입력한 후 "저장"을 클릭합니다. 참고: "From-<PrivateCloud>"와 같은 이름을 입력하세요. 
   
   여기서는 온프레미스 ExpressRoute에서 권한 부여 키가 생성되며, 이 키는 AVS 포털에서 ExpressRoute Global Reach 회로에 연결하는 데 사용됩니다.

1. 이제 다음과 같은 화면이 나타납니다. 리소스 ID와 인증 키를 복사하세요. 이 정보는 이후 단계에서 필요합니다.

1. AVS 프라이빗 클라우드로 이동하여 '연결'을 선택하세요. 그런 다음 'ExpressRoute Global Reach' 탭을 선택하고 '추가'를 누르세요.

1. 맨 위 항목(X 표시가 있는 항목)은 무시하세요. 아래 두 필드에는 2단계에서 생성한 리소스 ID와 인증 키를 입력하세요.

1. 이제 상태가 "연결됨"으로 표시됩니다. AVS 프라이빗 클라우드와 온프레미스 환경이 이제 연결되었을 것입니다.

1. Azure VMware Solution 프라이빗 클라우드로 이동하여 ID를 선택하세요. vCenter URL, vCenter 사용자 이름, vCenter 비밀번호가 표시됩니다. 
   
   방금 연결한 온프레미스 환경에서 vCenter에 액세스해 보세요.
   
   참고: 온프레미스에서 Azure로의 통신을 보호하는 방화벽이 있는 경우 vCenter IP 주소에 443번 포트가 열려 있는지 확인해야 합니다.

제 경험상 VMware HCX 설정 시 가장 큰 지연은 적절한 방화벽 포트가 열려 있지 않은 것입니다. Gabe Rosas는 자신의 사이트 에서 HCX 크로스 사이트 포트 요구 사항에 대한 훌륭한 다이어그램을 제공하며, 전반적으로 훌륭한 사이트이므로 꼭 확인해 보세요.

HCX 내에는 많은 포트가 있지만 일반적으로 기업 환경에서 차단되는 유일한 포트는 온프레미스와 클라우드 간의 포트입니다.

이 스크립트는 세 가지 간단한 입력 매개변수(AVS Private Cloud 이름, Azure 구독 및 AVS Private Cloud 리소스 그룹)를 사용하며, 이러한 매개변수를 사용하여 HCX가 작동하는 데 필요한 Azure VMware Solution Private Cloud의 HCX 어플라이언스와 인터넷 위치가 적절한 포트를 통해 액세스 가능한지 확인할 수 있습니다.

1단계

여기에서 스크립트를 다운로드하세요.

https://raw.githubusercontent.com/Trevor-Davis/Azure-VMware-Solution/master/HCX-온-프레미스-설정/avshcxportcheck.ps1

2단계

스크립트를 편집하고 변수를 변경합니다.

$global:sub – AVS Private Cloud가 배포되는 구독입니다.
$global:pcname – AVS Private Cloud의 이름입니다.
$global:pcrg – AVS Private Cloud가 배포되는 리소스 그룹입니다.

이러한 모든 변수는 AVS Private Cloud의 개요 블레이드에 있는 Azure Portal에서 찾을 수 있습니다.

3단계

여기서는 HCX가 온프레미스에 어떻게 배포되는지에 대해 조금 이해해야 합니다.

일반적으로 HCX에는 세 가지 구성 요소가 있습니다(HCX-NE-I 어플라이언스를 배포하지 않았을 수도 있음). 이러한 구성 요소는 모두 온프레미스의 동일한 포트 그룹에 있을 수도 있고, 모두 다른 포트 그룹에 있을 수도 있습니다.

온프레미스 vCenter에 로그인하여 HCX 어플라이언스를 찾으세요. 아래 그래픽과 비슷해야 합니다.

HCX-Manager, IX 및 NE 어플라이언스가 배포된 포트 그룹을 ID로 지정합니다.

4단계

이제 각 포트 그룹의 VM에서 스크립트를 실행하면 모든 것이 성공하면 다음과 같은 출력이 표시됩니다.

실패하면 이와 비슷하게 표시됩니다.

Azure VMware Solution이 발전함에 따라 Azure Portal과의 통합이 더욱 강화되고 있습니다. 이는 "기존 방식"으로 작업을 수행할 수 없다는 것을 의미하지는 않지만, 일반적으로 더 간소화된 대안을 제공합니다. DHCP가 그 중 하나입니다.

Azure VMware Solution 사용자가 DHCP 서버를 통해 일부 또는 모든 vSphere 워크로드에 IP 주소를 제공하려는 경우, NSX-T가 DHCP 서버 역할을 하거나 DHCP 서버에 릴레이하도록 구성해야 합니다. AVS 위에 Horizon을 구축하는 사용자에게는 이 기능이 필수적입니다.

DHCP 서버(NSX-T가 아님)로 릴레이하는 것이 선택 사항인 경우, 해당 DHCP 서버가 위치할 수 있는 몇몇 장소는 온프레미스, Azure vNet 또는 프라이빗 클라우드입니다.

DHCP 서버 위치를 어느 곳으로 선택하든 릴레이 설정 과정은 동일합니다. 하지만 환경 상태에 따라 구성 단계가 달라집니다.

각 시나리오와 구성 단계를 살펴보기 전에, 전체적인 내용을 살펴보겠습니다. DHCP 서버의 IP 주소는  192.168.1.99 이며 VirtualWorkloads-Mgmt  세그먼트에 있습니다  .

아래에 두 가지 시나리오와 구성 단계가 간략하게 설명되어 있습니다. 시나리오 1은 새로운 세그먼트와 DHCP 릴레이를 생성하는 것이고, 시나리오 2는 세그먼트가 이미 있는 환경에 릴레이를 할당하는 것입니다.

시나리오 1

아직 DHCP 릴레이가 필요한 세그먼트가 생성되지 않았으므로 이제 세그먼트를 생성합니다.

먼저 , DHCP 릴레이를 생성합니다.

1. Azure Portal에서 DHCP를 선택하세요
2. 추가를 눌러 DHCP 릴레이를 추가하세요.
3. DHCP 릴레이 선택
4. DHCP-Relay의 친근한 이름을 입력하세요.
5. DHCP 서버의 IP를 입력한 다음 확인을 누릅니다.

둘째 , 세그먼트를 만듭니다. Azure Portal에서 세그먼트를 선택합니다.

1. 세그먼트 선택
2. 추가를 눌러 세그먼트를 추가하세요.
3. 세그먼트의 이름을 입력하세요(친숙한 이름).
4. 세그먼트의 게이트웨이 IP 주소를 입력하세요.
5. DHCP 범위를 정의하세요.
   이 부분은 약간 헷갈립니다. DHCP 범위가 DHCP 서버에 있지만, Azure Portal에서 자동으로 구성해 주는 NSX-T의 세그먼트에는 범위가 구성되어 있어야 합니다. 제가 가정하는 것은 세그먼트 구성에 범위가 없으면 세그먼트가 DHCP 릴레이를 트리거하지 않는다는 것입니다. 참고로, DHCP 서버의 범위와 같을 필요는 없습니다.

AVS vCenter Server의 이 세그먼트에 VM이 추가되면 해당 IP는 이전 단계에서 정의한 DHCP 서버에서 가져옵니다.

시나리오 2

DHCP 릴레이가 필요한 세그먼트는 이미 생성되었으며, 생성 시점에는 DHCP 릴레이에 대해 구성된 세그먼트가 없습니다.

먼저 , DHCP 릴레이를 생성합니다.

1. Azure Portal에서 DHCP를 선택하세요
2. 추가를 눌러 DHCP 릴레이를 추가하세요.
3. DHCP 릴레이 선택
4. DHCP-Relay의 친근한 이름을 입력하세요.
5. DHCP 서버의 IP를 입력한 다음 확인을 누릅니다.

둘째 , NSX-T Manager에서 세그먼트에 DHCP 범위를 할당합니다.

1. NSX-T Manager에 로그인하고 네트워킹을 선택합니다.
2. 세그먼트 선택
3. 생략 부호를 선택하고 편집 옵션을 선택하세요.
4. 서브넷을 선택하세요.
5. 생략 부호를 선택하고 편집 옵션을 선택하세요.
6. DHCP 범위를 정의하세요.
   이 부분은 약간 헷갈립니다. DHCP 범위가 DHCP 서버에 있지만, Azure Portal에서 자동으로 구성해 주는 NSX-T의 세그먼트에는 범위가 구성되어 있어야 합니다. 제가 가정하는 것은 세그먼트 구성에 범위가 없으면 세그먼트가 DHCP 릴레이를 트리거하지 않는다는 것입니다. 참고로, DHCP 서버의 범위와 같을 필요는 없습니다.
7. 추가를 누르세요
8. 적용을 누르세요
9. 저장을 누르세요

도전

Azure VMware Solution에서 VMware 워크로드를 실행한다고 해서 백업이 필요 없는 것은 아닙니다. 한 가지 방법은 기존 온프레미스 솔루션을 사용하여 Azure VMware Solution에서 온프레미스로 VM을 백업하는 것입니다. 하지만 여러 가지 이유로 이 방법은 이상적인 솔루션이 아니며, 특히 워크로드와의 근접성과 비용 측면에서 바람직하지 않습니다.

해결책

Azure의 vSphere에서 실행되는 VM의 주요 이점 중 하나는 Azure 서비스와의 근접성 및 통합입니다. Microsoft는 AVS 워크로드에 백업이 매우 중요하다는 점을 인지하고 Azure VMware Solution을 Azure Backup과 통합했습니다.

높은 수준의 아키텍처, 설치 및 몇 가지 주요 기능을 살펴보겠습니다.

건축학

자세한 내용은 아니지만, 이 그림이 대략적인 개요를 제공하는 데 도움이 되기를 바랍니다. Microsoft Azure Backup Server(MABS)는 AVS의 vCenter Server와 통합됩니다. VM 백업은 MABS에 기록되고, Microsoft Azure Backup Server는 Azure Recovery Services Vault와 통합되어 백업의 복구 지점을 저장합니다(자세한 내용은 나중에 설명).

Azure Recovery Services Vault를 사용하면 저렴한 Azure 저장소에 백업을 저장하여 장기간 보존하고 복구할 수 있습니다.

설치

AVS를 배포한 후 다음 단계를 수행하면 AVS에서 실행되는 vSphere VM에 대해 Azure Backup이 활성화됩니다.

1. Microsoft Azure Backup Server(MABS)를 배포하는 데 사용되는 Windows VM을 빌드합니다.
2. Azure Recovery Services 자격 증명 모음을 만듭니다.
3. Microsoft Azure Backup Server를 설치합니다.
4. AVS의 vCenter에 MABS를 연결합니다.
5. Azure Backup에 vSphere VM을 구성하고 보호하세요.

Azure Backup 및 AVS를 설치하고 운영하는 방법에 대한 자세한 가이드는 https://docs.microsoft.com/en-us/azure/azure-vmware/set-up-mabs-for-avs 에서 확인하세요 .

주요 특징

에이전트 없는 백업 : vSphere 기반 VM을 백업하기 위해 Azure Backup에는   vCenter, vSphere 호스트 또는 vSphere VM에 에이전트를 설치할 필요가 없습니다 .

클라우드 통합 백업 : Azure Backup Server는 단기 저장을 위해 데이터를 디스크에 백업합니다. 또한, 단기 및 장기 백업 모두 Azure Backup Server는 워크로드를 저렴한 Azure 저장소로 보호합니다. 아래 그림에서 Microsoft Azure Backup Server는 Azure Recovery Services Vault에 연결되어 있습니다.  "FileServerOnAVS" 라는 이름의 VM  은 백업 서버의 보호 그룹의 일부로 표시되며, 저렴한 Azure 저장소로 지원되는 Recovery Services Vault에 속합니다.

VM 감지 및 보호 : AVS의 vSphere 클러스터에 생성된 새 VM을 자동으로 감지하고 보호 정책을 적용할 수 있습니다.

파일 또는 전체 VM 복구 : Azure Backup Server는 전체 VM을 복구하지 않고도 Windows VM에서 파일/폴더를 복구할 수 있으며, 필요한 경우 전체 VM을 복구할 수도 있습니다. 아래 그림에서  "FileServerOnAVS" 백업을  통해 세분화된 파일 복구 또는 전체 VM 복구가 가능하다는 것을 확인할 수 있습니다.

보호 그룹을 쉽게 생성 : vCenter 및 AVS와의 긴밀한 통합 덕분에 보호 그룹을 생성할 때 VM을 세부적으로 선택하거나 폴더와 같이 더 큰 그룹별로 선택할 수 있습니다.

자세히 알아보기

이 글이 Azure Backup과 Azure VMware Solution 통합에 대한 완벽한 리뷰는 아니지만, Azure 기반 vSphere 클러스터에 어떤 가치를 제공할 수 있는지 확인해 보시기 바랍니다.   자세한 내용은 이 링크를 참조하세요.

이전한 후, 전환 단계에서 vMotion을 호출합니다. 

이 유형의 마이그레이션은 비즈니스에 중요한 대규모 가상 머신에 가장 적합합니다. RAV를 사용하면 페타바이트 규모의 데이터를 온라인으로 이전할 수 있습니다.

RAV는 vSphere Replication을 활용하여 초기 (대부분) 디스크 이동을 수행하므로 더 높은 병렬 처리(수백 개에서 수천 개의 VM/디스크)를 구현할 수 있으며, 따라서 마이그레이션 횟수를 줄일 수 있습니다. 또한 RAV 마이그레이션은 마이그레이션 재개 및 일시 중지 기능을 제공합니다.

참고: RAV는 HCX Enterprise 기능이며, 소스와 클라우드 사이트 모두에서 Enterprise 키를 통해 HCX가 활성화된 경우에만 사용할 수 있습니다.

RAV 워크플로

아래 다이어그램은 RAV 작업의 높은 수준의 워크플로를 보여줍니다.

                                                                           그래픽은 vmware.com에서 제공되었습니다.

RAV 사용 사례

• 빠른 라이브 전환을 통한 대량 마이그레이션.
• 예약된 라이브 전환을 통한 대량 마이그레이션.
• DR 보호 VM에 대한 라이브 전환 일정을 예약합니다.
• 빠른 라이브 전환 DR 보호 VM.
• 계획된 데이터 센터 대피에 사용할 수 있습니다.

참고: RAV와 관련된 몇 가지 주의 사항이 있습니다. 이러한 내용은 HCX 공식 문서 에 자세히 설명되어 있습니다 . 따라서 RAV 마이그레이션을 사용하기 전에 마이그레이션 계획을 신중하게 세우시기 바랍니다.  

이제 RAV 마이그레이션에 대한 배경 지식을 갖추었으니 실험실로 들어가 실제로 작동하는 모습을 살펴보겠습니다.

온프레미스 vSphere Client에 로그인하고 기본 메뉴에서 HCX 컨텍스트로 전환한 다음 마이그레이션 페이지로 이동하여 마이그레이션을 클릭하여 마이그레이션 구성을 시작합니다.

마이그레이션할 VM을 선택하고 추가를 클릭합니다.

또한 그룹 이름을 제공합니다(이것은 모빌리티 그룹이라고 하는 새로운 HCX 기능이며 다음 게시물에서 이에 대해 설명하겠습니다)

참고: 내 랩에서 선택한 VM은 네트워크 확장 기능을 사용하여 HCX 클라우드 사이트로 확장된 네트워크에 배치되었습니다 .  

마이그레이션 프로필 드롭다운 메뉴에서 수행할 마이그레이션 유형을 선택하세요.  여기서는 RAV 마이그레이션을 시연해 보겠습니다.

선택한 VM에 대한 전송 및 배치 옵션도 선택합니다.

선택한 VM에 대한 네트워크 매핑이 구성되었는지 확인한 다음, 검증을 클릭하여 VM이 클라우드 사이트로 성공적으로 마이그레이션될 수 있는지 확인하세요.

검증이 통과되면 [이동] 버튼을 클릭하여 즉시 마이그레이션을 시작할 수도 있고, 나중에 마이그레이션을 시작할 수 있도록 이 프로필을 저장할 수도 있습니다.

VM 크기에 따라 마이그레이션에 시간이 다소 걸릴 수 있습니다. 마이그레이션하는 VM에 대한 전환을 예약할 수 있는 옵션이 있습니다. 전환 기간을 지정하지 않으면 VM의 초기 동기화가 완료되는 즉시 전환이 수행됩니다. 

참고: 어떤 이유로든 RAV 마이그레이션이 실패한 경우, 원본 사이트와 대상 사이트 모두에서 정리 마이그레이션을 강제 실행하는 옵션이 있습니다. 또한, 어떤 이유로든 실행 중인 마이그레이션을 중단할 수도 있습니다.

RAV 마이그레이션 문제 해결 팁

실패한 RAV 마이그레이션을 디버깅하거나 문제를 해결하는 경우 HCX 관리자 어플라이언스의 app.log 파일을 참조할 수 있습니다. 이 로그 파일은 /common/logs/admin 폴더 에 있습니다 . RAV 관련 로그 메시지를 보여주는 다양한 키워드는 다음과 같습니다.

• 복제 전송 서비스_서비스 스레드
• RAVService_SvcThread
• VmotionService_SvcThread

RAV가 vMotion을 호출한 단계와 관련된 로그는 UI에 있는 RAV 마이그레이션에 대한 ID를 사용하여 VC, ESXi, IX에서 볼 수 있습니다.

마무리: 기존 HCX 인스턴스의 라이선스 키를 고급에서 엔터프라이즈로 업그레이드하는 경우 HCX Enterprise 키로 잠금 해제된 기능(RAV, SRM 통합, OSAM 등)을 포함하도록 기존 서비스 메시와 컴퓨팅 프로필 등을 편집해야 합니다.

이 글은 여기까지입니다.  

얼마 전 HCX용으로 제작했던 네트워크 포트 다이어그램을 공유합니다. 이 다이어그램들은 ports.vmware.com에 있는 HCX 흐름 데이터를 시각화한 것일 뿐입니다 . 그 이상도 그 이하도 아닙니다.

1. HCX 네트워크 포트 – 소스 환경(개시자 사이트)

2. HCX 네트워크 포트 – 대상 환경(수신 사이트)

3. HCX 네트워크 포트 – vCD 기반 대상 사이트

4. HCX 네트워크 포트 - 소스 및 대상 표시

5. HCX 네트워크 포트 – OSAM 배포 시 소스 및 목적지

최근 한 고객으로부터 이전에 사용해 본 적이 없는 기능을 사용해 달라는 요청을 받았습니다. 해당 고객은 현재 네트워크 내 특정 사이트에 대한 사용자 액세스를 방지하기 위해 NSX-t 온프레미스의 ID 방화벽을 사용하고 있었습니다. Azure VMware Solution(AVS)은 관리형 서비스이므로 NSX에서 작동하는 몇 가지 기능이 AVS 기반 NSX에서는 지원되지 않습니다. 이는 여러 가지 이유가 있을 수 있지만, 대개 서비스 자동화가 중단되거나 대규모로 제공하기 어렵기 때문입니다. (IDS/IPS와 같은 일부 기능은 단순히 구현만 하면 되며 로드맵 우선순위가 높은 항목입니다.) 그렇다면 이 기능이 AVS에서 작동할까요? 함께 확인해 볼까요!

업데이트: 이 블로그 게시물이 게시된 이후 두 가지 유의해야 할 사항이 있습니다. 이 기능은 추가 라이선스가 필요합니다. 이는 IDS/IPS 기능에도 해당되며 Azure에서는 비공개 미리 보기로 제공됩니다!

ID 분산 방화벽이란 무엇인가요?

VMware의 가장 큰 이점 중 하나는 20년 이상 구축, 인수 및 통합하는 데 걸린 생태계입니다.모든 VMware 도구가 완벽하게 작동한다고 말하지는 않겠습니다.그러나 생태계 전체가 고객의 중요한 과제를 해결한다고 말할 수 있습니다.이에 대한 좋은 예는 Identity Firewall입니다.이 기능을 통해 사용자는 Active Directory 인프라를 사용하여 사용자 및 그룹에 대한 정보를 NSX로 전달할 수 있습니다.NSX에서 해당 정보를 사용하여 특정 컴퓨터 대신 사용자 및 그룹을 중심으로 보안 그룹을 만들 수 있습니다.이는 VDI(가상 데스크톱 인프라)와 같은 것을 살펴볼 때 필요합니다.VDI는 동적일 수 있으므로 영구적이지 않은 컴퓨터에 방화벽 규칙을 적용하기 어려울 수 있습니다.조직의 여러 부서에서 여러 사용자가 단일 컴퓨터에 로그인하는 경우 불가능할 수 있습니다.그러나 Active Directory의 데이터를 사용하면 이제 사용자에게 보안 그룹을 적용하여 환경의 다른 인프라로의 트래픽을 차단하거나 허용할 수 있습니다.

그렇다면 이 기능은 어떻게 작동하고 어떻게 구성해야 할까요? 먼저 이 기능의 작동 방식을 개략적으로 보여주는 다이어그램을 살펴보겠습니다.

개념은 매우 간단합니다. Active Directory 자격 증명을 사용하여 네트워크의 특정 애플리케이션에 대한 액세스를 활성화하거나 차단합니다. 즉, 인사팀의 Toby가 시스템에 로그인하면 Toby는 인사 도구에만 액세스할 수 있고 재무 도구에는 액세스할 수 없습니다.

구성

시작하기 위해 랩 환경에서 시연하겠습니다. 피자를 주문하는 데 사용되는 웹 서버가 있지만, 인사부에서 이 웹 서버에 접근하는 것을 차단하려고 합니다. 이 잔혹하고 불합리한 처벌은 CEO에게서 내려진 것입니다. 외로운 IT 관리자로서 저는 질문하지 않고, 그저 설정만 하겠습니다. 먼저 NSX-t의 "ID 방화벽" 섹션에서 Active Directory를 구성해야 합니다. 이 설정은 시스템->ID 방화벽 AD에서 찾을 수 있습니다. "Active Directory 추가"를 클릭합니다. AD 시스템 정보를 입력합니다. 간단한 팁: "기본 이름" 섹션에서는 마침표로 구분된 도메인을 사용합니다. 따라서 제 예에서는 도메인이 webblab.lab이므로 DC=webblab,DC=lab으로 구성합니다.

첫 번째 화면을 작성한 후 "LDAP 서버"를 클릭하고 LDAP 서버를 설정하세요. "연결 테스트"를 클릭하여 LDAP에 접속 가능한지 확인할 수 있습니다. 완료되면 "저장"을 클릭하세요.

이제 기본 설정을 마쳤으니 Active Directory의 사용자를 사용하여 분산 방화벽 규칙을 만들 차례입니다. 먼저, 방화벽 정책을 구축할 사용자로 그룹을 만들어 보겠습니다. 인벤토리 -> 그룹으로 이동하여 "그룹 추가"를 클릭하고 그룹 이름을 지정한 다음 "구성원 설정"을 선택합니다. 이 화면에서 적용할 그룹을 선택합니다. 예를 들어, 인사팀의 Toby를 찾고 있습니다. Toby는 인사팀에 있으므로 인사팀 그룹을 선택합니다. "적용"을 클릭합니다. 이제 피자 웹사이트에 대해서도 같은 단계를 반복합니다. 여기서는 웹사이트를 실행하는 VM의 이름을 기반으로 그룹을 생성합니다. 완성된 그룹의 예는 아래와 같습니다. "Webb-AD-HR" 및 "Webb-Pizza"

내 HR 그룹 "멤버 선택" 화면을 자세히 살펴보겠습니다.

이제 그룹이 구성되었으니 정책을 적용할 수 있습니다. 이 예시에서는 정책이 간단합니다. HR 그룹에서 피자 웹 서버로 향하는 모든 트래픽을 차단하는 정책을 만들겠습니다.

IDFW로 보호하려는 VM에서 게스트 인트로스펙션이 활성화되어 있는지 확인해야 합니다. 게스트 인트로스펙션이 설치되어 있는지 확인하려면 VMware Tools가 설치된 VM 또는 골드 이미지로 이동해야 합니다.

이제 설치를 수정하고 인트로스펙션이 선택되었는지 확인하세요. 선택되지 않은 경우 기능을 추가하세요.

이제 구성을 적용했으니 제대로 작동하는지 확인해 보겠습니다! VMware 원격 콘솔을 통해 로그인할 Windows 10 가상 머신이 있습니다. 일반적으로 사용자는 다른 방법으로 로그인하지만, 이 방법을 통해 규칙이 제대로 작동하는지 빠르게 확인할 수 있습니다. Toby로 로그인한 상태에서는 웹 서버에 접속할 수 없습니다.

관리자로 로그인하면 웹 서버에 접속할 수 있습니다.

마무리!

NSX-t는 Azure VMware Solution 고객에게 여러 보안 기능을 제공합니다. 가장 좋은 점은 NSX-t가 포함되어 있고 초기 구성이 모두 자동으로 이루어진다는 것입니다. 이는 NSX-t를 고려했지만 여러 가지 이유로 보류했던 고객에게 큰 가치를 제공합니다. NSX의 Identity Firewall은 VDI 인프라를 보호하기 위해 더욱 강력한 제어 기능을 제공합니다!

**업데이트 참고: 일부 정보가 최신이 아닌 일부 항목이 변경되었습니다. 스토리지 정책을 업데이트하는 간단한 통합 방법은 여기 와 여기의 Microsoft 문서를 참고하시기 바랍니다 . 다음 게시물도 관련성이 있습니다. vCenter API의 기본 사항과 사용 방법을 다루므로, 이 부분은 그대로 두기로 했습니다!**

Azure VMware Solution(AVS)은 Azure에서 가장 빠르게 성장하고 흥미로운 제품 중 하나입니다(네, 저도 약간 편파적일 수 있다는 것을 알고 있습니다). 많은 고객이 기존 지식과 교육을 Azure로 가져와 다양한 새로운 기능에 액세스하는 데 가치를 두고 있습니다. 게다가 AVS는 관리형 서비스이므로 IT 리소스를 비즈니스에 집중하고 혁신을 추진할 수 있습니다. 하지만 관리형 서비스에는 변화가 따릅니다. vCenter에서 제공되는 액세스 수준은 온프레미스 데이터 센터 vCenter와 다릅니다. 따라서 오늘은 "cloudadmin" 역할, 특히 vSAN 관리와 관련된 역할의 작동 방식에 대해 알아보겠습니다.

Azure VMware 솔루션의 vSAN

Azure VMware Solution은 Azure 클라우드의 VMware 기반 소프트웨어 정의 데이터센터입니다. vSphere, vCenter, vSAN, NSX-t, HCX를 기반으로 합니다. vSAN은 VM 데이터를 저장하는 기본 데이터 저장소입니다. vSAN은 클러스터의 각 호스트에 로컬 드라이브를 사용하고 데이터를 분산하여 엔터프라이즈급 스토리지 성능과 가용성을 제공하는 하이퍼 컨버지드 인프라(Hyper-Converged Infrastructure) 모델입니다. vSAN의 가장 큰 장점 중 하나는 스토리지 관리를 간소화한다는 것입니다. vSAN은 스토리지 기반 정책 관리(SPBM)를 통해 이를 수행합니다. 

이 게시물은 SPBM과 그 기능에 대한 심층적인 검토가 아닙니다. 더 자세한 내용을 원하시면 훌륭한 기술 마케팅 자료인 core.vmware.com 에서 검토 하거나 용량 관리에 대한 제 블로그 게시물(여기)을 참조 하세요 .   관리형 서비스 제공 방식은 변경될 수 있다는 점을 명심하세요.   대부분의 문서는 온프레미스 솔루션처럼 취급한다고 가정합니다. vSAN에 대해 알아볼 때 고려해야 할 몇 가지 주요 차이점을 살펴보겠습니다. 

• 동적 프로비저닝: 필요한 호스트 수를 고려할 때 일반적으로 재구축을 위한 공간을 고려해야 합니다. 일반적으로 추가 노드가 대기 상태로 남아 있을 것으로 예상하지 않기 때문입니다. AVS와 같은 솔루션에서 Microsoft는 언제든지 클러스터에 추가할 수 있는 여러 노드를 유지 관리합니다. 이러한 확장 및 자동화 기능은 수요 증가에 활용할 수 있을 뿐만 아니라, 문제가 있는 호스트 교체와 같은 유지 관리 작업에도 중요합니다. 따라서 온프레미스에서 실제로 호스트 4개를 구매하는 것과 같은 이유로 AVS에서는 호스트 3개만 구매하게 될 수도 있습니다. 호스트에 문제가 발생할 경우 Microsoft가 해당 호스트를 교체하고 새 호스트로 교체할 것이라는 것을 알고 있기 때문입니다.
• 스토리지 정책 액세스: 이 글을 쓰는 시점에는 새로운 스토리지 정책을 만들 수 없습니다. 이러한 정책은 AVS 클러스터에 미리 생성됩니다. 정책의 이름만 봐도 어떤 설정이 있는지 알 수 있으므로, 여기서는 정책에 대해 자세히 설명하지 않겠습니다. AVS 클러스터에서 제공되는 정책은 다음과 같습니다.  vSAN 기본 스토리지 정책, RAID-1 FTT-1, RAID-1 FTT-2, RAID-1 FTT-3, RAID-5 FTT-1, RAID-6 FTT-2.   앞서 언급한 것 외에도 더 많은 정책이 있지만, 주요 정책은 다음과 같습니다. 가장 눈에 띄는 점은  vSAN 기본 스토리지 정책이 씩 프로비저닝되어  있으며   데이터 저장소 기본 스토리지 정책이라는 것입니다. 이에 대해서는 나중에 자세히 설명하겠습니다. Azure 프라이빗 클라우드 인스턴스 이상에서 두 번째 클러스터의 데이터 저장소 기본 정책은 변경할 수 있지만, 첫 번째 정책은 변경할 수 없습니다. **업데이트: 이제 클러스터-1의 기본 스토리지 정책을 업데이트할 수 있습니다.**

AVS에서 스토리지 정책을 변경하는 방법

이제 AVS 클러스터에서 사용할 수 있는 기능에 대해 조금 알게 되었습니다. 이러한 VM의 정책을 개별적으로, 그리고 규모에 맞게 관리하는 방법에 대해 알아보겠습니다. AVS 클러스터의 데이터 저장소 기본값인 vSAN 기본 스토리지 정책이 무엇인지 알게 되었습니다. 대부분의 사람들은 씩 프로비저닝된 스토리지 정책을 사용하고 싶어하지 않습니다. 공간 효율적이지 않기 때문입니다. 따라서 다른 옵션 중 하나로 변경할 가능성이 높습니다. 어떤 옵션을 선택할지는 클러스터에 있는 호스트 수와 용량 및 성능 요구 사항에 따라 달라집니다(위에 링크된 이전 문서에서 이에 대해 자세히 설명했으며, 여기서는 이러한 고려 사항에 대해 자세히 설명하지 않습니다). VM의 스토리지 정책을 변경하는 것은 매우 쉽습니다. 온프레미스 클러스터에서 이 작업에 익숙하다면 다를 것입니다. 아래에서 "cloudadmin" 계정에 해당 권한이 없기 때문에 VM 정책 옵션을 선택할 수 없다는 점에 유의하세요.

하지만 VM 설정으로 들어가면 VMDK를 선택하고 스토리지 정책을 확인할 수 있습니다.

정책을 매우 구체적으로 설정할 때 유용합니다. 예를 들어 용량은 작지만 I/O가 높은 로깅 드라이브에 RAID 1 정책을 적용할 수 있습니다. 또는 I/O는 낮지만 공간을 많이 차지하는 파일 서버에 RAID 6 정책을 적용할 수도 있습니다. 하지만 전체 VM 세트에 단일 정책을 적용하려는 경우, UI에서 이러한 대량 변경을 수행할 수 있는 방법이 없습니다(제가 찾은 방법도 없습니다). 따라서 "반복적인 클릭-작업"을 피하기 위해 PowerCLI를 사용하여 대량 변경을 수행하겠습니다. PowerCLI를 처음 사용하는 경우 PowerShell에서 이 방법을 사용하여 쉽게 설치할 수 있습니다.

Get-SPBMEntityConfiguration및 명령을 사용하여 작업을 완료하겠습니다 Set-SPBMEntityConfiguration. 먼저 스토리지 정책에 연결된 전체 VM 세트에 대해 이 작업을 수행하는 방법을 살펴보겠습니다. 아래에서는 vSAN 기본 스토리지 정책Get-SPBMEntityConfiguration 에 연결된 모든 객체를 반환하는 명령을 사용합니다 .

다음과 같은 명령을 실행하여 이를 "세트"로 파이프하면 나열된 모든 VM이 변경됩니다.

Get-SpbmEntityConfiguration -StoragePolicy "vSAN Default Storage Policy" | Set-SpbmEntityConfiguration -StoragePolicy "RAID-1 FTT-1"

이렇게 하면 모든 객체가 "RAID-1 FTT-1" 정책으로 변경됩니다. 하지만 여기서는 특정 VM만 변경하겠습니다.

여기서 중요한 점은 하드 디스크를 지정해야 한다는 것입니다. VM 이름만 입력하면 스왑 및 홈 객체와 같은 VM 객체만 변경됩니다.

마무리

AVS는 기존 VMware 고객에게 많은 서비스를 제공하기 때문에 Azure에서 빠르게 성장하는 서비스입니다. 이 새로운 관리형 SDDC 모델을 도입할 때는 "클라우드 관리자" 역할이 일상 업무에 어떤 영향을 미칠 수 있는지 파악하는 것이 중요합니다. github에서 제 스크립트를 확인해 보세요 . 이 스크립트는 참고용일 뿐이며, 프로덕션 환경에서 사용되는 모든 스크립트는 반드시 철저히 테스트해야 합니다!

첫 번째 영상에서는 Azure에 AVS 인스턴스를 배포하는 방법을 다룹니다. 이 영상에서는 클러스터를 배포하고 Express Route 회로에 연결하는 단계별 프로세스를 자세히 설명합니다. 네트워크를 AVS 네트워크에 연결하는 방법은 여러 가지가 있으므로 네트워크 토폴로지에 따라 과정이 약간 다를 수 있습니다.

https://youtu.be/NkdMJlmbbzE

AVS 배포 방법

vSphere Cloud Foundation 중심의 플랫폼 비즈니스 전략

브로드컴은 VM웨어의 인수와 함께 가상화 솔루션 판매 위주에서 퍼블릭 클라우드 수준의 프라이빗 클라우드를 구축하기 위한 플랫폼 비즈니스로 중심을 변경하고 있습니다. 브로드컴의 CEO인 Hock Tan은 브로드컴 B-Connected Blog에 기고한 ‘CEO Insights: A Changing market landscape requires constant evolution: our mission for VMware customers’에서 VM웨어의 전략 변경에 대해서 설명하고 있습니다.

브로드컴은 고객에게 일관된 경험을 제공하기 위하여 변화를 지속하고 있습니다. 워크로드를 고객 자체의 데이터센터에서 퍼블릭 클라우드로 또는 퍼블릭 클라우드 사이에 자유롭게 이동할 수 있도록 클라우드 공급 업체(CSP)들과 협의하고 있습니다. 최종 사용자와 동일하게 라이선스를 코어(Core) 단위로 통합하고 vSphere Cloud Foundation(VCF)에 라이선스-호환성(License Portability)을 제공하고 VCF에 대한 클라우드 공급자의 기술 스택을 표준화하고 있습니다. 이를 통해 고객은 CSP 사이의 워크로드 이동 시에 라이선스 불일치로 인한 비용 추가를 피할 수 있으며, VM웨어가 지원하는 모든 클라우드 공급업체에서 동일한 기술 및 지원을 받을 수 있습니다. 현재는 구글 클라우드로의 VCF의 라이선스 이동이 가능합니다.

기업용 소프트웨어 업계는 라이선스 구독 모델로의 전환을 추진해 왔으며, VM웨어도 2018년부터 구독 모델을 도입하였습니다. VMware Cloud Foundation(VCF)과 VMware vSphere Foundation(VVF)을 중심으로 한 이 구독 모델은 가격을 각각 50%와 43%정도 인하하였고, 소프트웨어 개발사의 Upsell-점진적인 기능을 동일 제품의 새로운 버전 또는 새로운 Add-on 제품으로 브랜딩-하는 관행을 종식시켜 추가비용 없이 새로운 기능을 지속적으로 사용할 수 있습니다. 또한 소프트웨어 업체는 제품 수의 감소로 인해서 테스트 부담이 감소하며, 제품 혁신으로 운영 복잡성이 낮아지는 장점을 얻을 수 있습니다. 

이러한 변화가 소프트웨어 산업의 트렌드에는 부합하지만 장기적인 비용 증가에 대한 우려가 커지고 있는 것은 문제가 될 수 있습니다. 브로드컴은 고객을 Strategic, Corporate 및 Commercial의 3개의 세그먼트로 구분하고 고객의 세그먼트에 따라서 구매할 수 있는 제품에 제약을 두고 있습니다. vSphere Standard 및 vSphere Essentials Plus와 같이 소규모 가상화 환경을 위한 제품은 vSAN 등의 Add-On 제품의 구매가 불가능하도록 변경되었습니다. 결과적으로 이런 변화에 적응하기 위해서 제품의 특성 및 제한 사항에 대해서 예전보다 더 깊은 이해가 필요하게 되었습니다.

VM웨어 라이선스 정책 변경

VM웨어의 라이선스 기준은 CPU의 소켓당 라이선스에서 소켓당 코어 라이선스로 변경되었습니다. 최소 코어는 16코어로 16코어 미만의 호스트는 16코어로 산정됩니다. 즉, 8코어의 노드와 16코어의 노드는 라이선스가 동일하게 산정되어, 적은 코어 노드를 16코어 이상의 서버로 교체하는 것도 고려할 수 있습니다. 소규모 기업이나 개발 및 테스트 등의 환경에 적합한 VMware vSphere Essential Plus는 최대 32코어, 3노드(총 96코어)로 구성이 가능합니다.

vSphere Essential Plus와 Standard는 Add-On 구매가 제한된 단독제품으로, vSAN · SRM(Site Recovery Manager) · VCDR(VMware Cloud DR) 등의 Add-on을 구매할 수 없습니다. 기존에 해당 기능을 사용하고 있는 고객은 VVF나 VCF로 업그레이드를 고려해야 합니다. 또한 Add-On 중에서 vSAN은 기존 코어 단위에서 용량 단위로 라이선스 기준이 변경되었습니다. 기본 용량으로 VVF는 코어당 100GiB, VCF는 코어당 1TiB의 저장 공간을 사용할 수 있습니다. 따라서 더 많은 공간이 필요한 고객은 추가 비용이 발생할 수 있기에 스토리지 시스템의 아키텍처에 대한 검토가 필요합니다.

 (표 1) VM웨어 라이선스 전략 변화

VM웨어 제품 통합

브로드컴은 168개의 제품군(SKUs)를 4개의 제품군으로 간략화하였습니다. 서버 가상화는 데이터센터의 IT 인프라 최하부에 위치하며 AP · Database 서버 등 애플리케이션을 운영하기 위한 기본 인프라입니다. VMware vSphere Essential Plus와 vSphere Standard는 단품(Standalone)으로만 구매가 가능하며 소규모의 가상화 환경을 구축하는 기업에 적합합니다. VVF와 VCF는 대규모 가상화 및 프라이빗 클라우드를 구축하려고 하는 기업에 적합한 제품으로, 컨테이너 환경을 지원하는 TKG(Tanzu Kubernetes Grid)와 vSAN 및 NSX와 같은 엔터프라이즈 기능을 추가로 제공합니다.

 (표 2) VM웨어 제품 특성

VVF 및 VCF 플랫폼 선택

기업이 IT 인프라를 최적화하고 현대화하기 위해 플랫폼을 도입할 때에는 비용뿐만 아니라 인프라 발전 전략, IT팀의 인력 구성, AS-IS 인프라 환경 등 다양한 요소를 고려해야 합니다. 일반적으로 VVF는 기업의 가상화 인프라 플랫폼 구축에 적합한 제품이며, 데이터센터 수준의 프라이빗 클라우드와 하이브리드 클라우드 플랫폼을 구축하기 위해서는 VCF를 고려할 수 있습니다.

VVF는 애플리케이션 성능과 안정성을 위한 검증된 아키텍처가 필요할 때, 산업이나 비즈니스 요구사항에 맞춘 맞춤형 인프라를 구축할 때, 기업이 지켜야할 보안 표준과 규제를 준수하기 위한 아키텍처가 필요할 때에 최적화된 솔루션을 제공할 수 있습니다. VCF는 하이브리드 클라우드 환경을 통합 관리할 때, 기존 데이터센터를 현대화하여 효율성을 높이고자 할 때, 인프라 배포와 운영을 자동화하여 관리 부담을 줄이고자 할 때, 비즈니스 성장에 따라 쉽게 확장할 수 있는 인프라가 필요할 때에 강점을 제공합니다. 표3은 목표 시스템에 따라서 선택할 수 있는 제품과 Add-On을 나타내고 있습니다.

(표 3) 목표시스템에 따른 VM웨어 제품 구성

VM웨어 제품 EOA(End Of Availability)

VM웨어의 제품 구성 변경으로 인해 다수의 제품이 End of Availability(EOA) 상태가 되었습니다. 이러한 제품들은 더 이상 단독으로 구매할 수 없으며, VVF와 VCF 또는 Add-on으로만 구매할 수 있습니다. 기존 VM웨어 제품의 EOA 목록을 확인하고 지원 종료 제품을 식별하며, 대체 제품 및 업그레이드 계획을 수립하는 것이 중요합니다.

이를 통해 기존 제품의 기능을 최신 버전으로 대체하고, 새로운 제품에 대한 교육 및 훈련을 통해 전환 과정에서의 문제를 최소화하고 운영 효율성을 극대화할 수 있습니다. 또한, 기술 지원 및 서비스 계약을 검토하고 필요에 따라 갱신하여 지속적인 지원을 받을 준비를 해야 합니다. 이를 통해 기업은 IT 인프라를 안정적으로 유지하고, 미래의 IT 환경 변화에 유연하게 대응할 수 있습니다.

브로드컴의 VM웨어 인수 후 라이선스 정책 및 제품 전략 변화에 대해 살펴보았습니다. 소켓 당 코어 단위의 새로운 구독 체계가 도입되어 다양한 Standalone 구매 옵션이 사라지고, VVF와 VCF가 중심이 되는 2개 제품으로 통합되었습니다. VM웨어는 단순 가상화에서 퍼블릭 클라우드 수준의 하이브리드 클라우드 플랫폼으로 전략을 확대하였습니다. 이로 인해 고객들은 기존 VM웨어 인프라를 발전시키고 하이브리드 클라우드 플랫폼을 구축하기 위해서 새로운 정책을 명확히 이해하고 자신의 인프라 환경을 검토하여 조정하는 것이 필요합니다. 신규 라이선스 정책과 기준에 따라 비용 효율적이고 최적화된 아키텍처로의 전환을 시작하시기를 권장합니다.

VM웨어에 대해 더 자세히 알아보고 싶으시다면, 메타넷티플랫폼과 상담하세요!