Monitoring and Maintining the CLARiiON

1 2003 EMC Corporation. All rights reserved. 11

Monitoring and Maintaining the CLARiiON


Topics

z Boot Sequence Monitoring LEDs HyperTerminal

z Navisphere Manager Fault Status Event Log Connectivity Status

z Event Monitorz ClarAlertz Utility Partitionz spcollect


CX600 Boot Sequence Monitoring

z Initial Power On Green LED = on Amber LED = off

z BIOS Test Green LED = on Amber LED = 0.25 Hz blink rate (once / 4 seconds)

z POST Test & Extended POST Test Green LED = on Amber LED = 1 Hz blink rate (once / 1 second)

z NT Boot and Driver Load Green LED = on Amber LED = 4 Hz blink rate (four times/ 1 second)

z Successful SP Boot Green LED = on Amber LED = off

Green LED

Amber LED

Monitoring the SP Boot SequenceThe two LEDs adjacent to the Ethernet port may be monitored during the Storage Processor boot sequence.At initial power-up, the green LED will be on and the amber LED will be off while the power supplies and the voltages on the SP stabilize.The first stage in the SP boot sequence is the BIOS test. The BIOS used on the Storage Processors is PhoenixBIOS 4.0 Release 6.0. This is indicated by the green LED on and the amber LED blinking at a rate of once every 4 seconds (.25 Hz).The second stage in the SP boot sequence is the SP POST (Power On Self-Test). This is indicated by the green LED on and the amber LED blinking at a rate of once a second (1 Hz). Extended POST checks every PROM checksum on the array.The third stage in the SP boot sequence is the NT boot and driver load. This is indicated by the green LED on and the amber LED blinking at the rate of 4 times a second (4 Hz).


SP A

Green LEDs

Amber LEDs

Visible through the Personality module bulkhead.Green LEDs = most significant byteAmber LEDs = least significant byte

Examples

= d2 = 41 01 48

CX600 Boot Sequence Monitoring (contd)

A bank of LEDs is mounted on the Storage Processor motherboard and visible through the bulkhead of the Storage Processor Personality card. This bank of LEDs is known as a Port 80h card and can be used to establish at what point the system failed and what routine was being performed. During BIOS & POST testing the LEDs will display the current POST task being executed. If a failure should occur during POST the LEDs will display the error code with the green LEDs as the most significant byte and the amber LEDs as the least significant byte with the LEDs read left-to-right. Reference the Error Code Appendix of the student CD for a list of the Phoenix POST codes.When the BIOS and POST testing completes successfully, Chameleon II Extended POST testing will occur. An error in the Extended POST testing will generate an Extended POST error code. These codes will consist of a sequence of three codes. They begin with the Extended POST identifier of 0x41. The following 2 codes will indicate the error code. Reference the TOME document on the distributed CD for a full listing of the Extended POST error codes.


CX200/400 Boot Monitoring

SPASPB

Storage Processor

Status Indicators

Storage Processor

Status Indicators

One area of difference is the ability to monitor the boot sequence. Due to design restrictions, the port80 card that was mounted on the CX600 storage processor is not available on the CX400. The Storage Processor Status LEDs mounted on the CX400 storage processor can still be used to monitor the boot cycle.If the amber LED on the bottom is blinking at the rate of once every four seconds, the storage processor is in the process of running the BIOS tests. When BIOS is completed and POST and Extended POST testing takes place the LED will blink at the rate of once every second. After the POST and Extended POST testing is completed and the storage processor is booting NT and drivers from the fibre drive, this LED will blink at the rate of four times a second.


2 2 3 1Converted to decimal

10 10 11 011 added to each doublet

01 01 10 00Grouped as doublets

0101 1000Binary representation

58Hex BIOS Code

Example

CX200/400 Beep (Blink) Codes

Certain BIOS errors will generate a blink code on the amber LED. These blink codes are similar to beep codes generated on PCs at boot time failures.When examining the Phoenix BIOS documentation, errors are listed in hex. For our example well use a code of 58 which would indicate a failure in the test for unexpected interrupts subroutine.To perform the conversion this hex number must be converted to binary.5 converts to 0101 and 8 converts to 1000Next the 8 bit binary number is divided into doublets. This gives us four doublets of 01, 01, 10, 00. Next, 1 is added to each doublet resulting in our four doublets of 10, 10, 11, 01.Finally, these binary values are converted to the blink sequence of 2 pause 2 pause 3 pause 1 long pause repeat.


