林仕鼎谈数据中心计算（一）：整体大于部分之和

《失控》中提到一个很普遍的现象，就是整体大于部分之和。比如，把 5 只蜜蜂加起来，仍然是 5 只蜜蜂；把 10000 只蜜蜂加起来，可就不仅仅是 10000 只蜜蜂了：它是一个蜂群，具备很多只有蜂群才有（而蜜蜂没有）的特性。

那么，把一万台服务器加起来，我们能得到什么？

在 IDC 时代，这一万台服务器就是一万台服务器，各自做各自的事情，使用各自的计算能力和存储，互相之间的交集无非是抢夺一下网络带宽。

现在，情况已经在转变：我们尝试让这些服务器把资源共享出来，服从统一的管理。一万台服务器现在变成了一个集群，同时它还有另一个名字：云。

我现在就是把数据中心当做一台机器来看。

林仕鼎如是说。

从百度基础架构部主任架构师到基础体系首席架构师，林仕鼎对数据中心各层架构的理解和构思，逐渐都投射为百度云的实现。从学术界到工业界的跨界背景，在操作系统内核、存储系统、分布式系统等领域的多重经验，决定了他独特的眼界和架构理念。

2013 年年初，林仕鼎公开介绍了百度在南京的数据中心，并提到了百度定制的 SSD 和将在今年取代 BDDB 的新型存储系统 CCDB。在微博中，林仕鼎说道：

下一个我要隆重介绍的神器是百度 SSD，这是我一直鼓吹的 Datacenter Computing 领域中 application-driven, software-defined 设计理念的典型实践。

根据林仕鼎的介绍，百度 SSD 的性能达到 PCIe Flash 的两倍，SATA SSD 的六倍。这是如何做到的？这个定制 SSD 搭配 CCDB 的设计理念跟以前的存储思路有何不同？这会对其他底层软件的设计思路产生怎样的影响？

带着这些问题，InfoQ 编辑与林仕鼎先生进行了一次深度交流。在这次将近两个小时的对话当中，仕鼎谈到了基于 PC 的设备和基于数据中心的设备的根本性不同，设计针对数据中心的底层软件都需要考虑到哪些方面，百度在软件定义硬件的其他方向的一些工作，以及关于 12306 的一些看法。在未来的一段时间内，InfoQ 会将这次对话的内容分批整理、发布。

今天的主题：为什么要针对数据中心设计一套与以前不同的存储系统？

桌面 / 嵌入式 / 移动系统 数据中心 使用场景 单用户多任务 多用户单任务 物理并行度 少 极多 容错需求 本机处理容错 多机处理容错正如同很多蜜蜂构成蜂群一样，由很多服务器构成的集群，拥有很多不同于单机的特性。但是，在数据中心发展的过程中，单机一直被当做最小单元来处理，正如同蜂群的最小单元是蜜蜂一样——如果把单只蜜蜂再往下分解，会造成无法重组回蜂群的情况。

就自然界而言，这样的处理方式最为灵活，很能满足蜜蜂这个族群的发展需求。但是，自然界的选择有一个最大的问题，那就是效率低下。对于数据中心而言，其实并没有必要把单机作为最小的单元来处理。这就是林仕鼎提出的数据中心计算的核心思想：让蜂群的意志直接操作最基本的组件。

从单机到数据中心，使用场景有何不同？

以前的 SSD 是为桌面系统和嵌入式系统准备的，可以说是单用户多任务的系统，并没有考虑到很多并行性的问题。

林仕鼎举了一个桌面端应用的例子：

作为通用操作系统，桌面操作系统可以运行很多种任务，这样的系统对底下 IO 的优化并没有做特别多，因为没有这样的需求。比如 Email 客户端吧，现在没有一个 Email 客户端能够处理几万封邮件的：无论是我现在在 Mac（SSD）上用的 Mail，还是用 Outlook，一旦我邮件超过一万封以上，它就非常慢了。

之所以有这样的设计，有很大的历史原因：

在 PC 时代，软硬件是一个开放的体系，厂商们共生于其中，形成了一套标准，没有哪个厂家能独立构造整套体系。对于设备制造商而言，其设计首先不是考虑性能，而是考虑如何兼容这套标准，怎样更方便的让开发者在上面编程。存储设备面对的是标准的接口，比如文件系统或者嵌入式的 SQLite DB。这层软件不变，下层硬件就只能屈就于它。所以，为了能适配这些软件，SSD 要对外提供单一设备接口，并隐藏细节，比如要先擦除才能写入等等。于是，在优化之后，SSD 拿出了 20~30% 的空间来做写缓冲，又使用内存的映射表达到擦除平衡延长寿命。

然而，数据中心对存储的需求是不同的：

在数据中心里，上层的存储系统可以面对很高的并行度，并没有单一设备接口这样的要求；而且类似读写平衡这样的处理，也已经在软件层面上完成了。

数据中心的应用也是不同的：

我们针对数据中心做的应用，通常都是一个专门的应用，这个应用是单任务多用户的，而且用户非常非常多，IOPS 至少都是几万、几十万这个数量级。这就对底层的要求很高。可以说，需求变了。

在数据中心里，存储系统本身已经做了很多的事情：

比如从存储系统过来的写操作，本来就不会对某一个单元写得特别多，它一定是均匀来写的。也就是说，我在上面已经做了写缓冲，也做了读和写的均衡，所以下层就不用做了，我们就可以把这些逻辑移出来。这样一来，SSD 就变得很简单：你只要提供简单直接的存储功能就够了。

这样的存储系统，不再需要有“自我意识”的底层硬件设备：

