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

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

+ Recent posts