Login   Register  
PHP Classes
elePHPant
Icontem

10 steps to migrate Web site servers with the least of problems - PHP Classes blog

Recommend this page to a friend!
Stumble It! Stumble It! Bookmark in del.icio.us Bookmark in del.icio.us
  Blog PHP Classes blog   RSS 1.0 feed RSS 2.0 feed   Blog 10 steps to migrate W...   Post a comment Post a comment   See comments See comments (8)   Trackbacks (2)  
<< Previous: 2008 balance and 2009...>> Next: Automating Backup Tas...

Author: Manuel Lemos

Posted on:

Categories: PHP Tutorials, PHP Security

Sometimes you need to migrate a site between two servers. This article provides advice about which steps a server migration procedure should follow to prevent the problems that may happen.




Contents

* Guest blog postings

* Annoying advertising removal

* Site server migration

* 10 steps to migrate Web site servers with the least of problems

- 1. Prepare your DNS
- 2. Setup the new server
- 3. Tune the server file system for performance and integrity
- 4. Install the base applications
- 5. Initial data migration
- 6. Put the old server in migration mode
- 7. Bring your new server to life
- 8. Double check your server security
- 9. Epilogue
- 10. The forgotten step that you remembered

* Your migration approach


* Guest blog postings

Before the main subject of this post, as usual I would like to mention other things of interest to the PHPClasses site users.

Soon the site will start publishing posts in this blog written by guest authors. This will be experimental. Several authors already expressed interest. So we will start with articles of authors that already volunteered.

If all goes well, later the site will publish articles of other authors. If you are interested in writing good articles about topics of interest for PHP developers, feel free to contact the site using the contact link that shows at the bottom of all pages.


* Annoying advertising removal

This month has been quite busy. Despite no new visible features were implemented lots of internal maintenance and administration activities went on.

One of the activities was to remove annoying advertising from the site pages. That is something that I mentioned before I wanted to do in 2009.

http://www.phpclasses.org/blog/post/86-2008-balance-and-2009 ...

The types of advertising that were removed were mostly interstitial, pop-under, full page expanding ads and other ads that flash or are visually annoying.

In the case of some agencies, that meant a loss of 20% in advertising revenue. I hope it helps making the site nicer for those that are more sensitive to advertising.

By the way, once in a while I read complaints of users that are upset with advertising. I would like to clarify that I totally sympathize with the fact that some advertising is annoying because it is distracting and delays page loading.

However, this kind of advertising only appeared on the site because it provided much needed revenue to keep the site a viable business.

If it was not for that, the site could have been closed a few years ago when it was growing and needed all the revenue it could get.

Despite we are in a global crisis, nowadays it is possible to give up on the revenue of the most annoying types of advertising.

Additional revenue was generated thanks to all the users that have adhered the premium services subscriptions.

Not only premium subscribers can access the site without advertising, but they can also benefit from valuable services that help them as professional PHP developers, like having early access to PHP job postings, have full access to specialist forums to ask difficult PHP questions, etc..

If you are not yet familiar with premium subscription benefits, you may learn more about them here:

http://www.phpclasses.org/premium/#benefits


* Site server migration

Another activity that finally happened this month was to migrate the site to a different server.

Once in a while you may need to migrate your Web sites between two hosting companies, either because new hosting provides better servers or it provides more affordable prices, which is something you may be looking for during the times of financial crisis that we are living.

Here I would like to open a bracket to tell a little more about the hosting services that I use.

Since 1998 I have been hosting my sites with Net Virtual. It is such a long time, that I practically became friend of the owner, Greg Saylor. Net Virtual is based in San Francisco bay area, California. They provide a variety of hosting and systems integration services.

In the beginning I only used a shared hosting account. Later in 2003 when the site started becoming more demanding, it was migrated to a VPS account (Virtual Private Server).

VPS are servers that run on virtual machines. This means that the same computer can multiple virtual machines of different clients, as if they are distinct computers, but they share the same hardware resources (CPU, RAM, disk, etc..).

Later in 2005 when the VPS server was clearly not enough, the site was migrated to a dedicated machine.

The way it works with Net Virtual dedicated servers is that they co-locate server machines in data centers that fulfill the client project needs. Then they take care of installing the operating systems and any server applications that are necessary.

So, not only they provide hosting services, but also take care of systems administration tasks that may be necessary. This has been a blessing for me because either I would have to spend my own time doing server setup and management tasks, including migrations, or I would need to hire a dedicated professional to do that for me.

The cost of the server administration services is basically embedded in the server hosting rent that I pay to Net Virtual. Only when you need extra hardware you may need to pay additional fees. They also provide software development consulting services in PHP or other languages, but in my case I do all the development that is necessary.

