Skip to main content

We've Moved!

Product Documentation has moved to docs.hitachivantara.com
Hitachi Vantara Knowledge

Pausing and resuming replication or recovery of a tenant

You can pause and resume replication or recovery of an individual tenant on a replication link. Pausing replication or recovery of a tenant on a link causes the Replication service on the sending system to stop all send activity for the tenant on that link. With an active/active link, the Replication service on both systems involved in the link stops all send activity for the tenant on the link.

Resuming replication or recovery of a tenant on a link restarts all send activity for that tenant on that link. After pausing replication or recovery of a tenant on a link, you need to resume replication or recovery manually.

You might pause replication of some tenants on a link, for example, to give more processing time to other tenants with greater replication backlogs. While replication or recovery of a tenant is paused on a link, the two systems involved in the link can still use the link to read from each other the objects in the tenant's replicated namespaces.

Replication or recovery of a tenant can also be paused automatically due to certain events. After replication or recovery of a tenant is paused automatically, you need to resume replication or recovery manually. However, you cannot do this until the issue that caused replication or recovery to be paused is resolved.

Pausing replication or recovery of a tenant on a link in an erasure coding topology prevents each system involved in the link from sending full copies of object data and chunks for objects in the tenant's namespaces to the other system over that link. Pausing replication or recovery of a tenant, therefore, may prevent newly ingested objects in those namespaces from being protected.

Pausing replication or recovery of a tenant on a link does not prevent full copies of object data in the tenant's namespaces from being reduced to chunks on the systems involved in that link.

The Replication service periodically checkpoints its progress. When you pause replication or recovery of a tenant, no special checkpoint occurs. When you resume processing, therefore, processing starts from the last checkpoint before the pause.

Pausing and resuming tenant replication or recovery

  1. In the top-level menu of the HCP System Management Console, select Services Replication.

  2. On the replication Links page, click the link for which you want to pause or resume replication or recovery.

  3. On the replication link details page, click Status.

  4. In the link Status panel, click the Tenants tab.

  5. In the list of tenants, click the pause control (GUID-F7740D60-067B-4B8F-B304-AE6B27F3BB08-low.png) or resume control (GUID-156CE90F-380E-4281-BFD4-E3671E00BD79-low.png), as applicable, for the tenant for which you want to pause or resume activity.

Automatically paused tenant replication or recovery

Certain events can cause the Replication service to automatically pause replication or recovery of a tenant on a replication link. The following sections describe these events.

TipTo avoid situations that can cause the Replication service to automatically pause replication of a tenant, do not try to create the same tenants, namespaces, content classes, user accounts, and group accounts on both of the systems that are replicating to each other on an active/active link. Instead, allow the items you create on each system to replicate to the other system.

Tenant name collisions

A tenant name collision occurs when the Replication service tries to replicate an HCP tenant from one HCP system to another HCP system that already has a different tenant with the same name.

To recover from a tenant name collision, take one of these actions:

  • Rename the tenant on one of the systems involved in the link.
  • Delete the tenant on the receiving system.

Here are two scenarios that show how a tenant name collision can cause the Replication service to pause replication of a tenant.

Scenario 1

In this scenario:

  • System A replicates to system B on link AB. Link AB can be either active/active or active/passive.
  • System A has a tenant named T1 that is not on link AB.

These events occur in the order shown:

  1. On system A, you add T1 to link AB.
  2. Before T1 is replicated to system B, you create a tenant named T1 on system B.
  3. The Replication service tries to replicate T1 to system B. The replication is unsuccessful because a different tenant named T1 already exists on system B. As a result, the service automatically pauses replication of T1 on link AB.
Scenario 2

In this scenario:

  • System A replicates to system B on link AB, which replicates to system C on link BC, where link AB is chained into link BC. Link AB can be either active/active or active/passive. Link BC is active/passive.
  • System A and system C each have a tenant named T1, where T1 was created independently on each system.

These events occur in the order shown:

  1. On system A, you add T1 to link AB.
  2. T1 is replicated to system B.
  3. Because link BC includes link AB, the Replication service tries to replicate T1 to system C. The replication is unsuccessful because a different tenant named T1 already exists on system C. As a result, the service automatically pauses replication of T1 on link BC.

Namespace name collisions

Each HCP namespace you create in an HCP system has an internal ID that uniquely identifies that namespace. As a result, two namespaces created on different systems are different from each other, even if they have the same name and are owned by the same tenant.

