Sun Storage 3000 Arrays: How to Log Events to /var/adm/messages

Asset ID:	1-71-1001903.1
Update Date:	2016-10-02
Keywords:

Solution Type Technical Instruction Sure

Solution 1001903.1 : Sun Storage 3000 Arrays: How to Log Events to /var/adm/messages

Applies to:

Sun Storage 3511 SATA Array - Version Not Applicable and later
Sun Storage 3320 SCSI Array - Version Not Applicable and later
Sun Storage 3310 Array - Version Not Applicable and later
Sun Storage 3510 FC Array - Version Not Applicable and later
All Platforms

Goal

This document describes how to manually configure the remote logging functionality on Sun Storage 3310/3320/3510/3511 arrays to report array events in the host's /var/adm/messages file without using the ssconsole GUI via in-band management.

Solution

Customers should install the latest SUNWsscs sofware package, version 2.5, by referring to <Document 1004352.1> How to Download and Install Sun Storage Configuration Service Software (SUNWsscs). The software is compatible with all versions of 3310/3320/3510/3511 array controller firmware.

Below are the steps to configure remote logging using Sun Storage Configuration Service software (SUNWsscs) version 2.5.

1. The ssmon daemon is started by the script /etc/rc2.d/S81ssagent.

2. The ssmon daemon polls the /var/opt/SUNWsscs/ssagent/sscontlr.txt file repeatedly to check if it exists. If found, ssmon reads the file to discover raid-controller(s) to be monitored. The ssmon daemon is then able to print array events in /var/adm/messages. For example, an event logged for Sun Storage 3000 arrays in a host's /var/adm/messages file is shown below:

Dec 15 13:11:23 sanconfig SUNWscsdMonitor[389]: [ID 513617 daemon.error] [SUNWscsd 0x30B1D08: Informational] Controller Event, Controller Init Complete. Controller has been rebooted. Informational message. (Primary, Thu Jan 1 03:00:26 1970) {SN#123456}

3. To monitor an additional controller, there is no need to restart the ssmon daemon as the latter polls the sscontlr.txt file repeatedly.

4. Shown below is the content of an sscontlr.txt file.

By default the file does not exist. The following is the result of what the ssconsole (GUI) should create when requested to monitor the controller. It is used as a template for monitoring the configuration file. Any line starting with "#" is ignored by ssmon daemon.

# Any line starting with
# is ignored.
# Each entry is of the following form:
# RAID_CONTROLLER=::
# The first field is the key which must be RAID_CONTROLLER.
# The value of must be either Disable or Enable
# is the serial number of Primary controller in decimal integer.
# is the serial number of Secondary controller in decimal integer.
# If there are more than one entry for the same serial number of the
# controller, only the first one will be used.
# Typical entries:
#
# RAID_CONTROLLER=Enable:3132567:3132597
# RAID_CONTROLLER=Disable:3125305:3125707
#
# By default, controller is disabled. So, to disable a controller, it is not
# necessary to have an entry with "Disable" in the second field.
#

5. Add the RAID_CONTROLLER entry that corresponds to the array to be monitored.

Note: The template text above is not fully accurate. For each controller entry, the real syntax is "RAID_CONTROLLER=Disable:PrimarySN:SecondarySN:NodeName", where NodeName is a way to identify the whole array specifically using its Assigned Unique ID.

The array serial number and node name can be found using the below sccli commands:

sccli> show redundancy-mode
Primary controller serial number: 1234567 <-- PrimarySN
Redundancy mode: Active-Active
Redundancy status: Unknown
Secondary controller serial number: 7654321 <-- SecondarySN

sccli> show inquiry-data
Vendor: SUN Product: StorEdge 3510 Revision: 327R
Peripheral Device Type: 0x0 Page 80
Serial Number: 0015374XXXXXXA00
Page 83 Logical Unit Device ID: 600C0FF0000000000015374XXXXXXA00
Page 83 Target Device ID: 206000CXXXXXX537
IP Address: 129.157.218.148
Page D0 Target ID: 1
Page D0 Node Name: 206000CXXXXXX537 <-last 6 digits for sscontlr.txt entry
Page D0 Port Name: 216000CXXXXXX537
Page D0 Port Name: 216000CXXXXXX537
Device Type: Primary unique-identifier: 01537

Using the above output, the following entry can be added in sscontlr.txt file:

RAID_CONTROLLER=Enable:1234567:7654321:001537

Once the entry is added, the ssmon daemon will start to trap events reported by that array and report them via the host's syslog facility. By default, the Solaris Operating System logs all events in /var/adm/messages file. To redirect the events to a desired file, the /etc/syslog.conf file can be configured with filter: "local7.*" or "daemon.error". To configure the /etc/syslog.conf file, add the line daemon.error /var/adm/messages.daemon.

Note: In the /etc/syslog.conf file, the TAB is used as a separator but not SPACE.

6. Run the command "pkill -HUP syslogd" for syslogd to re-read the /etc/syslog.conf file.

Since syslogd can't specifically identify any particular daemon, the repercussion of this would be that errors from all other daemons (e.g. ftpd) in the system will also be logged in this file. User needs to identify the messages from SUNWscsd/ssagent.

7. The above will only work on servers with in-band connections to the arrays. The ssagent cannot scan for the manually provided controller serial numbers over IP, it can therefore only scan in-band connections. If out-of-band monitoring is required, the GUI software must be used to set it up. Trapping events via ssagent/ssmon over the network is also possible.

8. There is support to filter SSCS events by marking the error level. This means that the messages are marked as "daemon.error", "daemon.warning", "daemon.info" based on its severity.

Optionally, to filter informational or warning messages, the /etc/init.d/ssagent file need to be modified by adding a line after "_start)", which is shown below:

_start)

export SSCS_SUPPORT_MESSAGELEVELS=1

9. To make the configuration effective, the SSCS daemon should be restarted using the below scripts:

#/etc/init.d/ssagent stop
#/etc/init.d/ssagent start

Attachments

This solution has no attachment