树莓派2构建微型数据中心

树莓派2在数据中心的大数据和视频流应用中的能力

摘要

近年来，为了满足日益增长的服务器容量需求，许多新的数据中心被建立起来。这些数据中心需要大量的电能和冷却资源。大数据和视频流是数据中心中两个广泛使用的应用。本论文通过实验研究了使用廉价、低功耗且广泛支持的硬件作为微型数据中心的可行性及其优势，重点应用于大数据和视频流场景。为此，采用了多个树莓派2型B款（RPi2）构建了一个功能完整的分布式Hadoop和视频流设置，在性能上可接受，并拓展了新的研究机会。我们通过对其性能、可扩展性、能耗、温度和可管理性的分析，实验验证了该新型配置适用于数据中心环境。本文提出了一种在小型1U机架尺寸内实现高并发和低功耗的配置方案，预计可容纳72台树莓派2，作为传统机架式服务器的一种有趣替代方案。

关键词 ：微型数据中心 · Raspberry Pi 2 · Benchmarking · Hadoop · Big数据 · Video流 · Cloud计算

1 引言

在数据中心，过去几年服务器的密度显著增加[16]。新技术不断涌现，例如刀片服务器，不仅减少了曾经占满整个机架的服务器的物理体积，还通过采用新技术降低了功耗。ARM 处理器是另一种相对较新的技术，可能真正满足数据中心对模块化日益增长的需求。由于树莓派是具备 ARM 处理器、板载相对强大的图形芯片的完全功能服务器，并且由于能耗较低，这些应被视为一种重要的替代方案。本文的主要挑战是将搭载 ARM芯片的树莓派2集成到数据中心中。本文详细探讨了数据中心的两大应用：（i）大数据；以及（ii）视频流。大数据解决方案通常将数据处理分布于多个服务器上，对存储设备有较高需求。大数据的主要任务是对大量数据进行查询，以获取有价值的信息。另一方面，视频流应用对网络能力要求更高，因为其主要任务是在视频播放期间无缝地传输数据。视频流涉及处理大量小型任务，而大数据应用则执行相对较大的任务。

本文通过研究树莓派在微型数据中心中的能力，重点对一种可用于数据中心的树莓派集群实验设置进行功耗、性能、温度和硬件分配的基准测试与测量。这些方面使我们能够分析未来灵活且可持续发展的数据中心的三个主要设计标准[4,第 6]，即：可扩展性、性能和可管理性。

首先，在第2节中阐述了云计算在大数据和视频流方面的背景信息。第3节描述了一些基于RPi硬件的云项目。随后将讨论我们自主提出的RPi2集群，并使用Hadoop和视频流对其进行充分测试，以研究RPi2在微型数据中心中的应用潜力。

2 数据中心的两个关键应用

本节介绍了两大主要应用——大数据和视频流的背景。大数据是指数据量过大、过于复杂而无法通过常规数据处理应用程序处理的数据。在第2.1节中讨论了一种大数据解决方案，该方案允许对这些大规模数据块进行分布式处理。由于视频流服务Netflix在美国占据了约30%的下行流量[2]，因此在第2.2节中通过简要描述其运营模式和方法（灵感来源于现有的视频流服务Netflix）来深入探讨这一相关应用领域。

2.1 大数据

Apache Hadoop [25] 是一个开源框架，提供使用映射/归约等简单编程模型对大量分布式数据进行分布式处理所需的组件。它被设计为可从单台机器扩展到数千台机器。Hadoop 提供了高可用性选项，用于检测和恢复硬件及软件中的故障。Hadoop 被用于风险建模和推荐引擎等应用，这些应用需要分析拍字节级别的数据。

Hadoop 中实现的映射/归约 [9] 是一种编程模型，用于对大型数据集进行简单的分布式处理。一个映射/归约程序包含两个步骤。映射步骤执行过滤和排序。归约步骤则可以对映射的输出进行进一步计算，这通常是一种汇总操作。根据程序的不同，映射和/或归约任务可以并行化。

