Understanding I/O Flows in a Storage Network
Without considering I/O flows, a network is only aware of the frames in ingress and egress directions. Categorizing network traffic into I/O flows helps in correlating it with initiators, targets, and the logical unit number (LUN) for SCSI I/O operations and namespace ID (NSID) for NVMe I/O operations. In addition, storage performance can be monitored for every I/O flow individually to get detailed insights into the traffic. For example, when a switchport is 90% utilized, throughput per I/O flow can tell which initiator, target, and LUN/namespace are the top consumers.
I/O Flows in Fibre Channel Fabrics
The following can be the I/O flow types in a Fibre Channel fabric:
Port flow: Traffic belonging to all the I/O operations that pass through a network port makes a port flow. It can an SCSI port flow for SCSI traffic or an NVMe port flow for NVMe traffic.
VSAN flow: A port of a Cisco Fibre Channel switch may carry traffic in one or more VSANs. Hence, a port flow can be further categorized into one or more VSAN flows.
Initiator flow: Traffic belonging to all the I/O operations that are initiated by an initiator makes an initiator flow.
Target flow: Traffic belonging to all the I/O operations that are destined for a target makes a target flow.
Initiator-target (IT) flow: Traffic belonging to all the I/O operations between a pair of initiator and target makes an IT flow.
Initiator-target-LUN (ITL) flow: Traffic belonging to all the I/O operations between an initiator, a target, and a logical unit makes an ITL flow. An ITL flow is applicable only for SCSI I/O operations.
Initiator-target-namespace (ITN) flow: Traffic belonging to all the I/O operations between an initiator, a target, and a namespace makes an ITN flow. An ITN flow is applicable only for NVMe I/O operations.
Target-LUN (TL) flow: Traffic belonging to all the I/O operations that are destined for a target port and a specific logical unit makes a TL flow. A TL flow is applicable only for SCSI I/O operations.
Target-namespace (TN) flow: Traffic belonging to all the I/O operations that are destined to a target port and a specific namespace makes a TN flow. A TN flow is applicable only for NVMe I/O operations.
The definition of an I/O flow can also be extended to a virtual entity (VE), such as a virtual machine (VM) on the host. When combined with an ITL or ITN flow, the end-to-end flow becomes a VM-ITL flow or a VM-ITN flow. There are at least two approaches for achieving this visibility into the VMs.
The first approach needs support from hosts, and in some cases even from storage arrays, for tagging the VM identifier in the frame header. Although Cisco SAN Analytics on MDS switches supports VM-ITL and VM-ITN flows, because of the dependency on the end devices, most production deployments are not ready for it at the time of this writing.
The second approach uses the APIs from VMware vCenter to provide the correlation between the VM and the initiator and LUN (or namespace) from the ITL (or ITN) flow. The benefit of this approach, unlike the first approach, is that upgrading the end devices is not mandatory. Cisco SAN Insights uses this approach in NDFC 12.1.2 onward.
In environments where even the read-only access to VMware vCenter cannot be added to NDFC, this approach can still be used for manually correlating ITL or ITN flows with the VMs. The use of this approach is demonstrated further in the section “Case Study 3: An Energy Company That Eliminated Congestion Issues,” later in this chapter.
This chapter focuses only on ITL flows that are natively available on the Cisco MDS switches without any dependency on the end devices and NDFC. The environments with VM-ITL flows made available using either of the two approaches mentioned earlier can benefit by expanding ITL flows in the same way that port flows are expanded to IT flows and ITL flows.
To understand the I/O flows and how they help in gaining granular details about a network, consider the example in Figure 5-4. Two initiators, I-1 and I-2, connect to two targets, T-1, and T-2, via a fabric of Switch-1 and Switch-2. The ISL port on Switch-1 (Port-3) reports an ingress throughput of 800 MBps. After enabling SAN Analytics, Port-3 can categorize network traffic into multiple types of I/O flows and monitor the performance of every flow.
)
Figure 5-4 I/O Flows and Flow-Level Metrics Using Cisco SAN Analytics
SAN Analytics can find the following details:
The 800 MBps throughput on Port-3 on Switch-1 is because of SCSI read I/O operations.
Port-3 may have two VSANs: VSAN 100 and VSAN 200 (not shown in Figure 5-4). The VSAN flows provide a further breakdown of the port flow throughput, such as a read throughput of 600 MBps for VSAN 100 and a read throughput of 200 MBps for VSAN 200.
I-1’s read throughput via Port-3 is 300 MBps, whereas I-2’s read throughput via Port-3 is 500 MBps.
T-1’s read throughput via Port-3 is 250 MBps, whereas T-2’s read throughput via Port-3 is 550 MBps.
Port-3 has four IT flows: I1-T1, I1-T2, I2-T1, and I2-T2. The read throughput for each is as follows:
I1-T1: 100 MBps
I1-T2: 200 MBps
I2-T1: 150 MBps
I2-T2: 350 MBps
Port-3 has eight ITL flows. I-1 uses LUN-1 and LUN-2, whereas I-2 uses LUN-3 and LUN-4. The read throughput for each is as follows:
I1-T1-L1: 60 MBps
I1-T1-L2: 40 MBps
I1-T2-L1: 120 MBps
I1-T2-L2: 80 MBps
I2-T1-L3: 100 MBps
I2-T1-L4: 50 MBps
I2-T2-L3: 200 MBps
I2-T2-L4: 150 MBps
As is evident from this example, the hierarchical and relational definitions of I/O flows help create a precise breakdown of traffic on a switchport. During congestion, the per-flow metrics, such as throughput, help in pinpointing the root cause of the exact entity, such as initiator, target, LUN, or namespace. Without per-flow storage I/O performance monitoring, as provided by Cisco SAN Analytics, such detailed insights are not possible.
I/O Flows Versus I/O Operations
I/O flows shouldn’t be confused with I/O operations. An I/O flow is identified by end-to-end tuples such as initiator, target, LUN, or namespace (ITL or ITN flows). In contrast, I/O operations transfer data within an I/O flow. For example, when Initiator-1 initiates 100 read I/O operations per second to LUN-1 on Target-1, the ITL flow is identified as Initiator-1–Target-1–LUN-1, whereas there were 100 I/O operations per second.
An I/O flow is created only after an initial exchange of I/O operations between the identifying tuples. Later, if the initiator doesn’t read or write data, the I/O flows may still exist, but no I/O operations flow through it, which results in zero IOPS for these I/O flows.