Difference between revisions of "Moving SME to new Hardware"
m (→Introduction) |
m (→Introduction) |
||
| Line 5: | Line 5: | ||
This document describes a method using the '''[[Affa]]''' contrib. | This document describes a method using the '''[[Affa]]''' contrib. | ||
| − | The rise feature can be used to upgrade from a lower version to a higher version of the SME software. This also work from SME 8.1 to 9.<br> | + | The rise feature can also be used to upgrade from a lower version to a higher version of the SME software. This also work from SME 8.1 to 9.<br> |
Affa makes it possible to move with a minimal downtime of the production server. | Affa makes it possible to move with a minimal downtime of the production server. | ||
Revision as of 09:08, 17 May 2015
Introduction
There are many ways to move a SME Server installation to new hardware and also new versions of the SME Server software.
This document describes a method using the Affa contrib.
The rise feature can also be used to upgrade from a lower version to a higher version of the SME software. This also work from SME 8.1 to 9.
Affa makes it possible to move with a minimal downtime of the production server.
In the following it is assumed that prodIP is the IP address of your production server and newIP is the IP address of the new server hardware. Replace both placeholders by your real IP addresses.
Preparation
Production server
Enable remote administration ssh access in the server-manager of prodIP. This involves setting both the 'Secure shell access' for the local network, and the 'Allow administrative command line access over secure shell' setting, which must be set to 'Yes'. Also, you may have to set "Allow secure shell access using standard passwords" to 'Yes' as well.
Log into the prodIP box and run an update
yum update
If packages were updated signalling post-upgrade and reboot events is required.
New hardware
Install SME Server from the latest CDROM/ISO. Assign an unused IP address (newIP) and disable DHCP.
Enable remote ssh access in the server-manager on the newIP box.
Note: From now on all further steps can be done remotely via ssh login.
Log into the newIP box and run an update
yum update
Signalling post-upgrade and reboot events is required.
Install the Affa RPM
Follow the latest instructions here: Affa
Please remember to manually create directory for archive files:
mkdir /var/affa
Configure Affa
db affa set AffaGlobalDisable yes db affa set prodserv job db affa setprop prodserv remoteHostName prodIP db affa setprop prodserv RPMCheck yes affa --make-cronjobs
In this example you have an SME production server (prodIP) with IP 192.168.0.2.
You have a second SME box as your backup server (newIP) with IP 192.168.0.10.
The affa backup job will be called 'prodserv'.
Login to your newIP as root and edit/create the file /etc/affa/prodserv.conf . Using e.g. editor nano, add the following example job configuration text for jobname prodserv :
[prodserv] remoteHostName=192.168.0.2 SMEServer=yes Watchdog=yes RPMCheck=yes ConnectionCheckTimeout=120 Debug=no Description=Backup of 192.168.0.2 smeserver.athome.xx DiskSpaceWarn=strict RootDir=/var/affa TimeSchedule=0630 localNice=15 remoteNice=15 rsync--inplace=yes rsyncCompress=no rsyncTimeout=900 scheduledKeep=1 dailyKeep=7 weeklyKeep=4 monthlyKeep=12 yearlyKeep=1 status=disabled
Then save your job configuration file.
Now check that your configuration is OK:
affa --configcheck
N.B. If you have set the SSH port different from default, you must also tell Affa of the port number (represented below by xxxx ) with
db affa setprop prodserv sshPort XXXX
Generate DSA keys and send the public key to the prodIP server
affa --send-key prodserv
The answer from ProdIP server will be
Job prodserv: root@ProdIP's password:
enter the root ProdIP password. The answer will be:
Public key sent to prodIP
Copying data
Run the Affa job on the newIP box
affa --run prodserv
Depending on the amount of data and the speed of hardware and network this first job run can take a really long time.
Now view the file /var/affa/prodserv/rpms-missing.txt
less /var/affa/prodserv/rpms-missing.txt
You will find a list of RPMs which are installed on prodIP but not on this server (newIP) and also RPMs installed with different versions. Install or update the listed RPMs. To verify, you can run the steps of this chapter again. Finally the rpms-missing.txt should not list any RPMs.
In case you are upgrading the SME operating system to a higher version you may not only find the contribs installed in this list but all changes between the 2 systems - in this case you need to run this command on prodIP
/sbin/e-smith/audittools/newrpms
To find out what contribs are installed on prodIP.
Final data synchronization
Ask your users to log off.
Log into the prodIP box and stop all services that can modify data.
SVC='qpsmtpd sqpsmtpd crond imap pop3 imaps pop3s ftp httpd-e-smith atalk smb qmail' for s in $SVC; do service $s stop; done
Note: Downtime of the production server starts here
Log into the newIP box and run the Affa job again
affa --run prodserv
This run will complete very quickly as only differences since the the last run needs to be synchronsized.
Switch over to the new hardware
Log into the prodIP box and power it off
poweroff
Log into the newIP box and rise this server to your production server
affa --rise --all prodserv
This action will complete very quickly as only hardlinks are used and no data is physically moved.
Now do a reboot
reboot
Note: Downtime of the production server ends here
You now have an identical copy of your old production server running on the new hardware. Your users can now log on.
Cleaning up
Remove the Affa archives
/bin/rm -rf /var/affa
Remove the Affa packages and all status and configuration data
yum remove smeserver-affa perl-Filesys-DiskFree perl-Compress-Bzip2 rm -f /etc/cron.d/affa-status /etc/cron.d/affa rm -rf /home/e-smith/db/affa /home/e-smith/db/affa-report rm -rf /var/log/affa
Note: Don't forget to clean up /var/affa. Otherwise you will waste disk space and see strange quota reports. See this forum thread for details.
Additional information
Performance
With this method you should be able to move a typical 50 Gbyte sized server to new hardware with downtime less than 20 minutes. The final sync and the rise time does not really depend on the total files size, but on the number of files and directories.
