Node Performance Test
A node is a controller in a cluster. You can group pairs of nodes together to form a scalable cluster. Creating a cluster enables the nodes to pool their resources and distribute work across the cluster, while presenting administrators with a single entity to manage. Clustering also enables continuous service to end users if individual nodes go offline.
A cluster can contain up to 24 nodes (unless the iSCSI or FC protocols are enabled, in which case the cluster can contain up to eight nodes). Each node in the cluster can view and manage the same volumes as any other node in the cluster. The total file-system namespace, which comprises all of the volumes and their resultant paths, spans the cluster.
When new nodes are added to a cluster, there is no need to update clients to point to the new nodes. The existence of the new nodes is transparent to the clients.
Periodically monitoring the state and I/O activity of each of the node in the NetApp Cluster enables you to rapidly detect I/O overloads and figure out the nodes that are inconsistent/offline. This is exactly where the Node Performance test helps!
This test auto-discovers the nodes on the NetApp Cluster, and periodically reports the following:
- What is the current state of the node?
- Which are the nodes that are busy processing I/O requests
- Is the I/O load activity uniform across all the nodes? Are any nodes overloaded with I/O read-write requests?
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 node configured 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. |
|
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. |
| Measurement | Description | Measurement Unit | Interpretation | ||||||
|---|---|---|---|---|---|---|---|---|---|
|
State |
Indicates the current state of this node. |
|
The values that this measure can report and their corresponding numeric values have been listed in the table below.
Note: By default, this measure reports the above-mentioned Measure Values while indicating the current state of this node. However, in the graph of this measure, states will be represented using the corresponding numeric equivalents i.e., 0 or 1. |
||||||
|
Total operations |
Indicates the rate at which all operations were performed on this node. |
Ops/Sec |
|
||||||
|
Write operations |
Indicates the rate at which the write operations were performed on this node. |
Ops/Sec |
A consistent decrease in the value of this measure could indicate a bottleneck when processing write requests. Compare the value of this measure across nodes to know which nodes are servicing write requests slowly. |
||||||
|
Read operations |
Indicates the rate at which the read operations were performed on this node. |
Ops/Sec |
A consistent decrease in the value of this measure could indicate a bottleneck when processing read requests. Compare the value of this measure across nodes to know which nodes service read requests slowly. |
||||||
|
HTTP operations |
Indicates the rate at which HTTP operations were performed on this node. |
Ops/Sec |
A consistent decrease in the value of this measure could indicate a bottleneck when processing HTTP requests. Compare the value of this measure across nodes to know which nodes service HTTP requests slowly. |
||||||
|
Disk data read |
Indicates the rate at which data was read from the disk of this node. |
MB/Sec |
Comparing the value of this measure across nodes will help you identify the node that is the slowest in terms of reading the data from the disk. |
||||||
|
Net data received |
Indicates the rate at which network data is received on this node. |
MB/Sec |
|
||||||
|
Net data sent |
Indicates the rate at which network data is sent through this node. |
MB/Sec |
|
||||||
|
Average system latency |
Indicates the average time taken by the system to perform operations through this node. |
Secs |
A high value for this measure is a cause of concern. |
