다음을 통해 공유


Azure VMware Solution 엔터프라이즈 규모 시나리오에 대한 플랫폼 자동화

엔터프라이즈 규모 랜딩 존은 자동화 및 DevOps에 대한 일련의 모범 사례를 사용합니다. 이러한 모범 사례는 Azure VMware Solution 프라이빗 클라우드의 배포를 지원할 수 있습니다. 이 가이드에서는 Azure VMware Solution의 초기 배포에 대한 배포 고려 사항에 대한 개요를 제공합니다. 또한 운영 자동화에 대한 지침을 제공합니다. 이 구현은 확장성을 고려한 설계에 중점을 둔 클라우드 채택 프레임워크의 아키텍처 및 모범 사례를 따릅니다.

이 솔루션은 두 가지 핵심 부분으로 구성됩니다. 첫 번째 부분은 Azure VMware Solution의 배포 및 자동화 사례에 대한 지침입니다. 두 번째 부분은 프라이빗 클라우드 배포에 도움이 되도록 조정할 수 있는 오픈 소스 아티팩트 집합입니다. 이 솔루션은 엔드투엔드 자동화 여정을 시작하는 것을 목표로 하지만 조직은 이 문서의 고려 사항에 따라 수동으로 배포할 구성 요소를 결정할 수 있습니다.

Azure VMware Solution 랜딩 존 가속기 자동화는 이 리포지토리 내의 템플릿과 스크립트를 사용하여 Azure VMware Solution 배포를 시작하는 데 도움이 되도록 설계되었습니다. 배포하기 전에 템플릿을 검토하여 배포되는 리소스와 관련 비용을 이해하는 것이 좋습니다.

이 문서에서는 다음 영역에서 고려 사항 및 권장 사항을 다룹니다.

  • 수동 및 자동을 포함한 Azure VMware Solution의 배포 옵션.
  • 자동화된 확장 고려 사항 및 구현 세부 정보.
  • 프라이빗 클라우드 내의 VMware SDDC 수준 자동화에 대한 고려 사항.
  • 엔터프라이즈 랜딩 존에서 확장된 자동화 방법에 대한 권장 사항.
  • Azure CLI, Azure Resource Manager, Bicep 및 PowerShell과 같은 배포 및 관리에 사용할 자동화 기술에 대한 고려 사항입니다.

배포 전략

Azure VMware Solution은 수동으로 배포하거나 큐레이팅된 자동화된 도구를 사용하여 배포할 수 있습니다.

수동 배포

Azure Portal을 통해 그래픽으로 Azure VMware Solution 프라이빗 클라우드를 구성하고 배포할 수 있습니다. 이 옵션은 소규모 배포에 적합합니다. 대규모 Azure VMware Solution 토폴로지를 반복 가능한 방식으로 배포하려면 자동화된 배포를 고려합니다. 프라이빗 클라우드에 대한 연결을 구성한 다음 Azure Portal을 통해 수동으로 확장할 수도 있습니다.

고려 사항:

  • 초기 파일럿 및 소규모 환경에 수동 배포를 사용할 수 있습니다. 기존 자동화 또는 코드로서의 인프라 사례가 없는 경우에도 사용할 수 있습니다.
  • Azure Portal, Azure CLI 또는 Azure PowerShell 모듈을 통해 Azure VMware Solution을 배포하는 경우 솔루션에 데이터 보호에 대한 일련의 사용 약관이 표시됩니다. Azure Resource Manager API를 직접 사용하거나 Azure Resource Manager 또는 Bicep 템플릿을 통해 배포하는 경우 자동화를 배포하기 전에 이러한 사용 약관 을 검토하는 것이 좋습니다.
  • 필요에 따라 스핀업되는 주문형 환경의 경우 Azure VMware Solution 프라이빗 클라우드 만들기 프로세스를 자동화하여 수동 상호 작용의 양을 제한하는 것이 좋습니다.
  • Azure Portal 내에서 대상 리소스 그룹의 배포 블레이드를 사용하여 프라이빗 클라우드 만들기 프로세스를 모니터링할 수 있습니다. 프라이빗 클라우드를 배포했으면 계속 진행하기 전에 성공 상태인지 확인합니다. 프라이빗 클라우드에 실패한 상태 표시되는 경우 vCenter Server에 연결할 수 없습니다. 프라이빗 클라우드를 제거하고 재배포해야 할 수 있습니다.

