了解 DFSR 中(缺少)的分布式文件锁定

本文介绍了在 Windows 内缺少多主机分布式文件锁定机制,尤其是在 DFSR 复制的文件夹内。

某些背景

  • 分布式文件锁定 – 是指在多台计算机上具有多个文件副本的概念,并且当打开一个文件进行写入时,将锁定所有其他副本。 这可防止多个用户同时在多个服务器上修改文件。
  • 分布式文件系统复制 ––在基于状态的多主机设计中运行。 在基于状态的复制中,多主系统中的每个服务器会在其到达时将更新应用到其副本,而无需交换日志文件 (使用版本向量来维护 “ 最新 ” 信息) 。 初始同步后,任何一台服务器永远都不会获得权威,因此它在各种网络拓扑上都是高度可用且非常灵活的。
  • 服务器消息块- SMB是 Windows 用于通过网络访问文件的通用协议。 简而言之,它是一种客户端-服务器协议,使用重定向程序使远程文件系统看起来是本地文件系统。 这并不特定于 Windows,而且非常常见 – 的是众所周知的非 Microsoft 示例,这使得 Linux、Mac 和其他操作系统可以充当 SMB 客户端/服务器并参与 Windows 网络。

很重要的一点是,在复制的数据环境中,请务必清楚地略图 DFSR 和 SMB。 SMB 允许用户访问其文件,并且它不知道 DFSR。 同样,DFSR (使用 RPC 协议) 会使文件在服务器之间保持同步,并且不会意识到 SMB。 不要将此 post 和 机会锁定中定义的分布式锁定混为一谈。

就像 Brits 所说的那样,这里有一些东西。

由于用户可以在多个服务器上修改数据,并且每个 Windows 服务器只知道自己的文件锁定,而且由于DFSR 不知道其他服务器上有关这些锁的任何内容,因此用户可能会覆盖彼此的更改。 DFSR 使用 “ 最后一次编写器入选 ” 冲突算法,因此有人必须丢失,最后保存的人员才能保留其更改。 丢失文件复制 chucked 到 ConflictAndDeleted 文件夹。

现在,这种情况并不太常见。 通常,在本地环境中修改真实的共享文件;在分支机构或隔间的同一行中。 它们通常由同一团队的人员进行处理,因此人们通常会了解修改数据的同事。 而且,由于它们通常在同一站点中,因此,使用共享文档的所有用户都将使用相同的服务器。 Windows SMB 处理此情况。 如果用户已锁定要修改的文件,并且他的同事尝试编辑该文件,则其他用户将收到如下错误:

Screenshot of the File In Use dialog box showing an error message that says This action can't be completed because the file is open in another program.

而且,如果打开文件的应用程序真的很聪明(如 Word 2007),则可能会给出:

Screenshot of the File In Use dialog box showing three actions you can take when a file is locked by another user.

DFSR 确实有一个用于锁定文件的机制,但它仅在服务器自己的上下文中。 如果本地副本的本地副本具有排他锁,DFSR 将不会复制该文件。 但这并不会阻止其他服务器上的任何人修改该文件。

再次了解, 在地理上 修改的共享数据存在的问题是,对于某些人来说,这是相当 gnarly 的。 我们偶尔会问到,DFSR 不处理此锁定,并使用一只一波神奇的东西。 事实证明,对于多主机复制系统来说,这是一种有趣且难以解决的问题。 接下来,将探索双精度类型。

第三方解决方案

有一些供应商解决方案需要此问题,他们通常会通过以下一种或多种方法来处理此问题:

  • 使用 broker 机制

如果有一个中心 ‘ 流量 cop,则一个服务器可以识别所有其他服务器以及用户已锁定的文件。 遗憾的是,这也意味着分布式锁定系统中通常会出现单点故障。

Diagram showing the use of a broker mechanism.

  • 完全路由网络的要求