CX Boot Sequence Monitoring

z Chameleon II Extended POST testing will send POST codes to the serial port for display on an attached monitor

z Requires HyperTerminal session from an attached hostz Displays sequence of characters while tests are running

HyperTerminal setup of 9600 baud, 8 data bits, no parity, 1 stop bit and no flow control.Each test or subtest will have a alpha character associated with it. At the start of the test, the respective character will be sent to the HyperTerminal session. If the extended POST test should stop before completion, the last letter printed will indicate which test has failed.


Status Icons in Navisphere 6.X

z Either the component or one or more if its components is in a transition state

z Either the component or one or more of its components has failed

z Storage system is inaccessible

z Storage system is unsupported


Navisphere 6.X Array in Transition

10

2003 EMC Corporation. All rights reserved. 1010

Navisphere 6.X Array Faulted

11


Navisphere 6.X Array Inaccessible

12


Navisphere 6.X SPS Charging

Notice:Array is Faulted whileSPS Transitional

13


Navisphere Event Viewer

EventsYou can view the events for a specific SP or for a monitoring host and the events of all hosts it is monitoring. These events include hard errors, startups, and shutdowns involving disks, fans, SPs, LCCs, power supplies, SPSs, and the BBU. The messages are ordered by the time the event occurred with the most recent messages at the beginning of the log. The event viewer has a filtering mechanism built in, so you can view all events or view a subset of the events. Date Date that the event occurred. Time Time that the event occurred. Event Code Numerical code that pertains to the particular event. Description Brief description of the event. Storage System Name of the storage system that generated the event. Displays N/A for non-device event types. Device Name of the device within the storage system on which the event occurred. Displays N/A for non-device event types. SP SP to which the event belongs - SP A or SP B. Host Name for the currently running Agent - SP Agent or Host Agent. Save Opens the standard Windows Save As dialog box. Use to save the contents of the Event Viewer dialog box to a text file. Clear Clears all the logs on the selected machine. Print Opens the standard Windows Print dialog box. Use to print the contents of the Event Viewer. Filter Opens the Event Filter dialog box. Use to customize the event viewer list by selecting specific events to view and monitor.

14


NaviCLI getlog command

z Useful for pulling full log file for off-line viewing:>navicli -h 192.168.2.164 getlog > spa-log.txt

15


Trapping events with Event Monitor

z Receive automatic notification in the event of array or component failures

Email Pager SNMP Other

z Configured Through Navisphere Manager, and run from a Windows Monitoring Station on the network

z One Monitoring Station can monitor multiple arrays, each with different filter settings.

16


Event Monitor Architecture

Monitoring Station

EthernetTCP/IP

Network

CX400

CX600 CX600

FC4500

Legacy Host

FC

The Agent running on the monitoring station needs to be able to reach the Agents on the monitored arrays (or hosts, for legacy systems) through the TCP/IP network

The Monitoring Station uses its local copy of Navisphere Host-based Agent to communicate with the Agents running on the monitored arrays. It also will communicate with Host-based agents connected to Legacy systems. These monitored Agents will send their most recent Event Logs to the Monitoring Station on a set interval. When a trigger Event hits the System, it will perform its designated action.

17


Setting up an Event Monitor Template

To create a Template for Monitoring, click on the Monitors tab in Navisphere. Right-click on the Templates folder icon, then click Configuration Wizard.

18


Setting up an Event Monitor Template (contd)

19



20



21



22


CLARalert Centralized Monitor Dial-Home

z CLARalert allows a failing array to dial home to EMC Support and automatically enter a case in the Clarify database

z This installation also gives EMC Support the ability to Dial-in to the workstation to remotely diagnose and repair issues.

z There are several steps in the installation.z For more information, consult the Procedure Generator.

23


CLARalert Install Modem

You must have this specific modem model

24


CLARalert Install EMCRemote

Install EMC Remote Service

25


CLARalert Configure EMC Remote

The EMCRemote Program has some key settings to configure:start the host whenever system startsautomatically minimize when waiting for a callCreate a password for the caller

26


CLARalert Configure Compatibility

Compatibility settings:DisplayShut off active desktopShut off transition effects, smoothed fonts, and 16bit iconsMouseShut off Pointer Shadows

27


CLARalert Import Template to Navisphere

