NETAPP TECHNICAL REPORT SnapDrive 4.1 for UNIX Best Practices SnapDrive for UNIX Team, NetApp January 2009 | TR-3735-0109 SIMPLIFYING AND AUTOMATING STORAGE AND DATA MANAGEMENT FOR UNIX AND LINUX ENVIRONMENTS NetApp® SnapDrive® for UNIX® simplifies management of your business critical information with its advanced server-based storage virtualization, helps you to respond quickly to growth by providing the ability to expand your storage on the fly with no downtime, speeds backup and restore of data in seconds with integrated Snapshot technology and provides increased availability by performing online cloning and replication of production data without causing any downtime. This document details the best practices for deploying and using SnapDrive 4.1 for UNIX.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
NETAPP TECHNICAL REPORT
SnapDrive 4.1 for UNIX Best Practices SnapDrive for UNIX Team, NetApp
January 2009 | TR-3735-0109
SIMPLIFYING AND AUTOMATING STORAGE AND DATA MANAGEMENT FOR UNIX AND LINUX ENVIRONMENTS NetApp® SnapDrive® for UNIX® simplifies management of your business critical information with its
advanced server-based storage virtualization, helps you to respond quickly to growth by providing the
ability to expand your storage on the fly with no downtime, speeds backup and restore of data in
seconds with integrated Snapshot technology and provides increased availability by performing online
cloning and replication of production data without causing any downtime. This document details the best
practices for deploying and using SnapDrive 4.1 for UNIX.
2.1 KEY FEATURES ......................................................................................................................................... 4
2.2 SNAPDRIVE FOR UNIX DEPLOYMENTS ................................................................................................... 5
3 NEW IN VERSION 4.0 AND 4.1 ................................................................................................. 5
4 INSTALLATION AND BASIC CONFIGURATION ..................................................................... 5
4.1 CHECKLIST FOR STORAGE SYSTEM ...................................................................................................... 6
4.2 CHECKLIST FOR HOST BEFORE SNAPDRIVE INSTALLATION .............................................................. 7
4.3 USING THE SNAPDRIVE DAEMON ........................................................................................................... 8
4.4 SETTING UP SNAPDRIVE TO COMMUNICATE TO A NETAPP STORAGE SYSTEM .............................. 9
5 SECURITY FEATURES ............................................................................................................ 11
5.1 BEST PRACTICES FOR ACCESS CONTROL AND HTTPS .................................................................... 11
5.2 CONFIGURING SNAPDRIVE FOR ROLE-BASED ACCESS CONTROL .................................................. 12
11.2 BEST PRACTICES FOR BACKUP AND RESTORE IN CLUSTER ENVIRONMENT ................................ 20
12 PLATFORM AND PROTOCOLS .............................................................................................. 20
12.1 ALUA SUPPORT ....................................................................................................................................... 20
Dynamic storage allocation: Quickly and easily reallocates storage systems in response to shifts in
application or server demand.
Host file system consistent Snapshot copies: Implements a mechanism by which Snapshot copies
created are file system consistent.
Backup and restore: Provides a quicker way to create and restore storage from backups using NetApp
Snapshot copy technology.
For more details about SnapDrive for UNIX features, please refer to the SnapDrive for UNIX Installation and Administration Guide.
2.2 SNAPDRIVE FOR UNIX DEPLOYMENTS
SnapDrive for UNIX can be used either as a standalone product or as a part of other NetApp solutions. For
example, it can be deployed along with SnapManager® for Oracle. In both types of deployments, SnapDrive
for UNIX serves as a tool to create and manage storage. It also takes storage backup and restores storage
from those backups, using Snapshot technology. SnapDrive for UNIX integrates with native volume
managers and Veritas™ storage foundation suites and also works in clustering and multipathing
deployments using FCP and iSCSI transport protocols. For a complete list of supported platforms, refer to
the SnapDrive for UNIX Interoperability Matrix.
3 NEW IN VERSION 4.0 AND 4.1
Web services and daemon: SnapDrive for UNIX Web service provides a uniform interface for all the
NetApp SnapManager and third-party products to help them integrate seamlessly with SnapDrive for UNIX.
SnapDrive for UNIX configuration checker: The configuration checker tool helps you in verifying the
various configurations required for proper working of SnapDrive for UNIX.
Role-based access control for SnapDrive for UNIX: Role-based access control (RBAC) is used for
user login and role permissions. RBAC allows administrators to manage groups of users by defining roles.
Volume-based SnapRestore: SnapDrive 4.0 for UNIX introduces SnapRestore capability at a volume
level. Volume-based SnapRestore restores the volume with all its storage objects. The volume-based restore is faster than each storage object restored individually.
FlexClone® volumes in SnapDrive for UNIX: Previous versions of SnapDrive for UNIX would
leverage FlexClone technology in an NFS environment and LUN clone technology in a SAN environment. Starting from version 4.0, SnapDrive for UNIX can leverage FlexClone technology even in a SAN environment.
Support for asymmetric logical unit access (ALUA) in Solaris MPIO and AIX® native MPIO
Some of the above new features are explained in more detail in this report. For a more detailed list of new features, refer to the SnapDrive for UNIX Installation and Administration Guide.
4 INSTALLATION AND BASIC CONFIGURATION
You have to download the SnapDrive for UNIX software from the NOW™ site. Make sure that you select the
required UNIX platform and read the corresponding description and download pages. For detailed
installation instructions, see the SnapDrive for UNIX Installation and Administration Guide. The software can
be also obtained through a media kit. Before installing SnapDrive for UNIX, use the following checklists to
avoid potential errors or delays during or after the installation.
4.2.2 Preinstallation Manual Steps Before installing SnapDrive for UNIX it is a best practice to always check for the prerequisites. Refer to the
SnapDrive for UNIX Interoperability Matrix and check for the following items:
Confirm that SnapDrive for UNIX supports your environment
For specific information on requirements, such as any patches that are required for the operating system, see the Compatibility and Configuration Guide for NetApp FCP and iSCSI
Step Action
1
Identify whether the host operating system version is supported by SnapDrive for UNIX:
Solaris: cat /etc/release
HP-UX: uname –srv
AIX: oslevel –r
Linux: cat /etc/issue
For an FCP environment:
Check the SnapDrive for UNIX supported Host Utility version from the SnapDrive for UNIX Interoperability Matrix
Verify NetApp Host Utilities are present on the host:
sanlun version
If Host Utilities are not installed, download and install correct version from the NOW site
and see the Host Utilities Installation and Setup Guide to install (or upgrade) and configure Host Utilities
Identify the HBA adapters on the host and verify the ports are enabled:
sanlun fcp show adapter –v
For Veritas environment:
• If you are using Veritas Storage Foundation for multipathing, you must install and configure the Symantec™ Array Support Library (ASL) for NetApp storage systems
• To determine which version of the Veritas Storage Foundation and ASL to use, check the Compatibility and Configuration Guide for NetApp's FCP and iSCSI Products
• For more information about obtaining ASL and installing ASL, see the Host Utilities Installation and Setup Guide
For iSCSI environment:
• Check the SnapDrive for UNIX supported Host Utility version from the SnapDrive for UNIX Interoperability Matrix
• Verify NetApp Host Utilities are present on the host:
sanlun version
• If Host Utilities are not installed, download and install correct version from the NOW site and see the Host Utilities Installation and Setup Guide to install (or upgrade) and configure Host Utilities
Note
It is essential that:
The HBA and its utility software are installed properly
An iSCSI initiator is already installed on the system
All patches required by Veritas are installed on the host
BEST PRACTICE
Always download the latest package of the config checker tool from the ToolChest on the NOW site
Execute config checker post and preinstallation of SnapDrive for UNIX tool to validate and confirm the presence of dependent components
It is recommended to have a minimum of 1GB to 2GB spare space for SnapDrive for UNIX operation in the root directory to avoid root volume running out of space. This additional space is for the SnapDrive logs. The default location of the logs is specified by some options in the snapdrive.conf file which
can be modified to have SnapDrive create the logs in a different directory
SnapDrive for UNIX operations on HP-UX creates temporary files in the /tmp folder the temporary
filenames are pre-pended with “map” if native LVM is used and “vx” Veritas is used. The host
administrator should delete these files periodically when there are no SnapDrive for UNIX operations running
Once the preceding checklist is verified, follow the steps in the Installation and Administration Guide for more details on how to install SnapDrive for UNIX on different operating systems
NetApp recommends that you use the default path for the SnapDrive for UNIX installation and add the
SnapDrive for UNIX directory to your $PATH environment variable.
4.3 USING THE SNAPDRIVE DAEMON
Most NetApp SnapManager products like SnapManager for Oracle and SnapManager for SAP leverage
SnapDrive for UNIX to create application-consistent backups and perform fast restores and quick clones.
Prior to version 4.0 of SnapDrive for UNIX, the SnapManager products would communicate with SnapDrive
for UNIX via the SnapDrive CLI. This had an impact on SnapDrive performance and manageability.
Starting from version 4.0, SnapDrive for UNIX now provides a web service with a uniform interface for all
NetApp SnapManager products to integrate seamlessly with SnapDrive for UNIX using APIs. Using the
SnapDrive for UNIX daemon, all the SnapDrive commands will work as a unique process in the background.
4.3.1 Common Daemon Operations The SnapDrive daemon should be running for any SnapDrive for UNIX command or API to work. This
section lists the most common daemon operations.
Table 1) SnapDrive daemon operations.
Daemon Operation Command OS User
Starting the daemon snapdrived start Root
Verifying the status of the daemon snapdrived status Root
Stopping the daemon snapdrived stop Root
Changing the default daemon password snapdrived passwd Root
BEST PRACTICES
The SnapDrive for UNIX configuration file is read during daemon startup. If any changes are made to the configuration file, you need to restart the daemon for the changes to take affect
SnapDrive for UNIX daemon default password is stored in a file. This default password enables the SnapManager products to work with this authentication method easily. It is a best practice to change this default password. Only the root user can change this password. Once the password is changed, all the client applications must be notified about it
4.4 SETTING UP SNAPDRIVE TO COMMUNICATE TO A NETAPP STORAGE SYSTEM
Step Action
1 Verify the SnapDrive for UNIX version:
snapdrive version
2 Check the connectivity from the host to storage system:
For iSCSI, multiipathing is not supported and the multipathing-type variable should be set to "none."
On Linux platforms where SnapDrive for UNIX does not support multipathing, make sure that multipath modules are uninstalled before using SnapDrive commands. Complete the following steps to remove multipath software:
1. Verify only one FCP operational on the host. Check for 'port state' from the
output of sanlun fcp show adapter -v command
2. Unload the multipathing related modules using the below command:
Identify the multipath modules installed on the host:
HOST# multipath –F
If dm_round_robin, dm_multipath and dm_mirror are loaded, execute the
It is recommended practice to use Operations Manager for RBAC control, as described in the next section. In an environment where Operations Manager is not being used for RBAC, use the following steps:
Create a prbac file for each host to control the access of a host to the storage system. The file name will be /vol/vol0/sdprbac/sd<hostname>.prbac, where hostname is the name of the each host. For more information on the access privileges, refer to the SnapDrive for UNIX Installation and Administration Guide.
Understand which operations have to be performed from the host using SnapDrive for UNIX. For example, the host can be provided with ALL ACCESS permission initially; after all the
storage entities have been mounted on the host the permission can be changed to SNAP ALL.
This allows you to work only with commands related to Snapshot copies and stops from executing storage-related operations such as delete or resize operations that might be disruptive to your service.
Set the value of all-access-if-rbac-unspecified option to Off to assure security. If
the permission file is missing on the storage system, SnapDrive for UNIX checks the value of
the all-access-if-rbac-unspecified option in the snapdrive.conf file.
After you configure and veirfy the preceding tasks based upon your environment and needs, you
can perform the following tasks, using the SnapDrive CLI commands:
Creating storage entities, such as, LUNs, disk groups, logical volumes, and file systems
Creating Snapshot copies and restoration file systems, LUNs, disk groups, and NFS files
Connecting to and disconnecting from the Snapshot copy on the host
5.2 CONFIGURING SNAPDRIVE FOR ROLE-BASED ACCESS CONTROL
RBAC is implemented using the Operations Manager infrastructure. Prior to SnapDrive 4.0 for UNIX there
was limited access control, and only the root user could perform SnapDrive for UNIX operations. SnapDrive
4.0 for UNIX and later provides support for nonroot local user and NIS users by using RBAC infrastructure of
Operations Manager. SnapDrive for UNIX does not require root password of the storage system; it
communicates with the storage system using sd-<hostname> user.
The following steps needs to be performed for setting up RBAC:
The Operations Manager administrator creates a user, sd-admin user, with a capability core access
check over global group (global DFM.Core.AccessCheck). After the Operations Manager
administrator configures the sd-admin user, the admin has to manually send the credential information
to the SnapDrive for UNIX administrator
Operations Manager administrator can also grant (global DFM.Database.Write) to sd-admin to
enable SnapDrive for UNIX to refresh storage system entities on Operations Manager
The Operations Manager administrator needs to create sd-<hostname> user on the storage system
The SnapDrive for UNIX administrator receives user credentials of sd-admin and sd-<hostname>
from Operations Manager administrator
UNIX administrator needs to turn on RBAC functionality by setting the variable rbac-
method=dfm in snapdrive.conf file and restart the SnapDrive for UNIX daemon
Operations Manager administrator needs to grant capabilities to the invoker of SnapDrive in order to execute
SnapDrive commands. For more information on the mapping between capability compared to commands,
see the SnapDrive for UNIX Installation and Administration Guide.
SnapDrive for UNIX checks uses the following formats to check whether a user is authorized to perform the
tasks:
If you are a NIS user running snapdrive command, then SnapDrive for UNIX uses the format
<nisdomain>\<username>. For example, netapp.com\marc.
If you are a local user of a UNIX host such as lnx197-141, then SnapDrive for UNIX uses the format <hostname>\<username> format. For example, lnx197-141\john.
If you are an administrator (root) of a UNIX host, then SnapDrive for UNIX always treats administrator as a local user and uses the format lnx197-141\root.
SnapDrive for UNIX operations are not affected by using or not using naming conventions for LUNs and volumes.
By default, SnapDrive for UNIX makes storage persistent by adding an entry into the file system table. NetApp recommends that you not change this value: in most cases, storage has to be mounted automatically after reboots. -nopersist option can be used in snapdrive storage create
Starting from SnapDrive for UNIX 3.0, more than one volume manager and file system are supported; therefore, in environments where SnapDrive for UNIX operations are executed through scripts, it is highly recommended to specify the -vmtype and –fstype option explicitly in the command to avoid
errors in case the snapdrive.conf file is modified
6.1.2 Storage System Do not create LUNs on the root storage system volume
For better Snapshot copy management, do not create LUNs on the same storage system volume if those LUNs have to be connected to different hosts
If multiple hosts share the same storage system volume, create a qtree on the volume to store all LUNs for the same host
SnapDrive for UNIX also allows you to increase the size of your disk group by using the snapdrive
storage resize command with the –addlun option. By executing this command, SnapDrive for
UNIX creates a new LUN on the storage system and adds it to the disk group. You then have to manually execute commands to increase the size of the file system
To avoid space contentions, do not have LUNs on the same storage system volume as other data; for example NFS share
6.2 STORAGE PROVISIONING IN A MULTISTORE ENVIRONMENT
SnapDrive can manage LUNs on MultiStore units when using the iSCSI protocol. SnapDrive does not
distinguish between a physical storage system and a MultiStore unit. Therefore, there are no changes in the
SnapDrive commands. Also, SnapDrive for UNIX does not support FCP when connecting to LUNs on the
MultiStore unit.
Note
SnapDrive for UNIX supports only iSCSI LUNs on MultiStore only with Data ONTAP 7.2.2 and later.
7 SPACE MANAGEMENT AND SPACE RESERVATION
Data ONTAP uses space reservation to complete writes to a LUN or to overwrite data on a LUN. When you
create a LUN, Data ONTAP reserves enough space in the traditional or flexible volume so that write
operations to those LUNs do not fail due to lack of disk space. Other operations, such as making a Snapshot
copy or creating new LUNs, can succeed only if there is enough available unreserved space.
For more information about calculating the size of the storage system volume, refer to the Data ONTAP Block Access Management Guide for iSCSI and FCP.
7.1 FRACTIONAL RESERVE
For more information about calculating fractional reserve, refer to the Data ONTAP Block Access Management Guide for iSCSI and FCP.
7.1.1 Best Practices for Fractional Reserve Be careful when changing the fractional reserve value to a smaller number, because when you run out of
space, the write operation fails and that can be very disruptive.
Do not use fractional reserve:
Unless you have a mechanism to monitor fractional reserve. SnapDrive for UNIX does not provide this functionality
If you have multiple LUNs in a volume and each LUN has a different rate of change, you must estimate the overall volume size and the combined fractional reserve setting based on the average rate of change of all the LUNs
7.1.2 Guideline for Estimating the Volume Size with Fractional Reserve
Use the following formula to determine the volume size with fractional reserve:
Formula: (1 + fractional reserve) * LUN size + amount of data in Snapshot copies
Example: Consider a LUN with following requirements:
LUN size = 500GB
Fractional reserve for overwrites = 30%
In this case, your volume size should be (1 + 0.30) * 500, or at least 700GB
Note
You have to actively monitor data in the volume using the df –r command to make sure that you do not run
out of overwrite reserve space. If you run out of overwrite reserve space, writes to the active file system fail
and the host application or operating system might crash.
8 SNAPSHOT COPY MANAGEMENT
SnapDrive for UNIX integrates with NetApp Snapshot copy technology to make stored data reliable to host applications. Giving you the ability to create and manage Snapshot copies from the host makes SnapDrive for UNIX attractive to users. Snapshot copies record the state of the blocks in your file system at a given time and provide read-only access to that image of the file system. SnapDrive for UNIX enables you to create, restore, and delete Snapshot copies of the file system, and to clone storage entities from Snapshot copies. For more information on the commands used to perform these tasks, see the SnapDrive for UNIX Installation and Administration Guide. SnapDrive for UNIX Snapshot copies are widely used because of the following distinct advantages:
Host-consistent Snapshot copies (restorable copy)
Faster restore time
Create backups of larger amounts of data in a much quicker way
8.1 BEST PRACTICES FOR SNAPSHOT COPY MANAGEMENT
Disable automatic Snapshot copy creation on the storage system for the volume on which the LUNs are
created and set the Snapshot space reservation to 0 using the following commands on the storage system.
vol options <vol-name> nosnap {on | off}
snap reserve <vol_name> 0
For Data ONTAP 7.1 and later, SnapDrive uses the lun-clone-split-restore method for SnapRestore
operations. This has a limitation that Snapshot copy creation on the volume is not allowed until the lun-
clone-split operation is completed. So it is recommended to monitor LUN cloning status from the storage
system CLI using the lun clone split status command before initiating SnapRestore operations from
SnapDrive.
8.2 CONSISTENT SNAPSHOT COPIES
Making Snapshot copies in a SAN environment differs from doing so in a NAS environment in one very
fundamental way: in a SAN environment, the storage system does not control the state of the file system.
Snapshot copies are useful only when they can be successfully restored. Snapshot copies of a single
storage system volume that contains all the LUNs in the host file system are always consistent provided the
file system supports the freeze operation. But if the LUNs in the host file system span different storage
system volumes or storage systems, then the copies might not be consistent unless they are made at
exactly the same time across different storage system volumes or storage systems and they can be restored
successfully. Starting with SnapDrive 2.2 for UNIX, consistent Snapshot copies can be created using the
Data ONTAP consistency group feature, which is supported beginning with Data ONTAP 7.2.
Example: If a file system /mnt/fs_multi_vol resides over LUNs in storage1:/vol/vol1 and
storage2:/vol/vol1 and Data ONTAP 7.2 or higher is installed on storage1 and storage2, then the
8.2.1 Best Practices for Consistent Snapshot Copies If you cannot use the Data ONTAP consistency group feature, you can use the snapdrive snap create
command with the -nofilerfence option, which switches to the “best-effort mode” used by previous
versions of SnapDrive for UNIX.
SnapDrive for UNIX allows making Snapshot copies of multiple file systems or disk groups using a single
command when the file systems or disk groups are independent of each other. NetApp recommends that
you use the -unrelated option when NFS entities are present with other file specifications in the Snapshot
copy. This option allows SnapDrive for UNIX to treat each file specifications as unique and makes each
Snapshot copy independently.
8.3 SNAPSHOT COPY SPACE MANAGEMENT
Snapshot copy backups occur in a matter of seconds, and each copy typically consumes only the amount of
data that has changed since the previous copy was created. Thus, Snapshot copies consume minimal disk
space, while at the same time providing up to 255 online point-in-time images.
The amount of disk space consumed by an individual Snapshot copy is determined by the following two
factors:
The rate at which the data changes within the active file systems. The data change can be in megabytes per second or megabytes per hour
The amount of time that elapses between creation of Snapshot copies
8.3.1 Best Practices for Consistent Snapshot Copies Disable automatic Snapshot copy creation on the storage system for the volume on which the LUNs are
created.
Periodically use the snapdrive snap list command and delete old Snapshot copies which could
unnecessarily occupy space.
8.4 SNAP RESERVE
Data ONTAP reserves a default of 20% of volume for being available for configuring LUNs or for CIFS/NFS
files to use. This is because Snapshot copies need space, which they consume in the snap reserve area. By
default, after the snap reserve area is filled, the Snapshot copies start to take space from the general
volume. Because of WAFL® technology, snap reserve does not reserve specific physical blocks; rather, it is
a logical space accounting mechanism. For more information on snap reserve, please refer to the Data
ONTAP Block Access Management Guide.
8.4.1 Best Practices for Snap Reserve NetApp recommends setting the snap reserve value to 0%, because the automatic Snapshot copies that are
made by the storage system might not capture the LUN in a consistent state, and allows all the volume
space dedicated for the LUNs.
9 RESTORING A SNAPSHOT COPY USING VOLUME-BASED SNAPRESTORE
Previous versions of SnapDrive for UNIX allowed users to restore LUNs for a host-side entity such as file
system, disk groups and host volumes or normal files created over NFS from an application-consistent
Snapshot copy by leveraging single-file SnapRestore technology.
It is a best practice to execute the -vbsr preview command before using the -vbsr execute
command. If the preview option is used, SnapDrive will perform a series of checks on the volume being restored and present a file-by-file analysis of the restore operation before it occurs. The preview analysis will help you decide if you would like to proceed with the volume-based SnapRestore operation or not.
Use dedicated volumes for data that will need to be restored quickly using the volume-based SnapRestore method.
If there are newer Snapshot copies that were created after the Snapshot copy being used to restore from, then it is a best practice to replicate those Snapshot copies to a secondary storage system using SnapVault® and then perform the volume-based SnapRestore operation.
10 CLONING
SnapDrive for UNIX allows you to clone existing file systems from Snapshot copies. This capability allows
you to make replication copies of existing databases.
Following are some scenarios in which you might use the cloning feature:
When there is an available update for the application running on the storage system LUNs to make sure that the update software satisfactorily runs before using it in production.
To create a copy from a Snapshot copy backup of an existing file system, which contains LUNs on the NetApp storage system that can be mounted on the same host or on a different host to separate the upgrade and testing processes. After the new application update, the cloned file system can be destroyed and the update can be performed on the production storage system during scheduled maintenance.
18 SnapDrive 4.1 for UNIX Best Practices
10.1 FLEXCLONE IN A SAN ENVIRONMENT
Previous versions of SnapDrive for UNIX would leverage FlexClone technology in a NFS environment and
LUN clone technology in a SAN environment. Starting from version 4.0, SnapDrive for UNIX can leverage
FlexClone technology even in a SAN environment also based on the value of the san-clone-method
option in the snapdrive.conf file. The following table illustrates the various possible values that can be
specified for the san-clone-method option in the snapdrive.conf file.
Table 2) FlexClone configuration values.
CLI Usage Snapdrive.conf Variable and Value Description
-clone lunclone san-clone-method=lunclone Creates a LUN clone
-clone unrestricted san-clone-method=unrestricted
Create a FlexClone volume that
can be used as a back end for
provisioning and Snapshot
operations, just like normal
flexible volumes.
-clone optimal san-clone-method=optimal
Automatically chooses between
FlexClone and LUN clone based
on the storage system
configuration.
To use FlexClone in a SAN environment, a FlexClone license is required. No separate license is required for
creating LUN clones.
BENEFITS OF FLEXCLONE
Simplified data management and reduced risk.
Flexibility and greater utilization. You can use FlexClone to create multiple copies of data for additional users without giving them access to the original data.
It is faster than a LUN clone.
10.2 BEST PRACTICE FOR CLONING
Because you can make several numbers of clones from a Snapshot copy, NetApp recommends that you name the Snapshot copy in a way that indicates its usage. One simple naming convention is to prefix the characters cl_ to the cloned file system name; however, SnapDrive for UNIX does not have
any convention for naming Snapshot copies. You can also use the prefix-clone-name option in the
snapdrive.conf file to have SnapDrive automatically prefix a string to the FlexClone copy
Data ONTAP locks any Snapshot copies used to back up cloned volumes and LUNs until the clone is either split or destroyed. Any disk blocks associated with such a copy remains locked and cannot be reused until the copy is deleted. NetApp recommends that you regularly review your existing Snapshot copies and clones to determine if they should be destroyed.
In most cases, cloned LUNs have a short life span. As a result, SnapDrive for UNIX assumes that no reservation is required and sets space reservation to 0%. If you want to set space reservation, you can use the snapdrive snap connect command with the -reserve option to enable the storage
reservation.
You must consider capacity planning when you use clones. For a SAN environment, SnapDrive uses LUN clone mechanism to create clones, which creates a new LUN inside the same volume.
Starting from SnapDrive for UNIX 3.0, the LUN clone split operation is supported with the snapdrive
snap connect command. This can be achieved either by having enable-split-clone=on in the
snapdrive.conf file or by using the –split option in the snapdrive snap connect command.
• Before executing the LUN clone split operation, make sure the volume has enough space to accommodate the cloned LUN; otherwise, resize the volume.
• Always plan the clone split operation during low I/O time period.
19 SnapDrive 4.1 for UNIX Best Practices
• Use LUN clone split only if you are expecting the cloned LUN to be read-write and expecting to impact the original LUN.
• It is recommended to use the –split option instead of enable-split-clone=on so that you
can control the behavior per command.
Note
If you set the enable-split-clone configuration variable value to “on” or “sync” during the
Snapshot connect operation and “off” during the Snapshot disconnect operation, SnapDrive for UNIX
will not delete the original volume or LUN that is present in the Snapshot copy
LUN clone split is not supported with MultiStore
11 SNAPDRIVE FOR UNIX AND SNAPMANAGER FOR ORACLE
One of the major deployments for SnapDrive for UNIX is along with SnapManager for Oracle.
SnapManager for Oracle has become one of the most popular tools for making and managing backups for
Oracle in a NetApp storage environment. SnapManager for Oracle relies on SnapDrive for UNIX to execute
all backup and restore commands on the storage system.
For more information on SnapManager for Oracle product, see the NOW site, as well as the SnapManager
2.2 for Oracle Best Practices Guide (TR-3665) for details required to use SnapDrive for UNIX with
SnapManager for Oracle.
11.1 STORAGE CREATION
There is no change in existing SnapDrive for UNIX syntax to support Veritas Storage Foundation for Oracle
Real Application Clusters (SFRAC) environments. However, you have to add the – devicetype shared
option to the snapdrive storage create command, indicating that the created storage will be
accessed by a different host simultaneously, as in the following example:
11.1.1 Best Practices for Storage Creation in Cluster Environments
Always execute the snapdrive config check cluster command to check for the following in the
SFRAC cluster environment on a Solaris host:
SnapDrive for UNIX version
GAB configuration
Cluster status
CVM status
Usage of rsh or ssh for a secure communication within the cluster nodes
Differences in setting the following configuration variable values in the snapdrive.conf file:
default-transport= "fcp"
multipathing-type="DMP"
Provide fewer file specifications in the snapdrive snap create command. For example, if the
snapdrive snap create command has five or more file specifications in a 10-node cluster environment, the Snapshot copy might time out due to SnapDrive for UNIX needing to check and execute commands on all the cluster nodes and for all the file specifications provided.
If there are errors during the execution of SnapDrive for UNIX commands, execute all cleanup procedures advised by the accompanying error message.
To identify the master node in SFRAC environment, use the vxdctl -c mode command.