I have to say that the cost has been quite affordable for me, especially in comparison to the prices of similar services here in Brazil where I live and work.

Most of the times I have been in direct contact with Greg Saylor that has solved my most urgent needs very quickly, some times using instant messaging, which is much faster than e-mail or the regular Web based request tracking systems.

Given the rough economic times that we are living, I thought it could be useful to mention these details about the cost and the hosting services that I use because that has helped me to keep working full time on this site for all these years.

So if you are looking for similar hosting solutions that I have been using at affordable prices, you may want to get in touch with Net Virtual to see if they provide an affordable solution for your needs that also helps you to do well during the crisis and in the future when it passes.

In that case, here you may find their site, so you can contact them. The site is quite simple but it has the necessary information to put in touch with them.

As a disclaimer, I should mention that I do not have any business association with Net Virtual. As I mentioned, I am just an happy customer since 1998.

http://www.net-virtual.com/


* 10 steps to migrate Web site servers with the least of problems

So the PHPClasses site server had to be migrated. The main reason was bandwidth. The new served had premium bandwidth. This means the data center guaranteed the necessary bandwidth to my server.

Some data centers offer un-metered bandwidth. This means you can transfer as many data as you want, but the available bandwidth is shared with all other servers in the same data center.

Additionally, since a new machine was used in the new data server, it uses a faster CPU, larger hard disk and more RAM.

The choice of the new data center was handled by Greg of Net Virtual. So he knows better the details of the bandwidth offers. For me, what matters is that I am paying the same price as before for a better server in a better hosting facility.

Despite the benefits of migrating to a better server, the actual migration is a complicated process that can fail in so many ways that I thought it would be a good idea to share what you need to be concerned if you need to migrate your servers too.

You need to go through several steps that need to be done in the right order to prevent major headaches.


- 1. Prepare your DNS

When you move a site to a new server in a different network, it will get new IP addresses. This means that during the switch between the old and the new server, your site domain records in the DNS need to be updated.

The problem is that DNS servers cache domain name queries for as long as possible to provide the fastest response.

Usually the queries are cached for days. So if you change the DNS records for your domain, many sites users will only see the change of server after several days.

The solution for this problem is to to lower the TTL (Time To Live) values of your DNS records. This is a value that indicates for how long DNS queries can be cached. When the time that has passed exceeds the TTL, DNS queries need to be done again.

So the first thing you need to do before migrating is to lower the TTL to reasonable levels. Initially you can set it to 30 minutes. It depends on how long you expect to be your downtime during the actual server switch.

This must be done days before the actual migration day. Usually you migrate the site on a weekend day or whatever is the day of the week with less traffic in your site. So, if you are going to migrate on Saturday, lower the TTL on a Tuesday or Wednesday.

Also if you are using SPF (Sender Framework Policy), it is advisable that you disable it now.

SPF are special DNS TXT records that you can use to tell the world that e-mail sent from your domain can only come from servers with certain IP addresses. This is used to avoid that spammers forge messages with addresses from your domain.

http://en.wikipedia.org/wiki/Sender_Policy_Framework

Since your site will be changing IP addresses, either you remove the SPF records or add both the old and new server IP addresses.

You also need to setup a temporary migration sub-domain pointing to the IP of the new server. This is explained below.

For instance, if your site domain is www.somedomain.com, create another sub-domain named temporary.somedomain.com set to the new server IP.


- 2. Setup the new server

Once the new server is ready in the data center, you need to install the operating system and setup the new IP addresses.

Good data centers provide you the services of a capable systems administrator that can install the OS for you. If for some reason you need or you prefer to install the OS yourself or it has to be done by a person that you trust, all the decent data centers can provide you a KVM switch.

KVM stands for Keyboard, Video and Mouse. It is an hardware and software solution that has provides means for you to control the actual machine remotely, so you do not have to go to the data center in person.

http://en.wikipedia.org/wiki/KVM_switch

It consists of a box with cables that send keyboard and mouse signals and captures video output. The operator uses a client program that communicates with the KVM switch box using a regular Internet connection.

Since before you install the OS the server network settings are not configured, using a KVM is essential for anybody to configure the server remotely. KVM is also great for accessing a server that may have crashed or for some reason it cannot be accessed remotely.

- 3. Tune the server file system for performance and integrity

While you setup your server, you also need to partition the hard disks and setup RAID configuration.

RAID stands for Redundant Array of Independent Disks. This means that your server must use several redundant disks.

http://en.wikipedia.org/wiki/Redundant_array_of_independent_ ...

