Notes: Oracle Key Vault 21.9 multimaster concept

 

Oracle Key Vault - Multimaster setup notes:

url: https://docs.oracle.com/en/database/oracle/key-vault/21.9/okvag/multimaster_concepts.html#GUID-E1A92D83-760F-470F-877F-D769169C6ABC

3.1 Multimaster overview: 

1.High available, load distribution, disaster recovery, geographical distribution

2.smallest is a node 2 node cluster and largest is 16 node cluster

3.the update to security object is successful only after the replication between RW pair is successful

3.2 Benefits of multimaster setup:

1.standalone OKV offers least availability vs active-standby offers limited availability vs read/write (active-active) - pairs offer max availability 

2.persistent cache is optional in multimaster environment vs in other deployment modes it is mandatory

3.mutimaster (Active-active) offers HA and dR

4.maintenance operATIONS can be conducted online (both hardware and software)

3.3 Multimaster architecture

cluster node : individual OKV node or server; the process of converting an individual node to a cluster node is called induction

cluster limitation: multimaster replicate data in async. IP add is static, node remove/add is needed.Only one cluster operation at a time is possible [adding, disabling, deleting]

cluster subgroup: subset of nodes in the cluster, used for node affinity; nodes in the same subgroup are used in the search order first (considering them to be local to the endpoint); it isnt manadtory the read-write pair goes into 1 subgroup.

critical data: all endpoint data which are needed for the operation of db system or other security system are considered critical data and the ones which can be recreated @ OKV are non critical. The critical data is kept replicated amongst read-only and read-write pair as well.

RW pair - Replication between read write : Synchornous & with other nodes it is asynchoronous. This way we can be sure data is available in atleast 2 nodes.

Read only: affects only non critical data change; also the only RW pair goes to read only mode in case RO node is unavailable.

Based on the operating mode of the node: the operations permitted will change

3.4 Building multimaster cluster

Node which becomes first member of the cluster : first node or controller node

First node or Initial node: supplies the data; which will be replicated to other nodes [this node can be a fresh data or existing setup, existing setup in active - standby config]

Expansion of cluster: controller node inducts further nodes in RW mode or READ only mode further

Management of cluster reconfig: one cluster reconfig at a time allowed, only 1 controller node per cluster allowed (refer to picture 9)

Cluster Configuration Operation	Controller Node	Node Being Controlled
Induction as the first node	Any server	The controller node itself
Induction as a read-only node	Any node	Any server
Induction as a read-write node	Any node that does not have a read-write peer	Any server
Disable a node	Any node in the cluster	Any node in the cluster
Enable a node	Only the disabled node can re-enable itself	The disabled node itself
Delete a node	Any node in the cluster	Any other node in the cluster
Force Delete a node	Any node in the cluster	Any other node in the cluster
Manage inbound replication	Any node in the cluster	The node itself

Addition of more nodes in multimaster cluster: Node 2 becomes restricted read only until the new node (N2) is added  in cluster with node 1 (N1). The controller node can read write pair with other node in the cluster; further nodes will become rw pairs of their own.

conversion of the existing OKV: if the version of existing setup is latest, we can just convert the existing node to an initial node of the cluster.

convert physical-standby node: break the physical standby config, upgrade to latest release and then attempt to convert primary to initial node role.

3.5 Deployment scenarios

size: small 2 node to large 16 node cluster

2 node cluster vs 4 node cluster: both machines going offline is a concern in 2 node cluster vs in 4 node it isnt concern. hence with more nodes the risk of downtime reduces

3.6 features of multimaster cluster:

cluster inconsistency resolution: network disruption happens, then the nodes voluntarily or involuntarily gets disconnected from the cluster; if the issue resolves within 24hrs (Default disconnect max duration), the cluster will come to sync again by replicating the data collected during disconnect window.

name conflict resolution: cluster will automatically correct same names given in both the rw pairs by mistake by appending _okvnn (nn is node id), we can accept it by going to cluster -> name resolution page.

Endpoint node connection lists (endpoint node scanlist): list of all nodes an endpoint should scan to connect in a multimaster cluster - the scan list is automatically maintained by the cluster

3.7 cluster management information:

cluster management information: is the page which provides an overview of the cluster with all the nodes listed

a. cluster name

b. cluster sub group name

c. max disconnect interval

d. node list

e. node type

f. node id

g. node name

h. node ip

i. cluster version

j. node version

k. replication lag