728x90

개요

온프레미스 자산을 클라우드 솔루션으로 마이그레이션하는 것은 복잡한 과정일 수 있으며, 특히 기존 IP 주소 계획을 고려할 때 더욱 그렇습니다. Azure VMware Solution(AVS)으로 마이그레이션하는 주요 이점 중 하나는 기존 IP 주소를 유지할 수 있다는 점입니다. 이를 통해 마이그레이션 프로세스를 간소화하고 다운타임을 줄일 수 있습니다. 하지만 이러한 접근 방식은 원활한 전환을 위해 신중한 계획과 네트워크 원칙 고려가 필요합니다.

이 게시물에서는 AVS로 마이그레이션하는 동안 IP 주소를 유지하기 위한 몇 가지 고려 사항을 살펴보겠습니다. 여기에는 네트워크 종속성을 이해하는 것의 중요성과 성능에 미치는 잠재적 영향이 포함됩니다. 또한 VMware Hybrid Cloud Extension(HCX) 레이어 2 확장 기능을 활용하여 마이그레이션 프로세스를 원활하게 진행하는 이점도 논의합니다.

일반적인 고려 사항

무엇보다도, 솔루션을 모색하기 전에 몇 가지 기본적인 네트워크 원칙을 정립해야 합니다. Azure VMware Solution(AVS)으로 마이그레이션을 계획하고 기존 IP 주소를 유지할 때 이러한 원칙을 이해하는 것이 매우 중요합니다. IP 여정의 기대치에 맞춰 네트워킹 원칙을 재구축할 수는 없기 때문입니다.

단일 라우팅된 네트워크는 한 위치에서만 액세스할 수 있습니다.

당연한 것처럼 들리지만, 라우팅된 네트워크는 한 번에 한 위치에서만 액세스할 수 있다는 점을 이해하는 것이 중요합니다. 즉, 온프레미스 환경에 라우팅된 네트워크(예: 10.1.2.0/24)가 있는 경우, 동일한 IP 주소 범위를 가진 네트워크를 클라우드 측에서 동시에 게시할 수 없습니다. 이는 네트워킹의 기본 원칙이며 마이그레이션을 계획할 때 반드시 고려해야 합니다.

단일 라우팅된 네트워크는 한 위치에서만 액세스할 수 있습니다.

단일 vLAN의 자산은 동일한 브로드캐스트 도메인을 공유합니다.

자산이 동일한 VLAN에 있으면 동일한 브로드캐스트 도메인을 공유합니다. 즉, 라우터 없이도 서로 통신할 수 있습니다. 이는 확장된 L2 네트워크의 자산에도 적용됩니다.

확장된 L2 네트워크를 통한 ARP 브로드캐스트의 예:

단일 vLAN의 자산은 동일한 브로드캐스트 도메인을 공유합니다.

마이그레이션된 자산은 구성된 게이트웨이를 계속 사용하여 라우팅된 피어에 도달합니다.

자산을 클라우드로 마이그레이션하고 IP 주소를 유지하면 구성된 게이트웨이를 계속 사용하여 라우팅된 피어에 접속합니다. 즉, 온프레미스 환경에 라우팅된 네트워크가 있는 경우, 마이그레이션된 자산은 온프레미스 게이트웨이를 사용하여 동일 네트워크의 다른 자산과 통신합니다. 일반적으로 이 연결 경로는 송신 및 수신 트래픽 모두에 사용됩니다.

IP 주소를 유지하는 경우: 마이그레이션된 자산은 구성된 게이트웨이를 계속 사용하여 라우팅된 피어에 도달합니다.

마이그레이션된 자산과 마이그레이션되지 않은 자산 사이에 지연이 발생합니다.

자산을 클라우드로 마이그레이션하고 IP 주소를 유지하는 경우, 마이그레이션된 자산과 마이그레이션되지 않은 자산 간에 지연 시간이 발생합니다. 익숙한 온프레미스 연결 외에도 다음과 같은 여러 요인이 지연 시간에 영향을 미칩니다.

  • 두 위치 사이의 지리적 거리
  • 링크 품질 및 라우팅 홉
  • 링크 사용 및 혼잡
  • 터널링 기술 및 프로토콜 사용
  • 교통의 트롬보닝 가능성
마이그레이션된 자산과 마이그레이션되지 않은 자산 사이에 지연이 발생합니다.

확장된 L2 네트워크의 경우 트래픽 지연은 클라우드 간 통신에 영향을 미칠 수도 있습니다. 이를 트롬보닝 효과라고 합니다.

트래픽 트롬보닝이란 무엇인가요?

교통 트롬보닝은 교통이 직선 경로로 이동하지 않고 한 장소에서 다른 장소로 이동한 후 다시 돌아올 때 발생합니다.

예: 최악의 시나리오 중 하나는 클라우드에서 마이그레이션된 자산이 다른 네트워크의 다른 자산과 통신을 시도하는 경우입니다. 한 자산의 게이트웨이가 온프레미스에 있는 경우, 트래픽은 마이그레이션된 자산(클라우드 측)에서 온프레미스 게이트웨이로 이동한 후 다시 클라우드 측으로 이동하여 대상 자산에 도달합니다. 응답은 대상 자산(클라우드 측)에서 온프레미스 게이트웨이로, 마지막으로 마이그레이션된 자산으로 돌아오는 동일한 경로를 따릅니다.

이 패턴은 성능과 인지된 지연 시간에 큰 영향을 미칠 수 있습니다.

트래픽 트롬보닝이란 무엇인가요?

IP 주소를 유지하기 위해 네트워크 확장

이미 추측하셨겠지만, 클라우드 솔루션으로 마이그레이션하는 동안 IP 주소를 유지하기 위한 솔루션은 네트워크를 확장하고 VM/애플리케이션 또는 다른 종류의 자산이 아닌 "네트워크별" 마이그레이션을 고려하는 것입니다.

일을 제대로 하려면 다음과 같은 방법을 권장합니다.

실행 계획

  1. 계획, 계획, 계획!
    • 확장할 네트워크를 신중하게 선택하세요.
    • 다음 단계를 이해하고 네트워크를 확장하여 이를 실행하는 방법을 알아보세요.
    • 네트워크의 모든 종속성을 이해합니다.
  2. L2 네트워크 확장
    • 이제 네트워크는 두 위치에 자산을 호스팅할 수 있습니다.
    • 게이트웨이는 온프레미스(대부분의 자산)에 유지됩니다.
  3. 자산 마이그레이션
    • 마이그레이션된 자산은 연결성과 IP 주소를 유지합니다.
  4. 남은 자산 대피
    • 필요한 경우: 일부 자산에는 네트워크가 온프레미스 리소스로부터 자유로운지 확인하기 위해 reIP가 필요할 수 있습니다.
  5. 스위치오버 연결
    • 이제 연결성이 클라우드 쪽으로 전환되었습니다.
    • 모든 워크로드는 기본 연결을 사용합니다.
    • L2 확장이 제거되었습니다.

마이그레이션 프로젝트와 관련하여 실행 계획의 각 단계에는 고유한 중요도 수준이 있으며, 다음과 같이 요약할 수 있습니다.

단계중요성
계획 비판적인
L2 네트워크 확장 낮은
자산 마이그레이션 중간
남은 자산 대피 낮은
스위치오버 연결 비판적인 *

* 계획 단계에 따라 크게 달라집니다.

어떻게 작동하나요?

네트워크 확장이 작동하는 방식을 간략하게 나타낸 다이어그램은 다음과 같습니다.

어떻게 작동하나요?

신중한 계획 후:

  1. 네트워크 확장은 확장 기술을 사용하여 구현됩니다(예시는 나중에 제공).
  2. 이 네트워크의 자산은 마이그레이션(IP 주소 유지)되거나 네트워크에서 철수(재IP, 폐기 등)됩니다.
  3. 네트워크 확장이 제거되고 연결이 클라우드 쪽으로 전환됩니다.

현재 내 네트워크는 어떻게 구성되어 있나요?

마이그레이션을 계획할 때는 현재 네트워크가 어떻게 구축되어 있는지, 그리고 마이그레이션 프로젝트에 대한 목표가 무엇인지 이해하는 것이 중요합니다. 이를 통해 잠재적인 문제를 파악하고 성공적인 마이그레이션을 계획할 수 있습니다.

최상의 시나리오최악의 시나리오
VMware 자산만 있는 소규모 Layer 2(L2) 서브넷. 평평한 네트워크 토폴로지.
모든 자산이 클라우드로 마이그레이션됩니다. 모든 리소스가 클라우드로 전환되는 것은 아닙니다.
네트워크와 자산 간의 네트워크 종속성을 잘 이해합니다. 네트워크 종속성에 대한 지식이 제한적입니다.
마이그레이션 후 온프레미스와의 종속성이 없습니다. 마이그레이션 후 온프레미스와의 종속성이 많아졌습니다.
메모

최상의 시나리오와 최악의 시나리오 기준을 쉽게 결정할 수 있다면, 이 두 극단적인 시나리오 사이에는 온갖 가능성이 존재할 수 있습니다 .

위험 완화

다음 섹션에서는 이전 위험에 대한 몇 가지 가능한 완화 전략을 살펴보겠습니다.

VMware 및 비 VMware 자산을 포함하는 네트워크

  • 네트워크별로, 한 범주 또는 다른 범주를 재IP화하는 데 드는 노력의 수준을 고려하세요. 예:
    • 자산의 80%가 온프레미스에 남습니다. 마이그레이션된 20%의 IP 주소를 변경해야 합니까?
    • 자산의 80%가 클라우드로 마이그레이션됩니다. 온프레미스에 남아 있는 20%의 IP 주소를 변경해야 합니까?
  • 마이그레이션된 워크로드에 대한 재IP 전략을 고려하는 경우에도 L2 확장은 여전히 ​​리소스 마이그레이션에 도움이 될 수 있습니다.

마이그레이션 후 온프레미스와의 종속성

  • 온프레미스에서 호스팅되는 서비스(PaaS/IaaS 등)의 클라우드 마이그레이션을 고려하세요.
  • 환경 간에 연결 방법을 조정합니다. 대역폭을 늘리고 지연 시간을 줄입니다.

네트워크 종속성에 대한 지식이 제한됨

VMware 하이브리드 클라우드 확장(HCX)

VMware HCX는 Azure VMware Solution(AVS)으로 마이그레이션하는 동안 네트워크를 확장하고 IP 주소를 유지하는 데 도움이 되는 강력한 도구입니다. 기존 IP 주소를 유지하면서 워크로드를 원활하게 마이그레이션할 수 있는 방법을 제공하여 마이그레이션 프로세스를 간소화하고 다운타임을 줄일 수 있습니다.

