集群手册/ARM集群（德语）

ARM集群（德语）

我们解释了我们如何构建一个由 5 个香蕉派组成的简单集群，以及廉价的 ARM 计算机是否值得作为集群单元。（Jonas Gresens、Lennart Bergmann、Rafael Epplee）

项目目标

最初的目标是构建一个由单板计算机（例如树莓派）组成的可运行的集群。因此，整个项目充当基于 ARM 架构的低成本集群的可行性或实用性研究，特别是在能效和软件支持方面。这种集群的应用场景包括在真实硬件上进行小规模测试。计划使用 CoreOS 作为操作系统，使用 Docker 来组织应用程序，因为这种组合似乎可以轻松实现集群的稳定运行。最后，集群以及所有相关硬件应该在一个标准化的服务器机柜的亚克力外壳中找到位置，以便可以将其安装到工作组的集群机架中。

硬件

主板

首先，我们需要考虑选择单板 ARM 计算机。为此，我们比较了不同的主板

表 13.1：我的标题
主板	树莓派 2	BeagleBone Black	Cubieboard4	香蕉派 M2
CPU	Cortex A7	Cortex A8	Cortex A7/A15	Cortex A7
架构	ARMv7	ARMv7a	ARMv7/ARMv7	ARMv7
核心	4	1	4/4	4
时钟频率	900 MHz	1000 MHz	1300/2000 MHz	1000 MHz
RAM	1 GiB DDR2	512 MiB DDR3	2 GiB DDR3	1 GiB DDR3
网络	最高 100 Mbit/s	最高 100 Mbit/s	最高 1000 Mbit/s	最高 1000 Mbit/s
成本	40 欧元	55 欧元	100 欧元	60 欧元

Cubieboard4 以 4 个 2 GHz 内核、2 GiB DDR3 RAM 和千兆以太网而闻名，毫无疑问是最强大的四个。价格 100 欧元对于这种性能来说完全合理，但对于我们的项目来说有点高，因此 Cubieboard4 遗憾地被淘汰了。BeagleBone Black 情况不同，价格仅为 55.00 欧元，非常合适，但遗憾的是，性能方面无法与另外两个剩余的主板相媲美。只有一个核心和 512 MB RAM，它明显落后。树莓派 2（B 型）虽然比香蕉派 M2 价格便宜，但它只有 DDR2 而不是 DDR3 RAM，时钟频率也低 100 MHz。最终，香蕉派 M2 的更高网络吞吐量成为决定性因素，它能够提供 1000 Mbit/s。我们选择了五个香蕉派，四个计算节点和一个头节点。

其他组件

SD 卡 - 由于集群的大多数必要组件都应该安装在头节点上，我们为它准备了一张 32GB 微型 SD 卡，而对于节点来说，它们实际上只进行计算，不需要安装太多东西，我们准备了四张 8 GB 卡。
交换机 - 我们选择了一个 D-Link DGS-10008D 交换机，决定因素是千兆 LAN 以及 8 个端口，这样所有计算节点 + 头节点都可以同时连接到交换机，交换机也可以连接到互联网。
电源 - 香蕉派在峰值性能时功耗不应超过 5 瓦，因此，在电源方面，我们选择了一个来自 Logilink 的 USB 端口，它可以提供 50 瓦的功率并具有 6 个 USB 接口。这样，在项目进行过程中，我们在能耗方面没有遇到任何问题。
外壳 - 我们的集群还没有包含所有硬件的外壳，但有一个 3D 打印的外壳来容纳香蕉派，这样它们就不会散乱地摆放。该外壳最初是为树莓派设计的，据制造商称，香蕉派的尺寸应该与树莓派相同。但我们发现事实并非如此，香蕉派更大一些。因此，外壳必须手动调整。香蕉派现在可以放进去，但不像树莓派那样牢固地固定。

系统架构

操作系统

我们的主要目标之一是尽可能简化新的计算节点的连接。此外，集群应该为大量应用程序提供服务。对于这些要求，CoreOS 非常合适

