Networking with a Purpose (#2) – HA To Save The Day
Mon, 26 Aug 2024 05:00:00 -0000
|Read Time: 0 minutes
Introduction
In part one of Networking with a Purpose, the basics of PowerStore front-end connectivity were discussed. This included port connectivity options for the various PowerStore appliance models as well as some basic best practices when designing the physical connections of a PowerStore appliance. While having cabling and switch redundancy is important, utilizing high availability features can help further protect against single points of failure and provide other benefits. In this blog, we’ll discuss the high availability features native to PowerStore.
PowerStore High Availability Features
The PowerStore Appliance
We cannot talk about the high availability of PowerStore without first talking about the appliance hardware. Each PowerStore appliance is specifically designed to be highly redundant and fault tolerant, safeguarding against unforeseen circumstances that could impact data access. To protect against component failures within the network or appliance, PowerStore leverages a dual-controller architecture, featuring an active/active controller configuration in which both nodes service I/O simultaneously. If an individual component fails, the storage system can remain online and continue to serve data. The system can also withstand multiple failures if they occur in separate component sets. Customers can have confidence that PowerStore has been designed to deliver 99.9999% availability.
Bonds, PowerStore Bonds
A bond in the PowerStore world is the combination of two or more ports into a virtual relationship. In PowerStore, all systems that include a four-port card have a default bond on the system. The default bond, named bond0, is created on ports 0 and 1 on the four-port card for both storage nodes. Bond0’s primary use is to have a redundant port configuration for the cluster’s storage and management operations. This is also the first choice for block, file, and replication IO. The bond can be active/active, with both bonded ports within a node actively handling IO, or active/passive, with the passive port only becoming active when the primary link goes down. This handling depends on whether Link Aggregation Control Protocol (LACP) is configured on the network switches. To ensure best resiliency and network performance, it is recommended to enable LACP on the network. Even if you’re not clustering the system with other appliances, this bond is created automatically and cannot be deleted. One other important thing to note, user-created bonds support iSCSI, replication, and file connectivity. If you are using NVMe/TCP, you must leverage bond0 or individual ports for connectivity.
Bonding also does not end here. Users can create bonds, called Link Aggregations in PowerStore Manger, further combining ports into a loving relationship. Two to four ports can be aggregated together to create a bond. The ports within the bond can be from the same IO module, or across IO modules to create higher redundancy across components, further safeguarding against single points of failure. When choosing ports to bond together, it is suggested to select ports with the same performance capabilities. As with the default bond, it is suggested to configure LACP on the switches for user-created bonded ports. If cabling bonded ports across switches, it is recommended to configure Virtual Link Trunking interconnect (VLTi) with LACP or equivalent technology on the switch to take advantage of the bond’s active/active capabilities.
The following example shows two of the many configurations that are supported with link aggregations. For simplicity reasons, only Node A connections are shown, but the configurations would be mirrored to the peer node. In this example, LA#1 has been created using two ports within the same IO module, which is then cabled across the two switches in this environment. For these ports to be active/active, LACP and VLTi or an equivalent technology must be configured on the switches. For LA#2, ports have been selected across different IO modules. This eliminates the single IO module in LA#1 from being a single point of failure.
Fail-Safe Networking
PowerStore also supports Fail-Safe Networking (FSN). FSN is only for file resources and is a redundancy feature that combines two ports together in an active/standby configuration. With FSNs, standby ports sit unused until a failure occurs, meaning the port is essentially not utilized most of the time, if ever. Whether or not the FSN requires a special switch configuration is dependent on how the FSN is created. FSNs are highly flexible, allowing the combination of two ports, two bonds (link aggregations), or a bond and an individual port. When creating an FSN across two individual ports, this type of configuration does not require any special switch or network configuration as failover is handled within the PowerStore appliance. A special switch configuration is only required when a bond is part of an FSN. Being only for file resources means the ports within an FSN are reserved for NAS server interfaces and do not allow block or replication connectivity.
In the following figure, two FSNs have been created, but other configurations are supported. FSN#1 is created across two ports on the same IO module and the ports are cabled to different switches. One port within FSN#1 is active, while the other port is the standby and protects against the active switch or port failing. Only if the active path fails does the standby path become active. However, in this example, if the IO module fails, then both links are down. For FSN#2, the fail-safe network is created across two LAs. LA#1 is entirely active, while LA#2 is standby. All paths within LA#1 must fail before the ports within LA#2 become active. Although not shown below, a user could also configure an LA as the primary path and a single port as the standby within and FSN.
So, Bonds? FSNs? Both? Neither?
You are probably asking yourself, why would I use bonds or an FSN instead of individual ports?
When configuring a system for file connectivity, the port selected for the NAS server must be a bond or FSN. This is a hard requirement. Creating a NAS server on an individual port is not supported. This means that all NAS servers created within the appliance must be assigned to the default bond, or a bond/FSN must be created somewhere else on the system. The bond selected can also be reserved for file connectivity, which might be done based on network requirements or for performance reasons. The bond could also be shared with block (iSCSI) and/or replication. If you want to leverage more ports than the default bond for file, then the configuration will include multiple bonds.
But what about block connectivity? For this conversation, let’s forget about bonds for a moment. With block, each individual PowerStore port requires an IP allocated for each network mapped to them. The IP is how the host talks to the port. Hosts would then connect to the ports using the IP addresses assigned, and host multipathing would be configured. If a failure occurs, the host multipathing software would help overcome issues and only use the paths that are still available.
With bonds, think of them as single logical ports per node. Ports that are bonded together on a node only require a single block IP address per network, which reduces the number of IPs that are required for the system. This is true whether there are two, three, or four ports bonded together. The IP is available on each port within the bond. To the host, the bonded port is seen as a single path with a single IP, which means there is less host configuration work required to connect to it when compared to multiple individual ports. This also builds in redundancy outside of the host. In the case of a failure within a bond, the IP remains accessible as long as there is still at least one good path within the bond on the node. If LACP is configured, the remaining active ports stay online servicing IO. If LACP is not configured on the switch ports for the bond, then the passive port becomes active and the IP remains accessible.
But what about FSNs? The main benefit of an FSN is that there is no special network configuration required. If the primary port fails, the secondary port becomes active and IO can continue, as long as the failure doesn’t impact the second port of course. The downside to an FSN is the reserving of a port as the standby, which may seem like a waste. It’s like having a spare tire, great for when you need it, but is just extra weight being carried around when you don’t. If the network switches do not support LACP, VLTi, or some equivalent technology, then an FSN helps provide redundancy and might be required to spread out the file environment.
So what do you choose?
Using my best shopping network host voice, But wait, there’s more! With all this talk about the physical connectivity and high availability features, we haven’t talked about PowerStore networks and their purposes. In PowerStoreOS 4.0, storage networks are more flexible than in previous releases, and the supported configurations unlock a new world of possibilities. Before going off and designing the system, cabling the system, or creating bonds, check out Networking with a Purpose (#3) – What’s My Purpose?, the next installment in this blog series.
Resources
- Networking with a Purpose (#1) – Let’s Get Physical
- Dell PowerStore: File Capabilities
- Dell PowerStore: Best Practices Guide
- Dell PowerStore: Introduction to the Platform
- PowerStore Networking Guide
- PowerStore InfoHub
- PowerStore Product Documentation and Videos
Author: Ryan Poulin, Principal Engineering Technologist