您如何正确地为文件服务器进行灾难恢复？

Question

我们目前正在为 Windows 文件服务器实施 DR 策略。我们已经排除了存储复制，因为它是一项预览功能，而故障转移群集旨在实现高可用性，而不是灾难恢复。DFSR 在复制打开/锁定的文件方面也存在缺陷，使其不适合该任务。

文件服务器虚拟机的 SAN 到 SAN 复制对我来说似乎是最好的方法，尽管我被警告不要这样做，因为复制是未在更高级别合并的原始副本，可能会导致不一致文件系统或损坏的文件。然而，这个事实适用于以这种方法复制的任何服务器，而且我们的 DR 计划中的其他服务器也使用这种方法。VSS/以前的版本也可以始终用于恢复任何损坏的文件。

进行 SAN 复制的好处是否大于文件损坏的风险？或者有没有更好的方法为文件服务器做 DR？也许有一种产品可以执行更高级别的复制/快照，以最大限度地减少数据中的逻辑不一致？

注意：集群运行的是 vSphere 5.5

Answer 1

SAN 到 SAN 复制是在宣布灾难后尽可能快地使文件服务器恢复联机的最佳选择，并且损失尽可能小。请注意，这种类型的 DR 保护与本地备份不同，您不能使用复制的 SAN 卷来恢复上个月的文件。

损坏的文件不是 SAN 到 SAN 复制的危险，除非是主站点上的文件服务器损坏了它们。每个提供基于块的存储 (LUN) 复制的 SAN 都有一些机制来防止损坏和保证一致性。这是一个比大多数人知道的更棘手的问题，因为出于优化原因，即使没有复制，写入也经常无序地应用于磁盘。这就是为什么大多数存储的写入缓存都有某种电源故障安全网（如电池或 UPS）：如果写入仅保存在缓存中，则底层磁盘可能已损坏。通常这是可以的，但是如果断电，则需要确保将存储确认的最后一次写入保存到磁盘，以使磁盘在出现时保持一致。

复制对此的处理方式不同，具体取决于您复制的方式：

• 同步复制保证了一致性，因为它不会向本地服务器返回写入确认，直到它确认写入已安全到达辅助站点。这大大减慢了写入速度，并且没有供应商支持在距离相对较短的恒星连接以外的任何情况下执行此操作。事实上，支持的距离通常很低，您很容易受到同样的飓风的影响。很少看到，通常不是唯一的地方。
• 异步检查点复制是迄今为止最常见的算法，被绝大多数开放系统存储使用。该框将定期复制一致的检查点，这意味着它将确保在远程系统上找到的可恢复副本没有丢失的写入。如果它在检查点中间被中断，它会丢弃它并转到最后一个已知的一致点。我见过一些系统，只要您的 WAN 支持它，就可以使用这种方法让您拥有 15 秒的恢复点。
• 异步有序交付复制比检查点更罕见且更难做到，但在我看来，它是同类异步算法中最好的。它所做的是按照完成的顺序通过 WAN 发送写入。问题在于，与检查点复制不同，如果这落后，则用于保存未发送写入的存储无法在不需要完全重新同步（重新发送所有数据）的情况下刷新。通常，如果链接跟不上写入的速度，它会回退到检查点模式，并在获得足够新的检查点后再次开始按顺序交付。EMC 的recoverpoint 和Hitachi 的HUR 都这样做，但是我没有看到任何其他供应商以这种方式设置。

所有这些机制都为您提供“崩溃一致性”。磁盘处于与突然关闭服务器电源时相同的状态。从崩溃一致的副本中运行文件系统和数据库需要一些工作，但它总是可行的。如果您想要更多（您在问题中提到的“更高级别”），您需要将您的复制与您的应用程序集成。这通常意味着暂停对应用程序的写入，等待所有内容都已降级到存储，然后启动复制的一致性点。这称为“应用程序一致性”。它通常会提供稍旧的恢复点，但恢复时间略低于崩溃一致性。