通过etcd 进行分布式、自动配置管理（包括 IP 地址分配）
通过容器（rkt）为每个应用程序提供具有独立依赖项的隔离环境
像 Slurm 一样的应用程序管理通过fleet

遗憾的是，我们很快发现，ARM 架构（目前）尚不支持 CoreOS。因此，我们放弃了 CoreOS，决定在操作系统之外的层面上寻找解决方案来满足我们的需求。现在，香蕉派上运行的是 Raspbian 发行版，可以在香蕉派官方网站上找到。^[1]

布线

集群的构建非常简单。5 个香蕉派，包括头节点和计算节点，直接连接到交换机。从交换机到周围网络有一条网络线。USB 端口通过 6 个输出提供电源，其中 5 个为香蕉派供电，第 6 个连接到交换机。

网络

正如上一节所述，我们集群的拓扑结构有些不寻常。在常见的集群中，主节点通过一个接口连接到外部网络，通过另一个接口连接到交换机，进而连接到其他计算节点。这意味着所有来自计算节点的外部通信都必须经过主节点。这种拓扑结构通常用于建立计算节点之间的本地网络，并阻止计算节点直接与外部网络通信。在这种情况下，主节点通过 DHCP 为计算节点分配本地 IP 地址。这种方法简化了计算节点的管理和对集群的访问控制。然而，由于香蕉派只有一个网络接口，因此我们的集群采用了略微修改的拓扑结构，如图所示。所有节点都通过交换机连接到外部网络。主节点没有两个真实的网络接口，而是使用一个虚拟接口来表示本地网络连接。这种设置虽然可以正常工作，但它依赖于计算节点不会通过直接连接从外部网络的另一个 DHCP 服务器获取 IP 地址。为了防止这种情况发生，我们在外部 DHCP 服务器的黑名单中列出了所有计算节点，使它们不被识别。我们使用 dnsmasq 作为主节点上的 DHCP 服务器，在它的配置文件中，每个计算节点都通过 dhcp-host 选项使用 MAC 地址与固定的 IP 地址绑定。

NFS

由于我们希望尽可能地将所有数据集中存储在主节点上，因此我们使用 NFS 来通过网络将这些数据作为 POSIX 兼容的文件系统提供给计算节点。

主节点上运行着 NFS 服务器，它提供 /srv 和 /home 目录。
每个计算节点上都运行着 NFS 客户端，因此可以使用 fstab 将主节点上的 home 目录挂载到计算节点上，并让计算节点与主节点上的黄金镜像同步其本地软件包。

# /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5).
#
/srv *(rw,sync,no_subtree_check,no_root_squash)
/home *(rw,sync,no_subtree_check)
proc            /proc
/dev/mmcblk0p1  /boot
/dev/mmcblk0p2  /
proc    defaults          0       0
vfat    defaults          0       2
ext4    defaults,noatime  0       1
bpi-head:/home
 -&gt; async,rw,relatime,rsize=1048576,
wsize=1048576,proto=tcp,intr,nfsvers=3

黄金镜像

集群由多个独立的计算机组成，因此比单个系统更难管理。为了尽可能简化管理，所有计算节点尽可能使用相同的硬件，并且所有计算节点的软件（包括操作系统）都集中存储并在网络上提供。存储在主节点上的系统镜像被称为“黄金镜像”，它代表了所有计算节点的共同当前状态。通过黄金镜像，实际上只需要管理两个不同的系统，这大大提高了集群设置的可扩展性，因为软件分发和配置的成本保持不变。大多数商用集群的计算节点通过 PXE 直接启动网络上提供的黄金镜像。然而，香蕉派无法通过 PXE 在网络上启动，因为它们的 BIOS 配置为使用 SD 卡上的引导加载程序，因此我们不得不绕道而行。

