Skip to main content
Outside service Partner
Hitachi Vantara Knowledge

Working with erasure coding topologies


An erasure coding topology provides all the information the replication service and geo-distributed erasure coding service need to implement erasure-coded protection. You can create and manage an erasure coding topology in the HCP System Management Console from any of the HCP systems included in the topology.

To create an erasure coding topology, you select the HCP systems and replication links to include in the topology. You also set the topology properties. After you create the topology, you add HCP tenants to it. If the tenants you add are not already on the replication links in the erasure coding topology, they are automatically added to those links.

You can modify the properties of an erasure coding topology at any time. You can also replace the systems in a topology, but you cannot replace the links.

You can retire and delete erasure coding topologies. However, these actions should be taken only with a full understanding of the consequences.

This section of the Help contains considerations and instructions for performing the activities mentioned above.

RoleWebHelp.png

Roles: To view an erasure coding topology, you need the monitor or administrator role. To create, specify tenants for, modify, retire, or delete an erasure coding topology, you need the administrator role.

NoteWebHelp.png

Note: You can also use the HCP management API to create, specify tenants for, modify, retire, and delete erasure coding topologies. For information on doing this, see Erasure coding topology resources.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

About erasure coding topologies


An erasure coding topology consists of a set of HCP systems and active/active replication links that connect those systems. Within an erasure coding topology, each system must have at least two paths to each other system. Each path can consist of any number of systems and links, but the paths cannot have any systems or links in common.

When you create an erasure coding topology, you select the systems to include in it. The systems you select must be part of an existing active/active replication ring topology or fully connected active/active replication topology. For descriptions of these replication topologies, see Active/active replication ring and Fully connected active/active replication.

For each pair of selected systems that are connected to each other in the underlying replication topology, if the pair has only one active/active replication link between them, that link is automatically included in the erasure coding topology. If any pair of the selected systems is connected by more than one active/active link, you select which one of those links to include in the erasure coding topology.

An erasure coding topology does not automatically include the tenants on the links in the underlying replication topology. Instead, you select the tenants to include in an erasure coding topology from all the replication-enabled tenants defined on the systems in the topology. Each tenant you select is automatically added to each link in the erasure coding topology.

When you create an erasure coding topology, it's in the active state. If you want to stop using the active topology for erasure-coded protection, you need to retire the topology.

Retiring an erasure coding topology causes the geo-distributed erasure coding service to restore object chunks to full-copies or, on systems where the objects are on metadata-only storage tiers, delete the chunks. While the chunks are being restored or deleted, the topology is in the retiring state.

When all the systems in a retiring erasure coding topology have no more chunks that are the result of that topology, the state of the topology changes to retired. Once a topology is retired, you can delete it. Deleting an erasure coding topology does not cause any systems, links, tenants, namespaces, or objects to be deleted.

A system can be in at most five erasure coding topologies concurrently. Only one of those topologies can be active. The rest must be either retiring or retired.

For more information on retiring erasure coding topologies, see Erasure coding topology retirement.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Erasure coding topology properties


An erasure coding topology has these properties:

A name and, optionally, a description.

The number of HCP systems in the erasure coding topology. A topology can have from three through six systems.

For an erasure coding topology with four or more systems, the type of the underlying replication topology — ring or fully connected. The topology type for three systems is always fully connected.

For descriptions of these topology types, see Active/active replication ring and Fully connected active/active replication.

A distribution method — chunk or full copy. For information on distribution methods, see Distribution methods for erasure-coded protection.

A minimum size for erasure coding objects and object parts — 4 KB, 16 KB, 32 KB, 64 KB, 128 KB, 256 KB, 512 KB, or 1 MB. HCP erasure-codes only objects and object parts with a size greater than or equal to the minimum size you select. HCP uses whole-object protection for objects and parts below the minimum size, regardless of whether the containing namespace is using erasure-coded protection.

NoteWebHelp.png

Note: The service plan associated with a namespace can include a metadata-only storage tier on all the systems in an erasure coding topology. With this configuration, objects and parts in the namespace that are smaller than the minimum size for erasure coding may have data on only one of those systems. As a result, those objects and parts are not protected against a single system failure.

An erasure coding delay. This is the amount of time the geo-distributed erasure coding service waits before reducing a full copy of the data for an object or object part to a chunk. With full-copy distribution, this is also the amount of time the service waits on systems where the object or part is metadata-only before requesting a chunk for the object.

For more information on erasure coding delays, see Erasure coding delay.

Optionally, a restore period. If an erasure coding topology has a restore period, after an object or object part that's subject to erasure coding is read from a system in the topology, a full copy of the object or part data is kept on that system at least until the restore period expires.

For more information on restore periods, see Restore period.

When setting the minimum size, erasure coding delay, and restore period, consider the tradeoffs with respect to storage efficiency and read performance. For information on these tradeoffs, see Choosing a protection type.

Erasure coding delay

The erasure coding delay is counted from the time the ingest system receives the object or part data. You specify the delay as a number of days.

Even if the erasure coding delay has expired for an object, the geo-distributed erasure coding service does not reduce a full copy of the data for the object or part to a chunk if doing so would leave the object or part insufficiently protected. For information on keeping objects sufficiently protected, see Geo-distributed erasure coding service processing.

Restore period

