最近学校大跃进式把所有超算节点从 7 升级到 8 了，结果大翻车。

系统升级完，第一件事当然是登进去重新编译代码。结果新系统居然忘装 nano，没办法先用 vi 改配置文件吧，给管理员发了一个 ticket，10 分抗投诉服务器钟后回复我装好了，看来新系统装完了还挺闲的。

进 module 里面看看更新了啥，结果也乱套了。原来 CentOS 7 老的 module 还没清理干净，跟新的摆在一起都不知道谁是谁，只能通过版本号猜。（截至发帖时清理的差不多了）

编译的时候 openmpi 也翻车了，找不到libpmi2.so.0。这个应该是属于重大运维事故了吧？管理员在一整天之后才修复，告诉我说是忘记在头节点上编译 pmi 了。上线之前这么基本的组件都不测试一下的吗？

总结经验教训，学校级别的运维水平参差不齐，从 7 升级到 8 翻车是难免的。年底不能白嫖 CentOS 以后肯定得换系统，到时候接着翻车。

我觉得只要系统能起来，都不算重大事故吧。

明明 centos8 年底就要转 stream 了，这管理员也太胆大了吧，毕竟 7 的 eol 比 8 长，而且 7 也没什么问题啊。

哪里的运维都有干活不带脑子的

事实上，编译的事情你换个 os 也一样后果

这波操作看不懂啊？
明明 CentOS 8 的 EOL 就是今年年底了。CentOS 7 可以到 2024 年。

超算几乎没有不用 mpi 的，mpi 用不了跟系统起不来没啥区别。

不懂了，隔行如隔山

这么前卫吗，我司线上还是 centos4，从来没有谁提过要升级

你校运维不看看新闻？为何要 49 年入国军？不过 centos 8 转 centos 8 stream 也就 3 行代码。只是 centos 8 stream eol 和 centos7 一样，都是 2024 年。

好像最新的新闻是 RHEL 对非营利组织免费

开发者订阅对所有人免费，你们又不是商用环境

centos 8 到 oracle linux, rocky linux, almalinux 这些都是有一键切换脚本的，基本上算是可以无缝切换吧，也不算特别大的事

centos4 我有点不信呀

centos7 没必要上 8 吧
你们的运维老哥是闲着没事干了吗
还是他的 kpi 就是每年升级几次操作系统

俺们的生产环境里还有 win2003 来着....

不翻几次车怎么体现运维工作的重要性（滑稽

我的个人经验是，只要稳定跑，就不去搞升级。除非当前环境满足不了需求了才考虑升级，否则坚决不升。（手动斜眼

换 ubuntu 2004?

没有 KPI 制造 KPI 也要上

CentOS 7 真的足够了，如果采购的集群是 8，那就降级到 7 就好了。
依赖尽量通过 Container 来解决，没必要动基本系统。

生产环境敢直接给系统跨版本升级的简直是勇者

牛比～ CentOS 我们现在大部分业务都还是 6 的，7 的只有新业务在用。8 的都还没业务的正式环境敢用。

上 8 还是要折腾一番的，要是遇到点问题不是下线个几个钟头就能搞定的。

怕怕，谁的坑

至少过 1-2 年再考虑上 8

我也是和其他 V 友有同一个疑问，centos8 马上都要结束生命周期了，为啥还要升级了。centos 整个发行版都要升级为 stream，未来 centos 就再也不是企业级了。不过 centos7 还可以战几年。

企业 2022-2023 年再考虑 8 也不迟，到时候直接上 centos stream 9

为了不纠结 7 还是 8，新服务器都用了 debian 10

搞了六七年 Linux 的运维过来唠叨一句
无论是从实际经验还是从一些项目的官方文档建议来看，升级操作系统只有在少数的几种情况下是必要的：
- 重大的安全漏洞
- 当前旧版本上的某个软件存在某个 Bug，该 Bug 已经触发或者有潜在触发的可能
- 在当前系统上跑的软件需要系统更新至更新的版本
不过就实际经验来看，在线上跑的软件很少需要整个系统都升级的情况，即使像 K8s 明确在 3.10 内核上频繁创建 Pod 会触发 CGroup 内存泄露的 Bug 的这种问题，也可能通过仅仅升级内核而非整个操作系统都升级来解决。
所以这个帖子除了吐槽没有任何意义，正常的运维只要带了脑子上班都不会升级操作系统。
：）

