Planning a server migration is a complex task. But it’s also an opportunity to build a scalable hosting architecture for the future. The success of a migration to your new setup is all in the planning. So read this article, and get your thoughts in order before you begin.
This article will be useful if you’re planning to move hosting platform or provider, upgrade to a more powerful dedicated server, or migrate to a more scalable cluster architecture. We’ll address the broad planning areas, and what to consider at the outset of your migration project. We won’t provide specific scripts and step-by-step instructions here, but you will find some links to other resources.
Part One: Preparing to Migrate
The most simple migration we’re talking about is a migration from one dedicated server to another. This may be to upgrade, outsource or change hosting provider. At the other end of the spectrum, you may be migrating to a clustered architecture, perhaps even in stages that let you test the new servers, keep your databases up to date and avoid (or minimize) downtime.
New Server Architecture
Let’s get this out of the way early – migrating is complex. But it’s also a great opportunity to get things right so that you don’t need to migrate again any time soon. shopel’s system architects can help you with both your migration to our data centers and with identifying the best, most scalable, most redundant and most cost effective new solution. If you have any questions or doubts, get in touch.
If you’re still at the stage of considering what architecture to use, consider deploying a server cluster to improve performance and make managing/scaling your architecture simpler. A cluster is a logical step up from a single server, and can save you downtime and further migrations in future. You can find out more about some typical types of advanced or clustered solutions here:
Whatever you decide, there are certain hygiene factors to consider before you begin the process of migrating. You should ensure that you have sufficient disk space and processing power on your new servers, plus a 30-40% overhead, or a more detailed projection and scaling plan. Also make sure you have enough IP addresses, and a fast network port of 100Mbps or more.
Any changes to your server architecture, OS, software versions or control panels will necessitate some changes to the configuration of your servers. In fact, even if you are upgrading to a more powerful server, it is likely that you can you can configure your services to take advantage of additional RAM, CPU power, drives or RAID.
Thoroughly planning and documenting the deployment process and configuration requirements will help this process run more smoothly, and help you when looking for outside help, as will having a DevOps team who are already familiar with your application and your deployment process.
Migration strategy
The simplest way to migrate is to recreate your entire server on your new server hardware, then configure and thoroughly test it, then make the switch from the old to the new servers by changing the necessary DNS or IP settings. Although even this simple strategy takes system administrators to set up your new servers, it is relatively simple in terms of planning.
The downside of this process is that it involves freezing all code changes and locking the database on your old server while the new server is set up, and/or synchronizing the data between your old and new database before changing the DNS or IP settings. Otherwise you will lose any code/data changes made during the migration process.
The problem with freezing changes to your servers and locking your database during migration is that in many real-life scenarios you need to provide normal services to users of the server throughout the process of migration. While moving a bunch of files may be easy enough, moving a business critical service or a constantly updating live database presents the problem of avoiding downtime, maintaining user access and permissions, and ensuring data continuity. That means you may not be able to lock your database, freeze development or let your service go down at any time during the (potentially quite long) migration process.
A popular way to address this is to perform a hybrid migration strategy. This involves preparing the new servers, synchronizing the old and new servers, and staggering the switch over. For example:
For a database server: Begin with the old database as the master, and the new (tested and configured) database as the slave. This will synchronize the databases. Once the servers are synchronized, and the new database is up-to-date, reverse the master-slave roles so the new database becomes the master. The desired result is no downtime, no locking the database and the chance to switch back to the old database if anything should go wrong. You can find information about databas
Понеділок, Жовтень 10, 2011
