Skip to main content
Hitachi Vantara Knowledge

Replication topologies

An HCP system can have up to five outbound links and up to 20 inbound links. An active/active link counts as both an outbound link and an inbound link. The ability for a single system to participate in multiple links enables HCP to support various replication topologies.

Replication can occur:

  • In two directions on a single link between two HCP systems (active/active replication)
  • In one direction on a single link between two HCP systems (active/passive replication)
  • From multiple HCP systems to a single HCP system (many-to-one replication)
  • From one HCP system to a second HCP system and from that second system to a third HCP system, such that the same HCP tenants and namespaces and default-namespace directories that are replicated to the second system are then replicated to the third system (chained replication)
  • From one HCP system to multiple other HCP systems (one-to-many replication)

These configurations can be combined to form complex replication topologies.

NoteA replication topology can include one or more HCP systems where the occurrences of a given namespace can contain metadata-only objects. If the service plan associated with the namespace does not include a metadata-only storage tier on only one system in the topology and the topology is being used for production purposes, the topology should include a disaster recovery system where the service plan associated with the namespace also does not include a metadata-only storage tier.

Simple active/active replication

In an simple active/active replication topology, two HCP systems replicate the same HCP tenants and namespaces and default-namespace directories to each other over an active/active link. The items being replicated can be created originally on either system. The items are read-write on the system in which they were created and, after being replicated, are also read-write on the other system.

With active/active replication, client requests can be directed to either system. All changes made on each system, including both configuration changes and changes to namespace content, are replicated to the other system.

What this looks like

The following figure shows a simple active/active replication topology in which two HCP systems (A and B) are replicating to each other.

Simple active/active replication topology in which two HCP systems (A and B) are repicating to each other

In this figure:

  • Two of three HCP tenants created locally in system A are being replicated between system A and system B. In the first tenant being replicated, two of three namespaces are selected for replication. In the second tenant being replicated, one of two namespaces is selected for replication.
  • Two tenants created locally in system B are being replicated between system A and system B. In the first tenant, two namespaces are selected for replication. In the second tenant, one of three namespaces is selected for replication.
Uses

The active/active replication topology supports a cloud storage model, where any type of client request can be serviced equally by either HCP system involved in the replication link. With this topology, if one system becomes unavailable (for example, either unexpectedly or for scheduled maintenance), the other system can still provide all the required functionality.

With an active/active replication topology, the processing load can be distributed between the two systems. This distribution can be accomplished in two ways:

  • By having some applications direct requests to one system and other applications direct requests to the other system. Typically, the assignment of applications to systems is based on geographic location.

    With this configuration, a single shared DNS can enable requests to be redirected automatically from one system to the other in case one of the systems becomes unavailable.

  • By using a load balancer to divide requests between the two systems. For each client request, the decision as to which system to target can be based on several factors, such as the current load on each system and the geographical distance between the client and each system.

    With this configuration, if one system becomes unavailable, the load balancer simply directs all requests to the other system.

Active/active replication ring

In an active/active replication ring topology, four or more HCP systems are connected by active/active links, where:

  • Each system has exactly two active/active links that connect that system to two other systems in such a way that all the systems are linked in the form of a ring
  • The same HCP tenants and namespaces and default-namespace directories are replicated on each link

With an active/active replication ring topology, changes made on one system travel around the ring in both directions from that system until they reach a system where those changes have already occurred.

Configuring an active/active replication ring

To configure an active/active replication ring topology:

Procedure

  1. Create an active/active link between each pair of systems to be connected in the ring.

  2. For each system that has locally created tenants, namespaces, and directories that you want to replicate, add those items to one of the links connected to that system.

  3. After those tenants, namespaces, and directories have been replicated, add them to the second link that’s connected to the system to which the items have been replicated.

  4. After the items have been replicated to that system, add them to the next link in the ring.

  5. Continue adding the replicated items to successive links until you have added them to the second link that connects to the system where the items were originally created.

Active/active replication ring topology

