cancel
Showing results for 
Search instead for 
Did you mean: 

Help required for Service Group planning for Global Clustering!

uvahpux
Level 4
Partner

Dear Gets,

Greetings to all!

I was involved many vcs ha/dr soultions implemention in my place, however for firstime i am going to implement ha/dr for global clustering option.

Now i have couple of questions arises when i think about Global Clusting.let me tell the scenario as below.

PR ( Two Node Cluster )

OS - Rhel 6.x

SF : 5.1 SP1

Replication : Storage Replication SnapMirror ( Async )

Remote Connectivity : FC Dark Fibre ( 40KM ) for SAN and Network spans in same subnet.

DR ( One node Clsuter )

OS - Rhel 6.x

SF : 5.1 SP1

Replication : Storage Replication SnapMirror ( Async )

Remote Connectivity : FC Dark Fibre ( 40KM ) for SAN and Network spans in same subnet.

Now i understood that i would required to configure Cluster Service Group on bothsites of  Clusters to connect as Global Clusters.

also i need to configure service groups for application for each site separately. now my doupt is how the service group will failover or how the services are failover to DR incase of issue in PR site. since each application service group will have separe vip and its resources and the end users are connected to Virtual Ip for services so how after the failover to DR the users request would point to DR site.

some advise required in my last point.

Thanks.

Uv 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

mikebounds
Level 6
Partner Accredited

Most replication agents should work in an RDC or GCO.  The only agent I know that didn't work in an RDC was an early version of the ODG agent as ODG is a host based repliction product that needs to talk to the DR node and it used the global "haclus" commands to communicate with the other cluster, but this was corrected in later agent so it now works in an RDC.  Most replication agents don't need to communicate with the other cluster and the netapp snapmirror agent should be one such agent as netapp snapmirror is array based, not host based replication, so there should be no need for the agent to talk to the remote node.  

Support of replication agents in an RDC is a little "grey" - some agents like SRDF, specifically say they are supported in an RDC, but others like EMC Recoverpoint and netapp snapmirror, do not mention they are supported in an RDC, but neither do they say they are not supported in an RDC or ONLY supported with GCO.  Recently I had a customer who had being using EMC Recoverpoint for over a year in an RDC when Symantec were checking system and they said it wasn't supported, but later they said it was ok.  The netapp snapmirror says:
"You can use the agent in global clusters that run VCS",

not "you must", or "you can only"

and

"If you plan to configure the agent in a global cluster"

- the word "if" to me definatley signafies to me that you do not have to use in a global cluster, which implies you must be able to use it in an RDC as this is the only other choice.

 

From a technical point of view an RDC is setup as follows:

  1. Use Servicegroup system zones to specify which nodes are local and which are remote, so for instance if you haves nodes A and B at prod site and node C at DR site, then configure:
    SystemZones = { nodeA = 0, nodeB = 0, nodeC = 1 }

    This means VCS will try to fail WITHIN a system zone, so does not fail across sites unnecessarily
     
  2. If you ony want to fail across sites manually, which is the default in GCO and is what I would recommend in RDC, then set ServiceGroup attribute AutoFailOver to 2 - see extract from VCS admin guide for AutoFailOver = 2:
    VCS automatically fails over the service group only if another suitable node exists in the same system zone.
    If a suitable node does not exist in the same system zone, VCS brings the service group offline, and generates an alert for administrator’s intervention

     
  3. You will need to localise any resource that have different attribute values when running at DR.  The Netapp snapmirror resource is one such resource which will have something like:
    LocalFilerName@NodeA = netapp1
    LocalFilerName@NodeB = netapp1
    LocalFilerName@NodeC = netapp2
    RemoteFilerName@NodeA = netapp2
    RemoteFilerName@NodeB = netapp2
    RemoteFilerName@NodeC = netapp1

    You will also need to localise LocalFilerPword and RemoteFilerPword if the password is not the same on each filer

Mike

View solution in original post

6 REPLIES 6

mikebounds
Level 6
Partner Accredited

If network spans in same subnet, then you can use the same virtual IP for your application in each cluster so that the same IP fails across sites.  Normally with GCO, IPs are in different subnets and then you use DNS agent to update DNS, so clients must you DNS hostname, not IP.

