Home » Lacie Manuals » Computer Software » Lacie 131018 » Manual Viewer

Lacie 131018 User Manual - Page 41

Syslog

UPC - 093053789114

Add to My Manuals
Save this manual to your list of manuals

Page 41 highlights

Getting Started 4.5 SYSLOG StorView's SYSLOG agent is a module designed for StorView that enables sending RAID system event logs to all listening SYSLOG clients on all installed platforms. SYSLOG requires that the Global Access license be enabled before the feature is activated. Once activated on each installation of StorView, the locally monitored storage system events are then sent to the SYSLOG daemon running on the host system. StorView SYSLOG is designed for greater flexibility in that it supports "many-to-many" mapping. You may have: • Multiple SYSLOG servers that monitor a single RAID storage system for event logs. • A single SYSLOG server that monitors multiple RAID storage systems for event logs. • Multiple SYSLOG servers that monitor multiple RAID storage systems for event logs. This "many-to-many" mapping provides an additional safety net in that it offers data redundancy. In this instance a failed SYSLOG server will not have any impact if another SYSLOG server is functioning normally. If you are using a Linux operating system, the syslogd daemon is a component of your operating system. If you are using a Windows operating system you will need to install a separate tool (http://syslogwin32.sourceforge.net/) which runs as a Windows service. 4.5.1 Gathering Logs A host based StorView running the SYSLOG agent with two in-band connections to RAID storage systems, each with a unique WWN ID. Assuming the SYSLOG is configured to log/dispatch Error type events, It will gather all Error type events for both RAID storage systems and sent them directly to the intended host. The StorView SYSLOG agent is global in scope, in that it will always receive all error logs from the accessible storage systems. It is not possible to customize filtering of events for each managed storage system for that host. With Embedded StorView, previously configured listening SYSLOG servers will persist even though the embedded module is flashed with new software as the file data is stored in NVRAM and is not affected by software upgrades. However, with instances of installed host-based StorView, you must backup or make a copy of the syslog.ini file otherwise software updates will destroy the configuration information. 4.5.2 SYSLOG Daemon The daemon listens for incoming event log messages on port 514. It logs them to a messages file. The SYSLOG messages consist of: • Facility - indicates the type of syslog message. For example they can be kernel, user level, mail system and system daemon messages. • Priority - indicates the sensitivity of the message, to include: Information, Warning, or Error. • Timestamp - indicates the date and time of the event. 33