메모

HCX Enterprise는 AVS용 무료 추가 기능 으로, 추가 비용 없이 온프레미스에서 AVS로 워크로드를 마이그레이션하는 데 사용할 수 있습니다.

HCX L2 확장을 위해 고려해야 할 전제 조건

필수 조건완화
(표준) vSwitch는 HCX에서 L2 네트워크 확장을 지원하지 않습니다.
 Distributed-vSwitch 로 마이그레이션을 고려해 보세요.
  • 검증하기 쉽습니다.
  • 비교적 쉽게 수정할 수 있음
NSX-V에서 NSX-T로의 마이그레이션에 대한 HCX 지원은 버전 4.11에서 더 이상 지원되지 않습니다.
  • 검증하기 쉽습니다.
  • 현재 지원됨
HCX는 제한된 지원으로 vSphere 및 vCenter 6.5에 대한 마이그레이션을 지원합니다.
  • 검증하기 쉽습니다.
  • 현재 지원됨

HCX 모빌리티 최적화 네트워크(MON)를 통한 교통 트롬보닝 완화

HCX 사용의 주요 이점 중 하나는 네트워크 트래픽을 최적화하고 지연 시간을 줄이는 기능입니다. HCX 모빌리티 최적화 네트워크(MON)는 마이그레이션된 자산과 마이그레이션되지 않은 자산 간 또는 다른 네트워크의 리소스 간 트래픽 경로를 최적화하여 트롬보닝 효과를 최소화하는 기능입니다.

이전 게시물( VMware HCX: MON으로 이동 및 복귀 )에서는 HCX MON이 작동하는 방식과 트롬보닝 효과를 크게 줄이도록 구성하는 방법을 살펴보았습니다.

HCX L2 네트워크 확장 및 MON 기능이 활성화된 네트워크 경로 예

NSX 자율 엣지

HCX에 대한 또 다른 접근 방식은 NSX Autonomous Edge(NSX AE)를 사용하여 네트워크를 확장하고 Azure VMware Solution(AVS)으로 마이그레이션하는 동안 IP 주소를 유지하는 것입니다. 이 접근 방식은 NSX-T VPN 기능을 사용하여 온프레미스 환경과 클라우드 환경 간에 터널을 생성하므로, 워크로드를 마이그레이션하는 동안 네트워크를 확장하고 IP 주소를 유지할 수 있습니다.

메모

참고: NSX AE에서는 표준 vSwitch가 지원됩니다.

NSX L2 확장을 위해 고려해야 할 전제 조건 및 제한 사항

필수 조건완화
여러 VLAN을 확장하려면 트렁크 인터페이스가 필요합니다.
  • 무차별 모드가 필요합니다.
  • 전송 필요 없음을 잊어버리세요.
  • 검증하기 쉽습니다.
  • 쉽게 수정할 수 있습니다
HCX MON과 같은 최적화가 없습니다. 마이그레이션이 완료되면 즉시 네트워크 확장 전환을 권장합니다.
NSX AE OVF를 다운로드하려면 Broadcom 권한이 필요합니다. 해당 없음

결론

결론적으로 Azure VMware Solution(AVS)으로 마이그레이션하는 동안 IP 주소를 유지하는 것은 복잡한 프로세스가 아니지만 신중한 계획과 네트워크 원칙 고려가 필요합니다 .

VMware Hybrid Cloud Extension(HCX) Layer 2 확장 기능이나 NSX Autonomous Edge를 활용하면 마이그레이션 프로세스를 간소화하고 기존 IP 주소를 유지하면서 가동 중지 시간을 줄이거나 방지할 수 있습니다.

728x90
728x90

며칠 전, Microsoft는 Azure VMware 솔루션에 새로운 기능인 NSX Edge에 대한 공용 IP 활성화 기능을 출시했습니다 . 이 기회를 빌려 이 새로운 기능과 Azure VMware 솔루션에 인터넷 연결을 제공하기 위해 사용 가능한 다른 옵션(수신 및 발신 트래픽 모두)을 살펴보겠습니다.

Azure VMware 솔루션에 대한 인터넷 액세스 옵션

Azure VMware Solution 배포에 인터넷 액세스(인바운드 및/또는 아웃바운드)를 제공하기 위해 다음 3가지 옵션을 사용할 수 있습니다.

  1. Microsoft에서 관리하는 SNAT(아웃바운드 연결만 해당)를 사용합니다( 문서 )
  2. Azure Firewall, Azure vWAN 또는 타사 네트워크 가상 어플라이언스(NVA)를 사용하여 기본 경로를 광고합니다( 문서 )
  3. NSX-T Edge에 게시된 공용 IP 주소를 사용하세요( 문서 )

각 옵션에는 고유한 장점과 단점이 있으며 , 아래에 요약되어 있습니다.

Microsoft에서 관리하는 SNAT

Microsoft에서 관리하는 SNAT 옵션( 문서 )은 공용 IP 주소를 Microsoft에서 완전히 무료로 관리하므로 아웃바운드 (전용) 연결을 위한 가장 쉽고 비용 효율적인 옵션입니다 .

이 시나리오에서는 2개의 공용 IP가 사용되고 순환되어 최대 128,000개의 동시 연결을 통해 Azure VMware Solution 워크로드에 대한 아웃바운드 연결을 제공합니다.

여기에는 다음과 같은 제한 사항이 있습니다.

  • 인바운드 연결 없음
  • 아웃바운드 SNAT 규칙 제어 없음
  • 연결 로그 없음
  • 동시 연결 수는 128,000개로 제한됩니다.

Azure VMware Solution의 인터넷 연결을 위한 두 번째 옵션은 Azure 인프라의 다른 구성 요소에서의 기본 경로 알림을 기반으로 합니다( 문서 ).

이 광고는 다음을 사용하여 수행할 수 있습니다.

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 인스턴스 자체와 별도로 요금이 청구됩니다.

가격 세부 사항은 여기에 설명되어 있습니다: IP 주소 가격 및 요약:

유형표준(ARM)
공용 IP 접두사(주소 블록) IP당 시간당 0.006달러
공용 IP 주소 가격

IP 주소를 구매하기 전에 항상 공식 Azure 설명서에서 가격 정보를 확인하세요 . 위 표는 이 글을 쓰는 시점을 기준으로 발췌한 것입니다.

Azure VMware Solution에 대한 공용 IP 주소 예약

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 규칙을 구성해야 합니다.

  1. NSX-T 관리자에 로그인
  2. 네트워킹 탭 에서 NAT 섹션 에 액세스합니다.
  3. SNAT 규칙을 프로비저닝할 적절한 T1 라우터를 선택하세요.
  4. 이름과 프로비저닝된 블록의 IP 주소를 사용하여 아웃바운드 연결에 사용할 새 SNAT 규칙을 만듭니다.
  5. 구하다
아웃바운드 인터넷 연결을 활성화하기 위한 NSX-T SNAT 규칙 생성
방화벽 구성

NSX-T의 방화벽 구성에 따라 트래픽 통과를 허용하기 위한 방화벽 규칙을 만들어야 할 수도 있습니다.

인바운드 인터넷 액세스 활성화

DNAT를 통한 인바운드 연결

인바운드 인터넷 액세스는 DNAT 규칙에 따라 공용 IP 주소에서 워크로드(VM 또는 네트워크 서비스)의 내부 IP 주소로 트래픽을 전달할 수 있습니다.

  1. NSX-T 관리자에 로그인
  2. 네트워킹 탭 에서 NAT 섹션 에 액세스합니다.
  3. DNAT 규칙을 프로비저닝하려면 적절한 T1 라우터를 선택하세요.
  4. 프로비저닝된 블록의 이름, 공용 IP 주소 및 트래픽을 전달할 내부 IP 주소를 제공합니다.
  5. 구하다
인바운드 인터넷 연결을 활성화하기 위한 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 주소를 직접 사용할 수도 있습니다.

물론, 이러한 설정은 생각할 수 있는 모든 인터넷 연결 요구 사항을 충족하지는 않지만 새로운 가능성을 제공하며 인터넷에 연결된 애플리케이션을 호스팅하거나 발신 인터넷 연결을 제어하는 ​​데 있어 실제로 고려할 만한 자산입니다.

728x90
728x90

많은 조직이 추가 리소스를 클라우드로 이전하고 있으며, 클라우드 비용이 IT 예산에서 큰 비중을 차지하고 있습니다. Azure 비용 관리를 시작하면 비용을 절감하고 최적화하는 데 도움이 되는 기본 제공 가격 모델, 비용을 시각화하고 관리하는 데 도움이 되는 도구, 그리고 낭비를 줄이고 기존 리소스 활용도를 높이는 데 사용할 수 있는 검증된 모범 사례가 제공됩니다.

이 게시물에서는 Azure 가격 책정 구조의 핵심 요소인 5가지 비용 절감 옵션을 살펴보고, VM 크기 조정, 미사용 디스크 찾기, 워크로드를 컨테이너로 이전하는 등 비용 절감을 위한 7가지 모범 사례를 제시합니다.

 

이 기사에서는 Azure에서 비용을 절감하는 12가지 방법에 대해 알아봅니다.

  1. Azure 예약 인스턴스
  2. Azure 하이브리드 혜택
  3. Azure 개발/테스트 가격
  4. AWS와의 가격 매칭
  5. Azure 비용 관리
  6. VM 적정 크기 조정
  7. B 시리즈 VM 사용
  8. 컨테이너로 작업 부하 전환
  9. 사용하지 않는 디스크 찾기 및 삭제
  10. 데이터베이스 VM에서 탄력적 데이터베이스로 이동
  11. 스토리지 계층화 사용
  12. Cloud Volumes ONTAP을 사용하여 Azure 스토리지 비용 최적화

 

Azure 비용 절감 옵션 내장

Azure 클라우드는 비용 절감을 위한 여러 가지 기본 옵션을 제공합니다. Azure 비용 최적화 전략을 계획할 때 이러한 옵션을 잘 숙지해야 합니다.

1. Azure 예약 인스턴스

