ISCSI Performance Test

The iSCSI protocol is a licensed service on the storage system that enables you to transfer block data to hosts using the SCSI protocol over TCP/IP. The iSCSI protocol standard is defined by RFC 3720. In an iSCSI network, storage systems are targets that have storage target devices, which are referred to as LUNs (logical units). A host with an iSCSI host bus adapter (HBA), or running iSCSI initiator software, uses the iSCSI protocol to access LUNs on a storage system. The iSCSI protocol is implemented over the storage system’s standard gigabit Ethernet interfaces using a software driver. The connection between the initiator and target uses a standard TCP/IP network. No special network configuration is needed to support iSCSI traffic. The network can be a dedicated TCP/IP network, or it can be your regular public network. The storage system listens for iSCSI connections on TCP port 3260.

This test monitors the active and attempted iSCSI sessions on each VServer hosting the iSCSI service on the NetApp Cluster, and promptly captures the processing ability, login failures, failed tasks, and errors encountered by these sessions.

Target of the test : A NetApp Cluster

Agent deploying the test : An external/remote agent

Outputs of the test : One set of results for each Vserver hosting the iSCSI service on the NetApp Cluster being monitored.

Configurable parameters for the test
Parameters	Description
Test Period	How often should the test be executed.
Host	The IP address of the storage controller cluster.
Port	Specify the port at which the specified host listens in the Port text box. By default, this is NULL.
User	Here, specify the name of the user who possesses the readonly role. If such a user does not pre-exist, then, you can create a special user for this purpose using the steps detailed in Creating a New User with the Role Required for Monitoring the NetApp Cluster.
Password	Specify the password that corresponds to the above-mentioned User.
Confirm Password	Confirm the Password by retyping it here.
Authentication Mechanism	In order to collect metrics from the NetApp Cluster, the eG agent connects to the ONTAP management APIs over HTTP or HTTPS. By default, this connection is authenticated using the LOGIN_PASSWORD authentication mechanism. This is why, LOGIN_PASSWORD is displayed as the default Authentication Mechanism.
Use SSL	Set the Use SSL flag to Yes, if SSL (Secured Socket Layer) is to be used to connect to the NetApp Unified Storage System, and No if it is not.
API Report	By default, in most environments, NetApp Cluster listens on port 80 (if not SSL-enabled) or on port 443 (if SSL-enabled) only. This implies that while monitoring the NetApp Cluster, the eG agent, by default, connects to port 80 or 443, depending upon the SSL-enabled status of the NetApp Cluster - i.e., if the NetApp Cluster is not SSL-enabled (i.e., if the Use SSL flag above is set to No), then the eG agent connects to the NetApp Cluster using port 80 by default, and if the NetApp Cluster is SSL-enabled (i.e., if the Use SSL flag is set to Yes), then the agent-NetApp Cluster communication occurs via port 443 by default. Accordingly, the API Port parameter is set to default by default. In some environments however, the default ports 80 or 443 might not apply. In such a case, against the API Port parameter, you can specify the exact port at which the NetApp Cluster in your environment listens, so that the eG agent communicates with that port for collecting metrics from the NetApp Cluster.
Exclude Aggregates	If you wish to exclude certain aggregates from the scope of monitoring, specify a list of comma-separated aggregates in this text box. By default, none will be displayed here.
Records Per Call	The eG agent by default, executes the API commands in order to query the aggregates in the target environment. In critical infrastructures spanning large number of aggregates, a single execution by the eG agent may query(or download) a sizeable amount of monitoring data, thereby adding to the cluster load. To avoid this, you can tweak the Records Per Call parameter to enable the eG agent to obtain monitoring data iteratively in chunks instead of retrieving the entire amount of monitoring data in a single go. Say for example, the eG agent is required to query 1000 aggregates, then specifying the value 100 in this text box will enable the eG agent to query 100 aggregates at a time for 10 times to obtain monitoring data from all the aggregates. By default, the value of this parameter is 10.
Timeout	Specify the duration (in seconds) beyond which the test will timeout if no response is received from the device. The default is 120 seconds.

