Networking with a Purpose (#3) – What’s My Purpose
Wed, 04 Sep 2024 22:00:04 -0000
|Read Time: 0 minutes
Introduction
In the previous installments of the Networking with a Purpose blog series, the basics of PowerStore connectivity and high availability features were covered. While these provide information on what’s possible for physical connectivity, and best practices for a redundant configuration, there is more to discuss before fully designing the connectivity of a PowerStore appliance. In this blog, we’ll cover the storage network purposes available within PowerStore along with the configurations they support.
While most storage purposes within PowerStore are nothing new, an enhancement within PowerStoreOS 4.0 provides greater flexibility to configurations that may have an impact on network design decisions. Before jumping to 4.0 and what’s possible, let’s rewind a bit.
PowerStoreOS 3.6.x
Let’s go back, but not too far back. To understand the change in 4.0, it’s best to describe how things worked previously.
Storage Networks for Block Connectivity
A storage network within PowerStore is the way to define the networking information for block storage connectivity. When creating a storage network, information such as the network name, netmask, storage network IPs, and MTU size are entered. Things like the network’s gateway and global storage discovery IP are optional. Before choosing which front-end port(s) to assign the storage network to, the user also had to define the network’s purpose.
By default, the storage network’s purpose includes both iSCSI and NVMe/TCP. A user can leave them both enabled, or customize them to specifically enable just the protocol they wish to use for the network. After defining the network information and the purpose, the network is then assigned to ports on the appliances within the cluster. As mentioned in the previous blog, the port could be an individual port or a link aggregation configuration. After assignment, hosts can then connect to the IPs assigned if the ports were cabled and online. With this workflow, a user can completely control what ports are used for what storage network. On the physical network side, the user has the control of cabling the ports to a dedicated network or one shared with other things like other storage networks, management, file, and replication. An example of the Create Storage Network wizard within PowerStoreOS 3.6 is shown below.
Replication
Before a replication session can be created, management and data connections to a remote PowerStore cluster must be created. Before the data connection can be established, a block storage network must be tagged for replication. In PowerStore Manager, this is done by selecting a physical port within an appliance and selecting which storage network that is assigned on the port should also be used for replication. This assigns replication traffic to the same port and network/VLAN configuration the storage network is using.
With this model, there are a few things to note. First, replication is tied to a storage network created for iSCSI and/or NVMe/TCP connectivity. If a user wants to separate replication traffic to a dedicated port/network, a storage network must still be created and tagged to a port before replication can be added as a usage. Second, PowerStore only allows a single storage network to handle replication traffic for all remote systems. For example, Cluster A to Cluster B replication would go over a particular replication tagged storage network. If Cluster A also replicates to Cluster C, the same network must be used, which means that all three sites need to have access to the same network. This also means that Cluster B can replicate to Cluster C. And lastly, ports tagged with replication are also used for migrations to PowerStore and remote backup integration with Storage Direct. If replication, data migrations, and PowerProtect integration is required, they must all occur on the same network.
PowerStoreOS 4.0
PowerStoreOS 4.0 has a number of enhancements that make configuring networks more flexible. Before getting to those, let’s talk about what has not changed. In this release, configuring the networking for file resources has not changed. Everything that was mentioned above still applies in 4.0, from configuring the network on the NAS server to choosing the LA or FSN.
So What’s New?
Storage Networks
In PowerStoreOS 4.0, a few things have changed for storage networks. As mentioned above, a storage network needs to be created for block connectivity. The storage network’s assigned purpose, either iSCSI, NVMe/TCP, or both, is assigned to the network and a port. This is what makes block connectivity possible. In 4.0, replication becomes a storage network purpose. Like with iSCSI and NVMe/TCP, now renamed to Storage (iSCSI) and Storage (NVMe/TCP), replication can be part of the purposes selected for a network being created.
This enhancement changes a few things for PowerStore. First, this removes replication as an add-on to a storage network on the Ports page in PowerStore Manager. A storage network that may or may not be used for block connectivity is no longer required. Second, this enhancement also means a storage network can be dedicated for replication. This allows dedicating front-end ports for replication without the requirement of having iSCSI and/or NVMe/TCP also available on the port. Thirdly, replication can now occur over multiple networks (more on this below). Based on what is selected for network purposes and port mapping, network addressing is completed later in the process. The figure below shows the Create Storage Network wizard and the storage Purposes that can be selected.
Another 4.0 enhancement is around assigning individual network purposes to ports within the appliance. In previous releases, the storage network and all network purposes for the network are assigned to an available port on the appliance together. In 4.0, a storage network can be assigned across multiple ports and individual purposes can be enabled for each port. This allows the complete customization of the usage of the front-end port configuration.
In the example below, the network being created has the Storage (iSCSI), Storage (NVMe/TCP), and Replication purposes enabled. When mapping the storage network to ports within the appliance, the ports and purposes can be customized. In this example, bond0 on the 4PortCard will be used for Storage (iSCSI) and Storage (NVMe/TCP) host connectivity. Replication has been enabled on FEPort3 on the 4PortCard. While the physical network may be the same, this configuration allows replication and host connectivity to exist on the same IP network but separates the network traffic across different physical connections.
The following picture shows multiple storage networks created within the cluster. Each of these networks are customized to their usage. The first network, named Storage_VLAN_1090, has the Storage (NVMe/TCP) and Storage (iSCSI) purposes enabled. Based on the purposes, this network will be strictly used for block host connectivity and may or may not be on a dedicated port/network. Replication_VLAN_1092 has Replication and Storage (iSCSI) enabled, while Replication_VLAN_1093 has only the Replication purpose enabled meaning it will only be used for communication between two PowerStore clusters.
Note: When using PowerStore’s import or native PowerProtect integration features, certain storage network configurations are required. Please consult product documentation and the best practices guide for more information.
Replication
As replication can now occur over multiple VLANs, more replication configurations are supported such as replicating over different ports and networks to different remote systems. To help manage these configurations the network groups feature has also been added in 4.0. This feature is used to manage the data connections between remote systems, allowing users to select the local and remote storage networks and pair them in a group for replication. This makes sure the correct networks are being utilized for replication traffic. When configuring the network groups, the local and remote storage networks do not need to be the same on both clusters. The only requirement is that connectivity can be established. The storage network VLANs could be the same or different if the network can route traffic between them.
But wait, there’s more! Another part of this new feature is the ability to create multiple Network Groups. One Network Group could include one storage network combination, while a second group can have another. Creating multiple network groups is typically done for redundancy. In the example below, Network Group 1 uses the 1092 VLAN while Network Group 2 uses the 1093 VLAN. When healthy, both networks are used for replication between the systems. If a failure occurs on a connection or a network group, the remaining paths will continue to replicate data.
Going back to the Cluster A, B, and C example from earlier in this blog, Cluster A and Cluster B can now use one storage network/VLAN for replication, while Cluster A and Cluster C can use another. They can exist on the same physical ports and network or be spread across different ports connecting to different physical networks. No longer are users stuck with using a single VLAN/network no matter how large the replication environment is and how many PowerStore clusters are involved.
File Connectivity
For file, PowerStoreOS 4.0 didn’t have networking changes like with block and replication connectivity. The network configuration for file resources still happens on each individual NAS server, and there is no file storage network like there is with block. When defining network information for a NAS server, the user needs to select a supported front-end port to assign the NAS server interface and select a VLAN that is not in common with any block storage network. As discussed in the previous blog, NAS servers can only be placed on a bonded (link aggregated) or Fail-Safe Network (FSN) port. This limits file traffic to only the default bond or a user-created bond or FSN. If a bond is selected, the NAS server can share the same port with block and replication traffic or other NAS servers if desired. As shown in the figure below, only PowerStore bonds and Fail-Safe Network ports are supported selections for a NAS server Network Interface.
So, what now?
Now it’s time to finish planning and start configuring PowerStore. After reading this blog series you should have all the information you need to be successful. In the first blog in this series, we covered the physical connectivity and recommended best practices for a redundant configuration. In the second blog we discussed PowerStore’s high availability features and where they are useful. In this blog we talked about the new storage network purpose handling, how to configure the purposes across front-end ports, and the new manage network groups feature for PowerStore replication.
If you think you still need some help, don’t worry, keep an eye out for the final blog in the series, Networking with a Purpose (#4) – Final Wrap Up.
Resources
- Networking with a Purpose (#1) – Let’s Get Physical
- Networking with a Purpose (#2) – HA To Save The Day
- PowerStore Networking Guide
- Dell PowerStore: Replication Technologies
- Dell PowerStore Protecting Your Data
- PowerStore InfoHub
- PowerStore Product Documentation and Videos
Author: Ryan Poulin, Principal Engineering Technologist