在Hadoop 2中，引入了 Yet Another Resource Negotiator（YARN）作为新的资源管理层。YARN负责工作负载的管理和监控，管理高可用性功能，并支持除映射/归约之外的更多编程模型。

戴尔、惠普和超微等大型服务器制造商为Hadoop应用提供各种类型的服务器。Hadoop通常运行在大量包含八个或更多存储驱动器的1U机架式服务器上。1U机架式服务器相对便宜，但与更昂贵但更高效的解决方案（如通常为 10U的刀片服务器）相比，在部署大量服务器时会带来较大的空间和能耗开销 [20]。刀片服务器将垂直放置的刀片集中在一个共享电源和统一网络接入的机箱中，使其比传统1U服务器更加节省空间[20] Hadoop系统可以从单台服务器开始部署，并可扩展至数千台服务器。

2.2 视频流

大型视频流提供商通常需要执行各种操作，以不间断且快速的方式向客户交付视频。为此，视频的缓冲区时间被最小化，从而确保视频在任何时间都可访问。随后，视频由对客户端延迟最低的服务器进行传输。像Netflix这样的大型视频流提供商，其服务需要以下三项操作：

1. 内容摄取，即电影母版的影片被接收并上传至云。
2. 内容处理，即在云中为每个视频创建多种不同格式（例如AVI、MP4和MKV格式）。这些格式被上传到内容分发网络（CDN），CDN是由多个数据中心组成的网络，用于向用户分发内容。这意味着所创建的所有格式都将通过CDN进行分发。

Netflix 拥有自己的 CDN，可更好地分析网络，并改进负载均衡和视频流算法。为了存储所有视频数据，Netflix 使用文件存储系统亚马逊AWS、simpleDB、S3 和 Cassandra[2]。

视频流严重依赖数据存储，大多数情况下使用的是旋转式硬盘驱动器（ HDD）。如果某个视频被频繁访问，则会使用U1 SSD服务器以实现更快的流媒体传输。这意味着存在两种类型的服务器。配备HDD的服务器通常占用4U 的服务器空间，而固态硬盘变体的服务器则占用1U服务器空间[27]。

3 相关工作

已有多个使用树莓派Model B(+)(RPi)的集群项目。

由Cox等人构建了包含Iridis-pi 64个RPi的集群[7]。使用消息传递接口在树莓派之间进行通信。该研究旨在探究低功耗高性能集群的性能。该集群被设计为用于教育目的的便携式被动冷却集群。

Tso 等人[26]构建了一个由56个RPi组成的数据中心，该中心提供了一个包含虚拟化管理工具的云计算测试平台，称为Glasgow Raspberry Pi Cloud。该平台用于云计算的实际研究，避免了模拟的局限性。

Kiepert [17]为一项博士课题创建了一个Beowulf集群，用于在无线传感器网络中协同处理传感器数据。当主集群不可用时，树莓派集群可作为一种替代方案。

由亚伯拉罕松等人[1]搭建的Bolzano Raspberry Pi集群由300个RPi组成，旨在打造一个经济实惠的节能计算机集群。该集群被用于绿色研究测试平台和移动数据中心等应用场景的评估。其主要目标是实现更大规模的树莓派集群部署。

上述描述的树莓派集群主要用于研究、应用性能和集群移动性。上述项目使用的是第一代树莓派，其性能明显低于较新的第二代树莓派。本研究通过提供Hadoop和视频流应用在温度、功耗和性能方面的基准测试，与其他树莓派集群研究区分开来。

4 系统描述

在系统描述中，详细阐述了软件和实验设置。首先，在第4.1节中简要概述了微型数据中心中使用的设备，即树莓派2。在实验设置部分，第4.2节详细说明了我们自建的用于Hadoop和视频流变体的微型数据中心。第4.3节讨论了分布式处理所需的Hadoop软件。接着，第4.4节详细阐述了大型流媒体服务所需的视频流软件。

4.1 Raspberry Pi2

