我们有一台 Windows Server 2008 服务器，需要非常高的正常运行时间。我们希望在因某种原因（例如硬件更新、软件更新等）需要将其脱机时进行故障转移。
它主要运行 FTP（以及一些其他不太重要的服务）。
它不需要自动化。它可以手动完成，但它需要平稳进行，以免发生人为错误。
我们有一台额外的 Windows Server，我们正考虑将其用作网关。我们正在考虑提供 NAT，以便将 FTP 端口转发到另一台服务器进行故障转移。考虑到我们的情况，这是最好的解决方案吗？
PS：我知道 FTP 很棘手 - 例如：我们需要确保在 FTP 软件中设置了外部 IP，我们处理被动端口、镜像文件等。
答案1
使用 Windows Server 计算机提供 NAT 服务似乎有点过度，并且会产生维护需求（Windows 更新），这必然会导致 FTP 站点的服务中断（因为您必须定期重新启动 NAT“网关”计算机）。我认为您最好使用支持第 3 层解决方案（如 NAT）或第 7 层解决方案（如 TCP 或 FTP 代理）的嵌入式设备。
也许您只是进行 FTP 上传，并不关心远程用户是否能够下载文件。在这种情况下，只要您有办法将故障转移期间收到的任何文件合并回生产文件库，您就可以摆脱您正在谈论的事情。（这可能只是一个 XCOPY 或类似的东西，没什么大不了的，但如果不了解您的后端系统，就很难说。）
如果您希望在故障转移期间从远程用户那里下载文件，那么比网络级或应用程序协议级访问更大的问题将是 FTP 服务器托管文件的连续访问。除非您有办法缓解后端文件存储的单点故障，否则您可以在网络或应用程序层做任何您想做的事情，但仍然会陷入困境。
您可以使用 DFS 复制等简单方法（或者甚至只是使用 ROBOCOPY 或 rsync 等工具的复制脚本）来保持生产和故障转移 FTP 服务器同步。您的 SLA 窗口将决定您的复制一致性需要接近实时的程度。