NexentaStor^TM

User Guide

Version 3.0

Copyright © 2010 Nexenta Systems, Inc.

1 Introduction

NexentaStor is a software-based storage appliance based on the Zetta File System (ZFS) from OpenSolaris. NexentaStor supports file and block storage and a variety of advanced storage features such as replication between various storage systems and virtually unlimited snapshots and file sizes.

The product supports direct-attached SCSI, SAS, and SATA disks, and disks remotely connected via iSCSI, FibreChannel, or AoE protocols. Networking support includes

10/100/1G BaseT and many 10G Ethernet solutions, as well as aggregation (802.3ad) and multi-path I/O. For most installations, we recommend 100Mbps Ethernet at a minimum.

An in-kernel CIFS stack is provided and NFS v3 and v4 are supported. For easy access from Windows, WebDAV offers another file sharing option. The product also makes use of rsync, ssh, and zfs send/receive, CIFS and NFS transports for tiering and replication. Block level replication (remote mirroring) is provided as an optional module.

Directory services such as Active Directory and LDAP are supported, including UID mapping, netgroups, and X.509 certificate based client authentication.

1.1 Terminology

1.2 Functional Block Diagram

The following block diagram illustrates the main components of the NexentaStor management architecture. The management software includes Nexenta Management Server and its clients: NMC, NMV, NexentaStor runners (see Section “Terminology” above), NexentaStor plugins, 2^nd tier storage services.

1.3 Storage Limits

With ZFS many of the limits inherent in the design of other storage systems go away. Here is a summary of some of the key threshold limits in ZFS.

2 NMC Overview

The NexentaStor Management Console (NMC) provides a complete set of operations for managing the storage appliance. NMC also includes wizards and the ability to record and replay commands across all deployed NexentaStor instances. Command completion is provided to guide you through the interface. Using 'help keyword' is another way to learn the available commands.

2.1 Accounts

NexentaStor provides a “root” and “admin” user account. In NMC, the “root” user account has rights to perform all actions. The default passwords are “nexenta” and should be changed immediately after system installation. The passwords can be changed using the NMC command:

nmc:/$ setup appliance password

2.2 Command Completion

You can interchangeably use the “TAB-TAB” approach for command completion, type command names or partial command actions to enter a menu driven mode, or add “-h” as necessary to most secondary commands for full usage statements and examples.

Whichever way you use to enter commands, NMC will present a number of (completion) choices. To quickly find out the meaning of all those multiple options, type '?' and press Enter. For instance, type show appliance, and press TAB-TAB or Enter:

nmc:/$ show appliance

In response NMC will show a number of options - in this particular case appliance's services and facilities that can be "shown". Note that <?> is part of the show appliance completion set - its presence indicates availability of brief per-option summary descriptions. Next:

• type '?'

• observe brief descriptions

• decide which (completion) option to use

• repeat the sequence, if needed

2.3 Command Summary

The commands available in NMC are shown in the following table.

show	display any given object, setting or status
setup	create or destroy any given object; modify any given setting
query	advanced query and selection
switch	manage another Nexenta Appliance or a group of appliances
destroy	destroy any given object: volume, folder, snapshot, storage service, etc.
create	create any given object: volume, folder, snapshot, storage service, etc.
run	execute any given runnable object, including storage services: auto-snap auto-scrub auto-sync auto-tier
share	share (via NFS, CIFS, RSYNC, FTP and WebDAV [31]) a volume or a folder. Share zvol (Section “Terminology”) via iSCSI.
unshare	unshare a volume or a folder
record	start and stop NMC recording sessions
help	NexentaStor manual pages

Of these, the primary commands are setup and show. You can run setup usage or show usage to get a comprehensive usage guide for these commands. Search the result using '/' (forward search) and '?' (backward search).

By running setup, you can see the available options.

nmc:/$ setup

Option ?

<?> appliance auto-scrub auto-snap auto-sync auto-tier collector

delorean diagnostics folder group inbox indexer iscsi lun mypool/

network plugin recording reporter script-runner snapshot storagelink

trigger usage volume zvol

---------------------------------------------------------

Navigate with arrow keys (or hjkl), 'q' or Ctrl-C to quit

Summary information: short descriptions and tips

By running show, you can see the available options.

nmc:/$ show

Option ?

all appliance auto-scrub auto-snap auto-sync auto-tier collector

faults folder group inbox indexer iscsi lun mypool/ network

performance plugin recording reporter script-runner scsi-target share

snapshot trigger usage version volume zvol

---------------------------------------------------------

Navigate with arrow keys (or hjkl), 'q' or Ctrl-C to quit

Appliance at a glance: show appliance's network and

2.4 Scripting

NMC is easily scriptable, and can be used to quickly create custom scripts that run periodically, on event, or “on-demand”:

• NMC 'foreach' - an easy LOOP facility

• Custom scripting: functionality and HowTo

3 NMV Overview

Nexenta Management View (NMV) is NexentaStor’s Web-based GUI. Nearly all administrative functions can be performed using this GUI.

3.1 Accounts

NexentaStor provides a “root” and “admin” user account. In NMV, the “admin” user account has rights to perform all actions. The default passwords are “nexenta” and should be changed immediately after system installation. The passwords can be changed on the Settings tab under the Appliance heading.

3.2 Login

The default management port is 2000. Both HTTP and HTTP/s access are supported.

3.3 Navigation

The primary tabs in NMV are:

• Status

• Settings

• Data Management

• Analytics

The Status pages give you status on the appliance, network, and storage.

The Settings pages allow you to make configuration changes to the appliance.

The Data Management pages allow you to administer data volumes and folders.

The Analytics pages allow you to see storage and network performance trends over time.

3.4 Terminal Access

Note that you can access NMC from within the Web browser by clicking the Console icon.

3.5 View Log

The results of administrative actions are shown on a status bar at the top of the page. However it quickly disappears. To see the results of actions that have taken place in this Web session you can click on 'View log' in the upper right corner of the GUI.

4 Initial Setup

During the installation process you register your software on the Web and receive a license in email. Next you enter some basic network configuration information such as the default gateway to be used.

After the network configuration is setup the Web server can start. To connect to NMV from a Web browser enter the configured network address in the browser and use port 2000.

Once connected to the Web server for the first time, the installation wizard will lead you through a few basic installation steps.

Initially, you are asked to provide some basic information about the appliance, such as the host and domain name.

Next, you will be asked to set the root and admin user passwords.

On the next screen provide notification information. Specify SMTP server information to enable automatic issue reporting to Nexenta Support, requesting additional capacity, etc.

After completing the installation steps, you'll be asked to confirm the settings and save the configuration.

After saving the configuration you are taken to a second installation wizard which will allow you to configure networking, iSCSI, volumes, and folders.

5 Managing Data Volumes

This section describes the administration of data volumes. NexentaStor allows you to first aggregate your available disks into data volumes, and then to allocate file or block-based storage from the data volume. The data volume provides a storage pooling capability, so that file systems or blocks can have room to expand without being over-provisioned.

5.1 Data Redundancy

The data volume provides redundancy capabilities similar in concept to the RAID features of other storage systems. Redundancy options are: none, mirrored, RAID-Z1 (single parity), RAID-Z2 (double parity), and RAID-Z3 (triple parity). It is recommended that you always choose some form of redundancy for your pool.

The redundancy options in NexentaStor may sound familiar to other standard RAID options, but there are some important differences. For example, NexentaStor always relies on checksums to determine, if data is valid instead of assuming that devices will report an error on the read quest.

For RAID-1 the assumption is that either side of the mirror is equally current and correct. With mirroring in NexentaStor, checksums always validate the data and in the event of conflicts the most recent data with a valid checksum is used.

With RAID-5, if the data being written is smaller than the stripe width then multiple I/O operations are needed (read the data, modify it, write it). With NexentaStor RAID-Z1, all writes are full stripe writes. This helps to ensure, that data is always consistent on disk (even in the event of power failures, etc.).

When multiple redundancy groups are in the data volume, NexentaStor will dynamically stripe writes across them. However unlike RAID-0 stripes, the disks participating in the write are dynamically determined and there are no fixed length sequences.

A Note On Redundant Configurations A mirrored volume pool consists of matched drives or drive groups, where by data always has a redundant copy on the mirrored set of disks. Mirroring can make use of other pooled technologies such as parity, allowing multiple groups of disks to be setup each with one primary array and one secondary, mirrored array. In most cases, for best reliability and performances, administrators would setup a combined or striped set of mirrored devices (sometimes referred to as RAID 10). In the case of two-way mirrors RAID 10 will halve your overall storage capacity, but will provide the best read/write performance, as reads are striped across all of the primary disks, and writes only require a single duplication of each write to a secondary drive. At any time, any number of failed drives are permitted, as long as no two drives in a paired set fail at the same time. Parity based RAID volumes make use of one or two dedicated drives to maximize capacity without reducing redundancy of stored data. Each write is committed across all drives in a group, including the parity devices, and they further take some penalty in calculating the parity. The reverse is equally true, as reads must combine data and parity across all devices in a group. To improve performance, it is generally recommended to also stripe multiple parity based RAID groups together to allow parallel reads/writes to the disk. This is commonly referred to as RAID 50. Up to one drive in a RAIDZ1 group, or two drives in a RAIDZ2 group can fail at a time without losing data. In the RAID50 setup, you both allow for future expansion with new parity groups, as well as allow for more drive failures, limited still to at most two per group. In both mirrored and parity based RAID volumes, you should establish multiple spare devices equal to the size of each member drive. Redundant, striped arrays of either variety, with sufficient spare disks, allow one to achieve the greatest level of reliability on commodity disks. As disk capacity grows and gets ever cheaper, you can expand on these striped volumes. The ZFS based filesystem allows for continuous volume growth, but consistent disk group sizing across a striped array. is recommended. Therefore, as disk sizes increase, it is considered a good practice to create disk sub-groups of as close to an equal size as possible. Redundant configurations improve not only reliability of your NexentaStor system but performance as well. For mirrored configurations: Random reads scale linearly with the number of disks; writes scale linearly with the number of mirror sets. Read throughput scales linearly with the number of disks; write throughput scales linearly with the number of mirror sets. For parity (RAID-Z, RAID-Z2) configurations: Random I/O reads and writes scale linearly with the number of RAID sets. Sequential I/O throughput scales linearly with the number of data (non-parity) disk

5.2 Create Data Volume

Data volumes are managed from the Data Management tab within NMV. When the Data Management tab is selected there is a link to Data Sets. From this page you can create a volume. Here is an example of the screen where a volume can be created.

The redundancy options include mirroring, RAID-Z1 (single parity), RAID-Z2(double parity), and RAID-Z3 (triple parity).

All disks that are not already contained in data volumes are shown. Note that this may include disks mapped to the NexentaStor appliance from other storage systems.

Here is an example of selecting three available disks for a RAID-Z1 configuration.

In addition to choosing the disks, you can also specify the volume name and various properties such as a description, de-duplication, and auto-expand.

5.2.1 De-duplication

De-duplication is a technique for increasing the effective storage capacity within a data volume. Data is examined when it is being written to non-volatile storage. Hashes of the data blocks are compared to entries in the de-duplication table and if there are matches then the existing data block’s reference count is incremented instead of creating a new data block.

The following de-duplication options are available:

• SHA-256

• SHA-256 verify

• Off

De-duplication can save storage capacity and I/O bandwidth, but it will also increase latency. To minimize the performance impact, make sure that the de-duplication table fits in RAM. To estimate the size you can use this formula:

( (Size of pool / average block size) * (270 bytes) ) / estimated dedup ratio

Since there is a performance penalty with de-duplication it is off by default. Turn this option on, if you think you will have a lot of redundant data blocks in the pool. This can be true in virtualized environments or backened storage for email systems.

When de-duplication is turned on, the SHA-256 algorithm (a cryptographic hash algorithm from NIST) is used.

There is a one in 2^256 chance that SHA-256 will report a hash match even though the two blocks being compared are not the same. To ensure this is not an issue, you can include verify as an option which will read the data blocks after a hash match to ensure the blocks are the same.

The de-duplication is also available when using the auto-synch service. See the section on “Asynchronous Replication” for details.

5.2.2 Auto-expand

Auto-expand will automatically try to expand the size of the data volume when a new disk is added. This is another option that is off by default. One reason for this is to ensure that spare devices don’t unexpectedly increase the size of your data volume when they are temporarily activated in response to a disk failure. Once the volume size is expanded it can’t be shrunk.

5.3 Creating various RAID configurations

When you create a data volume you choose a redundancy type such as RAID-Z1 for each group of disks in the volume. There is a penalty for putting too many disks in a RAID-Z1 (or –Z2 or –Z3) group such as slow re-silvering times. For larger volume sizes you would instead split the disks between multiple redundancy groups. NexentaStor will then essentially stripe writes across the redundancy groups.

Here is an example using NMC to create something similar to a RAID50 configuration. Make sure you have at least six available disks. Assume their names are: c1t1d0 c1t2d0 c1t3d0 c1t4d0 c1t5d0 c1t6d0. In NMC:

nmc:/$ setup volume create my-notexactly-raid50
Group of devices: c1t1d0, c1t2d0, c1t3d0
Group redundancy type: raidz1

You are then asked "Continue adding devices to the volume 'my-notexactly-raid50'?
Type 'y'.

Group of devices: c1t4d0, c1t5d0, c1t6d0
Group redundancy type: raidz1
Create volume 'my-notexactly-raid50'? y

5.4 View Status

You can view the status of all of your data volumes by selecting the Show link under the Volumes heading. Here is a sample screen:

From this view you can take actions on the volume such as expanding it, exporting it, deleting it, or editing its properties.

In NMC you can get the status of the data volume using show volume volumename status. This will list the status of each device in the pool, and any I/O or checksum errors that have occurred.

5.5 Edit Properties

There are a few data volume properties that can be edited after the volume is created. To edit the data volume properties, click on the name of the data volume in the summary view.

In particular you can change the de-duplication and auto-expand properties. These properties are described earlier in this section.

In NMC you can see all volume properties using the command:

nmc:/$ show volume <volumename> property

To change a property use:

nmc:/$ setup volume <volumename> property <propertyname>.

5.6 Expand Data Volume

You can expand a data volume by selecting “Grow” on the summary page. You will see a page similar to the view when creating a volume. You are adding a new disk group at this point. Select the redundancy level, select the available disks to use, and add them to the pool.

Here is an example of adding a second RAID-Z1 group to a pool to create a configuration roughly similar to RAID 50:

After selecting “Grow Volume” the disk group is added to the data volume.

After adding this new redundancy group to the data volume, NexentaStor will favor writing to this newer group. The goal is to balance the writes across all the redundancy groups over time.

To expand a volume in NMC, use the command:

nmc:/$ setup volume <volumename> grow

5.7 Destroy Data Volume

A volume can be deleted by selecting the delete icon on the summary page. A dialog box will appear to confirm the request before the volume is actually destroyed.

Note that you will lose all the data in the volume at this point so make sure it is what you want to do!

Here is an example destroying a volume named “myvolume” using NMC:

nmc:/$ destroy volume <myvolume>

5.8 Export/Import Data Volumes

If you are going to perform a system or software upgrade, you should consider exporting the volumes first. Exporting the volume protects the underlying physical drives from I/O activity.

5.8.1 Export

The export will unmount any datasets in the volume. The volume meta-data is persistent. After the export, you can then import the volume into a new system and any datasets and ZFS configuration will be restored.

In NMV, the export option can be found on the summary page. A dialog box will appear to confirm your decision to export the volume, as shown below.

You can perform an export in NMC with the command:

nmc:/$ setup volume <volumename> export

5.8.2 Import

By default, NexentaStor will import existing accessible data volumes when a system starts.

You can also import data volumes manually.

The import option is available under the Volumes heading. Selecting “Import” will show the volumes that can be imported.

The syntax for setup volume import in NMC is:

nmc:/$ setup volume import [-D] [-f] [-s] [vol-name] [new-name]

'vol-name' is the name of the exported or destroyed volume.

You can use new-name to provide a new name for the imported volume so that it won’t conflict with any existing volumes.

The '–D' option is needed to import a destroyed volume.

The '–f' option forces the import, even if the system thinks the volume is already active.

The '–s' option applies the default auto-snap snapshot policy to the imported volume.

The NMC command show volume import will show data volumes that can be imported. Volume names are shown along with their GUID. The volume’s globally unique identifier may need to be used, for example, if two volumes have been exported or destroyed that used the same name. In this case the syntax would be:

nmc:/$ setup volume import

myvol:380744323214575787.

Here is an example in NMV of a data volume “mypool” that was created, destroyed, and then recreated with a different set of devices.

In the example above, 'mypool' was first created with six devices, then destroyed, and then re-created as a two-disk mirror. Note that for import to work the underlying drives must not have been used after the export. Thus only the mirrored 'mypool' can be imported in the above example.

To recover properly from failures or unclean shutdowns, import will replay any transactions in the ZFS Intent Log (ZIL). This occurs for regular or forced imports. If a separate ZIL is being used and it is unavailable, then the import will fail. Be sure to use a mirrored ZIL if using a separate log device to protect against this scenario.

5.9 Scrub

NexentaStor can periodically check the contents of the data volume. Scrubbing the data volume will read the data blocks checking for errors. If there is redundancy in the pool configuration then NexentaStor can correct any errors it finds.

To enable periodic scrubs for a data volume, go to Data Management → Auto Services. Choose “Create” under the “Auto –Scrub Services” heading and you will see the following screen:

Choose an existing data volume from the pull-down list and define scrub schedule. Note that scrubbing is resource-intensive, so it is preferable to perform it during the maintenance time window, if it's possible.

6 Disk Management

6.1 Locating Disks

NexentaStor supports physical slots to LUNs mapping based on on-disk GUID. NexentaStor slot mapping utility produces a map { disk GUID <=> slot number }.

T
his map, as well as JPEG image of the box (with drive slots shown and enumerated) is used then by the NexentaStor UI to perform related monitoring and management (including fault management) operations. The appliance's GUI does not need to be re-built to work with a new slot mapping. A hardware partner can run a simple utility to pre-generate the slotmap file for a given hardware platform installed with NexentaStor.

Existing drive <=> slot mapping can be modified and additional mappings can be added. You can also make a given drive's LED blink, to identify its exact location in the appliance.

Please use the following NMC commands to view and administer slot mapping:

nmc:/$ show lun slotmap

nmc:/$ setup lun slotmap

6.2 Viewing Disk Status

By selecting the Settings tab in NMV, and the Disks sub-tab, you can see a list of disks, various disk properties, and whether they are already associated with data volumes. An example screen is shown below:

If the disk already belongs to a data volume, the volume name will show in the Volume column. If you click on the disk name, you can see additional properties about the disk.

If disks have recently been mapped to this host, or if you suspect the configuration information is out-of-date, you can update the information using the Refresh button. Note that re-synchronizing the system with the disk configuration can take some time.

6.3 Adding Spares to a Data Volume

In NMC you can add one or more devices to a data volume by clicking 'Grow' in the data volume summary view. The Grow Volume page will appear showing you the available disks. Select one or more disks and then click the button “Add to spare”. You will see a view similar to the following screenshot:

Select “Grow Volume” to add the spare devices to the volume.

6.4 Adding Global Spares

NexentaStor allows you to have hot spares for your volumes. If a device in the pool fails, the system will detect the failure and activate the spare device automatically. However, if you have multiple volumes you may not want to dedicate a spare device to each one. With global hot spares, one device can be a spare for multiple volumes. If there is a failure in any of the volumes, the spare can then be activated.

To set up a device that serves as a spare for multiple volumes, first create a volume and add devices to it. Note that in this example we are setting up a mirror but other redundancy options such as RAID-Z1 would also work.

nmc@myhost:/$ create volume my-mirror
Group of devices : c1t1d0, c1t2d0
Group redundancy type : mirror
Continue adding devices to the volume 'my-mirror'? (y/n) y

After setting up the mirror, add the spare device.

Group of devices : c1t3d0
Group redundancy type : spare
Continue adding devices to the volume 'my-mirror'? (y/n) n

Create volume 'my-mirror'? (y/n) y

Now create a second volume.

nmc@myhost:/$ create volume my-mirror2
Group of devices : c1t4d0, c1t5d0
Group redundancy type : mirror
Continue adding devices to the volume 'my-mirror2'? (y/n) n

Create volume 'my-mirror2'? (y/n) y

Now you have two volumes. To allow for c1t3d0 to be a spare for the second
volume, in addition to the first volume, do the following:

nmc@myhost:/$ setup volume my-mirror2 grow spare c1t3d0

At this point each volume is using the device 'c1t3d0' as a spare. If a device
fails in either pool, the spare will be activated.

6.5 Adding Cache Devices

ZFS provides the Adaptive Replacement Cache (ARC) from main memory. The ARC is shared across all data volumes. Additional cache devices, also referred to as L2ARC, are assigned to a specific data volume.

In NMC you can add one or more cache devices to a data volume by clicking Grow in the data volume summary view. The Grow Volume page will appear showing you the available disks. Select one or more disks and then click the button “Add to cache”. You will see a view similar to the following screenshot:

You can then click “Grow Volume” to add the cache device to the volume.

Cache devices can improve your read performance for random I/O workloads.

6.6 Adding Log Devices

NexentaStor uses an intent log to meet POSIX requirements for handling synchronous writes.

By default, the intent log is a part of the main data volume, but you may be able to improve performance by moving it to a separate device such as a solid-state disk (SSD).

In NMC you can add one or more log devices to a data volume by clicking 'Grow' in the data volume summary view. The Grow Volume page will appear, showing you the available disks. Select one or more disks and then click the button “Add to log”. You will see a view similar to the following screenshot:

You can then click “Grow Volume” to add the log device to the data volume.

Note that it is recommended that you mirror your log device. Other types of redundant configurations are not supported.

6.7 Removing a Device

Cache, spare, and separate log devices can be removed from a data volume. To do this in NMC, use the command:

nmc:/$ setup volume <volumename> remove-lun

6.8 Replacing a Disk

If a disk in a data volume fails, you can replace it with another available disk. The following example shows how to do this using NMC:

nmc:/$ setup volume

Option ? mypool

Option ? replace-lun

LUN to replace : c1t1d0

LUN to use as a replacement : c1t4d0

Replace ‘c1t1d0’ with ‘c1t4d0’ in the volume ‘mypool’ ? Yes

This involves re-silvering the disk and can take some time. Using the NMC command:

nmc:/$ show volume <volumename> status

you will be able to tell, if the resilver is done or in-progress.

6.9 Taking a disk offline

If a disk in the data volume is having problems, it can be taken offline with the NMC command:

nmc:/$ setup volume <volumename> offline-lun

6.10 Recovering a previously disconnected disk

If a disk in the data volume was taken offline, but is now ready to be returned to the volume, then you can add it back with the NMC command :

nmc:/$ setup volume <volumename> online-lun.

Note that resilvering has to complete before the disk is fully online.

6.11 Replacing a Redundancy Group

You can replace a redundancy group with another group that is the same size or larger. If the data volume’s autoexpand property is on, then replacing all the groups with larger groups will expand the volume size.

To replace a redundancy group in NMC, use the command:

nmc:/$ setup volume <volumename> replace-lun.

6.12 Creating a Mirror

If you created a data volume without redundancy, you can later create a mirrored configuration. This is also true for a non-redundant separate log device. You can also add a mirror to a mirrored data volume.

The command to do this is:

nmc:/$ setup volume <volumename> attach-lun.

Note that the device being added must be at least as large as the existing device or redundancy group.

6.13 Detaching a Mirror

You can remove a device from a mirror by detaching it. To do this in NMC, use the command

nmc:/$ setup volume <volumename> detach-lun.

6.14 Re-attaching a Mirror

If you detached a disk temporarily from a mirror you can add it back in NMC using the command:

nmc:/$ setup volume <volumename> attach-lun.

7 Managing Folders

7.1 Create Folders

To create a folder in NMC use the command:

nmc:/$ create folder

To create a folder in NMV you can select the 'Create' link under the 'Folders' heading. You will see the screen below where you enter information such as the folder name, description, record size, and other properties.

De-duplication is off for the folder by default because it has a performance impact. Turn it on only if you expect to have duplicate blocks in this file system.

For case-sensitivity, the default choice is “mixed” which is optimal if the folder is going to be used in mixed CIFS and NFS environments.

7.2 View Status

After creating a folder you can monitor its status on the folder summary view. This view will show how much space is used and available, and also indicate if the folder is being shared via any sharing protocol.

7.3 Edit Properties

After a folder is created you can edit the properties by clicking on the folder’s name in the summary view.

In NMC you can see all folder properties using the command:

nmc:/$ show folder <foldername> property

To change a property use:

nmc:/$ setup folder <foldername> property <propertyname>

7.3.1 Logbias property

The 'logbias' property is specifically intended to improve database performance. The logbias property provides a hint to ZFS on how to handle synchronous requests. Note that database engines typically employ synchronous I/O when writing transaction logs. If logbias is set to 'latency' (the default), ZFS will use the volume's log devices (if available in the volume) to handle the requests at the lowest possible latency.

Typically, database transaction logs need the shortest latency. Therefore, use 'logbias=latency' on the corresponding NexentaStor folder or zvol that holds the database data. On the other hand, database data files need to be optimized for throughput. So, the appropriate setting is: 'logbias=throughput'.

If 'logbias' is set to 'throughput', ZFS will not use configured log devices.

This property can be set in NMC, as shown below:

nmc:/$ setup folder <foldername> property logbias
logbias : throughput

7.4 Destroy Folder

To delete a folder in NMC, use the command:

nmc:/$ destroy folder

A folder can be deleted in NMV from the folder summary view. Click on the delete icon to remove the folder.

7.5 Search & Indexing

NexentaStor supports the ability to index and later search folders and their snapshots. To start indexing a folder, click the Index checkbox on the folder summary view.