Azure를 사용하면 인스턴스를 예약하고 상당한 할인 혜택을 받을 수 있습니다. 예약 옵션은 세 가지입니다.

  • 1년 예약 인스턴스 - 1년치를 선불로 지불해야 하며 대부분의 가상 머신에 대해 40-45% 할인이 제공됩니다.
  • 3년 예약 인스턴스 - 3년치를 선불로 지불해야 하며 대부분의 가상 머신에 대해 60-65% 할인이 제공됩니다.
  • 스팟 가격 책정 - Azure Marketplace에서 사용 가능한 용량에 대해 입찰하고 80-90% 할인된 가격으로 인스턴스를 받을 수 있습니다. 그러나 인스턴스는 사전 통지 없이 중단될 수 있으므로 특정 유형의 작업에만 적합합니다.


모든 VM 유형과 관리 서비스에 대한 예약된 가격 세부 정보를 확인하세요 .

 

2. Azure 하이브리드 혜택

Azure Hybrid Benefit은 Microsoft의 광범위한 기업 설치 기반을 활용하는 프로그램입니다. 이미 Windows Server 또는 SQL Server 라이선스를 보유하고 있고 온프레미스에서 사용 중이라면, 해당 라이선스를 클라우드로 가져올 수 있습니다.

Azure VM 비용에는 Microsoft 소프트웨어 라이선스 비용이 포함되므로 이미 라이선스가 있는 경우 VM 비용 할인을 받을 수 있으며, 기존 라이선스를 사용하여 Windows Server VM, SQL Server VM 및 관리형 SQL Database 서비스에 대한 할인도 받을 수 있습니다. 예약 인스턴스와 하이브리드 혜택 프로그램을 함께 사용하면 최대 80%까지 할인받을 수 있습니다.

또한 Windows Server와 SQL Server 2008을 Azure로 마이그레이션하면 3년 동안 보안 업데이트가 무료로 제공되므로 보안 및 규정 준수를 위해 라이선스를 계속 연장할 필요가 없습니다.

Azure Hybrid Benefit 계산기를 사용하여 소유한 라이선스 수에 따라 정확한 절감액을 추정해 보세요.  

3. Azure 개발/테스트 가격

Azure는 개발 및 테스트에 서비스를 사용하는 경우 대폭 할인된 가격을 제공합니다. 

  • Microsoft 소프트웨어에 대해 Windows 및 SQL Server VM을 무료로 실행합니다. 이러한 VM은 일반적으로 Microsoft 소프트웨어 라이선스 비용 때문에 Linux VM보다 더 비싸지만 개발/테스트의 경우 Linux VM과 동일한 가격으로 제공됩니다.
  • Azure SQL Database 최대 55% 할인
  • 로직 앱 최대 50% 할인
  • 기타 서비스에 대한 다양한 할인 - 자세한 내용은 여기를 참조하세요.

4. 가격 매칭

Azure는 유사 서비스에 대해 AWS 비용과 동일한 가격을 보장합니다. 가격은 AWS 가격 인하에 따라 3개월마다 조정됩니다. 가격 매칭은 다음 서비스에 대해 가능합니다.

  • Linux VM - AWS EC2와 비교
  • Azure Functions—AWS Lambda와 비교
  • Block Blob Storage(ZRS HOT) - Amazon S3 Standard와 비교
  • Block Blob Storage(ZRS COOL) - Amazon S3 Standard-Infrequent Access와 비교

5. Azure 비용 관리

비용 관리는 Azure Portal에 기본 제공되는 무료 도구입니다. Azure 서비스 비용 절감에 도움이 되는 데이터를 수집하고 분석을 지원합니다. Azure는 Azure Advisor, 비용 계산기, 비용 분석, Azure Budgets, 그리고 Azure와 다른 클라우드의 리소스 사용량 및 지출을 추적할 수 있는 Cloudyn 등 비용 계획 및 최적화를 위한 추가 도구를 제공합니다.

Azure 비용 최적화: 팁과 모범 사례

Azure에서 기존 리소스를 보다 효과적으로 활용하는 데 사용할 수 있는 검증된 모범 사례 몇 가지를 소개합니다.

6. VM 크기 조정

Azure는 다양한 하드웨어 및 성능 기능을 갖춘 광범위한 VM을 제공합니다. 동일한 워크로드에 여러 VM을 사용하여 가장 낮은 비용으로 가장 높은 처리량이나 성능을 제공하는 VM을 확인해 보세요. 가장 성능이 좋은 VM을 선택하고 자동 크기 조정을 사용하여 실제 워크로드에 맞게 VM 수를 자동으로 조정하세요.  

모든 VM이 100% 사용되었을 때 최적의 비용을 달성할 수 있다는 점을 기억하세요. Azure Monitor를 사용하여 메트릭을 모니터링하고, 자동 크기 조정이나 기타 방법을 사용하여 사용률에 따라 머신을 추가 및 제거하여 이 목표에 최대한 근접하도록 노력하세요.

7. B 시리즈 VM 사용

Azure는 일반적으로 유휴 상태이다가 갑자기 사용량이 급증하는 애플리케이션을 위해 설계된 B 시리즈 가상 머신을 제공합니다. B 시리즈 VM은 일반적으로 낮은 기본 CPU 성능 수준으로 실행되며, 이 낮은 성능이 워크로드에 적합한 한 크레딧이 누적됩니다. 사용량이 갑자기 급증하면 CPU 성능이 증가하고, 크레딧을 사용하여 추가 용량에 대한 "비용"을 지불합니다. 크레딧이 소진되면 머신은 기본 CPU 성능으로 돌아갑니다.

B 시리즈 VM은 동급 VM 대비 15~55% 할인 혜택을 제공합니다. 가용성이 필요하지만 가끔씩 높은 성능이나 처리량이 필요한 워크로드가 있는지 파악하여 B 시리즈 VM으로 이전하세요.

8. 컨테이너로 워크로드 전환

컨테이너는 VM보다 가볍습니다. 하나의 물리적 호스트에서 여러 컨테이너화된 애플리케이션을 실행할 수 있으며, 경우에 따라 호스트당 최대 수십 개의 컨테이너를 실행할 수 있습니다. 애플리케이션을 컨테이너로 리패키징하면 VM 사용률을 줄이고 비용을 크게 절감할 수 있습니다. 기존 Azure VM에서 Azure Kubernetes Service(AKS)와 같은 컨테이너 서비스로 애플리케이션을 전환하는 것을 고려해 보세요.

9. 사용하지 않는 디스크 찾기 및 삭제

Azure는 가상 머신을 삭제해도 가상 디스크를 삭제하지 않습니다. 디스크는 사용자가 식별하여 삭제할 때까지 계속 사용되며 비용이 발생합니다. Azure Portal의 디스크 화면에는 현재 저장소 계정에서 활성화된 모든 관리 가상 디스크가 표시됩니다. 각 디스크의 소유자를 확인하세요. 이 항목이 비어 있으면 해당 디스크가 어떤 VM에서도 사용되지 않으며 삭제될 가능성이 있음을 의미합니다.

Azure에 관리되지 않는 디스크가 있을 수도 있습니다. 디스크(클래식) 화면 에서 이러한 디스크를 검색하세요 . VM에 연결되지 않은 관리되지 않는 디스크를 찾은 경우 다음 지침 에 따라 스크립트를 실행하여 삭제하세요.

10. 데이터베이스 VM에서 Elastic Database로 이동

Azure에서 SQL Server 또는 기타 데이터베이스 서버를 실행하면 비용이 빠르게 증가할 수 있습니다. VM 자체도 비용이 많이 들고, 데이터베이스 인스턴스의 사용률이 낮은 경우가 많으며, 기존 온프레미스 배포 방식처럼 인스턴스 간에 부하를 분산하는 것도 쉽지 않습니다. 대부분의 경우 PaaS 모델로 전환하면(예: SQL Server 인스턴스에서 Azure SQL 서비스로 이전) 실제 사용된 데이터베이스 리소스에 대해서만 비용을 지불하기 때문에 비용이 크게 절감됩니다.

11. 스토리지 계층화 사용

Azure 배포 시 스토리지는 일반적으로 지속적인 비용에서 큰 부분을 차지합니다. Azure Blob Storage는 프리미엄, 핫, 쿨 및 보관 스토리지 계층(월 GB당 내림차순 가격)과 다양한 중복성 옵션을 제공합니다(중복성이 낮을수록 스토리지 비용이 절감됩니다). Azure 스토리지 가격 책정 관련 문서에서 다른 스토리지 서비스의 가격에 대해 자세히 알아보세요 .

덜 민감하거나 액세스 빈도가 낮은 데이터를 저비용 계층이나 중복성이 낮은 옵션으로 이동하면 비용을 절감할 수 있습니다. 애플리케이션에 스토리지 계층화 자동화를 구축하여 더 이상 필요하지 않은 데이터가 자동으로 저비용 계층으로 이동되도록 하세요.

728x90
728x90

*자본 비용(CAPEX)**과 **운영 비용(OPEX)**은 IT 인프라 투자나 클라우드 이전(Assessment 포함)에서 반드시 구분해야 할 핵심 개념입니다. 아래에서 각각의 정의, 차이점, 구분 이유를 자세히 설명드릴게요.


💰 1. 자본 비용 (CAPEX, Capital Expenditures)

✅ 정의:

  • 초기 투자 비용으로, 물리적인 자산을 구매하거나 구축할 때 드는 비용입니다.
  • 일반적으로 장기간(수년) 사용하는 자산에 대해 선불 형태로 지불합니다.

✅ 예시:

  • 데이터센터 장비 구매 (서버, 스토리지, 네트워크)
  • 소프트웨어 영구 라이선스 구매
  • 빌딩 내 서버룸 공사 비용
  • IT 인프라 구축 컨설팅 비용

✅ 회계 처리:

  • 자산으로 분류되어 감가상각(depreciation) 처리됨 (예: 3~5년간 분할 비용 인식)

🛠 2. 운영 비용 (OPEX, Operating Expenditures)

✅ 정의:

  • 운영 중 반복적으로 발생하는 비용으로, 서비스 유지를 위해 정기적으로 지출하는 비용입니다.
  • 유지, 구독, 사용 기반의 비용입니다.

✅ 예시:

  • 클라우드 서비스 구독 요금 (Azure, AWS 등)
  • 서버 전기료, 냉방/공간 임대료
  • 인건비, 유지보수 계약비
  • 라이선스 연간 갱신 비용
  • 백업/보안/모니터링 서비스 비용

✅ 회계 처리:

  • 매월/매년 지출되며, 해당 회계 기간에 전액 비용 처리

🧾 3. CAPEX vs OPEX 비교