每个计算节点的 SD 卡都包含一个完整的可运行系统，它会在开机时启动。
SD 卡上的所有数据都来自黄金镜像。安装的唯一区别在于它们的主机名。
我们不会在重启时直接分发黄金镜像的更改，而是通过脚本半自动地将本地安装与黄金镜像同步。
还可以使用脚本将新计算节点的 SD 卡刷写为黄金镜像的当前状态，使集群易于扩展。

脚本

以下是我们开发的三个用于管理和使用黄金镜像的脚本。

create-local-installation.sh

为新/损坏的节点创建全新的当前黄金镜像安装。
在具有 SD 卡插槽的额外设备（例如笔记本电脑）上执行。
功能：创建新的分区表，创建文件系统，复制引导加载程序，使用 rsync 通过 NFS 从主节点复制黄金镜像的内容。

update-local-installation.sh

更新已安装节点上的本地安装。
在正在运行的计算节点上执行。
功能：使用 rsync 通过 NFS 从黄金镜像复制所有修改后的新文件。

start-chroot.sh

用于通过 chroot 环境管理黄金镜像的包装器脚本。
在主节点上执行，一次只能运行一个实例。
功能：挂载所有必要的分区，为用户在 chroot 中启动 bash。

容器

尽管我们决定不使用 CoreOS，但我们仍然很喜欢通过容器进行应用程序隔离的想法。与虚拟机相比，容器带来的性能损失更少，这在我们原本就很低的香蕉派性能上特别有用。

Docker

由于 Docker 目前是最受欢迎的容器实现，因此我们从这里开始进行安装尝试。Docker 使用了一些 Linux 内核的新功能，这些功能在 Banana Pi 的官方 Raspbian 发行版中并不包含。优秀的 ARM2 架构 Arch Linux 发行版可以开箱即用地支持这些功能，但 DKRZ 的其余集群完全运行在基于 Debian 的系统上，因此我们决定在我们的集群中也使用这样的系统，以简化维护。在 Raspbian 上也应该可以运行 Docker，但需要手动编译一个更新的内核。原则上这不是问题 - 遗憾的是，香蕉派需要一个来自制造商 LeMaker3 的专用内核。LeMaker 最近才发布了源代码^[2]，版本仍然是 3.4，而 Docker 至少需要 3.10 版本。经过大量的研究和一次在香蕉派上编译最新 Linux 内核的失败尝试后，我们最终放弃了 CoreOS 和 Docker。

rkt

rkt 是 CoreOS 团队开发的另一种容器实现。rkt 没有正式支持 ARM 架构 - 但这并没有阻止我们自己编译这个项目。结果发现，rkt 也不（还）支持 32 位系统，这意味着它无法在香蕉派上的 ARMv7 处理器上运行。

systemd-nspawn

在我们尝试了 Docker 和 rkt 之后，我们把最后的希望寄托在了 systemd 初始化系统上。它有一段时间提供了一个名为 systemd-nspawn 的最小容器实现。^[3]它最初是为了快速测试 systemd 本身而设计的，现在它包含了最基本的功能，已经完全可以满足我们的需求。在项目快结束时，我们开始在香蕉派上测试安装 systemd（我们使用的 Raspbian 版本仍然使用传统的初始化脚本）。然而，每次安装都会导致香蕉派无法启动，Raspbian 安装变得无法使用，需要重新刷写 SD 卡，这非常耗时。在项目的这个阶段，我们已经没有足够的时间来修复这个错误了。

已安装软件

在我们的集群最终运行起来之后，我们想使用 HPL 基准^[4] 测试香蕉派的实际性能。HPL 需要 MPI 和 BLAS 库，因此我们也必须安装它们。

MPI

“消息传递接口”标准（MPI）描述了单个并行进程之间交换消息的方式，这些进程共同解决一个问题。MPI 没有定义具体的协议或实现，而是描述了不同类型通信操作的语义及其 API，因此实际使用该标准需要 MPI 实现。最初，我们想使用 OpenMPI 或 MVAPICH2，但由于各种原因，它们都没有正常工作。

