Are you planning to migrate to E2E cloud services? Then you must know how to do it precisely and efficiently. So, if you are not aware of this process, then you have landed on the right page. Here, you will find the necessary guidance on completing this process without any hassle.
So, read on.
Choose a migrating strategy
When you are migrating your services to E2E, then there are three options for you –
- A fresh installation of the app/web service in the new location
- Migrating offline by cloning the existing servers
- Working with a migration expert to do a live, hot migration
Choice 1: Fresh Installation
Remember, these are not the precise steps, but the precise steps will depend on your app. But here are some general things you need to do before migrating your services or apps:
- Make a catalogue of your existing apps.
- Review the backups of your apps or web services as your worst-case scenario plan.
- Deploy the new cloud servers of E2E of the suitable speed, size, speed, and OS.
- Install your apps to the E2E servers.
- Try migrating the data and all these config files to the E2E servers.
- Redirect to E2E servers' DNS and URLs.
- Remove all the data from the old servers.
Choice 2: Image Backup and Restore
Before you use this method, we warn you it is not suitable for most customers. If you are not an expert system administrator (or sys admin for short), don’t use this step because there are many low-level config settings to be performed. You need to also check whether the server meets the E2E requirements.
Here are the following steps for backing up with images and restoration:
- Make a backup of the server files and your app/web apps resources
- Cleaning the server
- Server image file export with the help of Virtual or Physical servers
- Testing with QEMU
- Raw format conversion
- Stage the image at the E2E server
- Add the image as an E2E snapshot
- Deploy the server from a snapshot
- If required, expand the file system
- Re-install cloud-init (initialization command)
Choice 3: Use a Migration Partner
If you are using a migration partner, then you will have to do live migration. If your apps cannot stand the migration downtime, it is highly recommendable to hire a hybrid cloud management expert who knows live migrations in and out. The expert should be well versed in cloud backup and should know how to recover from a crash. You can hire the services of companies like Rackware and Siatik, which specialise in cloud migration.
Steps for Choice 1: Fresh Installation
Step 1: Make a catalogue of your existing apps
After locating the web server’s config settings, search for the virtual host config files, SSL certificates, DB connection settings, and app control files for a freshly-deployed E2E server.
Step 2: Review the backups of your apps or web services as your worst-case scenario plan
Store all data in a local server where you can access these files in offline mode. If you have any other online server backup service, then it is better to store it there as the transfer is quite easy.
Step 3: Deploy the new cloud servers of E2E of the suitable speed, size, speed, and OS
Deploy equal-sized infrastructure for every existing web services/app component, such as block storage, compute instances, load-balancers or managed databases. To choose a location and to run a speed test, use commands like mtr, ping, or traceroute for testing the routing, latency and bandwidth between your location and the location of the data centre.
For example – here is a test execution of our server location from Delhi.
# mtr dl-in-ping.e2e.com
You should check the power of the server, storage capacity and managed services that are equal to your old environment. You should check whether your OS is Linux or Windows.
Step 4: Install your apps to the E2E servers
Use configuration management tools like Packer, Terraform, Ansible or Puppet for installing the same stacks on the E2E servers.
Step 5: Try migrating the data and all these config files to the E2E servers
Use tools like FTP, scp, rsync, third-party migration tools, or GUI migration tools to migrate your data to the E2E servers. After that, you have to test your app or web service thoroughly to see whether everything is in order. You need to check the performance with load tests and functional tests before redirecting the traffic.
Step 6: Redirect to E2E servers' DNS and URLs
You might want to lower the hop limit or TTL (time to live). Keep it at 5 minutes a few days before you start redirecting the traffic. Most DNS servers have a TTL of 24 hours. This will ensure the quick modification of the DNS of new E2E servers.
Step 7: Remove all the data from the old servers
Remove all the data of the old servers after thoroughly checking any unwanted activity or logging in on the old server. Free the old server after a careful check.
Steps for Choice 2: Image Backup and Restore
Make a backup of the server files and your app/web apps resources. Also, ensure your device has ample free disk space for converting the disk images to their raw format.
Step 1: Make a backup of all files
Make a backup of all the files and how you will access them in case of any issues.
Step 2: Cleaning the server
If you want to clean the server for free disk space then here is how you can do it:
# zerofree -v /dev/sda2
# dd if=/dev/zero of=/tmpfile bs=4096k; rm -f /tmpfile
Server image file export with the help of Virtual or Physical servers
If your hosting machine is capable of this, then skip this set. Otherwise, you can either export the image with the help of a premise virtual server like QEMU, Microsoft Hyper-V or VMWare. If you want to do it through a physical server, then you can use a dd server. Export the with the command given below:
# dd if=/dev/sda bs=1M of=/mnt/USB_external/server_image.img
Step 3: Testing with QEMU
This is optional. It helps to check whether the Virtual Input/Output drivers have been installed properly or not.
Step 4: Raw format conversion
E2E allows conversion into images with free utilities like QEMU or VirtualBox. You can do it by executing the two commands given below.
$ qemu-img convert -f vmdk -O raw image.vmdk image.img
$ VBoxManage clonemedium disk /path/to/image.vdi image.img --format raw
Step 5: Stage image at E2E server
Stage this converted image into an E2E server using scp or rsync. The commands for doing these are given below:
$ scp -C image.img email@example.com:/var/www/html/image.img
$ rsync -z --progress image.img firstname.lastname@example.org:/var/www/html/image.img
Step 6: Check the image on the given URL of the LAMP server
Step 7: Add image as E2E snapshot
In your customer portal, upload the image by browsing the given menu, Products > Snapshots > Add Snapshot.
Step 8: Deploy server from a snapshot
You can check the method for this over the internet or on the blog post we have written for it. Ensure that VPS SSD is of an equal size.
Step 9: If required, expand the file system
Confirm the accuracy of the disk, partition, and filesystem sizes using the following commands.
- Verify the disk size: fdisk -l
- Verify the partition size: parted -l
- Check the filesystem size: df -h
The command given below helps in resizing the file system
$ sudo resize2fs /dev/vda1
Step 10: Re-install cloud init
Does the server have cloud-init installed beforehand? Remove all the configuration files and cloud-init files completely. After that, reinstall cloud-init. The E2E server should start receiving new vendor information from the Metadata API.
To sum up, the precision of this migration will largely base on the server OS and app’s infrastructure. E2E is responsible for the platform infrastructure but not the app’s infrastructure and previous cloud server dynamics. Moreover, you are responsible for the administration of your app’s development until and unless they are specifically services managed by E2E and E2E Kubernetes engine or databases managed by E2E. So, keep these in mind while going ahead with the migration process.