树莓派2型B款 [24]是一款小巧、便宜但功能丰富的计算机。它基于博通 BCM2836片上系统，配备900 MHz四核ARMv7 CPU和1GB内存，目前售价约为35美元。详细规格见表1。存储解决方案采用16 GB Adata Premier Pro UHS‐I microSD卡（图1）。

表1. 树莓派2型B款 规格 [24]

片上系统 博通BCM2836
以太网	板载10/100以太网 RJ45接口
USB	四个USB 2.0
视频输出	HDMI 1.4
音频	2路模拟
CPU	900兆赫四核ARM Cortex‐A7
GPU	双核VideoCore IV 多媒体 协处理器
卡槽	微型SD

4.2 实验设置

在我们的实验设置中使用了八个树莓派2。Hadoop和视频流的设置示意图分别显示在图2和3中。

设置示意图中的数字对应图4中所示的物理设置。数字（2）表示连接到电源的小型路由器/交换机。数字（1）表示八个RPi2。在视频流应用中，会安装一个负载均衡器和多个视频流服务器。对于Hadoop，则有一个主节点和多个从节点。

Dietpi[8]用作各个节点的操作系统。它是Raspbian的轻量版本，而 Raspbian是专为树莓派2定制的Linux发行版。

4.3 Hadoop软件

一个基本的Hadoop安装包括三个主要部分：HDFS、YARN和JobHistoryServer。

HDFS 是 Hadoop 分布式文件系统，由多个进程组成。名称节点是主要进程，负责跟踪所有文件的分布和复制位置，它是所有客户端的主要访问点。并在主节点上进行处理和运行。SecondaryNameNode（第二名称节点）会保存NameNode的最新备份，以便在NameNode可能发生故障时进行恢复。

DataNode（数据节点）进程在其余的从节点上运行，并负责数据存储与检索。

YARN 由一个 ResourceManager（资源管理器）组成，用于管理系统中的所有作业，以及在每个从节点上的 NodeManager（节点管理器）。NodeManager 进程负责处理分配给从节点的作业执行。

最后，JobHistoryServer 会跟踪所有已完成的作业及其日志。

在与Oracle Java 7 ARM HF配合下，配置了原生编译版本的Hadoop 2.6.0与YARN。

由于仅有八个可用的树莓派2，因此单个主节点运行名称节点、Secondary NameNode、 ResourceManager和JobHistoryServer。其余（可扩展的）数量的节点作为从节点，每个节点运行一个NodeManager（节点管理器）和一个DataNode（数据节点）。

该设置拥有91 GB的分布式存储，复制因子为2，因此有效存储容量约为 45 GB。YARN已配置为可在单个从节点上同时运行两个容器，这在测试设置中为Hadoop提供了14个可用的容器槽位来分配任务。

4.4 视频流软件

该视频流软件由四个软件程序组成：nginx、FFmpeg、JW Player 和 Cassandra。用于HTTP上的负载均衡和流媒体传输，nginx[23]被使用。

nginx 具有高效的 HTTP 负载均衡算法。实时消息协议（RTMP）模块来自 Arut 的 nginx，用于通过 HTTP 构建媒体流服务器 [5]。它具有高效的算法，可将封装了 RTMP 数据的 HTTP 传输给用户。FFmpeg 是一个跨平台的音频和视频录制、转换与流媒体解决方案 [11]。使用该软件可实现自适应流媒体以及多种格式的流媒体传输。JW Player 是一个 HTML5/Flash 嵌入式媒体播放器 [18]。JW Player 可根据视频输出的比特率实现可靠的负载均衡。它支持动态流媒体，该流媒体由多个内容相同但质量不同的单个流组成[18]。

Cassandra 是一种数据库，可帮助在多个数据中心之间复制数据[6]。数据可以自动在节点之间复制以实现容错性。因此，当某个节点发生故障时，数据仍然可用。

5 集群基准测试

本节详细介绍了在功耗、温度、存储、内存和网络方面的基准测试与测量，以在数据中心环境条件下对集群进行测试。

