10-06-2020 11:51 PM
ENVIRONMENT
Primary site = two nodes
DR site = one node
Product = Infoscale High Availability 7.4
Cluster configuration =
1- Global cluster option is configured, Failover Policy is AUTO configured for GLOBAL Service Group between both clusters.
2- Service Group-I Primary and DR site HA resource is configured with parallel service group
3- Service Group-II Primary and DR site HA resource is configured with failover service group
QUERY
Can we make Service Group-II (failover service group) dependency with Service Group-I (parallel service group) & in case Service Group-II faults it failover to standby node at Primary site. However in case Service Group-II faults on both nodes then the Service Group-II must failover to DR node with Service Group-I (even no issue with Service Group-I)
10-07-2020 03:24 AM
Yes you can.
in most GCO configuration, storage(VxVM, VxFS, VVR etc) related resources are placed in a rarallel service group (child) on the local cluster dependency tree) and the applications (web.DB etc) are placed in a failover group (parent), whenever there is a fault occurs on the production cluster, the service group where the failed resource is in will be failed over to the local standby node (single node cluster is therefore not recommended). If for whatever reason the applications are not be able to go online in this service group failover operation, the service groups will be switched over (failover) to the DR cluster. Assum you use VVR for pthe rod/DR sites data replication. If the network is OK and VVR is configured properly, VCS VVR agents shuld be able to make the DR site as a new primary in regards to data replication/
10-07-2020 10:28 PM
Its Infoscale HA so no replication is there, furthermore no replication required in my case as we only need application availability or its no data tier. Just application.
10-08-2020 03:04 AM
thanks for the update.
since there is no data replication involoved, the service group site failover/switch should be very straightforward as data replication site roll change (promote the DR sote as a new master) is most "trpublesome" part of a global service group site failover/migration. What you need to make sure in place is a correct set service group dependency/resource dependency to ensure that an application "concurrency violation" would not occur.
Make sure to test the service group site failover or switch before putting the cluster in production.