A namespace name collision occurs when the Replication service tries to replicate a namespace from one system to another system that already has a different namespace with the same name, where both namespaces are owned by the same tenant.

To recover from a namespace name collision, take one of these actions:

  • Rename the namespace on one of the systems involved in the link.
  • Deselect the namespace from replication.
  • Delete the namespace on the receiving system.

Here’s a scenario that shows how a namespace name collision can cause the Replication service to pause replication of a tenant. In this scenario:

  • System A and system B replicate to each other over active/active link AB.
  • Link AB includes tenant T1, so T1 exists on both systems.
  • On system A, T1 owns namespace NS1, which is not selected for replication.

These events occur in the order shown:

  1. On system A, you select NS1 for replication.
  2. Before NS1 is replicated to system B, you create a namespace named NS1 for T1 on system B.
  3. The Replication service tries to replicate NS1 to system B. The replication is unsuccessful because a different namespace named NS1 already exists on system B. As a result, the service automatically pauses replication of T1 on link AB.

Namespace compliance issues

Different HCP systems can have different definitions for service plans with the same name. When an HCP tenant or namespace is replicated, the name of its associated service plan, not the service plan itself, is replicated with it. As a result, the service plan that applies to a namespace can differ on the two HCP systems involved in a link on which the namespace is being replicated.

Service plans can be compliant or noncompliant. However, the service plan that applies to a namespace in compliance mode must be compliant. A namespace compliance issue occurs when replication of a namespace in compliance mode would cause a noncompliant service plan to apply to the namespace on the receiving system.

To recover from namespace compliance issue, take one of these actions:

  • Redefine the noncompliant service plan on the receiving system to be compliant.
  • If the service plan is assigned to the tenant that owns the namespace, assign a different service plan to the tenant on the sending system, where that service plan is complaint on both systems involved in the link.
  • If the service plan is assigned to the namespace, have the tenant administrator assign a different service plan to the namespace on the sending system, where that service plan is complaint on both systems involved in the link.
  • Deselect the namespace from replication.

Here are two scenarios that show how a namespace compliance issue can cause the Replication service to pause replication of a tenant.

Scenario 1

In this scenario:

  • System A replicates to system B on link AB. Link AB can be either active/active or active/passive.
  • Link AB includes tenant T1, so T1 exists on both systems.
  • On system A, T1 owns namespace NS1, which is in compliance mode. NS1 not selected for replication.
  • The service plan that applies to NS1 is named SP1. SP1 is compliant on system A and noncompliant on system B.

These events occur in the order shown:

  1. On system A, you select NS1 for replication.
  2. The Replication service tries to replicate NS1 to system B. The replication is unsuccessful because it would cause NS1, which is in compliance mode, to have a noncompliant service plan on system B. As a result, the service automatically pauses replication of T1 on link AB.
Scenario 2

In this scenario:

  • System A replicates to system B on link AB. Link AB can be either active/active or active/passive.
  • Link AB includes namespace NS1, which is owned by tenant T1, so NS1 exists on both systems.
  • NS1 is in enterprise mode, not compliance mode.
  • The service plan that applies to NS1 is named SP1. SP1 is compliant on system A and noncompliant on system B.

These events occur in the order shown:

  1. On system A, you change NS1 to be in compliance mode.
  2. The Replication service tries to replicate the change to system B. The replication is unsuccessful because it would cause NS1 to be in compliance mode with a noncompliant service plan on system B. As a result, the service automatically pauses replication of T1 on link AB.

Content class collisions

Each content class you create in an HCP system has an internal ID that uniquely identifies that content class. As a result, two content classes created on different HCP systems are different from each other, even if they have the same name and are defined for the same tenant.

A content class collision occurs when the Replication service tries to replicate a content class from one system to another system that already has a different content class with the same name, where both content classes are defined for the same tenant.

To recover from a content class collision, take one of these actions:

  • Rename the content class on either of the systems involved in the link.
  • Delete the content class on either of the systems involved in the link.

Here’s a scenario that shows how a content class collision can cause the Replication service to pause replication of a tenant. In this scenario:

  • System A and system B replicate to each other over active/active link AB.
  • Link AB includes tenant T1, so T1 exists on both systems.

These events occur in the order shown:

  1. On system A, you create a content class named CC1 for T1.
  2. Before CC1 is replicated to system B, you create a content class named CC1 for T1 on system B.
  3. The Replication service tries to replicate CC1 to system B. The replication is unsuccessful because a different content class named CC1 already exists on system B. As a result, the service automatically pauses replication of T1 on link AB.

