在上一篇文章中，我概述了构建数据复制解决方案时所面临的一些挑战，第一个Delphix实现是如何脱胎换骨的，以及我们如何着手在第二次构建更好的解决方案。在启动新的复制子系统之后，第一件事情变得很清楚：我们需要更好的NDMP实现。一个只有二进制的单独的守护进程，错误语义很差，通常会使系统处于不一致的状态，这样做是不可能的。NDMP是一种为单一目的而构建的协议：使用特定于文件的格式（转储或tar）在任意拓扑（直连磁带、三向恢复等）上备份文件。由于两者同时在数据语义上如此具体，但在控制协议中又如此笼统，我们最终得到了两个世界中最糟糕的结果：生硬的概念（如文件历史，完整的索引节点编号）阻止我们充分表达Delphix概念，以及一个有限的控制协议（缺少多个流或可恢复流），错误语义非常糟糕。虽然我们最终将取代NDMP进行复制，但我们知道我们仍然需要它来进行备份，而且我们没有时间为当前版本同时替换实施和数据协议。Illumos是我们发行版所基于的开源操作系统，它提供了一个NDMP实现，我以前在Fishworks时就处理过这个问题（尽管Dave Pacheo是真正进行NDMP集成的人）。我花了一段时间研究了这个实现，得出的结论是它存在一些致命缺陷：糟糕的错误语义-策略是"记录所有事情，然后再担心它"。对于一个使用自己的操作系统的实现来说，这不是一个糟糕的策略，但对于一个设备实现来说，这是一个失败的交易。我们需要清晰、简洁的故障模式，这些模式似乎与我们的UI集成在一起。嵌入式数据语义（Embedded data semantics）——tar作为备份格式（或原始zfs send）的概念非常深入地构建在体系结构中。我们需要自己的数据协议，但是不做大手术就不可能取代数据操作。虽然原始ZFS send看起来很吸引人，但它仍然假定拥有文件系统名称空间的所有权和控制权，这在Delphix世界是不可能的。未使用的代码-有大量的死代码，从不必要的协议变体（NDMPv2）到大量设备处理代码什么都不做。独立守护进程-独立守护进程使跨进程边界交换数据变得困难，并引入了新的复杂故障模式。考虑到这一点，我看着ndmp.org网站SDK实现，发现它也有同样的病态（以及更糟糕的启动实现）。很明显，Solaris实现是从SDK派生出来的，数据分析，而且没有神话般的"伟大的NDMP实现"等待着我们去发现。我要把它吸起来，然后回到我的太阳神之根，把这只野兽的内脏挖出来。我做的第一件事是将守护进程重新构造为一个库，删除所有处理守护进程的代码，运行door服务器来报告统计信息，购返利，什么叫物联网，以及与服务器通信的现有Solaris命令。这允许我添加一组客户端提供的回调向量和配置选项来控制状态。有了这个库，我们就可以使用JNA轻松地从java管理堆栈调用C代码，而不必担心将数据封送到外部守护进程或从外部守护进程中封送数据。下一步是删除所有的数据处理功能，而不是在库注册机制中创建一组回调向量来启动和停止备份。这就把over-the-wire格式的实际实现留给了消费者。用于支持tar和zfs send的代码数量惊人，而且它在整个实现中都有其卷须。当我开始拉线的时候，越来越多的开始解开。特定于数据的操作将调用"磁带库管理"代码（它与磁带库管理几乎没有任何关系），然后调用通用的NDMP代码，这样就什么也做不了了。随着数据操作的消失，我最终不得不解决最困难的部分：使代码可用。旧的错误语义非常糟糕。我必须遍历每个日志调用和非零返回值，分析它的用途，并重新构造它以使用使用者提供的向量，这样我们就可以在Delphix堆栈中本机地记录这些消息。在进行通用代码清理时，这导致我从缓冲区管理到NDMPv2支持（v3已经被普遍使用了十多年）等大量未使用的代码。这是相当痛苦的，但结果是相当有用的产品。虽然旧的Delphix实现会报告"NDMP服务器错误严重：有关详细信息，请参阅服务器日志"（当然，客户无法访问"服务器日志"），但我们现在将看到更多有用的消息，如"NDMP客户端在数据操作期间报告了一个错误：空间不足"。最后一块拼图让我很惊讶。通过选择NDMP作为复制协议（同样是临时选择），我们需要一种方法来从Delphix堆栈中驱动三向恢复操作。这意味着我们想扮演DMA的角色。当我查看NDMP SDK附带的令人难以置信的糟糕的"ndmpcopy"实现时，我注意到，与我们在客户端上所需的和服务器上的类似（处理请求是相同的，即使预期的请求集大不相同）。我没有构建完全独立的实现，而是将libndmp转换为可以充当服务器或客户机。这使我们能够在Java中构建NDMP复制操作，并模拟远程DMA（一种非常宝贵的测试工具）。花了一个多月的时间，又花了几个月的时间到处清理，什么是软件企业，但结果是值得的。新的实现只有11000多行代码，而最初的实现是惊人的43000行代码。我们的实现不包括任何实际的数据处理，所以这可能是一个不公平的比较。但我们还包括了作为全功能DMA客户端的功能，这是illumos实现所缺少的。gitx将在几周内发布结果。我们不太可能向上推一些有趣的东西。我鼓励其他寻求开源嵌入式NDMP实现的人改进我们在Delphix中的功能—这是一种非常灵活的NDMP实现，返现，可用于各种非传统NDMP场景。但由于没有内置的数据处理，也没有独立的守护程序实现，要取代illumos中的功能还有很长的路要走。如果有人受到启发，您可以在当前库的基础上构建一个守护进程—它支持tar、dump、ZFS以及当前illumos实现支持的任何其他格式。这不是一个小的工作量，但我很乐意向任何感兴趣的人提供建议（如果不是代码的话）。下一篇文章的标题是"数据复制：元数据+数据=我屁股上的痛"。