Network model

You can configure three networks for use with the StorageGRID Webscale system.

To understand how these three networks are used, consider the three types of network traffic that are processed by nodes in a StorageGRID Webscale system:

To allow you more precise control and security, you can configure one, two, or three networks to manage these three types of traffic.

Grid Network

The Grid Network is required. It is used for all internal StorageGRID Webscale traffic. The Grid Network provides connectivity between all nodes in the grid, across all sites and subnets. All hosts on the Grid Network must be able to talk to all other hosts. The Grid Network can consist of multiple subnets. Networks containing critical grid services, such as NTP, can also be added as Grid subnets.

When the Grid Network is the only StorageGRID Webscale network, it is also used for all admin traffic and all client traffic. The Grid Network gateway is the node default gateway unless the node has the Client Network configured.

Attention: When configuring the Grid Network, you must ensure that the network is secured from untrusted clients, such as those on the open internet.

Admin Network

The Admin Network is optional. It is a closed network used for system administration and maintenance. The Admin Network is typically a private network and does not need to be routable between sites.

Using the Admin Network for administrative access allows the Grid Network to be isolated and secure. Typical uses of the Admin Network include access to the Grid Management Interface, access to critical services, such as NTP and DNS, access to audit logs on Admin Nodes, and SSH access to all nodes for maintenance and support. The Admin Network is never used for internal grid traffic. An Admin Network gateway is provided and allows the Admin Network to span multiple subnets. However, the Admin Network gateway is never used as the node default gateway.

Client Network

The Client Network is also optional. It is an open network used to provide access to grid services for client applications such as S3 and Swift. The Client Network enables grid nodes to communicate with any subnet reachable through the Client Network gateway. The Client Network does not become operational until you complete the StorageGRID Webscale configuration steps.

You can use the Client Network to provide client access to the grid, so you can isolate and secure the Grid Network. The following nodes are often configured with a Client Network:
  • API Gateway Nodes and Storage Nodes, because these nodes provide S3 and Swift protocol access to the grid.
  • Admin Nodes, because these nodes provide access to the Tenant Management Interface.

When a Client Network is configured, the Client Network gateway is required and becomes the node default gateway after the grid has been configured.

Supported networks

The table summarizes the supported networks.

Network Interface IP/Mask Gateway Static routes Default route (
Grid Network (required) eth0 CIDR for static IP The Grid Network gateway must be configured if there are multiple grid subnets. The Grid Network gateway is the node default gateway until grid configuration is complete. Static routes are generated automatically for all nodes to all subnets configured in the global Grid Network Subnet List. The Grid Network Gateway IP is the default gateway. If a Client Network is added, the default gateway switches from the Grid Network gateway to the Client Network gateway when grid configuration is complete.
Admin Network (optional) eth1 CIDR for static IP The Admin Network gateway is required if multiple admin subnets are defined. Static routes are generated automatically to each subnet configured in the node's Admin Network Subnet List. N/A
Client Network (optional) eth2 CIDR for static IP The Client Network gateway is required if the Client Network is configured. The Client Network gateway becomes the default route for the grid node when grid configuration is complete. N/A Added if a Client Network Gateway IP is configured
When deploying grid nodes:
  • You configure the Grid Network Subnet List using the Grid Management Interface to enable static route generation between subnets on the Grid Network.

  • Each node must be attached to the Grid Network and must be able to communicate with the primary Admin Node using the networking configuration you specify when deploying the node.
  • At least one NTP server must be reachable by the primary Admin Node, using the networking configuration you specified when deploying the primary Admin Node.
  • If you are not ready to configure the optional Admin and Client Networks during deployment, you can configure these networks when you approve grid nodes during the configuration steps. See "Approving pending grid nodes" for more information.
  • Admin Nodes must always be secured from untrusted clients, such as those on the open internet. You must ensure that no untrusted client can access any Admin Node on the Grid Network, the Admin Network, or the Client Network.
After completing configuration:
  • If DHCP was used to assign IP addresses on the Admin and Client Networks, you must make the leases assigned by the DHCP server permanent.

    Note: The Grid Network configuration does not support DHCP. For the other networks, you can only set up DHCP during the deployment phase. There are no options to set up DHCP during configuration.
  • You must use the IP address change procedures if you want to change IP addresses, subnet masks, and default gateways for a grid node. For more information, see the "Configuring IP addresses" section in the Recovery and Maintenance Guide.
  • If you make networking configuration changes, including routing and gateway changes, client connectivity to the primary Admin Node and other grid nodes might be lost. Depending on the networking changes applied, you might need to re-establish these connections.

For more information on the StorageGRID Webscale network model and various ways to use it, review the Grid Primer.