Home.... | log in.... | Pub my question! | Sign-up....

Java-index >> Solaris Operating System >> Solaris Essentials - General Technical Questions

VCS to Sun Cluster migration

I am planning to migrate a 2-node cluster from VCS to Sun Cluster. how much downtime does this involve? is there any documentation that i can reference?

[159 byte] By [maxpila] at [2007-11-27 10:35:42]

«« I want to compile even with errors!
»» Combining J2ME and J2EE?

# 1

Your best option would be to migrate your application to a temporary server, after which I would recommend you re-install OS on existing servers and build the Sun Cluster from scratch. Your downtime would involve a) migration to temp server and b) migration back to new cluster. As you are using VCS I assume you use VxVM. Depending on what and where your application is running the migration to new cluster could be fairly straightforward.

The downtime for migration to new Sun Cluster should include cluster tests and application tests to ensure everything is running.

Another approach would be to switch your application(s) onto on primary VCS node. The second VCS node would then be available for OS re-install and build first node of Sun Cluster. Then you can migrate to the new Sun Cluster node and re-install OS and Sun Cluster on remaining VCS node and add to new cluster.

Downtime would depend on many things but I would guestimate 2 hours for migration and 6 hours for migration and cluster testing. This does not include time to build / install cluster nodes as downtime is not needed.

Hope this helps :)

Stuart_Flishera at 2007-7-28 18:36:37 >

top of Java-index,Solaris Operating System,Solaris Essentials - General Technical Questions...

# 2

Stuart,

Thanks, can you explain why a re-install of OS is needed? Both nodes are running Solaris 9 and have 3 Oracle 9i instances. I would rather not have to re-install the entire OS, although upgrade to Solaris 10 could be an option.

maxpila at 2007-7-28 18:36:37 >

# 3

Hi,

Peace of mind, re-install is only a recommendation from me based on experience ( and habit :) ). As you have a production system and downtime is a concern then you don't want to be troubleshooting something 'left over' from the old environment after you complete your migration. Otherwise your call ;)

As you are running Oracle then is should be straightforward. I assume you are running binaries from a separate partition locally or on shared storage. For a re-install you would only need to re-create user account, profile, /etc/system settings and /var/opt/oracle (right?).

Maybe you have VxVM root disk encapsulation? In which case It does make things tricky for a re-install/upgrade should you need to preserve any local file systems.

Stuart_Flishera at 2007-7-28 18:36:37 >

# 4

Hello all!

This is not a good idea to migrate from VCS to SunCluster. I worked with both. VCS is better no doubt. Sorry, Sun people! I like Sun and work a lot with Sun for many years but the SunCluster should be much better than it is now ...

PavelTsvetkova at 2007-7-28 18:36:37 >

# 5

PavelTsvetkov - sorry but that's your personal preference and in reality, both clusters have their place and both definitely do their "own thing" and depending on what you're looking for, each can be argued as the best for a particular scenario.