我选 ubuntu

世界前 20 的超算跑 ubuntu 的一个手都数得过来，楼上几个花式创造 kpi ？

你们学校运维上线太快了，我校超算软硬件升级（ RHEL 系统迁移+新增 EPYC 节点+安装从 NVIDIA 那里薅来的 5000w 美元显卡羊毛）整整花了圣诞节 1 个月的假期，期间超算完全关闭，登陆节点都上不去，然后软硬件搞好后还试运行了好一阵子，才 OK，升级系统这种大事，上线快肯定要出毛病的

超算上大部分都是科学计算程序，并行程度很高，一个任务都是几百个 cpu 核心同时算，内存都是几百 g 或者上 T 占用，mpi 很重要，根本离不开

我这是第一次听说 CentOS 4 。。。以前最旧的也就是 5，还很少见，其实 6 都见得不多。。。

10 多年的老项目了，centos4+php5.4，还依赖很多动态库。根本没人敢动

我的关注点是编辑器为什么用 nano ？ vi 虽然比 vim 难用很多但也是秒 nano 的啊，进到 nano 页面完全不知所措

10 多年前的老项目，java4?

8 就是个坑，官方仓库里好多 package 有问题，我已经遇到好多问题了，真被恶心到了。赶紧要么降级，要么换别的系统

学校的运维大部分是本校研究生兼职的，有时候爱把集群当自己的 PC 折腾。

从描述来看,
运维经验不足呀.
没有编辑器, 可以结合 cat echo sed 等修改配置文件呀, 不会连 cp cat 等无法使用吧?
至于各种编译, 应该说服管理员安装一个 Singularity 就高枕无忧了.
如果运维方不晓得什么是 Singularity, 让他多看看新闻吧.
我自己也有集群, 仅是规模不大, 系统是混跑的, CentOS 6.x 混 RHEL 6.y, x, y 1~10 均有.
机器是浪潮不同批次送来的.
只要机器能正常运行, 不死机, 不重启, 不 kernel panic,
合理采用各种镜像技术, 完全可以应付好几年的.
数年之后, 机器也就到寿命了.
CentOS 系统并没有说要完犊子. 根据我自己理解官方的说法.
之前是, RedHat 测试, 推送给 RHEL; centOS 社区编译, 推送给 CentOS 用户.
现在是, RedHat 测试, 推送给 CentOS, 再推送给 RHEL.
就是之前滞后的命运要完犊子.

我想知道容器化解决不了这种场景吗？性能有损耗？

我的应用用，性能几乎无损耗。
测试软件，典型的量子化学电子结构计算软件，gaussian16 。
TF-DFT 计算频率，36 核心，120GB 内存，
主机裸体跑，4 小时左右。
容器方式，多五秒。
软件自己统计的时间。
我认为效率无差异。
可能是，所谓超算的运维，
不晓得容器化技术。

看你们的运维平常是怎么维护系统的了，如果是一台台上去维护，那不懂也正常……
如果使用 Ansible 之类的工具批量运维，能够保证每台机器环境基本一致，那是正常水平，估计是不想转
还有看你们的集群有多大，就几台的话上容器也没啥必要，k8s 学习成本太高

我之前在 mit 人工智能数据中心，我们用免费的 rhel 授权

UC 震惊部总监：中国知名高校完犊子了，被卡脖子了，无法编译美国发明的 mpi，中国高校中国魂，中国芯片中国造

搜 Singularity 的时候找到了交大超算平台的用户手册，发现他们并没有通过虚拟化技术做用户隔离，这让普通程序员很难想象，就算是学校内部使用，如此规模的用户数，竟然不做隔离
https://docs.hpc.sjtu.edu.cn/faq/index.html#q-sudo

