HCP System Management Help


Considerations for specifying link content

These considerations apply to specifying the content for replication links:

The content for a replication link (that is, what is replicated on the link) consists of any number of:

oHCP tenants

oHCP namespaces

oDirectories defined in the default namespace

oFor active/passive links only, chained links

You cannot have two or more replication links that are pointed at the same replica system share a tenant. If two replication links point at the same replica system, they must have their own separate tenant lists with not overlap.

You can choose which namespaces to replicate for any given HCP tenant only if that tenant has granted system-level users administrative access to itself. Namespaces that are selected for replication are replicated on every link that includes the owning tenant.

You can add and remove HCP tenants, default-namespace directories, and chained links from a replication link at any time, except during an upgrade of either system involved in the link, while the link is failed over, while data recovery is occurring on the link, or while the two systems involved in the link cannot communicate with each other.

To select and deselect HCP namespaces for replication, you can use any link that includes the owning tenant.

You can select HCP namespaces for replication at any time, except during an upgrade of either system involved in the link you started from. You can deselect HCP namespaces from replication at any time, except during an upgrade of either system involved in the link you started from, while a link that includes the owning tenant is failed over, or while data recovery is occurring on a link that includes the owning tenant.

When you add one or more default-namespace directories to a link, some objects in directories that were already included in the link may be reprocessed. This can increase the replication backlog for the default namespace.

You cannot add an HCP tenant to an active/passive link if the same tenant already exists on the replica. Two tenants are the same as each other if they have the same internal ID.

The only way the same tenant can exist on two systems is if it was created on one system and then replicated to the other system. Changing the name of the tenant on either of the systems does not make the two tenants different from each other.

You cannot add an HCP tenant to any type of replication link if a different tenant with the same name already exists on the other system involved in the link. In this case, however, if you change the name of the tenant on either of the systems involved, you can add the tenant to the link.

You cannot add a default-namespace directory to an active/passive link if a directory with the same name already exists on the replica. If the directory is empty on the primary system or the replica, you can change the directory name on that system. Then you can add the directory to the link.

You cannot chain a replication link between system A and system B into an active/passive link between system B and system C if an HCP tenant included in the first link has the same name as a different tenant that already exists on system C. However, if you change the name of the tenant on system A or system C, you chain add first link into the second link.

You cannot chain a replication link between system A and system B into an active/passive link between system B and system C if an HCP tenant included in the first link is the same as a tenant that already exists on system C, regardless of whether the tenant names are the same.

You cannot chain a replication link between system A and system B into an active/passive link between system B and system C if a default-namespace directory included in the first link has the same name as a default-namespace directory that already exists on system C.

In a replication chain with the configuration A4B4C, if you add an HCP tenant to the link from system A to system B and the same tenant already exists on system C, replication of that tenant from system B to system C is automatically paused. To recover from this situation:

1.Either delete the tenant on system C, or remove the tenant from the link from system A to system B.

2.Resume replication of the tenant on the link from system B to system C.

For information on resuming replication of a tenant, see Pausing and resuming replication or recovery of a tenant.

In a replication chain with the configuration A4B4C, if you add an HCP tenant to the link from system A to system B and a different tenant with the same name already exists on system C, replication of that tenant from system B to system C is automatically paused. To recover from this situation:

1.Either rename the tenant on system C, delete the tenant on system C, or remove the tenant from the link from system A to system B.

2.Resume replication of the tenant on the link from system B to system C.

In a replication chain with the configuration A4B4C, if you add a default-namespace directory to the link from system A to system B and a default-namespace directory with the same name already exists on system C, replication of the default tenant from system B to system C is automatically paused. To recover from this situation:

1.Either rename the directory on system C, delete the directory on system C, or remove the directory from the link from system A to system B. The first two options are possible only if the directory is empty on system C.

2.Resume replication of the default tenant on the link from system B to system C.

In a replication chain with the configuration A4B4C, if you add a default-namespace directory to the link from system A to system B and either of these is true, replication of the default tenant from system B to system C is automatically paused:

oThe default namespace doesn’t exist on system C. To recover from this situation:

