Currently, we see more and more requests from customers who want to move away from Veritas Cluster. This trend is not industry specific; the customers come from finance, automotive, manufacturers, telcos and others.
They give us various reasons:
1. Cost/performance: Solaris Cluster is less expensive and offers superior functionality.
2. Service: many customers want to move to a single vendor who offers services for both the cluster and the OS. Problem ownership is then clearly with Sun.
3. Sun offers a supported agent(s) for the customer's key application(s).
4. Some customers like the greater choice in our container support.
To elaborate a bit on this process, this will be the beginning of “Migrating Veritas Cluster Server to Solaris Cluster” blog trilogy. Today you get the cluster migration itself, and shortly you will find a blog about data migration and another one about case studies.
Whenever you want to migrate from Veritas Cluster Server to Solaris Cluster, you will probably face one of two scenarios:
1. You have an existing cluster with existing data, and you want to use exactly this data in the new Solaris Cluster.
2. You want to build a new cluster, and you have already written various Veritas Cluster Server agents for your applications.
Hybrid scenarios are possible as well.
If you buy new servers, you have the most trivial migration scenario, but you may consider splitting an existing cluster into two parts. Obviously this may reduce your high availability due to the time of the migration.
A migration process consists of various steps:
1. An analysis of the Veritas Cluster Server topology.
2. An inventory of the deployed agents.
3. An agent conversion strategy.
4. A data migration strategy which will be covered in a separate blog.
Analysis of the Veritas Cluster Server topology
In some configurations, the structure of the Veritas Cluster Server service group is fairly simple, especially when all the resources of an application are configured in one service group. In this case we can take the structure, eliminate the resources we do not need, and configure it in a Solaris Cluster resource group. In these simply-structured configurations, the resource group topology of the Solaris Cluster will be fairly equivalent. Usually we have to identify and eliminate some resources which we do not need in a Solaris Cluster.
- The Veritas Cluster Server proxy resources are not needed at all.
- Diskgroup, Volume and Mount resources will be combined into one or more HAStoragePlus Resource(s).
If you have service group dependencies in a Veritas Cluster Server cluster, you have to model the resource groups in the Solaris Cluster with the appropriate affinities.
The concepts of Solaris Cluster are explained in http://docs.sun.com/app/docs/doc/819-2969
If you want to know more about resource group affinities, consult http://docs.sun.com/app/docs/doc/819-2974/6n57pdk26?l=en&a=view&q=affinities
If your Veritas Cluster Server cluster has restart triggers implemented, we do not need to code anything to migrate those. In Solaris Cluster you simply configure a restart dependency between resources. The restart dependencies can be configured between Solaris Cluster resources in different resource groups. Just provide a list of resources either in the property Resource_dependencies_restart or in Resource_dependencies_offline_restart.
Inventory of the Veritas Cluster Server agents used
Several of the Veritas Cluster Server bundled agents are not needed in Solaris Cluster. Two such scenarios are:
1.The resources NIC and IPAddress, or MultiNICA and IPMultiNIC will be combined to one logical host resource.
2.There won't be a full tree of DiskGroup, Volume and mount resources any more. All we need is one HAStoragePlus resource.
To learn more about high available file systgems and HAStoragePlus see http://docs.sun.com/app/docs/doc/819-2974/cdcegbeg?l=en&q=HAStoragePlus&a=view
The Veritas Cluster Server agent portfolio is smaller than the Solaris Cluster agent portfolio, so there is a good chance that you can use fully supported Solaris Cluster Agents instead of the in-house Veritas agents you were required to write. For example, there is no supported PostgreSQL agent for Veritas Cluster Server but there is one for Solaris Cluster.
Agent conversion strategy
For the agents which are not covered by a Solaris Cluster standard agent, we have to discuss a migration concept.
Here we have two options:
1. Rewrite the agent
1.1 If you are rewriting a custom agent, you can take the basic start probe algorithm and create a start and a probe script for a Generic Data Service (GDS) agent. For stopping, you have to combine the stop and the clean algorithm. The return codes have to adhere to the GDS interface. For information about GDS visit http://docs.sun.com/app/docs/doc/819-2972
1.2 The same rules as mentioned above apply for an application agent as well. Solaris Cluster monitors a process tree, by default. So you may have to adjust the child monitoring level of the GDS agent to get a similar functionality as for the pid file configuration and the process strings of an Veritas Cluster Server Application agent.
The two options above are a complete rewrite of your agent and will take some time, but will lead to a pure Solaris Cluster configuration.
2. We developed a migration tool to take the scripts of a Veritas Cluster Server agent and use them in Solaris Cluster. We can just plug in the Veritas Cluster Server agent into Solaris Cluster. There might be very minimal modifications necessary, so you must have the exclusive ownership on this agent for legal reasons. We will not treat a third party agent in this way, but for your home grown agent, it is a fairly easy way of agent migration. This service can be delivered as a consultancy service only.
The advantage of this option is the reduced amount of time for your migration.