항목CAPEXOPEX
목적 자산 확보 및 장기 투자 운영/유지 및 일상 운영비
지출 시점 초기에 일시불 지출 정기적으로 지출 (월/년)
회계 처리 감가상각 전액 비용 처리
유연성 낮음 (자산 변경 어려움) 높음 (스케일 조절 용이)
예시 서버 구매, 구축 비용 클라우드 사용료, 관리 위탁비

📊 4. Assessment에서 CAPEX와 OPEX를 구분하는 이유

🎯 이유 1: 비용 구조의 변화 분석

  • 온프레미스 → 클라우드 전환 시 CAPEX 중심 구조 → OPEX 중심 구조로 바뀜
  • 기업 입장에서는 지출 형태 변화가 재무적으로 큰 의미를 가짐

🎯 이유 2: ROI, TCO 평가 정확성

  • 클라우드 이전에 따른 총소유비용(TCO) 계산 시:
    • CAPEX(서버 감가상각) vs OPEX(클라우드 사용료)로 비교
  • ROI 산정 시 자본투자 대비 절감되는 연간 OPEX도 포함

🎯 이유 3: 비즈니스 의사결정 지원

  • 자산으로 보유할지(내부 구축) vs 서비스로 사용할지(외부 위탁)
  • 예산 집행 방식에 따라 재무팀, IT팀, 경영진의 관점이 다르므로 구분이 중요

📝 정리 문장 (Assessment 보고서용 표현 예시)

"본 Assessment에서는 기존 인프라의 자본 비용(CAPEX)과 클라우드 전환 시 발생하는 운영 비용(OPEX)을 구분하여 총소유비용(TCO) 분석을 수행하였으며, 비용 구조의 유연성 및 재무 투명성 확보 관점에서 클라우드 기반 모델이 유리함을 도출하였습니다."


 

728x90
728x90

Azure Virtual Desktop의 좋은 점은 AVD 환경에 가입하면 로그인하여 MFA 정책을 통과하면 "기억하기" 옵션을 선택할 수 있다는 것입니다. 이 옵션은 최종 사용자에게 좋은데, 사용자 이름/암호를 다시 입력할 필요가 없기 때문입니다.

"기억해줘"는 환상적이지만 보안 관점에서는 그렇지 않습니다. 보안성이 낮습니다. 사용자와 환경을 보호하려면 클라이언트가 자격 증명을 더 자주 요청하도록 해야 합니다. 따라서 별도의 조건부 액세스 정책을 사용하여 다중 요소 인증을 강제하고 더 자주 요청할 수 있습니다.

조건부 액세스 정책을 만들고 적용합니다.

  1. 검색 창(Azure Portal 상단)에 "조건부 액세스"를 입력합니다. 그리고 Azure AD 조건부 액세스를 엽니다 .
  2. 정책 개요에서 새 정책을 클릭하세요.
  3. 원하는 이름을 입력하세요. 제 경우에는 “CA-AVD”를 사용했습니다.
  4. Assignments 블록 에서 “선택된 사용자 및 그룹 0개”를 클릭합니다. 그리고 모든 사용자를 선택합니다.
  5. "클라우드 앱 또는 작업" 섹션에서 "클라우드 앱 없음..."을 클릭합니다. 앱 선택을 선택합니다 . 목록에서 "Windows Virtual Desktop"을 입력하고 "9cdead84-a8ff ……."로 시작하는 것을 선택합니다.
  6. 클라이언트 앱 섹션 내의 조건을 클릭하고, 최신 인증 클라이언트 섹션에서 브라우저  모바일 앱과 데스크톱 클라이언트를 선택 하고 완료를 클릭합니다. 또한 필요한 경우 "위치"를 구성합니다. 예를 들어 신뢰할 수 있는 위치에서 MFA를 비활성화할 수 있습니다.
  7. 허용 에서 다중 요소 인증 필요를 클릭 하고 "선택한 컨트롤 중 하나 필요"를 선택한 다음 선택을 클릭합니다.
  8. 세션 파트 내에서 시간 제한 또는 다른 세션 제어 하에 이러한 제어를 구성하도록 할 수 있습니다. 제 경우에는 1일의 로그인 빈도가 있습니다. 따라서 매일 사용자는 사용자 이름/비밀번호 또는 mfa 토큰을 다시 입력해야 합니다.
  9. 정책 사용 버튼을 켜기  옮기고 만들기를 클릭하세요.

기본적으로 그게 전부입니다. 올바른 클라우드 앱을 선택하는 데 주의하세요. Azure Virtual Desktop(클래식)을 사용하는 경우 다음 앱을 선택하세요.

Azure Virtual Desktop(앱 ID 5a0aa725-4958-4b0c-80a9-34562e23f3b7)
Azure Virtual Desktop Client(앱 ID fa4345a4-a730-4230-84a8-7d9651b86739)를 사용하면 웹 클라이언트에서 정책을 설정할 수 있습니다 .

Azure Virtual Desktop을 사용하는 경우 대신 이 앱을 선택하세요:
Azure Virtual Desktop(앱 ID 9cdead84-a844-4324-93f2-b2e6bb768d07)

Azure Virtual Desktop Azure Resource Manager Provider(50e95039-b200-4007-bc97-8d5790743a63)라는 앱을 선택하지 마세요. 이 앱은 사용자 피드를 검색하는 데만 사용되며 다중 인증이 없어야 합니다.

728x90
728x90

RVTools is a free tool widely known in the VMware community and is a great resource for VMware administrators. With RVTools, you can manage ESX servers, virtual machines, and vCenter servers. It is also very easy to use and gives specific health check information about the environment, making it an essential VMware utility.

Installing RVTools: A Step-by-step Guide

Installing RVTools on your Windows machine is a straightforward process. Simply download the latest version from the official RVTools website, located here:

Run the installer, and follow the on-screen instructions. Remember, RVTools interacts directly with the VMware vSphere Management SDK. It means you must have VMware Tools installed on your virtual machines.

Navigating RVTools: A Closer Look at the Tabs

RVTools displays information through several tabs, each offering insight into different aspects of your VMware infrastructure. Some of the tabs VIAdmins reference most often include:

  • vInfo tab: Displays general information about your virtual machines.
  • vDisk tab: Provides detailed information about the disk properties of your virtual machines.
  • vHealth tab: Conducts health checks and points out potential issues in your vSphere environment, including hosts, virtual machine

Unleashing the Power of RVTools for VMware Health Checks

RVTools isn’t just a tool for display information. It’s a great utility for conducting health checks within your vSphere environment. The vHealth tab is a “go-to” source of information for vSphere health checks. It checks for things like:

  • VMware tools not installed or out of date
  • Zombie VMDKs
  • CD Drives connected
  • Inconsistent folder names
  • Overprovisioned hosts
  • Other Best practices

These health checks are a great way to make sure your VMware environment runs smoothly. RVTools makes these checks easier by providing specific information and alerts on potential issues.

Leveraging RVTools for VMware Resource Management

RVTools is also an excellent tool for managing resources within your VMware environment. It provides insights into resource pools, memory, disks, partitions, network configurations, and more. You can monitor CPU usage, memory allocation, and even the status of your distributed switches and distributed ports.

RVTools Tabs and Features

The vInfo Tab

The vInfo tab in RVTools provides a comprehensive overview of your virtual machines, including their current power state, connection state, VMware Tools installed status, and ESX host data. Notably, the tab displays whether VMware Tools is installed, ensuring your VMs are running the latest version of this crucial software.

The vDisk Tab

The vDisk tab offers detailed information about your virtual machines’ disks. It provides specific information about each VM’s disks, memory, partitions, and network configurations. It also shows whether CD drives and USB devices are connected, proving useful when troubleshooting hardware issues.

The vHealth Tab

The vHealth tab takes health checks in your vSphere environment to a whole new level. It flags potential inconsistencies, such as outdated VMware Tools or inconsistent folder names, and helps you maintain the overall health of your ESX server and the VMs it hosts.

Efficiently Working with vCenter Server

RVTools interfaces smoothly with vCenter Server, providing administrators with a comprehensive overview of their vSphere environment.

This includes detailed information about ESX hosts, distributed switches, distributed ports, service consoles, VM kernels, and even license info. This data is invaluable when managing complex virtual environments.

Creating a Single XLSX Report

One of RVTools’ useful features is its ability to generate a single XLSX file report containing all the data it collects. Using an XLSX merge utility (included with RVTools), you can consolidate data from multiple vSphere environments into one comprehensive report. This feature saves time and simplifies data analysis, proving invaluable for VMware administrators.

RVToolsMergeExcelFiles.exe -input C:\myfiles\vcsa-site1-vHealth.xlsx;C:\myfiles\vcsa-site2-vHealth.xlsx -output C:\myfiles\allvcenters-vHealth.xlsxCopyCopy

SRM Placeholder and Other Advanced Features

RVTools also includes support for SRM Placeholder VMs used in disaster recovery scenarios. This feature and multipath info for iSCSI, FC, and NFS datastores make RVTools a versatile and powerful tool for managing VMware environments.

Referer. Learn how to configure autostart of virtual machine on VMware.

RVTools FAQs

1. What is RVTools and why is it beneficial for VMware environments? RVTools is a free utility that connects to your vSphere environment and collects detailed information about your ESX hosts, virtual machines, and other components. This tool is beneficial as it helps VMware administrators perform health checks, manage resources, and generate detailed reports efficiently.

2. How does RVTools interface with vCenter Server? RVTools interfaces smoothly with vCenter Server, providing a comprehensive overview of your vSphere environment. This includes details about ESX hosts, distributed switches, distributed ports, service consoles, and VM kernels, aiding in effectively managing your VMware environment.

3. Can RVTools provide specific information about distributed switches and ports? RVTools offers detailed insights into distributed switches and ports in your vSphere environment. It provides information about HBAs, NICs, switches, ports, distributed switches, and service consoles. This network data is invaluable for troubleshooting and planning network expansions.

4. How does RVTools assist with resource management in a VMware environment? RVTools provides detailed data about resource pools, helping VMware administrators manage resources more efficiently. It shows the allocation and usage of CPU, memory, disks, and partitions, which assists in balancing workloads and optimizing resource utilization across your VMware environment.

5. How does RVTools help with reporting? RVTools has a feature to generate a single XLSX report containing all the data it collects. Using an XLSX merge utility, you can consolidate data from multiple vSphere environments into one comprehensive report, simplifying data analysis and saving time for VMware administrators.

728x90
728x90

Update 10th September 2020: vSphere 7.0 (VDS 7.0) and NSX-T 3.0.1+ are supported since the HCX R143 release which has been made available on September 8, 2020