OpenMPI 无法完全编译，因为它包含了在 ARM 上无法运行的汇编代码，而且移植工作可能不值得。
MVAPICH2 在某个系统更新之前一直正常工作，但之后就找不到 “libpmi” 头文件了。

出于无奈，我们决定使用发行版包源中预编译的 MPICH2，因为我们认为，对于我们的集群而言，MPI 实现的选择对性能的影响很小，如果有的话也微乎其微。

OpenBLAS

“基本线性代数子程序”（BLAS）是一组用于基本向量和矩阵运算的例程。我们使用的 OpenBLAS^[5]是一个经过优化的 BLAS 库，需要在 Banana Pi 上重新编译才能使用。在 Pi 上编译 OpenBLAS 大约需要 1 个小时。我们通过不使用线程的版本（使用 _USE THREADING=0_）获得了最佳测试结果。

HPL

“高性能 Linpack”基准测试是一个用于测量（分布式）计算机系统浮点计算性能的程序。HPL 通过求解一个密集的 $n*n$ -线性方程组 $(Ax=B)$ 来测量系统的 GFLOPS 性能。与 OpenBLAS 一样，我们也需要为我们的系统专门编译 HPL，以便它能够尽可能高效地适应可用的硬件。

测试结果

HPL 有四个主要参数

$N$ 表示矩阵的高度和宽度，问题随着 $N$ 的平方而增长
$NB$ 是进程之间通信的消息大小
$P$ 和 $Q$ 描述了矩阵在进程网格上的分布

四条曲线显示了使用不同数量的计算节点和问题规模时测量的性能之间的关系：考虑到使用的硬件，弱加速（每个核心相同的问题规模）令人惊讶地好（使用 3 个计算节点时大约为 2.8）。然而，强加速（在核心数量增加的情况下保持固定的问题规模）的发展表明，所使用的商用交换机不适合 HPC，因为随着计算节点数量的增加，性能会下降。不幸的是，由于技术问题，我们无法测量在 4 个节点上使用更大的 $N$ 的更多 HPL 运行的性能数据。

bpi4 在满负荷运行几分钟后就关闭了。
bpi-head 不能用作替代品，因为它出现了相同的症状。

Pi 在高温下不稳定，这对实际密集使用的 Pi 集群来说是一个大问题。

SLURM

SLURM^[6] 代表“用于资源管理的简单 Linux 实用程序”，是一个开源工作负载管理器，在世界各地的许多集群和超级计算机上使用。SLURM 用于将单个作业尽可能高效地分配到集群的节点上。虽然我们付出了很多努力，但在项目进行过程中遇到的复杂情况远超我们的预期，因此，我们最终没有时间将 SLURM 完全集成到集群中。

现状

目前状态

目前，我们拥有一个虽然不完美但能正常工作的集群。我们使用了一个黄金映像，它可以轻松地将所有节点更新到相同状态，并且可以通过它轻松地扩展集群。网络连接仍然不理想，因为计算节点在某些情况下会从互联网而不是从头节点获取 IP 地址，因此无法从头节点访问它们。积极的一面是，该集群可以运行可用的 MPI 库和可运行的 HPL，因此可以进行详细的性能测试。Banana Pi 位于专门为其设计的 3D 打印机箱中，不幸的是这个机箱有点小。

进一步的工作

解决网络问题的方法是使用静态 IP 地址，这样就不会有节点自行搜索 IP 地址了。为了尽可能完全地集成到 WR 集群中，只需要添加一些软件包。

使用 SLURM，可以使用 WR 集群中常用的 UI 来使用该集群。
WR 集群使用 LDAP 来访问用户的 home 目录，因此在 Pi 集群中也必须使用它，以避免每个用户多个 home 目录的问题。
虽然监控工具 Ganglia 通常是可选的，但也应该存在，因为它与 SLURM 一样是常用的 UI。

此外，还需要一个有机玻璃机箱，用于安装该集群，其中可以容纳 ARM 计算机、所有配件、一些 LED 和风扇。

