ons-doc-sag-2200-g1_3100sag2007-09

ONStor Bobcat™ 2200 SeriesNAS Gateway

System Administrator’s Guide

Customer Order Number: ONS-DOC-SAG-2200, Rev G1Text Part Number: 690-0015-0001G1

ONStor, Inc.254 East Hacienda Ave.

Campbell, CA 95008(408) 963-2400

Copyright © 2005-2007 ONStor, Incorporated. All rights reserved.

ONStor, EverON, AutoGrow, ONStor Bobcat, ONStor Cheetah, ONStor Pantera, and STORE-FS are trademarks of ONStor, Inc.

This document exists for use with the products of ONStor, Inc. and is intended for use by employees, representatives, assigns, and clientele of ONStor, Inc. This document cannot be copied, reproduced, transmitted, or stored electronically, in part or in whole, without first obtaining the express consent and agreement of ONStor, Inc.

This document can contain the names of products and services of other companies. Such products and services are the property of their owners, and ONStor, Inc. makes no implications or claims, express or implicit, to the ownership of such products and services. ONStor, Inc. has, in good faith, made efforts to represent trademarked and copyrighted products and services as the property of their respective owners.

Contents

Foreword......................................................................................................... iAudience................................................................................................................................ 1-iiScope .................................................................................................................................... 1-iiiDocument Organization ....................................................................................................... 1-ivRelated Documentation ........................................................................................................ 1-viRevision Trail...................................................................................................................... 1-viiSyntax Usage...................................................................................................................... 1-viii

Chapter 1: NAS Gateway Overview and Access .....................................1-1Introducing the ONStor NAS Gateway ................................................................................ 1-2Hardware Overview ............................................................................................................. 1-4

System Switch and Controller ........................................................................................ 1-4File Processor.................................................................................................................. 1-4Storage Processor............................................................................................................ 1-5NAS Gateway Chassis.................................................................................................... 1-5Fans................................................................................................................................. 1-6AC Power Supplies......................................................................................................... 1-6Chassis Front Panel......................................................................................................... 1-7

Example Topology .............................................................................................................. 1-11Software Overview.............................................................................................................. 1-12

EverON Operating System ........................................................................................... 1-12System Control ............................................................................................................. 1-12File Processing.............................................................................................................. 1-12Network Connectivity................................................................................................... 1-13Storage Processing........................................................................................................ 1-13

Volume Manager.................................................................................................... 1-13Understanding the Active Configuration ............................................................................ 1-15Accessing the NAS Gateway CLI....................................................................................... 1-16

690-0015-0001G1 ONStor Bobcat 2200 Series NAS Gateway System Administrator’s Guide

Chapter 2: Managing Privileges................................................................2-1Understanding Privileges....................................................................................................... 2-2

Enforcing Privileges........................................................................................................ 2-2Understanding Exec Privileges ....................................................................................... 2-2

Creating Exec Privileges ....................................................................................................... 2-4Managing Local User Accounts .......................................................................................... 2-10

Chapter 3: Working with Virtual Servers..................................................3-1Understanding Virtual Servers .............................................................................................. 3-2

Supported Features.......................................................................................................... 3-2Virtual Server States ....................................................................................................... 3-3

Understanding the Management Virtual Server .................................................................... 3-4Virtual Server Context and NAS Gateway Context ....................................................... 3-5

Adding a Virtual Server and a NAS Gateway to an LDAP Domain ..................... 3-15Displaying DNS Name Resolution for a Virtual Server ........................................ 3-45Configuring DNS Name Resolution for a Virtual Server ...................................... 3-45

Load Balancing Virtual Servers.................................................................................... 3-55

Chapter 4: Managing Storage and Fibre Channel ...................................4-1Disk LUNs ...................................................................................................................... 4-1

Free LUNs ................................................................................................................ 4-2Foreign LUNs........................................................................................................... 4-2Out of Cluster ........................................................................................................... 4-2

Storage Ports and LUNs.................................................................................................. 4-2Initial Boot ...................................................................................................................... 4-3

Addition of Physical Storage.................................................................................... 4-3Physical Storage Going Offline................................................................................ 4-4

Network Power Cycle ..................................................................................................... 4-5Managing Storage Ports ........................................................................................................ 4-6Managing LUNs .................................................................................................................... 4-9

Displaying the LUN Topology ..................................................................................... 4-12Managing the SCSI Layer ................................................................................................... 4-16

Chapter 5: Working with Network Interfaces...........................................5-1Working with Network Protocols.......................................................................................... 5-2

ONStor Bobcat 2200 Series NAS Gateway System Administrator’s Guide 690-0015-0001G1

Working with Management Interfaces.................................................................................. 5-4Creating Interfaces.......................................................................................................... 5-5

Working with Logical Ports ................................................................................................ 5-12Understanding Logical Port Operation Modes ............................................................. 5-12Load Balancing on IP Interfaces with Logical Ports .................................................... 5-18

Cisco Systems Switch Connectivity Example ....................................................... 5-18Extreme Networks Switch Connectivity Example................................................. 5-20

Understanding Stackable Logical Ports........................................................................ 5-22

Chapter 6: Managing Volumes and File Systems ...................................6-1Introduction to Volumes........................................................................................................ 6-2

Volumes and Virtual Servers.......................................................................................... 6-2Understanding the Management Volume ....................................................................... 6-2

Managing Volumes ............................................................................................................... 6-5Considerations for Importing Volumes.................................................................. 6-20

File System Statistics .......................................................................................................... 6-24

Chapter 7: Managing Shares.....................................................................7-1NFS Environment.................................................................................................................. 7-2

NFS Share Considerations.............................................................................................. 7-2Sharing Nested Directories ...................................................................................... 7-3Share Permissions .................................................................................................... 7-3Sharing with Root Access ........................................................................................ 7-3Share’s Client List.................................................................................................... 7-4Exclusions to the Share’s Client List ....................................................................... 7-4

CIFS Environment................................................................................................................. 7-6Global Namespace (GNS)..................................................................................................... 7-8GNS Root Management ...................................................................................................... 7-10Junction Management ......................................................................................................... 7-16Virtual Directory Management ........................................................................................... 7-19Shares Management ............................................................................................................ 7-24Multiprotocol Environment................................................................................................. 7-30

Understanding ID Mapping .......................................................................................... 7-31ID Map Scanning Logic ......................................................................................... 7-32ID Map Components .............................................................................................. 7-33Naming Conventions.............................................................................................. 7-33


CIFS and NFS Shares and Services..................................................................................... 7-35Preconfiguration Considerations................................................................................... 7-35Configuration Steps ...................................................................................................... 7-36

Managing NFS Shares......................................................................................................... 7-48Modifying NFS Shares ................................................................................................. 7-49

Managing CIFS Shares........................................................................................................ 7-52Enabling or Disabling CIFS.......................................................................................... 7-53Deleting a CIFS Share .................................................................................................. 7-54

Managing CIFS Servers ...................................................................................................... 7-56Managing CIFS Wide Links................................................................................................ 7-58

Examples of Wide Link Behavior................................................................................. 7-58CIFS Behavior Considerations with Wide Links.......................................................... 7-59

Exporting and Importing Shares.......................................................................................... 7-64Managing ID Mappings....................................................................................................... 7-68Multiprotocol File Access Without Using NIS ................................................................... 7-73Working With Symbolic Links ........................................................................................... 7-77

Symbolic Links and the Directory Tree........................................................................ 7-77Deletions and Symbolic Links ...................................................................................... 7-78Deletion of All Objects in a Path .................................................................................. 7-78Support for Absolute and Relative Symbolic Links ..................................................... 7-79Displaying a Symbolic Link Mapping Rule ................................................................. 7-81Removing a Symbolic Link Mapping Rule .................................................................. 7-82

Chapter 8: Managing File Auditing ...........................................................8-1Understanding File Auditing ................................................................................................. 8-2

Audit Events.................................................................................................................... 8-3Managing File Auditing ........................................................................................................ 8-9Configuring File Auditing ................................................................................................... 8-19

Chapter 9: Managing Snapshots ..............................................................9-1Snapshots Overview .............................................................................................................. 9-2

Scheduled Snapshots ................................................................................................ 9-2File System Quotas and Snapshots ................................................................................. 9-3Snapshot Location on the NAS Gateway........................................................................ 9-3

Managing Snapshots on the NAS Gateway........................................................................... 9-4


Chapter 10: Managing File System Quotas ..........................................10-1Quotas Overview................................................................................................................. 10-2

File System Quotas and Volume-Level Quotas............................................................ 10-2Quota Types.................................................................................................................. 10-2Quota Interaction with Other NAS Gateway Features ................................................. 10-3File System Quotas and Backup and Restore Operations ............................................ 10-3

Setting ONSTOR_SUPERSEDE_QUOTAS......................................................... 10-4Setting ONStor Ignore User or Group Quotas ....................................................... 10-6Setting ONStor Ignore Tree Quotas....................................................................... 10-7

File System Quotas and Mirrors ................................................................................... 10-8File System Quotas and Snapshots ............................................................................... 10-9

Specific Tree Quotas ............................................................................................ 10-12Specific Tree Quotas Removal............................................................................. 10-13Specific User and Group Quotas.......................................................................... 10-13

Working With the Quota Log............................................................................................ 10-23

Chapter 11: Monitoring the NAS Gateway .............................................11-1Monitoring with the NAS Gateway .................................................................................... 11-2

Supported RFCs and MIBs........................................................................................... 11-3Managing SNMP................................................................................................................. 11-4

Chapter 12: Autosupport and Event Monitoring ..................................12-1Understanding Autosupport ................................................................................................ 12-2

Understanding Autosupport and Event Logs................................................................ 12-2Understanding Autosupport Message Types ................................................................ 12-3

Configuring Autosupport .................................................................................................... 12-4Event Monitoring and Reporting Services ........................................................................ 12-10

EMRS Upload Methods.............................................................................................. 12-11Configuring and Managing EMRS............................................................................. 12-11

Prerequisites for EMRS........................................................................................ 12-12

Chapter 13: Working with ONStor Data Mirror ......................................13-1Managing ONStor Data Mirror ........................................................................................... 13-2

Data Mirroring Over IP ................................................................................................ 13-2Features and Functionality Supported by Data Mirror over IP.............................. 13-3


Data Mirror over IP Prerequisites .......................................................................... 13-4Local Data Mirror ......................................................................................................... 13-4Data Mirroring Methods ............................................................................................... 13-4

Asynchronous and Synchronous Mirroring ........................................................... 13-5Volumes and Automatic Growth .................................................................................. 13-5Tracking File System Quotas on Target Volumes........................................................ 13-6

Configuring Data Mirrors.................................................................................................... 13-7Backing Up Mirror Volumes ...................................................................................... 13-15

Chapter 14: Managing Backup and Restore ..........................................14-1Introducing Backup and Restore ......................................................................................... 14-2

Backing Up and Restoring Data Using NDMP ............................................................ 14-2Backing Up and Restoring Data Using CIFS or NFS................................................... 14-3Supported Backup and Restore Configurations............................................................ 14-4Supported Backup and Restore Types .......................................................................... 14-4Supported Data Management Applications .................................................................. 14-5Supporting the NDMP Snapshot Management Extension............................................ 14-5Performing NDMP Services Through the NAS Gateway ............................................ 14-6Performing Backup and Restore Through the NAS Gateway ...................................... 14-6Understanding Backup and Snapshots.......................................................................... 14-9Understanding Restore and File System Quotas........................................................... 14-9Understanding Management Volumes and NDMP Sessions...................................... 14-12Understanding NDMP Environment Variables .......................................................... 14-13

Managing NDMP Sessions................................................................................................ 14-28Configuring the NAS Gateway for NDMP Services......................................................... 14-39

Typical Task Sequence in Configuring the NAS Gateway for NDMP ...................... 14-39Preconfiguration Considerations................................................................................. 14-39

Mapping a Device Path to a Physical Device by Querying a SCSI Bridge....14-42Mapping a Device Path to a Physical Device by Querying a Tape Library ...14-43

Chapter 15: Managing Virus Scanning...................................................15-1Introducing Virus Scanning................................................................................................. 15-2

Supporting Third-Party Virus Scanning Solutions ....................................................... 15-2Installing the VirusScan Applet........................................................................................... 15-4

Installation Prerequisites............................................................................................... 15-4Configuring the VirusScan Applet .................................................................................... 15-18


Configuring the VirusScan Applet for the Symantec AntiVirus Scan Engine........... 15-19Configuring the VirusScan Applet for the McAfee AntiVirus Engine API............... 15-21Updating McAfee .DAT files ..................................................................................... 15-22

Configuring the CIFS Domain .......................................................................................... 15-23Receiving Virus Notification on CIFS Clients ........................................................... 15-26

Prerequisites and System Recommendations.................................................................... 15-27Virus-Scan Server Recommendations for the Symantec AntiVirus Scan Engine...... 15-27Virus-Scan Server Recommendations for the McAfee VirusScan Enterprise 8.0i Software

15-27Virus-Scan Server Recommendations for the VirusScan Applet ............................... 15-27

Configuring the Symantec AntiVirus Scan Engine........................................................... 15-29Configuring the McAfee VirusScan Enterprise 8.0i Software.......................................... 15-30Managing Virus Scanning From the CLI.......................................................................... 15-31

Chapter 16: Managing NAS Gateway System Settings ........................16-1Introducing NAS Gateway System Management ............................................................... 16-2

Working with System Time.......................................................................................... 16-5Change in Daylight Saving Time (DST) ...................................................................... 16-6Working With an Event Log (elog) ............................................................................ 16-10

Displaying IP Statistics ..................................................................................................... 16-17Displaying File Processing Port Load Statistics ............................................................... 16-18Managing NAS Gateway System Health .......................................................................... 16-19

Getting the NAS Gateway Statistics........................................................................... 16-26Working with the Read Ahead Cache ............................................................................... 16-32Working with Core Dumps ............................................................................................... 16-34

Displaying Core Dump Files ...................................................................................... 16-37


PrefaceThis preface contains the front matter for the System Administrator’s Guide for the ONStor Bobcat™ 2200 Series NAS Gateway family of products. It contains the following sections:

• “Audience”

• “Scope”

• “Document Organization”

• “Related Documentation”

• “Revision Trail”

• “Syntax Usage”


1-ii

AudienceThis System Administrator’s Guide is for IT professionals that administer the ONStor family of products and their company’s storage area network (SAN). This guide serves IT professionals and storage administrators of varying levels of experience.


1-iii

ScopeThis System Administrator’s Guide helps you understand and configure the ONStor NAS Gateway software. This guide accompanies a separate set of installation instructions, the ONStor Bobcat 2200 NAS Gateway Installation Guide. Use this System Administrator’s Guide only after you have successfully installed the NAS Gateway and connected it to the facility’s power source.

This document is predominantly a reference manual. It contains some reference text and some task-oriented text. Although some overview material is contained in this manual, this manual is not intended to be an in-depth reference document about the public domain protocols with which the NAS Gateway interfaces. For additional material about the NAS Gateway, refer to the additional NAS Gateway product documentation listed in “Related Documentation”.


1-iv

Document OrganizationTable 1 lists the chapters in this document and briefly describes each chapter.

Table 1 : Document Organization

Chapter... Purpose...

1 - “NAS Gateway Overview and Access”

Provides an overview of the software, hardware, and product features and shows how to access the command-line interface (CLI).

2 - “Managing Privileges” Explains the administrative privileges supported on the NAS Gateway for administrative uses, and specify file system privileges for end users.

3 - “Working with Virtual Servers”

Explains the concept of virtual servers and provides commands for configuring and managing virtual servers.

4 - “Managing Storage and Fibre Channel”

Explains the NAS Gateway’s role in discovering and using storage and Fibre Channel (FC) compliant devices.

5 - “Working with Network Interfaces”

Explains how network interfaces are used on the NAS Gateway, and how to provision IP functionality.

6 - “Managing Volumes and File Systems”

Explains what volumes are and how the NAS Gateway manages volumes.

7 - “Managing Shares” Explains the EverON™ software, how it operates with NFS, and how to use NFS share functions.

8 - “Managing File Auditing” Explains the support for auditing and logging file and directory access and usage attempts.

9 - “Managing Snapshots” Explains what snapshots are, what types are available, and how to configure them.

10 - “Managing File System Quotas”

Explains what quotas are, what types are available, and how to configure them.

11 - “Monitoring the NAS Gateway”

Explains what SNMP functionality the NAS Gateway supports.

12 - “Autosupport and Event Monitoring”

Explains what the autosupport feature is and how it works.


1-v

13 - “Working with ONStor Data Mirror”

Explains the NAS Gateway’s mirroring capabilities through the Data Mirror feature.

14 - “Managing Backup and Restore”

Explains the type of backup and restore operations supported, how to manage NDMP sessions and tape devices, and how to configure the NAS Gateway for NDMP sessions.

15 - “Managing Virus Scanning”

Explains how to install and configure the virus scanning applet, what types of third-party virus scanning packages are supported, and how to manage virus scanning from the command-line interface (CLI).

16 - “Managing NAS Gateway System Settings”

Explains the system-wide features that control the NAS Gateway’s operation, and how to configure them.

Table 1 : Document Organization (Continued)

Chapter... Purpose...


1-vi

Related DocumentationThis document is part of a set of product documentation for the NAS Gateway. Table 2 lists the related documentation.

If you are managing the NAS Gateway through the ONStor NAS Cluster Manager, you can also use the NAS Cluster Manager context-sensitive online help.

Release notes are available with every release of software. The release notes contain additional information about bugs and fixes in the product, documentation errata or omissions, and new features or enhancements.

Table 2 : ONStor Product Documentation

Document Name Part Number Revision Level

ONStor Bobcat NAS Gateway Installation and Cluster Configuration Guide

ONS-DOC-CCG-2200 D1

ONStor Bobcat 2200 Series NAS Gateway Command Reference

ONS-DOC-CR-2200 E1

ONStor Bobcat 2200 Series NAS Cluster Manager Administrator’s and User’s Guide

ONS-DOC-CMA B1


1-vii

Revision TrailThis document is regularly reviewed and revised. Table 3 lists the revision history of this document. We recommend that you obtain the latest information whenever possible.

Table 3 : Product Documentation Revision History

Document Name Part Number Revision Level

Revision Date

ONStor Bobcat 2200 Series System Administrator’s Guide

ONS-DOC-SAG-2200

A1 01/18/05


ONS-DOC-SAG-2200

B1 03/16/06


ONS-DOC-SAG-2200

C2 05/08/06


ONS-DOC-SAG-2200

D1 08/15/06


ONS-DOC-SAG-2200

E1 01/23/07


ONS-DOC-SAG-2200

F1 05/18/07

ONStor NAS Gateway System Administrator’s Guide

ONS-DOC-SAG-2200

G1 09/30/07


1-viii

Syntax UsageThe NAS Gateway command-line interpreter uses different syntax markers to indicate specific conditions of usage in the command line. Table 4 lists the different syntax markers used in the command-line interpreter and explains what each marker means.

Table 4 : Syntax Markers

Syntax Marker Means... Example

- (dash) You are specifying an option. -a

blank space You are delimiting words, arguments, or options in a command.

arp show

bold text Command syntax. list

bold italic text A mandatory variable. You need to enter some input for italicized arguments.

ipaddr

[ ] (squared brackets)

Input is optional. The command will complete with or without the optional argument.

[-c CONTROLLER]

| (pipe) A logical or operation. Select one of the choices for the command to complete.

disk|tape

{ } (braces) A choice is contained within the braces. The open brace ({) indicates the beginning of the choice list, and the closed brace (}) indicates the end of the choice list. Choice lists use pipes (described above) to delimit each element in the choice list. Enter one of the elements in the choice list exactly as it occurs in the list.

{left|center|right}


Chapter 1: NAS Gateway Overview and Access

This chapter provides an overview of the main software and hardware elements that enable the ONStor™ NAS Gateway to provide file system services to a storage environment.

This chapter contains the following sections:

• “Introducing the ONStor NAS Gateway” on page 1-2

• “Hardware Overview” on page 1-4

• “Example Topology” on page 1-11

• “Software Overview” on page 1-12

• “Understanding the Active Configuration” on page 1-15

• “Accessing the NAS Gateway CLI” on page 1-16


1-2

Introducing the ONStor NAS Gateway The ONStor NAS Gateway consists of reliable and scalable hardware and software that provides file-level services in your storage environment. The NAS Gateway supports file services features, such as:

• Automatic storage area network (SAN) discovery

• Virtualization of storage resources to simplify administration of the SAN

• Consolidation of network-attached storage (NAS) and direct-attached storage (DAS) into a single platform

• Elimination of NAS and DAS storage islands

• Dynamic volume growth

• Mirroring

• Snapshots

• Clustering

• File system quotas

• Virus scanning

• Multiprotocol client support through Common Internet File System (CIFS) only, NFS only, and a mixed CIFS and NFS environment

The NAS Gateway operates in enterprise and storage service provider (SSP) applications and environments, such as:

• Network-accessible file systems, for example, for collaborative development efforts

• E-mail message archiving and retrieval

• Data and software applications storage

• Storage of e-commerce transactions - online transaction processing (OLTP)

• Content distribution and Internet publishing

• Customer resource management and enterprise resource management applications (CRM and ERM, respectively)


1-3

The NAS Gateway carries out the following functions in a NAS or SAN storage environment:

• Support large numbers of users, files, and file systems.

• Support a high number of file system operations per second.

• Provide virtualized storage, which makes a SAN appear as a unified storage pool over the local area network (LAN). Because IT administrators are more familiar with an IP LAN, the NAS Gateway facilitates SAN administration, which reduces costs and required personnel time.

• Provide high scalability and high reliability. The NAS Gateway offers efficient, high-performance service to the data center and enables the data center to grow.

• Provide graphical policy-based management. Policies can be set for file system volumes for such features as snapshot frequency, mirror frequency, and automatic growth of logical unit number (LUN) space for volumes.

• Automate storage tasks. The NAS Gateway facilitates management of storage. Advanced storage capacity management through the NAS Gateway’s automated storage growth policies facilitates controlling storage regardless of the number of users, growth rates, or the amount of storage you need to manage.

• Automatically discover SAN storage devices when the NAS Gateway is connected to a SAN. The NAS Gateway enables configuration of devices into a single managed storage pool.

• Reducing element-level management tasks through automating processes enabling you to focus on more productive activities.


1-4

Hardware Overview The NAS Gateway is a one-rack unit. Hardware elements inside the chassis are responsible for communicating user data and file meta data, distributing power, and transporting control packets. The NAS Gateway contains the following hardware elements:

• System switch and controller (SSC)

• Gigabit Ethernet (GE) file processor (FP)

• Fibre Channel (FC) storage processor (SP)

System Switch and ControllerThe SSC contains the following elements:

• Boot and runtime images

• Central address resolution protocol (ARP)

• Interface and route tables

• Fault tolerance software

• Logs and system elements

The SSC provides the command-line interface. You can connect to it through a secure shell (SSH) session over any of the NAS Gateway’s 10/100 Ethernet ports, or through the Console port on the front of the chassis.

File ProcessorThe FP contains processing for IP connectivity. The FP supports IP protocol processing, network file protocols, volume management, and GE interfaces into the IP network. The FP supports connections to the IP network through four optical GE (1000BaseSX) ports that support the IP interface connecting the NAS Gateway to the IP network. Each port supports an optical link at a throughput rate of 1 Gbps. You can also use SFP (small form pluggable) copper transceivers.

Note - Optical and copper transceivers cannot be mixed on the same FP.


1-5

Storage ProcessorThe SP contains processing for storage functions. The SP supports FC and serial small computer system interface (SCSI) protocols that run on top of FC. The SP provides connection to the storage network through two physical FC ports that connect the NAS Gateway to the SAN. The SP supports fiber optic cabling on each of the two FC ports. Each FC port supports full duplex traffic at 1 or 2 Gbps in each direction. The link speed is autonegotiated.

NAS Gateway ChassisThe NAS Gateway is installed in a standard 19-inch open frame equipment rack, and the mounting brackets for the chassis can be front-mounted or center-mounted depending on your requirements. The NAS Gateway has the following physical dimensions:

• Height: 1.675 inches

• Chassis weight: 22 pounds

• Total shipping weight: 31 pounds

• Width: 19 inches with mounting brackets installed, 17.3” without mounting brackets

• Depth: 23.45 inches

The NAS Gateway operates effectively in the following physical environment conditions:

• Operating temperature: 0 degrees Celsius to 40 degrees Celsius (from 0 to 3000 feet in altitude), and 0 degrees Celsius to 35 degrees Celsius (from 3000 to 7000 feet in altitude)

• Humidity: 10% to 80%, noncondensing

The NAS Gateway operates effectively with AC power at a current draw of 100 to 240 V AC. At 100 V AC, the NAS Gateway draws a peak 2.2 amps and a constant 1.5 amps.

The NAS Gateway ships with a console cable and a cross-over cable.

The NAS Gateway complies with the following agency approvals and certifications:


1-6

• FCC Class A, Part 15

• CA ICES-003, Issue 3, Class A

• EN60950

• NOM-018

FansThe NAS Gateway provides a chassis cooling system that draws air in from the front, across the elements in the chassis to cool them, then exhausts the heated air out of the chassis to the rear into the surrounding data closet. The NAS Gateway chassis contains five individual fans.

The fan system contains a grill work that allows ambient air from the surrounding room to enter the chassis and cool the chassis. Then, the NAS Gateway’s exhaust fans push the heated air out of the back of the chassis where the air can diffuse into the surrounding room and cool again. The fans are located toward the back of the chassis.

AC Power SuppliesThe NAS Gateway chassis contains two AC power supply units (PSUs). The power supplies plug into the facility’s AC power outlets, digest the input AC power, and distribute the power across the NAS Gateway’s chassis elements.

One power supply provides enough power to support the NAS Gateway. However, two power supplies are provided for power supply redundancy. When the NAS Gateway is operating, the two power supplies loadshare to decrease the load on each PSU. If a power supply fails, the active power supply assumes the full load.


1-7

Chassis Front PanelThe front panel of the NAS Gateway features status LEDs, ports, and slots for the CompactFlash cards. See Table 1-1.

Table 1-1: Chassis Front Panel Elements

Panel Element Description

NAS Gateway status LEDs Indicator of whether the NAS Gateway is operating properly or has encountered a failure. A green LED means that the NAS Gateway is OK. A red LED means the NAS Gateway has encountered a failure.

Figure 1-1 ONStor NAS Gateway Front Panel

ONStor NAS Gateway Status LED

Power Supplyand Fan Status LED

10/100 EthernetPorts and LEDs

Compact FlashEjector

Compact FlashSlots and LEDs

GEPort LEDs

GEPorts

FC PortLEDs

FC Ports

Console Port


1-8

Power supply and fan status LEDs Indicator of the status of the fans (the FAN LED) and the power supplies (the PS LED):• A green FAN LED means the NAS

Gateway’s fans and chassis cooling system are operating properly.

• A red FAN LED means the NAS Gateway’s fans and cooling system have encountered a failure.

• A green PS LED means the NAS Gateway’s power supplies are operating properly.

• A red PS LED means the NAS Gateway’s power supplies have encountered a failure.

10/100 Ethernet ports, 2 Two ports for an Ethernet or Fast Ethernet segment. The ports automatically negotiate for the higher of the two bandwidths.

10/100 Ethernet port LEDs, 2 Indicator of whether the NAS Gateway recognizes a valid 10/100 Ethernet connection at the physical layer. One LED corresponds to each of the management ports, and if the LED is lit, a physical link has been established.

CompactFlash ejectors Ejects the CompactFlash cards. Each CompactFlash slot has one ejector button.

Table 1-1: Chassis Front Panel Elements (Continued)



1-9

CompactFlash memory card slots, 2 Two slots that accept one CompactFlash memory card each. One CompactFlash memory card is considered the active card because it contains the runtime images, and one CompactFlash memory card is considered the standby card because it is not in runtime mode. The active card is indicated by an amber LED, the standby card is indicated by a green LED.

Do not remove the active (amber LED) card. You can remove the standby card (green LED).

CompactFlash LEDs, 2 Indicator for the CompactFlash cards. A green LED indicates either that no CompactFlash card is in the slot or the card that is in that slot is the standby card. An amber light indicates that a active CompactFlash card is in the slot.

Do not remove the active CompactFlash card.

GE ports, 4 GE ports of the NAS Gateway. Each port supports an individual GE collision domain. The four ports on the chassis correspond to the four Link Status LEDs. The NAS Gateway also supports copper transceivers.

GE port LEDs, 4 Indicator of whether the NAS Gateway’s transceiver recognizes a valid GE LAN connection at the physical layer. One LED corresponds to each of the GE ports. If the LED is lit, a physical link has been established.

FC ports, 2 FC ports for the NAS Gateway. Each port supports an individual FC link. The two ports on the chassis correspond to the two Link Status LEDs.




1-10

FC port LEDs, 2 Indicator of whether the NAS Gateway transceiver recognizes a valid FC connection at the physical layer. One LED corresponds to each of the FC ports. If the LED is lit, a physical link has been established.

Console Port Enables you to directly connect to the chassis and attach a management console to the NAS Gateway.




1-11

Example TopologyThe NAS Gateway sits between the IP network and the SAN. The NAS Gateway provides a front end for file processing transactions between the clients in the IP network and the stored data resources in the SAN. Figure 1-2 shows an example configuration containing the NAS Gateway.

IBM Compatible

IBM Compatible

W orkstation

W orkstation

GE

ONStor NAS Gateway

IP SAN

FC

NFS

Primary Windows

Disk ar ray Disk ar ray

Consolidated NASand SAN Storage

hub/router

WindowsNT Client

Workstat ion

WindowsXP Client

Workstat ion

Windows2000 Client

Secondary WindowsDomain Controller

Domain Controller

Client

W orkstation

NFSClient

IBM Compatible

ServerNIS

Figure 1-2 Example Topology Containing an ONStor NAS Gateway


1-12

Software OverviewThe NAS Gateway contains several software components that control the file services and storage network operations it performs.

EverON Operating SystemThe proprietary ONStor EverON™ operating system software overlays the format of file system blocks onto resources in the SAN. The EverON operating system software supports NFS and CIFS network file system protocols for UNIX and Windows client accessibility to data.

System ControlThe system control software governs the NAS Gateway. The system control software runs across multiple processors and resides on the SSC element. The system control software performs such tasks as monitoring and maintaining the NAS Gateway during runtime and boot time. The system control software also enables you to halt, restart, or upgrade the NAS Gateway, set time and date information, and track uptime.

For more information about the NAS Gateway System Control software, see “Managing NAS Gateway System Settings” on page 16-1.

File Processing File processing enables clients in the IP network to successfully read and write files and other data to disks and tapes. File processing resides on the GE FP element. File processing features include:

• Network connectivity

• The ONStor STOR-FS™ file system

The NAS Gateway supports file services, such as:

• Scheduled and on-demand snapshots

• Mirrors

• Clustering


1-13

For more information about the StorFS file system, see “Managing Shares” on page 7-1.

Network ConnectivityThe NAS Gateway’s network connectivity is used to transmit and receive NFS packets through User Datagram Protocol (UDP) or Transmission Control Protocol (TCP). The NAS Gateway supports both UDP and TCP. The determination of whether to use TCP or UDP depends on which protocol is in use on the client machine.

Storage ProcessingThe NAS Gateway’s storage processing software enables the NAS Gateway to support SCSI and FC services over multiple physical media, and it resides on the SP element. The storage processing software enables the following features:

• Automatic SAN discovery

• Rapid convergence on SAN topology changes

• High throughput of file system input and output processes between the NAS Gateway and the storage resources

SP software also governs volumes through the NAS Gateway’s volume manager (VM). For more information about the SP software, see the “Managing Storage and Fibre Channel” on page 4-1.

Volume Manager The Volume Manager (VM) summarizes and manages LUN-level information for the SAN. The VM gathers information about physical storage, virtualizes that information, and presents it to the file system so that file systems can be created on top of the virtualized disk blocks. The VM is also responsible for dynamically adding LUNs to a volume’s free space based on a configured ONStor AutoGrow™ policy. For more information about the VM, see the “Managing Volumes and File Systems” on page 6-1.

You can access and configure the NAS Gateway through one of the following methods:

• Command-line interface (CLI) through secure shell (SSH) access


1-14

• CLI through direct connect Console port access

• NAS Cluster Manager Web user interface (web UI)


1-15

Understanding the Active ConfigurationEach NAS Gateway contains its active configuration in the cluster database. The cluster database is the repository of all configuration information for all NAS Gateways in the cluster. Each NAS Gateway in the cluster contains its own copy of the cluster database. When a parameter has been configured, that parameter is written to the NAS Gateway’s cluster database. If any state change or configuration change occurs, the cluster databases are synchronized between all NAS Gateways in the cluster so that they all contain the same information.


1-16

Accessing the NAS Gateway CLIThe NAS Gateway’s command line interface (CLI) is the prompt at which you type commands. Figure 1-3 shows the NAS Gateway’s CLI at the admin mode.

The default command prompt displays that the management session is logged in to the system switch and controller (SSC) element.

Note - The NAS Gateway’s command line is case sensitive. Ensure that you run all commands in lower case. Capitalization of letters can be used when entering the names of objects, for example, a volume or virtual server.

If you access the user interface through a secure shell or telnet session, you can enter the NAS Gateway through either of the following methods:

• A management interface, one of the two 10/100 SSC interfaces on the SSC

• A Gigabit Ethernet interface, a configured IP interface on the GE file processor

If you access the user interface through a direct console connection, you can enter the NAS Gateway through the Console port on the front of the chassis.

Note - If you are accessing the NAS Gateway for the first time, direct console connection is the only connection method supported until IP addresses are configured. After IP addresses have been configured, secure shell access is available.

Login:adminPassword:*****ssc>

Figure 1-3 Sample ONStor NAS Gateway Command Prompt at Admin Mode


Chapter 2: Managing Privileges This chapter contains the following sections:

• “Understanding Privileges” on page 2-2

• “Creating Exec Privileges” on page 2-4

• “Managing Local User Accounts” on page 2-10


2-2

Understanding PrivilegesPrivileges provide a secure mechanism to assign task responsibility on a system-wide basis. Each privilege has a well-defined role assigned by the system administrator to a user or group.

The NAS Gateway supports file system execution (exec) privileges that apply to end users on Windows, Network Information Service (NIS), or Lightweight Directory Access Protocol (LDAP) clients. For more information, see “Understanding Exec Privileges” on page 2-2.

A privilege consists of the admin, user, or group name, a privilege, and a scope:

• Privileges are the rights that you have to perform an action on the NAS Gateway.

• Scope defines to which objects the privilege applies. Two types of scope exist: cluster and virtual server.

When you create a privilege, you specify an allow or deny action as a privilege rule that determines the privilege and scope of the privilege. The allow or deny logic is similar to the Windows Access Control List (ACL) logic.

Enforcing PrivilegesPrivileges are checked against the scope and the deny rule. The software checks for privileges at the virtual server scope first, then at the cluster scope. The software also checks for deny rules first and stops at the first match of an admin, user, or group name with a deny privilege.

Understanding Exec PrivilegesFile system execution (exec) privileges are applied to users or groups for manipulating files and directories in the file system. CIFS domains require these file system execution privileges, and they closely resemble the Windows privilege model. Exec privileges are applied to the user or group name during file access check.


2-3

Table 2-2 lists the exec privileges that the NAS Gateway supports and displays the amount of control that they have.

Table 2-2: Exec Privileges for File Operations

Exec Privilege Scope Allowed Operations

SECURITY Cluster, virtual server Enabling or disabling file-level audit management, manipulating SACL.

BACKUP Cluster, virtual server Read any file or directory. This privilege is used for backup operations only.

RESTORE Cluster, virtual server Read, write, or delete any file or directory. This privilege is used for restore operations only.

TAKEOWNERSHIP Cluster, virtual server Change owner of any file or directory.

TRAVERSE Cluster, virtual server Traverse directory, request change notification.


2-4

Creating Exec PrivilegesWhen you create exec privileges for NIS, LDAP, or Windows users or groups for a given domain, at least one virtual server that is part of that domain must be enabled in the cluster.

Creating an Allow Rule You can create allow privileges by running the priv add allow command. This command sets the parameters for allowed operations at a specific level of control.

Note - Exec privileges can override file-level privileges. For example, if user exec1 does not have read permissions on a file, but is configured with “backup” exec privileges, user exec1 can read the file for the purposes of backing up the file.

You can specify only one level of scope for each admin user, but specifying higher-scope levels includes the lower-scope levels. Enter the scope in lowercase.

To Add an Allow Privilege

• Run the following command:priv add allow {user|group} IDENTITY PRIVILEGES cluster|vsvr [VIRTUALSERVER]

Options and Arguments Description

user|group This argument interacts with the IDENTITY argument to specify the name of the user or group. Use an alphanumeric character string. If you specify group, the IDENTITY argument names the group, and if you specify user, the IDENTITY argument names the user.


2-5

Configuring a Deny Rule Deny privileges are added to the NAS Gateway to enforce a limit on what a NAS Gateway administrator or user can do. You can configure a deny rule for a NAS Gateway administrator by running the priv add deny command.

Note - The NAS Gateway administrator’s privilege is cluster and scope is cluster, so by creating a deny list for a NAS Gateway administrator, you disallow that admin from running any commands on the NAS Gateway.

IDENTITY Specifies the name of the user or group for which you are adding a privilege definition. The maximum identity string size must be congruent with the string size supported through the domain, such as 15 characters for a NetBIOS name, 64 for a Windows domain. If an identity has blank spaces, enclose it in double quotation marks.This argument works in combination with the user|group argument to specify the name of a user or group. Enter the identity as one of the following:• WindowsDomainName\UserName, for a Windows user or

group• UserOrGroupName@DomainName for a NIS or LDAP user

or group from an NIS or LDAP domain• A local user account

PRIVILEGES Specifies the privilege that you are configuring for the NAS Gateway admin in IDENTITY. This argument accepts any of the privileges listed in Table 2-2 on page 2-3 for exec privileges. Enter the privilege in uppercase.

cluster|vsvr [VIRTUALSERVER]

Specifying cluster applies privileges to all virtual servers within that cluster.Specifying vsvr applies privileges to the current virtual server.Specifying vsvr [VIRTUALSERVER] applies privileges to a specified virtual server.


2-6

To Create a Deny Privilege

• Run the following command:priv add deny {user|group} IDENTITY PRIVILEGES cluster|vsvr [VIRTUALSERVER]


user|group This argument interacts with the IDENTITY argument to specify the name of the user or group. If you specify group, the IDENTITY argument names the group, and if you specify user, the IDENTITY argument names the user.

IDENTITY Specifies the name of the user or group for which you are adding a privilege definition. Use an alphanumeric character string. The maximum identity string size must be congruent with the string size supported through the domain, such as 15 characters for a NetBIOS name, 64 for a Windows domain. If an identity has blank spaces, enclose it in double quotation marks.This argument works in combination with the user|group argument to specify the name of a user or group. Enter the identity as one of the following:• WindowsDomainName\UserName, for a Windows user or



PRIVILEGES Specifies the privilege that you are configuring for the NAS Gateway admin in IDENTITY. This argument accepts any of the admin privileges listed in Table 2-2 on page 2-3 for exec privileges. Enter the privilege in uppercase.

cluster Specifying cluster applies privileges to all virtual servers within that cluster.

vsvr [VIRTUALSERVER]

Specifying vsvr applies privileges to the current virtual server.Specifying vsvr [VIRTUALSERVER] applies privileges to a specified virtual server.


2-7

Displaying the Configured PrivilegesThe privileges table contains a list of configured privileges and information about each privilege’s scope. You can display the contents of the privileges table by running the priv show command.

To Display Configured Privileges

• Run the following command:priv show cluster|vsvr [VIRTUALSERVER] [-P PAGENUMBER] [-S PAGESIZE]

Deleting an Allow RuleYou can delete an allow rule at any time by running the priv delete allow command. This command allows you to delete privileges of a specified user or group.

To Delete an Allow Rule

• Run the following command:priv delete allow {user|group} IDENTITY PRIVILEGES cluster|vsvr [VIRTUALSERVER]


cluster Shows privileges of all virtual servers within that cluster.

vsvr Shows privileges of the current virtual server.

VIRTUALSERVER Specifies the virtual server that you want to show privileges for.

-P PAGENUMBER Shows privileges by page number.

-S PAGESIZE Show privileges by page size in number of records.



2-8

Deleting a Deny RuleYou can delete a deny rule at any time by running the priv delete deny command. This command allows you to delete privileges from a specified user or group.


IDENTITY Specifies the name of the user or group for which you are deleting an allow rule. Use an alphanumeric character string.This argument works in combination with the user|group argument to specify the name of a user or group. Enter the identity as one of the following:• WindowsDomainName\UserName, for a Windows user or

group• UserOrGroupName@DomainName for a NIS or LDAP user or

group from an NIS or LDAP domain• A local user account

PRIVILEGES Specifies the privilege for which you are deleting the allow rule in IDENTITY. This argument accepts any of the privileges listed in Table 2-2 on page 2-3 for exec privileges. Enter the privilege in uppercase.

cluster Specifying cluster deletes an allow rule on all virtual servers within that cluster.

vsvr [VIRTUALSERVER]

Specifying vsvr deletes an allow rule on the current virtual server.Specifying vsvr [VIRTUALSERVER] deletes an allow rule on a specified virtual server.


2-9

To Delete a Deny Rule

• Run the following command:priv delete deny {user|group} IDENTITY PRIVILEGES cluster|vsvr [VIRTUALSERVER]



IDENTITY Specifies the name of the user or group for which you are deleting a deny rule. Use an alphanumeric character string.This argument works in combination with the user|group argument to specify the name of a user or group. Enter the identity as one of the following:• WindowsDomainName\UserName, for a Windows user or



PRIVILEGES Specifies the privilege for which you are deleting the deny rule in IDENTITY. This argument accepts any of the privileges listed in Table 2-2 on page 2-3 for exec privileges. Enter the privilege in uppercase.

cluster|vsvr Specifying cluster deletes a deny rule on all virtual servers within that cluster.

[VIRTUALSERVER] Specifying vsvr deletes a deny rule on the current virtual server. Specifying vsvr [VIRTUALSERVER] deletes a deny rule on a specified virtual server.


2-10

Managing Local User AccountsA local user account gives you a user identity for accessing NAS Gateways. You can assign privileges to a local user account and use it for specific system functions and applications. For example, a local user account is necessary to run Network Data Management Protocol (NDMP).

Unlike NIS or Windows user accounts that reside on the domain controller or NIS server, the NAS Gateway local user account has no effect outside of the NAS Gateway. Because the local user account is configured on the NAS Gateway, the account name cannot contain a domain name and does not need to be authenticated through a domain controller.

Each local user account is a cluster-wide entity, so you can use the same local user account on any NAS Gateway in a cluster. However, each local user account must be unique within a cluster.

Note - If you want to launch the ONStor VirusScan applet from any user account, you need to configure that user account with BACKUP and RESTORE privileges because the VirusScan applet needs to access files in read/write mode in the virtual server. The scope of the privilege can be either VIRTUAL SERVER or CLUSTER.

You need to configure a local user account with LOGIN privilege to allow the owner of the local user account to login to the NAS Gateway. With LOGIN privilege, the owner of the local user account can also run any of the show commands - for example, arp show - but cannot configure or change any parameters.

You can configure a local user account to support SSH keys for access to the NAS Gateway without a password.

Adding a Local User AccountThis procedure creates a new user account on the NAS Gateway. As part of the account creation, you are required to specify a password for the user account you are


2-11

configuring. When you enter the user name, the NAS Gateway prompts you for the user account's password. Enter the password for the account. For security purposes, the password is not displayed when you configure it with this command.

To Add a Local User Account

Step 1: Run the following command:useraccount add USERNAME [-k PUBKEY]

Step 2: When prompted, do either of the following:

• Enter the password for the user account you just created.

• Enter the SSH key that the client generated for the local user account.

Step 3: Set the privileges for the user account you just created by running the priv add allow command.

Changing a Local User Account Password or SSH KeyYou can modify the password or SSH key for the local user account at any time by running the useraccount modify command.


USERNAME Specifies the user account name by using an alphanumeric character string from 3 to 63 characters.

-k PUBKEY Specifies the SSH key for a local user account. This argument must be the SSH key that the client generated. If the key is not supplied or is not an exact match with the client’s SSH key, the user account cannot automatically log in. Therefore, you need to enter a password every time the user account accesses the NAS Gateway.The first time you create a local user account, you need to specify the password, even if you use the -k PUBKEY argument.


2-12

When you run the useraccount modify command, the NAS Gateway either prompts you to enter the new password for a specified user account or a new SSH key.

• When you enter the new password, it becomes active immediately.

• When you enter a new SSH key, it overwrites any existing SSH key for the local user account, and becomes active immediately.

To Change the Password or SSH Key Associated With a Local User Account

Step 1: Run the following command:useraccount modify USERNAME [-k PUBKEY]

Step 2: When prompted, enter the password for the user account you just created.

Displaying a Local User AccountWhen a local user account is created, it is added to the local user account list, which contains all defined local user accounts for NDMP in the current virtual server. You can display the configured local user accounts by running the useraccount show command.


USERNAME Specifies the user account name by using an alphanumeric character string from 3 to 63 characters.

-k PUBKEY Specifies the SSH key for a local user account. This argument must be the SSH key that the client generated. If the key is not supplied or is not an exact match with the client’s SSH key, the user account cannot automatically log in. Therefore, you need to enter a password every time the user account accesses the NAS Gateway.The first time you create a local user account, you need to specify the password, even if you use the -k PUBKEY argument.


2-13

To Display All Local User Accounts

• Run the following command:useraccount show

Deleting a Local User AccountYou can remove a local user account at any time by running the useraccount delete command. The deletion is effective immediately.

To Delete a Local User Account

Step 1: To locate the local user account you want to delete, run the following command:useraccount show

Note the user account name for use in the next step.

Step 2: Run the following command:useraccount delete USERNAME

USERNAME specifies the user account by using an alphanumeric character string from 3 to 63 characters.


2-14


Chapter 3: Working with Virtual Servers


• “Understanding Virtual Servers” on page 3-2

• “Understanding the Management Virtual Server” on page 3-4

• “Creating a Virtual Server and Performing Basic Setup” on page 3-7


3-2

Understanding Virtual ServersA virtual server is a software entity that enables the logical association of elements required for file services.

Note - When a node is added to a cluster, you need to ensure that all virtual servers reside on the Primary cluster.

Two types of virtual servers exist within a NAS Gateway:

• Management virtual server, which is automatically created when the NAS Gateway is started for the first time. The management virtual server is used to support the core volume and management volume. For more information about the core volume and management volume, see “Understanding the Management Volume” on page 6-2.

• Virtual servers, which you create and configure to provide file services.

Supported FeaturesVirtual servers support the following two features:

• Failover - When a virtual server is set to protected mode, it supports failover. When it is set to unprotected mode, it does not support failover.

• Manual load balancing - You can manually assign a virtual server to different NAS Gateways to facilitate load Balancing.

You need to create at least one virtual server to enable client input/output (I/O) on the NAS Gateway. When you create a virtual server, you configure it with all the pertinent components for supporting failover and load balancing. The following components are required for creating and configuring a virtual server:

• A unique name so that each virtual server can be addressed individually

• At least one IP interface for connectivity to the client’s IP network

For the virtual server to provide file services, you need to configure the following components:


3-3

• Volumes

• Lightweight Directory Access Protocol (LDAP), Network File System (NFS) or Common Internet File System (CIFS) shares

• Routes, which are associated with an IP interface

You can set the route table, interface table, and address resolution protocol (ARP) table for each virtual server individually.

Multiple virtual servers can exist on a NAS Gateway, but NAS Gateways cannot share the same virtual server. Each cluster can support up to 32 virtual servers. The automatically created management virtual servers (one per NAS Gateway in the cluster) do not count against the maximum number of virtual servers.

Virtual Server StatesVirtual servers can be in one of two states:

• Enabled: The state when the virtual server has been created and enabled in a cluster.

• Disabled: The state when the virtual server is not online and clients cannot connect to the virtual server. This state is the default state when you create the virtual server. When you have configured the virtual server, you need to enable it.

Note - When you disable a configured virtual server, you interrupt the file services and IP connectivity provided to the clients.


3-4

Understanding the Management Virtual ServerEach NAS Gateway has one management virtual server that is automatically created when the NAS Gateway is started for the first time. The management virtual server provides:

• Continuous availability of core dump functionality

• Continuous availability of a management volume

The management virtual server requires no network-related configuration because that configuration is done on the individual virtual servers. However, if you are using any of the following features, some configuration is required:

• A temporary directory for NDMP backup and restore operations. To use this feature you need to create and configure a management volume from the management virtual server context.

• Core dump space for failure information. To use this feature you need to create and configure a core volume from the management virtual server context.

• Autosupport mechanism. The management virtual server is preconfigured for the autosupport mechanism.

Note - For autosupport to function, the management virtual server must have the DNS resolver configured, which you can configure through the system dnsconfigure resolver command. For more information, see “Configuring DNS Name Resolution for a Virtual Server” on page 3-46.

Because the management virtual server is unprotected, it does not failover to another NAS Gateway if the NAS Gateway is configured in a clustered environment. The management virtual server cannot be moved within a cluster.

The management virtual server always contains the name string “VS_MGMT” and a numerical ID. The ID is generated when the management virtual server name is created, and is an identifier only. It has no relation to the number of virtual servers configured.


3-5

Virtual Server Context and NAS Gateway Context When the NAS Gateway is initially booted, by default all resources belong to the NAS Gateway, and not to a specific virtual server. After you have created at least one virtual server, two types of context exist from which you can perform tasks, such as running commands for creating and configuring virtual servers:

• NAS Gateway context

• Virtual server context

The context from which you are running commands determines the scope of the commands’ effects. Some features, such as the interfaces, route table, and ARP table, display different information depending on whether you are viewing them from the NAS Gateway context or a specific virtual server context.

Note - You need to make the configurations for any virtual server within the context of that virtual server.

You can determine whether you are in virtual server or NAS Gateway context by looking at the command-line prompt, as shown in the following examples:

eng33> Shows the default prompt, which is the NAS Gateway’s unique node name. This command prompt indicates that you are in NAS Gateway context.

eng33 PUBSTEST> Shows the virtual server named PUBSTEST. The value eng33 is the NAS Gateway’s unique node name. This prompt indicates that you are in the virtual server context.

Table 3-3 lists the virtual server commands, the contexts in which they are available, and the virtual server state necessary to run the command. If a virtual server state is


3-6

listed as N/A, the command does not depend on the virtual server state, so you can run the command regardless of the virtual server state.

Table 3-3: Command Availability

CommandNAS

Gateway Context

Virtual Server

Context

Virtual Server State

system dnsconfigure show Yes Yes N/A

system dnsconfigure hosts Yes Yes N/A

system dnsconfigure resolver Yes Yes N/A

vsvr create Yes No N/A. By default, virtual servers are created “disabled”.

vsvr clear No Yes N/A

vsvr clear autocreate No Yes Disabled

vsvr clear domain No Yes Disabled

vsvr set unprotected No Yes N/A

vsvr clear wins No Yes Disabled

vsvr delete Yes, if you specify the virtual server name

Yes, but with or without the virtual server name

N/A

vsvr disable No Yes Enabled

vsvr enable No Yes Disabled

vsvr move No Yes N/A

vsvr set NAME Yes Yes N/A

vsvr set name netbios NAME No Yes Disabled


3-7

Creating a Virtual Server and Performing Basic SetupYou can create virtual servers only from the context of the NAS Gateway by running the vsvr create command. The NAS Gateway does not support nested virtual servers. When the vsvr create command completes, you are automatically put into the virtual server context. If you are in a virtual server context and you want to configure a new virtual server, return to the NAS Gateway context with the vsvr clear command.

To Create a Virtual Server and Perform Basic Setup

Step 1: Run the following command:

vsvr set name generic NAME No Yes Disabled

vsvr set autocreate No Yes Disabled

vsvr set domain No Yes Disabled

vsvr set protected No Yes N/A

vsvr set wins No Yes Disabled

vsvr show Yes Yes N/A

Table 3-3: Command Availability (Continued)

CommandNAS

Gateway Context

Virtual Server

Context

Virtual Server State


3-8

vsvr create VIRTUALSERVER [-n NODE] [-u]


VIRTUALSERVER Specifies the name of the virtual server you are creating. Use an alphanumeric character string from 1 to 15 characters. Do not use special characters in the virtual server name, such as *, ?, and /. • Virtual server names need to start with an alphabetic or

numeric character.• Each virtual server name must be unique within a cluster.

Even though virtual server names are displayed in uppercase, they are case insensitive with all vsvr commands. Therefore, you can use upper or lowercase when specifying a virtual server name.

• Virtual servers cannot be named with VS_MGMT because that string is reserved for the management virtual server.

• The keyword All is reserved and cannot be used as a virtual server name.

-n NODE An optional argument that configures the virtual server on any NAS Gateway in a cluster.• If you specify the -n option and enter a NAS Gateway

name, the virtual server is created on that NAS Gateway.• If you do not specify the -n option, the virtual server is

created on the current NAS Gateway.

-u An optional argument that sets the virtual server to unprotected mode. By default, virtual servers are created in protected mode.• If you specify the -u option, the virtual server will not be

switched to another NAS Gateway if the NAS Gateway is forced to reset.

• If you do not specify the -u option, the virtual server is created in protected mode (the default). This mode makes the virtual server transportable to a different NAS Gateway on failover.


3-9

Note - The virtual server name you create is also the NetBIOS name by default.

Step 2: Assign an IP interface to the virtual server by running the interface create command:interface create INTERFACE -l LPORT [-s (enable|disable)] [-t VLANTAG] [-a IPADDR/MASKLEN] [,IPADDR/MASKLEN] ...] [-p [cifs=(enable | disable)],[nfs=(enable|disable)]] [-w PRIMARYIPADDR [,SECONDARYIPADDR]]

The interface create command is run from within the context of the current virtual server so you do not need to specify the virtual server name. You can configure a virtual server with no interfaces, but for client connectivity, each virtual server must have at least one IP interface.


INTERFACE Specifies the name you want to give the interface.

-l LPORT Specifies the name of the logical port that the interface uses. For more information about logical ports, see “Working with Logical Ports” on page 5-12.

-s enable|disable Specifies the interface’s state, either enabled or disabled. The interface state takes precedence over other parameters’ states. For example, if you create the interface in disabled state, but set CIFS and NFS to enabled, then CIFS and NFS access is also disabled on the interface because the interface is not online.


3-10

-t VLANTAG Specifies a VLAN tag enabling the NAS Gateway to process 802.1q packets. The value for VLAN tags can be any number between 0 and 4095. A value of 0 indicates that VLAN tagging is disabled for that interface. You can assign one VLAN tag per interface.

Note - The VLANTAG option of this command is only available if you are running the command from the virtual server context.

For the virtual server, the IP address of each interface has to be unique. The virtual server does not support overlapping subnets across VLANs. Do not use the same VLAN number for different interfaces on the same virtual server.

-a IPADDR/MASKLEN Specifies the IP address and mask length in bits that you are adding. Each virtual server can support up to 32 IP interfaces.

,IPADDR/MASKLEN An optional comma-separated list of IP addresses and masks that you can add to the interface.



3-11

Step 3: Create a default route for the virtual server by running the route add command:route add default -g IPADDR

-g IPADDR is the IP address of the gateway.

-p The argument that supports controlling the file access protocol state for either CIFS or NFS when the interface is created:• -p cifs=enable|disable allows you to create the

interface with CIFS either enabled or disabled. After the interface is created, you can change the state of CIFS on the interface by running the interface modify command.

• -p nfs=enable|disable allows you to create the interface with NFS either enabled or disabled. After the interface is created, you can change the state of NFS on the interface by running the interface modify command.

• For a multiprotocol environment, you can run the arguments in the same command if you separate them with a comma. For example:-p cifs=enable,nfs=enable would create an interface with both CIFS and NFS enabled on the same interface.

By default, all protocols are enabled when the interface is created.

-w PRIMARYIPADDR Specifies the primary WINS server address for interfaces supporting CIFS that need WINS.

,SECONDARYIPADDR Specifies the secondary WINS server address, if needed. If you are specifying the secondary WINS server address, make sure you separate the primary and secondary IP addresses with a comma.

Note - The same physical and logical port can be used by different virtual servers, but the same IP address cannot be used on multiple virtual servers.



3-12

Example: route add default -g 10.2.0.1

Modifying Virtual Server InterfacesAny time after you’ve created a virtual server, you can make changes to its interfaces by running the interface modify command. Through this command you can modify interfaces in any of the following ways:

• Change the logical port associated with the interface.

• Change the state of the interface to either disabled or enabled.

• Add or delete IP addresses on the interface.

• Enable or disable CIFS or NFS on the interface.

• Change the WINS server address, or add a backup WINS server.

• Enable or disable protocols associated with the interface.

• Change or disable VLAN tagging.

To Modify a Virtual Server Interface

• Run the following command:interface modify INTERFACE [-l LPORT][-s (enable|disable)] [-t VLANTAG][-a IPADDR/MASKLEN] [,IPADDR/MASKLEN] ...] [-d IPADDR][-p [cifs=(enable | disable)], [nfs=(enable|disable)]] [-w PRIMARYIPADDR [,SECONDARYIPADDR]]


INTERFACE Specifies the location of the NAS Gateway and port where you want to modify the IP interface.

-l LPORT An optional argument that specifies name of the logical port that the interface uses.


3-13

-s enable|disable Enables or disables the entire interface. If you use this argument to change the state of the interface, all the interface’s parameters are affected. For example, if you disable an interface that supports a multiprotocol share, CIFS and NFS access is also disabled on the interface even though you have not explicitly disabled the individual protocols on the interface.

-t VLANTAG Specifies a VLAN tag that enables the NAS Gateway to process 802.1q packet. The value for VLAN tags can be any number between 0 and 4095. A value of 0 indicates that VLAN tagging is disabled for that interface. You can assign one VLAN tag per interface.

Note - The VLANTAG option of this command is only available if you are running the command from the virtual server context.

For the virtual server, the IP address of each interface has to be unique. The virtual server does not support overlapping subnets across VLANs. Do not use the same VLAN number for different interfaces on the same virtual server.

-a IPADDR/MASKLEN Specifies the IP address and mask length in bits for the interface that you are adding. Each virtual server can support up to 32 IP interfaces.

,IPADDR/MASKLEN An optional comma-separated list of IP addresses and mask lengths that you can add to the interface.



3-14

Joining Virtual Servers to a DomainFor virtual servers and NAS Gateways to be visible to clients, you need to add the NAS Gateway to the domain that clients use. The NAS Gateway supports any of the following client domain environments:

• LDAP (Lightweight Directory Access Protocol) for NFS and CIFS clients. For CIFS clients using LDAP, the LDAP domain environment is set as a Windows domain.

• Network information services (NIS) domain for NFS clients.

• Windows domain for CIFS clients.

Adding a virtual server to a domain occurs in two steps:

1. Add a domain to the NAS Gateway using the domain add command.

-p The argument that controls the state of CIFS or NFS:• -p cifs=enable|disable allows you to enable or disable

CIFS on the interface.• -p nfs=enable|disable allows you to enable or disable

NFS on the interface. • For a multiprotocol environment, you can run the

arguments in the same command if you separate them with a comma. For example:-p cifs=disable,nfs=disable would disable both CIFS and NFS on the same interface.

By default, all protocols are enabled when the interface is created.

-w PRIMARYIPADDR Specifies the primary WINS server address for interfaces supporting CIFS that need WINS.

,SECONDARYIPADDR Specifies the secondary WINS server address, if needed. If you are specifying the secondary WINS server address, make sure you separate the primary and secondary IP addresses with a comma.



3-15

2. Add the virtual servers associated with the NAS Gateway to a domain using the vsvr set domain command.

Note - Disable virtual servers before joining them to domains.

When the virtual servers are added to the domains, the remaining configuration and management of the NAS Gateway is done through the virtual servers. For more information about configuring virtual servers, see “Working with Virtual Servers” on page 3-1.

LDAP or NIS authentication is not mandatory for supporting NFS shares. It is only required if the virtual server contains volumes with data that is accessed by both CIFS and NFS clients.

In a Windows domain, CIFS authentication enables the addition of a virtual server to the domain so that clients can access the virtual server’s resources.

After you have added LDAP, NIS, or Windows domain to the NAS Gateway cluster, you can add virtual servers to the domain with the vsvr set domain command.

The following sections document the commands necessary to add and manage the virtual server in an LDAP, NIS, or Windows domain. For more information about joining the virtual server to an LDAP, NIS, or Windows domain, see:

• “Adding a Virtual Server and a NAS Gateway to an LDAP Domain” on page 3-15

• “Adding a Virtual Server and a NAS Gateway to a NIS Domain” on page 3-19

• “Adding a Virtual Server and a NAS Gateway to a Windows Domain” on page 3-21

Adding a Virtual Server and a NAS Gateway to an LDAP DomainYou can add an LDAP domain to the NAS Gateway’s configuration by running the domain add ldap command. This command also specifies the primary LDAP server and optionally, a backup LDAP server with which the NAS Gateway will register to become a part of the domain.

To Configure the NAS Gateway for an LDAP Domain

Step 1: From the NAS Gateway context, run the following command:


3-16

domain add ldap DOMAINNAME SERVER_URIS DEFAULT_BASE_SCOPE [-u LOGIN_DN] [-p PASSWORD_BASE_SCOPE] [-g GROUP_BASE_SCOPE] [-h HOST_BASE_SCOPE] [-n NETGROUP_BASE_SCOPE]


DOMAINNAME Specifies the name of the LDAP domain that is used for authentication. Use an alphanumeric character string of up to 63 characters. Do not use restricted characters such as *,~,?, and !.

SERVER_URIS Specifies the LDAP server host name or IP address and port. You can specify up to 32 servers by including them in quotation marks (“) and separating the list with commas and spaces (, ). For example, a string specifying the LDAP server ldap://192.168.3.1 can use any of the following formats: • ldap://server.example.com:345

• ldap://192.168.2.1:678

• 192.168.3.1

• server.example.com


3-17

DEFAULT_BASE_SCOPE Specifies the default base distinguished name (DN) and scope to be used for LDAP searches. Examples: “ou=eng, o=company, c= us: SUB”,“ou=qa, o=company, c= us: BASE”,“ou=finance, o=company, c= us: ONE”• BASE specifies a search at the root layer of the

directory.• ONE specifies a search at one layer of the

directory.• SUB specifies a search through all subdirectories of

the tree.

Note - When enclosing values in quotation marks, a space between the values after the comma is valid. A space before the values BASE, SUB, and ONE is required.

If the scope is not specified or is not BASE, ONE, or SUB, the default scope is SUB.

The following arguments are optional.

-u LOGIN_DN Specifies the login DN to be used for administrative queries. Example: “cn=admin, dc=example, dc=com”.If you enter this argument, you are prompted for that account’s password.

-p PASSWORD_BASE_SCOPE Specifies the base DN and scope to be used for user account-related LDAP searches. Example: “ou=People, o=company, c=us: SUB”.

-g GROUP_BASE_SCOPE Specifies the base DN and scope to be used for user group-related LDAP searches. Example: “ou=Groups, o=company, c=us: BASE”.

-h HOST_BASE_SCOPE Specifies the base DN and scope to be used for LDAP searches related to the host name and address. Example: “dc=example,dc=com: ONE”.


3-18

Note - Because all optional arguments are character strings, verify any values you enter with your LDAP system administrator to ensure that they are valid. Invalid values cause LDAP search errors and might produce unexpected results.

Step 2: From the virtual server context, run the following command to disable the virtual server:vsvr disable

Step 3: From the virtual server context, run the following command to add the virtual server to the domain:vsvr set domain ldap DOMAINNAME

DOMAINNAME specifies the domain name for the virtual server. DOMAINNAME is the domain name you previously specified in the NAS Gateway using the domain add ldap command.

Step 4: From the virtual server context, run the following command to enable the virtual server:vsvr enable

Step 5: From the virtual server context, run the following command to verify the LDAP domain configuration and to connect to the LDAP server:domain verify ldap DOMAINNAME

DOMAINNAME specifies the LDAP domain name for the virtual server. DOMAINNAME is the domain name you previously specified in the NAS Gateway using the domain add ldap command.

-n NETGROUP_BASE_SCOPE

A character string that specifies the base DN and scope for LDAP searches related to NIS netgroups. Example: “cd=example,dc=com: SUB”.


3-19

Adding a Virtual Server and a NAS Gateway to a NIS DomainYou can add a NIS domain to the NAS Gateway’s configuration by running the domain add nis command, which specifies the NIS domain controller with which the NAS Gateway will register to become a part of the domain.

Note - The domain that you are adding needs to exist before running this command because the NAS Gateway attempts to register with the domain controller when this command completes.

After you have added the NAS Gateway to a NIS domain, you can add virtual servers associated with the NAS Gateway to the NIS domain with the vsvr set domain command.

To Add the NAS Gateway to a NIS Domain

Step 1: From the NAS Gateway context, run the following command:domain add nis DOMAINNAME IPADDR



DOMAINNAME Specifies the name of the LDAP domain that is used for authentication. Enter an alphanumeric character string of up to 63 characters. Do not use restricted characters such as *,~,?, and !.

Note - If you need to log in to the NAS Gateway through this domain, use the NIS identity format, for example, userA@domainY.

IPADDR Specifies the IP address of the NIS server.


3-20

Step 3: From the virtual server context, run the following command to add the virtual server to the domain:vsvr set domain nis DOMAINNAME

DOMAINNAME specifies the domain name for the virtual server. DOMAINNAME is the domain name you previously specified in the NAS Gateway using the domain add nis command.


Note - When a NIS domain is configured for a virtual server, client host name resolution occurs through a NIS server, not through the DNS resolver. With local NIS maps, no NIS server exists for the virtual server, so client host name resolution does not occur for the virtual server. Therefore, configure DNS on each virtual server that is using local NIS maps.

Step 5: From the virtual server context, run the following command to verify the NIS domain configuration:domain verify nis DOMAINNAME IPADDR [IPADDR]


DOMAINNAME Specifies the domain name by using an alphanumeric character string.

IPADDR Specifies the IP address of the NIS server or domain controller from which to retrieve the configuration information.

[IPADDR] An optional argument that specifies up to four additional IP addresses of NIS servers serving the same domain.


3-21

Adding a Virtual Server and a NAS Gateway to a Windows DomainAdd a Windows domain to the NAS Gateway’s configuration by running the domain add windows command. This command also specifies the primary domain controller (PDC) and optionally, a backup domain controller (BDC) with which the NAS Gateway will register to become a part of the domain.

Note - The domain that you are adding needs to exist before running this command because the NAS Gateway attempts to register with the domain controller when this command completes.

To Configure the NAS Gateway in a Windows Domain

Step 1: From the NAS Gateway context, run the following command:domain add windows DOMAINNAME LOGINUSER HOSTNAME [HOSTNAME] [-NONETBIOS] [-k KRBDOMAINNAME] [-t CLOCKSKEW]


DOMAINNAME Specifies the domain name by using an alphanumeric character string. For Windows domains, this should currently be the NetBIOS Windows domain name.

LOGINUSER Specifies a user name that will be used to contact the domain controllers. Use an alphanumeric character string. This argument is applicable only to Windows domains. LOGINUSER can be a regular domain user account with "domain user" group.

HOSTNAME Specifies the IP (A.B.C.D) or hostname of the domain controller that should be contacted for retrieving the domain information. In case [-NONETBIOS] is set, the HOSTNAME needs to be the hostname, not the IP address.For a Windows NT domain, this is the IP or hostname of the Primary Domain Controller (PDC).


3-22


Step 3: From the virtual server context, run the following command to add the virtual server to the domain:

[HOSTNAME] An optional argument that specifies the hostname or IP address of up to three additional primary domain controllers for a Windows domain. If the -NONETBIOS option is set, HOSTNAME needs to be the DNS host name.

[-NONETBIOS] This option should be set when the Domain Controller server can only be contacted by using either DNS or LDAP name resolution (when NetBIOS name resolution is not configured on the Domain Controller). When this option is used, the Domain Server name should be used instead of the Domain Controller server IP in the HOSTNAME field.When using the domain show command, this domain is displayed with an asterisk (*) next to it.

[-k KRBDOMAINNAME] This option needs to be set for adding a Kerberos domain only.

[-t CLOCKSKEW] Max. clock skew value in minutes. This option can be specified only with -k option. Clock skew ranges from 1 to 9999 minutes.Default value is 5 minutes. All clocks must be synchronized.



3-23

vsvr set domain windows DOMAINNAME ADMINUSER [-o ORGUNIT]


Displaying the Domains Associated with a NAS GatewayThe NAS Gateway tracks all the domains it has joined in the domain list. This list is available on each cluster. You can display the NAS Gateway’s domain list by running the domain show command. By adding keywords to the domain show command, you can filter the display by the following categories:

• All domains regardless of domain type

• All LDAP domains

• All NIS domains

• All Windows domains


DOMAINNAME Specifies the name of the Windows domain that you are setting for the virtual server.

ADMINUSER Specifies the name of the Windows domain administrator to use when the virtual server joins the domain. ADMINUSER should be a domain user account with full privilege.

[-o ORGUNIT] Specifies the organizational unit in which the computer object for the virtual server should be created. This option can be set only for a Kerberos domain.

Note - If any portion of ORGUNIT contains spaces, it should be enclosed in quotes.


3-24

To Display the Domains in Which the NAS Gateway is Participating

• Run the following command:domain show {all|ldap|nis|windows}

Choose from all|ldap|nis|windows to specify the type of domain that you are displaying.

• all displays a list of all LDAP, NIS, and Windows domains configured on the NAS Gateway.

• ldap displays a list of all LDAP domains configured on the NAS Gateway.

• nis displays a list of all NIS domains configured on the NAS Gateway.

• windows displays a list of all Windows domains configured on the NAS Gateway.

Displaying LDAP Domain SchemasYou can display the contents of the LDAP domain schema with the domain show ldap schema command. The display contains the following schema information:

• User (object class, attribute name for the user name, attribute name for the user ID, and attribute name for the user password)

• Group (object class, attribute name for the group name, attribute name for the group ID, and attribute name for the group member)

• Netgroup (object class, attribute name for the netgroup name, attribute name for the netgroup triple (user, host, and domain), and attribute name for the netgroup member)

• Host (object class, attribute name for the host’s canonical name, attribute name for the hosts’s alias names, attribute name for the host’s IP address)

To Display the Schema of a Configured LDAP Domain

• Run the following command:domain show ldap schema DOMAINNAME


3-25

DOMAINNAME is the LDAP domain name.

Modifying the LDAP Domain Information for a NAS GatewayYou can modify parameters of an existing domain by running the domain modify command.

Note - Except for the -s SERVER_URIS and the -d DEFAULT_BASE_SCOPE options, you can enter an empty string to clear an option.

If the scope is not specified or is not BASE, ONE, or SUB, the default scope is SUB.

To Modify the LDAP Domain Information in the NAS Gateway

Step 1: From the NAS Gateway context, run the following command to locate the domain information that you want to modify:domain show {all|ldap|nis|windows}

Step 2: From the NAS Gateway context, run the following command:domain modify ldap DOMAINNAME [-s SERVER_URIS] [-d DEFAULT_BASE_SCOPE] [-u LOGIN_DN] [-p PASSWORD_BASE_SCOPE] [-g GROUP_BASE_SCOPE] [-h HOST_BASE_SCOPE] [-n NETGROUP_BASE_SCOPE]


DOMAINNAME Specifies the name of the LDAP domain membership that you are modifying. Use an alphanumeric character string of up to 63 characters. Do not use restricted characters such as *,~,?, and !.


3-26

SERVER_URIS Specifies the LDAP server host name or IP address and port. You can specify up to 32 servers by including them in quotation marks (“) and separating the list with commas and spaces (, ). For example, a string specifying the LDAP server ldap://192.168.3.1 can be either of the following formats: • ldap://server.example.com:345• ldap://192.168.2.1:678• 192.168.3.1• server.example.com

DEFAULT_BASE_SCOPE Specifies the default base distinguished name (DN) and scope to be used for LDAP searches. Examples: “ou=eng, o=company, c= us: SUB”,“ou=qa, o=company, c= us:BASE”,“ou=finance, o=company, c= us: ONE”• BASE specifies a search at the root layer of the

directory.• ONE specifies a search at one layer of the

directory.• SUB specifies a search through all subdirectories

of the tree.

Note - If the scope is not specified or is not BASE, ONE, or SUB, the default scope is SUB.

When enclosing values in quotation marks, a space between the values after the comma is valid. A space before the values BASE, SUB, and ONE is required.

The following arguments are optional.



3-27

Step 3: Run the following command to verify the LDAP domain configuration:domain verify ldap DOMAINNAME

DOMAINNAME is the name of the LDAP domain.

-u LOGIN_DN Specifies the login DN to be used for administrative queries. Example: “cn=admin, dc=example, dc=com”.

Note - If you enter this argument, you are prompted for that account’s password.

-p PASSWORD_BASE_SCOPE Specifies the base DN and scope to be used for user account-related LDAP searches. Example: “ou=People, o=company, c=us: SUB”.

-g GROUP_BASE_SCOPE Specifies the base DN and scope to be used for user group-relates LDAP searches. Example: “ou=Groups, o=company, c=us: BASE”.

-h HOST_BASE_SCOPE Specifies the base DN and scope to be used for LDAP searches related to the host name and address. Example: “dc=example, dc=com: ONE”.

-n NETGROUP_BASE_SCOPE Specifies the base DN and scope for LDAP searches related to NIS netgroups. Example: “cd=example,dc=com: SUB”.

Note - Because all optional arguments are character strings, verify any values you enter with your LDAP system administrator to ensure that they are valid. Invalid values cause LDAP search errors and might produce unexpected results.



3-28

Modifying Schemas of LDAP Domain ConfigurationsYou can modify the schema of a configured LDAP domain by running the domain modify ldap schema command. With this command you can modify the following schemas:

• User

• Group

• Netgroup

• Host

To Modify the Schema of an LDAP Domain

Step 1: From the NAS Gateway context, run the following command:domain modify ldap schema (user | group | netgroup | host) DOMAINNAME [OPTIONS ...]


user The user schema. In the user schema you can modify the user object class, the user name, the user ID number, and the user password.

group The group schema. In the group schema you can modify the object class, the group name, the group ID number, and the group member ID.

netgroup The netgroup schema. In the netgroup schema you can modify the object class, the netgroup name, the netgroup triple (user, host, domain), and the netgroup member ID.

host The host schema. In the host schema you can modify the object class, the host name, and the host’s IP address.

DOMAINNAME Specifies the LDAP domain name by using an alphanumeric character string.

OPTIONS A set of optional arguments through which you can specify object class names and attribute names.


3-29

For the group portion of the LDAP schema, the following options are available:• -o OBJECTCLASS — the object class name for the group.

The RFC2307 value is posixGroup. The default Windows ADS value is group.

• -n GROUPNAME — the attribute name for the group name. The RFC2307 value is cn. The default Windows ADS value is msSFU30Name.

• -i GID — the attribute name for the group ID. The RFC2307 value is gidNumber. The default Windows ADS value is msSFU30GidNumber.

• -m MEMBERNAME — the attribute name for the group member. The RFC2307 value is memberUid. The default Windows ADS value is msSFU30MemberUid.

For the host portion of the LDAP schema, the followingoptions are available:• -o OBJECTCLASS — the object class name for a host, for

example, the IP device. The RFC2307 value is ipHost. The default Windows ADS value is computer.

• -n HOSTNAME — the attribute name for a host’s canonical name. The RFC2307 value is cn. The default Windows ADS value is msSFU30Name.

• -l HOSTALIASES — the attribute name for a host’s alias names.The RFC2307 value is cn. The default Windows ADS value is msSFU30Aliases.

• -a HOSTADDR — the attribute name for a host’s IP address. The RFC2307 value is ipHostNumber. The default Windows ADS value is msSFU30IpHostNumber.



3-30

Step 2: Run the following command to verify the LDAP domain configuration:domain verify ldap DOMAINNAME

For the netgroup portion of the LDAP schema, the followingoptions are available:• -o OBJECTCLASS — the object class name for the NIS

netgroup. The RFC2307 value is nisNetGroup. The default Windows ADS value is msSFU30NisNetgroup.

• -n NETGROUPNAME — the attribute name for the netgroup name. The RFC2307 value is cn. The default Windows ADS value is msSFU30Name.

• -t NETGROUPTRIPLE — the attribute name for the netgroup triple. The RFC2307 value is nisNetgroupTriple. The default Windows ADS value is msSFU30NetgroupDetail.

• -m NETGROUPMEMBER — the attribute name for the netgroup member. The RFC2307 value is memberNisNetgroup. The default Windows ADS value is msSFU30NetgroupDetail.

For the user portion of the LDAP schema, the followingoptions are available: • -o OBJECTCLASS — the object class name for the user

account. The RFC2307 value is posixAccount. The default Windows ADS value is user.

• -n USERNAME — The attribute name for the user name. The RFC2307 value is uid. The default Windows ADS value is msSFU30Name.

• -i UID — the attribute name for the user ID. The RFC2307 value is uidNumber. The default Windows ADS value is msSFU30UidNumber.

• -p PASSWORD — the attribute name for the user password. The RFC2307 value is userPassword. The default Windows ADS value is msSFU30Password.



3-31

DOMAINNAME is the name of the LDAP domain.

Modifying the NIS Domain Information for a NAS GatewayYou can modify parameters of an existing domain by running the domain modify nis command.

To Modify the NIS Domain Information In the NAS Gateway


Step 2: From the NAS Gateway context, run the following command:domain modify nis DOMAINNAME IPADDR

Modifying the Windows Domain Information for a NAS GatewayYou can modify parameters of an existing domain by running the domain modify windows command.

To Modify the Windows Domain Information In the NAS Gateway


Step 2: From the NAS Gateway context, run the following command:


DOMAINNAME Specifies the name of the domain that you are modifying. Enter an alphanumeric character string of up to 63 characters. Do not use restricted characters such as *,~,?, and !.

IPADDR Specifies the IP address of the NIS server.


3-32

domain modify windows DOMAINNAME LOGINUSER HOSTNAME [HOSTNAME] [-t CLOCKSKEW]

Removing Virtual Servers and NAS Gateways from a DomainYou can remove virtual servers and NAS Gateways from a domain at any time. Removing a NAS Gateway from a domain occurs in two steps:

1. Remove the virtual servers associated with the NAS Gateway from the domain using the vsvr clear domain command.

Note - Disable virtual servers before removing them from a domain.

2. Remove domain from the NAS Gateway by using the domain delete command.


DOMAINNAME Specifies the domain name by using an alphanumeric character string. For Windows domains, this should currently be the NETBIOS Windows domain name.

LOGINUSER Specifies a user name that will be used to contact the domain controllers by using an alphanumeric character string. This argument is applicable only to Windows domains.

HOSTNAME Specifies the IP (A.B.C.D) or hostname of domain controller that should be contacted for retrieving the domain information.

[HOSTNAME] An optional argument that specifies the IP address of any additional backup domain controllers for a Windows domain. Enter the IP address of the backup domain controller.

[-t CLOCKSKEW] Specifies the maximum clock skew value in minutes. This option can be specified only if the domain was created with -k option. Clock skew ranges from 1 to 9999 minutes. Default value is 5 minutes.


3-33

Note - If you want to change the domain definition on the NAS Gateway, you can delete the domain and reconfigure it. However, a more efficient way to change a domain definition is through the domain modify command.

To Remove the Virtual Server From a Domain

Step 1: From the NAS Gateway context, run the following command to locate the domain information that you want to delete:domain show {all|ldap|nis|windows}


Step 3: From the virtual server context, run the following command to remove the virtual server from the domain:vsvr clear domain ldap|nis|windows [DOMAINNAME]

Note - You need to repeat steps 2 and 3 for every virtual server in the cluster that were joined to the domain before you can delete the domain at the NAS Gateway context.



ldap|nis|windows A list from which you specify one domain type at a time.

DOMAINNAME Specifies the name of the domain that you are deleting.


3-34

Step 5: Run the following command to remove the domain information from the NAS Gateway:domain delete {ldap|nis|windows} DOMAINNAME }

Note - A domain cannot be removed from the NAS Gateway unless there are no virtual servers associated with the domain.

Setting the Virtual Server to Protected ModeA virtual server can be in one of two modes: protected or unprotected. Protected mode enables the virtual server to failover, unprotected mode does not permit failover.

By default, a virtual server is configured in protected mode when you create it through the vsvr create command. However, you can specify the -u option in the vsvr create command to change the state from protected mode to unprotected mode.

Note - The management virtual server is always in unprotected mode and the vsvr set protected command does not affect the management virtual server.

To Set a Virtual Server to Protected Mode

Step 1: From the virtual server’s context, run the following command:vsvr set protected


ldap|nis|windows A list from which you specify one domain type at a time.

DOMAINNAME Specifies the name of the domain that you are deleting. Enter an alphanumeric character string of up to 63 characters. Do not use restricted characters such as *,~,?, and !. For Windows domains, this is the NetBIOS Windows domain name.


3-35

Step 2: (Optional) You can check the virtual server’s mode by running the vsvr show command with the virtual server’s name. The ID field shows the mode as protected. If the ID field shows only the numerical ID, the virtual server is in unprotected mode.

Setting a Virtual Server to Unprotected ModeA virtual server can be in one of two modes: protected or unprotected. Protected mode enables the virtual server to failover, unprotected mode does not permit failover.

To Set a Virtual Server to Unprotected Mode

Step 1: From the virtual server’s context, run the following command:vsvr set unprotected

Step 2: (Optional) You can check the virtual server’s mode by running the vsvr show command with the virtual server’s name. The ID field shows only the virtual server’s numerical ID, which means it is in unprotected mode. If the ID field shows protected, the virtual server is in protected mode.

Setting the WINS Server Address for a Virtual ServerThe Windows Internet Name Service (WINS) name servers allows resolution of windows work station names to IP addresses. The NAS Gateway uses WINS name servers to locate domain controllers. The NAS Gateway also registers the name of each virtual server with the WINS server so that Windows clients can resolve the names to IP addresses.

Note - Configuring the WINS server address for a virtual server is optional.

With the vsvr set wins command, you can specify the IP address of the WINS server that a virtual server should use. You can specify the WINS server addresses for a virtual server only if the virtual server is in the disabled state. You can put the virtual server into disabled state by running the vsvr disable command. For details, see “Enabling and Disabling a Virtual Server” on page 3-45.


3-36

To Specify the IP Address of the WINS Server

• Run the following command:vsvr set wins PRIMARYIPADDR [SECONDARYIPADDR]

Deleting the WINS Server Address from a Virtual ServerDelete the WINS server address from a domain at any time by running the vsvr clear wins command. This command enables you to delete the IP address of the primary and secondary WINS server. When you delete the WINS server, the name-to-IP-address resolution does not occur for the virtual server.

You can delete the WINS server IP addresses from a virtual server only if the virtual server is in the disabled state. You can put the virtual server into disabled state by running the vsvr disable command. For details, see “Enabling and Disabling a Virtual Server” on page 3-45.

To Delete the WINS Server

• Run the following command:vsvr clear wins


PRIMARYIPADDR Specifies the IP address of the primary WINS server. Because the WINS server can reside in a standalone server or on the domain controller, specify either the IP address of the standalone WINS server, or the IP address of the domain controller, whichever is pertinent to your network configuration.

[SECONDARYIPADDR] An optional argument that specifies the IP address of the secondary WINS server. Because the WINS server can reside in a standalone server or on the domain controller, specify either the IP address of the standalone WINS server, or the IP address of the domain controller, whichever is pertinent to your network configuration.


3-37

Setting a CIFS NetBIOS Name of a Virtual ServerYou can set the CIFS NetBIOS name of the virtual server by running the following command from the virtual server context:

vsvr set name netbios NAME

NAME specifies the CIFS NetBIOS name. By default, the NetBIOS name is the same as the virtual server name. This command overrides that rule. The virtual server must be disabled before you can run this command.

Note - You can add additional NetBIOS names to the virtual server with the cifs server add command. See the ONStor 2200 Series NAS Gateway Command Reference for details on how to use this command.

Configuring a Virtual Server with the Autocreated Shares UtilityThe autocreated shares utility enables the creation of a share for the volume and path to users’ home directories. Each virtual server can contain a volume where home directories are supported for users. The autocreated shares utility supports CIFS clients only.

You can configure the autocreated shares utility for a virtual server through the vsvr set autocreate command. This command enables the NAS Gateway to automatically create a user’s home directory share in a virtual server by concatenating three pieces of information:

• The volume that will contain the user home directories.

• The path to the home directories. The path must already be configured on the volume that will contain the user home directories.

• The user’s name, which is discovered as the user logs in to the network.

When the virtual server is enabled, the volume and path are exported along with any specific shares configured in the virtual server. When a user logs in to a Windows domain, the NAS Gateway matches the user name portion of the logon and appends it to a concatenation of the volume and file path.


3-38

Part of the vsvr set autocreate command is a file path. For a share with the user’s name to appear in the Shares List, a directory with the same name must exist in the path.

The autocreated shares feature has the following considerations:

• You can run the vsvr set autocreate command only when the virtual server is in the disabled state.

• The volume you specify must be read-writable.

• The volume containing home directories must already be created.

• The path to the home directories must already be configured in the file system on the home directory’s volume.

• You need to have a home directory for each user.

• The user’s home directory name must be the same as the user’s Windows login.

• If a user logs in with a different name, the user can directly connect to the home directories of other users. For example, user “paulw” can connect to the home directory of “johndoe” even though this share is not listed by default for “paulw.” After a user has connected to another user’s home directory share, this share is listed in the connected user’s Shares List as long as the user remains connected to that share. For example, “paulw” will see a share called “johndoe” while listing the shares in the same virtual server, but only for as long as “paulw” is connected to the “johndoe” share.

Before configuring a virtual server with the autocreated shares utility, ensure that a volume with user home directories exists. For more information about creating volumes, see “Managing Volumes and File Systems” on page 6-1.

Before configuring a virtual server with the autocreated shares utility, gather the name of the volume where the home directories exist, and the path to the users’ home directories.

Note - The user home directory structure must match the file path you enter when configuring the virtual server’s autocreated shares utility.


3-39

To Configure the Autocreated Shares Utility on a Virtual Server

Step 1: From the virtual server context, disable the virtual server if it is currently enabled by running the vsvr disable command.

Step 2: Configure the autocreated shares utility and specify the file path so autocreated shares can export a user’s home directory by running the following command:vsvr set autocreate VOLNAME PATHNAME


VOLNAME Specifies the volume in which the home directory is configured. Use an alphanumeric character string from 1 to 127 characters. Volume names can begin with an alphanumeric character, an underscore ( _ ), or a hyphen ( - ). The volume must already exist before you run this command.

PATHNAME Specifies the absolute path to the directory in which the user home directories are configured, for example: \users\local\homes. Use an alphanumeric character string from 1 to 15 characters. You do not need to specify the user name as part of the path. The NAS Gateway discovers the user name from the user’s login and uses the name to determine which home directory is shared with which user. Example:

vsvr set autocreate testvol \user\local\homes

This argument takes the file path to the directory where user home directories are configured. The NAS Gateway prefixes the volume to the file path. When the user logs into the domain, the user name from the login is automatically appended to the end of the volume and file path, resulting in the creation of the entire share to each user’s home directory.

Note - You do not need to specify the user name in the file path.


3-40

Deleting the Autocreated Shares UtilityAt any time, you can delete the autocreated shares utility from a virtual server by running the vsvr clear autocreate command. After deleting the autocreated shares utility, if users want to access their home directories, they need to browse the file system to their home directories through the virtual server.

Note - You can delete the autocreated shares utility at any time. However, if you delete the autocreated shares utility while the virtual server is enabled, the change does not take effect until you have disabled, and then re-enabled the virtual server.

To Delete the Autocreated Shares Utility

Step 1: Disable the virtual server by running the following command:vsvr disable

Step 2: Delete the autocreated shares utility by running the following command:vsvr clear autocreate

Step 3: Re-enable the virtual server by running the following command:vsvr enable

Configuring a Virtual Server for a File System ProtocolVirtual servers use standard file system protocols to access and share files. Virtual servers support the following file system protocols:

• CIFS

• NFS

• A multiprotocol environment with both NFS and CIFS


3-41

Before you begin configuring a virtual server for any of these environments, you need prerequisite information. Table 3-4: lists the prerequisite information you need for each environment before you start configuring a virtual server for it.

Table 3-4: File System Protocol Configuration Prerequisites

Prerequisite Information Required For

Decide whether you want the virtual server configured in protected mode for failover to a different NAS Gateway. See “Creating a Virtual Server and Performing Basic Setup” on page 3-7.

CIFS, NFS, and mixed CIFS-NFS

Decide what the virtual server’s name will be. By default, the virtual server’s name and the NetBIOS name are the same, but you can change the virtual server’s name or the NetBIOS name later.


Gather the IP addresses you want assigned to the virtual server. Each virtual server can be configured with a maximum of 32 IP addresses. These IP addresses are assigned to the virtual server itself.


Gather the Windows domain and user names. The virtual server uses the Windows domain.name.

CIFS and mixed CIFS-NFS

Gather the name of the LDAP domain the virtual server will join.

NFS and mixed CIFS-NFS

Gather the name of the NIS domain the virtual server will join.

NFS and mixed CIFS-NFS

Gather the IP address of the primary WINS server and any secondary WINS server. The WINS server might be configured on the domain controller, in which case, you’ll need the domain controller’s IP address.

CIFS and NFS


3-42

To configure and activate a virtual server for a NFS, CIFS, or multiprotocol file system protocol, follow the steps outlined in the following procedure. Steps for CIFS only or NFS only file system protocols are specifically noted as such. All other steps apply to either CIFS, NFS, or multiprotocol file system environment setup. Follow the steps as required, depending on the type of file system protocol you want to set up.

To Configure and Activate a Virtual Server for an NFS, CIFS, or Multiprotocol File System Protocol

Step 1: If you are configuring a virtual server for the CIFS file system protocol, specify any WINS servers that the virtual server should use by running the vsvr set wins command. For example, to specify that the virtual server use the primary WINS server at 33.44.55.5, and the secondary WINS server at 33.44.55.66, enter the command as shown:vsvr set wins 33.44.55.5 33.44.55.66

Note - This step is optional.

If your multiprotocol environment supports home directories through the autocreated shares utility, go to “Configuring a Virtual Server with the Autocreated Shares Utility” on page 3-37 before continuing with this procedure.

Step 2: If you are setting up a CIFS file system protocol, specify the Windows domain that the NAS Gateway will join as part of configuring another virtual server, by running the domain add windows command.

Decide if the virtual server will support home directories. See “Configuring a Virtual Server with the Autocreated Shares Utility” on page 3-37.

CIFS and mixed CIFS-NFS

Table 3-4: File System Protocol Configuration Prerequisites (Continued)

Prerequisite Information Required For


3-43

For example, to have the NAS Gateway join the Windows domain “effigy” whose domain controller is at 10.2.128.141 and use the admin login name “onstor,” run the following command:domain add windows effigy onstor 10.2.128.141

If you are setting up an NFS file system protocol, specify the NIS domain that the NAS Gateway will join as part of configuring another virtual server, by running the domain add nis command.

For example, to have the NAS Gateway join the NIS domain “tiamat” whose domain controller is at 10.5.129.1, enter the command as shown:domain add nis tiamat 10.5.129.1

Note - The NIS or Windows domain name can be a maximum of 63 characters.

Step 3: If you are configuring a virtual server for a CIFS file system protocol, specify the Windows domain in which the virtual server will register by running the vsvr set domain command.

For example, to set the Windows domain “effigy” with the login administrator name “onstor”, run the command as shown:vsvr set domain windows effigy onstor

You also need to specify the password for the administrator “onstor”.

Note - DNS is supported through the vsvr set domain windows command.

Step 4: If you are configuring a virtual server for an NFS file system protocol, specify the NIS domain in which the virtual server will register by running the vsvr set domain command.

For example, to set the NIS domain “tiamat”, run the following


3-44

command:vsvr set domain nis tiamat

Step 5: Add an interface that supports IP connectivity and a route to the domain controller by running the interface create command.

For example, to create an interface on fp.0 and logical port lp.0 to the domain controller 10.2.128.141 with mask length of 24, run the following command:interface create fp.0 -l lp.0 -a 10.2.128.141/24

Step 6: Run the vsvr show command to verify the virtual server’s configuration, and check that you have assigned the resources to the correct virtual server.

For example, to check the virtual server configuration of “pubstest,” run the following command:vsvr show pubstest

• If the virtual server configuration is not correct, you can rerun commands to delete and reconfigure, or modify, the parts of the virtual server that need correcting. Configure virtual server setup parameters while the virtual server is disabled. At this point, the virtual server is still disabled.

• If the virtual server configuration is correct, proceed to the next step.

Step 7: Enable the virtual server in runtime, by running the vsvr enable command from the virtual server context:vsvr enable

Enabling and Disabling a Virtual ServerWhen you have created a virtual server with the vsvr create command, it is in the disabled state by default. Configure the virtual server’s setup parameters while it is in the disabled state. Configure the virtual server’s runtime parameters while it is in the enabled state. For more information about which parameters and commands are available in which state, see Table 3-3 on page 3-6.


3-45

Enabling a virtual server, does not require the virtual server to have any resources configured, such as IP interfaces, volumes, or shares.

To Enable the Virtual Server Configuration

• Run the following command from the virtual server context:vsvr enable

New or changed virtual server parameters become active when you run this command.

You can disable individual virtual servers by running the vsvr disable command. Disabling a virtual server is important for the following functions:

• Changing the setup configuration of a virtual server.

• Adding the virtual server to a domain with the vsvr set domain command.

To Disable a Virtual Server

• Run the following command from the virtual server context:vsvr disable

Displaying DNS Name Resolution for a Virtual ServerYou can display details of DNS configuration by running the system dnsconfigure show command from the context of the virtual server. This command show hosts and resolver configuration details of the virtual server.

Configuring DNS Name Resolution for a Virtual ServerThe NAS Gateway supports DNS name resolution for virtual servers through a hosts database specific to each virtual server. The NAS Gateway also supports a specific DNS resolver configuration for each virtual server.

DNS is configured on a per-virtual server basis. This includes the management virtual server. For example, for autosupport to work, you need to configure DNS for the management virtual server.

Editing the DNS Hosts DatabaseYou can configure a mapping of IP addresses to symbolic device names by running the system dnsconfigure hosts command from the context of the virtual server. This command starts a text editor and allows you to enter one or more mappings for IP


3-46

addresses. When the text editor is closed, the mapping you created is saved and name resolution can begin for the devices you added to the DNS hosts database.

To Configure a DNS Entry in the Hosts Database

Step 1: Run the following command:system dnsconfigure hosts

This command starts the vi editor for the hosts database.

Step 2: When the editor is opened, you can enter the following information separated by spaces or tab characters:

• Host IP address in dotted decimal notation

• An official host name

• An alias for the host name

Example: 192.168.10.101 rutile Server10

Note - When an NIS domain is configured for a virtual server, client host name resolution happens through an NIS server, not through DNS resolver. With local NIS maps, no NIS server exists for the virtual server, so client host name resolution does not occur for the virtual server. Therefore, configure DNS on each virtual server that is using local NIS maps.

Editing the DNS Resolver Configuration FileThe NAS Gateway supports a DNS resolver configuration file that allows you to configure different types of DNS-supported information. You can edit the resolver configuration file for the DNS-supported information with the system dnsconfigure resolver command from within the context of the virtual server.

The resolver configuration file contains a list of keyword/value pairs that provides various types of resolver information. Valid keywords for editing the resolver configuration file are:


3-47

• nameserver — Specifies the IP address of a name server for the resolver to query. When the name server is found, the IP address of that name server is displayed. You can specify up to three name servers, one per keyword. The resolver queries them in the order listed. If a query times out, the query algorithm continues to query each subsequent name server until the list of specified name servers is completed. The query algorithm then repeats the query of the name servers on the list for a maximum number of times.

• domain — Specifies the local domain name. Most queries for names within the domain accept short names relative to the local domain.

• lookup — Specifies which database to search and in which order to search. Valid keywords are: bind and file.

- If you specify bind only, the resolver search uses the domain server to search IP address-to-DNS name bindings.

- If you specify file only, the resolver searches the hosts database.

Note - When you are resolving a host name within a virtual server context, the NAS Gateway always checks the NIS domain for that virtual server first. This is done automatically; you do not have to explicitly specify this in your query.

As an alternative, you can specify the lookup keyword with no related keyword. If no keyword is specified, the resolver searches both databases, first the bind database, then the hosts database.

• search — Specifies a search list for host-name search. The search list contains a domain search path following the search keyword with spaces or tabs separating the names. The search list function supports a maximum of six domains and a total of 1024 characters. Most resolver queries search each component of the search path in turn until a match is found.


3-48

Note - The search process can take a while if the servers for the listed domains are not local. Queries will time out if no server is available for one of the domains.

To Edit the DNS Resolver Configuration File

Step 1: Run the following command:system dnsconfigure resolver

This command starts the vi editor for the appropriate file or database.

Step 2: When the editor is opened, you can enter one of the following keyword and string patterns:

• The nameserver keyword and an IP address.

• The domain keyword and an official host name.

• The lookup keyword and “bind”, “file”, “bind file” or “file bind”. For example: lookup bind to search only the bind database, or lookup file bind to search the hosts database first, then the bind database.

• The search keyword and one or more domain search paths.

You can use the system ping command with a host name to check whether you configured the resolver correctly. When given a host name, the ping utility attempts to resolve the name and prints the IP address of the host in dotted decimal notation if the resolution is successful.

Displaying Virtual ServersYou can view the state of a virtual server by running the vsvr show command. This command displays all virtual servers arranged by their virtual server ID and displays the runtime state of each virtual server.


3-49

Note - Even though virtual server names are displayed in uppercase, they are case insensitive when entered at the command prompt. Therefore, you can specify a virtual server name in uppercase or lowercase when you run any of the vsvr commands.

To Display Virtual Server Information

• Run the following command:vsvr show ([VIRTUALSERVER] [-v]|all ([-n NODE]|[-v])))


VIRTUALSERVER An optional alphanumeric character string, 1 to 15 characters long, that specifies a particular virtual server that you want to display. The following information about the virtual server is displayed:• The server’s ID number. Virtual server numbers can range

from 1 to 33 because 32 virtual servers are supported per cluster and there is also the management virtual server.

• The Windows or NIS domain in which the server is registered.

• The server’s mode. Valid modes are “unprotected” or “protected”.

• The server’s state. Valid state’s are “enabled” or “disabled”.• The IP interface the server owns.• The autocreate volume name that is exported through the

CIFS share autocreation. For more information, see “Configuring a Virtual Server with the Autocreated Shares Utility” on page 3-37.

• The autocreate path for supporting CIFS share autocreation. The path is created as part of the virtual server autocreate volume.

• The volumes owned by the virtual server.• The volumes mounted in the current virtual server’s context.


3-50

If you enter none of the optional arguments, all virtual servers configured on the current NAS Gateway are displayed.

Note - If a failover occurs, you can locate virtual servers by running the vsvr show command. This command executes on the local NAS Gateway by default.

• If you run the vsvr show command, and the virtual server is displayed, it resides on the local NAS Gateway.

• If you run the vsvr show command, and the virtual server is not displayed, it is not currently on the local NAS Gateway. Run the vsvr show all command to ensure that the virtual server is still in the cluster. You can also run the vsvr show -n NODE command against each NAS Gateway in the cluster, where NODE is the node name of an NAS Gateway.

Changing to a Different Virtual Server ContextEach NAS Gateway can contain more than one virtual server. By running the vsvr set command, you can switch the context of a virtual server. From within that context, you can configure the virtual server’s resources.

all An optional keyword that enables you to list all virtual servers configured in a cluster. When you specify the all keyword, the runtime state of each virtual server is also listed in the output.

-n NODE An optional keyword that enables you to list brief information on all virtual servers of a particular NAS Gateway.

-v Displays additional information about the virtual server, such as the failover state, the number of volumes owned by the virtual server, and the name of the NAS Gateway to which the virtual server is assigned.



3-51

Note - This command is cluster aware, so when you run the command, you can change context to any virtual server in the cluster regardless of the NAS Gateway on which the virtual server resides.

You can verify that the vsvr set command has completed by looking at the command prompt after you run the command:

• If the command completes against an existing virtual server, the command prompt contains the name of the new virtual server, and you are in the context of the new virtual server.

• If the command does not complete, the command prompt displays the name of the virtual server from which you ran the command, and you are still in the context of that virtual server or you are still in the cluster context (where the command could also have been run from).

To Change From One Virtual Server to Another Virtual Server

• Run the following command:vsvr set VIRTUALSERVER

VIRTUALSERVER is an alphanumeric character string from 1 to 15 characters.

Clearing a Virtual Server ContextYou can exit a specific virtual server’s context by clearing the context.

To Clear the Virtual Server Context

• Run the following command:vsvr clear

Note - You do not have to run the vsvr clear command before changing virtual server contexts.


3-52

This command does not delete a virtual server or release any resources configured within a virtual server. Instead, when you run this command, you return to the NAS Gateway context.

Changing a Virtual Server’s NameYou can change the virtual server’s name by using the vsvr set name generic command. This command enables you to change the virtual server name of an existing virtual server, but the NetBIOS name of the virtual server is not changed. The virtual server ID does not change when you change the virtual server name. The virtual server set name generic command has the following considerations:

• The command works only in the context of the virtual server whose name you want to change.

• The virtual server must be disabled to change the name. You can use the vsvr disable and vsvr enable commands to disable, then re-enable, the virtual server.

• The management virtual server cannot be renamed.

• The new name for the virtual server has the same restrictions as the original name you used when you created the virtual server with vsvr create:

- The new virtual server name needs to start with an alphanumeric character, with a dash ( - ) or an underscore ( _ ).

- The new virtual server name can have a maximum of 15 characters.

- The new virtual server name cannot use a name starting with “VS_MGMT”.

- The new virtual server name cannot be the reserved word all.

Note - Virtual server names are case insensitive, so the name vs1 is the same as the name VS1.

To Change a Virtual Server’s Name

Step 1: From the context of the virtual server that you want to rename, disable the virtual server by running the following command:


3-53

vsvr disable

Step 2: Change the name of the virtual server by running the following command:vsvr set name generic NAME

NAME is the new name that you are setting on the virtual server.

Step 3: Re-enable the virtual server by running the following command:vsvr enable

Note - The NetBIOS name of the virtual server won't change when you rename the virtual server. To modify the NetBIOS name, see the vsvr set name netbios command.

Moving a Virtual Server You can move a virtual server to a different single NAS Gateway or to a NAS Gateway group. Moving a virtual server to a different NAS Gateway can be useful, for example, if a hot-swap procedure is required on the NAS Gateway or for load balancing across NAS Gateways in a cluster.

Consider the following before moving a virtual server configuration:

• Know the name of the NAS Gateway that currently owns the virtual server. This NAS Gateway is called the source NAS Gateway in the following procedure.

• Display the NAS Gateway’s name by running either the cluster show group or vsvr show all command.

• Know the name of the NAS Gateway that will own the virtual server after the move. This NAS Gateway is called the destination NAS Gateway in the following procedure. You can display the NAS Gateway’s name by running either the cluster show group or vsvr show all command.

• Ensure that the IP subnets for the virtual servers you are moving are accessible from the destination NAS Gateway.


3-54

• Ensure that the destination NAS Gateway has one or more logical ports with the same name as the logical ports used by the virtual server’s interfaces. The admin and operational state of the logical ports must be UP.

• Ensure that the destination NAS Gateway has access to each volume owned by the virtual server.

• You cannot move virtual servers to a NAS Gateway in another cluster.

You can move a virtual server by running the vsvr move command. When the vsvr move command completes, the virtual server configuration, the IP interfaces, volumes, and shares configured on the virtual server are retained, but relocated to the destination NAS Gateway. After the move completes, the virtual server is in the enabled state.

To Move a Virtual Server Between NAS Gateways

Step 1: Verify the virtual server’s name and state by running the following command:vsvr show all

Step 2: Specify and set the virtual server you want to move:vsvr set VIRTUALSERVER

Step 3: To move the virtual server, run the following command:vsvr move -f DSTNASGATEWAY | -g DSTGROUP

Step 4: Verify that the virtual server has been moved to the correct NAS Gateway:vsvr show all


-f DSTNASGATEWAY Specifies the destination NAS Gateway that you want to move the virtual server to.

-g DSTGROUP Specifies the destination NAS Gateway group that you want to move the virtual server to.


3-55

Load Balancing Virtual ServersVirtual servers provide continuous file services through manual load balancing.

Note - Virtual servers do not have to be in protected mode for manual load balancing

Manual load balancing involves the following basic tasks:

1. Gather performance and operation reports from NAS Gateways and their associated virtual servers to determine capacity and load issues. See “Displaying Virtual Server Performance Statistics” on page 3-56.

2. Display performance statistics at regular intervals by using the vsvr stats command to help you make load balancing decisions. See “Displaying Virtual Server Performance Statistics” on page 3-56.

3. Move any virtual servers from one NAS Gateway to another to balance the load. See “Moving a Virtual Server” on page 3-54.

Displaying Virtual Server Performance StatisticsUse the vsvr stats command to display virtual server statistics. You can configure this command to show a scrolling display of performance statistics at regular intervals for either all virtual servers on an NAS Gateway or for a particular virtual server. To stop scrolling of the display, type Ctrl+Z. The vsvr stats command provides statistics on two types of operations: speed and throughput. Speed is measured in the number of operations per second, and throughput is measured in bytes (B), kilobytes (KB), or megabytes (MB) per second.

Speed operations on which the vsvr stats command provides statistics include:

• NFS request operations received from clients

• NFS responses successfully sent to clients


3-56

• CIFS requests received from clients

• CIFS responses successfully sent to clients

Throughput operations on which the vsvr stats command provides statistics include:

• Number of NFS B, KB, or MB per second received from clients

• Number of NFS B, KB, or MB per second sent to clients

• Number of CIFS B, KB, or MB per second received from clients

• Number of CIFS B, KB, or MB per second sent to clients

To Determine Which Virtual Servers Need to Be Moved to Create a Balanced Load

• Run the following command:vsvr stats [all|agg] [-i SECONDS][-c COUNT]


all An optional keyword that enables the display of statistics associated with all the enabled virtual servers on a particular NAS Gateway. If you don’t specify this keyword and you are in virtual server context, the command displays statistics only for that virtual server.

agg An optional keyword that enables the display of the cumulative or aggregate statistics of all the enabled virtual servers on a particular NAS Gateway. If you don’t specify this keyword and you are in virtual server context, the command displays statistics only for that virtual server.

-i SECONDS Enables you to set a refresh interval for gathering statistics. The default refresh interval is 10 seconds.

-c COUNT Specifies the number of reports to display.


3-57

Note - You can execute the vsvr stats command without the keywords all and agg only from within the context of the virtual server. If you are running the vsvr stats command with the keywords all and agg, you need to be in the virtual server context.

Deleting a Virtual Server and Its ResourcesYou can delete a virtual server by running the vsvr delete command. This command removes the virtual server and all its configurations from the database.

Before deleting the virtual server, you need to delete the volumes from the virtual server by running the volume delete command from within the virtual server’s context; otherwise, the vsvr delete command will not complete.

After you delete a virtual server, you automatically revert to the NAS Gateway context, and the resources that were associated with the deleted virtual server are now available to be assigned to another virtual server.

Note - The vsvr delete command is available from the NAS Gateway context as well as a virtual server context. The context you are in when you run this command affects whether you need to specify an argument.

• If you run the vsvr delete command from the NAS Gateway context, you need to specify the virtual server to be deleted.

• If you run the vsvr delete command from the context of a specific virtual server, you do not need to specify the virtual server name. The virtual server that has the current context is deleted.

• You cannot delete a virtual server from the context of another virtual server.

To Delete a Virtual Server and Its Resources

Step 1: As an option, delete all shares assigned to the virtual server’s


3-58

volumes by running one of the following commands:

• nfs share delete

• cifs share delete

Step 2: Delete all volumes assigned to the virtual server, by running the volume delete command against all volumes on the virtual server.

Note - If you have not yet deleted the shares, you can run the volume delete command, and it will delete the shares as part of the volume deletion process.

Step 3: As an option, you can delete all interfaces assigned to the virtual server, by running the interface delete command.

Note - If IP addresses are associated with the interface, remove them before deleting the interface. You can use the interface modify command with the -d IPADDR option to delete the IP address.

Step 4: Delete the virtual server by running the following command: vsvr delete [VIRTUALSERVER]

Step 5: When you run the vsvr delete command, the NAS Gateway prompts you for confirmation as follows:

Are you sure? [y|n]:

Type y to confirm the deletion, or type n to cancel the deletion of the virtual server.

Note - The NAS Gateway requires at least one virtual server for processing client I/O. Be sure not to delete the only virtual server in a cluster. If you do, you will isolate clients from SAN resources.


Chapter 4: Managing Storage and Fibre Channel


• “Managing Storage Ports” on page 4-6

• “Managing LUNs” on page 4-9

• “Managing the SCSI Layer” on page 4-16

Disk LUNsLogical unit numbers (LUNs) are unique identifiers in the SAN that represent granular units of storage that the NAS Gateway can control. LUNs represent the disks that the NAS Gateway needs to access for reading or writing. You cannot divide a LUN into smaller parts.

LUNs are discovered through SCSI and FC topology discovery routines. After the LUNs are discovered, the volume manager (VM) groups LUNs with specific characteristics into storage pools. LUNs are grouped in the storage pool by characteristics such as:

• Make

• Model

• RAID controller name

The VM can then create volumes out of the LUNs in the storage pools or leave LUNs in the storage pools. The volume manager (VM) does not control tape drives. As volumes are created, the NAS Gateway manages the assignment of resources out of the pool automatically. During runtime operation of the volume, the NAS Gateway tracks volume space usage and can automatically add new LUNs through the ONStor AutoGrow™ feature if more space is required in the volume. The AutoGrow feature selects only the allocatable LUNs that have the correct parameters. For example, you would get only LUNs that have the same RAID level, make, model, or that were from the same controller. You can configure LUN parameters for the AutoGrow feature.


4-2

Free LUNsFree LUNs are available to the NAS Gateway, but they have not been used for volume space. The NAS Gateway recognizes free LUNs by a label that you can instruct the NAS Gateway to put on each LUN. Free LUNs reside in the storage pool and are available for creating new volumes or for assignment to volume space if the NAS Gateway’s automatic resizing feature determines that a volume needs to grow.

Foreign LUNsForeign LUNs are not available to the NAS Gateway. The NAS Gateway typically considers LUNs foreign for two reasons:

• The LUN is new and you have not yet made the LUN available to the NAS Gateway.

• The LUN is in use by another vendor’s storage equipment.

However, you can convert foreign LUNs to free LUNs by making them explicitly available. Foreign LUNs reside in the foreign LUN pool until you label them.

Out of ClusterOut of cluster LUNs are recognized by one NAS Gateway as being claimed by another NAS Gateway that is not in the same cluster. LUNs are only available to a NAS Gateway if they are in the same cluster as the NAS Gateway.

Storage Ports and LUNsDuring initial boot the NAS Gateway automatically detects LUNs through a storage port. The storage port is the FC, or FC-compliant, transceiver, that connects an individual FC slice to the FC topology. The NAS Gateway supports two storage ports on each Fibre Channel (FC) storage processor (SP) element.

Storage ports interact with physical storage devices to discover LUNs. When physical devices are connected to the NAS Gateway through a storage port, SCSI discovery routines discover the device and its characteristics. The discovered device is virtualized and its LUNs are recorded. After a device has been virtualized, the NAS Gateway’s volume management software can use it in the EverON file system.


4-3

Initial BootAt initial boot, the FC protocol discovers the storage devices attached to the NAS Gateway, the connection types they are in, and how they can be accessed. The NAS Gateway discovers characteristics about each physical device, such as its World Wide Name (WWN), LUN ID, and relevant number of data blocks for each LUN discovered. After the initial discovery is complete, any LUN that is added or deleted from an array requires an operator intervention before the changes become known to the NAS Gateway. Once a LUN has been added to the NAS Gateway for use by the file system, care must be taken not to alter the device’s number of blocks. Never increase or decrease the number of blocks a LUN exports for use after the discovery completes. This information is passed to other software entities that process the physical device information for use by volumes or file systems.

Note - The NAS Gateway’s storage software does not discover whether blocks are used.

Addition of Physical StorageWhen physical storage is added to the SAN, that creates a SAN topology change, the NAS Gateway automatically detects the attachment point change. The detection routines are part of the FC protocol and depend on the type of topology involved:

• In arbitrated loops, the FC-AL protocol governs the arbitration of adding new devices. Through a series of notification messages passed between neighbors, the new device is added and every device reregisters. If a device is added to the arbitrated loop, the loop resets. During the reset, data transfer is momentarily interrupted. Instead of controlling the loop arbitration or reset, the NAS Gateway detects all announcing devices and puts them in a list.

• In a switch-fabric topology, the FC switch arbitrates the addition of the new device through a request-and-response sequence that forces the new device to log in to the FC switch. During the addition or deletion of storage, all devices are forced to reregister with the FC switch. The NAS Gateway participates in the registration process in the switch fabric by receiving notifications from the FC switch about new device or target. A target will normally export one or more LUN devices that can be used by the NAS Gateway and the file system. Before the NAS Gateway


4-4

can detect the available LUN devices, a SAN topology event must take place. This event will start the LUN discovery in motion for the topology change. When adding or deleting LUN devices from a target device, operator intervention will be required before the NAS Gateway will register the changes.

- In the case of Target/LUN discovery, there is one exception to the rule. If a target does not export a LUN zero, the NAS Gateway will periodically probe the target device for any changes in the number of LUN devices exported for use. This probe will only detect newly exported LUN devices, and add them to the NAS gateway. This will not detect deleted LUN devices or LUN devices that have changed in size. For that to take place, operator intervention is required. See “Managing the SCSI Layer” on page 4-16.

• After the target and LUN devices are discovered and registered, you need to label them to make them available to the NAS Gateway. After you label the LUN, the VM adds the LUN to its database of LUNs. The NAS Gateway does not automatically add this new resource to any part of available file system space. The LUN remains empty of file system space until you use it to either resize an existing volume space or create a new file system volume. Automatic resizing is initiated by the VM. If the new LUN is intended to be part of a file system, perform additional configuration as documented in “Managing Volumes” on page 6-5.

Note - Never resize an individual LUN after it is in use by the file system.

Physical Storage Going OfflineSystem or network events can cause physical storage to go offline. If a device is deleted from an arbitrated loop, the loop resets, and data transfer is momentarily interrupted.

The NAS Gateway error detection features enable it to detect an error condition and alert you to the problem. While the error condition exists, the physical storage is offline, and the NAS Gateway notes the deletion of those resources and converges on the location of the errored LUN. The NAS Gateway rediscovers the remaining storage resource locations, characteristics, and accessibility to represent an accurate picture of the SAN and its components.


4-5

Network Power CycleWhen the NAS Gateway is power cycled, it will rediscover the storage information. To ensure correct storage information, the NAS Gateway always reregisters with the SAN switches and composes a new list of LUNs when the FC restarts.


4-6

Managing Storage PortsStorage port functionality enables you to view some of the operation and performance statistics of the NAS Gateway’s FC ports. You can also enable, disable, and reset storage ports.

Displaying Storage Port StatisticsAs storage ports become active, the NAS Gateway tracks the performance and operation statistics for read and write data on each FC port on the NAS Gateway’s SP element. Each port’s statistics are entered into the port statistics table, where you can view them. The port statistics table contains general statistics about the port and traffic on it. You can view FC ports individually.

To View the Port Statistics Table

• Run the following command:port show stats PORT

PORT is one of the NAS Gateway’s storage ports. For example, sp.2.

Displaying Detailed Information About a Storage PortYou can view detailed information about port attributes for any FC port on the NAS Gateway. Detailed storage port information includes information about:

• The FC adapter type and version levels

• Interface and link state information

• SCSI tag information and FC node name and frame size information

To View the FC Ports Individually

• Run the following command:port show detail PORT

PORT is one of the NAS Gateway’s storage ports. For example, sp.2.


4-7

Displaying All Information About Storage PortsThe NAS Gateway supports a table of general information about all storage ports on an NAS Gateway. The storage port information table displays the following information about all FC ports on the SP element:

• The adapter name

• The firmware revision

• The hardware revision

• The interface type

• The link state

• The link speed

• The maximum number of SCSI tags allowed per device

• The Fibrechannel node name

• The Maximum Fibrechannel frame size allowed

• Whether SRAM parity is available

To Display the Storage Port Information

• Run the following command:port show all

Enabling and Disabling a Storage PortWhen you enable the storage port, you are not automatically setting it into a state of activity. Instead, you are causing the port to transition from disabled state to enabled state. When the port is in the enabled state, it can be in either the UP or the DOWN state:

• If the port is UP, the FC port detects a physical link and communication on the port.

• If the port is DOWN, the FC port detects no neighbor device on the link or no physical connection.


4-8

When you disable the storage port, you are not automatically setting it into a state of inactivity. The storage port is only disabled, not in DOWN mode. When the port is disabled, it is unable to support a physical layer link.

To Enable a Storage Port

• Run the following command:port enable PORT

PORT is one of the NAS Gateway’s storage ports. For example, sp.2 would enable storage port 2 on the SP element. You can also specify the keyword all to enable all ports.

To Disable a Storage Port

• Run the following command:port disable PORT

PORT is one of the NAS Gateway’s storage ports. For example, sp.2 would enable storage port 2 on the SP element. You can also specify the keyword all to enable all ports.

Resetting a Storage PortWhen the storage port is reset, a restart of the target port occurs. The port is put in the DOWN state, then transitions to the UP state.

When you reset a storage port, the NAS Gateway rediscovers the SAN. While the port is resetting, it cannot support traffic until it has reached the UP state.

This command can be helpful if there are changes in the SAN. For example, if you change a RAID in the SAN, you can reset the port to cause the NAS Gateway to discover the device.

To Reset a Storage Port

• Run the following command:port reset PORT

PORT is one of the NAS Gateway’s storage ports. For example, sp.2 would reset storage port 2 on the SP element. You can also


4-9

specify the keyword all to reset all ports.


4-10

Managing LUNsThe NAS Gateway discovers and manages LUNs automatically through the FC and SCSI protocols. This section details the LUN management functions available on the NAS Gateway.

Note - Zoning is a common practice in SANs. The NAS Gateway cannot discover or display devices that have been zoned away from it.

Displaying LUN InformationYou can display LUN information in any of the following ways:

• LUN storage availability report

• All LUNs

• LUNs associated with a specific physical device

• LUNs configured on tape devices

• LUNs configured on a specific storage port

• LUNs configured on disk devices

To Display the LUN Storage Availability Report

• Run the following command:lun show

The storage availability report organizes all devices by controller, device type, and RAID level. The report shows size and usage information of LUNs as follows:

• Size, in megabytes, of used LUN space in each device

• Size, in megabytes, of free LUN space in each device

• Size, in megabytes, of the out-of-cluster LUN in each device

• Size, in megabytes, of the foreign LUN space in each device


4-11

To Display All LUNs That the NAS Gateway Has Discovered

• Run the following command:lun show all

This command displays a list of LUNs and their configuration parameters.

To Display the LUNs Associated With a Specific Physical Device

• Run the following command:lun show device DEVICE_NAME [-n NODE]


DEVICE_NAME Specifies the name of the controller for the LUN. For example, IBM_KPZ0B663_0 indicates the RAID controller for which you want to display all the associated LUNs.

-n NODE An optional argument that allows you to sort the output of the lun show device command by NAS Gateway node name. This option is only applicable to a clustered environment.• If you enter a node name, the lun show device

command is run for all LUNs associated with a device on the specified NAS Gateway.

• If you do not enter a node name, the lun show device command is run for LUNs associated with a device on the local NAS Gateway, which is the NAS Gateway on which you run the command. By default, the lun show device command executes on the local NAS Gateway.


4-12

To Display the LUNs Configured on Tape Devices

• Run the following command:lun show tape [-c CONTROLLER] [-n NODE] [-P PAGENUMBER] [-S PAGESIZE]

To Display LUNs Configured on a Specific Storage Port

• Run the following command:lun show port PORT [-n NODE] [-P PAGENUMBER] [-S PAGESIZE]


-c CONTROLLER An optional argument that specifies the controller of the LUNs that you want to view. If you do not specify this argument, all LUNs assigned to tape devices will be displayed.

-n NODE An optional argument that specifies the NAS Gateway associated with the LUNs that you want to view. If you do not specify this argument, all LUNs assigned to tape devices will be displayed.

-P PAGENUMBER An optional argument that specifies the number of pages to display.

-S PAGESIZE An optional argument that specifies the page size in number of records to display.


PORT Specifies the storage port on which you are displaying the configured LUNs. Use an alphanumeric character string.

-n NODE An optional argument that specifies the node. Only devices that are accessible on the specified node are displayed.

-P PAGENUMBER An optional argument that specifies the number of pages to display.


4-13

To Display LUNs Configured on Disk Devices

• Run the following command:lun show disk [-c CONTROLLER] [-r RAID_LEVEL][-t STATE] [-n NODE]

Displaying the LUN TopologyYou can view the LUN topology by running the lun topology command. This command provides basic information about the discovered storage devices. With this command you can display the storage topology report, which lists the following:

• All controllers that are accessible in a cluster

• The physical device each controller governs, tape, or disk

• The nodes in the cluster

-S PAGESIZE An optional argument that specifies the page size in number of records to display.


-c CONTROLLER An optional argument that specifies the controller ID of the LUNs that you want to view.

-r RAID_LEVEL An optional argument that enables you to filter the output of the lun show disk command by RAID level.

-t STATE An optional argument that enables you to filter the output of the lun show disk command by LUN state: free, foreign, used, or outCluster.

-n NODE An optional argument for filtering the LUN list by node name. Only devices that are accessible on the specified node are displayed. The default value is local.



4-14

To Display the Storage Topology Report

• Run the following command:lun topology

Labeling and Unlabeling a LUNLUNs that contain a label have been recognized by the NAS Gateway. The label is required for enabling automatic claims through such actions as file system automatic growth. You need to explicitly apply the label for the NAS Gateway to consider a LUN as eligible for use. You can label the following types of LUNs:

• Foreign LUNs, which are discovered but not yet labeled for use by a NAS Gateway. Foreign LUNs do not contain a label, so they could be used by another storage device.

• Out-of-cluster LUNs are available to the NAS Gateway. By labeling an out-of-cluster LUN, you can assume ownership of the LUN from a NAS Gateway in a different cluster.

Note - Use caution when assuming ownership of out-of-cluster LUNs because you might loose data or destroy a volume.

To Label a LUN for the NAS Gateway’s Use

Note - A LUN must have the ONStor label for the NAS Gateway to be able to virtualize and use the LUN.

Step 1: Run the following command to locate a particular LUN:lun show disk

Step 2: Run the following command to claim the LUN:


4-15

lun label DEVICE_NAME -f [-r RAID_LEVEL] [-c CLUSTERNAME]


DEVICE_NAME Specifies the device name of the LUN that you want to label.

-f Enables you to force a label onto a LUN.

Note - This is intrusive and immediate. It can write a label on a LUN that is owned by other NAS Gateways or other clusters. When a label is forced onto a device, it can destroy volumes or data.

-r RAID_LEVEL An optional argument that enables you to configure LUNs with RAID level. If you enter the value Plain, no RAID level is configured to the LUN, and the RAID level is considered None. Enter any of the following values:• Raid-0• Raid-1• Raid-01• Raid-3• Raid-5• Plain (which indicates no RAID level)

Note - You can view the device’s RAID level by running the lun show command. If the value in the Raid Level field is None, then the LUN can be labeled and simultaneously assigned a RAID level.

Depending on the setup of your storage network, specifying a RAID level might be a required parameter.

-c CLUSTERNAME An optional argument that enables you to selectively label the LUN as part of a different cluster.


4-16

To Unlabel a LUN

Note - You can unlabel free LUNs only. When a free LUN is unlabeled, it becomes a foreign LUN. Foreign LUNs are not available to the NAS Gateway and cannot be used for automatic volume space growth.

Step 1: Run the following command and note the device name of the LUN that you want to unlabel:lun show all

Step 2: Run the following command to remove the label from the LUN:lun unlabel DEVICE_NAME

DEVICE_NAME is the identifier of the LUN that you want to unlabel. The DEVICE_NAME argument is the controller’s device name plus the LUN ID of the LUN.


4-17

Managing the SCSI Layer The NAS Gateway supports SCSI drivers and SCSI-layer discovery and management.

Initiating SCSI Discovery Storage Port and LUNsEach storage port on the NAS Gateway’s SP element is its own FC slice. Therefore, each port recognizes the SAN from a unique perspective. The SCSI layer functionality is started automatically when the SP element is booted. However, you can manually start storage port discovery with the scsi discover device command, or you can start LUN discovery with the scsi discover lun command. The storage ports remain active while the SCSI drivers are restarted and the rediscovery of the SAN devices connected on the port or LUNs completes. The neighbor devices on the NAS Gateway’s port, and any devices attached to the NAS Gateway’s neighbor’s port are discovered when discovery completes and the SAN resources are reported to the NAS Gateway by its neighbor, typically an FC switch.

To Start SCSI Discovery for New Target Devices on a Specific Port

• Run the following command:scsi discover device {all|sp.0|sp.1|sp.2|sp.3}

This command might be needed if a target device was present on the SAN at boot time. However, if no LUN devices were exported for use by the NAS Gateway at startup, the target device itself is ignored by the NAS Gateway. This command will retry the base target discovery on all targets connected to a storage port, or the SAN that the storage port is attached to.


all Initiates SCSI device discovery on all ports on the NAS Gateway’s SP element.

sp.0|sp.1|sp.2|sp.3 Selects the storage port on which you want to perform SCSI device discovery. You can specify only one port at a time.


4-18

To Start SCSI Discovery for One or All LUNs

• Run the following command:scsi discover lun {all|WWN}

This command might be needed when LUN devices on a target device have changed. A change may be an alteration of the exported LUN ID, or a change in the number of blocks a LUN shows as usable.

Warning - Never change the number of blocks exported by a LUN device after the LUN device is in use by the NAS Gateway file system.

Displaying SCSI Configuration and Device InformationYou can display the following SCSI configuration and device information:

• SCSI configuration with the scsi show config command

• Disk or tape SCSI devices or all devices with the scsi show {all|DISK|TAPE} [-P PAGENUMBER [-S PAGESIZE]] command

• SCSI statistics by device with the scsi show stats DEVNAME command

• SCSI details by device with the scsi show detail DEVNAME command

• Worldwide names of SCSI devices’ ports’ with the scsi show arraywwn command

To Display the SCSI Configuration

• Run the following command:scsi show config


all Initiates SCSI device discovery on all LUNs in the SAN.

WWN Specifies the WWN of a specific LUN to discover.


4-19

This command displays the following information about the current SCSI parameters and the device counts for each of the NAS Gateway’s FC ports:

• The SCSI Configuration and Status Information section displays the state of the Device-Path Failback feature. For more information about the SCSI failback feature, see “Enabling or Disabling the Device-Path Failback Feature” on page 4-22 and “Managing Device Path Failback” on page 4-22.

• The Device Counts section shows the devices opened on the enumerated ports and the total number of devices discovered.

When the devices are first discovered, they are kept in the storage devices list. This list contains all devices and displays configuration and state information about each device, such as:

• Each device’s WWN

• Each device’s type and model number

• The storage port that each device is available through

• Each device’s state and RAID level supported

To Display the SCSI Devices Discovered by the NAS Gateway

• Run the following command:scsi show (all | DISK | TAPE) [-P PAGENUMBER [-S PAGESIZE]]


all Displays all discovered devices. This option displays the entire storage devices list, including disk and tape devices.

DISK Displays only the discovered disk devices.

TAPE Displays only the discovered tape devices.

-P PAGENUMBER Specifies the number of the page to display.

-S PAGESIZE Specifies the page size in number of records to display.


4-20

The NAS Gateway tracks the SCSI statistics for each identified SCSI device. The statistics are counted in the SCSI statistics summary.

To Display the SCSI Statistics Summary

• Run the following command:scsi show stats DEVNAME

DEVNAME is the alphanumeric character string that specifies the disk or tape device that you want to display.

To Display Details About a SCSI Device

• Run the following command:scsi show detail DEVNAME

DEVNAME is the name of the storage device for which you want to display detailed information. Enter the device name of a disk or tape device. You can find the device name by running the scsi show all command.

The detailed display shows product information about the device that you are managing, physical device information, and logical device information.

To Display the Worldwide Names of the SCSI Devices’ Ports

• Run the following command: scsi show arraywwn [-P PAGENUMBER[-S PAGESIZE]]

-P PAGENUMBER specifies the page to display.

-S PAGESIZE specifies the page size in number of records to display.

Releasing a Reserved Tape DeviceThe NAS Gateway and other storage devices can reserve a tape device. When a reservation occurs, the tape device becomes unavailable until you clear the reservation. Although reservations and releases can occur automatically, the NAS


4-21

Gateway supports manual release operations. You can use the manual release whenever a tape drive cannot be opened or used.

To Invoke a SCSI Release of a Tape Device

• Run the following command:scsi release WWN LUN

Note - You can obtain a device’s WWN and LUN ID by running the scsi show detail command against a device name. For example, scsi show detail IBM_ECV3HM0B_0. At the bottom of the resulting output, you will see the WWN and LUN ID field.

Moving SCSI Devices to a Specific Storage PortThe NAS Gateway supports moving devices to an FC port on the SP element. By enabling you to move SAN devices, the NAS Gateway supports the following:

• Path failback for situations such as a link failure and recovery, or an array controller failure and recovery. For example, if the NAS Gateway has redundant connections to a RAID through FC ports sp.0 and sp.1. If the link on sp.1 fails, all I/O would be supported on sp.0 until the error is cleared. When the error is cleared, you can use the scsi move command to balance the I/O among storage ports by assigning some devices back to sp.1.

• Manual load balancing of device I/O across multiple ports.


WWN Specifies the world wide name of the storage device that you want to release.

LUN Specifies the LUN of the storage device that you want to release.


4-22

Note - The port setting you assign through the scsi move command is not persistent, so the port usage that you set is affected by a reboot.

To Assign Devices to a NAS Gateway Storage Port

Step 1: Run the volume show VOLNAME command against a specific volume name. In the resulting display, locate the Device Name field and note the name of the device that the volume is on.

Step 2: Run the scsi show detail NAME command and find the following information:

• The STATE field. The device must be in the OPEN state.

• The PORT field in the PATH LIST. Note the port where the device containing the LUN is located. If numerous devices are using the same port, you can move some of them to a different port.

Step 3: Run the scsi move command to rebalance the I/O by assigning devices to another FC port:scsi move DEVNAME (sp.0|sp.1)

Step 4: Run the scsi show all command and check the DEVNAME and PORT fields of the resulting list to verify that the appropriate devices have been moved to the appropriate ports.


DEVNAME Specifies the device name of the SAN device that you want to move.

sp.0|sp.1 Specifies the storage port to which to move the device. You can only specify one port at a time.


4-23

Enabling or Disabling the Device-Path Failback FeatureThe NAS Gateway selects a primary path to a storage device. If the primary path for a device fails, the device-path failback feature enables the NAS Gateway to revert back to using that preferred device path when it is restored. When a device is opened for use, the NAS Gateway selects a preferred path from the list of paths created during the device-discovery process. If this path fails, the NAS Gateway automatically selects an alternate path and directs device I/Os to that path.

To Enable or Disable the Device-Path Failback Feature

• Run the following command with the appropriate option.scsi failback [enable|disable]

Managing Device Path FailbackThe NAS Gateway supports device path failback. You can set up any storage device, a disk volume, or a tape with multiple paths to the NAS Gateway to enable device path failback. This feature is useful when a path failure occurs. It also helps to maintain load balancing across the storage ports managed by the NAS Gateway.

When a device is opened for use, the Storage Device Manager (SDM) selects a primary path from a list of paths created during the device discovery process. The SDM automatically saves the primary path to the device’s database record. The primary path is selected based on port load balancing and array preferences that have been configured by the array manufacturer.


enable Sets the device path used when service restores after a failure to be the preferred path that had been originally set. This command affects all devices on a single NAS Gateway. enable is the default setting.

disable Sets the device path used when service restores after a failure to be whatever the NAS Gateway finds upon restart during the discovery process. This command affects all devices on a single NAS Gateway. In this case, if the storage administrator wants to use the original path, the original path must be configured at the command prompt by running the scsi move command.


4-24

Note - You can manually override the automatic primary path selected with the scsi move command. For details on how to use this command, see “Moving SCSI Devices to a Specific Storage Port” on page 4-20.

If the primary path fails, the SDM automatically selects a new path from a list of alternate paths and directs device I/O to that path. When the SDM moves the device I/O to the new path, it attempts to maintain load balancing across the available NAS Gateway ports.

When the primary path is available again, the SDM automatically detects the restored primary path and reverts the device back to it. You also can move the device back to the primary path manually by running the scsi move command.

Note - Primary and alternate path configurations are lost during a device reboot.

You can enable or disable the device path failback feature with the scsi failback enable|disable command. This command enables or disables the device path failback feature for all devices connected to a single NAS Gateway.

By default, the device path failback feature is enabled in the NAS Gateway.

To Disable Device Path Failback

• Run the following command: scsi failback disable

You can check the device failback status of all devices connected to a single NAS Gateway along with additional device configuration information by running the scsi show config command.

You can check the device failback status and other configuration details of an individual device by running the scsi show detail DEVNAME command. For details see “Releasing a Reserved Tape Device” on page 4-19.


Chapter 5: Working with Network Interfaces


• “Working with Network Protocols” on page 5-2

• “Working with Management Interfaces” on page 5-4

• “Working with Logical Ports” on page 5-12


5-2

Working with Network ProtocolsThe NAS Gateway supports the following network protocols:

• Internet protocol (IP), version 4, as defined in RFC 791

• User datagram protocol (UDP) as defined in RFC 768

• Transmission control protocol (TCP) as defined in RFC 793

• Internet control message protocol (ICMP) as defined in RFC 792

• Address resolution protocol (ARP)

The NAS Gateway uses IP and higher-layer IP-based protocols for communicating with clients in the IP network and to serve users who initiate file service requests through NFS or other file access protocols.

Note - Though the NAS Gateway supports IP and IP-based protocols, it does not perform any routing of network traffic from other IP devices. The NAS Gateway supports limited static routing for packets originating from the NAS Gateway.

The NAS Gateway’s IP protocol stack operates mainly on the file processing (FP) Gigabit Ethernet ports and allows the physical and logical connection to IP-connected clients.

The NAS Gateway’s routing functionality is used to transmit and receive packets using UDP or TCP. The NAS Gateway supports Internet Control Message Protocol (ICMP) for tracking the connectability of hosts and the communication status of datagrams. Address Resolution Protocol in the NAS Gateway.

The NAS Gateway supports keep alive, traceroute, and ping packets to verify that nodes are online, and connections are available to carry data and metadata. The NAS Gateway can initiate ping and traceroute packets and receive them from a host.

For more information about sending pings, see “Pinging Another Device from the NAS Gateway” on page 16-5. For more information about performing traceroutes, see “Performing Traceroute to an IP Address” on page 16-5.


5-3

For more information about adding static entries to the NAS Gateway’s ARP table, see “Adding Entries to the ARP Table” on page 5-10.


5-4

Working with Management InterfacesManagement interfaces are automatically created on top of the system switch and controller (SSC) ports on the NAS Gateway. These ports operate at 10 or 100 Mbps depending on what bandwidth is negotiated with the peer at the other end of the management interface’s physical layer. They most commonly are assigned an IP address from a different network and used for purposes other than network traffic. For example, management interfaces can be used for configuration and management of the NAS Gateway through secure shell (SSH) connections, and are essential for high-availability configuration. Each management interface must have a unique IP address.

Note - The NAS Gateway uses the 192.168.192.0/24 network internally. Therefore, you cannot use any network address in 192.168.192.0/24 for interfaces that carry network traffic. If you attempt to assign addresses from that network space, the NAS Gateway will operate unpredictably.

Displaying Interface InformationThe interfaces table lists information about all interfaces either from the NAS Gateway or the virtual server context. One interfaces table exists for the NAS Gateway and all its virtual servers.

To Display the Interfaces Table

• Run the following command:interface show interface [-a SPEC] [-n NODE]


-a SPEC An optional argument that specifies the Gigabit Ethernet interface for which to display information. If you do not specify a port, the entire interfaces table is displayed for the NAS Gateway.

-n NODE An optional alphanumeric character string that specifies the NAS Gateway for which to display interface information.


5-5

Creating InterfacesThe NAS Gateway interfaces sc1 and sc2 are created automatically. As part of a virtual server setup you can create interfaces for the virtual server using the interface create command. For more information, see “Creating a Virtual Server and Performing Basic Setup” on page 3-7.

Modifying Interfaces and Their IP AddressesYou can use the interface modify command to add, enable, disable, or delete NAS Gateway interfaces sc1 and sc2 and their IP addresses. You can use this command in the virtual server context to modify interfaces for the virtual server. See “Modifying Virtual Server Interfaces” on page 3-12, for details on how to modify virtual server interfaces.

To modify a NAS Gateway interface, use any of the following commands from the NAS Gateway context, where INTERFACE specifies the name of the interface:

To modify a NAS Gateway interface, use any of the following commands from the NAS Gateway context, where INTERFACE specifies the name of the interface:

To Enable an Interface

• Run the following command:interface modify INTERFACE -s enable

To Disable an Interface

• Run the following command:interface modify INTERFACE -s disable

To Add One or More IP Address to the Interface

• Run the following command:interface modify INTERFACE -a IPADDR/MASKLEN [,IPADDR/MASKLEN]...

To Delete One or More IP Address From the Interface

• Run the following command:interface modify INTERFACE -d IPADDR [,IPADDR] ...


5-6

Displaying the IP TableThe IP table lists information about all the NAS Gateway’s configured IP addresses from either the NAS Gateway context or the virtual server context. One IP table exists for the NAS Gateway and each of its virtual servers.

To Display the IP Table

• Run the following command:interface show ip [-a SPEC] [-n NODE]:

Configuring Frame SizeThe NAS Gateway supports maximum transmission unit (MTU) sizes on each port. The default MTU size for the NAS Gateway’s file processing ports is 1500 bytes. You can set the MTU on a file processing port by running the port modify command. This command configures the largest unfragmented packet size for packets transmitted on the port. Packets that are larger than the MTU size are fragmented and sent in multiple packets and then reassembled at their destination.

Note - Configuring the MTU size to a value that is not supported by the switch and network can cause unexpected behavior or loss of service.


-a SPEC An optional argument that specifies the IP address for which to display information. If you do not specify an IP address, all IP addresses for the NAS Gateway are displayed.

-n NODE An optional alphanumeric character string that specifies the NAS Gateway for which to display the IP table.


5-7

To Configure the MTU Size

• Run the following command:port modify PORT [-m MTU]

Adding a RouteYou can configure routes at the NAS Gateway level or at the virtual server level. When you add a route, the route is added to the appropriate route table. Routes remain in either the NAS Gateway’s route table or a virtual server’s route table until you remove them.


MTU Specifies a numerical value, in bytes, that sets the MTU size for unfragmented packets on the port. Specify an MTU size between 1500 and 16384 bytes. The default MTU size is 1500 bytes. You can set different MTU sizes on different ports.

PORT Specifies the port on which you are setting the MTU size.


5-8

To Add a Route to the NAS Gateway’s Route Table

• Run the following command:route add {net|default} -g IPADDR [-a IPADDR/MASKLEN] [-n NODE]

Displaying the Route TableThe route table shows all routes, including default routes and network routes, that are currently configured for the current context. If a default route is present, it will appear as an all-zeroes broadcast address (0.0.0.0) in the route table.


net|default Specifies the type of route that you are adding:• net indicates a specific network route. Network routes

enable communication with a separate subnet when no routing exists between the two subnets.

• default indicates a default route to a gateway. Default routes enable communication with a destination that does not exist as a network route in the NAS Gateway’s route table. A default route always points to a network gateway so the NAS Gateway can forward packets to a next hop, where the gateway will assume further routing responsibilities.

-g IPADDR Specifies the address of the gateway router for the route. For example, 192.168.0.1.

-a IPADDR/MASKLEN Specifies the route and the mask length in bits that you’re adding. For example, 10.20.30.0/16.

-n NODE An optional command that specifies the name of the NAS Gateway on which the route is configured. This option is valid only for displaying the NAS Gateway route table.


5-9

To Display the Route Table

• Run the following command:route show [-a IPADDR/MASKLEN] [-n NODE]

Removing a RouteYou can remove a static or default route from the route table at any time. You can remove routes from either the virtual server’s route table or the NAS Gateway’s route table.

To Remove a Route From the Route Table

• Run the following command.route delete {net|default} -g IPADDR [-a IPADDR/MASKLEN] [-n NODE]


-a IPADDR/MASKLEN Specifies the IP address and mask length, for the route table you want to display. For example, 10.20.30.0/24.

-n NODE Specifies the name of the NAS Gateway on which to display the route table. This option is valid only for displaying route information in the NAS Gateway route table.


net|default Specifies whether to delete a network or default route.

-g IPADDR Specifies the address of the gateway router for the static route.

-a IPADDR/MASKLEN Specifies the static route and mask length in bits that you are deleting, for example, 10.20.30.0/24.

-n NODE An optional alphanumeric string that specifies the NAS Gateway on which you are deleting the route. This option is valid only for removing a route from the NAS Gateway route table.


5-10

Adding Entries to the ARP TableThe NAS Gateway supports ARP and maintains ARP tables at the NAS Gateway level and at the virtual server level. Because virtual server boundaries are enforced, you cannot see another virtual server’s ARP table from the context of a different virtual server.

You can manually add an ARP entry into the NAS Gateway’s or virtual server’s route table. When you add an ARP entry to the ARP table, you specify the six-bit MAC address of the far-end device. This MAC address enables the NAS Gateway to resolve a MAC address to an IP address.

To Manually Add an ARP Entry Into the ARP Table

• Run the following command:arp add IPADDR -a MACADDR [-n NODE]

Displaying the ARP Table

The ARP table contains all the resolved ARP transactions for all interfaces in the NAS Gateway or a virtual server. When you view the ARP table, you see manually added entries as well as dynamically added entries. You can view the ARP table for the NAS Gateway or for a virtual server depending on what context you are in.


IPADDR Specifies the IP address of the ARP entry you are adding.

-a MACADDR Specifies the MAC address of the device at the far-end of a physical link.

-n NODE An optional alphanumeric string that specifies the NAS Gateway where the ARP entry is added. This option is valid only for adding an ARP entry to the NAS Gateway ARP table.

cluster1-4> arp add 10.1.1.89 -a 00:01:d2:c3:a4:21 -n cluster1-3cluster1-4>


5-11

To View the ARP Table for the NAS Gateway or a Virtual Server

• Run the following command:arp show [-a IPADDR] [-n NODE]

Removing Entries from the ARP TableDeletes an ARP entry from any node within the cluster.

To Remove an Entry from the ARP Table

• Run the following command:arp delete IPADDR [-n NODE]


-a IPADDR An optional argument that specifies the IP address of an interface for which you want to view the ARP information. If you do not use the optional IPADDR argument, the entire ARP table is displayed.

-n NODE An optional argument that specifies the NAS Gateway on which you want to display the ARP table. This option is valid only for displaying an entry in the NAS Gateway ARP table.


IPADDR Specifies the IP address associated with the ARP entry that you want to remove.

-n NODE An optional alphanumeric character string that indicates the NAS Gateway from which you want to delete the ARP entry. This option is valid only for deleting an entry in the NAS Gateway ARP table.


5-12

Working with Logical PortsThe NAS Gateway supports logical ports. Logical ports are logical constructions that enable you to group physical links so that they appear as one single port. By doing so, you gain redundancy through configuration, because the NAS Gateway can recover from port or link failure.

Interfaces use logical ports. Multiple interfaces can use the same logical port, but one interface can use only one logical port.

Logical ports exist in the network stack and enable link-layer configuration and flexibility in network wiring.

The NAS Gateway supports two types of logical ports:

• Standard logical ports are created out of one or more child physical ports. For more information, see “Understanding Logical Port Operation Modes” on page 5-12.

• Stackable logical ports are created out of one or more logical ports. For more information, see “Understanding Stackable Logical Ports” on page 5-22.

Understanding Logical Port Operation ModesThe NAS Gateway’s logical port feature operates in one of three modes: failover, aggregation, or single.

• In failover mode, only one active physical port of the logical ports carries traffic. Other physical links on the logical ports are available to carry traffic, but only if the active link becomes unavailable. When the active link state changes to DOWN, the live backup link can assume operation as the new active physical link, and continue carrying traffic after a switch over. During switch over, packet retransmission occurs through TCP or UDP.

Note - After setting the port preference, the preferred port becomes the active port for the logical port as long as the preferred port is UP. For more information about setting the link preference, see “Setting Path Preference for a Logical Port” on page 5-24.


5-13

• In aggregation mode, all physical links in the logical port are considered active and carry traffic simultaneously. In link-aggregated configuration, the traffic is load balanced across all physical links that are associated with the logical port. Link aggregated mode provides redundancy by load balancing traffic across remaining active links if one link goes into the DOWN state.

Note - To support aggregation mode, EtherChannel or another trunking method needs to be configured on the switch to which the physical ports are connected.

• In single mode, only one physical port exists. It can be used as a way to rename the default logical port.

NAS Gateway

CIFS/NFS

Route TableARP Table

IP

Link Layer

Virtual Server “Eng”

UDP TCP

CIFS/NFS


IP

Virtual Server

UDP TCP

CIFS/NFS


IP

Virtual Server

UDP TCP

Interfaces

Logical Ports

Physical Ports

Figure 5-1 NAS Gateway Network Stack Showing Logical Port Layer


5-14

As shown in Figure 5-1, logical ports exist at the NAS Gateway level and are associated with virtual servers. Because the interface is associated with the virtual server, it fails over to a new NAS Gateway whenever the virtual server fails over.

However, the logical ports themselves belong to the NAS Gateway and do not fail over. Therefore, for a virtual server to successfully fail over from one NAS Gateway to another, the new NAS Gateway should have all logical ports required by all the interfaces in the virtual server. During a virtual server failover, the NAS Gateway checks for the following:

• The existence of a logical port with required names

• The link state of the logical port

The NAS Gateway does not check the logical port’s mode (single, failover, or aggregation).

Table 5-5 and Table 5-6 are examples of two NAS Gateways (A and B) in which the logical port configuration is not viable for virtual server failover.

Table 5-5: Logical Port Configuration on NAS Gateway A

Virtual Servers Logical Port Name

Logical Port Mode Physical Ports

vs-0 lp0 aggregate fp.0, fp.1

vs-0, vs-1 lp1 single fp.2

vs-2 lp2 single fp.3

Table 5-6: Logical Port Configuration on NAS Gateway B

Virtual Servers Logical Port Name

Logical Port Mode Physical Ports




5-15

In the previous configuration, vs-2 can run on NAS Gateway A. It cannot be failed over to NAS Gateway B because logical port lp2 does not exist on NAS Gateway B.

For successful virtual server failover, make sure that all NAS Gateways have logical ports with the same name. There is no restriction on the type of logical port and the physical port contained in the logical port, which relaxes wiring/cabling requirements. Consider the following example of two NAS Gateways, A and B. Table 5-7 and Table 5-8 list the logical port configuration of each NAS Gateway.

On NAS Gateway A, ports fp.0 and fp.1 are connected to network1 whereas on NAS Gateway B fp.0 and fp.1 are connected to network2.

On NAS Gateway A, lp1 is in failover mode whereas on NAS Gateway B lp1 is of type aggregate.

Creating a Logical PortWhen creating a logical port, consider the following:

Table 5-7: Logical Port Configuration on NAS Gateway A

Logical Port Name

Logical Port Mode Physical Ports Physical Network

lp0 aggregate fp1.0, fp1.1 network 1

lp1 fail-over fp1.2, fp1.3 network 2

Table 5-8: Logical Port Configuration on NAS Gateway B

Logical Port Name

Logical Port Mode Physical Ports Physical Network




5-16

• A default logical port or user-defined logical port that is already in use by an interface cannot participate in a logical port.

• A default logical port cannot participate in multiple logical ports. For example, default logical port fp.0 cannot be configured in both logical port1 and logical port2.

You can create a standard or stackable logical port by running the lport create command. The difference is in the type of port you use to complete the -a PORTS argument:

• If you use a default logical port for the -a PORTS argument, you will create a standard logical port. See “Understanding Logical Port Operation Modes” on page 5-12.

• If you use a user-defined logical port for the -a PORTS argument, you will create a stackable logical port. See “Understanding Stackable Logical Ports” on page 5-22.

Note - If a port on the NAS Gateway changes to the DOWN state, it does not transition to the UP state unless the state of autonegotiation on the NAS Gateway matches the state of autonegotiation on the peer device on the link. For example, if a port goes offline, and the port’s autonegotiation state is set to OFF when the peer device on the other end of the link has autonegotiation set to ON, the NAS Gateway’s port does not come back online because of this mismatch.

Ensure that the port and peer device are both set to the same autonegotiation state. To set the autonegotiation state of a port, run the port autoneg command.

The lport create command must have at least one default port. The command cannot have more than:

• Four default logical ports for a standard logical port.

• Four logical ports for a stackable logical port.


5-17

To Create a Standard Logical Port

• Run the following command:lport create LPORTNAME -m {single|failover|aggregation} -a PORTS -s {enable|disable}


LPORTNAME Specifies the logical port you are adding by using an alphanumeric character string.

-m single|failover|aggregation

Indicates the mode in which the logical port should operate. • single configures the logical port with a standard single port. • failover causes the logical port to operate in failover mode.

By default, the NAS Gateway assigns the first default logical port configured as the preferred logical port. However, you can change the preferred logical port by running the lport prefer command.

• aggregation causes the logical port to operate in link aggregation mode.

Note - To support aggregation mode, EtherChannel or another trunking method has to be configured on the switch to which the physical ports are connected.

-a PORTS Specifies the default logical ports that are being created. You can specify multiple default logical ports by separating them with commas, for example, fp.0,fp.1. The -a PORTS argument must have at least one default logical port specified, but no more than four.

-s enable|disable Specifies whether the logical port is enabled or disabled regardless of what mode of logical port you are creating. You can modify the state of the logical port by running the lport modify command.


5-18

Load Balancing on IP Interfaces with Logical PortsLoad balancing on the NAS Gateway Gigabit Ethernet IP interfaces is supported through logical ports. Load balancing support on a logical port requires the following prerequisites:

• Create the logical port in aggregation mode.

• The NAS Gateway must have two or more Gigabit Ethernet ports that connect to Gigabit Ethernet ports on a switch, and must be in the same subnet.

• Connect the logical port to a switch that supports EtherChannel.

• Configure the EtherChannel switch needs. The switch is doing the load balancing.

Note - Logical ports have been tested for interoperability with Cisco Systems 3500, 4000, and Extreme Networks 5i and 7i series switches only.

Cisco Systems Switch Connectivity ExampleFor illustration purposes, assume the following:

• The switch to which you are connecting is a Cisco Systems 3508.

• The 4440 model NAS Gateway’s two file processing (FP) ports are ports fp1.0 and fp1.1 and the ONStor Bobcat 2200 series NAS Gateway’s two FP ports are ports fp.0 and fp.1.

• These ports connect to the Cisco 3508 Gigabit Ethernet ports 1 and 6.

To Support Load Balancing on a Cicso 3508 Switch

Step 1: Configure the Cisco 3508 switch, for example:cisco3508r30#config term

Enter configuration commands, one per line. End with CNTL/Z.

cisco3508r30(config)#interface gigabitEthernet 0/1

cisco3508r30(config-if)#port group 1

cisco3508r30(config-if)#exit

cisco3508r30(config)#interface gigabitEthernet 0/6


5-19

cisco3508r30(config-if)#port group 1 distr source

cisco3508r30(config-if)#end

cisco3508r30#show running-config

interface GigabitEthernet0/1

port group 1

!


!


!


!


!


port group 1

!


!


!

The switch’s port 1 and port 6 have been configured as part of a port group. Therefore, the switch distributes the traffic on these two output links based on the source media access control (MAC) address of the clients.

Step 2: On the NAS Gateway, create the logical ports in aggregation mode by running the lport create command. For example, to create a logical port named “lp1.0” on the NAS Gateway and associate physical ports to the logical port, you would enter:


5-20

lport create lp1.0 -m aggregation -a fp1.0,fp1.1

lp1.0 is the name of the logical port that you are creating.

-m aggregation is the mode that you are configuring for the logical port.

-a fp1.0,fp1.1 is the comma-separated list of physical ports that you are associating with the logical port.

Step 3: On the NAS Gateway, configure the IP address that the logical port’s physical ports will share, by running the interface create command. For example, to configure 11.111.22.11 as the IP interface to be shared on “lp1.0”, run: interface create intname -l lp1.0 -a 11.111.22.11/16

intname is the name of the virtual interface to which you are adding an IP address.

-l lp1.0 is the name of the logical port to which you are adding an IP address.

-a 11.111.22.11 is the IP address and /16 is the subnet mask.

Extreme Networks Switch Connectivity ExampleFor illustration purposes, assume the following:

• The switch to which you are connecting is an Extreme Networks 5i.

• The 4400 model NAS Gateway’s two FP ports are ports fp1.0 and fp1.1 and the ONStor Bobcat 2200 series NAS Gateway’s two FP ports are ports fp.0 and fp.1.

• These ports connect to the Extreme Networks 5i Gigabit Ethernet ports 1 and 6.

To Support Load Balancing on an Extreme Networks 5i

Step 1: For configuration on the Extreme Networks 5i, use the following syntax:enable sharing MASTER PORT NUMBER grouping RANGE OR LIST OF NUMBERS algorithm round-robin

On the Extreme Networks 5i switch, this command appears as shown in the following example:


5-21

enable sharing 1 grouping 1,6 algorithm round-robin

To show the Extreme Networks 5i switch configuration, run the following command:show ports configuration

To disable the Extreme Networks 5i switch, run the following command:disable sharing 1

Step 2: On the NAS Gateway, create the logical ports in aggregation mode by running the lport create command. For example, to create a logical port named “lp1.0” and associate physical ports to the logical port, you would enter:lport create lp1.0 -m aggregation -a fp1.0,fp1.1

-l lp1.0 is the name of the logical port that you are creating.

-m aggregation is the mode that you are configuring for the logical port.

-a fp1.0,fp1.1 is the comma-separated list of physical ports that you are associating with the logical port.

Step 3: On the NAS Gateway, configure the IP address that the logical port’s physical ports will share, by running the interface create command. For example, to configure 11.111.22.11 as the IP interface to be shared on “lp1.0”, run: interface create intname -l lp1.0 -a 11.111.22.11/16

intname is the name of the virtual interface to which you are adding an IP address.

-l lp1.0 is the name of the logical port to which you are adding an IP address.

-a 11.111.22.11 is the IP address and /16 is the subnet mask.


5-22

Understanding Stackable Logical Ports The NAS Gateway supports stackable logical ports, which you can use to create a parent logical port out of child logical ports. Stackable logical ports operate similar to standard logical ports. See “Understanding Logical Port Operation Modes” on page 5-12.

Before you can create stackable logical ports you need to create single or aggregation logical ports.

Consider the following illustration of configuring a failover parent logical port out of two child logical ports configured to use two physical Gigabit Ethernet ports in link aggregation mode. See Figure 5-2 on page 5-22. No single point of failure exists.

Note - Both switches must be in the same subnet.

Figure 5-2 Configuring a Failover Logical Port out of Child Logical Ports

Gigabit Ethernet Switch Gigabit Ethernet Switch

Connect to 2 switchesfor failover

fp1.0 fp1.1 fp1.2 fp1.3 Gigabit Ethernet ports

Logical Port A Logical ports with link

Logical port with failover

NAS Gateway A

Logical Port B

Logical Port AB across logical ports A and B

aggregation


5-23

Note - Not all combinations of logical ports are permitted. Currently the following restrictions apply to forming a logical port using other logical ports:

• To form a single logical port, use only the ports fp1.0 through fp1.3.

• To form an aggregate logical port, use single ports only.

• Do not use failover ports to form a failover logical port

• Parent logical ports can only be in failover mode. Children ports can only be in single or aggregation mode.

Creating Stackable Logical PortsCreates a logical port of specified mode and ports or lports.

To Create a Stackable Logical Port

• Run the following command:lport create LPORTNAME -m {single|failover|aggregation} -a PORTS -s {enable|disable}


LPORTNAME Specifies the name of the logical port you are adding by using an alphanumeric character string.


5-24

Setting Path Preference for a Logical PortThe NAS Gateway supports a preferred path for failover logical ports only. The preference value you assign determines which one is the preferred path to carry traffic.


Indicates the mode in which the logical port should operate. • single configures the logical port with a standard single port. • failover causes the logical port to operate in failover mode.

By default, the NAS Gateway assigns the first logical port configured as the preferred logical port. However, you can change the preferred logical port by running the lport prefer command.


Note - To support aggregation mode, EtherChannel or another trunking method has to be configured on the switch to which the physical ports are connected.

-a PORTS Specifies the logical ports to be used as children. You can specify only two logical ports separated by a comma, for example, lport1, lport2.

-s enable/disable Specifies whether the logical port is enabled or disabled regardless of what mode of logical port you are creating. You can modify the state of the logical port by running the lport modify command.



5-25

To Set a Logical Port Preference

• Run the following command:lport prefer LPORTNAME -a PORT

Modifying a Logical PortYou can modify an existing logical port by running the lport modify command. When you modify a logical port, you can:

• Change the mode of the logical port.

• Add up to four ports to the logical port. When adding one or more ports to the logical port, the ports you are adding cannot belong to another logical port.

• Delete ports from the logical port.

• Change the administrative state of the logical port.

The lport modify command does not complete unless you specify at least one of the arguments.

Options and arguments Description

LPORTNAME Specifies the failover logical port on which you are setting the preferred link by using an alphanumeric character string.

-a PORT Specifies the preferred path for carrying traffic on a failover logical port. You can specify the name of the default or user-defined logical port to be the preferred port. You can specify only one logical port link with this argument.


5-26

To Modify a Logical Port

• Run the following command:lport modify LPORTNAME [-m {single|failover|aggregation}] [-a PORTS] [-s {enable|disable}]

Displaying Logical Port InformationThe NAS Gateway keeps a list of all the logical ports and their associated physical links in the logical ports table. The logical ports table contains each logical port and provides information about how the logical port is configured and operating.


LPORTNAME Specifies the logical port you are modifying by using an alphanumeric character string.


Determines the mode that you are setting on the logical port. • single configures the logical port with a standard single

port. • failover causes the logical port to operate in failover mode.

By default, the NAS Gateway assigns the first logical port configured as the preferred logical port. However, you can change the preferred logical port by running the lport prefer command.


-a PORTS Specifies which ports are being added to or deleted from the logical port. Ports can be default logical ports or user-defined logical ports. If you specify multiple logical ports, separate them with commas.

-s enable|disable Changes the state of the logical port to either enabled or disabled. If a logical port’s state is changed, the state change is applied to all interfaces of all virtual servers using the logical port.


5-27

To Display the Logical Ports Table

• Run the following command:lport show [LPORTNAME][-n NODE]

Deleting a Logical PortThe NAS Gateway supports deleting a logical port. When you delete a logical port, no IP interface can be associated with the logical port.

Note - If you need to first delete the interfaces associated with the logical port, you do so by running the interface delete command.

To Delete a Logical Port

• Run the following command:lport delete LPORTNAME

LPORTNAME is an alphanumeric character string that specifies the logical port you are deleting.


LPORTNAME An optional alphanumeric character string that names the logical port you are displaying. • If you do not specify a logical port, all logical ports are

displayed.• If you specify a logical port, then detailed information about

the logical port is displayed, such as the administrative state, the operational state, the list of ports, preferred port (if the mode is failover), and the list of interfaces using this logical port.

-n NODE Displays all logical ports of a NAS Gateway.


5-28


Chapter 6: Managing Volumes and File Systems


• “Introduction to Volumes” on page 6-2

• “Managing Volumes” on page 6-5

• “File System Statistics” on page 6-24


6-2

Introduction to VolumesThe NAS Gateway builds its file system from volumes that are created by LUNs. The following types of volumes can exist on the NAS Gateway, depending on their use:

• File system volumes, also called standard volumes. This type of volume contains a file system and provides the user a way to make their file system data accessible.

• Mirror volumes are used by the NAS Gateway’s Data Mirror mirroring application. You can mount a mirror volume only as a read-only volume. For more information, see “Working with ONStor Data Mirror” on page 13-1.

• Core volumes are used to receive and temporarily hold NAS Gateway core dumps if the NAS Gateway crashes. The core volume is not mountable. Any core data is copied from the core volume to the management volume from where you can retrieve it. One core volume exists on each NAS Gateway. For more information, see “Working with Core Dumps” on page 16-34.

• Management volumes exist within management virtual servers. This volume provides a repository for temporary files (for example, during NDMP backup and restore sessions), and for administrative tasks, such as receiving core dump files when they are copied from the core volume. One management volume exists on each NAS Gateway.

Volumes and Virtual ServersVolumes are associated with virtual servers and, therefore, you need to configure them from within the context of a virtual server. For more information about virtual servers, see “Working with Virtual Servers” on page 3-1.

Understanding the Management Volume The management volume operates like any other volume. It contains management data, but it can also contain user data. You need to explicitly create the management volume by running the system create mgmtvolume command.

The management volume has the following considerations:

• It exists within the management virtual server and, therefore, you need to configure it within the context of the management virtual server. For more


6-3

information about the management virtual server, see “Understanding the Management Virtual Server” on page 3-4.

• It always has the name string vol_mgmt_XXXX. Where XXXX is the same numerical identifier as the management virtual server in which it is configured.

• You need to configure it on an array.

• You can configure it with volume AutoGrow parameters.

• You can modify it and its AutoGrow parameters through the volume modify command.

Creating a Management VolumeThe management volume is created within the management virtual server. The management volume operates like a standard volume in regards to volume features such as AutoGrow.

To Create a Management Volume

Step 1: Run the following command to display the management virtual server:vsvr show all

The management virtual server contains the name string “VS_MGMT_”. Note the full name of the management server including its number. You will use the management virtual server name in the next step.

Step 2: Switch to the management virtual server by running the following command:vsvr set VS_MGMT_4353

Step 3: Configure an IP address for the management virtual server by running the following command:interface create fp1.0 -l lp.0 -a 10.123.48.101

Step 4: Run the following command from within the context of the management virtual server to create the management volume. Specify the array on which the management volume will be


6-4

created. For example, to create the management volume on the array “IBM_ECV5TUHB” within the management virtual server vs_mgmt_4353, you would run the following command: system create mgmtvolume IBM_ECV5TUHB

This creates the management volume name string. The management volume name string is always vol_mgmt_XXXX where X is the same number string as the management virtual server.

Note - This step creates the management volume with default usage and AutoGrow parameters, but you can configure custom parameters. For more information about the volume usage and AutoGrow parameters, see “Creating a Volume” on page 6-5.


6-5

Managing VolumesAlthough volumes and their associated physical storage and file systems are managed automatically in runtime, you need to configure the volume space policy that the NAS Gateway uses.

Creating a VolumeWhen creating and managing volumes, consider the following:

• Smaller volumes facilitate and expedite maintenance.

• Smaller volumes are more flexible and efficient for snapshots, mirrors, and other file system services.

• Smaller and more focused volumes are more easily managed because the amount of data contained in more focused volumes is less than in one larger volume.

Note - When you create a volume, assign it an alphanumeric name string of no more than 127 characters.

Volumes are created within the context of a virtual server. To configure a volume, the minimum required parameters are the volume name and the array or device name on which it is configured. Additional parameters you can configure are disk usage conditions for triggering the volume AutoGrow feature, and LUN characteristics for creating or AutoGrow the volume with compatible LUNs.

Before creating a volume, ensure that the following conditions exist:

• One or more LUNs must be labeled. See “Labeling and Unlabeling a LUN” on page 4-14 for details.

• A virtual server must exist because you create a volume within a virtual server. See “Configuring a Virtual Server for a File System Protocol” on page 3-41 for details.


6-6

To Create and Configure a Volume

• Run the following command:volume create VOLNAME ARRAY [-A ATIMEUPDATES] [-c CHARSUBST] [-e SHAREDREAD] [-g MINAUTOGROW] [-h HIGHWATERMARK] [-l MINLUNSIZE] [-L LANGUAGE] [-m] [-o OPLOCKS] [-q HARDQUOTA][-r RAIDLEVEL] [-s SOFTQUOTA] [-t CHARSUBSTTABLE] [-u MAXLUNSIZE] [-j SECURITYTYPE]


VOLNAME Specifies the name of the volume you are creating. Volume names can be any alphanumeric character string of up to 127 characters.

ARRAY Specifies the name of an array or device from which the volume obtains LUNs, or a specific device name. • An array name is a string that consists of a

make_serial#. For example, IBM_60432. You can also use part of the array name, for example, I to select all IBM arrays, IBM_6 to select all IBM arrays with a serial number that starts with 6, or IBM_60432_ to select any LUN in the specific array IBM_60432_. If you use this method and multiple arrays fit the criteria, a LUN is used from the first array in the list.

• A device name is a string that consists of make_serial#_LUN. For example, IBM_60432_255.

-A ATIMEUPDATES An optional argument that disables or enables the automatic last access time updates option. When enabled, the file system automatically updates the last access time on files and directories when they are read. When disabled, the last access time is only updated when an NFS or CIFS client explicitly sets the time stamp. Enabling this option increases the file system update load, but enables clients to see which files are being used. The default is enabled.


6-7

-c CHARSUBST An optional argument that sets the CIFS illegal character substitution option to enabled or disabled. When enabled, if NFS creates a filename with the illegal characters, which are "*:<>?\|, then the NAS Gateway automatically substitutes a list defined by CHARSUBSTTABLE. The value for CHARSUBST can be “enabled” or “disabled”. By default, the CHARSUBST is “disabled”. You cannot set this to enabled without also providing a value for CHARSUBSTTABLE.

-e SHAREDREAD An optional argument that specifies the state of the CIFS “no shared read” open flag for the volume. This flag is read by NFS requests, and the state you set affects whether NFS clients can access files on the volume. You can set this variable to allow or disallow. By default, the shared read is allowed. Specify the shared read argument with the following construction:• -e sharedread=allow permits NFS requests to ignore

the “no shared read” flag. NFS requests are allowed, and NFS clients are able to read files on the volume.

• -e sharedread=disallow causes NFS requests to respect the “no shared read” flag. NFS requests are not allowed, and NFS clients are not permitted to read files on the volume.

-g MINAUTOGROW An optional argument that specifies the smallest amount of storage that the volume can automatically grow if it needs more space. Enter the volume’s absolute maximum size in MB. If you set this argument to 0 there is no minimum limit, so the NAS Gateway can get a chunk of disk space that is any size. The default value is 500 MB.



6-8

-h HIGHWATERMARK An optional argument that enables the AutoGrow feature for the volume. It specifies the trigger that causes the volume space to grow by the amount specified in the MINAUTOGROW argument. Enter the value as a percentage of the total amount of currently allocated space. The NAS Gateway uses the percentage of total used space to calculate the actual amount of disk space required. Set the high water mark to a value between 25% and 100%. If you set the value to zero (0), then automatic volume space growth is disabled.Default value: 0, no threshold is set for automatic volume space growth.

-j SECURITYSTYLE Controls the security style supported by the file system. When creating a new filesystem object, any supplied security information will be honored only if the filesystem security style matches the style of the security information. Otherwise, security information from the parent directory is inherited. Possible values are: normal, nfs, cifs, and cifsWithSilentNfsFailures.• When set to normal, both NFS and CIFS security styles

are supported. While an object can have only one form of security style at any point, it is set by the last protocol that created or modified it.

• When set to nfs, setting CIFS ACLs will not be supported.• When set to cifs, any attempt to change security

information by NFS will be ignored.• When set to cifsWithSilentNfsFailures, any attempt to

change security information by NFS will appear to be successful, but no change is made to the security information.

-l MINLUNSIZE An optional argument that specifies the smallest LUN to be used in AutoGrow. Set this argument to 0 (the default) to allow any size of LUN to be used.

-L LANGUAGE Specifies the language code that you are using to create the volume. For a list of language codes, use the online help by running the help volume create command.



6-9

-m Creates the volume as a mirror volume.

-o OPLOCKS An optional argument that specifies whether CIFS requests are permitted to obtain OPLOCKS (opportunistic locks) on files. The values for this option are allow and disallow. When allowed, CIFS requests are permitted to obtain oplocks on files. When disallowed, no CIFS oplocks are granted.The default value for OPLOCKS is allow. Ensure that the volume is online before setting this option.

-q HARDQUOTA An optional argument that specifies the hard quota, which is the maximum size of the volume. Enter the volume’s absolute maximum size in 1 MB blocks. Set this argument to 0 (the default) if you want unlimited growth for the volume.

-r RAIDLEVEL An optional argument that specifies the RAID level of the LUNs that will be used to create the volume. The NAS Gateway supports RAID 0, 1, 0 + 1, 3, and 5. Specify the RAID level as the word RAID plus a dash, then the RAID level. For example, you would enter the strings “RAID-0+1”, “RAID-3”, or “RAID-5” (minus the quotation marks) for the corresponding RAID levels. By default, the NAS Gateway does not pay attention to RAID level, it just builds the volume on the first available LUN on the specified array. Therefore, if you want to create a volume out of LUNs of a specific RAID level, you need to specify the RAID level.

Note - If you also configure volume AutoGrow parameters, the AutoGrow uses only LUNs of the same RAID level. Therefore, if you are creating a volume with LUNs of a specific RAID level and you also want to configure AutoGrow for the volume, you need to have some unused LUNs of the same RAID level. Otherwise, AutoGrow will not find an available LUN of the same RAID level to add to the volume.



6-10

Adding Arrays to a VolumeYou can add up to eight arrays to a volume by following this procedure.

To Add Arrays to a Volume

Step 1: Run the following command to list the created volumes:volume show

Step 2: From the resulting output, locate the volume that will receive the additional arrays and note the volume name.

Step 3: Run the lun show command and find the names of the arrays that you want to add.

Step 4: Add up to eight arrays to the volume by running the following command:

-s SOFTQUOTA An optional argument that specifies a percentage of the hardquota. When the volume usage equals or exceeds the percentage you specify, another free LUN is taken and added to the volume. An Elog message is posted on the management console when the soft quota triggers the addition of another LUN to the volume. Enter a percentage value from 1 to 100. The default value is 0, which means that the NAS Gateway does not track the softquota value.

-t CHARSUBSTTABLE An optional argument that sets the CIFS illegal character substitution table. CHARSUBSTTABLE is a comma-delimited list of 2-byte Unicode values in hexadecimal format to be substituted for the characters “*:<>?\ /, for example, FF82,FF89, FF8A, FF8C, FF8E, FF8F, FF7F, and FF88.

-u MAXLUNSIZE An optional argument that specifies the size of the LUN to be used in AutoGrow. Set this argument to 0 (the default) to allow any size of LUN to be used.



6-11

volume add array VOLNAME ARRAY

Deleting Arrays From a VolumeYou can delete arrays from a volume by running the volume delete array command.

Note - If a volume is contained in part or in whole on an array, the NAS Gateway will not allow this command to complete. The volume delete array command will complete only if the array contains none of the volume’s data. If you want to delete an array that does contain some or all of the volume’s data, run the volume delete command to delete the volume’s data. Running the volume delete command will immediately delete all of the volume’s data.

To Delete a Volume From An Array

Step 1: Run the following command to list the created volumes:volume show

Step 2: Locate the volume that will have its arrays deleted and note the volume name.

Step 3: Delete the arrays from the volume by running the following command:


VOLNAME Specifies the name of the volume to which you are adding an array. Volume names can be a maximum of 127 characters.

ARRAY Specifies a list of controller names for one or more arrays from which the volume will obtain its LUNs. You can enter a single array name. Enter the controller names as shown in the lun show command.


6-12

volume delete array VOLNAME ARRAY

Assigning a Volume to a Virtual ServerAssign a volume to a virtual server only if the volume is not already associated with a virtual server. For example, if the NAS Gateway configuration is lost or becomes corrupted, you can use this command as part of the recovery process for the NAS Gateway. Restart the NAS Gateway restarted after the recover process.

Note - You cannot assign a volume that is already assigned to a virtual server. To determine whether a volume is currently owned by a virtual server, run the volume show command. If the Virtual Server column is empty, the volume is not assigned to a virtual server.

To Assign a Volume to a Virtual Server

• Run the following command:volume add vsvr VOLNAME VIRTUALSERVER


VOLNAME Specifies the volume you are deleting.

ARRAY Specifies a list of device names that you will be deleting from the volume. You can enter a single array name, or a comma separated array list up to a maximum of eight arrays. Enter the device names as shown in the lun show command.


VOLNAME Specifies the existing volume to be assigned to the virtual server. The volume name can be from 1 to 127 characters.

VIRTUALSERVER Specifies the virtual server to assign to the volume.


6-13

Displaying Volume InformationThe NAS Gateway tracks all the configured volumes for usage information. The configured volumes are displayed in the volumes table regardless of the volume’s operational state. You can display a listing of all volumes or you can display detailed information about a specific volume.

The volume table displays a listing of all volumes with the following information:

• Status information for each volume. Valid values for volume status are:

- Online

- Mounted

- Mounted-RO, for a volume that is mounted read-only (for example, a mirror volume)

- Paused

- NotMounted

- Unmounting

- Failing

- Offline

• Type information, such as whether the volume is configured as a standard file system volume for file system data, or a mirror volume for receiving file system data as the result of a mirroring operation.

• Usage information in MB, such as the current volume size, hard quota, amount of space used, and amount of space available. The percentage of used space compared to available space is also displayed.

• Virtual Server information, which indicates the virtual server that contains the volume.

Displaying the volume table for a specific volume, shows the following information:

• Status information, such as whether the volume is mounted, online, or offline.

• Virtual Server information, which indicates the virtual server that contains the volume.


6-14

• Volume ID information, which is used for NAS Gateway internal computations.

• Type information, such as whether the volume is configured as a standard file system volume for file system data, or a mirror volume for receiving file system data as the result of a mirroring operation.

• Usage information in MB, such as the current volume size, amount of space used, and amount of space available. The percentage of used space compared to available space is also displayed.

• Volume quota information for disk usage and AutoGrow, such as the hard quota, soft quota, high watermark, and minimum AutoGrow parameters.

• Device information for the LUNs associated with the volume, such as the device name, make and model, and RAID level of the array on which the volume has been configured. The minimum and maximum LUN size parameters for the array are also displayed.

• LUN List information, which identifies each LUN that is assigned to the volume.

To Display Volume Information

• Run the following command:volume show [(VOLNAME|-r)]

VOLNAME is an optional argument that specifies the name of a configured volume for which to display information. If you do not supply a volume name, a list of all volumes is displayed.

The -r option displays the volume’s RAID level.

Modifying a Volume’s ParametersYou can modify a volume’s characteristics, including its name and automatic resizing parameters by running the volume modify command. This command is useful for renaming a volume or changing its quota parameters. For the volume modify command to complete, the volume must be offline or online depending on the parameter that you want to modify:

• To change the -h HIGHWATERMARK, -e SHAREREAD, or -L LANGUAGE, or the -j SECURITYSTYLE parameters, the volume must be online. If the volume is offline,


6-15

you can explicitly bring the volume online by running the volume online command. (See “Bringing a Volume Online” on page 6-19.)

• To change the -p NEWVOLNAME parameter, the volume must be offline. If the volume is online, you can take the volume offline by running the volume offline command. (See “Taking Volumes Offline” on page 6-18.)

• To change the -q HARDQUOTA, -s SOFTQUOTA, -g MINAUTOGROW, or -d DEVICENAME (regardless of whether you are using -f) parameters, the volume can be online or offline.

To Modify a Volume

• Run the following command:volume modify VOLNAME [-A ATIMEUPDATES][-c CHARSUBST] [-d DEVICENAME][-e SHAREDREAD] [-f] [-g MINAUTOGROW] [-h HIGHWATERMARK] [-j SECURITYSTYLE] [-L LANGUAGE] [-o OPLOCKS] [-p NEWVOLNAME] [-q HARDQUOTA] [-s SOFTQUOTA] [-t CHARSUBSTTABLE]


VOLNAME Specifies the volume you want to modify.

-A ATIMEUPDATES Disables or enables the automatic last access time updates option. When enabled, the file system automatically updates the last access time on files and directories when they are read. When disabled, the last access time is only updated when an NFS or CIFS client explicitly sets the time stamp. Enabling this option increases the file system update load, but enables clients to see which files are being used. The values for ATIMEUPDATES are enabled or disabled. The default is enabled.


6-16

-c CHARSUBST An optional argument that sets the CIFS illegal character substitution option to enabled or disabled. When enabled, if NFS creates a filename with the illegal characters "*:<>?\|, then the NAS Gateway automatically substitutes a list defined by CHARSUBSTTABLE. The value for CHARSUBST can be enabled or disabled. By default, CHARSUBST is disabled. You cannot set this to enabled without also providing a value for CHARSUBSTTABLE.

-d DEVICENAME and -f

Allows you to specify one device to trigger growth of the volume:• If you specify -d DEVICENAME, the device is not added to

the volume if it is configured with a different RAID level than the volume.

• If you specify -d DEVICENAME -f, the device is added to the volume even if the specified device is a different RAID level.

The device name is a string that consists of make_serial#_LUN. For example, IBM_60432_255.

-e SHAREDREAD An optional argument that specifies the state of the CIFS “no shared read” open flag for the volume. This flag is read by NFS requests, and the state you set will affect whether NFS clients can access files on the volume. You can set this variable to allow or disallow. By default, the shared read is allowed. The shared read argument must be specified with the following construction:• -e sharedread=allow permits NFS requests to ignore

the “no shared read” flag. Therefore, NFS requests will be allowed and NFS clients will be able to read files on the volume.

• -e sharedread=disallow causes NFS requests to respect the “no shared read” flag. Therefore, NFS requests are not allowed, and NFS clients are not permitted to read files on the volume.



6-17

-g MINAUTOGROW An optional argument that specifies the smallest amount of storage that the volume can automatically grow if it needs more space. Enter the volume’s absolute maximum size in MB. This value must be a nonzero value. The default value is 500 MB.

-h HIGHWATERMARK An optional argument that specifies the trigger that causes the volume space to grow by the amount specified in the MINAUTOGROW argument. Enter the value as a percentage of the total amount of currently allocated space. The NAS Gateway uses the percentage of total used space to calculate the actual amount of disk space required. Set the high water mark to a value between 25% and 100%. If you set the value to zero (0), then automatic volume space growth is disabled. Default value: 0, no threshold is set for automatic volume space growth.

-j SECURITYSTYLE An optional argument that specifies the security style supported by the file system. When creating a new file system object, any supplied security information will be honored only if the file system security style matches the style of the security information. Otherwise, security information from the parent directory is inherited. Possible values are: normal, nfs, cifs, and cifsWithSilentNfsFailures.• When set to normal, both NFS and CIFS security styles are

supported. While an object can have only one form of security style at any point in time, it is set by the last protocol that created or modified it.

• When set to nfs, setting CIFS ACLs will not be supported.• When set to cifs, any attempt to change security

information by NFS will be ignored.• When set to cifsWithSilentNfsFailures, any attempt to

change security information by NFS will appear to be successful, but no change is made to the security information.

-L LANGUAGE The language code that you are using to create the volume. For a list of language codes, use the online help by running the help volume create command.



6-18

Taking Volumes OfflineYou can take a volume offline to perform diagnostics or for maintenance to the physical devices that support the LUNS that the volume owns. When you take a volume offline, all of its configured parameters remain intact until you bring the volume back online.

-o OPLOCKS An optional argument that specifies whether CIFS requests are permitted to obtain OPLOCKS on files. The values for this option are allow and disallow. When allowed, CIFS requests are permitted to obtain oplocks on files. When disallowed, no CIFS oplocks are granted.The default value for OPLOCKS is allow. Ensure that the volume is online before setting this option.

-p NEWVOLNAME An optional argument that specifies the new name that you are assigning to the volume. When you set the new volume name the name used in VOLNAME no longer applies.

-q HARDQUOTA An optional argument that specifies the hard quota, which is the maximum size of the volume. Enter the volume’s absolute maximum size in MB. Set this argument to 0 (the default) if you want unlimited growth for the volume.

-s SOFTQUOTA An optional argument that specifies a percentage of the hardquota. When the volume usage equals or exceeds the percentage you specify another free LUN is taken and added to the volume. An Elog message is posted on the management console when the soft quota triggers the addition of another LUN to the volume. Enter a percentage value from 1 to 100. The default value is 0, which means that the NAS Gateway does not track the SOFTQUOTA value.

-t CHARSUBSTTABLE An optional argument that sets the CIFS illegal character substitution table. CHARSUBSTTABLE is a comma-separated list of 2-byte Unicode value in hexadecimal format to be substituted for the characters "*:<>?\|, for example, FF82,FF89,FF8A,FF8C,FF8E,FF8F,FF7F,FF88.



6-19

To Take a Volume Offline

• Run the following command:

Note - This command can be intrusive. Make sure that no one is currently using the volume when you take the volume offline.

volume offline VOLNAME

VOLNAME is the name of a currently online volume that you want to take offline.

Bringing a Volume OnlineYou can bring a volume online after performing diagnostics or for maintenance to the physical devices that support the LUNs that the volume owns. When the volume comes back online, it is automatically mounted with its previously configured parameters.

By default, the volume can be brought online only by the virtual server that owns it. However, mirror volumes are the exception. Mirror volumes can be brought back online in read-only mode by any virtual server.

Note - When you bring an offline volume back online, the shares for the volume become visible again in the list of shares.

To Bring a Volume Online

• Run the following command:volume online VOLNAME [-o MODE]


VOLNAME Specifies the currently offline volume that you want to activate.


6-20

Importing a Volume From One Cluster to AnotherThe NAS Gateway supports importing volumes from the source virtual server of one cluster to the target virtual server of another cluster.

The volume import feature is supported on standard volumes and mirror volumes. Anytime a volume is imported, the NAS Gateway recognizes it as a takeover event, so volume ownership changes. Do not import core volumes and management volumes.

The volume import feature supports importing volumes regardless of a cluster’s state. Importing volumes is helpful if, for example, a cluster fails. In that case, you can import any number of volumes from the failed cluster into a virtual server of another cluster. You also use the volume import feature as part of performing a baseline mirror operation. See “Creating a Local Mirror to Perform Baseline Data Copy for a Data Mirror over IP” on page 13-7. You can import only one volume at a time.

Considerations for Importing VolumesTo import a volume into a cluster, consider the following:

• Before importing a volume, disable the volume to be imported and stop any active backup or mirror sessions on that volume.

• You need to be in the context of the virtual server to which you are importing the volume. The command fails if you run it from the NAS Gateway context.

• The volume import feature supports only volumes that are visible through network or SAN connectivity.

To Import a Volume to a Cluster

Step 1: From the context of the virtual server that will receive the

-o MODE An optional argument that sets the access mode for the volume when it is brought back online:• -o ro allows read-only access when the volume comes

back online.• -o rw allows read-write access when the volume comes

back online. Read-write access is the default.



6-21

imported volume, run the lun rescan all command. Allow approximately 30 seconds before proceeding to the next step.

The 30-second interval allows the lun rescan all command to complete and refresh the LUN list.

Step 2: Run the lun show all command and note the cluster name and volume name for the volume that you will be importing.

Step 3: Take the volume to be imported offline by running the following command:volume offline VOLNAME

VOLNAME is the name of the volume you are importing.

Step 4: From the context of the virtual server to receive the imported volume, run the volume import command:volume import CLUSTERNAME SOURCEVOLNAME [DESTVOLNAME] [-m]

Step 5: From the context of the virtual server that received the imported volume, run the volume show command to verify that the volume


CLUSTERNAME Specifies the cluster from which you are importing the volume.

SOURCEVOLNAME Specifies the volume that you are importing.

DESTVOLNAME An optional argument that allows you to rename the volume that you are importing to the new virtual server. If you use this option, the new name must be unique in the new cluster. If you do not use this option, the volume is imported with its original name if that name is not already in use in the new cluster.

-m Sets the type of volume to be imported to a mirror volume. When you import a volume as a mirror volume, a mirror demote operation is performed. See “Working with ONStor Data Mirror” on page 13-1 for details on demoting a mirror volume.


6-22

exists on the target virtual server. When you perform this step, the newly imported volume’s state is offline.

Note - At this point, the volume can appear in both the original cluster and the new cluster. If the source cluster or virtual server’s state is UP, the volume you imported still appears in the original cluster until you bring the imported volume online in the new cluster.

Step 6: From the context of the virtual server that received the imported volume, put the volume into service by running the volume online command.

Note - This step causes the volume in the source cluster or virtual server to automatically go offline in the original cluster because all the LUNs have been moved. At this point, the imported volume is no longer part of the original cluster, so it cannot be brought online or managed through the original cluster.

Step 7: From the original cluster, run the volume delete command and specify the name of the offline volume that has been moved. This step deletes the offline volume from the source cluster.

Deleting a VolumeBy deleting a volume, you delete the file system data on it, any share configured for the volume, and release the disk space that was assigned to the volume.

To Delete a Configured Volume

Step 1: Run the following command to identify the volume you want to remove:volume show

Step 2: Run the following command to remove the volume:volume delete VOLNAME


6-23

VOLNAME is the name of the volume you want to delete.

When you run the following command, the NAS Gateway prompts you for confirmation. Press the Y key to accept the deletion or the N key to abort the deletion when you see this prompt:

Are you sure? [y|n]


6-24

File System StatisticsThe NAS Gateway supports multiple file system operation and performance counters. The following file system statistics are available:

• Cache statistics, which include the file system cache usage for common file system operations.

• Performance statistics, which include file system usage by file system request type, and average response or completion times for each file system request type.

• Resource statistics, which include file system resource usage and availability prior to an NFS request being completed.

Displaying the File System Cache StatisticsFile system cache statistics display the cache usage for the file system including the traffic usage of I/O operations.

The file system cache statistics track the information about various user data metadata events in the file system, such as:

• Types of file system user data and metadata events.

• Current maximum size of the cache for various user data and metadata functions.

• Number of times the cache has hits for various metadata and user data functions.

• Number of times that an object needed to be written to disk.

To Display the File System Cache Statistics

• Run the following command: filesystem show stats cache [-n NODENAME|VOLNAME]


-n NODENAME An optional argument that displays the file system cache statistics for a specific node. This is the default setting.

VOLNAME An optional argument that displays the file system cache statistics for a specific volume.


6-25

Displaying File System Cache Hash StatisticsFile system information is hashed to more efficiently locate metadata in NAS Gateway memory. The NAS Gateway’s file system cache hash statistics focus primarily on inode and metadata usage. These statistics show information about the following:

• Inodes

• Memory buffers

• User data

• Pages

• Disks

To Display the File System Cache Hash Usage Statistics

• Run the following command:filesystem show stats cache hash [-n NODENAME|VOLNAME]

Displaying File System Cache Verbose StatisticsThe file system tracks verbose cache statistics for metadata. Verbose cache statistics track the usage of the writeback cache and the writeback daemon:

• The writeback cache is used whenever a user or metadata object is modified and the cache is full, which causes the user or metadata to be written to disk.

• The writeback daemon is triggered on regular intervals and when specific file system events occur.


-n NODENAME An optional argument that displays the file system cache hash statistics for a specific node. This is the default setting.

VOLNAME An optional argument that displays the file system cache hash statistics for a specific volume.


6-26

To Display the File System Cache Verbose Statistics

• Run the following command:filesystem show stats cache verbose [-n NODENAME|VOLNAME]

Displaying File System Performance StatisticsThe file system performance statistics show information about the runtime operation of the file system based on specific NFS request types. The performance statistics also list average response or completion times for each NFS request type. Through the completion times you can assess file system performance by noting how quickly requests are processed. Many of the file system requests tracked resemble NFS v3 or CIFS requests.

To Display the File System Performance Statistics

• Run the following command:filesystem show stats performance [-n NODENAME|VOLNAME]


-n NODENAME An optional argument that displays the verbose cache statistics for a specific node. This is the default setting.

VOLNAME An optional argument that displays the verbose cache statistics for a specific volume.


-n NODENAME An optional argument that displays the file system performance statistics for a specific node. This is the default setting.

VOLNAME An optional argument that displays the file system performance statistics for a specific volume.


6-27

Displaying File System Input/Output PerformanceThe file system I/O performance statistics track the operation and performance of specific user data and metadata functions. The file system I/O performance statistics include the standard file system performance statistics for reference, but the I/O statistics elaborate on the statistics tracked in the ioUsec column. The statistics in this column are provided as more detailed statistics and counters for each of the supported file system request types. Many of the file system requests tracked resemble NFS v3 or CIFS file system requests, just like the file system performance statistics.

To Display the File System I/O Performance Statistics

• Run the following command:filesystem show stats performance io [-n NODENAME|VOLNAME]

Displaying File System Daemon Performance StatisticsThe file system daemon statistics show the time that is spent by the NAS Gateway’s daemons. The file system daemon performance statistics also list average response or completion times for each file system request type.


-n NODENAME An optional argument that displays the file system I/O performance statistics for a specific node. This is the default setting.

VOLNAME An optional argument that displays the file system I/O performance statistics for a specific volume.


6-28

To Display the File System Daemon Performance Cache

• Run the following command:filesystem show stats performance daemon [-n NODENAME|VOLNAME]

Displaying File System Resource StatisticsBefore executing a file system request, the NAS Gateway runs a resource checking algorithm to determine whether enough resources exist to provide a reasonable attempt at completing the request.

• If resources exist, then the file system request completes.

• If no resources exist, the file system request is blocked and queued, while the NAS Gateway rechecks resource availability.

The file system resource statistics show file system resource usage and availability before a file system request is completed. These conditions are displayed as counters that describe the number of successful or blocked file system requests.


-n NODENAME An optional argument that displays the file system daemon performance statistics for a specific node. This is the default setting.

VOLNAME An optional argument that displays the file system daemon performance statistics for a specific volume.


6-29

To Display the File System Resource Statistics

• Run the following command:filesystem show stats resource [-n NODENAME|VOLNAME]


-n NODENAME An optional argument that displays the file system resource performance statistics for a specific node. This is the default setting.

VOLNAME An optional argument that displays the file system resource performance statistics for a specific volume.


6-30


Chapter 7: Managing SharesThis chapter documents setting up the NAS Gateway for CIFS, NFS, and multiprotocol file sharing services. This chapter contains the following sections:

• “NFS Environment” on page 7-2

• “CIFS Environment” on page 7-6

• “Global Namespace (GNS)” on page 7-8

• “GNS Root Management” on page 7-10

• “Junction Management” on page 7-15

• “Virtual Directory Management” on page 7-18

• “Shares Management” on page 7-22

• “Multiprotocol Environment” on page 7-28

• “Configuring CIFS and NFS Shares and Services” on page 7-33

• “Managing NFS Shares” on page 7-46

• “Managing CIFS Shares” on page 7-50

• “Managing CIFS Wide Links” on page 7-56

• “Exporting and Importing Shares” on page 7-62

• “Managing ID Mappings” on page 7-66

• “Multiprotocol File Access Without Using NIS” on page 7-71

• “Working With Symbolic Links” on page 7-75


7-2

NFS EnvironmentThe network file system (NFS) protocol is an industry-standard, file-access protocol that is platform neutral. The NAS Gateway provides file-level services for NFS v.2 and NFS v.3 clients in IP networks. The NAS Gateway does not require NLM requests on the share, but you can use the SECURE_LOCK option of the nfs share add command to configure the requirement for NLM requests. See the ONStor 2200 Bobcat NAS Gateway Command Reference for details on how to use this command.

Figure 7-1 shows a typical configuration in which the NAS Gateway provides file services for NFS clients in an IP data network.

Figure 7-1 NFS Topology

For details on how to configure NFS shares, see “Configuring CIFS and NFS Shares and Services” on page 7-33.

NFS Share ConsiderationsWhen preparing to share resources to clients, consider the following:

IBM Compatible

IBM Compatible

W orkstation

W orkstation

GigabitEthernet

IP SAN

Fibre ChannelNFS

NFSClient

Client

File Server

Application Server



hub/router

ONStor 2200 NAS Gateway Cluster


7-3

• Specify a full path name to the resource.

• You cannot share the root directory

Sharing Nested DirectoriesYou can configure the NAS Gateway to share nested directories.

Note - The EverON file system has no software restriction on the number of nested directories when sharing. However, implicit practical limits exist, such as buffer sizes, that can apply a limit to the number of levels for nested shares.

Each directory in the file system supports a maximum of 65533 unique subdirectories. This number is a total of 65535, but accounting for the . and .. subdirectories, the number is 65533.

Share PermissionsPermissions indicate how resources are shared with client. The NAS Gateway supports the following permissions on share:

• Controlling read-only access

• Controlling read-write access

• Controlling the root squash access

• Controlling root access

Sharing with Root AccessRoot access enables the clients to access shared resources as the root user, UID 0. The NAS Gateway supports up to 255 root hosts, and root access can be applied to subnets and individual hosts.

The NAS Gateway responds to file system requests from hosts depending on what root access options you have specified for shared resources. Requests can be accepted or denied as follows:

• When you configure a host with root access on share, the root user on that host keeps root level access (UNIX UID 0) when accessing the resource.


7-4

• When you do not configure root access on share, either root access is denied or the NAS Gateway performs a root squash, which modifies the root UID for the request.

By default, the NAS Gateway’s root squash ID is 65534 for “nobody,” but supports customizable root squash IDs through the ANON_UID and ANON_GID options. You can configure these options on each NFS share.

Share’s Client ListThe client list is the section of the nfs share add command that enables you to specify one or more clients that are permitted to access the share. The client list supports single clients, domains, netgroups, or all clients by including an asterisks (*) as a wildcard.

Note - The maximum number of clients per client list is 16. The maximum client string size is 255 characters.

Exclusions to the Share’s Client ListThe share’s client list supports exclusions. An excluded client gets no access through the share. You can create an exclusion to the client list by using one of the following methods:

• Indicate the excluded clients with a hyphen (-).

• In the clients list, always list excluded clients before the domain or netgroup they belong to, or before the asterisk ( * ). The NAS Gateway scans shares in a left-to-right order and stops at the first match. Therefore, list the exclusion first on the clients list.

Examples:

- nfs share add /vol1 rw,nosub=-192.168.22.24 :192.168.0.0/24

- nfs share add /vol1 rw,no_root_squash,nosub=-192.168.22.24:onstor.com

- nfs share add /vol1 ro,anon_uid99=-192.168.22.24:@mygroup


7-5

- nfs share add /vol1 ro=-192.168.22.24:*


7-6

CIFS EnvironmentThe Common Internet File System (CIFS) is a file access protocol that supports IP-connected clients in a Windows environment. Figure 7-2 shows a typical configuration in which the ONStor Bobcat 2200 Series NAS Gateway provides file services for CIFS clients in an IP data network.

Figure 7-2 Example CIFS Topology

The NAS Gateway CIFS environment supports the following features:

• The NAS Gateway supports wide links. Wide links are supported on CIFS shares. This feature, which is similar to Microsoft’s distributed file system (DFS), allows CIFS clients access to shares on multiple volumes on multiple virtual servers or NAS Gateways. For more information regarding DFS, see www.microsoft.com. For details about managing wide links, see “Adding Wide Links” on page 7-58.

• The NAS Gateway supports Microsoft’s volume shadow copy service for CIFS clients. This service helps prevent users from accidentally overwriting or deleting files. Volume shadow copy service allows users to browse a file’s snapshot history using the Previous tab in/]777 the Microsoft Internet Explorer browser. The feature is run as a schedule process on the NAS Gateway, and operates on the same schedule as the NAS Gateway’s snapshot schedule. For details about snapshot schedules, see “Managing Snapshots” on page 9-1.

IBM Compatible

Workstat ion

W orkstation

GigabitEthernet


IP SAN

FibreChannel

Windows98 Client

Primary Windows



hub/router

WindowsNT Client

W orkstation

WindowsXP Client

Workstat ion

Windows2000 Client

IBM Compatible


Domain Controller


7-7

• The NAS Gateway supports Windows mandatory byte-range locking and network lock manager (NLM) advisory byte-range locking. The NAS Gateway is aware of each lock algorithm and ensures consistent operation of each lock method without allowing the violation of either one. The NAS Gateway supports 2 million file locks and 1.5 concurrent locked files.

Opportunistic locks (oplocks) increase network performance by allowing clients to cache specific information in some file sharing situations. Because the client retains necessary information in its cache, the client can perform read and write operations on files without having to consult the server whenever it needs to access a file. Oplocks are always enabled on the NAS Gateway. They cannot be disabled. For details about using oplocks, see “Managing Volumes and File Systems” on page 6-1.

Note - Because read, write, and lock information is cached on the client, events such as cache flush messages, file close operations, oplock break messages, or network errors on the client can negatively affect oplocks.

• The NAS Gateway supports symbolic links so that CIFS users can follow UNIX/NFS symbolic links to their target. Symbolic links are a way of representing a real directory path in a shorter and easier way to comprehend. For details on how to manage symbolic links, see “Working With Symbolic Links” on page 7-75.

You can configure CIFS shares by using either the NAS Gateway command-line interface (CLI) or the Microsoft Windows computer management tool. This chapter describes how to configure CIFS shares by using the NAS Gateway CLI. For more information, see “Configuring CIFS and NFS Shares and Services” on page 7-33.


7-8

Global Namespace (GNS) Global Namespace (GNS) is the ONStor implementation that allows administrators to build virtual file systems from CIFS shares on ONStor file systems, Windows CIFS shares, and Windows DFS roots. GNS is comprised of multiple GNS root directories, each of which is visible as a CIFS share on all virtual servers. GNS contains virtual directories and junctions. A virtual directory is a directory entry for GNS. A junction is a name space object that redirects CIFS clients to a list of paths of the form \\server\share\dir1\dir2\etc, where these paths can be shares in the local cluster, a remote cluster, a Windows system, other GNS roots, other virtual directories, or even other junctions.

GNS allows administrators to group shared folders located on different servers by connecting them to one or more namespaces. A GNS namespace is a virtual view of shared folders in an organization. Administrators use GNS commands to select the shared folders to present in the namespace, design the hierarchy in which the folders appear, and determine the names that the shared folders show in the namespace. The folders appear to reside on a single, high-capacity hard disk, through which users can navigate without needing to know the server names. GNS also provides other benefits, such as fault tolerance and load-sharing capabilities.

GNS simplifies the process of moving data from one file server to another. Administrators can physically move data to another server without needing to reconfigure applications or reeducate users about where they can find their data. This minimizes the impact of server consolidation on users. It also allows administrators to deploy additional file servers and present the folders on those new servers as new folders within an existing namespace.

Note - The CIFS share permissions on the alternate paths must match, otherwise clients will get unexpected access errors. Windows clients will only traverse up to eight ONStor GNS junctions. This can be the cause of client access failures.

Offline settings for junction targets are set on the individual CIFS shares that are specified as targets. If a junction has multiple targets with different offline settings, the client will use whatever settings are applied to the target.


7-9

You must have cluster network privileges to make any changes or to view the global namespace. The Web UI must support the following operations as well.


7-10

GNS Root ManagementA GNS root is logically the top of the global namespace. There can be more than one of these, such as one for Marketing and another for Engineering. Each one might lead to a different, but overlapping set of virtual servers and shares.

Note - You cannot access the GNS root if you login as the local user account.

Creating a New GNS RootYou can create a new GNS root using the gns add root command. The GNS root will be exported by every virtual server in the cluster as the CIFS share \\vsvr\ROOTNAME.

To Create a GNS Root

• Run the following command:gns add root cifs ROOTNAME [-a ACCESSBASEDENUM] [-c COMMENT] [-d DOMAIN\USERGROUP:RIGHTS] [-g DOMAIN\USERGROUP:RIGHTS] [-o CACHING]


ROOTNAME Specifies the name of the root. It cannot match any existing root or CIFS share name in the cluster. It can have a maximum of 250 characters.

Note - Win32 applications cannot access a path greater than 260 total bytes. In practice, the length of \\Server\ROOTNAME must not exceed 258 characters, where Server is any virtual server name in the cluster.


7-11

ACCESSBASEDENUM Enables or disables the access-based enumeration support for this root. When enabled, CIFS users will only see files and directories on which they have FILE_GENERIC_READ rights. Legal values are enabled or disabled. The default value is disabled.

COMMENT Specifies the new comment string that will be reported to CIFS clients when they enumerate the shares on any virtual server. The default value is no comment.

DOMAIN Specifies the domain associated with the user or group.

USERGROUP Specifies the name of the user or group to which the ACL applies.

RIGHTS Specifies the access rights to grant or deny. The legal value is: r – Read access.

CACHING Specifies how files are cached on clients. The default value is manual. The legal values are:• none - Clients should not cache files to make them available

when working offline.• manual - Users must manually specify any files they want

available when working offline. To ensure proper file sharing, the server version of the file is always opened.

• documents - Opened files are automatically downloaded and made available when working offline. Older copies are automatically deleted to make way for newer and more recently accessed files. To ensure proper file sharing, the server version of the file is always opened.

• programs - Opened files are automatically downloaded and made available when working offline. Older copies are automatically deleted to make way for newer and more recently accessed files. File sharing is not ensured.

-a The -a option sets the access-based enumberation feature to enabled or disabled. When enabled, CIFS users will only see files and directories on which they have read rights.


7-12

Note - The -d and -g options can appear multiple times to build a larger ACL.

By default, the root is created with the Everyone group having Read Access.

Since a GNS root is itself a CIFS share, there is the possibility that a customer will attempt to modify its security and comment via the Windows Control Panel. This is not allowed.

Modifying the GNS RootThis command modifies the global namespace root.

To Modify the GNS Root

• Run the following command:gns modify root cifs ROOTNAME [-a ACCESSBASEDENUM] [-c COMMENT] [-d DOMAIN\USERGROUP:RIGHTS]

-d The -d option specifies an ACL entry that should be added into the deny list. These entries are users or groups that are explicitly denied certain access rights. The caller should be in some virtual server context to specify grant or deny ACL entries. This option is necessary to be able to convert the names to ids.

-g The -g option specifies an ACL entry that should be added into the granted list. These entries are users or groups that are explicitly granted certain access rights. The caller should be in some virtual server context to specify grant or deny ACL entries. This option is necessary to be able to convert the names to ids.

-o The -o option sets the client-side caching options. This controls how clients cache files for use when working offline.

Note - If Win2k clients are used, it is not a good idea to enable client-side caching.


7-13

[-g DOMAIN\USERGROUP:RIGHTS] [-n NEWNAME] [-o CACHING] [-r DOMAIN\USERGROUP]




-a ACCESSBASEDENUM

Enables or disables the access-based enumeration support for this root. When enabled, CIFS users will only see files and directories on which they have FILE_GENERIC_READ rights. Legal values are enabled or disabled. The default value is disabled.

-c COMMENT Specifies the new comment string that will be reported to CIFS clients when they enumerate the shares on any virtual server. The default value is no comment.



RIGHTS Specifies the access rights to grant or deny. The legal value is r – Read access.

-n NEWNAME Specifies the new name for this root. The object will stay within the current parent directory.

Note - Win32 applications cannot access a path greater than 260 total bytes. In practice, the length of \\Server\NEWNAME must not exceed 258 characters, where Server is any virtual server name in the cluster.


7-14

-o CACHING Specifies how files are cached on clients. This controls how clients cache files for use when working offline. The default value is manual. The legal values are:• none - Clients should not cache files to make them available





Note - If Win2k clients are used, it is not a good idea to enable client-side caching.

-d The -d option specifies an ACL entry that should be added into the deny list. These entries are users or groups that are explicitly denied certain access rights. The caller should be in some virtual server context to specify grant or deny ACL entries. This option is necessary to be able to convert the names to IDs.

-g The -g option specifies an ACL entry that should be added into the granted list. These entries are users or groups that are explicitly granted certain access rights. The caller should be in some virtual server context to specify grant or deny ACL entries. This option is necessary to be able to convert the names to IDs.

-r The -r option removes the ACL entry associated with the user or group.


7-15

Junction ManagementA junction is an object within the global namespace below a root that points to a list of paths of the form \\server\share\path. These paths can point to a GNS root, a virtual directory, another junction, a CIFS share, or a directory path below a CIFS share. The target can be in the same cluster, another cluster, or even to paths outside of ONStor filers, like a Windows CIFS share

A GNS junction specifies zero or more targets. Each target contains a server, share, and optional path portion. Each target within a junction must specify a unique server, share combination. Duplicate targets are not allowed within a junction, nor are targets that differ only in the path specified.

Since Active Directory is not supported, junction targets are sorted so that targets that match more IP address octets are sorted first. If a client and a junction server are in the same subnet, it is more likely to be chosen than a target that is in a different subnet. If multiple targets have an equal number of matching octets, they are sorted randomly so clients are load spread.

Note - In case of failure of a junction target, the client should switch to alternate targets. This failover is totally dependent on the client detection of failure. The failover depends on the client to select available alternate targets.

Creating a JunctionThis command adds a new global namespace junction to every virtual server.

To Create a Junction

• Run the following command:gns add junction cifs ROOTNAME\PATH [-t TARGET]



7-16

Note - It is the responsibility of some external process, like ONStor Data Mirror, to guarantee that all alternate paths have the same contents.

Modifying a JunctionModifies a CIFS junction in the global namespace.



PATH Specifies one or more path names delimited by a backslash (\). The last name must not already exist but the previous ones must already exist. Case is ignored. Each name can be at most 250 characters.

-t TARGET Specifies a target path to which ONStor GNS clients will be redirected of the form \\server\share\path.The -t option can appear multiple times to build up a list of alternate paths.

Note - It is a Windows restriction that there can only be a single target path when it’s a domain-based DFS path. A domain-based DFS path is one where the DFS path is stored in the Active Directory.


7-17

To Modify a Junction

• Run the following command:gns modify junction cifs ROOTNAME\PATH [-n NEWNAME] [-r TARGET] [-t TARGET]

Note - The -t and -r options can appear multiple times.




-n NEWNAME Specifies the new name for this root, the object will stay within the current parent directory.

TARGET Specifies a target path to which ONStor GNS clients will be redirected of the form \\server\share\path.

-t The -t option can appear multiple times to build up a list of alternate paths.



7-18

Virtual Directory ManagementA virtual directory is any directory within the global name space below a root that is not a junction.

Creating a Virtual DirectoryThis command adds a new global namespace directory to every virtual server.

To Create a Virtual Directory

• Run the following command:gns add dir cifs ROOTNAME\PATH [-d DOMAIN\USERGROUP:RIGHTS] [-g DOMAIN\USERGROUP:RIGHTS]






RIGHTS Specifies the access rights to grant or deny. The legal values is r – Read access.



7-19

Note - By default, the virtual directory is created with the Everyone group having Read Access.

Modifying a Virtual DirectoryThis command modifies a global namespace directory in every virtual server.

To Modify a Virtual Directory

• Run the following command:gns modify dir cifs ROOTNAME\PATH [-d DOMAIN\USERGROUP:RIGHTS] [-g DOMAIN\USERGROUP:RIGHTS] [-n NEWNAME] [-r DOMAIN\USERGROUP]




PATH Specifies one or more path names delimited by a backslash (\). The last name must not already exist, but the previous ones must already exist. Case is ignored. Each name can be at most 250 characters.




7-20

Listing GNS ObjectsThis command displays information about global namespace objects.

To List GNS Objects

• Run the following command:gns show cifs [all | ROOTNAME[\PATH]]

If ROOTNAME is omitted, or all is specified, the names of all of the roots are listed. If it is provided and PATH is omitted, the detailed information about the root is listed, including the comment, the ACL, and the list of child GNS objects. For each child object, the name and the object type, either virtual directory or junction is listed.

RIGHTS Specifies the access rights to grant or deny. The legal value is: r – Read access.

-n NEWNAME Specifies the new name for this root, the object will stay within the current parent directory.





ROOTNAME Specifies the name of the GNS root.

PATH Specifies one or more path names delimited by a blackslash (\).


7-21

If ROOTNAME and PATH are provided and they refer to a virtual directory, detailed information about the directory including the ACL and the list of child GNS objects is displayed. For each child object, the name and the object type, either virtual directory or junction is displayed.

If ROOTNAME and PATH are provided and they refer to a junction, the list of target paths to which this junction points is listed.

Note - If the virtual server context is not set, it might not be possible to convert the security information into normal user and group names.

Deleting GNS ObjectsThis command deletes global namespace objects.

To Delete GNS Objects

• Run the following command:gns delete cifs ROOTNAME[\PATH] [-r]

Note - Without the -r option, this command will fail if there are child objects.


ROOTNAME Specifies the name of the root to delete or the parent of the path that is to be deleted. The name is case insensitive.

PATH Specifies the optional path within the global namespace to be deleted.

-r The -r option denotes a recursive delete of all the objects from ROOTNAME\PATH, but only within the global namespace. The -r option will not delete the CIFS shares or files to which child junctions point.


7-22

Shares ManagementAn administrator can show, modify, and delete a CIFS Share even if the virtual server is disabled. Creating a new share will still require the virtual server to be enabled so that we can verify that the path being shared actually exists. Modifications of ACL information also require the virtual server to be enabled so that we can map names to IDs.

Creating CIFS SharesA new option has been added to control widelinks support. Support has also been added for CLI control on all attributes of a CIFS share, eliminating the need to use the Windows Control Panel application for share management.

To Create a CIFS Share

• Run the following command:cifs share add VOLNAME SHARENAME PATHNAME [-A DOMAIN\USERGROUP:AUDITTYPE:RIGHTS] [-a ACCESSBASEDENUM] [-c COMMENT] [-d DOMAIN\USERGROUP:RIGHTS] [-g DOMAIN\USERGROUP:RIGHTS] [-o CACHING] [-s SESSIONS] [-w WIDELINKS]


VOLNAME Specifies the name of the volume for which the CIFS share is created.

SHARENAME Specifies the name of the CIFS share.

PATHNAME Specifies the export path name within the volume.

ACCESSBASEDENUM Enables or disables the access-based enumeration support for this root. Legal values are enabled or disabled. The default value is disabled.

-c COMMENT Specifies the new comment string that will be reported to CIFS clients when they enumerate the shares on any virtual server. The default value is no comment.


7-23



AUDITTYPE Specifies the type of Audit ACL. The legal values are:• success – Audit successful accesses when they use the

specified RIGHTS.• failed – Audit failed accesses when they use the specified

RIGHTS.

RIGHTS Specifies the access rights to grant or deny. The legal values are:• r – Read access.• c – Change access.• f – Full access.

-o CACHING Specifies how files are cached on clients when working offline.The default value is manual. The legal values are:• none - Clients should not cache files to make them available





-s SESSIONS Specifies the maximum number of client sessions on this share at any one time. This must be in the range 1 to 65535, where 65535 means unlimited. The default value is unlimited.

-w WIDELINKS Enables or disables support for widelinks on this share. When enabled, CIFS clients can be redirected using widelinks, but this CIFS share cannot be a target of a GNS junction. Legal values are enabled and disabled. The default value is disabled.


7-24

Note - The -A, -d, and -g options can appear multiple times to build up a larger ACL.

By default the share is created with the Everyone group having Full Access.

Modifying a CIFS ShareThis command modifies the a CIFS share's options. The volume does not need to be online for this command to be run.

To Modify a CIFS Share

• Run the following command:cifs share modify SHARENAME [-A DOMAIN\USERGROUP:AUDITTYPE:RIGHTS] [-a ACCESSBASEDENUM] [-c COMMENT]

-A The -A option specifies an ACL entry that should be added to the Audit ACL list. These entries are users or groups for which audit records should be generated when they successfully use certain access rights, or when they fail to use certain access rights. The administrator must have SECURITY privileges to change the Audit ACL.

-a The -a option sets the access-based enumeration feature to enabled or disabled. When enabled, CIFS users only see files and directories on which they have read rights.

-d The -d option specifies an ACL entry that should be added to the deny list. These entries are users or groups that are explicitly denied certain access rights. The caller should be in some virtual server context to specify grant or deny ACL entries. This option is necessary to be able to convert the names to IDs.

-g The -g option specifies an ACL entry that should be added to the granted list. These entries are users or groups that are explicitly granted certain access rights. The caller should be in some virtual server context to specify grant or deny ACL entries. This option is necessary to be able to convert the names to IDs.


7-25

[-d DOMAIN\\USERGROUP:RIGHTS] [-g DOMAIN\USERGROUP:RIGHTS] [-o CACHING] [-R DOMAIN\USERGROUP:AUDITTYPE] [-r DOMAIN\USERGROUP] [-s SESSIONS] [-w WIDELINKS]



-a ACCESSBASEDENUM

Enables or disables the access-based enumeration support for this root. When enabled, CIFS users will only see files and directories on which they have read rights. Legal values are enabled or disabled. The default value is disabled.

-c COMMENT Specifies the new comment string that is reported to CIFS clients when they enumerate the shares on any virtual server. The default value is no comment.



AUDITTYPE Specifies the type of Audit ACL. The legal values are:• success – Audit successful accesses when they use the

specified RIGHTS.• failed – Audit failed accesses when they use the specified

RIGHTS.

RIGHTS Specifies the access rights to grant or deny. The legal values are:• r – Read access.• c – Change access.• f – Full access.


7-26

-o CACHING Specifies how files are cached on clients. This controls how clients cache files for use when working offline. The legal values are:• none - Clients should not cache files to make them available





-s SESSIONS Specifies the maximum number of client sessions on this share at any one time. This must be in the range 1 to 65535, where 65535 means unlimited. The default value is unlimited.

-w WIDELINKS Enables or disables support for widelinks on this share. When enabled, CIFS clients can be redirected using widelinks, but this CIFS share cannot be a target of a GNS junction. Legal values are enabled and disabled. The default value is disabled.

-A The –A option specifies an ACL entry that should be added into the Audit ACL list. These entries are users or groups for which audit records should be generated when they successfully use certain access rights, or when they fail to use certain access rights. The administrator must have SECURITY privileges to change the Audit ACL.



7-27


-r The -r option removes the ACL entry associated with the user or group and can appear multiple times.

-R The -R option specifies an ACL entry that should be removed from the Audit success or failure ACL list, depending on the AUDITTYPE setting. This option can appear multiple times. The administrator must have SECURITY privileges to change the Audit ACL.


7-28

Multiprotocol EnvironmentIn a multiprotocol environment, also known as a mixed CIFS and NFS environment, files are created or accessed through both Windows and UNIX domains. Figure 7-3 shows a typical configuration in which the NAS Gateway provides file and block services for CIFS clients in an IP data network.

Figure 7-3 Example CIFS and NFS Multiprotocol Topology

For details on how to configure a multiprotocol file sharing environment, see “Configuring CIFS and NFS Shares and Services” on page 7-33.

In a multiprotocol environment, the NAS Gateway has two roles, NFS server and CIFS server:

• As the NFS server, the NAS Gateway supports the NFS protocol operating between a client workstation, file server, or application server, and the NAS Gateway to enable the end user to access files. The NAS Gateway uses NFS shares to export file system mount points to authorized clients in the IP data network. SAN resources are only available to NFS clients when exported.

IBM Compatible

IBM Compatible

W orkstation

W orkstation

GigabitEthernet

IP SAN

FibreChannel

NFS Primary Windows



hub/router

WindowsNT Client

Workstat ion

WindowsXP Client

W orkstation

Windows2000 Client


Domain ControllerClient

IBM Compatible

ServerNIS



7-29

• As the CIFS server, the NAS Gateway enables clients that run Windows OS to read and write to the resources in the SAN at the disk block and file system block level. The NAS Gateway also participates in the Windows or NetBIOS domains.

Note - The NAS Gateway has no role in client access to specific shares in the file system. It trusts the challenge results from the domain controllers.

The NAS Gateway supports the following features in a multiprotocol environment:

• Multiprotocol access without requiring an NIS domain controller to process user and group ID mappings. A local copy of the password and group files for every virtual server is stored in the cluster database. For details, see “Setting the Local NIS Domain” on page 7-71.

• Object locking. Object locking allows subsequent operations on a file that was opened by CIFS, but only if the file is configured with the appropriate share value, either Delete, Read, or Write.

- NFS reads and writes will be unsuccessful when the NFS client attempts to read or write to a file that is locked by a CIFS client if CIFS deny-read and deny-write open modes exist.

- NFS writes will be unsuccessful when the written range of the file is locked with an exclusive CIFS bytelock.

• ID mapping. The ID map consists of any number of rules that determine how a user from one type of domain, either NFS or CIFS, is mapped into the other domain. The ID map rules are created to allow mapping in the following ways:

- Unidirectionally, to translate a CIFS user into an NFS user

- Unidirectionally, to translate an NFS user into a CIFS user

- Bidirectionally, to equally translate a user between both CIFS and NFS

Understanding ID MappingThe NAS Gateway supports identity mapping between NFS and CIFS shares. The ID maps are required only for users that do not have identical logons in both NFS or CIFS


7-30

domains. If a user has logons that are identical in both domains, you do not need to create an ID mapping rule for that user.

The following is an example of an ID map: Type Index

--------------------------------------------

user 1 spectrum\paulw==paulwilson@chromatis

user 2 *\johndoe=>johndoe@bentoptics

Type Index

--------------------------------------------

group 1 spectrum\domain admins==admins@chromatis

group 2 prism\*=>*@bentoptics

In these samples, the ID map lists users in one section, and groups in another. In the users section:

• Entry 1 is mapping the CIFS user “paulw” in the CIFS domain “spectrum” to the NFS user “paulw” in the NFS domain “chromatis” and the NFS user “paulw” in the NFS domain “chromatis” to the CIFS user “paulw” in the CIFS domain “spectrum.”

• Entry 2 is mapping the CIFS user “johndoe” from any CIFS domain to the NFS user “johndoe” in the NFS domain “bentoptics.”

In the groups section:

• Entry 1 is mapping a member of the CIFS group “domain admins” in the CIFS domain “spectrum” to the NFS group “admins” in the NFS domain “chromatis.” Because this mapping is bidirectional, the NFS group “admins” in the NFS domain “chromatis” are being mapped as members of the CIFS group “domain admins” in the CIFS domain “spectrum.”

• Entry 2 is mapping a user who is a member of any CIFS group in the CIFS domain “prism” to any NFS group in the NFS domain “bentoptics.”


7-31

Note - The mapping does not control access to CIFS files, just the translation of users from one domain type to another. Whether a mapped user can actually access a CIFS file depends on what Access Control (ACE) information is configured on the CIFS file.

ID Map Scanning LogicThe NAS Gateway uses the following logic to scan through the ID map:

• The NAS Gateway scans the ID map in ascending index order and stops scanning when it reaches the first matching rule.

• For the rule to match and stop the scan, a match must exist for the domain name and user name (for CIFS the match is case sensitive), and the translation director needs to be valid.

• If no match is found, the NAS Gateway maps the NFS name to the exact same name in the CIFS domain that the virtual server belongs to, and it maps the CIFS name to the same name in lowercase (remember, that CIFS is case sensitive) in the NFS domain that the virtual server belongs to.

ID Map ComponentsThe ID map is positional in that it expects the left most entry as the CIFS user and the right most user as the NFS user.

In addition to the position of parameters, the ID map uses three specific components:

• A CIFS name, which is typically in the form WindowsDomainName\username.

• A translation director, which specifies the direction of the ID mapping. The translation director can take one of three forms:

- == which indicates a bidirectional mapping between NFS to CIFS.

- => which indicates a unidirectional mapping from CIFS to NFS.

- <= which indicates a unidirectional mapping from NFS to CIFS.

• An NFS name, which typically takes the form “username@DomainName.”


7-32

Naming ConventionsThe NAS Gateway supports NIS or LDAP and CIFS style names in its ID map. Therefore, the ID map accept names in the form of name@domain for NFS users or groups, and Windowsdomain\user for CIFS users.

The NAS Gateway also supports special characters in the ID map:

• An asterisk (*) represents the value any.

• A blank space represents no mapping—no domain if used in the domain position, or “nobody” if used in the user name position.

• Some domain names, might contain a dot and suffix, or a dot as a separator.

The NAS Gateway supports the NetBIOS naming style only. User names with dots are not supported. Enter domain names containing dots in the ID map without the dot. The user name can have up to 20 characters and the domain name can have up to 15 characters. A user name or domain name can contain an internal blank space.

Note - Except for strings in ID mappings, when you use the NAS Gateway’s CLI to run a command, you need to enclose a name string with an internal blank space in double quotes.


7-33

Configuring CIFS and NFS Shares and ServicesTo perform the configuration process, it is assumed that you have:

1. Configured your IP data network.

2. Installed the NAS Gateway.

3. Connected the NAS Gateway to the network.

4. Logged in to the NAS Gateway and have an active command-line.

Preconfiguration ConsiderationsConsider the following issues before performing the virtual server configuration procedure:

• Decide whether you want the virtual server configured in protected mode for failover to a different NAS Gateway.

• Decide the virtual server’s name. Virtual server names are used as the NetBIOS name. To comply with NetBIOS, virtual server names are a maximum of 15 characters.

• Gather the IP addresses that you want assigned to the virtual server.

• Gather the Windows domain and user names. The virtual server uses the Windows domain.name.

• Gather the IP address of the primary WINS server and secondary WINS server (if any). The WINS server might be configured on the domain controller, in which case, you will need the domain controller’s IP address.

• Decide if the virtual server will support home directories. If so, then gather the name of the volume where the home directories exist and the path to the users’ home directories. Be aware that:

- the volume that supports the home directories must already exist before starting this procedure.

- the path to the home directories must already exist on that volume.

• Gather the name of the NIS domain that the virtual server will join.


7-34

Configuration StepsFor this procedure, ONStor makes the following assumptions for illustrative purposes only:

• The virtual server is named “vs1-production.”

• The NIS domain is named “spectrum”.

• The NFS clients reside on 192.168.12.0/24.

• The NIS server is 192.168.12.100.

• The NAS Gateway’s Gigabit Ethernet interface is 192.168.148.61.

• The gateway router is 192.168.148.1.

• The volume to be shared is named “engineering.”

• The volume “engineering” will be shared on the NAS Gateway’s Gigabit Ethernet interface with read and write access for two NFS clients.

• Home directories will be supported on the volume “homebase” through \users\local\homes.

Note - The home directory must be configured in the Windows domain. If you choose to create this path later, the path to the home directories must exist on the volume where the home directories will be.

• The WINS servers are 192.168.24.100 and 192.168.24.101.

• The Windows domain that the virtual server will be joining is “effigy”.

• The Windows domain controller is 129.192.24.1.

• The Windows domain login user name you can use is “onstoruser”.

• The Windows domain admin user name is “onstoradmin”.

• The CIFS share that will be exporting “engineering” is “eng”.


7-35

Configuring CIFS and NFS SharesTo Configure the NAS Gateway for a NFS, CIFS, or Multiprotocol Domain

To configure the NAS Gateway for an NFS, CIFS, or multiprotocol domain, follow the steps outlined in the following procedure. Follow the steps as required, depending on the type of share environment you want to set up.

Whether you are setting an NFS protocol, a CIFS protocol, or a multiprotocol, you need to first begin by creating a virtual server.

Step 1: From the NAS Gateway context, create a virtual server by running the vsvr create command from the NAS Gateway context. For example, to create a virtual server named “vs1-production,” run the following command:vsvr create vs1-production

You are now in the virtual server context. The commands in the following section are run from the context of the virtual server.

Note - The virtual server name you create is also the NetBIOS name by default.

Step 2: From the virtual server context, assign an IP interface to the virtual server by running the interface create command. For example, to create interface 192.168.148.61 on Gigabit Ethernet port 3 as part of the logical port “lp.3,” run the following command:interface create fp1.3 -l lp.3 -a 192.168.148.61/24

Note - The same physical port can be used by different virtual servers, but the same IP address cannot be used on multiple virtual servers.

Step 3: From the virtual server context, create a default route for the current virtual server by running the route add command:route add default -g 192.168.148.1


7-36

Do Steps 4 and 5 only if you are configuring for CIFS. If you are configuring only for NFS, go to Step 6.

Step 4: From the virtual server context, specify the WINS server(s) that the virtual server should use, by running the vsvr set wins command. For example, to configure the primary WINS server at 192.168.12.100, and the secondary WINS server at 192.168.12.101, enter the following command:vsvr set wins 192.168.24.100,192.168.24.101

Step 5: From the virtual server context, specify the Windows domain that the NAS Gateway will join by running the domain add windows command. For example, for the NAS Gateway join the Windows domain “effigy” whose domain controller is at 192.168.24.1, and use the login name “onstoruser”, run the following command:domain add windows effigy onstoruser 192.168.24.1

Note - When you run this command, the NAS Gateway prompts you for the password for the login name.

Do Step 6 if you are configuring only for NFS or multiprotocol.

Step 6: From the virtual server context, specify the NIS domain that the NAS Gateway will join by running the domain add nis command. For example, to have the NAS Gateway join the NIS domain “spectrum” whose domain controller is at 10.5.129.1, run the following command:domain add nis spectrum 192.168.12.100

Note - The NIS domain name can be a maximum of 63 characters.

Do Step 7 if you are configuring only for CIFS or multiprotocol.


7-37

Step 7: From the virtual server context, specify the Windows domain in which the virtual server will register by running the vsvr set domain command. For example, to set the Windows domain “effigy” with an admin user “onstoradmin,” run the following command:vsvr set domain windows effigy onstoradmin

You would also need to specify the password for the admin user “onstoradmin”.

Note - The Windows domain name can be a maximum of 63 characters.

Do Step 8 only if you are configuring NFS or multiprotocol.

Step 8: From the virtual server context, specify the NIS domain in which the virtual server will register by running the vsvr set domain command. For example, to set the NIS domain “spectrumV”, run the following command:vsvr set domain nis spectrumV

Note - The NIS domain name can be a maximum of 63 characters.

Do Step 9 only if you are configuring Kerberos.

Note - For more information on Kerberos, check the Kerberos Network Authentication Service at http://www.ietf.org/rfc/rfc4120.txt

Step 9: From the virtual server context, specify the Kerberos domain in which the virtual server will register by running the vsvr set domain command. For example, to set the Kerberos domain ORGUNIT, run the following command:vsvr set domain windows -o ORGUNIT


7-38

Do Steps 10-15 for configuring NFS, CIFS, or multiprotocol.

Step 10: From the virtual server context, run the vsvr show command to verify the virtual server’s configuration, and double check that you have assigned the resources to the correct virtual server. For example, to check the virtual server configuration of “vs1-production”, run the following command:vsvr show vs1-production

Virtual server parameters should be reconfigured while the virtual server is disabled.

Step 11: Enable the virtual server, by running the vsvr enable command. For example, to enable the virtual server “vs1-production” run the following command:vsvr enable vs1-production

Step 12: Label a foreign LUN so that the NAS Gateway can use it to create the home directories volume by running the lun label command. For example:lun label DEVICE_NAME

where DEVICE_NAME is the device name of the array you will use to create the volume.

Note - The NAS Gateway will post the message “Done” when the LUN has been completely labelled.

Step 13: Find an array on which to create a volume as the home directories volume, by running the lun show command. For example:lun show

LUNs known to the NAS Gateway can be in different states. You need a LUN with a state of “foreign.”

Step 14: From the virtual server context, create a volume for user data and specify the array that you are configuring the volume on by running


7-39

the vol create array command. For example, to create the volume “engineering” on the array named “IBM_ECV52AZB”, run the following command:vol create engineering IBM_ECV52AZB

Step 15: From the virtual server context, create the home directories volume and specify the array that you are configuring the volume on by running the vol create command. For example, to create the “homebase” volume on IBM_ECV52AZB_0, run the following command:vol create homebase IBM_ECV52AZB_0

Note - This command creates the volume with default parameters. You can set additional parameters, such as disk usage and AutoGrow parameters, by using non-default values for those parameters.

Do Steps 15-21 for configuring NFS, CIFS, or multiprotocol.

Step 16: From the virtual server context, create a default CIFS share for the volume you created in the previous step by running the cifs share add command. This share has to be created on the root of the volume. For example, to create a default share named “dir” on the volume “homebase”, run the following command:cifs share add homebase dir \

Note - This share supports the default share to the root volume. You can create directories through the Windows client for additional paths you want to share.

By default, the original security on the root of a volume does not allow write access. To allow write access, change the security, by right clicking the client, then selecting Properties>Security.


7-40

Step 17: If the virtual server supports home directories through the autocreate facility, add an admin privilege for the admin that is configuring the virtual server by running the priv add command. For example, to add the admin user “nate7” for the Windows domain “shire”, run the command as follows:priv add allow shire\nate7 CLUSTER cluster

Step 18: (Optional) From the virtual server context, if the virtual server will be supporting home directories through the autocreate facility, from a Windows client, connect to the root share that you just created in Step 13.

Step 19: (Optional) You can create the directories that will reside on the volume, including the directory structure for the home directories. Ensure that each user’s directory exists on the volume you named in Step 13.

Step 20: (Optional) From the virtual server context, you can set the NAS Gateway’s autocreate facility to display shares to the user home directories on the volume you specified in Step 13. To configure this feature, you need to configure the path to the home directories on the volume you specified in Step 13, and each of the individual user directories. For example, to connect to the volume “homebase” and create \user\local\homes, create each of the user directories that would reside in that path–for example \user\local\homes\paulw.

Step 21: (Optional) From the virtual server context, you can have the virtual server support autocreated home directories, by specifying the volume which will host the user home directories, and specifying the file path so CIFS autocreate can support a user’s home directory. To accomplish this, run the vsvr set autocreate command.


7-41

Note - The volume that you specify in the vsvr set autocreate command must already exist.

To enable this feature, the path to the home directories must already exist on the volume.

A directory must exist for each user that will have a user directory. This directory must exist in the last directory of the path.

For example, to assign “homebase” as a volume on which autocreate will run, run the following command: vsvr set autocreate homebase \user\local\homes

This argument takes the file path to the directory where user home directories are configured. The NAS Gateway prepends the volume to the file path to create the export.When the user logs in, the user name is automatically appended to the end to create the entire export to each user’s home directory. You do not need to specify the user name in the file path.

Step 22: From the virtual server context, create a default CIFS share for the user data volume by running the cifs share add command. This share has to be created on the root of the volume. For example, to create a share named “eng” on the volume “engineering”, run the following command:cifs share add engineering eng \

Do Steps 22-26 only if you are configuring CIFS or multiprotocol.

Step 23: From the virtual server context create an admin user on the NAS Gateway as documented in Step 16. If you already have the admin user configured in the virtual server, you can use the same admin user for the next two steps on the Windows client.

Step 24: From a Windows client, connect to the root share that you just created in the previous step.


7-42

Step 25: From a Windows client, create the directories that will reside on the volume.

Step 26: From the virtual server context, verify that the share appears in the Shares List, by running the cifs show command. For example: cifs show

This command shows the shares that can be browsed by a Windows client.

Step 27: From the virtual server context, verify that the share has the correct parameters, by running the cifs show command name against the share. For example, to view the configuration of the share “eng”, run the following command:cifs show eng

This command provides a detailed display of all the parameters that are assigned to the share.

Do Step 27 for configuring NFS, CIFS, or multiprotocol.

Step 28: From the virtual server context, you can create additional volumes in the virtual server by repeating Steps 10 through 12.

Do Step 28 only if you are configuring CIFS or multiprotocol.

Step 29: From the virtual server context, you can create additional CIFS shares in the virtual server by repeating Steps 15 through 20.

Note - When you are configuring shares through either the NAS Gateway or through a Windows client, you can add a dollar sign ($) at the end of the share name (for example, eng$) to configure a hidden share. You cannot browse hidden shares in the list of shares, but you can still connect to them by explicitly entering the share name, for example, \\pubstest\eng$.

If you have been configuring CIFS shares, the CIFS shares creation process is complete at this point.

Do Steps 29-33 only if you are configuring NFS or multiprotocol.


7-43

Step 30: From the virtual server, for NFS access, create a route to the IP data network where the NFS clients reside, by running the route add net command. For example, to configured a route to the 192.168.12.0/24 network through the gateway router 192.168.148.1, run the following command:route add net -g 192.168.148.1 -a 192.168.12.0/24

Step 31: From the virtual server context, create an administrator share for the volume.

• Configure the share with the no root squash option to allow you to access the share as root.

• Create the administrator share with read-write permission so that you can configure options on the volume that will be exported to users.

For example, to configure an administrator share on the volume called “engineering”, to a client called “admin-pc”, run the following command:nfs share add /engineering -o rw,no_root_squash=admin-pc;rw=*

Step 32: Set the ownership bits to allow you administrator access through the standard UNIX chown command. For example, run the following command:chown usera:usergroup /mnt/nfs-share

usera:usergroup is the name of the administrator and the name of the administrator group to which the admin belongs.

Step 33: Set the mode bits to allow you administrator access through the standard UNIX chmod command. For example, run the following command:chmod 775 /mnt/nfs-share


7-44

Note - Specific permission can vary from company to company based on security policies. The mode bits shown in the preceding example are for illustrative purposes only.

Step 34: Verify that the share has the correct parameters, by running the nfs show command against the share. You can view the NFS shares on a per-volume level. For example, to view the NFS shares exporting the volume “engineering,” run the following command:nfs show engineering

If you are setting up a multiprotocol share environment, do the following steps to create the ID mapping between the different types of shares.

Step 35: Run the following command:idmap insert {user|group} INDEX

Step 36: Press the Enter key to receive the mapping prompt, which looks like this:

Enter the user mapping:

windowsDomain\name ==/<=/=>name@NIS, or LDAPDomain

(*=wildcard, name empty=no mapping)

Step 37: Enter the mapping information at the mapping prompt. Mapping information takes three building blocks: the CIFS identity, the mapping director, and the NFS identity. An example of the MAP argument would be


user|group Specifies the translation semantics for users or groups.

INDEX Specifies a number that controls where in the Identity List the ID mapping will be added. Enter a number that refers to the ID map’s position in the list.


7-45

epicenter\paulw==paul@spectrum. For more information, see “ID Map Components” on page 7-31.

• The first building block is windowsDomain\name, where name is a CIFS user or group name that will be mapped to an NFS user or group. The windowsDomain and name components must be separated with a backslash (\). Both components support an asterisk (*) to represent “any” or a blank space to represent no mapping.

• The second building block is the mapping director. This building block specifies the direction of the translation for the ID mapping. The NAS Gateway supports unidirectional or bidirectional translation. For more information, see “ID Map Components” on page 7-31.

- == indicates bidirectional translation between the CIFS domain and the NFS domain.

- => indicates unidirectional translation from the CIFS domain to the NFS domain.

- <= indicates unidirectional translation from the NFS domain to the CIFS domain.

• The final building block is name@NIS or LDAPDomain user or group name that will be mapped to a CIFS user or group. Both components support an asterisk (*) to represent “any” or a blank space to represent no mapping.


7-46

Managing NFS SharesYou can manage existing NFS in one of the following ways:

• Displaying NFS share parameters

• Enabling and disabling NFS shares

• Modifying NFS share parameters

Displaying NFS Share States and Mount OptionsThe NAS Gateway contains its NFS shares in the NFS Shares List. To display the NFS Shares List and the detailed information about all clients configured on a specific share, run the nfs show command. This command displays the following information in the current virtual server:

• The state of each share (either Enabled or Disabled)

• Each share path configured

• The specific mount options configured on the share and the clients to which the mount options apply

• The client auth level (either 0,0 or 0,1 or 1,1)

To Display the NFS Shares List

• Run the following command from the virtual server context:nfs show {[PATHNAME|[all]|[-v VOLNAME [-P PAGENUMBER [-S PAGESIZE]]])


all Specifies the mount options for all shares.


7-47

Enabling or Disabling NFS SharesYou can enable or disable the NFS protocol on each interface by using the -p nfs=enable|disable argument of the interface create and interface modify commands.

• When you first create the interface that supports the NFS share, you can set the state of NFS on that interface through the interface create command.

• After the initial creation of the interface that supports the NFS share, you can set the state of NFS on that interface through the interface modify command.

Modifying NFS SharesWhen you run the nfs share modify command, a vi editor starts that enables you to modify a share by editing the share options list or the client list you have configured with the nfs share add command.

PATHNAME Specifies the name of a path for which to display mount options. The path name you enter is the path you noted in the previous step. If you specify the pathname, detailed information about options and the clients to which they apply is displayed. If you do not specify the pathname, only the share and its state are displayed.

-v VOLNAME Displays all NFS shares on a volume.

-P PAGENUMBER Specifies the number of the page to display.




7-48

Note - If you need to modify an NFS share, you can also overwrite the share by running the nfs share add command and recreating the share with the mount options you want to change. If you overwrite the share, you are prompted with a confirmation message similar to the one shown below:

Existing share configuration will be overwritten.

Are you sure? [y|n]:

Answering yes (Y) overwrites the existing share with the new one. Answering no (N) cancels overwriting the existing share.

When you edit the NFS share list, consider the following:

• Each line in the NFS share file contains information about each parameter that you can configure in the share.

• The sort order for the clients in each line of parameters in the file is from left to right.

• The first match of a client and its permissions halts the search.

• Clients must be specified by their IP address or host name. You can specify all clients by using the asterisk ( * ) as a wildcard operator for “all.” You can also use subnet masking to allow all clients within a configured network address space to use the share.

• If a client is not listed in the NO_ROOT_SQUASH parameter, it is assumed to have root-squash capability.

To Modify an NFS Share

Step 1: Run the nfs share modify command to start the vi editor:nfs share modify PATHNAME

PATHNAME is the name of the exported path for which the NFS Shares List is editable.


7-49

Step 2: When the editor starts, use standard vi commands to search the file and edit its contents.

Step 3: When you are done editing the share, use the standard vi commands to save and close the file.

Step 4: After editing shares, run the nfs show command to check that they are configured correctly.

Deleting NFS SharesYou can delete individual NFS shares at any time by running the nfs share delete command. When a share is deleted, it is completely removed from the virtual server. If you have configured the share with submount functionality, the share’s submounts are also unavailable after the share is deleted. You can delete an NFS share regardless of whether the share is enabled or disabled. Share deletion is immediate and intrusive. When you delete a share, you are not prompted with a confirmation message and any clients currently using the share are immediately disconnected.

To Delete an NFS Share

Step 1: Run the nfs show command to locate the share that you want to delete:nfs show

Step 2: Run the nfs share delete command to individually delete a share:nfs share delete PATHNAME

PATHNAME specifies the name of a specific path for which you want to delete the share.


7-50

Managing CIFS SharesYou can manage CIFS share in one of the following ways:

• Displaying CIFS shares

• Enabling or disabling CIFS shares

• Modifying CIFS shares

• Deleting CIFS shares

Displaying CIFS Share Information When you configure a CIFS share, it is added to a list of shares. This list contains the share definition as well as path and parameter information for the share. You can display the list in its entirety, or list a specific share by name, by running the cifs show command.

In the list, you will see not only the file system shares, but also the hidden shares. Hidden shares are always hidden from the clients, but they are visible to you, the NAS Gateway administrator. A dollar sign ($) indicates that a share is hidden from the end user or client. If you create a share with an ending $, it will not show up in the list of shares when a client is browsing, but you (as admin) can still connect to it directly. The NAS Gateway supports the IPC$ share by default.

After a CIFS share has been configured, you can display a list of the shares and the SAN resources that the shares are advertising by running the cifs show command. This command displays the list of configured shares.

Note - You can view the list of configured shares through standard CIFS client browsing as well, for example, through the Network Neighborhood display when you are using a Windows client. The resulting list of Network Places is the contents of the CIFS Shares List.

Autocreate shares (home directory shares) are not listed in the Shares List by running the cifs show command. You can see home directory shares only by browsing the virtual server through the Network Neighborhood display.


7-51

To Display CIFS Share Information

• Run the following command:cifs show [SHARENAME]|[all|[-v VOLNAME [-P PAGENUMBER [-S PAGESIZE]]])

Note - Administrative shares are visible through the Shares List, but not through the NAS Gateway’s command line. For example, if you run the cifs show command against the share IPC$ to view detailed information about the IPC$ share, the NAS Gateway will not show any information about this share.

Enabling or Disabling CIFSThe CIFS protocol can be enabled or disabled on a per-interface basis. The protocol state is controlled through the -p cifs=enable|disable argument of the interface create and interface modify commands.


SHARENAME An optional alphanumeric character string from 1 to 128 characters in length that describes the share that you want to display. • If you enter no share name, then the Shares List is displayed

for the current virtual server. Only the share names are listed. • If you enter a share name, then the specifics of that share are

displayed, such as the volume in which the share is configured, the configured path to the resource in the volume, and any comment text.

all Displays a list of all shares.

-v VOLNAME Displays a list of all shares on a specific volume.

-P PAGENUMBER Specifies the page to display.



7-52

• When you first create the interface that will support the CIFS share, you can set the state of CIFS on that interface through the interface create command.

• After the initial creation of the interface that supports the CIFS share, you can set the state of CIFS on that interface through the interface modify command.

Configuring ABE CIFS SharesThe NAS Gateway supports the Microsoft Windows feature access-based enumeration (ABE) of CIFS shares.

With this feature, more control exists over what users see when they enumerate a directory to only those files and directories for which they have FILE_GENERIC_READ rights. ABE provides more security. For more information about ABE, you can search the Microsoft web site.

You configure ABE on the NAS Gateway’s CIFS shares by using the -a ACCESSBASEDENUM argument with the cifs share modify command. With this new argument, you can enable or disable ABE. By default, ABE is disabled. To set the state of ABE, the volume must be online.

Here is the syntax of the cifs share modify command:cifs share modify SHARENAME [-a ACCESSBASEDENUM]

Deleting a CIFS ShareYou can delete a CIFS share at any time by running the cifs share delete command. This command immediately deletes the share, so the shared file system resource is made unavailable. When you delete the share, the path to the resource is



-a ACCESSBASEDENUM Specifies the state of ABE: enabled or disabled.• When enabled, CIFS users only see files and

directories on which they have FILE_GENERIC_READ rights.

• When disabled, CIFS users see an unfiltered directory listing.


7-53

removed, so the domain controller is no longer aware of the resource, and clients that request the resource are denied.

Note - You cannot delete the system hidden share IPC$.

To Delete a CIFS Share

• Run the following command:cifs share delete SHARENAME

SHARENAME is the name of the share that you want to delete.


7-54

Managing CIFS ServersCIFS servers control the CIFS client connectivity by responding to client connection requests. CIFS servers can be associated with a virtual server so that only a specified CIFS server can support client connectivity on the virtual server. CIFS servers that are associated with a virtual server manage the authentication and access of shares in the virtual server. The NAS Gateway supports a maximum of 32 CIFS server names. The following sections document the NAS Gateway commands that enable you to configure one or more CIFS servers for a virtual server.

Creating a CIFS Server in a Virtual ServerYou can create one or more CIFS servers for a virtual server by running the cifs server create command. This command associates one CIFS server name with the current virtual server. You can use this command to associate multiple CIFS servers with a single virtual server.

When the CIFS server is specified for a virtual server, that CIFS server name is added to the CIFS Server List. The virtual server scans the list in a top-down order to determine if the CIFS server can respond to access requests from CIFS clients that are attempting to access the virtual server.

To Create a CIFS Server for a Virtual Server

Step 1: Make sure are in virtual server context. If you are not in the virtual server for which you want to create the CIFS server, run the vsvr set command to change to that virtual server.

Step 2: Run the following command, from the virtual server context:cifs server create NAME

NAME is the name of the CIFS server that you are creating in the virtual server. The CIFS server name is an alphanumeric character string from 1 to 15 characters in length.

Displaying the CIFS Server for a Virtual ServerYou can display the CIFS servers that are a part of the virtual server by running the cifs server show command. This command displays the CIFS Server List for the current virtual server.


7-55

To Display the CIFS Server List for a Virtual Sever

Step 1: Make sure you are in the virtual server context. If you are not in the virtual server for which you want to display the CIFS Server List, run the vsvr set command to change to that virtual server.

Step 2: Run the following command:cifs server show NAME

NAME is the name of the CIFS server that you are displaying. Enter the name of the share that you want to display exactly how it appears in the CIFS Servers List.

Deleting a CIFS Server from a Virtual ServerYou can delete a CIFS server from a virtual server by running the cifs server delete command. When you delete a CIFS server, that specific named server can no longer process CIFS client access requests from CIFS clients that attempt to access a virtual sever through any shares supported by the virtual server.

To Delete a CIFS Server From a Virtual Server

Step 1: Make sure you are in the virtual server context. If you are not in the virtual server for which you want to delete the CIFS server, run the vsvr set command to change to that virtual server.

Step 2: Run the cifs server show command to locate the CIFS server you want to delete from the current virtual server.

Step 3: Run the following command to delete the CIFS server:cifs server delete NAME

NAME is the name of the CIFS server that you are deleting.


7-56

Managing CIFS Wide Links Wide links allow CIFS shares to span volumes in one or more virtual severs or NAS Gateways. Wide links are supported in a multiprotocol environment because the CIFS wide link interacts with an NFS symbolic link to allow access. When you add a wide link, you are creating a rule for a symbolic link, and that rule determines the target volume or CIFS server that the client wants to access. The following section provides some examples of how wide links operate. By default, wide links are enabled.

Note - Before you can use the wide link feature, you need to set up domain trusts. For more information on how to setup domain trusts, see www.microsoft.com. Wide links can allow clients to follow shares to different domains only if the domains are trusted.

Examples of Wide Link Behavior When you configure a CIFS wide link, you are configuring a mapping rule through symbolic link. The mapping rule sets the target volume for the CIFS link, so that when the CIFS share is accessed, the wide link mapping translates to the correct volume, directory, or file at the end of the link.

The following examples show some wide link rules created on the ONStor NAS Gateway and the symbolic links on a UNIX client, then explain the wide link behavior.

Consider the following wide link rules on the NAS Gateway:1. symlink add vol1 /Redir1 /mnt/vol12. symlink add vol1 /Redir2/Redir3 /mnt/vol1/Test3. symlink add vol1 \\srv\share\Redir4 /mnt/vol2

And, assume the following symbolic links have been created on an UNIX box:1. ln -s /mnt/vol1/afile.txt sym12. ln -s /mnt/vol1/Test/dirB sym23. ln -s /mnt/vol2/dirC/dirD sym3

When a CIFS client accesses sym1, mapping rule 1 is applied and the client is redirected to the path /Redir1/afile.txt at the root of volume vol1. The software


7-57

took the path /Redir1 from the mapping rule and /afile.txt from the remaining symbolic link target text.

When a CIFS client accesses sym2, mapping rule 2 is applied because it matches more characters than mapping rule 1. The client is redirected to the path /Redir2/Redir3/dirB at the root of volume vol1. The software took the path /Redir2/Redir3 from the mapping rule and /dirB from the remaining symbolic link target text.

When a CIFS client accesses sym3, mapping rule 3 is applied and the client is redirected to \\srv\share\Redir4\dirC\dirD. The CIFS server srv can be any CIFS server on the network and share can be any CIFS share on that server. EverON software took the path \\srv\share\Redir4 from the mapping rule and /dirC/dirB from the remaining symbolic link target text.

CIFS Behavior Considerations with Wide LinksBefore you begin managing wide links, consider the following notes about CIFS behavior:

• If you attempt to delete a wide link in Explorer, Explorer first follows the link to the target directory and deletes all of the files in that directory. It then appears to have deleted the wide link itself, but refreshing the directory shows that it still exists. When this operation completes, the wide link can point to a nonexistent target, because the target directory was deleted.

• If the target of the wide link is not available, Explorer displays an error message and the cmd shell when you try to access the wide link.

• If you already have a drive mapped to any share on the target server of a wide link, and that user name used to connect to that server is not the same one as you used to connect to the originating virtual server, you are denied access when trying to follow the wide link. You will see the following error message about attempting to log on to the target server with multiple user IDs:

Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.


7-58

• If the target of a wide link is a server and share in another authentication domain, access is denied without a logon dialog.

• Macintosh (Mac) clients do not support wide links/DFS. The Mac displays wide links, but when clients click the wide link, nothing is returned.

• A cmd shell deletion cannot remove a wide link.

• You cannot rename a wide link.

Adding Wide LinksWide link functionality is configured and controlled through a symbolic link. To add a wide link, run the symlink add command. This command adds a mapping rule for CIFS clients when they access an absolute NFS symbolic link. NFS clients find the target of an absolute symbolic link by checking their locally mounted file systems, while the NAS Gateway finds the target for CIFS clients.

The target of the wide link can be a path within the same volume, or a path to another CIFS server which then processes the access request through the wide link feature.

To Add a CIFS Wide Link

• Run the following command:symlink add VOLUME REDIRECTEDPATH LINKTARGETTEXT


VOLUME Specifies the name of the volume on which to apply symbolic link mapping rule.


7-59

To delete a wide link, run the symlink delete command. This command immediately removes the wide link functionality. Therefore, the client accesses the link or symbolic link as normal. Be aware that if your data is accessible through a wide link, and you delete the wide link, the data is no longer accessible until you create a mount point on the volume that contains it.

Note - When a wide link rule is deleted, the link between source and target does not become immediately inaccessible. Instead, the link can remain displayed and accessible for up to 10 minutes. This behavior is controlled by a link timeout that is set on the client, not by the NAS Gateway.

REDIRECTEDPATH Specifies the path the CIFS client should follow when it encounters an absolute symbolic link whose target text starts with the text in the LINKTARGETTEXT argument. The REDIRECTPATH can be either of the following:• A path within the same volume of the form /dir1/dir2/dir3/...

This form redirects the CIFS client to a specific directory within the same volume as the symbolic link.

• A CIFS share path of the form \\server\share\dir1\dir2\dir3\.... This form redirects the CIFS client using ONStor GNS and Microsoft DFS to any other CIFS server and share.

LINKTARGETTEXT Specifies an NFS-style path of the form /dir1/dir2/... When a CIFS client encounters a symbolic link whose target text starts with LINKTARGETTEXT, the client is redirected to the path REDIRECTEDPATH. The longest matching rule is applied.



7-60

To Remove a Symbolic Link

• Run the following command:symlink delete VOLUME LINK

Viewing Wide LinksTo view a wide link, run the symlink show command. This command displays the current list of all wide links and symbolic links on the current NAS Gateway.

To Display the Symbolic Links Configured on a Volume

• Run the following command:symlink show VOLUME

VOLUME specifies the volume for which you want the symbolic link mapping rules displayed. Enter the name of the volume for which you want to display symbolic links.

As an alternative, you can also view the wide link from the Link Properties window on the Windows client. You cannot administer the link from this window. Figure 7-4 shows the Link Properties widow.


VOLUME Specifies the volume from which you are deleting a mapping rule. Enter the name of the volume from which you will be deleting a symbolic link.

LINK Specifies the symbolic link that you are deleting. Because you are creating a mapping for an absolute symbolic link, enter the name of the configured symbolic link that you want to delete, and include the root slash (/). For example: /pubs/ paulw/filter


7-61

Figure 7-4 Properties Dialog Showing Configured Wide Link


7-62

Exporting and Importing Shares Exporting and importing CIFS and NFS shares facilitates recovery efforts. It is used for disaster recovery in the following way:

Step 1: Create a remote mirror (with local baseline or not).

Step 2: Export the shares of the source volume.

Step 3: Start the mirror.

Step 4: Halt the source cluster/filer.

Step 5: Promote the target volume.

Step 6: Rename it the same as the source volume, or when importing the shares specify the name of the target volume.

Step 7: Verify client can access (probably need to unmount/mount on NFS and reconnect on CIFS) CIFS and NFS shares are exported to a share list text file from the source volume.

The share list text file is then imported to a target volume. The share list file consists of a list of shares and corresponding options, share names, and comments, one per line. The share list file also contains the source release version, and the file format is as follows:

version

share1path [NFSoptions|CIFSoptions]

NFS shares are exported using a path relative to the volume name, so the source and target volume names can differ. CIFS share path names are independent of the volume name. Table 7-9 lists actual share paths and the exported share path.

Table 7-9: Share Paths

Actual Share Path Exported Share Path Description

\ \ CIFS root share

/vol1 / NFS root share

\dir1 \dir1 CIFS share


7-63

When importing shares to a target volume, the share list file is parsed, and each share is created on the target volume. The target volume must be online. An event log is generated for each share to indicate whether the share creation on the target volume succeeded or failed.

Note - You can have spaces in share names, share paths, and comments. However, you need to enclose share names with spaces in double quotation marks.

Exporting Shares ListsExports CIFS and NFS shares to a file on a specified volume. Exported shares can be subsequently replicated (imported) on another volume. Shares are typically replicated to another volume after the volume data is replicated or moved to another volume or gateway.

To Export a List of Shares from a Source Volume to a Share List File for Importing to a Target Volume

• Run the following command:volume share export VOLNAME LOCATION [-V VIRTUALSERVER] (all|SHARELIST) [SHARELIST...]

/vol1/dir1 /dir1 NFS share

IPCS$ Hidden CIFS shares are not exported


all All CIFS and NFS shares to be exported.

Table 7-9: Share Paths (Continued)

Actual Share Path Exported Share Path Description


7-64

Importing Shares ListsImports CIFS or NFS shares previously exported through the volume share export command. Shares are typically replicated to another volume after the volume data is replicated or moved to another volume or gateway.

To Import a Previously Exported List of Shares Onto a Target Volume

• Run the following command from the virtual server context:volume share import VOLNAME LOCATION [-V VIRTUALSERVER]

LOCATION Specifies the path to a file where to store the exported shares.

SHARELIST Specifies one or more space-separated CIFS and NFS shares to be exported.

VOLNAME Specifies a source volume where file specified with the LOCATION argument resides.

-V VIRTUALSERVER Specifies the virtual server that owns the source volume specified with VOLNAME. The default is the current virtual server. If you are already in the context of the virtual server that owns the source volume, this argument is optional.


LOCATION Specifies the path to a file containing the share list information or created using the volume share export command.

VOLNAME Specifies a target volume where file specified with the LOCATION argument resides.

-V VIRTUALSERVER Specifies the virtual server that owns the target volume specified with VOLNAME. The default is the current virtual server. If you are already in the context of the virtual server that owns the target volume, this argument is optional.



7-65

Note - Use the vol import command only if the volume to be moved is from another cluster.


7-66

Managing ID MappingsYou can manage ID mappings in one of the following ways:

• Editing ID mappings

• Showing ID mappings

• Deleting ID mappings

• Forcing an update of ID mapping rules

Editing an ID MappingThe NAS Gateway supports identity mapping between NFS and CIFS domains. With identity mapping, you can specify rules that govern the following translations:

• How NFS user and group IDs (UIDs and GIDs, respectively) are translated to CIFS users and groups

• How CIFS users and groups are translated to NFS UIDs and GIDs

You can edit an ID mapping by running the idmap edit command. The process of editing allows you replace an ID mapping in the Identity List. As part of this command, you specify an index number, which is a numerical value that indicates which entry in the list will be replaced. Because an entry in the list will be replaced with a new entry, the net result is zero, and no movement occurs in the list.

This command operates in two steps:

1. You enter the command syntax shown except for the mapping information. For example, you would run the idmap edit user 1 command to edit the first user ID map entry. The NAS Gateway will accept the command syntax then prompt you with the > for the actual syntax of the map entry that you are editing.

2. You enter the actual map entry after the NAS Gateway presents you with the > prompt.

To Edit an ID Mapping



7-67

idmap edit {user|group} INDEX

Step 2: When the NAS Gateway prompts you with the > prompt, enter the mapping information. Mapping information is a construction of CIFS identity, translation director, and NFS identity that you want to edit. For example:

• spectrum\user7077=>user7077@onstorlab could be a map for a user.

• spectrum\techpubs==publications@stylus could be a map for a group.

• spectrum\ <=user7077@onstorlab could be a map that creates an entry for a user that maps to nobody in the CIFS domain.

• spectrum\guest<=user7077@onstorlab could be an map that creates an entry for a user that maps to the “guest” user in the CIFS domain.

Showing the ID MappingsWhen you configure ID mappings, the NAS Gateway adds the user and group mappings to the Identity List. You can display the Identity List by running the idmap show command.

The Identity List contains separate sections for user and group mappings. As part of this command, you can filter the output by specifying the type of ID mapping–either


user|group Specifies the translation semantics for users and groups. This argument takes the specific syntax that is referenced in the idmap insert command.

INDEX Specifies the number that controls where in the list the ID mapping will be added. Enter the same index number as the entry that you are replacing.


7-68

user or group–that you want the NAS Gateway to display. As an option, you can use the “all” keyword to see both sections of the Identity List.

The Identity List contains information about the user or group names for CIFS and NFS, the index number for each mapping, and the direction of name mapping.

To Display ID Mappings

• Run the following command:idmap show {all|user|group}

Choose on of all|user|group to display the contents of the Identity List:

• all displays all entries in the Identity List. Users are displayed at the top of the Identity List, then groups are displayed.

• user causes the NAS Gateway to display only the user entries in the Identity List.

• group causes the NAS Gateway to display only the group entries in the Identity List.

Deleting an ID MappingYou can delete an ID mapping any time after it has been created. When you delete an ID mapping the user or group for which you created the mapping can no longer be translated between a CIFS or NFS domain. Therefore, that user or group can log in to their native domain only. For example, a native CIFS user or group will not be able to log in to a NFS domain, and a native NFS user or group will not be able to log in to a CIFS domain.

To Delete an ID Mapping

Step 1: Run the following command and locate the user’s or group’s ID mapping that you want to delete:idmap show all

Step 2: Run the following command to delete the ID mapping:


7-69

idmap delete {user|group} INDEX

Forcing an Update of the ID Mapping RulesCertain conditions on the Windows or NIS domain controllers can affect how the NAS Gateway recognizes and maps NFS and CIFS users through the ID map. For example, if a new NIS username is created, it might cause a new mapping to match to a CIFS user that did not exist before. In this type of situation, the NAS Gateway must update some system cache information and user and group mappings in the Security file. You can cause an explicit update by running the idmap notify change command.

The idmap notify change command is helpful for situations where you know of changes to the CIFS or NIS configuration. For example, assume you need to change an NIS map on your NIS server. When you add an entry for the user “timg” to your NIS password map, you know it will have an impact on the NAS Gateway’s identity mapping because “timg” has an account in a CIFS domain. In situations like this, you use the idmap notify change command so that quotas are recomputed to properly account for the charge.

The idmap notify change command allows you to alert the NAS Gateway to changes in the ID Map. The NAS Gateway can then reconstruct the ID map with new quota-related information. When the new ID map is constructed, internal caches, and the user and group records in the Security file are refreshed. The relevant entries are updated to


user|group Specifies which type of user map you want to delete. • Enter user to delete a user ID mapping.• Enter group to delete a group ID mapping.

INDEX Specifies the index number associated with the ID map entry that you are deleting.

Note - Note - The entries in the Identity List are numbered sequentially, so when you delete an index entry, the remaining entries will renumber to move up or down in the Identity List to keep a contiguous range of numbers.


7-70

use the most recent version of the ID Map, which ensures that the user and group entries are kept current. The idmap notify change command invokes a quota rebuild phase.

To Force an Update of the ID Mapping Rules

Step 1: Create a virtual server and configure a volume in it. For more information about configuring virtual servers, see “Working with Virtual Servers” on page 3-1.

Step 2: From the context of the virtual server that contains the volume where the quota is configured, run the following command: idmap notify change {user|group}

Choose either user or group to specify the type of quota you are enabling on the volume named in volname. You can specify one or more quota types. If you specify multiple quota types, separate each quota type with a comma—for example, user,group.


7-71

Multiprotocol File Access Without Using NISEverON software supports multiprotocol file access without having to use an NIS domain controller to process user and group ID mappings. A local copy of the password and group files for every virtual server is stored in the cluster database.

• The local password file contains the user name, the UID, and the primary GID for every user. The information is stored in the following form:

- uname1::uid1:pgid1:::

- uname2::uid2:pgid2:::

• The local group file contains the group name, the GID, and a list of every user name for that group. The information is stored in the following form:

- gname1::gid1:user-list1:::

- gname2::gid2:user-list2:::

ID mapping for multiprotocol file access is performed on a per-virtual-server basis using local password and group files. The local file enable a virtual server to use a localhost NIS domain instead of an external remote NIS domain. You can import and edit the password and group files from external servers or clients, or create new password and group files. A separate set of files must be created for each virtual server that is used for multiprotocol file access.

Setting the Local NIS DomainLocal NIS domains are configured on a per-virtual server basis through the vsvr set domain nis command. To support the local NIS domain, the NAS Gateway uses a reserved domain name called localhost with the IP address of 0.0.0.0. The localhost domain must be created once per cluster with the command:

domain add nis localhost 0.0.0.0

To configure a virtual server in the reserved NIS domain localhost, set the context to the specific virtual server and add it to the localhost domain with the commands:

vsvr set <vsvr name> vsvr diag vsvr set domain nis localhost


7-72

Importing Password, Netgroup, and Group Files for Multiprotocol File AccessYou can import the password and group files for multiprotocol file access from an FTP server by running the localmap import command. Because local host information is kept on a per-virtual server basis, you need to run the command from the virtual server context.

Note - Export functionality is not supported in this release.

NIS mappings support local password and group files for multiprotocol file access without an NIS server. If you are using this feature, consider the following:

• You need to import and/or configure both the passwd and group files for correct configuration. The netgroup file is optional.

• You need to manually refresh the cached user name and group name information for virtual servers that are using the local NIS maps. To refresh the information, you can do either of the following:

- Disable, then re-enable the virtual server by running the vsvr disable command followed by the vsvr enable command.

- Run the idmap notify change user|group command to flush any old mappings out of the cache, and allow the new mappings to be cached.

To Import Password, Netgroup, and Group Files From an FTP Server

Step 1: From within the virtual server context, set the virtual server to the domain localhost by running the command:vsvr set domain nis localhost

Step 2: Import the password or group file by running the localmap import command from the virtual server context:


7-73

localmap import {passwd|netgroup|group} ftp://USER:PASSWORD@IPADDR/PATHNAME

Editing Password, Netgroup, and Group Files for Multiprotocol File AccessYou can create and edit password and group files for multiprotocol access by running the localmap edit command. This command starts a vi editor that allows you to modify the password and group files. You can use this command to:

• Add user names and IDs, and group names and IDs to the password and group files.

• Delete user names and IDs, and group names and IDs from the password and group files.

To Edit Password and Group Files

Step 1: From within the virtual server context run the command to start a vi text editor with the contents of the respective file:


passwd Imports the password file to be used by the current virtual server.

netgroup Imports the netgroup file to be used by the current virtual server.

group Imports the group file to be used by the current virtual server.

USER Specifies the user account on the FTP server.

PASSWORD Specifies the user password on the FTP server.

IPADDR Specifies the IP address of the FTP server from where to download the file.

PATHNAME Specifies the directory path to the file to be downloaded. PATHNAME is the location on the server specified by IPADDR.


7-74

localmap edit {passwd|netgroup|group} -g|-s

Step 2: Make your edits from within the vi text editor.

Step 3: When you have finished editing the file, save the file in the vi text editor and close it.


passwd Specifies to edit a password file.

netgroup Specifies to edit a netgroup file.

group Specifies to edit a group file.

-g Displays the file.

-s Specifies that the edits are saved. When you edit the file, press Enter at each line you are editing. When you have finished editing, type exit and press Enter again.


7-75

Working With Symbolic LinksSymbolic links are a way of representing a real directory path in a shorter and easier way to comprehend. Symbolic links relate to a volume or directory in the EverON file system. For example, the path /vol1/marketing/users/paulw/home could be represented much more intuitively through the use of a symbolic link as /marketing/paulw. The implementation of CIFS by the ONStor software provides a mechanism to create symbolic links.

The NAS Gateway supports relative and absolute symbolic links. However, absolute symbolic links require a symbolic link mapping rule. The CIFS server on the NAS Gateway processes the link to access the storage area network (SAN) resource that is the target of the symbolic link.

Symbolic links are native to UNIX, so NFS clients support symbolic link functionality natively. However, CIFS clients do not recognize symbolic links natively, so you need to configure a symbolic link map if the link is an absolute symbolic link. The map contains rules that allow the CIFS client to understand and follow the path represented in the symbolic link to its target. For more information about the symbolic link map, see “Creating Symbolic Link Mapping Rules” on page 7-77.

CIFS clients evaluate the symbolic link on the NAS Gateway, and interpret where to orient the path based on whether the symbolic link is an absolute or relative link. For more information about types of symbolic link supported on the NAS Gateway, see “Support for Absolute and Relative Symbolic Links” on page 7-77.

Symbolic Links and the Directory TreeBy definition, the CIFS protocol cannot open a file directory above your point in the directory tree. However, the NAS Gateway has optimized the usage of this rule with symbolic links. The NAS Gateway enforces some rules on navigating a symbolic link:

• When a client receives its connection point in the directory tree, the NAS Gateway will allow a symbolic link to move anywhere from the connection point down the directory tree without restriction.

• When a client needs to navigate up the directory tree, the NAS Gateway allows the symbolic link to move anywhere above the connection point, but only temporarily


7-76

and only if the symbolic link’s target is equal to or below the directory tree connection point.

• The NAS Gateway never allows a symbolic link to move to a target that is above the client’s initial connection point in the directory tree.

Deletions and Symbolic LinksThe NAS Gateway’s implementation of CIFS includes a mechanism that ensure correct deletion of objects linked by symbolic links. The NAS Gateway tracks the name of the object you opened and allows for the correct deletion of the opened object. Consider the following example.

A symbolic link named \e is targeting \a\b\c. When a Windows user attempts to delete \e, the NAS Gateway responds by deleting \e, which is the open object, whereas some other devices would delete \c, which is the target of the symbolic link.

Deletion of All Objects in a PathThe NAS Gateway’s implementation of CIFS handles deletion of all objects in the path through the del * command. In some cases, when a user deletes all objects on a path that includes a symbolic link, some other devices can fail to delete all objects. Consider this example.

On a Windows client, you are at the top level directory and three subdirectories exist below called dirA, dirB, and dirC. The directory dirA contains the file A.doc that is a symbolic link to \C. When a user on the Windows client run the del * operation from the top level, the NAS Gateway correctly deletes all files in the subdirectories and the subdirectories themselves. Some other devices would fail the deletion because when the devices reach dirC it’s an empty directory and cannot be removed.

Parent

dirA dirCdirB

A.doc

Figure 7-5 Sample Deletion Through Symbolic Link


7-77

Support for Absolute and Relative Symbolic LinksThe NAS Gateway supports both absolute and relative symbolic links. An absolute symbolic link always begins with a slash (/) and the path is always oriented to the root of the file system. A relative symbolic link always begins with a nonslash character, and the path is always oriented to the parent directory of the symbolic link. The NAS Gateway has a symbolic link feature that supports relative symbolic links. You don’t have to create a mapping for a relative symbolic link.

The NAS Gateway supports absolute symbolic links through a rule that maps the symbolic link to an actual file system volume and directory. After the rule is created, CIFS clients that seek to access that directory are subject to the rule. The symbolic link and the actual link can exist simultaneously, and users can navigate to the appropriate directory using either method. But, by default the NAS Gateway will always choose the symbolic link first. To support absolute symbolic links, you need to create a symbolic link mapping. See “Creating Symbolic Link Mapping Rules” on page 7-77.

Note - Symbolic link mappings are per-volume, and the target of the symbolic link must always lead to the same volume. You cannot create a symbolic link whose target is on a different volume.

Creating Symbolic Link Mapping RulesSymbolic links can facilitate file access. A symbolic link is a mapping between a representative path and an actual path to a volume or directory. For example, a symbolic link for /pubs/projects/users/paulw/filter could be created as/filter. However, in a mixed CIFS and NFS environment, problems can arise because NFS can process a file system path that uses an absolute symbolic link, but CIFS cannot.

To allow CIFS clients to process absolute symbolic links, you create a rule for mapping an absolute symbolic link so that every CIFS client’s access request for that target can be processed. When the client follows the symbolic link, security settings are applied to the directory and target in the symbolic link as if the client was following a standard path.


7-78

The NAS Gateway will not support absolute symbolic links without a symbolic link mapping. The mapping allows a CIFS client to follow a symbolic link to a target that is supported on the same share only. Without a symbolic link mapping, a target volume or directory is still available through the actual path.

If a symbolic link is configured to a target, the NAS Gateway always follows that link. However, based on permissions, a user might not be able to open or manipulate the target of the symbolic link. In such cases, the NAS Gateway will allow the client to traverse the directory, but will display an empty directory if the permissions disallow the manipulation of the object at the target of the symbolic link.

If multiple links are configured, the NAS Gateway matches to the longest path. By default, a symbolic link is active when it is added to the NAS Gateway. The NAS Gateway can support a total of 32 symbolic links in one path.

The NAS Gateway also uses symlinks to support wide link functionality. A wide link is a CIFS share that is interacts with an NFS symlink to allow access to domain controller that can be in another domain or accessable through another virtual server. When you add a wide link, you are creating a rule for a symlink, and that rule determines the target volume or CIFS server that the client wants to access. Consider the following example of a wide link rule added to the NAS Gateway:symlink add vol1 \\srv\share\Redir4 /mnt/vol2

Assume the following symbolic link exists on an UNIX client:ln -s /mnt/vol2/dirC/dirD sym3

When a CIFS client accesses the symbolic link, the mapping rule is applied and the client is redirected to \\srv\share\Redir4\dirC\dirD. The CIFS server srv can be any CIFS server on the network and share can be any CIFS share on that server. The NAS Gateway takes the path \\srv\share\Redir4 from the mapping rule and /dirC/dirB from the remaining symbolic link target text.

You can create a symbolic link’s mapping rule by running the symlink add command.


7-79

Note - The symlink add command creates a symbolic link mapping rule for absolute symbolic links only. Symbolic links are always available through NFS, and they can be created through NFS without using this command. However, NFS-created symbolic links might not be accessible through CIFS unless you map the symbolic link with the symlink add command.

To Create a Symbolic Link Mapping Rule

• Run the following command:symlink add VOLUME TARGET LINK

Displaying a Symbolic Link Mapping RuleYou can display the symbolic link mappings configured on a volume by running the symlink show command. This command displays the symbolic links on a per-volume basis, so you need to run this command on each volume if you want to see all symbolic links configured.

To Display the Symbolic Links Configured on a Volume

• Run the following command:symlink show VOLUME


VOLUME Specifies the volume on which the mapping rule applies.

TARGET Specifies the directory to which the symbolic link is pointing. Enter the name of the directory without specifying the root slash or the parent directories that precede the target directory. When you specify the target directory, enter just the directory name and use a blank space to separate the target directory from the volume listed in VOLUME.

LINK Specifies the symbolic link that you are creating to represent the actual path to the target. Because you are creating a mapping for an absolute symbolic link, enter the symbolic in reference to the root, so include the root slash (/). For example: /pubs/paulw/filter


7-80

VOLUME specifies the volume for which you want the symbolic link mapping rules displayed. Enter the name of the volume for which you want to display symbolic links.

Removing a Symbolic Link Mapping RuleYou can remove a symbolic link mapping rule any time after it has been configured by running the symlink del command. When you remove a symbolic link mapping rule, the mapping and rule is completely deleted from a specified volume. You need to remove symbolic link mapping rules individually. Therefore, you need to run the symlink del command once for each symbolic link mapping rule you want to remove, and once on each volume. After a symbolic link mapping rule is removed, you can still access the previously linked volume or directory by navigating through the actual path.

To Remove a Symbolic Link

• Run the following command:symlink del VOLUME LINKTARGETTEXT


VOLUME Specifies the volume from which you are deleting a mapping rule. Enter the name of the volume from which you will be deleting a symbolic link.

LINKTARGETTEXT Specifies the symbolic link that you are deleting. Because you are creating a mapping for an absolute symbolic link, enter the name of the configured symbolic link that you want to delete, and include the root slash (/). For example: /pubs/paulw/filter.


Chapter 8: Managing File AuditingThis chapter contains the following sections:

• “Understanding File Auditing” on page 8-2

• “Managing File Auditing” on page 8-9

• “Configuring File Auditing” on page 8-19


8-2

Understanding File Auditing The ONStor implementation of file auditing occurs on a per-volume basis. Each volume contains one audit log file. File auditing occurs at the file or directory level, when the user actually attempts to perform an action on a specified file or directory. However, the file or directory access requests are queued on the Gigabit Ethernet (GE) file processor (FP) element while the NAS Gateway checks the user’s permissions and the system control access list (SACL) on the file or directory. If the user is allowed to access the file or directory, the request is allowed to proceed past the FP element. If access is not allowed, the request is denied and does not proceed past the FP element. If auditing is enabled, the resulting success or failure result will be written to the audit log.

Audit log files are created on disk in a secure directory when you create the volume. To ensure complete security, each volume’s audit log file resides in a hidden portion of disk space. You can view its contents through a command that posts the audit log contents to the management console. By default, file auditing is disabled.

Note - The NAS Gateway supports viewing the audit log only through the audit show log command. Therefore, the NAS Gateway, Windows clients, or Windows servers cannot display the audit log file through the Windows Event Viewer.

File auditing for NFS is not supported.

File Auditing in CIFS File auditing in CIFS occurs when a user attempts to perform an action on a file. Concurrent with the user’s request for access to the file, the NAS Gateway checks two components at the file level:

• The SACL which is part of the Windows ACL. The SACL indicates which file operations should generate an audit or alarm, and which file access types should generate an audit event. The result of the SACL and the attempted operation by the user is either successful or failed. The SACL can specify which outcome, either


8-3

success or failure, generates the audit event. The success or fail event is then written to the audit log file.

• Execution privileges, grant users access rights to files. The privileges that are audited are:

- SECURITY

- BACKUP

- RESTORE

- TAKEOWNERSHIP

- TRAVERSE

For file auditing in a CIFS environment, configure the file auditing feature on the NAS Gateway, but also configure the Auditing tab for the file or directory that you want to audit. For example, you would:

• Log on as an administrator on a Windows client.

• Map a drive to a CIFS share.

• Select a directory.

• Select Properties>Advanced>Auditing for that directory.

Note - CLUSTER or SECURITY privilege are required for accessing the Auditing tab.

For more information about File Auditing in a Windows environment, see the Microsoft documentation at www.microsoft.com.

Audit EventsThe audit events are represented in the audit log file by ONStor abbreviations that represent Microsoft standard file access events. Each entry in the audit log contains an access mask that displays the information about the file operation that was audited. Table 8-1 shows the mapping of the Microsoft label to the ONStor abbreviation that is displayed in the audit log file. Use this table to decode the access mask in the audit log


8-4

file. The NAS Gateway performs auditing on file access operations only. Auditing does not occur on logon or logoff events.

Table 8-1: Audit Log Event Abbreviations

Abbreviation Event Description

RD FILE_READ_DATA For a file, indicates the right to read a file’s file data.For a directory, indicates the right to read a directory’s data.

WD FILE_WRITE_DATA For a file, indicates the right to write file data to the file.For a directory, indicates the right to create file in the directory.

AD FILE_APPEND_DATA For a file, indicates the right to append data to an existing file.For a directory, indicates the right to create a subdirectory.

REA FILE_READ_EA Indicates the right to read extended file attributes.

WEA FILE_WRITE_EA Indicates the write to read extended file attributes.

EX FILE_EXECUTE For a native code file, indicates the right to execute the file. If given to scripts, this right might cause scripts to be executable if the script interpreter allows.

DC FILE_DELETE_CHILD For a directory, indicates the right to delete a directory and the files in it, including read-only files.

RA FILE_READ_ATTRIBUTES Indicates the right to read file attributes.

WA FILE_WRITE_ATTRIBUTES Indicates the right to write file attributes.


8-5

An example entry in the audit log file is shown below.

DEL DELETE Indicates the right to delete the file or directory.

RC READ_CONTROL Indicates the right to read information in the file or directory’s security descriptor.

WDAC WRITE_DAC Indicates the right to modify the DACL on the security identifier.

WOWN WRITE_OWNER Indicates the right to change the owner in the security identifier.

SYNC SYNCHRONIZE Indicates the right to specify a write handle in a wait function during a synchronous I/O.

SEC ACCESS_SYSTEM_SECURITY Indicates a backup system’s rights to access the system level access control settings.

MAX MAXIMUM_ALLOWED Indicates that the file can be opened for as many of the other desired access right types as allowed by the ACL.

GR GENERIC_READ Indicates generic read access for a file or directory.

GW GENERIC_WRITE Indicates generic write access for a file or directory.

GE GENERIC_EXECUTE Indicates generic execute attribute for a file or directory.

GA GENERIC_ALL Indicates generic read, write, and execute access for a file or directory.

Table 8-1: Audit Log Event Abbreviations (Continued)

Abbreviation Event Description


8-6

Tue Aug 5 13:39:08 GMT 2003 -- Audit clear

user : root@local

Tue Aug 5 13:39:08 GMT 2003 -- Audit modify

user : user1@domainX

Tue Aug 5 14:44:04 GMT 2003 -- Audit modify

user name: domainY\user2

Tue Aug 5 14:49:13 GMT 2003 -- File access


Path name: /test.tst

Access granted: yes

Request type: Access file

Access mask: 00020000 - RC

Privileges used: restore


user : domainY\user2


Access granted: yes


Access mask: 00020000 - RC



user : domainY\user2


Access granted: yes


Access mask: 00020089 - RD REA RA RC






8-7

Access granted: yes


Access mask: 00020080 - RA RC


This example audit log text contains entries for config records and audit records. In the example, the config records are smaller. They have a title that is anything other than “file access,” and the titles indicate which action was performed. For example, the first three entries in this example are config records. These entries indicates that the NAS Gateway admin with ID “root@local” changed the auditing configuration by first clearing the audit log file, then NAS Gateway admin “user1@domainX” modified the auditing configuration. The last config record shows that NAS Gateway admin “domainY\user2” also changed the auditing configuration.

Note - You can determine the domain type by the admin ID format. IDs from a UNIX domain have the format “admin@domain”, as in user1@domainX. IDs from a Windows domain have the format “domain\admin”, as in domainY\user2.

The remainder of the entries are audit records as indicated by their title “file access.” In this example audit log, you can see the following information is contained in each audit record:

• The date and timestamp at which the audit record was created, and the reason for the record. In these examples, a file access request was sent.

• User name information, including the domain in which the user is requesting access to a file.

• The path that the user used to attempt access to the file.

• The access information about the request, including whether file access was allowed or denied.

• The type of request the NAS Gateway received from the user.

• The access mask, which is the string of numerals and the file access abbreviation(s) that indicate which actions were attempted on the file. These


8-8

abbreviations map closely to access mask values used by Windows devices, but the abbreviation for each label is related to the EverON file system. For a list of access mask values and their ONStor abbreviations, see Table 8-1 on page 8-4.

• The privileges used to access the file.


8-9

Managing File Auditing File auditing is supported on files and directories that are configured in a volume that is accessed by UNIX and CIFS clients.

Enabling and Disabling File Auditing on a VolumeWhen you enable file auditing for the first time, the NAS Gateway creates the audit log file on disk for the specified volume, and the same audit log file is used for subsequent audits regardless of how many times the auditing software is enabled or disabled on that volume. By default, file auditing is disabled.

Note - File auditing can impact the NAS Gateway while enabled based on the volume of transactions and amount of data scanned in each file transaction.

When you disable file auditing, all entries in the audit log file are retained. The audit file will remain configured on the volume.

To Enable File Auditing

• Run the following command:audit enable VOLNAME

To Disable File Auditing

• Run the following command:audit disable VOLNAME

VOLNAME specifies the volume on which the file auditing is being enabled or disabled.

Setting or Deleting Success ParametersAs part of file auditing, you need to specify the audit parameters that will be tracked. Parameters can be tracked for positive events on the volume, such as successful file operations. You can determine if a file operation has been successful by comparing privilege levels, such as backup, take ownership, and restore, to file level permissions.


8-10

If this comparison results in acceptance of the operation, the file operation is successful.

You can declare which successful file operations are tracked by configuring a success parameter. The success parameters specifies all the file operations that you want to appear in the audit log when a comparison of the ACL to the SACL on the file allows the operation to occur.

Note - You cannot configure actual permissions through any auditing commands. You only specify the permissions that will create an audit record in the audit log file. To configure permissions, run the priv add command. For more information about this command, see “Managing Privileges” on page 2-1.

The NAS Gateway compares the permission that is attempting a file access with the permission required for that file access. In the case of success parameters, the NAS Gateway then adds a record to the audit log file whenever the comparison allows the file access.

A deleted success parameter is not automatically tracked as a failure parameter. If you want a deleted success parameter to be tracked for failures, you need to configure it as a failure parameter. For more information about configuring failure parameters, see “Setting or Deleting Failure Parameters” on page 8-11.”

To Set the Success Parameters

• Run the following command:audit set success_privilege VOLNAME PRIVILEGES


8-11

To Delete One or More Success Parameters

• Run the following command:audit unset success_privilege VOLNAME PRIVILEGES

Setting or Deleting Failure ParametersAs part of file auditing, you need to specify the audit parameters that will be tracked. Parameters can be tracked for negative events on the volume, such as failed file operations. The determination of a failed file operation is made through a comparison of privilege levels, such as backup, takeownership, or restore, to file level permissions. If this comparison results in denial of the operation, the file operation fails.

You can declare which failed file operations are tracked by configuring a failure parameter. This parameter specifies all the file operations that you want to appear in the audit log when a comparison of the ACL to the SACL on the file prevents the operation from occurring.


VOLNAME Specifies the name of the volume on which you want to track file operations that resolve if you are setting success parameters, or the name of the volume on which you want to delete success parameters.

PRIVILEGES Specifies one or more file privileges that you want the NAS Gateway to record in the audit log file if you are setting success parameters, or one or more file privileges that you no longer want the NAS Gateway to record in the audit log file. Enter one or more of the following privileges:• security• backup• restore• takeownership• traverseIf you enter multiple file operations, separate each operation with a blank space.


8-12

Note - You cannot explicitly configure actual permissions, for example “backup”– through any auditing commands. You only specify the permissions that will create an audit record in the audit log file. To configure permissions, run the priv add command. For more information about this command, see “Managing Privileges” on page 2-1.

The NAS Gateway compares the permission that is attempting a file access with the permission required for that file access. In the case of failure parameters, the NAS Gateway then adds a record to the audit log file whenever the comparison disallows the file access.

You can delete failure parameters that are configured for the audit log. A deleted failure parameter is not automatically tracked as a success parameter. If you want a deleted failure parameter to be tracked for success, you need to explicitly configure it as a success parameter.

To Set the Failure Parameters That Are Tracked in the Audit Log

• Run the following command:audit set fail_privilege VOLNAME PRIVILEGES

To Delete the Failure Parameters That Are Tracked in the Audit Log

• Run the following command:audit unset fail_privilege VOLNAME PRIVILEGES


VOLNAME Specifies the name of the volume on which you want to configure or delete failure parameters.


8-13

Disallowing File Operations From the Audit Log FileThe NAS Gateway’s ability to record operations in the audit log file can affect the completion of file operations. You can configure the NAS Gateway to disallow an attempted file operation if that operation cannot be recorded in the audit log file. The specified operation will fail, and the client will not be allowed to perform the operation because there is no way to track it.

To Disallow File Operations From the Audit Log File

• Run the following command:audit set fail_flag VOLNAME {yes|no}

PRIVILEGES Specifies one or more file privileges that you want the NAS Gateway to record in the audit log file if you are configuring failure parameters, or one or more file privileges that you no longer want the NAS Gateway to track if you are deleting failure parameters. Enter one or more of the following privileges:• security• backup• restore• takeownership• traverseIf you enter multiple file operations, separate each operation with a blank space.


VOLNAME Specifies the name of the volume on which you want to file operations to fail if they cannot be written to the audit log file.



8-14

Setting the Audit Log File’s Capacity You can set the total size of the file with the audit set filesize command. This command enables you to customize the audit log file’s capacity based on your use of file auditing. For example, if you intend to track few file operations for success or failure, you could set the audit log file to a smaller size. Conversely, if you want to enforce a very strict and detailed implementation of auditing, or if your network is exceptionally large or busy, you might want to set a large audit log file. There is a trade off with either situation:

• Smaller audit log files consume less disk space for the volume, but do not store an extensive audit trail.

• Larger audit log files consume more disk space for the volume, but provide a much more detailed and informative audit trail.

The default size of the file is 0 for unlimited space. The file behaves differently depending on whether the file is configured as a circular file:

• If the file size is 0 and the file is circular, the file will not wrap.

• If the file size is 0 and the file is not circular, it will continue to grow until it reaches the maximum disk space minus the amount of user data. At this point, the file will no longer accept new audit log entries. However, if you have configured AutoGrow on the volume, prior to the file reaching the truncation point, the NAS Gateway can automatically add more disk space.

Because the audit log file contains a full path, the size of each record in the file can vary, and therefore, the size of each file can vary. If you create success and failure

yes|no Specifies the state of denying a file operation that cannot be recorded in the audit log file:• yes causes the NAS Gateway to deny the file access operation if it

cannot be written into the audit log file. • no causes the NAS Gateway to allow the file access operation even

if it cannot be written into the audit log file. The default value is no.



8-15

parameters that track many or all privileges, set your audit log file to a larger size than if you have fewer success or failure parameters.

To Set the Audit Log’s Size

• Run the following command:audit set filesize VOLNAME FILESIZE

Controlling Audit File BehaviorBecause the audit file has a finite capacity, it behaves in one of two ways when it reaches capacity:

• It performs a circular write by wrapping to the beginning of the file and writing new entries over the first entry. For example, if the file is configured for 56 audit log records, the 57th audit log record will be written at location 1 of the file.

• It does not write any more entries. Instead it sends an audit log file notification that the file is full.

You can control the audit file by activating or deactivating the circular write. By default, circular write is disabled.

Note - If you elect not to enable circular write, you can clear the audit log file by running the audit clear command.


VOLNAME Specifies the volume on which you are setting the audit log file capacity.

FILESIZE Specifies the total size, in number of Kilobyte blocks, of the audit log file.


8-16

To Control the Audit File Behavior

• Run the following command:audit set circular VOLNAME {yes|no}

Displaying the File Audit Configuration Displays the audit configuration settings for the specified volume.

To View the File Auditing Configuration for a Volume

• Run the following command:audit show config VOLNAME

VOLNAME is the name of the volume for which you want to display the currently configured file auditing parameters.

Displaying the Audit Log File The NAS Gateway supports viewing the audit log only through the audit show log command. Therefore, the NAS Gateway, Windows clients, or Windows servers cannot display the audit log file through the Windows Event Viewer.


VOLNAME Specifies the volume on which you are enabling or disabling the circular write feature. Enter the name of the volume whose audit log you setting with the circular write feature.

yes|no Sets the state of the circular write:• yes activates circular write of new entries when the audit log file

reaches capacity.• no causes the file not to write new entries when the audit log file

reaches capacity.


8-17

To View a Volume’s Audit Log File

• Run the following command:audit show log VOLNAME MAXRECORDS

Clearing the Contents of an Audit Log FileClears the audit log file for the specified volume. The audit log file contains logs corresponding to file accesses within a volume.

To Manually Clear the Audit Log File

• Run the following command:audit clear VOLNAME

VOLNAME is the name of the volume that contains the audit log file you want to clear. All entries in the audit log file are erased, and the empty audit log file remains configured and ready to accept new entries.

Exporting the Audit Log FileExports the audit logs for a specified volume to a file.


VOLNAME Specifies volume for which you want to display the audit log file.

MAXRECORDS Specifies the number of audit records to display, from 1 to 20.


8-18

To Export the Audit Log File

• Run the following command:audit export VOLUME LOCATION [-m MINUTE] [-h HOUR] [-d DATE] [-M MONTH] [-D DATE]


VOLNAME Specifies the volume for which the audit log file is exported.

LOCATION Specifies the file path to store the audit log. If the path name is a directory, the audit log is stored in a default file name in the specified directory.The default file name is <VOLNAME>.<YYYYMMDD>.<NUMBER> where YYYYMMDD represents the date of the export. For example, in the case of an hourly export of volume VOL1 on 2/1/07, the export files would be VOL1.20070201.0, VOL1.20070201.1, ... VOL1.20070201.23.

-m MINUTE The -m parameter is the minutes (0-59) of the hour at which the report should be generated and sent.

-h HOUR The -h parameter is the hour (0-23) at which the report should be generated and sent.

-d DATE The -d parameter is the date (1-31) on which the report should be generated.

-M MONTH The -M parameter is the month (1-12) in which the report should be generated and sent.

-D DATE The -D parameter is the day of the week (0-7) on which the report should be generated. Day 0 or 7 is Sunday.


8-19

Configuring File AuditingThe following procedure describes how to figure file auditing on a volume. For this procedure, assume the following:

• The NAS Gateway has been configured with at least one virtual server. For more information about configuring virtual servers, see “Working with Virtual Servers” on page 3-1.

• The volume on which you want file auditing configured is named payroll.

• A client is attempting to access the target file “file1” in the file system.

• The audit log file will be set to 500 KB.

• The audit log file will be set to circular mode.

To Configure File Auditing

Step 1: Configure the audit log file’s capacity, by running the audit set filesize command:audit set filesize payroll 500

where 500 is the 500 KB file size of the audit log file.

Step 2: Configure the audit log file’s behavior by configuring it to wrap or discard new entries at capacity, and fail or allow file access based on whether the NAS Gateway can write an audit record into the audit log file, by running the audit set circular command. audit set circular payroll yes

• circular allows the file to wrap new entries to the beginning of the audit log file and overwrite the oldest entries.

• payroll is volume on which you are configuring whether access to target file can be allowed or not based on whether the NAS Gateway can write an audit record into the audit log file.

• yes indicates that audit entries will be overwritten when the audit log reaches capacity.


8-20

Step 3: Configure the failure events for the privileges that attempt file access, by running the audit set command:audit set fail_privilege payroll takeownership

• payroll is the volume on which you want file access attempts logged in the audit log file.

• takeownership is the privilege that will be audited for successful file access attempts.

Note - The NAS Gateway supports takeownership, traverse, security, backup, and restore privileges for auditing. You can enter these privileges as a space-separated list.

Step 4: Configure the success events for the privileges that attempt file access, by running the audit set command:audit set success_privilege payroll takeownership

• payroll is the volume on which you want file access attempts logged in the audit log file.

• takeownership is the privilege that will be audited for successful file access attempts.

Step 5: Enable file auditing by running the audit enable command:audit enable payroll

payroll is the volume on which you are enabling file auditing. When file auditing is enabled, it applies to all clients that use shares configured for the volume. For example, if payroll has 46 shares configured on it, the NAS Gateway will apply file auditing to all clients that use any of the 46 shares that export the volume, regardless of the file access protocol–NFS or CIFS–the share uses to advertise payroll to clients.

Step 6: Check the audit log configuration and verify that the auditing parameters are set correctly, by running the audit show config command:


8-21

audit show config payroll

payroll is the volume on which you are checking the auditing configuration.


8-22


Chapter 9: Managing SnapshotsThis chapter contains the following sections:

• “Snapshots Overview” on page 9-2

• “Managing Snapshots on the NAS Gateway” on page 9-4


9-2

Snapshots OverviewSnapshots are static images of the EverON™ file system. Each file system can support a maximum of 48 snapshots. The maximum size of these snapshots is limited by the amount of disk space. The NAS Gateway supports two types of snapshots: on-demand and scheduled.

• You can create an on-demand snapshot manually at any time. For more information about on-demand snapshots, see “Creating Snapshots On-Demand” on page 9-4.

• A scheduled snapshot occurs automatically at a preset time and frequency. For more information about scheduled snapshots, see “Creating Snapshot Schedules” on page 9-6.

Scheduled SnapshotsScheduled snapshots can occur either hourly, daily, or weekly. Daily snapshots are taken at midnight, and weekly snapshots are taken at midnight on every Sunday. Daily and weekly snapshots have the following scheduling considerations:

• If daily snapshots are configured, hourly snapshots do not occur at midnight.

• If weekly snapshots are configured, daily snapshots do not occur at midnight on every Sunday.

The NAS Gateway supports a default snapshot schedule, as shown in Table 9-2.

Table 9-2: Default Snapshot Schedule

Snapshot Type Supported? Maximum Snapshot Schedule

weekly no n/a n/a

daily yes 2 kept by default n/a

hourly yes 8 kept by default 8 a.m., 12 p.m.,4 p.m., 8 p.m.


9-3

File System Quotas and SnapshotsThe snapshots functionality includes the ability to revert a volume from a saved snapshot. These features can affect the NAS Gateway’s quota configuration. Restoring affects all types of quota: user, group, and tree.

Snapshot Location on the NAS GatewaySnapshots reside in the designated /.snapshots directory of the EverON file system. The /.snapshots directory is a central directory for each file system supported by the NAS Gateway. The NAS Gateway does not currently support one /.snapshots directory for each data directory within a file system.

All files in the /.snapshots directory are read only. The snapshots directory is created automatically at the time the file system is created. No default name exists for on-demand snapshots files, so when you create a snapshot, you need to name it with the snapshot create command before it can be saved to the /.snapshots directory.

Snapshots appear in the /.snapshots directory in most-recent to least-recent order. Because snapshots are numbered incrementally when newer snapshots arrive, the most recent snapshots are named hour.0, daily.0 or weekly.0. Older snapshots have a larger number, such as hourly.12, daily.5, or weekly.3.


9-4

Managing Snapshots on the NAS GatewaySnapshot management consists of the following tasks:

• “Creating Snapshots On-Demand” on page 9-4

• “Deleting On-Demand Snapshots” on page 9-5

• “Creating Snapshot Schedules” on page 9-6

• “Enabling and Disabling the Snapshot Schedule” on page 9-7

• “Viewing Snapshot Usage” on page 9-8

• “Restoring a Snapshot as a Live File System” on page 9-9

• “Renaming a Snapshot” on page 9-9

• “Pinning and Unpinning a Snapshot” on page 9-10

Creating Snapshots On-DemandThis command is used to create a snapshot of a volume.

To Create an On-Demand Snapshot

• Run the following command:snapshot create VOLNAME SNAPNAME -m


VOLNAME Specifies the volume that contains the file system that you are capturing with a snapshot.

SNAPNAME Specifies the name of the on-demand snapshot that you are taking. The file suffix (.ss) indicates that the file is a snapshot file. Snapshot names up to 31 characters long.

-m Creates a snapshot with a name reserved for mirror snapshots. Use this command if the volume is going to be replicated by array replication and subsequently used as a part of a mirror. The created snapshot will be used as the mirror baseline.


9-5

Note - If you name the on-demand snapshots with any of the default names for scheduled snapshots, the command fails. For more information about default names, see Table 9-3 on page 9-6. Do not name any on-demand snapshots with the following file names:

• hourly.x.ss

• daily.y.ss

• weekly.z.ss

Deleting On-Demand SnapshotsIf a snapshot is pinned, you need to unpin it before you can delete it. For more information about unpinning a snapshot, see “Pinning and Unpinning a Snapshot” on page 9-10. By default, the snapshots scheduled for mirrors are always pinned.

To Manually Remove an On-Demand Snapshot

• Run the following command:snapshot delete VOLNAME SNAPNAME


VOLNAME Specifies the volume that contains the snapshot snapshot you are deleting.

SNAPNAME Specifies the name of the on-demand snapshot that you are deleting.


9-6

Creating Snapshot SchedulesScheduled snapshots are named automatically based on the type of snapshot you schedule. See Table 9-3.

When scheduled snapshots are completed, they reside in the /.snapshots directory along with on-demand snapshots.

When creating the snapshot schedule consider the following:

• The default snapshots schedule should be adequate if:

- Files are not lost often.

- Lost files are noticed quickly after they are lost.

• A customized schedule that keeps snapshots for a longer amount of time should be used if:

- Files are lost often.

- Lost file are not noticed quickly after they are lost.

• Different snapshot schedules are supported on different volumes enabling you to customize snapshot schedules to closely match the activity of the volume.

Table 9-3: Snapshot File Naming and Maintenance

Snapshot Type File Name Maintenance Method

hourly hourly.n n is an integer that indicates the snapshot number. The NAS Gateway increments this integer from most recent to least recent snapshot.

daily daily.n n is an integer that indicates the snapshot number. The NAS Gateway increments this integer from most recent to least recent snapshot.

weekly weekly.n n is an integer that indicates the snapshot number. The NAS Gateway increments this integer from most recent to least recent snapshot.


9-7

To Create Scheduled Snapshots

• Run the following command:snapshot schedule VOLNAME [-w MAXWEEKLY[ [-d MAXDAILY[ [-h MAXHOURLY[ [-l HOURS]

Enabling and Disabling the Snapshot ScheduleBy default, the snapshot scheduler is enabled, so if you create a schedule, the snapshots automatically occur at the configured date and time. However, if the snapshot scheduler becomes disabled, you can manually enable the snapshot schedule.

Note - You can check the status of the snapshot scheduler by running the snapshot show schedule command. If the snapshot scheduler is disabled, the output of the show schedule command will show the following message:

**snapshot scheduling currently disabled for this volume**

If you attempt to modify the current snapshot schedule while the snapshot scheduler is disabled, the following error message is displayed:

snapshot operation not allowed


VOLNAME Specifies the volume on which you want to take snapshots of the file system.

-w MAXWEEKLY Specifies the maximum number of weekly snapshots to be kept.

-d MAXDAILY Specifies the maximum number of daily snapshots to be kept.

-h MAXHOURLY Specifies the maximum number of hourly snapshots to be kept.

-l HOURS An optional hours list that specifies the times at which to take snapshots. Hours in the list are separated with a comma. Valid range is 1 to 24, where 1 is 1 a.m., 12 is mid-day, and 24 is midnight. By default hourly snapshots occur at 8 a.m.,12 p.m.,4 p.m., and 8 p.m.


9-8

To Enable the Snapshot Scheduler

• Run the following command:snapshot enable VOLNAME

VOLNAME is the name of the volume on which you are enabling the configured snapshot schedule.

Note - These commands affect scheduled snapshots only. On-demand snapshots are not affected by command.

Viewing Snapshot UsageYou can use the snapshot show command to display all the snapshots that have been taken for a specific volume and the disk usage of snapshots. Through the disk usage, you can determine whether the snapshot schedule is too frequent by the amount of disk space that is consumed.

To View Snapshot Usage

• Run the following command:snapshot show VOLNAME {schedule|list|usage}


VOLNAME Specifies the volume associated with the snapshots whose usage you want to view.

schedule|list|usage Specifies what type of snapshot you want to display:• schedule shows the volume’s current snapshot schedule.• list shows the all snapshots names, creation times, and

internal snapshot IDs.• usage shows the volume’s disk usage for snapshots.


9-9

Restoring a Snapshot as a Live File SystemYou can restore a specified scheduled snapshot or an on-demand snapshot as a live file system.

Note - After the snapshot has been restored as the live file system, the NAS Gateway retains the target snapshot as a normal snapshot. The snapshot is not deleted when it has been restored as the new file system, and the NAS Gateway does not take a duplicate snapshot of the new file system. Snapshots occur as normal after a new file system has been created from a snapshot.

To Restore a Snapshot as the Live File System

• Run the following command:snapshot revert VOLNAME [-n SNAPNAME]

Renaming a SnapshotYou can rename an on-demand snapshot or a scheduled snapshot by running the snapshot rename command.


VOLNAME Specifies the volume on which you are restoring a snapshot as a live file system.

-n SNAPNAME An optional argument that specifies the name of the snapshot to be reverted as the file system. If you specify no SNAPNAME, by default, the NAS Gateway uses the most recent snapshot as the live file system.


9-10

Note - The NAS Gateway uses reserved names for some of its snapshots. If you are renaming a snapshot, you cannot use any of the following names or the command fails:

• hourly.x.ss, where x is a number.

• daily.y.ss, where y is a number.

• weekly.z.ss, where z is a number.

To Rename a Snapshot

• Run the following command: snapshot rename VOLNAME OLDNAME NEWNAME

Pinning and Unpinning a SnapshotWhen a snapshot is pinned, it cannot be deleted until it is unpinned. The NAS Gateway supports pinning and unpinnning on-demand and scheduled snapshots. Snapshots that use reserved names cannot be pinned.

To Pin a Snapshot and Prevent Its Deletion

• Run the following command:snapshot pin VOLNAME SNAPNAME


VOLNAME Specifies the volume that holds the snapshot you are renaming.

OLDNAME Specifies the current name of the snapshot.

NEWNAME Specifies the new name of the snapshot.


9-11

To Unpin a Snapshot

• Run the following command:snapshot unpin VOLNAME SNAPNAME


VOLNAME Specifies the volume on which you are pinning or unpinning a snapshot.

SNAPNAME Specifies the name of the snapshot to be pinned or unpinned.


9-12


Chapter 10: Managing File System Quotas


• “Quotas Overview” on page 10-2

• “Quota Interaction with Other NAS Gateway Features” on page 10-3

• “Configuring Default Quotas” on page 10-9

• “Enabling or Disabling Quotas” on page 10-17

• “Configuring Quotas” on page 10-19

• “Updating ID Mapping Rules” on page 10-22

• “Working With the Quota Log” on page 10-23


10-2

Quotas OverviewQuotas help to control the amount of disk space that can be used by a user, group, or part of the directory tree. You can ensure that disk space is available to other users, groups, and parts of the directory tree by controlling the amount of disk space that can be used.

File System Quotas and Volume-Level QuotasThe NAS Gateway supports volume-level quotas and file system quotas:

• Volume-level quotas can be configured with the volume create or volume modify command. Volume-level quotas are for setting usage and warning thresholds for a volume that is reaching capacity. For more information about volume-level quotas and the NAS Gateway’s AutoGrow feature, see the “Managing Volumes and File Systems” on page 6-1.

• File system quotas are configured to enforce usage conditions for clients that attempt to allocate space in the file system. File system quotas are used to deny a client the ability to allocate a file system object, or deny the allocation of a specific path element in the file system’s name space.

File system quotas enforce usage conditions first, and, therefore, volume-level quotas do not activate.

Quota TypesThe NAS Gateway’s quota implementation supports the following types of quotas:

• User quotas are usage conditions configured for a specific user or all users.

Note - User quotas cannot be deleted through the NAS Gateway’s CLI. If you no longer want quotas to operate in the file system, you can disable the quota. (See “Enabling or Disabling Quotas” on page 10-17.

• Group quotas are usage conditions configured for a specific group or all groups.

• Tree quotas are usage conditions configured on a specific location of the directory path, either on the root or anywhere along the directory path. Quota conditions on


10-3

lower levels of the directory structure are inherited from a higher-level tree quota. Inheritance of quota conditions moves downward from the directory where the tree quota is configured, so children of the directory inherit the quota usage conditions from the parent. Tree quotas can be either simple or nested. The main difference between simple and nested quotas is where usage is charged.

Note - The NAS Gateway supports a maximum of 64 levels of nesting, but configuring more than four levels of nesting can negatively affect performance.

For each quota type, you can set either default quotas or specific quotas:

• Default quotas apply the same usage conditions to every user, group, or tree quota that uses the volume. Default quotas are helpful when you want to set the same usage conditions for all user, group, or tree quotas in a volume.

• Specific quotas apply usage conditions that are different from the default quota’s conditions. Specific quotas are helpful when you want to set special usage conditions for some, but not all, user, group, or tree quotas on the volume.

Quota Interaction with Other NAS Gateway FeaturesFile system quotas have some interdependency with other file system features on the NAS Gateway. This section documents how the quotas are affected by the following:

• Backup and restore operations. See “File System Quotas and Backup and Restore Operations” on page 10-3.

• ONStor Data Mirror. See “File System Quotas and Mirrors” on page 10-8.

• Snapshots and snapshot revert operations. See “File System Quotas and Snapshots” on page 10-9.

File System Quotas and Backup and Restore OperationsFile system quotas are metadata that can be backed up when the NAS Gateway’s NDMP services run:


10-4

• During a full backup, any configured user, group, or tree quotas are backed up to tape. During a partial backup, quotas are not backed up to tape.

• During a full restore operation, the backed up file system quotas are restorable. During a partial restore operation, any quotas backed up are not restored.

Behavior is different if the quotas are being restored. When a restore operation occurs, two outcomes can exist for the backed up quota information:

• Quotas on tape can overwrite any quotas configured in the live file system.

• Quotas on tape can be discarded in favor of quotas in the live file system.

Both scenarios are controlled by ONStor-specific environment variables that determine whether quotas on tape should be restored to the live file system or not. See “Setting ONSTOR_SUPERSEDE_QUOTAS” on page 10-4.

File system quotas do not affect the data that is restored. For example, if an enforce tree quota allows 50 GB of file system space, and a restore operation contains 51 GB of data, the entire restore operation completes to the live file system. Quotas disregard data in restore operations to allow the entire data set to be restored.

The NAS Gateway’s implementation of quotas includes the following environment variables that affect how quotas are restored from tape:

• ONSTOR_SUPERSEDE_QUOTAS, which controls whether quota information on tape is overwritten when an NDMP restore session occurs.

• ONSTOR_IGNORE_USR_GROUP, which controls the behavior of user and group quotas when an NDMP restore session occurs.

• ONSTOR_IGNORE_QTREE, which controls the behavior of tree quotas when an NDMP restore session occurs.

For more information about the NAS Gateway’s implementation of NDMP, see “Managing Backup and Restore” on page 14-1.

Setting ONSTOR_SUPERSEDE_QUOTASThe NAS Gateway’s decision to overwrite or disregard the quota information from tape is based on the ONStor-specific environment variable ONSTOR_SUPERSEDE_QUOTAS that can be configured by a data management application (DMA) that moves data in an NDMP operation. This environment variable


10-5

accepts a “yes” or “no” value. The default is “yes.” If this variable is set to “no,” the variable affects different types of quota differently:

• If a user or group quota already exists, it is not updated with the limits and warning information from tape.

• If a tree record already exists on the directory in the destination volume, the tree quota is not updated with values from tape.

Table 10-4 explains the ONSTOR_SUPERSEDE_QUOTAS environment variable if it is set to “yes.”

Table 10-4: ONSTOR_SUPERSEDE_QUOTAS Set to Yes

On Tape On Disk Action on Restore

No tree quota Tree quota Files are added to the quota tree. The directory still remains a tree quota.

Tree quota Empty non-tree quota directory

Tree quota warning and limit values are restored from tape, directory becomes a quota tree.

Tree quota Non-empty, non-tree quota directory

Fail to set the tree quota values. In this situation, the data is restored but the quota metadata is not. A message is transmitted to the DMA to indicate that some of the contents of the tape are not restored.

Tree quota Non-empty tree quota directory

Tree quota warning and limit values are restored from tape.

Tree quota (simple) Tree quota (simple) Warning and limit values are restored from tape.


10-6

Setting ONStor Ignore User or Group QuotasThe NAS Gateway’s decision to restore or disregard the specific user or group quota information from tape is based on the ONStor-specific environment variable ONSTOR_INGORE_USR_GRP_QUOTAS that can be configured by a DMA that moves data in an NDMP operation.

With this environment variable, you can control how specific user and group quotas are restored. Default user or group quotas can also be restored but only in the case of a full restore operation of / (root directory) to either / (root directory) or a nonroot directory.

Tree quota (nested) Tree quota (nested) Warning and limit values are restored from tape. Tree quota settings are restored from tape.

Tree quota (simple) Tree quota (nested) Warning and limit levels are restored from tape. A warning message is transmitted to the DMA to indicate that the change from a nested quota to a simple quota is not supported. The nested tree is retained.

Tree quota (nested) Tree quota (simple) Warning and limit levels are restored. A warning message is transmitted to the DMA to indicate that the change from a simple quota to a nested quota is not supported. The simple tree is retained.

Table 10-4: ONSTOR_SUPERSEDE_QUOTAS Set to Yes (Continued)

On Tape On Disk Action on Restore


10-7

In some circumstances, the ONSTOR_INGORE_USR_GRP_QUOTAS variable can be set to “yes” automatically. The restore operation implicitly sets this variable to “yes” under the following conditions:

• When performing a selective restore operation of a file or a nonroot directory

• When performing a restore operation of a partial dump (a dump of a nonroot directory)

Table 10-5 describes the ONSTOR_IGNORE_QTREES environment variable.

Setting ONStor Ignore Tree QuotasThe NAS Gateway’s decision to restore or disregard the tree quota information from tape is based on an ONStor-specific environment variable that can be configured by a data management application (DMA) that moves data in an NDMP operation. This environment variable is called ONSTOR_INGORE_QTREES.

With this environment variable, you can control how specific tree quotas are restored. Default tree quotas can also be restored but only in the case of a full restore of / (root directory) to / (root directory). Default quotas are not restored in the following cases:

• Restoring a partial backup

• Restoring / to a nonroot directory

• Selectively restoring files directories

Table 10-5: ONSTOR_IGNORE_USR_GRP_QUOTAS

Variable Options Description

ONSTOR_INGORE_USR_GRP_QUOTAS

y or nDefault: n

Used in restore session. Controls restoration of user and group quotas. If set to Yes, this variable causes only tree (hierarchical) quota records to be restored. User or group group quotas are ignored. Restore can implicitly set this variable when restoring dump formats that do not support quotas. If set to No, this variable allows user and group quotas to be restored.


10-8

The following list shows special cases for restoring quota tree root directories, and the resulting action in each case:

• If the tree quota’s root directory does not exist on the destination volume, tree quota information is restored when the tree quota’s root directory is created.

• If the tree quota’s root directory exists on a destination volume as an empty directory, the tree quota information is restored from tape to the destination directory regardless of whether the target directory is a tree quota root directory or not.

• If the tree quota’s root directory exists on the destination volume as a directory with content, tree quota information is restored from tape and the directory is made a tree quota root. In all other situations, the tree quota warning and limit values are not restored. A message is transmitted to the DMA to indicate that the tree quota information was not restored. Any files or directories on the directory are restored.

Table 10-6 describes the ONSTOR_IGNORE_QTREES environment variable.

File System Quotas and MirrorsIn a typical configuration, quota configuration information is mirrored from the source volume to the target volume. However, because the target volume is read-only, data operations that require disk block allocations in the live file system are not mirrored to the target. Therefore, quotas are not be enforced or tracked on the target.

Table 10-6: ONSTOR_IGNORE_QTREES


ONSTOR_IGNORE_QTREES

y or nDefault: N

Controls restoration of tree (hierarchical) quotas. If this variable is set to Yes, then no tree quota information from tape will be restored. If it is set to No, then the tree quota information will be restored. Restoration of quota tree information involves restoring only the default and limit values for tree. Usage is not restored.


10-9

Because quota information is present on both the source and target volumes, if the target volume is promoted, it already owns a copy of the quota conditions that were active the last time the mirror occurred.

For more information about ONStor Data Mirror, see “Working with ONStor Data Mirror” on page 13-1.

File System Quotas and SnapshotsA snapshot revert can affect the NAS Gateway’s quota configuration. Performing a snapshot revert to recreate data from snapshots affects all types of quota—user, group, and tree. If you perform a snapshot revert, and the snapshot has different quota conditions, the conditions from the snapshot are put into effect.

Using snapshots to rebuild part or all of your file system can change configured quota conditions if the quota conditions on the snapshot are different than the quota conditions in the file system.

For more information about snapshots, see “Managing Snapshots” on page 9-1.

Configuring Default QuotasQuotas are assigned to a volume, so you need to be in the context of the virtual server that owns the volume on which to configure the quotas to be able to define the quotas. The virtual server must be in enabled state, and the volume must be online and in read-write mode.

Multiple tree quotas can be assigned to a single directory in the directory path, but only if the directory is part of a nested tree quota. Otherwise, the directory can be part of only one tree quota.

To Configure Default User Quotas

• Run the following command from the virtual server context:filesystem quota user config VOLNAME [-e {enforce|trackonly}] [-l LIMIT] [-L {yes|no}][-w WARNING] [-W {yes|no}] [-d]


10-10

To Configure Default Group Quotas

• Run the following command from the virtual server context:filesystem quota group config VOLNAME [-e {enforce|trackonly}] [-l LIMIT] [-L {yes]|no}][-w WARNING] [-W {yes|no}]

To Configure Default Tree Quotas

• Run the following command from the virtual server context:filesystem quota tree config VOLNAME [-e {enforce|trackonly}] [-l LIMIT] [-L {yes|no]}[-w WARNING] [-W {yes|no}]


VOLNAME Specifies the name of the volume where the quota will be configured.

-e enforce|trackonly

An optional argument that causes the NAS Gateway to track and enforce usage on the volume, or to only track usage on the volume.• -e enforce tracks and enforces usage on the volume. With this

argument, allocation is prevented if a usage threshold is met or exceeded. trackonly is the default.

• -e trackonly tracks usage, but allocation can continue even if a usage threshold is exceeded.

-l LIMIT An optional argument that specifies the absolute limit (in MiBs) for the quota. A MiB is 1048576 bytes. You can set an infinite limit by entering the keyword -l followed by a blank space then the word “infinite.” By default, the limit is “infinite.”• This argument interacts with the -e enforce argument to

indicate the threshold at which quota enforcement occurs. If this threshold is exceeded, then an allocation fails.

• This argument also interacts with the -L yes argument to indicate the threshold at which usage events are recorded when the log limit has been exceeded.


10-11

-L yes|no An optional argument that specifies that usage events should be logged for events that exceed the value specified for the -l LIMIT argument. • If the -L yes argument is specified, and the value specified for -

l MiB is exceeded, the event is written to the quota log the first time that usage exceeds the limit.

• If the -L no argument is specified, usage events are not logged if they exceed the value specified for the -l MiB argument. The default is -L no.

Note - Events are logged once per day regardless of how many times the log limit has been exceeded in a 24-hour period. This argument allows the admin to know that usage is getting high before the hard limit is reached and user requests might fail. If you do not specify this argument, then the default is -L no, and not logging occurs.

-w WARNING An optional argument that specifies the soft limit (in MiBs) for the quota. To specify this argument, enter the keyword -w and the value. You can set an infinite limit by entering the keyword -w followed by a blank space then the word “infinite.” This argument works with the -W yes argument. If the user or group exceeds the -w WARNING usage limit, an event is written to the quota log if the -W yes argument is configured. If the log limit has been exceeded, the event is written to the log the first time that usage exceeds the limit.

Note - Events are logged once per day regardless of how many times the log limit has been exceeded in a 24-hour period. If you specify no limit, the default is “infinite.”



10-12

Setting Specific QuotasYou can set specific quotas for user, group and tree quotas. If a default quota and a specific quota are configured on the same volume, the specific quota is applied.

Specific quotas inherit the following quota parameters from the default quota configured on a volume:

• Type (either enforce or track-only)

• Log warnings, or do not log warnings

• Log when limits are exceeded, or do not log when limits are exceeded

Specific Tree QuotasSpecific tree quotas support tracking or enforcing usage conditions on a specific part of the directory structure (for example, a directory and its children). When you configure a tree quota, its conditions are inherited by child directories. If a quota

-W yes|no An optional argument that specifies that usage events should be logged if the soft limit is exceeded. This argument governs whether an event is written to the quota log when usage exceeds the value specified in -w WARNING: • If you specify -W yes, logging occurs when the warning limit

threshold is met or exceeded. If the -W yes argument is configured, you can disable logging by using the -W no argument.

• If you specify -W no, logging does not occur if the warning limit threshold is met or exceeded. The default is -W no.

-d Specify this option to generate a default configuration of the quota. The default configuration is as follows:Enabled: yesEnforcement: enforcedLimit: infiniteLog Limit: yesWarn: infiniteLog Warn: yes



10-13

definition is inherited by the children directories, the quota is applied to all children in the directory tree. If the specific tree quota is nested, usage of a directory is recursively charged up the tree to all quota tree roots until the closest simple quota is encountered (or the root directory), whichever is first. If a directory is not a quota tree directory, it does not get charged for usage.

The directory you specify must always be in relation to the root of the volume, so you need to include the root slash ( / ) when you specify the directory path. You can configure specific tree quotas as either simple or nested, which changes how the disk allocation and usage is charged.

For specific tree quotas, you can specify the directory paths in either Windows or UNIX formats. Because the NAS Gateway is multiprotocol, it reads the path correctly and applies the quota. The directory path where the quota is being applied must already exist.

Specific Tree Quotas RemovalThe filesystem quota tree remove command removes a directory which is the root of tree quota. All the directories and files under the quota tree will be removed recursively.

To Remove Specific Tree Quotas

• Run the following command:filesystem quota tree remove <VOL> <PATH>

This command does not wait for the actual file removals, but all of them will be taken out of the namespace and no further access to them allowed. If the path is not a directory or quota tree root, this operation will fail.

Specific User and Group QuotasSpecific user or group quotas enable you to set specific usage conditions for individual users or groups that access the volume. These usage conditions for specific user or group quotas are applied along with the default user or group quotas on the volume.

When multiple specific quotas are configured for a user or group, the NAS Gateway analyzes all of them, and applies the strictest to offer the most control over usage. Specific user or group quotas are optional.


10-14

When setting specific quota, you can specify the name of the user or group to which the quota applies. You can specify a user ID (UID) for a user quota, a group ID (GID) for group quota, an NIS user or group name, or a Windows user or group name. The following is the correct syntax for specifying names and IDs with specific quotas:

• 99@onstor (NIS or LDAP UID format)

• user@onstor (NIS or LDAP user name format)

• onstor\user (Windows user name format)

User and group names must be valid and known to the Windows or NIS domain controllers. Because the NAS Gateway is multiprotocol, CIFS and NFS users and groups can be seamlessly mapped between domain types through ID Mapping. For more information about ID Mapping, see “Managing ID Mappings” on page 7-68.

Note - Problems with accessing the Windows or NIS domains can prevent the NAS Gateway from displaying per-user quota information.

To Set Specific User Quotas

• Run the following command from the virtual server context: filesystem quota user set VOLNAME USERNAME [-l LIMIT] [-w WARNING] [-d]

To Set Specific Group Quotas

• Run the following command from the virtual server context: filesystem quota group set VOLNAME GROUPNAME [-l LIMIT] [-w WARNING [-d]


10-15

To Set Specific Tree Quotas

• Run the following command:filesystem quota tree set VOLNAME PATHNAME [-l LIMIT] [-w WARNING] [-n {yes|no}] [-d]


VOLNAME Specifies the volume where the quota is configured.

USERNAME Specifies the name of the user to which you are assigning the quota usage conditions. User names can be either Windows, LDAP, or NIS formats, and they must match the user name that is configured on the NIS or LDAP server or Windows domain controller.

Note - You cannot assign specific user quotas to the root user, for example UID 0.

GROUPNAME Specifies the name of the group to which you are assigning the quota. Group names can be either Windows, NIS, LDAP formats, and they must match the group name that is configured on the NIS or LDAP server or Windows domain controller.

PATHNAME Specifies the first object in the directory path where the tree quota is configured. Specify the directory path in relation to the root of the volume, for example /dir1. Children of this object inherit the quota conditions of the parent.


10-16

-l LIMIT An optional argument that specifies the absolute limit (in MiBs) for the specific quota. The default is whatever LIMIT value is configured for the default quota, or “infinite” if no value is specified for default and specific quotas. You can set an infinite limit by entering the argument -l followed by a blank space then the word “infinite.” • This argument interacts with the enforce argument to indicate the

threshold at which quota enforcement occurs. If this threshold is exceeded, then an allocation fails.

• This argument also interacts with the -L yes argument to indicate a threshold when usage events are recorded if the log limit has been exceeded.

Note - It is possible to configure a 0 MiB quota. Although unusual, it is a valid configuration in some cases.

-w WARNING An optional argument that specifies the soft limit (in MiBs) for the specific quota. To specify this argument, enter the argument -w followed by a blank space then the value. You can set an infinite limit by entering the argument -w followed by a blank space then the word “infinite.” If you specify no warn MiB value, the default is “infinite.” This argument works with the -L yes argument to specify when an event is written to the quota log.

-d An optional argument that causes the specific quota to use the values from the default quota on the volume. This option is useful for resetting a specific quota’s usage conditions to the same usage conditions that are assigned to the default quota quota. This option cannot be combined with the -l LIMIT or -w WARNING arguments.

Note - The -d argument does not set all arguments in the filesystem quota user config command to their default values. It is used to set a specific quota to the default quota’s values.



10-17

Enabling or Disabling QuotasYou can simultaneously enable or disable all quotas of any or all types on a volume. For example, you could enable all user quotas on vol1 at the same time. Or, by using a comma-separated list, you could enable all user and group quotas on vol1 at the same time, or all user, group, and tree quotas on vol1 at the same time.

Note - Power cycles and reboots do not change quota state. The quota will be in the same operational state that it was in before the power cycle or reboot occurred.

To Enable or Disable Quotas That Contains the Volume Where the Quota Is Configured

• Run the following command from the virtual server context:filesystem quota enable|disable VOLNAME{user,group,tree}

Displaying Quotas When you display quotas, the information shown varies depending on the following conditions:

• If the quota feature is enabled and the quota configuration contains no specific user quotas, the output of this command shows the default quotas assigned to everyone on the volume.

• If quotas are enabled and the quota configuration contains one or more specific user, group, or tree quotas, the output of this command shows the specific quota


VOLNAME Specifies the name of the volume where the quota is configured.

user,group,tree Specifies the type of quota you are enabling or disabling. You can specify one or more quotas. If you specify multiple quotas, separate each quota type with a comma.


10-18

configuration for the users, groups, or directory trees. If no limit or warning has been configured, the output of this command shows infinite warning and limit levels.

• If the quota feature is disabled, the output shows “unknown (disabled)” to indicate that usage cannot currently be measured because quota is disabled.

• If the quota rebuild phase is in progress, the output of this command shows “unknown (rebuilding)” to indicate that usage cannot currently be measured because quota is rebuilding.

Note - In cases where a CIFS and an NFS identity exist, the NAS Gateway gives preference to the CIFS identity and the NFS user’s usage is charged to the CIFS identity.

To Display User Quota Information

• Run the following command from the virtual server context:filesystem quota user show VOLNAME [USERNAME|-all] [-P PAGENUMBER [-S PAGESIZE]]

To Display Group Quota Information

• Run the following command from the virtual server context:filesystem quota group show VOLNAME [GROUPNAME|-all] [-P PAGENUMBER [-S PAGESIZE]]

To Display Tree Quota Information

• Run the following command:filesystem quota tree show VOLNAME [PATHNAME|-all][-P PAGENUMBER [-S PAGESIZE]]


10-19

Note - A quota tree always owns its root directory, which is 8K in size, and usage is always rounded up. Therefore, if you have configured a tree quota that has no data contents, the output of filesystem quota tree show command can show 1 MiB of usage because of the root directory.

Configuring QuotasThis section documents the step-by-step procedures for configuring user, group, and tree quotas on the NAS Gateway.

Before configuring quotas, decide the following:


VOLNAME Specifies the volume where the quota is configured.

USERNAME| An optional argument for looking up quotas based on user name.To lookup quotas by user name.The names need to match the user name that is configured on the NIS or Windows domain controller.

GROUPNAME

An optional argument that specifies the name of the group quota to be displayed. The names need to match the group names that are configured on the NIS or Windows domain controller.

PATHNAME An optional argument that specifies the path for which you are displaying the tree quota. Paths can be specified in either Windows or NIS format and can have a maximum length of 1024 characters.

Note - Note - You use either \ or / in this command. The NAS Gateway always represents the directory structure as \.

-all An optional argument for looking up all user or group quotas.To lookup all user or group quotas. If the quotas are enabled when you run this command, the NAS Gateway displays the quota records and the usage information. If you do not specify the -all keyword, only the default quotas are displayed.


10-20

• Whether are configuring default or specific quotas

• Whether you are configuring track-only or enforce quotas

To Configure Quotas

Step 1: Make sure that you have a virtual server configured and enabled. For more information about configuring virtual servers, see “Working with Virtual Servers” on page 3-1.

Step 2: From the virtual servers’ context, verify that the volume where you want to configure quotas is enabled and online, by running the volume show command.

Step 3: To configure default user, group, or tree quotas in track-only or track enforce mode, run the following commands: filesystem quota user config

filesystem quota group config

filesystem quota tree config

Example for a track-only user quota: filesystem quota user config vol1 -e trackonly -l 88 -L yes -w 77 -W yes

Example for a track and enforce group quota:filesystem quota group config vol1 -e enforce -l 88-L yes -w 77 -W yes

Example for a track-only tree quota: filesystem quota tree config vol1 -e trackonly -l 88 -L yes -w 77 -W yes

Step 4: To configure specific user, group, or tree quotas, run the following commands:filesystem quota user set

filesystem quota group set

filesystem quota tree set

Example for a specific user quota:


10-21

filesystem quota user set vol1 user1@onstor -l 150 w 140 -W yes

Example for a specific group quota:filesystem quota group set vol1 pubs@onstor -l 150 -w 140 -L yes -W yes

Example for a simple tree quota:filesystem quota tree set vol1 /dir1/dir2 -l 88-w 77

To create a nested tree quota, run the following command: filesystem quota tree set vol1 /dir1/dir2 -l 88-w 77 -n yes

Step 5: Enable the quota by running the following command:filesystem quota enable|disable VOLNAME{user,group,tree}

Example for enabling user quota:filesystem quota enable vol1 user

Example for enabling group quota:filesystem quota enable vol1 group

Example for enabling tree quota:filesystem quota enable vol1 tree

Note - Each time you run the filesystem quota enable command, the NAS Gateway rebuilds the user quota definition on the volume. To save time configure all user quotas, and run the filesystem quota enable command once to enable all user quotas as a batch instead of enabling them individually.

Enabling configured quotas can affect performance. If you choose not to configure quotas, no group disk space usage limits are tracked or enforced.


10-22

Updating ID Mapping RulesThe NAS Gateway supports multiple protocols and therefore can serve NFS and CIFS clients. The NAS Gateway uses ID maps to translate user and group names between CIFS and NFS domains. For more information about ID Mapping, see “Managing ID Mappings” on page 7-68.

You can alert the NAS Gateway to changes in the ID map. The NAS Gateway then reconstructs the ID map with new quota-related information, and relevant entries are updated to use the most recent version of the ID map.

To Alert the NAS Gateway to Changes in the ID Map

• Run the following command: idmap notify change {user,group}

user,group specifies the type of quota you are enabling on the volume. You can specify one or more quota types. If you specify multiple quota types, separate each quota type with a comma.

Note - When you run the idmap notify change command, the NAS Gateway preforms a quota rebuild.


10-23

Working With the Quota LogThe NAS Gateway automatically tracks the use of storage space and its configuration and writes usage events to the quota log. The quota log stores this information for later retrieval and analysis.

Quota log messages contain information about specific usage events that meet or exceed a warning or limit threshold. The quota log receives messages when a quota is configured with the following parameters:

• A noninfinite limit or warning value

• -W (log warning) or -L (log limit), or both

Events are logged once per day regardless of how many times a warning or limit threshold is exceeded in a 24-hour period. The log shows how many times the particular message has been received in the 24-hour period. Quota activity can be posted to the NAS Gateway’s quota log or sent to an external syslog host.

Displaying the Quota LogYou can display locally stored log messages by running the filesystem quota log show command. Quota log messages contain information about specific usage events that meet or exceed a warning or limit threshold.

To View the Quota Log

• Run the following command from the NAS Gateway context:filesystem quota log show [NUMLINES]

NUMLINES is an optional argument that specifies the number of lines you want to display. The number of lines you specify are displayed in most-recent to least-recent order. NUMLINES can be a 32-bit number. By default, the entire quota log is displayed.

Clearing the Quota LogClearing the quota log is immediate and removes all entries from the quota log. If the quota is enabled after clearing the log, new entries are posted to the quota log whenever a usage event causes a message to be posted.


10-24

To Clear the Quota Log

• Run the following command from the NAS Gateway context:filesystem quota log clear

Specifying the Syslogd Host for Sending Quota Log MessagesYou can forward quota log messages to syslog daemons running on a specified host.

• If the host address is set to 0.0.0.0, all quota log messages are forwarded to the local syslogd daemon.

• If the host address is set to other than 0.0.0.0, all quota log messages are forwarded to the specified host using the currently configured facility code.

If you are sending the quota log output to a remote syslog host, make sure that the remote syslog host is configured to receive syslog messages from other hosts because some implementations, by default, are configured not to receive syslog messages forwarded by other hosts. Remote logging is disabled by default, so all messages are sent to the local host.

To Specify the Syslogd Host for Sending Quota Log Messages

• Run the following command: filesystem quota log host IPADDR

IPADDR specifies the IP address of a remote host that runs syslogd and can receive quota log messages from this NAS Gateway.

Specifying the Facility Code To Be Used by the Quota LogThe quota log facility interfaces with the standard syslogd capability to provide logging of system information at the desired level of priority. Using this facility, system messages can be locally saved, forwarded to a remote host, or displayed on the system console. Quota log messages use the same user-level facility codes as the standard UNIX syslog program. The facility codes are local0, local1, local2, local3, local4, local5, local6, and local7. These facility levels can be used to filter messages


10-25

from different NAS Gateways at a common syslog host. Table 10-7 lists the default facility values for the different log files that can be exported off of the NAS Gateway.

To Specify the Facility Code To Be Used By the Quota Log

• Run the following command: filesystem quota log facility {local0|local1|local2|local3|local4|local5|local6|local7}

local0|local1|local2|local3|local4|local5|local6|

local7 is a list of the facility codes that you can use for quota log messages. By default, the local facility level is local6. Make sure you do not use the same facility level as another log, or it can be difficult to determine which log is being reported.

Displaying the Quota Log ConfigurationYou can display the current quota log configuration to obtain the following information about the quota log:

• The log facility used for the quota log

• The remote host used for the quota log

To View the Current Quota Log Configuration

• Run the following command:filesystem quota log show config

Table 10-7: Log Files and their Default Facility Levels

Log File Default Facility Level

Elog local0

Quota log local6

Virus scan log local7


10-26


Chapter 11: Monitoring the NAS Gateway


• “Monitoring with the NAS Gateway” on page 11-2

• “Supported RFCs and MIBs” on page 11-3

• “Managing SNMP” on page 11-4

• “Adding an SNMP Community” on page 11-4

• “Deleting an SNMP Community” on page 11-4

• “Adding an SNMP Trap” on page 11-5

• “Deleting an SNMP Trap” on page 11-7

• “Adding a Trap Specification List” on page 11-7

• “Deleting an SNMP Trap Specification List” on page 11-8

• “Showing an SNMP Configuration” on page 11-8

• “Deleting an SNMP Configuration” on page 11-9

• “Setting the System Contact and System Location” on page 11-9


11-2

Monitoring with the NAS GatewayThe ONStor NAS Gateway supports the simple network management protocol (SNMP), version 2. The ONStor implementation of SNMP operates at the cluster or the virtual server level. Therefore, SNMP functions are applied to either the cluster or virtual server.

Through a configured community string, management stations that communicate with the cluster or virtual server are allowed to access the virtual server if packets transmitted from the network device to the virtual server contain the community string. The virtual server supports both read-only and read-write community strings.

However, you can add, change, or delete communities on each NAS Gateway through the snmp commands documented later in this document. SNMP configuration changes made from one NAS Gateway are now applied to all NAS Gateways in the cluster. The maximum of 10 read-only and 10 read-write community strings applies to the cluster entity and each individual virtual server.

You can configure one or more SNMP agents. You can set the community string so that it can be polled by third-party management software. The NAS Gateway supports the following statistics information:

• 10/100 Ethernet interface statistics

• Gigabit Ethernet interface statistics

• Volume Manager statistics

• Fibre Channel (FC) port statistics

• NFS protocol statistics

• CIFS protocol statistics

• Cluster and Filer Group statistics

• Virtual Server statistics

• Environmental statistics

• Hardware specific statistics

• Storage statistics


11-3

Supported RFCs and MIBsThe NAS Gateway supports some standard MIBs (Management Information Base). In this version of the software, the NAS Gateway supports RFC 1213, also known as MIB-II for its internal SNMP agent.

The NAS Gateway also supports the following proprietary MIBs:

• ONStor-NASGW-MIB

• ONStor-SYSSTAT-MIB

• ONStor-EVM-MIB

• ONStor-CIFS-MIB

• ONStor-NFS-MIB


11-4

Managing SNMPThe NAS Gateway uses SNMP commands to configure the SNMP agent on the NAS Gateway.

Adding an SNMP CommunityWhen you add an SNMP community, the hosts that are configured with that string can view information on the NAS Gateway. When the string is configured, it is added to the NAS Gateway’s SNMP agent.

Note - The community string that you configure on the NAS Gateway’s SNMP agent must also be configured on the SNMP management console. Otherwise, the two devices will not be able to communicate because they are in different community strings.

To Add a Community to the NAS Gateway

• Run the following command: snmp add cluster|VIRTUALSERVER community COMMUNITY [-w]

COMMUNITY is the name of the community string that you are configuring on the NAS Gateway. Enter an alphanumeric character string of up to 31 printable non-white space characters.

-w option is specified to indicate that it is read-write. if you do not specify this option, it will be presumed to be read-only. A maximum of 10 read-only and 10 read-write community strings are supported.

Deleting an SNMP CommunityWhen you delete a community string from the SNMP agent configuration file, it can no longer be used to contact SNMP agent on the filer.


11-5

To Delete a Community String

• Run the following command: snmp delete cluster|VIRTUALSERVER COMMUNITY

COMMUNITY is the community that you are deleting from the NAS Gateway. Enter the name of the community string that you want to delete.

Adding an SNMP Trap You can add an SNMP trap to include management of trap-related configuration parameters. When a trap is not specified, the type of traps that may be sent to the trap host recipient is limited to generic traps and elog traps with severity equal to or greater than the severity threshold level.

To Add an SNMP Trap Host

• Run the following command: snmp add cluster|VIRTUALSERVER trap HOST[:PORT] [-s SEVERITY] [-c COMMUNITY] [-t TRAPSPEC]

HOST is the trap recipient name that can be up to 31 characters in size, printable non-white space or IP address.

PORT is the trap recipient UDP port. The default is162. You can enter any non-zero 16-bit port number, 1 to 0xFFFF.

SEVERITY is the elog event severity threshold level. The default is warning.

COMMUNITY is the trap community string. The default is public.

TRAPSPEC specifies the enterprise trap specification list name.

The Specific Event traps are uniquely defined based on the event type. These specific Event traps are listed below with accompanying object parameters:

Trap Name Trap Object Paramenters Trap Group/Number


11-6

Cold Start gen/1

Power Supply Ok (number=1,2) env/2

Power Supply Error (number=1,2) env/3

Elog String(Format: slot:cpu:appName:severity:eventDesc)

elog/1

Fan Ok (number=1,2 description) env/4

Fan Error (number=1,2 description) env/5

Temperature Ok (tempValue, desc) - Temp reduced below max threshold

env/6

Temperature Error (tempValue, desc) - Temp exceeds max threshold

env/7

Node Up (nodeName) node/8

Node Down (nodeName) node/9

Port Up (portName=sp2.0-sp2.1, fp1.0-fp.1.3)

port/10

Port Down (portName=sp2.0-sp2.1, fp1.0-fp.1.3)

port/11

vsvr IP Interface Added (vsvrName) vsvr/12

vsvr IP Interface Removed (vsvrName) vsvr/13

Virtual Server Fail Over (vsvrName) vsvr/14

Virtual Server Disabled (vsvrName) vsvr/15

Virtual Server Up (vsvrName) vsvr/16

Virtual Server Down (vsvrName) vsvr/17

Volume Created (volName) vol/18

Volume Deleted (volName) vol/19

Volume Grow (volName) vol/20


11-7

Note - A maximum of 10 trap recipients and 10 trap specs are supported.

Deleting an SNMP TrapDeletes a trap host recipient from the SNMP configuration of the cluster entity or a virtual server. Once a trap host is deleted, the configuration change becomes effective immediately.

To Delete an SNMP Trap

• Run the following command: snmp delete cluster|VIRTUALSERVER trap HOST[:PORT]

HOST is the IP address or trap recipient name that can be up to 31 characters in size, printable non-white space.

PORT is the trap recipient UDP port. The default is 162. You can enter any non-zero 16-bit port number, 1 to 0xFFFF.

Adding a Trap Specification ListAdds a trap specification to the SNMP configuration of the cluster entity or a virtual server. The trap specification defines specific traps of interest by type that may be sent to a trap recipient. It consists of a list of trap numbers or range of trap numbers. The traps may also be referenced by keywords that map to a group of traps related by

Volume SoftQuota (volName) vol/21

Volume Full (volName) vol/22

Volume Modify (volName) vol/23

Volume Broken (volName) vol/24

Volume Takeover (volName) vol/27

Volume Online (volName) vol/29

Volume Offline (volName) vol/30


11-8

function. When a trap spec by the same name is already defined, the new trap spec entries are appended to the existing list.

To Add a Trap Specification List

• Run the following command: snmp add cluster|VIRTUALSERVER trapspec TRAPSPEC TSLIST


TSLIST is the trap specification list. It is specified in a comma-delimited list of trap types where each trap list entry is a keyword, trap group, or trap number(s) as follows:

• gen includes generic traps (Cold-Start, Warm-Start, AuthenErr).

• elog includes elog event generated enterprise traps with severity at or above severity threshold.

Deleting an SNMP Trap Specification ListDeletes a trap specification or specified entries within a trap specification from the SNMP configuration for the cluster or a specific virtual server.

To Delete an SNMP Trap Specification List

• Run the following command:snmp delete cluster|VIRTUALSERVER trapspec TRAPSPEC [TSLIST]


TSLIST is the trap specification list. It is specified in a comma-delimited list of trap types where each trap list entry is a keyword, trap group, or trap number(s).

Showing an SNMP ConfigurationThe snmp show command option is used to distinguish between read-only and read-write community strings.


11-9

To Display the SNMP Configuration

• Run the following command: snmp show cluster|VIRTUALSERVER

Deleting an SNMP ConfigurationThe snmp command includes a delete all option to clear out the entire SNMP configuration of a virtual server or for the cluster entity.

To Delete the SNMP Configuration

• Run the following command:snmp delete cluster|VIRTUALSERVER all

Setting the System Contact and System LocationThe snmp modify command can be used to set syscontact and syslocation values:

To Set the SNMP System Contact and System Location

• Run the following command:snmp modify cluster|VIRTUALSERVER syscontact|syslocation OBJVALUE

OBJVALUE is a string of 1 to 63 characters.


11-10


Chapter 12: Autosupport and Event Monitoring


• “Understanding Autosupport” on page 12-2

• “Configuring Autosupport” on page 12-4

• “Event Monitoring and Reporting Services” on page 12-10


12-2

Understanding AutosupportThe ONStor NAS Gateway’s autosupport feature enables real time e-mail alerts for system events. The autosupport feature tracks a specific set of events that the NAS Gateway reports to the administrator. The tracked events can be:

• System-level, such as node resets.

• Element-level, such as card resets.

• Component-level, such as CPU resets.

For a full list of the events that the NAS Gateway tracks through autosupport, see “Displaying and Clearing Autosupport Statistics” on page 12-9.

Use the autosupport feature to specify e-mail aliases for receiving system events. When you specify the e-mail aliases, the NAS Gateway can notify an administrator through e-mail when system events occur that might present a problem.

For autosupport to function, the management virtual server must have the DNS resolver configured. For more information about the DNS resolver, see “Configuring DNS Name Resolution for a Virtual Server” on page 3-46.

Understanding Autosupport and Event LogsEvent logs (elog) and autosupport are similar but not the same. These features complement each other. Events might be written to the log and also generate autosupport e-mails, but not everything that is logged will also generate e-mails. Table 12-8 lists the differences between the Elog and autosupport features.

Table 12-8: Differences Between Elog and Autosupport

Elog Autosupport

Forwards elog output to an administrator-configured external syslog daemon.

Forwards system events to one or more e-mail addresses.

Posts an event to an Elog file on the SSC, or displays the Elog message output on the management console.

Forwards an e-mail of autosupport events and a snapshot of the system configuration to the administrator in real time.


12-3

For more information about the NAS Gateway’s Elog facility, see “Setting Elog Message Levels” on page 16-10.

Understanding Autosupport Message TypesAutosupport tracks system events in any of the following ways:

• A notification, which is a detailed message that includes a summary of the NAS Gateway’s configuration at the time of the event as well as the summary of the system event. For details see “Creating E-mails for Autosupport Notifications” on page 12-4.

• A note, which is a brief message that includes only a summary of the system event. Autosupport notes do not contain the NAS Gateway’s configuration at the time the event occurred. For details see “Creating E-mails for Autosupport Notes” on page 12-5.

Summarizes system events that are equal to or more severe than an administrator configured severity level.

Can summarize the system configuration at the time of the system event in addition to the system event.

Table 12-8: Differences Between Elog and Autosupport (Continued)

Elog Autosupport


12-4

Configuring AutosupportThe following sections document how to configure autosupport.

Creating E-mails for Autosupport NotificationsThis command lets you specify an email address to which a detailed autosupport note will be sent either on demand or upon the occurrence of specific events.

To Create E-mail Autosupport Notifications

• Run the following command:autosupport email to EMAIL

EMAIL is the address of an administrator or ONStor support contact that is managing the NAS Gateway. Enter a valid e-mail address of up to 256 characters, including the e-mail suffix. The NAS Gateway supports all common domain suffixes, such as .com, .org, .gov, and .edu.

Note - The e-mail address does not have to exist prior to entering it as part of the autosupport feature on the NAS Gateway.

You can send notifications and notes sent to the same or a different e-mail address.

Configuring the Address From Which Autosupport E-mail Is SentYou can now configure the address from which you are sending autosupport e-mail.

To Configure the Autosupport From E-mail Address

• Run the following command: autosupport email from EMAIL

EMAIL is the e-mail address from which all autosupport e-mail is being sent on generation of important events and on demand. You


12-5

can enter any e-mail address.

Note - You can specify only one e-mail ID in the EMAIL field.

If you don’t configure the e-mail address, it defaults to the NAS Gateway node name.

Creating E-mails for Autosupport NotesThis command lets you specify an email address to which a brief autosupport note will be sent either on demand or upon occurrence of specific events.

To Designate the E-mail Recipient for Autosupport Notes

• Run the following command: autosupport email noteto EMAIL

EMAIL is the address of an administrator or ONStor support contact that is managing the NAS Gateway. Enter a valid e-mail address of up to 256 characters, including the e-mail suffix. The NAS Gateway supports all common domain suffixes, such as .com, .org, .gov, and .edu.

Note - The e-mail address does not have to exist prior to entering it as part of the autosupport feature on the NAS Gateway.

You can send notifications and notes sent to the same or a different e-mail address.

Specifying the SMTP Server to Receive Autosupport E-mailsYou can now configure the simple mail transfer protocol (SMTP) server to which to direct autosupport e-mails by specifying the IP address of the SMTP server.


12-6

To Configure the SMTP Server for Autosupport Email

• Run the following command:autosupport email server SERVER

SERVER is the IP address of the SMTP server to which to route autosupport e-mail. To specify the default IP address use 0.0.0.0.

The default mail server is automatically determined using DNS MX records, so run this command only when you want to override the default SMTP server.

Setting an Autosupport ScheduleYou can schedule autosupport reports to occur at regular intervals. By default all parameters except minutes in the autosupport schedule are configured with an asterisk (*) which indicates that the autosupport feature report can occur at all times in the range.

Note - By default, the autosupport schedule’s minutes parameter is set to 0 to disable autosupport reports every minute. The smallest default autosupport schedule is hourly.


12-7

To Configure an Autosupport Schedule

• Run the following command: autosupport schedule [-m MINUTE] [-h HOUR] [-d DATE] [-M MONTH] [-D DAY]


-m MINUTE Specifies the minutes of the hour at which to generate the system report. Use a numeric value between 0 and 59. For example, if you set 30, the system report will be generated on the half hour of whichever hour you specify. You can enter multiple values for this argument by specifying a comma-separated list of values. By default, this parameters is set to zero (0), which disables the scheduling of autosupport messages every minute.

-h HOUR Specifies the hour at which to generate the system report. Use a numeric value between 0 and 23. 0 is midnight, and 23 is 11 pm. You can use the -m MINUTE argument to specify the generation of the system report at a time other than the top of the hour. You can enter multiple values for this argument by specifying a comma-separated list of values.

-d DATE Specifies the date on which you want the system report generated. Enter one of the following:• The numerical date of a particular day in the month. For

example, generate a system report on the first day of each month, enter 1. Also, you can enter a comma-separated list of dates.

• A specific date. For example, to generate a system report on the September 27, 2003, specify the date as 092703.

Note - Do not separate the numbers with any special characters.


12-8

Generating Autosupport ReportsAutosupport reports contain the same content as autosupport notifications, but the information can be generated at any time instead of scheduled intervals. The autosupport report is forwarded to the recipients in the noteto and notification email alias fields.

To Generate an Autosupport Report

• Run the following command: autosupport generate report

Enabling or Disabling the Autosupport FeatureIf you disable autosupport, the NAS Gateway retains all the configured autosupport parameters until you re-enable the feature. Autosupport is disabled by default.

To Set the Operational State of the Autosupport Feature

• Run the following command: autosupport state {disable|enable}

disable|enable specifies the state of autosupport that you are setting.

-M MONTH Specifies the month of the year at which to generate a system report. Use a numeric value between 1 and 12. For example, if you set 6, the system report is generated in the month of June. You can enter multiple values for this argument by specifying a comma-separated list of values.

-D DAY Specifies the day of the week at which to generate a system report. Use a numeric value between 1 and 7. 1 is Sunday, and 7 is Saturday. You can enter multiple values for this argument by specifying a comma-separated list of values.



12-9

Displaying the Autosupport ConfigurationThe NAS Gateway stores the configured autosupport parameters in memory as the Autosupport Configuration List. You can view the autosupport configuration on the local node only.

To Display the Autosupport Configuration

• Run the following command: autosupport show config

Displaying and Clearing Autosupport StatisticsThe NAS Gateway tracks performance and operation statistics for system events. The following event are listed in the Autosupport Statistics Summary:

• Node failures or resets

• Card failures or resets

• CPU failures or resets

• Volume failures or volume space violations

• Core dump events

The statistics are gathered in real time whenever the system event is forwarded to the administrator in a notification or a note. The statistics are tracked in runtime, so if the NAS Gateway is reset, the statistics reset to zero and begin incrementing again whenever a system event occurs.

To Display the Autosupport Statistics Summary

• Run the following command: autosupport show statistics

To Clear the Autosupport Statistics Summary

• Run the following command: autosupport clear statistics


12-10

Event Monitoring and Reporting ServicesThe NAS Gateway supports event monitoring and reporting services (EMRS). This feature enables the NAS Gateway to securely transmit event logs (elogs), configuration information, and performance statistics through HTTPS to a secure server on site at ONStor. EMRS is enabled by default.

EMRS uses SSL to transmit NAS Gateway information, including the following:

• System information, such as NTP server information, system date, time, and timezone stamps, system chassis configuration, and software versions

• Cluster and virtual server information, such as cluster configuration, the number and names of virtual servers in the cluster, cluster and virtual server states, and information about each virtual server in the cluster

• File system information, such as data and metadata counters, snapshots, CIFS hash statistics, and NFS hash statistics

• Storage information, such as SCSI level information, Fibre Channel I/O information, tape and RAID devices attached to the NAS Gateway, and storage port state information

• Network information, such as route and interface table information, file processing port state and configuration information, and domain information

Note - No user data is transmitted to ONStor.

EMRS facilitates diagnosing and troubleshooting the NAS Gateway and provides the following benefits:

• Faster resolution of issues

• Automatic transmittal of problems to ONStor

• Facilitated analysis of non-optimal NAS Gateway configurations, which can prevent issues that might arise from a misconfigured NAS Gateway


12-11

• Enhanced communication of performance histories, uptime, and MTBF numbers, which allow ONStor continued improvements in the NAS Gateway products and services

EMRS Upload MethodsEMRS can upload information to the secure ONStor server using any of the methods listed in Table 12-9.

Configuring and Managing EMRSEMRS is an extension of the NAS Gateway’s autosupport feature, and the commands that configure and manage EMRS are in the autosupport command group.

EMRS configuration affects the entire cluster. When you configure the settings for EMRS, the information is written into the cluster database, and other NAS Gateways in that cluster use the same information.

Table 12-9: EMRS Upload Methods

Method Description

Nightly Sends a day’s worth of system configuration information and statistics to the ONStor secure server every night at midnight.

Admin-initiated Sends the output of the system get commands to the ONStor secure server. For details about these commands, see “Managing NAS Gateway System Health” on page 16-19.

Note - Admin-initiated EMRS requires a Customer Support case number. If you don’t have a case number, you need to open a case.

Event-initiated When selected system events occur, the NAS Gateway transmits information about those events to the ONStor secure server. CPU reboot events are not currently a trigger for EMRS to send information. Event-initiated EMRS enables information to be sent to the ONStor secure server asynchronously after CPU events occur. The information is transmitted when a CPU reboots, not when a CPU crashes.


12-12

However, system information is gathered and uploaded on a per-NAS Gateway basis. Therefore, when gathering system information for NAS Gateways in a multinode cluster, you need to run the system get command on each NAS Gateway the cluster.

Prerequisites for EMRSTo support EMRS:

• The network must support HTTPS traffic to the Internet.

• You need to have administrator privileges on the NAS Gateway and in your network.

• Some networks use a proxy to support traffic to the Internet. If the network uses a proxy to route traffic to the Internet, you will need the proxy’s IP address, the port number that supports traffic, and any user name and password to access the proxy.

Enabling or Disabling Proxy Support for Transmitting EMRS InformationBy default, the EMRS information is gathered on a NAS Gateway and transmitted to the secure ONStor server by the NAS Gateway itself. However, the EMRS information can be sent by proxy.

The following information about the proxy device is needed for configuring EMRS:

• The proxy’s IP address

• The port that the proxy will be using to transmit the EMRS information

• The user name and password that are used to authenticate the NAS Gateway with the proxy if the network’s proxy requires a user name and password


12-13

To Set EMRS’s Proxy Parameters

• Run the following command:autosupport emrs proxy enable -i IPADDR -p PORT[-u USER -P PASSWORD]

To Disable Proxy Support for Transmitting EMRS Information

• Run the following command:autosupport emrs proxy disable

Enabling Automatic Transmission of EMRS DataBy default the EMRS feature is enabled. But if this feature is disabled, you can explicitly enable it by running the autosupport emrs send enable command.

To Enable Automatic Transmittal of EMRS Data

• Run the following command: autosupport emrs send enable

Disabling Automatic Transmission of EMRS DataBy default the EMRS feature is enabled. But you can explicitly disable this feature by running the autosupport emrs send disable command. When you disable the EMRS feature, the NAS Gateway stops sending system information through nightly or event-initiated uploads to the ONStor server, and the EMRS configuration is removed from the cluster.


-i IPADDR Specifies the IP address of the proxy.

-p PORT Specifies the proxy port that supports the EMRS information from the NAS Gateway.

-u USER Specifies the user name if the proxy requires one for access.

-P PASSWORD Specifies the password if the proxy requires one for access.


12-14

To Disable the Automatic Transmittal of EMRS Data

• Run the following command: autosupport emrs send disable

Displaying the EMRS ConfigurationYou can display the current settings and operational state of the EMRS feature. If the no proxy server information is specified, the display shows an asterisk (*) for each of the proxy parameters.

To Display the Current Configuration of EMRS Parameters

• Run the following command: autosupport emrs show config

Displaying Information Supported by EMRSYou can display the configuration information and performance statistics that are transmitted automatically through nightly EMRS uploads.

To Display the Configuration Information and Performance Statistics

• Run the following command: system get config -s

The -s option displays the output on the management console.

Note - The system get config -s command does not support displaying information contained in admin-initiated uploads.

Uploading Information Through a Case NumberTo manually transfer system information to the ONStor secure server, run the system get command. With this command, the NAS Gateway transfers configuration information and performance statistics to the secure ONStor server. This method requires a case number, so there must be a case filed with ONStor Customer Support.


12-15

After the information is uploaded to the ONStor secure server, Customer Support can begin analysis of the information.

To Upload System Information Through a Case Number

Step 1: Make sure there is case opened with ONStor Customer Support. The case number must be used in uploading the information.

Step 2: When you receive the case number, make a note of it.

Step 3: Run the system get command for the type of information that you want to upload, and include the case number in the command. For example, to upload the system information for case number 2659, run the command as follows:

• system get all -c 2659 to transmit all logs, statistics, crash information, and configuration information.

• system get config -c 2659 to transmit configuration information.

• system get logs -c 2659 to transmit various log files.

• system get stats -c 2659 to transmit system and volume statistics.

• system get tse -c 2659 to transmit pertinent technical support information.


12-16


Chapter 13: Working with ONStor Data Mirror


• “Managing ONStor Data Mirror” on page 13-2.

• “Configuring Data Mirrors” on page 13-7.


13-2

Managing ONStor Data MirrorThe ONStor NAS Gateway uses the ONStor Data Mirror functionality to support configuration and management of mirrors for data replication. Use data mirroring to replicate a file system from one volume to another one as a read-only mirror copy.

The NAS Gateway supports two types of data mirroring:

• Data mirroring over IP

• Local data mirroring

Data Mirroring Over IPData Mirror over IP mirrors files from a source volume to a target volume using IP. The source and target volumes are volumes in different clusters, and the volumes might be in geographically different locations.

Read and write operations in Data Mirror over IP occur as parallel operations. In Data Mirror over IP, you can run some commands from the virtual server associated with source volume, some commands from the virtual server associated with the target volume, and some commands from the virtual server with either volume as shown in Table 13-10.

Table 13-10: Mirror Commands in Data Mirror Over IP

CommandRun from Virtual Server Associated with Source

Volume

Run from Virtual Server Associated with Target

Volume

mirror create yes no

mirror delete yes yes

mirror demote no yes

mirror disable yes no

mirror enable yes no

mirror kill yes yes

mirror modify yes no


13-3

Features and Functionality Supported by Data Mirror over IP Data Mirror over IP supports the following features and functionality:

• Whole-volume asynchronous replication over IP

• One source pointing to one target volume

• Ability to schedule, suspend, and restart replications

• Provide resynchronization capability after suspending (using mirror pause and mirror resume commands) without level 0 copy again

• Block-based incremental mirrors

• Break mirror and promote target to read/write

• CLI and NAS Cluster Manager Web UI

• A maximum of 20% degradation in performance and throughput when replication is enabled

• Source and destination volumes and virtual servers on different clusters

• A maximum of 16 concurrent Data Mirror over IP sessions per NAS Gateway

mirror pause yes no

mirror promote no yes

mirror resume yes no

mirror reverse yes no

mirror schedule yes no

mirror show yes yes

mirror start yes no

mirror testconnect yes yes

Table 13-10: Mirror Commands in Data Mirror Over IP (Continued)

CommandRun from Virtual Server Associated with Source

Volume

Run from Virtual Server Associated with Target

Volume


13-4

• Target read-only with the ability to move live file systems on a target volume to the latest snapshot

• Backup of remote mirror target

Data Mirror over IP PrerequisitesFor Data Mirror over IP to work you need to open the following specific ports in your firewalls:

• The sanm agent on the target file processor listens on TCP port 58502.

• The sanmd daemon on the system switch and controller (SSC) listens on UDP port 36035.

ONStor does not support changing these ports.

Local Data MirrorIn local data mirroring the source and target volumes are on the same NAS Gateway and the same virtual server. Read and write operations in local mirroring occur as serial operations.

Data Mirroring MethodsThe NAS Gateway supports the following methods of data mirroring:

• Asynchronous storage area network (SAN) based mirroring for intermittently synchronizing file system information between a source volume and a read-only target volume. The data is mirrored through the SAN because the source and target volumes reside on disk arrays accessible by the same NAS Gateway.

• Volume mirroring from multiple source disk arrays to target volumes on a single high-capacity disk array. The AutoGrow feature can increase the size of a target volume automatically as needed. However, it is good practice to create the target volume in the same size or larger as the source volume. For information about supported disk arrays, contact your customer support representative and request a copy of the Compatibility Matrix.

• The NAS Gateway supports mirroring a source small computer system interface (SCSI) disk array to a slower but higher capacity target integrated drive electronics disk array as long as the disk array has a Fibre Channel (FC) interface.


13-5

During a base line data copy, a baseline mirror session takes place, which transfers the file system in its entirety. Subsequent mirror sessions are incremental.

Asynchronous and Synchronous MirroringTwo types of mirroring exist: synchronous and asynchronous. With synchronous mirroring, the file system is replicated to the target volume in real time. With asynchronous mirroring, the file system is replicated to the target volume at recurring synchronization intervals. The ONStor Data Mirror solution supports asynchronous mirroring through two methods: a mirror schedule and an on-demand mirror session.

• The mirror schedule is a policy you can configure that sets various time parameters for managing the mirroring interval of file system data from the source volume to the target volume.

• The on-demand mirror enables you to manually invoke the transmission of file system data from the source volume to the target volume. The on-demand mirror session requires more user intervention because the on-demand session occurs only once each time you start the session by running a user interface command.

A configured mirror schedule can exist concurrently with an on-demand mirror session, but only one mirror session per volume can be active.

Volumes and Automatic GrowthFor more information about volume AutoGrow, see “Managing Volumes and File Systems” on page 6-1.

When the NAS Gateway’s Volume Manager (VM) requests an AutoGrow event, the VM checks for the presence of a target volume, and enforces AutoGrow in the following ways:

1. If a target volume exists, AutoGrow occurs on the target volume first.

2. If no target volume exists, AutoGrow occurs on the source volume.

3. If a target volume exists, but there is not enough space to automatically grow the volume, the AutoGrow fails.

If situation 3 occurs, you can resolve the disk space problem by one of two methods:


13-6

• Expand the target disk space.

• Delete or break the mirror. At the conclusion of target disk expansion or mirror deletion, AutoGrow resumes on the source volume as configured.

Tracking File System Quotas on Target VolumesIn a typical configuration, quota configuration information is mirrored from the source volume to the target volume. However, because the target volume is read-only, data operations that require disk block allocations in the file system are not mirrored to the target volume. Therefore, quotas are not enforced or tracked on the target.

Because quota information is present on both the source and target volumes, if the target volume is promoted, it will already own a copy of the quota conditions that were active the last time the mirror was synchronized.


13-7

Configuring Data MirrorsBefore configuring a mirror, consider the following:

• You need to be in the virtual server context to configure and manage mirrors.

• The LUNs for the target volume and the file system can be on different or the same disk arrays.

• You need LUNs that are free and labeled for the target volume, or you can use a volume that has been created with the -m option. If the mirror existed before and has been deleted, thus promoting the target volume, you can demote the original target volume using the mirror demote command, and re-use it for the mirror. It has to have the same source volume and same mirror name. See “Demoting a Mirror Volume for Data Analysis” on page 13-16.

• Mirroring occurs on a 1:1 ratio between the source volume and the target volume.

• The entire file system is mirrored. You cannot mirror a part of a file system.

• Zoning must not eliminate an identical view of the target disk array.

• The NAS Gateway has no fault tolerance or autorepair of the source or target disk array. If the source disk array fails, manually repair it.

- If the source disk array fails, you can promote the mirror. For more information, see “Promoting Mirrors” on page 13-21.

- If the target disk array fails, you can perform the physical repairs, then recreate the source data on the new target disk array.

Creating a Local Mirror to Perform Baseline Data Copy for a Data Mirror over IPWhen you create the first mirror on your cluster, you use a local mirror to perform a baseline data copy onto an existing target volume on your cluster. After the initial data copy, mirroring operations are incremental. Incremental mirroring can be done on a local or a data mirror over IP.

Within a NAS Gateway, you can configure mirrors for multiple volumes, one mirror per volume. You can configure mirrors for up to half of the maximum number of volumes allowed per NAS Gateway because each target volume counts against the


13-8

maximum number of volumes allowed per NAS Gateway. You can schedule multiple mirror sessions to start concurrently. The NAS Gateway processes a maximum of 16 mirror sessions at a time. Any sessions beyond the first 16 sessions scheduled to start at the same time are placed on a pending list. As mirror sessions complete, the NAS Gateway automatically starts mirror sessions from the pending list.

To Perform a Baseline Data Copy

Step 1: Create a mirror on the source cluster by running the following command:mirror create MIRRORNAME SRC-VOL TGT-VOL [-R TARGETARRAYORDEVICE] [-S STATE] [-m MINUTE] [-h HOUR] [-d DATE] [-M MONTH] [-D DAY] [-l{low|med|high}]


MIRRORNAME Specifies the name of the mirror you are creating. Use an alphanumeric character string of up to 16 characters. Avoid using special characters such as *,?, ~, and /.

SRC-VOL Specifies the name of the source volume that the NAS Gateway will be mirroring onto the target volume.

TGT-VOL Specifies the name of the target volume that will receive the data copy from the source volume on the source disk. For a baseline data copy, use an existing volume.

-R TGTARRAYORDEVICE The name of the device controller for the target disk. Type the name of the array controller. You cannot mirror a file system volume across multiple arrays. The name string can be up to 127 characters. This optional parameter becomes required if the target volume does not yet exist.


13-9

-S STATE An optional argument that sets the operational state of the mirror schedule when you configure it. Specify either enable or disable. If you specify enable, the mirror schedule is immediately active when you complete configuring it. This state is the default.If you specify disable, the mirror schedule is not active when you complete configuring it.

-m MINUTE An optional argument that specifies the minutes of the hour at which to initiate a mirror session. Type a value from 0 to 59 where 0 is the top of the hour and 59 is the 59th minute of the hour. Multiple values can be entered in a comma-delimted list.

-h HOUR An optional argument that specifies the hour of the day at which to initiate a mirror session. This parameter accepts 24-hour time, so type a value from 0 to 23 where 0 is midnight and 23 is 11:00 p.m. If you do not specify a minutes value, the session occurs at the top of the hour that you specify.If you specify a minutes value, the session occurs at the number of minutes in the hour you specify. Multiple values can be entered in a comma-delimted list.

-D DATE An optional argument that specifies the date in a month on which to initiate a mirror session. Type a value from 1 to 31 where 1 is the first of the month and 31 is the last day of the month.Multiple values can be entered in a comma-delimted list.



13-10

Step 2: Start the mirror with the mirror start command to perform a baseline data copy to the target volume on the source cluster. For details on how to use this command, see “Starting or Stopping a Mirror” on page 13-20.

-M MONTH Specifies an optional month of the year in which to initiate a mirror session. Type a value from 1 to 12 where 1 is January and 12 is December. If you do not specify a month value, the mirror session occurs every month based on the time values configured with the other time parameters. If you specify a month value, the mirror session occurs at that month within the year. For example, if you specify 6, the mirror session occurs in June of each year. Multiple values can be entered in a comma-delimted list.

-d DAY An optional argument that specifies the day on which to initiate a mirror session. Type a value from 0 to 6 where 0 is Sunday and 6 is Saturday. If you do not specify a day of the week value, the session occurs as configured by the other parameters. If you specify a day of the week value, the session occurs on the day that you specify. Multiple values can be entered in a comma-delimted list.

-l low|med\high Specifies the the mirror load at either low, medium or high. You select the mirror load that is put on the NAS Gateway and disk arrays during a mirror session.



13-11

Step 3: When the baseline data copy is completed, delete the local mirror with the mirror delete command on the source cluster. Deleting the local mirror that you created for the baseline data copy operation automatically promotes the target volume to a standard volume. For details on how to use this command, see “Deleting a Mirror” on page 13-19.

Step 4: Disconnect the target volume storage and move the storage to the remote site. Then connect it to the target cluster.

Step 5: Delete the target volume from the source cluster with the volume delete command. For details on how to use this command, see “Deleting a Volume” on page 6-22.

Step 6: Rescan all LUNs on the source cluster with the lun rescan all command. For details on how to use this command, see the ONStor Bobcat 2200 Series Command Reference.

Step 7: Rescan all LUNs on the target cluster with the lun rescan all command. For details on how to use this command, see the ONStor Bobcat 2200 Series Command Reference.

Step 8: Import the target volume in a virtual server of the remote cluster as a mirror volume with the volume import command. For details on how to use this command, see “Importing a Volume From One Cluster to Another” on page 6-20.

Step 9: Bring the target mirror volume on the remote cluster online by running the volume online command. For details on how to use this command, see “Bringing a Volume Online” on page 6-19.

Step 10: On the source cluster, create a data mirror over IP with the mirror create command by using the source and target volumes, and the IP or DNS name of the virtual server where you imported where you imported the target volume. You do not need to specify the -R option at this point because the target volume already exists. For details on how to use this command, see “Creating Local Mirror and Data Mirror over IP Schedules” on page 13-12.


13-12

Note - Ensure that the remote mirror name is the same as the local mirror name you previously created.

At this point, each subsequent mirror session is incremental, and you can create mirror schedules.

Creating Local Mirror and Data Mirror over IP SchedulesIf a schedule is configured for a mirror at create time, then this command is used to replace the schedule with a new one. If no schedule was specified at mirror create time, then this command may be used to add one. If this command is run with no options, the schedule for the specified mirror is deleted.

Note - For a remote mirror, this command must be run in the context of the virtual server associated with the remote mirror's source volume.

To Create a Mirror Schedule

• Run the following command:mirror schedule MIRRORNAME [-m MINUTE] [-h HOUR] [-d DOM] [-M MONTH] [-D DOW]


MIRRORNAME Specifies the name of the mirror you are creating. Use an alphanumeric character string of up t 15 characters. Avoid using special characters such as *,?, ~, and /.


13-13

-m MINUTE An optional argument that specifies the minutes of the hour at which to initiate a mirror session. Enter a value from 0 to 59 where 0 is the top of the hour and 59 is the 59th minute of the hour. This value can interact with the -h HOUR argument to specify an hour at which the mirror session will occur. If you do not specify a minute value, the mirror session will occur at the top of the hour. If you do specify a minute value, the mirror session occurs at that minute within an hour. By default, this argument is set to zero (0).Multiple values can be entered in a comma-delimted list.

-h HOUR An optional argument that specifies the hour of the day at which to initiate a mirror session. This parameter accepts 24-hour time, so enter a value from 0 to 23 where 0 is midnight and 23 is 11:00 p.m. This value can interact with the -m MINUTES argument to specify a time other than the top of the hour. If you do not specify a minutes value, the session will occur at the top of the hour that you specify. If you do specify a minutes value, the session will occur at the number of minutes in the hour you specify. Multiple values can be entered in a comma-delimted list.

-d DOM An optional argument that specifies the date in a month on which to initiate a mirror session. Enter a value from 1 to 31 where 1 is the first day of the month and 31 is the last day of the month.Multiple values can be entered in a comma-delimted list.

-M MONTH An optional argument that specifies the month of the year in which to initiate a mirror session. Enter a value from 1 to 12 where 1 is January and 12 is December. This value can interact with the -d DOM argument. to specify a particular date at which the mirror session will occur. If you do not specify a month value, the mirror session will occur every month based on the time values configured with the other time parameters. If you do specify a month value, the mirror session occurs at that month within the year. Multiple values can be entered in a comma-delimted list.



13-14

Note - You can also create a mirror schedule when you first create a mirror with the mirror create command.

Verifying Data Mirror over IP Port ConnectivityFor Data Mirror over IP to work, the following ports must be accessible:

• 48502, the port on which the sanm agent on the target FP port listens

• 36035, the port used by the sanmd daemon on the SSC

Firewalls might block the sanm ports used for data mirroring over IP, so you need to check these ports for accessibility.

To Check Port Accessibility

• Run the following command from the virtual server context: mirror testconnect {HOSTNAME|IPADDR}

{HOSTNAME|IPADDR} specifies either a DNS, NIS, or LDAP host name or an IP address of the location to check for port accessibility across firewalls.

Note - You need to run this command from the context of the virtual server of the NAS Gateway that you are logged on.

-D DOW An optional argument that specifies the day on which to initiate a mirror session. Enter a value from 0 to 6 where 0 is Sunday and 6 is Saturday. If you do not specify a day of the week value, the session will occur as configured by the other parameters. If you do specify a day of the week value, the session will occur on the day that you specify.Multiple values can be entered in a comma-delimted list.



13-15

Backing Up Mirror VolumesYou can back up system or user-created snapshots on mirror volumes. The following limitations apply to backing up a mirror volume:

• Backup of a mirror volume fails on a running mirror.

• If a backup of a mirror volume is running, a mirror will fail to start if the snapshot being backed up on the target volume has been deleted from the source volume. If the snapshot still exists on the source volume, the mirror and backup will run concurrently. This limitation applies for both local and remote mirrors.

Modifying Mirror AttributesYou can modify the following attributes of an existing mirror with the mirror modify command:

• The mirror source volume

• The mirror target volume

• The mirror load

For a remote mirror, you need to run this command in the context of the virtual server associated with the remote mirror’s source volume.

To Modify a Mirror’s Attributes

• Run the following command: mirror modify MIRRORNAME [-s SRCFSYS] [-tTGTFSYS] [-l {low|high|med}]


MIRRORNAME Specifies the name of the mirror you are modifying. Use an alphanumeric character string of up to 16 characters. Avoid using special characters such as *,?, ~, and /.

-s SRCFSYS Specifies the name of the source volume. You can change this attribute only when the mirror is idle.


13-16

Demoting a Mirror Volume for Data AnalysisYou can demote a mirror volume that was previously promoted to a live file system volume with the mirror promote command back to a mirror volume by running the mirror demote command. This command reverts the volume to the last mirror snapshot. When you demote a mirror volume, you will lose all file system modifications you might have made since the last mirror snapshot. You can demote local mirrors and data mirrors over IP. For a data mirror over IP, run this command from the context of the virtual server associated with the remote mirror’s target volume. Demoting a mirror is helpful when you need to perform data analysis and need to write data on the target volume but do not need to keep that data.

To Demote a Mirror Volume

Step 1: After the mirror has transferred the data to the target volume, disable the mirror with the mirror disable command. For details on how to use this command, see “Enabling or Disabling a Mirror” on page 13-19.

Step 2: Promote the target volume using the mirror promote command. For details on how to use this command, see “Promoting Mirrors” on page 13-21.

Step 3: Perform the data analysis.

Step 4: Demote the target volume back to a mirror volume using the following command:mirror demote VOLNAME

VOLNAME is the name of the mirror volume you are demoting.

You will lose all modifications made to the volume made since

-t TGTFSYS Specifies the name of the target volume.You can change this attribute only when the mirror is idle.

-l {low|high|med}

Specifies the relative load that the mirror session should place on the NAS Gateway. The default is med.



13-17

the last mirror snapshot.

Step 5: Bring the target mirror volume online with the volume online command. For details on how to use this command, see “Bringing a Volume Online” on page 6-19.

Note - Mirror sessions can now resume, and subsequent mirror sessions will be incremental.

Reversing a Mirror for Disaster RecoveryUse the mirror reverse command to reverse the direction of a mirror. This is helpful after disaster recovery because you can revert a mirror back to the source volume with data modifications made on the target volume after the failure occurred. You need to run this command from the virtual server context of the mirror source virtual server when the source cluster has recovered and is back up again.

To Reverse the Direction of a Mirror

Note - This procedure assumes that the target volume has been promoted and is currently servicing data from the remote site.

Step 1: When the source NAS Gateway is back up, run the mirror disable command on the source NAS Gateway to prevent the source NAS Gateway from attempting to send data to the target volume. Any such attempt would fail because you promoted the target volume in Step 2.

Step 2: Reverse the mirror by running the following command on the source NAS Gateway:mirror reverse MIRROR

MIRROR is the name of the mirror you are reversing. Reversing a mirror automatically enables the mirror.


13-18

Step 3: Run the mirror start command on the source NAS Gateway that recovered to transfer back to the original source volume all target volume modifications made to the target since the target volume was promoted. Before doing this, you might want to disable CIFS and NFS services to prevent additional modifications to the target volume. For details on how to use the mirror start command, see “Starting or Stopping a Mirror” on page 13-20. For details on how to disable NFS and CIFS shares, see “Enabling or Disabling NFS Shares” on page 7-49 and “Enabling or Disabling CIFS” on page 7-53.

The following steps are intended to restore your original mirror direction after a disaster recovery.

Step 4: Take the source volume on the original NAS Gateway that serviced the data offline by running the volume offline command. For details on how to use this command, see “Taking Volumes Offline” on page 6-18.

Step 5: Promote the source volume on the original source cluster that had the disaster with the mirror promote command. For details on how to use this command, see “Promoting Mirrors” on page 13-21.

Step 6: On the original target NAS Gateway that serviced the data temporarily, reverse the mirror by running the following command:mirror reverse MIRROR

MIRROR is the name of the mirror you are reversing.

Step 7: Bring the source and target volumes online on their respective clusters by running the volume online command. For details on how to use this command, see “Bringing a Volume Online” on page 6-19.

Mirror sessions can now resume through the mirror schedule or by using the mirror start command.


13-19

Deleting a MirrorWhen you delete a mirror, all its configured parameters are deleted, but the file system data associated with the mirror is not deleted from the target disk array. Deleting a mirror when the target volume has not yet been promoted will promote the target volume from a mirror to a standard volume. The target volume has to be offline.

To Delete a Mirror Schedule

• Run the following command: mirror delete MIRRORNAME

MIRRORNAME is an alphanumeric character string of up to 15 characters.

Enabling or Disabling a MirrorMirrors are automatically enabled when they are created. However, for mirrors that have been manually disabled, you need to explicitly enable each mirror by name. When you enable the mirror, one of two situations occurs:

• If the NAS Gateway is configured for scheduled mirroring, it begins mirroring based on the mirror schedule’s time parameters that you have configured.

• If the NAS Gateway is configured for on-demand mirroring, it waits for you to manually invoke a mirror session.

When you disable a mirror, any configured parameters in the mirror schedule are not deleted, but remain configured and suspended until the mirror is re-enabled.

To Enable a Mirror

• Run the following command:mirror enable MIRRORNAME


To Disable a Mirror

• Run the following command: mirror disable MIRRORNAME


13-20


Starting or Stopping a MirrorYou can start either one mirror or multiple mirror sessions concurrently. The NAS Gateway processes a maximum of 16 mirror sessions at a time. Any sessions beyond the first 16 sessions you have started at the same time are placed on a pending list. As mirror sessions complete, the NAS Gateway automatically starts mirror sessions from the pending list.

You can stop in-progress or paused mirror sessions by name regardless of whether they are on-demand or scheduled. If you stop a scheduled mirror session, only the current session is halted. The next mirror session will occur at its regularly scheduled time.

To Start a Mirror Session

• Run the following command: mirror start MIRRORNAME


To Stop a Mirror Session

• Run the following command: mirror kill MIRRORNAME

MIRRORNAME is a free-form alphanumeric character string from 1 to 15 characters in length. Enter the name of the configured mirror that you want to stop.

Displaying Mirror Session InformationYou can display general information about all mirror sessions on the current NAS Gateway, or obtain detailed information about a specified mirror session.


13-21

To Display Mirror Session Information

• Run the following command: mirror show [MIRRORNAME]|[-v SRCVOLNAME]

MIRRORNAME is an optional alphanumeric character string of up to 15 characters.

• If you specify a name, only that mirror is displayed.

• If you specify no name, all configured mirror schedules are displayed.

-v SRCVOLNAME displays mirrors for the specified source volume.

Promoting MirrorsYou can promote a mirror to a mountable, read-write file system.

Note - ONStor recommends promoting a mirror to a read-write file system only in the case of an emergency because you lose redundancy.

Before you can promote a mirror, ensure that the target volume is in an operational state of IDLE and that the target volume is offline.

To Promote a Mirror to a Read-Write File System

Step 1: Check whether the mirror you want to promote is in IDLE state by running the following command:mirror show

From within the context of the NAS Gateway, this command displays a list of all mirrors associated with that NAS Gateway and the mirror’s operational state.

If the mirror you want to promote is in paused or in-progress state, wait for it to reach idle state.


13-22

Step 2: If the mirror you are promoting has is scheduled to occur at regular intervals, turn off the mirror schedule by running the following command:mirror schedule MIRRORNAME

MIRRORNAME is the name of the mirror.

Clear all parameters presently specified in the mirror schedule to remove the mirror schedule.

Step 3: Run the following command to obtain the latest mirror before promoting it:mirror start MIRRORNAME

MIRRORNAME is the name of the mirror.

Step 4: Take the target volume offline by running the following command:volume offline VOLNAME

VOLNAME is the name of the target volume to be taken off line.

Step 5: Promote the mirror to the role of file system by running the following command:mirror promote MIRRORNAME


Step 6: Unless you plan to demote the target volume, you can delete the mirror information from the cluster database by running the following command:mirror delete MIRRORNAME

MIRRORNAME is the name of the mirror you just promoted to the role of file system.

Note - Using mirror delete on the source cluster in Step 5 instead of mirror promote automatically promotes the target volume and deletes the mirror.


13-23

The target volume can now be brought online and service data after you add shares.

Promoting a Remote Mirror to Restore Services If the Source NAS Gateway Is DownYou can promote a remote mirror to restore file system services if the source NAS Gateway is down.

To Promote a Remote Mirror If the Source NAS Gateway Is Down

Step 1: Take the target mirror volume offline by running the volume offline command. For details on how to use this command, see “Taking Volumes Offline” on page 6-18.

Step 2: Promote the target mirror volume by running the mirror promote command. For details on how to use this command, see “Promoting Mirrors” on page 13-21.

Step 3: Configure the target NAS Gateway to provide file services while the source NAS Gateway is down.

Pausing and Resuming a Mirror SessionBy pausing the mirror session, you stop the open disk-to-disk connection of the mirror without halting the session or deleting the target disk’s copy of the file system. The paused mirror session retains the configured mirror schedule and all other configured mirror parameters, but the file system and snapshot updates are suspended while the mirror session is paused.

Note - When you pause a mirror session, the file system can change without the mirror reflecting the changes.

Paused mirror sessions do not time out or restart. When a mirror session is paused, it remains paused until you resume the mirror session.


13-24

To Pause a Mirror Session

• Run the following command:mirror pause MIRRORNAME

MIRRORNAME is an alphanumeric character string from 1 to 15 characters in length. Enter the name of the configured mirror that you want to pause.

When you resume a paused mirror session, the configured schedule and mirror parameters are available again, and the file system and mirror file system synchronize and are able to replicate any changes from the source volume to the target volume.

To Resume a Mirror Session

• Run the following command: mirror resume MIRRORNAME


Removing a Mirror Schedule You can modify or remove a mirror schedule at any time. When you modify the mirror schedule, the modified parameters become active immediately, but they will not take effect until the next scheduled update of the mirror. You can perform the following tasks with the mirror schedule command.

To Remove a Mirror Schedule

Step 1: Locate the mirror with the schedule that you want to modify by running the following command:mirror show

Step 2: Run the mirror schedule command, but specify no parameters to clear the current mirror schedule:mirror schedule MIRRORNAME


Chapter 14: Managing Backup and Restore


• “Introducing Backup and Restore” on page 14-2

• “Adding Local User Accounts for NDMP Services” on page 14-18

• “Managing NDMP Sessions” on page 14-28

• “Configuring the NAS Gateway for NDMP Services” on page 14-39


14-2

Introducing Backup and RestoreIn the ONStor implementation of backup and restore operations, the terms backup and restore describe moving data between disk and tape:

• A backup operation moves data from a primary storage disk to a tape drive.

• A restore operation retrieves archived data from secondary storage, such as a tape to primary storage, such as a disk.

The ONStor backup and restore solution supports two backup and restore topologies:

• Network data management protocol (NDMP)

• CIFS or NFS

Backing Up and Restoring Data Using NDMPThe NDMP defines an open-standard mechanism and protocol for controlling backup, recovery, and other transfers of data between primary and secondary storage. A disk or disk array is considered primary storage. A tape device is considered secondary storage. A tape device can be a standalone tape drive or it can reside in a tape library, also known as a media changer.

Because NDMP is an open-standard protocol, it does not specify the data format for the data stream written to the tape device. Instead, the ONStor NAS Gateway supports a proprietary format for the data stream. Therefore, if you have backed up a file system through a NAS Gateway, you can restore it only through a NAS Gateway.

The NAS Gateway is always the NDMP server in backup, restore, and media operations. As the NDMP server, the NAS Gateway receives and fulfills requests from the NDMP client. The NAS Gateway does not schedule or create backup or restore sessions. Instead, it supports the backup and restore conditions that are requested by a backup and restore application.

The NAS Gateway supports backup and restore on a per-virtual-server basis. Each virtual server acts as a separate instance of NDMP server, and therefore, each virtual server communicates with an NDMP client to support NDMP backup and restore operations.


14-3

The NDMP architecture separates the network-attached data management application (DMA), data servers and tape servers participating in archival or recovery operations. NDMP also provides low-level control of tape devices and SCSI media changers.

You can install data servers and tape servers either on separate devices or on the same device. In the ONStor implementation of backup and restore through NDMP, tape and data servers are not required to be on the NAS Gateway. Tape and data servers can be independent equipment or exist on the same physical device. They can also be the ONStor NAS Gateway, or a product from an NDMP-compliant, third-party equipment vendor that ONStor supports. If you are using a third party tape or data server, it must be NDMP-compliant, and it must be supported by ONStor. To find out which third-party equipment vendors ONStor supports, you can contact ONStor Customer Support and request the latest version of the Compatibility Matrix.

To use the ONStor NDMP backup and restore solution, you need a third-party NDMP DMA. The ONStor NAS Gateway is always the NDMP server. In this client/server model, the NDMP client controls the scheduling of backups and restores, and the NDMP server is the entity that processes any NDMP request that the NDMP client sends.

Note - All aspects of scheduling and activating backups are configured through the NDMP client, not on the ONStor NAS Gateway (NDMP server).

For details about supported DMAs and how to configure the NAS Gateway to interoperate with DMAs see “Supported Data Management Applications” on page 14-5 and “Configuring the NAS Gateway for NDMP Services” on page 14-39. For more information about NDMP, consult www.ndmp.org.

Backing Up and Restoring Data Using CIFS or NFSYou can perform backup and restore operations by using a CIFS or NFS client to backup and restore a mounted CIFS or NFS file system.

When performing backup by using CIFS or NFS clients, certain file system meta data might not be backed up. For example, when backing up from NFS, CIFS ACLs are not backed up, and when backing up from CIFS, NFS ACLs are not backed up. You might


14-4

also lose quota information. Consequently, during a restore operation that file system meta data is not restored. However, all files with file data are restored.

Note - Using a CIFS or NFS client for backing up data might adversely affect performance.

This chapter does not describe in detail backup and restore operations using a CIFS or NFS client. The remainder of this chapter focusses on NDMP backup and restore operations.

Supported Backup and Restore ConfigurationsThe NAS Gateway supports two backup and restore configurations:

• Local backup and restore. In a local configuration, you can back up data or restore data that belongs to a virtual server to and from tape devices controlled by the same virtual server.

• Remote backup and restore. The NAS Gateway supports acting as both a data server and as a tape server in remote NDMP configurations. You can back up data from a NAS Gateway to a tape device connected to a remote NDMP server. In a remote configuration you can back up data or restore data that belongs to a virtual server to and from tape devices controlled by a different virtual server.

Supported Backup and Restore TypesThe NAS Gateway supports the following types of backup and restore operations:

• Full backup, in which the NAS Gateway performs the backup of 100 percent of the data on a per-file-system or partial-file-system basis.

• Partial backup, in which the NAS Gateway can back up a file hierarchy of directories and subdirectories that does not begin at the root of the file system.

• Incremental backup, in which the NAS Gateway performs a backup of only the data that has changed since the last full, or lower level backup. You can also perform an incremental backup in a partial backup operation.


14-5

On the NDMP client, you can give incremental backups a level that ranks them and allows a backup only when a higher ranking increment occurs. For details on how to assign levels to incremental backups, see the documentation that accompanied your backup application.

• The NAS Gateway supports cumulative and differential backups for full and partial backups. In a cumulative backup, a backup of the changed data since the last full backup occurs. In a differential backup, only the changes in the data that occurred since the last backup are backed up. Some DMA vendors use different terminology and time intervals for differential, partial, or cumulative backup. For specifics, consult the documentation that accompanied your DMA product.

Supported Data Management ApplicationsNDMP clients use third-party DMAs for data processing. The ONStor implementation of NDMP supports the following DMAs:

• IBM Tivoli® Storage Manager (TSM)

• Veritas® NetBackup™ (VN)

• BakBone NetVault™

• Computer Associates International, Inc., BrightStor® ARCServe

• Networker by EMC Legato

• CommVault Galaxy

For details on which versions of these DMAs are supported, contact the ONStor technical support department and request the latest issue of the Compatibility Matrix. For details on how to configure the NAS Gateway for NDMP Services using any of these DMAs, see “Configuring the NAS Gateway for NDMP Services” on page 14-39.

Supporting the NDMP Snapshot Management ExtensionThe NAS Gateway supports the NDMP snapshot management extension. The NDMP snapshot management extension interface defines a mechanism and protocol for controlling snapshots. For details about snapshots, see “Managing Snapshots” on page 9-1.


14-6

Performing NDMP Services Through the NAS GatewayThe NAS Gateway supports a full implementation of the services listed in the NDMP specification. Functioning as the NDMP server, the NAS Gateway supports the following main services for backup and restore operations:

• Tape services, which control the following:

- Reading data from tape drives to an active data stream during a restore

- Writing data from an active data stream to tape drives during a backup

Supported tape and media changer services are in accordance with the NDMP specification. The NAS Gateway supports tape services for FC-attached tape devices.

• Data services, which control the following:

- Writing data from disk to an active NDMP session during a backup operation

- Reading the NDMP session’s data to disk during a restore operation

Supported data services are in accordance with the NDMP specification.

• SCSI services, which support SCSI pass-through functions and relay SCSI control data blocks (CDBs) initiated by the NDMP client. SCSI services command the SCSI tape changer to automatically perform actions, such as changing tapes or ejecting them from a drive whenever a tape becomes full.

• Mover services, which control reading data from and writing data to a tape device and applying buffering of data where required.

Performing Backup and Restore Through the NAS GatewayTo perform a successful backup or restore, the NDMP client and server communicate through a series of requests and responses that occur in two sequential phases: setup and communication. During these phases, and during backup and restore sessions, the NAS Gateway is always the NDMP server.

In the setup phase for local backup and restore, the client issues commands to establish a control connection to the server.


14-7

In the setup phase for remote backup and restore, the client issues commands to establish two control connections: one to the tape server handling all tape control and one to the data server to control the backup and restore operation.

The commands that the NDMP client issues can include:

• Authentication and queries for NDMP server information

• The types of backup supported

• File system information

• Tape information

• SCSI tape changer information

Using the control connection, the NDMP client is the initiator of requests that trigger responses from the NDMP server. The NDMP client opens control connections in the setup phase. After successful discovery of the target device and its characteristics, the NDMP client requests a data connection for actual transfer of data to a storage device.

For a local backup and restore session, the address type is always local. For a remote backup and restore session, the address type is TCP.

In the communication phase, the actual transfer of data between the disk and the target storage device that was discovered in the setup phase occurs. In the communication phase, the NDMP client is still the initiator of requests, and the NDMP server is the agent that activates drivers that place data on, or pull data from, one or more tape


14-8

devices. Figure 14-3 shows the local backup and restore operations and related control connections and data flow.

During the setup phase, the NAS Gateway listens for the NDMP client’s requests on the NDMP server’s TCP port. The NAS Gateway also contacts the tape drive or the robot arm of a tape library and prepares the tape to receive data. In Figure 14-3, the dashed line shows this as the control connection. During the communications phase, on each instance of backup or restore, the NAS Gateway creates an NDMP session on a one-to-one basis with each client.

In each NDMP backup session, the backup application transmits data from the disk and writes it to the tape drive, as shown by the solid black line in Figure 14-3. The NDMP client governs opening and closing the backup session, and transmitting the data.

In each NDMP restore session, the restore application reads data from the tape library and writes it to disk, as shown by the grey line in Figure 14-3. The NDMP client governs opening and closing the backup session, and transmitting the data.

Tape Library

Data

NDMP Server

Disk

NDMP Client

(ONStor NAS Gateway)

Control Connection

Data Flow Data Flow

Figure 14-3 NDMP Client and Server in Simple Topology


14-9

Understanding Backup and SnapshotsEach volume contains its own snapshots in the /.snapshots directory. For more information about snapshots, see “Managing Snapshots” on page 9-1.

The NAS Gateway uses snapshots as part of the backup procedure in either of the following ways:

• Backing up a standard file system. When backing up a standard file system, the NAS Gateway does the following:

- Creates a snapshot of the file system.

- Pins the snapshot. Pinning the snapshot prevents anyone from deleting or renaming the snapshot while the backup is in progress.

- Runs the backup session.

- Unpins the snapshot.

- Deletes the snapshot.

• Backing up a directory within the /.snapshots directory. When backing up a directory within the /.snapshots directory on a volume, the NAS Gateway runs a backup session without creating and pinning a new snapshot for the purpose of the backup session.

Understanding Restore and File System QuotasWhen a restore occurs, two outcomes can exist for the backed up quota information:

• Quotas on tape can overwrite any quotas configured in the live file system.

• Quotas on tape can be discarded in favor of quotas in the live file system.

Both scenarios are controlled by NDMP environment variables that determine whether quotas on tape should be restored to the live file system.

The NAS Gateway’s implementation of quotas includes NDMP environment variables that affect how quotas are restored from tape:

• ONSTOR_SUPERSEDE_QUOTAS, which controls whether quota information on tape is restored when an NDMP restore session occurs.


14-10

• ONSTOR_IGNORE_USR_GROUP, which controls the behavior of user and group quotas when an NDMP restore session occurs.

• ONSTOR_IGNORE_QTREE, which controls the behavior of tree quotas when an NDMP restore session occurs.

Backing Up an ONStor Data MirrorMirror and backup services cannot operate concurrently on the same NAS Gateway. If both services are configured on the same NAS Gateway, the service that starts first takes priority.

• A mirror start will fail if a backup session is in progress.

• A backup start will fail if a mirror session is in progress.

To avoid this service conflict, you can run the mirror session on the NAS Gateway with the live file system and run the backup and restore services on the NAS Gateway with the read-only mirror. In this configuration, both services can operate concurrently without intruding on each other. However, during a backup session no changes can occur on the read-only mirror, and the source volume (the live file system) will contain a pinned mirror snapshot. You cannot rename or delete the pinned snapshot until the backup session completes.

During a backup session, the mirror data on the target volume is backed up to tape. No snapshot is taken. For more information about the ONStor Data Mirror feature, see “Working with ONStor Data Mirror” on page 13-1.

During the backup session, the live file system can continue to process file requests from common Internet file services (CIFS) or network file system (NFS) clients, and I/O can still be read to and written from disk.

The NAS Gateway automatically generates a name for the mirror snapshot. The name’s format is similar to: SANM_SS_m1_000001, where:

- SANM_ indicates that the snapshot has been automatically generated by the NAS Gateway.

- SS_ indicates a snapshot file.

- m1_000001 is an identifier string for the mirror snapshot.


14-11

To Back Up a Mirror

Step 1: Create a snapshot on the source volume by running the snapshot create command. This command requires a volume name and a snapshot name.

A snapshot name can be in any alphanumeric character format of up to 256 characters. However, do not use any of the following snapshot names:

• Reserved snapshot names, such as hourly.x, daily.y., or weekly.z. For more information about reserved snapshot names, see “Managing Snapshots” on page 9-1.

• Mirror snapshot names, such as SANM_SS_m1_000001.

Step 2: Note the name of the snapshot that you just created, you will use it later.

Step 3: Create the mirror by running the mirror create command. For more information about this command, see “Working with ONStor Data Mirror” on page 13-1.

Step 4: Start the mirror by running the mirror start command.

Note - Wait for the mirror to complete successfully before continuing with Step 5.

Step 5: Configure the backup session for the appropriate DMA, as documented in the following sections:

• “Preconfiguration Considerations” on page 14-39

• “Configuring the NAS Gateway for Interoperability with DMAs for NDMP Services” on page 14-44

Step 6: After the backup has completed, delete the snapshot that you created in Step 1.


14-12

Understanding Management Volumes and NDMP SessionsEach volume on the NAS Gateway exists within the context of a virtual server. Backup of the volumes in a virtual server only occurs if NDMP is enabled on that virtual server. For details, see the “Working with Virtual Servers” on page 3-1.

Each NAS Gateway contains a management virtual server that is used for system functions. Within the management virtual server resides the management volume. For backup and restore sessions to operate, you need to configure a management volume for each management virtual server that will support backup and restore. For details, see “Managing Volumes and File Systems” on page 6-1.

Note - Although you can use the management virtual server for configuring user data or populating it with file system data, ONStor recommends to reserve the management virtual server for system functions.

The management volume is used to store state information when performing a backup or restore operation. Do not delete any files or directories within the temporary directory on the management volume.

Ensure that you have enough free space on the management volume during a backup or restore sessions:

• For backup operations, use the following formula as a general guideline for determining how much free space you need on the management volume: On the management volume, reserve 0.3 percent of the size of the volume you are backing up.

• For restore operations, use the following formula as a general guideline for determining how much free space you need on the management volume: On the management volume, reserve 1 percent space of the amount of space used on the volume you are restoring. This formula is based on an average file size of 16 K. Space requirements change linearly with changes of the average file size.

AutoGrow parameters are in effect when backup or restore occurs. If the amount of data for a backup or restore operation is larger than the volume can hold, the AutoGrow feature is triggered and the volume manager obtains enough LUN space to accommodate the amount of data in the operation.


14-13

Understanding NDMP Environment VariablesYou can use NDMP environment variables to control the following aspects of a backup or restore operation:

• Parts of the backup or restore session

• What data is backed up or restored

• How the NAS Gateway processes certain phases of the backup or restore session

Typically, environment variables are set automatically by the backup application. However, some are configurable so that you can customize the operation or performance of the backup or restore sessions.

Note - Backup applications can have expected or optimized values for environment variables. Changing these values can cause the backup application to behave unpredictably or can negatively affect the performance of the backup or restore session. Therefore, set or change environment variables only if you are familiar with the environment variables and the backup applications that are using them.

Some environment variables are supported by the NDMP specification, and others are specific to ONStor. Table 14-11 lists all environment variables defined by the NDMP protocol and ONStor and supported by the NAS Gateway. In the table, all variables specific to ONStor are indicated as such. The NAS Gateway ignores any unsupported


14-14

variables and does not send a message to the DMA or the NAS Gateway’s management console.

Table 14-11: Supported NDMP Environment Variables


BASE_DATE 0 or DUMP_DATEDefault: none

Used in backup sessions. Specifies the a reference time for incremental backup. A value of zero (0) indicates a full backup. Any other value indicates a reference time of a previous backup. An incremental backup includes only those files modified since the reference time. This reference time should be a value returned at the conclusion of a previous backup through the DUMP_DATE variable. If not set, the LEVEL variable is used to specify full or incremental backup and the backup timestamp is stored in an NAS Gateway’s local database if the UPDATE variable is true.

DIRECT y or nDefault: n

Used in restore sessions. Controls the support of Direct Access Restore (DAR) functionality. If set to Yes, a tape device forwards space directly to the location on the tape where a specified file exists, instead of scanning the whole tape. If set to No, no space is forwarded to the file’s location, thus the entire tape is scanned for the file. Set this variable only to Yes if the backup being restored was performed with HIST set to Yes.

DUMP_DATE return valueDefault: none

Used in backup sessions. Returned at the conclusion of a successful backup if BASE_DATE was set. If BASE_DATE was not set, this variable is not returned. Specifies a backup reference time that may be passed as the value of BASE_DATE in a subsequent incremental backup.

EXTRACT y or nDefault: y

Used in restore sessions. Controls the processing of files that were renamed or deleted between backups. This variable is analogous to the UNIX restore -x and restore -r commands. If set to Yes, no file deletions or renaming occurs when restoring an incremental backup. If set to No, file deletion and renaming occurs to restore the file system to the exact state at the time of the incremental backup.


14-15

FILESYSTEM Default: none

Used in backup and restore sessions. Defines the root of the backup. The path must include the volume name and must begin with a forward slash ( / ), for example, /vol1, /vol1/homes. Also include the snapshot directory for the volume, for example, /vol1/.snapshots, so that the volume’s snapshots are also backed up and restored. When backing up a read-only mirror, set this variable to a path within a snapshot that was created on the NAS Gateway where the volume is writable.

HIST y or nDefault: n

Used in backup sessions. Controls the generation of file history data during a backup session. File history data enables the use of DAR. If set to Yes, file history information is sent during a backup session. If set to No, file history information is sent. By setting this variable to No, you disallow DAR functionality.

LEVEL 0 to 9Default: 0

Used in backup sessions. Controls the level of backup to be started. If set to 0, all data is copied on backup. If set to a value greater than 0, incremental backup occurs. With incremental backup, all files with a lower level that have been modified are backed up. This variable is ignored if BASE_DATE is set.

ONSTOR_EXTRACT_8.3

(ONStor-specific)

y or nDefault: y

Used in restore sessions. Controls whether to restore “8 dot 3” file names from tape. If set to Yes, any 8.3 file name that was backed up is restored. However, this can cause a naming conflict. If a naming conflict occurs, the NAS Gateway posts a warning message and uses a new file name. If set to No, a file name is generated by the file system, which can result in a name that is different from the one that was backed up.

Table 14-11: Supported NDMP Environment Variables (Continued)



14-16

ONSTOR_EXTRACT_ACLS

(ONStor-specific)

y or nDefault: y

Used in restore sessions. Controls whether to restore the ACLs on a backed up file. If set to Yes, this variable restores the same ACLs that were on a file when it was backed up. If set to No, when the file is restored, the ACLs that were backed up with the file are discarded, and the file’s ACLs are inherited from the parent directory where the file is being restored.

ONSTOR_OVERWRITE

(ONStor-specific)

y or nDefault: y

Used in restore sessions. Controls the restore behavior on existing files. If set to Yes, this variable preserves existing files in the restore. If set to No, the existing files are overwritten during the restore.

ONSTOR_SUPERSEDE_QUOTAS

y or nDefault: y

Used in restore sessions. Controls restoration of tree (hierarchical) quotas. If set to Yes, this variable restores no tree quota information from tape. If set to No, the tree quota information is restored. Restoration of tree quota information involves restoring only the default and limit values for a tree. Usage is not restored. For more information, see “File System Quotas and Backup and Restore Operations” on page 10-3.

ONSTOR_IGNOREUSR_GRP

y or nDefault: n

Used in restore sessions. Controls restoration of user and group quotas. If set to Yes, this variable restores only tree (hierarchical) quota records. User or group quotas are ignored. You can implicitly set this variable when restoring dump formats that do not support quotas. For more information, see “File System Quotas and Backup and Restore Operations” on page 10-3.




14-17

ONSTOR_IGNORE_QTREE

y or nDefault: n

Used in restore sessions. Controls whether to restore tree (hierarchical) or directory quota information from tape to a live file system. If set to Yes, tree and directory quota configuration information and usage conditions are restored. If set to No, tree and directory quota configuration and usage conditions are left on tape, and log messages are generated. For more information, see “File System Quotas and Backup and Restore Operations” on page 10-3.

PATH_SEPARATOR

return valueDefault: none

Used in backup sessions as a return value to the DMA. Defines the character to be used as a separator in the path. The forward slash ( / ) is always returned as the path separator at the end of each backup session. The DMA must use the character specified by PATH_SEPARATOR when specifying files to be restored.

RECURSIVE y or nDefault: y

Used in restore sessions. Controls the behavior of restoring directories. The NDMP restore request contains a list of paths to be restored. This variable only takes effect if a path represents a directory. If set to Yes, the entire directory hierarchy specified by the path is restored. If set to No, this variable restores the directory path, but does not restore any of the files or directories within the directory path.

TYPE Default: none

Used in backup or restore sessions. Defines the backup type to be used. Overrides the butype_name specified in the NDMP_DATA_START_BACKUP or NDMP_DATA_START_RESTORE request.




14-18

Adding Local User Accounts for NDMP ServicesNDMP client and server communication occurs only after authentication. Authentication can be one way from either the client to the server or the server to the client, or two way, where the client and server authenticate each other. The authentication routine can be either a clear text password or an MD5 hash constructed from part of a username and password. The username and password for authentication are configured through a local user account.

You need to add a local user account on the NAS Gateway for NDMP authentication. The local user account is “local” because it is configured and resides on the NAS Gateway. The local user account has no effect outside the NAS Gateway, unlike Windows and NIS user accounts that reside on the domain controller or NIS server.

Each local user account is a cluster-wide entity, so you can use the same local user account on any NAS Gateway in a cluster. However, each local user account must be unique within a cluster.

The user account added for NDMP sessions must have privileges, otherwise, NDMP authentication and authorization will fail. For details on how to add privileges, see “Managing Privileges” on page 2-1.

To Add a Local User Account


UPDATE y or nDefault: y

Used in backup sessions. Updates the dump data section in the NAS Gateway’s cluster database by writing the time stamp part of the backup START_REQUEST message into the cluster database. If set to Yes, this variable writes a backup session’s timestamp to the NAS Gateway’s cluster database. If set to No, the configuration database is not updated with the backup session’s time stamp. This variable is ignored if BASE_DATE is set.




14-19

useraccount add USERNAME [-k “PUBKEY”]

Step 2: When prompted, enter the password for the user account you just created. The password for the local user account is an alphanumeric character string from 6 to 64 characters.

Step 3: Set the privileges for the user account you just created by running the priv add allow command. For more information about this command, see “Managing Privileges” on page 2-1. As part of this command, you need to set a scope at which the privilege is applied. For NDMP functionality, valid scopes are cluster or vsvr (virtual server). The scope cluster is greater than the scope vsvr and therefore includes the scope vsvr. You can also provide various levels of functionality with this command:

• For adding a user with full NDMP administrative privileges, set the user to cluster privilege.


USERNAME Specifies the user account name. Use an alphanumeric character string between 3 to 63 characters.

-k “PUBKEY” Specifies the SSH key for a local user account when the user account is created. The -k PUBKEY argument must be the SSH key that the client generated. If the key is not supplied or is not an exact match with the client’s SSH key, the user account cannot automatically log in. Therefore, you need to enter a password every time the user account accesses the NAS Gateway.The first time you create a local user account, you need to specify the password, even if you use the -k PUBKEY argument. The NAS Gateway gives precedence to the SSH key, so if it is specified, it is used instead of the password. If the SSH key is removed, the password is still configured, and you need to enter it for the local user account to be granted access to the NAS Gateway.The PUBKEY value is a character string from 1 to 4094 characters enclosed in double quotation marks.


14-20

• For security, you might want to allow someone to back up files but not restore them. For this situation, set the user to BACKUP privilege.

• For security, you might want to allow someone to restore files but not do any backup. For this situation, set the user to RESTORE privilege.

Setting an Alias for a Tape DeviceYou can assign an alias to tape devices to facilitate identification of the device. When you assign an alias, you associate a text string with the tape device’s actual device name. For example, you could create an alias called “tapedrive22” to identify a single tape drive instead of referring to it as QUANTUM_PMC01P3145_0.

To Create a Tape Alias

Step 1: Run the following command to discover the media changer’s device name:tape devlist -v

Note the tape device’s physical and logical device name. You will use this information in the next step.

Step 2: Run the following command to create an alias for the tape device:tape alias set DEVNAME LOGICALNAME ALIAS [-f]


DEVNAME Specifies the physical device name of the tape device as known to the NAS Gateway.

LOGICALNAME Specifies the logical device name of the tape device for which you are creating an alias.

ALIAS Specifies the alternate name of the tape device. Use an alphanumeric character string between 1 and 32 characters.

-f An optional argument that allows your to overwrite any existing alias.


14-21

Listing Tape Devices and Their AliasesTape devices that have aliases are kept in the Tape Devices Alias List. This list contains the following information for tape devices that have been aliased:

• The device name

• The alias that has been assigned

To Display the Tape Devices Alias Listtape alias show [DEVICE_NAME]

DEVICE_NAME displays the list of tape aliases and logical names for a specific physical device.

Removing an Alias from a Tape DeviceWhen remove an alias from a tape device, you can manage the tape device only through the device name or the logical device.

To Remove a Tape Device Alias

Step 1: Run the following command to locate the media changer:tape alias show

Step 2: Run the following command to delete the alias from the tape device:tape alias clear ALIAS

ALIAS is the name of the tape device alias that you are removing.

Listing Tape DevicesWhen the NAS Gateway completes its SAN discovery, the tape resources are virtualized and posted to the tape devices list. The list provides operational and performance information about each device. You can display either basic information about all tape devices, detailed information about all devices, or detailed information about a specific device.

Information displayed in this list can include the following:

• The tape device’s physical name.


14-22

• The tape device’s logical device name. Each physical device can support up to 12 logical device names.

• The tape’s state. Valid states are:

- CLOSED

- OPENING

- OPEN

- BUSY

- REWINDING

- UNLOADING

- CLOSING

• Any configured alias for each tape device. If the device has no configured alias, the Alias field contains NA.

• The tape’s attributes. Valid values are:

- Density, either high density (HIGH-DENSITY) or low density (LOW-DENSITY).

- Compression state, either compression is enabled (COMPRESSED) or compression is not enabled. If the tape attributes do not explicitly say COMPRESSED, then compression is not enabled on the tape drive.

- Rewind state, either rewind (REWIND) or do not rewind (NO-REWIND) when the tape is closed.

- Unload state, either unload a tape (UNLOAD) or do not unload (NO-UNLOAD) a tape when it is closed.


14-23

To View the Tape Device List

• Run the following command:tape devlist [-v [DEVNAME]]

Displaying the Operational State of a Tape DeviceWhen you display the operations state of a tape device, the following information is provided. This command displays the following information about a specific tape device:

• Flags, such as rewind state, unload state, density, and so on.

• The current file number on which the tape head is located.

• The current block number on which the tape head is located.

• The tape device’s fixed block size, if the tape device is configured for fixed block size. If the tape device is configured for variable block size, this field displays a zero (0).

• The total space, in bytes, that the tape device supports.

• The amount of available space that remains on the tape device. If this value shows INVALID, the NAS Gateway does not support calculating available space.

• A list of the soft errors on the tape device. If this value shows INVALID, the NAS Gateway does not support soft error detection.

To View a Tape Device’s Operational Parameters

• Run the following command: tape devstate DEVNAME


-v Displays detailed information about all tape devices in the list.

-v DEVNAME Displays detailed information about a specified tape device in the list.


14-24

DEVNAME is the tape device’s name. The DEVNAME string can be a physical device name or a logical device name.

Note - The tape must be open for this command to complete. Otherwise, the NAS Gateway displays an error message indicating that the device is not open.

Closing a Tape DeviceYou can close a tape device to reading and writing, which is helpful if the tape device is stuck in a busy or open state.

To Close the Tape Device

Step 1: Run the following command to determine whether the device is open or closed:tape devlist

Step 2: Run the following command: tape close DEVNAME [-f]

Displaying the Media ChangersWhen the NAS Gateway discovers media changers in the SAN, they are added to the Media Changers List. This list contains the following information about the media changers:

• The media changer’s physical device name

• The media changer’s vendor or manufacturer


DEVNAME Specifies the tape controller that you want to close to read and write operations.

-f An option that forces the tape controller to close. Any client that attempts a subsequent session will get an error message.


14-25

• The media changer’s product or model number

• The media changer’s alias, if an alias is configured

The media changers are listed by their physical or logical device name, and the media changers displayed are listed regardless of their state.

To Display the Media Changer List

• Run the following command:tape mc devlist

Setting an Alias for a Media ChangerYou can assign an alias to media changers to facilitate identification of the device. When you assign an alias, you associate a text string with the media changer’s actual device name.

To Create an Alias for a Media Changer

Step 1: Run the following command to discover the media changer’s device name:tape mc devlist

Note the media changer’s device name. You will use this information in the next step.

Step 2: Run the following command to create the alias for the media changer:tape mc alias set DEVNAME ALIAS [-f]


DEVNAME Specifies the device name of the media changer as known to the NAS Gateway.

ALIAS Specifies the alternate name of the media changer. Use an alphanumeric character atring between 1 and 32 characters.


14-26

Listing Media Changers and Their AliasesMedia changers and their aliases are kept in the Media Changers Alias List. This list contains the following information for media changers that have been aliased:

• The device name

• The alias that has been assigned

To Display the Media Changers Alias List

• Run the following command: tape mc alias show

Removing an Alias from a Media ChangerWhen you remove an alias from a media changer, it is immediately removed, and you can manage the media changer only through the device name or the logical device.

To Remove a Media Changer’s Alias

Step 1: Run the following command to locate the media changer alias:tape mc alias show

Note the name of the alias. You will use it in the next step.

Step 2: Run the following command to delete the alias from the media changer:tape mc alias clear ALIAS

ALIAS is the alias you are removing.

Releasing a Reserved Tape DeviceWhen a tape device is opened, the NAS Gateway posts a SCSI_Reserve lock on the device that provides exclusive access to the device so that no other devices can open

-f An optional argument that allows you to overwrite the existing alias.



14-27

the device. When the device is closed, the SCSI_Release flag is sent to the NAS Gateway to remove the lock and allow the device to be opened.

In some error cases, the SCSI_Reserve flag is not removed even when the device is closed, so the device remains unavailable. The NAS Gateway supports the scsi release command to explicitly remove the SCSI_Reserve flag. ONStor recommends using the scsi release command only after you determine that the device is actually closed. Run the scsi release command from the same NAS Gateway that reserved the tape device.

To Release a Reserved Tape Device

Step 1: Run the following command to determine whether the device is open or closed:tape devlist

Note the physical name of the device you want to release. You will use this information in the next step.

Step 2: Run the following command to display detailed information about the device:tape devlist -v DEVNAME

DEVNAME is the unique name of the tape device you want to release.

Note the WWN and LUN ID of the device. You will use this information in the next step.

Step 3: Run the following command to release the device: scsi release WWN LUN


WWN Specifies the world wide name of the device you want to release.

LUN Specifies the LUN ID of the device you want to release.


14-28

Managing NDMP SessionsBecause NDMP is configured and operates on a per-virtual-server basis, you need to run the commands for configuring and managing NDMP functionality from the context of a virtual server.

Enabling or Disabling NDMP NDMP must be enabled on a virtual server for successful backup and restore operations. When you create a virtual server, NDMP is enabled by default. When NDMP is enabled, the virtual server can respond to NDMP client requests.

To Enable NDMP on a Per-Virtual-Server Basis

• Run the following command: ndmp enable

When you disable NDMP, any in-progress NDMP sessions will complete, but all subsequent sessions will not run.

Note - Use this command with caution. Many DMAs use multiple sessions to perform a backup or restore operation. In some cases, if you run this command while a session is active, you might cause an error that stops the entire operation. For example, if multiple sessions comprise a single backup operation, and you run this command while one session in the operation is active, the entire backup operation can be stopped. ONStor therefore recommends that you verify that all sessions in the virtual server are closed before running the ndmp disable command.

You can verify that all sessions in the current virtual server are closed by running the ndmp show status -v command. If you run this command and no sessions are listed, no sessions are active, and you can safely run the ndmp disable command.

To Disable NDMP on a Virtual Server

Step 1: Run the following command to determine if any sessions are


14-29

active:ndmp show status

• If this command returns an empty list, proceed to the next step.

• If this command returns one or more sessions, wait until the in-progress sessions complete.

Step 2: When no sessions are active, run the following command from within the context of a virtual server to disable the NDMP software on that virtual server:ndmp disable

Setting the DMA TypeSetting a specific DMA may enable workarounds to NDMP protocol conformance issues present in the DMA. Not all DMAs have conformance issues. For details on which versions of these DMAs are supported, contact the ONStor technical support department and request the latest issue of the Compatibility Matrix.

To Set the DMA Type for the NAS Gateway

• Run the following command, and specify the DMA type:ndmp set dma {generic|bakbone|ca|commvault|legato|oracle|tivoli|veritas}

Choose from generic|bakbone|ca|commvault|legato|oracle|tivoli|

veritas to determine the type of DMA that is communicating with the NDMP server:

- generic sets an unspecified DMA. This setting is the default.

- bakbone sets BakBone NetVault.

- ca sets Computer Associates BrightStor.

- commvault sets CommVault Galaxy.

- legato sets Legato NetWorker.


14-30

- oracle sets Oracle.

- tivoli sets Tivoli Storage Manager.

- veritas sets Veritas NetBackup.

Setting the NDMP Protocol Version You can set the NDMP version number to be supported for NDMP services for each virtual server, so different virtual servers can support different versions.

The backup application and the NAS Gateway must be using the same version of NDMP protocol for backup and restore to be successful. When the application connects to the NAS Gateway, the NAS Gateway returns its default version. If both versions match, backup or restore can occur.

Note - For more information about what version of NDMP your backup applications supports, refer to the product documentation that accompanied your backup application.

If a protocol version mismatch occurs between the client and NAS Gateway, automatic negotiation occurs with between the NDMP client and the NAS Gateway to reach agreement on which version of NDMP to use. The NAS Gateway, as the NDMP server, responds to the version requested by the client. Therefore, the client must support either NDMP v3 or v4.

To Set the Active Version of NDMP

• Run the following command:ndmp set version NUM

NUM indicates the version of the NDMP protocol that should be negotiated. By default, v4 is used, but if the client cannot support NDMP v4, the client and NAS Gateway will renegotiate to NDMP v3. However, certain DMAs fail to perform protocol negotiation. If you are using such a DMA, you can use this command may restrict the NDMP server to version 3.


14-31

Note - Use this command only if you are an experienced administrator.

Displaying an NDMP LogYou can display the locally stored NDMP protocol log messages for each NAS Gateway.

To Display the NDMP Log

• Run the following command: ndmp show log [NUMLINES]

NUMLINES is an optional argument that specifies the number of lines that you want to display. The number of lines you specify are counted in most-recent to least-recent order to facilitate seeing the most recent usage events. Enter a 32-bit number for NUMLINES. By default, the entire NDMP log is displayed.

Note - This command is presently supported at the CLI only. It is not supported by the NAS Cluster Manager.

Setting Tape Devices to Alternative Tape ModelsYou can configure each virtual server to use a specified tape model within an NDMP v3 environment. The configured tape model determines the behavior of the tape driver:

• The Veritas tape model causes the tape driver to consume the file mark and position the tape at the end of tape (EOT) side of the file mark. To support Veritas interoperability with NDMP v3, configure this tape model behavior by setting the alternative tape model parameter to “true.”

Note - This configuration is only required for older Veritas NetBackup versions that do not support NDMP version 4.


14-32

• The standard tape model used causes the tape driver to halt at a file mark and position the tape at the beginning of tape (BOT) side of the file mark. To support Veritas interoperability with NDMP v3, configure this tape model behavior by setting the alternative tape model parameter to true. To support Tivoli TSM interoperability, set the alternative tape model parameter to false.

By default, the alternative tape model feature is set to false, which supports interoperability with Tivoli TSM and all versions of Veritas that use NDMP v4. When set to true, the virtual server supports the default tape driver functionality within a negotiated NDMP v3 environment.

Configuring the alternative tape model enables the NAS Gateway to conform to other vendors’ backup implementations. For more information about which version of tape driver model to set, consult the documentation that accompanied your NDMP backup solution. Then, set the NAS Gateway to comply with that implementation.

Note - This command has no effect if the DMA negotiates protocol version 4, which is the default. Use this command only if version 3 is negotiated.

To Set the Tape Driver Version Compatibility on the NAS Gateway

• Run the following command.ndmp set tape altmodel {true|false}

true causes the NAS Gateway to support the alternative model that allows the Veritas tape model to operate in an NDMP v3 environment. false causes the NAS Gateway to support the standard tape model for an NDMP v3 environment.

Setting the Tape Block ModeYou can configure the NAS Gateway to support one of the following tape block modes:

• The default of the tape device

• Fixed block mode


14-33

• Variable block mode

You can also specify the tape block size to be used if fixed block mode is configured. ONStor recommends using variable block mode unless the NDMP client requires fixed block mode. Consult the documentation that accompanied your backup solution to discover which mode is supported. Then, set the NAS Gateway to comply with that mode.

Note - If you are specifying the tape block size, specify a multiple of 512-bytes. Otherwise, you might experience I/O errors.

Setting this parameter can change the tape device’s read and write speed.

A mismatch occurs between the tape block mode configured on the NAS Gateway and the tape block mode configured on the DMA can cause I/O errors.

To Set the Tape Block Mode and Size

• From within the context of a virtual server, run the following command:

ndmp set tape blksize <-1|0|SIZE>


-1 Sets the virtual server to use the default tape block mode and size that are in use on the tape device.

0 Sets the virtual server to support variable block mode.

SIZE Specifies the size, in bytes of a tape block, for the virtual server to support fixed block mode.


14-34

Setting the TCP Port for NDMP ServicesBy default, the NAS Gateway listens for services on TCP port 10,000. However, you can set a different TCP port for NDMP by issuing the ndmp set port command. If you set the port to a different value, you disallow any other functionality supported on that port. For example, if you set the port to 80, the NAS Gateway supports NDMP on that port, but disallow World Wide Web HTTP support, which uses that TCP port by default.

To Set a TCP Port for Supporting NDMP Services

• Run the following command from the virtual server context:ndmp set port PORT

PORT is the TCP port number on which you want to configure NDMP services. By default, port 10,000 is used.

Resetting the NDMP Configuration to DefaultsIf you have configured a virtual server with custom NDMP settings, you can return the NDMP feature to default state. The default NDMP parameters are as follows:

• NDMP state: Enabled

• NDMP version: 4

• TCP port for NDMP services: 10000

• Tape block size: 0 (variable block mode)

• Tape Alternate Model: false

Note - You can view the current state of the NDMP software by running the ndmp show config command.

To Set NDMP Parameters to Their Defaults

• Run the following command from the virtual server context:ndmp reset


14-35

Displaying the NDMP Configurations for Virtual ServersThe NAS Gateway tracks the NDMP parameters configured for each virtual server supporting NDMP functionality. This information is displayed in the NDMP Configuration Table that contains general NDMP configuration and state information, such as:

• Whether the virtual server’s NDMP software is currently enabled or disabled.

• The NDMP version that the virtual server advertises it can support.

• The tape block size. This information is valid for either fixed block or variable block mode.

• Whether the alternative tape model flag is set.

You can view the NDMP configuration for either all virtual servers or for a specific virtual server.

To View the Configuration Information for All Virtual Servers

• Run the following command:ndmp show config

To View the NDMP Configuration Information for a Specific Virtual Server

• Run the following command:ndmp show config [VIRTUALSERVER]

VIRTUALSERVER is the name of the virtual server for which to display the detailed NDMP configuration information.

Displaying Status for NDMP SessionsYou can display information about the status of current NDMP sessions by one of the following types of display options:

• Display information on all active NDMP sessions on all virtual servers within an NAS Gateway.

• Display information on a specified active NDMP session.

• Display information on all active NDMP sessions on a specified virtual server.


14-36

To View Information on All Active NDMP Sessions on All Virtual Servers Within a NAS Gateway

• To view information on all active NDMP sessions on all virtual servers within an NAS Gateway, run the following command from the context of a NAS Gateway:

ndmp show status -a

-a indicates to display all active NDMP sessions on the current NAS Gateway.

To View Information on All Active NDMP Sessions on a Specified Virtual Server

• To view information on all active NDMP sessions on a specified virtual server, run the following command from the virtual server context:

ndmp show status [-v VIRTUALSERVER]

-v VIRTUALSERVER is the virtual server for which you want to display all active NDMP sessions. If you don’t specify the virtual server name with this command, the status of all active NDMP sessions on the current virtual server displays by default.

Displaying Details for NDMP SessionsYou can display detailed information for all NDMP sessions by one of the following types of display options:

• Display details on all active NDMP sessions on all virtual servers within a NAS Gateway.

• Display details on a specified active NDMP session.

• Display details on all active NDMP sessions on a specified virtual server.

To View Details of All Active NDMP Sessions of All Virtual Servers Within a NAS Gateway

• Run the following command from a NAS Gateway context:ndmp show detail -a


14-37

-a indicates to display all active NDMP sessions in detail.

To View Details of All Active NDMP Sessions Within a Particular Virtual Server

• Run the following command from a virtual server context:ndmp show detail [-v VIRTUALSERVER]

-v VIRTUALSERVER is the name of the virtual for which you want to display the detailed NDMP session information. If you don’t specify the virtual server name with this command, the details of all active NDMP sessions on the current virtual server display by default.

To View Details of a Single Active NDMP Session

Step 1: Run the following command to locate the NDMP session and session ID:ndmp show detail -a

-a indicates to display all active NDMP sessions.

Step 2: Run the following command to view detailed information for the session:ndmp show detail -s SESSIONID

SESSIONID is the unique ID assigned to the session.

Deleting NDMP SessionsDeleting NDMP sessions is useful when the TCP/IP session is not closed completely the session deletion forces the TCP/IP session to close completely. Only the current session is deleted. You can delete either all NDMP sessions in a virtual server or a specific NDMP session.

Delete NDMP sessions only if you think the session is hung. You can discover if the session is hung when a backup session fails by:

1. Querying the DMA for active sessions.


14-38

2. If the DMA responds that no sessions are active, check the NAS Gateway by running the ndmp show status -a command.

3. If the NAS Gateway shows a session, run the ndmp show status -s command. Then check for a DMA’s IP address.

4. Check the tape device for an active session. For more information about checking the tape device, consult the documentation that accompanied your tape device or media changer.

To Delete All NDMP Sessions in a Virtual Server

• Run the following command from a virtual server context:ndmp delete session -a

-a indicates to delete all NDMP sessions.

To Delete a Specific NDMP Session

Step 1: From the context of a virtual server, run the following command to locate the NDMP session and session ID:ndmp show detail -a

-a lists all NDMP sessions.

Note the session ID. You will use it in the next step.

Step 2: From the context of a virtual server, delete the NDMP session by running the following command:ndmp delete session -s SESSIONID

SESSIONID is the unique ID assigned to the NDMP session to be deleted.


14-39

Configuring the NAS Gateway for NDMP ServicesTo use NDMP services you need to configure the NAS Gateway to interoperate with one or more DMAs. For a list of supported DMAs, see “Supported Data Management Applications” on page 14-5.

NDMP services are configured on a per-virtual-server basis. Therefore, configure the NDMP backup and restore services in each virtual server that is to use NDMP services. For more information about virtual servers, see “Working with Virtual Servers” on page 3-1.

Typical Task Sequence in Configuring the NAS Gateway for NDMPA typical sequence of tasks when configuring NDMP services might be the following:

1. Configure the NAS Gateway.

• Enable NDMP. See page 14-28.

• Add a local user account. See page 14-18.

• Add a privilege to the user. See page 14-18.

• Ensure that the management volume has been configured. See page 14-40.

• Get the tape drive and media changer name. See page 14-21 and page 14-26.

2. Configure the DMA. See the documentation that came with you data management application.

3. Add a new drive and connect it to a robotic library column. See the documentation that came with your tape drive.

Preconfiguration ConsiderationsMost NDMP applications require some information to set up the application. Obtain the following information before performing the configuration procedure:


14-40

• Device paths. For more information, see “Mapping Device Paths to Physical Devices” on page 14-41.

• The IP address of the virtual server in which you are configuring NDMP functionality. Run the vsvr show command from the virtual server context to view this information.

• The TCP port that will support NDMP services. By default, this is 10,000, but you can set it to a different value with the ndmp set port command.

• The username and password for authentication. This information is configured with the NAS Gateway’s useraccount add command. For more information about this command, see “Adding Local User Accounts for NDMP Services” on page 14-18.

Configuring a Management VolumeFor backup and restore sessions to operate, you need to configure a management volume for each management virtual server that will support backup and restore. See “Understanding Management Volumes and NDMP Sessions” on page 14-12 for more details.

To Configure a Management Volume

Step 1: To display the management virtual server, run the following command from the NAS Gateway context:vsvr show all

Note the name of the management virtual server. You will need it in the following step. Management virtual server names contain the string VS_MGMT_XXXX where xxxx is a series of numbers. For example, VS_MGMT_5343.

Step 2: Switch to the context of the management virtual server by running the vsvr set command. For example, to switch context to the management virtual server VS_MGMT_4353, you would run the command as follows:vsvr set vs_mgmt_4353

The NAS Gateway’s command-line prompt changes to indicate


14-41

that you are in the context of VS_MGMT_4353.

Step 3: Run the system create mgmtVolume command from within the context of the management virtual server to create the management volume. Also specify the array on which to create the management volume. For example, to create the management volume on the array IBM_ECV5TUHB within the management virtual server vs_mgmt_4353, you would run the following command: system create mgmtVolume IBM_ECV5TUHB

This creates the management volume name string. The management volume name string is always vol_mgmt_XXXX where X is the same number string as the management virtual server. For example, if you ran this command within management virtual server VS_MGMT_4353, this command would create the management volume called vol_mgmt_4353.

Note - If you create the management volume with default parameters, you can always configure custom usage and AutoGrow parameters later by running the volume modify command against the management virtual server. You cannot change the management volume’s name through the volume modify command because the management volume name is automatically generated.

interface create fp1.0 -a 10.123.48.101

Step 4: Exit the management virtual server context, and return to the NAS Gateway context by running the vsvr clear command:vsvr clear

Mapping Device Paths to Physical DevicesThe NAS Gateway provides a path ID that you can map to a physical device to determine which path ID is for which physical tape device. You can determine the device path in one of two ways, each of which represents a standard tape device topology:


14-42

• Through a SCSI bridge, for topologies with a SCSI bridge. See “Mapping a Device Path to a Physical Device by Querying a SCSI Bridge”.

• By querying the tape library, for topologies with a direct-attached tape. See “Mapping a Device Path to a Physical Device by Querying a Tape Library” on page 14-43.

Note - Determining the device path is optional for configuring NDMP services on the NAS Gateway. In standard configurations, the tape device is directly connected to the SAN, and mapping device paths is not necessary.

Mapping a Device Path to a Physical Device by Querying a SCSI BridgeWhen you know a device’s path ID, you can map the path to the actual physical drive that owns it. When you map a path to a device, you use the Path ID displayed on the NAS Gateway, relate that value to a LUN, and locate the LUN on the SCSI bridge.

To Map Which Path Equates to Which Drive

Step 1: Obtain the mapping for a tape device by running the tape devlist -v command. Note the device name.

• If the device is in a tape library, proceed to Step 2.

• If not, proceed to Step 3 on page 14-42.

Step 2: If the drive exists within a tape library, obtain the mapping for the library as well by running the tape mc devlist if the tape device is in a media changer. Note the device name. You will use it in the next step.

Step 3: Run the scsi show detail command against the device name you learned from the tape devlist or tape mc devlist command.

Note the values in the WWN and LUN ID field. You will use this information in the next step. The value in the WWN field corresponds to the WWN of the SCSI bridge. The value displayed in the LUN ID is the FC LUN ID, not the SCSI LUN ID.


14-43

Step 4: Access the SCSI bridge. For more information about accessing or using the SCSI bridge, consult the documentation that accompanied the SCSI bridge.

Step 5: On the SCSI bridge, display the WWNs and LUNs and locate the tape device associated with the LUN you learned from the NAS Gateway’s scsi show detail command. With the LUN information, you can map the FC LUN on the NAS Gateway to the SCSI LUN on the SCSI bridge. For more information about using the SCSI bridge, consult the documentation that accompanied the SCSI bridge.

The information from the NAS Gateway and the SCSI bridge is sufficient to determine which path is for which physical device.

Mapping a Device Path to a Physical Device by Querying a Tape LibraryWhen you know a device’s path ID, you can map the path to the actual physical drive that owns it. When you map a path to a device, you use the Path ID displayed on the NAS Gateway, relate that value to a LUN, and locate the LUN on the tape library.

To Map Which Path Equates to Which Drive

Step 1: Obtain the mapping for a tape device by issuing the tape devlist -v command. Note the device name.

• If the device is in a tape library, proceed to Step 2.

• If not, proceed to Step 3 on page 14-43.

Step 2: If the drive exists within a tape library, obtain the mapping for the library as well by issuing the tape mc devlist if the tape device is in a media changer. Note the device name. You will use it in the next step.

Step 3: Issue the scsi show detail command against the device name that you learned from the tape devlist or tape mc devlist command.

Note the values in the WWN and LUN ID field. You will use this information in the next step. The value in the WWN field corresponds to the WWN of the tape library. The value displayed


14-44

in the LUN ID is the FC LUN ID, not the SCSI LUN ID.

Step 4: Access the tape library. For more information about accessing or using the tape library, consult the documentation that accompanied the tape library.

Step 5: On the tape library, display the WWNs and LUNs and locate the tape device associated with the LUN you learned from the NAS Gateway’s scsi show detail command. With the LUN information map the FC LUN on the NAS Gateway to the SCSI LUN on the tape library. For more information about using the tape library, consult the documentation that accompanied the tape library.

The information from the NAS Gateway and the tape library is sufficient to determine which path is for which physical device.

Configuring the NAS Gateway for Interoperability with DMAs for NDMP ServicesNDMP services are configured on a per-virtual-server basis. Therefore, you will need to perform this configuration procedure for each virtual server you want to support NDMP.

Before you begin configuration, ensure that you have fulfilled the following preconfiguration requirements:

• Obtain all information required for configuration, such as an IP address, or TCP port number. See page 14-39.

• Run the ndmp show config command to check whether NDMP is enabled. By default NDMP is enabled. See page 14-28.

• Configure a management volume. See page 14-40.

• Map the device path to the physical device. See page 14-41.

Note - TSM supports only local NDMP backup and restore operations.Veritas supports local and remote backup and restore operations.


14-45

To Configure the NAS Gateway for Interoperability With DMAs

Step 1: From the NAS Gateway context, add a local user account on the NAS Gateway by running the useraccount add command. For more information about adding local user accounts, see “Adding Local User Accounts for NDMP Services” on page 14-18.

Step 2: From the NAS Gateway context, add a privilege for the username you configured for the local user account by running the priv add allow user command. For NDMP functionality, valid scopes are cluster or vsvr (virtual server). The scope cluster is greater than the scope vsvr and therefore includes the scope vsvr. You can also provide various levels of functionality with this command:

• For adding a user with full NDMP administrative privileges, set the user to cluster privilege. The scope cluster includes virtual server scope.

• For security, you might want to allow someone to back up files but not restore them. For this situation, set the user to BACKUP privilege.

• For security, you might want to allow someone to restore files but not do any backup. For this situation, set the user to RESTORE privilege.

For more information about the priv add allow user command, see “Managing Privileges” on page 2-1.

Step 3: Switch to the virtual server on which you want to configure NDMP services by running the vsvr set command. For example, to configure NDMP in the virtual server “pubstest,” you would run the following command:vsvr set pubstest

Note - The remaining NDMP commands will be run in the context of the current virtual server.


14-46

Step 4: As an option, configure the port on which NDMP services will be configured by running the ndmp set port command. For example, to set the TCP port to 10100, you would run the command as follows:ndmp set port 10100

By default, this port is 10,000

Step 5: As an option, you can set the version of NDMP to be supported, by running the ndmp set version command. However, explicitly setting the protocol version is not required because the NDMP client and the NAS Gateway will automatically negotiate for the protocol version of NDMP by first trying NDMP v4, and if that version is not supportable in the configuration, negotiating NDMP v3. For example, to explicitly set the protocol version to NDMP v3, you would run the command as follows:ndmp set version 3

Step 6: As an option, you can activate and set the trace level for NDMP message by running the following command:ndmp set trace {0|1|2}

The default is 0, tracing is deactivated.

You can display the trace level with the ndmp show trace command.

Step 7: Determine the tape device name by running the following command:tape devlist -v

Note the tape device name. You will need this information for configuring the DMA.

Step 8: Determine the media changer device name by running the following command:tape mc devlist

Note the name of the media changer device. You will need this information for configuring the DMA.


14-47

Step 9: As an option, configure the tape model for use in NDMP v3 by running the ndmp set tape altmodel command.

When working with TSM, set the tape model to false as follows:ndmp set tape altmodel false

When working with NetBackup, set the tape model to true as follows:ndmp set tape altmodel true

Step 10: As an option, configure the tape mode and block size by running the ndmp tape set tape blksize command.

With TSM, the NAS Gateway supports only variable block mode.

With NetBackup, the NAS Gateway supports variable and fixed block mode. The NAS Gateway can support fixed block mode only if it is set in multiples of 512 bytes.

Note - Setting this parameter can change the tape device’s read and write speed. Your NDMP sessions will slow down if you set fixed block mode with an invalid size.

For example, to configure the NAS Gateway for variable block mode operation, you would run the command as follows:ndmp set tape blksize 0

Step 11: Repeat Step 3 through Step 10 for each virtual server in which you want NDMP services.

Step 12: On the NDMP client, supply the full device path wherever required. For more information about determining the full device path, see “Mapping Device Paths to Physical Devices” on page 14-41.

Step 13: On the NDMP client, enter the IP address of the virtual server for which you are configuring NDMP wherever required. Enter the IP address that you configured in Step 3 on page 14-41.


14-48

Step 14: On the NDMP client, enter the TCP port on which the NAS Gateway is supporting NDMP services. If you changed the TCP port where NDMP will be supported, enter the port that you configured in Step 4 on page 14-46.

On the NDMP client, supply the username and password for use in authentication. Enter the username and password that you configured in Step 1 on page 14-45.


Chapter 15: Managing Virus Scanning


• “Introducing Virus Scanning” on page 15-2

• “Installing the VirusScan Applet” on page 15-4

• “Unregistering the VirusScan Applet” on page 15-17

• “Configuring the VirusScan Applet” on page 15-18

• “Configuring the CIFS Domain” on page 15-23

• “Prerequisites and System Recommendations” on page 15-27

• “Configuring the Symantec AntiVirus Scan Engine” on page 15-29

• “Configuring the McAfee VirusScan Enterprise 8.0i Software” on page 15-30

• “Managing Virus Scanning From the CLI” on page 15-31


15-2

Introducing Virus ScanningThe ONStor NAS Gateway supports virus scanning with the ONStor VirusScan applet. You can access, configure, and monitor the virus-scanning capability on a per-virtual-server basis from the following access points:

• The command-line interface (CLI)

• The ONStor NAS Cluster Manager browser-based GUI

To use the virus scan feature, you need to add a virus-scan server to your NAS Gateway network topology and configuration. The virus-scan server is connected to your network and communicates with the NAS Gateway through the Gigabit Ethernet ports to provide the virus scanning. The VirusScan applet that is installed on the virus-scan server provides the necessary connectivity between the NAS Gateway and the virus-scan software.

Supporting Third-Party Virus Scanning SolutionsEverON software supports integration with third-party virus-scanning software. The virus-scanning software is installed on the virus-scan server where the VirusScan applet is also installed. You can choose from one of the following virus-scanning packages supported by EverON software:

• Symantec AntiVirus™ Scan Engine 5.0 and earlier

• On-Access Scanner (AOS) of the McAfee® VirusScan Enterprise 8.0i virus scanning software. For details, see the McAfee VirusScan Enterprise, version 8.0i Product Guide.

Note - Although it is possible to install the Symantec AntiVirus Scan Engine and the VirusScan applet on separate servers, we recommend that you keep them on the same machine in your network. The McAfee VirusScan Enterprise 8.0i software always resides on the same server as the VirusScan applet.

Although a virtual server can use multiple VirusScan applets, all applets a virtual server uses must be of the same type, either Symantec or McAfee.


15-3

For a detailed listing of requirements, see “Prerequisites and System Recommendations” on page 15-27.


15-4

Installing the VirusScan AppletThe VirusScan applet handles the communication between the NAS Gateway and the virus-scanning function on the server. An InstallShield guides you through the installation process.

Installation PrerequisitesBefore installing the VirusScan applet, verify the following:

• Verify that your NAS Gateway is installed, powered up, and configured.

• If you are using the Symantec AntiVirus Scan Engine, ensure that it is installed and configured to use ICAP. Refer to the Symantec AntiVirus Scan Engine documentation on how to do this.

• If you are using the McAfee AntiVirus Engine API, ensure that the .DAT files are available to enable the virus-scan engine to run.

• Verify that both the VirusScan applet and the virus-scan engine (if you are using Symantec) are installed on servers configured with a static IP address.

• You are logged in as an administrator or with an account that has administrator privileges for installing the VirusScan applet.

• CIFS domain users must have administrator privileges on the machine where the applet is installed.

Installing the VirusScan Applet for the Symantec AntiVirus Scan EngineTo Install the VirusScan Applet by Using the InstallShield Utility

Step 1: Double-click the setup application icon to launch the installation wizard.


15-5

You can click Cancel at any time to stop the installation. Click Next to continue with the installation.

Step 2: Select Symantec as the applet that you want to install and click Next.

Figure 1 ONStor VirusScan Applet Installation Wizard


15-6

Step 3: The Custom Setup dialog box enables you to customize the default setup of the applet. You can make the following changes:

• Change the directory location where the applet will be installed.

• Select from a dropdown list whether you want to install the basic features or all features of the applet, and when and where you want to install them.

• View the disk space requirements for the installation.

Figure 2 Feature Selection


15-7

Step 4: From the Symantec Virus Scanner dropdown list, select the features you want.

Figure 3 Custom Setup

Figure 4 Custom Setup Feature List


15-8

Step 5: If you want to change the location of the applet, click Change on the Custom Setup dialog box. You can either browse to the directory where you want the applet to install or you can enter the directory path.

Step 6: To view disk space requirements for the installation of the applet, click Space on the Custom Setup menu. Disks that are highlighted on the Disk Space Requirements list do not have enough disk space available for the installation of the applet.

Figure 5 Change Current Destination Folder


15-9

Step 7: When you have completed the custom setup, click Next to continue the installation.

Step 8: On the Ready to Install the Program window, click Install to continue the installation of the applet.

Figure 6 Disk Space Requirements


15-10

Step 9: Click Finish to allow the InstallShield wizard to complete the installation and exit.

Figure 7 Ready to Install the Program

Figure 8 Installation Complete


15-11

Installing the VirusScan Applet for the McAfee AntiVirus Scan Engine APITo Install the VirusScan Applet By Using the InstallShield Utility

Step 1: Double-click the setup application icon to launch the installation wizard.

You can click Cancel at any time to stop the installation. Click Next to continue with the installation.

Step 2: Select McAfee as the applet that you want to install. Click Next.

Figure 9 ONStor VirusScan Applet Installation Wizard


15-12

Step 3: The Custom Setup dialog box enables you to customize the default setup of the applet. You can make the following changes:

• Change the directory location where the applet will be installed.

• Select from a dropdown list whether you want to install the basic features or all features of the applet, and when and where you want to install them.

• Select the disk space for the installation.

Figure 10 Feature Selection


15-13

Step 4: From the McAfee Virus Scanner dropdown list, select the features you want.

Figure 11 Custom Setup

Figure 12 Custom Setup Feature List


15-14

Step 5: If you want to change the location of the applet, click the Change on the Custom Setup dialog box. You can either browse to the directory where you want the applet to install or you can enter the directory path.

Step 6: To select the disk to which to install the applet, click Space on the Custom Setup dialog box. Disks that are highlighted on the Disk Space Requirements list do not have enough disk space available for the installation of the applet.

Figure 13 Change Current Destination Folder


15-15

Step 7: When you have completed the custom setup, click Next to continue the installation.

Step 8: On the Ready to Install the Program window, click Install to continue the installation of the applet.

Figure 14 Disk Space Requirements


15-16

Step 9: Click Finish to allow the InstallShield wizard to complete the installation and exit.

Figure 15 Ready to Install the Program

Figure 16 Installation Complete


15-17

Unregistering the VirusScan AppletYou may need to update or remove the VirusScan applet from your machine. The applet must be unregistered before updating and reinstalling the ONStor virus scan application.

To Unregister the VirusScan Applet

Step 1: To unregister or remove the VirusScan applet, run the following command on the virus scan server from within the VirusScan applet directory:OnStorVirusScanApplet.exe -unregister

Step 2: To unregister or remove the port map service, run the following command on the virus scan server from within the VirusScan applet directory:portmap -unregister


15-18

Configuring the VirusScan AppletAfter the InstallShield has installed the VirusScan applet in either the default directory or one that you specified, configure the applet and register the port map service and applet service. The default directory for the installation is applet_installation_directory. The directory contains the VirusScan applet executable and its associated files as described in Table 15-12.

Table 15-12: Contents of the VirusScan Applet Directory

File Description

Common files needed for either one, Symantec or McAfee installation

ONStorVirusScanApplet.exe Application.

VScanEngine.dll ONStor dll.

oncrpc.dll ONC/SUN RPC dll for Windows.

PortMap.exe RPC port mapping utility—Window Service application.

msvcr70d.dll Used by portmap.exe. Some machines might need that library.

Files needed for Symantec installation only

symcsapi.dll Symantec dll.

ONStorVirusScanApplet.config Configuration file for entering the Symantec scan engine IP and ICAP port for the VirusScan applet.

Files needed for McAfee installation only

ONStorVirusScanApplet.config Configuration file for entering the McAfee scan engine API path for the VirusScan applet.

Enginepath="" Location of the virus definition files for the McAfee AntiVirus Engine API.

ONStorMcUpdate.bat Batch file used for an autoupdate.

DoMcafeeAutoupdate.vbs File used for an autoupdate.


15-19

Configuring the VirusScan Applet for the Symantec AntiVirus Scan EngineThe VirusScan applet file is an XML file that enables you to specify the Symantec AntiVirus Scan Engine IP address and ICAP port number for the applet to use. If no alternate configuration file is available, the applet uses the Symantec AntiVirus Scan Engine on the designated default machine, 127.0.0.1, and it uses the default ICAP port, 1344. The following example shows the applet with the default IP and ICAP port specified:

Note - If you do not use the default port for ICAP, you need to specify the port number in the applet configuration file.

<ONStorVirusScanApplet>

<LogFile mode="disable" name="VScanApplet.log" /><Resource MaxNumberofParallelFileScanning="100" />

<ScanEngine>

<Symantec™>

<Engine IP="127.0.0.1" Port="1344" />

</Symantec>

</ScanEngine>

</ONStorVirusScanApplet>

• You can specify for the virus-scan application to write a virus-scan log to a log file in the same directory in which the applet is installed. The applet shown previously includes a log-file entry that is disabled.

- If you specify the log file mode by replacing “disable” in the shown code with “enable”, the applet creates a log file or writes to the existing log file either in the current directory or in a path you provide within the applet.

- If the log file mode is specified to be “disable”, the applet sends output to the console only.


15-20

Note - Enabling the log file mode is not recommended because it slows down the virus-scanning performance. Even when the applet log file mode is disabled, the applet will log errors and some warnings to the Windows Event Log.

If the current log file reaches the maximum size of 5MB, the file is automatically renamed (for example, from applet.log to an older version log file, such as applet.log.old). If an older version already exists, the newer version overwrites the older version, and new incoming messages are written to the active log file.

• You can configure the applet to scan a number of files concurrently. The MaxNumberOfParallelScanning parameter in the configuration file specifies the maximum number of files the applet can scan concurrently. The default is 100.

Note - Parallel scanning affects memory usage. Depending on the memory available, if you set the value for parallel scanning too high, your network operations might take a longer time or the entire network might fail.

• If you want the applet to use more than one virus-scan engine, add the IP addresses for each into the configuration file so the client library can automatically load balance over the virus-scan engines. The following example shows an applet using two Symantec AntiVirus Scan Engines, 10.2.14.150 and 10.2.14.151. Both use the default port, 1344.


<LogFile mode="enable" name="VScanApplet.log" /><Resource MaxNumberofParallelFileScanning="100" />

<ScanEngine>

<Symantec>

<Engine IP="10.2.14.150" Port="1344" />

<Engine IP="10.2.14.151" Port="1344" />

</Symantec>

</ScanEngine>


15-21


Configuring the VirusScan Applet for the McAfee AntiVirus Engine APIThe VirusScan applet file is an XML file that enables you to specify the McAfee definition file location. The following example shows the applet with the default file location specified:


<LogFile mode="disable" name="VScanApplet.log" /><Resource MaxNumberofParallelFileScanning="100" />

<ScanEngine>

<McAfee>

<Engine DatPath="" Enginepath="" />

</McAfee>

</ScanEngine>


• You can specify for the virus-scan application to write a virus-scan log to a log file in the same directory in which the applet is installed. The applet shown previously includes a log-file entry that is disabled.

- If you specify the log file mode by replacing “disable” in the shown code with “enable”, the applet creates a log file or writes to the existing log file either in the current directory or in a path you provide within the applet.

- If the log file mode is specified to be “disable”, the applet sends output to the console only.

Note - Enabling the log file mode is not recommended because it slows down the virus-scanning performance. Even when the applet log file mode is disabled, the applet will log errors and some warnings to the Windows Event Log.


15-22

If the current log file reaches the maximum size of 5MB, the file is automatically renamed (for example, from applet.log to an older version log file, such as applet.log.old). If an older version already exists, the newer version overwrites the older version, and new incoming messages are written to the active log file.

• You can configure the applet to scan a number of files concurrently. The MaxNumberOfParallelScanning parameter in the configuration file specifies the maximum number of files the applet can scan concurrently. The default is 100.

Note - Parallel scanning affects memory usage. Depending on the memory available, if you set the value for parallel scanning too high, your network operations might take a longer time or the entire network might fail.

• The DatPath and EnginePath parameters contain the path to the location of the DAT files and the engine DLLs. By default the values of these parameters are set to empty string (“ ”) to enable the applet to use the DAT files and engine DLLs from the McAfee VirusScan Enterprise 8.0i package. You can however use these parameters to specify a different location for downloading the required files.

Updating McAfee .DAT filesThe ONStor VirusScan applet depends on information in the virus definition (.DAT) files to identify viruses. Without updated .DAT files, the virus scan software might not detect new virus strains or respond to them effectively. McAfee releases new .DAT files every week and occasionally a new version of the virus scan engine, and makes them available for updating.

You can schedule automatic updates of the .DAT files at regular intervals. For details, see the McAfee VirusScan Enterprise, version 8.0i Product Guide.


15-23

Configuring the CIFS DomainIn the Windows Settings, ensure that the designated domain (CIFS) user for virus scan operations is configured as an administrator. See your Windows documentation for more information on how to set up the domain user as an administrator.

Step 1: Verify that the domain user has “Log on as a service” privileges granted in the local setting. To check this, use the Windows path Start>Control Panel>Administrative Tools>Local Security Policy>Local Policies>User Rights Assignments>Log on as a service. Clicking along this path invokes the “Local Security Policy Setting” as shown in Figure 17.

Step 2: Make sure that the checkbox for the user is marked to set the “Log on as service” privileges for this user on Local Policy Setting. If the designated virus scan administrator is not listed in the dialog box that displays, click Add. Clicking Add invokes the “Security Policy—Select Users or Groups” as shown in Figure 18 on page 15-24.

Figure 17 Local Security Policy Setting


15-24

Step 3: Find and click the proper user in the scroll list or type the user name in the space provided.

Step 4: Click OK when done. Make sure that the checkbox for the user for Local Policy Setting is marked to set the “Log on as service” privileges for this user. For more information, see your Windows documentation.

Step 5: Within the context of the directory where the VirusScan applet files are located, use the DOS Prompt utility to install and register the re-implemented ONC/SUN RPC port map service by running the following command:portmap -register

This step registers the port mapping as a Windows Service (logon as local system account) and starts the port map service automatically.

Figure 18 Security Policy—Select Users or Groups


15-25

Step 6: Within the context of the directory where the VirusScan applet files are located, use the DOS Prompt utility to register and start the VirusScan applet as a Windows service by running the following command:OnStorVirusScanApplet.exe -register DOMAIN USER

where:

• DOMAIN specifies the domain name.

• USER specifies your user name.

This command starts the VirusScan applet as a Windows service automatically (logon as domainName\userName account).

Step 7: Check the service status for each of the preceding Windows services in the Windows Service file. The registered service names should be “ONStorRPCPortmapper” and “OnStorVirusScanApplet”.

The two registered ONStor Windows service names should appear as shown enclosed within the box in Figure 19.

Figure 19 Windows Service Folder Showing ONStor Windows Services


15-26

Receiving Virus Notification on CIFS ClientsTo receive virus notifications on CIFS clients, the Windows Messenger Service must be enabled on the client machines. To verify this, use the following path:

Control Panel>Administrative Tools>Services>Windows Messenger Service

Verify that the Windows Messenger Service is started and that its startup is automatic, which typically is no problem because Windows Messenger Service is usually enabled by default.

Note - Ensure that the CIFS client is on the same subnet as the NAS Gateway and that WINS is configured. Otherwise, virus notification messages might not transmit.


15-27

Prerequisites and System RecommendationsThe following sections detail the operating and hardware system recommendations for the Symantec AntiVirus Scan Engine 5.0 or earlier, the McAfee VirusScan Enterprise 8.0i software, and the VirusScan applet.

Virus-Scan Server Recommendations for the Symantec AntiVirus Scan EngineThe following are the operating system and hardware recommendations for running the Symantec AntiVirus Scan Engine 5.0 or earlier:

• Microsoft® Windows Server 2000 or Advanced Server with Service Pack 2 or later

• 500 MHz Pentium III

• 256 MB RAM

• 25 MB hard disk space available

• 1 NIC running TCP/IP with a static IP address

• Web-based administration requires Microsoft Internet Explorer 6.0 with Service Pack 1 or later

• Live update of virus definitions requires an Internet connection

Virus-Scan Server Recommendations for the McAfee VirusScan Enterprise 8.0i SoftwareSee the documentation that accompanied your McAfee VirusScan Enterprise 8.0i software package for details on system requirements.

Virus-Scan Server Recommendations for the VirusScan AppletFollow these considerations for running the VirusScan applet:

• For running the VirusScan applet, we recommend the Windows 2000, with Service Pack 2, or a later operating system.


15-28

• If you are running the VirusScan applet on the same server as the McAfee VirusScan Enterprise 9.0i software, 15 MB hard disk space is required for the installation of the applet and one network interface card (NIC) running TCP/IP with a static IP address.

• The ONStor VirusScan applet needs to access files in read/write mode in the virtual server. Therefore the user account that launches the applet must be configured with the BACKUP and RESTRORE privilege. The scope of the privilege can be either VIRTUAL SERVER or CLUSTER. To enable virus scanning, configure the privilege before starting the ONStor VirusScan applet, or restart the applet after you configure the privilege. Use the priv add command to configure privileges for the user account. For more information about this command, see “Managing Privileges” on page 2-1.


15-29

Configuring the Symantec AntiVirus Scan EngineTo the VirusScan applet, the Symantec AntiVirus Scan Engine is an out-of-process scan engine. The applet uses the Symantec scan engine’s client API library. Virus-scanning operations can have the following results from the Symantec AntiVirus Scan Engine viewpoint:

• File is clean (read and write operations can proceed).

• File was infected and deleted.


• Insufficient server resources.

• Access denied.

• License expired.

• Internal error.

You need to configure the Symantec AntiVirus Scan Engine to use Internet Content Adaptation Protocol (ICAP), a request/response-based protocol, to communicate with the clients (ICAP version 1.0—RFC 3507, April 2003). Refer to the Symantec AntiVirus Scan Engine documentation for instructions on how to do this.


15-30

Configuring the McAfee VirusScan Enterprise 8.0i SoftwareThe VirusScan applet uses the McAfee AntiVirus Engine API of the McAfee VirusScan Enterprise 8.0i package as an in-process scan engine. The applet links the scan engine DLLs and accesses the scan engine directly in the same process.

Virus-scanning operations can have the following results from the McAfee Anti-Virus Engine API viewpoint:

• File is clean (read and write operations can proceed).



• Insufficient server resources.

• Access denied.

• License expired.

• Internal error.

Refer to the documentation that accompanied your McAfee VirusScan Enterprise 8.0i package for details on how to configure the software package.


15-31

Managing Virus Scanning From the CLIManaging virus scanning from the CLI can involve the following tasks:

• Adding a virus scan server

• Deleting a virus scan server

• Showing the virtual server virus scan server configuration

• Listing virus scan statistics

• Displaying the virus scan log

• Clearing the virus scan log

• Enabling virus scanning for incoming traffic

• Disabling virus scanning for incoming traffic

• Enabling virus scanning for outgoing traffic

• Disabling virus scanning for outgoing traffic

• Listing the file extensions that should be scanned

• Adding file extensions for scanning

• Removing file extensions from scanning

• Replacing the list of file extensions to be scanned

Adding or Deleting a Virus Scan ServerThe virtual server can be in enabled or disabled state when you add or delete a virus scan server. You can add or delete virus scan servers one at a time. For details on how to configure a virtual server, see “Working with Virtual Servers” on page 3-1.

Have the IP addresses of available virus scan servers ready for entering into the appropriate commands.


15-32

Note - Have your third-party equipment with the virus scanning engine set up, powered on, connected, installed, and configured before you add a virus scan server.

Have your VirusScan applet installed and properly configured on the server running the virus scanning engine such that it communicates with the virus scanning engine.

To Add a Virus Scan Server to the List of Available Virus Scan Servers for Your Virtual Server

Step 1: In the virtual-server context, run the vscan server show command to see if any virus scan servers have been added to the virtual server and to see what the configurations are.

Step 2: To add a virus scan server (the virtual server can be in enabled or disabled state), run the following command:vscan server add IPADDR

IPADDR is the IP address of the selected virus scan server.

Before deleting the last virus scan server from a virtual server, disable virus scanning on that virtual server.

To Delete a Virus Scan Server

• To delete a virus scan server, run the following command from a virtual server context:

vscan server delete IPADDR

IPADDR is the IP address of the selected virus scan server.

Displaying the Virtual Server Virus Scan Server ConfigurationThe virtual server virus scan configuration status information display includes:

• Delete infected files (yes or no, default is no)

• Quarantine infected files (yes or no, default is no)


15-33

• Incoming CIFS (disabled or enabled, default is disabled)

• Outgoing CIFS (disabled or enabled, default is disabled)

• Allow access to CIFS clients if scan fails (yes or no, default is no)

• Incoming NFS (disabled or enabled, default is disabled)

• Outgoing NFS (disabled or enabled, default is disabled)

• Allow access to NFS clients if scan fails (yes or no, default is no)

• The virus scan servers (IP address or multiple IP addresses of assigned virus scan servers)

To Display the Configuration of a Virtual Server’s Virus Scan

• Run the following command:vscan server show

Displaying the Virus Scan LogOne log exists for all virtual servers, but after the date-time stamp, the records are prefixed with the virtual-server name ID for filtering.

The log’s display includes the following:

• Events logged with most recent event at top, in chronological order:

- month, day, time (hh:mm:ss)

- NAS Gateway name ID

- scanner (Symantec AntiVirus Scan Engine or McAfee AntiVirus Engine API)

- status of the scanner

- applet restarts

- file names of infected files and action taken

- communication errors between the NAS Gateway and applet

You do not need to be in virtual-server context to use this command.


15-34

To List the Virus Log

• Run the following command:vscan log show [NUMLINES]

NUMLINES is the number of lines from the end to be displayed.

Clearing the Virus Scan LogOne log exists for all virtual servers but after the date-time stamp, the records are prefixed with the virtual-server ID for filtering. You can clear the log of all records from the CLI by running the vscan log clear command from the virtual server context.

To Clear the Virus Log

• Run the following command:vscan log clear

Configuring Virus-Scanning Activity with the Virus-Scan LogVirus-scanning activity is logged, and you can configure some virus-scanning activities with the log from the NAS Cluster Manager. One log exists for all virtual servers, but after the date-time stamp, the records are prefixed with the virtual-server name ID for filtering. Configuring virus-scanning activities with the virus-scan log can only be done from the CLI. You can configure and display the following:

• Specify the syslog host for sending virus scan log messages using the vscan log host command.

• Specify the facility code to be used by the virus scan log using the vscan log facility command.

• Display the current virus scan log configuration using the vscan log show config command.

To View the Current Virus Scan Log Configuration

• Run the following command:vscan log show config


15-35

This command displays the current virus scan log configuration that applies to the virus scan log.

Note - If the virus scan log is on a remote host, this command does not display any virus scan log messages. You can specify the virus scan log to be located on a remote host by the vscan log host command. See the next section for details.

Specifying the syslogd Host for Sending Virus Scan Log MessagesThe virus scan log facility interfaces with the standard syslogd capability.

To Specify the Syslogd Host for Sending Virus Scan Log Messages

• Run the following command:vscan log host IPADDR

IPADDR specifies the IP address of a remote host that runs syslogd and can receive virus scan log messages from this NAS Gateway.

Specifying the Facility Code to Be Used by the Virus Scan LogThe virus scan log facility interfaces with the standard syslogd capability.

To Specify the Facility Code to be Used By the Virus Scan Log

• Run the following command:vscan log facility {local0 | local1 | local2 | local3 | local4 | local5 | local6 | local7}

The default facility code is local0.


15-36

Enabling or Disabling Virus Scanning for Incoming Traffic To Enable or Disable Virus Scanning on a Virtual Server for Incoming Traffic


Step 2: To enable virus scanning for incoming traffic, run the following command:vscan enable incoming PROTOCOL [,PROTOCOLS]

PROTOCOL is a protocol, which can be either CIFS or NFS. Case is ignored. Multiple protocols are separated by commas.

Step 3: To disable virus scanning for incoming traffic, run the following command:vscan disable incoming PROTOCOL [,PROTOCOLS]


Step 4: You are prompted to confirm disabling virus scanning of incoming traffic. Enter “y” to confirm the action, or “n” to continue virus scanning of incoming traffic.

Enabling or Disabling Virus Scanning for Outgoing Traffic Displays the list of virus scan servers configured for the virtual server and current configuration settings.

To Enable or Disable Virus Scanning on a Virtual Server for Outgoing Traffic


Step 2: To enable virus scanning for outgoing traffic, run the following command:


15-37

vscan enable outgoing PROTOCOL [,PROTOCOL][-scanfailureok]

Step 3: To disable virus scanning for outgoing traffic, run the following command:vscan disable outgoing PROTOCOL [,PROTOCOL]


Step 4: You are prompted to confirm disabling virus scanning of outgoing traffic. Enter “y” to confirm the action, or “n” to continue virus scanning of outgoing traffic.

Listing the File Extensions that Should Be ScannedThe NAS Gateway accesses a list of common extensions that have been known to contain malicious code. This default list is used to determine which files are scanned for viruses.

To List the File Extensions That Should Be Scanned

• Run the following command from a virtual server context:vscan extension show

The following default extensions are scanned by the NAS Gateway virus scan application:.


PROTOCOL Specifies either the CIFS or NFS protocol. Case is ignored. Multiple protocols are separated by commas.

-scanfailureok An optional parameter to allow the read to proceed if a virus scan cannot be completed. By default, if virus scanning cannot be completed, the scan fails and the file transfer does not occur.

386 CPL HTM MSO PPT VSD


15-38

Adding or Deleting File Extensions For ScanningA default list of extensions exists, but you can add or delete extensions on your NAS Gateway virus-scan configuration extension list.

To Add or Delete File Extensions

Step 1: In the virtual server context, run the vscan extension show command to display what extensions are currently enabled for scanning.

Step 2: To add a file extension, run the following command:vscan extension add EXTENSION [,EXTENSION]

EXTENSION is any alphanumeric string between 1 and 4 characters. It can also include a “.” that matches any single character. Case is ignored. Choose an extension from the default list below, or if you have a specific extension not mentioned in the following list, specify it in this command with this string. Multiple extensions are separated by commas.

Step 3: To delete a file extension, run the following command:vscan extension delete EXTENSION [,EXTENSION]

EXTENSION is an alphanumeric string between 1 and 4

ACM CSC HTML OBD RTF VSS

ACV CSH HTT OBT SCR VST

ADT DLL INF OCX SH VXD

AX DOC INI OV. SHB WSF

BAT DOT JS PIF SHS WSH

BIN DRV JSE PL SMM XL

BTM EXE JTD PM SYS

CLA HLP MDB POT VBE

COM HTA MP. PPS VBS


15-39

characters. Only an exact match with an existing scanned extension is removed. It can also include a “.” that matches any single character. Case is ignored. Multiple extensions are separated by commas.

Replacing the List of File Extensions to be Scanned Sets the list of extensions as the virus scan extensions.

To Replace the List of File Extensions That Should Be Scanned

Step 1: In the virtual-server context, run the vscan extension show command to display what extensions are currently enabled for scanning.

Step 2: Run the following command:vscan extension set EXTENSION [,EXTENSION]

EXTENSION is any alphanumeric string between 1 and 4 characters. It can also include a “.” that matches any single character. Case is ignored. Multiple extensions are separated by commas.

Resetting the List of File Extensions to the System DefaultEverON software supports the following default file extensions that can be scanned:

386 CPL HTM MSO PPT VSD

ACM CSC HTML OBD RTF VSS

ACV CSH HTT OBT SCR VST

ADT DLL INF OCX SH VXD

AX DOC INI OV. SHB WSF

BAT DOT JS PIF SHS WSH

BIN DRV JSE PL SMM XL

BTM EXE JTD PM SYS


15-40

To Reset a Customized List of File Extensions to the Default List

Step 1: In the virtual-server context, run the vscan extension show command to display what extensions are currently enabled for scanning.

Step 2: Run the following command:vscan extension reset

CLA HLP MDB POT VBE

COM HTA MP. PPS VBS


Chapter 16: Managing NAS Gateway System Settings


• “Introducing NAS Gateway System Management” on page 16-2

• “Displaying IP Statistics” on page 16-17

• “Displaying File Processing Port Load Statistics” on page 16-18

• “Managing NAS Gateway System Health” on page 16-19

• “Working with the Read Ahead Cache” on page 16-32

• “Working with Core Dumps” on page 16-34


16-2

Introducing NAS Gateway System Management

Displaying System Software VersionDisplays a version string that identifies the system software that is currently installed on the NAS Gateway.

To View the Current System Software Version

• Run the following command:system version [-s]

-s displays the software version running on the standby CompactFlash card.

Displaying Specific Software VersionsDisplays version information about the hardware and software that is operating on the NAS Gateway. The version information includes software revisions for each module and version numbers of major hardware components.

To View Details of the Current System Software Version

• Run the following command: system show version

Displaying NAS Gateway System InformationDisplays summary information about the NAS Gateway, such as NAS Gateway name, current date & time, timezone, system uptime, system temperature, active flash software version, chassis information, NTP configuration, sc1 & sc2 IP addresses, and the total number of virtual servers.

To View Detailed System Information About the Current NAS Gateway

• Run the following command:system show summary

This command displays the following details:

• NAS Gateway name


16-3

• NAS Gateway date, time, time zone, and system uptime

• NAS Gateway temperature

• NAS Gateway software version

• NAS Gateway chassis information

• NTP servers configured for this NAS Gateway

• sc1 and sc2 IP addresses

• Number of virtual servers assigned to this NAS Gateway

Displaying the System TimeShows the current time and how long the system has been running.

To Display the Current System Time and How Long the System Has Been Running

• Run the following command:system show uptime

Displaying the Chassis TemperatureThe NAS Gateway displays the last gathered temperature reading in number of degrees centigrade (ºC). The formula for converting ºC to ºF is [(ºC * 1.8) + 32]. If the temperature sensor is not able to read the temperature, the NAS Gateway displays a zero (0).

To Display the Chassis Temperature

• Run the following command: system show temperature

Displaying the NAS Gateway’s Node NameThe NAS Gateway’s node name is a unique name that is assigned as part of the startup script. The node name enables NAS Gateway’s to interact with each other as unique entities.


16-4

To Display the NAS Gateway’s Node Name

• Run the following command: system show nodename

Displaying the Chassis ConfigurationDisplays information about the hardware that is installed in the NAS Gateway. Information displayed includes:

- Which module is installed in each slot

- The number of modules installed in the NAS Gateway

- The number and state of the CPUs on each module

To View the Chassis Configuration

• Run the following command: system show chassis

Halting the NAS GatewayUse the system halt command to stop all active internal processes on the NAS Gateway without having to power cycle the system or initiate a restart. When you halt the system, you can expect the following occurrences:

• All user transactions stop.

• All internal processes halt, with the exception of a few management functions.

• The system remains online, but inactive.

• The system remains powered on.

• The configuration file does not change.

To reactivate the NAS Gateway, you need to power cycle or restart.

To Stop the NAS Gateway

• Run the following command: system halt


16-5

Pinging Another Device from the NAS GatewayThe NAS Gateway supports ping functionality to an IP address or host name.

To Send a Ping

• Run the following command: system ping {HOSTNAME|IPADDR} [-n COUNT]

Performing Traceroute to an IP AddressThe NAS Gateway supports traceroute functionality to an IP address or host name.

To Perform a Traceroute From the NAS Gateway

• Run the following command: system traceroute {HOSTNAME|IPADDR}

HOSTNAME is the name of the host or gateway you are tracing. If you are tracing the route to a hostname or gateway name, the name must be resolvable through DNS or NIS.

IPADDR is the IP address of the node to which you are performing a traceroute.

Working with System TimeThe NAS Gateway keeps accurate system time for time stamping of many features such as event log (elog) and autosupport, and operations such as uptime and file system creation time. System time is maintained through one of two sources:


HOSTNAME Specifies the host name of the device you are pinging. If you are pinging to a host name or gateway name, the name needs to be a DNS of NIS resolvable name.

IPADDR Specifies the IP address of the node that you are pinging.

-n COUNT Specifies the number of responses to display.


16-6

• An NTP server. The NAS Gateway uses an NTP v4 implementation.

• The real-time clock chip on the SSC.

Note - To avoid discrepancies, always run the system time set command on all NAS Gateways in the cluster, and run this command before configuring the NTP server.

Change in Daylight Saving Time (DST)ONStor’s product release has been modified to reflect the latest available timezone information for all zones. The US Congress mandated that there should be a change to the Daylight Saving Time (DST) start and end days from 2007.

Note - ONStor recommends that an upgrade of a cluster be started with plenty of time to complete the update on all filers in a cluster before DST starts. Otherwise, until all filers are updated to the same version, it is possible that some show different times during DST.

Setting System TimeAlways set the system time on all NAS Gateways in a cluster.

To Set the System Time

• Run the following command: system time set [[[[[[cc]yy]mm]dd]HH]MM[.SS]]


cc Specifies two digits of the current millennium.

yy Specifies two digits for the current year.

mm Specifies two digits for the current month.


16-7

Synchronizing System Time with an NTP Master Time ServerThe NAS Gateway listens for NTP time signals on TCP port 123.

To Synchronize the NAS Gateway With an NTP Master Server

• Run the following command:system time ntp server -a|-d IPADDR

-a|-d indicates that you are adding a server to the server list(-a) or deleting a server from the list. (-d).

IPADDR is the IP address of an NTP server.

Disabling the NAS Gateway from Synchronizing with NTP Servers

Note - If NTP was active on the NAS Gateway, then you disable NTP, the NAS Gateway must be rebooted in order for it to begin re-synchronization with a specific server or a broadcasted time signal on TCP port 123.

To Disable Listening for NTP Broadcasts

• Run the following command: system time ntp disable

dd Specifies two digits for the current date.

HH Specifies two digits for the current hour, in 24-hour time.

MM Specifies two digits for the current minutes.

.SS Specifies two digits for the current seconds. Separate minutes (MM) and seconds (.SS) with a period.



16-8

Setting the NAS Gateway’s Time ZoneYou can program the NAS Gateway’s realtime clock automatically with time from a NTP server. Because NTP uses GMT, the NAS Gateway uses the local time zone and converts it to GMT.

To Set the NAS Gateway’s Time Zone

Step 1: Run the following command to display the current time zone programmed into the NAS Gateway:system time zone

• If the time zone displayed is correct, no further configuration is required.

• If the time zone displayed is incorrect, proceed with the next steps.

Step 2: Run the following command to display all the current time zones available to the NAS Gateway:system time zone -l

-l lists all the supported time zones by geographical region. Pick the time zone that is closest to your location. Make sure you note the time zone exactly as it is displayed. You will need to enter the time zone string exactly as it is displayed.

Step 3: Run the following command to program in the time zone you found from the time zone list:system time zone TIMEZONE

TIMEZONE is the time zone string that you have noted from the time zone list displayed in the previous step.

Displaying the Current System TimeThis command displays the NAS Gateway's day of the week, month and date, time zone, and year.


16-9

To Display the Current System Time

• Run the following command: system time show [-v]

-v is an optional argument that indicates verbose mode for NAS Gateways that receive their time information from an NTP server. Verbose mode shows not only the system time, but also information about the NTP server, stratum, the amount of time lost as time signals traverse servers and stratum, and so on. If you do not use the -v argument, the currently programmed system date and time are displayed.

Displaying Load Average for CPUs in the Main Data PathThe NAS Gateway enables you to see the amount of load that each CPU in the main data path by running the stats show ldavg command. The main data path is the series of hardware components that are involved with processing file service I/O to or from CIFS or NFS clients. The stats show ldavg command tracks information for the amount of load on each of the following processors, and is useful for determining which CPUs are more busy or less busy for any given user load:

• The NCPU, which processes transport traffic

• The ACPU, which processes the bulk of the CIFS and NFS traffic

• The FP1 and FP2 CPUs, which processes the file system traffic

• The FC CPU, which processes the SCSI traffic

Note - The SSC is not in the main data path, so the load on SSC CPUs is not displayed.

For these processors, the load average displays a value between zero (0) and one (1) that indicates how loaded each processor is. Zero indicates that the processors has no load; one indicates that the processor is at full load; and a decimal value between 0 and 1 indicates the percentage of load on the processors. The stats show ldavg command


16-10

gathers the processor loads by using a polling model. Each polling interval is approximately 1 to 2 seconds long.

To Display the Load Average for CPUs in the Main Data Path

• Run the following command: stats show ldavg

Working With an Event Log (elog)Elog provides messages about system activity of various levels. Elog messages are prioritized with the same priority levels used by the standard UNIX syslog program. You can display elog messages on the console or forward them to an elog host.

Setting Elog Message LevelsYou can set specific elog levels to have the NAS Gateway report system events to either the console or to a remote elog host.

The following list shows elog messages in least-severe to most-severe order:

• Debug

• Info

• Notice (this is the default level)

• Warning

• Error

• Critical

• Alert

• Emergency

To Set the Elog Level

• Run the following command: elog level {debug|info|notice|warning|error|critical|alert|emergency}

• debug|info|notice|warning|error|critical|alert|em


16-11

ergency is the minimum level of elog message that you want the NAS Gateway to report. Select only one value and that value plus all values of greater severity will be reported. The default level is warning.

Enabling or Disabling Elog Messaging SoftwareThis command is used to enable or disable the elog state. When the elog state is disabled, no elog messages are forwarded to the syslog daemon. By default elog state is enabled.

To Enable or Disable the Elog Messaging Software

• Run the following command: elog state {enable|disable}

Setting the Elog Local Facility LevelThe elog facility interfaces with the standard syslogd capability to provide logging of important system information at the desired level of priority. By using this facility, system messages can be saved locally, forwarded to a remote host, and displayed on the system console.

To Set the Elog Local Facility Level

• Run the following command: elog facility {local0|local1|local2|local3|local4|local5|local6|local7}

• local0|local1|local2|local3|local4|local5|local6|

local7 is a list of choices that set the local facility level for the elog message coming from a specific NAS Gateway to an elog host.

Specifying the Elog HostThe elog host is the system that is running Syslog functionality to receive elog messages. Elog messages can be forwarded to Syslog daemons running on the specified elog host. The address you specify determines whether elog messages are forwarded to a remote host or the local host:


16-12

• If the host address is set to 0 all elog messages are forwarded to the local syslog daemon and eventually stored in /usr/local/agile/log/messages.

• If a non-zero syslog host is specified all messages are forwarded to the specified host using the currently configured facility code.

Note - If you set the Syslog host to a valid IP address, make sure that the remote syslog host is configured to receive syslog messages from other hosts.

To Specify the Elog Host

• Run the following command: elog host IPADDR

IPADDR is the address of the network-attached host that will receive elog messages.

Displaying the Elog Message LogThis command displays the locally stored elog messages.

To Display the Elog Message Log

• Run the following command: elog show log [NUMLINES]

NUMLINES is an optional numerical value that causes the NAS Gateway to display the number of lines that is specified. The number of lines is displayed descending from the most recent message.

Searching the Elog Message LogBecause the event log message log can support numerous messages, the NAS Gateway supports a basic keyword search engine for locating text strings within the event log message log.


16-13

To Perform a Keyword Search Through the Elog Message Log

• Run the following command: elog find KEYWORD

KEYWORD is a character string from 1 to 32 characters in length that you want to find in the elog message log. The NAS Gateway will attempt to exactly match the character string you enter with a character string in the elog message log.

Clearing the Elog Message LogThe elog clear log command deletes all entries in the event log. When you run this command, the event log is immediately cleared, and it can begin accepting messages whenever new system events occur.

To Delete the Elog Message Log

• Run the following command: elog clear log

Displaying Elog System SettingsYou can display the following elog configuration information:

• The state of elog software, either enabled or disabled.

• The configured elog message level. All messages equal to or greater than the configured severity are displayed.

• The currently configured elog level for reported messages.

• The currently configured elog facility

• The currently configured elog host address.

To View the Elog System Configuration

• Run the following command: elog show config


16-14

Enabling or Disabling Elog Console DisplayBy default, the elog messages are enabled so that you can view the any elog messages on the management console.

To Enable or Disable the Display of Elog Messages on the Management Console

• Run the following command: elog display {enable|disable}

• If enabled, whenever system events equal to or greater than the configured severity occur, the elog message is displayed. Messages can be displayed during any management task you are performing. This is the default.

• If disabled, elog messages are written to the elog messages file, but not displayed on the SSC.

Making a Backup Copy of the System ConfigurationThe NAS Gateway’s configuration exists in the cluster database. The NAS Gateway supports the cluster database on one of two CompactFlash cards. You can copy the NAS Gateway configuration from the database of the active CompactFlash card to the database of the standby CompactFlash card.

To Make a Backup Copy of the System Configuration

• Run the following command: system config copy

Note - This command is closely associated with the system config restore command, which enables you to restore the secondary system configuration that has been saved through the system config copy command.


16-15

Resetting the NAS Gateway Configuration to DefaultsResetting the NAS Gateway’s system configuration to an initial configuration removes the existing cluster database from the CompactFlash card, allowing you to reconfigure the NAS Gateway.

Note - To reconfigure the NAS Gateway after deleting the cluster database, reboot the NAS Gateway. When the NAS Gateway reboots, it proceeds through the ONStor Configuration Tool (OCT) through which you can configure the NAS Gateway. When you finish the bootup script, the NAS Gateway will be online and operating with a default configuration that you can customize to your needs.

To Reset the NAS Gateway Configuration

• Run the following command: system config reset

Restoring the Last Saved System ConfigurationIf you have a backup copy of the NAS Gateway’s system configuration, you can restore the NAS Gateway from the most recently saved cluster database.

After you restore the configuration, you can modify the active configuration to your needs without affecting the saved backup copy of the system configuration. When you restore the configuration, you do not delete the secondary copy of the cluster database that resides on CompactFlash card.

To Restore the Last Saved Configuration File

• Run the following command: system config restore


16-16

Note - This command is closely associated with the system config copy command, which enables you to create a backup copy of the system configuration that can then be restored through the system config restore command.

Copying All FilesThe NAS Gateway supports copying all files on the NAS Gateway’s CompactFlash card from the active CompactFlash card to the standby CompactFlash card. You might experience a delay as the files are copied, but the system remains online and serves read and write requests during any delay from the copying.

To Copy All Files on the NAS Gateway’s CompactFlash

• Run the following command: system copy all

Initializing the Standby CompactFlash CardYou initialize the standby CompactFlash card then duplicate the file system from the primary CompactFlash card on the secondary disk through. Initializing the standby CompactFlash card is analogous to formatting a disk. It clears the CompactFlash card of any contents and formats the disk with file system structure prior to copying any files from the active CompactFlash card to the standby CompactFlash card.

To Initialize the Standby CompactFlash Card

• Run the following command: system copy init


16-17

Displaying IP StatisticsThe NAS Gateway compiles statistics and usage information for its IP interfaces and its connection-oriented interfaces, such as transmission control protocol (TCP) and user datagram protocol (UDP) ports. You can display system wide information about the IP layer protocols supported, and the TCP and UDP connections established on the NAS Gateway. The IP statistics table consists of the following parts that are displayed in a scrolling list:

• IP statistics

• ICMP statistics

• IGMP statistics

• IP Encapsulation statistics

• TCP statistics

• UDP statistics

Note - Some of listed statistics are returned by the kernel software. The NAS Gateway does not use all of the listed statistics.

To Display the IP Statistics

• Run the following command: system show ipstat


16-18

Displaying File Processing Port Load StatisticsYou can view the amount of traffic load that occurs on all file processing ports.

The statistics gathered are:

• The speed, measured in packets per second, of transmitted and received traffic. This statistic uses either Kilo (1024) or Mega (1024 * 1024) to indicate a large value of packets per second.

• The throughput, measured in bytes per second, of transmitted and received traffic. This statistic uses either Kilo (1024) or Mega (1024 * 1024) to indicate a large value of bytes per second.

The NAS Gateway tracks the file processing port usage on a port by port basis and displays the output for each port.

To Display File Processing Port Load Statistics

• Run the following command: port show loadstats [-i SECONDS]

-i SECONDS is an optional argument for specifying the interval of time that statistics are displayed. During the interval, statistics are displayed once per second. Enter a value from 1 to 1000. The default interval is 5 seconds.


16-19

Managing NAS Gateway System HealthThe NAS Gateway supports gathering system health information, which is helpful when troubleshooting the NAS Gateway. You can gather system health and performance data and send that information to ONStor Customer Support without having to allow an ONStor Technical Support Engineer to log in to your NAS Gateway to gather information.

The system get commands enable you to gather either all pertinent information as a batch, or individual pieces of the overall system health information. The following list shows the new system get commands and what they support:

• system get all, which gathers all system information and related files. For more information, see “Gathering All System Health Information” on page 16-21.

• system get config, which gathers system configuration information. For more information, see “Getting System Configuration Information” on page 16-23.

• system get logs, which gathers all system log files. For more information, see “Getting the Log Files” on page 16-25.

• system get stats, which gathers all system performance stats. For more information, see “Getting the NAS Gateway Statistics” on page 16-26.

• system get tse, which gathers crash dump files and pertinent log files for Technical Support Engineers (TSE) to use in diagnosing problems. For more information, see “Gathering Technical Support Information” on page 16-29.

When the system get commands complete, they write the system health information to a target location. By default, the output is sent to the root of the management volume. However, through software, you can configure the output to be written to a nondefault target directory anywhere in the file system.

Note - Create the directory where the system information will be written. Otherwise, the system get commands cannot complete.

For example, assume the /tmp/onstor/support directory has been created. When you run the system get commands, the output file is written to the target location in the following format:


16-20

system_get_TYPE,HOST,DATE<.NUM>

The output file contains the following format:

• type is the type of information that the system get command retrieved. Valid values are all, config, logs, stats, or tse. These values refer to the types of output information.

• host is the host name.

• date is the year, month, and date when the system get command retrieved the information.

• NUM is an optional format and a number that identifies individual copies of information if multiple copies exist with the same date stamp. The NUM element is appended only if more than one directory is output by the system get commands on the same day.

Here are some examples of the output:

• system_get_all,ONStor0,05-03-18 indicates that the system get all command gathered information from the NAS Gateway named ONStor0 on March 18, 2005.

• system_get_all,ONStor0,05-03-18.1 indicates that the system get all command gathered a second iteration of information from the NAS Gateway named ONStor0 on March 18, 2005.

• system_get_stats,ONStor0,05-03-19 indicates that the system get stats commands gathered information from the NAS Gateway named ONStor0 on March 19, 2005.

• system_get_config,ONStor0,05-03-20 indicates that the system get config command gathered information from the NAS Gateway named ONStor0 on March 20, 2005.

The system get commands are supported on a per-NAS Gateway basis.


16-21

Gathering All System Health InformationYou can gather all system information and log files into one file through the system get all command. This command packs all the components of the system health information into one file. The system information that is gathered includes:

• All log files

• Pertinent system statistics

• The cluster database

• Current system configuration information

This information is placed in a directory on the target location. By default, the target location is the management volume, but you can specify any other volume in the file system. The system health information can exist in the same directory as user data or in a separate directory.

If multiple copies of the information exist for the same date, a number is appended to the end of the new file name to prevent overwriting the existing file.

When the system get all command stops, a symlink is created to the most recent system_get_all information. This symlink always points to the latest iteration of the system_get_all information. Therefore, you can always find the most recent information by following the symlink. The symlink takes the format of TYPE_FILER, where TYPE is the type of system get command that was run, and FILER is the name of the NAS Gateway on which the command was run.


16-22

To Get All System Health Information

• Run the following command: system get all [-n NUMBER] [-i INTERVAL] [-a] [-V VSVRNAME] [-v VOLNAME] [-d DIRECTORY] [-c CASENUM]


-n NUMBER An optional argument that specifies the number of iterations in which the command must gather all system health information. By default the current statistics are gathered into the sfinfo.xml file. You need the NUMBER and INTERVAL arguments only if you want to gather statistics at a certain interval over time. For gathering statistics at a certain interval over time, set the NUMBER argument to at least 2.

-i INTERVAL An optional argument that specifies the interval, in number of minutes, between statistics gathering iterations. The default value is 0 minutes, which causes no wait between iterations. Enter a number greater than 0 to specify the interval.

-a An optional argument for gathering statistics for all volumes on the current NAS Gateway.Because additional processing is necessary to gather data from all volumes, this option takes additional time for the command to complete.

-V VSVRNAME An optional argument that specifies the name of the target virtual server where the information is saved. By default, the information is written to the management virtual server, but you can specify a different virtual server. The target virtual server must exist and be enabled. If the targeted virtual server does not exist or is not enabled, the command fails.


16-23

Getting System Configuration InformationYou can gather system configuration information and basic operational statistics through the system get config command. The output of this command is packaged into an .XML file and sent to a directory on the target location, which can be either the management volume or a location that you specify.

Note - Gathering configuration information from the NAS Gateway can take some time.

You can keep multiple copies of the system get config output because the NAS Gateway creates a unique name for each output. If multiple copies of the information

-v VOLNAME An optional argument that specifies the name of the target volume where the information is saved. By default, the information is written to the management volume, but you can specify a different volume. If you do not want the information written to the management volume, enter the name of an existing volume.

Note - If the target volume does not exist or is offline, the command fails.

-d DIRECTORY An optional argument that specifies the name of the target directory where the information is saved. The default directory is the root directory ( / ), but you can specify a different directory. If you do not want the information written to the root directory, enter the name of an existing directory.

Note - If the target directory does not exist, the command fails.

-c CASENUM An optional argument that enables the collected information to be uploaded to an ONStor server through SSL, under a specific case number (CASENUM). To use this option, a Customer Support case must already exist, and you will use the provided case number when you specify this argument.



16-24

exist for the same date, a number is appended to the end of the new file name to prevent overwriting of the existing file.

When the system get config command stops, a symlink is created to the most recent system_get_config information. This symlink always points to the latest iteration of configuration information, so you can always find the most recent information by following the symlink. The symlink takes the format of TYPE_FILER, where TYPE is the type of system get command that was run, and FILER is the name of the NAS Gateway on which the command was run.

To Display the System Configuration Information

• Run the following command from the virtual server context: system get config [-s | [-V VSVRNAME] [-v VOLNAME] [-d DIRECTORY] [-c CASENUM]


-s An optional argument that displays the output on the management console. If you do not display the output on the management console, the system configuration information is displayed on either the management volume or the location specified by the VSVRNAME, VOLNAME, and DIRECTORY arguments. • If you send the output to the management console, the

configuration information scrolls up the management console’s monitor as the output of system get config is being processed.

• If you send the output to the target location, the configuration information is available only after you mount the target location through an NFS or CIFS share.

-V VSVRNAME An optional argument that specifies the name of the target virtual server where the information is saved. By default, the information is written to the management virtual server.

Note - The target virtual server must exist and be enabled. If the targeted virtual server does not exist or is not enabled, the command fails.


16-25

Getting the Log Files You can get the NAS Gateway’s log files by running the system get logs command to check them for system messages or error messages to help analyze performance issues or debugging problems. The log files are gathered in a target directory, which by default is the management volume or volume that you specify.

You can keep multiple copies of the system get logs output because the NAS Gateway creates a unique name for each output. If multiple copies of the information exist for the same date, a number is appended to the end of the new file name to prevent the existing file from being overwritten.

When the system get logs command stops, a symlink is created to the most recent system_get_logs information. This symlink always points to the latest iteration of logs, so you can always find the most recent information by following the symlink. The symlink takes the format of TYPE_FILER, where TYPE is the type of system get command that was run, and FILER is the name of the NAS Gateway on which the command was run.

-v VOLNAME An optional argument that specifies the name of the target volume where the information is saved. By default, the information is written to the management volume, but you can specify a different volume. If you do not want the information written to the management volume, enter the name of an existing volume.


-d DIRECTORY An optional argument that specifies the name of the target directory where the information is saved. By default, the default directory is the root directory ( / ).

Note - If the target directory does not exist, the command fails

-c CASENUM An optional argument that enables you to upload the collected information to an ONStor server through SSL, under a case number. To use this option, a Customer Support case must already exist.



16-26


• Run the following command.system get logs [-V VSVRNAME] [-v VOLNAME] [-d DIRECTORY] [-c CASENMUM]

Getting the NAS Gateway StatisticsYou can gather and save important system and volume statistics by running the system get stats command. This command gathers NAS Gateways statistics for


-V VSVRNAME An optional argument that specifies the name of the target virtual server where the information is saved. By default, the information is written to the management virtual server,

Note - The target virtual server must exist and be enabled. If the targeted virtual server does not exist or is not enabled, the command fails.

-v VOLNAME An optional argument that specifies the name of the target volume where the information is saved. By default, the information is written to the management volume.


-d DIRECTORY An optional argument that specifies the name of the target directory where the information is saved. The default directory is the root directory ( / ), but you can specify a different directory. If you do not want the information written to the root directory, enter the name of an existing directory.


-c CASENUM An optional argument that enable you to upload the collected information to an ONStor server through SSL, under a case number. To use this option, a Customer Support case must already exist.


16-27

one or all volumes. The statistics are posted to a target directory, which by default is the management volume or a volume that you specify in the file system.

You can keep multiple copies of the system get stats output because the NAS Gateway creates a unique name for each output. If multiple copies of the information exist for the same date, a number is appended to the end of the new file name to prevent the existing file from being overwritten.

When the system get stats command stops, a symlink is created to the most recent system_get_stats information. This symlink always points to the latest iteration of statistics, so you can always find the most recent information by following the symlink. The symlink takes the format of TYPE_FILER, where TYPE is the type of system get command that was run, and FILER is the name of the NAS Gateway on which the command was run.

You can stop statistics gathering intervals in either of the following ways:

• If the previously configured statistics gathering interval is in progress, it stops if you run the system get stats command.

• If the current statistics gathering interval is in progress, you can stop it by using the optional -k argument. This option is useful if you have started the statistics gathering interval, but need to stop it before it completes.


• Run the following command from a NAS Gateway context:system get stats [-k] [-n NUMBER] [-i INTERVAL] [-a][-s | [-V VSVRNAME] [-v VOLNAME] [-d DIRECTORY] | [-c CASENUM]]


-k An optional argument that kills any in process statistics gathering operations.


16-28

-n NUMBER An optional argument that specifies the number of iterations in which to gather the statistics information: • If you want to gather statistics once, leave the NUMBER and

INTERVAL arguments blank. • If you want to gather statistics repeatedly over time, set

NUMBER to at least 2.

-i INTERVAL An optional argument that specifies the interval, in number of minutes, between statistics gathering iterations. The default value is 0 minutes, which causes no wait between iterations. Enter a number greater than 0. For example, 60 for hourly statistics gathering or 1440 for daily statistics gathering.

-a An optional argument for gathering statistics for all volumes on the current NAS Gateway.

Note - Because additional processing is necessary to gather data from all volumes, this option takes additional time for the command to complete.

-s An optional argument that controls whether to display output on the management console or on a target location. • If you send the output to the management console, the statistics

scroll up the management console’s monitor as the output of system get config is being processed.

• If you send the output to the target location, the information is available only after you mount the target location through an NFS or CIFS share.

-V VSVRNAME An optional argument that specifies the name of the target virtual server where the information is saved. By default, the information is written to the management virtual server, but you can specify a different virtual server. If you do not want the information written to the management virtual server, enter the name of an existing virtual server.

Note - If the target virtual server does not exist or is not enabled, the command fails.



16-29

Gathering Technical Support InformationThe system get tse command enables you to gather a subset of technical support information that ONStor Technical Support Engineering can use to perform troubleshooting.

Note - This command is needed only if significant parts of the NAS Gateway are not operating and you cannot run the system get config or system get all commands.

The system get tse command obtains system information and places it in a directory on the target location, which is by default the management volume default, or a volume you specify in the file system.

You can keep multiple copies of the system get tse output because the creates a unique name for each output. If multiple copies of the information exist for the same

-v VOLNAME An optional argument that specifies the name of the target volume where the information is saved. By default, the information is written to the management volume

Note - If the target volume does not exist or is not online, the command fails.

-d DIRECTORY An optional argument that specifies the name of the target directory where the information is saved. The default directory is the root directory ( / ).


-c CASENUM An optional argument that enables you to upload the collected information to an ONStor server through SSL, under a case number. To use this option, a Customer Support case must already exist.



16-30

date, a number is appended to the end of the new file name to prevent overwriting the existing file.

When the system get tse command stops, a symlink is created to the most recent system_get_tse information. This symlink always points to the latest iteration of the TSE information, so you can always find the most recent information by following the symlink. The symlink takes the format of TYPE_FILER, where TYPE is the type of system get command that was run, and FILER is the name of the NAS Gateway on which the command was run.


• Run the following command from a NAS Gateway context:system get tse [-V VSVRNAME] [-v VOLNAME] [-d DIRECTORY] | [-c CASENUM]


-V VSVRNAME An optional argument that specifies the name of the target virtual server where the information is saved. By default, the information is written to the management virtual server.

Note - If the targeted virtual server does not exist or is not enabled, the command fails.

-v VOLNAME An optional argument that specifies the name of the target volume where the information is saved. By default, the information is written to the management volume.



16-31

-d DIRECTORY An optional argument that specifies the name of the target directory where the information is saved. By default, the default directory is the root directory ( / ).


-c CASENUM An optional argument that enables you to upload the collected information to an ONStor server through SSL, under a case number (CASENUM). To use this option, a Customer Support case must already exist.



16-32

Working with the Read Ahead CacheRead ahead cache allows the NAS Gateway to process user data blocks from applications ahead of the actual read operation that places the blocks in NAS Gateway’s data cache. Some applications have file access patterns that require read ahead caching. The NAS Gateway supports enabling and disabling of read ahead caching.

Enabling or Disabling Read Ahead CachingBy default, the NAS Gateway’s read ahead caching is disabled.

Note - You can determine whether read ahead caching needs to be enabled or disabled by running the system show readahead performance command. If an excessive amount of cache misses is occurring, you can try enabling read ahead caching for more optimized use of the cache. If the amount of cache misses is acceptable, read ahead caching can be left in its current state.

To Enable Read Ahead Caching

• Run the following command: system enable readahead

When read cached is enabled, it can optimize the read ahead of data blocks into the NAS Gateway data cache if the NAS Gateway is reading from an application that uses sequential file reads. However, some applications perform random file reads, and if the NAS Gateway’s read ahead caching is enabled, the result can be excessive data cache thrashing.

To Disable Read Ahead Caching

• Run the following command:system disable readahead


16-33

Displaying the State or Performance of Read Ahead CachingYou can display the state of read ahead caching at any time by running the system show readahead command. By default, this feature is enabled.

To Display the Current State of Read Ahead Caching

• Run the following command: system show readahead state

Read ahead cache performance statistics include:

• The number of read ahead requests the NAS Gateway has received

• The number of data blocks read

• The percentage of read ahead hits in the NAS Gateway’s data cache

• The percentage of read ahead misses in the NAS Gateway’s data cache

To Display System Read Ahead Cache Performance

• Run the following command:system show readahead performance


16-34

Working with Core DumpsA core dump is the entire memory core of the NAS Gateway and the cores from the file processor (FP) element. This information is written to a file if the NAS Gateway crashes. The core dump file is written to a core volume that you configure on the NAS Gateway’s management virtual server.

The NAS Gateway supports an automatic core dumping feature that enables flushing of the memory core and FP cores to disk whenever the NAS Gateway encounters a system event that causes it to reset. The core dump file that is created during a core dump is automatically compressed during the copy operation onto the core volume. The .gz extension indicates the compressed core dump file.

Creating a Core Dump VolumeWhile the raw core dump is in the core volume, it cannot be accessed for debugging purposes. When the NAS Gateway reboots, it copies the raw core dump as a core dump file onto the management volume, and the core dump file is accessible. When the copy is complete, the raw core dump remains in the core dump volume until the next crash overwrites it, and the core dump file exists as a binary file on the management volume on the management server. The analysis and interpretation of the core dump file’s binary data can be performed only with the assistance of ONStor personnel.

Note - When the core volume is created, it appears in the volume show command’s output as Status NotMounted and Type Core.

Each NAS Gateway supports only one core dump volume.

Note - To support the core volume, a configured management virtual server must exist, and a management volume must be configured in the management virtual server.


16-35

To Create a Core Volume

• Run the following command from the management virtual server context:

system create corevolume VOLNAME [LUN]

Deleting the Core Dump VolumeWhen you delete the core volume, the following occurs:

• The core volume is destroyed and any LUN assigned to it is released and returns to “free” state.

• Any raw core dumps that exist in the core volume are deleted.

• All future core dumps cannot be written to the core volume.

• The management volume is still assigned.

Note - There is no dependency between system delete corevolume and system modify coredump off, so you do not need to disable the core dump feature before deleting the core volume.

To Delete the NAS Gateway’s Core Volume

• Run the following command from the management virtual server


VOLNAME Specifies the name of the volume that you are creating as the NAS Gateway’s core volume. The core volume cannot support a file system.

LUN An optional argument that enables you to configure the core volume on a specific LUN. By default, the NAS Gateway takes the first “free” LUN when you run this command. You can use only a “free” LUN for this argument. To get a list of LUNs, you can run the lun show disk command, and page through the display until you find a LUN whose state is “free”.


16-36

context:system delete corevolume VOLNAME [force]

Enabling or Disabling Automatic Core DumpingThe NAS Gateway supports an automatic core dumping feature that enables flushing of the memory core and FP cores to disk whenever the NAS Gateway encounters a system event that causes it to reset.

Before you enable the core dump feature, the following conditions must be met:

• A management virtual server must be configured on the NAS Gateway where you are enabling the core dump feature.

• A management volume must be configured within the management virtual server on the NAS Gateway where you are enabling the core dump feature.

• A core volume must be configured within the management virtual server on the NAS Gateway where you are enabling the core dump feature.

To Enable the Automatic Core Dump Feature


system modify coredump on

If you disable core dumping, the NAS Gateway retains the core volume and any core dumps that exist on the core dump volume. Any in-progress write operations to the management volume are allowed to complete.


VOLNAME Specifies the name of the core dump volume that you are deleting. When the core volume is deleted, all data within it is deleted.

force An optional argument that deletes the core dump volume regardless of any checks or processes to take the core dump volume offline gracefully. This option is immediate.


16-37

To Disable Automatic Core Dumping


system modify coredump off

Displaying the State of Automatic Core DumpingDuring run time, you can check the state of the automatic core dump feature. The current state displays as either ON or OFF. By default, automatic core dump is ON.

To Display the State of the NAS Gateway’s Automatic Core Dumping Feature


system show coredump

Displaying Core Dump FilesTo display a list of the core dump files, you can mount and display the management volume. When the management volume is mounted, all NFS commands, such as ls and cp are available. You can provide the core dump files to ONStor Technical Support for analysis and interpretation through FTP or another standard file transfer protocol. Only ONStor personnel can interpret the core dump files.

Setting the Maximum Number of Saved Core Dump FilesBy default, the NAS Gateway saves one core dump file on the management volume. However, you can set the maximum number of core dump files to be saved on the management volume.

To Enable the Management Volume to Retain More Than One Core Dump File


system modify coredumpmaxsavedfiles MAX

MAX is the maximum number of files to be saved. Enter a number


16-38

between 0 and 99. The default is 8.

Configuring the Volume Exception Dump FileIn addition to core dump files, the NAS Gateway also supports volume dump files. These files are written to the management virtual server whenever a volume goes offline due to a volume exception. The volume exception dump file contains information related to the volume at the time it went offline. All volume dump files have the same naming convention, which consists of the volume name and a numerical identifier.

You can configure the contents of the volume exception dump file, and enable or disable the volume exception dump feature by running the system modify volumeexceptiondump command. As part of this command you can specify some of the data structures that are captured and written to the volume exception dump file when the volume goes offline. Table 16-13 lists the types of data that the NAS Gateway can send to the volume exception dump file.

Table 16-13: Possible Data Types for Volume Exception Dump File

Data Type Summary

FS The file system structure.

SUPERBLOCK The in-core copy of the super block.

THREADSTACKS The stacks and registers of the threads currently running.

CONTEXTS Context structures of the running threads.

LOCKS The locks obtained by the running threads.

REQUESTS The file system requests executed by the running threads.

INODESMRU The most recently used Inodes. This includes the Inodes that have been modified and have not been written to the disk yet

BUFFERSMRU The most recently used buffers. This includes the buffers that have been modified and have not been written to the disk yet.

INODES 1 All Inodes that were cached at the time of the exception.

BUFFERS 1 All buffers that were cached at the time of the exception.


16-39

By default, not all of the data types are stored in the volume exception dump file. The default data types stored are:

• FS (file system)

• Superblock

• Threadstacks

• Contexts

• Locks

• Requests

To Configure the Volume Exception Dump File

• Run the following command: system modify volumeexceptiondump [-m on|off][-a DATATYPE] [-d DATATYPE] [-r]

1: These data types can significantly increase the size of the volume exception dump file.


-m on|off Specifies the operating mode of the volume exception dump feature. Use this argument to turn volume exception on or off. By default, the feature is off.

-a DATATYPE An argument for adding a specified data type to the volume exception dump.

-d DATATYPE An argument for deleting a specified data type from the volume exception dump.

-r An argument for resetting the data types to the default.

Table 16-13: Possible Data Types for Volume Exception Dump File (Continued)

Data Type Summary


16-40

Displaying the State of Volume Exception Dump FeatureDisplays the automatic core dump's state of on or off. This command also displays the name of the on-disk coredump volume, the maximum number of saved core dump files, if the volume exception core dump is on or off, and the volume exception data types.

To Display the Current State of the Volume Exception Dump Feature


system show coredump


Index

Symbols/.snapshots 9-3Numerics1.0.NAS Gateway Overview and Access 1-1Aadmin

allowdeleting 2-7

denyadding 2-4, 2-5

admin privilegesdisplaying 2-7

aliastape

displaying 14-26removing 14-26setting 14-25

allow admindeleting 2-7, 2-8

ARP 5-9adding entries 5-10displaying table 5-11remove entries 5-11

ARP Table 5-9, 5-10clearing 5-11displaying 5-11

asynchronous mirroring 13-5Audit Log

690-0015-0001G1 ONStor Bobcat 2200 Series

displaying 8-16Audit Log file 8-2auditing

filecircular file 8-15displaying config 8-16displaying log 8-16enabling 8-9fail flag 8-13file size 8-14setting failure 8-11setting mode 8-15setting success 8-10

file audit events 8-4autocreate

deletingvirtual server 3-40

settingvirtual server 3-37

autogrowvolume

and quotas 10-2autogrowth

mirror volumes 13-5autosupport 12-2

note 12-3notification 12-3vs. elog 12-2

NAS Gateway System Administrator’s Guide

1-2

autosupport configdisplaying 12-9

autosupport statisticsdisplaying 12-9

Bbackup 14-3

full 14-4incremental 14-4partial 14-4

backup/restoreNAS Gateway 14-6

backup/restore types 14-5CCIFS

auditing 8-3share deletion 7-55share information 7-52

client exclusionsNFS shares 7-4

command-line contents 1-16configuration

NDMPresetting 14-34

configuring mirrors 13-7context

virtual serverchanging 3-50clearing 3-52

Ddata services 14-6deleting

NFS shares 7-51deleting mirrors 13-19deny

admindeleting 2-8

deny adminadding 2-4, 2-5

device pathmapping 14-42, 14-43

directories

ONStor Bobcat 2200 Series NAS Gateway Sys

homeconfiguring 3-36, 3-37deleting 3-40

displaying optionsNFS shares 7-48

domainconfiguring

NIS domainadding 3-19

Eelement

file processor 1-4FP 1-4SP 1-5storage processor 1-5

elogvs. autosupport 12-2

emailautosupport 12-2

enable mirror 13-19environment variables

NDMPquotas 10-5, 10-6, 10-8

Ffan tray

fans 1-6file auditing

audit events 8-4Audit Log

displaying 8-16CIFS 8-2circular mode 8-15configuration

displaying 8-16enabling 8-9fail flag

setting 8-13failure parameters

setting 8-11, 8-14file mode

setting 8-15

tem Administrator’s Guide 690-0015-0001G1

I-1-3

Log 8-2success parameters

setting 8-10understanding 8-2

file extensionsvirus scan

adding 15-38listing 15-37replacing 15-39

file processing overview 1-12file processor element 1-4file system

quotaand autogrow 10-2and NDMP 10-4enabling 10-17NDMP

variables 10-5, 10-6, 10-8snapshots

quotasnapshots

snapshotsquota

considerations 10-9

foreign LUNs 4-2FP element 1-4free LUNs

LUNsfree 4-2

Hhome directory share

sharehome directory 3-36, 3-37, 3-40

IICMP 5-2

ping 5-2traceroute 5-2

ID mapupdating

for quotas 7-72, 10-22

interfacesmanagement 5-4

interfaces displaying 5-4IP

adding static routes 5-7displaying interfaces

IP Interfaces Table 5-4displaying IP Table 5-6displaying Route Table 5-8management interfaces 5-4removing routes 5-9

IP Table 5-6Llabel

LUN 4-13local useraccounts 14-18log

virus scanclear 15-34show 15-33

logging in 1-16LUN

labelling 4-13LUNs

foreign 4-2LUN discovery 4-1

Mmanagement interfaces 5-4management virtual server 3-4management volume

NDMP 14-12map

IDupdating

quotas 7-72, 10-22media changers

aliasdisplaying 14-26removing 14-26setting 14-25

listing 14-24


1-4

mirrordelete 13-19enabling 13-19schedule

modifying 13-12session

displaying 13-20pausing 13-23

mirror show 13-20mirroring

asynchronous 13-5autogrowth 13-5configuration 13-7

mirrorsconsiderations 13-7

modifying mirrors 13-12module

SSC 1-4mount options

displaying 7-48mover services 14-6NNAS Gateway

backup/restore 14-6NDMP

configurationdisplaying 14-35resetting 14-34

disabling 14-28enabling 14-28management volume 14-12quota variables 10-5, 10-6, 10-8snapshot management extensions 14-5tape

block size 14-33set model 14-31

NDMP serviceand quotas 10-4

NDMP services 14-3data 14-6mover 14-6SCSI 14-6


tape 14-6NDMP sessions

displaying 14-36network connectivity 1-13NFS

sharesclient exclusions 7-4deleting 7-51showing options 7-48

noteautosupport 12-3

notificationautosupport 12-3

Oon-demand snapshots

creating 9-4, 9-5ONStor NAS Gateway

dimensions 1-5displaying configuration 16-4displaying uptime 16-3halting 16-4performing traceroute 16-5sending pings 16-5setting NTP 16-7setting time 16-6

ONStor Volume Manager 1-13overview 1-13

overviewONStor Volume Manager 1-13software 1-12

file processing 1-12system control 1-12

Pparameters

autosupportcreating 12-9

pausing mirrors 13-23physical device

mapping 14-42, 14-43portmap

RPC


I-1-5

virus scanning 15-24privileges

admindisplaying 2-7

Qquota 7-72, 10-22

autogrowinteraction 10-2

enabling 10-17NDMP

interaction 10-4NDMP variables 10-5, 10-6, 10-8

quotas 10-1Rremote backup 14-4restore 14-3

backup 14-4incremental 14-4partial 14-4

Route Tabledisplaying 5-8

routes 5-8removing 5-9static

static routeadding 5-7

Ssample topology 1-11scanning

virusadd server 15-2config

requirements 15-18config files 15-18delete server 15-32extensions


incoming traffic 15-36log

clear 15-33, 15-34outgoing 15-36RPC portmap 15-24server 15-27show config 15-32uninstalling 15-17Windows service 15-25

schedulemirror

modify 13-12scsi

releasetape 14-27

SCSI services 14-6server

management virtual 3-4virtual

changing 3-50clearing 3-52deleting autocreate 3-40deleting WINS 3-36enabling 3-44moving 3-54setting autocreate 3-37state

virtual server disabled 3-3virtual server enabled 3-3

understanding 3-3virus scan

add 15-2delete 15-32

servicesNDMP

and quotas 10-4session

mirrordisplaying 13-20pause 13-23

sharesCIFS

deleting 7-55information 7-52


1-6

NFSclients exclusion 7-4deleting 7-51showing options 7-48

sharing read-only 6-24snapshot schedules

creating 9-6snapshots 9-2

directory 9-3on-demand 9-2scheduled 9-2

software overview 1-12file processing 1-12network connectivity 1-13storage processing 1-13system control 1-12

SP element 1-5SSC 1-4SSC module 1-4state

NDMPdisplaying 14-35

tapedisplaying 14-23

statisticsautosupport

creating 12-9storage ports

statisticsdisplaying 4-6

storage processing 1-13storage processor element 1-5system control overview 1-12System Switch and Controller 1-4TTable

ARP 5-10, 5-11table

ARP 5-9tape

block sizeNDMP 14-33


set modelNDMP 14-31

tape aliasclear 14-21displaying 14-21setting 14-20

tape devicereleasing 14-27state

displaying 14-23tape library

aliasdisplaying 14-26removing 14-26setting 14-25

displaying 14-24tape services 14-6topology

sample 1-11traffic 15-36UUpdating ID map 7-72, 10-22user

allow admindeleting 2-7, 2-9

user interfaceaccessing 1-16

useraccountdeleting 2-13displaying 2-12modifying 2-11

useraccounts 14-18Vvirtual server

management server 3-4state 3-3

virtual serverschanging 3-50clearing 3-52deleting autocreate 3-40deleting WINS 3-36


I-1-7

enabling 3-44moving 3-54protected mode 3-54setting autocreate 3-37

virus scancomponents

server 15-27config

requirements 15-18show 15-32

config files 15-18extensions


incomingenable 15-36

logclear 15-34show 15-33

outgoingdisable 15-36

RPC portmap 15-24server

add 15-2delete 15-32

trafficincoming 15-36outgoing 15-36

virus scanninguninstalling 15-17Windows service 15-25

volumeautogrow

and quotas 10-2creating volumes 6-5deleting volumes 6-22displaying volumes 6-14modifying volumes 6-15

WWindows domain

adding 3-19

WINSdeleting

virtual server 3-36


1-8


ons-doc-sag-2200-g1_3100sag2007-09

Documents

Transcript of ons-doc-sag-2200-g1_3100sag2007-09