cancel
Showing results for 
Search instead for 
Did you mean: 

Virtual ip configuration in global clustering.

uvahpux
Level 4
Partner

Dear Gents,

One of my previous discussion i was discussing how to setup global clustering with storage replication and i have received many helps . as per my understand i need to have two clusters for global clustering. in the gco configuration there would be a cluster service group for inter-cluster communication which will have unique gcoip, heartbeat and wac.further i need to configure service group for application at each cluster with same name but resources can be different. i would like to mention that the network is same subnet across the sites so my cluster and the nodes are falls in same subnet ( i have checked with Symantec consultant and they said it fine for same subnet ).

here when i configure the sg and its resource on each cluster the resources will come online but i have a doupt how to configure the sg vip ? each sg will have separate vip,  if so how the clients will connect to vip as the clients would be pointing to one vip? or any kind of network NAT is required ?

anyhelp is highly appreciated.

 

Thanks

Uv

 

1 ACCEPTED SOLUTION

Accepted Solutions

mikebounds
Level 6
Partner Accredited

Here's an example:

Site1:

Cluster VIP 1.1.1.1 (IP resource in ClusterService service group)

App1 VIP 1.1.1.11 (IP resource in SG1 service group)

App2 VIP 1.1.1.12 (IP resource in SG2 service group)

 

Site 2:

Cluster VIP 1.1.1.2 (IP resource in ClusterService service group)

App1 VIP 1.1.1.11 (IP resource in SG1 service group)

App2 VIP 1.1.1.12 (IP resource in SG2 service group)

 

Clients for App1 connect to 1.1.1.11 and clients for App2 connect to 1.1.1.12.

The 2 clusters communicate using 1.1.1.1 and 1.1.1.2, so the ClusterService group should always be online in bot clusters.

SG1 and SG2 are configured as global service groups so GCO only allows SG1 to be online on one site and the same for SG2 and so SG1 and SG2 can fail locally within th cluster or across sites.

Mike

 

View solution in original post

3 REPLIES 3

mikebounds
Level 6
Partner Accredited

Here's an example:

Site1:

Cluster VIP 1.1.1.1 (IP resource in ClusterService service group)

App1 VIP 1.1.1.11 (IP resource in SG1 service group)

App2 VIP 1.1.1.12 (IP resource in SG2 service group)

 

Site 2:

Cluster VIP 1.1.1.2 (IP resource in ClusterService service group)

App1 VIP 1.1.1.11 (IP resource in SG1 service group)

App2 VIP 1.1.1.12 (IP resource in SG2 service group)

 

Clients for App1 connect to 1.1.1.11 and clients for App2 connect to 1.1.1.12.

The 2 clusters communicate using 1.1.1.1 and 1.1.1.2, so the ClusterService group should always be online in bot clusters.

SG1 and SG2 are configured as global service groups so GCO only allows SG1 to be online on one site and the same for SG2 and so SG1 and SG2 can fail locally within th cluster or across sites.

Mike

 

Gaurav_S
Moderator
Moderator
   VIP    Certified

Hi,

Ideally you would be configuring different SGs for different components or purpose right ? for e.g you may have separate databases in separate sgs or you may have one sg containing database, other sg containing application or middleware components etc. So depending on what you are using you need to take decision on vip.

If its a multi database cluster, you will have different listeners which will need different vips. For cluster management purpose every cluster must have a vip, which is tied to the cluster. This IP address will be defined in the cluster's ClusterAddress attribute. This address is normally configured as part of the initial VCS installation.

vip inside a service group will be common across sites,this is required because as site failover happens, applications will still search for same IP as primary & try to connect to those vips. E.g which Mike gave above explains same.

 

G

uvahpux
Level 4
Partner

Thanks mike, my concern is cleared now as i was thinking IP conflict between sg vip because of same subnet. so in this case after linking the sgs between clusters as global it will make sure that only one configured sg will be online globally and in the event of site failure the global cluster will enable other sg to come online and the clients request will be directed to DR site.

thanks gaurav for additional info, we will have only one sg for application.

Thanks.

Uv