After selecting indexer, a dialog box will appear confirming that you want to create an indexer. Note that the indexer runs at a scheduled time, so searching immediately may not work.

7.6 Sharing Folders

NexentaStor can share folders using a variety of protocols including CIFS, NFS, WebDAV, RSYNC, and FTP. CIFS and NFS sharing are describing in the following sections.

7.6.1 Sharing Folders with NFS and CIFS

Sharing a folder with NFS or CIFS are each described in separate sections. If you plan to share a folder using both protocols, there are a couple property settings to be aware of.

When you create a new folder the default setting for casesensitivity is “mixed”. This will ensure the proper behavior if the folder will be shared via CIFS and NFS. You can change this property only at folder creation time.

Another important property is “nbmand”. NexentaStor will check this property when you share a folder via NFS that has already been shared with CIFS, or vice versa. If the property is off, you will be asked to change it to on.

CIFS protocol assumes mandatory locking and UNIX traditionally uses advisory locking so it is recommended to set the property 'nbmand' to 'on' in order to enforce mandatory cross-protocol share reservations and byte-range locking in a mixed NFS/CIFS environment.

For 'nbmand' property changes to take effect, the folder need to be remounted. Unmounting and mounting the folder again may cause a temporary loss of client connections. Note that you can remount manually any time later.

8 NFS File Sharing

8.1 Create NFS Share

You can use the NMC share command to share a folder via NFS.

nmc:/$ share vol1/a/b nfs

rw : group-engineering:10.16.16.92

ro : group-marketing

root : admin

extra-options:

8.2 Edit NFS Folder Properties

8.3 Mounting on Linux

Note that child file systems do not get mounted automatically. You need to mount each ZFS file system you're exporting via NFS separately.

9 CIFS File Sharing

9.1 Introduction

NexentaStor provides one of the best existing kernel and ZFS-integrated CIFS stacks, with native support for Windows Access Control Lists (ACL). This section explains how to use CIFS capabilities to share NexentaStor folders for:

1. Anonymous access

2. Non-anonymous access in workgroup mode

3. Non-anonymous access in domain mode

This section explains all 3 basic ways of using CIFS, and includes both NMC and NMV examples to illustrate the usage.

The appliance's CIFS service can operate in either:

• workgroup mode

or

• domain mode.

The related terminology to keep in mind is: “join workgroup” and “join Active Directory” (“join AD”). The corresponding operations are illustrated further in the section. CIFS service operational mode is system-wide, and it is either workgroup or domain. To state the same differently, NexentaStor cannot provide some CIFS shares to workgroup users and, simultaneously, other shares to users joined via Active Directory. By default, NexentaStor operates in workgroup mode. The default pre-configured workgroup name is: WORKGROUP.

In workgroup mode, the CIFS service is responsible for authenticating users locally when access is requested to shared resources. In domain mode, the CIFS service uses pass-through authentication, in which user authentication is delegated to an Active Directory domain controller.

Independently of whether you will use appliance's CIFS for anonymous access, non-anonymous (workgroup) or in domain mode, the very first step is to configure CIFS server. You can simply review and accept built-in system defaults.

Rest of this Section includes:

1. Configuring CIFS server (or reviewing the defaults)

2. Anonymous access

3. Non-anonymous access in workgroup mode

4. Non-anonymous access in domain mode

9.2 Configuring CIFS server

NMV provides a page to configure all network services, including CIFS (Data Management → Shares):

In NMV, you will find on this page a number of related links to configure, join workgroup, join active directory (Section “Using Active Directory”), unconfigure, and view the log file (see above).

The following screenshot illustrates viewing CIFS logfile:

In NMC, network services are configured via 'setup network service'.

The corresponding NMC command to view the log would be, respectively:

nmc:/$ show network service cifs-server log

The important screen, however, is CIFS Server Settings, which you get by clicking on the link denoted as Configure. In NMC, the corresponding command would be (see footnote):

nmc:/$ setup network service cifs-server configure

Here, make sure that the server is enabled, and specify a password for anonymous access.

	The default password is sent to you in email, along with the product Registration Key. For more information please see NexentaStor Quick Start Guide at http://www.nexenta.com/docs. It is important to change the default pre-configured password for anonymous access.

9.3 Anonymous Access

NexentaStor provides a unified view of all network shares and simple consistent way to share appliance's folders via NFS, CIFS, FTP, WebDAV, and RSYNC.

In NMV, go to Data Management → Shares:

In NMC, the corresponding commands are 'show share' and 'show folder' (or 'df'), for instance:

nmc:/$ show share

FOLDER CIFS NFS RSYNC FTP SAMBA

vdemo/a/b/c - Yes - - -

vdemo/new - Yes - - -

To share a folder, use 'share' command (NMC) or simply check the corresponding checkbox (NMV). In this example, we are sharing folder 'vol1/a/b/':

The operation is recursive – it'll share the folder and its sub-folders. Note that in the example above 'vol1/a/b/c' got shared as well.

This screenshot (see above) contains several important pieces of information:

Anonymous username The built-in anonymous username is: 'smb'. Unless you are using Active Directory (Section “Using Active Directory”), this is the name you will need to specify to access the share. Note that anonymous read/write access is enabled by default. To view or change the default settings, click on the Edit link to the right of the corresponding checkbox (see picture above). Anonymous password If you forgot the password, please in NMV go to CIFS Server Settings (under Data Management → Shares), click on Configure, and re-enter the password. In NMC, the corresponding command would be: nmc$ setup network service cifs-server configure Share name: By convention, a folder named 'volume-name/folder-name' becomes a CIFS share named 'volume-name_folder-name'. That fact is reflected on the previous screenshot: 'vol1/a/b' will be visible on CIFS clients under name 'vol1_a_b' (see above). You may change the appliance's generated CIFS share name by simply editing the corresponding field.

Next, on Windows machine go to 'My Computer' → 'Tools' → 'Map Network drive' and fill the corresponding field with appliance's hostname or IP address.

The very first time, login will be required:

If you forgot the password, please go to CIFS Server Settings (under Data Management → Shares), click on Configure, and re-enter the password. In NMC, the corresponding command would be:

nmc:/$ setup network service cifs-server configure

After successful authentication, the shared folders will show up:

Depending on your Windows version, you could modify the ACL of these directories using Windows ACL editor (Right click → Properties → Security tab).

Assuming anonymous access is enabled, we can now start using the NexentaStor folders as Windows directories:

9.4 Non-anonymous access, workgroup mode

The very first and absolutely essential step is making sure that the CIFS server operational mode is: WORKGROUP. Please make sure to join the proper workgroup.

	Not using the right operational mode leads to confusion and mistakes. Please see the following F.A.Q. article for more information: How do I share appliance's folders for access from Windows?

The basic facts to keep in mind are:

Operational mode: NexentaStor supports both workgroup mode and domain mode. For the latter, see Section “Using Active Directory” in this document. Group name: By convention, the pre-configured group of CIFS users is: WORKGROUP. If this group name works for you, you do not need to change anything. Otherwise, to change the default: In NMV go to Setting => Network and click on Join Workgroup link In NMC, run: nmc$ setup network service cifs-server join_workgroup Share name By convention, a folder named 'volume-name/folder-name' becomes a CIFS share named 'volume-name_folder-name' (see previous Section). You may change the appliance's generated CIFS share name by simply editing the corresponding field. User name The built-in anonymous username is: smb (see previous Section). Non-anonymous user accounts must be added as regular appliance's Unix users as demonstrated in step (A) below (see also Section “Notes on User Management and Access Control”)

Rest of this section – steps (A) through (E) below – demonstrate how easily this can be done, and provides NMC and NMV examples.

(A) Let's first create appliance's user named 'alice'. In NMC:

nmc:/$ setup appliance user

Option ? create

New User : alice

Home folder :

Description :

Default group : other

Password : xxxxxx

Confirm password : xxxxxx

This newly created user shows up in NMV, which can certainly be used to create users in the first place:

(B) Next, we share an appliance's folder for access from Windows machines. Notice: this time we set anonymous access to false (compare with the previous section “Anonymous Access”):

nmc:/$ share folder vol1/a

show cifs ftp nfs rsync webdav <?>

nmc@zhost:/$ share folder vol1/a cifs

Share Name : vol1_a

Anonymous Read-Write : false

Recursive : true

Added CIFS share for folder 'vol1/a'

The folder 'vol1/a' is now CIFS-shared, and can be seen as shared via NMC and NMV:

(C) Let's login from Windows as user 'alice':

	Use correct user password to login. In our current example, the password for user 'alice' was specified at user creation time (see step (A) above).

Once logged in as 'alice', the appliance's folder and its content shows up:

Note that at this point user 'alice' can read but not write.

	Read access to CIFS-shared folders is granted by default. Write access need to be explicitly granted – via the corresponding operation on the shared folder's ACL.

The following NMC command shows folder's ACL (for more information on Access Control, see Sections “Notes on User Management and Access Control” and “User, Group and ACL Management”):

nmc:/$ show folder vol1/a acl

=============== vol1/a (user owner: root, group owner: root) ===============

ENTITY ALLOW DENY

owner@ add_file, add_subdirectory,

append_data, execute,

list_directory, read_data,

write_acl, write_attributes,

write_data, write_owner,

write_xattr

group@ execute, list_directory, add_file, add_subdirectory,

read_data append_data, write_data

everyone@ execute, list_directory, add_file, add_subdirectory,

read_acl, read_attributes, append_data, write_acl,

read_data, read_xattr, write_attributes, write_data,

synchronize write_owner, write_xattr

(D) Next, we grant write access to user 'alice' using NMC 'setup folder <name> acl' command:

nmc:/$ setup folder vol1/a acl Entity type : user User : alice Permissions : (Use SPACEBAR for multiple selection) DELETE *add_subdirectory *add_file *execute *read_xattr *read_attributes *list_directory *read_data *read_acl *delete delete_child inherit_only no_propagate file_inherit dir_inherit *write_data *write_xattr write_owner write_attributes write_acl ----------------------------------------------------------------------------- Select one or multiple permissions for 'user:alice' to access 'vol1/a'. Hit DELETE to delete all permissions granted to 'user:alice'. Navigate with arrow keys (or hjkl), or Ctrl-C to exit.

In the example above '*' marked extended attributes indicate permissions that were selected for granting 'alice'. In this particular example we are granting 'alice' almost all permissions...

For more information, please see Section “Notes on User Management and Access Control”.

Newly added permissions show up in Nexenta Management View GUI, which (as always) can be used to grant permissions in the first place:

(E) At this point user 'alice' can write. For instance, drag and drop a PDF file into the shared folder:

Do not use name based mapping in workgroup mode. If you do, the mapping daemon (called idmap) will try to search Active Directory (next Section) to resolve the names, and will most probably fail. See “Using Active Directory” for details. For more information, please make sure to review NexentaStor F.A.Q. pages (searchable by keywords, for instance “cifs” or “CIFS”), and/or Section “Frequently Asked Questions” in this document.Next Section details NexentaStor usage in domain mode, via Active Directory. In particular, see the following F.A.Q. article: How do I share appliance's folders for access from Windows?

9.5 Using Active Directory

Active Directory (AD) is an implementation of LDAP directory services (Sections “LDAP integration”, “Using LDAP”) by Microsoft for use primarily in Windows environments. AD purpose is providing central authentication and authorization services for Windows-based computers. In addition, Active Directory supports deploying software and assigning policies on a level of organizations.

	Prior to using AD, the first step would be to configure appliance's native CIFS server, as described above (Section “5. CIFS: Tutorial”, sub-section “Configuring CIFS server”).

	For more information on Active Directory, search NexentaStor F.A.Q. pages on the website, and in particular: How do I integrate NexentaStor into my ACLs or my Active Directory domain? See also Section “Frequently Asked Questions” in this document.

Note some of the environment related requirements: Time must be accurate between AD server and the NexentaStor NAS to join DNS servers, search, and domain values need to match what the AD server expects

Please note one sometimes repeated mistake: for the join to succeed, the appliance must be setup so that the Active Directory Domain is the same as the DNS Domain of the appliance. In general, Active Directory functionality depends on the proper configuration of the DNS infrastructure. Microsoft Knowledge Base article "Troubleshooting Active Directory—Related DNS Problems" describes the corresponding requirements. Those include DNS server and zone configuration and proper delegations in parent DNS zones, and presence of DNS domain controller locator records (SRV records). These and other guidelines are further described in the User Guide.

To start using AD, you first need to make NexentaStor appliance to become a member server. In AD terms that particular operation is often called join or join-ads.

The second step requires identity mapping. Rest of this section illustrates both steps.

9.5.1 Joining Active Directory

The process of adding NexentaStor appliance to Windows Active Directory (or, joining an Active Directory) has two different scenarios:

1. NexentaStor computer object is already registered with the Active Directory

2. NexentaStor computer object is not present in the Active Directory

It is important to distinguish between these two cases. In general, creating a new record in the Active Directory database requires administrative privileges.