5.1 存储和内存性能

对于基本的系统基准测试，使用了SysBench套件[19]。它作为一种工具，可在不设置任何复杂软件的情况下快速确定系统性能。

表2. SysBench 存储 & 内存

基准测试	传输速度
随机存储读取	9.9718 MB/s
随机存储写入	1.2604 MB/s
随机存储读写	3.4046 MB/s
顺序存储读取	17.7400 MB/s
顺序存储写入	6.3972 MB/s
顺序存储重写	13.0000 MB/s
顺序内存读取	207.5000 MB/s
顺序内存写入	177.0200 MB/s

通过运行随机和顺序存储测试对SD卡存储进行了测试。使用SysBench准备了4GB测试数据。基准测试的最大执行时间为300秒。内存测试在内存中顺序读取和写入了512MB数据。

表格2显示SD卡的写入性能较低。读取性能低于SD卡标称水平，其顺序读取操作承诺达到40MB/s，但实际速度仅达到该值的一半左右。树莓派2的内存顺序读取速度为207 MB/s，写入速度为177 MB。

5.2 能耗

使用一个简单的装置来测量能耗。通过一块带有两个USB连接器和一些跳线的原型PCB，将万用表（Elro M990）接入以测量单个树莓派2的电压和电流。这样便可测得树莓派2的实际功耗，因为未考虑电源效率。如果在墙壁插座处进行测量，功耗预计会更高。

在多种工作负载下测量了功耗，以了解不同类型的操作对树莓派2功耗的影响。使用SysBench持续对主板的不同部分施加压力。

表3. 用于测试无电源损耗情况下树莓派2能耗的基准测试

	电流(A)	电压(V)	功率(W)
CPU 1核	0.340	4.84	1.65
CPU 2核	0.365	4.79	1.75
CPU 3核	0.392	4.77	1.87
CPU 4核	0.415	4.78	1.99
内存测试	0.440	4.79	2.11
存储读取	0.442	4.77	2.11
存储写入 0.395	4.77	1.89
Idle	0.315	4.78	1.51

如表3所示，树莓派2在此测试中的功耗最多为2.1 W。一台普通服务器大约需要500 W [21]，因此238台树莓派2的功耗相当于一台服务器。

5.3 网络性能

Iperf3[10]被用来通过从/向不同介质[10]读取/写入数据，以确定网络、存储或内存是否存在瓶颈。树莓派2使用通过集成的USB 2.0/以太网芯片[22]连接的 100兆以太网连接。这一点非常重要，因为Hadoop会在网络中进行大量数据的洗牌操作，而视频流需要在服务器之间以及向用户传输大量数据。为了确定是否存在瓶颈，已执行了60秒iperf3基准测试，拥塞窗口为133千字节，测试包括内存到内存、内存到存储以及存储到内存的场景。

表4. 使用树莓派2内存和SD卡存储的以太网吞吐量基准测试

写入方向	平均带宽（兆比特）
内存 →内存 93.4
内存 →存储	24.3
存储 →内存	94.2

对于每次吞吐量基准测试，拥塞窗口均为133千字节。根据表4中的结果，树莓派2和/或SD卡的写入性能存储卡形成了瓶颈，速度仅为3 MB/s。该数值与SysBench写入测试结果一致，随机写入和顺序写入的速度分别为1.26 MB/s和6.4 MB/s。USB 2.0/以太网带来了一些开销，因此其吞吐量约为94 Mbit。

5.4 温度

在使用不同线程数进行SysBench CPU压力测试期间，通过shell脚本记录操作系统的温度数据来测量CPU温度。该温度测量是在CPU上进行的。结果如图5所示。此基准测试期间的室温约为 23°C。基准测试结束后出现的冷却阶段如图 6所示。冷却阶段期间的室温约为 21°C，并在另一次独立的基准测试运行中测得。默认情况下，树莓派2是一块无散热片或风扇的被动散热电路板。