Having a RAID setup is essential, not only to achieve greater performance, but also assure that if one disk fails, at least another disk will take over and your server does not stop until the bad drive is replaced.

Therefore, you should use at least RAID 1. This means that your system only sees one disk, but there are two disks with exactly the same data being replicated.

There other levels of RAID that provide greater performance. Obviously you need to spend more money in hardware and controllers.

A cheap alternative is to use software RAID. This means that the operating system will take care of reading and writing the data to the disks. Nowadays software RAID can be almost as fast as hardware RAID. This way you save the money of the cost of buy and hardware RAID controller.

Additionally, you can setup several partitions achieve greater performance and integrity of the data. For instance you can have a partition for the database server, a partition for the e-mail server, a partition for the Web server and a partition for all the rest.

This way the accesses to the database server partition will not be hold by the accesses to the e-mail server partition and so on.

Also, if you have a file system problem in one partition, the data in other partitions is not affected. You can fix partition problems independently.

Since you can have different types of file systems on each partition, you can tune each partition according to the purpose of its data.

For instance you can use a transactional file system for the database partition like for instance ReiserFS, but use a non-transactional (faster) file system like ext2fs for the e-mail server, that usually handles less critical data. It depends on how critical each kind of data is.

Once the file system partitions are set, you may need to create users and groups in your system. When you do that try to copy the same user and group identifiers used in the old server, so you do not get problems with denied permissions.


- 4. Install the base applications

Once you have installed the OS and setup the file system, you are ready to install the base applications, like the Web server, e-mail server, database server, PHP, etc..

I recommend that you use the exact same versions of these applications on the new server that you were using on the old server.

If you want to upgrade the version of some application, do it before or after the migration. Never do it as part of the migration procedure.

This way it reduces the chances of the migration to break because something in the new application versions work differently.

If you have installed a newer version of the OS in the new server, it is very likely that it will install newer versions of the applications.

In this case I strongly recommend that you do not install the versions that come in the OS installation media. Instead try to find the old versions and install them manually. This will help you migrate the database data much faster, as you may read below.

If you use MySQL, you may find older version packages in their site. Same goes for PHP, Apache, etc.. If you do not find old version packages with compiled binaries, you may need to build the binaries from source archives.

Actually recompiling applications from source may get you better performance, as the binaries will be optimized for your platform.


- 5. Initial data migration

Once the base applications are installed, you are ready to do the initial migration of your application data. This includes the database data, your application code files, mail server account configuration, logs, file caches, etc..

For simple file migration, the best tool to use is rsync. This is a tool that replicates files and directories from one machine to the other.

http://samba.anu.edu.au/rsync/

For migrating databases this is a bit more delicate matter. If the old and the new servers use different versions of OS, CPU or database server version, you may need to use database backup and restore methods to migrate the databases.

Since this is something that may take a long time, you need leave the database migration for a later step to minimize site down time.

However, if the OS, CPU, and database server are exactly the same, you may also use rsync to synchronize database server data files. This may reduce the migration down time from hours to minutes.

You may still migrate database data with rsync when the OS versions are not very different. For instance I used rsync to migrate MySQL database data that was in a server with OpenSuse 9 to a new server with OpenSuSE 11 both using different 32 bits Linux 2.6 kernel revisions.

When in doubt if it will work, use rsync to migrate the data initially and the start the database server. Use database table check queries to verify that all worked well.

The initial data migration done with rsync may take a while. But when you do the final data migration step using rsync again, it is all much faster and rsync only copies the parts of the files that changed.


- 6. Put the old server in migration mode

You need to configure your old server so it does nothing that changes your site data. This means it must not change your site database in any form. Make your old server Web server only exhibit a message that says the site is being migrated.

To make it safer, shut down your database server and maybe even your e-mail server, so no database data is changed nor any e-mail is processed.

If you have maintenance tasks being run from a task scheduler program like cron, disable all tasks now.

When you are sure all data is frozen, you are ready for the final data migration step.

Since this is the last step before switching to the new server, you also should lower further the TTL of the DNS records before migrating the database data.

That will help making all site users start accessing the new server much faster. Set it to 5 minutes to make them all see the new server very quickly.

Now just use rsync to synchronize changed files, like logs and cache files. If you have used rsync to migrate your database data, use rsync again to do the final database data migration. Make sure the database server in the new server is shutdown before you do this.

If you could not use rsync to migrate database data, you need to use a database backup tool instead, like for instance mysqldump in the case of MySQL. Then transfer the backup files to the new server and restore the database.


- 7. Bring your new server to life

Once all the data is moved to the new server, you are ready to bring it to life.

Your Web server in the new machine must be already configured to use the new server IP addresses by now. Once that is done, you should change your site domain DNS records to point to the new server address.