If the computer object that represents NexentaStor appliance is already present in the Active Directory, you can use any valid user account to join the appliance to Active Directory – assuming this particular account has Full Control over this particular computer (appliance). Importantly – in the case of the pre-existing computer object in the AD, account used to join the appliance to the Active Directory does not necessarily need to have administrative privileges.

The following assumes that NexentaStor appliance is not present yet in the Active Directory database. The very first step in this case is for the Windows Administrator to create a corresponding computer object. In more detail:

Step 1. Start Microsoft Management Console, right click on Computers, and select New:

Step 2. Specify NexentaStor appliance – by hostname:

Step 3. Once the computer is added, right click on it and select Properties:

Step 4. Optionally, add users/groups that will use this computer and will perform join operation. Click on Security tab, type in user (or group) name, and click on Check Names button.

Make sure to provide the newly added computer users with Full Control over this computer.

	Using Microsoft Management Console and performing Steps 1 through 4 (above) can be skipped in either one of the following two cases: Account with administrative privileges is used to perform join operation. A record of computer object representing appliance already exists.

The rest of this section assumes that either (1) or (2) above (or both the (1) and the (2)) are true.

To join Active Directory, and subsequently get access to centralized authentication and authorization information, go to NMV's Settings → Network and click on Join AD/DNS Server:

NMC provides a similar functionality, via 'setup network service cifs-server join-ads':

nmc@testbox1:/$ setup network service cifs-server join_ads DNS Server IP address, port : 216.129.112.28 AD Server IP address, port : 216.129.112.28 AD Domain Name : nexenta-ad.nexenta.com AD Join User : Administrator AD Join Password : xxxxxxxxx

Successful join is persistent across reboots.

Note that when connecting to a 2008 domain controller, an additional step is needed which can be done only in the Unix shell:

nmc:/$ option expert_mode=1 –s

nmc:/$ !bash

$ sharectl set –p lmauth_level=2 smb

Successful join, or a failure to join Active Directory – both manifest themselves with the corresponding NMC printed messages, or NMV messages in its status bar (see the next two screenshots):

Failure to join AD can be further investigated.

For troubleshooting, the first place to look would be the log files under NMV's Settings → Network → View Log

Notice the listbox (picture above) that allows to choose one of the associated logs. In NMC, the corresponding command:

nmc:/$ show network service cifs-server log

This command has two “completions” (Section “Navigation”): 'network-smb-server:default.log' and 'messages'. Select 'messages'; the following shows an example of 'messages' log:

Nov 5 12:04:06 testbox1 smbd[16289]: [ID 528497 daemon.debug] SmbRdrNtCreate: fid=49160

Nov 5 12:04:06 testbox1 smbd[16289]: [ID 702911 daemon.debug] server=[\\nexenta-win] account_name=[TESTBOX1$] hostname=[TESTBOX1]

Nov 5 12:06:01 testbox1 smbd[16289]: [ID 208731 daemon.debug] NEXENTA-AD<1B> flags=0x0

Nov 5 12:06:01 testbox1 smbd[16289]: [ID 757673 daemon.debug] 216.129.112.28 ttl=149438 flags=0x0

Nov 5 12:06:01 testbox1 smbd[16289]: [ID 208731 daemon.debug] TESTBOX1<20> flags=0x1

Nov 5 12:06:01 testbox1 smbd[16289]: [ID 757673 daemon.debug] 216.129.112.18 ttl=600 flags=0x1

Nov 5 12:06:01 testbox1 smbd[16289]: [ID 757673 daemon.debug] 1.1.1.1 ttl=600 flags=0x1

Nov 5 12:06:03 testbox1 smbd[16289]: [ID 208731 daemon.debug] NEXENTA-AD<1D> flags=0x0

Nov 5 12:06:03 testbox1 smbd[16289]: [ID 757673 daemon.debug] 216.129.112.28 ttl=149434 flags=0x0

Further troubleshooting can be done by investigating service configuration files. Currently this can be done only via NMC.

To view CIFS server configuration, run 'show network service cifs-server settings':

nmc:/$ show network service cifs-server settings

krb5.conf resolv.conf smbautohome

------------------------------------------------------------------

Select cifs-server configuration file for viewing. Navigate with arrow keys (or hjkl), or Ctrl-C to exit.

There are 3 associated configuration files (see above). Advanced users can edit these files as follows:

nmc:/$ setup network service cifs-server settings

krb5.conf resolv.conf smbautohome

------------------------------------------------------------------

Select cifs-server configuration file for viewing. Navigate with arrow keys (or hjkl), or Ctrl-C to exit.

9.5.2 CIFS shares

After joining Active Directory, use the regular 'share/unshare' functionality to share (and unshare) appliance's folders for Windows users.

In NMC you would use the same generic 'show share', 'share' and 'unshare' commands. For example:

nmc@testbox1:/$ show share

FOLDER CIFS NFS RSYNC FTP WEBDAV SAMBA

vol1/a Yes Yes - - - -

vol1/a/b Yes Yes - - - -

nmc@testbox1:/$ show folder vol1/a share cifs -v

PROPERTY VALUE

folder vol1/a

share_name vol1_a

comment ""

anonymous_rw true

PROPERTY VALUE

folder vol1/a/b

share_name vol1_a_b

comment ""

anonymous_rw true

In NMV, to display or change existing CIFS shares, or add new ones, go to Data Management → Shares:

NMV page Data Management → Shares is the single point of control that allows to create folders with a given set of properties, and destroy existing folders.

Folders can be filtered by name – see the Filter button at the bottom of the screenshot (below). Folders can be shared via CIFS (as well as NFS, FTP, RSYNC, and WebDAV).

In addition, the same page is used to view and configure CIFS server settings (see left panel below). All this power and flexibility is available via NMV Data Management → Shares page:

To configure any given share, first enable it (checkbox in the CIFS column above). This will automatically share the folder using default system settings. You can view and modify those settings by clicking on the Edit link to the right of the checkbox, as shown below:

9.5.3 ID mapping

User name equivalence between Windows users and groups and their counterparts in the UNIX is established via appliance's 'idmap' facility. The 'idmap' mappings persist across reboots. To use CIFS shares for non-anonymous access, please make sure to establish the mapping.

To map Windows users/groups onto UNIX users/groups, go to NMV's Settings => Network and click on the Identity Mapping link:

The example above shows several identity mappings. Group of Windows users called “Domain Users” is mapped onto Unix group 'staff'. Windows user 'joe' is mapped onto Unix user 'joe', and Windows user 'Alice' – onto user 'alice'. All mappings are bi-directional in this case – notice the '==' sign in the table above.

NMC provides a similar functionality, via 'setup network service cifs-server idmap':

nmc:/$ setup network service cifs-server idmap Mappings Rules : ------------------------------------------------------------------- Comma-delimited list of name-based mapping rules. Rule-mapping format is as follows: windows-name[=>|<=|==]unix-name, ... Formats of names one of [winname:|winuser:|wingroup:|unixuser:|unixgroup:]. For unidirectional mapping use [=>|<=]. Use '*' for pattern matching. This field required to be filled in. Press Ctrl-C to exit.

Windows user name must be specified by using one of the following formats: winuser:username@domain-name winuser:'domain-name\username' Unix user name must be specified in the following format: unixuser:username Note that Windows user names are case insensitive, while Solaris user names are case sensitive. Examples: a) map all users in the domain mydomain.com: winuser:'*@mydomain.com'==unixuser:'*' b) map Unix user 'joe' to Windows user Joe in the domain mydomain.com: winuser:'Joe@mydomain.com'==unixuser:joe

ID mapping takes an effect immediately. Following is an example of the file titled “New Text Document.txt” created by Windows user in the CIFS-shared appliance's folder 'vol1/a/b':

nmc:/$ ls -l vol1/a/b/ total 2 ----------+ 1 admin 2147483650 12 Nov 4 22:11 New Text Document.txt

Notice that Windows Administrator is mapped here onto Unix admin.

The following sequence of screenshots shows how to:

1. add new domain user named 'joe' via Windows native GUI

2. join AD as 'joe'

3. map 'joe' => Unix 'admin' user

1) adding new domain user named 'joe' via Windows native GUI:

2) joining AD as 'joe':

3. mapping 'joe' → 'admin'. In effect, 'joe' will have 'admin' permissions as far as working with CIFS shares.

   
   

9.6 Troubleshooting Active Directory

1. Start from scratch. Unshare existing CIFS shares, if any. Remove existing idmap mapping rules, if any. On the Windows side, if you are logged in, please log out. Use Microsoft Management Console to create a new computer object that represents the appliance, as described in the User Guide, Section "Joining Active Directory".

2. DNS. Active Directory functionality depends on the proper configuration of the DNS infrastructure. Please note one sometimes repeated mistake: for the join to succeed, the appliance must be setup so that the Active Directory Domain is the same as the DNS Domain of the appliance. Microsoft Knowledge Base article "Troubleshooting Active Directory—Related DNS Problems" describes the corresponding requirements. Those include DNS server and zone configuration and proper delegations in parent DNS zones, and presence of DNS domain controller locator records (SRV records). These and other guidelines are further described in the User Guide.

3. NTP. Time must be accurate between AD server and the NexentaStor NAS to join. To configure NTP, run 'setup appliance nms property default_ntp_server' from NMC (CLI), or use the corresponding NMV (web GUI) page.

4. Join Active Directory. The steps are described and illustrated in the User Guide, Section "Using Active Directory". For troubleshooting, please refer to the next Section (below). If you are trying to join Windows 2008 domain, please also see a special note on that in the next section.

5. User Management. The main question at this point would be: centralized user database OR local users. The following few steps until the step #9 describe how to work with local users and groups. Please skip to step #9 if you intend to manage users, groups and permissions solely through the AD Domain Controller. Otherwise: create new Unix user, say 'joe'.

6. Assuming, you are using local Unix users - Add a mapping rule, to map a Windows user onto the Unix user. As always, this can be done both via NexentaStor CLI (NMC) and web GUI (NMV). First time users - please use NMV. Note also that in production environment Windows <=> Unix ID mapping needs to be approached with a certain planning. See Identity Mapping Administration (Tasks) for more information.
   Please note: AD user shows up in the appliance after being "idmap-ed" in. Once identity mapping is established, you can then use the resulting Unix username to assign ACLs on a per folder base.

7. Assuming, you are using local Unix users - Double check that the users are visible through the UI. Use for instance NMC command 'show appliance user'

8. Assuming, you are using local Unix users - Add permissions for the Unix user to read/write a given appliance's folder. For illustration purposes, let's assume the folder in-question is called 'vol1/a'. You would need to create a new ACL entry in this folder's ACL, specifying permissions for the user 'joe123' (see step 5 above). Note that this locally created ACL gets used by the native CIFS server after you share this folder ('vol1/a' in this example) via CIFS.
   In other words, by virtue of the fact that you have created a local ACL entry and mapped a Windows user onto UNIX user, you in fact enabled this Windows user to access the corresponding folder, with the permissions specified in this (locally created) ACL. For more information, please see NexentaStor User Guide, Section "Notes on User Management and Access Control". You can also access this section on-line here.

9. On the Windows side, (use your Windows computer to) log into Active Directory domain. Presumably, you are using at this point the same Windows user name that was specified in the mapping rule at step #6 (above).

10. Optionally, map drive Z: (or any other available drive letter) onto [hostname]/[share]. You can also access this shared folder using Windows Uniform Naming Convention (UNC), as \\hostname\share. The hostname here is certainly a DNS resolvable host name of the NexentaStor appliance, and the share is the name of the CIFS share. Note that default naming of CIFS shares simply substitutes forward slash '/' with underscore '_'. In the example above (see step 6), the default CIFS share name for the folder 'vol1/a' would be: 'vol1_a'. This is further described in the the User Guide, Section "CIFS: Tutorial".

9.6.1 Additional troubleshooting tips

• Enable extensive debug-level system logging:

nmc:/$ setup appliance nms property sys_log_debug

System log is a facility used by various sub-systems, including CIFS. All sub-systems log their failures and messages in accordance with the current verbosity level. Use the command above to enable detailed debug-level system logging, and try to perform join Active Directory operation (for instance). You can then review system log via:

# dmesg

Note also that the system log is automatically emailed to the product's Technical Support team (Section “Documentation – Registration – Support”)

• As stated above, correct DNS configuration is important. One typical error that happens when the DNS settings are not correct is recorded in the system log as: "failed to find any domain controllers". This error indicates that the DNS SRV RR lookup for DCs of the specified domain has failed. As the very first troubleshooting step, confirm that a correct DNS server has been specified during join AD operation via NMC (CLI) or NMV (web GUI). Next, assuming the domain name is 'mydomain.com', make sure '_msdcs.mydomain.com' record is present in the DNS database under 'dc._tcp._ldap'

Note that being able to resolve hostname to the IP address of the domain controller does not necessarily mean that the DNS configuration is correct.

• To join Windows 2008 domain, please run:

# sharectl set -p lmauth_level=2 smb

For more details (and more troubleshooting tips), see CIFS Service troubleshooting.

• Review generated and saved configuration files.

There are two configuration files that play a critical role in joining the AD: /etc/resolv.conf and /etc/krb5/krb5.conf