运行四线程CPU基准测试时，最高温度为60°C，空闲时温度为 42°C，见图5。在图5中，经过短暂时间后，温度趋于一个上限值。基准测试完成后， CPU迅速冷却至空闲温度，如图6所示。数据中心需要维持约 26°C的温度，为此需要额外消耗能量进行冷却[12]。Hadoop和视频流最常见的工作负载为两个 CPU线程，此时温度保持在约 50°C。因此，若使用多个树莓派2，需要一定的散热措施，以确保其工作在最佳性能温度范围内。

6 应用基准测试

在本节中，通过分析多个Hadoop和视频流基准测试，表明在数据中心环境中，所提出的设置具有可接受的性能。

6.1 Hadoop 基准测试

选择了一系列Hadoop基准测试，以涵盖Hadoop集群最重要的方面。这些基准测试属于HiBench基准测试套件[13]，即标准的Hadoop测试套件，涵盖 CPU密集型计算和分布式大数据上的通用计算。并与特温特大学的CTIT集群进行了比较，该集群中Hadoop运行在32台Dell R415服务器上。

Terasort 是一种用于测量在大型分布式文件上排序速度的基准测试。该基准测试包含一个 Map/Reduce 任务，用于创建并排序多个 100 字节的行，并验证结果。输出文件的复制因子被强制设置为 1，而不是使用集群默认值。这样可以确保数据在整个集群中的复制不会影响实际的 Map/Reduce 性能。

表5. Terasort 基准测试

	树莓派2	树莓派2	树莓派2	树莓派2	树莓派2	树莓派2	CTIT	CTIT	CTIT
节点	5	8	5	8	5	8	-	-	-
插槽	8	14	8	14	8	14	80	-	16 6
Maps	16	16	64	64	80
归约	8	8	8	8	8	8	8	8	8
数据（GB）	1.366	1.230	3.758	4.17	7.47	-	10	10.341	2
总时间（秒）							71	01
平均映射（秒）	70	72	144	141	-		261	41	92
平均混洗（秒）	70	88	491	-	741	698	-	830	21
平均归约（秒）	48			406	-		550

CTIT集群的容器槽位和节点数量远超RPi2集群。CTIT集群中有足够的槽位可一次性分配所有映射/归约任务，因此表5中未提及可用槽位。

在五个节点上运行7 GB数据时，较小集群的一个固有问题显现出来，该问题是由于Hadoop针对更大集群所做的优化所导致的。当一个节点上的映射任务完成后，Hadoop会在此同一节点上启动一个归约任务，因为所需数据已经存在于该节点。这些节点被配置为可同时运行两个任务。在拥有七个节点的情况下，总共可提供14个容器槽位，其中一个是应用程序主控。当映射任务数量较多时，如果任务数量超过可用容器的数量，部分任务将按顺序运行。问题在于，一旦第一批映射任务完成，归约任务就会在节点上启动，因此只有少量容器可用于完成数量相对较多的映射任务。由于映射任务产生的输入数据速度较慢，归约任务将会有大量空闲时间。增加更多节点可以解决此问题，因为将有足够的槽位来分配映射作业，从而使总运行时间更接近平均映射时间。

由于7GB的运行分配了64个映射任务，完成所有作业总共耗时1747秒。平均归约时间较高，因为归约器仍在等待新的输入数据。洗牌时间是指将映射任务输出的数据传输到正确归约器所需的时间。由于映射任务的数量通常远多于归约任务，因此这一数值对Hadoop的快速运行至关重要。归约器能够以约11 MB/s的报告速度从其他节点获取数据。这意味着Hadoop大部分时间是在写入内存，因为Iperf3显示通过网络写入SD卡的写入速度要低得多。

当TeraSort在5个节点上使用10GB数据运行时，首次出现了最后一个问题。如果Hadoop将两个归约任务分配给单个节点，这些任务需要处理大量数据，因此在将结果写入HDFS时会消耗过多内存，导致DataNode（数据节点）进程崩溃并被挤出内存，从而使归约任务失败。随后，Hadoop可能会决定在集群中启动同一作业的两个副本。这在小型集群中会加剧问题，显著增加两个任务运行在同一节点上的可能性。此问题可能通过更改YARN配置来解决，即限制每个节点仅运行一个归约任务。

