了解影子迁移

语言：

影子迁移需要使用插入，但是已集成到设备中，因此不需要单独的物理机。当创建共享资源后，它们可以选择在本地或在 NFS 上充当现有目录的“影子”。在这种方案中，将一次性调度好停机时间，让源设备 X 进入只读模式，并创建设置了影子属性的共享资源，而客户机将更新为指向 Oracle ZFS Storage Appliance 上的新共享资源。然后，客户机可以以读写模式访问该设备。

图 46 影子迁移

在设置了影子属性后，数据将在后台从源设备本地透明地进行迁移。如果客户机请求访问某个尚未迁移的文件，源设备会自动将该文件迁移到本地服务器，然后响应请求。对于某些客户机请求，这会产生一些初始延迟，但文件一旦迁移完毕，所有访问都可在设备本地完成，从而能完全发挥设备本身的性能。当文件系统的当前工作集远远小于总数据大小时，就经常出现这种情况，因此一旦将工作集迁移完毕，无论源上的总数据大小如何，都不会感觉到对性能造成影响。

影子迁移的缺点是需要在完成数据迁移之前执行一些相关任务，不过只有插入方法是这样。在迁移过程中，数据的某些部分存在于两个位置，这意味着备份更加复杂，快照可能不完整且（或）仅存在于一个主机上。因此，非常重要的一点是，两个主机之间进行的任何迁移都要首先进行彻底测试，确保身份管理和访问控制设置正确。这并不需要测试整个数据迁移过程，但应该验证非全局可读的文件或目录是否能正确迁移、ACL（如果存在）是否能保留，以及身份是否能在新系统中正确表示。

影子迁移是使用文件系统中的磁盘数据实施的，因此没有外部数据库，也不在存储池外部的本地存储数据。如果存储池在群集中进行了故障转移，或者两个系统磁盘都出现故障而需要有新的机头节点时，不中断地进行影子迁移所需的所有数据将随该存储池一起保存。

以下列出了影子源的限制：

要正确地迁移数据，源文件系统或目录必须为 *只读状态*。对文件源所做的更改是否会传播取决于其发生的时机，对目录结构的更改可能会导致设备上发生无法恢复的错误。
影子迁移只支持从 NFS 源进行迁移。NFSv4 共享资源将产生最佳效果。也可以进行 NFSv2 和 NFSv3 迁移，但会在迁移过程中丢失 ACL，且相对于 NFSv2 过大的文件无法使用该协议进行迁移。不支持从 SMB 源进行迁移。
不支持 LUN 的影子迁移。

在迁移过程中，如果客户机访问尚未进行迁移的文件或目录，将对文件系统产生以下可监测的影响。以下列出了影子文件系统语义：

对于目录访问，客户机请求将被阻止，直到整个目录完成迁移为止。对于文件访问，将只迁移所请求的文件部分，多个客户机可以同时迁移文件的不同部分。
可以在影子文件系统中任意地对文件和目录进行重命名、删除或覆盖，而对迁移过程没有任何影响。
对于作为硬链接的文件，在迁移完成之前，硬链接计数可能与源文件不匹配。
大多数文件属性都会在创建目录时进行迁移，但只有在对文件完成读取或写入操作后，盘上大小（UNIX stat 结构中的 st_nblocks）才可用。逻辑大小是正确的，但 du(1) 或其他命令会报告大小为零，直到文件内容已实际迁移为止。
重新引导设备后，迁移将从最初停止的位置开始继续进行。虽然不需要重新迁移数据，但可能需要遍历本地文件系统中某些已迁移的部分，因此，可能会由于中断而对总迁移时间有所影响。
数据迁移会利用文件上的专用扩展属性。通常，这些属性是无法查看的，除非它们位于文件系统的根目录上，或者通过快照来查看。如果添加、修改或删除以 SUNWshadow 开头的任何扩展属性，则会对迁移过程产生不确定的影响，并导致不完整或已损坏状态。此外，文件系统级别的状态存储在文件系统根目录的 .SUNWshadow 目录中。如果对此内容进行任何修改，则会产生类似的影响。
文件系统完成迁移后，将发布一个警报，同时会删除影子属性以及任何适用的元数据。之后，该文件系统就与标准文件系统没有任何差别了。
可以通过使用 NFSv4 自动客户机挂载（有时称为“镜像挂载”）或嵌套本地挂载将多个文件系统中的数据迁移到单个文件系统中。

使用以下规则迁移文件的标识信息（包括 ACL）：

迁移源和目标设备必须具有相同的名称服务配置。
迁移源和目标设备必须具有相同的 NFSv4 mapid 域
迁移源必须支持 NFSv4。可以使用 NFSv3，但会丢失某些信息。基本标识信息（所有者和组）和 POSIX 权限将保留下来，但所有 ACL 都会丢失。
必须以设备的 root 权限导出迁移源。

如果您发现文件或目录的所有者为 "nobody"，则可能的原因是，该设备未正确设置名称服务，或者 NFSv4 mapid 域不同。如果在遍历客户机本应能够访问的文件系统时显示 "permission denied"（权限被拒绝）错误，则最可能的原因是，没有以 root 权限导出迁移源。