未来的Kubernetes将效仿Facebook的做法

正如你可能想象的那样，管理Tupperware和其他Facebook服务中的控制平面的数据是一项很大的工作，为此，Facebook正在谈论一种新的复制存储系统Delos，部署在Facebook堆栈的控制平面中，最终可能成为文件和对象存储的架构。

在Delos创建之前，Facebook软件的各种控制平面中使用的数据以各种不同的方式存储，有些使用MySQL，有些使用ZooKeeper，有些使用其他键值存储或数据库。与大多数公司一样，每个独特的应用程序似乎都需要一个独特的数据存储或数据库，具有自己的API、性能、容错和部署方法。控制平面的这些存储系统通常必须从头开始设计，并在每次向这些控制平面添加一组新特性时重写。这真是件麻烦事。

因此，Flinn告诉“Next平台”，Facebook放弃了使用Delos的单片存储系统设计。

Flinn解释说，Delos背后的想法是围绕可重构、虚拟、分布式共享块的新抽象构建一个存储系统，这允许我们满足控制平面的许多独特目标。所以你有了高可靠存储的标准：它必须是高可用的，它必须是强一致的。它还必须有一个相当丰富的API，其中包含一些类似于带有辅助索引的关系查询的内容，以及一些查询规划和复杂谓词。它还必须运行在各种各样的硬件上，我们最新的和最好的机器上，它们的存储空间肯定是最好的，但是它也应该运行在旧的机器上，这些机器可能与它提供元数据的服务位于同一位置。最后，在我看来，这方面最大的要求，也是Delos所提供的独特之处之一，就是它必须没有依赖关系，而且它的设计目标是在堆栈的底部。这简化了一些事情，比如打开一个新的数据中心、恢复工作等等。

Delos背后的关键思想是，所谓物化的数据状态与存储的顺序和持久性方面是分离的，并且可以从相对简单的日志构建具有不同级别容错或复制的更复杂的日志。像下图这样：

VirtualLog可以切换模式，以一种SimpleLog格式操作另一种SimpleLog格式，同时仍然在更高的具体化级别上维护状态，这就是关系、键值、文件系统和其他API对外公开的方式。这样做的好处是，可以在不破坏上层API层的情况下完全更改存储系统的底层，这意味着两件事：存储系统可以具有多个并发的特性，并且可以根据需要独立地更新不同的层。

Delos的第一个用例是创建一个名为DelosTable的关系系统，它位于Tupperware资源代理下面，取代了Facebook从Hadoop堆栈的开源ZooKeeper项目创建的定制ZKLog系统。起初，Facebook将DelosTable放在ZKLog之上运行，四个月后，它能够使用原生的SimpleLog格式替换掉ZKLog层，该格式基于LogDevice系统，Facebook在Tupperware生产软件环境中开放了一段时间。下面是运行Tupperware资源代理的每种不同日志格式的性能概要：

（编辑：PHP编程网 - 湛江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!