结论

Banana Pi

在积累了一些使用“Banana Pi”模型的经验后，我们想在此简要概述该模型的优缺点。由于我们是从HPC的角度来进行这个项目的，因此硬件方面在我们规划中尤为重要。特别是，Banana Pi通过千兆以太网承诺在计算节点之间实现无缝通信，即使是HPC中常见的庞大数据量也不例外。事实上，我们在基准测试中也没有发现任何与通信负载有关的问题。此外，我们与Raspberry Pi 2 Model B的比较发现，性能差异仅约300 MFLOPS。然而，我们很快意识到，Banana Pi周围相对较小的社区和生态系统带来了不少问题。首先，我们发现实际上有不同的制造商声称自己生产“官方”的Banana Pi。每个制造商都提供了略有不同的文档，其中许多地方缺失。用于Raspberry Pi的SD卡镜像在Banana Pi上无法使用；目前尚不清楚是否存在一个真正官方的网站提供官方的Linux发行版。很长一段时间，Banana Pi的修改版Linux内核并没有开源；在社区的强烈要求下，代码最终得以发布。^[7] 不幸的是，该内核的最新稳定版本仍停留在3.4版。这导致了其他问题，例如无法为Docker安装编译自定义内核。

其他优缺点

我们想通过这个项目回答的一个问题是，Banana Pi的能效，特别是在高性能计算的背景下如何。不幸的是，ARM集群在这方面令人失望。如果我们比较保守地^[8] 假设功耗为5瓦特（满负荷），那么根据我们的基准测试，这相当于 $1/4$ GFLOPS/瓦特。根据TOP500列表，目前的技术水平约为2 GFLOPS/瓦特。^[9] 尽管价格低廉，但由Banana Pi组成的集群甚至不适合小规模测试程序，因为ARM CPU不支持x86(64) CPU的所有指令集，因此会导致编译问题——使用虚拟化集群（例如通过Vagrant）要方便得多。总的来说，我们可以说，根据我们的经验，ARM集群的主要价值在于，它能够在一个尽可能真实的场景中练习集群的搭建和安装。用于管理不同节点的脚本运行良好，可以在任何使用多个Pi类计算机的项目中无缝使用，以便于管理。

附录

create-local-installation.sh

#!/bin/bash
# JG/RE/LB 2015