Even if you do all this, some DNS servers in world will still be caching queries pointing to the IP of the old server. To make all users come to the new server, you should configure the Web server to redirect all users to a special temporary domain that was previously configured in the first step.

In Apache you just need to add a line like this to your virtual host configuration of the old server:

Redirect / http://temporary.somedomain.com/

It will look like this:

<VirtualHost new.ip.address>
DocumentRoot ...
ServerName www.somedomain.com
Redirect / http://temporary.somedomain.com/
</VirtualHost>

In the new server you need to add a line like this to your domain virtual host configuration:

ServerAlias temporary.somedomain.com

It will look like this:

<VirtualHost new.ip.address>
DocumentRoot ...
ServerName www.somedomain.com
ServerName temporary.somedomain.com
</VirtualHost>

Just keep in mind that cookies from one domain may not be shared with other domain. So if you use cookies based sessions for logged users, users that are redirected this way will no longer be seen as logged.


- 8. Double check your server security

In your old server you may have taken some security precautions, like closing unused ports in the firewall, auditing the server security, etc... You should take the same precautions on the new server, especially if it uses a different version of the OS and applications.

For instance, if you use security auditing tools on the old server, use them again on the new server.

You should for instance security tools like nessus. This is a free tool that performs thousands of tests to verify if your server has known security vulnerabilities.

http://www.nessus.org/nessus/

If you do not do this, script kiddies will do it and abuse from your server soon or later.

Nessus will tell you if you are using insecure software that needs to be updated or you have unnecessary ports opened.

Some Linux distributions already come with nessus. However, it is better to download and install the application from the Nessus site. Usually it is a newer version and it does not require you to install all the GUI packages on the server.

Nessus is a client-server application. You can use a client program from your desktop machine that communicates with the server and performs the tests. You can run both the client and the server from your desktop machine, but then you may not be able to test local server vulnerabilities.

There is a commercial version of Nessus, which is basically the same, but it is updated more quickly in terms of tests of new vulnerabilities that were found. You need to pay a subscription to have access to the most recent test scripts.

You need to understand a bit about security to understand the reports and fix the issues that may be reported. Alternatively, you may also use online professional auditing services from companies like SecuritySpace. Once you pay for the audits, they perform automated tests from their servers to check your server.

http://www.securityspace.com/sspace/index.html?refid=1057382 ...

Some of these security checks can and should be done before the actual migration to the new server. The only reason why I listed this step after the migration is because your server will not yet be responding under your site domain before you make the DNS switch.


- 9. Epilogue

Finally, you may re-enable the your site maintenance cron tasks.

You should also restore your DNS records TTL value, usually set to several days.

If you have disable the SPF record in the first step, you may re-enable it after a few days when all the world DNS servers are seeing the new server IP address for your domain.


- 10. The forgotten step that you remembered

As you may have read, migrating servers is complicated, but it can get worse if you do not anticipate all the problems that may arise.

Often it is better to leave it to a systems administration professional that has experience and competence to do it.

If you are an experience systems administrator, I am sure you have been through circumstances that I forgot to mention and you had to find a clever solution on demand.

In that case it would be great if you could post a comment to this article and let us know how you did it.

You need to be a registered user or login to post a comment

Login Immediately with your account on:

Facebook ConnectGmail or other Google Account
Hotmail or Microsoft Windows LiveStackOverflow
GitHubYahoo


Comments:

4. 10 steps to migrate Web site servers with the least of problems - aburachman (2009-09-27 04:55)
10 steps to migrate... - 2 replies
Read the whole comment and replies

2. Great Article - Carlos Mario Mejia (2009-02-12 14:03)
reply... - 1 reply
Read the whole comment and replies

3. Thank you - Greg Saylor (2009-02-12 14:02)
Thank you... - 0 replies
Read the whole comment and replies

1. Step 11 of 10 - Jeff Greenberg (2009-01-30 17:05)
Don't forget the mail... - 1 reply
Read the whole comment and replies


Trackbacks:

2. Episode 35 | More Questions Answered (2011-01-25 03:49)
How to Minimize DNS Problems When Moving Servers

1. PHPClasses.org: 10 steps to migrate Web site servers with the least of problems (2009-02-04 04:05)
After having moved servers just recently, Manuel Lemos has a few helpful hints for anyone out there considering a web site/web server move in the near future:...


<< Previous: 2008 balance and 2009...>> Next: Automating Backup Tas...

  Blog PHP Classes blog   RSS 1.0 feed RSS 2.0 feed   Blog 10 steps to migrate W...   Post a comment Post a comment   See comments See comments (8)   Trackbacks (2)