Migrating from Veritas Cluster Server to Solaris Cluster

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.

Migration Scenarios

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.

Migration Process

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.

For example:

   - 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.


Detlef Ulherr
Sun Cluster Engineering

Comments:

I see this was posted this past September, and yet there are no comments?

Are there any case studies/"success stories" about customers who have downgraded from VCS, genuinely saved money, and are satisfied with the end result? With names?

Posted by Mark on March 04, 2008 at 08:20 AM PST #

Hi Mark,

In fact, we do have a blog titled "Case studies to migrate from Veritas Cluster Server to Solaris Cluster" dated 09/21/07 to share details on actual migrations from VCS to SC for your reference. Please note that customer name is not releasable as per NDA signed between Sun and its customers to protect their business interest.

BTW, not all blog readers take the time to comment the blog they read like you do, so thanks for taking the time to do so.

Posted by SC Blog Administrator on March 07, 2008 at 11:49 AM PST #

I understand that some businesses need to keep their secrets, and that's fine. However many vendors "name names" in "success story" write ups. These are more important than you think. Even if they are short on details it does help your resellers-and people like me- speak to management. Management is often interested in "the company they keep".

I sort of found what I was looking for http://www.sun.com/customers/index.xml?soln=0a5e5d5a-6aea-11dc-9b8e-080020a9ed93
However none of these studies reflect a migration from VCS to Sun Cluster.

Without names I have no idea if your case studies are real, or if Sun is simply forcing internal units and partners to eat your "own dog food".

Posted by Mark on March 07, 2008 at 10:56 PM PST #

We do recognize the importance of associating names with references (internal and/or external). However, the ability to name names publicly is strictly governed by NDA. And this we've respectfully followed to the letter. Certainly, we'd very much appreciated if we're Sun customers. Surely, you would as well.

If you provide your contact info (e.g. fill out the email address field in this comment form), we can have someone from Mktg and/or Sales to work with you. Please don't just take our words at their face value, but provide us an opportunity to enhance your company performance and to lower operating cost based on criteria unique to your company.

Posted by SC Blog Administrator on March 10, 2008 at 01:23 PM PDT #

How easy/hard is it is to get a platform that is currently not certified for Sun Cluster?

More specifically, I would like to know whether

Dell 1950 servers attached to MD3000 will get certified for Sun Cluster

Thanks

Posted by sunclusteruser on May 03, 2008 at 05:08 PM PDT #

We do not anticipate Dell to be part of the Solaris Cluster Open Hardware Program within this fiscal year.

Posted by guest on May 08, 2008 at 10:28 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

mkb

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today