1.Create the default namespace on system C with the same retention mode and cryptographic hash algorithm as the default namespaces on systems A and B have.

2.Resume replication of the default tenant on the link from system B to system C.

oThe default namespace exists on system C but has a different retention mode or cryptographic hash algorithm from the default namespaces on systems A and B. To recover from this situation:

1.Delete the default-namespace directory from the link from system A to system B.

2.Resume replication of the default tenant on the link from system B to system C.

Once you remove an HCP tenant or directory from an active/passive link, you cannot add it back to that link unless you first delete it from the replica. This is because the tenant or directory now already exists on the replica.

On the Replication page in the System Management Console, each panel in which you can add and remove items of a specific type to and from a replication link includes a list of the items of the applicable type that are already included in the link. In those lists, rows containing items that have been deleted from HCP are highlighted in red and have a trash can icon ( ) on the right.

HCP automatically removes each deleted namespace from a link after the deletion has been replicated. You need to remove deleted tenants and directories yourself.

Important: Do not remove a deleted item from a replication link until after the deletion has been replicated.

If you deselect a namespace from a replication, any further action on that namespace, including deletion of the namespace, is not replicated. This enables a situation in which the owning tenant can end up with more namespaces than are allowed by its namespace quota and/or using more storage than is allowed by its hard quota.

For example, consider the following scenario for a tenant has reached its namespace quota of five:

1.The tenant is selected for replication on an active/passive link, along with all five of its namespaces.

The tenant now has five namespaces on both the primary system and the replica.

2.One of the namespaces is removed from the replication link.

3.On the primary system, the tenant empties and deletes the removed namespace.

The tenant now has four namespaces on the primary system and five namespaces on the replica.

4.On the primary system, the tenant creates a new namespace.

The tenant now has five namespaces on the primary system and five namespaces on the replica, but the namespaces on the two systems are not the same ones.

5.The new namespace is added to the replication link.

The tenant now has five namespaces on the primary system and six namespaces on the replica.

A namespace can contain metadata-only objects on one or more HCP systems in a replication topology. If such a system is involved in only one replication link that includes the tenant that owns the namespace, the following actions can result in the data for those metadata-only objects becoming inaccessible from that system, possibly permanently:

oYou remove the tenant that owns the namespace from the link. In this case, to make the data accessible again:

If the link is active/active, add the tenant back into the link.

If the link is active/passive, either change the link to active/active, or create a new active/active link between the same two systems. Then add the tenant back to the changed link or to the new link, as applicable.

oYou deselect the namespace from replication. In this case, to make the data accessible again, reselect the namespace.

oThe tenant that owns the namespace is included in the first link in a replication chain, the namespace with the metadata-only objects is on the third HCP system in the chain, and you remove the first link from the link to the third system. In this case, to make the data accessible again, take either of these actions:

1.If the first link in the chain is active/passive, change the link to active/active.

2.Either change the link to the third system to active/active, or create a new active/active link between the second and third systems in the chain.

3.Add the tenant back to the changed link to the third system or to the new link, as applicable.

oThe namespace with the metadata-only objects is on the third HCP system in a replication chain, and you remove the tenant that owns the namespace from the first replication link in the chain. In this case, to make the data accessible again:

1.Create a new active/active link between the first and second systems in the replication chain.

2.Add the tenant to the new link.

HCP displays a warning about metadata-only objects when you submit a request to delete an active/passive link or to remove a tenant from an active/passive link while any of the namespaces being replicated on the link contain metadata-only objects.

For more information on metadata-only objects, see Administering HCP.

You can add an HCP tenant to a replication link on one of the systems involved in the link even if the management and data access networks associated with that tenant aren’t defined on the other system involved in the link. However, if these networks are not defined on the other system, the tenant and its namespaces will be inaccessible on that system.

If a network associated with a tenant is undefined in a given system, the tenant list on the Tenants page in the System Management Console for that system shows this alert for the tenant:

For more information on networks, see Administering HCP.

© 2017 Hitachi Vantara Corporation. All rights reserved.