原文：https://www.samba.org/samba/docs/old/Samba3-HOWTO/SambaHA.html
译者：Younger Liu
特征和优点
网络管理员经常关心文件和打印服务的可用性，网络用户对于他们依赖的履行重要任务的服务是不能容忍的。
计算机机房的标志，提醒员工注意自己的职责：
所有的人类都失败了，不管是大的还是小的，我们都会失败。机器也失败了。计算机是由人类管理的机器，失败带来的后果是惊人的。你的责任是处理失败，预期它，尽所能的智慧去消除它。你的行为是问题的一部分还是解决方案的一部分？
(All humans fail, in bothgreat and small ways we fail continually. Machines fail too. Computers aremachines that are managed by humans, the fallout from failure can bespectacular. Your responsibility is to deal with failure, to anticipate it andto eliminate it as far as is humanly and economically wise to achieve. Are youractions part of the problem or part of the solution?)
如果我们要有计划地、有成效地处理失败，首先我们必须了解问题所在。这是本章的目的。
顺便说一句，在下面的讨论中（thereare seeds of information on how to provision a network infrastructure againstfailure.）。我们这里的目的不是提供关于高可用性主题的长篇论文。此外，我们决定不提供高可用性解决方案实例的细节；而是目前问题的一个概述，希望有人会提供一份详细的文档能够关注——高可用知识和实践在CIFS/Samba技术中应用得现状和挑战。
技术探讨
下面的总结是JeremyAllison在SambaXp 2003会议(德国Goettingen，2003年4月举行)论述得一部分。也增加了一般其他地方的材料，但都是Jeremy Allison整理的结构。
最终的目标
所有集群技术旨在实现以下一个或多个目标：
(1) 获得最大可负担的计算能力。
(2) 获得更快的程序执行。
(3) 传递不可阻挡的服务。
(4) 避免故障点。
(5) 资源的最有效利用。
理想情况下，集群文件服务器具有以下属性：
(1) 所有客户端都可以透明地连接到任何服务器。
(2) 一个服务器可以失败后客户透明地连接到另一台服务器。
(3) 所有服务器都提供相同的文件集。
(4) 所有文件更改都会立即出现在所有服务器上。
(5) 需要分布式文件系统。
(6) 通过添加更多服务器或磁盘来扩展规模的无限能力。
为什么这么难？
简言之，问题在于“状态”：
(1) 所有TCP/IP连接都依赖于状态信息
TCP连接涉及包序列号。这个序列号需要在集群中的所有机器上动态更新，以实现无缝TCP故障转移。
(2) CIFS / SMB使用TCP连接
这意味着从基本设计角度看，故障转移是没有得到审慎考虑得：所有当前的SMB集群都是依赖于客户机重新连接的故障转移解决方案。它们提供服务器故障转移，但由于服务器故障，客户机可能丢失信息。
(3) 服务器保存关于客户端连接的状态信息。
CIFS / SMB涉及很多状态。
必须将每个文件打开与其他打开进行比较，以检查共享模式。
前端挑战
为了能够将文件服务器集群当作一个服务器（一个名称一个IP地址），客户端的传入TCP数据流必须由前端虚拟服务器处理。此服务器必须在SMB协议层级别对传入的数据包进行多路复用，然后将SMB包传输到集群中的不同服务器。
可以将所有IPC连接和RPC调用拆分到一台服务器来处理打印和用户查找请求。RPC打印处理在两个不同的IPC4会话之间共享，很难共享给整个服务器集群。
从概念上讲，所有其他服务器都只提供文件服务。这是一个更简单的问题。
Demultiplexing SMB请求
对SMB请求的Demultiplex需要了解SMB状态信息，所有这些信息都必须由前端虚拟服务器保存。这是一个复杂而又难以解决的问题。
后来，Windows XP改变了语义状态信息，使得成功得必须为一个（vuid，tid，FID）组合。这使事情比以前简单，是向前迈出的积极的一步。
SMB requests are sent by vuid to their associated server. No codeexists today to effect this solution. This problem is conceptually similar tothe problem of correctly handling requests from multiple requests from Windows2000 Terminal Server in Samba.
一种可能是直接将服务器池暴露给客户机。这可以消除去复用步骤。
分布式文件系统挑战
在UNIX和Linux中存在许多分布式文件系统。常见的开源分布式文件系统包括：
NFS
AFS
Openfs
Lustre
Glusterfs
Ceph
后端文件系统也可以使用任何分布式文件系统。但是需要考虑共享模式、加解锁、oplock等问题。
分布式文件系统的限制性约束
若集群单纯地提供Samba服务，oplock处理可以在服务器中处理而不需要传递给后端文件系统。
另一方面，在服务器集群提供了NFS或其他文件的服务，对Samba服务来说oplock-aware是必不可少的。这是一个重大的挑战。如果未能提供这种互操作性，将对Windows用户造成显著得性能损失。
最后，所有状态信息必须在服务器集群中共享。
集群通信
大多数后端文件系统支持POSIX文件语义。POSIX锁与samba锁得语义具有不同的性质。这使得将SMB语义推广到文件系统中变得困难。
集群中各节点得smbd进程必须快速通信。相对于此，当前Samba使用TDB文件结构不适合在网络中使用。集群smbd必须用别的。
Server Pool通信需求
在Server Pool中服务器间得高速通信是一个完整系统设计的前提。包括：
(1) 专有的共享内存总线，（例如：Myrinet或SCI）。这些都是高成本项目。
(2) 千兆位以太网（现在相当便宜）。
(3) 原始以太网帧（绕过TCP和UDP开销）。
我们还没有确定性能需求的度量标准，以便有效地实现这一目标。
对Samba的必要修改
如果要求Samba在对高速服务器互连系统中有效工作，需要对其进行显式修改，以允许透明的故障转移。
Samba的某些功能将受到影响，包括：
(1) 数据库锁定，oplock通知和共享模式的数据库。
(2) 需要定义故障语义。Samba的行为与Windows相同。当oplock消息失败，打开一个文件的请求是允许的，但在群集环境中存在潜在的危险。那么如何在服务器之间定义失败语义，如何实现？
(3) 是使用点到点锁管理器？还是使用多播技术来实现吗？
一个简单的解决方案
在导出得文件系统内部允许服务器故障转移以不同功能，可以消除需要分布式锁定协议的问题。
如果Server pool中只有一个Server是Active的，那么服务器间得高速互联要求是可以避免的。从而可以使用现有的高可用性解决方案，而不是发明一种新的高可用性解决方案。这个简单的解决方案代价是需要管理更复杂的文件命名空间。由于不是单一的文件系统，管理员必须记住所有服务的复杂性所在，是不容易处理得。
仍然需要虚拟服务器将请求重定向到后端服务器。后端文件空间完整性是管理员的职责。
高可用性服务器产品
故障转移服务器必须进行通信，以处理资源故障转移。这对于高可用性服务至关重要。将专用心跳引入故障转移中是一种常用技术。通常是通过专用链接（局域网或串行）完成的。
许多故障转移解决方案（如红帽集群管理器和微软狼群）可以使用光纤通道磁盘存储阵列的容错通信共享SCSI。参考redat。
Linux高可用性项目是一种值得参考的资源，如果您希望构建一个高度可用的Samba文件服务器解决方案的话。请参考www.linux-ha.org
前端服务器的复杂性对高可用性仍然是一个挑战，因为它必须优雅地处理后端故障，同时为所有网络客户提供服务的连续性。
MS-DFS：穷人的集群
MS-DFS可用于将客户端重定向到不同的后端服务器。这将复杂性推回到网络客户机上，这已经被微软收录了。MS-DFS创建一个简单的幻觉，连续文件系统命名空间，甚至在文件级。
最重要的是，以管理的复杂性为代价，可以使用现有的Samba功能创建分布式系统（伪集群）。
结论
透明的SMB集群很难做到！
客户端故障转移是我们今天能做的最好的事情。
在实际可行的高可用性透明集群解决方案之前，还需要做更多的工作。
MS-DFS可以用来创建一个透明的集群的错觉。
本作品采用 知识共享署名-非商业性使用-相同方式共享 3.0 未本地化版本许可协议 进行许可。