App Migration to Azure: Moving your virtual machines from VMware step-by-step guide

Coming up, if you’re
considering the benefits of moving your on-premises
VMs or workloads to the cloud, we’ll take a look at how you can discover and assess your Windows and Linux VMs, migrate your workloads and
optimize them in production. And what’s more, you can also leverage the Azure Hybrid Benefit
for Windows Server to use your existing Windows
Server licenses in Azure and lower your costs by up to 40%. Now running your VM in
Azure IaaS gives you access to a global cloud platform. This translates to a number of advantages, from freeing up time spent managing your virtual machine hosts to now future-proofing
your platform for scale to the ability to take advantage
of the intelligent security in Azure, with its machine
learning and global monitoring to help you protect your
apps running in Azure, on-premises, or wherever. Of course, there are some
prerequisites to get started, and I’ll walk through them. You’ll need an Azure subscription,
and there’s a free trial to get you started. You’ll want to start small, to
get experience with your apps and so let’s walk through the basics of the migration process to Azure. Here, I’m in my VMware
vSphere environment, and as you can see, I have an application that consists of multiple virtual machines in a three-tier configuration. Now we’re gonna start with Azure Migrate, a new service we recently
released to preview. This helps me find my on-premises VMs and application
environments and assess them for migration to Azure. I started in the Azure Portal
by searching for “migrate” and creating a migration project. Now I’m gonna click here
on Discover & Assess. This will launch a two-step process. First, we’re going to the discovery, which will literally
discover your on-premises VMs using a virtual appliance
called the collector. Once we select Discovery,
you’ll also be prompted to download a collector appliance. This is a complete, preconfigured OVA, or Open Virtual Appliance,
that you import into vSphere. Azure will generate
your unique project ID, which you’ll need to supply
when initiating your discovery. So make sure to copy your
project ID and project key. Now I’ve set up a collector
VM in the ESX environment, and from a remote browser, I’m
logging in to my collector VM where we’ll kick off the discovery of our on-premises environment. Keep in mind this is a
read-only inspection of your VMs and their metadata, including
performance history, which we’ll use for right-sizing in Azure. When you first launch the
Azure Migrate Collector tool, you’ll be asked to go
through three primary steps. You’re gonna set up your prerequisites, it’ll prompt you to accept the terms, check that you’re
connected to the internet, make sure your time is in sync
with the internet time server and of course make sure
you have a current version of the PowerCLI installed. If not, it will automatically
install it for you. I’m gonna click here on Continue, and move to Discover Virtual Machines. Now, under Virtual Machine Discovery, here is where you’re gonna
provide your credentials for the vCenter server
that you are attaching to, and the read-only
discover of your machines. Well, you can see we’ve done that, and we’ll click on Connect. Next, we’ll select project. By selecting project, you’re asked to enter
the migration project key that was generated in Azure when you created your migration project. From here, once you’ve clicked Continue, it will kick off the discovery
by reading the metadata of your VMs and you can watch the progress and complete collection. Let’s go ahead and do that too. Now one things I want to point out is note that there’s no agent installed here. We’re simply talking
to the vCenter server, reading the configuration
data for the virtual machines, their virtual processors, memory size, disk, network configuration, also collect the performance
history of the virtual machines such as CPU utilization,
memory disk networking, which we’ll use for right-sizing later. Now this will make a few minutes depending on the number of VMs, so I’ll use the collection I ran earlier. Back in my migration project in Azure, I can see that I have 215 virtual machines that have been discovered, and I’m gonna go ahead
and move to step two, which is to create an assessment. I’m gonna click on Create Assessment for the multi-tier
application we saw earlier in the vSphere environment. I’ll give the assessment
group a name, like Mechanics, and I can choose to select all VMs, but in this case, I know the
ones that I want to migrate, which all have the word
“tier” in the name. So I’m gonna do a search for “tier,” and I’m gonna select all of these, and when I click the
Create Assessment button, this will create the group with these VMs and compute the assessment. I’ll click on the assessment, what you can see here called Mechanics, and then select Azure readiness. Here, you can see the
detailed view of the VMs and other properties. You’ll see all of your selected VMs and an assessment of whether or not the VM is ready to be hosted in Azure. Keep in mind if the VM is
not ready for migration, it will give you a reason and point you to documented guidance on the next steps. Now if we move to Cost
details, you can look here at the aggregate monthly
cost estimates for compute as well as storage, and you’ll see the
corresponding Azure VM size recommended below, based
on the performance history of the VM details and
storage requirements and more for each VM. If we go back to Azure readiness, you’ll notice that most
of my VMs can be migrated by Azure Site Recovery, or ASR, which is our primary migration tool. Now you’ll notice here in this first virtual
machine DataTierVM01, that it’s detected that I
have a VM running a database. In fact, let’s widen this a little bit. You can see in this case,
My SQL, and it recommends that I use the Azure
Database Migration service. Now we’ll cover this on a
future Mechanics episode. If you click on Edit Properties, you can tweak things like
the target Azure location, the currency, and you can also
factor in existing discounts like the Azure Hybrid Benefit
to estimate the 40% discount into your migration cost assessment. Also, one more thing to call out here. If you’re unaware of
your application topology and dependencies, you
can download an agent to a dependency map of
the VMs in your group. We’ll also cover this scenario in a future Mechanics episode too. So now I’m gonna go back
to my assessment overview and I’m going to export
the assessment report. Now this report gives me
the information that I need to set up my Azure environment, including Azure VM readiness, VM sizing, and cost estimates for
compute and storage, and I can drill into this per VM. And keep in mind, if you need
to show the folks in finance, they really love to see stuff like this in an Excel spreadsheet. So now that I feel good about
my discovery and assessment, I’m ready for migration. For VM replication and migration, we use Azure Site Recovery
in the Azure Portal. This service is typically used for disaster recovery
scenarios, as the name suggests, and the same process
is used for migration. You’ll also see us
streamlining both the ASR and Azure Migrate tools in the near future to derive more cohesiveness
between the discovery, assessment, and migration. Azure Site Recovery
will follow four steps. Number one, set up your
target environment in Azure using the information from
the assessment report. Two, download and import
Azure Site Recovery configuration server and process server into your vSphere environment. This is essentially the
replication assistant for Azure. Third, replicating the VMs that
you want to migrate to Azure and finally, switching your
production environment to Azure once you’ve tested everything in Azure. So let’s start. If you’re new to Azure,
you’ll need to do a few things to set up the target environment that should sound familiar
before we start replicating. First, you’ll need to set up
a place to store your VMs. In Storage accounts, click
Add and then give it a name. Choose the kind of storage,
performance, and subscription. I’m gonna go ahead with the defaults. Then create or assign a resource group and pick the location. We’ll skip the virtual network here but we’re gonna configure that next. So now, let’s add a virtual network. In the virtual network’s
blade, we’ll click Add and then we’ll give our network a name, address space, resource
group assignment, etc. Now I’m skipping the address
number assignment to save time but here you’d need to assign
the number of addresses needed up to 256. The last step is to prepare
to receive replicated data is to set up the Recovery Services vault. I’ll go to Recovery
Services and add a vault. I’ll select Add again,
give the vault a name, assign a resource group and a location of Western
United States number two. Now we have the area,
a prerequisite set up to start replicating our VMs. With your Azure target environment set up, the next step is to
prepare your on-premises VMware environment for VM replication and test failover and to
ultimately migrate production to Azure. In Site Recovery, you’ll
open the Site Recovery blade to see the steps for
preparing your infrastructure. We’re going to select
Prepare Infrastructure, then select the protection goal, which is to state the
environment source, target, and virtualization details. Now we’re gonna click
on Deployment planning. We did this during the
Azure Migrate steps, so we can select Yes, I’ve done it. Here is where you point
to the target source. If you’ve already done a
migration or site recovery, your existing vCenter
environments are listed here. If not, click on Configuration server and that blade highlights
all of the resources needed to get replication running. As with the discovery, we’ll
download an OVF template to manage the ongoing
replication of your VMs. This appliance will replace
Azure Site Recovery’s existing unified setup if
you do not already see it in your Azure tenant. ASR uses a configuration
server and process server to coordinate the replication between your on-premises vSphere
server and Azure Storage. Data is only replicated to
your Azure Storage account and no running components
are needed in Azure until you perform test
or production failover to spin up VMs in Azure. Now both environments are connected and ready for the command
to begin replicating. To ensure you only
replicate what you want, you go back to the Azure
Portal to enable replication. Now I’ve already gone through
this process to save time and you can see there are
six replicated items already, but I’ll show you how to enable one VM. I’m gonna select Replicate
to show you how this works. First, you select your
source, your vCenter server, and this is important as you
can have multiple vCenter hosts that can be set up as the source. Then you select the configuration
of your target environment in Azure, your storage account
that you set up earlier to replicate your VMs, and
we’ll configure the network in just a moment. From here, you’re going to select the VMs that you want to replicate
and in this case, I’m gonna do a search for “FrontTier” to pull up my VM that I’m looking for. There it is, I’m gonna click OK. And now we can select my storage options. I can select the disks
that I want to replicate and in this case, I’m just
gonna keep the default disks to replicate and use this account. Now here, you can set your
replication policy and settings and click here to enable replication. Now, in the interest of time, I’ve already started the
process of replicating my six VMs, as I mentioned earlier. Now we need to set up a recovery
plan to automate the steps to get your migrated VMs running. To set up the recovery plan,
go to the Recovery plans blade, select Add Recovery Plan,
or plus Recovery Plan. We’re gonna go ahead and give
it a name, like Mechanics, and select the target Microsoft Azure. We’ll use the resource manager model as we’ve done throughout the process. Now we’ll select our VMs,
and I’m gonna go ahead and select all of them and
Azure will create a default plan that spins all of these
VMs up simultaneously. Now in my case, I’ll customize the plan, and here is where you can
define stages of recovery. So for example, if you want the backend of your multi-tier
application to come up first, then the middle tier,
and then the frontend, you’d set up those stages all right here. So, okay, now everything is almost set up. Our VMs are replicated, I’ve
created a staged recovery plan, and now to complete the migration. I’m actually gonna failover to Azure and just keep my VMs there. Now before I complete the migration, I can review each VM
and specify my compute and network configuration
settings for all of my VMs before I migrate them. In my Recovery Services vault
for the app I’m migrating, I’m gonna click into the Replicated items and here, I’ll see the
status of my replicated VMs. You’ll notice DataTierVMO2 isn’t healthy, but since it’s a mirror of VMO1, I’m okay with that right now. I’ll select DataTierVM01,
then Compute and Network, and here you can see I have
a comparison of what I have in my data center and
what Azure has assigned. You can see how on the right-hand side, you’ll see an Azure VM
size selected by default, but you can change this
with the information from the Azure Migrate
assessment we did earlier. Under Network properties
is where we’ll attach the replicated VM to your
selected Azure network. All you need to do is
select the target network that you created earlier, also we estimated the cost savings with Azure Hybrid Benefit
for Windows Server. Here is where I’m gonna apply it. So I’m gonna do that,
confirm it, and click Save. Now you can do this for each of your VMs. In the future, as we integrate
Azure Migrate with (Azure Site Recovery), the information from your assessment will be automatically integrated. Once you save your changes and
go back to your recovery plan you can then do a test
migration, test failover, which allows you to test if
your VMs are running in Azure in an isolated environment. Once you’ve tested your
failover, you can then use the failover option to move
the production VMs to Azure. Here, it will make sure, in
fact, it will even ask you and verify that you’ve tested
the failover ahead of time. In this case, you can
choose the recovery point and whether you’re gonna shut
down VMs before beginning. We recommend that you take
the source application offline in the on-premises data center
during the migration window to ensure zero application data loss as you migrate VMs to Azure. Now, after clicking OK, your virtual machines
are running in Azure, and as you can see right here, the virtual machines from
my VMware ESX environment are now running in Azure. I’ll do one final search here using Tier, and everything is running. So that was an overview of how to migrate your VMware Windows
Server workloads to Azure. You’ll see us streamlining
this process more and more over the coming months, and
we welcome your feedback on the Azure Migrate tool, which is in preview at the link shown. You can also visit the
Azure Migration Center for more information, but of course, once your workloads are in Azure, now you have a vast array of
options opened up for you. In fact, you can learn
more at the playlist shown. Thanks for watching.


Add a Comment

Your email address will not be published. Required fields are marked *