简介本资源是一份面向高校计算机专业学生与高性能计算初学者的Ubuntu虚拟机MPI集群搭建实验指南聚焦并行计算环境配置核心技能。文档系统讲解在VMware虚拟机中基于Ubuntu 14.04/12.04双节点部署MPICH集群的完整流程涵盖SSH无密码登录、NFS网络文件共享、MPICH编译安装、MPI程序编译运行及HA高可用基础原理适用于课程实验、科研入门与工程实践预演。资源为单个PDF文件大小2.08MB内容结构清晰含实验目的、环境要求、原理详解MPI/NFS/SSH/GCC、拓扑图示、分步配置说明及测试验证方法便于离线研读与实操对照。已有301人学习下载特别适合需要掌握Linux集群基础架构、理解并行计算底层协同机制的学习者提供从理论到部署的一站式技术参考。1. 为什么在 VMware 里用 Ubuntu 14.04 搭两台虚拟机跑 MPI比直接装 Docker 或 WSL 更贴近真实 HPC 场景这不是一个“跑通 hello world 就算成功”的玩具实验。当你在 VMware 中手动配置 node1master和 node2slave强制自己处理192.168.22.132/24和192.168.22.133/24的静态 IP、手写/etc/hosts映射、逐行敲ssh-keygen -t rsa并scp -r ~/.ssh node2:你实际复现的是 2014–2017 年高校高性能计算实验室最典型的入门路径——那个还没有 Kubernetes 编排、没有 Slurm 自动调度、连mpirun --hostfile都要靠machinefile手动列节点的年代。MPICH 3.1 不是过时而是“可解释性”极强它的 configure 参数如--disable-f77 --disable-fc直白暴露 Fortran 支持与编译器绑定关系NFS 共享目录/home/abc/cluster不是抽象的 volume而是你能ls -l看到属主为abc:abc、权限为drwxr-xr-x的真实路径SSH 无密码登录失败时ssh -v node2输出里明明白白告诉你卡在debug1: Trying private key: /home/abc/.ssh/id_rsa还是debug1: Next authentication method: password。这种“每一步都裸露在 shell 里”的搭建方式对理解现代分布式系统底层通信模型如 MPI 进程如何通过 SSH 启动远端mpiexec子进程、文件系统一致性NFSsync模式下 write() 调用何时返回、甚至 Linux 权限继承no_root_squash如何让 root 用户在挂载点获得真实 root 权限有不可替代的价值。它不面向生产部署但面向“知道为什么不能只apt install mpich就完事”的人。2. 从零构建双节点通信基座SSH 信任链与 NFS 共享路径的硬核对齐2.1 SSH 公钥认证必须跨节点双向打通且权限控制精确到字节MPI 启动多节点任务时master 节点会通过ssh node2 mpiexec ...方式远程执行 slave 上的命令。这意味着node1 必须能无密码 ssh 到 node2同时 node2 也必须能无密码 ssh 回 node1——这是很多初学者忽略的关键点。实验文档中“将~/.ssh复制到所有节点”的做法存在隐患若直接scp -r ~/.ssh node2:node2 上的authorized_keys文件会包含 node1 的公钥但 node2 自身的公钥并未写入 node1 的authorized_keys。正确做法是分三步完成双向认证2.1.1 在每个节点独立生成密钥对并注入本地 authorized_keys# 在 node1 上执行注意不是 root是普通用户 abc abcnode1:~$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N abcnode1:~$ cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys abcnode1:~$ chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys # 在 node2 上执行完全相同的命令 abcnode2:~$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N abcnode2:~$ cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys abcnode2:~$ chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys提示-b 4096指定密钥长度为 4096 位比默认 2048 更安全-N 显式设置空 passphrase避免交互式输入chmod 600是硬性要求OpenSSH 服务端会拒绝读取权限过宽的authorized_keys文件如644日志中报错为Authentication refused: bad ownership or modes for directory /home/abc/.ssh。2.1.2 交叉分发公钥实现双向信任# node1 将自己的公钥追加到 node2 的 authorized_keys abcnode1:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub abcnode2 # node2 将自己的公钥追加到 node1 的 authorized_keys abcnode2:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub abcnode1ssh-copy-id会自动处理远程主机上~/.ssh目录创建、权限设置及authorized_keys追加比手动scp更可靠。验证命令必须在两个方向执行# 在 node1 上测试能否免密登录 node2 abcnode1:~$ ssh -o ConnectTimeout5 abcnode2 echo node2 OK # 在 node2 上测试能否免密登录 node1 abcnode2:~$ ssh -o ConnectTimeout5 abcnode1 echo node1 OK若任一方向失败检查/var/log/auth.log中sshd日志常见错误包括User abc from node1 not allowed because not listed in AllowUsers需在/etc/ssh/sshd_config中添加AllowUsers abc并重启sudo systemctl restart ssh或 SELinux 上下文异常Ubuntu 14.04 默认未启用 SELinux此条仅作知识延伸。2.2 NFS 共享目录必须满足“路径一致 权限穿透 同步写入”三重约束MPI 程序编译产物如cpi可执行文件和运行时工作目录需在所有节点以完全相同路径访问。若 node1 上mpicc编译出的二进制放在/home/abc/cluster/mpich-3.1/examples/cpi则 node2 必须能通过同一路径执行它而非/mnt/nfs/cluster/mpich-3.1/examples/cpi。这要求 NFS 服务端导出路径与客户端挂载点路径严格对齐。2.2.1 服务端/etc/exports配置的语义陷阱解析实验文档中给出的两种写法# 写法 A显式指定每个节点 /home/abc/cluster node1(rw,sync,no_root_squash) /home/abc/cluster node2(rw,sync,no_root_squash) # 写法 B通配符放行 /home/abc/cluster *(rw,sync,no_root_squash)必须选择写法 A。原因在于no_root_squash的作用对象是“连接到该导出路径的客户端 root 用户”。若使用*任何能访问该网段的机器包括未授权的测试机都可获得 root 权限挂载严重违反最小权限原则。而写法 A 明确限定只有node1和node2的 IP 可挂载且no_root_squash保证当abc用户在 node1 上以sudo mount方式挂载后其在 node2 上对共享目录的写操作不会被映射为nobody用户。2.2.2 客户端挂载命令必须带nolock选项规避锁竞争Ubuntu 14.04 的 NFS 客户端默认启用lockd网络锁守护进程但在双节点无专用 NIS/LDAP 认证的实验环境中lockd会因无法同步锁状态导致cp或make命令卡死。正确挂载命令为# 在 node2 上执行假设 node1 IP 为 192.168.22.132 abcnode2:~$ sudo mkdir -p /home/abc/cluster abcnode2:~$ sudo mount -t nfs -o rw,hard,intr,nolock,vers3,tcp 192.168.22.132:/home/abc/cluster /home/abc/cluster参数说明nolock禁用 NFS 文件锁避免lockd进程争用vers3强制使用 NFSv3 协议Ubuntu 14.04 对 NFSv4 支持不稳定tcp使用 TCP 传输比 UDP 更可靠适合局域网hard,intr硬挂载断网后阻塞而非报错intr允许 CtrlC 中断挂起的 I/O。验证挂载效果# 查看挂载信息确认 type 为 nfs abcnode2:~$ mount | grep cluster # 测试写入在 node1 创建文件node2 应实时可见 abcnode1:~$ echo test from node1 /home/abc/cluster/test.txt abcnode2:~$ cat /home/abc/cluster/test.txt # 应输出 test from node13. MPICH 3.1 源码编译全流程从 GCC 版本校验到 PATH 环境变量的精准注入3.1 编译前必须验证 GCC/G 兼容性否则 configure 阶段静默失败MPICH 3.1 要求 GCC 4.4而 Ubuntu 14.04 默认 GCC 版本为 4.8.2表面兼容但存在隐性风险若系统中存在多个 GCC 版本如通过update-alternatives切换./configure可能调用错误版本导致后续make报错undefined reference to pthread_create。必须显式锁定编译器路径3.1.1 强制指定 GCC/G 路径并验证 ABI 兼容性# 检查当前默认编译器版本 abcnode1:~$ gcc --version # 应输出 gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4 abcnode1:~$ g --version # 应输出 g (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4 # 进入 MPICH 源码目录确保已解压 abcnode1:~/cluster$ cd mpich-3.1 # 执行 configure 时显式传入编译器绝对路径 abcnode1:~/cluster/mpich-3.1$ ./configure \ --prefix/home/abc/cluster/mpich3.1 \ --disable-f77 \ --disable-fc \ CC/usr/bin/gcc \ CXX/usr/bin/g \ F77 \ FC注意CC和CXX必须用绝对路径/usr/bin/gcc不能用gcc别名F77和FC是空字符串赋值而非省略否则 configure 会尝试搜索 Fortran 编译器并报错。3.1.2 configure 输出关键字段解读与失败诊断成功 configure 后终端末尾会显示... MPI C compiler: /usr/bin/gcc MPI C compiler: /usr/bin/g MPI Fortran compiler: (none) ... Build process: make (GNU Make) ...若出现MPI Fortran compiler: /usr/bin/gfortran说明--disable-f77 --disable-fc未生效需检查命令是否漏掉--或拼写错误。若报错configure: error: C compiler cannot create executables则CC路径错误或gcc未安装执行sudo apt-get install build-essential补全。3.2 make install 后的 PATH 注入必须作用于所有 Shell 会话且优先级高于系统路径MPICH 安装后mpiexec、mpicc等命令位于/home/abc/cluster/mpich3.1/bin。若仅修改~/.bashrc新打开的终端会加载但已存在的tmux会话或cron任务不会生效。必须确保环境变量在所有上下文中生效。3.2.1 全局 PATH 注入的三层保障机制# 步骤 1修改用户级配置覆盖交互式 Shell abcnode1:~$ echo export PATH/home/abc/cluster/mpich3.1/bin:$PATH ~/.bashrc abcnode1:~$ echo export LD_LIBRARY_PATH/home/abc/cluster/mpich3.1/lib:$LD_LIBRARY_PATH ~/.bashrc # 步骤 2修改系统级配置覆盖非登录 Shell如 cron abcnode1:~$ echo PATH/home/abc/cluster/mpich3.1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin | sudo tee /etc/environment # 步骤 3验证所有路径是否生效 abcnode1:~$ source ~/.bashrc abcnode1:~$ echo $PATH | grep mpich3.1 # 应输出含 /home/abc/cluster/mpich3.1/bin 的字符串 abcnode1:~$ which mpiexec # 应输出 /home/abc/cluster/mpich3.1/bin/mpiexec abcnode1:~$ mpiexec --version # 应输出 MPICH version 3.1提示LD_LIBRARY_PATH必须同步设置否则运行mpiexec时可能报错libmpi.so.12: cannot open shared object file。Ubuntu 14.04 的动态链接器缓存需手动更新sudo ldconfig -v | grep mpich。4. machinefile 驱动的跨节点 MPI 执行从单机验证到双节点协同的完整链路4.1 machinefile 文件格式必须严格遵循“每行一个主机名无空格无注释”规范machinefile是 MPICH 识别节点列表的唯一依据其格式容错性极低。实验文档中“node1”和“node2”的写法看似简单实则暗藏三个致命细节4.1.1 主机名必须与hostname命令输出及/etc/hosts解析完全一致# 在 node1 上执行 abcnode1:~$ hostname # 输出必须为 node1非 node1.local 或 192.168.22.132 abcnode1:~$ cat /etc/hosts | grep node1 # 应含 192.168.22.132 node1 # 在 node2 上执行 abcnode2:~$ hostname # 输出必须为 node2 abcnode2:~$ cat /etc/hosts | grep node2 # 应含 192.168.22.133 node2若hostname输出为ubuntu则machinefile必须写ubuntu否则mpiexec会报错Unable to find host node1 in the hostfile。4.1.2 双节点执行必须使用-machinefile而非-host参数MPICH 3.1 的mpiexec不支持-host node1,node2这类逗号分隔语法必须依赖外部文件# 创建标准 machinefile注意文件名无扩展名内容无空行 abcnode1:~$ echo -e node1\nnode2 ~/machinefile # 验证文件内容确保无 DOS 换行符 abcnode1:~$ cat -A ~/machinefile # 应输出 node1$ node2$ # 执行双节点任务启动 4 个进程node1 和 node2 各 2 个 abcnode1:~$ mpiexec -n 4 -machinefile ~/machinefile /home/abc/cluster/mpich-3.1/examples/cpi若报错mpiexec noticed that process rank 2 exited with status 127通常是cpi程序在 node2 上找不到因 NFS 挂载失败或路径不一致此时应先在 node2 上手动执行/home/abc/cluster/mpich-3.1/examples/cpi测试。4.2 进程分布验证用ps和hostname组合确认 MPI 实际调度位置仅看mpiexec返回值无法确认进程是否真正在远端节点运行。必须通过进程树和主机名交叉验证4.2.1 在 master 节点启动任务时实时监控 slave 节点进程# 终端 1在 node1 启动 MPI 任务保持运行 abcnode1:~$ mpiexec -n 4 -machinefile ~/machinefile /home/abc/cluster/mpich-3.1/examples/cpi # 终端 2在 node2 上实时观察 mpiexec 子进程 abcnode2:~$ watch -n 1 ps aux | grep mpiexec | grep -v grep正常输出应类似abc 12345 0.0 0.1 12345 6789 ? S 10:00 0:00 mpiexec -n 2 -machinefile /home/abc/machinefile ... abc 12346 0.0 0.1 23456 7890 ? S 10:00 0:00 /home/abc/cluster/mpich3.1/bin/mpiexec ...技巧watch -n 1每秒刷新一次grep -v grep过滤掉自身进程。若 node2 上无mpiexec进程说明machinefile解析失败或 SSH 信任未建立。4.2.2 在 MPI 程序内嵌入主机名打印实现逻辑级验证修改cpi.c源码位于mpich-3.1/examples/cpi.c在计算前插入#include unistd.h #include sys/utsname.h int main(int argc, char *argv[]) { int size, rank; MPI_Init(argc, argv); MPI_Comm_size(MPI_COMM_WORLD, size); MPI_Comm_rank(MPI_COMM_WORLD, rank); // 新增获取并打印当前主机名 char hostname[256]; gethostname(hostname, sizeof(hostname)); printf(Rank %d running on %s\n, rank, hostname); // 原有 cpi 计算逻辑... }重新编译并运行abcnode1:~/cluster/mpich-3.1/examples$ mpicc cpi.c -o cpi abcnode1:~$ mpiexec -n 4 -machinefile ~/machinefile ./cpi预期输出片段Rank 0 running on node1 Rank 1 running on node1 Rank 2 running on node2 Rank 3 running on node2若所有Rank都显示node1说明machinefile未生效mpiexec退化为单机模式若出现Rank X running on unknown则是gethostname()调用失败需检查/etc/hostname是否可读。5. 故障排查黄金组合SSH 详细日志、NFS 挂载状态、MPI 进程树的三维定位法5.1 当mpiexec报错 “No route to host” 时必须按 OSI 模型自底向上排查该错误表面是网络层问题但根源常在应用层配置。按以下顺序执行诊断命令每步失败即终止5.1.1 物理层验证确认虚拟网卡处于活动状态# 在 node1 和 node2 上分别执行 abcnode1:~$ ip link show | grep -A2 eth0\|ens33 # 查看网卡状态 # 正常输出应含 state UP 和 mtu 1500 abcnode1:~$ ping -c 3 192.168.22.133 # node1 ping node2 abcnode2:~$ ping -c 3 192.168.22.132 # node2 ping node1若ping失败检查 VMware 网络适配器是否设为NAT 模式非桥接或仅主机并在 VMware 虚拟网络编辑器中确认VMnet8的子网 IP 与192.168.22.0/24一致。5.1.2 传输层验证SSH 端口连通性与服务状态# 在 node1 上测试 node2 的 22 端口 abcnode1:~$ telnet 192.168.22.133 22 # 若连接拒绝检查 node2 的 SSH 服务 abcnode2:~$ sudo systemctl status ssh # Ubuntu 14.04 使用 upstart等价命令sudo service ssh status abcnode2:~$ sudo ufw status # 若防火墙开启需允许 22 端口sudo ufw allow 225.1.3 应用层验证NFS 导出列表与挂载点一致性# 在 node1服务端查看导出状态 abcnode1:~$ sudo exportfs -v # 应输出/home/abc/cluster node1(rw,wdelay,root_squash,no_subtree_check,fsid0,secsys,rw,secure,root_squash,...) # 在 node2客户端查看挂载详情 abcnode2:~$ mount | grep nfs # 应输出192.168.22.132:/home/abc/cluster on /home/abc/cluster type nfs (rw,relatime,vers3,rsize65536,wsize65536,...) # 关键检查挂载点路径是否与 MPICH 安装路径完全匹配 abcnode2:~$ ls -ld /home/abc/cluster/mpich3.1/bin # 若报错 No such file or directory则 NFS 挂载失败或路径不一致5.2 当mpiexec启动后立即退出且无输出时启用 MPICH 内置调试模式MPICH 提供--mca btl_base_verbose 100参数输出底层通信库BTL详细日志可定位到具体失败环节# 在 node1 上启用最高级别调试 abcnode1:~$ mpiexec --mca btl_base_verbose 100 -n 2 -machinefile ~/machinefile /bin/true # 观察输出中的关键线索 # - 若含 btl_tcp_endpoint_send_handler: send() failed with errno111 → TCP 连接被拒SSH 未运行 # - 若含 orte_plm_rsh_module.c: unable to exec ssh → SSH 命令路径错误检查 PATH # - 若含 unable to resolve host node2 → DNS 解析失败检查 /etc/hosts技巧将调试日志重定向到文件便于分析mpiexec --mca btl_base_verbose 100 -n 2 -machinefile ~/machinefile /bin/true 21 | tee debug.log。本文还有配套的精品资源点击获取