When you are trying to join Active Directory, the management software - behind the scenes - modifies these two files accordingly. If (and only if) the join is unsuccessful, the modifications are discarded.

However. To assist with troubleshooting, the two modified files are stored at a temporary location, as:

/tmp/.nms-resolv.conf.saved

/tmp/.nms-krb5.conf.saved

If the join is not successful, please review these two files.

• Use 'nslookup' or 'dig' commands to validate AD/DNS configuration:

  # dig @[DNS IP] _ldap._tcp.dc._msdcs.[DOMAIN] SRV +short

where [DNS IP] is your actual DNS IP address, and [DOMAIN>] stands for domain name.

For instance, assuming 1.1.1.1 is the DNS IP address:

# dig @1.1.1.1 _ldap._tcp.dc._msdcs.mydomain.com SRV +short

• Make sure that CIFS service operates in Active Directory mode (see Section above).

• Use ldaplist to test LDAP/AD user/group database

# ldaplist -l passwd <name of AD user>

# ldaplist -l group <name of AD group>

This command should return UID and GID numbers.

• Validate Kerberos configuration:

# kinit <name of AD user>

A successful Kerberos test will not return any feedback, and the 'klist' command will show a ticket granting ticket (TGT) from the Active Directory DC/KDC.

Similar to 'nslookup' or 'dig', this command needs to be executed using the modified (but not committed) Kerberos configuration. Here, again - first, try to join AD. If (and only if) the join is unsuccessful, use /tmp/.nms-krb5.conf.saved instead of /etc/krb5/krb5.conf. And then, try the 'kinit' and/or 'klist' command.

10 Managing Snapshots

Snapshots are read-only, point-in-time representations of a file system or zvol. Because of the copy-on-write nature of ZFS, snapshots can be created instantaneously.

10.1 Create Snapshot

Before making significant changes to a folder, you may want to create a snapshot so that you can recover to this point in time if anything goes wrong. You can create a new snapshot in NMV from the “Data Sets” subtab under the Data Management tab. Under the “Snapshots” heading choose “Create” and you will see the following screen:

Enter the name of the snapshot (e.g. mypool/myfolder@now) and indicate whether child folders should be included, and then click “Create”. The snapshot is taken immediately, and will appear if you then click “Show” under the Snapshots heading on this page.

10.2 Setup Periodic Snapshots

NexentaStor can automatically take snapshots of a folder or zvol on a periodic basis. To set up a snapshot schedule in NMV, use the “Auto Services” subtab under the Data Management tab. Then choose “Create” under the “Auto-Snap Services” heading and you will be presented with a page similar to the following:

Here you can chose the name of an existing dataset, and specify the schedule: periodic interval, number of days to keep the snapshots, exceptions, trace level. If you need to include subfolders to the snapshots, check recursive. After selecting the desired options, click Create Service.

10.3 View Snapshots

To view all existing snapshots in NMV, go to Data Sets page and click on “Show” under the “Snapshots” heading. You will see a page similar to the following:

From this view you can clone a snapshot or rollback a folder or zvol to this point in time.

10.4 View Scheduled Snapshots

To ensure that you scheduled your snapshots correctly in NMV, you can view all the scheduled snapshots and verify that your new entry is present. To see the summary list, select “Show” under “Auto-Snap Services”.

From this view you can delete the periodic snapshot or edit the snapshot service. One useful option available from the edit screen is to take a snapshot immediately.

10.5 Recover Snapshot

To recover a file system from a snapshot you first create a clone. Clones are read-write copies of a file system and are based on a snapshot. The origin snapshot cannot be destroyed if a clone exists.

10.6 Delete Snapshot

When viewing existing snapshots you can select a snapshot and then delete it. Note that because of the copy-on-write nature of NexentaStor and ZFS, deleting a snapshot will not necessarily free additional space in the folder.

11 SCSI Target (Managing Blocks)

A SCSI Target is a generic term used to represent different types of targets such as iSCSI or Fibre Channel. SCSI Target accesses all of the different types of targets in the same way and hence allows the same zvol to be exported to any type of target (or to multiple targets at once).

Configuring a target means making it available to the system. This process is specific to the type of target being configured.

11.1 Create Zvol

A Zvol is an emulated block device contained within a data volume. Zvols provide an easy way to expose SCSI Targets to hosts. For example, a zvol can serve as the backing store for an iSCSI target. A zvol can also be used as a swap partition.

Storage services such as snapshotting and replication can be used with zvols.

Thin provisioning is supported for zvols, meaning that storage space is allocated on-demand. Here is an example using NMC to create a 5TB zvol named zvol1 within the data volume vol1:

nmc:/$ create zvol vol1/zvol1 -S -s 5TB

Alternatively, you can type 'create zvol' and follow the prompts to complete the request.

In NMV you can create a zvol on the “SCSI Target” page. You will be prompted for the data volume that will contain the new zvol, the zvol name, an optional description, and whether the zvol will have space initially reserved. The block size and maximum size is also specified. You can indicate whether the zvol data should be compressed on the backend storage and how many redundant copies should be stored.

Here is an example in NMC of setting up periodic snapshots for the zvol:

nmc:/$ create auto-snap zvol vol1/zvol1

You will then be asked to provide the snapshot frequency, retention policy, etc.

Zvol can be thin provisioned, and can be grown over time, both in terms of its effective and maximum size. A thin provisioned (also called "sparse") zvol does not allocate its specified maximum size. At creation time a thin provisioned zvol actually allocates only a minimum required to store its own metadata.

You can grow both the effective (actually used) size of the zvol by storing more data on it, and the maximum size of the zvol, by incrementing its property called 'volsize'. In NMC, the latter is done via:

nmc:/$ setup zvol <zvol-name> property volsize

You can change 'volsize' property anytime.

Be careful shrinking a zvol. If you indicate a zvol size less than it is currently using, it may cause a data lost.

A similar function is available via the NMV web GUI.

11.2 View Zvol Properties

If a zvol is being shared over iSCSI and/or FC as a SCSI disk, the writeback caching for that disk can be Enabled or Disabled. When writeback caching is enabled, the disk performs better on writes but the data is not flushed to the backing store of the zpool before a write I/O is completed to the initiator. Disabling writeback caching will always ensure that data is flushed to stable storage before a write is completed. But doing so will reduce the disk write performance.

To control writeback caching select 'SCSI Target → 'View (Zvols)'. Click on the zvol name and its properties will show up. Select the desired writeback caching mode from the drop down list.

11.3 Destroy a Zvol

To destroy a zvol in NMC, use the command:

nmc:/$ destroy zvol

11.4 Add initiators and targetsa

The configuration of initiators and targets is protocol-specific. iSCSI is shipped by default with NexentaStor and is described in the section “Managing iSCSI”. Other protocols are beyond the scope of this document.

11.5 Create initiator group

You can share a zvol with all remote initiators. In this case you do not need to create any initiator groups. If you want to control which initiators can see a zvol, then you need to create one or more initiator groups. Even if you intend to associate only a single initiator with a zvol, the initiator needs to be in an initiator group.

To create an initiator group in NMV, click the link “Initiator Groups”.

Provide a group name and a list of remote initiators for this group, and then click Create.

11.6 Create target group

You can associate a zvol with a set of targets by putting the targets in a target group. Target groups are not required. The following screen in NMV shows how to create a target group. You simply choose a group name and select the targets to be in the group.

11.7 Create LUN mappings

LUN mappings allow you to control which remote initiators can see a zvol. A zvol is not accessible over the SAN until it has been mapped.

Here is an example in NMV of creating a LUN mapping for a zvol:

Instead of defining and choosing initiator and target groups, you can simply select “All”. However, remote iSCSI initiators will not find this target if you haven’t defined at least one iSCSI target.

When creating a LUN mapping you can choose a specific LUN id or let NexentaStor assign one automatically.

12 Managing iSCSI

You can set default authentication and registration options by clicking the “Defaults” under the iSCSI heading. For authentication, you can choose CHAP, RADIUS, or none. You can also indicate whether configured targets should be registered with iSNS.

12.1 Add remote initiator

Add remote initiators if you want to control which initiators can see individual zvols. You can specify CHAP authentication information for each remote initiator.

12.2 Create iSCSI target

If you map a zvol for iSCSI, the remote initiator won’t see it unless you have defined at least one iSCSI target.

In NMV, you can create an iSCSI target by selecting Targets under the iSCSI heading on the SCSI Target page, and then clicking Create. You will see this page:

If the name is left blank then an IQN will be automatically assigned by NexentaStor.

Other fields such as Alias and a CHAP user/secret can also be entered. The CHAP user/secret specified here is used for bidirectional CHAP only. For the non-bidirectional CHAP authentication (The usual case), the CHAP parameters are specified for the initiator on the Initiators page and not here. Finally, clicking on Create button will create the target.

Unless Multiple Targets are needed for a more advanced configuration, this step is only needed once. All the SCSI LUNs created and exported afterwards, will be exposed on the iSCSI SAN via this target.

12.3 Create iSCSI target portal group

A target portal group can be associated with a target to further specify the IP address and port that should be used for a target.

12.4 Setting up CHAP Authentication

The Challenge-Handshake Authentication Protocol (CHAP) is used for authentication of iSCSI initiators and targets. In standard CHAP, the target authenticates the initiator. With bi-directional CHAP (aka mutual CHAP), the initiator also authenticates the target.

For NexentaStor iSCSI target, when using standard CHAP, the CHAP secret is set on a per initiator basis. Thai is, for every initiator logging into a NexentaStor iSCSI target (CHAP enabled), the user needs to create an initiator and set its CHAP secret. The CHAP secret for target is only set when using bidirectional CHAP authentication.

The use case shown below shows how to set the CHAP secret for a Microsoft iSCSI initiator. Here are the steps:

1. Create a target with auth method set to chap. Or if the target is already created, update it and set auth method to chap.

2. Create a remote initiator and provide its CHAP secret (you can also specify its CHAP user name. However for most cases that is not required).