在存储系统看来，经过一系列的数据分解和组织的机制之后，对于存储设备的要求就是一堆的块设备。它同样也可以不用依赖文件系统。虽然我们可能还在使用文件，但其实都是定长的数据块。然后对于这些块来说，我们其实还可以把块空间直接映射到 SSD 里面去。

所以，我们把 SSD 上的写缓冲、映射表这些设计，这些控制逻辑，全都去掉。这样就把延迟和浪费的因素都去掉了，这就是为什么我们的性价比能够高。硬件其实是一样的，我们只是把它的架构变了。

针对单机和数据中心在并行度方面的不同，又做了什么？

林仕鼎简单介绍了一下以前的文件系统的设计场景：

以前，文件系统是针对单个硬盘设计的。这样比较简单，但缺点是没法将多个硬盘的并行度充分发挥出来。以前的数据库系统设计也是一样，希望面对单个硬盘，容量很大而且不会出故障。这就是 RAID 卡的作用，把一台服务器上的多个硬盘整合起来，加上冗余算法，形成一块大硬盘。这么做的好处是上层软件不需要有太复杂的控制逻辑，但坏处是降低了并行度也增大了延迟。

这跟 CPU 的情况其实类似：

再好比以前操作系统设计的时候，它面对的就是一块 CPU，后来多 CPU 出现时才改造成 SMP 的架构。但后来到了几十个核的时候，SMP 也不合适了——它的上限基本上在 16 个核左右，多了性能有问题。不过，对于 PC、手机来说，单个设备本身的并行度并没有特别大的改变，所以架构也并不需要特别去调整。

现在到了数据中心里面，量变已经引发了质变：

以前这么做是合理的，因为大家协同工作，所以兼容性和标准接口变得重要。在 PC 体系中，需求确定后，软件系统也就确定了，于是硬件只能在标准接口下发展。但数据中心给了我们一个机会，去重新考虑整套软硬件体系的构建，只要能满足最终的应用系统需求，兼容性和既有标准都不再重要。

此时，我们希望中间的层次越少越好。因为存储系统已经做了大量的数据管理工作，本身也具有操作多个硬件设备的能力，而且也不再依赖文件系统。正是因为存储系统能够直接访问硬件设备，我希望底下的并行度能够更充分的发挥出来，暴露物理细节而不是隐藏起来变成一个设备。

我们在设计存储系统的时候，已经充分考虑到了这个并行度。比如，一个服务器上可能挂了十几块硬盘，我们能同时调度这十几块硬盘，使它们能很好的并行工作。

针对高并行度的设计，其实林仕鼎在五年前就已经在 BDDB 上进行过实现，并专门为此找到硬件合作伙伴定制了设备：

在 2008 年前后，RAID 卡还是服务器的标配，多数存储系统的设计还是集中在数据组织上，对系统架构与硬件资源调度的考虑较少。在我设计 BDDB 时，采用了全异步的架构，可以对多硬盘、多网络和多 CPU 进行调度，RAID 的存在反而成了障碍。但要把 RAID 卡拆掉却非易事，我们花了很长时间才说服厂家给我们设计了一个 12 块硬盘直连的服务器型号。这个新型号现在已经是存储型服务器的标准了，但在刚开始使用时故障率很高，我们的存储系统一开始也不成熟，二者都用了一年多的时间才逐渐稳定下来。另外，这种服务器型号是先在中国开始应用然后再向美国推广的，这在过去是很少有的。

当然，现在的实现可以获得比当时更高的并行度：

我们 SSD 的做法就是充分暴露物理细节，尽可能让每个单元都成为可以被独立调度的设备。极端情况下，甚至每一个颗粒都可以成为一个独立单元——如果总线够宽、通路控制器够便宜的话。当然，具体能并行多少还要看成本和收益的折中。最终选择某个粒度形成最小的单元，这个单元可以独立控制，然后有多少个这样的单元，也就有了多大的并行度。

针对容错的设计又有怎样的不同？

单机的设计理念，一定是要越可靠越好，因为你只有一台机器，坏掉就没了。所以要在里面加很多冗余信息和校验逻辑，这样在出现错误之后还可以恢复回来。

分布式集群的概念出现之前，针对更多存储的冗余设计仍然是一样的思路：

以前的服务器在设计上的很多逻辑是从桌面上过来的，像是 RAID 卡，也是一个单机的思路，在内部做冗余，因为我能够控制的只有这台机器。

到了数据中心时代，还是那句话，量变引起质变。

在数据中心里面，我们已经不是从一个单机的视角去考虑这些事情了。

我们的存储系统，天然是分布式系统。分布式系统假设所有的设备最终都会发生故障，所以它可以容忍任意一台设备出现问题。因为没有什么设备可以做到 100% 可靠，我这个数据一定要分布到不同的机器上去——现在的工业标准是三个副本。

当我们把数据的副本放在不同的机器上时，我们以前所有的限制都可以去掉了。而且以前单机上的数据验证逻辑，也可以不要。RAID 卡的容错功能也可以去掉，它带来的修复和管理成本很高，可靠性却不如三个副本。这样，我们可以提升性能，也能再省一些空间出来。

总结

以上，林仕鼎总结了数据中心计算中，在系统设计上跟单机系统的三大区别：使用场景、硬件并行度、以及对容错的处理思路。

从系统的角度来看，整个数据中心就是一台机器。

接下来的对话中，林仕鼎会介绍设计一个数据中心级别的系统时的一个关键概念：分层。敬请期待！

在 4 月 25 日 QCon 北京的主题演讲上，林仕鼎将会带来主题为《架构设计与架构师》的分享，就系统领域中基本的存储、计算、分布式技术以及服务模型进行分析，从另一种视角看待这些领域问题。敬请期待！

感谢马国耀对本文的审校。