권장 사항:

  • 수동 배포 방법을 선택하는 경우 프라이빗 클라우드를 프로비저닝하는 데 사용하는 구성을 문서화하는 것이 중요합니다. 배포되면 설명서를 위해 사용한 배포 템플릿을 다운로드 합니다. 이 템플릿 아티팩트에는 프라이빗 클라우드를 배포하는 데 사용되는 ARM 템플릿이 포함되어 있습니다. 템플릿 아티팩트에도 선택한 구성이 포함된 매개 변수 파일이 있습니다.
  • Azure Portal의 프라이빗 클라우드와 정기적으로 상호 작용하려는 경우 리소스 잠금을 설정하여 리소스 삭제를 제한하는 것이 좋습니다. 읽기 전용 리소스 잠금을 사용하여 확장 작업을 제한할 수도 있습니다.

자동화된 배포

자동화된 배포를 사용하여 반복 가능한 방식으로 Azure VMware Solution 환경을 배포할 수 있습니다. 그런 다음 주문형 방식으로 환경을 설계하고 배포할 수 있습니다. 이러한 사용은 여러 환경 및 지역을 대규모로 롤아웃하는 효율적인 배포 메커니즘으로 이어집니다. 또한 위험도가 낮고 주문형이며 반복 가능한 배포 프로세스를 제공합니다.

자동화된 Azure VMware Solution 구현 옵션

구현 옵션 설명 GitHub 리포지토리에 대한 배포 링크
Azure에 연결하여 Azure VMware Solution 및 종속성 배포 이 배포는 새 Azure VMware Solution 프라이빗 클라우드를 프로비전하는 데 가장 적합합니다. 본격적인 배포 버전이며 다양한 지원 구성 요소를 만드는 데 도움이 됩니다. 이러한 구성 요소에는 Azure 연결, 모니터링 및 추가 기능이 포함됩니다.

Azure Portal UI, PowerShell 및 Terraform의 세 가지 배포 옵션이 있습니다. 각 배포 옵션을 사용하면 다음 리소스를 배포하도록 선택할 수 있습니다.

▪ Azure VMware Solution 프라이빗 클라우드
▪ 새로 만들기 또는 기존 가상 네트워크 선택(VNet)
▪ VPN 커넥트용 Azure Route Server 배포(선택 사항)
▪ Azure VMware Solution 모니터링 배포(선택 사항)
▪ HCX 및 SRM 배포(선택 사항)
Azure에 배포(Azure Portal UI)

Azure에 배포(PowerShell)

Azure에 배포(Terraform 모듈)
Azure에 연결하지 않고 Azure VMware Solution 배포 이 배포는 더 가벼운 버전입니다. POC(개념 증명) 또는 파일럿에 더 적합합니다. 다음 리소스를 배포할 수 있습니다.

▪ 새 Azure VMware Solution 프라이빗 클라우드: (1) 사용자 지정 리소스 그룹 이름 및 프라이빗 클라우드 이름 또는 (2) 기존 Azure VMware Solution 프라이빗 클라우드를 선택합니다.
▪ Azure VMware Solution 모니터링을 배포합니다(선택 사항).
▪ HCX 및 SRM을 배포합니다(선택 사항).
Azure에 배포 (Azure Portal UI)

고려 사항:

  • Azure VMware Solution 프라이빗 클라우드 배포는 완료하는 데 몇 시간이 걸릴 수 있습니다. 프라이빗 클라우드에서 Azure Resource Manager 배포 상태 또는 상태 속성을 사용하여 이 프로세스를 모니터링하는 것이 좋습니다. 배포 파이프라인을 사용하거나 PowerShell 또는 Azure CLI를 통해 프로그래밍 방식으로 배포할 수 있습니다. 그렇다면 프라이빗 클라우드 프로비저닝 프로세스를 수용할 수 있도록 적절한 시간 초과 값을 선택해야 합니다.
  • 네트워크 토폴로지 및 연결의 권장 사항에 따라 프라이빗 클라우드 및 워크로드 네트워크의 주소 범위를 미리 할당할 수 있습니다. 그런 다음 환경 구성 또는 매개 변수 파일에 추가합니다. 주소 범위 겹침은 배포 시 유효성이 검사되지 않습니다. 두 개의 프라이빗 클라우드에 동일한 주소 범위가 있는 경우 이러한 유효성 검사 부족으로 인해 문제가 발생할 수 있습니다. 범위가 Azure 또는 온-프레미스 내의 기존 네트워크와 겹치는 경우에도 문제가 발생할 수 있습니다.
  • 배포에 서비스 주체를 사용하여 최소 권한 있는 액세스를 제공할 수 있습니다. 또한 Azure RBAC(역할 기반 액세스 제어)를 사용하여 배포 프로세스에 대한 액세스를 제한할 수 있습니다.
  • 로컬 도구에 의존하지 않고 자동화되고 반복 가능한 배포를 위한 파이프라인을 사용하여 프라이빗 클라우드 배포에 DevOps 전략을 사용할 수 있습니다.

