Table of Contents
Advertisement
migrated, the appliance will automatically migrate this file to the local server before responding
to the request. This may incur some initial latency for some client requests, but once a file has
been migrated, all accesses are local to the appliance and have native performance. It is often
the case that the current working set for a filesystem is much smaller than the total size, so once
this working set has been migrated, regardless of the total native size on the source, there will
be no perceived impact on performance.
The downside to shadow migration is that it requires a commitment before the data has
finished migrating, though this is the case with any interposition method. During the migration,
portions of the data exist in two locations, which means that backups are more complicated,
and snapshots may be incomplete and/or exist only on one host. It is therefore extremely
important that any migration between two hosts first be tested thoroughly to make sure that
identity management and access controls are setup correctly. This need not test the entire data
migration, but it should be verified that files or directories that are not world readable are
migrated correctly, ACLs (if any) are preserved, and identities are properly represented on the
new system.
Shadow migration is implemented using on-disk data within the filesystem, so there is no
external database and no data stored locally outside the storage pool. If a pool is failed over in a
cluster, or both system disks fail and a new head node is required, all data necessary to continue
shadow migration without interruption will be kept with the storage pool.
The following lists the restrictions on the shadow source:
In order to properly migrate data, the source filesystem or directory *must be read-only*.
■
Changes made to files source may or may not be propagated based on timing, and changes
to the directory structure can result in unrecoverable errors on the appliance.
Shadow migration supports migration only from NFS sources. NFSv4 filesystems will
■
yield the best results. NFSv2 and NFSv3 migration are possible, but ACLs will be lost in
the process and files that are too large for NFSv2 cannot be migrated using that protocol.
Migration from SMB sources is not supported.
Shadow migration of LUNs is not supported.
■
During migration, if the client accesses a file or directory that has not yet been migrated, there
is an observable effect on behavior. The following lists the shadow file system semantics:
For directories, client requests are blocked until meta-data infrastructure is created on
■
the migration target for any intervening directories for which infrastructure is not yet
established. For files, only the portion of the file being requested is migrated, and multiple
clients can migrate different portions of a file at the same time.
Files and directories can be arbitrarily renamed, removed, or overwritten on the shadow
■
filesystem without any effect on the migration process.
For files that are hard links, the hard link count may not match the source until the migration
■
is complete.
Understanding Shadow Migration
Shadow Migration
429
Advertisement
Table of Contents
