我们面临着一个设计“挑战”，需要建立具有以下属性的存储解决方案：
我们需要的
- 哈
- 可扩展的存储后端
- 客户端上的离线/断开连接操作可解决网络中断问题
- 跨平台访问
- 客户端访问肯定来自 Windows（可能是 XP 以上版本），也可能是 Linux
- 后端与 AD/LDAP 集成（权限管理（用户/组管理，...））
- 应该可以在较慢的 WAN 链路上很好地工作
另一个问题是，我们实际上并不了解这里所有可能的用例，如果人们需要能够并发访问共享文件，或者他们只能访问自己的文件，那么可能的解决方案需要考虑并发访问以及从用户的角度来看，在这种情况下冲突管理将如何进行。
这两年前的博客文章总结了我在过去几天的研究中获得的印象，有很多当前超酷的项目正在实现（非 Windows）集群式 PB 级 Blob 存储解决方案，但没有一个能够很好地、本地地支持断开连接的操作，但我希望我们错过了一个明显的解决方案。
我们已经尝试过
开放AFS
我们认为我们需要一个带有本地缓存的分布式网络文件系统，并测试了 OpenAFS（作为目前唯一支持断开连接操作的“稳定” DFS，似乎是可行的方法）一周，但它存在几个问题：
- 它是真实的建立起来很痛苦
- 没有官方的 RHEL/CentOS 软件包
- elrepo 的当前稳定版本 1.6.5.1 的软件包在全新安装时会随机出现内核崩溃，这是绝对不行的
- Windows 支持（包括所需的 Kerberos 包）很神秘。1.6 分支的当前客户端无法在 Windows 8 上运行，1.7 的当前客户端可以运行，但它只是随机崩溃。在那次经历之后，我们甚至懒得在 XP 和 Windows 7 上进行测试。可以说，我们无法让它工作，整个设置非常不稳定且设置复杂，以至于它根本不适合生产。
桑巴舞 + 齐奏
由于 OpenAFS 完全是一场灾难，而且似乎没有其他 DFS 支持断开连接的操作，因此我们采用了一个更简单的想法，即使用 Unison 将文件同步到 Samba 服务器。这具有以下优点：
- Samba 与 AD 集成；这很麻烦，但可以做到。
- Samba 解决了从 Windows 远程访问存储的问题，但引入了另一个 SPOF，并没有解决实际的存储问题。我们可能可以将任何集群 FS 放在 Samba 之下，但这意味着我们需要在其上设置 HA Samba 来维护 HA，这可能会增加很多额外的复杂性。我依稀记得以前尝试用 Samba 实现冗余，但我无法在服务器之间默默地进行故障转移。
- 即使在线，您也在处理本地文件，这会导致比仅在断开连接时触及本地缓存时必要的冲突更多的冲突
- 它不是自动的。我们不能指望用户定期使用（功能齐全但不太漂亮的） GTK GUI 手动同步他们的文件。我尝试使用 Windows 任务调度程序半自动化该过程，但您无法以令人满意的方式做到这一点。
- 除此之外，Unison 的工作方式使与 Samba 同步成为一项昂贵的操作，因此我担心它不能很好地扩展，甚至根本无法扩展。
Samba + “脱机文件”
之后我们有点绝望，于是给 Windows“脱机文件”一个机会。我们认为，在操作系统中内置一些东西可以减少管理工作量，当它无法正常工作时，有助于责怪他人，而且既然人们已经使用了很多年，它就应该能正常工作。对吗？错。我们真的希望它能工作，但它就是不工作。30 分钟的复制文件和拔掉网线/禁用网络接口让我们
- （静默！Windows 资源管理器的状态栏中只有一个小通知，即使您单击它也不会打开同步中心！）服务器上无法删除的文件（！）和
- 根本不应该成为冲突的冲突。
最后，我们成功同步了一个小文本文件，其他一切都崩溃了。
除此之外，还有其他问题：
- 微软承认，Windows XP 中的“脱机文件”无法处理“大文件”，因此根本不缓存/同步它们，这意味着如果连接断开，这些文件将不可用
- 在 Windows 7 中，该功能仅在专业版/旗舰版/企业版中可用。
概括
除非有另一种支持 Windows 的容错 DFS，否则我认为在 GlusterFS/Lustre/whatnot 之类的东西上堆叠 HA Samba 集群是唯一的选择，但我希望我错了。其他公司如何在 Windows 异构环境中允许容错网络访问冗余存储？
答案1
正如我之前所评论的，DFS 不是满足您的要求的正确方法。
我认为以下解决方案堆栈最适合您：
分布式高可用性对象存储，如 Openstack SWIFT（https://wiki.openstack.org/wiki/Swift）。
对象存储之上的类似 Dropbox 的应用程序（例如http://www.gladinet.com/openstack-access-solution.html）。