未来的Kubernetes将效仿Facebook的做法

有趣的是，Facebook一直站在单套接字服务器的前沿，尤其是Yosemite微服务器，它们被广泛部署在Facebook上运行基础设施软件。这里是这样的效果，每个Facebook数据中心现在都有更多的物理服务器，如果没有更多的标准双套接字机器，可能会有更多的物理服务器，这会给Tupperware带来更多的负载，而摩尔定律(Moore’s Law)正在增加每个节点能够支持的核心，因此也就增加了容器的数量。因此，需要分割Tupperware的工作，但希望与Tupperware的界面保持透明。

但这里还有另外一个使命，最终，Facebook希望能够通过一个面板管理其整个机群，这将需要更多的Tupperware工作分片，以及与Facebook网络上的工作负载相关的类似存储分片。到目前为止，Facebook已经安装的服务器中只有20%包含在这个巨大的共享资源池中，但最终Facebook希望能够随时随地使用其全球资源，而不再考虑数据中心和区域。

这是另一个有趣的观察，Borg考虑工作负载的方式是，有在线工作和批处理工作，调度程序的主要工作是用批处理工作(如MapReduce数据分析工作)填充空闲的容量，直到在线工作(如填充搜索引擎请求)需要更多的容量。因此，这两种类型的工作在系统上交错进行，按需要按比例增加和减少它们的使用，以提高利用率。

Facebook采取了一种不同的方法，并在原始服务器级别进行思考。首先，使用微服务器时，每个服务器节点的原始计算量更小，因此与使用双套接字机器相比，可以分割的部分更少(这一点随着AMD Rome Epyc处理器的高内核数量而发生变化)。在Facebook，程序员被教导以这样一种方式编码，即使用他们在服务器上所能使用的所有容量。在每个区域的夜间，当新闻提要、Messenger、Web前端和应用程序的其他层没有被大量使用时，该区域的服务器节点将执行各种批处理工作，如MapReduce分析和统计机器学习(毕竟，并不是所有的东西都需要GPU才能进行深度学习)。因此，不必担心多少在线或批处理工作提供每个物理服务器上不同的容器与Resource Broker，Facebook将批处理或在线工作分配给每个服务器，确保它运行完整得到最有价值的消费。这是谷歌和Facebook之间一个有趣的区别，在Facebook中，容器实际上更像是一种部署机制，而不是工作负载隔离工具。

除了规模之外，还有一个领域是Facebook声称对Kubernetes有吹嘘的权利，那就是管理有状态的应用程序——比如Facebook网站、Instagram、Messenger和WhatsApp背后的数据库和数据存储，包括ZippyDB、ODS Gorilla和Skuba——而不是无状态的应用程序——比如构成Facebook应用程序前端的网络和PHP服务器。

Tupperware控制器上增加了一项名为TaskControl的服务，该服务查看应用程序对维护与其存储的有状态链接的依赖性，然后根据这些需求决定如何部署运行这些应用程序的容器，并根据需要更新和移动它们，而不会破坏该有状态链接，从而损坏或崩溃应用程序。TaskControl与一个名为ShardManager的数据服务协同工作，该服务决定数据在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层的情况下完全更改存储系统的底层，这意味着两件事：存储系统可以具有多个并发的特性，并且可以根据需要独立地更新不同的层。

（编辑：辽源站长网）

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