You specify the restore period for an erasure coding topology as a number of days. If the specified number is zero, the topology does not have a restore period.

When an object or part that's subject to erasure coding is read from a given system, where that system is in an erasure coding topology with a restore period:

If the system currently has a full copy of the object or part data, the restore period applies to that full copy.

If the system currently has a chunk for the object or part on primary running storage, on an S Series Node, or on spindown storage and the chunk has never been tiered to extended storage, a full copy of the object or part data is restored on the current tier, and the chunk is deleted. The restore period applies to the restored full copy.

While the system has only a full copy of the object or part data, the object or part is not counted as an erasure-coded object on that system.

If the system currently has a chunk for the object or part and the chunk is or ever was on an extended storage tier, a full copy of the object or part data is restored on the highest storage tier that could have had a full copy of the data, and the chunk is deleted. The restore period applies to the restored full copy.

NoteWebHelp.png

Note:  For objects and parts that are subject to erasure coding, the storage tiers that can have a full copy of the object or part data are primary running storage, HCP S Series Nodes, and primary spindown storage. HCP never tiers a full copy of the object or part data to extended storage. Instead, when the geo-distributed erasure coding service on a system reduces a full copy of object or part data to a chunk, if the object or part is due to be tiered, that service puts the chunk on the applicable storage tier.

For more information on storage tiering, see Storage administration.

The restore period for an object or part starts when the object or part is read. If the object or part is read again during the restore period, the restore period restarts from the time of that read operation.

The restore period for an object or part can restart only once on any given day. After the first restart on a day, subsequent reads on the same day do not cause the restore period to restart.

The restore period for an object or part can start before the erasure coding delay has expired. If the erasure coding delay then expires before the restore period expires, the full copy of the object or part data is not reduced to a chunk until the restore period expires. If the restore period expires before the erasure coding delay expires, the full copy of the object or part data is not reduced to a chunk until the erasure coding delay expires.

NoteWebHelp.png

Note: Internal reads (for example, by an HCP service) do not cause object or part chunks to be restored to full copies of the object or part data and do not start or restart restore periods.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Supported replication topologies


An erasure coding topology can include from three through six HCP systems. An erasure coding topology with four, five, or six systems can be based on either an active/active replication ring topology or a fully connected active/active replication topology. A three-system erasure coding topology is always based on a fully connected active/active replication topology.

Before you can create an erasure coding topology, the underlying replication topology must already exist.

The figures below show all the replication topologies on which an erasure coding topology can be based.

ThreeSystemTopology.png

FourSystemTopologies.png

FiveSystemTopologies.png

SixSystemTopologies.png

For more information on these replication topologies, see Active/active replication ring and Fully connected active/active replication.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Erasure coding topology retirement


When you retire an erasure coding topology, the protection type for any namespaces that were using erasure-coded protection changes to whole-object protection. This change causes the geo-distributed erasure coding service to, for any given object:

Restore the chunk for the object to a full copy of the object data on HCP systems where the object is not supposed to be metadata-only. As the service restores chunks to full copies, the use of storage on those systems increases.

Delete the chunk for the object on HCP systems where the object should be metadata-only. The service does not delete the chunk for an object until a full copy of the object data exists either on at least two systems in the topology or on one system if the object should have data on only one system.

For any given erasure-coded object, if the object should be metadata-only on every system in the topology, the geo-distributed erasure coding service on one system restores the chunk to a full copy. The system where this occurs varies depending on when the service processes the object on each system in the topology.

The number of concurrent system failures HCP can tolerate for a replicated namespace with whole-object protection is one less than the number of systems where the namespace contains object data. Therefore, to maintain at least the same protection level with whole-object protection as the protection level maintained by erasure-coded protection, the underlying replication topology must include at least two systems where the replicated namespaces contain object data.

Before retiring an erasure coding topology, you need to ensure that any system where object chunks will be restored to full copies of the object data has sufficient storage to accommodate that data.

TipWebHelp.png

Tip: To estimate the amount of storage required on a given system:

1.For each tenant included in the retiring erasure coding topology, use the management API to get the value of the erasureCodedSize property of the /tenants/tenant-name/statistics resource. This value is the total amount of storage, in bytes, occupied by chunks for erasure-coded objects in all the tenant's namespaces.

2.Add together the numbers of bytes occupied by chunks for erasure coded objects for all the tenants. The total is the number of bytes occupied by chunks for all erasure-coded objects on the system.

3.Multiply the total number of bytes by the number of data chunks in the topology protection level. The result is an estimate of the required amount of storage, in bytes.

Also before retiring an erasure coding topology, if you don't want chunks for objects in a namespace restored to full copies of the object data on a given system, ensure that, on that system, the namespace is already associated with a service plan that keeps all objects in the namespace on a metadata-only storage tier. That way, chunks are not unnecessarily restored to full copies on systems where the objects should be metadata-only.

As the geo-distributed erasure coding service on a system processes the chunks for a retiring erasure coding topology, the number of erasure-coded objects for that topology on that system decreases. When that number reaches zero on all the systems in the topology, the state of the topology changes to retired.

For any given system in an erasure coding topology, you can use the erasure coding topology details page in the HCP System Management Console to monitor the count of erasure-coded objects for that topology on that system. For information on this page, see Understanding erasure coding topology details.

You can also view counts of erasure-coded objects for all active and retiring erasure coding topologies:

The storage Overview page shows the total number of erasure-coded objects currently stored on the system.

The tenant Overview panel shows the total number of erasure-coded objects in all the tenant's namespaces.

These counts are not specific to an erasure coding topology. If an active erasure coding topology exists, these numbers do not go down to zero when an erasure coding topology has finished retiring.

Chargeback reports also contain erasure-coded object counts for the system, tenants, and, if you have administrative access to a tenant, the namespaces owned by that tenant.

For instructions on retiring an erasure coding topology, see Retiring an erasure coding topology.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Erasure coding topology replacement


You cannot add or remove HCP systems in an erasure coding topology. You also cannot add, remove, or replace replication links in an erasure coding topology. If you want to change a topology in any of these ways, you need to retire the topology and create a new one to replace it.

After you retire an erasure coding topology, you cannot make it active again. If you inadvertently retire a topology, you can replace it with a new topology that includes the same systems and links.

To replace a system in an active erasure coding topology, you don't need to create a new topology. Instead, you use the procedure for replacing a failed system outlined in System failure workflow with an active/active link. At the end of this procedure, replication restarts with the replacement system, and the replacement system receives full copies of object data or chunks for objects, as determined by the erasure coding topology.

NoteWebHelp.png

Note: To replace a system in an active erasure coding topology with a system that has a different domain name or different IP addresses, you need to reconfigure the replication links that connect other systems in the topology to the system you're replacing. When reconfiguring the links, ensure that they all connect to the same replacement system. If the links connect to different systems, the erasure coding topology will no longer be functional.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Erasure coding topology replacement process


When replacing an erasure coding topology, you don't need to wait for the old topology to finish retiring before you create the new topology. During the replacement process, the geo-distributed erasure coding service on each system in the retiring topology determines what to do with each object affected by that topology based on:

The current state of the object on the system (full copy or chunk).

The state the object should be in with the new topology. (Until you create the new topology, the object is subject to whole-object protection.)

The requirement that the object always be protected against a single system failure.

During the topology replacement process, the geo-distributed erasure coding service on any given system in the retiring topology can take any of these actions on an object:

If the system is part of the new topology:

oReduce a full copy of the object data to the chunk for the new topology

oReplace an existing chunk for the object with the chunk for the new topology

oRestore an existing chunk for the object to a full copy of the object data and, some time later, reduce the full copy to the chunk for the new topology

oRestore an existing chunk for the object to a full copy of the object data and, if the object is smaller than the minimum size for erasure coding with the new topology, leave the full copy as is

oMake no change if the existing full copy of the object data or chunk for the object is the same as it should be with the new topology

If the system is not part of the new topology but should contain data for the object, restore an existing chunk for the object to a full copy of the object data

Regardless of whether the system is part of the new topology:

oDelete the existing chunk or full copy of the object data if the system should not contain data for the object (that is, the object should be metadata-only).

oCompletely delete the object (that is, delete both the data and metadata for the object).

During the topology replacement process, the geo-distributed erasure coding service deletes an object only on detecting that the object has been deleted on another system in the retiring topology. The service can delete the object even if replication is paused on the link over which the service detected the deletion.

For systems that are in both the retiring and new topologies, you cannot predict on which systems the service will try to restore chunks to full copies of object data. Therefore, to facilitate the topology replacement, you should ensure that each system in the topology you're retiring has significantly more free space than the space required for the addition of a full copy of the data for the largest object that was erasure coded.

Systems in the retiring topology that are not also in the new topology must have enough free space to accommodate full copies of the object data for all erasure-coded objects that are not supposed to be metadata-only.

During the topology replacement process, the number of erasure-coded objects for the retiring topology only decreases on each system. However, the total number of erasure-coded objects on each system can increase or decrease unpredictably until the topology replacement is complete.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Considerations for replacing an erasure coding topology


You can replace an erasure coding topology with a topology that includes some but not all of the HCP systems in the old topology. When you add a tenant in the old topology to the new topology, replication of that tenant is automatically paused on each link where:

The link is not in the new topology

One or both of the systems involved in the link are in the new topology

Although replication of the tenant is paused on those links, the tenant, its replicated namespaces, and the objects in those namespaces still exist on systems in the old topology that are not in the new topology.

In this situation, you may want to sever the relationship between the tenant on systems in the new topology and the tenant on systems that are not in the new topology. Severing this relationship lets you:

Delete the tenant either on systems in the new topology or on systems that are not in the new topology but not on both

Delete one or more of the tenant's replicated namespaces either on systems in the new topology or on systems that are not in the new topology but not on both

Delete one or more objects in the tenant's replicated namespaces either on systems in the new topology or on systems that are not in the old topology but not on both

Before you sever the tenant relationship, do not let clients access the tenant or its replicated namespaces on systems where you plan to delete that tenant or those namespaces . Disallowing access prevents situations such as this, where these events occur in the order shown:

1.A client makes a change to an object on a system where the tenant or containing namespace will be deleted.

2.You sever the tenant relationship before the change is replicated to a system where the tenant or namespace will not be deleted.

To sever the tenant relationship:

1.Wait for each system in the old topology to have no objects that are erasure coded according to that topology.

You can see the number of objects that are erasure coded according to a given topology on the details page for that topology in the HCP System Management Console.

2.When the state of the old topology changes to retired, delete that topology.

ImportantWebHelp.png

Important: Do not resume replication of the tenant on the links where replication of the tenant is paused.

3.Remove the tenant from each link between a system in the new topology and a system that's not in the new topology.

After severing a tenant relationship, you can add the tenant back to the links from which you removed that tenant only if the tenant is not in the erasure coding topology (either because you removed the tenant from the topology or because you deleted the tenant from the systems in the topology). For the effects of adding a tenant back to links from which you removed it, see Considerations for specifying link content.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Erasure coding topology replacement procedure


When replacing an erasure coding topology, use this procedure to ensure that the replacement process occurs in the most efficient manner:

1.Disable the geo-distributed erasure coding service on each system in the topology you're replacing. Doing this will prevent the service from restoring chunks for objects to full copies that will later need to be reduced to chunks.

NoteWebHelp.png

Note: Services can be disabled from the system Overview page in the System Management Console. To disable services, you need the service role.

2.Disable the storage tiering service on each system in the topology you're replacing. Doing this will prevent the service from tiering full copies of object data that will later need to be reduced to chunks.

3.If all of the following are true for any given namespace on any given system, ensure that the service plan associated with that namespace keeps all objects in the namespace on a metadata-only storage tier on that system:

oThe system will be included in the new erasure coding topology.

oThe namespace has erasure coding allowed, and the tenant that owns the namespace will be included in the new topology.

oYou want each object in the namespace to use whole-object protection until the erasure coding delay specified by the new topology expires.

oYou want objects in the namespace to be metadata-only on the system while they are subject to whole-object protection.

With whole-object protection, HCP does not store data for objects on metadata-only storage tiers. However, if an object should be on a metadata-only storage tier on all the systems in the topology, one system in the topology will store data for that object.

Keeping objects on a metadata-only storage tier on one or more systems will prevent full copies of object data from being distributed to those systems:

oBetween the retirement of the existing topology and the creation of the new topology

oBefore the expiration of the erasure coding delay for the new topology

NoteWebHelp.png

Note: To keep objects protected during the replacement procedure, ensure that the service plan associated with each applicable namespace does not include a metadata-only storage tier on at least two of the systems in the topology you're replacing. To distribute the storage load, on any given system, configure the applicable service plans such that some include a metadata-only storage tier and some do not.

For information on metadata only storage tiers, seeMetadata-only storage tiers.

4.Retire the existing erasure coding topology. Newly ingested objects are now replicated using whole-object protection. Objects that are already erasure coded remain erasure coded.

For instructions on retiring an erasure coding topology, see Retiring an erasure coding topology.

5.Create any new replication links you need for the new erasure coding topology. Do not add tenants to the new links at this point. The tenants will be added to the links automatically when you add the tenants to the new topology.

For instructions on creating replication links, see Creating a replication link.

6.Create the new erasure coding topology and then add tenants to it. The tenants you add are automatically added to any replication links in the topology that do not already include them.

The tenants you add to the new erasure coding topology may already be included on links not in the topology, where one of the systems involved in the link is in the topology. When this is the case, replication or recovery of those tenants is automatically paused on those links.

For instructions on creating an erasure coding topology, see Creating an erasure coding topology. For instructions on adding tenants to an erasure coding topology, see Specifying the tenants for an erasure coding topology.

7.Reenable the geo-distributed erasure coding service. The service starts processing objects again, as described in Erasure coding topology replacement process.

8.Reenable the storage tiering service. The service starts tiering object chunks that are the result of the new erasure coding topology.

9.When the state of the retiring erasure coding topology changes to retired, delete that topology.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Considerations for creating an erasure coding topology


These considerations apply to creating an erasure coding topology:

Before you can create an erasure coding topology:

oAll the HCP systems to be included in the erasure coding topology must be at release 8.0 or later.

oAll the HCP systems to be included in the erasure coding topology must be available.

oThe underlying replication topology must already exist.

oEach system in the underlying replication topology must be able to recognize each other system in the topology through a path of one or more active/active replication links. However, these links do not need to be the links you include in the erasure coding topology.

All replication links to be included in an erasure coding topology must be active/active.

You can create an erasure coding topology from any HCP system to be included in the topology. You cannot create an erasure coding topology from a system that will not be part of the topology.

You cannot create an erasure coding topology while any HCP systems to be included in the topology are being upgraded.

Each link to be included in an erasure coding topology can include any number of tenants, including none. Those tenants do not need to be included in the erasure coding topology.

The links to be included in an erasure coding topology can include different tenants from each other.

Two systems to be connected by a replication link in a new erasure coding topology can already be connected by a link in a retiring or retired topology.  If this is the case, the new topology must include that link. You cannot use a different link to connect the two systems in the new topology.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Creating an erasure coding topology


To create an erasure coding topology:

1.In the top-level menu of the HCP System Management Console for any system you want to include in the erasure coding topology, select Services Geo-distributed EC.

2.On the EC Topologies page, click on Create Erasure Coding Topology.

The erasure coding topology creation wizard opens.

3.Review the information on the wizard Overview page. Then click on Next.

4.On the wizard Name page:

oIn the Name field, type a name for the erasure coding topology. The name must be from one through 64 characters long and can contain any valid UTF‑8 characters, including white space. Erasure coding topology names are not case sensitive.

