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
 

• The most current recommended Solaris[TM] OS and Java[TM] runtime environment patches are installed on the host

• You are logged in as superuser

• Online help is not needed

These instructions were written using version 2.1 of SSCS.

Preparation

You can monitor the StorEdge array in-band (from a data host over data cable) or out-of-band (from any host over IP). Out-of-band monitoring is recommended over in-band.

If you monitor in-band:

• a lun 0 from the array must be visible on the monitoring (data) host before you can begin

If you monitor out-of-band:

• the network settings must be configured on the array
• the monitoring host must be able to telnet to the array
• it is preferable to setup monitoring before connecting any data paths

In either case, never have multiple hosts monitoring the same array as this may cause availability issues on the array.

Installation and Configuration

The following steps are carried out on the monitoring host.

1. pkgadd SUNWsscs (version 2.x works with array firmware 3.x and 4.x)
   • if you already have SSCS version 1.x installed, remove it first with
     pkgrm SUNWsccli SUNWscsa SUNWscsd SUNWscsu SUNWscui
2. as instructed by pkgadd (see below), enable and start the ssagent and ssdgrptd
   • Cutout instructions by pkgadd
     • The Sun StorEdge Configuration Service agent and Sun StorEdge Diagnostic Reporter daemon have been installed, but are not configured to start at boot time by default.
     • To enable the Sun StorEdge Configuration Service agent to start automatically when the system boots, and to start it now, type:
       /etc/init.d/ssagent enable start
     • To enable the Sun StorEdge Diagnostic Reporter to start automatically when the system boots, and to start it now, type:
       /etc/init.d/ssdgrptd enable start
3. provide passwords for the Unix users (ssmon, ssadmin and ssconfig) created during the installation of the above packages
4. launch the SSCS gui with /usr/sbin/ssconsole:
   • In the "Server List Setup" window, select "Add..."
     • enter the name of your monitoring host
     • get IP address by clicking on "Get IP Addr by name" or enter it manually
     • in the Monitoring Login section enter the ssmon password
     • apply with "ok"
     • select "no" for mail server setup; we won't use ssconsole for this
   • select "> Add >" to include your server in the Managed Servers and exit the window with "OK"
   • Wait for the "server discovery completed" message at the bottom of the window
   • For out-of-band only: select View -> Agent Options Management:
     • Provide the array IP Address and controller password (if any) then "Add" it
     • Select "Out-of-band Agent preferred over In-Band" and apply with "OK"
     • Quit any open telnet session to the array
     • Select View -> View Server and launch a "Probe"
   • From the "Array Administration" menu, select "Controller assignment":
     • Choose your monitoring host under "Server to manage this controller"
     • Apply and provide the ssadmin password as requested
   • Wait for SSCS to discover and display the device(s) under the server name
   • While you have ssconsole open, you may want to schedule weekly parity checks for RAID5 logical drives. This step is not relevant to monitoring, but it's good practice.
     • select a RAID5 logical drive from the device tree
     • from the "Array Administration" menu, select "Schedule parity check"
     • choose a quiet period. Only one time can be scheduled for all LDs
   • exit ssconsole. Don't worry about the warning; we'll use diagnostic reporter for monitoring, rather than ssconsole which would have to remain open
5. launch the diagnostic reporter GUI with /usr/sbin/ssdgrptui:
   • In the "Server List Configuration" window, select "Add"
     • enter the name of your monitoring host
     • get IP address by clicking on "Get IP Addr by name" or enter it manually
     • enter the ssconfig password under "Login information"
     • Apply and Close the window
   • From the "Servers" menu, select "Connect to DR Agent" -> "<your servername>". If you can't connect, see Troubleshooting (below) for how to start daemons
     • enter the name of your system in "System ID" and a "Location"
     • enter a customer "Name"
     • in the "Contact information" tab enter a "Name" and an "Email" address
     • under "SMTP information" enter a mail server and a "From" address. If no mailhost is defined, this can be set to "localhost". The "From" field should be something like "root@<your servername>"
   • In the "Trap Information" tab "Add" a new trap
     • From the "Content" drop down, select "Event"
     • de-select "XML"
     • select trap type "Event"
     • min interval: 0. This also determines the delay for reporting an event the first time
     • select all 3 event types (at least for testing)
     • enter a valid "mail to" address. You can test this at Unix command line with "mailx -v <address>"
     • "Save"
   • In the "SSCS Agent Information" tab, select "Add"
     • enter the name of your system under "Agent Name"
     • check the box "Server to send mail"
     • get IP address by clicking on "Get IP Addr by name" or enter it manually
     • enter the ssconfig password under "Login Information"
     • "Apply"
     • "Save Configuration". This will only succeed if you entered *all* the information above
     • "Probe SSCS Agent". It may take a minute or two to go from OFFLINE or DISCOVERING to ONLINE

You can close the diagnostic reporter configuration tool now because the daemon runs in the background, but you may want to keep it open until you've finished testing.

To test event reporting, you can, for example:

• turn off a power supply. Once it beeps and reports an error on the SE3000 console, turn it back on.
• create an NRAID logical drive on a single unused disk. If you don't have one, you can use a standby disk by doing a "delete global/local spare". Once the informational message appears on the SE3x1x console, remember to delete the NRAID logical drive and redefine the global/local spare. This is useful if you're not physically next to the array but proceed carefully if it's already in production.

Once you've determined that e-mail alerts are correctly delivered, you may want to remove "Informational events" from the Event Trap you defined to avoid drowning out the more important notifications.

Troubleshooting

• Make sure all the expected daemons are running: ssserver, ssmon, ssdgrptd
  • you can (re)start them using /etc/init.d/ssagent and /etc/init.d/ssdgrptd
  • run the scripts with "enable" once to ensure they autostart at boot
• Verify that events are appearing in /opt/SUNWsscs/ssdiagreporterd/eventlog.txt. If you're not seeing your events in here, check that:
  • correct passwords were entered as per above for ssmon, ssconfig, etc.
  • the trap min interval is "0", "*", or a small number of minutes
  • you selected the type of event you're testing for in the Active trap events
  • you successfully saved the diagnostic reporter configuration
• /opt/SUNWsscs/ssdiagreporterd/mailed.log is updated when events are e-mailed.
  • check the messages in this file if e-mail is failing
  • test e-mail to the desired recipient on the command line with "mailx -v <address>" (Ctrl-D to send)
• For in-band monitoring make sure that a lun 0 is mapped to each target visible to the data host. See Technical Instruction <Document: 1017707.1> for more info.
• Out-of-band setup and monitoring will fail if a telnet session to the array is already open. With newer firmware releases, only one network connection is allowed at a time.
• Out-of-band: check that the correct array password (or none if none set) is entered in Agent Options

This solution has no attachment