Skip to main content
Outside service Partner
Hitachi Vantara Knowledge

Network overview

HCP networks


HCP has two networks that are created during system installation: [hcp_system] and [hcp_backend]. The [hcp_system] network is used for front-end communication with the system. The [hcp_backend] network is used for communication between the nodes in the HCP system. Modifying the [hcp_system] and [hcp_backend] networks requires the service role and should be done only by authorized HCP service providers.

With certain HCP system hardware configurations, an [hcp_management] network is created during installation and can be enabled once the system is running. The [hcp_management] network needs to be enabled by a system administrator. The management network segregates system and tenant administration, management API, SNMP , syslog, outgoing SMTP, and SSH traffic from the [hcp_system] network.

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

IP modes


The IP mode for a front-end network determines whether that network can be configured to use IPv4 addresses, IPv6 addresses, or both. HCP has a system-level IP mode setting that determines which types of front-end network IP addresses are supported.

If the system supports both IPv4 and IPv6 addresses (that is, the IP mode is set to Dual), the [hcp_system] networks can be configured to use either or both types of IP addresses. If the HCP system is configured to support the [hcp_management] network, the [hcp_management] network can use IPv4 or IPv6 regardless of the IP mode set for front-end network.

The IP mode of a front-end network determines the types of IP addresses that can be used for communication between HCP and other devices over that network. For example, if the [hcp_system] network is configured to use only IPv6 addresses, all devices that need to use that network to communicate with HCP must be configured to use IPv6 addresses (or both IPv4 and IPv6 addresses).

If HCP is not currently configured to support a specific type of IP address that is required for communication between HCP and other devices, contact your authorized HCP service provider to request a change to the system configuration.

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

About virtual networking with HCP


Virtual networking is a technology that enables the overlay of multiple logical network configurations onto a single physical network. For virtual networking to work, the physical network must include VLAN-capable devices.

HCP supports virtual networking only for the front-end network through which clients communicate with the system and through which different HCP systems communicate with each other. HCP does not support virtual networking for the back-end network through which the HCP nodes communicate with each other.

In HCP, logical network configurations are referred to simply as networks. Each network has a name, an IP mode (IPv4, IPv6, or Dual), one or more subnets defined for the network, IP addresses defined on each subnet for none, some, or all of the nodes in the HCP system, and some other settings.

You can create and configure user-defined networks for communication with HCP over the front-end network. In order to create networks the Virtual network management must be enabled. You can then configure the system to use the specific networks for specific functions.

You can also create network aliases for user-defined networks. Aliases are pointers to actual networks. For information on network aliases, see Network aliases.

At any given time, the total number of user-defined networks and network aliases together cannot exceed 200.

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

Front-end network usage


The [hcp_system] network is always used for:

Access to the HCP System Management Console

Access to the Tenant Management Console for the default tenant

Access to the HCP management API using a system-level URL

Syslog functions at the system and tenant levels

SNMP functions at the system and tenant levels

Access to the default namespace using the namespace access protocols

Access to the HCP metadata query API using a system-level URL

Access to the HCP Search Console using a system-level URL

Access to the default namespace using HCP Data Migrator

Communication between HCP and Active Directory for configuration and for user authentication at the system and tenant levels

Communication between HCP and RADIUS servers for user authentication at the system and tenant levels

For SAIN systems, communication between HCP and the storage arrays

Communication between HCP and any external storage components configured for the system

Communication between HCP and Hitachi Tiered Storage Manager

Communication between HCP and Hitachi Device Manager (HDvM)

Communication between HCP and Hi-Track®

Access to the HCP system through interfaces reserved for authorized service providers

You can choose to use [hcp_system] or any user-defined network for the following purposes:

Management of a given HCP tenant, including:

oAccess to the Tenant Management Console for the tenant

oAccess to the HCP management API using a URL for the tenant

You select the network for this purpose when you create or modify the tenant.

Access to the namespaces owned by a given HCP tenant, including access through:

oThe namespace access protocols

oThe Namespace Browser

oThe HCP metadata query API using a URL for the tenant

oThe HCP Search Console using a URL for the tenant

oHCP Data Migrator

You select the network for this purpose when you create or modify the tenant.

Communication with other HCP systems in a replication topology. For information on selecting the network for this purpose, see Replicating Tenants and Namespaces.

You can use the same network for multiple purposes. If you don’t choose a network for a purpose, HCP uses [hcp_system] by default.

When you select a network for a given purpose, you need to ensure that your networking infrastructure is configured to allow client requests for that purpose to be routed to that network. HCP responds to each client request on the same network as the one on which the request arrived. Therefore, clients do not need to be on the same subnet as the network they are using to access the system, but they do need to be configured to use at least one IPv4 or IPv6 address that is routable from that network.

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

Network properties


A user-defined network has these properties:

A name.

Optionally, a description.

Optionally, a VLAN ID (see Tagged and untagged networks).

A domain (see Network domains).

A maximum transmission unit (MTU). The MTU is the largest packet size supported for data sent on the network.

The MTU for a network can be 1,500 or, if supported by the networking infrastructure, 9,000. The larger MTU reduces overhead and increases network throughput.

Whether the network is enabled or disabled. If a network is disabled, HCP does not accept communications routed on that network.

When first created, networks are enabled by default.

A total number of tenant references. This is the number of tenants that are configured to use the network for management, data access, or both purposes. HCP derives this number from the tenant configurations defined on the system.

For information on this property and on the next property in this list, see Understanding the tenant list

If the network is assigned to one or more tenants, a list of tenant references. This list contains the names of the tenants that are configured to use the network and the purpose for which each tenant uses the network (management, data access, or both purposes). HCP obtains this information from the tenant configurations defined on the system.

A total number of alias references. This is the number of network aliases that are defined for the network. HCP derives this number from the network alias configurations defined on the system.

For more information on this property and on the next property in this list, see Network aliases.

If one or more aliases are defined for the network, a list of alias references. This list contains the names of the network aliases that are defined for the network. HCP obtains this information from the network alias configurations defined on the system.

Whether HCP should hide the IP addresses of its master name servers from clients using the network and allow client access to HCP over the network only through specified downstream DNS servers.

For more information on this property and on the next two properties, see Downstream DNS configuration settings for networks.

Whether HCP should notify specified downstream DNS servers about changes to the zone definition for the network.

The rate at which the downstream DNS servers should query HCP for updates to the zone definition for the network domain.

If the [hcp_system] network is also configured to use a specific type of IP address, a user-defined network can have that IP address.

Whether the network supports IPv4 addresses, IPv6 addresses, or both:

oIf the network supports IPv4 addresses, the network has these properties:

An IPv4 gateway. This is the IPv4 address from which system-initiated communications are sent over the network.

An IPv4 subnet mask.

An IPv4 subnet. HCP derives the IPv4 subnet for the network from the IPv4 gateway and subnet mask that you specify.

Optionally, assignments of IPv4 addresses to storage nodes. The IPv4 addresses for a given network must all be on the IPv4 subnet defined for that network.

NoteWebHelp.png

Note: If a node has any IP addresses assigned to it for a given network, that node must have an IP address assigned to it on each IPv4 and IPv6 subnet defined for the network.

If the network supports IPv6 addresses, it has primary IPv6 address settings and, optionally, secondary IPv6 address settings. For each type of IPv6 address settings, the network has these properties:

An IPv6 gateway. This is the IPv6 address from which system-initiated communications are sent over the network.

NoteWebHelp.png

Note: Each IPv6 gateway defined for the network can be a global address, a unique local address (ULA), or a link local address (LLA). However, if two IPv6 gateways are defined for the network, you cannot use ULAs for both gateways, and the two gateways must be on separate, non-overlapping IPv6 subnets.

An IPv6 address prefix length.

An IPv6 subnet. HCP derives the IPv6 subnet for the network from the IPv6 gateway and IPv6 address prefix length that you specify.

Optionally, assignments of IPv6 addresses to storage nodes. The IPv6 addresses for the network must all be on the IPv6 subnet defined for that network.

NoteWebHelp.png

Note: If a node has any IP addresses assigned to it for a given network, that node must have an IP address assigned to it on each IPv4 and IPv6 subnet defined for the network.

Each network, including the [hcp_system] and [hcp_backend], must use separate, non-overlapping subnets for IPv4 addresses, primary IPv6 addresses, and secondary IPv6 addresses.

A zone definition. This is the DNS zone definition that is currently used for the network domain. HCP automatically creates and maintains a DNS zone definition for each network defined on the system.

For more information on zone definitions used for HCP, see Configuring DNS for HCP.

For information on viewing zone definitions used for HCP, see Viewing the DNS zone definition for a network domain.

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

Tagged and untagged networks


A tagged network is one that has a specified VLAN ID. The VLAN ID is an identifier that’s attached to each packet routed to HCP over that network. This function is performed by the switches in the physical network.

The routing tables in the switches that route requests to the HCP front end must include each VLAN ID you assign to a network. The routing tables associate the VLAN IDs with the network subnets.

A network carries only the packets that have its VLAN ID and ignores all other packets, thereby segregating the traffic on each tagged network from the traffic on other networks.

An untagged network is one for which you don’t specify a VLAN ID. An untagged network ignores all packets that have VLAN IDs.

HCP can have at most one untagged front-end network, including the [hcp_system] network. All other networks must have a VLAN ID.

An untagged network uses the bond0 front-end network interface. When you assign a VLAN ID to a network, HCP creates a logical network interface for the network. This interface is named bond0.xxxx, where xxxx is the VLAN ID, with leading zeroes added if needed to create a four-digit number.

The figure on the next page shows a configuration in which:

HCP uses the [hcp_system] network with VLAN ID 999 for system-level management purposes

The tenant named Tenant-1 uses a network named t1 with VLAN ID 7 for tenant management purposes and a network named t1-data with VLAN ID 8 for data access purposes

HCP uses a network named replication with VLAN ID 200 for replication traffic

1_1.jpg

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

Network domains


Each network you create must be associated with a domain. The domain can be unique to the network or can be shared among networks. For example, you may want to configure different tenants to use networks associated with different domains, but you may want to configure a single tenant to use management and data networks associated with the same domain.

Clients use network domain names in the URLs that provide access to the HCP system. By associating different domains with different networks, you can brand the system for different customers. For example, the networks you associate with the tenants you create for Customer-1 could all have the domain named object-store.cust1.com.

Assigning different domains to different networks enhances network security because each domain uses a separate certificate to authenticate access requests. If two different networks have two different domains assigned to them, a client cannot use the same credentials to access HCP over both networks. In addition, when a client request uses a domain name for access to HCP, the client making that request has visibility only into the networks that use the specified domain. Thus, a client can retrieve IP addresses only for the networks that it’s authorized to use to access the HCP system.

For more information on domains, see About domains.

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

Downstream DNS configuration settings for networks


At any time after you create a network, you can change its downstream DNS configuration settings to:

Enable hidden master for one or more downstream DNS servers

Enable notify for one or more downstream DNS servers

Change the DNS refresh rate for all the downstream DNS servers

A downstream DNS server is a DNS server through which client requests are routed to HCP. An upstream DNS server is a DNS server to which HCP routes the outbound communications it initiates (for example, for sending log messages to syslog servers or for communicating with Active Directory). The downstream and upstream DNS servers can be the same servers.

Hidden master

Hidden master is an HCP DNS configuration that’s used to hide the IP addresses of the HCP nodes configured as master name servers from users accessing HCP over a specific network. In a hidden master configuration, the specified downstream DNS servers become the authoritative masters for the zone defined for the network domain. Additionally, in the zone definition that HCP sends, the name server records contain the IP addresses of the downstream DNS servers, and not the IP addresses of the HCP nodes configured as master name servers.

Notify

Notify is a network configuration option that, when enabled for a network, tells HCP to notify only the specified downstream DNS servers whenever any of the network properties changes (including the description). In response to this notification, each specified DNS server sends a request to HCP to get the updated zone definition for the network domain.

Zone definitions with hidden master or notify enabled

When hidden master or notify is enabled for a network, the domain associated with that network must be defined as a secondary zone (also called a slave zone), and not as a stub zone, on the specified downstream DNS servers. If a network domain is defined as a stub zone and:

You enable hidden master for the network, client requests routed to any of the specified DNS servers fail

You enable notify for the network, the specified DNS servers do not receive the notify messages

If a stub zone is already defined for a domain associated with a network, and you plan to enable hidden master or notify for that network, change the DNS zone definition type for the domain to secondary before you modify the network.

When hidden master or notify is enabled for a network that’s configured to use a secondary IPv6 subnet, each IPv6 address that’s specified in the downstream DNS server list must either be on the secondary IPv6 subnet or be routable from the primary IPv6 gateway that’s defined for the network.

For more information on zone definitions for HCP, see Configuring DNS for HCP.

Refresh rate