For sites close together (40km is quite close), then you can configure a single replicated data cluster (RDC) rather than use GCO - see posts:

https://www-secure.symantec.com/connect/forums/global-cluster-option-two-single-node-cluster

https://www-secure.symantec.com/connect/forums/cluster-configuration-rdc-or-gco

Mike

uvahpux
Level 4
Partner

Hi Mike,

Thanks lot, wth your previous help i have deployed many vcs ha/dr in my place smiley

so the global clusering is not really required for the above query right ?

if it is RDC then i think i can able to save lot of works in terms of app or db deployment as i will have a single sg, vip and resources across the sites.

most of the symantec docs in this case are based on the vvr and none of them are mentioned to use storage replication. how would i achive it as in my case i need to use netapp snapmirror for replication acrros sites in aync mode. also please tell me which option is more reliable in my case.

 

Thanks.

Uv

mikebounds
Level 6
Partner Accredited

Most replication agents should work in an RDC or GCO.  The only agent I know that didn't work in an RDC was an early version of the ODG agent as ODG is a host based repliction product that needs to talk to the DR node and it used the global "haclus" commands to communicate with the other cluster, but this was corrected in later agent so it now works in an RDC.  Most replication agents don't need to communicate with the other cluster and the netapp snapmirror agent should be one such agent as netapp snapmirror is array based, not host based replication, so there should be no need for the agent to talk to the remote node.  

Support of replication agents in an RDC is a little "grey" - some agents like SRDF, specifically say they are supported in an RDC, but others like EMC Recoverpoint and netapp snapmirror, do not mention they are supported in an RDC, but neither do they say they are not supported in an RDC or ONLY supported with GCO.  Recently I had a customer who had being using EMC Recoverpoint for over a year in an RDC when Symantec were checking system and they said it wasn't supported, but later they said it was ok.  The netapp snapmirror says:
"You can use the agent in global clusters that run VCS",

not "you must", or "you can only"

and

"If you plan to configure the agent in a global cluster"

- the word "if" to me definatley signafies to me that you do not have to use in a global cluster, which implies you must be able to use it in an RDC as this is the only other choice.

 

From a technical point of view an RDC is setup as follows:

  1. Use Servicegroup system zones to specify which nodes are local and which are remote, so for instance if you haves nodes A and B at prod site and node C at DR site, then configure:
    SystemZones = { nodeA = 0, nodeB = 0, nodeC = 1 }

    This means VCS will try to fail WITHIN a system zone, so does not fail across sites unnecessarily
     
  2. If you ony want to fail across sites manually, which is the default in GCO and is what I would recommend in RDC, then set ServiceGroup attribute AutoFailOver to 2 - see extract from VCS admin guide for AutoFailOver = 2:
    VCS automatically fails over the service group only if another suitable node exists in the same system zone.
    If a suitable node does not exist in the same system zone, VCS brings the service group offline, and generates an alert for administrator’s intervention

     
  3. You will need to localise any resource that have different attribute values when running at DR.  The Netapp snapmirror resource is one such resource which will have something like:
    LocalFilerName@NodeA = netapp1
    LocalFilerName@NodeB = netapp1
    LocalFilerName@NodeC = netapp2
    RemoteFilerName@NodeA = netapp2
    RemoteFilerName@NodeB = netapp2
    RemoteFilerName@NodeC = netapp1

    You will also need to localise LocalFilerPword and RemoteFilerPword if the password is not the same on each filer

Mike

uvahpux
Level 4
Partner

hello mike,

 

Thanks lot, let me discuss it with my project team.

one more question is that i will be configuring two LLT and one low priority link for this setup, is it okay ?  please advise.

 

Thanks.

Uv

mikebounds
Level 6
Partner Accredited

 Configuring two LLT and one low priority link is fine.

 

Mike

uvahpux
Level 4
Partner

hello mike,

thanks lot, the symantec consultant is advising us to go with GCO even if the nodes are in same subnet it will work. he also said the RDC will work fine but need to have sync replication.

also he was cautioning about RPO as the application could not tollerate RPO > 0 if we use GCO.

Thanks.