3. Set the same CHAP secret (as set in step #2 above) on the initiator side.

4. To create a target with CHAP on, Create the target as described before and select 'Auth Method' chap from the drop down list. Do not enter CHAP secret here unless you want to use bidirectional CHAP authentication.

Next create the initiator by selecting 'SCSI Target'->Remote Initiators. Enter the iSCSI name of the initiator. For Microsoft iSCSI initiator, the initiator name is available under 'General' tab of the Microsoft initiator UI. Now enter a CHAP secret for this initiator. The CHAP secret has to be a minimum of 12 characters. Click 'Create' to create the initiator with CHAP secret.

Now go to the Microsoft Initiator UI and discover this target (This is mostly done by entering the IP address of the NexentaStor appliance under the 'discovery → 'target portal' and then going under the 'Target' tab and clicking 'Refresh').

Select the newly discovered target and click 'LogOn'. In the 'Log On to Target' screen, click 'Advanced...'. Now select Chap Log on information and enter the target secret (same as what was set for the initiator created above). Now, click OK and again OK to logon to the target. At this point the Initiator should be able to logon to the target using CHAP Authentication.

13 Asynchronous Replication

The continuing growth of disk based storage has had two primary affects. The amount of data to backup is increasingly difficult to fit onto tape or within a backup window, and the costs of capacity of storage makes it feasible to build online backups out of disk subsystems themselves. One of NexentaStor’s primary uses is in this new digital archiving role. Whereas tapes will always find use, the development of disk based backup systems regulates tape to the final tier of archiving, where offline preservation is the requirement. You will find this product fits many roles, including primary storage, secondary storage to any primary storage array, and even remote site replication and archival.

What makes multi-tier storage possible in Nexenta’s solution is the “auto-tier” service, which can regularly copy data from one source, local or remote of any nature, to a destination target again of any type. The only limitation is that at least one of either the source or destination must be local. In large arrays where the appliance encompasses both first tier and second tier storage, you’ll even see local-to-local tiering. Tiering is accomplished by taking a given filesystem or share, breaking into smaller manageable chunks, and replicating that data at that point in time to another volume. Using snapshots at the target end, one can maintain a full efficient backup of the primary storage at unique intervals typical of backups. Whereas you may have hourly and daily snapshots on your primary NAS, auto-tiering with snapshots will generally have daily, monthly, and even yearly snapshot points, with the same policies for retention of any given periodicity.

One commonly sets up tiering locally, over NFS or CIFS, or using rsync directly with or without SSH. A simple example of tiering data from an NFS file server to our example volume would be to first create a filesystem to tier to and then to setup an auto-tier from our source NFS server.

Auto-tier and auto-sync are not limited just to the first two tiers, as tertiary tiering for more critical data is also common. As legal and business drivers dictate, tiering will also include access policy enforcement, limiting data access to restricted personnel to over longer periods of time.

As either a primary or secondary storage server, NexentaStor can pull or push data regularly at arbitrary intervals, transferring only the periodic changes seen. This can be done as frequently or as sparingly as required, thus being ideal for both large tiering as well as replication needs or for providing WAN-base off site mirroring.

NexentaStor provides the complete range of data replication services:

Auto-Tier - In the case of "auto-tier" (or simply, tiering) service, NexentaStor makes use of snapshots and user definable source and destination points to regularly replicate a single copy of a file system to another storage pool, whether local or remote. Using snapshots on the target end, the tiered copy may have arbitrarily different retention and expiration policies and can be administered separately. NexentaStor tiering service runs on a variety of transports, and can use snapshots as its replication sources. This solution fits the more common backup scenarios found in disk-to-disk backup solutions. The auto-tier service is not limited just to the first two tiers, as tertiary tiering for more critical data is also common. As legal and business drivers dictate, tiering will also include access policy enforcement, limiting data access to restricted personnel to over longer periods of time.

Auto-Sync - Another option provided is the "auto-sync" (or simply, syncing) service, which will maintain a fully synchronized copy of a given volume, file system, or emulated block device (a. k. a. zvol, Section “Using ZVOLs”) on another NAS. Where tiering provides a copy, auto-sync provides a true mirror, an exact replica of data, inclusive of all snapshots and file system properties. Auto-sync uses the built-in ZFS snapshot capability to efficiently identify and replicate only changed blocks. This allows central mapping of multiple snapshots of a file system onto remote storage, all the while maintaining control of the retention and expiration of that data at the replication source. This facility is the most ideal for full disaster recovery.

Hybrid-tier/sync - NexentaStor provides a hybrid tiering-syncing service which enables a history of changes on the tiering destination. Unlike regular backup solutions with only the latest copy available on the backup target, this solution would have the advantage of both "the latest copy" and a configurable number of previous copies - the latter in accordance with the retention policy.

And still in addition, you could tier from a snapshot, which provides the best combination of transactional snapshot at the source combined with potentially faster transport to copy the data without risking that it is being modified concurrently.

See also:

Section “Frequently Asked Questions”

F.A.Q. entry: What is the difference between 'auto-sync' and 'auto-tier' storage services?

13.1 Auto-Sync

The NexentaStor auto-sync service transfers snapshots between storage systems. The service is built on the ZFS send/receive capability. It assumes that the source and target systems are using ZFS.

Auto-sync replicates dataset snapshots and can be configured to send only the incremental changes. A key advantage is that it also replicates the dataset properties.

To setup an auto-sync service in NMV, select “Auto Services” under the Data Management tab and then select Create under the Auto-Sync Services heading.

The auto-sync service includes a de-duplication capability for the data transfer. Both the sending and receiving systems need to support de-duplication. By using de-duplication you may be able to reduce the amount of data sent across the network. As blocks are sent, if they are a duplicate then only a reference is sent instead of the full data block. This can be especially beneficial over slow or expensive network links. De-duplication is managed separately for each auto-sync replication stream.

13.1.1 Additional Options

The following additional options can be specified when setting up the auto-sync service:

• Trace level

• Rate limit

• Auto-mount location

• Force replication

• Auto-clone

• RSYNC options

• Service Retry

13.2 Auto-Tier

To setup an auto-tier service in NMV, select “Auto Services” under the Data Management tab and then select Create under the Auto-Tier Services heading.

13.2.1 Additional Options

The following additional options can be specified when setting up the auto-tier service:

• Trace level

• Rate limit

• RSYNC fanout

• Tiering snapshot

• Exclude folders

• RSYNC options

• Service Retry

14 Synchronous Replication (Auto-CDP)

NexentaStor provides synchronous replication through an option plugin module called Auto-CDP (Automatic Continuous Data Protection). Remote mirroring is provided at the block level between two NexentaStor appliances.

The following table provides a feature summary:

14.1 Installation

Before installing the Auto-CDP plugin, please make sure that the data volume that you intend to replicate exists. Also make sure that both appliances are SSH-bound and networking connectivity is properly setup.

	Even if your data volume is unused, the initial syncing will take a significant amount of time because of the block-level sector-by-sector transfer of all of its (unused) blocks over the IP network. Please see the following F.A.Q.: I'm using auto-cdp plugin to block-mirror my storage. Initial replication is very slow.

To verify that Auto-CDP plugin is available for installation, run the following command:

nmc$ show plugin remotely-available

To install Auto-CDP plugin, please run the following command:

nmc$ setup plugin install autocdp

Note that plugins can also be installed using the NexentaStor Web GUI.

The installation will require NMS restart and NMC re-login. After installation, use NMV or NMC to verify that the plugin is successfully installed. In NMC, that corresponding operation would be:

nmc$ show plugin autocdp

The command will display the plugin version, as well as other useful information.

14.2 Getting Started

Creating Auto-CDP service instances involves the following steps:

1. Select local (primary) data volume to replicate. The name of the service instance is in form “:volname”.

	Document Convention Assuming there is a volume named 'vol1', the corresponding Auto-CDP service will be named :vol1. Here, and throughout the rest of this document, :volname indicates the name of the volume to block-mirror using Auto-CDP, and simultaneously, the name of the corresponding Auto-CDP service.

Note, Auto-CDP service cannot be created for syspool – the appliance's system volume.

1. Select remote appliance. Specifying existing SSH-bound appliance registered on local appliance-creator;

2. Select disks on the remote appliance to serve as block-level replicas of the disks of the local (primary) volume.

As always, to carry out the 1-2-3 steps, NMC provides a guided multiple-choice interactive environment. As always, the same steps can be executed via command line, using the options specified above.

Once initiated, Auto-CDP will transfer the local (primary) volume's metadata, which will effectively create a secondary (remote) volume out of the corresponding remote disks.

The appliance's Auto-CDP will keep both data and ZFS metadata on the replicated disks in-sync, at all times.

Note: Auto-CDP requires using either DNS hostname for the local and remote appliances, or their "replacement" via local host tables. See 'setup appliance hosts -h' for more information.

The following NMC wizard command can be used for service instance creation:

nmc:/$ create auto-cdp

For details on service creation and all supported command line options, please see the corresponding man page:

nmc:/$ create auto-cdp -h

To modify/show parameters of newly created Auto-CDP service use the following commands:

nmc:/$ setup auto-cdp <volname>

where “:volname” is a service instance, and simultaneously, the name of the volume that is being block-mirrored via (or by) Auto-CDP.

14.3 The alternative hostname

The alternative local hostname can be specified instead of the one automatically selected by the Auto-CDP service.

Background:

Auto-CDP identifies the primary <=> secondary nexus by the specified IP addresses and their corresponding fully qualified hostnames. In a simple case there is a single networking interface and appliance's fully qualified domain name (FQDN). If the appliance has multiple IP interfaces, an attempt is made to find the matching primary IP to be used for the specified secondary IP address. The logic to find the best matching pair of interfaces for the CDP data transfers is built-in.

To override the default logic and specify an alternative hostname, use the -H option as shown below during service creation command:

nmc:/$ create auto-cdp -H althost

where “althost” is the alternative hostname to be used for the Auto-CDP service instance created.

14.4 Enabling Auto-CDP service instance

After Auto-CDP service instance was successfully created the wizard will ask permission on service enable. Service can be enabled/disabled at any given time using the following command:

nmc:/$ setup auto-cdp :volname enable

This enables the remote mirror replication for the primary volume and also uses the remote mirror scoreboard logs to start the resynchronization process so that the corresponding secondary data volume becomes a full replica of the primary volume.

Sizes of the remote (secondary) disks (a. k. a. LUNs) must be equal or greater than the corresponding primary disks that are being replicated.

Once enabled, NexentaStor Auto-CDP service instance will update a remotely mirrored data volume. Only the blocks logged as changed in the remote mirror scoreboards are updated.

Use '-f' (force) option when the primary and the secondary volumes/luns might be different and no logging information exists to incrementally resynchronize the volumes/luns.

Reverse synchronization and DR (disaster recovery)

At some point in time the secondary setup will be used as a disaster recovery (DR) site. There are two scenarios which needs to be considered while failing over to secondary setup:

1. Primary site is still active and you just want to manually switch to the secondary for primary maintenance operations. The assumption is that Auto-CDP service instance was in replication mode. In this case, the following command needs to be executed on primary:

nmc:/$ setup volume volname export

The command above will gracefully disable instance “:volname” after export completes. After command is complete, the following command needs to be executed on secondary:

nmc:/$ setup volume import volname

The “:volname” instance will stay in logging mode and once primary site is up the export/import operations can be repeated. After import command is complete on primary, execute the following command to enable reverse synchronization back from secondary to primary:

nmc:/$ setup auto-cdp :volname enable -r

The '-r' option (reverse) used to reverse the direction of synchronization: that is, synchronize from the secondary volume to the primary. With the '-r' option the primary volume becomes a passive destination while the secondary volume is considered active source (of the changes).

2. Primary site is down and you need to forcefully switch to secondary. The graceful Auto-CDP service instance disable is not possible in this case and loss of data may occur. However, the filesystem on a secondary setup is going to be always in consistent state due to transactional nature of ZFS and synchronous mode of SNDR operation. On the secondary setup, execute the following command to forcefully import data volume:

nmc:/$ setup volume import volname -f

The '-f' option will disregard host checking and forcefully import data volume on a secondary setup. The rest of operations could be done similar to (1).

The reverse operation '-r' then resumes Remote Mirror replication of new updates from the primary volume to the secondary volume automatically so that the volume sets remain synchronized. We recommend to quiesce the workload to the volume sets during the restore/refresh operation. This action ensures that the primary and secondary volumes match before replication of new updates resumes.

14.5 Volume operations and Auto-CDP

Auto-CDP service tightly integrated with main NMC/NMS management commands which simplifies service maintenance. The following data volume operations supported:

1. Volume grow. Add new LUN or group of LUNs to an existing data volume will interactively invoke Auto-CDP NMC wizard for disk pair setup;

2. LUN removal or replacement will ensure that appropriate Auto-CDP NMC wizard is invoked

3. Volume export will ensure that corresponding Auto-CDP instance is disabled if desired;

4. Volume import will ensure that corresponding Auto-CDP instance is enabled if desired;

5. Volume destroy will ensure that corresponding Auto-CDP instance is removed;

6. Simple-Failover service ensures that Auto-CDP configuration is securely transferred to all machines with-in the simple-failover group and automatically activates Auto-CDP service on failover machine;

14.6 Service monitoring

There are number of ways to monitor Auto-CDP service health and statuses:

1. Automatic NexentaStor trigger “autocdp-check”. As any other NexentaStor trigger it will send notification events (e-mails) if some of services instances suddenly enters logging mode or when initial syncing enters into normal replication mode;

2. AVS level monitoring of service status and I/O progress. The following command can be used:

nmc$ show auto-cdp :volname iostat

name t s pct role rkps rtps wkps wtps

v/rdsk/c2t0d0s0 P L 0.05 net 8 3 0 0

v/rdsk/c2t1d0s0 P L 0.40 net 0 0 345 0

The output includes the following information:

t Volume type

s Volume status

pct Percentage of volume requiring sync

role Role of the item being reported

rtps Number of reads

wtps Number of writes

rkps Kilobytes read

wkps Kilobytes written

3. Service-generated socket-level network traffic. The following command can be used:

nmc$ show auto-cdp :volname stats

4. Service logs can be viewed by executing the following command:

nmc$ show auto-cdp :volname log

5. To monitor logging activity interactively, execute the following command:

nmc$ show auto-cdp :volname logtail -f

14.7 Auto-CDP configuration properties

Auto-CDP service provides the following configurable properties:

1. cdproot - AutoCDP internal database root folder. Location where NMS and Auto-CDP service will store its internal data (AVS bitmaps devices). Default is “syspool/.cdp”. This option allows user to create dedicated volume to store zvol-emulated bitmap devices and isolate system volume;

2. cdp_scoreboard_log_size - specifies Auto-CDP scoreboard log size. Default is '1G' (one gigabyte). The AVS bitmap devices. Zvol-emulated and thin-provisioned.

14.8 Service States

The following are the states that can be set to the operational service instance:

• volume failed (VF) - an I/O operation to the local data volume has failed ;

• bitmap failed (BF) - an I/O operation to the local bitmap volume has failed ;

• need sync (SN) - a sync to this volume has been interrupted. It needs to be completed. The direction of the data flow must not be changed until one or the other is done;

• need reverse sync (RN) - a reverse sync to this volume has been interrupted. It needs to be completed (or restored via Point-in-Time Copy). The direction of the data flow must not be changed until one or the other is done;

• logging (L) - incoming writes are logged in the bitmap devices only. Data is not replicated to the remote site. need sync and need reverse sync are all sub-states of logging such that writes are logged in the bitmap, but not replicated;

• reverse syncing (RS) - a secondary to primary copy is in progress;

• syncing – a primary to secondary copy is in progress.

14.9 Troubleshooting

To troubleshoot, execute either one of the following commands:

1. To re-enable the entire service corresponding to instance “:volname”:

nmc$ setup auto-cdp :volname enable

2. To re-enable the entire service and fully resynchronize the associated primary volume “volname” to secondary volume. Beware, this operation may take a long time to complete:

nmc$ setup auto-cdp :volname enable -f

3. To re-enable specific <LUN> pair for service instance “:volname”:

nmc$ setup auto-cdp :volname lun <LUN> enable

4. To re-enable and fully resynchronize the specific <LUN> pair for service instance “:volname”:

nmc$ setup auto-cdp :volname lun <LUN> enable -f

5. To reset all Auto-CDP services and re-initialize AVS databases on both sides active and passive:

nmc$ setup auto-cdp reset

	WARNING! This operation will reset Auto-CDP service to its initial (post-creation) state.

6. As a troubleshooting example, to replace failed drive just run standard volume command:

nmc$ setup volume volname replace-lun

The major difference between all of the commands listed above is: granularity.

The first two commands (1,2) execute on a level of the entire service instance, with the corresponding action applied to all associated disk pairs. Use command (1) if you want to move service from “logging” mode back to “replication”.

The second pair (3,4) of troubleshooting actions is LUN specific. These two commands (3,4) are especially useful when a single or a few specific pairs of syncing LUNs appear to be stuck in a so called "logging" mode and will not change states. Another relevant scenario is related to importing of the secondary volume. If the newly imported mirrored volume shows faulted drive(s), use the LUN specific re-synchronization to troubleshoot.

The reset command (5) is plugin/service wide and will affect all instance on both active and passive sides.

The disk replacement, as well as all other disk management operations, tightly integrated with the service and the right action will be taken if corresponding Auto-CDP instance is present. Simply execute normal volume management operation and do not worry about the complexity associated with AVS disk set management.

14.10 Creating Auto-CDP – example

In the following example appliance 'testbox1' is a primary, 'testbox2' is a secondary. This example includes all NMC prompts – it is a complete demonstration of auto-cdp creation:

nmc@testbox1:/$ create auto-cdp Remote appliance : 192.168.37.128 Remote for c2t1d0 : c2t1d0 Remote for c2t0d0 : c2t0d0 Creating new Auto CDP service 'auto-cdp:vol1', please wait... Successfully created service 'auto-cdp:vol1' Enable it now? Yes Enabling service, please wait... PROPERTY VALUE name :vol1 max_q_fbas 16384 autosync off max_q_writes 4096 async_threads 2 state syncing to_host testbox2 from_host testbox1 type active TESTBOX1 TESTBOX2 c2t1d0 => c2t1d0 c2t0d0 => c2t0d0 The local host is 'active' auto-cdp node.

Once the initial synchronization between a pair of active (primary) and passive (secondary) volumes commences, you can monitor it either via 'show auto-cdp <name> stats' or 'show auto-cdp <name> iostat' NMC commands.

In fact, these two commands are always useful, in terms of monitoring the data replication traffic, whether this is auto-cdp, auto-sync or auto-tier service. However, auto-cdp traffic monitoring is particularly useful at the time of the initial block-level syncing:

It is recommended not to use the primary (active) volume during the very first (the initial) CDP synchronization. Any updates on the primary during this period of time may considerably delay the initial synchronization. Note also that during this phase a major part of the available I/O bandwidth is used by the auto-cdp service, which is yet another reason to let it run through as soon as possible. See 'show auto-cdp <name> stats' for more information.

Following is an example of 'show auto-cdp <name> stats' output:

nmc@testbox1:/$ show auto-cdp :vol1 stats -i 1

TCP CONNECTIONS SNEXT RNEXT TRANSFER
192.168.37.128.1022-192.168.37.134.121 1313611534 3140553278 1.60 MB

192.168.37.128.1022-192.168.37.134.121 1314180374 3140554114 569.68 KB

192.168.37.128.1022-192.168.37.134.121 1314838374 3140554994 658.88 KB

192.168.37.128.1022-192.168.37.134.121 1316976874 3140557854 2.14 MB

192.168.37.128.1022-192.168.37.134.121 1321352574 3140563706 1.25 MB

192.168.37.128.1022-192.168.37.134.121 1327471974 3140571890 955.38 KB

192.168.37.128.1022-192.168.37.134.121 1328722174 3140573562 1.25 MB...

Once the traffic stops, you'll be able to see the block-level replicated volume on the remote side:

nmc@testbox2:/$ show auto-cdp :vol1 -v

PROPERTY VALUE

name :vol1

max_q_fbas 16384

autosync off

max_q_writes 4096

async_threads 2

state logging

to_host testbox2

from_host testbox1

type passive

TESTBOX1 TESTBOX2

c2t1d0 => c2t1d0

c2t0d0 => c2t0d0

The local host is 'passive' auto-cdp node.

14.11 Reverse mirroring – example

In the following 6-steps example appliance 'testbox1' is again a primary, and 'testbox2' is a secondary. The reverse mirroring starts from exporting a volume from the primary appliance (Step #1)...

	One critically important guideline in re CDP: It is recommended NOT to have the primary and secondary volume imported simultaneously. In fact, NexentaStor software will prevent this from happening. Still, note: the remotely mirrored volume may be imported only at one side, primary or secondary, at any given moment.

In short, several preparation steps need to be performed before actually enabling reverse mirroring from 'testbox2' to 'testbox1' (Step #5 below):

Step #1. testbox1 (primary): first, export vol1

nmc@testbox1:/$ setup volume vol1 export

Export volume 'vol1' and destroy all associated shares ? Yes

Step #2. testbox2 (secondary): import vol1

nmc@testbox2:/$ setup volume import vol1

volume: vol1

state: ONLINE

scrub: none requested

config:

NAME STATE READ WRITE CKSUM

vol1 ONLINE 0 0 0

mirror ONLINE 0 0 0

c2t0d0 ONLINE 0 0 0

c2t1d0 ONLINE 0 0 0

Step #3. ...using secondary volume until (and if) the problem with primary is resolved...

Step #4. testbox2 (secondary): export vol1

nmc@testbox2:/$ setup volume vol1 export

Export volume 'vol1' and destroy all associated shares ? Yes

Step #5. testbox1 (primary): reverse syncing

nmc@testbox1:/$ setup auto-cdp :vol1 enable -r

Enable reverse synchronization for auto CDP service 'vol1'? Yes

Enabling service, please wait...

Auto CDP service ':vol1' enabled.

Step #6. testbox1 (primary): import vol1

nmc@testbox1:/$ setup volume import vol1

volume: vol1

state: ONLINE

15 Operations and Fault Management

15.1 Runners

To see existing runners in NMC use the command 'show appliance runners'. Here is sample output:

nmc:/$ show appliance runners

RUNNER STATUS STATE SCHEDULED

memory-check enabled ready every 12 minutes

runners-check enabled ready every 12 hours

cpu-utilization-check enabled ready every 15 minutes

nms-check enabled ready not schedulable

services-check enabled ready every 15 minutes

volume-check enabled ready every 10 minutes

hosts-check enabled running hourly

nms-fmacheck enabled ready not schedulable

network-collector enabled ready hourly

nfs-collector enabled ready hourly

volume-collector enabled ready hourly

volume-reporter enabled ready weekly on Sat 04:00am

services-reporter enabled ready daily at 05:00am

nfs-reporter enabled ready weekly on Sat 03:00am

network-reporter enabled ready weekly on Sat 02:00am

indexer:vtest/a enabled ready daily at 01:00am

indexer:vtest/b enabled ready daily at 01:00am

This shows:

several fault triggers (all with extension “check”, Section “Fault Management”), followed by

statistic collectors, followed by storage and network service reporters, followed by two specific indexers with their associated folders (Section “Indexing NexentaStor Archives”).

In NMV, you can view runners by selecting Runners under the Data Management tab:

The appliance's framework allows you to add runners. NexentaStor runners have the advantage of exercising the entire NMS-provided SA-API (Section "Terminology"; see also [3], Section “References”), execute periodically, and/or on event, and/or run constantly in the background.

NexentaStor runners rely on the mailing facility which can be configured in NMC using the command 'setup appliance mailer'.

All appliance's runners are runtime-configurable. Runners' times-to-run and other properties can be changed via:

nmc:/$ setup trigger

nmc:/$ setup collector

nmc:/$ setup reporter

nmc:/$ setup indexer

Each of the setup commands listed above has its show “counterpart”, to show the existing configuration and runtime status:

nmc@myhost:/$ show trigger

nmc@myhost:/$ show collector

nmc@myhost:/$ show reporter

nmc@myhost:/$ show indexer

For instance:

nmc:/$ setup trigger cpu-utilization

This can be used to disable, enable, run, and configure standard fault trigger that monitors CPU utilization. For instance, press TAB-TAB or Enter, type or select 'property', and view all 'cpu-utilization' properties available for tuning. You could change the alarm-generating thresholds (in this case - low and critically low idle CPU), make it run more or less frequent, etc.

nmc:/$ show trigger cpu-utilization -v

This will show the trigger's current runtime state, status and existing configuration in detail (notice the verbose -v option).

15.2 Triggers

Part of the NexentaStor Fault Management facility is realized through Fault Triggers. A fault trigger, or simply, a trigger, is a special kind of a pluggable runner module ('help runners') that performs a certain fault management and monitoring operation(s). Each trigger monitors one, or a few related conditions.

If any of the monitored conditions are violated, a fault trigger raises an alarm, which manifests itself in several ways:

• email notification to the administrator, with detailed description of the fault, including: severity, time, scope, suggested troubleshooting action, and often an excerpt of a related log with details.

• red color showing up via one of the NMC 'show' operations detailed below.

  show trigger all-faults

  show trigger <name>

  show appliance runners

  show faults all-appliances

• and message posted to appliance's Inbox (see Section “Inbox”).

	Notifications of hardware faults are immediate. Unlike many other potentially faulty conditions that are getting periodically "polled", any hardware fault itself triggers the appliance's fault management logic, that in turn includes email notification.

To see all available fault triggers in NMC, use the command show trigger all.

In all cases a trigger that "carries" the alarm will be shown in red, assuming NMC colors are enabled. In addition, the faulted trigger will try to notify system administrator via appliance's mailing facility. Therefore, as already noted elsewhere, it is important to setup the appliance's mailer.

Trigger counts the fault conditions every time it runs. Typically, the fault trigger will send email once the faulty condition is observed a certain configurable number of times. Typically, after that the trigger itself goes into 'maintenance' state - it will still run and count the faulty conditions but it will not send email notification anymore - that is, until system administrator clears it from its maintenance state:

nmc:/$ setup trigger <name> clear-faults

Similar to the rest appliance's runners, triggers are flexible, in terms of their runtime behavior and trigger-specific conditions they monitor. For details on any specific fault trigger, run:

nmc:/$ show trigger <name> -v

where <name> stands for the trigger's name, and -v (verbose) is used to display details

	The appliance includes one special fault trigger – 'nms-check'. This trigger performs fault management/monitoring function for the Fault Management facility itself. Nms-check tracks NMS connectivity failures and internal errors. nmc:/$ show trigger nms-check -v In presence of network failures, this will show all alarms (in detail) that the appliance failed to report.

	nmc:/$ show faults all-appliances This generates Fault Management summary report that includes all known (explicitly ssh-bound and dynamically discovered) Nexenta appliances. Upon generating the summary, use a combination of NMC 'switch' operation ()(Section “Command Reference - switch”) and 'show faults' - to "zoom-in" into a particular ("faulted") appliance for details.

15.3 Handling an Unrecoverable I/O Error

Here is an example of an unrecoverable I/O error and possible resolutions:

FMA EVENT: ======= START =======
FMA EVENT: SOURCE: zfs-diagnosis
FMA EVENT: PROBLEM-IN: zfs://pool=iscsidisk/vdev=56f1d7932d4c039d FMA EVENT: AFFECTS: zfs://pool=iscsidisk/vdev=56f1d7932d4c039d
FMA EVENT: ======== END ========
fault trigger 'nms-fmacheck (E1)' reached the configured maximum of 1 failure

FAULT: *****************************************************************
 FAULT: Appliance   : ups-nxstor1 (OS v0.99.5b82, NMS v0.99.5)
 FAULT: Machine SIG : 1CG5KI
 FAULT: Primary MAC : 0:15:17:a:d1:fc
 FAULT: Time        : Tue Mar 11 14:10:47 2008
 FAULT: Trigger     : nms-fmacheck
 FAULT: Fault Type  : ALARM
 FAULT: Fault ID    : 1
 FAULT: Fault Count : 1
 FAULT: Severity    : CRITICAL
 FAULT: Description : FMA Module: zfs-diagnosis, UUID:
 FAULT:             : 5bbb38fb-f518-4aa2-9018-8c2fe7e70360
 FAULT: *****************************************************************

Fault class : fault.fs.zfs.vdev.io
Description : The number of I/O errors associated with a ZFS device exceeded acceptable levels. Refer to http://sun.com/msg/ZFS-8000-FD for more information.

The following is the type of email you might receive if you have FMA checks enabled and your appliance mailier is properly configured.

An unrecoverable I/O error scenario presents only two options:

1. Manually recover the faulted device. As specified in the fault report, it makes sense to review the posted URL (http://sun.com/msg/ZFS-8000-FD in this case) for the latest tips and guidelines.

In the case of FC/iSCSI/USB attached drives, please verify connectivity to the corresponding target(s).

Next, ssh into the appliance as root. At this point NMC will automatically determine the presence of a faulted condition and will prompt you to execute corrective action (you will simply need to press Enter).

2. The second option is simple: power cycle the appliance. This may cause an unrecoverable loss of data: the in-flight data that was not committed to stable storage at the time of the hardware failure will be lost. However, the existing data on the affected volume will not be corrupted. After power cycling, the entire faulted volume (that is, the volume that contains the faulted drive) will be marked 'offline' and inaccessible.

15.4 Handling a System Failure

If the NexentaStor appliance fails and is restarted, then you will get an email after the restart , which includes information about date and time of the reboot. By default, last 20 lines from the system log file are included in the e-mail. To change this properties, run the following NMC command:

nmc:/$ setup trigger nms-rebootcheck

16 Analytics

16.1 DTrace

DTrace is a comprehensive dynamic tracing framework created by Sun Microsystems to analyze performance and troubleshoot problems on production systems in real time. For in-depth guide on DTrace language and details, please visit DTrace at OpenSolaris.org.

DTrace can be used to generate performance profiles and analyze bottlenecks. DTrace can help to troubleshoot problems by providing detailed views of the system internals.

16.1.1 DTrace command line

As with many other functional components, NexentaStor provides an easy DTrace integration. DTrace is integrated into Nexenta Management Console as one of its top level commands (Section 'Top-Level Commands').

To start using DTrace, type 'dtrace' at NMC prompt and use TAB-TAB to navigate, or simply press Enter and make a selection. DTrace is functionally sub-divided into sections, as follows:

nmc:/$ dtrace

Option ?

<?> IO cpu locks memory misc network report-all

------------------------------------------------------

Choose one of the options above, 'q' or Ctrl-C to quit

Memory utilization, physical and virtual memory statistics

In most cases examples are provided; to see an example, select 'example' option. For instance:

nmc:/$ dtrace cpu cpuwalk example

To override the default behavior of any given dtrace utility, specify extra options in the command line, for instance:

nmc:/$ dtrace cpu cpuwalk 5

This will run for 5 seconds (as opposed to running until Ctrl-C is pressed by default).

Use TAB-TAB to navigate and make a selection. For details on particular command line options use help (-h), for instance:

nmc:/$ dtrace cpu cpuwalk -h

16.2 NMV Analytics

To setup and view a performance chart in NMV, select the 'Analytics' tab and the 'Profiles' subtab. After selecting some metrics and creating the chart, the chart will appear at the bottom of the page. You can choose any number of metrics, but make sure that the scale for each metric is compatible or some series may be difficult to see. If you choose metrics from multiple statistics (top level tree nodes) you will get multiple charts.

You can close a chart by clicking the “x” icon in the upper right, or by clicking the “remove” button for the appropriate entry in the chart list at the top of the screen.

The header panel as well as any chart can be “shuttered” closed by using the triangle-shaped toggle button next to the x button.

To reorder charts, click in the blue heading (title) area and drag the chart where you wish to display it. The chart list will update to show the new order.

If the series lines of a chart are difficult to see in the default line chart presentation, you can click the bar chart icon in the upper left of the toolbar to change the view.

16.3 I/O Performance

You can check the real-time I/O performance of your data volume using NMC or NMV. In NMC, the command:

nmc:/$ show volume <volumename> iostat

will show capacity, number of reads and writes, and read and write bandwidth.

16.4 Performance Benchmarks

The appliance includes a number of facilities to monitor and test its performance. This includes DTrace (Section “DTrace”). This includes NMV performance charts (Section “Graphical Statistics”). This includes performance benchmarks intended to run stressful I/O and networking operations and show the corresponding statistics.

Performance benchmark functionality is included in a form of extensions – pluggable modules (plugins). These particular plugins are available to all users and can be installed into both Developer Edition and Commercial Editions.

NexentaStor includes currently two pluggable (micro-) benchmarks described in the subsequent sections: I/O benchmark and network performance benchmark.

To show all currently installed benchmarks:

nmc:/$ run benchmark

(and press TAB-TAB or Enter)

To list benchmarks (and other plugins) available in the remote central software repository:

nmc:/$ show plugin remotely-available

16.4.1 I/O performance benchmark

Usage: [-p numprocs] [-b blocksize] [-q] [-s]

-p <numprocs> Number of process to run. Default is 2.

-b <blocksize> Block size to use. Default is 32k

-s No write buffering. fsync() after every write

This benchmark is using well known Bonnie++ tool, it is based on the Bonnie benchmark written originally by Tim Bray.

Sequential Write (SEQ-WRITE):

1. Block. The file is created using write(2). The CPU overhead

should be just the OS file space allocation.

2. Rewrite. Each <blocksize> of the file is read with read(2),

dirtied, and rewritten with write(2), requiring an lseek(2).

Sequential Read (SEQ-READ):

Block. The file is read using read(2). This should be a very pure

test of sequential input performance.

Random Seeks (RND-SEEKS):

This test runs SeekProcCount processes (default 3) in parallel,

doing a total of 8000 lseek()s to locations in the file specified

by random(). In each case, the block is read with read(2).

In 10% of cases, it is dirtied and written back with write(2).

Example:

nmc@thost:/$ run volume vol1 benchmark -p 2 -b 8192

Testing 'vol2'. Optimal mode. Using 1022MB files and 8192 blocks.

SEQ-WRITE CPU S-REWRITE CPU SEQ-READ CPU RND-SEEKS

162MB/s 8% 150MB/s 6% 188MB/s 9% 430/sec

158MB/s 7% 148MB/s 8% 184MB/s 7% 440/sec

--------- ---- --------- ---- --------- ---- ---------

160MB/s 8% 149MB/s 7% 186MB/s 8% 435/sec

16.4.2 Network performance benchmark

Quoting Wikipedia Iperf article (http://en.wikipedia.org/wiki/Iperf):

“Iperf is a commonly used network testing tool that can create TCP and UDP data streams and measure the throughput of a network that is carrying them. Iperf is a modern tool for network performance measurement written in C++.

Iperf allows the user to set various parameters that can be used for testing a network, or alternately for optimizing or tuning a network. Iperf has a client and server functionality, and can measure the throughput between the two ends, either unidirectonally or bi-directionally. It is open source software and runs on various platforms including linux, unix and windows. It is supported by the National Laboratory for Applied Network Research.”

Usage: [-s]

[-P numthreads] [-i interval] [-l length] [-w window] [-t time][hostname]

-s run in server mode

-P numthreads number of parallel client threads to run (default = 3)

-i interval seconds between periodic bandwidth reports (default = 3)

-l length length of buffer to read or write (default = 128KB)

-w window TCP window size (socket buffer size) (default = 256KB)

-t time total time in seconds to run the bencmark (default = 30)

hostname for the iperf client, you can optionally specify

hostname or IP address of the iperf server

Usage: [-s] [server-options]

[-c] [client-options]

server-options any number of valid iperf server command line option,

as per iperf documentation

client-options any number of valid iperf client command line option,

as per iperf documentation

This plugin is based on a popular Iperf tool used to measure network performance. The benchmark is easy to set up. It requires two hosts, one - to run iperf in server mode, another - to connect to the iperf server and run as a client. Use -s option to specify server mode.

The easiest way to run this benchmark is to select a host for the server and type 'run benchmark iperf-benchmark -s'. Next, go to the host that will run iperf client and type 'run benchmark iperf-benchmark'. You will be prompted to specify the server's hostname or IP address. See more examples below.

To run this benchmark, you can either:

a) use built-in defaults for the most basic parameters, or

b) specify the most basic benchmark parameters, or

c) specify any/all iperf command line option, as per iperf manual page.

To display iperf manual page, run '!iperf -h'

Examples:

Example 1.

Let's say, there are two appliances: hostA and hostB. On appliance hostA run:

nmc@hostA:/$ run benchmark iperf-benchmark -s

This will execute iperf in a server mode. On appliance hostB the iperf client connects to hostA and drives the traffic using default parameter settings:

nmc@hostB:/$ run benchmark iperf-benchmark hostA

Example 2.

Same as above, except that now we assign parameters such as:

* number of parallel client threads = 5

* seconds between periodic bandwidth reports = 10

* length of buffer to read or write = 8KB

* TCP window size = 64KB

nmc@hostA:/$ run benchmark iperf-benchmark -s

nmc@hostB:/$ run benchmark iperf-benchmark hostA -P 5 -i 10 -l 8k -w 64k

Notice that all these parameters are specified on the client side only. There is no need to restart iperf server in order to change window size, interval between bandwidth reports, etc.

Example 3.

Same as Example #1, except that iperf server is not specified in the command line. Instead, NMC will prompt you to select the server interactively from a list of all ssh-bound appliances:

nmc@hostA:/$ run benchmark iperf-benchmark -s

nmc@hostB:/$ run benchmark iperf-benchmark

Example 4.

********* Note: advanced usage only *********

You can specify any number of valid iperf server and/or client command line option, as per iperf documentation. Unlike the most basic command line options listed above, the rest command line options are not validated and do not have NMC provided defaults. Unlike the most basic command line options listed above, the rest command line options are passed to iperf AS IS.

17 Managing the Users

NexentaStor automatically syncs user ids in the /etc/passwd and /var/smb/smbpasswd files. Keep this in mind if you change a user id on the appliance. You won’t be able to access existing files owned by this user until you also change the file ownership to the new user id.

To change a user’s user id:

nmc:/$ setup appliance user jack property uidNumber
User id (uid) : 1001

To change the owner of the folder use the NMC command setup folder foldername ownership.

17.1 Adding Local Appliance Users

In NMV, you can add local appliance users by selecting “Users” under the “Settings” tab.

17.2 Local Appliance Groups

You can also create user groups within NexentaStor. This is done in NMV on the Users page under the Settings tab. You can create a new group by selecting “New Group” under the Groups heading.

17.3 LDAP

The Lightweight Directory Access Protocol (LDAP) is a common protocol interface to Network Directory Services. Widely deployed directory services are Domain Name Service (DNS), NIS (Network Information Service), etc. They provide the clients with information such as host IP addresses, usernames, passwords and home directories. LDAP is a widely-deployed, simple and efficient network protocol for accessing information directories. LDAP typically runs over TCP; it has the potential to consolidate existing Network Directory Services into a single global directory.

NexentaStor provides easy to use LDAP integration, specifically for usage in the NFS environments. In addition, LDAP user and group management can be deployed with NFSv4 – the default NFS version provided by the appliance. In general, LDAP based user and group management is required to consistently utilize ZFS extended Access Control List (ACLs) across heterogeneous file services instead of POSIX permissions and attributes.

It is recommended that you use LDAP for centralized user management. NexentaStor is an LDAP client in this case. To use NexentaStor with LDAP server, make sure the server is available. You will need your base DN, with either anonymous or authenticated SASL bindings (the latter requiring account DN and password), and netgroup, user, and group subtree DNs if known. Netgroup (a group of hosts) is only necessary if currently supported by the LDAP server and is of interest.

You define authentication information for communicating with an LDAP server within NMV on the Settings tab in “Misc. Services”.

Note that in addition to Unix based LDAP, NexentaStor provides Active Directory integration - an implementation of LDAP directory services by Microsoft for use primarily in Windows environments (Section “Using Active Directory”).

Finally, NexentaStor LDAP client provides integrated ability to authenticate itself using X.509 certificates. Management console and management UI both provide the corresponding interfaces.

17.4 ACLs

NexentaStor provides native extended Access Control Lists (ACLs), capable of handling CIFS ACLs, as well as NFSv4 ACLs, as well as POSIX permissions natively in the same filesystem.

The appliance supports full management of per-user, per-group, per-folder ACLs in its user interface, while also populating the system with accounts and groups that you may have already defined in Active Directory or other LDAP-based directory service.

NexentaStor User and Access Control management has the following characteristics:

• Support both local and LDAP (or AD) managed users and groups. In LDAP or Active Directory configurations, the local users and groups can be used to override centralized settings.

• Native extended Access Control Lists (ACLs), that are both CIFS and NFSv4 compliant.

Following are two screenshots that show, first, appliance users (most of which are retrieved from LDAP in this case), and the management GUI capability to administer access control to a given folder (and its subfolders – all operations on ACLs are recursive, to reduce the amount of administration).

Notice that in the case below a local 'test-user' and LDAP-defined 'rfgroup' are granted a special set of permissions:

NexentaStor CLI management client provides the same capabilities – via command line. The users and groups can be retrieved (that is, 'shown'), created and deleted, extended permissions can be modified and all the rest related management operations can be executed using either NMV or/and NMC.

NexentaStor ACLs are native across ZFS, CIFS, and NFSv4, and as such have no conflict in how they are operated on. Generally, one accomplishes ACL management via the following tasks:

• local user or LDAP configuration

• definition of per-user or per-group capabilities per volume or folder

• overall management of ACLs and ACEs system wide, allowing overriding of end user activity via CIFS/NFS

17.5 User Quotas

User quotas are defined in NexentaStor on a per-folder basis by setting the userquota folder property.

Here is an example in NMC of setting a quota for a user named “fred”: