There are multiple options or tools available to migrate
On-premises workloads to Azure however the best option that MS provides is
Azure Site Recovery aka ASR which primarily known as a tool for protecting
servers in the event of a disaster. ASR could get you free migration to the
azure if planning and preparation is right as MS allows up to 31 days free
protection per server before the charges begin. If you can manage to migrate
the servers with in 30days or less then you will be charged nothing more than
the cost of the storage for the data itself.
Azure Site Recovery replicates workload between the location
over the internet or Express route & the best part is ASR is application
aware in most of the scenarios like Active Directory, Exchange, SAP, SQL Always
on and Oracle Data Guard.
ASR Replicates data over the internet or Express route it
doesn’t use VPN during failover however during failback you can leverage VPN.
Data that is going through internet is encrypted over port 443 and compressed
to avoid any breach.
Process server talk to the machines over 443 and machines
replicate data to process server on 9443. Inbound port on Process server 9443
HTTPS and Inbound HTTPS 443 on configuration server.
Additionally, port 80 is required to be open on the
management machine only during the set-up for MySQL download.
Scenarios that ASR Covers or can be used:
·
Azure VMs: Site Recovery can replicate any
workload running on a supported Azure VM
·
Hyper-V virtual machines: Site Recovery can
protect any workload running on a Hyper-V VM.
·
Physical servers: Site Recovery can protect
physical servers running Windows or Linux.
·
VMware virtual machines: Site Recovery can
protect any workload running in a VMware VM
·
Other Cloud: Site Recovery can protect workloads
from different clouds like AWS but you can not failover back to AWS.
Components of ASR:
- ASR Service: Azure’s
managed service, which is responsible for management and orchestration of
whole processes
- Config Server: The
centralized on-premises appliance coordinating VMWare and physical server
replication
- Process Server(s): Caching, compression, and
encryption for VMWare and physical server bi-directional replication
during.
- Mobility Service: Captures
block level changes in memory on each protected VMware or physical
machine. Supports filesystem (Linux) and application (Windows) level
consistency across multiple servers in a consistency group.
- ASR Provider and the ASR Agent: Used
for replicating and controlling replication of Hyper-V VMs
- HRL Files: Files that are
used to track the delta replication changes that occur after the initial
replication
In all the above-mentioned scenarios steps for setting up migration are very similar:
1.
Create a Recovery Services vault
2.
Create storage accounts to hold the replicated
data before migration, and the server VHDs after
3.
Configure the required servers needed for your
migration (Hyper-V, VMWare, VMM, etc) and add them to the vault configuration
4.
Specify replication settings
5.
Enable replication for the servers you want to
migrate
6.
Do a Test Failover to verify that the servers
are working as expected
7.
After multiple rounds of testing and
adjustments, do a planned failover to recover the new VMs in Azure
8.
Complete the migration for each server
Click
Here for the MS documentation for On-Premises to Azure.
There
are also several limitations to what
ASR can currently handle:
1.
UEFI/EFI drives are NOT supported
2.
iSCSI and FC Disks are NOT supported
3.
Static IP addresses on Linux servers are NOT
supported
4.
The Servers must be running 64-bit Operating
Systems of Windows 2008 or higher
5.
Hostnames, Mount Points, Device Names and
Windows System Paths should be in English language
6.
Operating System should be installed on the C
Drive
7.
Drive Letter E is reserved in Azure. If you have
servers to be migrated that have Data on the E Drive, then the drive letter
needs to be changed prior to migration
8.
Windows Server Disks should be Basic
9.
Shared Disks are not supported
10.
Failover Clusters are not supported
11.
Administrator rights may be needed to deploy the
Azure Agents
12.
ASR Supports Premium Storage for replicated
data, but a Standard storage account is still needed for logging purposes
13.
All standard Azure Limitations still apply
With
those items in mind, be sure to review and fully understand the requirements
and prerequisites listed here
We have talked about Azure Site recovery, Its components,
Scenarios where we can leverage ASR for the migration, General steps to
establish the ASR and limitations. Now let’s see an example of VMWare machines
migrating to Azure.
Deployment Steps:
1. Verify prerequisites and limitations.
2. Set up Azure network and storage accounts.
3. Prepare the on-premises machine that you want to deploy as
the configuration server.
4. Prepare VMware accounts to be used for automatic discovery
of VMs, and optionally for push installation of the Mobility service.
5. Create a Recovery Services vault. The vault contains
configuration settings, and orchestrates replication.
6. Specify source, target, and replication settings.
7. Deploy the Mobility service on VMs you want to replicate.
8. Enable replication for the VMs.
9. Run a
test failover to make sure everything's working as expected.
1)
Pre-requisites:
On-Prem Configuration Server - You need a VMware VM
running Windows Server 2012 R2 or later. You set up this server during Site
Recovery deployment. By default, the process server and master target server
are also installed on this VM. When you scale up, you might need a separate
process server, and it has the same requirements as the configuration server.
On-Prem VMWare Servers - One or more VMware vSphere
servers, running 6.0, 5.5, 5.1 with latest updates. Servers should be in the
same network as the configuration server (or separate process server). We
recommend a vCenter server to manage hosts, running 6.0 or 5.5 with the latest updates.
Only features that are available in 5.5 are supported when you deploy version
6.0.
On-Prem VMs - VMs you want to replicate
should be running a supported operating system, and confirm with Azure
prerequisites. VM should have VMware tools running.
Configuration for ASR Config Server:
Component
|
Requirements
|
CPU
cores
|
8
|
RAM
|
16
GB
|
Number
of disks
|
3
disks
|
Disks
include the OS disk, process server cache disk, and retention drive for
failback.
|
|
Disk
free space
|
600
GB of space required for process server cache.
|
Disk
free space
|
600
GB of space required for retention drive.
|
Operating
system
|
Windows
Server 2012 R2 or Windows Server 2016
|
Operating
system locale
|
English
(en-us)
|
PowerCLI
|
|
Windows
Server roles
|
Don't
enable:
|
-
Active Directory Domain Services
|
|
-
Internet Information Services
|
|
-
Hyper-V
|
|
Group
policies
|
Don't
enable:
|
-
Prevent access to the command prompt.
|
|
-
Prevent access to registry editing tools.
|
|
-
Trust logic for file attachments.
|
|
IIS
|
Make
sure you:
|
-
Don't have a preexisting default website
|
|
-
Don't have preexisting website/app listening on port 443
|
|
NIC
type
|
VMXNET3
(when deployed as a VMware VM)
|
IP
address type
|
Static
|
Ports
|
443
used for control channel orchestration)
|
9443
used for data transport
|
2)
Limitations
We have talked about the ASR set-up on VMWare environment
and its Pre-req. Let’s check the limitations
of ASR for above set up.
Azure - Storage and network
accounts must be in the same region as the vault. If you use a premium storage
account, you also need a standard store account to store replication logs.
On-Prem Configuration Server - VMware VM adapter type
should be VMXNET3. vSphere PowerCLI 6.0 should be installed. The machine
shouldn't be a domain controller. The machine should have a static IP address.
The host name should be 15 characters or less, and operating system should be
in English.
VMWare - Only 5.5 features are
supported in vCenter 6.0. Site Recovery doesn't support new vCenter and vSphere
6.0 features such as cross vCenter vMotion, virtual volumes, and storage DRS.
VMs –
·
You can't
replicate VMs with encrypted disks, or VMs with UEFI/EFI boot.
·
Shared disk
clusters aren't supported. If the source VM has NIC teaming, it's converted to
a single NIC after failover.
·
If VMs have
an iSCSI disk, Site Recovery converts it to a VHD file after failover.
·
If you want
to enable multi-VM consistency, which enables VMs running the same workload to
be recovered together to a consistent data point, open port 20004 on the VM.
·
Windows must
be installed on the C drive. The OS disk should be basic, and not dynamic. The
data disk can be dynamic.
3)
Set up Azure
o
Create Azure
Recovery Vault.
o
Set-up a
connectivity between Azure and On-premise
o
Azure VM will
be placed in this Azure Vnet, when they are created after failover.
o
Set-up an
Azure Storage account for replicated data.
4)
Prepare the configuration Server
o
Install Windows Server 2012 R2 or later, on a
VMware VM.
o
Make sure
the VM has access to the URLs listed in prerequisites or internet.
o
Install
VMware vSphere PowerCLI 6.0.
5)
Prepare for Automatic Discovery and Push
Installation
o
Prepare an
account for auto-discovery: The Site Recovery process server automatically
discovers VMs. To do this, Site Recovery needs credentials that can access
vCenter servers and vSphere ESXi hosts.
o
To use a
dedicated account, create a role (at the vCenter level, with these permissions.
Give it a name such as Azure_Site_Recovery.
o
Then, create
a user on the vSphere host/vCenter server, and assign the role to the user. You
specify this user account during Site Recovery deployment.
6)
Create a Recovery Services Vault
1. Sign in
to the Azure portal > Site Recovery
2. Click New
> Monitoring & Management > Backup and Site Recovery >
3. In Name,
specify a friendly name to identify the vault. If you have more than one
subscription, select one of them.
4. Create a
resource group, or select an existing one. Specify an Azure region. To check
supported regions, see Geographic Availability in Azure Site Recovery Pricing
Details
5. If you want to quickly access the vault from the
Dashboard, click Pin to dashboard and then click Create
Once Vault is created we need to Prepare the infrastructure, where we would specify –
1.
Source
2.
Target
3.
Replication Settings
4.
Deployment Planning
In Protection goal, select To Azure > Yes, with VMware
vSphere Hypervisor
Set up the source
environment:
Set up the
configuration server, register it in the vault, and discover VMs.
1. Click Site Recovery > Step 1: Prepare Infrastructure
> Source.
2. If you
don’t have a configuration server, click +Configuration server.
3. In Add Server, check that Configuration Server appears in
Server type.
4. Download the Site Recovery Unified Setup installation
file.
5. Download
the vault registration key. You need this when you run Unified Setup. The key
is valid for five days after you generate it.
Run Site Recovery Unified
Setup
Do the
following before you start, then run Unified Setup to install the configuration
server, the process server, and the master target server -
o
On the
configuration server VM, make sure that the system clock is synchronized with a
Time Server. It should match. If it's 15 minutes in front or behind, setup
might fail.
o
Run setup as a Local Administrator on the
configuration server VM.
o
Make sure TLS 1.0 is enabled on the VM
•
1. Run the
Unified Setup installation file.
•
2. In Before
you begin, select Install the configuration server and process server.
In Third
Party Software License, click I Accept to download and install MySQL
In
Registration, select the registration key you downloaded from the vault
In Internet
Settings, specify how the Provider running on the configuration server connects
to Azure Site Recovery over the Internet:
o
If you want
to connect with the proxy that's currently set up on the machine, select
Connect with existing proxy settings.
o
If you want
the Provider to connect directly, select Connect directly without a proxy.
o
If the
existing proxy requires authentication, or if you want to use a custom proxy
for the Provider connection, select Connect with custom proxy settings.
o
If you use a
custom proxy, you need to specify the address, port, and credentials.
o
If you're
using a proxy, you should have already allowed the URLs described in
prerequisites
In Prerequisites Check, Setup runs a check to make sure that
installation can run. If a warning appears about the Global time sync check,
verify that the time on the system clock (Date and Time settings) is the same
as the time zone.
In MySQL
Configuration, create credentials for logging on to the MySQL server instance
that is installed.
In
Environment Details, select whether you're going to replicate VMware VMs. If
you are, then setup checks that PowerCLI 6.0 is installed.
In Install
Location, select where you want to install the binaries and store the cache.
The drive you select must have at least 5 GB of disk space available, but we
recommend a cache drive with at least 600 GB of free space.
In Network
Selection, specify the listener (network adapter and SSL port) on which the
configuration server sends and receives replication data. Port 9443 is the
default port used for sending and receiving replication traffic, but you can
modify this port number to suit your environment's requirements. In addition to
the port 9443, we also open port 443, which is used by a web server to
orchestrate replication operations. Do not use Port 443 for sending or
receiving replication traffic.
In Summary,
review the information and click Install. When installation finishes, a
passphrase is generated. You will need this when you enable replication, so
copy it and keep it in a secure location
After
registration finishes, the server is displayed on the Settings > Servers
blade in the vault.
Add the account
for automatic discovery
1. On your configuration server, launch CSPSConfigtool.exe. It is available as a shortcut on the desktop
and located in the install location\home\systems\bin
folder.
2. Click
Manage Accounts > Add Account.
(It can take 15
minutes or more for the account name to appear in the portal)
3. To update immediately, click Configuration Servers >
server name > Refresh Server.
Connect to
VMware servers:
o
Connect to vSphere ESXi hosts or vCenter
servers, to discover VMware VMs & account needs administrative privileges.
o
When you add
VMware servers, it can take 15 minutes or longer for them to appear in the
portal. To allow Azure Site Recovery to discover virtual machines running in
your on-premises environment, you need to connect your VMware vCenter Server or
vSphere ESXi hosts with Site Recovery.
o
Select
+vCenter to start connecting a VMware vCenter server or a VMware vSphere ESXi
host.
o
In Add
vCenter, specify a friendly name for the vSphere host or vCenter server, and
then specify the IP address or FQDN of the server. Leave the port as 443 unless
your VMware servers are configured to listen for requests on a different port.
Select the account that is to connect to the VMware vCenter or vSphere ESXi
server. Click OK.
o
Enter the Vcenter information.
Target Configure
o
In Target,
select the subscription and the resource group in which you want to create the
failed over VMs. Choose the deployment model that you want to use in Azure
(classic or resource management), for the failed over VMs.
o
Select the
Azure storage account you want to use for replicating data. If you don't want
to use an account you've already set up, you can create a new one.
o
Select the
Azure network and subnet to which Azure VMs will connect, when they're created
after failover. Select Configure now for selected machines, to apply the
network setting to all machines you select for protection. Select Configure
later to select the Azure network per machine. If you don't want to use an
existing network, you can create one.
o
In Virtual
Machines > Select virtual machines, click and select each machine you want
to replicate. You can only select machines for which replication can be
enabled. Then click OK.
o
In
Properties > Configure properties, select the account that will be used by
the process server to automatically install the Mobility service on the
machine.
o
By default,
all disks are replicated. Click All Disks and clear any disks you don't want to
replicate. Then click OK. You can set additional VM properties later.
Setup Replication
o
In Replication
settings > Configure replication settings, verify that the correct
replication policy is selected. If you modify a policy, changes will be applied
to replicating machine, and to new machines.
o
Enable
Multi-VM consistency if you want to gather machines into a replication group,
and specify a name for the group
o
Machines in
replication groups replicate together, and have shared crash-consistent and
app-consistent recovery points when they fail over.
o
We recommend
that you gather VMs and physical servers together so that they mirror your
workloads. Enabling multi-VM consistency can impact workload performance, and
should only be used if machines are running the same workload and you need
consistency.
o
Click Enable
Replication. You can track progress of the Enable Protection job in Settings
> Jobs > Site Recovery Jobs. After the Finalize Protection job runs the
machine is ready for failover.
NOTE: After
you enable replication, the Mobility service will be installed if you set up
push installation. After the Mobility service is push installed on a VM, a
protection job will start and fail. After the failure, you need to manually
restart each machine. Then the protection job begins again, and initial
replication occurs.
View and manage VM
properties
o
Click
Replicated items >, and select the machine. The Essentials blade shows
information about machines settings and status.
o
In
Properties, you can view replication and failover information for the VM.
o
In Compute
and Network > Compute properties, you can specify the Azure VM name and
target size. Modify the name to comply with Azure requirements if you need to.
o
Modify
settings for the target network, subnet, and IP address that will be assigned
to the Azure VM. You can set the Target IP Add, if you don’t then failed-over
machine will use Azure DHCP & If you set IP that’s not available then
failover wouldn’t work.
o
No. of
network adapters is dictated by the size you specify for the target virtual
machines.
-
If the
target network adapters on the source machine is the same or less than Target machine
allowed, than will have the same no. if adapters as the source
-
If Target
network adapters exceeds than no. of allowed on target then the target size
maximum will be used.
-
For example,
if a source machine has two network adapters and the target machine size
supports four, the target machine will have two adapters. If the source machine
has two adapters but the supported target size only supports one then the
target machine will have only one adapter.
-
If the VM has
multiple adapters then first one in the list would become default adapter.
Prepare VMs for replication
All machines
that you want to replicate must have the Mobility service installed. You can
install the Mobility service in many ways:
1.
Install with
a push installation from the process server. You need to prepare machines in
advance to use this method.
2.
Install
using deployment tools such as System Center Configuration Manager, or Azure
automation DSC.
3.
Install
manually
Enable replication Steps.
1.
When you add or modify VMs, it can take up to 15
minutes or longer for changes to take effect, and for them to appear in the
portal.
2.
You can check the last discovered time for VMs
in Configuration Servers > Last Contact At.
3.
To add VMs without waiting for the scheduled
discovery, highlight the configuration server (don’t click it), and click
Refresh.
4.
If a VM is prepared for push installation, the
process server automatically installs the Mobility service when you enable
replication.
Replicate VMs
- Click Replicate application > Source.
2.
In Source,
select On-premises
3.
In
Source-location, select the configuration server name
- In Machine type, select Physical Machines
5.
In Process
server choose the process server. If you haven't created any additional process
servers this will be the configuration server. Then click OK
In Target,
select the subscription and the resource group in which you want to create the
Azure VMs after failover. Choose the deployment model that you want to use in
Azure (classic or resource management), for the failed over VMs.
Select the Azure storage account you want to use for
replicating data. If you don't want to use an account you've already set up,
you can create a new one.
Select the
Azure network and subnet to which Azure VMs will connect after failover. Select
Configure now for selected machines, to apply the network setting to all
machines you select for protection. Select Configure later to select the Azure
network per machine. If you don't want to use an existing network, you can
create one.
Adding Physical Machines
In Physical
Machines, Click the '+' button and enter Name, IP address and choose the
operating system of the machine you want to replicate.
It will take
a few minutes until machines are discovered, and shown in the list
In
Properties > Configure properties, select the account that will be used by
the process server to automatically install the Mobility service on the
machine.
By default,
all disks are replicated. Click All Disks and clear any disks you don't want to
replicate. Then click OK. You can set additional VM properties later.
In
Replication settings > Configure replication settings, verify that the
correct replication policy is selected. If you modify a policy, changes will be
applied to replicating machine, and to new machines
Click Enable
Replication. You can track progress of the Enable Protection job in Settings
> Jobs > Site Recovery Jobs. After the Finalize Protection job runs the
machine is ready for failover.
After you
enable replication, the Mobility service will be installed if you set up push
installation. After the Mobility service is push installed on a machine, a
protection job will start and fail. After the failure, you need to manually
restart each machine. Then the protection job begins again, and initial
replication occurs
Test Failover to Azure in
Site Recovery
Test
failover is run to validate your replication strategy or perform a disaster
recovery drill without any data loss or downtime. Doing a test failover doesn't
have any impact on the ongoing replication or on your production environment.
Test failover can be done either on a virtual machine or a recovery plan. When
triggering a test failover, you need to specify the network to which test
virtual machines would connect to.
Prerequisites
1. Before you do a failover, do a test failover to
ensure that everything is working as expected.
2. Prepare the network
at target location before you do a failover.
When a test
failover is triggered, it involves following steps:
·
Prerequisites
check: This step ensures that all conditions required for failover are met
·
Failover:
This step processes the data and makes it ready so that an Azure virtual
machine can be created out of it. If you have chosen Latest recovery point,
this step creates a recovery point from the data that has been sent to the
service.
·
Start: This step
creates an Azure virtual machine using the data processed in the previous step.
When a failover is triggered, it involves following steps:
·
Prerequisites
check: This step ensures that all conditions required for failover are met
·
Failover:
This step processes the data and makes it ready so that an Azure virtual
machine can be created out of it. If you have chosen Latest recovery point,
this step creates a recovery point from the data that has been sent to the
service
·
Start: This
step creates an Azure virtual machine using the data processed in the previous
step.
Useful
resource –
It’s interesting to read content. nice post.
ReplyDeleteMicrosoft Azure Online Training