RFC3530 定义了NFS文件系统迁移和引用的管理机制。文件系统定位功能通过fs_location属性向客户端提供文件系统的位置信息。fs_location属 性是一个包含有位置信息的列表，位置信息由一个主机名(hostname)和一个路径名(path)组成，其中路径名表示服务器端的根(root)文件系 统。fs_location的具体含义依赖于具体的服务类型(引用，迁移或者备份)。对于迁移来说，列表中的位置信息表示数据被迁移到的最终位置；再者对 于备份来说，列表指定了备份文件系统所在的位置。
该文档主要是简短地分析了引用，迁移和备份，同时提供如何使用它们的配置信息。
1. 引用（Referrals）:
当客户端第一次访问一个文件系统就被重定向到一个新的位置，这种情况是最好描述的，客户端会被其视为一个文件系统引用，而不是一个迁移事件。因为在迁移发生之前，客户端是不可能获取到该文件系统迁移后的任何信息。
在文件系统迁移过程中，如果没有任何客户端访问文件系统，将存在一种文件系统引用的简单状态(pure应该叫单纯)：所有客户端看到的将是一个抽象文件系统的引用。
客户端可以通过这些引用信息来定位文件系统当前的位置，服务器可以有效地提供这些引用信息，尽管文件系统在服务器端从来没有被重新设置。
文件系统引用让构建一个多服务器的命名空间成为可能。对于提供引用的服务器，客户端可以通过名字来标记一个文件系统。服务器配置的修改不会影响到客户端，如将文件系统从一个服务器迁移到另一个服务器。
与单一服务器节点共享所有的文件系统相比，文件系统引用很好地将压力平均到多个服务器。可以很简单地想象这样一个框架：一个服务器只向客户端提供文件系统引用信息，将文件系统请求分配到包含有数据的服务器去。
配置
服务器必须在/etc/exports文件中，通过以下选项指定迁移后文件系统的位置：
refer=<directory>@<host>
示例
/export/docs <world> (rw,async,wdelay,insecure,no_subtree_check,refer=/[email protected]) /export/sources <world> (rw,async,wdelay,insecure,no_subtree_check,refer=/[email protected])
该配置表明服务器上的/export/docs和/export/sources已经被迁移到另外两个服务器。
注意：只需要对服务器进行修改。客户端和文件系统被迁移到的目的服务器均不需要进行特殊的配置。仅需要客户端有能力处理fs_location属性。2.6.18-rc5及以后的内核都是有能力处理的。不需要对客户端的用户态部分进行任何的修正。
2. 迁移（Migration）:
文件系统迁移是将一个文件系统从一个服务器移动到另外一个服务器。文件系统迁移典型的应用场景是一个可写并且拥有单一复制的文件系统。通过告知客户端每次修改后数据新的位置，而不修改客户端的任何配置，移动NFS导出的数据是很方便的。
简单地说：
客户端已经从服务器挂载了一个NFSv4的文件系统。服务器端的系统管理员有权决定将导出的文件系统迁移到其他的服务器。服务器必须通知所有挂载了文件系统的客户端数据（文件系统）被移动这个事实。
以下描述客户端与服务器就迁移事件进行交流的方法：
一 旦服务器端文件系统迁移完成，所有发送到原来服务器的后续请求将被返回NFS4ERR_MOVED错误。在接收到NFS4ERR_MOVED错误后，客户 端需要从原来服务器端获取fs_location属性。然后，客户端将使用fs_location属性中的信息将请求重定向到指定的服务器。
配置
在服务器端，使用refer选项来指定文件系统迁移后的位置。此外，还要在服务器端做类似以下的操作：
mount --bind /dummy_mount /export_nfs
（假定/export_nfs是nfs-root，但不是一个挂载点。）
客户端不需要做任何配置，该操作对于客户端来说是透明的。
迁移服务器必须被配置成单一服务器（单一的文件系统导出）。
示例
/etc/exports文件：
/home/charbona <world> (rw,async,wdelay,insecure,no_subtree_check,refer=/[email protected])
常规的操作顺序
- 客户端挂载sever1导出的文件系统，
- 将文件系统从server1迁移到server2，
- 客户端对已挂载文件系统的后续操作，将获得一个NFS4ERR_MOVED错误以及指明文件新位置的fs_location属性，
- 客户端从server2挂载迁移后的文件系统。
注意：NFSv4没有对数据迁移的方法进行定义。
引用与迁移
引用可以视为迁移的一个子情况。
如果服务器实现了文件系统迁移，在迁移事件没有被同步前，独立的客户端节点将遇到不同的情况（从单个客客户端角度来看）。
一些客户端可能已经从迁移后的文件系统中获取到新的文件句柄(filehandles)，但其他客户端还在访问旧的文件系统（当它依然存在）然后需要重定向。
然而，引用作为迁移的一个特殊子情况。当一个迁移事件发生时，一些客户端看到的将是一个普通的迁移事件，与此同时，其他客户端看到的将是一个文件系统引用。前者是在文件访问过程中发生的迁移事件，后者在迁移完成后才进行第一次文件系统访问。
3. 备份（Replication）：
对于备份，fs_location属性用于向客户端提供文件系统所备份的位置列表，客户端可以在问题（网络问题，NFS服务停止等）发生时访问这些备份。
文 件系统备份的目的是用于只读数据的情况。文件系统通常会被备份到两个或更多的服务器中。fs_location属性将向客户端提供这些备份位置的列表。当 第一次访问文件系统时，客户端就应当处理fs_location属性。如果后续的客户端请求超时，客户端可能尝试使用fs_location中指定的其他 服务器。
这种导出数据被备份在其他服务器的情况称为replicas。
注意：NFSv4没有对文件系统备份进行定义。
可以想象备份：
- 数据可以手动地进行备份（从一个服务器复制到另外一个服务器）。这种情况，数据应当是以只读形式导出的。
- 数据可以通过额外的工具自动地进行备份，备份更新以及所有备份的数据一致性保证等。
配置
客户端：不需要任何配置。2.6.18-rc5及以后的内核都有能力处理fs_location属性。
服务器：导出项必须为每个备份文件系统包含一条备份文件系统位置的选项，
replica=<dir>@<host>
备份：备份服务器是一个单一的NFS服务器，可以被标记为一个备份服务器或者单一的服务器。
示例
/etc/exports文件:
/export_nfs <world>(rw,[...], insecure,no_root_squash,replicas=/@replica1:/[email protected])
常规的操作顺序
- 客户端挂载一个文件系统，并且获取备份的位置，
- 服务器端不能继续为客户端提供服务，
- 客户端挂载一个备份文件系统。
4. 软件（待确认）
内核： linux 2.6.18-rc5 ~
NFS用户态软件： nfs-utils-1.0.10
英文pdf版本：http://nfsv4.bullopensource.org/doc/migration-and-replication-0.2.pdf
中文原文：http://www.cnblogs.com/kinglongmee/p/4703486.html
版权声明：本文为博主原创文章，任何转载必须包含以上两行链接地址。