An active/active replication ring topology that includes four, five, or six HCP systems can be used as the basis for an erasure coding topology. When you add a tenant to the erasure coding topology, if the tenant is not already being replicated in the ring topology, HCP automatically adds that tenant to all the links in the ring topology.

What this looks like

The following figure below shows an active/active replication ring topology that includes four systems (A, B, C, and D).

active/active replication ring topology that includes four systems (A, B, C, and D)

In this figure:

•Two of three HCP tenants created locally in system A are being replicated around the ring. In the first tenant being replicated, two of three namespaces are selected for replication. In the second tenant being replicated, one of two namespaces is selected for replication.

•Two tenants created locally in system D are being replicated around the ring. In the first tenant, two namespaces are selected for replication. In the second tenant, one of three namespaces is selected for replication.

Using active/active replication ring topology

The active/active replication ring topology supports increasingly large storage clouds. The HCP systems included in the ring are typically in geographically disperse locations, with each system providing the same functionality as all the others. Changes made on any one system are propagated to all the other systems, effectively enabling shared read-write access to the same HCP tenants and namespaces and default-namespace directories regardless of where the client applications are located.

New HCP systems can be added to an active/active replication ring topology at any time. To add a new system (for example, system X) to the topology:

Procedure

  1. Create a new active/active link between any system already in the topology (for example, system B) and system X.

  2. Add the tenants, namespaces, and directories already being replicated around the ring to the new link.

  3. Create a new link between system X and one of the other systems with which system B participates in a link (for example, system C).

  4. Add the tenants, namespaces, and directories already being replicated around the ring to that new link.

  5. Delete the link between system B and system C.

Fully connected active/active replication

In a fully connected active/active replication topology, multiple HCP systems are connected by active/active links, where:

  • Each system in the topology is connected to each other system in the topology by an active/active link
  • The same HCP tenants and namespaces and default-namespace directories are replicated on each link

Because each system can participate in at most five active/active links, a fully connected active/active replication topology can have up to six systems.

Configuring a fully connected active/active replication topology

To configure a fully connected active/active replication topology:

Procedure

  1. Create an active/active link between each pair of systems to be included in the topology.

  2. For each system that has locally created tenants, namespaces, and directories you want to replicate, add those items to each of the links connected to that system.

  3. After those tenants, namespaces, and directories have been replicated, add them to each of the other links in the topology.

Fully connected active/active replication topology as erasure coding topology

A fully connected active/active replication topology can be used as the basis for an erasure coding topology. When you add a tenant to the erasure coding topology, if the tenant is not already being replicated on the links in the fully connected active/active topology, HCP automatically adds that tenant to all the links in the fully connected active/active topology.

What this looks like

The following figure shows a fully connected active/active replication topology that includes four systems (A, B, C, and D).

Fully connected active/active replication topology that includes four systems (A, B, C, and D)

In this figure:

  • Two of three HCP tenants created locally in system A are being replicated throughout the topology. In the first tenant being replicated, two of three namespaces are selected for replication. In the second tenant being replicated, one of two namespaces is selected for replication.
  • Two tenants created locally in system D are being replicated throughout the topology. In the first tenant, two namespaces are selected for replication. In the second tenant, one of three namespaces is selected for replication.
Uses

The fully connected active/active replication topology is an alternative to the active/active ring topology for maintaining the same namespaces on multiple HCP systems in a storage cloud.

A fully connected topology provides better protection from system unavailability and nonfunctioning replication links than a ring topology provides. The network of links in a fully connected topology ensures that each system has multiple paths to each other system, thereby preventing individual systems from becoming isolated from the rest.

For example, suppose that the following conditions are true:

  • Namespace NS1 is being replicated in a replication topology that includes systems A, B, C, and D
  • The service plan associated with NS1 includes a metadata-only storage tier on A and B
  • Object O1 is metadata-only on both A and B

With a ring topology, if the replication links between B and C and between C and D are broken, system C is isolated. Because no path connects system D to system C, system D cannot retrieve data for O1 from the only other system that has the data (for example, in a situation in which read from remote is required).

