SAN同步复制和Server 0的RPO可能吗？

Question

我正在开发一种解决方案，即使用Server 2012 SP2，但不使用AlwaysOn可用性组。这是由于跨数据库事务，这不适用于此方案。

注意:我们正在讨论这个问题，但作为我的问题的背景资料。

我们使用HP 3 3PAR解决方案通过SAN获得站点到站点的同步复制。这使得DR方案可以跨站点工作，因此我们可以将故障转移到次要位置。

我担心的是0的RPO，因为在某些情况下，数据可能丢失，并且会发生损坏。例如，站点之间的链接被切断，然后主链接就会下降。

我的问题如下：

1. SAN是否拒绝将数据写入I/O，直到同步完成？

或

1. 如果一个链接被切断，SAN缓冲区是否会改变这个块，直到连接被恢复？
2. 如果一个链接在TL日志写入过程中被切断，并且发生DR，这不意味着我们将有一个潜在的损坏TL写入次要站点，从而导致数据丢失吗？数据丢失仅仅是因为主节点能够提交，而次要数据不能同步。
3. RPO为零是跨堆栈( Server /内存/ Network / SAN / IO)的保证吗？

来自HP 3 3PAR白皮书：要求容灾环境的复制解决方案，第6页：

对于同步复制解决方案，解决方案的RPO始终为零。然而，对于异步复制解决方案，RPO总是大于零。异步周期模式是异步复制。因此，在设计使用异步周期复制的解决方案时，RPO成为一个关注的问题。

SAN保证0容忍度的RPO，那么当网络死亡时SAN不允许改变渗透到I/O中吗？

更新：

我在上面参考的第12页找到了这个信息：

远程复制同步长距离拓扑是目前支持的唯一允许将远程复制卷组中的卷从一个源StoreServ数组复制到两个不同目标StoreServ数组的拓扑。它通过在两个StoreServ数组(“源”和“同步目标”数组)之间同步复制数据，同时通过周期性异步模式将相同的数据复制到第三个StoreServ数组、灾难恢复或“异步目标”数组。用户可以选择以主动激活的方式处理这两个同步数组，如果/当数据中心的故障指示故障转移是必要的，并且恢复对“同步目标”数组的操作时，它们之间的切换就会失败。这提供了一个故障转移解决方案，由于同步数组之间复制的同步性质，它提供了一个RPO等于零的RPO。在故障转移到同步目标数组时，该数组与异步目标数组之间的被动异步周期链接将变为活动，任何复制到同步目标但尚未复制到异步目标数组的数据都将从同步目标数组发送到异步目标数组，使异步目标数组与同步目标发生的最后一次写入同步目标数组同步更新。然后，在同步目标数据中心中继续操作，并继续将数据复制到异步目标数组。

根据这些信息，您确实需要第三个端点来参与异步复制，以便当网络链接中断时，可以通知辅助站点更改的情况。

Answer 1

我不能对3PAR做出具体评论，但我对EMC Symmetrix数组有很多经验。

我的建议是:另辟蹊径。同步复制是这些技术中的一种，在纸面上和最佳情况下看起来都很棒，但在现实世界中却造成了巨大的痛苦。

它的工作方式是：

• 传入写入进入数组上的缓存。
• 写通过同步链接复制到远程站点。
• 写被指定为远程数组上的缓存。
• 确认被发送回主。
• 写IO成功是公认的主机。

它是'RPO 0‘，也就是说，如果它在磁盘上，它就在远程站点上。大多数应用程序都使用内存缓存，而内存缓存将在DR. .中丢失，但它需要付出很大的代价：

• 您需要足够的总带宽到您的远程站点，您将始终拥有足够的带宽来满足复制需求--如果不这样做，您的主要系统将遭受严重的损失，因为磁盘延迟将急剧上升。如果您曾经饱和此链接，您将遭受损失，您的主要服务可能只是崩溃。
• 您将始终有一个延迟负担，您的性能将因此受到影响。

现在，也许这两件事都是“好的”。然而，在我的经验中，RPO0和“同步复制”通常只有在您有了非常重要的事情时才会讨论。

不过，要直接回答你的问题：

Does the SAN deny data writes to the I/O until synchronisation has completed?

不-在进入同步模式之前，它将在异步中“追赶”。这可能需要一段时间，这取决于带宽，直到它是同步，您没有您的'0 RPO‘。

If a link is severed, does the SAN buffer the block changes until the connection is restored?

有点取决于你的配置。通常，它将链接挂起/恢复视为需要异步重新同步的事件。当链接“退出”时，您的RPO不再为零。您可以在链接失败时“阻止”IO，但这可能会使您的应用程序崩溃。

If a link is severed during a TL log write, and a DR occurs, doesn't this mean that we will have a potentially corrupt TL written to the secondary site, and therefore incur data loss? The data loss is only because the primary was able to commit, but the secondary was not able to synchronise.

不同步意味着同步。如果您是同步的，磁盘上的任何IO也在遥控器上。但是，磁盘上没有的任何IO都会丢失，因此您可能会丢失最后一个事务日志。

Is RPO of zero ever a guarantee across the stack (SQL Server / Memory / Network / SAN / IO)?

RPO是恢复点目标。如果你的目标是零那么..。你需要好好考虑一下你的架构。这是可以实现的，但却非常昂贵。

就我个人而言，我建议不要同步：

运行您的主数据存储异步，并依赖您的日志提供‘同步’位。你的“RPO0”--实际上说--无论如何，它只会是“你忠实的过载日志”。那么NFS (CIFS?)安装一个远程驱动器，并将您的传输记录写入网络以及“本地”存储，并在离同步数据库仅几分钟的时间内将它们重放到数据库上。

无论如何，您将得到大约相同的恢复点--因为我非常怀疑您是否希望使用没有日志记录的数据--这样做并不需要昂贵的同步操作。