권장 사항:

  • 최소한의 프라이빗 클라우드를 배포한 다음 필요에 따라 확장합니다.
  • 성공적인 배포를 위해 미리 호스트 할당량 또는 용량을 요청합니다.
  • 하위 리소스를 배포하기 전에 프라이빗 클라우드 배포 프로세스와 프라이빗 클라우드의 상태를 모두 모니터링합니다. 프라이빗 클라우드에 대한 추가 구성 업데이트는 프라이빗 클라우드가 성공 상태인 경우에만 처리할 수 있습니다. 실패한 상태 프라이빗 클라우드의 경우 추가 작업을 중지하고 해결할 지원 티켓을 발생시키는 것이 좋습니다.
  • 자동화된 배포 내에 관련 리소스 잠금을 포함하거나 정책을 통해 적용되도록 합니다.

자동화된 연결

Azure VMware Solution 프라이빗 클라우드를 배포한 후에는 ExpressRoute를 통해 연결을 설정할 수 있습니다. 이 구성 집합 내에서 설명하는 네트워크 연결을 위한 두 가지 중요한 경로가 있습니다.

  • 가상 네트워크 게이트웨이를 통한 가상 네트워크 또는 Azure Virtual WAN에 대한 연결.
  • Azure VMware Solution과 Global Reach를 통한 기존 ExpressRoute 간의 연결.

권장 네트워크 토폴로지에 대한 자세한 내용은 네트워크 토폴로지 및 연결을 참조하세요.

고려 사항:

  • Azure VMware Solution 프라이빗 클라우드를 Azure 가상 네트워크 또는 기존 ExpressRoute에 연결할 수 있습니다. 이 연결은 프라이빗 클라우드 내의 관리 네트워크와 워크로드 네트워크 모두의 경로를 자동으로 보급합니다. 중복 검사가 없으므로 연결하기 전에 보급된 네트워크의 유효성을 검사하는 것이 좋습니다.
  • ExpressRoute 권한 부여 키의 이름을 연결하는 리소스의 기존 명명 체계에 맞출 수 있습니다. 이 정렬을 통해 관련 리소스를 쉽게 식별할 수 있습니다.
  • ExpressRoute 가상 네트워크 게이트웨이 및 ExpressRoute 회로는 Azure VMware Solution 프라이빗 클라우드와 다른 구독에 있을 수 있습니다. 단일 서비스 주체가 이러한 모든 리소스에 액세스할 수 있도록 할지 아니면 별도로 유지할지 결정합니다.
  • Azure Portal을 통한 NSX-T 데이터 센터 워크로드 네트워킹은 필수 네트워크 리소스를 프라이빗 클라우드에 배포할 수 있지만 NSX-T 관리자는 NSX-T 데이터 센터 구성 요소를 보다 자세히 제어할 수 있습니다. 네트워크 세그먼트에 필요한 제어 수준을 고려해 볼 가치가 있습니다.
    • Azure Portal 내에서 NSX-T Data Center 워크로드 네트워킹을 사용하여 프라이빗 DNS 통합을 위한 DNS(Do기본 이름 시스템) 영역을 설정합니다.
    • 단일 계층 1 게이트웨이만 필요한 네트워크 토폴로지의 경우 Azure Portal 내에서 NSX-T Data Center 워크로드 네트워킹을 사용합니다.
    • 고급 구성의 경우 NSX-T Manager를 직접 사용할 수 있습니다.
    • 네트워크 관리자의 기술 수준을 고려합니다. 네트워크 관리자가 VMware NSX-T 데이터 센터에 대한 지식이 거의 없거나 전혀 없는 경우 네트워크 작업에 대한 위험을 줄이는 대신 Azure Portal을 사용하는 것이 좋습니다.

