11.3. Server Migration and Scalability Issues

With support for a diverse selection of hardware, as well as proven speed and reliability, Linux is up to the challenge of scaling up to meet resource demands as they increase. This can include moving to an SMP (Symmetric Multi Processing) configuration for greater processing needs, RAID levels 0 through 5 (either in software or hardware driven modes), etc.

On occasion, you may feel that your Linux server has outgrown the hardware it is running on, perform a major Linux version upgrade, or perhaps move to a different distribution of Linux. There are, of course, two ways of doing this. Either you will be leaving your server on existing or upgraded hardware (in which case you need simply shut down services, back up your data, perform the required modifications, and then restore data if needed), or in the more radical case, migrate your server to new hardware.

This section will concentrate more on the latter situation, where you will be actually migrating your various services from the old server to a new one. There are, of course, several migration strategies, however this section will attempt to provide some rough guidelines which you can follow in order to ensure your migration effort succeeds with minimal disruption to your users.

• Prepare your new server as necessary; install and configure Linux so that your new hardware devices are supported, and any required daemons and kernel-based features (such as firewalling) are enabled. See Chapter 4, as well as Section 10.6 for details.

• Set up your existing services (such as the Apache web server, Samba or Netatalk file & print services, etc.) and make use of them with test data for at least several days to ensure everything is working as desired. See Section 7.4, as well as Section 7.5 for details. Don't forget to ensure that any changes or custom scripts you have made in the ``/etc/'' directory, including anything in ``/etc/rc.d/'' have also been done on the new server as required. It is especially important that you remember to move over your user account information in the ``/etc/passwd'', ``/etc/group'', and, if you are using shadow passwords, ``/etc/shadow''!

• Shut down services on your old server, so that your file systems will see a minimal amount of file update activity. Obviously you don't want users uploading web pages and receiving e-mail on the old server, while you are restoring the data onto the new one! As root, you can shut down most services with the following command:

  killall httpd atalkd smbd nmbd squid sendmail ftpd

  The above command will shut down the web server, file & print services, e-mail server, and FTP service. (You may be running less or more services than the ones I have listed above. Check your process list and terminate any other service you feel appropriate; see Section 9.2 for details.)

  You might also want to edit the ``/etc/inetd.conf'' file on your old server, and with the ``#'' character, comment out any services (such as FTP, IMAP, and POP3 services) which might result in file system updates. Then, again as root, type:

  killall -HUP inetd

  The above command will reload the TCP wrappers (security wrappers to Internet services) so that future connections to any services you have disabled in the ``/etc/inet.conf'' file will not be loaded).

• Now you should be able to move over the data from one system to another. Likely, you will have prepared your new server to have everything it needs to function, including any additional software that you wish to install that did not come with your Red Hat distribution. Therefore, you will likely need to backup any data stored in ``/home'', ``/var/spool'', as well as optional file systems, such as ``/archive'', if applicable. Here is an example command that uses the ``tar'' utility to make a compressed backup file of data:

  cd / tar zcvpf /tmp/backup_data.tar.gz --exclude=var/spool/squid \ home archive var/spool

  The above command will write a backup of your ``/archive'', ``/home'', and ``/var/spool'' file systems (or subdirectories, depending on how you have set up your system), to a file called ``/tmp/backup_data.tar.gz'' in compressed tar format. Make sure you have enough space to create the backup, or write it elsewhere!

  Tip: Tip: You can use the ``du'' utility to help determine required space. For example, to determine the requirements of the ``/archive/'' and ``/home/'' directory trees, type:

  du -h -s /archive /home

  Bear in mind that the above command will report the actual size of your data, but if you are using tar's ``z'' option (as above) to compress the image file, your usage requirements will likely be significantly less. Consider the output from the ``du'' command a worst-case estimate of the space required.

• Now, you can restore the backup data from the tar file onto the new server. You can restore it directly over NFS (see Section 7.6 for details on how to configure NFS), or simply use FTP to transfer it over and untar it locally. Here is an example that will restore the files that were backed up as above:

  cd / tar zxvpf /tmp/backup_data.tar.gz

• Next, if necessary, swap your IP addresses so that your new server is seen on the old address.

• Finally, you may wish to shutdown and restart your server to ensure there are no unexpected error messages that appear. See Section 6.7 for details.

Once you are done, make sure everything is working as expected! If not, you can always re-enable any services you disabled on the old server and restart them so that users can continue using it until you resolve the problems on the new one (bear in mind, however, that you'll need to repeat the above steps again if you choose to do that).