https://docs.vmware.com/en/VMware-HCX/services/rn/VMware-HCX-Release-Notes.html 

Most people think that VMware HCX is a only migration tool that helps you moving workloads to a vSphere based cloud like VMware Cloud on AWS, Azure VMware Solution or Google Cloud VMware Engine. But it can do so much more for you than only application or workload migrations. HCX is also designed for workload rebalancing and business continuity across data centers or VMware clouds. Why I say “across VMware clouds” and not only “clouds”?

A few years ago everyone thought or said that customers will move all their workloads to the public cloud and the majority of them don’t need local data centers anymore. But we all know that this perception has changed and that the future cloud operation is model hybrid.

A hybrid cloud environment leverages both the private and public clouds to operate. A multi-cloud environment includes two or more public cloud vendors which provide cloud-based services to a business that may or may not have a private cloud. A hybrid cloud environment might also be a multi-cloud environment.

We all know that the past perception was an illusion and we didn’t have a clue where the hyperscalers like AWS, Azure or GCP would be in the next 5 or 7 years. And I believe that even the AWS and Microsoft didn’t expect what is going to happen since we observed interesting shifts in the last few years.

Amazon Web Services (AWS) has been launched 14 years ago (2006) to provide web services from the cloud. At AWS re:Invent 2018 the CEO Andy Jassy announced AWS Outposts because their customers have been asking for an AWS option on-premises. In the end, Outpost is just an extension of an AWS region into the own data center, where you can launch EC2 instances or Amazon EBS volumes locally. AWS already had some hybrid services available (like Storage Gateway) but here we talk about infrastructure and making your own data center part of the AWS Global Infrastructure.

Microsoft Azure was released in 2010 and the first technical preview of Azure Stack has been announced in 2016. So, Microsoft also realized that the future cloud model is a hybrid approach “that provides consistency across private, hosted and public clouds”.

Google Cloud Platform (GCP) offers cloud computing services since 2008. Eleven years later (in 2019) Google introduced Anthos that you can “run an app anywhere –  simply, flexibly and securely”.

All the hyperscalers changed their cloud model to provide customers a consistent infrastructure with consistent operations and management as we understand now.

VMware is coming from the other end of this hybrid world and has the same overall goal or vision to make a hybrid or multi-cloud reality. But with one very important difference. VMware helps you to abstract the complexity of a hybrid environment and gives you the choice to run your workloads in any cloud infrastructure with a cloud-agnostic approach.

As organizations try to migrate their workloads to the public, they face multiple challenges and barriers:

  • How can I migrate my workload to the public cloud?
  • How long does it take to migrate?
  • What about application downtime?
  • Which migration options do I have?
  • Which cloud is the best destination for which workloads?
  • Do I need to refactor or develop some applications?
  • Can I do a lift and shift migration and modernize the application later?
  • How can I consistently deploy workloads and services for my multi-cloud?
  • How can I operate and monitor (visibility and observability) all the different clouds?
  • What if tomorrow one the public cloud provider is not strategic anymore? How can I move my workloads away?
  • How can I control costs over all clouds?
  • How can I maintain security?
  • What about the current tools and 3rd party software I am using now?
  • What if I want to migrate VMs back from the public cloud?
  • What if I want to move away/back somewhen from a specific cloud provider?

In summary, the challenges with a hybrid cloud are about costs, complexity, tooling and skills. Each public cloud added to your current on-premises infrastructure is in fact a new silo. If you have the extra money and time and don’t need consistent infrastructures and consistent operations and management, you’ll accept the fact that you have a heterogeneous environment with different technology formats, skill/tool sets, operational inconsistencies and security controls.

If you are interested in a more consistent platform then you should build a more unified hybrid cloud. Unified means that you provide consistent operations with the existing skills and tools (e.g. vCenter, vRealize Automation, vRealize Operations) and the same policies and security configuration over all clouds – your data center, public cloud or at the edge.

To provide such a cloud agnostic platform you need to abstract the technology format and infrastructure in the public cloud. This is why VMware built the VMware Cloud Foundation (VCF) platform that delivers a set of software-defined services for compute, storage, networking, security and cloud management for any cloud.

VMC on AWS, Azure VMware Solution, Google Cloud VMware Engine and all the other hybrid cloud offerings (IBM, Oracle, Alibaba Cloud, VCPP) are based on VMware Cloud Foundation. This is the underlying technology stack you would need if your goal is to be independent and to achieve workload mobility between clouds. With this important basic understanding we can take a closer look at VMware HCX.

VMware HCX Use Cases

HCX provides an any-to-any vSphere workload mobility service without requiring retrofit as we use the same technology stack in any cloud. 

HCX enables you to schedule application migrations of hundreds or thousands of vSphere VMs within your data centers and across public clouds without requiring a reboot or a downtime.

If you would like to change the current platform or have to modernize your current data center, HCX allows you to migrate workloads from vSphere 5.x and non-vSphere (Hyper-V and KVM) environments.

Workload rebalancing means providing a mobility platform across cloud regions and cloud providers to move applications and workloads at any time for any reason.

Workload mobility is cool and may be the future but is not possible today as the public cloud’s egress costs would be way too high at the moment. Let’s say you pay $0.05 per GB when you move data away from the public cloud to any external destination, this would generate costs of $2.50 for a 50GB virtual machine.

Not that much, right? If you move away 500 VMs, the bill would list $1’250 for egress costs. Evacuating VMs from one public cloud to another one is not so expensive if it happens three or four times a year. But if the rebalancing should happen at a higher cadence, the egress costs would get too high. But we can assume that this fact will change in the future as the public cloud computing prices will come down in the future. 

HCX Components and Services

HCX is available with an Advanced and Enterprise license. The Advanced license services are standard with HCX and are also included in the HCX Enterprise license. The Enterprise license is needed when you migrate non-vSphere workloads into a vSphere environment. This capability is called OS Assisted Migration (OSAM).

The HCX Advanced features are included in a NSX Data Center Enterprise Plus license. With a managed service like VMware Cloud on AWS or Azure VMware Solution HCX Advanced is already be included.

If you want to move workloads from a vSphere environment to a vSphere enabled public cloud, you don’t need the complete VMware Cloud Foundation stack at the source site:

  • On-premises vSphere version 5.5 and above
  • Minimum of 100 Mbps bandwidth between source and destination
  • Virtual switch based on vDS (vSphere Distributed Switch), Cisco Nexus 1000v or vSphere Standard Switch
  • Minimum of virtual machine hardware version 9
  • VMs with hard disks not larger than 2TB

Depending on the HCX license and services you need, you have to deploy some or all of the HCX components. HCX comprises components and appliances at the source and destination sites.

The HCX Connector services and appliances are deployed at the destination site first before you are going to deploy the virtual appliances at the source site (HCX Interconnect appliance).

After you deployed the appliances at the source site, you can create the site pairing.

As soon as you have installed HCX in both sites, you can manage and configure the services within the vSphere Client.

After a successful site pairing, you can start to create the HCX Service Mesh.

The Multi-Site Service mesh is used to create a secure optimized transport fabric between any two sites managed by HCX. When HCX Migration, Disaster recovery, Network Extension, and WAN Optimization services are enabled, HCX deploys Virtual Appliances in the source site and corresponding “peer” virtual appliances on the destination site. The Multi-Site Service Mesh enables the configuration, deployment, and serviceability of these Interconnect virtual appliance pairs.

In the HCX site-to-site architecture, there is notion of an HCX source and HCX destination environment. Depending on the environment, there is a specific HCX installer:

HCX Connector (previously HCX Enterprise) or HCX Cloud. HCX Connector is always deployed as the source. HCX Cloud is typically deployed as the destination, but it can be used as the source in cloud-to-cloud deployments. In HCX-enabled public clouds, the cloud provider deploys HCX Cloud. The public cloud tenant deploys HCX Connector on-premises.
The source and destination sites are paired together for HCX operations. 

In both the source and destination environments, HCX is deployed to the management zone, next to each site’s vCenter Server, which provides a single plane (HCX Manager) for administering VMware HCX. This HCX Manager provides a framework for deploying HCX service virtual machines across both the source and destination sites. VMware HCX administrators are authenticated, and each task authorized through the existing vSphere SSO identity sources. VMware HCX mobility, extension, protection actions can be initiated from the HCX User Interface or from within the vCenter Server Navigator screen’s context menus.

In the NSX Data Center Enterprise Plus (HCX for Private to Private deployments), the tenant deploys both source and destination HCX Managers.

The HCX-IX service appliance provides replication and vMotion-based migration capabilities over the Internet and private lines to the destination site whereas providing strong encryption, traffic engineering, and virtual machine mobility.

The VMware HCX WAN Optimization service appliance improves performance characteristics of the private lines or Internet paths by applying WAN optimization techniques like the data de-duplication and line conditioning. It makes performance closer to a LAN environment. It accelerates on-boarding to the destination site using Internet/VPN- without waiting for Direct Connect/MPLS circuits.

The VMware HCX Network Extension service appliance provides a late Performance (4–6 Gbps) Layer 2 extension capability. The extension service permits keeping the same IP and MAC addresses during a Virtual Machine migration. Network Extension with Proximity Routing provides the optimal ingress and egress connectivity for virtual machines at the destination site.

 

Using VMware HCX OS Assisted Migration (OSAM), you can migrate guest (non-vSphere) virtual machines from on-premise data centers to the cloud. The OSAM service has several components: the HCX Sentinel software that is installed on each virtual machine to be migrated, a Sentinel Gateway (SGW) appliance for connecting and forwarding guest workloads in the source environment, and a Sentinel Data Receiver (SDR) in the destination environment.

The HCX Sentinel Data Receiver (SDR) appliance works with the HCX Sentinel Gateway appliance to receive, manage, and monitor data replication operations at the destination environment.

HCX Migration Types

VMs can be moved from one HCX-enabled data center using different migration technologies or types.

HCX cold migration uses the VMware NFC (Network File Copy) protocol and is automatically selected when the source VM is powered off.

HCX vMotion

  • This option is designed for moving a single virtual machine at a time
  • There is no service interruption during the HCX vMotion migration
  • Encrypted vMotion between legacy source and SDDC target
  • Bi-directional (Cross-CPU family compatibility without cluster EVC)
  • In-flight Optimization (deduplication/compression)
  • Compatible from vSphere 5.5+ environments (VM HW v9)