From Navisphere Window, select Tools, Event Monitor, Import TemplateBrowse to the location of the Template on the CD.

28


CLARalert Change Template Properties

Change the settings of the Template to their appropriate values

29


Utility Partition

The Utility Partition Module will discuss identifying the uses of the Utility Partition on the CX family of arrays and identifying the pre-requisites for installation of the Utility Partition on the CX family of CLARiiON arrays.At the completion of this module the student will be able to:Identify the array modifications caused by installation of the Utility Partition.Identify the steps required to perform the Utility Partition NDU.Identify the steps required to perform a Utility Partition boot.Identify the steps required to copy Image files to a CX family array.Identify the steps required to install images on array

30


Utility Partition Basics The Utility Partition contains an NT image with portionsof Base code (excluding FLARE), plus additional utilities

Utility Front-End to provide a menu-driven user interface RAM Disk to act as a scratch pad FTP Server to provide network access to RAM Disk Image Repository to hold images persistently Write Filter to prevent unintentional modifications

Used to recover failed pairs of boot drives The Integrated Utility Partition will become the preferred method of recovery

for CX Family arrays Used to simplify the array conversion process

All CX Family Conversions after Release 11 is GA will be expected to use theIntegrated Utility Partition.

A new Conversion Kit will be created that includes a CD in place of the two Conversion Drives in the current kit.

An SP will boot normally unless Utility Partition Boot is selected via Extended POST

The utility partition when installed, contains a very limited NT image. Booting from the utility partition will not enable the storage processor with full functionality. It will, however, provide you with a menu driven interface that can be used to manage the image repository and re-image boot disks.The re-imaging process can be used to recover pairs of failed boot drives. In the past, this was accomplished via recovery disks provided from manufacturing. The recovery disks could be used only once and had to be returned to manufacturing to be recreated. This process was time-consuming and expensive. The preferred method with release 11 will be the utility partition.Another use for the utility partition will be upgrading the boot disks during a model upgrade in the CX family. Again, the utility partition reduces costs by eliminating the need for drives during the upgrade process.Booting to the utility partition requires interrupting the storage processors extended post testing through a hyper-terminal session.

31


Vault Drive Private Space Structure

Data Directory Boot Service (2MB/disk)

Flare Db (28.3MB/disk)Data Directory (2MB/disk)

SPANT Boot

Primary(2826.2MB)

SPBNT Boot

Primary (2826.2MB)

SPANT Boot

Secondary(2826.2MB)

SPBUtility Pr (200MB)

SPAUtility Pr (200MB)

SPBUtility Pr (200MB)

Reserve Area (100MB/disk)

NAS Core Dump Area (1GB)

0 1 2 3 4

6GB

Not in use

Not in use

Not in use

SPBNT Boot

Secondary(2826.2MB)

Vault Area (2176MB/disk)

PSM (1024MB/disk)

SPAUtility Pr (200MB)

FRU Signature (28.3MB/disk)External Db (35MB/disk)

Image Repository(1GB)

Data Directory Boot Service 2 MB All disks in array Fixed space for boot serviceData Directory 2 MB All disks in array - Each disk contains a data directory that maintains a map of the database entries for that diskFlare Database 28.3 MB All disks in array The traditional database is triple-mirrored on drives 0, 1 & 2. This area is used in other drives for FRU signature, clean/dirty flags, HW/FRU verify, etc. and a large reserved for future use areaExternal Database 35 MB drives 0, 1, & 2 Contains persistent information outside the purview of Flare such as: BIOS code image, PROM code image, Chameleon Kernel software, Chameleon volume manager, Chameleon filesystem database.NT Boot Partitions 2826.2 MB drives 0, 1, 2, & 3 - Each SP will have a mirrored NT boot partition. SPA will use drives 0 & 2, SPB will use drives 1 & 3.Reserved Space 300 MB Set aside for future NT growth.PSM 1024 MB drives 0, 1 & 2 Triple mirrored private LUN for storage of persistent SP data.Vault 2176 MB drives 0 through 4 RAID 4+1 area used for vaulting cache data in power fail emergencyCore Dump Partition 1 GB disk 4 reserved for Chameleon II NAS software core dumpsTotal private space drives 0 4 = 6393.5 MB

