The NetApp Mixed Security Model
File security on a NetApp filer is handled by the WAFL file system,
which understands both the UNIX and NTFS permissions models. The
security mechanism used depends on whether the file has an ACL.
There are four possible access modes:
• A UNIX client accesses a UNIX file, meaning a file without an
ACL6
• A PC client accesses a file with an ACL
• A UNIX client accesses a file with an ACL
• A PC client accesses a file without an ACL
For the purposes of this paper, all files in UNIX qtrees are
assumed not to have ACLs. This is not always true, as ACLs are
preserved when changing qtree styles. But any ACLs on files in a
UNIX qtree are ignored when doing permissions checks, so the net
effect is as if no file in a UNIX qtree ever has an ACL.
In the first two modes, the filer acts exactly as it would if it
were an NFS or Windows server. The other two modes, which involve
access to a file by a nonnative client, are more complex and are
discussed at length in the following sections.
4.1 Share-Level ACLs
All shares exported by a NetApp filer to CIFS clients have special
ACLs set on them called share-level ACLs. By default, these allow
the special Windows group “everyone” full access, which means
that no additional restrictions are imposed at the share level on
what users can do to the files in the share. System administrators
can elect to set more restrictive ACLs on shares, however. When
this happens, all operations coming in from CIFS clients are first
checked against the share’s ACL to decide whether they can
progress farther (this is done anyway, but because the default ACL
grants everyone full access, it is as if no test were done). This
check is not always mentioned in the following descriptions of how
files are authenticated, but it is important to remember that it is
always done first, before any of the other permissions are
checked.
The concept of share-level ACLs does not apply to clients using the
NFS protocol to access files (UNIX or (PC) NFS clients), as those
are accessed through NFS-exported directories. The export settings
of the exported directory serve a similar purpose in the NFS
world.
4.2 The Qtree Security Style
Data ONTAP implementation has the idea of a “qtree,” which is
an extension of the quota tree concept in previous releases of the
OS. Briefly, a qtree can have its security style set to “UNIX,”
“NTFS,” or “mixed.” The default security style for a qtree
is inherited from the security style set on the volume, which is
set with the qtree command just as if the volume (e.g., /vol/vol0)
is itself a qtree.
It is a common misconception that the security style of a qtree
controls who can access a file system. The truth is that qtree
security type controls the type of permissions applied to files and
directories in that file system. In other words, it controls who
can apply security to a file, not who can access a file. Therefore,
you do not need to have a mixed or NTFS style qtree for PC users to
access data on a filer. Similarly, you do not need to have a
mixed or UNIX style qtree for UNIX users to access data on a
filer.
Files in UNIX qtrees can have ACLs set on them, because qtree
styles may be changed (from NTFS to UNIX) after files in them have
already been created and, perhaps, modified. If an ACL does exist
on such a file, it is ignored by all authentication and
permissions-getting operations. Any subsequent change in
permissions to a file results in removal of the ACL, if it exists,
and the resulting permissions are always “true” UNIX
permissions. In other words, it is not possible to set or change an
ACL on a file in a UNIX qtree.
Similarly, files in NTFS qtrees can have genuine UNIX permissions,
but any change to the security style results in setting an ACL on
them, and subsequent accesses by UNIX clients are validated using
the UID-to-SID mapping mechanism and the file’s ACL. It is not
possible to directly set the UNIX permissions on a file in an NTFS
qtree.
Files in mixed qtrees can have either security style; they always
have the security style associated with the client that was last
used to change their access permissions or ownership. When a UNIX
client sets the permissions on a file, any ACL on it is
removed.
When a PC client sets the permissions on a UNIX file, an ACL is
constructed and attached to the file, which becomes a PC file. A
set of synthesized UNIX permissions is also generated at that time
for use by UNIX clients.
Because of the conservative mapping used by NetApp, changing the
security style on a file from UNIX to PC and back—by setting an
ACL, and then setting UNIX permissions that match the synthesized
permissions calculated from the ACL—can result in a net
permissions change. This unintuitive behavior occurs whenever there
is loss of information going from one security style to the other.
For example, if an ACL allows access to everyone but denies it to
user agy, the synthesized UNIX permissions cannot allow access to
everyone. In some cases, enterprise customers have various
administrators on both UNIX and NTFS side changing file permissions
on a frequent basis. It is not uncommon that the administrators
from Windows and UNIX world sometimes run into each other and mess
up each other’s permissions. For these customers, it is
recommended not to use mixed qtrees unless it is absolutely
necessary.
UNIX shops that use groups heavily, however, could also have
problems with mixed permissions. This is because the OS has no way
of determining what UNIX groups a mapped CIFS user might belong to,
so the permissions for the UNIX group of the file are set to the
same as the permissions for others.
Loss of information does not happen when you change the security
style of a qtree. Changing the security style of a qtree does not
affect the files in the tree, so you can change a qtree from NTFS
style to UNIX style, and back, without changing permissions on any
of the files in the qtree. This is true even if the file system has
been dumped and restored (using the NetApp dump and restore console
commands) in the meantime.
However, just as with mixed style security, any permission changes
made subsequent to the qtree security style change will become the
effective security and will replace the style of security settings
that were in place before the security style change.
Either UNIX or PC clients can access files in a qtree. As was said
in the last section, file accesses when the file and client type
are the same have the same semantics as if the client were
accessing a file on its native file system. The cases where the
client and file security style do not agree are discussed
next.
4.3 Access to a File without an ACL by a PC Client
When a PC client requests access to a file without an ACL, the UNIX
permissions on the file are used to determine whether to grant
access to the file. The requester’s NTFS SID is looked up on the
domain controller (or local user database) to get a username. The
username is then mapped to a UNIX username using the name-mapping
feature, which is then looked up through the /etc/passwd file (or
NIS or LDAP) to get the mapped user’s
ID and group IDs (UID and GIDs). These are then compared to the UID
and GID and associated permissions for the file, exactly as if the
requester were the mapped UNIX user.
If the client wants to set the permissions on a file, the result
depends on the qtree security style. If the file is in a UNIX
qtree, the PC client cannot set an ACL on the file and can perform
only the actions allowed by its mapped UNIX ID. This means that the
PC client must use a remote session on a UNIX client to set the
UNIX permissions on the file.
UNIX Set an ACL on the directory. Permission to do this must have
been granted by the permissions gotten from WAFL on the original
access request. The new ACL overrides any previous UNIX permissions
and is used to determine whether any future attempts to add,
delete, or change files in the directory should succeed.
This case would be valid if the qtree style was mixed or if the
qtree style had previously been UNIX but was changed to NTFS or
mixed.
Set an ACL on the file. Same basic rules as for directories.
This case would be valid if the qtree security style is mixed and
the security style of the directory or file is already NTFS style
or if the qtree security was NTFS.
4.4 Access to a File with an ACL by a UNIX Client
In a UNIX qtree, a file can have an ACL, but the ACL is ignored and
standard UNIX permissions checking rules are used.
In a mixed qtree, when a UNIX client requests access to a file with
an ACL, the ACL was formerly translated into a set of
“effective” UNIX permissions that the client can understand.
The UID-to-SID mapping mechanism is now used to do permissions
checking, but the translation is still done, for use by some UNIX
operations such as chown, for when CIFS is unavailable or when the
qtree style is changed, and so forth.
The same “conservative mapping” rule as mentioned previously is
used in doing the translation, so that no UNIX user can get access
to a file that he or she could not have obtained under the CIFS
protocol. This mapping is done at the time you set the ACL, so the
effective permissions are always available for authenticating UNIX
clients. If the UNIX client subsequently sets the permissions on
the file, however, the resulting
permissions are “true” permissions, and the ACL is
removed.
If the file is in an NTFS qtree, file access works the same way as
in a mixed tree, but the UNIX client cannot set UNIX permissions on
the file. NetApp does not presently furnish a way for UNIX users to
set ACLs on files. These functions are described below in
5. Another Data Access Protocol—HTTP
NetApp support of HTTP is similar to support for NFS and CIFS in
that each request is serviced by a continuous process, from the
network driver through the file system and back. Having the HTTP
server embedded inside the Data ONTAP real-time microkernel offers
a significant performance advantage over traditional Web servers
that run as applications in user space, outside the kernel on UNIX
or Windows platforms. In the current implementation of NetApp Web
Filer™, only the HTTP get operation is supported. This means that
Web Filer may need to be deployed in concert with one or more
traditional web servers, to handle any non-get operations.
Typically, get operations account for the overwhelming majority of
HTTP requests received by a Web server, and so by handling the
lion’s share of the incoming load, Web Filer can have a dramatic
impact on the effective performance of a Web site. Furthermore, the
companion Web servers can (and should, for simplest administration
and most scalable configurability) be configured as NFS or CIFS
clients served by the filer, facilitating the use of a consistent
file naming convention within a common file system across both (or
all) Web servers.
For further discussion of Web site configuration using Web Filer,
see NetApp Technical Report, “Migrating to a Web Filer”
[TR-3012]. For other even more effective methods of scaling Web
service, NetApp Net Cache® products can be used in conjunction
with (or instead of) Web Filer.
5.1 HTTP for Filer Administration
The GUI provided for administration of a NetApp filer uses HTTP.
This allows the user to sit at any platform and use any Web browser
to execute administrative tasks. This does not require the HTTP
protocol to be licensed and enabled on the filer, because it uses a
special, nonstandard port and facilitates access only to specific
administration files and actions.
You can use this tool to monitor the filer’s status remotely.
Performance is displayed graphically. You can control configurable
parameters and options (e.g., setting the minra option for minimum
read-ahead). And you can apply all actions that change the
filer’s current, active configuration to configuration files that
the filer consults at startup time. In a future release,
simultaneous administration of multiple filers will be added.
For additional information about HTTP-based GUI administration
tools for NetApp filers, see the NetApp System Administrator’s
Guide on the NOW™(NetApp on the Web) site.
5.2 HTTP for Filer Setup
The Filer Setup Wizard is designed to facilitate setup of a filer.
As is the case with FilerView, Filer Setup Wizard can be run by a
Web browser on any platform and doesn’t require that the HTTP
protocol be licensed. The wizard is used to set up protocol
licenses, current time zone, language options and network
information.
6. Using Multiprotocol Filers
There are many protocol combinations available on NetApp filers:
NFS-only, CIFS-only, and NFS-plus-CIFS. In all three cases, HTTP
access can also be enabled. Note that NFS here implies both NFS
versions 2 and 3, operating over UDP and/or TCP transport layers
(see Figure 3). For more information about the configuration
options and software offerings, see the NetApp Software
Configuration Guide available at the NOW site.
Multiprotocol filers are designed to make deployment into
heterogeneous (mixed NFS and CIFS) environments as easy as
possible. The homogeneous (all NFS, or all CIFS) cases are simpler
to plan and implement. For the purposes of this paper, the
discussion assumes a mixed environment with UNIX-based NFS clients
as well as Windows-based CIFS clients.
6.1 Administration and Security
• In general, whether in the context of NFS or CIFS, file servers
must constrain access to files based on file ownership, explicit
permissions (e.g., read and/or write privileges) granted to other
users, implicit permissions inherited from the local directories in
which the files are found, or the directory tree as exported or
shared by the file server.
• File access restrictions are typically created by users (for
the files they own) and systems administrators (for shared file
systems and directory trees, or when creating a user’s home
directory).
• User (and sometimes client system) identification must be
authenticated prior to file access.
• All of the above are different for NFS and CIFS. Both NFS and
CIFS methods are explained and compared in Sections 6.1.1 and
6.1.2, below. Section 6.1.3 describes how these security models are
comprehensively merged on NetApp filers.
In a heterogeneous environment, information about
users—usernames, group affiliation, and passwords—is accessible
in multiple formats from multiple sources. Merging the namespace
for users is strategically important to the task of administering
shared resources on a network. This is usually accomplished by
assigning UNIX-style UIDs and GIDs (integer-value User IDs and
Group IDs) to PC users. Thereafter, the database of PC users must
be carefully updated in two places: typically via NIS (Network
Information System) among the UNIX platforms, and via Windows NT/AD
(Active Directory)
Domain on the PCs. This is onerous, especially for sites with large
numbers of Windows users that do not have any other need for having
a UNIX UID and GID assigned to them.
(NetApp offers two methods for eliminating this time-consuming
administrative overhead, as described below in Section
6.1.3.)
User information is used by a NetApp filer to enforce
security—basically for authentication of the user and to regulate
file access based on permissions. These mechanisms and events are
fundamentally different for UNIX and NFS versus PCs and CIFS.
First, let’s look at NFS and then contrast it with CIFS.
6.1.1 NFS
• NFS exports data to a client system. NFS relies on the client
to authenticate its own users. Given the complete local control a
user might have over a client system, the NFS security model can be
subverted relatively easily.
• NFS is UNIX-derived and therefore implements a UNIX-style set
of file permissions limited to three categories of users
(user/group/other) and three types of file permissions
(read/write/execute).
• An NFS file server can apply various options (e.g., restricting
all access to read only) when exporting, and an NFS client has
similar options when mounting from an NFS file server;
• A NetApp filer can export to specified NFS clients, netgroups
(lists of clients), or even network subnets (note that exporting by
subnet is not always available on conventional NFS file servers
from other vendors).
With UNIX NFS clients, file systems are “mounted” from the
server so as to be logically indistinguishable from local file
systems. This can happen without any user activity— simply as a
result of starting up the client, for example. The NFS server will
grant or deny the mount request based on the hostname of the
client, as dictated by restrictions specified in the /etc/exports
file (which contains lists of hostnames—or on a NetApp
filer
it could also be a list of network subnets). No password or other
authentication is required by an NFS server7.
User authentication is performed by the client, not the server. The
client-authenticated user’s UID must be passed across the network
with all NFS requests sent to the server. (PC) NFS requires a
username and password at mount time, but that is to rectify a
deficiency, from the UNIX
perspective, in the PC client, and not a function of the NFS
protocol per se.
Therefore, if a user can convince8 the NFS client of identity
username associated with the UID n, then an NFS server will accept
that any NFS requests issued by that client on that user’s behalf
are for UID n. One exception to this occurs when n corresponds to
the superuser (“root”), in which case an NFS server will assign
unauthenticated status (the user “nobody”)—unless root access
privileges have been assigned to that client in the
/etc/exports file. It contains the list of resources to be exported
when Data ONTAP starts up, restarts, or receives the exportfs –a
command (given that a valid NFS license exists). Maintaining the
/etc/exports file enables resources to be available automatically
upon filer startup and eliminates the need to enter the exportfs
command for each resource you want to export.. In the /etc/exports
file, you also specify the access restrictions and security service
with which clients can mount each resource. At any time after filer
startup, you can override specifications in the /etc/exports file
by using the
exportfs command (until the filer is restarted or another
overriding exportfs command is issued).
Each time an export rule is loaded into memory, it undergoes a
straightforward conversion from a string to an entry in a hash
table. The basic string format is:
/vol/volFoo -rw=host1,ro=host2
This specifies that host1 has read/write access on volume volFoo on
the filer while host2 has only read-only access right. However, if
-rw or -ro is specified with no hosts, for example:
/vol/volFoo -rw=host1,ro
then it implies all hosts. So the above example would be host1 gets
read/write, and all other hosts get read-only.
Note that the current version of Data ONTAP supports user
authentication through Kerberos. By specifying security services
option “sec=krb5” in the exports list, you can control NFS/CIFS
access to a specific volume at the user lever. For more information
on
Kerberos, refer to TR3367 and TR3085.
6.1.2 CIFS
• CIFS shares data with users (not machines, as with NFS).
Authentication of a
CIFS user’s identity is done by the server, not the client (as
with NFS).
• In a Windows NT/AD domain, the server can use another system
(the domain
controller) for authentication of users’ credentials. It is
easier to make file
This can be done with a valid password (perhaps one that has been
guessed or stolen), or by some means that bypasses the use of the
password on the client (e.g., using an NFS file handle snooped from
legitimate network traffic).
• CIFS share, directory, and file permissions are controlled by
ACLs. ACLs can include permissions specific to individuals or
groups of users.
• Users accessing files via CIFS are generally more at risk when
the file server restarts than would be the case with NFS.
Therefore, CIFS users should be warned well in advance of file
server restarts. (NetApp filers provide automatic notification of
file server shutdowns and restarts, sent to all users with open
CIFS sessions.)
A CIFS server provides access to a file system (or a directory tree
portion of a file system) in a unit called a share. In many
respects this is similar to an NFS export, except that NFS exports
file access to a remote host (essentially, an IP address), whereas
CIFS shares are network accessible to users, not machines.
Unlike NFS, no UID is passed over the network with each CIFS
request. Nor does the client “mount a file system” without an
active user (as does a UNIX NFS client). Instead, the initial
connection-establishment sequence requires the user’s PC to
provide credentials to the file server. In a Windows domain, these
credentials were previously obtained when the user first logged on
to the domain (when NetLogon required the user
to provide a password). The server then authenticates the user’s
credentials (either with a domain controller through Active
Directory or by looking up the user in a local file), and obtains
additional information (user ID and group affiliation) used for the
duration of the connection. (See Section 6.4 for more about
authentication with NetApp filers.)
Notice the higher granularity and heightened security of CIFS
compared to NFS. Each CIFS session provides a single10 specific
user with access to a single specific share, with access
authenticated by the server, not the client. This requires a CIFS
server to maintain a persistent state, whereas an NFS server is
stateless, trusting the client for user authentication and relying
on it to provide information (e.g., UID and GID) repeatedly,
with every request.
The downside to this is resiliency after failure. If the CIFS
server restarts, connections are broken and sessions are lost,
requiring the user’s PC to repeat the authentication procedure
(i.e., supply a username and password in a dialog with the
server—usually executed automatically and transparently from the
user’s perspective). With some applications running on a CIFS
client (e.g., Microsoft WordPad), a server restarting very
There can be multiple domain controllers (DCs) for redundancy
purposes.
Multiple-user Windows server implementations (for example, WinDD
[Tek-96] and WinCenter [NCD-96]) can establish CIFS sessions for
many users.
Other applications might attempt to perform I/O to the server more
continuously, leaving no window for client-tolerable server
restarting. If a CIFS client attempts file access on an established
connection while the server is unavailable (down or not yet
finished restarting), this is effectively the equivalent of a
failed disk from the perspective of the application software. In
many cases, the application will report an error and allow the user
to retry, but some applications will simply hang or exit.
Unlike other CIFS implementations, NetApp filers can provide
automatic notification of shutdowns and restarts, sent to all users
with open CIFS sessions whose machines have been configured to
receive such messages. This will at least give users an opportunity
to save their work (and in some cases, exit the application if
necessary), without the system administrator needing to remember to
broadcast a warning.
NFS’s statelessness allows it to tolerate events like restarts
without impact on the user’s application (which simply waits on
the client side, under most circumstances, until the server has
restarted). Essentially, NFS was designed such that each operation
would be independent, but CIFS is session-oriented. There are pros
and cons to both approaches, but it must be conceded that CIFS
offers a stronger security model than NFS.
File locking (see Section 6.5)—a component of security in some
contexts—is also stronger with CIFS than with NFS.
Another important difference between NFS and CIFS is the nature of
the file permissions themselves. Instead of the limited file
permission model12 in UNIX and NFS, NTFS and CIFS permits a richer
file access permission description. ACLs define a list of users
and/or groups mapped to permissions, and can be as long as
necessary. Figure 9 offers an example of an ACL. See Section 2.2.1
for more details.
NetApp filers reboot in about one minute, regardless of the size of
the file system or the configuration of the server.
Although some versions of UNIX also support ACLs, these ACLs are
not the same as CIFS ACLs, and are not yet interoperable among
diverse UNIX implementations.
Figure 9) ACLs in NTFS. A user’s access privileges for a file are
determined by the user’s explicit presence in the ACL, or
membership in a group included in the ACL. An ACL entry can define
rights granted or explicitly deny all access. If a user’s
multiple group affiliations result in an
ACL both granting and denying permission for one or more forms of
file access, then denials override grants. As with options applied
to the whole exported (or mounted) file system (or exported/mounted
subtree) with UNIX and NFS, CIFS shares also have global
properties—an ACL that applies to the whole share. In the event
that multiple shares overlap, and include one or more directories
in common, the applicable ACL derives
from the share that provided the client’s connection path to the
file.
6.1.3 Multiprotocol Filer
• Tree-by-tree, system administrators can configure a NetApp
filer to implement PC-style file access permissions (which apply
administrator- or user-specified ACLs), UNIX-style permissions
(read/write/execute), or “mixed” mode where both styles of file
access permissions are applied.
• NetApp filers offer the industry’s only completely integrated
locking across protocols (see Section 6.5).
• The Active Directory Users and Computers snap-in (Windows
Server Manager and User Manager utilities for Windows NT), or the
Computer Management snap-in can be used to administer NetApp
multiprotocol filers. Also, NetApp offers FilerView for an
administrative interface via a Web browser, or a command-line
administrative interface can be used via telnet or the console
serial port.
• NetApp filers resolve UNIX-style hard and symbolic links
(conceptually similar to Windows shortcuts) on behalf of Windows
users, when the links point elsewhere within the filer. (Hard links
always meet this requirement, but symbolic links can point
anywhere.)
• Windows NTFS based file access auditing is available for both
Windows (CIFS) and UNIX (NFS) clients.
A NetApp multiprotocol filer is designed to meet the administration
and security requirements of a heterogeneous environment. The
applicable requirements are somewhat different than for a server
intended for a purely UNIX or purely PC network.
Fundamental differences in file attributes (especially access
permissions, file names), authentication, locking, and
statefulness/statelessness, make this particularly challenging. For
all of the above considerations, the features and behavior of the
NetApp filer have been extended natively to provide file service to
all users in the mode that is familiar for each of them, with no
trade-offs in performance, reliability, or ease of
administration.
NetApp has implemented NTFS-style file-, directory- and share-level
ACLs by extending the WAFL file system (which has the advantage of
being neither a UFS nor an NTFS).
Therefore, unlike emulated CIFS file service applications running
on competitors’ UNIX- derived file servers, NetApp does not need
to maintain a “shadow database” of files containing the
NTFS-style ACLs. This has several benefits:
• Faster (lower latency, faster response time) file access
• Stronger integrity in the event of an unplanned shutdown (i.e.,
no possibility for the actual file system and a “shadow
database” to get out of sync)
• UNIX file access metadata is accessible to Windows clients as
NTFS-style “extended file attributes”
• UNIX-style ACLs will be available with the emerging NFSv4
standard.
There are three modes of file access enforcement modes available13
on a NetApp multiprotocol filer: UNIX-style; NTFS-style; and mixed
mode
...
In NFSv4, both advisory locking and mandatory locking are
supported, the addition of mandatory locking would greatly improve
NFS performance.
Emulated CIFS file servers like SAMBA cannot truly enforce respect
for CIFS locks among NFS clients. The emulated CIFS file service
runs as an application, outside of the kernel and independent of
the underlying file system, potentially allowing NFS accesses to
“go around” its locks. To mitigate the likelihood of such
events, SAMBA (or a commercial CIFS-emulating equivalent) registers
with the lock daemon all PC locks it has granted. However, most
UNIX applications have not been written to query the historically
unreliable lock daemon before opening files; therefore, NFS
violations of PC locks are routine on such CIFS-emulating
servers.
Before a NetApp filer responds to any file access request, it first
verifies that the client has the appropriate permissions. For a
CIFS file access request, the filer also checks—in the WAFL file
system—that there are no outstanding locks that would exclude the
attempted access. For an NFS file access request, this same lock
check is made, plus the application software running on the NFS
client may in some cases interact with the Lock Manager. PC clients
will not interact with the Lock Manager unless they are using (PC)
NFS instead of CIFS.
6.6 Character Sets
WAFL fully supports UNICODE, a 2-byte encoding system that provides
the capacity to encode all of the characters used for the written
languages of the world. Windows is based on UNICODE and can
theoretically support (correctly write, view, and access) file
names with any of the supported characters at the same time. The
fonts included with the operating system, however, do not contain
all of the UNICODE characters. Windows 2000 and third-party fonts
for Windows support most, if not all, of the UNICODE
characters.
UNIX/NFS does not support UNICODE. Instead it supports simple code
pages that are subsets of locales. On a given network, all UNIX
machines and filers should be set to the same locale so that file
names will be displayed uniformly. Since UNIX/NFS is case
sensitive, the operating system does not need to interpret the bit
string representing the file name. This is contrary to the
operation of NTFS, which needs to interpret case for the entire
UNICODE character range.
Windows 9x systems support a subset of UNICODE for file names only.
User names and share names are encoded using code pages. These
systems should therefore have the language set to the same as that
of the file server.
Windows NT, 2000, 2003, and XP use UNICODE for Network Neighborhood
displays.
For simplicity and better manageability (from, say, a centralized
support location) the same language should be used across the
entire Windows network. An even simpler solution would be to
standardize on ASCII-based machine and domain names. On a filer,
language is set per volume. This is a very useful feature for
multinational companies employing UNIX/NFS clients in different
countries (locales).
For each file, WAFL keeps a long file name (up to 255 characters)
and a DOS-style 8.3 filename. If a CIFS client creates a UNICODE
file name containing non-ASCII characters, WAFL will create an
ASCII file name so that UNIX/NFS clients can always access the
file. In the case where a UNIX/NFS client writes a file containing
characters that are illegal for PC clients, an 8.3 file name will
be generated. The same is true if there is a case collision.
UNIX/NFS generated file names that don’t translate to UNICODE are
preserved in such a way as to maintain the original bit stream.
Data ONTAP supports a variety of languages, simply use the Data
ONTAP command “vol lang” to retrieve a most current list of
supported languages.
6.7 Snapshot Copies
The NetApp WAFL file system has an interesting feature not found in
other file systems, called Snapshot copies.
A Snapshot copy is a “frozen” (read-only) point-in-time copy of
the file system created by preserving all the pointers to all the
disk blocks currently in use at the time of the copy. After a
Snapshot copy has been made, changes to files are reflected in
updates to the current set of pointers18, no differently than if no
Snapshot copies existed. The disk usage overhead of Snapshot copies
is minimized by preserving individual 4KB disk blocks instead of
whole files. Snapshot copies can be scheduled to occur
automatically on a recurring basis. Data recovery from online
Snapshot copies is a much more efficient way compared to tape
storage. There can be up to 255 Snapshot copies per volume at any
one time.
Files in a Snapshot copy of the file system have the same access
privileges as in the active file system. A user with permission to
read a file in the active file system will still be able to read it
in a Snapshot copy. Users without such permission will still be
unable to read the file. Write access privileges simply do not
apply—files within a Snapshot copy cannot be changed because
Snapshot copies are read-only. Updates to files must be performed
on the file’s image in the current, active file system.
Backups can be performed via Snapshot copies, allowing users to
continue to write to the live, actual file system without
endangering the restorability of the backup in progress. In fact,
the NetApp dump command will automatically create a temporary
Snapshot copy for its own use, unless directed otherwise by the
system administrator.
Snapshot copies are whole parallel file systems, from the top of
the directory tree on down. There is an entry into this parallel
directory tree accessible from every directory— a subdirectory
named .snapshot for UNIX/NFS (and PC software that can handle long
file names) within every directory in the active file system. These
.snapshot
The WAFL file system never overwrites existing blocks in a file.
Instead, WAFL always writes new blocks, then updates the pointers
in the active file system, and releases the superseded blocks for
other use—unless those older blocks are still part of a Snapshot
copy.
Within the .snapshot subdirectories are lower subdirectories named
for the interval in which that particular Snapshot copy was
made.
Also, at the top of the directory tree, the Snapshot copy may be
entered through a visible (see below) directory named .snapshot
(for UNIX/NFS), ~snapshot for long-file-name-compatible PC/CIFS
clients, and ~SNAPSHT for PC/CIFS clients that require 8.3 file
names.
In order to avoid confusion, except for the top of the directory
tree, Snapshot copy entry point subdirectories are not
displayed—are invisible—in ordinary listings of directory
contents, and cannot be revealed by other methods of inspecting a
directory’s contents.
This is accomplished slightly differently in NFS than in CIFS.
Aside from simplifying the user’s interface with the file system,
concealing Snapshot copies also protects against problems such as
the UNIX recursive remove (rm -rf) failing because of the read-only
nature of the contents of a Snapshot copy.
The example below shows the appearance of the Snapshot copy
parallel directory tree from the UNIX/NFS perspective.
# ls -alg ~agy/test
total 444
drwxr-xr-x 2 agy eng 4096 Nov 18 01:10 ./
drwxr-xr-x 30 agy eng 8192 Nov 26 19:25 ../
-rw-r--r-- 1 agy eng 197648 Nov 18 01:09 results.1
-rw-r--r-- 1 agy eng 233224 Nov 18 01:09 results.2
# ls -alg ~agy/test/.snapshot
total 48
drwxrwxrwx 2 root wheel 4096 Nov 27 00:01 ./
drwxr-xr-x 2 agy eng 4096 Nov 18 01:10 ../
drwxr-xr-x 2 agy eng 4096 Nov 18 01:10 hourly.0/
drwxr-xr-x 2 agy eng 4096 Nov 18 01:10 hourly.1/
# ls -alg ~agy/test/.snapshot/hourly.0
total 444
drwxr-xr-x 2 agy eng 4096 Nov 18 01:10 ./
drwxr-xr-x 30 agy eng 8192 Nov 26 19:25 ../
-rw-r--r-- 1 agy eng 197648 Nov 18 01:09 results.1
-rw-r--r-- 1 agy eng 233224 Nov 18 01:09 results.2
By convention, the UNIX /bin/ls command (which lists a
directory’s contents) suppresses display of file names beginning
with the dot character (e.g., the file named .cshrc). If the
/bin/ls command is invoked with the -a command line option, the
resulting directory listing then displays such “hidden” files.
However, even with the -a option, display of the file named
.snapshot will still be suppressed. Only when .snapshot is provided
as an explicit command line argument will /bin/ls “see” it (or
its contents). The effect of this can be seen in above
example.
PCs have a similar convention, in which the Windows GUI allows
users to choose to have “hidden” files suppressed from display.
However, unlike the UNIX /bin/ls command, the Windows GUI will
include ~snapshot (or ~SNAPSHT) in listings of files together with
other hidden files. In other words, although with NFS .snapshot is
a special category of hidden file, via CIFS the display of
~snapshot is no more suppressed than other hidden files. Figure 10
shows how Snapshot copies are displayed at the Windows command
prompt and Figure 11 shows how they are displayed in the GUI.
The ~snapshot directory can be completely hidden (even to Windows
clients that are configured to “view hidden files”), yet remain
browseable by explicitly specifying the directory name. An easy way
to configure this is via FilerView.
Snapshot copies provide users with a method to recover almost
instantly from accidental file deletions or to return to older
versions of files. This can lift a significant burden from the
shoulders of the system administration staff, in that fewer
recoveries of files from backup tapes are likely to be requested by
users. Consequently, NetApp customers often cite Snapshot copies as
a resource they could not appreciate fully until they had
experience with them, but that they came to increasingly depend
upon over time.
Furthermore, Data ONTAP Snapshot copies can also be reverted to
become the active file system or propagated to remote machines for
mirroring of data.
For more details about Snapshot copies, see Section 2 of NetApp
Technical Report 3002.
6.8 Filer Management with DataFabric® Manager
As a customer’s need for storage grows, so does the number of
filers. Although Data ONTAP software aims at reducing the
complexity of storage management by providing features such as
Snapshot and multiprotocol access, system administrators still
encounter pain points in these areas as the company grows:
• Too many isolated “storage islands” and too many point
solutions to manage these storage islands
• Complex processes for allocating and expanding storage
• Need for visibility into where each device is and how they are
being used
• Need for 24x7 access; need to know that something is going
wrong before the failure occurs; extremely expensive
downtimes
• Need for unified view of where the bottlenecks are (CPU,
network, or the application?)
• Extremely complex management in mixed NAS and SAN environment;
UNIX and Windows environments (need to make sure IT can use data
across platforms/OS)
• Need for visibility into who is using what, resource sharing,
what filers are overloaded and what filers are underutilized
• Difficult advance planning (knowing when to add capacity)
NetApp DataFabric Manager (DFM) is a powerful, easy-to-use
application for managing a NetApp storage/NetCache infrastructure
from a single console.
DFM addresses these pain points by allowing an organization to
rapidly deploy, provision, and manage a complete enterprise storage
network. For more information on DFM, refer to TR3296.
7. Conclusions
Multiprotocol filing facilitates easier sharing of data in
heterogeneous environments without compromising security. This
drives cost savings, streamlined administration, and enhanced
productivity. As mixed environments become increasingly common, the
need for more multiprotocol filing will also increase.
The unique elements of Data ONTAP software—the specialized
microkernel, the WAFL file system, support for NDMP, fully
integrated and dynamically expandable RAID-protected storage,
etc.—make native multiprotocol filing a practical reality for
environments employing NFS, CIFS, and HTTP. The WAFL file
system’s unique Snapshot capability is especially useful for
making fully restorable backups with minimals’ access to their
data. NetApp has also supplied a suite of essential features and
utilities that make deployment in a multiprotocol environment
easier, including tools for dynamically mapping Windows user
accounts to UNIX UIDs, or assigning all Windows users the same UNIX
user account, migrating Windows domain user account information to
UNIX password and group databases, and so on.
Foreign language support is provided by a unique dynamic mapping of
ASCII (for NFS) and UNICODE (for Windows).
