HCP tenant properties

You specify a set of properties when you create a tenant.

You can specify the following tenant properties:

A name for the tenant. This name determines the URL for the tenant.

When naming tenants, keep in mind that each tenant name must be unique within an HCP system. For example, you cannot create a tenant named finance for each of two different customers. You could, however, create a tenant named cust1-finance for Customer 1 and another tenant named cust2-finance for Customer 2.

Also, keep in mind that you cannot replicate a tenant to another HCP system that already has a different tenant with the same name.

You can change the tenant name at any time after you create the tenant, except while the CIFS or NFS protocol is enabled for any of the tenant's namespaces. However, keep in mind that when you change the tenant name, you are also changing the URLs for the tenant and its namespaces.

Tip: Be sure to notify the tenant contact when you change the name of a tenant.

Optionally, a description of the tenant. For example, you can use a description to specify the name of the organization for which you’re creating the tenant.

You can change this description at any time after you create the tenant.

In an HCP system that uses virtual networking and has the management network enabled at the System Management Console, a management network for the tenant. Clients use this network to access the Tenant Management Console and HCP management API for the tenant. Clients use the domain name associated with this network when sending access requests to the management interfaces (Tenant Management Console and HCP management API) for the tenant.

You need to ensure that requests for access to the Tenant Management Console and HCP management API for the tenant are routable from the clients to the HCP system over the management network that you specify.

If the tenant is configured to allow system-level users to manage it, those users can access its Tenant Management Console directly from the System Management Console even if the tenant management network is not [hcp_system].

You can select a different management network for a tenant at any time. However, when you change the management network, you also change:

oThe IP addresses used to route access requests from clients to the management interfaces (Tenant Management Console and HCP management interface) for the tenant

o The management network domain name included in the tenant URL

Tip: Be sure to notify the tenant contact when you select a different management network for a tenant.

In an HCP system that uses virtual networking, a data access network for the tenant. Clients use this network to access the contents of namespaces that the tenant owns. Clients use the domain name associated with this network when sending namespace data access requests to the tenant.

You need to ensure that requests for access to the contents of the namespaces that the tenant owns are routable from the clients to the HCP system over the data access network that you specify.

HCP Data Migrator (HCP-DM) and the Hitachi Data Discovery Suite (HDDS) search facility do not support the use of IPv6 networks for communication with HCP. To enable clients to use HCP-DM to access the contents of namespaces that the tenant owns or to use the HDDS search facility to search and index those namespaces, you need to specify a data access network that has IPv4 addresses assigned to it.

You can select a different data access network for a tenant at any time. However, when you change the data access network, you also change:

oThe IP addresses used to route namespace data access requests from clients to the tenant

oThe domain name included in the URLs for the namespaces that the tenant owns

Changing the IP addresses and domain name used to access the namespaces that a tenant owns causes all CIFS and NFS mounts of those namespaces to be disconnected from HCP.

Tip: Be sure to notify the tenant contact when you select a different data access network for a tenant.

A hard quota for the tenant. This is the total amount of storage available to the tenant. The tenant allocates this storage to the namespaces it owns by setting a hard quota for each namespace.

You can allocate more total space to your tenants than is actually available for storing objects. HCP warns you when the space used by all tenants is approaching the system storage capacity.

You can change this quota at any time after you create the tenant. However, you cannot specify a quota that is less than the total amount of storage that the tenant has already allocated to its namespaces.

Note: HCP checks the amount of data stored in a namespace against the namespace hard quota hourly. If large amounts of data are added rapidly to a namespace, the namespace can store substantially more data than its hard quota allows.

Each namespace managed by a tenant can exceed its hard quota in this way. As a result, the total amount of storage used by all namespaces owned by a tenant can exceed the hard quota for that tenant.

A soft quota for the tenant. This is the percentage point at which HCP should notify tenant administrators that the storage available to the tenant is running low on free space.

You can change this quota any time after you create the tenant.

A namespace quota for the tenant. This is the number of namespaces that HCP reserves for the tenant out of the total number of namespaces that the system can have (10,000).

You cannot overallocate namespaces. That is, the maximum number of namespaces that you can allocate to tenants is 10,000, or 9,999 if the system includes the default namespace.

You can create tenants that do not have quotas. The total number of namespaces that these tenants can own is equal to the number of unallocated namespaces in the HCP system. If you allocate a total of 10,000 namespaces to other tenants, the tenants that do not have quotas cannot create any namespaces.

You can change the namespace quota for a tenant at any time after you create the tenant, as long as the new quota is not less than the number of namespaces that the tenant currently owns.

Note: While an active/passive replication link that includes a given HCP tenant is failed over to the replica, you cannot change the namespace quota for that tenant on the replica. For information about replication links, see Replicating Tenants and Namespaces.

The authentication methods allowed for the tenant. At least one of these authentication methods must be enabled:

oLocal — The tenant supports internal authentication by HCP. To be authenticated, a user must have a locally authenticated HCP user account.

oRADIUS — The tenant supports remote authentication by RADIUS. To be authenticated, a user must have a RADIUS-authenticated HCP user account.

A tenant that supports RADIUS authentication must also support local authentication, Active Directory authentication, or both.

oActive Directory — The tenant supports remote authentication by AD. To be authenticated, a user must have an AD user account.

Tip: To help ensure that AD authentication is available for those tenants that need to support it, enable AD only for those tenants.

Note:  For RADIUS or Active Directory authentication to work for the tenant to access the Tenant Management Console and HCP management API, the tenant management network must be [hcp_system]. Similarly, for RADIUS or Active Directory authentication to work for the tenant to access the content of the tenant's namespaces, the tenant data access network must be [hcp_system].

You can change the allowed authentication methods at any time after you create the tenant. However, you cannot disable local authentication if the only tenant-level account with the security role is a locally authenticated HCP user account. Similarly, you cannot disable AD authentication if the only tenant-level account with the security role is a group account.

If you disable AD authentication for a tenant after the tenant has created group accounts, those accounts continue to exist but are not visible to the tenant. If you subsequently reenable AD authentication for the tenant, the group accounts become visible again.

An initial security account for the tenant. This can be a locally authenticated HCP user account or an HCP group account, depending on which authentication methods are allowed for the tenant:

oFor a locally authenticated user account, you specify the account username and password. When HCP creates the tenant, it also creates a tenant-level user account with the specified username and password. This account has only the security role and no data access permissions.

oFor an HCP group account, you select an AD group. When HCP creates the tenant, it also creates a tenant-level group account that corresponds to that AD group. This group account has only the security role and no data access permissions.

For the initial security account to be a group account, Active Directory must be selected as an authentication method for the tenant, HCP must be configured to support AD, and HCP must be able to communicate with AD.

After creating the tenant, you cannot modify the initial security account configuration from the System Management Console. However, tenant administrators can modify the initial security account configuration in the Tenant Management Console.

Optionally, contact information for the tenant. For example, you can specify contact information for the primary person responsible for administering the tenant.

You can change this information at any time after you create the tenant. Tenant-level administrators can also change this information from the Tenant Management Console.

Optionally, tags for the tenant. A tag is an arbitrary text string associated with an HCP tenant. You can associate up to ten tags with any given tenant, and you can use the same tags for multiple tenants.

You can use tags to group tenants and filter tenant lists. For example, if you’ve created multiple tenants for a company named ABC Corporation, you could associate the tag ABC with each of those tenants. Then you could filter a list of tenants to display only the tenants with that tag.

Tags exist only as long as they are associated with at least one tenant. If you remove a tag from the last tenant with which it’s associated, the tag no longer exists.

You can change the tags associated with the tenant at any time after you create the tenant.

Whether the tenant can be replicated.

After creating the tenant, you can change this setting from not allowing replication to allowing replication. However, you cannot do the reverse.

For information about replication, see Replicating Tenants and Namespaces.

If the tenant can be replicated, whether tenant administrators can choose which cloud-optimized namespaces allow erasure coding. If tenant administrators are not allowed to do this, all cloud-optimized namespaces owned by the tenant allow erasure coding.

After creating the tenant, you can change this setting from having all cloud-optimized namespaces allow erasure coding to allowing tenant administrators to choose which cloud-optimized namespaces allow erasure coding. However, you cannot do the reverse.

When HCP is upgraded to release 8.0 or later, preexisting tenants are configured such that tenant administrators cannot select erasure coding for namespaces.

Whether tenant administrators can select the retention mode for the namespaces that the tenant owns. If this is not allowed, tenant administrators can create namespaces only in enterprise mode.

After creating the tenant, you can change this setting from not allowing tenant administrators to select the retention mode to allowing it. However, you cannot do the reverse.

Whether tenant administrators can enable search for the namespaces that the tenant owns.

After creating the tenant, you can change this setting from not allowing tenant administrators to enable search for the namespaces that the tenant to allowing it. However, you cannot do the reverse.

Whether tenant administrators can associate service plans with the namespaces that the tenant owns. If tenant administrators are not allowed to do this, you need to specify a service plan for the tenant. This specification is not visible in the Tenant Management Console.

After creating the tenant, you can change this setting from not allowing tenant administrators to associate service plans with the namespaces that the tenant owns to allowing it. However, you cannot do the reverse.

Whether tenant administrators can enable versioning for the namespaces that the tenant owns.

After creating the tenant, you can change this setting from not allowing tenant administrators to enable versioning for the namespaces that the tenant owns to allowing it. However, you cannot do the reverse.

© 2015, 2020 Hitachi Vantara LLC. All rights reserved.