Arrays shipped with at least release 11 and Utility Partition installed include the following areas:SPA and SPB Utility Boot Partitions The SPA utility partitions are on SPBs boot drives and the SPB utility partitions are on SPAs boot drives. This will allow SPA to be booted to the utility partition on drives 1 and 3 in the event of failure of both drives 0 and 2. SPB has the same arrangement with drives 0 and 2 in the event both drives 1 and 3 fail.Image Repository A separate 1gigabyte partition has been created on previously unused space on drive 4 for the storage of raw image metafiles.

32


Utility Partition Front-EndThe Utility Partition has minimal hardware and software

requirementsSerial port, serial cable, and terminal emulator (any platform)Ethernet LAN port and hub (or crossover cable)FTP Client (any platform)

No additional service requirements Provides a menu based, task-oriented interface Provides an "Upgrade Wizard" to simplify CX Family Conversions

The user-interface provided when booting an sp into the utility partition is menu-driven and task-oriented. The connection is provided via a serial cable and a terminal emulator such as hyper-terminal. The menu options provide for enabling the LAN port to facilitate the download of raw image files through the FTP server running on the sp when booted to the utility partition.CX family model conversions are further simplified through the use of an upgrade wizard provided by the menus.

33


Booting to the Utility Partition Interrupt Extended POST during its diagnostics Enter the Extended POST Diagnostic Menu withDB_key

Enter the Image Sub-Menu Select Utility Partition Boot Wait ~ 30 seconds (without I/O) The Utility Front-End will perform its diagnostics Enter the Utility Toolkit menu

Booting to the utility partition requires starting a terminal emulation session and interrupting the extended post tests. This is accomplished by hitting the key during extended post. After hitting the key it will appear as though the terminal emulator has hung. The next step is to enter the diagnostic menu password of DB_key which is case sensitive and is echoed on the terminal.Select the item from the diagnostic menu and press , then select item from the Image Sub-Menu and press .The utility front-end will perform some diagnostics and will then present the Utility Toolkit Menu.All utility functions can be accessed from this and a series of sub-menus.

34


Booting Utility Partition: Password Entry

U_P_08.gif

Extended Post Tests

Open a HyperTerminal session on the storage processor serial port and boot the storage processor. When the SP starts running the extended post tests, identified by a stream of upper and lower case letters beginning with A, press the key on the keyboard to interrupt the tests.The system will report a failure and appear to hang.Enter the password (case-sensitive). DB_key and press on the keyboard.

35


Booting Utility Partition: Diagnostic Selection

U_P_10.gif

The number of entries on the diagnostic menu will depend upon the Storage Processor model being accessed. The menu displayed here is for the CX600, the CX400 and 200 will display less options. Select the from the diagnostic menu and press .

36


Selecting Utility Partition Boot

U_P_11.gif

Select from the menu and press to continue with the boot operation. When you start the boot operation you will leave the diagnostic system and be unable to return to this or previous menus without physically rebooting the Storage Processor.

37


Utility Partition Initialization: First Boot

U_P_12.gif

Each time the Utility Partition is booted, the image repository will be analyzed. On the first Utility Partition boot it will found that the repository is uninitialized and it will be initialized. This can take several minutes.

38


Utility Partition: Subsequent Boots

U_P_14.gif

On second and subsequent utility partition boots, the image repository will be found already initialized the tasks performed by the SP at this stage will happen quicker than the first boot.

39


Using the Utility Partition: Enabling the LAN Port The LAN port is enabled using the menu system Settings persist through the Image Repository Use the same IP addresses as your normal boot partitions

If you need to disable the LAN port, delete Network-A.cfg and/or Network-B.cfg from the Image Repository

When enabling the LAN port for FTP transfers the system will prompt for the ethernet addresses to be used. It is recommended that you use the same addresses as would normally be used for the storage processor were it in production. This should eliminate and address duplication.If there is a need to disable the LAN port it is simply accomplished by using the image repository menu to delete the appropriate configuration file.

40


Enabling LAN Port

U_P_15a.gif

Select from the Utility Toolkit Main Menu.

41


Enter LAN Settings

U_P_16.gif

Enter the LAN settings. It is best to use the addresses and subnet mask as would be assigned to the Storage Processor were it to boot from its standard boot partition. This will avoid any address conflicts that might otherwise occur.

42


Using the Utility Partition: The RAM Disk 381mB of scratch space Holds images to be installed Holds data that has been extracted Any files on the RAM Disk are lost on reboot

381 MB of the storage processors memory is set aside as a ramdisk. All image file activity will be routed through the ram disk. Because this is ram on the SP it is not persistent and its content will be lost during an SP reboot.