Erasure coding topology names must be unique for each HCP system in the topology. That is, you cannot use the name of a retiring or retired topology as the name for a new topology that will include any of the same systems as the retiring or retired topology. You can reuse the name of a deleted topology.

oOptionally, in the Description field, type a description for the erasure coding topology. The description can be up to 1,024 characters long and can contain any valid UTF-8 characters, including white space.

5.Click on Next.

6.On the wizard HCP System Selection page:

oIn the Number of HCP Systems field, select the number of systems to be included in the erasure coding topology.

oIf you selected 4, 5, or 6 for the number of systems, for Topology Type, select Ring or Fully connected.

oIn each numbered field in the HCP Systems section, select an HCP system to be included in the erasure coding topology:

For a ring topology, the order of the systems in the numbered fields must correspond to the arrangement of the systems in the topology diagram displayed on the page, with your choice of system as number one.

For a fully connected topology, the systems can be in any order in the numbered fields.

If you don't see all the systems you want to include in the erasure coding topology, check that all required links exist and are healthy.

In the process of creating the erasure coding topology, HCP may change which system is associated with each number. However, this change in no way affects the topology itself.

7.Click on Next.

8.On the wizard Link Selection page, for each pair of HCP systems connected by more than one replication link, select the link you want to include in the erasure coding topology.

For each pair of systems connected by a single link, that link is automatically included in the erasure coding topology. These pairs on not listed on the Link Selection page.

9.Click on Next.

10.On the wizard Settings page:

oFor Distribution Method, select Chunk distribution or Full-copy distribution.

For information on distribution methods, see Distribution methods for erasure-coded protection.

oIn the Minimum Object or Object Part Size for Erasure Coding field, select the minimum size for objects and parts of multipart objects to be erasure coded. The options are 4 KB, 16 KB, 32 KB, 64 KB, 128 KB, 256 KB, 512 KB, and 1 MB.

oIn the Erasure Coding Delay field, type the number of days after ingest that full copies of object or part data should be reduced to chunks. Valid values are integers in the range zero through 3,650.

oIn the Restore Period field, type the number of days that full copies of object or part data should remain on the ingest after being restored from chunks due to a read operation. Valid values are integers in the range zero (no restore period) through 180.

11.Click on Next.

12.On the wizard Review page, review the erasure coding topology configuration.

If the erasure coding topology configuration is what you want, click on Finish.

If the erasure coding topology configuration is not what you want, use the Previous button in the wizard to return to pages on which you want to make corrections. Alternatively, press Cancel to leave the wizard without creating the erasure coding topology .

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Considerations for specifying the tenants for an erasure coding topology


These considerations apply to specifying the content for an erasure coding topology:

When you add a tenant to an erasure coding topology, that tenant is automatically included on all the replication links in the underlying replication topology. Therefore, all the considerations that apply to adding a tenant to a replication link apply to adding a tenant to an erasure coding topology. For these considerations, see Considerations for specifying link content.

An erasure coding topology can include at most one thousand tenants.

You cannot add default-namespace directories to an erasure coding topology.

You cannot add or remove tenants from a retiring or retired erasure coding topology.

You can use the System Management Console for any system in an erasure coding topology to add tenants to that topology.

You choose tenants to add to an erasure coding topology from a list of tenant candidates. This list includes only tenants for which all of these are true:

oReplication is enabled for the tenant.

oThe tenant exists on at least one system in the topology.

oFor at least one such system, either:

The tenant is not on any links in which that system participates.

The tenant is on one or more links in which that system participates, and each of those links is in an active, retiring, or retired topology.

If, for every such system, the tenant is on one or more links that are not in an active, retiring, or retired topology, the tenant is not included in the candidate list. In this case, to have HCP include the tenant in the candidate list, for at least one of the systems, remove the tenant from all links not in an active, retiring, or retired topology.

You cannot add a listed tenant candidate to an erasure coding topology if either of these is true:

oA different tenant with the same name exists on one or more other systems in the topology.

To add a tenant with a name conflict to the topology, you first need to either rename that tenant or rename the other tenants that have the same name.

oThe tenant is on a link that's not in the topology, and both of these are true:

One or both of the systems involved in the link are in the topology.

The link is not in an active, retiring, or retired topology.

To add a tenant with a link conflict to the topology, you first need to remove the tenant from all the links that satisfy the above criteria for at least one system in the topology.

In the tenant candidate list, tenants with a name conflict or link conflict are accompanied by an icon (TenantEcEligWarning.png) indicating that an issue exists. The hover text for the icon identifies the issue.

When you add a tenant to an erasure coding topology, namespaces owned by the tenant use erasure-coded protection only if they are configured to allow erasure coding. Namespaces that are not configured this way use whole-object protection.

If you have administrative access to a tenant:

oYou can use the System Management Console to select namespaces for replication by starting from a replication link that includes the owning tenant

oYou can use the Tenant Management Console to select namespaces for replication and, at the same time, configure them to be cloud optimized and to allow erasure coding

When you add tenants to an erasure coding topology, the process of including those tenants on the all the replication links in the topology can take up to five minutes.

When you add a tenant to an erasure coding topology, replication of that tenant is automatically paused on all links for which all of these are true:

oThe tenant is on the link.

oThe link is not in the topology.

oOne or both of the systems involved in the link are in the topology.