由于中央代理必须能够与参与文件复制的所有服务器进行通信,因此这会消除处理复杂网络拓扑的功能。 通常不可能出现环拓扑和多个中心辐射型拓扑。 在非完全路由的网络中,某些服务器可能无法直接与其他服务器或代理进行联系,并且只能与他可以与另一台服务器通信的合作伙伴通信, – 等等。 这在多主机环境中是正常的,但不能使用协调机制。

Diagram showing the requirement for a fully routed network.

  • 仅限于一对服务器

某些解决方案将拓扑限制到一对服务器,以便简化其分布式锁定机制。 对于较大的环境,这可能不可行。

  • 使用客户端和服务器上的代理
  • 不使用多主机复制
  • 不要使用 MS 群集
  • 使用专业设备

* 请注意,我通常会说! 请不要发布死亡威胁,因为你的解决方案可以/不实现其中一种或多种方法!

更深入的想法

当你进一步考虑此问题时,会开始剪裁一些基本问题。 例如,如果有四个服务器,其中包含四个站点中的用户可以修改的数据,并且与其中一个用户的 WAN 连接处于脱机状态,我们该做什么? 用户仍可以访问其各自的服务器, – 但是否应该允许他们? 我们不希望这些更改发生冲突,但我们确实希望他们能够继续工作,并做出公司的资金。 如果在这种情况下,我们会随机阻止更改,即使可能没有发生任何冲突,用户也不能工作! 无法告诉其他服务器该文件正在使用中,而您又是第一方。

Diagram showing the results of a partial network outage.

然后是 SMB 本身和报告锁的错误处理。 我们无法真正改变 SMB 报告共享冲突的方式,因为我们会破坏大量的应用程序,客户端仍然无法理解新扩展的错误消息。 Word 2007 之类的应用程序执行一些 undercover trickery 来确定谁正在锁定文件,但大多数应用程序不知道哪个用户使用了文件 (甚至是该 SMB 存在。 确实如此 ) 。 因此,当用户收到 ‘ 该文件正在使用中的消息时, – 他们是否都应该调用支持人员,这并不是特别可行的呢? 支持人员是否有权访问所有文件服务器以查看哪些用户正在访问文件? 有些.

由于我们希望使用多主机来实现高可用性,因此不太适合使用 broker 系统;我们可能需要在所有服务器上运行一些内容,以便所有服务器甚至可以通过非完全路由的网络进行通信。 这将需要非常复杂的同步技术。 它会在网络 (上增加一些开销,但这可能不太太) ,需要尽快确保我们不会让用户处于工作状态;它需要 outrun 文件复制本身,实际上,它可能需要通过某种方式与复制相关联。 它还必须考虑与网络相关的服务器中断,而不是由某种程度的服务器故障引起的。

Diagram showing Locking and Replication across five servers.

接下来,我们回到此方案中的特殊客户端软件,以便更好地理解锁定,并可以为用户提供一些有用的信息 “ , (在 Susie 中调用,并告诉她发布该文档 ” , “ 很抱歉,文件锁定拓扑已断开,管理员阻止你打开此文件,因为它已修复 ” , 依此类推) 。 这种情况下,在 Windows 中运行的应用程序可以很好地发挥作用。 有大量的操作系统不受支持,或者获取软件 – Windows 2000 不受主流支持。 Linux 和 Mac 客户端在感觉非常重要之前,不会使用此软件,因此,客户必须希望其供应商做出类似的操作。

更多更多信息

现在,在 DFSR 中控制这种情况的最简单方法是使用 DFS 命名空间指导用户使用一致的命名空间的可预测位置。 通过正确配置你的 DFSN 站点拓扑和服务器链接,你可以强制用户共享同一本地服务器,并且仅允许他们在其主服务器关闭时访问远程计算机 ‘ 。 对于大多数环境,这种方式非常有效。 作为 DFSR 的替代方法,SharePoint 是一个选项,因为它是其签出/签入系统。 BranchCache (传入 Windows Server 2008 R2 和 Windows 7) 可能是为你提供的一个选项,因为它旨在缓动在分支方案中读取文件,但最终权威数据在一台服务器上仍将仅在一个服务器上运行 – 。 – 同样,这些供应商也有其自己的解决方案。