Section	Page
Introduction	9
1.1 Overview	9
1.2 Inter-Server Communication	9
1.2.1 Multicast	9
1.3 License Manager	10
1.3.1 Access License Limits	10
1.3.2 Feature License	11
StorView Quick Tour	13
2.1 The Work Area	13
2.1.1 Tool Bar	14
2.1.2 Enclosure Section	15
2.1.3 Array and Logical Drive Section	23
2.1.4 Server Sidebar and Top Section	25
2.2 How to Use this Document	27
Embedded StorView Setup	29
3.1 Embedded Network Settings	29
3.1.1 Configuring Network Settings via the Wizard	29
3.1.2 Configuring Network Settings via the CLI	32
3.1.3 Configuring Network Settings within StorView	32
3.1.4 Getting a New IP Address	33
Getting Started	35
4.1 Starting StorView	35
4.2 Upgrading the Access License	35
4.3 E-MAIL	37
4.3.1 Configuring E-Mail Notices	37
4.3.2 Deleting an E-Mail Addressee	38
4.4 SNMP	39
4.4.1 Configuring SNMP Traps	39
4.4.2 Deleting an SNMP Server	40
4.5 SYSLOG	41
4.5.1 Gathering Logs	41
4.5.2 SYSLOG Daemon	41
4.5.3 Operational View	42
4.5.4 Configuring SYSLOG	42
4.5.5 Delete a SYSLOG Server	43
4.6 Changing the Password	44
4.7 Monitoring Settings	45
4.7.1 Additional Monitoring Servers	46
4.7.2 Remove Monitored StorView Server IP	46
Storage Assistant	47
5.1 Assisted Automatic Configuration	47
Configuring a Storage Solution	53
6.1 Creating Disk Arrays	53
6.1.1 RAID Levels	53
6.1.2 Terminology	54
6.1.3 Optimization and Drive Selection for RAID 5 and 6	56
6.2 Create the Array	56
6.2.1 Configuring Array Writeback Cache	62
6.3 Initializing the Array	63
6.3.1 Pause/Resume the Initialization	64
6.4 Adding Hot Spare Drives	65
6.4.1 Assigning a Global Spare	65
6.4.2 Assigning a Dedicated Spare	66
6.4.3 Removing a Spare	68
6.4.4 Auto Spare	69
6.5 Create the Logical Drive	70
6.6 Saving the Configuration	73
6.6.1 Saving the Configuration	73
SAN LUN Mapping	77
7.1 Overview	77
7.2 Terminology	77
7.3 Accessing SAN LUN Mapping	78
7.4 Overview: SAN LUN Mapping Window	80
7.4.1 HBA Ports Name Section	80
7.4.2 ADD NEW MAP Section	81
7.4.3 SELECTED HOST HBA PORT CONNECTION Section	81
7.5 Creating a SAN LUN Mapping	82
7.6 Deleting a SAN LUN Mapping	85
7.7 Modifying a SAN LUN Mapping	86
Controller Environmentals	89
8.1 Overview	89
8.2 Controller Environmentals	89
8.2.1 Status	91
8.2.2 Hardware/Firmware	91
8.2.3 Configuration	91
8.2.4 Operations	91
Controller Advanced Settings	99
9.1 Overview	99
9.2 Advanced Settings	99
9.2.1 Identity	100
9.2.2 Fault Tolerance	102
9.2.3 Host Ports	104
Managing the Storage Solution	107
10.1 Overview	107
10.2 Advanced Array Functions	108
10.2.1 Deleting an Array	108
10.2.2 Modifying Arrays	109
10.2.3 Verify Parity	109
10.2.4 Identifying Drive Members	112
10.2.5 Rebuilding an Array	113
10.2.6 Expanding an Array	114
10.2.7 Trust an Array	116
10.3 Restoring and Clearing the Configuration	117
10.3.1 Restoring the Configuration	117
10.3.2 Clearing the Configuration	118
10.4 Advanced Drive Options	121
10.4.1 Accessing the Drive Information Window	121
10.4.2 Locate Drive	122
10.5 Advanced Logical Drive Functions	123
10.5.1 Viewing Unassigned Free Space	123
10.5.2 Expanding a Logical Drive	123
10.5.3 Deleting a Logical Drive	125
Using Snapshot	127
11.1 Introduction	127
11.2 Enabling Snapshot	127
11.3 Taking a Snapshot	130
11.4 Mapping a Snapshot	133
11.5 Deleting a Snapshot	135
11.6 Performing a Snapback	137
11.7 Disabling Snapshot	139
Failover, Performance and Additional Functions	141
12.1 Overview	141
12.2 How StorView Server Failover Works	141
12.3 StorView Performance Optimization	142
12.3.1 Execution Throttle	142
12.3.2 Scatter/Gather	142
12.4 Time Out Issues	142
12.5 Additional StorView Functions	143
12.5.1 About	143
12.5.2 Take Control Monitoring	144
12.5.3 Rescan	145
12.5.4 Alarm Mute and Enable/Disable	146
Support and Updates	147
13.1 Tech Support	147
13.2 Updating Embedded StorView	149
Event Logs	151
14.1 Overview	151
14.2 Accessing and Navigating the StorView Event Log	153
14.3 Exporting the StorView Event Log	154
14.4 Clearing the StorView Event Log	157
14.5 Operating System Event Log	158
14.6 List of Events	159
14.6.1 Controller Events	159
14.6.2 Expansion Module Events	165
14.6.3 Alarm Events	166
14.6.4 Drive and Array Events	167
14.6.5 Controller Port Events	172
14.6.6 Enclosure Events	174
14.6.7 StorView Server Events	177
14.6.8 SnapShot Events	181
14.7 Failed Drives Codes	183
14.8 SAS Fatal Error Codes	183
Statistics	185
15.1 Overview	185
15.2 Access Statistics	186
15.3 Command Size - Alignment Statistics	187
15.4 Read-Ahead Statistics	189
15.5 Command Cluster Statistics	191
A.1 Introduction	193
A.2 Sequential Access	194
A.2.1 Number of Outstanding Commands	194
A.3 Access Size	194
A.3.1 Access Alignment	194
A.4 Sub-Array	195
A.5 Multiple Drive Failures	196
A.5.1 Faster Rebuild	196
A.6 Summary	196
B.1 Problems You May Encounter	197
C.1 Overview	203
C.1.1 Terminology	203
C.2 Overwrite Data Area	204
C.3 Overwrite Data Area Location	205
C.4 Selecting the ODA Stripe Size	205
C.5 Overwrite Data Area Storage Capacity	205
C.6 ODA Assignment	206
C.7 Snapshots and Caching	206
C.7.1 Application Caches	206
C.7.2 Operating System Cache	207
C.7.3 RAID Controller Cache	207
C.8 Virtual LUNs	207

Match case Limit results 1 per page

Getting Started

4.5 SYSLOG

StorView’s SYSLOG agent is a module designed for StorView that enables sending RAID system event

logs to all listening SYSLOG clients on all installed platforms.

SYSLOG requires that the Global Access license be enabled before the feature is activated. Once

activated on each installation of StorView, the locally monitored storage system events are then sent to

the SYSLOG daemon running on the host system.

StorView SYSLOG is designed for greater flexibility in that it supports “many-to-many” mapping. You may

have:

•

Multiple SYSLOG servers that monitor a single RAID storage system for event logs.

•

A single SYSLOG server that monitors multiple RAID storage systems for event logs.

•

Multiple SYSLOG servers that monitor multiple RAID storage systems for event logs.

This “many-to-many” mapping provides an additional safety net in that it offers data redundancy. In this

instance a failed SYSLOG server will not have any impact if another SYSLOG server is functioning

normally.

If you are using a Linux operating system, the syslogd daemon is a component of your operating system.

If you are using a Windows operating system you will need to install a separate tool (http://syslog-

win32.sourceforge.net/) which runs as a Windows service.

4.5.1

Gathering Logs

A host based StorView running the SYSLOG agent with two in-band connections to RAID storage

systems, each with a unique WWN ID. Assuming the SYSLOG is configured to log/dispatch Error type

events, It will gather all Error type events for both RAID storage systems and sent them directly to the

intended host.

The StorView SYSLOG agent is global in scope, in that it will always receive all error logs from the

accessible storage systems. It is not possible to customize filtering of events for each managed storage

system for that host.

With Embedded StorView, previously configured listening SYSLOG servers will persist even though the

embedded module is flashed with new software as the file data is stored in NVRAM and is not affected

by software upgrades.

However, with instances of installed host-based StorView, you must backup or make a copy of the

syslog.ini file otherwise software updates will destroy the configuration information.

4.5.2

SYSLOG Daemon

The daemon listens for incoming event log messages on port 514. It logs them to a messages file. The

SYSLOG messages consist of:

•

Facility - indicates the type of syslog message. For example they can be kernel, user level, mail

system and system daemon messages.

•

Priority - indicates the sensitivity of the message, to include: Information, Warning, or Error.

•

Timestamp - indicates the date and time of the event.