HCX Bulk Migration

  • Bulk migration uses the host-based replication (HBR) to move a virtual machine between HCX data centers
  • This option is designed for moving virtual machines in parallel (migration in waves)
  • This migration type can set to complete on a predefined schedule
  • The virtual machine runs at the source site until the failover begins. The service interruption with the bulk migration is equivalent to a reboot
  • Encrypted Replication migration between legacy source and SDDC target
  • Bi-directional (Cross-CPU family compatibility)
  • WAN Optimized (deduplication/compression)
  • VMware Tools and VM Hardware can be upgraded to the latest at the target.

HCX Replication Assisted vMotion

VMware HCX Replication Assisted vMotion (RAV) combines advantages from VMware HCX Bulk Migration (parallel operations, resiliency, and scheduling) with VMware HCX vMotion (zero downtime virtual machine state migration).

HCX OS Assisted Migration

This migration method provides for the bulk migration of guest (non-vSphere) virtual machines using OS Assisted Migration to VMware vSphere on-premise or cloud-based data centers. Enabling this service requires additional HCX licensing.

 

  • Utilizes OS assisted replication to migrate (conceptually similar to vSphere replication)
  • Source VM remains online during replication
  • Quiesce the source VM for final sync before migration
  • Source VM is powered off and the migrated VM is powered on in target site, for low downtime switchover
  • VMware tools is installed on the migrated VM

Cross-Cloud Mobility

Most customers will probably start with one public cloud first, e.g. VMC on AWS, to evaluate the hybridity and mobility HCX delivers. Cross-cloud monility is maybe not a requirement today or tomorrow but gets more important when your company has a multi-cloud strategy which becomes reality very soon.

If you want to be able to move workloads seamlessly between clouds, extend networks and protect workloads the same way across any cloud, then you should consider a VMware platform and use HCX.

Let’s take network and security as an example. How would you configure and manage all the different network, security, firewall policies etc. in your different clouds with the different infrastructure and security management consoles?

If you abstract the hyperscaler’s global infrastructure and put VMware on top, you could in this case use NSX (software-defined networking) everywhere. And because all the different policies are tied to a virtual machine, it doesn’t matter anymore if you migrate a VM from host to host or from cloud to cloud.

This is what you would call consistent operations and management which is enabled by a consistent infrastructure (across any cloud).

And how would you migrate workloads in a very cost and time efficient way without a layer 2 stretch? You would have to take care of re-IPing workloads and this involves a lot of changes and dependencies. If you have hundreds of applications then the cloud migration would be a never ending project with costs you could not justify.

In the case you need to move workload back to your own on-premises data center, HCX also gives you this advantage.

You have the choice in which cloud you want to run your applications, at any time.

 

HCX and vSphere 7

At the time of writing HCX has no official support for vSphere 7.0 yet. I tested it in my home lab and ran into an error while creating the Service Mesh. At least one other colleague had the same issue with vSphere 7 using NSX-T 3.0 and VDS 7.0.

I would like to thank Danny Stettler for reviewing and contributing. 🙂 Big kudos to you, Danny! 🙂

I hope the article has helped you to get an overview what HCX and a hybrid cloud model really mean. Drop a comment and share your view and experience when it comes to cloud strategies and migrations.

728x90
728x90
  • 시나리오 : 최근의 업무에서 고객 중 한 명이 IT 자산의 패치 및 규정 준수 보고를 관리하는 데 따르는 어려움을 설명했습니다. 하이브리드 설정이었고 Azure를 포함한 여러 클라우드에 인프라가 분산되어 있었습니다. Windows가 있었지만 많은 부분이 SUSE 및 RedHat Linux 서버에 있었습니다. 고객은 중앙에서 패치 및 보고를 자동화하기를 원했습니다.
  • 해결책 : 제목에서 알 수 있듯이 저희는 그들에게 Azure Update Manager를 도입하라고 요청했습니다. 온프레미스와 멀티 클라우드 에스테이트에 모두 적용되었습니다. 고객은 Azure Monitor를 사용하여 만든 규정 준수 대시보드를 가지고 있으며, 이는 요구 사항에 따라 사용자 지정되었습니다.

Azure 업데이트 관리자란 무엇입니까?

Azure Update Manager는 온프레미스 서버와 GCP, AWS, OCI, Azure와 같은 클라우드 공급자에 호스팅된 서버에 대한 패치를 예약하는 데 사용되는 클라우드 기반 솔루션입니다. Azure Update Manager 자체는 클라우드 서비스이므로 어플라이언스로 설치할 수 없습니다. 이 서비스는 추가 비용 없이 Azure에서 기본적으로 활성화됩니다. 따라서 요새나 방화벽처럼 이 서비스를 배포할 필요가 없습니다. 모든 서버는 확장 기능을 통해 AUM 서비스에 보고합니다. 따라서 기본적으로 후드 아래에는 Azure VM 또는 Azure Arc 지원 VM에 설치된 확장 기능입니다. 맞습니다. Azure Arc 지원 VM입니다. Azure 외부에 호스팅된 VM이 있고 Azure Update Manager를 사용하려면 먼저 해당 서버에서 Arc를 활성화해야 합니다. 그런 다음 AUM을 확장 기능으로 활성화할 수 있습니다.

서버가 AUM에 온보딩되면 AUM 서비스에 규정 준수 상태를 보고하고 Azure Portal에 있는 AUM 콘솔에서 패치를 예약할 수 있습니다. Azure Update Manager의 주요 작업은 다양한 구성에 따라 서버에 패치를 다운로드하도록 지시하는 것입니다. 머신에 패치를 다운로드할 위치를 지시하지 않습니다. 예를 들어 리포지토리 서버를 제공하지 않습니다. VM/서버가 AUM에서 패치를 다운로드하라는 지침을 받으면 머신의 로컬 구성에 따라 패치를 획득합니다. WSUS(Windows Server Update Server)와 같거나 인터넷을 통해 직접 또는 프록시 서버를 통해 패치를 획득합니다. 서버는 패치를 다운로드하기 위해 연결하고 완료되면 최신 규정 준수 상태를 AUM에 보고합니다.

Arc란 무엇입니까?

AUM에 대해 논의하고 심층적으로 살펴보기 전에 Arc에 대해 간략하게 살펴보겠습니다. Arc는 단일 창, 즉 Azure에서 모든 워크로드를 보고 중앙에서 관리할 수 있는 플랫폼을 제공합니다. Azure Monitor, Azure Update Manager, Defender 및 기타 여러 솔루션과 같은 Azure 서비스를 온프레미스 서버에 배포하는 데 도움이 됩니다. 이는 먼저 모든 서버에 Azure 연결된 머신 에이전트를 설치하여 수행됩니다. CMA가 설치되면 머신은 Arc 지원 서버가 됩니다. 여기에서 확장을 통해 원하는 Azure 솔루션을 활성화할 수 있습니다.

Arc-Enabled VM에 배포할 수 있는 확장 프로그램이 많이 있습니다. 아래 링크에 설명되어 있습니다.

https://learn.microsoft.com/en-us/azure/azure-arc/servers/manage-vm-extensions#windows-extensions

Arc Key Vault 확장을 사용하여 온프레미스 서버의 인증서 갱신에 대한 블로그 게시물을 작성했습니다. 아래에서 블로그를 찾을 수 있습니다.

https://www.azuredoctor.com/posts/arc-keyvault/

Windows 서버에서 AUM이 작동하는 방식:

이전에 언급했듯이 AUM은 서버가 패치 업데이트를 수신하고 연결할 리포지토리 서버를 제공하지 않고, 대신 오케스트레이터 역할을 하여 지정한 일정에 따라 서버에 패치를 다운로드하도록 알립니다. 예를 들어, 매월 마지막 날, 패치 화요일 이틀 후, 주간 또는 월간 타임라인 등입니다. 서버가 지침을 받으면 WSUS 리포지토리 또는 Microsoft 업데이트에 연결합니다. 이는 머신에 설정된 구성에 따라 달라집니다.

저는 고객이 데이터센터에 로컬로 WSUS 서버를 두고, Azure와 다른 클라우드 공급자에 WSUS를 두고, Windows 서버가 인터넷을 통해 Microsoft Update에서 직접 패치를 다운로드하지 않고 WSUS를 로컬 저장소로 사용하는 것을 보았습니다. 하지만 WSUS에 의존하고 싶지 않다면 프록시나 방화벽을 통해 Windows 업데이트 URL을 직접 허용 목록에 추가하면 서버가 그에 따라 최신 업데이트를 다운로드합니다.

Linux에서 AUM이 작동하는 방식:

리눅스에서 AUM의 동작은 윈도우 서버와 거의 같습니다. AUM은 리눅스 저장소를 제공하지 않지만 시스템이 구성된 저장소에서 업데이트를 받도록 합니다. AUM의 역할은 일정에 따라 업데이트를 트리거하는 것입니다.

Linux를 사용하는 AUM에는 여러 옵션이 있습니다. Linux 서버가 호스팅되는 위치에 따라 다릅니다.

온프레미스:

Linux 서버가 온프레미스에 호스팅된 경우 로컬 개인 저장소 또는 공개 저장소를 사용하여 OEM에서 최신 업데이트를 다운로드해야 합니다. SUSE 또는 RedHat 서버가 있고 SUSE Manager 또는 RedHat 위성 서버에 대한 라이선스가 있는 경우 이러한 서버는 저장소 역할을 하고 AUM은 규정 준수 확인, 패치 업데이트 일정 및 보고를 위한 오케스트레이터 역할을 합니다. SUSE Manager와 RedHat Satellite는 패치에 사용되며 유료 버전입니다. 신뢰할 수 있고 저렴하다고 생각되는 모든 저장소 서버 타사(3P)를 사용할 수 있습니다.

클라우드의 Linux:

Linux 서버가 Azure, GCP 또는 AWS에 호스팅된 경우. 특히 RedHat 및 SUSE와 같은 공급업체이고 Marketplace에서 라이선스를 구매했거나 Marketplace 이미지에서 배포한 경우 이러한 공급업체는 서버가 최신 업데이트를 다운로드할 수 있는 해당 지역에 로컬로 퍼블릭 클라우드 업데이트 인프라를 제공합니다. VNET 또는 VPC 외부이지만 동일한 지역 내의 퍼블릭 연결이 됩니다.

아래는 각 배포판의 링크와 업데이트 인프라를 제공하는 방식에 대한 설명입니다.

https://www.suse.com/c/accessing-suse-updates-in-aws-when-do-you-need-a-private-repository/

https://www.suse.com/c/accessing-the-public-cloud-update-infrastructure-via-a-proxy/

