Browse Prior Art Database

Prevention of DR Configuration Drifts in geographically separated application clusters

IP.com Disclosure Number: IPCOM000246681D
Publication Date: 2016-Jun-27
Document File: 6 page(s) / 74K

Publishing Venue

The IP.com Prior Art Database

Related People

Sunil Yadav: INVENTOR [+2]

Abstract

i. Configuring the application for disaster recovery such that a configuration policy defined once on any host of a cluster is automatically synchronized on all the nodes of all the clusters. ii. The method used does not leverage a Replicate State Machine approach to effect this change (thus more scalable). iii. The method applies to traditional clustered application setups like Oracle RAC, Microsoft Fail over clustering (and not to scale out distributed application environments – like Hadoop).

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 26% of the total text.

Page 01 of 6

Prevention of DR Configuration Drifts in geographically separated application clusters

Sunil Yadav

Anand Bhalerao

Abstract


i. Configuring the application for disaster recovery such that a configuration policy defined once on any host of a cluster is automatically synchronized on all the nodes of all the clusters.


ii. The method used does not leverage a Replicate State Machine approach to effect this change (thus more scalable).


iii. The method applies to traditional clustered application setups like Oracle RAC, Microsoft Fail over clustering (and not to scale out distributed application environments - like Hadoop).

Problem Statement

In Veritas Cluster Server, geographically separated (more than 80 kilometers) clusters can form GCO (Global Cluster Option). GCO is most commonly used for disaster recovery.

Service groups configured across GCO clusters are called global service group. In case of application fault or cluster fault, if service groups can't failover in local cluster, it is failed over on remote/DR clusters. There are paint points w.r.t. configuring/managing such application deployments.

a) Configuring application in GCO. b) Modeling applications in DR configuration (adding Global Service Group and Resources).

c) Synchronizing application availability configuration changes across clusters.

With today's implementation, we have seen escalation around configuration mismatch across clusters. E.g.

    i. Group not treated as "Global Service Group" across clusters

1

© 2016 Veritas Technologies LLC. All rights reserved. Veritas and the Veritas Logo are trademarks or registered trademarks of Veritas Technologies LLC or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners.


Page 02 of 6

ii. Different ClusterFailOverPolicy on different clusters

    iii. AutoStart failed because of configuration mismatch

Publication Description

Key aspects of the invention are:
1. Simplified provisioning of Secondary/remote clusters from existing Primary cluster.


2. Synchronizing application availability configuration changes across clusters (i.e. initiated from a node in a cluster and implemented on all nodes in all clusters).


3. Detecting configuration mismatch between clusters.


4. Mechanism to enforce valid configuration to mismatching clusters.

Invention is elaborated with VCS GCO use case.

VCS GCO Overview: Veritas Cluster Server provides high availability to applications configured on systems in cluster. Geographically separated (more than 80 kilometers) clusters can form GCO (Global Cluster Option), which is most commonly used for disaster recovery. Service groups (representing managed applications) spanning across GCO clusters is known as Global Service Group. In case of application fault or cluster fault, if global service groups can't failover in local cluster, it is failed over on remote/DR clusters. WAC process: WAC is key component of VCS GCO. It runs on one system in each cluster and connects...