User account collisions

Each user account you create in an HCP system has an internal ID that uniquely identifies that user account. As a result, two user accounts created on different systems are different from each other, even if they have the same username and are defined for the same HCP tenant.

A user account collision occurs when the Replication service tries to replicate a user account from one system to another system that already has a different user account with the same username, where both user accounts are defined for the same tenant.

To recover from a user account collision, take one of these actions:

  • Change the username for the user account on either of the systems involved in the link.
  • Delete the user account on either of the systems involved in the link.

Here’s a scenario that shows how a user account collision can cause the Replication service to pause replication of a tenant. In this scenario:

  • System A and system B replicate to each other over active/active link AB.
  • Link AB includes tenant T1, so T1 exists on both systems.

These events occur in the order shown:

  1. On system A, you create a user account with username U1 for T1.
  2. Before U1 is replicated to system B, you create a user account with username U1 for T1 on system B.
  3. The Replication service tries to replicate U1 to system B. The replication is unsuccessful because a different user account with username U1 already exists on system B. As a result, the service automatically pauses replication of T1 on link AB.

Group account collisions

Each HCP group account you create in an HCP system has an internal ID that uniquely identifies that group account. As a result, two group accounts created on different systems are different from each other, even if they are created from the same Active Directory group and are defined for the same HCP tenant. (An HCP group account always has the same name as the AD group it’s created from, so group accounts created from the same AD group on two different systems have the same name as each other.)

A group account collision occurs when the Replication service tries to replicate a group account from one system to another system that already has a different group account created from the same AD group, where both group accounts are defined for the same tenant.

To recover from a group account collision, delete the group account on either of the systems involved in the link.

Here’s a scenario that shows how a group account collision can cause the Replication service to pause replication of a tenant. In this scenario:

  • System A and system B replicate to each other over active/active link AB.
  • Link AB includes tenant T1, so T1 exists on both systems.

These events occur in the order shown:

  1. On system A, you create an HCP group account for T1 from the AD group named AD1. The name of the group account you create is AD1.
  2. Before AD1 is replicated to system B, you create an HCP group account for T1 from the AD group named AD1 on system B. The name of the group account you create is AD1.
  3. The Replication service tries to replicate the HCP group account named AD1 to system B. The replication is unsuccessful because a different group account named AD1 already exists on system B. As a result, the service automatically pauses replication of T1 on link AB.

Tenant conflicts

A tenant conflict occurs when you add a tenant to an erasure coding topology and that tenant is on one or more replication links where:

  • The link is not in the topology
  • One or both of the systems involved in the link are in the topology

When a tenant conflict occurs, the Replication service automatically pauses replication or recovery of the tenant on each link that meets the criteria listed above.

To recover from a tenant conflict, take one of these actions:

  • Remove the tenant from the links on which replication or recovery of the tenant is paused.
  • Remove the tenant from the erasure coding topology. Then resume replication or recovery of the tenant on the applicable links.

Here's a scenario that shows how a tenant conflict can cause the Replication service to pause replication of a tenant. In this scenario:

  • Erase coding topology ECT1 is a ring topology that consists of:
    • Systems A, B, C, and D
    • Active/active link AB between systems A and B
    • Active/active link BC between systems B and C
    • Active/active link CD between systems C and D
    • Active/active link DA between systems D and A
  • ECT1 is the active erasure coding topology.
  • Tenant T1 is included in topology ECT1. Therefore, T1 is included on links AB, BC, CD, and DA and exists on systems A, B, C, and D.
GUID-836610F1-96BF-4A85-84A2-9986648B62B3-low.png

These events occur in the order shown:

  1. You deploy system E.
  2. You retire topology ECT1.
  3. You create active/active link BE between systems B and E.
  4. You create active/active link CE between systems C and E.
  5. You create a new topology, ECT2, that consists of systems B, C, and E and links BC, BE, and CE.GUID-A542269D-8F80-496E-B539-492F1EC75DB9-low.png
  6. You add tenant T1 to topology ECT2.
  7. All of these occur:
    • T1 is added to links BE and CE and is replicated to system E.
    • The Replication service on system B pauses replication or recovery of T1 on link AB because system B is in topology ECT2 and system A is not
    • The Replication service on system C pauses replication or recovery of T1 on link CD because system C is in topology ECT2 and system D is not
    GUID-E6C0736C-2D35-4973-93E9-AAF595A8A11B-low.png

 

  • Was this article helpful?