Any standard SNMP query tool and monitoring system can be used to interact with Swarm. The examples in this section use the open source Net-SNMP (formerly UCD-SNMP) package available for UNIX and Microsoft Windows platforms. Install the Swarm MIB definition file before using most tools and monitoring packages. Follow the instructions included with the tool or package for more information.

Open Source Tools

The following tools can be useful to monitor and manage Swarm. DataCore does not endorse the applicability nor the fitness of these products when used within any environment.

• Net-SNMP (net-snmp.sourceforge.net). Provides command-line tools for UNIX and Windows environments to send and receive SNMP requests.

• Nagios (nagios.org). Provides web-based monitoring system for UNIX environments for monitoring systems and sending alerts through email and pager.

• Zenoss (zenoss.com). An SNMP-based system for IT monitoring and management.

SNMP Examples with Swarm

Complete the following to prepare to use the examples in this section:

1. Record the IP address of a storage cluster node. Record the SCSP Proxy if the cluster is not in the subnet.
   The node's IP address is 172.16.0.32 in the examples below.

2. Run the command from the directory containing CARINGO-CASTOR-MIB.txt.
   Copy CARINGO-CASTOR-MIB.txt from the root directory of the USB flash drive or distribution to a local directory.

3. Record the following passwords:

   • read-only-password. The password for the read-only user defined in the security.operators setting. Default: public

   • read-write-password. The password for the read-write user defined in the security.administrators setting. Default: ourpwdofchoicehere

See Defining Swarm Admins, Swarm Users, and Swarm Passwords.

SNMP walk (snmpwalk) of all Swarm values on a node:

Request for a specific SNMP variable from a Swarm node:

Set request to shut down a Swarm node:

Set request to change the cluster's sleepAfter setting to 7260 seconds (121 minutes):

SNMP Action OIDs

The "action" OIDs in Swarm are the SNMP objects affecting the operation of a node or the cluster.

Practical SNMP with Swarm

This section outlines practical approaches in using the built-in SNMP agent to monitor the health and operational aspects of a storage cluster.

Health Monitoring

The following variables can be used to monitor the basic health of a Swarm node. The volume table has n from 1 to the number of volumes.

• caringo.castor.castorState. Equal "OK."

• caringo.castor.castorVolTable.volEntry.volState.n. Equal "OK."

• caringo.castor.castorVolTable.volEntry.volErrors.n. Equal to zero.

There is something wrong with the node if the monitoring console receives timeouts when trying to read these variables. The node or the disks are transitioning from the normal state if the state values are anything other than "ok”.

Any non-zero value in the volume error count indicates a hard error has surfaced from the hardware through the OS driver and to the Swarm process.

Capacity Monitoring

The following variables can be monitored and collected for capacity alerting and reporting. The volume table has n from 1 to the number of volumes.

• caringo.castor.castorFreeSlots. Greater than zero.

• caringo.castor.castorVolTable.volEntry.volMaxMbytes.n

• caringo.castor.castorVolTable.volEntry.volFreeMbytes.n

• caringo.castor.castorVolTable.volEntry.volTrappedMbytes.n

The castorFreeSlots variable indicates how many more objects a node can hold before it exhausts the memory index. The node is unable to store additional objects until objects are deleted or moved to other cluster nodes (or more RAM is added to the node) if this occurs. The free slots indicate how much RAM is required per object.

See the Hardware Requirements for Storage for RAM effects on node storage.

Add the values volFreeMbytes and volTrappedMbytes to compute the amount of disk space available for writing content.

Client Activity Reporting

Collect and report the amount of client activity received by the nodes to understand the end-user usage patterns and identify nodes receiving significantly more activity than others. The resulting value can indicate a poor primary access node selection mechanism in the client application code.

The following SNMP variables indicate client request activity on a Swarm node.

• caringo.castor.scsp.writes

• caringo.castor.scsp.reads

• caringo.castor.scsp.infos

• caringo.castor.scsp.deletes

• caringo.castor.scsp.errors

• caringo.castor.scsp.updates

• caringo.castor.scsp.copies

• caringo.castor.scsp.appends

SNMP Repository Dump

The SNMP Repository Dump page provides additional node-specific information.

Open

Accessing the Repository Dump

Access the SNMP Repository Dump page for a cluster node:

1. Open the legacy Admin Console.

2. In the Node IP column, click the IP address of the target node.

3. Scroll down and maximize Node Info.

4. Scroll down and click SNMP Repository.

See the SNMP MIB Reference file included in the Swarm download bundle for more on the SNMP Repository Dump tables.

Disk Monitoring

Swarm 12 collects more health data from the SMART values reported by storage disks, can be accessed via the SNMP Drive table. (v12.0)

• driveStatus is now correctly computed.

• drivePowerOnHours is from SMART attribute 9.

• driveTempC is from SMART attribute 194.

• driveCompromisedCount is the sum of SMART attributes 5, 187, 188, 197, and 198. A non-zero value may indicate an impending disk failure.

Discontinued Items

Note these SNMP items are no longer populated (v9.4):

• planarTemp

• tempStatus

• fanRedundancy

• psuRedundancy

• instantaneousWatts

• instantaneousMA

• minPowerCap

• maxPowerCap

• nics

• nicTable (including detail)

• nicFwVsn

• driveTable.driveStatus

• fans

• fanTable (including detail)

• psus

• psuTable (including detail)

• powerIntervals

• powerDrawTable (including detail)

Those SNMP values can be re-populated with a configuration change if relying on them. Contact DataCore Support for instructions.