If the replication links between B and C and between C and D are broken, system C is isolated

Given the same circumstances with a fully connected topology, system D can still read data for O1 from system C by using the links between D and A and between A and C.

System D can still read data from system C by using the links between D and A and between A and C

A fully connected topology requires more maintenance than a ring topology. In the worst case, with six systems in a fully connected topology, you must maintain 15 replication links. With six systems in a ring topology, you need to maintain only six links.

Additionally, the more systems you have in a fully connected topology, the less the ability to replicate other tenants to systems outside the topology. For example, in a five-system fully connected topology, any system could have one additional link on which to replicate tenants that are not in the topology to a system outside the topology. In a six-system fully connected topology, the systems cannot have any additional links.

A typical use for a fully connected active/active replication topology is as the basis for an erasure coding topology.

Responses to read requests for erasure-coded objects are faster with a fully connected topology than with a ring topology because all chunks not on the target system can be retrieved from directly connected systems. In comparison, with an erasure coding topology based on a ring replication topology, responses to read requests are slower because some chunks can be retrieved only through paths consisting of more than one replication link. Also, the use of the additional links increases network bandwidth usage.

Simple active/passive replication

In a simple active/passive replication topology, one HCP system, the primary system, replicates HCP tenants and namespaces and default-namespace directories to another HCP system, the replica, over an active/passive link. The items being replicated are originally created only in the primary system. The items are read-write on the primary system and, after being replicated, read-only on the replica.

What this looks like

The figure below shows a simple active/passive replication topology in which one HCP system (A) is replicating to a second HCP system (B).

Simple active/passive topology in which system A replicates to system B

In this figure:

  • From system A, two of three locally created tenants are being replicated to system B. In the first tenant being replicated, two of three namespaces are selected for replication. In the second tenant being replicated, one of two namespaces is selected for replication.
  • In system B, no locally created tenants are being replicated.
Uses

The main purpose of a simple active/passive replication topology is to have a backup of the primary system for use in disaster recovery. However, this topology also supports a scenario in which some applications need read-write access to the replicated items while other applications need only read access. By directing requests from the latter to the replica, you can reduce the load on the primary system.

Active/passive many-to-one replication

In an active/passive many-to-one replication topology, multiple HCP systems replicate to a single other HCP system. Each of the replicating systems is the primary system for an active/passive replication link. The other system is the replica for each of those links.

In this topology, the replica is like a hub, with the primary systems being at the ends of spokes connected to that hub. The spokes themselves are the replication links. The hub can have up to five spokes.

Each HCP tenant and default-namespace directory selected for replication on a primary system must be unique on the replica. For example, if two of the primary systems each have a tenant named Finance, the Finance tenant can be replicated from only one of the systems. For both tenants to be replicated, they must have different names.

Similarly, before you can have an email directory in the default namespace on multiple primary systems replicated, the SMTP protocol on each system must specify a different email directory name.

NoteYou can also create a many-to-one replication topology that consists of a combination of active/passive and active/active links or even active/active links only.
What this looks like

The figure below shows an active/passive many-to-one replication topology in which three primary systems (A, B, and C) are replicating to a single replica (D).

An active/passive many-to-one replication topology in which three primary systems (A, B, and C) are replicating to a single replica (D).

In this figure:

  • From system A, two HCP tenants are being replicated to system D. In the first tenant, two of three namespaces are selected for replication. In the second tenant, one of two namespaces is selected for replication.
  • From system B, two of three HCP tenants are being replicated to system D. In the first tenant being replicated, two of three namespaces are selected for replication. In the second tenant being replicated, one of two namespaces is selected for replication.
  • From system C, one of two HCP tenants is being replicated to system D. In that tenant, both namespaces are selected for replication.
  • System D has one HCP tenant of its own that is not the result of replication. This tenant has two namespaces.
Uses

