Microsoft Cloud Account Purchase Channel: Hand Teach You to Seamlessly Migrate Local Hyper-V / VMware Virtual Machines to Azure VM
In the process of the evolution of enterprise IT architecture to the cloud, the most difficult task for operation and maintenance and architects to sleep is "server migration".
No matter Windows your local computer room comes with it.
Hyper-V
, it is standard for big factory
VMware vSphere
, to move the virtual machines that have been running for several years and stored several TB of core data to Microsoft Cloud (Azure VM) without any damage. The traditional method is extremely primitive: shutdown, export huge VHD/VMDK image files, endure tortoise speed uploading across the public network, manually convert formats, reconfigure the network... This set of tossing down, not only downtime for more than ten hours, any step of network jitter in the middle will lead to a fall short, forcing the team to cry bitterly in the computer room late at night.
In Microsoft's cloud native ecology, there is an "official moving artifact" designed to solve this pain point "--
Azure Migrate(Azure Migration Service)
.
Its core logic is very elegant:
Fully managed, agentless (or lightweight), real-time incremental synchronization
. It is like a fully automatic "cloud crane", which silently clones and continuously transmits data to the cloud in the background on the premise that the local business opens to pick up customers as usual and flows continuously. When the data on both sides are completely aligned and the delay is zero, you only need to pick a calm afternoon and click "switch" to complete the smooth cloud-up at the large factory level in a few minutes.
Today we reject any official preaching rhetoric and do not memorize boring authentication parameters. Directly from the hard core of the production environment, hands-on teach you how to seamlessly migrate local virtual machines to Azure VM.
Phase 1: Deep disassembly, the "shadow human world model" of Azure migration"
Before you go to the console, you have to build a physical model of the underlying Azure Migrate in your head. Whether it is Hyper-V or VMware, the core logic of seamless migration is divided into three positions:
Local Monitoring Sentinel (Azure Migrate Appliance): This is an extremely lightweight virtual machine image officially provided by Microsoft. You just need to download it and run it in your local Hyper-V or VMware. This sentry does not invade your business code. Its only task is to inventory assets, calculate bandwidth, and continuously push disk data from local virtual machines to the cloud.
Cloud transfer station (Replication Storage): During the migration process, your on-premises server stays on, read and write all the time. Sentinel will encrypt and package the stock disk data and the latest change data (increment) generated per second to a temporary storage transfer station on Azure.
Cutting Full Blood Evolution (Cutover): When Cloud Transfer Station Data and Local Old Machines
After you reach full real-time synchronization at the pixel level, you click Migrate. Azure will instantly shut down the local old machine, and then use the latest data snapshot in the transfer station to directly pull up the new Azure VM virtual machine within one second.
Core Security Conclusion: Before you officially click "Migrate Cut Flow", your local production environment assets are intact and can even be terminated unconditionally at any time. This leaves 100 percent of the fault-tolerant retreat for operation and maintenance.
The second stage: the eve of actual combat-opening up a "rear area" on the Azure side"
We have to go to Microsoft cloud to lay the "foundation" of the infrastructure first, so that the local virtual machines have a place to stay.
Sign in to the Azure Portal.
Search for and go to the Azure Migrate page.
Under Migration Destination, click Servers, databases and web apps (server, database, and web app), and then click Create project at the top.
Select your subscription and resource group, name the project datacenter-to-azure-prod, and select the region closest to you (such as East Asia Hong Kong or Singapore Singapore).
After the creation is completed, click the "Discover" (discovery) button in the "Migration tools" toolbox.
At this time, the system will pop up a crucial password configuration page: "Is your machine virtualized?": Select Yes, with VMware vSphere or Yes, with Hyper-V according to your actual situation. The system will automatically generate a long "Azure Migrate project key" (project key) for you. Quickly copy and save it to Notepad, which is the only certificate for the local sentinel and cloud connector.
Phase III: Actual Combat Exercise I-Deploy Local "Sentinels" and Start Real-Time Incremental Replication
Go back to your local computer room (Hyper-V Manager or VMware vCenter).
1. Summon and activate Sentinel (Appliance)
On the Azure console page just now, download the official cut OVA (for VMware) or VHD (for Hyper-V) file.
Import this file into your local host and directly start the virtual machine named "AzureMigrateAppliance.
Open the browser of this virtual machine and a configuration webpage will pop up automatically. Paste the Project Key in the notebook just now.
Next, enter the password of your local vCenter or the administrator account of the Hyper-V cluster in the webpage.
Secret code alignment: At this point, Ben
The ground sentry will connect to the cloud through a fully encrypted channel. If you go back to the Azure console to refresh, you will be shocked to find that all the virtual machine lists, CPU cores, memory size and hard disk capacity running in your local computer room have been neatly displayed on the Microsoft cloud screen.
2. Turn on the barbed wire protection: start copying (Replicate)
After the asset inventory is clear, we select the virtual machine that runs the core business (for example:
prod-web-server
), ready to let it "shadow".
Click Replicate in the Azure console.
Source Settings: Select the local sentinel we just built.
virtual machine selection: select prod-web-server in the list.
Target settings: Select the Azure resource group, virtual network (VNet), and subnet that you want to host. Note: Be sure to plan well in advance to ensure that the IP segment of the cloud subnet does not conflict with the local data center.
Compute & Storage: Choose the Azure VM specification (such as Standard_D2s_v5) you want it to evolve into, and SSD for hard drives.
Click
“Start replication”
. At this point, the local disk data began to block (Block) as a unit, crazy and safe pouring to Azure. You can sit back and have a cup of coffee, because at this time, your local online users are still placing orders normally without noticing.
Phase IV: Actual Combat Exercise II-Absolute Safety "Exercise Exercise" and Golden Cut-off Switching
When the virtual machine state in the console is from
Initial replication
turn green
Protected (protected)
And when the synchronization delay approaches 0, the decisive time comes.
However, mature architects never gamble with luck. Before we really stop and cut the flow, we should first use Azure's black technology to do it once.
Insensitive military exercises
.
1. Ultimate Line of Defense: Test Migration (Test Migration)
To the right of the protected virtual machine, click the three dots and select Test migration ".
Select a fully isolated test virtual network (Test VNet).
Click Run. Azure will pull up an identical test virtual machine out of thin air in the cloud on the premise of not affecting the operation of the local old machine at all.
You can log in to this test machine to check whether the business can be pulled up normally, whether the database is damaged, and whether the code is wrong. After confirming that 100% is perfect, click "Clean up test migration" and the test machine will be automatically and physically destroyed by the cloud. The data is intact and the heart is greatly enhanced.
2. Gold 5 Minutes: Official Migration Cut Flow (M
igrate)
Exercise through, pick a dead of night, business trough moment, open the final general attack.
Click Migrate (migrate) to the right of the virtual machine.
There is a very user-friendly check on the page: "Shut down local virtual machines to minimize data loss" (shut down the local virtual machine to minimize data loss). Without hesitation, check it decisively! The architect cuts the flow inside story: when you click confirm, Azure Migrate will first notify the local host to gracefully shut down the old machine. Once the old machine is shut down, the disk will not produce any new data. The sentinel will drip the last few megabytes of "data tail" onto the cloud.
The moment the tail is replayed, the cloud virtual machine on the Azure side is full of blood and turns on the green light to run.
Replace DNS/gateway: resolve the domain name of your global front-end or the back-end IP of the load balancer from the original public network IP of the local computer room to modify the IP address pointing to the new Azure VM with one click.
A big win! After the whole migration campaign, the business downtime was only a few minutes of "local old machine shutdown-> cloud new machine startup-> domain name resolution effective", realizing seamless and smooth cloud migration in a real sense.
The fifth stage: the history of blood and tears in the transnational cloud environment.
This fully managed moving scheme is extremely elegant. But to survive in the cloud environment after the migration, as the chief architect, you must guard against the following two hidden holes before closing the computer:
1. The deadly "network card completely lost the black hole"
After the migration, many teams found that the virtual machine status on the Azure side showed normal operation, but SSH or Windows Remote Desktop (RDP) could not be connected, and the website could not be opened, as anxious as ants on a hot pot.
Cause disassembly: In the local physical data center, the network card of the server is usually manually configured with a static fixed IP (such as 192.168.1.50) and a fixed local gateway. When it is packaged and thrown into the cloud, Azure's network brain (VNet) distributes intranet IP to virtual machines through DHCP (Dynamic Host Configuration Protocol) by default. The old operating system in the virtual machine is stuck to the local static IP configuration and refuses to accept dynamic distribution from the cloud, thus becoming "deaf and blind" in the cloud network world ".
Large factory standard pit avoidance operation: before the local old machine starts replication, or during the test migration phase, enter the operating system of the virtual machine, and modify all network card attributes to "automatically acquire IP address (DHCP)" and "automatically acquire DNS server address". The first iron rule for servers to go to the cloud is to hand over the control of fixed IP to the VNet in the cloud.
2. "Deduction of Hourglass Cleaning" after Migration"
A lot
After watching the cloud server run perfectly, the novice happily went off work to eat hot pot. As a result, looking through the bill at the end of the month, it was found that a large amount of storage and replication instance occupancy fees were incurred.
Hardcore stop loss suggestion: when you click "Migrate" and confirm that the new machine is running smoothly for 24 hours, you must return to the Azure Migrate page, select the completed migration instance, and click "Complete migration" (complete migration) or "Disable replication".
Only this action will notify the cloud to completely physically destroy and stop the temporary transfer station and the synchronization channel of the local sentry, which are usually used to transmit data. If you don't do it, the hourglass will always default that you are still moving and continue to charge wildly.
Summary
Using Azure Migrate for seamless migration of local virtual machines, the core industrial essence actually lies in 16 words:
Sentinel detection, incremental chase, test avoid death, cut drift lock
.
You have completely bid farewell to the original workshop where human flesh carried hundreds of GB of mirror files and was afraid of network interruption. Leave the tedious disk block-level alignment, format conversion, and network mapping all to Microsoft's powerful managed migration brain. Sitting in front of the computer, watching the progress bar flickering gracefully and calmly completing the great shift of enterprise-level assets, this is the most elegant customs clearance posture of architects in the modern modern cloud native era.
