更换分布式文件系统副本组成员的硬件或操作系统

第一步：计划

大家好，Ned在这里又要开始一个新的关于分布式文件系统副本的系列介绍，该系统包含5个部分。随着Windows Server 2008 R2的发行，经济的复苏以及硬件淘汰的时间和速度，我们已经开始意识到很多在已存在的分布式文件系统副本组中更换服务器的问题。

通过这个系列，我将围绕在一个已存在的分布式文件系统副本中更换某些或全部服务器来介绍各种不同的选择和技术。根据配置和预算的不同，这项更换操作可以是让用户毫无察觉的一项几乎不留痕迹的操作，也可以是事先计划本地服务器停机一段时间的一项操作。但是最终还是由个人根据经费决定使用什么方式。

这个系列也对已有的准备操作提出了改进意见，以避免冲突并使初始化同步的性能最大化。同时，我也会介绍在对集群和只读副本更换过程中将用到的一些新选择。

最后，人们在处理杂乱的分散于不同地域的数以GB的用户数据时会显得很紧张。在这一系列里我会尽最大可能避免出现古怪的Ned主义理论，同时我也将其推广至TechNet范畴内。我只希望这些不要太令人嫌烦。

背景：

客户们最常使用的分布式文件系统副本配置结构是传统的中心节点和辐射状的数据存取子节点。这就意味着：

l  多个分支文件服务器用来存储用户数据，而且出于备份目的，这些服务器对一台独立的主业务节点提供数据的复制恢复；

l  某些数据可能会悄悄地从存储在中心节点变为存储在分支节点，例如，应用程序安装包或人力资源文书；

l  分支节点服务器上的存储是本地固定磁盘；

l  中心节点服务器上的存储是SAN存储；

l  绝大多数（如果不是全部）服务器均运行于Windows Server 2003 R2 SP2操作系统之上。

在现实中，我们可能会发现有多种不同的可能性，比如说有更多的SAN存储网络，或者没有任何SAN存储网络，或者有50台服务器，再或者有5台中心节点服务器。当我们通过下面这些简单的例子理解了基础知识后，我们会发现这些可能性实际上根本不会影响我们的操作。我们只需要从微观方面关注它是怎么运行的，然后从宏观方面确保我们的业务没故障。

在下面的示意图中，我们先假设具备了如下的条件：

• 所有的分布式文件系统服务器均运行在Windows Server 2003 R2 SP2操作系统之上；
• 中心节点服务器使用光纤直连的SAN存储，分支节点服务器使用本地磁盘；
• 整个分布式文件系统的拓扑结构是中心节点与辐射式分支节点。在各自独立的复制组内，分支01、分支02与分布式文件系统中心节点之间互相复制；
• 所有更换后的操作系统均为Windows Server 2008 R2（这样才有可能可以使用集群和只读功能）；
• 域控制器都运行在Windows Server 2008 R2操作系统之上（这样才有可能可以使用只读功能）；
• 更换的中心节点服务器是一组集群，用于提供高可用性。

选项：

我们对服务器进行新硬件的更换和操作系统的更换有很多方式。我按照对分布式文件系统复制的影响由最小至最大进行了排序。显而易见的，对分布式文件系统复制的影响大小与为此需要的支出和获得的效果成反比关系。在下面的文章里，我将深入介绍这些方法的优缺点。

注意：示意图只适用于方便理解，而不是该步操作的完整设置。不要将这些示意图作为我们实现更换的唯一地计划和方法，一定要坚持阅读该系列的其他文章。

我们可能需要根据时间、预算和人力的情况完成一个综合性的考虑，并做出选择。

“N+1”模式（适用于硬件、操作系统）

“N+1”模式需要添加一台新的替换服务器，并使这台替换服务器与被替换的服务器建立起一对一的协作关系。这样做，可以配置两个节点间的复制和同步，无须最终用户干预，因为如果需要最终用户干预操作，那同步复制操作将被中断很长一段时间。这样做同样允许更换更新版本的硬件和操作系统。预先的准备操作也是有可能的。当这些服务器之间完成了同步，老的服务器可以从复制队列里移除，而新的服务器可以被重新命名。我们需要确保两台中心节点有足够的存储空间，如果我们现在拥有的容量必较少，那么使用该模式会比较需要花费经费来补充存储空间。

图1  拥有老的中心节点和分支节点的已存在的环境

图2  用新的中心节点集群与老的中心节点进行复制

图3  老的中心节点服务器移除，新的中心节点连接存储

图4  新的分支节点服务器与老的分支节点服务器复制

图5   新的分支节点服务器与新的中心节点服务器复制

图6   老的服务器移除

数据磁盘交换模式（适用于硬件、操作系统）

数据磁盘交换模式不需要原有老中心节点服务器存储容量2倍的存储空间，而且可以从老的服务器到新的服务器移动替换一块已存在的磁盘（正常是一个LUN）。这也意味着我们不需要重新预定义。这一模式的缺点在于与中心节点的复制在磁盘移动过程中会中断。而后，在中心节点和它的协作节点间会出现未经认证的同步，这样的话，在这一时间段内分支节点服务器就处于数据不稳定的风险之中。

图1  拥有老的中心节点和分支节点的已存在的环境

图2  新的中心节点集群建立

图3  老的中心节点服务器移除，新的中心节点连接存储

图4  新的分支节点服务器与老的分支节点服务器复制

图5  新的分支节点服务器与新的中心节点服务器复制

图6   老的服务器移除

重装模式（仅适用于操作系统）

重装模式可以用于需要将操作系统降级的情况下。原先的文件都被事先定义为在该模式下不会被触及到的数据，同时复制也会停止，直到安装全部完成后复制选项重新配置完毕后才会重新开始复制同步。这种模式就会潜在的存在一个停机时间问题。对于该种模式，以前安装的操作系统的版本与复制及数据本身没什么联系。

图1  拥有老的中心节点和分支节点的已存在的环境

图2  操作系统重装，DFSR重建后的环境

升级模式（仅适用于操作系统）

最后，升级模式适用于使用安装来升级原有操作系统的版本。只要我们的服务器符合本地升级的需求，我们就选择这个升级模式选项。这一模式不会导致复制操作重新同步，但是在升级操作系统本身这一过程中还是会需要停机一段时间。同样的，如果老机器运行的是32位的操作系统，那它也不支持部署Win2008 R2的操作系统。当然与任何升级一样，这种升级模式也存在出现升级不能圆满完成或在一个不一致的状态完成的风险。如果出现这些情况，那将导致我们要花更长的时间和过程去排查错误或者阻碍我们的升级操作。由于这一原因，升级模式是最不推荐使用的一种模式。

图1  拥有老的中心节点和分支节点的已存在的环境

图2  操作系统已升级完成的环境