叢集手冊/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]