Skip to main content
Hitachi Vantara Knowledge

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:
    • HCP tenants
    • HCP namespaces
    • Directories defined in the default namespace
    • For active/passive links only, chained links
  • You can add a tenant to a replication link only if the tenant is configured to allow replication.
  • You cannot add a tenant to a replication link between two systems if another link between the same two systems already includes that tenant.
  • You can choose which namespaces to replicate for any given HCP tenant only if the 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.
  • To select and deselect HCP namespaces for replication, you can use any 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.
  • When you add an HCP tenant to an erasure coding topology, the tenant is automatically added to every link in that topology.
  • When you add an HCP tenant to a replication link without adding the tenant to an erasure coding topology, all replication-enabled namespaces owned by the tenant use whole-object protection regardless of whether they are configured to allow erasure coding.
  • You cannot add an HCP tenant to a replication link while that tenant is included in an active, retiring , or retired erasure coding topology that includes one or both of the systems involved in the link but not the link itself.
  • You cannot remove an HCP tenant from a replication link that's part of an active erasure coding topology.
  • You cannot remove an HCP tenant from a replication link if that tenant was previously removed from the active erasure coding topology and any of the tenant's namespaces still contain chunks for erasure-coded objects.
  • You cannot remove an HCP tenant from a replication link that's part of a retiring erasure coding topology if any of the tenant's namespaces still contain chunks for erasure-coded objects.
  • 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.
  • After removing an HCP tenant or default-namespace directory from an active/active replication link, you can add the tenant or directory back to that link. While the tenant or directory is not on the link, operations on that tenant or directory, on replicated namespaces owned by that tenant, or on objects in those replicated namespaces or in that directory can occur on both systems involved in the link.

    Similarly, after deselecting a namespace for replication, you can select it again. If the tenant that owns the namespace is on an active/active link, while the namespace is deselected, operations on objects in the namespace can occur on both systems involved in the link.

    These considerations apply:

    • When you add a replicated tenant back to a link:
      • If you deleted the tenant on either system involved in the link while the tenant was not on the link, the tenant is replicated back to that system
      • If you deleted any of the tenant's replicated namespaces on either system involved in the link while the tenant was not on the link but you did not delete the tenant, those namespaces are replicated back to that system
      • If you deleted any objects in any of the tenant's replicated namespaces on either system involved in the link while the tenant was not on the link but you did not delete the tenant or those namespaces, those objects are deleted on the other system
    • When you add a replicated directory back to a link:
      • If you deleted the directory on either system involved in the link while the directory was not on the link, the delete operation is replicated to the other system
      • If you deleted any objects in the directory on either system involved in the link while the directory was not on the link but you did not delete the directory, those objects are deleted on the other system.
    • When you add a replicated tenant or directory back to a link or reselect a replicated namespace for replication, all operations that occurred in that tenant, directory, or namespace on either system while replication was not happening are replicated to the other system (except for the deletion of the tenant or namespace). During this replication, conflicts can occur between changes made on different systems while the tenant, directory, or namespace was not being replicated.
  • After removing an HCP tenant or default-namespace directory from an active/passive link, you cannot add the tenant or directory back to that link unless you first delete the tenant or directory from the replica. This is because the tenant or directory now already exists on the replica.
  • When you add one or more default-namespace directories to a link, some objects in directories that were already on 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 on 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 the 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 on 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 on 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 A B C, 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.
  • In a replication chain with the configuration A B C, 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 A B C, 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 A B C, 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:
    • The 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.
    • The 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.
  • 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 on the link. In those lists, rows containing items that have been deleted from HCP are highlighted in red and have a trash can icon (GUID-726558FA-C2E6-49FB-A03A-C2FA06AE7140-low.png) 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.

    ImportantDo not remove a deleted item from a replication link until after the deletion has been replicated.
  • If you deselect a namespace from 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:
    • You 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.
    • You deselect the namespace from replication. In this case, to make the data accessible again, reselect the namespace.
    • The tenant that owns the namespace is included on 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:
      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.
    • The 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.

  • 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: GUID-04476258-04A1-48CA-8961-C541AD9AE721-low.png

 

  • Was this article helpful?