https://www.suse.com/c/azure-public-cloud-update-infrastructure-101/

https://www.suse.com/c/accessing-the-public-cloud-update-infrastructure-via-a-proxy/

https://learn.microsoft.com/en-us/azure/virtual-machines/workloads/redhat/redhat-rhui?tabs=rhel7

https://access.redhat.com/products/red-hat-update-infrastructure

아래 아키텍처는 Azure Arc와 Public 엔드포인트 및 Azure Private 엔드포인트의 연결을 보여줍니다. Private 엔드포인트를 배치할 위치도 보여줍니다.

아래 아키텍처는 WSUS와 Linux Repo 서버의 배치를 보여줍니다. 멀티 클라우드 설정을 보여줍니다.

이 아키텍처의 Visio 파일 다운로드

Azure Update Manager 비용:

서비스 비용에 대해 논의해 보겠습니다. AUM은 클라우드 서비스입니다. 어플라이언스가 없고 어플라이언스 고가용성 등에 비용을 지불할 필요가 없습니다. 이 모든 것이 서비스에 내장되어 있으므로 이 모든 것을 처리할 필요가 없습니다. Azure Servers용 AUM은 무료입니다. 바로 AUM을 활용할 수 있습니다. Azure Stack HCI 온프레미스에서 호스팅되는 서버가 있는 경우 AUM은 무료입니다. 온프레미스에서 호스팅되는 서버에는 요금이 부과됩니다. 서버당 월 5달러가 청구됩니다. Arc 지원 서버의 AUM은 세 가지 조건에서 무료입니다.

  1. Arc를 통해 확장 보안 업데이트를 활성화한 경우
  2. Defender for Servers Plan 2를 사용하는 경우
  3. Azure Arc가 제공하는 Windows Server Management를 사용하면 활성 소프트웨어 보증이 있는 Windows Server 라이선스나 활성 구독 라이선스인 Windows Server 라이선스를 사용하는 고객은 AUM을 무료로 얻을 수 있습니다.

위 시나리오에 대한 자세한 내용은 아래 링크에서 확인하세요. https://learn.microsoft.com/en-us/azure/update-manager/update-manager-faq#are-there-scenarios-in-which-arc-enabled-server-isnt-charged-for-azure-update-manager

https://techcommunity.microsoft.com/blog/azurearcblog/announce-general-availability-windows-server-management-enabled-by-azure-arc/4303854

이 블로그가 여러분이 AUM을 더 빠르게 배포하고 올바른 아키텍처 패턴을 따르는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

728x90
728x90

이 블로그는 아직 Azure ESAN 저장소를 탐색하지 않았지만 ESAN과 그 기본 사항에 대해 들어봤지만 워크로드에 어떤 가치를 제공하는지 모르는 사람들을 위한 것입니다. 이 블로그를 읽으면 다음 질문에 답할 수 있는 통찰력을 얻을 수 있습니다.

  1. ESAN을 사용해야 하는 이유는 무엇인가요? 디스크 관리 대신 이 서비스를 선택하면 가격상 이점이 있나요? 그리고 얼마나 비용을 절감할 수 있나요?
  2. 프로덕션 워크로드에 ESAN을 고려할 수 있나요?
  3. 내 워크로드에 ESAN을 배포하기 전에 고려해야 할 제한 사항은 무엇입니까?

ESAN 볼륨을 단계별로 생성하고 VM에 연결하는 방법은 다루지 않습니다. 이는 Microsoft 학습 문서에서 자세히 다룹니다.

기본 정보

시작해 보겠습니다. Azure Elastic SAN(ESAN)은 2022년 10월에 출시되었습니다. ESAN은 VM, AKS 및 AVS를 마운트하는 데 사용할 수 있는 iSCSI LUN을 제공합니다. 2022년 이후로 Elastic SAN에 많은 개선이 있었고 현재 대부분의 Azure 지역에서 이 서비스를 지원합니다.

Elastic SAN이 IOPS와 스토리지를 계산하는 방법 - ESAN을 만들고 기본 단위를 기반으로 1TiB씩 증가하는 총 IOPS와 처리량을 얻습니다. 1TiB의 기본 단위는 5000 IOPS와 200MBps 처리량을 제공합니다. 저렴한 스토리지만 원하는 경우 IOPS/처리량은 제공하지 않고 추가 스토리지만 제공하는 추가 용량 단위를 추가할 수 있습니다.

Elastic SAN의 한 가지 중요한 측면은 Elastic SAN을 생성할 때마다 ESAN의 전체 IOPS와 처리량이 여러 볼륨에서 공유된다는 것입니다.예를 들어, ESAN 20TiB를 생성하면 총 100,000 IOPS와 4000MBps 처리량을 얻게 됩니다.각각 200Gb의 볼륨 두 개를 생성하면 개별적으로 최대 80K IOPS와 1280MBps 처리량까지 확장할 수 있습니다.그러나 Elastic SAN의 부모 Base 단위에서 제공하는 총 IOPS와 처리량을 공유합니다.한 VM이 60K IOPS를 얻고 동시에 두 번째 VM에 50K IOPS가 필요한 경우 두 번째 VM은 40K IOPS만 얻게 되는데, 이는 ESAN의 20TiB에 대한 최대 한도가 100K IOPS이기 때문입니다.
최대 80K IOPS를 얻는 데 필요한 최소 볼륨은 106GiB이고 최대 1280GB/s를 얻으려면 최소 21GiB가 필요합니다.

이제 여러 애플리케이션에 대한 스토리지 요구 사항을 결합하여 단일 Elastic SAN에 넣을 수 있습니다. 비용과 통합 스토리지 이점을 얻을 수 있습니다.
기억해야 할 한 가지는 IOPS와 처리량이 동시에 필요한 모든 중요한 프로덕션 애플리케이션을 단일 ESAN에 넣을 수 없다는 것입니다. 따라서 여러 ESAN 인스턴스에 균등하게 분산해야 합니다. 이는 모든 앱이 동시에 필요한 경우 IOPS/처리량 때문에 ESAN을 해당 한계까지 확장해야 하거나 그렇지 않으면 ESAN이 조절을 시작하기 때문입니다.
200개의 볼륨 그룹을 가질 수 있으며, 하나의 볼륨 그룹은 최대 1000개의 볼륨을 가질 수 있습니다. 따라서 단일 ESAN에 많은 애플리케이션 세트를 모을 수 있습니다.

ESAN 볼륨 데이터는 네트워크를 통해 전송됩니다.

Azure 관리자라면 모든 VM에 디스크 및 네트워크 제한이 할당되어 있다는 사실을 이미 알고 계실 것입니다.VM SKU를 낮추면 제한도 낮아집니다.D4s_v5 크기의 VM에 4TB 프리미엄 SSD 디스크를 연결하는 경우 디스크 IOPS가 7500 IOPS이더라도 이 정도의 IOPS를 사용할 수 없습니다.VM 자체가 최대 6400 IOPS를 지원하기 때문입니다.더 높은 CPU와 메모리가 필요하지 않더라도 VM 크기를 변경하고 더 높은 SKU를 선택해야 합니다.Azure Elastic SAN은 네트워크를 사용하여 저장소에 연결하므로 VM 디스크 제한 제한은 적용되지 않습니다.하지만 이 경우에도 VM 네트워크 제한은 계속 적용됩니다.그러나 VM 네트워크 처리량은 항상 더 높은 편입니다.ESAN에 대한 iSCSI 기반 연결을 실행하는 것과 함께 워크로드에 충분한 네트워크 처리량이 남아 있는지 확인해야 합니다.

아래에서는 IOPS와 처리량을 충족하기 위해 다음으로 사용 가능한 SKU로 이동하는 위와 같은 문제에 직면했다면 관리형 디스크에서 Elastic SAN Volumes로 디스크를 이동하면 얼마나 많은 비용을 절감할 수 있는지 예를 들어 설명하겠습니다.

이제 ESAN이 디스크 스토리지와 비교했을 때 어떻게 배치되는지 비교해 보겠습니다. 또한 지금은 4TiB의 디스크 하나만 고려하겠습니다. ESAN을 고려할 때 일반적으로 더 큰 스토리지 크기의 조합인 Base Unit을 배포하면 모든 볼륨에서 사용할 수 있는 훨씬 더 높은 처리량을 얻을 수 있습니다. 이는 단일 디스크에서는 불가능합니다. 단일 VM에만 연결되어 있고 IOPS를 다른 VM과 공유할 수 없기 때문입니다.
참고: 더 높은 IOPS와 처리량을 제공하는 Performance Plus의 미리보기 기능은 고려하지 않았습니다. 자세한 내용은 아래 링크에서 확인하세요.

https://learn.microsoft.com/en-us/azure/virtual-machines/disks-enable-performance?tabs=azure-powershell

ESAN 대 프리미엄 SSD

Azure Premium SSD인 프로덕션 등급 디스크로 시작하겠습니다. 프로덕션 워크로드에 가장 많이 사용되는 디스크 중 하나입니다.
보시다시피 7500 IOPS와 250MB/s 처리량을 제공하는 4TB 디스크가 있었습니다. 이를 충족하기 위해 Elastic SAN의 2TiB 기본 단위와 용량 단위의 나머지 2TiB를 가져와야 했습니다.
디스크 하나만 있으면 월 266.40달러를 절약할 수 있습니다.

ESAN 대 표준 SSD

제 경험상, 고객은 종종 비생산적 작업 부하에 표준 SSD를 사용합니다. 처리량과 IOPS가 꽤 낮지만, 비생산적 작업 부하에 대한 저렴한 대안이 될 수 있으며, 여기서는 성능을 희생하여 비용을 절감할 수 있습니다.
그러나 이제 표준 SSD를 프리미엄인 Elastic SAN과 비교하면 아래 표에서 볼 수 있듯이 훨씬 더 높은 IOPS와 처리량을 얻을 수 있고 여전히 비용을 절감할 수 있습니다.
ESAN을 사용하면 5K IOPS를 얻고 표준 SSD는 4TiB의 작업 부하에서 500 IOPS를 제공합니다.
여전히 이러한 성능 향상으로 월 약 29.28달러의 비용을 절감할 수 있습니다.

ESAN 대 프리미엄 SSD v2