43


Using the Utility Partition: FTP Server Accessible after the LAN port has been enabled Provides network access to the RAM Disk Use any FTP client (but dont forget bin mode!)

Internet Explorer has a built in FTP clientMost operating systems include a command line ftp client

User/Pass: clariion/clariion! or clariion1992/clariion1992

Transferring the image metafiles, which run about 135 MB, would be extremely difficult and time consuming over the serial connection. For this reason, the utility toolkit will allow you to enable the LAN port on the SP and transfer the image metafile to the FTP server provided on the SP as part of its utility boot code.You may use the FTP client built into internet explorer which automatically performs the transfer in "Bin" mode or a command line FTP client but dont forget to set Bin mode.The FTP server on the SP uses the standard clariion service username/password pairs.

44


Image Metafile

U_P_17.gif

The next step in the process is to download the image metafile from an attached host to the storage processor via the Ethernet connection. The Utility Partition boot image contains an FTP server which is automatically started at boot time. The FTP file transfer can be initiated from the host in a number of ways. Internet Explorer contains an FTP client and automatically will transfer the file in Bin mode. Point the Internet Explorer at the FTP server using the IP address assigned earlier.You may also use a command line ftp client but remember to set Bin mode.The FTP server will request a username/password pair. The standard CLARiiON service pairs work, either a username of clariion with a password of clariion!, or a username of clariion1992 and a password of clariion1992.Click .

45


File Transferring to Ramdisk

U_P_18.gif

Once validated with the FTP server, the file transfer is a simple drag and drop operation using Internet Explorer.

46


File Transferred to Ramdisk

U_P_19.gif

The metafiles are on the order of 135 megabytes in size and the transfer will take a little time. After the transfer is complete, the file should show in the FTP window.Remember, this transfers the file to the Ramdisk and not to the image repository. Saving the file to the image repository for later use requires several additional steps.

47


Using the Utility Partition: Image Repository Persistent storage for the Utility Partition

1gB on Disk 4 Non-redundant (Lose disk 4, and you lose the Image Repository) Portable (Swap in disk 4 from another system and use its images)

Holds configuration data, wizard files, and images Files can be moved between the RAM Disk and the Image

Repository using the Image Repository Menu

Images may be added to the Repository by NDU packages

Primarily for CX Family Conversions

The image repository represents the persistent part of the utility partition. It is 1 Gigabyte of space set aside on disk 4. This space is not data protected by anything other than the error correction capabilities provided by the disk module itself. Loss of the disk means loss of the image repository. Disk 4 is portable though, if you should move this disk to slot four in another arrays first DAE, you may use the image metafiles stored on it. All file transfers are routed through the ramdisk to speed their execution.In addition to file transfers via the FTP mechanism, some NDU packages may also store images in the repository.The image repository was primarily designed to aid the CX family conversions but is also very useful for re-imaging failed or replaced boot disks.

48


Storing the Metafile

U_P_20a.gif

Select and press to store the metafile in the image repository.

49


Listing the Image Repository

U_P_21.gif

Before copying the file, you might want to check the current contents of the image repository. Select from the Utility Toolkit Image Repository Menu and press .

50


Disabling a LAN Port

U_P_22.gif

At present, the only thing saved in the image repository is the network configuration file for SPA. If for some reason you wanted to disable the LAN port you would simply select the appropriate entry on the previous menu and delete this file.

51


Copying Files from Ramdisk to Image Repository

U_P_23.gif

You are not required to save an image metafile to the repository but it might be a good idea, if you suspect you may need it again. Select from the menu and press .

52


Selecting Image Repository Files

U_P_24.gif

The system will list the files currently occupying the RAM Disk, there may be more than one. Select the numbers for the files you want to copy and press .

53


Copying files to Image Repository

U_P_25.gif

The system will update the operation dynamically. When all selected files have been copied to the repository, it will allow you to continue.

54


Verifying File Copy

U_P_26.gif

Another check of the contents of the repository reveals that the file just copied to it has been saved.

55


Using the Utility Partition: Installing Images

Images may be in the Image Repository or the RAM Disk

Images may be installed to SPA, SPB, or Both Imaging is data-in-place MIFs are preferred, but IIFs are still supported