When you remove a tenant from an erasure coding topology, the tenant remains on all the links in the underlying replication topology, but the tenant's namespaces that allow erasure coding change from using erasure-coded protection to using whole-object protection. The effect of this change is the same as the effect of retiring an erasure coding topology.

For more information on the effect of retiring an erasure coding topology, see Erasure coding topology retirement.

You cannot remove a tenant from a retiring erasure coding topology if any objects in any of the tenant's namespaces still contain objects that were erasure coded according to that topology.

You can add and remove tenants in an erasure coding topology while one or more systems in the topology are unreachable from other systems in the topology. If conflicting changes are made during this period (for example, the same tenant is added on two different systems and then removed on one of those systems), the most recent change is the one that takes effect when communication between the systems is restored.

While a system in an erasure coding topology is being upgraded, you cannot use that system to add or remove tenants in that topology.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Specifying the tenants for an erasure coding topology


You use the Tenants panel for an erasure coding topology to specify the tenants for the topology. This panel contains two sections:

Tenants in This Erasure Coding Topology — Lists the tenants that are currently included in the erasure coding topology. The tenants are listed in alphanumeric order by name.

Tenant Candidates — Lists the tenants from which you can choose tenants to be added to the erasure coding topology. The tenants are listed in alphanumeric order by name.

Each listed tenant with a name conflict or link conflict is accompanied by this icon: WarnIconFilledIn.png. The hover text for the icon identifies the issue.

Adding and removing tenants

To add tenants to or remove tenants from an erasure coding topology:

1.In the top-level menu of the HCP System Management Console, select ServicesGeo-distributed EC.

2.On the EC Topologies page, click on the topology for which you want to specify the tenants.

3.On the erasure coding topology details page, click on Tenants.

4.Take either or both of these actions:

oTo add tenants to the erasure coding topology:

1.Optionally, in the Tenant Candidates section, filter the list of tenants that are eligible to be included in the topology. For instructions on doing this, see Filtering the tenant lists.

2.In the tenant candidate list, select the tenants you want to add to the topology.

To select all the tenants in the list, click on Select All above the list.

To deselect all the selected tenants, click on Clear above the list.

3.Click on Add Selected Tenants.

oTo remove tenants from the erasure coding topology:

1.Optionally, in the Tenants in This Erasure Coding Topology section, filter the list of tenants that are currently included in the topology. For instructions on doing this, see Filtering the tenant lists.

2.In the list of tenants in the topology, select the tenants you want to remove from the topology.

To select all the tenants in the list, click on Select All above the list.

To deselect all the selected tenants, click on Clear above the list.

3.Click on Remove Selected Tenants.

Filtering the tenant lists

By default, each tenant list in the Tenants panel contains all the applicable tenants. You can filter the list in either section to display a subset of the applicable tenants. A filtered list contains only those items with a name that begins with or is the same as a specified text string.

You cannot filter a list while any of the tenants in it are selected.

To filter a tenant list:

1.In the field above the list, type the text string you want to use as a filter. This string can be up to 64 characters long, can contain any valid UTF-8 characters, and is not case sensitive. White space is allowed.

2.Click on the find control ( FindControl.png ).

To redisplay the entire list, click on the clear filter control ( ClearFilterControl.png ).

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Considerations for modifying an erasure coding topology


These considerations apply to modifying an erasure coding topology:

You can modify these properties of an active erasure coding topology:

oName

oDescription

oDistribution method

oMinimum object size for erasure coding

oErasure coding delay

oRestore period

You cannot modify a retiring or retired erasure coding topology.

Changes you make to the configuration of an erasure coding topology apply to existing objects as well as to new objects.

When you change the distribution method from chunk distribution to full-copy distribution, previously distributed chunks are restored to full copies of object data if the erasure coding delay has not yet expired. The full copies are reduced to chunks again after the erasure coding delay expires.

When you change the distribution method from full-copy distribution to chunk distribution, previously distributed full copies of object data are reduced to chunks after the erasure coding delay expires.

When you reduce the minimum object size for erasure coding, for any given object that was previously subject to whole-object protection but is now subject to erasure coding:

oOn a system where the object is not metadata-only, the object data is reduced to a chunk after the erasure coding delay expires

oOn a system where the object is metadata-only:

If the erasure coding topology is configured for chunk distribution, the system receives a chunk for the object.

If the erasure coding topology is configured for full-copy distribution, the system receives a chunk for the object if the erasure coding delay has already expired. If the erasure coding delay has not yet expired, the system receives a chunk for the object when the delay expires.

When you increase the minimum object size for erasure coding, for any given object that was previously subject to erasure coding but is now subject to whole-object protection:

oOn a system where the object is not supposed to be metadata-only:

If the system has a chunk for the object, the chunk is restored to a full copy of the object data

If the system has a full copy of the object, the full copy remains as is

oOn a system where the object should be metadata-only, the chunk for the object or the full copy of the object data, as applicable, is deleted

When you increase the erasure coding delay for an erasure coding topology configured for full-copy distribution, chunks for existing objects for which the new delay has not yet expired are restored to full copies of the object data.

When you decrease the restore period, objects that are currently in a restored state and for which the new restore period has already expired are returned to their previous erasure-coded states.

When you increase the restore period, objects that are currently in a restored state and for which the new restore period has not yet expired are returned to their previous erasure-coded states after the new restore period expires.

You can modify an erasure coding topology from any system in the topology.

While a system in an erasure coding topology is being upgraded, you cannot use that system to modify the topology.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Modifying an erasure coding topology


To modify an erasure coding topology:

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

2.On the EC Topologies page, click on the topology you want to modify.

3.On the erasure coding topology details page, click on Settings.

4.In the Settings panel, make the changes you want.

For valid values for the settings you can change, see Creating an erasure coding topology.

5.Click on Update Settings.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Retiring an erasure coding topology


Before retiring an erasure coding topology, be sure you're familiar with the information in Erasure coding topology retirement. You cannot make a retiring or retired topology active again.

To retire an erasure coding topology:

1.In the top-level menu of the HCP System Management Console for any system in the topology, select Services Geo-distributed EC.

2.On the EC Topologies page, click on the topology you want to retire.

3.On the erasure coding topology details page, click on Management.

4.In the Management panel, click on Retire.

5.In response to the confirming message, click on Retire.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Considerations for deleting an erasure coding topology


These considerations apply to deleting an erasure coding topology:

You can delete an erasure coding topology only while either of these is true:

oAt least one system in the topology is available, the total number of erasure-coded objects and erasure-coded parts of multipart objects on each available system is zero, and the state of the topology is retired. These are the normal conditions for deleting a topology.

oNo more than one system in the topology is unavailable, the total number of erasure-coded objects and erasure-coded parts of multipart objects on each available system is zero, and the state of the topology is retiring. In this case, you are prompted to confirm the delete request.

ImportantWebHelp.png

Important: Deleting an erasure coding topology under these conditions may result in inaccessible data in namespaces on the unavailable system, even if those namespaces are configured to be compliant. You should delete the topology only if that system is no longer needed. If the system is still needed, wait to delete the topology until the topology has finished retiring on all systems.

You cannot delete an erasure coding topology while either of these is true:

oThe total number of erasure-coded objects and erasure-coded parts of multipart objects on any available system in the topology is greater than zero.

The Management panel on the EC Topologies page for a retiring or retired topology shows the number of erasure-coded objects and erasure-coded parts of multipart objects on the available systems.

oMore than one system in the topology is unavailable, and the state of the topology is retiring.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Deleting an erasure coding topology


To delete an erasure coding topology:

1.In the top-level menu of the HCP System Management Console for any system in the topology, select Services Geo-distributed EC.

2.On the EC Topologies page, click on the topology you want to delete.

3.On the erasure coding topology details page, click on Management.

4.In the Management panel, click on Delete.

If deleting the topology could result in inaccessible data in namespaces on an unavailable system, a confirming message appears.

In the field in the message window, type YES (this is case sensitive) to confirm that you understand the consequences of your action. Then click on Delete Topology.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Understanding the erasure coding topology list


The EC Topologies page in the HCP System Management Console lists the currently defined erasure coding topologies in which the current system participates. To display this page, in the top-level menu of the System Management Console, select Services Geo-distributed EC.

For each listed erasure coding topology, the EC Topologies page shows:

Name — The erasure coding topology name.

State — The current state of the erasure coding topology: Active, Retiring, or Retired. For information on these states, see About erasure coding topologies.

Protection Status — The current status of the erasure coding topology with respect to how well-protected erasure-coded objects are: Healthy, Vulnerable, Broken, Retiring, Retired, or Unknown.

Read Status — The current status of the erasure coding topology with respect to the ability to read erasure-coded objects: Healthy, Vulnerable, Broken, Retired, or Unknown.

For explanations of the protection and read statuses, see Understanding erasure coding topology details.

Alerts — If issues exist with the erasure coding topology, one or both of these icons:

o WarnIconFilledIn.png — This icon is displayed under these conditions:

The erasure coding topology protection status is vulnerable.

The erasure coding topology read status is vulnerable.

Replication is paused for one or more tenants on one or more replication links in the erasure coding topology. This condition is reported only for active topologies.

o BadIconFilledin.png — This icon is displayed under these conditions:

The erasure coding topology protection status is broken.

The erasure coding topology read status is broken.

One or more tenants added to the erasure coding topology have not been added to one or more replication links in the topology. HCP does not report this condition for a tenant until ten minutes after the tenant was added to the topology.

HCP cannot find one or more replication links that are included in the erasure coding topology.

To view text describing the condition that's causing the alert, hover over the alert icon.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Understanding erasure coding topology details


The list of erasure coding topologies on the EC Topologies page shows the current status of each active, retiring, or retired erasure coding topology. To further monitor the status of a topology and to manage the topology, click on the name of the topology in the list.

The page that opens shows details about the erasure coding topology in a Status section, HCP Systems section, and Overview panel, each of which is described below. The additional panels you can access on this page are:

Tenants panel — Shows the tenants that are included in the topology and the tenants that are eligible to be included in the topology. For information on using this panel to change the tenants included in the topology, see Specifying the tenants for an erasure coding topology.

Settings panel — Shows the erasure coding topology properties and lets you change those properties. For information on erasure coding topology properties, see Erasure coding topology properties. For information on changing these properties, see Modifying an erasure coding topology.

Management panel — Lets you retire and delete the erasure coding topology. For information performing these tasks, see Retiring an erasure coding topology and Deleting an erasure coding topology.

