In this third and final installment of the “ Veritas Cluster Server to Solaris Cluster migration” blog trilogy, you'll find two case studies from actual migrations that have previously been completed.
We had a number of customers where we performed the migration from Veritas Cluster Server to Solaris Cluster. Most of them took hardware refresh as an opportunity to move away from Veritas Cluster Server. For example, one customer had an IBM Tivoli Server with Veritas Cluster Server. During a hardware refresh, they completely eliminated the Symantec stack which included Veritas Volume Manager, Veritas File System and Veritas Cluster, and move over to Solaris Volume Manger, UFS and Solaris Cluster. In this case, we migrated a highly sophisticated agent for their Tivoli Server using the Cluster Migration Toolkit. For the Oracle database portion, we used Solaris Cluster standard agent. The data migration was a pure backup-and-restore exercise.
The main steps of the migration process are outlined below:
1. Setup of the new Solaris Cluster.
2. Installation of the Tivoli server and the Oracle Database application.
3. Restore of the Tivoli configuration.
4. Restore of the Oracle database content including the creation of the oracle monitoring user.
5. Definition of the oracle database resource.
6.Migration of the Tivoli agent. We just configured the migration toolkit to use the customer's application agent scripts.
After the acceptance test, we simply switched the ip addresses and shut down the old Veritas Cluster Server.
We also had customers who were interested in just agent migration because they had a lot of home-grown agents that they wanted to use for new projects. For example, an outsourcer added Solaris Cluster to his portfolio. This outsourcer had various agents for backup clients, monitoring clients, etc... to integrate the data center infrastructure such as centralized backup and system monitoring into the customer systems. In this specific scenario, we just rewrote the Veritas Cluster Server agents. There was no data migration needed because all the customer wanted was to reuse his home-grown agent algorithm. The Generic Data Service was the most appropriate and extremely easy to use in writing the agent. For information about the Generic Data Service, see: http://docs.sun.com/app/docs/doc/819-2972
The challenge of the migration here was to merge the clean script and the offline script into the stop script of the Solaris Cluster agent. In a Veritas Cluster Server, the offline script is used for a graceful stop only. The clean script is used after probing errors, so it possesses the needed contents of a forced stop. The approach here is to just add the clean algorithm to the offline algorithm in this particular instance. The new start script and the probe script had to adhere to the Generic Data Service API. The customer was using korn shell scripts, and we were able to just copy the algorithm and change the return codes only.
There is a number of other customers like this outsourcer. Roughly 50 percent of these customers decided to pursue a complete agent rewrite while the rest used the cluster migration toolkit.
Summary on this “Migrating from Veritas Cluster Server to Solaris Cluster”blog trilogy:
The process to migrate a Veritas Cluster server installation to a Solaris Cluster installation is fairly easy overall. The easiest scenario is the parallel hardware setup. The only complex scenario is the migration on existing Cluster hardware while keeping the service up and running most of the migration time. A tradeoff between hardware investment and project complexity.