Measurements made by the test
Measurement	Description	Measurement Unit	Interpretation
Command descriptor blocks processed	Indicates the rate at which the Command Descriptor Blocks were processed by the inititator.	Blocks/Sec	The SCSI Command Descriptor Block (CDB) is a block of information that describes the command. Commands are sent from SCSI Initiators, which are contained in host computers, to SCSI Targets, which are controllers of some type of storage device (hard disk, tape drive, etc.). Almost every CDB contains 3 parts: a “What” field, a “Where” field, and a “How Much” field. For some commands, these fields are implied or not required. The “What” field is called the Operation Code (or OpCode) and tells the target what the command is supposed to do. A couple of examples would be READ or WRITE. The READ command moves data from the storage device to the host system, while the WRITE command moves data to the storage device for later access. The “Where” field tells the target where to begin the operation and is expressed as a Logical Block Address, or LBA. This address ranges from zero (0) to the maximum address of the device. Some commands, such as INQUIRY, do not require this field. The “How Much” field tells the target how many blocks (or bytes) or data to move. The block size of most storage devices is 512 bytes, but in certain storage devices, the block size can be different. This field is expressed as either Transfer Length (in blocks), Allocation Length (bytes moving to the host), or Parameter List Length (bytes moving to the device). Which name is used depends on the command itself. CDBs come in various sizes, typically 6, 10, 12, or 16 bytes total. Below is a figure of a 10-byte READ command to be sent to a hard drive. This command, if successful, will move one block (512 bytes) of data to the host computer system, from logical block address 100h (hex). All other bits or fields that are not labeled are set to zero. This measure is a good indicator for analyzing the traffic/load in this cluster.
Successfully processed command descriptor blocks	Indicates the rate at which the Command Descriptor Blocks were successfully executed by the initiator.	Blocks/Sec	A high value is desired for this measure. A low value indicates that there were too many unsuccessful CDB executions, which may have caused a processing bottleneck.
Command descriptor blocks with errors	Indicates the rate at which the Command Descriptor Blocks were processed by the initiators with errors.	Errors/Sec	Ideally, the value of this measure should be 0. A high value indicates that there were too many errors that occurred while processing the CDBs which may affect the performance of the storage system. Some of the common errors that occur while the CDBs are processed include the medium/hardware errors, providing illegal parameters for the CDB, accessing unauthorized data, volume overflow etc.
Total errors	Indicates the rate at which the iSCSI errors occurred.	Errors/Sec	Ideally, the value of this measure should be 0. Some of the common iSCSI errors that occur are digest errors, login/logout errors, PDU errors etc.
Failed logins	Indicates the rate at which failed login attempts were made by the initiator while creating new iSCSI sessions.	Logins/Sec	Ideally, the value of this measure should be 0.
Failed logouts	Indicates the rate at which logouts failed while attempting to gracefully end the iSCSI sessions.	Logouts/Sec	Ideally, the value of this measure should be 0.
Failed tasks	Indicates the rate at which iSCSI tasks failed.	Tasks/Sec
Protocol errors	Indicates the rate at which protocol errors occurred.	Errors/Sec	Ideally, the value of this measure should be 0. Protocol errors mainly occur due to the violation of protocol rules. The protocol errors occur in scenarios like violation of iSCSI PDU exchange sequences, duplication of protocol steps, invalid format/entries in protocol messages etc.
Login requests	Indicates the rate at which login requests were made.	Requests/Sec	This measure is an actual indicator of the users who are attempting to login to the storage system. Compare this value with the Failed logins measure to find out how well the user requests are processed in this storage system.
Logout requests	Indicates the rate at which the logout requests were made.	Requests/Sec	This measure is an actual indicator of the users who are attempting to logout of the storage system. Compare this value with the Failed logouts measure to find out how well the user requests are processed in this storage system.
Protocol Data Units rejected	Indicates the rate at which Protocol Data Units were rejected by the initiator.	Units/Sec	In a layered system such as iSCSI, a unit of data which is specified in a protocol of a given layer and which consists of protocol-control information and possibly user data of that layer is termed as a Protocol Data Unit. Ideally, the value of this measure should be 0. The Protocol Data Units are rejected due to iSCSI error conditions such as protocol errors, unsupported option etc., which may lead to connection/data loss, performance/processing bottleneck on the storage system etc.