iCluster replication group *HADR

Hi,

I came across this in the icluster user manual and wonder if it is a exact replacement for the ICLSTAPY tool.
Have anyone implement *HADR replication group or came across any rocket technote for *HADR replication group ? 
Ps:i  dun see this featured on the rocket icluster blog.

------------------------------
ZQ L

------------------------------

Hi ZQ L,

Thank you for the question and suggestion of a new blog entry. 

The old tool for ICLASTAPY function is not required any longer because that function is included in iCluster commands and functions without the need for the additional tool.

An *HADR replication group type is available for three node configurations.  A single replication group definition along with all the selections for replication are orchestrated to two targets.  When defining the group parameters you will see node definition for the PRIMARY, HA backup and DR backup node entries. Customers find that this group configuration type can reduce complexity when switching between the PRIMARY and HA instance and continuing replication to the DR instance.

In the online help for *HADR group definition within the DMADDGRP function you will find the following assistance:

 *HADR
Specifies a replication group intended for both high
availability (HA) and disaster recovery (DR). An *HADR
group has one primary node and two backup nodes - one
for high availability and one for disaster recovery.
When a roleswitch is done with an *HADR group, the HA 
backup node becomes the new primary node and the
previous primary node becomes the new HA backup node.
The role of the DR backup node is not changed.
Replication in an *HADR group is from the primary node
to both of the backup nodes.

Thanks for the question and keep them coming!

------------------------------
Mark Watts
Rocket Software
------------------------------

Hi ZQ L,

Thank you for the question and suggestion of a new blog entry. 

The old tool for ICLASTAPY function is not required any longer because that function is included in iCluster commands and functions without the need for the additional tool.

An *HADR replication group type is available for three node configurations.  A single replication group definition along with all the selections for replication are orchestrated to two targets.  When defining the group parameters you will see node definition for the PRIMARY, HA backup and DR backup node entries. Customers find that this group configuration type can reduce complexity when switching between the PRIMARY and HA instance and continuing replication to the DR instance.

In the online help for *HADR group definition within the DMADDGRP function you will find the following assistance:

 *HADR
Specifies a replication group intended for both high
availability (HA) and disaster recovery (DR). An *HADR
group has one primary node and two backup nodes - one
for high availability and one for disaster recovery.
When a roleswitch is done with an *HADR group, the HA 
backup node becomes the new primary node and the
previous primary node becomes the new HA backup node.
The role of the DR backup node is not changed.
Replication in an *HADR group is from the primary node
to both of the backup nodes.

Thanks for the question and keep them coming!

------------------------------
Mark Watts
Rocket Software
------------------------------

Hi Mark,

Could a *REPL group directly convert as a *HADR group ?
Could a *HADR group change back to *REPL group ?
So this would be a solution where the ICPROD and ICHA sharing the same IASP device replicating to a DR node with its own IASP disk ?

------------------------------
ZQ L

------------------------------

Hi Mark,

Could a *REPL group directly convert as a *HADR group ?
Could a *HADR group change back to *REPL group ?
So this would be a solution where the ICPROD and ICHA sharing the same IASP device replicating to a DR node with its own IASP disk ?

------------------------------
ZQ L

------------------------------

Hi ZQ L,

I'm afraid converting a three node relationship to a two node replication group (and back) would not work well.  I don't have a three node configuration ready I can go attempt it for you but I'm not confident that would result with the desired working replication design.  However, in my opinion, there is a better way to get to the desired conversion configuration.

1. Use command RTVHACFGS with the group name to capture all of your groups' configuration and selections into CL source code.
2. Modify the resulting source into the desired new group configurations (whether you decide to just add new REPL groups to include the cluster node you are wanting to broadcast the data to OR leveraging a HADR replication group definition to take advantage of its benefits.
3. Check and Compile your new definitions
4. Depending on your design goals, you may need to pause replication and remove any conflicting replication groups...  Don't forget the ability to change a group to a STDBY group type which will delete all of the groups journal position metadata.  Best scenario would be at a time you can schedule the users and applications stopped.
3. When you are ready to activate your new replication groups, submit your metadata changes, mark your positions for group startup and start replication at the marked position.

Basically the procedure I am describing is removing the groups and adding new groups with the new cluster goals in mind.  If you are actually attempting to start with REPL groups and adding a temporary target node, you can do that by adding new REPL groups with the two desired node relationships without disrupting the current replication streams.  Then after the need is fulfilled, the temporary groups could be ended and removed.  If you anticipate you would need them again in the future, another option would be to change them to STDBY until they are needed or removed.

Hope that is in line with what you were thinking.



------------------------------
Mark Watts
Software Engineer
Rocket Software Inc
Waltham MA United States
------------------------------

Hi ZQ L,

I'm afraid converting a three node relationship to a two node replication group (and back) would not work well.  I don't have a three node configuration ready I can go attempt it for you but I'm not confident that would result with the desired working replication design.  However, in my opinion, there is a better way to get to the desired conversion configuration.

1. Use command RTVHACFGS with the group name to capture all of your groups' configuration and selections into CL source code.
2. Modify the resulting source into the desired new group configurations (whether you decide to just add new REPL groups to include the cluster node you are wanting to broadcast the data to OR leveraging a HADR replication group definition to take advantage of its benefits.
3. Check and Compile your new definitions
4. Depending on your design goals, you may need to pause replication and remove any conflicting replication groups...  Don't forget the ability to change a group to a STDBY group type which will delete all of the groups journal position metadata.  Best scenario would be at a time you can schedule the users and applications stopped.
3. When you are ready to activate your new replication groups, submit your metadata changes, mark your positions for group startup and start replication at the marked position.

Basically the procedure I am describing is removing the groups and adding new groups with the new cluster goals in mind.  If you are actually attempting to start with REPL groups and adding a temporary target node, you can do that by adding new REPL groups with the two desired node relationships without disrupting the current replication streams.  Then after the need is fulfilled, the temporary groups could be ended and removed.  If you anticipate you would need them again in the future, another option would be to change them to STDBY until they are needed or removed.

Hope that is in line with what you were thinking.



------------------------------
Mark Watts
Software Engineer
Rocket Software Inc
Waltham MA United States
------------------------------

Hi Mark,

Thanks for the reply. I am on  a 3 node setup. 2 nodes(ICPROD,ICHA) share a single IASP and replicate the IASP data thru iCluster to another node ICRMT, Whenever there is a IASP switch between the ICPROD and ICHA, IASP replication to ICRMT will be continue using ICLSTAPY.

I have the impression or was told that  *HADR would be able replace the ICLSTAPY as there are some complexity using the ICLSTAPY tool.

------------------------------
ZQ L

------------------------------