In an active/passive many-to-one replication topology, the replica is typically the largest HCP system. The data center in which it resides is usually fully staffed with IT personnel. The primary systems typically are smaller. Because replication links can be created and managed from either side, the data centers where these systems reside can be minimally staffed with less experienced people.

Active/passive many-to-one replication supports a scenario in which the outlying sites are branch offices of an enterprise that has an HCP system at a primary data center. Applications running at each of those offices connect over a local area network (LAN) to an HCP system at the local data center. Because they are close to the storage they use, the applications perform better than they would if they were using a wide area network (WAN) to connect to the HCP system at the hub. Also, the distribution of the network load among the outlying sites further enhances application performance.

With active/passive many-to-one replication, you can consolidate similar data from multiple sources in a single HCP system. Using a search application, you can then perform federated queries across the replicated namespaces on that system. For example, suppose each of the branch offices of an enterprise stores completed orders in a namespace in its own HCP system. If each of those namespaces is replicated to a single HCP system, you could query that system to find all orders placed for a specific product at any of the branch offices.

Active/passive many-to-one replication enables a single HCP system to be used for backup and recovery of multiple other HCP systems, so the outlying sites don’t need backup systems of their own. For additional data protection, the hub system can be backed up, for example, to tape or to another HCP system .

Active/passive chained replication

In an active/passive chained replication topology, HCP tenants and namespaces and default-namespace directories in one HCP system (A) are replicated to a second HCP system (B) and then from the second system to a third HCP system (C). Both the replication link from A to B and the replication link from B to C are active/passive links.

Configuring an active/passive chained replication

To configure an active/passive chained replication topology:

Procedure

  1. When you create the replication link from A to B, select the tenants, namespaces, and directories you want to replicate. In this link, A is the primary system and B is the replica.

  2. When you create the replication link from B to C, select the link from A to B to be included in that link. This causes the HCP tenants, namespaces, and directories replicated on the link from A to B to be replicated again from B to C.

    In this link, B is the primary system and C is the replica.The link from B to C can also include tenants, namespaces, and directories that were originally created on B.You cannot individually select the replicated tenants, namespaces, and directories on B for inclusion in the link from B to C.In an active/passive chained replication topology with the configuration A B C, B is the replica for the link from A to B. Therefore, in B, the tenants and directories that were replicated from A are read-only, even though B is also the primary system for the link from B to C.HCP supports replication chains that consist of three HCP systems. Longer chains are not supported.
    Note
    • You can also create a chained replication topology in which the first link is active/active and the second link is active/passive. You cannot, however, create a chained replication topology in which the first link is active/passive and the second link is active/active or in which both links are active/active.
    • In a replication chain A B C, in which the objects in a namespace on system B are supposed to be metadata-only, HCP does not remove data from those objects until that data has been replicated to system C.

Active/passive chained replication topology details

What this looks like

The following figure shows an active/passive chained replication topology in which system A is replicating to system B and system B is replicating to system C.

Active/passive chained replication topology: system A replicates to system B; system B replicates to system C

In this figure:

  • From system A, two HCP tenants are being replicated to system B. In the first tenant, two of three namespaces are selected for replication. In the second tenant, one of two namespaces is selected for replication.
  • From system B, the tenants and namespaces created by replication from system A are being replicated to system C because the link from A to B is included in the link from B to C.
  • One tenant that was originally created on system B is also being replicated to system C. Both the namespaces in that tenant are selected for replication.
Uses

In an active/passive chained replication topology, all three HCP systems typically are located at full-scale data centers. For example, suppose a corporation has three major locations: New York, Los Angeles, and Tokyo. Each of these locations runs an application that is vital to the corporation, but only New York generates the data for these applications. Replicating the data from New York to Los Angeles and from Los Angeles to Tokyo enables applications at each location to access the data through a local area network. Because those applications are not accessing the data on the HCP system in New York, this topology also reduces the load on that system.

Active/passive chained replication helps ensure continuous data availability. If any one or even two of the HCP systems in the chain become unavailable, applications still have access to the stored data.

