Migrate IaaS services to another datacenter

You can migrate your IaaS services to another Gandi datacenter by yourself, by creating similar services in a new datacenter, and then copying the original data to those new services. This page includes all necessary resources to help you prepare and migrate all IaaS services from one Gandi datacenter to another.

FAQ

Howto

If you have any questions, our hosting support team is available to guide you with your migration. You can contact us by :

FAQ

Can I migrate my services automatically ?

Unfortunately, no. For technical reasons, mainly incompatibility between platforms, it's not possible to automatically migrate services from one datacenter to another.

Can I migrate my services manually ?

Yes, this article will help you prepare and migrate services to another datacenter.

How long will my migration take ?

Migration of resources can take from a few minutes to several hours, depending on the quantity of resources and complexity of the running services. Then, DNS records modification can take a few hours to propagate. This delay can be reduced with different methods described in this article.

Will my services be unavailable during the migration ?

In most cases, yes. Nevertheless, you can control when and how long it will take if you prepare for it.

The key points to control the duration of interruptions are in regards to database migrations and DNS records modification.

It is quite possible to migrate without interruption, or with very short interruptions. This will depend on your architecture and / or ability to adapt.

How should I prepare for the migration ?

Preparation of the migration is important for it to succeed. To avoid errors and minimize time of unavailability, it's recommend to prepare in detail your migration. We recommend to follow these steps to prepare your migration :

  • List all services that need to be migrated
  • Identify which data needs to be migrated (ie : databases)
  • Study multiple scenarios to determine which one fits your requirements in time and resources
  • Create a list with all steps, including all commands and modifications to handle in the correct order
  • Review your plan in detail before beginning the migration

Migrations always have the same structure :

  • Recreate the services in the new datacenter
  • Stop services in the old datacenter
  • Migrate data
  • Start services in the new datacenter
  • Test and validate

The order and how you execute these steps will vary depending on which scenarios you follow. To determine which scenarios fit your need, answer these questions :

  • What services must I migrate ?
  • What data must I transfer ?
  • What services will be unavailable during the migration ?
  • How long can these services be unavailable ?
  • When do I modify the DNS zone ?

Please consult the following Howto section to learn more about the different scenarios and determine which one fits your needs. Then prepare your detailed migration plan while reading the examples below and create a list of steps to execute for your migration scenarios.

Some are demanding in time, resources, and technical skills. Others are more accessible. Others faster. From all the lists you have created, choose the one that seems most suitable to your requirements. Revise it, then go ahead with executing your tasks.

Howto

Change DNS records

Preparation

Before doing anything else, you can start by changing your DNS records in order to decrease their TTL (Time To Live) to 300 seconds, without making any other modifications. This will indicate to DNS servers around the world that they need to refresh their cache at least every 5 minutes. Note that the TTL must be the same for all records of the same type. Go to DNS management guide for more information.

In this way, the propagation delay while changing IP addresses or domain names will be drastically smaller.

You can choose two strategies to manage changes in the DNS zones of the domain names impacted by the migration.

The first method is simpler and more direct, but may cause a service interruption while the changes are not propagated. The second involves a cost, as you can use a Web Accelerator as a proxy. By opting for this second method, you can avoid any DNS-related service interruption.

Method 1 - Set new IP addresses or domains name

Most Gandi services will allow you to change DNS records automatically from the UI. You'll also be able to utilize the available information in the UI to do the necessary changes at any external provider.

You can follow the example provided in migrate server Howto and refer to the section dedicated to DNS zone modifications in our wiki : https://wiki.gandi.net/en/dns/zone/edit

Method 2 - Use a Web Accelerator to manage DNS modifications

If you plan to migrate a website or application, it is often easier to make your migration if you use a Web Accelerator .

In this scenario, which is very easy to setup, you'll use a Web Accelerator as a HTTP / HTTPS proxy. Instead of creating DNS records with the IP address of your servers, you create a record that points to a Web Accelerator. The Web Accelerator will then, in turn, point to your server(s).

The steps are as follows :

  1. Create a Web Accelerator in the new datacenter
  2. Attach the existing server in the original datacenter to the Web Accelerator
  3. Add Vhosts for domains name to use (cf dedicated howto)
  4. Change DNS to link domains to Web Accelerator (cf dedicated guide)
  5. Wait for DNS propagation
  6. Migrate original server to a server in the new datacenter (cf dedicated guide)
  7. Detach original server from Web Accelerator
  8. Attach new server to Web Accelerator

If you do not plan to use the Web Accelerator after the migration is over, you can change the DNS records to link your domain names directly to your server (cf method 1). Leave the Web Accelerator active as long as the propagation is running to avoid unavailability. You can delete the Web Accelerator after confirming that the changes have been taken into account for all of your visitors (ie : 24 to 48H after migration)

Migrate a server to a new datacenter

Two methods are available to migrate a server to a new datacenter. In fact, it's not the server itself that is migrated but its services and data.

Consequently, no matter which method, you'll have to create a new server in the datacenter selected for the migration. This new server must have same hardware specs as the original server.

Then, depending on which scenarios seems most suitable to your requirements, copy the system disk from original server, or recreate services in a new server then selectively copy data.

Method 1 - Copy system disk directly to the new server

Consult the HowTo section for a more detailed explanation of performing a migration while copying the system disk.

The advantage of this method is that it ensures a complete duplication. However, keep in mind it is also a longer process than creating new servers if there's lot of data to transfer.

https://wiki.gandi.net/en/iaas/tutorials/migrate_vm_dc

