F5 ARX-VE, Planning Manual

Page: 28 / 64

Chapter 1
Site Planning
1 - 22
the file servers’ Windows domain. The proxy user requires strong privileges
on all CIFS-supporting servers, This user account must belong to the
Backup Operators group or a group with equivalent privileges, and it must
have full control (defined as both read and change control) over all files and
directories in the share.
To support CIFS subshares and their share-level ACLs, the proxy user
credentials must belong to the more-privileged Administrator’s group.
These higher privileges are required for RPC queries, such as queries about
the physical paths of the filer’s shares and subshares.
You may also need to address potential issues with licensing, local groups,
and mapping a proxy user to the UNIX root user. These issues are discussed
in the following sections.
Windows Server Licensing
Each namespace can use up to 16 threads for replicating and migrating files
between back-end CIFS shares. Since a thread can move files between
shares on the same Windows server, using one connection to the source
share and a second connection to the destination share, this means that each
namespace can use up to 32 concurrent server connections.
If your installation supports Per-Seat licensing, this is not an issue. For
Per-Server licensing, you must configure each back-end server with 32
licenses per namespace.
Support for Local Groups
If you plan to use a CIFS server with Local Groups in an ARX volume, you
must duplicate the local groups on each of the volume’s servers. This only
applies to a volume where you plan to use policy to migrate files. If a client
has access to a file on server A because he is a member of the “doctors”
local group, he cannot access the file if it moves to server C, where the
“doctors” group is undefined. If the volume has policy running, the policy
engine is likely to migrate many files between server A and server C.
You can also configure a volume to copy its files to a remote ARX volume,
called a
shadow volume . In this case, you must copy all local groups behind
the source volume to all servers behind the shadow volume. This facilitates
client access to the local copy as well as the remote one. If the shadow
volume site is in a different Windows domain altogether, you must duplicate
all of the Windows user groups in the source volume file servers in all of the
shadow volume servers.