The refresh rate for a network is the frequency with which the downstream DNS servers poll HCP to check whether the zone definition for the network domain has changed. If the definition has changed, the servers then ask HCP for the updated definition.

The refresh rate always applies to all the downstream DNS servers that have a zone definition for the network domain and is used regardless of whether that zone definition has a type of secondary or stub.

By default, the refresh rate is three hours. If you enable notify and specify all the applicable DNS servers, consider increasing the refresh rate to a much higher value.

Notify does not work with stub zones. Therefore, if the domain is defined as a stub zone, consider decreasing the refresh rate. If DNS failover occurs, the shorter refresh rate may allow clients targeting a failed system over the network to be more quickly redirected to another system in the replication topology. For information on DNS failover, see Replicating Tenants and Namespaces.

You specify the refresh rate for a network as any combination of weeks (W), days (D), hours (H), minutes (M), and seconds (S), using this syntax:

#W#D#H#M#S

These considerations apply:

In each case, # must be an integer greater than or equal to one.

If an integer is specified without a time unit, the time unit is assumed to be seconds.

Time units can be specified in any order.

Any given time unit can be specified only once.

Time units are not case sensitive.

The total time specified must be in the range one through 2,147,483,647 seconds.

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

Advanced downstream DNS configuration


A system administrator can activate advanced downstream DNS configuration mode through the management API. The advanced downstream DNS configuration mode offers more control over the HCP system downstream DNS configuration than the basic panel provides. For more information on enabling advanced downstream DNS configuration mode, see the HCP Management API Reference manual.

Once enabled, advanced DNS downstream configuration mode replaces the Downstream DNS Configuration panel for an individual network on the Network Network View page with Zone Entry and Forward Zone File fields that let you work directly with the HCP DNS management files. In order to use these fields, you need to have the service role. Using advanced downstream DNS configuration mode is not recommended unless you have an extensive background in networking. User accounts with the monitor role enabled can see the created networks.

Downstream DNS configuration supports 32 downstream DNS servers.

For more information on zone definitions for HCP, see Configuring DNS for HCP.

For more information on using the advanced downstream DNS configuration mode, see Changing the advanced downstream DNS configuration settings for a network.

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

Network aliases


A network alias is a named pointer to another network. You can select a network alias for any purpose for which you can select a network. When a network alias is selected for a particular purpose, HCP uses the network the alias points to for that purpose.

For example, suppose you have a network alias named t1-mng that points to a network named tenant-1. If you select t1-mng as the management network for a given tenant, HCP uses the tenant-1 network as the management network for that tenant.

Network aliases are useful in the context of replication, particularly in situations where the network topologies differ between the two systems involved in a given replication link. The two systems, for example:

May not have the same number of nodes

May not both have a VLAN-capable networking environment

Because network topologies can differ, HCP doesn’t replicate the definitions of networks and network aliases from one system to another. However, when replicating a tenant, HCP does replicate the names of the networks or aliases associated with that tenant. For the tenant and its namespaces to be accessible on the target system, networks or aliases with those names must be defined on that system.

Here are two replication scenarios that illustrate the use of network aliases:

One of the HCP systems involved in a given replication link makes extensive use of virtual networking, with each tenant having its own networks for management and data access purposes. None of these networks is [hcp_system]. The other system involved in the link is in a networking environment that is not VLAN capable. As a result, the only front-end network defined on that system is [hcp_system].

To support replication of the tenants on the first system to the second system, for each network used by a tenant on the first system, you create a network alias with the same name on the second system. You define each of these aliases to point to the [hcp_system] network.

One of the HCP systems involved in a given replication link has networks named t1-mng, t1-data, t2-mng, t2-data, and so forth selected as the management and data access networks for Tenant-1, Tenant-2, and so forth. The other system involved in the link is used exclusively for data access. Therefore, on that system, the segregation of tenant management networks is not important.

On the second system, you want to have a single network for the management of all tenants and a separate network for data access for each tenant. To do this and still support replication of all the tenants from the first system to the second system, on the second system:

oFor tenant management, you create a single network named tenant-mng. You also create network aliases named t1-mng, t2-mng, and so forth that all point to the tenant-mng network.

oFor data access, you create networks named t1-data, t2‑data, and so forth.

HCP does not require that the networks and network aliases defined on one system in a replication pair directly correspond to networks and network aliases on the other system. That is, the name of a network on one system can be the name of an alias on the other system.