你说的 Ansible 我不懂, 也用不到. 我自己做的集群, 还用不到这么高级的东西. 实际应用中, 除非硬件损坏, 几乎碰不到节点需要维护的情形.
k8s 没玩过.
计算化学并行计算方面, 使用 singularity 就解决问题了. 十分简单.
对于用户而言, 无非就是,
原来是 mpirun -np $NP AAAA
现在是 mpirun -np $NP singularity exec AAAA
其他方案, 对于用户而言, 学习成本偏高.
用户的水平可以这样描述:
如果在说明里面写, 系统有多个 intel 编译器版本,
使用 XXX 请运行 source /opt/scirpt/enable_intelXXX.sh 激活.
用户会来 BB, 啥, 你到底会不会弄呀,
还让我自己激活 Intel 编译器? 我去那里搞激活码, 序列号?
用户大概都是这个水准的.
以上仅仅来自个人工作经历.
我仅仅管理过顶多 50 节点左右的并行计算集群.
我自己做的集群, 仅限课题组小规模使用.
部分言论, 可能有不严谨, 请见谅.

1. 超算用户基本都不是学 CS 的。会用 vi 的凤毛麟角。
2. 一般也就是进配置文件改个数。这种事情 nano 就能轻轻松松完成。

你想多了，超算最多限制对其他人文件夹的访问权限，不可能搞什么隔离的。

这 50 节点都是物理机吗？并行计算的时候节点之间如何通信？
正常用 docker，如果有特殊的依赖，都是用户自己根据需要写 dockerfile，在干净的系统镜像上自行编译安装。如果是运维负责维护镜像，那应该把不同版本的编译器放到不同的 image 里去，由用户自行选择，但如果用户连用哪个编译器版本都不知道的话……那我也不知道怎么办了
其实 singularity 我也是第一次听说，同样是高性能计算，学校和企业的要求完全不一样，像用户隔离，这对于企业来说是基本要求，数据泄露是绝对不能承担的风险。一个用户无论怎么折腾，都不会对其他用户有任何影响，这是虚拟化的优势，但虚拟化也有性能损耗。singularity 为了性能而弱化了隔离，这是企业用户不能接受的，估计也是 singularity 在商业领域不怎么火的原因

我有限的知识：节点间通信是 infiniband，这里面是个大坑，你用虚拟化容易玩崩。


怪不得这里写禁止运行军工项目，别说军工项目了，商业项目估计都没人敢放上面

超算领域 CentOS 是事实标准。而且因为它是事实标准，所有工业软件基本都只做 RHEL 版的。

所以对于用户来说，这 50 个节点跟一个虚拟机是一样的，用户完全不用考虑任务调度和节点间通信的问题？

调度是 Slurm 管，用户写好了自己需要多少个 CPU 提交脚本就行了，slurm 算法自动管理队列。通信是 mpi 管的，infiniband 负责传输，用户无需插手。

真是隔行如隔山，我用过的任务调度系统都是自己写的

我校升级从上午 10:00 到下午 1:46 。速度是挺快，活干的够糙的。

记得有位网友问我，怎么搭建计算用的并行集群？
说自己看了些都是 k8s 集群。
我说你看错方向了。
计算用的和 k8s 集群是两会事。
去小破站找我的视频，能有点帮助。
id 一样的。
后来他搞定了。

物理机器呀. 你说的那些, 没法跑所谓高性能并行计算. 你说的, 和我用的, 完全是不同的领域.

https://mp.weixin.qq.com/s/yFUIZqOPrhbWQXwbOutrGQ
去申请一个 RHEL 用吧

7 的用户比 8 的多不少吧

“RHEL for Open Source Infrastructure 不适合单个开发人员，以及当前想要在独立的开源项目基础架构之外使用 RHEL 的红帽客户 /合作伙伴、政府组织、医疗机构、学术机构或非营利组织。红帽将继续为传统的非营利组织、学术机构和政府实体探索新计划”