All images are installed to the boot drives from the Ramdisk, and all image metafile transfers to the array via FTP are to the Ramdisk. Optionally, you may also save the image metafiles in the image repository. When installing the image files to the boot drive partitions you will be presented with the option of installing to SPA or SPB or both.Re-imaging will be performed on the boot disks with data-in-place, andSupport for the older style IIF files is provided but the preferred method is to use the new style MIF file format.

56


Starting the Disk Imaging Process

U_P_28.gif

Select and press to begin the disk imaging process.

57


Select Image to Install

U_P_29.gif

The system will display the images presently stored in the repository. Select the image to be installed and press .

58


Selecting a Target SP for Image Install

U_P_31.gif

The next information the system needs is the target for the reimaging. You may reimage the boot partitions on drives 0 and 2 by selecting 1, or the boot partitions on drives 1 and 3 by selecting 2, or all four drives by selecting option 3.If the SP selected for reimaging is presently active you will be prompted to disengage from the chassis before proceeding. WARNING!!Proceeding with a reimaging on an active storage processor may cause loss of customer data.

59


Summary

z Requires Release 11 exist on the arrayz A Menu-driven system for re-imaging Storage

Processor boot imagesz Creates a RAM Disk and a disk-based image repository

60


spcollect Introduction

z SP-based data collect scriptz Revision 5z Invoked from management station

The spcollect tool has existed since the introduction of the FC4700, the first of the K10 class of CLARiiON arrays. It is currently at revision level 5. Prior to Release 12, this tool was accessed via a SymmRemote connection to the Storage Processor. With Release 12, spcollect is now integrated with Navisphere CLI and is invoked from a management station.

61


spcollect Basic Operation

Produces a data zip file, filename format is:SPx_ChassisSerNum_SpSig_Date_Time_data.zip

Dump files not included C:\dumps folder on the SPRun spcollect on both Storage Processors

When the spcollect script is invoked it will create as an end result a zip file with a unique filename. This is achieved by using the Storage Processor, chassis serial number, Storage Processor signature, and a date and time stamp when formulating the filename.The zip file created by spcollect does not include and core dumps which may have occurred. If these are required they will have to be retrieve separately.The spcollect script executes on the Storage Processor addressed in a CLI command. The script is stored in the C:\dumps directory on the SP and its output will be stored in this directory. This directory may also hold additional files beyond the spcollect output and dump files.Because the spcollect script executes locally on the Storage Processor, it must be run on both SPs if data from both SPs is required and this is certainly recommended.

62


Running spcollect

Navicli is used to invoke spcollect with the following format:

navicli h {ip} spcollect {eng mode}

The command must be directed at the IP address of the SP and must include the engineering password of messner. The spcollect script can take up to 5 minutes to complete and provides no immediate response to the command.

63


Monitoring spcollect

After invoking the spcollect script, its progress can be monitored with the managefiles command using the following format.

navicli h {ip} managefiles list

While the script is running it will create 7 interim files. 6 of these files will follow the standard spcollect naming convention and a seventh file, SPx_collect_name_rev.txt, will also be created.

64


spcollect Completion

When the spcollect script completes, it will bundled the seven interim files into a single file for retrieval. It will be necessary to check the existence of this file before retrieval.

65


Transferring spcollect Data

Use the navicli managefiles command to get the spcollect data file with the following format:

navicli h {ip} managefiles retrieve file {filename}

This command will transfer the spcollect data file to the attached management station.

66


spcollect Data Location

The managefiles command will transfer the data file to the Navisphere CLI directory where the command was invoked.

67


spcollect Data Contents

The zipped data file, in tact, should be sent to engineering for analysis. This file will be unzipped and the component parts will be distributed to the relevant organizations upon receipt. The component files are:_evt.zip SP NT event logs_ktd.zip Ktrace dumps_nav.zip Navisphere information_psm.zip PSM information_rtp.zip Layered driver information_sus.zip Sustaining engineering information

68


spcollect Summary

Key Points covered in this module:z Spcollect execution and results

The spcollect script can now be executed via a Navisphere CLI command. It collects important information needed in the debug process performed by various engineering groups and stores this information in a zip file on the Storage Processor. The zip file must be retrieved from the Storage Processor via another Navisphere CLI command.

69


Summary

z We can monitor the Boot of a CX series using: LEDs HyperTerminal

z Navisphere Manager Fault Status Event Log Connectivity Status

z Event Monitorz ClarAlertz Utility Partitionz spcollect

Documents

Monitoring and Maintining the CLARiiON