Status section

The Status section on the details page for an erasure coding topology shows:

Topology state — The current state of the topology. The topology state can be Active, Retiring, or Retired. For information on these states, see About erasure coding topologies.

Protection status — The current status of the erasure coding topology with respect to how well-protected erasure-coded objects are. The protection status can be:

oHealthy — All of these are true:

All systems in the topology are available.

The loss of a link in the topology would not cause any system to become unavailable.

The suspension of activity on a link in the topology would not prevent any system from receiving data or chunks for newly ingested objects.

Data or chunks for newly ingested objects are being distributed to all systems in the topology. Full copies of object data will be reduced to chunks when the applicable erasure coding delay expires.

Objects that were erasure coded according to the topology are protected.

oVulnerable — One or both of these are true:

The loss of a link in the topology would cause a system in the topology to become unavailable.

The suspension of activity on a link in the topology would prevent a system in the topology from receiving data or chunks for newly ingested objects.

Data or chunks for newly ingested objects are being distributed to all systems in the topology. Full copies of object data will be reduced to chunks when the applicable erasure coding delay expires.

Objects that were erasure coded according to the topology are protected.

oBroken — One or more systems in the topology are unavailable.

Data or chunks for newly ingested objects are being distributed to the systems that are available to the ingest system. However, full copies of object data won't be reduced to chunks until all systems in the topology are available, regardless of the erasure coding delay.

Objects that were erasure coded according to the topology are not protected and may not be available.

For information on how replication works when a topology includes unavailable systems, see Replication service processing.

oRetiring — Both of these are true:

The topology is in the process of retiring.

One or more systems in the topology still have chunks for objects that were erasure coded according to the topology.

oRetired — Both of these are true:

The topology has finished retiring.

No systems in the topology have chunks for objects that were erasure coded according to the topology.

oUnknown — HCP cannot determine the protection status.

Read status — The current status of the erasure coding topology with respect to the ability to read erasure-coded objects.

NoteWebHelp.png

Note: For the purpose of determining read status, HCP treats suspended links as broken links. However, if a suspended link is not actually broken, the systems involved in the link can still use the link to read data from each other.

The read status can be:

oHealthy — Both of these are true:

The loss of a link in the topology would not cause the inability to read erasure-coded objects.

A system in the topology becoming unavailable would not cause the inability to read erasure-coded objects.

The data for objects that were erasure coded according to the topology can be reconstructed or restored as needed.

oVulnerable — All of these are true:

The data for objects that were erasure coded according to the topology can be reconstructed or restored as needed.

The loss of a link in the topology would cause the inability to read erasure-coded objects.

A system in the topology becoming unavailable would cause the inability to read erasure-coded objects.

oBroken — Two or more systems in the topology are unavailable. The data for objects that were erasure coded according to the topology cannot be reconstructed or restored unless the unavailability of all or all but one of those systems is due to links with suspended send activity.

oRetired — The topology has finished retiring. No systems in the topology have chunks for objects that were erasure coded according to the topology.

oUnknown — HCP cannot determine the read status.

Protection levelx+y, where x is the number of data chunks and y is the number of parity chunks for each object that was erasure coded according to the topology.

Erasure-coded objects and object parts on this system — The number of erasure-coded objects and erasure-coded parts of multipart objects on the current HCP system that were erasure coded according to the topology. An object or part is counted as erasure coded if a chunk for it is stored on the system.

Parts of multipart objects are erasure coded independently of each other.

HCP Systems section

The HCP Systems section on the details page for an erasure coding topology contains a diagram of the topology and a numbered list of the systems in the topology.

The lines between the numbered systems in the topology diagram represent the replication links in the topology. The color of each line indicates the last known status of the applicable link:

Gray means healthy.

Orange means not replicating.

Red means unhealthy.

For a description of the link statuses, see Overview panel.

Overview panel

The Overview panel on the details page for an erasure coding topology contains a list of the replication links in the topology. For each link, the section shows:

Name — The link name.

HCP System, HCP System — The HCP systems involved in the link.

Status — The last known status of the link. This status indicates the general health of the link. If the link is not directly connected to the current HCP system, the link status may be out of date.

The link status can be:

oHealthy — The status displayed when the specific status of the link is one of these:

Synchronizing data

Scheduled off period

oNot replicating — The status displayed when the specific status of the link is one of these:

Suspended by user

Remote storage full, link suspended

Local storage full, link suspended

Failed over

oUnhealthy — The status displayed when the specific status of the link is one of these:

High error rate

Stalled link

Unrecognized link

Broken link

oUnknown — HCP cannot determine the specific status of the link.

For information on the specific link statuses, see Understanding the replication link list.

Alerts — If issues exist with the link, one or both of these icons:

o WarnIconFilledIn.png — This icon is displayed while replication is paused for one or more tenants on the link.

o BadIconFilledin.png — This icon is displayed under these conditions:

One or more tenants added to the erasure coding topology have not been added to the link. HCP does not report this condition for a tenant until ten minutes after the tenant was added to the topology.

This condition is reported only on the systems involved in the link.

HCP cannot find the link.

This condition is reported only on the system where HCP cannot find the link. A link that cannot be found on one of the systems involved in the link is typically reported as broken on the other system involved in the link.

To view text describing the condition that's causing the alert, hover over the alert icon.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.