This chapter provides a brief overview of the performance analysis capabilities of the IBM Storwize storage system. It also describes a method that you can use to collect and process performance statistics.

However, it is beyond the scope of this book to provide an in-depth understanding of performance statistics, or explain how to interpret them. For a more comprehensive look at the performance of the IBM Storwize storage system, see IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines, SG24-7521.

For the IBM Storwize family, as with all other IBM storage subsystems, the official IBM tool for the collection of performance statistics, and to supply performance reporting is IBM Spectrum Control (formerly IBM Tivoli® Storage Productivity Center). For more information, see Chapter 8, “IBM Spectrum Virtualize and IBM Storwize performance monitoring” on page 157.

This chapter describes the following topics:

Jumbo frame is a term that is applied to an Ethernet frame that carries more than the standard 1500-byte data payload. The most commonly quoted size for a jumbo frame is
9000 bytes, which is large enough for 8 KB of application data plus some upper layer protocol capacity.

Jumbo frames can improve performance in two ways:

Jumbo frames require the end points and all devices between them in the network to be configured to accept the larger packet size if they are not configured for them by default, including any network switching equipment.

For information about how to set jumbo frames, see 10.4.7, “Problem determination: Checking for performance problems” on page 207.

Before you consider how virtual local area network (VLAN) separation contributes to enhancing the iSCSI performance, it is important to understand what a VLAN is and the advantages of implementing VLANs.

This section uses an example of a configuration that has iSCSI connectivity between ESX and an IBM Storwize storage system with the same subnet configuration.

For VLAN configuration guidelines for an iSCSI environment, see IBM Knowledge Center.

A VLAN can be described as a group of devices on one or more LANs that are configured to communicate as though they had the same physical connectivity, but actually might be on different LAN segments. It abstracts the idea of a LAN and might also comprise a subset of ports on a single switch or on multiple switches. VLANs help network administrators to partition the network to meet functional and security requirements. You can also refer VLANs as any broadcast domains, which are nothing but a partition of a network on the data link layer. Therefore, despite the geographical distribution of devices, you can have a logical group of workstations, servers, and network devices that are called a VLAN.

Here are some of the major advantages that can be obtained by implementing VLANs:

This section explains what a VLAN is and the major advantages it offers. 6.2.3, “VLAN and iSCSI performance” on page 75 explains how it enhances iSCSI performance.

Figure 6-1 shows iSCSI connectivity that uses a 10 GbE link between the ESX and IBM Storwize storage systems. The main challenge here is a traffic storm. Consider a scenario where massive read operations are made from ESX. A single NIC on ESX can see all four storage paths. Therefore, all the storage paths send the data back. This process creates excessive load on the switch and it becomes a bottleneck. The switch might start dropping packets.

Also, in such scenarios, latency issues certainly are reported because the maximum amount of Ethernet broadcast is being observed.

These issues must be solved by reducing the number of paths, to be specific, by segregating the paths and restricting access so that the resources on the switch are not exhausted and it can handle the traffic efficiently. One solution to these problems is VLAN implementation and the other is a configuration with multiple subnets, which is described in 6.3, “Subnetting” on page 76.

Figure 6-2 shows a VLAN split out on the switch, which restricts access by reducing the number of paths sending traffic on the switch. This reduction helps achieve effective usage of the switch and reduces the traffic, which reduces the latency and effective usage of network resources to end the traffic storm. All these factors eventually contribute to enhancing the iSCSI performance.

Subnetting is one of the solutions to overcome network bottlenecks and latency issues. This section explains what subnetting is, its advantages, and how it helps enhance iSCSI performance.

A division of an IP network is called a sub network or a subnet. The practice of dividing an IP network into further smaller networks is termed as subnetting.

There are differences in the implementation of VLAN and subnetting. However, the advantages of implementing either strategy are almost the same. The reason is that both the strategies are focused on breaking the large network into small networks, restricting access by creating administrative boundaries, configuring hosts and storages to use only the assigned network, preventing bombardment of heavy traffic in the network, and preventing network bottlenecks, packet drop, and latency issues. Both strategies help network administrators to manage efficiently the network. For a detailed description of the advantages, see 6.2.3, “VLAN and iSCSI performance” on page 75.

This section uses the same example that is used in 6.2, “VLAN separation” on page 74, where ESX is connected to an IBM Storwize V7000 storage system by using iSCSI (10 GbE).

Figure 6-3 shows the same subnet configuration, where only one switch connects the ESX with the IBM Storwize V7000 storage system. This configuration has the following challenges and impact on iSCSI performance:

Figure 6-3 shows a single subnet configuration.

Now, consider the modified configuration in Figure 6-4, where multiple subnets are configured.

The configuration in Figure 6-4 has a typical multipathing configuration, where there are two switches that are not connected to each other. This configuration helps reduce the number of paths. Now, four paths are visible because each vNIC is connected to one switch, which reduces traffic on each switch. The risk of a network bottleneck is mitigated and latency issues are addressed. Having two switches also prevents a single point of failure. To conclude, the network is properly managed, leading to a controlled environment that is more secure and optimized to improve iSCSI performance.

Certain Ethernet traffic can be prioritized relative to other traffic, specifically in 10 Gb enhanced Ethernet networks.

Priority Flow Control (PFC), as described in the IEEE 802.1Qbb standard, allows the network to control the flow of Ethernet traffic based on the class of traffic that is identified with its associated Priority Group. Network frames can be tagged with one of eight priority levels (described in the IEEE 802.1p priorities). Switches that are 802.1p compliant can give preferential treatment to priority values in terms of transmission scheduling. For example, priority can be assigned to iSCSI or Fibre Channel over Ethernet (FCoE) traffic to prioritize storage traffic if network congestion occurs.

Enhanced Transmission Selection (ETS): IEEE 802.1Qaz provides a mechanism to use 802.1p priority values to map traffic to defined bandwidth allocations on outbound switch links. Thus, iSCSI traffic can be given higher bandwidth allocation relative to other traffic. This higher allocation helps improve performance because in case the network gets saturated, the PFC pause mechanism pauses traffic with lower priority and prevents it from using bandwidth that is allocated to iSCSI storage traffic.

PFC and ETS must be configured on the Switch network to get guaranteed performance in a network congestion scenario. For more information about how to configure PFC and ETS, see 7.8, “Configuring Priority Flow Control for the IBM Storwize storage system” on page 148.

Digests can provide an extra measure of data integrity above TCP checksums. They might be useful if a WAN or known unreliable network is being used for iSCSI traffic. Most administrators prefer to run iSCSI over a network at least as reliable as a normal Network File System (NFS)/Common Internet File System protocol (CIFS)-level network, which they trust to deliver reliable file I/O requests and responses without any upper layer protocol checksums. If digests are enabled for the iSCSI protocol, the IBM Storwize iSCSI target must calculate and append checksum values to each outgoing packet, and calculate and verify values on each incoming packet.

There are two types of digests: header digests and data digests. Header digests performs checksums on only the 48-byte header of each iSCSI Protocol Data Units (PDU), and data digests perform checksums on the data segment that is attached to each PDU.

Enabling headers, data digest, or both is expected to have some impact on performance and CPU usage on the initiator and target systems because they require extra processing for calculation of checksums both for incoming and out going packets. For IBM Storwize storage systems, when performance measurements were done in the lab environment with header and data digests enabled, the IOPS workloads were virtually unaffected, and there was some drop seen in bandwidth usage. There was a marginal increase in CPU usage. Overall, enabling digests does not cause a significant decrease in performance.