In an active/passive replication chain, the third HCP system provides disaster recovery functionality for the second system, and the second system provides disaster recovery functionality for the first system.

With an active/passive chained replication topology, you can create and manage both replication links from the HCP system in the middle of the chain. To this system, the link from the first system is an inbound link, and the link to the third system is an outbound link.

Active/passive one-to-many replication

In an active/passive one-to-many replication topology, one HCP system replicates to two or more other HCP systems using separate active/passive replication links. The replicating system is the primary system for each link. The other systems are replicas.

Typically, in an active/passive one-to-many replication topology, the replication links include different HCP tenants and namespaces and default-namespace directories.

If three systems need to have the same tenants, namespaces, and directories as each other, consider using a chained topology for them rather than a one-to-many topology. The one-to-many topology puts greater load on the single primary system than does a chained topology, which splits the load between the first and second systems in the chain.

In some cases, however, replicating the same tenants and namespaces to two different replicas in a one-to-many topology may be appropriate.

NoteYou can also create a one-to-many replication topology that consists of a combination of active/passive and active/active links or even only active/active links.
What this looks like

The figure below shows an active/passive one-to-many replication topology in which one primary system (A) replicates to two replicas (B and C) over two separate replication links.

Active/passive one-to-many replication topology in which one primary system (A) replicates to two replicas (B and C) over two separate replication links

In this figure:

  • Two of three HCP tenants in system A are being replicated to system B. In the first tenant being replicated, two of three namespaces are selected for replication. In the second tenant being replicated, one of two namespaces is selected for replication.
  • The third HCP tenant in system A is being replicated to system C. This tenant has two namespaces, both of which are selected for replication.

Using active/passive one-to-many replication topology to upgrade HCP systems from RAIN to SAIN

An active/passive one-to-many replication topology lets you replicate different tenants and default-namespace directories from a single primary system to multiple different replicas. You might do this, for example, if the replicas are at sites where users need read access to only a limited number of namespaces. Those sites can then have HCP systems that use smaller amounts of storage.

You can also use an active/passive one-to-many replication topology to upgrade your HCP systems from RAIN to SAIN. This scenario assumes you currently have a RAIN primary system replicating to a RAIN replica on an active/passive link. A SAIN primary system must replicate to a SAIN replica. To make this happen:

Procedure

  1. Create a second active/passive link from the RAIN primary system to the SAIN system that will be the primary system after the upgrade.

    Use this link to replicate all the HCP tenants, HCP namespaces, and default-namespace directories in the RAIN system.
  2. Create a replication link from the new SAIN primary system to the second SAIN system.

    Include the link created in Step 1 above in this link to create a replication chain.
  3. When replication is completely up to date, fail over the link from the RAIN system to the SAIN system.

    To enable replication to become completely up to date, you may need to stop clients from writing to the RAIN system before you fail over the link.
  4. Delete the link from the RAIN system to the SAIN system.

  5. Decommission the two RAIN systems.

Active/active replication with disaster recovery support

You can combine active/active replication with active/passive replication to create a topology in which a third system provides disaster recovery support for the two systems that participate in an active/active link. In this topology, a set of HCP tenants and namespaces and default-namespace directories is replicated on an active/active link between two systems (A and B). Some of those items are also replicated on an active/passive link from A to a third system (C). The rest of the items are also replicated on an active/passive link from system B to system C.

The choice of which items to replicate on each active/passive link is independent of which system the items were initially created on. For example, an HCP tenant created locally on system A could be included on the active/passive link from B to C.

The following figure shows a simple active/active replication topology with disaster recovery support.

Simple active/active replication topology with disaster recovery support

In this figure:

  • Two of three HCP tenants created locally in system A are replicated between system A and system B. In the first tenant being replicated, two of three namespaces are selected for replication. In the second tenant being replicated, one of two namespaces is selected for replication.
  • Two HCP tenants created locally in system B are replicated between system A and system B. In the first tenant, two namespaces are selected for replication. In the second tenant, one of three namespaces is selected for replication.
  • From system A, one HCP tenant initially created on system A and one HCP tenant initially created on system B are replicated to system C.
  • From system B, one HCP tenant initially created on system A and one HCP tenant initially created on system B are replicated to system C.