顺便吐槽一下.
很多超算中心写的那个使用说明, 太过于专业化了.
99%的用户, 仅仅是来做计算, 让计算跑起来, 又不是 CS 专业的,
谁理解什么容器啥意思?
手册应该分两版本,
简明版, 只需要讲,
怎么到这个机器来, 怎么拿走数据?
如果你的程序手册告诉你, 是这么运行, 那么在这个机器, 是如此运行.
需要对中心提供的每一个程序都要写类似的说明.
高阶版, 一定要提醒客户, 如果没有任何计算机基础, 请一定找一个 CS 专业的人员, 陪同一起看使用说明.
我课题组的机器,
从单个服务器到计算集群, 自己做.
只要是机器上提供的计算软件,
每一个, 操作流程都是:
用户提供输入控制文件到指定目录; mkdir ~/input
用户拷贝脚本到目录; cp /opt/share/scripts/run-XXX.sh ~/input
需要更换 XXX 为对应的程序名称, 手册有列表.
最后, 运行计算, bash ~/input/run-XXX.sh
所有计算, 会自动加载到队列中. 会自动设定 CPU 核心数目, 内存数目等.
只用如何登录以及拿走数据,
录制视频, 演示 windows + MobaXterm 如何搞.
就是这样的简易使用策略, 学生都能搞错.
还想指望学生能看懂诸如 容器 之类的名词, 是不现实的.

没事升级新系统那个干啥 新系统有的问题谷歌不到呀 我司都还是 centos 7 呢

而个人开发者可以通过更新的红帽开发者计划轻松访问 RHEL，更多信息点击《新年新项目：让红帽企业 Linux 更易获得》。

服务器还在用 centos7，之前尝鲜升级到 8，结果一堆兼容问题，然后又退回去了。踩过的众多坑告诉我，不要在生产环境下手贱去尝鲜新事物，可能是习惯了这种保守策略，导致我连普通软件只要能用就非常抗拒升级，否则少不了乱七八糟的各种毛病。

超算上百台机器，redhat 改行做慈善了？

管理员说我是全校唯一一个需要编译 C++的。别人要么用现成的商业软件要么就是 python 练丹师。他手册里编译器那页写那么长就我一个人在看...

只要支持 singularity 就可以了。
在自己机器上编译处理完毕，拷贝上去就可用了。我认为特别好用。
我把它当作可以秒开的虚拟机，网络用户啥都不用考虑，数据还在原来地方，只是环境不同了。
前一秒还是 c7，后一秒可能就是 apt 可用可。
我个人认为，这是针对科学计算方面十分优秀的解决方案。

我看了一下手册，他们确实这个月随着新系统同时上线了 singularity，不过并没有建议我用...

感觉确实是没法用啊，我个人又没有 icc 的 license，还得跑去本机编译。

php 的项目，php5.4，而且 php 还自己写了很多 c 扩展，nginx 又加了些 lua 扩展啥的。导致这么多年来根本没人敢动

跑肯定是能跑，就是坑太多，用户和运维的学习成本都很高

同运维，支持这个观点。

编译的时候发生混沌 /软件包版本混沌有个很直接的解决方案：自己搭建 dist-git/koji 等一套软件包编译打包系统。软件包管理就能解决找出没有被满足的依赖、以及提示冲突的老包。而不是一股脑 make install，然后谁也不记得哪些文件是哪些软件的。
并且上游有包(印象中 openmpi 就在 centos 有打包)并且能满足需求就直接用呗。就算是 CERN 的集群都有安装 EPEL 包...虽然大家用软件都是直接去 cvmfs 上面 source 的。


虽然是这样变化没错,但 centos 一下子从以稳定性著称的 RHEL 系统再编译版变成了 fedora 的贝塔测试版...还是滚动发布版本;
那么以后谁还会大规模部署使用呢?我相信绝大多数用户都不会去使用 stream 版而会转去 第三方 rhel 再编译版的,比如那个
Rocky Linux 或 CloudLinux