This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Governance Registry Deployment Patterns

The following are the minimum deployment patterns for WSO2 Governance Registry considering the common scenarios that the product is used for.

Minimum HA setup (without SSO)

The minimum deployment pattern for Governance Registry without single sign-on includes two Governance Registry nodes. One node is always active and receives and services requests, while the other is passive and only services requests when the other node is unavailable for some reason. This deployment pattern is for a more traditional scenario where the publisher and store are not used much.

Minimum HA setup (with SSO)

In a single sign-on scenario, the publisher, store and Carbon components of Governance Registry can all be set up for access by a single login. The minimum deployment pattern includes two Governance Registry nodes configured with an external identity provider. The user's identity is stored in a user store that can be accessed by the identity provider. The WSO2 Identity Server can be used as an identity provider here as well.

Minimum HA setup (embedded SSO)

This is similar to the previous deployment pattern, only there is no external identity provider and the single sign-on happens with the help of an embedded identity provider.

Minimum distributed HA setup (with SSO)

In a fully distributed highly available setup, four Governance Registry instances are used. Two instances run as publishers and two as stores. One publisher and store will always be active to service requests. An external identity provider is used to handle the single sign-on aspect.

Minimum distributed HA setup (with SSO and WSO2 API Manager)

This pattern caters to the scenario where the Governance Registry is deployed along with the WSO2 API Manager in a distributed manner. In a typical API Manager distributed deployment, you would have a gateway node, a key manager node, a publisher and a store. In this scenario, the publisher and store can be Governance Registry nodes to handle the governance aspect of the solution. The gateway is a typical API Manager gateway node but the key manager is an IS node configured to work as the key manager. This key manager node handles the single sign-on aspect of the deployment. So this deployment has a minimum of four Governance Registry instances (two publishers and two stores, with one publisher and store active and one of each passive). It has two API Manager gateway nodes for high availability and a single Identity Server as a key manager instance.