Many-to-one replication with disaster recovery support

You can combine the many-to-one and chained replication topologies to create a configuration in which multiple HCP systems replicate to a single HCP system (many-to-one), which, in turn, replicates to another HCP system (chained). The last system provides additional assurance of continuous data availability for all the HCP tenants and namespaces and default-namespace directories originally selected for replication. It also provides disaster recovery functionality for the HCP system to which those tenants, namespaces, and directories are initially replicated.

Creating many-to-one replication with disaster recovery support

In this example, HCP systems A, B, and C replicate to system D, which replicates to system E. To create this combined topology:

Procedure

  1. When you create the replication links from A to D, from B to D, and from C to D, select the tenants, namespaces, and directories you want to replicate.

  2. When you create the replication link from D to E, select the links from A to D, from B to D, and from C to D to be included in that link.

    This causes the tenants, namespaces, and directories replicated on all three of those links to be replicated again from D to E. In effect, you’re creating three replication chains: A → D → E, B → D → E, and C → D → E. The following below shows a many-to-one replication topology with disaster recovery support. Many-to-one replication topology with disaster recovery support

Bidirectional active/passive replication

For any given pair of HCP systems, each system can serve as both a primary system and a replica for the other system, as long as different HCP tenants and different default-namespace directories are being replicated in each direction. A system that serves as both a primary system and a replica at the same time has two active/passive links: one outbound and one inbound. This topology is called bidirectional active/passive replication.

What this looks like

The following figure shows a bidirectional active/passive replication topology in which two systems (A and B) are each replicating to the other system.

Bidirectional active/passive replication topology

In this figure:

  • From system A, two locally created tenants are being replicated to system B. In both tenants, all namespaces are selected for replication.
  • From system B, one locally created tenant is being replicated to system A. In this tenant, all namespaces are selected for replication.
Uses

For each link in a bidirectional active/passive replication topology, the tenants, namespaces, and directories being replicated are read-write on the primary system and read-only on the replica. Therefore, a bidirectional active/passive replication topology supports a scenario like this:

  • Application 1 running in a data center in New York needs read-write access to Tenant-1, which was created locally in the HCP system (A) in New York.
  • Application 2 running in a data center in Tokyo needs read-write access to Tenant-2, which was created locally in the HCP system (B) in Tokyo.
  • Application 1 needs only read access to Tenant-2.
  • Application 2 needs only read access to Tenant-1

To meet these needs, you could:

  • Create an active/passive link from system A to system B that includes Tenant-1. System A sends Tenant-1 to system B, where the tenant is in read-only mode. Application 2 can access the tenant more efficiently on system B than on system A.
  • Create an active/passive link from system B to system A that includes Tenant-2. System B sends Tenant-2 to system A, where the tenant is in read-only mode. Application 1 can access the tenant more efficiently on system A than on system B.

Bidirectional active/passive chained replication

In a bidirectional active/passive chained replication topology, three HCP systems participate in two active/passive replication chains, with each chain going in a different direction. That is, given three HCP systems A, B, and C:

  • In one chain, system A replicates to system B, which replicates to system C.
  • In the other chain, system C replicates to system B, which replicates to system A.
What this looks like

The following figure shows a bidirectional active/passive chained replication topology in which the replication chains are A → B → C and C → B → A.

Bidirectional active/passive chained replication topology

In this figure:

  • From system A, Tenant-1 and Tenant-2 are being replicated to system B. In both tenants, all namespaces are selected for replication.
  • From system C, Tenant-3 is being replicated to system B. This tenant has three namespaces, all of which are selected for replication.
  • From system B:
    • The tenants and namespaces created by replication from system A (that is, Tenant-1 and Tenant-2 and their namespaces) are being replicated to system C because the link from A to B is included in the link from B to C.
    • The tenant and namespaces created by replication from system C (that is, Tenant-3 and its namespaces) are being replicated to system A because the link from C to B in included in the link from B to A.