表格5显示，CTIT集群在排序1GB数据时的总运行时间比RPi2集群低十倍。映射任务的平均耗时在RPi2集群上也大约长了十倍。当处理更多数据时，由于 RPi2集群中可用的容器槽位不足，运行速度显著变慢。在排序10 GB数据时， RPi2集群上的映射任务平均耗时是CTIT集群的24倍。这一更高的比率可能是由于在处理更多数据时，向SD卡的写入速度较低所致。

表6. Pi基准测试用于计算数字 π

	树莓派2 CTIT	树莓派2 CTIT	树莓派2 CTIT
容器	8	8	14	-	-
Maps	6996	1	12975	9	12
总时间（秒）		981	9	75	32
平均映射（秒）	976
平均混洗（秒）	13	978	13	3	3
平均归约（秒）	2	2	2	0	0

Pi基准测试在五节点八容器和八节点14个容器的配置下执行。该数值 π在基准测试中通过每个映射 10^9个样本进行计算。增加基准测试中的映射数或样本数可使 π的估算更加准确。从表6中的Pi基准测试结果可以看出，平均洗牌时间取决于归约器可用数据的情况。Pi基准测试生成的中间数据非常小，如果所有映射都能被分配，则洗牌时间仅需13秒，这主要是由于Hadoop中硬编码轮询间隔带来的开销时间。具有8个可用容器的运行情况显示了可用槽位少于待运行映射数量时配置的影响；相比之下，6个映射和12个映射在有足够可用节点的情况下，总持续时间取决于各个映射完成的速度。表6中的结果表明，如果有足够的容器槽位，Pi基准测试的运行时间不受映射数量的影响。因此我们可以直接比较这两个系统的结果。CTIT集群完成该基准测试耗时40秒，平均映射时间为32秒。相比之下，树莓派2集群耗时996秒完成，平均映射时间为975秒。这意味着对于此CPU密集型基准测试，CTIT集群的处理核心速度大约是树莓派2处理核心速度的30倍。

6.2 视频流基准测试

第一个基准测试通过RTMP流式传输并测试视频。Apache JMeter是一种在外部机器上运行的基准测试工具，用于测量树莓派2能够处理的流数量[3]。

Apache JMeter可用于测量HTTP捕获。因此，可以测量RTMP流，因为这些流被封装在HTTP中。启动RTMP视频流后，通过网页浏览器访问视频来经由 HTTP分析流的工作负载。该RTMP流的速率为约800千比特/秒，对应一个较小的230MB视频。以下基本公式定义了理论最大用户数：

max users = bandwidth / bit_rate_stream.

根据此公式，在100兆比特带宽下的理论最大用户数为118。通过网页浏览器访问视频的基准测试允许25个同时连接的用户通过HTTP流式传输 MPEG-4（MP4）文件。由于缓冲区和视频转换时间的影响，实际在网页浏览器中可连接的用户数少于最大用户数。

对于Synchronized Multimedia Integration Language（SMIL），使用了一种特殊的SMIL基准测试，可对单个文件的不同视频流速率进行测试。可以根据通过网络传输的数据量动态切换质量，例如在YouTube中所使用的那样。不同视频质量是通过FFmpeg使用H.264编码器从一个230 MB的源视频生成的，分别为：720p、480p、240p和120p。在Apache JMeter测试中，模拟了100个连接同时观看视频。有两种场景使用服务器端JW Player：第一种允许用户选择视频质量，第二种情况会根据可达到的最大比特率自动切换到合适的质量。在第一种情况下，用户可以选择230MB视频的120p、240p或480p版本。当使用480p版本时，会出现卡顿；而使用120p和240p版本时则未观察到卡顿。因此，当允许用户自行选择视频质量时可能会出现卡顿；但在根据最大比特率自动选择质量的情况下，则不会发生卡顿。

