我们有一个Windows Server 2008服务器，它需要非常高的正常运行时间。 我们希望在出于某种原因需要离线时进行故障转移，例如：硬件更新，软件更新等。
它主要运行FTP（以及其他一些不太关键的服务）。
它不需要是自动的。 它可以手动完成，但需要顺利进行，以免发生人为错误。
我们有一个额外的Windows服务器，我们正在考虑用作网关。 我们正在考虑提供NAT来将FTP端口转发到不同的服务器以进行故障转移。 鉴于我们的情况，这是最好的解决scheme吗？
PS：我知道FTP是非常棘手的：我们需要确保外部IP被设置在FTP软件中，我们处理被动端口，镜像文件等。
使用Windows服务器机器来提供NAT服务似乎是矫枉过正的，并创build一个维护需求（Windows更新），总是会导致与FTP站点的服务中断（因为您将不得不重新启动NAT“网关”计算机） 。 我想你最好使用支持第三层解决scheme（如NAT）或第七层解决scheme（如TCP或FTP代理）的embedded式设备。
也许你只是在上传FTP而不关心远程用户下载文件的能力。 在这种情况下，只要您有办法将故障转移过程中收到的任何文件合并到生产文件语料库中，就可以避免使用类似于您所谈论的内容。 （这可能只是一个XCOPY或者其他类似的东西，而不是一个大问题，但不知道你的后端系统很难说。）
如果您希望在故障转移期间从远程用户进行下载，那么比networking级别或应用程序协议级别访问更大的问题将是访问由FTP服务器托pipe的文件的连续性。 除非您有办法缓解后端文件存储的单点故障，否则您可以在networking或应用程序层完成任何您想要的任务，并且仍然在水中死去。
您可能能够使用像DFS复制这样简单的东西（甚至只是使用像ROBOCOPY或rsync这样的工具的复制脚本）来使生产和故障转移FTP服务器保持同步。 您的SLA窗口将决定您的复制一致性需要接近实时。