Method 2 - Create services then migrate data from the original server to a server in the new datacenter

Since the server creation and package installation is fast on the Gandi platform, it is often faster to recreate system components manually, rather than reusing the old system, and transfer only the essential data rather than the entire system.

However, it's essential to ensure that all services are recreated with identical settings to avoid any environment incompatibility, which are avoided with system duplication.

Prepare your migration while checking all steps below (and possibly other tasks that might apply to your specific use case) :

  1. List services to migrate
  2. Create server in a European datacenter with the same disk size and power (or superior)
  3. Stop services on the original server
  4. Configure and start services

Copy disk to another datacenter

To migrate data to another datacenter, you can use disk copy or selective copy. In both case, disks must be attached to servers when runnning transfers. You can, if needed, use temporary servers, which will be used only for the transfer then destroyed.

Method 1 - Copy disk image to new disk

This method implies the use of a source server and a target server in the new datacenter to execute the copy.

If the disk to migrate is not already attached to a server, and if you do not plan to attach it to a server in the new datacenter, you still have to create a temporary server in each datacenter to initiate the transfer. The temporary servers can be destroy as soon as the disks are detached.

Consult Howto migrate a server while copying disk to have a detailed example of commands to execute.

Method 2 - Copy data from a disk to a new disk

Instead of copying the whole disk, you can migrate only the data needed. In this case, you can use commands such as rsync to transfer data between two datacenters.

Start by creating and setting up a server in a new datacenter. Install and start all required services for transferring data (rsync is pre-installed in most distributions but setting up the server is a manual process).

To initiate a copy of a directory from the source server to the target server, you can use following command :

user@source:~/ $ rsync -arvz /source/directory user@123.456.78.9:/new/directory

Migrate a snapshot to another datacenter

Migration of system disks and data disks (cf dedicated HowTo) are sufficient to start Snapshots again in the new datacenter from viable data. If you need to migrate a Snapshot for a specific reason, you can follow this process :

to create a new disk using a snapshot then follow HowTo copy disk to another datacenter.

Once the disk is created in the new datacenter, it can be used as a snapshot to create new disks. You can then delete snapshots from the disk in the original datacenter.

Migrate a Web Accelerator to another datacenter

You can follow the steps described below to migrate a [::eb::iaas::references::web-accelerator | Web Accelerator]] to a new datacenter.

The sequence proposed allows you to migrate in two process, separating the issues of migrating servers and migrating a Web Accelerator while changing DNS zones. However note that this strategy implies increasing latency, as the original servers and the new Web Accelerator will be in different datancenters prior to the servers migration.

As a Web Accelerator migration implies a change to DNS records, we recommend to also decrease the TTL for existing records before. Consult HowTo modify DNS records.

We recommend to study following steps and adapt it to your requirements if needed :

  1. Create a Web Accelerator in the new datacenter
  2. Attach the original server to the new Web Accelerator
  3. Delete the vhosts in previous Web Accelerator and create them again in the new one
  4. Make DNS zone changes
  5. Wait for DNS changes to propagate
  6. Delete the original Web Accelerator
  7. Migrate servers to the new datacenter (cf HowTo)
  8. Detach old servers from the new Web Accelerator
  9. Attach new servers to the new Web Accelerator
  10. Test
  11. Delete the old servers

Migrate a database to a server in another datacenter

There are two scenarios for your database : either your database service is running on server with other services (for example, a simple website), or the database service is running on its dedicated server or cluster.

In the first scenario, you can migrate your database in two different ways : either by copying the source disk to another disk in the new datacenter, or by creating a backup (dump) and then copying the backup to the new server, on which same settings as original server are applied. In both cases, you'll have to prevent writing new data on the original server before copying data (for example while shutting down web server to avoid new visitors), otherwise data corruption can occur.

In the second scenario, you can also transfer data while copying the source disk or dumpingthe databases. You'll also be able to manage the migration of database independently of other services - migrating it before other services, or replicating in real-time. Those advanced options aren't covered by this HowTo but you can find more information in your database application's official documentation and / or community. We are also at your disposal for any questions regarding your server with contact information available at the beginning of this page.

Method 1 - Migrate server with a copy of its system disk

To migrate a database along with the system and other data, report to specific HowTo to disk copy. You can also follow the same process to migrate a dedicated database server.

Method 2 - Migrate to a new server

To migrate your database to a new server, start by creating a new database server in the datacenter of your choice. Use the same settings for size and power as on the original server. Install the database server of your choice (same version if available to avoid any incompatibility). Then you can backup and copy data, assuring that services are stopped to ensure no new data is created on the old server.

  1. Create a server in the new datacenter with same specs as the original
  2. Install and configure the same services, including the database server
  3. Stop services on the original server to prevent writing to the database
  4. Make a “dump” of the database data
  5. Transfer data dump to the new server
  6. Import data dump to the new database server
  7. Verify the imported data
  8. Migrate the remaining services (consult other Howto available on this page)

Migrate a Private Vlan to another datacenter

When migrating to another datacenter, you can use the same settings in the new datacenter to speed up the migration. After creating a new Private Vlan in the new datacenter, you'll just need to create servers and interfaces that use same settings as previously for everything to be functional.

You may find these steps to be straightforward, but we recommend to include these in your migration plan :

  1. Create a new private vlan with the same settings as original
  2. Create servers in the new datacenter, giving them a private interface with the same parameters as the original
  3. Test private vlan is functional
  4. Migrate the rest of the data and services (consult other Howto available on this page)
Last modified: 07/11/2016 at 23:41 by Jonathan G. (Gandi)