Since this shouldn't be a debate of which clustering product to choose, I'll finish by stating that Stuart does have the right idea: Build a parallel platform (if you must, you can take out one of the nodes from the existing cluster and use that since it's already going to have all of the hardware setup as desired) - Install the OS, Install the cluster (which includes VM as an installtime option), then install the application on top of it - then just start building your groups and resources to mirror the current setup.

As Stuart said, depending on how the initial install was done, with applications running on either private or public storage, your work ahead may be easier or harder, but I'm sure you've already realized that - Jeff

Sun Cluster can be installed (if you have all of your prework done) in about the same time as VCS, it's always postinstall configuration that takes the longest, depending on cluster / application complexity.

jeffrey.sa at 2007-7-28 18:36:37 >

# 6

Hi all,

In the following I outlined the principle steps how to migrate a cluster in place. Tis will be one of the subtopics of an upcoming blog about VCS to SC migration.

Pavel, you should revisit SC 3.2 definitely and explicitly the bui. We had various VCS admins on different projects who told us, the gap became that small, that VCS is not worth the additional costs.

Bear in mind that migrating in place is the most complex scenario, and doing it on a complete alternative platform is a much simpler process. But lets proceed with the assumptions and process:

Let us assume a two node cluster where you want to migrate from VCS with VXVM to Solaris Cluster and Solaris Volume Manager. I assume as well that your data is mirrored. The steps below are a principle outline of the migration process, to get the necessary cluster administration commands you need to consult the appropriate documentation.

1.Reduce the VCS cluster to a one node cluster and disconnect the interconnect. The interconnect has to be disconnected to allow a Solaris Cluster installation on the other node. Solaris Cluster check the interconnect for unwanted traffic

2.Split the storage in two halfs, and disallow the access from the VCS cluster to the future Solaris cluster part. This can be achieved in example by modifying the switch zoning, or lun masking. At this point in time your application is still running, but you have no high availability and no data redundancy any more.

3.Install a single node Solaris Cluster on the second host, it is advisable to start with a fresh Solaris install.

4.Configure the full Solaris Cluster topology with a temporary copy of your date. The data has to be installed by backup/restore, because you are changing the volume manager as well. It is important here, that you use different IP addresses for the logical hosts to avoid duplicate addresses. Now the new single node Solaris Cluster is ready to take the actual data.

5.When you are ready for an application downtime, transfer the actual data from the Veritas Cluster again to the Solaris Cluster, and shut down the remaining VCS single node cluster.

6.Change the IP Addresses of the logical host in the Solaris Cluster to the final value and enable all relevant resources. From now on your application will be running on the new Solaris Cluster.

7.Reestablish the interconnect, destroy the VCS cluster and install Solaris Cluster packages on the old VCS node, but do not configure the node yet.

8.Allow data access to the storage for both nodes with appropriate methods.

9.Add the second node to the Solaris Cluster including the Solaris Cluster device groups, this step will take an other short application downtime.

10.Mirror your data. From this point you have full redundancy and full high availability again.

Cheers

Detlef

deulsuna at 2007-7-28 18:36:37 >

# 7

Hi,

I have a few of questions regarding your procedure.

1) can you convert a single node cluster to a 2-node cluster? i thought this was not possible, but this was on SC 3.1U4

2) What is the point of disallowing storage access to the SC node ?

3)I am not planning to migrate from VxVM to SVM at the same time, so I guess i can just manually migrate the disk group to the SC node and manually migrate the IP. ?

maxpila at 2007-7-28 18:36:37 >

# 8

Hi,

Some answers to your questions:

You can add a node to a single node cluster. To do this, you have to bring the cluster in install mode, probably with scconf -c -q installmode

allow the node to add with claccess

add the node with clnode

and if you are set, call clsetup to select a quorum device and disable install mode.

This was doable ith the appropriate scconf commands in 3.1U4 as well

The VCS node can setting scsi reservations on fencing disksand this may interfere with SC. Ify you do not use fencing disks, you can omit these steps. but it does not harm to perform them.

In your case this is one way to go. I certainly would consider in this case to do all at once, because just installing the cluster is a matter of half an hour. Configuring it can take longer. You should carefully plan your resource topology and your agents on a test cluster (a single node does the trick) this gives you all the necessary commands to execute. Then import the diskgroup, register it and configure your cluster topology.

To be absolutely safe I would do this in an alternate boot environment. Needless to say, that taking a good backup is highly advisable.

Cheers

Detlef

deulsuna at 2007-7-28 18:36:37 >

# 9

Detlef,

Thanks for your reply, I have another question. When you say "Configure the full Solaris Cluster topology with a temporary copy of your data". Since this node does not have access to the storage, where should the data reside? I gues I need to configure all the Oracle servers and listener resources, so just give it an empty directory for data?

thanks,

Max

maxpila at 2007-7-28 18:36:37 >

Java programming resources: FAQs, tutorials, compiler and browser download sites, documentation, books lists, IDEs, etc.

VCS to Sun Cluster migration

Solaris Operating System Hot Topic

Solaris Operating System

All Classified