Video Screencast Help

Global Cluster Setup

Created: 04 Dec 2013 • Updated: 05 Dec 2013 | 13 comments
mokkan's picture
This issue has been solved. See solution.

Planning to seup  a lab before I create the environment  on  Production.

This is our Lab setup for Global Clustering.

4  VMs  (  Centos  6.1)

2 Nodes cluster

 One pair act as PRO and other pair will act as  DR.

We will use VVR for replica.

When we create remote cluster(DR),  do we need to keep the same cluster name, service group name and resource name?

Comments 13 CommentsJump to latest comment

mikebounds's picture

Service groups which you configure as global service groups need to have the same name in each cluster.

The cluster names should be different.

I don't think it matters if resource names are the same

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

SOLUTION
mokkan's picture

Thank  you very much Mike. Why do we need to have same  service group name? It is running totally different datacenter and different cluster.  Any specific reason?  Sorry I am new to this and trying to get clear picture.

Gaurav Sangamnerkar's picture

Hello,

Service group names to be very much same because they would be part of global configuration. Consider it like a simple service group in local cluster where service group names must be same, can u keep the service group name different in local cluster ?  answer would be no because VCS understands it is same group while the systemlist attribute defines which systems this group can failover.

The only difference here in GCO is the cluster are site separated, though once service group is part of global configuration, VCS will treat this as one service group & systemlist is now scaling beyond datacenters to remote cluster

A snippet from VCS Admin guide about Global Service Groups

Global service groups
A global service group is a regular VCS group with additional properties to
enable wide-area failover. The global service group attribute ClusterList defines
the list of clusters to which the group can fail over. The service group must be
configured on all participating clusters and must have the same name on each
cluster.
The Global Group Configuration wizard provides an easy interface to
configure global groups.
See“Administering global service groups” on page 516.
VCS agents manage the replication during cross-cluster failover.
See “VCS agents to manage wide-area failover” on page 471.

G

PS: If you are happy with the answer provided, please mark the post as solution. You can do so by clicking link "Mark as Solution" below the answer provided.
 

SOLUTION
g_lee's picture

Note: non-global service groups do not need to have the same names (ie: groups that will not failover between clusters can have different names) - just the global service groups (that do failover between clusters) need to have the same names for the reasons outlined by Gaurav above.

https://sort.symantec.com/public/documents/sfha/6.0/solaris/productguides/html/vcs_admin/ch16s03s01.htm

Cluster names must be unique within each global cluster; system and resource names need not be unique across clusters. Service group names need not be unique across clusters; however, global service groups must have identical names.

If this post has helped you, please vote or mark as solution

SOLUTION
mikebounds's picture

Suppose you have 2 clusters at production and dr and 2 apps called app1 and app2 - then your clusters names are typically based on the location so you could call prod_clus and dr_clus or base names on geographic location.  

The service groups names are normally based on the application name, like app1_sg and app2_sg and your application should be the same from a client point of view whether it is running at prod_clus or dr_clus and hence it is logical to use the same name and this is enforced as what makes a service group global is that you specify the ClusterList service group attribute which defines the clutsters the group can run on and there is nowhere to specify the remote service group name so it must be the same.

Resource names are generally the same, as the application would normally start with the same process names and use the same mount points so it makes sence to use the same resource names for these, but prod and dr might use different hardware so your NIC resources may have different names if you base your NIC resource names on the network device and this is different between clusters.

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

SOLUTION
mikebounds's picture

Note it is a similar case for VVR:

For the diskgroup names, by default, it is assumed you have used the same diskgroup name, but you can use different diskgroup names if you want, but the volume names must be the same for each diskgroup - see extracts from vradmin manpage for addsec option:

The addsec command creates a Secondary RVG in the disk group with the same name as the Primary disk group. If required, you can use the option -sdg diskgroupto specify a different disk group on the Secondary.

The addsec command requires that the data volumes and SRL must exist on the Secondary with the same names

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

SOLUTION
mokkan's picture

Thank you very much all of you. Last question about global clustering.

Can we switch over just one service group to other site? It suppose to be whole cluster needs to be fail over to other site? Therotically whole cluster needs to be moved to other site.

Gaurav Sangamnerkar's picture

Hello,

you can switch the service group which is configured as global group, there could be one group, there could be many ..

Resources like WAC or cluster heartbeat as explained above are part of clusterservice group which will anyways exist & will be online on remote cluster, so you don't need to switch that ..

I would recommend you to run through the guides to build concepts ,this will also clear lot of your queries..

https://sort.symantec.com/public/documents/sfha/6....

G

PS: If you are happy with the answer provided, please mark the post as solution. You can do so by clicking link "Mark as Solution" below the answer provided.
 

SOLUTION
mikebounds's picture

If switching a group manually, you can ONLY switch one global group at time - there is no "switch all global groups" option.  

If your cluster fails, then you get a "cluster failure" alert which gives you a list of the global service groups and you can select all, or just select the groups you want to fail over.

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

SOLUTION
jdangelo_symc's picture

Mokkan,

I would be remiss if I didn't point out that we don't officially support CentOS even though it is a RHEL derivative.  Any production deployment of SFHA/DR with VVR would have to be on either RHEL/OEL or SUSE. Also, you may or may not run into issues with even the test environments, and to be honest it wouldn't be a valid test setup if it's not the same in both prod and pre-prod.

Joe D

mokkan's picture

Thank you,  we can try with RHEL since we have the VM licences.

How do we diffirentiate or identify that servcie group is configured as global service group or normal service grup?

Thanks in advance

mikebounds's picture

You can check if ClusterList attribute is populated:

hagrp -display -attribute ClusterList

or in the java GUI there is a "3d" circle around the group on the left pane.

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

SOLUTION
mokkan's picture

Thank you very much Mike.