권장 사항:

  • ExpressRoute 구성 대신 Azure VMware Solution 배포에 대해 별도의 서비스 주체를 사용하는 경우 Azure Key Vault 또는 유사한 비밀 저장소를 사용하여 필요한 경우 배포 간에 권한 부여 키를 전달합니다.
  • Azure VMware Solution 프라이빗 클라우드를 통해 언제든지 수행할 수 있는 병렬 작업의 수에는 제한이 있습니다. 많은 Azure VMware Solution 프라이빗 클라우드 하위 리소스를 정의하는 템플릿의 경우 종속성을 사용하여 직렬 방식으로 배포하는 것이 좋습니다.

자동화된 규모

기본적으로 Azure VMware Solution 클러스터에는 클러스터 규모로 정의된 고정된 수의 호스트가 있습니다. 클러스터별 크기 조정을 프로그래밍 방식으로 수정할 수 있으므로 자동화를 통해 크기 조정 및 스케일 인할 수 있습니다. 이 자동화는 요청 시, 일정에 따라 또는 Azure Monitor 경고에 대한 반응으로 수행될 수 있습니다.

고려 사항:

  • 자동 스케일 아웃은 주문형으로 더 많은 용량을 제공할 수 있지만 더 많은 호스트에 대한 비용을 고려하는 것이 중요합니다. 이 비용은 구독에 제공된 할당량으로 제한되지만 수동 제한이 있어야 합니다.
  • 스케일 인을 자동화하기 전에 클러스터 내에서 적용된 실행 중인 워크로드 및 스토리지 정책에 미치는 영향을 고려합니다. 예를 들어 RAID-5가 할당된 워크로드는 3노드 클러스터로 확장할 수 없습니다. 메모리 및 스토리지 사용을 고려하는 것도 중요합니다. 이러한 사용은 스케일 인 작업을 차단할 수 있기 때문입니다.
  • 한 번에 하나의 단일 규모 작업만 수행할 수 있으므로 여러 클러스터 간의 규모 작업 오케스트레이션을 고려하는 것이 중요합니다.
  • Azure VMware Solution 확장 작업은 즉각적이지 않으며 기존 클러스터에 다른 노드를 추가하는 데 걸리는 시간을 고려해야 합니다.
  • 타사 솔루션 및 통합에서는 호스트가 지속적으로 제거 및 추가될 것으로 예상하지 않을 수 있습니다. 모든 타사 제품의 동작의 유효성을 검사하는 것을 고려합니다. 이 유효성 검사를 통해 호스트가 추가되거나 제거될 때 제품을 새로 고치거나 재구성하는 데 더 많은 단계가 필요하지 않습니다.

권장 사항:

  • 할당량을 벗어나는 스케일 인 및 스케일 아웃 작업 모두에 대해 엄격한 제한을 설정합니다.
  • 크기 조정 작업에 영향을 주지 않도록 할당량 을 미리 요청합니다. 할당량은 용량을 보장하는 것이 아니라 특정 제한까지 배포할 수 있는 기능입니다. 항상 여유 공간이 있는지 확인하려면 할당량 한도를 정기적으로 검토합니다.
  • 자동화된 크기 조정 시스템이 모니터링되고 스케일링 작업이 완료되면 경고하는지 확인합니다. 이 경고는 예기치 않은 규모 이벤트가 없는지 확인합니다.
  • Azure Monitor 메트릭을 사용하여 적절한 여유 공간이 있는지 확인하기 위해 스케일 인 작업 전에 클러스터 용량을 확인합니다. 스케일링 작업 전, 도중, 후에 CPU, 메모리 및 스토리지에 주의합니다. 용량에 대한 이러한 주의는 SLA(서비스 수준 계약)에 영향을 주지 않도록 합니다.

Azure 통합