if [[ $# -ne 4 ]]; then
        echo &quot;Usage: $0 bpi_head_ip dist device hostname&quot;
        exit 1
fi

if [ &quot;$USER&quot; != &quot;root&quot; ]; then
        echo &quot;MUST be run as root! Try 'sudo $0 ...'&quot;
    exit 1 
fi

BPI_HEAD_IP=&quot;$1&quot;
DIST=&quot;$2&quot;
DEV=&quot;$3&quot;
HOSTNAME=&quot;$4&quot;

# sd card formatting
echo &quot;Partitioning $DEV&quot;
parted -s $DEV mklabel msdos || exit 1
parted -s $DEV unit s mkpart primary fat32 8192s 122879s || exit 1
parted -s -- $DEV unit s mkpart primary 122880s -1s || exit 1
echo &quot;Report:&quot;
fdisk -l $DEV

echo &quot;Filesystems:&quot;
mkfs.vfat -F 32 ${DEV}p1 || exit 1
mkfs.ext4 ${DEV}p2 || exit 1

echo &quot;Bootloader&quot;
dd if=&quot;$(dirname $0)&quot;/bootloader_ohne_table.img count=2048 of=/dev/mmcblk0 seek=8 bs=1024

# mounting
mkdir /tmp/target/{b,r}oot -p
mount ${DEV}p1 /tmp/target/boot
mount ${DEV}p2 /tmp/target/root

# rsync magic
rsync -axzh --stats root@$BPI_HEAD_IP:/srv/nodes/$DIST/boot/ /tmp/target/boot || exit 1
rsync -axzh --stats root@$BPI_HEAD_IP:/srv/nodes/$DIST/root/ /tmp/target/root || exit 1

echo $HOSTNAME &gt; /tmp/target/root/etc/hostname

# Clean up
umount /tmp/target/*

update-local-installation.sh

#!/bin/bash
# JG/RE/LB 2015

test -z &quot;$1&quot; &amp;&amp; echo &quot;Please specify a distribution.&quot; &amp;&amp; exit 1

DIST=&quot;$1&quot;

#####
# mounting the source, this could be done outside of this script to use arbitrary sources.
mkdir -p /tmp/source_root
umount /tmp/source_root
mount -o ro,nfsvers=3 bpi-head:/srv/nodes/$DIST/root /tmp/source_root || exit 1

mkdir -p /tmp/source_boot
umount /tmp/source_boot
mount -o ro,nfsvers=3 bpi-head:/srv/nodes/$DIST/boot /tmp/source_boot || exit 1

####
# Sanity checks to check if the ip is 10.0.0.X where X below 100, then the script is allowed to run.

IP=$(ip addr show dev eth0 |grep &quot;inet &quot; |sed &quot;s/.* inet \([0-9.]*\)\/.*/\1/&quot;)

if [[ ${#IP} -lt 8 ]] ; then
        echo &quot;Could not determine IP!&quot;
        exit 1
fi

LAST=${IP#10.0.0.}
if [[ $IP == $LAST || $LAST -gt 99 ]] ; then
        echo &quot;Invalid host with IP: $IP&quot;
        echo &quot;I won't run the script on this machine!&quot;
        exit 1
fi

rsync -axzh --delete --exclude=&quot;/home&quot; --ignore-errors --progress /tmp/source_root/ /
rsync -axzh --delete --exclude=&quot;/home&quot; --ignore-errors --progress /tmp/source_boot/boot

hostname &gt; /etc/hostname

# cleanup and restoring the previous state
umount /tmp/source_root
umount /tmp/source_boot

start-chroot.sh

#!/bin/bash
# JG/RE/LB 2015

(
flock -n 200
CHROOTDIR=&quot;/srv/nodes/default/root&quot;

usage ()
{
    echo &quot;USAGE: ${0} [-h|--help] [&lt;DIR&gt;]&quot;
    echo
    echo &quot;-h&quot;
    echo &quot;  --help     print this message&quot;
    echo &quot;&lt;DIR&gt;  directory with common file system&quot;
    echo
}

if [[ &quot;$1&quot; != &quot;&quot; ]] ; then
        CHROOTDIR=&quot;/srv/nodes/${1}/root&quot;
fi
[ -d &quot;${CHROOTDIR}&quot; ] || \
        { echo &quot;Directory for chroot ${CHROOTDIR} not found!&quot; &amp;&amp; exit 1; }

echo &quot;Starting chroot environment in ${CHROOTDIR}&quot;

# mount dev
[ -d ${CHROOTDIR}/dev ] &amp;&amp;
mount -o bind /dev ${CHROOTDIR}/dev

# mount dev/pts
[ -d ${CHROOTDIR}/dev/pts ] &amp;&amp;
mount -o bind /dev/pts ${CHROOTDIR}/dev/pts

# mount /run for resolv.conf
[ -d ${CHROOTDIR}/run ] &amp;&amp;
mount -o bind /run ${CHROOTDIR}/run

# mount boot 'partition'
mount -o bind ${CHROOTDIR}/../boot ${CHROOTDIR}/boot

# mount proc
[ -d ${CHROOTDIR}/proc ] &amp;&amp;
mount -t proc proc_chroot ${CHROOTDIR}/proc

# mount sysfs
[ -d ${CHROOTDIR}/sys ] &amp;&amp;
mount -t sysfs sysfs_chroot ${CHROOTDIR}/sys

#JK:
#sed -i &quot;s/10.0.0.250/129.206.100.126/&quot; ${CHROOTDIR}/etc/resolv.conf if [ -f ${CHROOTDIR}/usr/sbin/invoke-rc.d ]
then
        echo '#!/bin/sh' &gt; ${CHROOTDIR}/usr/sbin/policy-rc.d
        echo 'exit 101' &gt;&gt; ${CHROOTDIR}/usr/sbin/policy-rc.d
        chmod +x ${CHROOTDIR}/usr/sbin/policy-rc.d
fi

/usr/sbin/chroot ${CHROOTDIR} /bin/bash

# YOU ARE IN CHROOT HERE AND THIS SCRIPT IS STOPPED UNTIL YOU QUIT BASH!

echo &quot;Closing chroot environment!&quot;

[ -f ${CHROOTDIR}/usr/sbin/policy-rc.d ] &amp;&amp;
rm ${CHROOTDIR}/usr/sbin/policy-rc.d

# umount sysfs
mountpoint -q ${CHROOTDIR}/sys &amp;&amp; umount sysfs_chroot

# umount proc
mountpoint -q ${CHROOTDIR}/proc &amp;&amp; umount proc_chroot

# umount boot 'partition'
# 'mountpoint' doesn't work here for some reason umount ${CHROOTDIR}/boot

# umount dev/pts
mountpoint -q ${CHROOTDIR}/dev/pts &amp;&amp; umount ${CHROOTDIR}/dev/pts

# umount /run
mountpoint -q ${CHROOTDIR}/run &amp;&amp; umount ${CHROOTDIR}/run

# umount dev/pts
mountpoint -q ${CHROOTDIR}/dev &amp;&amp; umount ${CHROOTDIR}/dev
) 200&gt;/var/lock/start-chroot.sh

SLURM配置

ControlMachine=bpi-head ControlAddr=10.0.0.250
#
MailProg=/usr/bin/mail
MpiDefault=none
#MpiParams=ports=#-# 
ProctrackType=proctrack/cgroup
ReturnToService=1 
SlurmctldPidFile=/var/run/slurmctld.pid 
#SlurmctldPort=6817 
SlurmdPidFile=/var/run/slurmd.pid 
#SlurmdPort=6818 
SlurmdSpoolDir=/var/spool/slurmd 
SlurmUser=slurm
#SlurmdUser=root
StateSaveLocation=/var/spool/slurm 
SwitchType=switch/none 
TaskPlugin=task/none
#
# TIMERS
#KillWait=30
#MinJobAge=300
#SlurmctldTimeout=120
#SlurmdTimeout=300
#
# SCHEDULING
FastSchedule=1
SchedulerType=sched/backfill
#SchedulerPort=7321
SelectType=select/linear
#
# LOGGING AND ACCOUNTING
AccountingStorageType=accounting_storage/none
ClusterName=pi-cluster
#JobAcctGatherFrequency=30
JobAcctGatherType=jobacct_gather/none
#SlurmctldDebug=3
SlurmctldLogFile=/etc/slurm-llnl/slurmctldLog.log
#SlurmdDebug=3
SlurmdLogFile=/etc/slurm-llnl/slurmdLog.log
#
# COMPUTE NODES
NodeName=bpi[1-4] CPUs=4 State=UNKNOWN
PartitionName=debug Nodes=bpi[1-4] Default=YES MaxTime=INFINITE State=UP

参考资料

[1] ttp://bananapi.com/

[2] ttps://github.com/LeMaker/linux-sunxi

[3] ttp://www.freedesktop.org/software/systemd/man/systemd-nspawn.html

[4] ttp://www.netlib.org/benchmark/hpl/

[5] ttp://www.openblas.net/

[6] ttp://slurm.schedmd.com/

[7] ttps://github.com/LeMaker/linux-sunxi

[8] ttp://raspberrypi.stackexchange.com/questions/5033/how-much-energy-does-the-raspberry-pi-consume-in-a-day

[9] ttps://en.wikipedia.org/wiki/Performance_per_watt

[2]

[3]

[4]

[5]

[6]