1. 项目概述为什么我们需要Open OnDemand如果你在高校的计算中心、研究所的IT部门或者任何需要管理高性能计算HPC集群的岗位上工作过一定对下面这个场景不陌生用户可能是研究员、学生发来一封邮件附件里是一个写好的作业脚本然后问“老师我这个任务怎么提交不上去报错了您能帮我看看吗” 你打开终端SSH登录到集群的头节点找到他的作业ID查看日志发现可能是环境变量没加载或者某个模块没挂载。一来一回半天时间就过去了用户着急你也头疼。这就是传统命令行访问HPC集群的痛点门槛高、交互不直观、资源状态不透明。用户需要学习一套复杂的Linux命令和作业调度系统如Slurm、PBS的语法才能完成最基本的计算任务提交。而Open OnDemand简称OOD的出现就是为了解决这个问题。它本质上是一个基于Web的门户将HPC集群的强大计算能力“包装”成一个可以通过浏览器访问的、直观易用的图形化界面。用户无需记忆任何命令通过点击鼠标就能完成文件管理、交互式应用启动如Jupyter Notebook、RStudio、作业提交与监控、以及远程桌面连接等几乎所有操作。我最早接触OOD是在2018年当时我们中心的管理员为了降低用户的使用门槛决定部署这套系统。部署过程本身就是一个学习的过程从最初的Apache配置、Passenger集成到与Slurm调度器的深度对接再到定制开发适合本地环境的App每一步都踩过坑也积累了不少经验。这份手册就是基于这些一线实战经验整理而成目标是为后来者提供一份从零开始到稳定上线再到日常运维的完整路线图。无论你是计划首次部署OOD的集群管理员还是想深入了解其内部机制的技术爱好者这篇文章都能给你提供直接的、可操作的参考。2. 核心架构与部署前准备2.1 Open OnDemand 的核心组件解析在动手安装之前理解OOD的架构至关重要。它不是一个单一的黑盒软件而是一个由多个松耦合组件构成的生态系统。知其然更要知其所以然这样在遇到问题时你才知道该从哪里入手排查。1. Web服务器与应用服务器NGINX Passenger这是OOD的门面和处理核心。默认情况下OOD使用NGINX作为Web服务器负责处理HTTP/HTTPS请求。而Passenger原名mod_rails则是一个应用服务器它紧密集成在NGINX中专门用于高效、稳定地运行Ruby on Rails应用OOD的前端主程序就是用Rails写的。为什么选这个组合因为Passenger在进程管理、资源隔离和自动重启方面做得非常出色特别适合生产环境。它确保了当用户访问门户时背后的Rails应用能快速响应且保持稳定。2. 门户应用Portal App这是用户登录后看到的那个Web界面。它负责用户认证会话管理、导航菜单渲染、以及调度其他“子应用”。门户本身提供了用户管理、作业管理、文件管理、交互式Shell等基础功能。它的所有配置都基于YAML文件非常灵活。3. 计算节点代理与PUN这是OOD架构中最精妙的部分。当用户通过网页点击“启动Jupyter Notebook”时门户应用并不会直接在Web服务器上运行这个计算密集型的交互应用那样会拖垮门户服务器。相反门户会通过SSH在指定的计算节点上启动一个轻量级的代理进程这个进程会创建一个独立的、受控的运行时环境称为“Per-User NGINXPUN”。PUN本质上是一个为用户专属的、迷你版的NGINX服务器它运行在计算节点上负责代理用户交互式应用如Jupyter的流量。这样计算负载被完美地卸载到了计算节点门户服务器只做轻量的调度和反向代理。4. 作业适配器Job AdapterOOD需要知道如何与你的集群作业调度系统对话。它通过作业适配器来实现。官方支持Slurm、PBS Pro、Torque等主流调度器。适配器是一组Ruby脚本和配置文件定义了如何查询队列状态、如何提交作业、如何获取作业信息等。部署时你需要选择并配置正确的适配器。2.2 部署环境与前提条件检查部署OOD对基础环境有一些要求提前准备好能避免后续很多麻烦。操作系统官方强烈推荐使用RHEL/CentOS/Rocky Linux/AlmaLinux 7 或 8系列。这些系统的软件包生态和长期支持与OOD的依赖最为匹配。Ubuntu/Debian理论上也可以但可能需要处理更多依赖关系冲突对于生产环境我建议遵循官方推荐选择RHEL系。目标服务器角色你需要选定一台服务器作为OOD门户服务器。这台服务器需要满足能够通过网络访问你的HPC集群的所有登录节点或头节点。因为OOD需要通过SSH在登录节点上执行命令来启动作业和PUN。具备稳定的、相对较好的性能。虽然计算负载不在这但它需要处理所有用户的Web请求和调度任务。建议至少4核CPU8GB内存。拥有一个固定的域名或IP地址用于用户访问。软件依赖以下软件包需要在门户服务器上预先安装或确保可用EPEL仓库这是必须的提供了许多额外的软件包。Development Tools编译工具链用于编译一些原生扩展。Node.js版本14或16OOD 2.0需要用于构建前端资源。Ruby版本2.7或3.0这是OOD核心Rails应用的运行环境。强烈建议使用系统自带的Ruby版本通过rbenv或rvm管理多版本有时会与Passenger产生兼容性问题。SQLite3OOD默认使用SQLite来存储会话等轻量级数据。权限与访问OOD服务需要以一个普通系统用户身份运行通常是ondemand用户。这个用户必须能够免密SSH到集群的登录节点。这是整个系统能工作的最关键前提。你需要配置SSH密钥对并将公钥部署到所有登录节点的authorized_keys文件中。确保该用户在登录节点上有正常的家目录和Shell环境如/bin/bash。注意很多部署失败案例都卡在SSH免密登录这一步。务必先在OOD服务器上手动切换到ondemand用户尝试SSH到登录节点确认可以无需密码直接登录并且环境变量特别是PATH加载正常。可以执行一下sinfoSlurm或qstatPBS命令看是否能正确返回信息。3. 分步部署安装实战假设我们的基础环境已经就绪一台全新的Rocky Linux 8服务器主机名ood-portal.example.com我们以root身份开始操作。3.1 步骤一配置基础仓库与安装依赖首先我们需要启用EPEL和PowerTools或CodeReady仓库它们提供了许多必要的软件包。# 安装EPEL仓库 dnf install -y epel-release # 启用PowerTools仓库Rocky/AlmaLinux 8 dnf config-manager --set-enabled powertools # 如果是RHEL 8需要启用CodeReady Builder仓库 # subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms # 更新系统并安装基础开发工具和依赖 dnf update -y dnf groupinstall -y Development Tools dnf install -y wget curl git zlib-devel sqlite-devel nodejs npm接下来安装Ruby。Rocky Linux 8默认的Ruby版本是2.7符合要求。dnf install -y ruby ruby-devel rubygems # 验证版本 ruby --version # 应显示 ruby 2.7.x为了加速RubyGems的下载建议更换为国内镜像源。gem sources --add https://gems.ruby-china.com/ --remove https://rubygems.org/ gem sources -l3.2 步骤二安装Open OnDemand官方提供了基于RPM包的安装方式这是最推荐的生产环境安装方法能更好地处理依赖和服务管理。# 下载并安装Open OnDemand的Release包 # 访问 https://openondemand.org/download/ 查看最新版本此处以2.0为例 wget https://github.com/OSC/Open-OnDemand/releases/download/v2.0.28/ondemand-release-2.0.28-1.el8.noarch.rpm dnf install -y ./ondemand-release-2.0.28-1.el8.noarch.rpm # 安装ondemand元包它会自动引入所有核心组件 dnf install -y ondemand这个安装过程会完成以下几件大事创建系统用户和组ondemand。安装NGINX并集成Passenger模块。安装OOD门户应用及其所有Ruby Gem依赖。安装nodejs运行时并编译前端资源。设置基本的系统服务单元和日志轮转。安装完成后先不要急着启动服务。关键的配置还在后面。3.3 步骤三核心配置详解与定制OOD的配置文件主要位于两个目录/etc/ood/config/和/etc/ood/config/apps/。我们需要逐一检查并修改。1. 配置NGINX与Passenger (/etc/ood/config/nginx_stage.yml)这个文件控制着NGINX服务器的行为。最重要的配置是pun_custom_env它定义了传递给PUN用户计算节点上的运行时的环境变量。你必须在这里设置集群相关的环境变量否则用户在交互式应用里可能找不到module命令或调度器命令。# 片段示例 pun_custom_env: # 加载集群环境假设集群环境通过 /etc/profile.d/cluster.sh 设置 PATH: /usr/local/bin:/usr/bin:/opt/slurm/bin:$PATH LD_LIBRARY_PATH: /opt/slurm/lib:$LD_LIBRARY_PATH # 指定模块系统的初始化文件 BASH_ENV: /etc/profile2. 配置门户 (/etc/ood/config/ood_portal.yml)这是门户的主配置文件。你需要生成一个初始配置然后编辑它。# 生成默认配置 /opt/ood/ood-portal-generator/sbin/update_ood_portal --force生成的配置文件/etc/ood/config/ood_portal.yml内容非常丰富。你需要关注以下几个关键部分# 监听端口和SSL生产环境必须启用SSL servername: ood-portal.example.com port: 443 ssl: true ssl_cert: /etc/pki/tls/certs/your_cert.crt ssl_key: /etc/pki/tls/private/your_key.key # 用户认证。OOD支持多种方式最常用的是HPC集群已有的LDAP/SSO。 # 这里以最基础的“通过系统用户认证”为例Dex或Keycloak是更佳生产选择。 auth: - AuthType Basic - AuthBasicProvider file - AuthUserFile /etc/ood/.htpasswd # 需要手动创建这个密码文件 - Require valid-user # 集群定义。这是告诉OOD你的HPC集群信息。 clusters: - my_hpc_cluster: # 集群ID自定义 job_adapter: slurm # 作业调度器类型 login: host: login-node.example.com # 登录节点主机名 # 可以定义多个登录节点实现负载均衡 # 资源管理器配置用于在Web界面显示队列、节点信息 resource_mgr_host: login-node.example.com3. 创建用户密码文件如果使用Basic认证如果上面配置了AuthUserFile你需要用htpasswd命令创建用户。# 安装apache2-utils包含htpasswd命令 dnf install -y httpd-tools # 创建文件并添加第一个用户 htpasswd -c -B /etc/ood/.htpasswd username1 # 添加更多用户去掉-c选项 htpasswd -B /etc/ood/.htpasswd username2注意Basic认证非常不安全仅适用于测试或内部安全网络。生产环境强烈建议集成LDAP、OpenID Connect如Keycloak或CAS。4. 配置作业适配器对于Slurm集群适配器配置通常在/etc/ood/config/apps/bc_desktop/submit.yml.erb或类似位置。你需要确保OOD服务器上的ondemand用户能正确执行sinfo,squeue,sbatch等命令。这通常意味着需要将登录节点上的Slurm客户端配置文件如/etc/slurm/slurm.conf同步到OOD服务器或者确保OOD服务器能通过网络访问登录节点上的Slurm控制守护进程slurmctld。3.4 步骤四启动服务与防火墙配置配置完成后更新NGINX配置并启动服务。# 重新生成并应用NGINX配置 /opt/ood/ood-portal-generator/sbin/update_ood_portal # 启动并启用相关服务 systemctl enable --now ondemand nginx systemctl status ondemand nginx # 检查状态应为active (running)配置防火墙开放HTTPS端口443。# 如果使用firewalld firewall-cmd --permanent --add-servicehttps firewall-cmd --reload # 如果使用iptables请相应开放443端口现在打开浏览器访问https://ood-portal.example.com你应该能看到Open OnDemand的登录界面了。用之前htpasswd创建的用户登录。4. 核心功能配置与应用开发4.1 文件管理与Shell访问登录后最常用的两个功能是“文件”和“作业”。文件应用基于浏览器提供了上传、下载、编辑、预览文本/图片等功能基本可以替代传统的SFTP客户端。而“Shell Access”则提供了一个基于Web的终端使用tty.js或wetty等后端用户可以直接在浏览器里执行命令行操作这对于快速检查文件、测试命令非常方便。实操心得Web终端的性能高度依赖网络延迟。对于需要大量字符输出的操作如cat大文件可能会比较慢。建议引导用户对大文件操作使用文件应用的“查看”功能或者仅将Web终端用于简单的目录导航和命令测试。4.2 交互式应用Apps配置以Jupyter Notebook为例OOD的强大之处在于能动态启动交互式应用。这些应用以“App”的形式存在每个App对应一个计算任务。系统自带了一些示例如“Desktops”远程桌面和“Job Composer”作业模板提交。但最受欢迎的还是Jupyter Notebook。配置一个Jupyter App并不复杂。OOD使用“Batch Connect”机制来启动这类应用。我们创建一个自定义的Jupyter App。创建App目录结构sudo -u ondemand mkdir -p /var/www/ood/apps/sys/myjupyter cd /var/www/ood/apps/sys/myjupyter编写表单配置文件 (form.yml):这个文件定义了用户在启动前需要填写的参数表单。--- form: - cluster - queue - num_cores - memory - walltime - jupyterlab attributes: cluster: my_hpc_cluster queue: batch num_cores: widget: number_field label: Number of cores value: 1 min: 1 max: 32 memory: widget: number_field label: Memory per core (GB) value: 4 min: 1 max: 128 step: 1 walltime: widget: number_field label: Walltime (hours) value: 1 min: 0.5 max: 72 step: 0.5 jupyterlab: widget: check_box label: Launch JupyterLab (instead of classic Notebook) value: true编写提交脚本模板 (submit.yml.erb):这是一个ERB模板OOD会根据用户表单输入动态生成一个提交给调度器如Slurm的作业脚本。--- script: native: % if !queue.nil? !queue.empty? -% - -p % queue % % end -% - -N 1 - -n % num_cores % % if !memory.nil? -% - --mem% memory %G % end -% - -t % (walltime * 3600).to_i % job_environment: MODULEPATH: /usr/share/Modules/modulefiles before_script: | module purge module load anaconda3/2022.05 # 根据用户选择设置启动命令 % if jupyterlab 1 -% export JUPYTER_APPjupyter-lab % else -% export JUPYTER_APPjupyter-notebook % end -% # 这个脚本会在计算节点上执行启动Jupyter script: | echo Starting Jupyter on $(hostname)... LAUNCHER$HOME/.local/bin/jupyter-$RANDOM cat $LAUNCHER EOF #!/bin/bash source ${MODULESHOME}/init/bash module load anaconda3/2022.05 exec % context.jupyter_app % --no-browser --ip$(hostname -f) --port${PORT} EOF chmod x $LAUNCHER $LAUNCHER4. **编写前端显示模板 (template.html.erb):** 这个文件控制App在OOD门户中的展示样式图标、描述等。 完成以上文件后在OOD门户的“Interactive Apps”下拉菜单中就能看到你新创建的“My Jupyter”应用了。用户填写表单提交后OOD会向Slurm提交一个作业作业启动后会在计算节点上运行Jupyter并将Web接口通过PUN反向代理到用户的浏览器。 ### 4.3 作业提交与监控Job Composer Job Composer是一个模板化的作业提交工具。管理员可以预置一些标准的作业脚本模板如“ Gaussian计算”、“VASP弛豫”用户只需选择模板修改几个输入文件路径和参数就能一键提交无需自己写复杂的SBATCH脚本。这对于规范作业提交、减少用户错误非常有用。 配置Job Composer需要定义“模板仓库”。你可以创建一个Git仓库来存放这些模板然后在/etc/ood/config/apps/dashboard/initializers/下创建一个Ruby文件来配置模板仓库的路径。 ## 5. 运维、故障排查与性能调优 ### 5.1 日常运维要点 - **日志查看** OOD的日志分散在几个地方排查问题时需要综合查看。 - **门户日志** /var/log/ondemand-nginx/user/ 目录下每个用户都有一个子目录里面有error.log和access.log记录了该用户PUN的访问和错误信息。 - **NGINX错误日志** /var/log/nginx/error.log 和 /var/log/nginx/access.log记录门户本身的访问情况。 - **Passenger日志** passenger-status 和 passenger-memory-stats 命令可以查看Rails应用进程的状态和内存使用。 - **磁盘空间监控** PUN进程和用户会话会生成临时文件。需要监控/var/lib/nginx/tmp/默认的PUN临时目录和/tmp目录的空间使用情况。 - **定期更新** 关注OOD的版本更新特别是安全更新。可以通过更新RPM包进行升级但升级前务必在测试环境验证并备份配置文件。 ### 5.2 常见问题与排查技巧实录 下面是我在运维中遇到的一些典型问题及解决方法整理成了速查表 | 问题现象 | 可能原因 | 排查步骤与解决方法 | | :--- | :--- | :--- | | 用户登录后页面空白或500错误。 | 1. Passenger应用进程崩溃。br2. Ruby Gem依赖冲突或缺失。br3. 配置文件语法错误。 | 1. 查看/var/log/nginx/error.log和passenger-status。br2. 检查/var/www/ood/apps/sys/dashboard/下的Gemfile.lock尝试bundle install。br3. 使用/opt/ood/ood-portal-generator/sbin/update_ood_portal --check检查配置文件语法。 | | 点击启动交互式应用如Jupyter长时间处于“Queued”或“Starting”状态最终失败。 | 1. SSH免密登录失败。br2. 作业调度器命令无法执行路径或权限问题。br3. 计算节点资源不足或作业脚本有误。 | 1. 以ondemand用户身份手动SSH到登录节点验证是否成功。br2. 在/etc/ood/config/nginx_stage.yml的pun_custom_env中正确设置PATH和模块环境。br3. 查看失败作业的Slurm日志scontrol show job jobid。在App的submit.yml.erb中加入debug: true可以输出更详细的日志。 | | 交互式应用启动成功但浏览器无法连接ERR_CONNECTION_REFUSED。 | 1. PUN进程启动失败。br2. 计算节点防火墙阻止了PUN使用的端口范围。br3. 反向代理配置错误。 | 1. 查看对应用户的PUN错误日志 (/var/log/ondemand-nginx/user/error.log)。br2. 确保计算节点上OOD使用的端口范围默认是1024-65535是开放的。br3. 检查NGINX配置中proxy_pass指令是否正确指向了PUN的socket文件。 | | 文件应用上传/下载速度极慢。 | 1. Web服务器NGINX缓冲区配置不当。br2. 网络问题。br3. 客户端浏览器问题。 | 1. 尝试调整/etc/nginx/nginx.conf中client_max_body_size和proxy_buffering相关参数。br2. 使用浏览器开发者工具的网络面板查看具体请求的耗时阶段。 | | 用户反映Web终端Shell卡顿或断开。 | 1. 网络延迟或波动。br2. WebSocket连接被中间代理服务器阻断。br3. 服务器负载过高。 | 1. 这是Web终端的通病建议用户用于轻量级操作。br2. 检查NGINX配置确保正确代理WebSocket连接proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade;。br3. 监控服务器资源使用情况。 | ### 5.3 性能与安全调优建议 - **启用并优化SSL** 使用Let‘s Encrypt获取免费证书并在NGINX配置中启用HTTP/2和现代加密套件提升安全性和性能。 - **调整Passenger参数** 在/etc/ood/config/nginx_stage.yml中可以调整passenger_max_pool_size和passenger_min_instances来控制Rails进程数量平衡内存使用和响应速度。 - **会话超时设置** 合理设置pun_pre_hook_root_cmd或使用pun_custom_env设置OOD_IDLE_TIMEOUT控制空闲会话的自动销毁时间释放计算资源。 - **使用外部认证** 尽快迁移到LDAP、OpenID Connect等集中认证系统废除基础的htpasswd提升安全性和管理便利性。 - **备份配置** 定期备份/etc/ood/config/目录下的所有配置文件。在升级或迁移时这些配置是恢复服务的关键。 部署和运维Open OnDemand是一个持续的过程它不仅仅是安装软件更是对现有HPC运维流程的一次Web化升级。从最初的命令行到如今的Web门户改变的不仅是交互方式更是资源管理的理念——让计算资源更易用、更透明。在部署过程中耐心和细致的日志排查是关键。一旦系统稳定运行你会发现用户的支持请求会显著减少而集群资源的利用率和管理效率则会得到实实在在的提升。