Azure VMware Solution 프라이빗 클라우드는 여러 다른 Azure 네이티브 서비스도 사용할 수 있습니다. Azure VMware Solution 배포 내에 이러한 서비스를 포함하거나 별도의 구성 요소로 배포할 수 있습니다. 이 문서의 범위를 벗어나는 경우 엔터프라이즈 규모 랜딩 존 아키텍처 내의 기존 패턴을 사용하여 이러한 서비스와 통합하는 것이 좋습니다.

고려 사항:

자동화하려는 각 구성 요소의 배포 수명 주기를 고려합니다. 수명 주기에 따라 긴밀하게 바인딩된 그룹 구성 요소를 함께 그룹화하여 단일 단위로 배포할 수 있도록 해야 합니다. 수명 주기가 다른 구성 요소를 분리합니다.

Automation 도구

Azure VMware Solution 프라이빗 클라우드는 Azure Resource Manager 내에서 리소스로 존재하며 여러 자동화 도구를 통해 상호 작용을 제공합니다. Azure Resource Manager 사양에서 생성된 자사 Microsoft 도구는 릴리스 직후 기능을 지원하는 경향이 있습니다. 자동화 관점에서 이 문서의 고려 사항은 다양한 도구 집합에 적용할 수 있는 방식으로 제공됩니다.

고려 사항:

  • 구성을 단일 아티팩트로 정의할 수 있도록 Azure Resource Manager 및 Bicep 템플릿과 같은 선언적 도구를 사용합니다. Azure CLI 및 PowerShell과 같은 명령줄 및 스크립트 기반 도구에는 수동 배포에 더 가까운 단계별 실행 방법이 필요합니다.
  • Terraform과 같은 타사 자동화 도구를 사용하여 Azure VMware Solution 및 Azure 네이티브 서비스를 배포할 수 있습니다. Azure VMware Solution 내에서 사용하려는 기능이 현재 사용 가능한 리소스에 포함되어 있는지 확인하는 것이 중요합니다.
  • 배포에 대한 스크립트 기반 방법을 사용할 때는 항상 배포 실패의 의미를 고려하고 적절하게 모니터링합니다. 특히 Azure VMware Solution의 경우 배포 및 프라이빗 클라우드 상태를 모두 모니터링하는 것이 좋습니다. Azure VMware Solution 모니터링에 대한 자세한 내용은 Azure VMware Solution 관리 및 모니터링을 참조하세요.

권장 사항:

DevOps 방법

이상적으로는 워크플로 또는 파이프라인을 통해 Azure VMware Solution 배포 자동화를 반복 가능한 일련의 단계로 구현해야 합니다. 배포에 포함할 계획인 필수 단계의 범위를 지정하는 것이 중요합니다. 이러한 단계에는 다음이 포함될 수 있습니다.

  • 프라이빗 클라우드 배포.
  • ExpressRoute 게이트웨이 연결.
  • 전역 도달률 연결.
  • 간소화된 NSX-T 데이터 센터 DHCP, DNS 및 세그먼트 만들기

프라이빗 클라우드를 배포한 후 프라이빗 클라우드 내에서 리소스를 배포할 수 있습니다. 자세한 내용은 VMware SDDC 플랫폼 자동화를 참조 하세요.

고려 사항:

  • 기존 자동화 사례가 있거나 엔터프라이즈 규모 랜딩 존의 일부로 DevOps 전략을 구축했을 수 있습니다. 그렇다면 Azure VMware Solution 배포에 동일한 패턴을 재사용하여 전반적으로 일관된 자동화 스타일을 유지하는 것이 좋습니다.
  • 자세한 내용은 엔터프라이즈 규모 랜딩 존 플랫폼 자동화 및 DevOps 설명서를 참조하세요.

VMware 플랫폼 자동화

Azure VMware Solution 프라이빗 클라우드 내에서 vCenter Server 및 NSX-T Manager 내에서 리소스 만들기를 자동화하도록 선택할 수도 있습니다. VMware SDDC 수준 자동화를 설계하는 데 도움이 되는 다음 일련의 고려 사항이 나열됩니다.

vCenter Server 자동화 - PowerCLI

