随着下一个Delphix版本即将发布，我想花一些时间讨论一个主要新功能背后的工程过程：服务器之间的数据复制。当前的Delphix版本已经有了一个复制解决方案，那么这如何构成一个"新特性"？原因是它是一个全新的系统，是努力创建一个更可靠、可维护和可扩展的系统的结果。我们是如何做到这一点的，这是一个关于业务分析、架构和实现的有趣故事。我们从哪里来的？在我们开始研究当前的实现之前，我们需要理解为什么我们一开始就有一张白纸，而我们已经有了一个运输解决方案。简而言之，我们所拥有的是不可用的：它不可靠、不可调试、无法维护。当您负责灾难恢复的数据一致性时，"不可靠"是不可接受的状态。虽然我没有在Fishworks编写任何复制基础设施（我的同事Adam Leventhal和Dave Pacheco值得称赞），但我花了大量时间与他们讨论，并考虑如何在Fishworks构建分布式数据架构。所以我在德尔菲斯接这个项目似乎很自然。当我开始放松我们目前的状态时，我发现了一系列的决定，大数据云计算，事后看来，这些决定导致了我们今天所处的无法维持的状态。对业务问题的分析——当前复制系统的核心是认为其目的是为了灾难恢复。这确实是复制的一个主要用例，但它不是唯一的用例（数据的地理分布是另一个强有力的竞争者）。虽然首先要解决的一个主要问题是限制范围的合理方法，大数据产业，但由于未能正确识别未来的机会，我们最终得到的解决方案只能用于主动/被动灾难恢复。数据协议选择—还有一个与复制非常相似的问题：离线备份/恢复。显然，我们希望利用相同的数据格式和序列化过程，但是我们想使用相同的协议吗？NDMP是备份的行业标准，但它是针对特定的使用情形（文件和文件系统）而定制的。通过选择使用NDMP进行复制，我们牺牲了特性（可恢复的操作、多个流）、可用性（错误语义差）和可维护性（不必要的复杂操作）。工作外包—在创建此体系结构时，已确定NDMP不是公司核心竞争力的一部分，我们应该与第三方签订合同以提供NDMP解决方案。我坚信工程工作永远不应该外包，除非事先知道结果会被抛弃。否则，您将不可避免地承担产品的一部分，而您的更改、调试和支持能力有限。在我们的例子中，由于可交付的是二进制对象——我们甚至没有可用的源。体系结构设计—通过使用一个单独的NDMP守护程序，我们被迫使用一种神秘的通信机制（本地HTTP），这种机制在每次转换时都会丢失信息，导致大量应用程序逻辑停留在我们无法控制的二进制文件中。这使得它很难适应底层抽象的核心变化。算法设计-有一个非常早期的决定，复制将在每个组的基础上进行（Delphix将数据库排列成逻辑组）。这与底层ZFS数据依赖关系的现实脱节，导致了许多奇怪的情况，例如无法复制非自包含的组或组之间的循环依赖关系。这种抽象被深深地烙进了架构中，以至于不可能在原始架构中修复。实现——实现本身被构建成与系统中任何其他代码"隔离"的。当复制系统元数据的核心表示时，这将导致无法维护和脆弱的混乱。我们有一个完全独立的对象模型副本，它必须与核心模型一起维护和更新，而系统中其他地方的更改（例如在复制过程中删除对象）可能会导致模糊的错误。最严重的问题导致了不可恢复的状态—目标和源可能不同步，因此唯一的解决方案是从头开始进行新的完整复制。测试基础设施-没有单元测试基础设施，没有自动功能测试基础设施，也没有办法在不手动设置多机复制或使用远程DMA的情况下测试大多数功能。因此，只有最基本的功能才起作用，而且即使这样，大多数时候也不可靠。新体制的理想考虑到这些限制，我（后来由马特加入）坐下来，云从，拿了一张新的纸。以下是我们在构建这个新系统时提出的一些核心理念：机制与协议的分离——无论我们在协议和复制拓扑方面做了什么选择，我们都希望核心序列化基础设施与用于传输数据的协议完全分离。对任意拓扑的支持—我们应该能够从一个主机复制到任意数量的其他主机，反之亦然，还可以从复制的对象进行供应。健壮的测试基础设施—我们应该能够在单个系统单元测试框架中运行协议级测试、模拟故障并执行完全复制。与核心对象模型集成-应该有一个地方维护对象定义，这样复制系统就不会与主源代码失去同步。抗故障能力-无论发生什么情况，系统在面对故障时必须保持一致的状态。这包括灾难性的系统故障，以及正在进行的系统更改（即创建和删除对象）。在任何时候，怎么选购云服务器，免费的数据分析软件，我们必须能够在没有用户干预的情况下从先前已知的良好状态恢复复制。清晰的错误消息-当失败发生时，必须清楚地表明问题的性质，以及用户必须采取什么措施（如果有的话）来解决潜在的问题。同时，我们被迫限制项目的范围，以便在适当的时间范围内交付一些东西。尽管存在固有的问题，我们还是坚持将NDMP作为一种协议，因为我们还需要修复备份/恢复实施。我们保留了主动/被动部署模型，因此不需要对GUI进行任何重大更改。接下来，我将讨论第一项主要工作：构建更好的NDMP实现。