Uses

A bidirectional active/passive chained replication topology lets clients write to selected HCP tenants, namespaces, and default-namespace directories on three different systems while reading from all those tenants, namespaces, and directories on all those systems. In this example, data centers are in New York, Los Angeles, and Tokyo, and:

  • The HCP system in New York has a locally created HCP tenant named Tenant-1
  • The HCP system in Los Angeles has a locally created HCP tenant named Tenant-2
  • The HCP system in Tokyo has a locally created HCP tenant named Tenant-3
  • At each data center, a locally running application needs write access to the namespaces owned by the locally created tenant
  • Clients at all three locations need read access to the namespaces owned by all three HCP tenants

To meet these needs, you could:

  • Create an active/passive link (Link-1) from the New York system to the Los Angeles system that includes Tenant-1, which is writable in New York. The New York system sends Tenant-1 to the Los Angeles system, where the tenant is in read-only mode.
  • Create an active/passive link (Link-2) from the Los Angeles system to the Tokyo system that includes Link-1 and Tenant-2, which is writable in Los Angeles. The Los Angeles system sends both Tenant-1 and Tenant-2 to the Tokyo system, where the tenants are in read-only mode.
  • Create an active/passive (Link-3) from the Tokyo system to the Los Angeles system that includes Tenant-3, which is writable in Tokyo. The Tokyo system sends Tenant-3 to the Los Angeles system, where the tenant is in read-only mode.
  • Create an active/passive link (Link-4) from the Los Angeles system to the New York system that includes Link-3 and Tenant-2. The Los Angeles system sends both Tenant-3 and Tenant-2 to the New York system, where the tenants are in read-only mode.

Bidirectional active/passive replication with disaster recovery support

You can combine the bidirectional and one-to-many replication topologies to create a configuration in which each of two systems replicates its locally created HCP tenants and namespaces and default-namespace directories to both the other system and a third system. This third system then provides each of the first two systems with both additional assurance of continuous data availability and disaster recovery functionality.

For example, HCP systems A and B each replicate their locally created HCP tenants and namespaces and default-namespace directories to each other, and a third system, C, provides disaster recovery functionality for each of those systems. To create this combined topology:

  • Create a link from A to B that includes all the HCP tenants and namespaces and default-namespace directories that were originally created on system A.
  • Create a link from A to C that includes the same tenants, namespaces, and directories as the link from A to B.
  • Create a link from B to A that includes all the HCP tenants and namespaces and default-namespace directories that were originally created on system B.
  • Create a link from B to C that includes the same tenants, namespaces, and directories as the link from B to A.

The following figure shows a bidirectional replication topology with disaster recovery support.

Bidirectional replication topology with disaster recovery support

You can combine the bidirectional and chained replication topologies to have the same result as the topology described above, which involves the bidirectional and one-to-many topologies. That is, the replicated items in the link from A to B also end up on C, and the replicated items in the link from B to A also end up on C.

In this case, however, instead of the link from A to C replicating the same items as the link from A to B, the link from A to C would include the link from B to A. Likewise, instead of the link from B to C replicating the same items as the link from B to A, the link from B to C would include the link from A to B.

The following figure shows this topology.

bidirectional replication topology with disaster recovery support

This topology provides better performance than does the first topology described above. Additionally, if you need to add a tenant to the link from A to B, for example, you don’t need to also add it to the link from A to C. Instead, the tenant is automatically replicated to C because the link from A to B is included in the link from B to C.

On the other hand, the first topology described above is better for assuring continuous data availability in case system A or B fails. For example, if system A is replicating to systems B and C and system B fails, the items being replicated from system A are still making it to system C. In the second topology, if system B fails, the items from system A are not replicated to system C because the replication chain is broken.

 

  • Was this article helpful?