可以在存储堆栈的多个层上配置远程数据复制。下面是一些示例，以解释我所说的层的含义：
- 物理卷层（TruCopy、SRDF/MirrorView、SnapMirror）
- 虚拟服务器层（vReplicator、Veeam）
- 逻辑卷层（VVR、AVS）
- 文件系统层（Rsync、ZFS 发送/接收）
- 应用层（Data Guard、MySQL/PostgreSQL 复制、AD 复制）
每一层的复制都有独特的价值主张，但全部使用它们会很疯狂。我面临的特殊问题是不同解决方案的泛滥；我希望将一两种解决方案标准化，以降低许可成本、复杂性和专业知识要求。
我的问题是：忽略单个产品示例，在典型的企业环境中，哪一层或哪几层复制组合能提供最大价值，哪些变得更有价值？
可能的指标包括管理的简易性、专业知识的可用性、对数据损坏的保护、灾难恢复场景中的恢复时间/复杂性、计划停机时间窗口的减少、应用程序性能、应用程序灵活性以及任何其他可能有价值的东西。
这是我作为系统管理员经常遇到的一个问题，因此我很感激任何建议。
答案1
哪种解决方案更适合特定场景，很大程度上取决于所涉及的应用程序和数据，不存在可以随时随地起作用的“全局”方法。
确实涉及太多不同的场景。以下是一些示例：
- Active Directory 域控制器是设计作为一个多主、复制、分布式数据库工作；并且你还可以需要在 WAN 设置中拥有本地 DC，因为加入域的 Windows 计算机需要有可用的 DC 才能正常工作。同时，使用 AD 不会带来好处根本在虚拟服务器层或物理存储层进行低级复制，因为您无法让 DC “装载” 从另一个 DC 复制的数据库，并且您无法启动克隆的 DC 并期望它正常工作（甚至不要尝试这样做，USN 回滚是可恶的）。
- 对于文件服务器来说，情况恰恰相反：是应用程序级复制技术（Windows 中的 DFS），对于大量数据，存储级复制可能是最好的方法。
- 现在，假设你正在使用 Exchange；最近的 Exchange 系统（2007-2010）在设计时就考虑到了事务数据库复制，而且这是唯一官方支持的方法；你实际上能复制 Exchange 数据库并将其挂载到另一台 Exchange 服务器上（这称为“数据库可移植性”），因此存储级复制可以可以正常工作……但这要痛苦得多，将用户转移到这样的服务器需要大量重新配置。此外，虽然在上述两种情况下实际上是在多个地方拥有数据的本地副本（到处都需要 AD，不同办公室的用户可能需要访问相同的文件服务器数据），对于 Exchange，这仅在灾难恢复场景中才有意义，因为在正常运行中每个用户只能访问他/她自己的邮箱，该邮箱一次只能在单个服务器上处于活动状态。
- 对于各种数据库系统，这可以在应用程序级别或任何底层工作；但这在很大程度上取决于应用程序：如果您需要在多个地方修改数据（而不是仅读取它们），则存储复制无法合并冲突的副本，并且您需要让您的 DBMS 来处理这个问题。
每种技术都有其自身的优势和用途；实际上并不存在“一刀切”的方法。
答案2
到目前为止，我考虑过两种选择。两者的总体思路都是将复制的责任仅分配给一个团队：系统管理员或应用程序管理员。只有一个团队参与，可以降低系统的复杂性和风险。
虚拟服务器层复制标准化
通过仅在虚拟服务器层配置复制，您可以将操作系统及其中运行的任何应用程序视为黑匣子。系统管理员可以控制一切。
优点：
- 所有应用程序的 DR 过程都是相同的：停止复制，启动 DR 虚拟服务器，并要求不同的应用程序团队确认一切正常。
- 很容易确认您已完整覆盖所有数据。
- 由于应用程序团队的参与很少，因此很容易规划服务器/存储维护。
缺点：
- DR 服务器大部分时间处于空闲状态：可能会浪费服务器资源。
- 如果 IP 地址与 Prod 匹配，则在没有完整故障转移的情况下测试 DR 可能会很困难。
- 复制是即时的，因此如果 Prod 中的数据损坏，它会立即传播到 DR。
- 使用此方法克隆到 Dev/Test 可能会比较困难。
- 无法与在虚拟机中运行不佳的系统一起使用。
可以与物理卷层技术结合使用，以增强复制性能（同时仍由 VM 软件进行管理）。
应用层复制标准化
通过仅在应用程序层配置复制，您可以将服务器、存储和操作系统视为黑匣子。应用程序管理员可以控制一切。
优点：
- 许多应用程序可以以多主或主从模式运行，以利用所有服务器资源。
- 许多应用程序可以以简洁的格式传输变化，从而节省带宽并提高性能。
- 某些应用程序可以延迟更改的应用，以防止损坏在 DR 处立即传播。
- 切断复制并将服务器重新配置为开发/测试相对容易。
缺点：
- 每个应用程序团队必须以自己独特的方式配置复制。
- 并非所有应用程序都支持这种复制，因此需要有一个后备选项。
可与文件系统层技术结合使用，支持不具备复制能力的应用程序。