This article contains instructions on how to migrate a Operations Automation management node host running RHEL/CentOS 5.x to a host running RHEL/CentOS 6.x in case if a database is on a separate host.
A migration process includes a full backup and restore of the system database. You can estimate total amount of time required for the migration as time of full database backup and restore plus two hours to migrate other components. This time depends on the database size and a number of available CPU cores. For example:
- number of subscriptions: 150K
- number of accounts: 100K
- number of users: 250K
- number of processing cores on OA DB server: 8
- backup time: 1h
- restore time 1h
- total estimated migration time: 3h
Rolling back of migration is fast and it does not require any considerable time.
- initial release
- migration steps for Windows Asure Pack
- no issues
Make sure that target management host meets all the requirements listed at Linux Platform Deployment Guide > Installing Linux-based Operations Automation Management Node > Installation Preconditions.
Assign any temporary IP addresses on the target node.
Additional packages will be installed automatically by a migration scripts.
Check that Service Automation Central YUM Repository
http://download.pa.parallels.com/pa/6.0/RPMS/ is accessible from the destination node.
Names of network interfaces should be the same on the original and on the destination hosts. That is, if the BackNet IP address of a source node is bound to eth0 interface, then on the destination node the eth0 interface should be also configured for the BackNet IP.
Prepare a new RHEL/CentOS 6 host for the database server:
Install the PostgreSQL server on the new database server. You need to install the following RPMs from the OA distribution with the dependencies:
- postgresql91-libs-9.1.14-1PGDG.rhel6.x86_64 - postgresql91-server-9.1.14-1PGDG.rhel6.x86_64 - postgresql91-9.1.14-1PGDG.rhel6.x86_64 - pgtune-0.9.3-4 (for CentOS5/RHEL5)
Configure the kernel parameters
kernel.shmmaxon the new database server in the same way as they are configured on the source database node:
- Copy the
kernel.shmmax = ...and
kernel.shmall = ...lines from the
/etc/sysctl.conffile of the source database node, and paste them to the
/etc/sysctl.conffile on the new database node.
- Execute the
sysctl -pcommand on the new database node.
- Copy the
Initialize the new PostgreSQL database on the new database node:
Add to chkconfig and start the PostgreSQL server on the new database node:
chkconfig postgresql-9.1 on /etc/init.d/postgresql-9.1 start
/var/lib/pgsql/9.1/data/pg_hba.conffiles from the source database node to the new one.
Restart PostgreSQL on the new database node:
Before backing up the Operations Automation management node, make sure that the source node is ready for migration:
- Log in to source management node as
- Download the following scripts.
- Extract content of the archive into
Run the pre-check script:
/usr/local/pem/bin/backup.sh -t mn-migration-precheck
If the pre-check failed for some reason, follow recommendations in the script output.
Important: Before backing up the Operations Automation management node, make sure that there are no custom services (for example, apache, proftpd, bind, and so on) installed on the host. In case there are custom services which you also need to migrate, refer to Migrating Services to Nodes Running Up-to-Date OSes.
To back up all necessary data from the Operations Automation management node do the following:
- Log in to management node as
- Make sure that there is enough free space to store the backed up data.
Make sure that Operations Automation is not running. You can use the following commands to shut Operations Automation down:
service pemui stop service pem stop service pau stop
Back up necessary data using the following command:
/usr/local/pem/bin/backup.sh -t mn-migration -o /Operations_Automation_backup -d <db_host_ip_address>
After the operation is performed, the backup data will be stored in the
The data contains all the information needed for migration:
pemfolder (including tarballs, APS, binaries, etc.)
- Full DB dump
- ssh configs
- redis configs
- Configs of OACI, pvps APS
- Copy the backup to any safe external storage.
- Write down the host name, the external and internal IP addresses of the management and database hosts.
If Windows Azure Pack component is installed on source management node, use Backup section of this instruction to backup additional data.
- Shutdown the original management and database hosts.
To finish migration of the Operations Automation management node, you need to restore the backed up data to new host.
- Log in to the target database host as
- Assign the original database host's IP addresses to the target database host.
- Configure the host name so that it matches the name of the original database host.
- Log in to target management host as
- Assign the original host's IP addresses to the new host. Make sure that the the IP-addresses are assigned to the same network interfaces, as it was configured on the source host.
- Configure the host name so that it matches the name of the original host.
- If a virtualization technology is used, make sure that it have correct settings (IP addresses, hostname, name servers) for the destination node.
- Copy the backed up data to the host.
Perform the following command from the directory with the backed up data:
cd /Operations_Automation_backup ./install.py --migrate
- If Windows Azure Pack component is installed on source management node, use Restore section of this instruction to restore additional data.
Once the data is restored all necessary services will be launched automatically, and you will be able to work with Operations Automation.
To rollback the migration:
for the database and management hosts:
- Revert the hostname and IP addresses on the target host.
- Shutdown the target host.
- Start the original host.