为了测试具有质量约束的自动可调比特流，创建了一个视频点播（VOD）基准。首先，需要启动转换器FFmpeg和nginx，以通过RTMP共享视频。打开媒体播放器VLC，用于检测VOD与RTMP流之间是否存在差异。VOD未出现视频卡顿现象。这是因为VOD能够根据流的质量调整比特流，而RTMP则不能。RTMP仅允许观看当前正在播放的视频，类似于普通电视。

7 集群在服务器机架中

要使树莓派2在企业环境中发挥作用，必须能够安装在标准的服务器机架中。数据中心的硬件经常发生故障，因此应便于访问和更换，以保持数据中心的可管理性。当前树莓派2的一个缺点是电源接口和以太网接口的位置设计：这两个接口相互垂直，使得在狭小空间内安装主板更加困难。为了保持数据中心的可管理性，本文提出了两种设计。

机架必须包含一个具有足够端口和功率的电源，以支持所有树莓派2。外壳必须包含一些风扇以产生气流。

标准数据中心机架通常包含42U的空间。根据EIA-310标准，单个U的高度为44.50毫米[14]。1U机架的内部尺寸定义为宽450毫米、高44.43毫米，深度最多为739.775毫米[15]。树莓派2的宽度为85.60毫米，深度为56毫米，高度为21毫米。它配有四个标准安装孔，可用于穿过螺丝或垫圈进行固定。

将树莓派2放置在狭小空间内的最有效方式是让电源接口朝下，这样可以从机架底部连接电源，从侧面连接以太网，从而实现对树莓派2的最便捷访问。然而，如图7所示，垂直放置的树莓派2略高于标准U高度，因此应使用更大的 1.5U 机架以确保其能够安装。也可以尝试通过倾斜树莓派2电路板使其适配 1U 机架，这种方法的效果如图7所示。但由于倾斜角度较小，树莓派2之间实际上无法实现重叠，这使得该方法的主要优势丧失。

最明显的放置电路板的方法是将它们成对堆叠，并填满机架。通过使用垫圈，堆叠的电路板可以轻松固定在机架服务器底部。这种方法的缺点是树莓派2的可访问性较差，因为需要拆下上方的树莓派2或同时拆下两个树莓派2。12个树莓派2可以在机架中并排放置，单行可容纳24块电路板。在为所有电缆和连接器预留空间的情况下，一个机架宽度内可容纳四行。加上电源，一个1U机架最多可容纳约72个树莓派2，如图8所示。

为了给所有板卡提供以太网，将需要一个2U交换机，因为1U交换机最多只能容纳 48个以太网端口。

8 结论与未来工作

本文的贡献在于构建了一个由多个树莓派2型B款（RPi2）组成的、具备可接受性能的完整功能分布式Hadoop与视频流设置，其形式为微型数据中心。提出了一种高并发、低功耗的配置方案，可容纳于小型1U标准化外形尺寸中。这种低成本配置在性能要求不高而相较于昂贵的性能集群更具优势的场景下尤为有益。针对本文所涉及的两个应用，确实实现了可接受的性能，并通过若干应用特定基准测试予以验证。此外，还在集群上执行了多项基准测试，以确保其在数据中心环境中的正常运行。网络基准测试表明，在满载情况下，两项应用均接近约94 Mbit/s的最大网络带宽，证实了其可接受的性能表现。预计在一个 1U机架中部署72台树莓派2型B款设备，可在满载时仅消耗约160瓦功耗的情况下，实现高性能的并发能力。与轻易消耗千瓦级功率的CTIT集群相比，运行较大Map/Reduce任务（如Terasort）的程序在此配置上仅慢24倍。考虑到树莓派2目前尚未针对通过USB支持千兆连接以及SD卡读取器性能进行优化，这些数据已颇具前景。在将此配置扩展至数据中心环境之前，仍需解决大量线缆带来的可管理性问题。此外，该配置还可作为廉价的微型版数据中心，用于在昂贵集群中部署应用前对现有应用进行模拟。