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.
At any given time, the total number of user-defined networks and network aliases together cannot exceed 200.
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 systems
- 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 Hitachi Remote Ops®
- 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:
- Access to the Tenant Management Console for the tenant
- Access 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:
- Namespace access protocols
- Namespace Browser
- HCP metadata query API using a URL for the tenant
- HCP Search Console using a URL for the tenant
- HCP Data Migrator (HCP-DM)
You select the network for this purpose when you create or modify the tenant.
- Communication with other HCP systems in a replication topology.
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.
A user-defined network has the following properties:
- A name
- Optionally, a description
- Optionally, a VLAN ID
- A domain
- 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. HCP derives this number from the tenant configurations defined on the system.
- 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). 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.
- 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.
- 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:
- If 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.NoteIf 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 IPv4 addresses, the network has these properties:
- 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.NoteEach 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.
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.
- An IPv6 gateway. This is the IPv6 address from which system-initiated communications are sent over the network.
- 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.
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 following figure 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
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.
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 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 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.
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.
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.
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:
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.
Advanced downstream DNS configuration
A system administrator can activate advanced downstream DNS configuration mode through the HCP management API.
Advanced downstream DNS configuration mode offers more control over the HCP system downstream DNS configuration for an individual network than using the Network View page of the System Management Console. This configuration enables you to work directly with the HCP DNS management files.
Downstream DNS configuration supports 32 downstream DNS servers.
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:
- For 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.
- For 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.
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.
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:
A network is fully defined if all nodes in the system have IP addresses defined for the network.
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.
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.
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.
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.
In order to give storage components individual networks, Virtual network management must be enabled.
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.
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 (HCP-DM) 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.