For more information on replication, see Replicating Tenants and Namespaces.

These considerations apply to network aliases:

The target network for a network alias can be a user-defined network or the [hcp_system] network. A network alias cannot point to another network alias.

A network alias can point to only one network. However, multiple aliases can point to the same network.

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

Network states


To be used most effectively, a network should have IP addresses defined for each node in the HCP system. This enables HCP to spread the processing load across all nodes for clients using that network.

If a node doesn’t have IP addresses for a given network, that node does not receive communications that come into the system on that network. However, a network is usable as long as at least one available node is assigned IP addresses for the IPv4 and IPv6 subnets defined for that network.

Depending on the number of nodes that have IP addresses for a network, the network can be in any of these states:

Fully defined — A network is fully defined if all nodes in the system have IP addresses defined for the network.

Partial — A network is partial if at least two nodes have IP addresses defined for the network and at least one node does not have any IP addresses defined for the network.

Degraded — A network is degraded if exactly one node has IP addresses defined for that network.

A degraded network presents a single point of failure for clients using that network for system access.

Empty — A network is empty if no nodes have IP addresses defined for the network. An empty network is not usable.

You cannot select an empty network for tenant management or data access purposes. You cannot select an empty, degraded, or partial network for use with replication.

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

Isolating networks for storage tiering


A network can be reserved for exclusive communication between an HCP system and an HCP S Series Node or an HCP supported external storage device. This increases tiering security by segregating data tiering to individual networks instead of having all data tiered over one network.

The total amount of virtual networks that can tier to individual storage components is 200. In order to designate an individual network to a storage component, you need the administrator role. Users with the monitor role can see which storage components are tiering through which networks.

If a network is assigned to a storage tier, it can still be used for Tenant data management, Tenant network management, and replication. For more information about Tenant management, see HCP tenant properties. For more information about replication, see the Replicating Tenants and Namespaces manual.

In order to give storage components individual networks, Virtual network management must be enabled. For information on enabling Virtual network management, see About the Advanced Setting panel.

A network is only accepted for an individual storage component if each node that belongs to the network has its IP address defined on HCP.

For more information on how to select a network for individual storage components, see:

Creating an S Series storage component

Creating an extended storage component

For more information on selecting a network for existing storage components, see:

Modifying basic component settings

Modifying an extended storage component

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

Considerations for virtual networking


The following considerations apply to virtual networking with HCP:

The IP mode of a front-end network determines the type of IP addresses that can be used to communicate with HCP over that network. Before selecting a specific network for a specific purpose, you need to ensure that all devices that need to communicate with HCP for that purpose are configured to use at least one type of IP address supported by that network.

HCP accepts communications from Active Directory only on the [hcp_system] network. Therefore, if a tenant is configured to use AD for user authentication, that tenant must also be configured to use either the [hcp_system] network or an alias for that network for both management and data access purposes. In addition, each Active Directory domain controller used for HCP user authentication must have at least one IPv4 or IPv6 address that is routable from the [hcp_system] network.

When using HCP Data Migrator to copy objects between namespaces owned by different tenants, a client must have visibility into the data access networks for both tenants.

HCP Data Migrator does not support the use of IPv6 networks for communication with HCP. Therefore, to use HCP Data Migrator to access namespaces owned by a given tenant, that tenant must have IPv4 addresses defined for its data access network.

In addition, if the data access network for a tenant has both IPv4 and IPv6 addresses, HCP Data Migrator cannot use a domain name to connect to any namespace owned by that tenant. Instead, HCP Data Migrator must be configured to connect to each namespace using the IPv4 addresses assigned to the nodes for the data access network.

After HCP is upgraded from release 6.x to release 7.0 or later, by default, the HCP system is configured to support only IPv4 addresses for front-end networks. If you need to use IPv6 addresses for communication between HCP and other devices over the [hcp_system] network or any user-defined network, you need to ensure that when the upgrade is complete, your authorized HCP service provider configures HCP to enable support for IPv6 addresses and then configures the [hcp_system] network to use IPv6 addresses.

When a new node is added to the HCP system, it automatically has IP addresses on each subnet defined for the [hcp_system] network. However, it does not have any IP addresses for any user-defined front-end networks. Those networks, therefore, become partial networks. You can assign IP addresses to the new node for each of those networks at any time.

For considerations related to replicating an HCP system that uses virtual networking, see Network aliases and Replicating Tenants and Namespaces.

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