About the Discover Components App

• Information Message 1: Verify the Connector is installed on the host.

• Information Message 2: The Connector’s snconnect_client_version.py store is pointing to discover_host.connect_host_name.

  Note: The IP address must be identical to the StorNext Connect system IP address.

• Information Message 3: Quantum recommends you contact Quantum Support.

• Error 1: Connector’s stats_health_check.py plugin returns non-valid configuration in stats_health.configurations (see Example of the Output From the HealthCheck Plugin).
• Error 2: The Connector’s snconnect_client_version.py plugin returns send_stats_as that does not match name server entered during the Discover process.
• Error 3: A service is not running in the stats_health.processes (see Example of the Output From the HealthCheck Plugin).
• Error 4: A problem is occurring with graphite. Quantum recommends you contact Quantum Support.

Below is an example of the output from the HealthCheck plugin.

{
    "stats_health": {
        "errors": [
            "Put general error messages here if necessary",
            "for example: mintd and snstatd configuration not matching",
            "The caller will decide how/if to combine/show the list of errors"
        ], 
        "processes": [
            { "name": "snstatd", "running": true },
            { "name": "mintd", "running": false}
        ],
        "configurations": [
            {"name": "snstatd.conf", "valid": true}
        ]
    }
}

Note: If you use the /etc/hosts file to update IP addresses, then you must perform the steps below to update the secondary node's docker-compose-host.yml file in StorNext 6.2. If you do update the file, then StorNext Connect does not correctly identify the private network entries.

Do the following to synchronize the entries from /etc/hosts to Connect docker in order for the Discover app to correctly identify the hostname entries.

1. Run one of the following commands to restart Docker:

   systemctl restart docker

   or

   /opt/quantum/connect/docker/quantum_connect.sh restart

2. Verify that the entries you added or edited in the /etc/hosts file are added to the /opt/quantum/connect/docker/docker-compose-hosts.yml file.

3. On each node, run the command:

   /opt/quantum/mintd/mintd_control.py set --hostname hostname.com
4. Rediscover your cluster using the StorNext Connect GUI.
5. Verify your Discover entries and the Performance apps.

Hosts are discovered (and shown in Discover Components) if:

• StorNext is installed on the host

  OR

• The Connector is installed on the host

For each name server, StorNext Connect runs the snprobe command to identify the hosts and their volume (file system), disk array, and licensing information. For each host, StorNext Connect discovers additional details, such as the operating system and StorNext version. This detailed discovery requires the Connector to be installed.

Make sure the same (and latest) version of the Connector is installed on the StorNext Connect system and all hosts in the environment to ensure proper operation.

During the snprobe discovery, StorNext Connect identifies a host by its metadata IP address. If the metadata IP address changes, Discover Components identifies it as a different host. If an IP address other than the metadata IP address for the host changes, StorNext Connect recognizes the change and continues to monitor and manage the host seamlessly after rediscovery.

Note: StorNext Windows clients and Apple Xsan clients require manual updating to continue to be monitored by StorNext Connect if IP addresses or hostnames change.

The StorNext name service provides a means for StorNext clients to discover the location (IP address) of the File System Manager (FSM) and other similar services. The FSM registers with the name server(s) and provides the IP addresses by which it can be reached. These addresses are then forwarded to clients.

Name servers (also called "coordinators") are defined in the fsnameservers file.

For additional information about StorNext name servers, see the fsnameservers man page in the StorNext 6 Man Pages Reference Guide and Name Servers in the StorNext Documentation Center.

Quantum does not recommend entering StorNext clients as a name server in the Discover Components application. However, StorNext Connect does not restrict this configuration. When adding name server values in the Discover Components application, only enter the values contained in the fsnameservers file on the StorNext MDC/Xcellis Workflow Director for the workspace (cluster) associated with that client.

When configuring a StorNext client, its fsnameservers file must include all of the same IP addresses included in the fsnameservers file on the MDC(s)/Workflow Director(s).

Note: It is important to make all the fsnameservers files identical for all StorNext MDCs and StorNext clients in the StorNext Connect workspace (cluster).

If a client mounts volumes (file systems) from two or more disjointed workspaces, the fsnameservers file for that client will not match the fsnameservers file used by the clients and MDCs in the StorNext Connect workspace. Configure and use all relevant MDC IP addresses to be used by the Discover Components application (primary and secondary nodes of dual-node systems). Failure to do so will cause any clients installed via StorNext Connect to only include the IP of the primary MDC in their fsnameservers file, and StorNext Connect may be unable to discover all components in the StorNext Connect workspace.

In Discover Components, a message similar to the following example is displayed at the bottom of the page.

The note indicates the shared volume (file system) is available only for use by the StorNext MDC/Workflow Director HA pair, and is not mountable by any StorNext client. In this example, shared-AV1442CKB00310 is the name of the HA shared volume. For appliances, this name is based on the serial number of the appliance. For customer-supplied HA systems with a shared volume, this could be a different identifier.

If a management capable Connector is installed on a host, discovery identifies all IP addresses for the host. For example, StorNext Connect recognizes if an MDC has both a public and private network IP address. Similarly, StorNext Connect recognizes a StorNext client by any of its IP addresses, whether metadata network, management network, NAS, or iSCSI.

When running the Discover Components application, it is possible for a StorNext MDC to be listed twice. This occurs when the client or MDC has both a public and private network IP address. If a host is listed twice, you will see both entries in the Manage Clients application as well. There are no issues with this; it is just a duplicate entry.

In the above example, the StorNext host named "sntestm660a.mdh.quantum.com" is shown once as an MDC and again as both a name server and an MDC.

During the detailed discovery of a host, StorNext Connect reads the /etc/fstab file to identify the volumes (file systems) that the host mounts. If you stop StorNext on the host, the Discover Components main page continues to list the volume even though the host is unable to mount the volume because StorNext is inactive.