위의 프리미엄 v1 디스크 예를 살펴보면, 왜 프리미엄 SSD v2와 비교하지 않는지 궁금할 수 있습니다. 프리미엄 SSD v2는 훨씬 더 나은 성능을 제공하고 프리미엄 SSD v1 디스크보다 비용이 저렴합니다. 그럼, 여기 있습니다. 프리미엄 SSD v2의 기본 가격으로 3000 IOPS와 125MB/s 처리량을 얻을 수 있습니다. 이것을 ESAN과 비교하면 ESAN의 기본 단위 1개와 용량 단위 3TiB를 얻을 수 있으며, 한 달에 약 70.90달러를 절약할 수 있습니다. 이 시나리오에는 몇 가지 고려 사항이 있습니다.

  1. ESAN은 지역 또는 지역적으로 배포된 VM에서 사용할 수 있습니다. 그러나 Premium SSDv2는 VM이 ​​영역에 있어야 합니다.
  2. VM이 가용성 집합에 있거나 지역적으로 배포된 경우 이 디스크를 사용할 수 없습니다.
  3. ESAN은 특정 구역에 배포해야 하지만, VM은 지역 내의 모든 구역에서 연결할 수 있습니다. 더 나은 성능을 얻으려면 VM과 ESAN을 같은 구역에 두는 것이 좋습니다.

AVS 시나리오: ESAN 대 ANF 표준

ESAN은 iSCSI 프로토콜을 통해 VM에 연결된 블록 스토리지입니다. ANF는 NFS 또는 SMB 프로토콜을 통해 사용할 수 있는 NAS입니다.
ESAN은 Azure VMware 솔루션 시나리오에서도 사용할 수 있으므로 ESAN과 ANF를 비교하는 것이 좋습니다. ANF는 AVS 워크로드에도 지원되기 때문입니다.
일반적인 읽기/쓰기 I/O인 8KB IOPS를 고려해 보겠습니다. 데이터베이스가 있는 경우 더 높을 수 있으며 웹 또는 앱 서버인 경우 달성된 IOPS가 증가하거나 감소할 수 있는 기준에 따라 더 낮을 수도 있습니다.
표준 계층인 저렴한 ANF 계층을 고려해 보았습니다.
ESAN을 고려하면 월 271달러의 전반적인 절감 효과를 얻을 수 있습니다.

하지만 강조하고 싶은 몇 가지 고려사항이 있습니다.

  1. ESAN과 함께 AVS를 사용하려면 ESAN에 대한 개인 엔드포인트를 배포해야 합니다. 개인 엔드포인트의 가격을 알고 있다면 GB당 인바운드 및 아웃바운드 데이터 전송에 약간의 요금이 부과됩니다. 이는 개인 엔드포인트 가격 페이지에서 확인할 수 있습니다. 따라서 매월 ESAN으로의 데이터 전송에 따라 대역폭 비용이 발생합니다. AVS와 함께 ANF를 배포할 때는 이런 일이 발생하지 않습니다. ANF는 VNET에 배포되므로 관련 데이터 전송 비용을 걱정할 필요가 없습니다.
  2. ESAN은 현재 스토리지만 제공하지만 ANF는 AVS와 함께 스토리지 측면에서 성숙한 서비스입니다. ANF 데이터 저장소에 호스팅된 VM에 대한 클라우드 백업 확장을 제공합니다. https://learn.microsoft.com/en-us/azure/azure-vmware/install-cloud-backup-virtual-machines
  3. ANF는 Azure의 SAP에서 지원되지만 ESAN은 아직 지원되지 않습니다.

제한 사항 및 고려 사항:

Elastic SAN은 불과 2년 된 서비스이므로 많은 개선 사항이 아직 로드맵에 있습니다. 워크로드에 ESAN을 배포하는 것을 고려하기 전에 아래 고려 사항을 염두에 두어야 합니다.

  1. Azure 사이트 복구를 통해 VM을 다른 지역으로 복제하는 경우 VM에 연결된 ESAN 볼륨은 지원되지 않습니다.
  2. Azure Backup을 통한 ESAN Volume 백업은 현재 GA가 아닙니다. 현재로서는 공개 미리보기에서 사용할 수 없습니다.
  3. 백업은 미리보기에 있는 볼륨 스냅샷을 통해 사용할 수 있으며, 이는 ESAN 기능입니다. 이러한 백업 및 DR 기능은 Azure Marketplace 지원 어플라이언스를 통해 백업 도구를 사용하는 경우 타사를 통해 달성할 수 있습니다.
  4. Azure VM의 SAP는 현재 ESAN에서 지원되지 않으며, Azure Managed Disk 및 ANF에서만 지원됩니다.
  5. 일반 디스크의 스냅샷을 찍은 다음 이를 통해 ESAN 볼륨을 만들 수 있습니다. 이는 미리보기 상태이며 ESAN 볼륨으로 이동하는 데 사용할 수 있습니다.
  6. DC 마이그레이션을 평가하고 크기를 조정하는 데 Azure Migrate를 사용하는 경우 해당 도구는 현재 마이그레이션뿐 아니라 평가 대상으로도 관리형 디스크만 지원합니다.
    https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-snapshots?tabs=azure-portal#create-a-volume-from-a-managed-disk-snapshot

위의 비교와 설명이 ESAN이 귀하의 배포에 더 적합한지 확인하고 비용 절감을 달성하는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

728x90
728x90
  • 시나리오 : 고객이 하나의 Enterprise 계약 등록을 했고, 그 등록 내에 두 개의 회사를 두고 싶어하는 시나리오를 여러 번 접했습니다. 이 회사들은 같은 모회사에 속해 있지만, IT 인프라와 정책이 다르기 때문에 별도의 Entra Tenants(Azure AD)를 원했습니다. 하지만 청구 파트너를 통해 서명된 단일 Enterprise 계약 등록을 공유하고 싶어했습니다.
  • 해결책 : 청구 파트너를 통해 Enterprise Agreement(EA)에 서명하면 결코 단일 Entra 테넌트에 묶이지 않습니다. 하나의 EA는 여러 Entra 테넌트와 연결된 여러 Enrollment 계정을 가질 수 있습니다.

이 블로그는 합병, 인수 전환에 참여하는 사전 판매 담당자가 사용할 수 있습니다. 또한 여러 계약 유형 간에 구독을 이동하는 방법을 알고 싶다면 이전 블로그 게시물을 참조할 수 있습니다. https://www.azuredoctor.com/posts/mergers-and-acquisitions-on-azure/

우리는 한 회사가 IT 인프라를 별도로 관리하는 분사 법인에 대해 별도의 테넌트를 만들고 싶어하지만, 모회사와 Azure 청구를 공유하고 싶어하는 시나리오를 살펴볼 것입니다. 이는 두 번째 법인이 더 큰 회사 그룹의 일부이고 좋은 할인을 협상했으며 그것을 공유하고 싶어하기 때문일 수 있습니다.

주의하세요. 이는 임시 설정일 수도 있습니다. 분사된 법인이 청구 파트너와 새로운 Enterprise Agreement를 설정할 수 없는 시나리오를 가정해 보겠습니다. 분사된 법인이 청구 파트너에게 새로운 법인의 이름을 공개하고 싶지 않고 모든 분사 및 IT 인프라 작업을 비밀리에 수행하고 싶어하기 때문입니다.

그들은 새로운 Entra 테넌트에서 Azure 구독을 설정하고 IT 설정 작업을 할 수 있습니다. 나중에 공식 이름과 등록 작업이 완료되면 새로운 Enterprise Agreement를 구매하고 새로운 EA에서 구독을 새로운 Enterprise Enrollment로 옮길 수 있습니다. 이는 다운타임 없이 Azure 서비스를 재배포하지 않고 완전히 백엔드 이동이 될 수 있습니다. 구독 이동에 대한 자세한 내용은 위에 언급된 블로그를 참조하십시오.

Entra Tenant 생성

고객들 사이에서 제가 발견한 오해 중 하나는 Entra 테넌트는 파트너를 통해 계약을 체결한 후에만 생성될 수 있다는 것입니다. 하지만 실제로 고객은 여러 테넌트를 생성할 수 있습니다. 그리고 테넌트가 생성되면 사용자 ID를 사용하여 등록 계정을 생성할 수 있으므로 구독이 생성될 때마다 사용자 ID의 새 Entra 테넌트에 연결됩니다.

이것이 어떻게 달성될 수 있는지 살펴보겠습니다.

먼저 portal.azure.com을 탐색하고 Entra ID(이전 Azure Active Directory)를 검색합니다.

테넌트 관리를 클릭하면 아래 창이 열리고, 거기에 액세스 가능한 모든 디렉터리가 표시됩니다.

B2C가 아닌 Entra ID를 선택하세요.

이 단계에서는 새 조직의 이름과 새 Entra Tenant를 지정해야 합니다.

goto users로 가서 새로 만든 Entra Tenant에서 사용자 계정을 만듭니다. 이제 Entra Tenant와 사용자를 성공적으로 만들었으므로 다음 단계로 진행할 수 있습니다.

등록 계정 생성

엔터프라이즈 등록에서 여러 등록 계정을 만들 수 있습니다. 기본적으로 등록 계정에서 구독이 생성되면 등록 계정 소유자의 Entra ID와 연결됩니다.

계속해서 등록 계정을 만들어 보겠습니다. 등록 계정을 만들려면 등록에 대한 Enterprise 관리자 역할이 있어야 합니다.

Azure Portal에 로그인하고 Cost Management + Billing으로 이동합니다. 그리고 Enterprise 등록을 선택합니다.

계정을 클릭하면 모든 등록 계정이 열립니다.

참고 사항: 아래 단계를 실행하기 전에 엔터프라이즈 계약의 권한 수준을 직장 또는 학교 교차 테넌트로 변경해야 합니다.

https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/direct-ea-administration#view-and-manage-enrollment-policies

추가를 클릭하고 계정 소유자 이메일을 지정하세요. 이것은 새로 만든 entra 테넌트에 있는 entra 사용자 ID입니다.

이제 두 개의 다른 Entra 테넌트에 두 개의 등록 계정이 있습니다. 등록 계정에서 구독을 생성할 때마다 해당 구독은 새 Entra 테넌트에 연결됩니다.

Enterprise Agreement는 곧 종료되고 고객은 MCA로 전환합니다. MCA에서 동일한 것을 달성하는 방법에 대한 블로그를 곧 쓸 것입니다. 그리고 네, MCA-E에서도 동일한 것이 가능하다는 것을 보았습니다.

콘텐츠 검증을 도와준 Darshit Shah 에게 특별 감사드립니다 .

이 블로그가 분사 시 적절한 기업 계약과 세입자 협회를 설계하는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

728x90

+ Recent posts