고려 사항:

  • PowerCLI를 사용하여 VM(가상 머신), 리소스 풀 및 VM 템플릿을 만들고 구성하여 vCenter Server를 프로그래밍 방식으로 완전히 제어할 수 있습니다.
  • vCenter Server는 프라이빗 연결 또는 개인 IP를 통해서만 사용할 수 있으므로 Azure VMware Solution 관리 네트워크에 대한 시야가 있는 컴퓨터에서 PowerCLI를 실행해야 합니다. 파이프라인 실행을 위해 자체 호스팅 에이전트 사용을 고려합니다. 이 에이전트를 사용하면 가상 네트워크 또는 NSX-T 데이터 센터 세그먼트 내의 VM에서 PowerCLI를 실행할 수 있습니다.
  • CloudAdmin 역할로 제한되므로 특정 작업을 수행할 수 있는 액세스 권한이 없을 수 있습니다. 구현하려는 자동화에 필요한 권한을 매핑하고 CloudAdmin 권한에 대해 유효성을 검사하는 것이 좋습니다.
  • 최소 권한 액세스의 경우 Active Directory 통합을 통해 vCenter Server 수준 자동화에 서비스 계정을 사용하는 것이 좋습니다.

NSX-T 데이터 센터 자동화 - PowerCLI

고려 사항:

  • Azure VMware Solution 프라이빗 클라우드에서 관리 사용자는 기본적으로 NSX-T 데이터 센터에 대한 관리 액세스 권한을 줍니다. 이 기본 액세스로 인해 PowerCLI 또는 NSX-T 데이터 센터 API를 통해 변경된 내용이 직접 미치는 영향을 고려합니다. 전송 영역 및 계층 0 게이트웨이와 같은 Microsoft 관리 구성 요소를 수정하는 것은 허용되지 않으며 주의가 권장됩니다.
  • NSX-T 데이터 센터와 상호 작용하려면 PowerCLI를 실행하는 VM에서 Azure VMware Solution 프라이빗 클라우드로 프라이빗 연결이 필요합니다.
  • Azure Resource Manager를 통해 워크로드 네트워킹을 제어할 수 있습니다. 이 컨트롤을 사용하면 Azure Resource Manager API를 통해 작업의 하위 집합을 수행할 수 있습니다. 그러면 NSX-T 데이터 센터 ID 대신 Azure RBAC를 사용하여 Azure CLI 및 PowerShell을 통해 작업을 수행할 수 있습니다.

Terraform vSphere 및 NSX-T 데이터 센터 공급자

고려 사항:

  • Terraform용 vSphereNSX-T 데이터 센터 공급자를 사용하여 리소스를 배포할 수 있습니다. 이러한 리소스는 선언적 방식으로 프라이빗 클라우드 범위 내에서 배포됩니다.
  • Terraform은 vCenter Server 및 NSX-T Manager 내의 API 엔드포인트와 통신해야 하므로 프라이빗 클라우드 관리 네트워크에 대한 프라이빗 연결이 필요합니다. 프라이빗 클라우드로 라우팅할 수 있는 Azure Virtual Machines에서 배포하는 것이 좋습니다.

vRealize Automation 및 vRealize Operations

고려 사항:

  • 온-프레미스 환경과 유사하게 vRealize Automation을 사용하여 Azure VMware Solution 내에서 가상 머신 프로비저닝을 자동화할 수 있습니다.
  • Azure VMware Solution에서 지원되는 배포 모델에는 제한 사항이 있습니다. vRealize Cloud Management를 사용하거나 vRealize Automation 장치를 온-프레미스로 호스팅하는 것을 고려합니다.
  • PowerCLI와 마찬가지로 vRealize Automation 및 vRealize Operations 어플라이언스가 있는 환경에서 Azure VMware Solution에 대한 프라이빗 연결이 필요합니다.

워크로드 수준 자동화

Azure VMware Solution의 개별 워크로드 내에서 VM 수준에서 자동화를 설정하도록 선택할 수 있습니다. 이 자동화는 온-프레미스와 동일한 방식으로 달성되며 이 문서의 범위를 벗어납니다. 이 자동화의 예로는 Microsoft Configuration Manager, Chef, Puppet 및 Ansible이 있습니다. 온-프레미스 에이전트를 사용하여 VM 수준 구성에 Azure Automation을 사용할 수도 있습니다.

다음 단계

이제 설계 영역을 읽었으므로 엔터프라이즈 규모 시나리오에서 Azure VMware Solution에 대한 아키텍처 방법 및 구현에 대해 알아봅니다.