FCP Port Performance Test
A Fibre Channel (FC) port is a hardware pathway into and out of a node that performs data communication over an FC link i.e., an FC Channel. The FC ports therefore are the primary handlers of I/O requests from the NetApp Cluster. I/O load on the ports directly translate into load on the volumes of the cluster. This is why, administrators need to continuously monitor the data and read/write latency on each port, so that overloaded ports can be quickly identified and the load-balancing algorithim fine-tuned accordingly. Moreover, since port-related errors can deny hosts access to the data stored in the NetApp Cluster, port monitoring is imperative to enable administrators to quickly detect such errors and fix them to ensure the normal functioning of the cluster. This can be achieved using the FCP Port Performance test! For each FC port on the NetApp Cluster, this test reports the rate at which data and I/O requests are handled and the number and nature of errors/failures encountered by each FC port. This way, administrators can be proactively alerted to potential port overloads and error conditions (with FC ports), and thus enabled to rapidly initiate remedial measures to avoid an impending system slowdown.
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 FC port on the NetApp Cluster being monitored.
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. |
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. |
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Other latency |
Indicates the average time taken to perform operations other than read and write through this port. |
Secs |
|
Other operations |
Indicates the rate at which operations other than read and write are performed through this port. |
Ops/Sec |
|
Read operations |
Indicates the rate at which data/block is read through this port. |
Ops/Sec |
Very high values for these measures are indicative of the existence of road-blocks to rapid reading/writing by the storage device through the port. By observing the variations in these measures over time, you can understand whether the latencies are sporadic or consistent on the port. Consistent delays in reading/writing could indicate that there are persistent bottlenecks (if any) in the port which helps you identify the over-utilized ports.
|
Read latency |
Indicates the average time to read a block/data through this port upon a user request. |
Secs |
|
Write operations |
Indicates the rate at which data/block is written through this port. |
Ops/Sec |
|
Write latency |
Indicates the average time taken to write a block/data using this port upon a user request. |
Secs |
|
Authentication failures |
Indicates the number of times authentication failure occurred on this port during the last measurement period. |
Number |
|
Link down |
Indicates the number of times the Fiber Channel link was lost during the last measurement period. |
Number |
|
Loop failures at receiver |
Indicates the number of loop failures detected at the receiver of this FC port during the last measurement period. |
|
Loop Initialization is an essential process for allowing new devices onto the loop, assigning Aribrated Loop Physical Addresses (AL_PAs), providing notification of topology changes, and recovering from loop failure. Following loop initilaization, the loop enters a stable monitoring mode and resumes normal activity. Depending on the number of normal ports (NL_Ports) attached to the loop, an entire loop initialization may take a few milliseconds. A loop initialization can be triggered by a number of causes, the most common being the introduction of a new device. The new device could actually be a former device that has been powered on, or an active device that has been moved from one hub port to another. A number of ordered sets have been defined to cover the various conditions that an NL_port may sense as it launches the initialization process. These ordered sets, called loop initialization primitive sequences, are referred to collectively as LIPs. An NL_Port issues atleast 12 LIPs to start loop initialization. During loop initialization, each downstream device that are part of the loop receives the LIP stream and enters a state known as Open-init, which suspends any current operations and prepares the device for the loop initialization procedure. The LIPs are forwarded along the loop until all NL_ports, including the originator of the loop, are in Open-init state. At this point, a temporary loop master is selected for conducting the rest of the initialization procedure. The first task of the temporary loop master is to issue a series of four frames that will allow each device on the loop to select a unique AL_PA. A LIP reset is used to perform a vendor specific reset at the loop port specified by this AL-PA value. These LIP resets are used to temporarily cure connectivity issues. Prolonged resets should be noted and the underlying actual connectivity issues should be resolved. |
Loop initialization error |
Indicates the number of loop initialization errors that occurred on this FC port during the last measurement period. |
Number |
Ideally, the value of this measure should be zero. |
Loss of signal |
Indicates the number of times the signal was lost on this FC port during the last measurement period. |
Number |
Ideally, the value of this measure should be zero. A non-zero value for this measure indicates that the port detected a loss of the electrical or optical signal used to transfer data on the port. This is likely an indicator for a faulty connector or cable. These are also caused when the device connected to the port is restarted, replaced or being serviced when the Fibre Channel cable connected to the port is temporarily disconnected. If the port is in the “loss of signal” state for longer than a specific period, the port will get into the link failure state which could degrade the performance of the Fibre Channel link. |
Loss of sync |
Indicates the number of times this FC port failed to synchronize during the last measurement period. |
Number |
Ideally, the value of this measure should be zero. A non-zero value for this measure indicates that port went into the “loss of synchronization” state, where it encountered continuous Disparity errors. This is likely an indicator for a faulty connector or cable. These are also caused when the device connected to the port is restarted, replaced or being serviced when the Fibre Channel cable connected to the port is temporarily disconnected. If the port is in the “loss of synchronization” state for longer than a specific period, the port will get into the link failure state which could degrade the performance of the Fibre Channel link. |
Primitive sequence error |
Indicates the number of Primitive Sequence protocol errors that occurred on this FC port during the last measurement period. |
Number |
Ideally, the value of this measure should be zero. |
Spurious interrupts |
Indicates the number of spurious signals received by this FC port during the last measurement period. |
Number |
|
Virtual link down |
Indicates the number of times the virtual Fiber channel link was lost on this FC port during the last measurement period. |
Number |
Ideally, the value of this measure should be zero. A non-zero value for this measure indicates that the port detected a loss of the electrical or optical signal used to transfer data on the port. |