|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Mailing List
|
By Joining the mailing list you will be notified of site updates.
|
|
Show Your Support For
This Site By Donating:
|
|
|
|
|
|
|
Audience: Linux Admins
Last Updated: 10/4/2011 6:23:28 PM
**All times are EST**
|
|
Migrating to a New Linux Server
By Erik Rodriguez
Tags: CentOS migration, linux migration, move linux to new hardware, redhat to SuSE, steps to migrate linux server
This articles provides information about migrating Linux web servers.
Migration Time
I've had the unfortunate job of migrating some very old Linux servers to new hardware and OSes. This can be fairly straight forward or very complicated. Most of the time it's somewhere in the middle. If your server runs an out of the box configuration with little customization, chances are you will be in good shape. Previously I successfully migrated a large website from older hardware (and Fedora Core 3) to a new server with CentOS 5. I've also had the unpleasant task of migrating a server with a highly customized Java application running. This took forever because nothing was documented, and the old systems had A TON of things custom compiled and tweaked by hand. Going back to the dedicated web server...
The change was part of a cluster, so there wasn't much involved to accomplish this. The database was on a different server and all I really had to do was grab the apache config file (httpd.conf) the home directory that contained the website and a few other housekeeping items. I also had to update the database ACL to allow connections from the new server. Not really a big deal. The whole process took a few hours and everything was good as new on fresh hardware and a current OS. Things can also get complicated on Linux when you start dealing with older version of mySQL and it's databases, older versions of php, and things that have been compiled by hand instead of using a package manager. Depending on your database, the code may need to be updated if moving to a newer database server.
Unlike Distros
Migrations from non-like distros can be difficult if you are not familiar with how the other distro works. Fedora to CentOS or RHEL are fine because they are basically the same OS with minor tweaks and various lengths of support. Novell (SuSE) to RHEL or CentOS is a different story. Novell has a few funky ways of doing things that are somewhat different from the red hat-base distros. Some folks have been nice enough to create scripts or migration tools for various tasks between the two OSes. Although, they don't always work. Close UNIX variants like Debian or Slackware have been a little tricky for me because some of the (redhat-specific)commands I like to use don't always work on them. I am talking specifically about packages like chkconfig and yum.
A few things you often miss when moving web servers are the .htaccess files and any cronjobs that may have been setup. If the web server you are migrating houses a high-traffic site, you may have to pay special attention to your log rotation settings. Apache can consume a massive amount of drive space relatively quickly if you have a busy website. These are all things I've picked up over the years and believe me, I've learned the hard way a few times.
The last thing you may need to check if you are running a cluster of servers is DNS. Depending on how your cluster is configured, you may need to add another A record for your second server if you are doing round-robin DNS. As a general rule of thumb, If round-robin is being used, I recommend setting up only 1 server with FTP. Have your web changes uploaded to 1 server and replicate the changes across the the rest via rsync. I usually give the FTP server a unique hostname so the FTP user doesn't get a round robin A record and screw up the rsync job.
Using round-robin also gives you a psuedo-failover setup. Provided you are using an active-active setup, and if you have round-robin in place, you probably do. If one server goes offline, you can set it's IP address on one of the other servers in your cluster and have apache listing with *:80. That will listen for all IP addresses configured for the server, and gives you an easy way to add IP addresses on the fly. If you are clever, you can create a script that will ping the server, and run an "ifup" script once the ping dies. Once you get the failed server back online, you simply "ifdown" the interface you created to take it's place and you're back in business. It's also an easy to way to do maintenance without putting up a site down for maintenance.
Contact Us
NOTE: this form DOES NOT e-mail this article, it sends feedback to the author.
|
|
|
|
|
|