Rocket iCluster

 View Only
  • 1.  iCluster replication group *HADR

    Posted 04-28-2021 21:44
    Edited by Zq L L 08-10-2021 22:16
    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

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


  • 2.  RE: iCluster replication group *HADR

    ROCKETEER
    Posted 04-30-2021 15:30
    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
    ------------------------------



  • 3.  RE: iCluster replication group *HADR

    Posted 08-10-2021 05:09
    Edited by Zq L L 08-10-2021 22:16
    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

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



  • 4.  RE: iCluster replication group *HADR

    ROCKETEER
    Posted 08-10-2021 11:03
    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
    ------------------------------



  • 5.  RE: iCluster replication group *HADR

    Posted 08-10-2021 22:16
    Edited by Zq L L 08-10-2021 22:16
    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

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