Sun Storage 3510 FC Array
 
Sun Storage 3310 Array
 
Sun Storage 3511 SATA Array
 
Sun Storage 3320 SCSI Array
 

GCS>Sun Microsystems>Storage - Disk>Modular Disk - 3xxx Arrays
 

Applies to:

Goal

Solution

Steps to Follow:

NOTE:  It is imperative that customers install the latest 2.5 SUNWsscs
sofware from Oracle Software Downloads. The software will be compatible with
most versions of 3310/3320/3510/3511 Array Controller Firmware.

For SUNWsscs 2.5:

1. The ssmon daemon is started by the /etc/rc2.d/S81ssagent script.
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. ssmon is then able to print minnow
events in /var/adm/messages. For example :

  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#000056}

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

4. sscontlr.txt file content:

By default, this 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.

 # 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 it's "Assigned Unique ID".

Serial numbers and node name can be found using the sccli command line:

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

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

Finally, the following entry can be added:

 RAID_CONTROLLER=Enable:8005909:8006164:001537

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

Example: Add the following line in the /etc/syslog.conf file.

daemon.error /var/adm/messages.daemon
[The separator has to be tab, not space]

6. Run the following command for syslogd to re-read the syslog.conf file.

"pkill -HUP syslogd"

Caveat: 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 has no way of "knowing" it needs to 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 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 out informational/warning messages, you can modify /etc/init.d/ssagent,
by adding a line after "_start)", such as:

_start)

export SSCS_SUPPORT_MESSAGELEVELS=1

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

This solution has no attachment