这是一个创建于 1670 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近学校大跃进式把所有超算节点从 7 升级到 8 了，结果大翻车。
系统升级完，第一件事当然是登进去重新编译代码。结果新系统居然忘装 nano，没办法先用 vi 改配置文件吧，给管理员发了一个 ticket，10 分钟后回复我装好了，看来新系统装完了还挺闲的。
进 module 里面看看更新了啥，结果也乱套了。原来 CentOS 7 老的 module 还没清理干净，跟新的摆在一起都不知道谁是谁，只能通过版本号猜。（截至发帖时清理的差不多了）
编译的时候 openmpi 也翻车了，找不到libpmi2.so.0。这个应该是属于重大运维事故了吧？管理员在一整天之后才修复，告诉我说是忘记在头节点上编译 pmi 了。上线之前这么基本的组件都不测试一下的吗？
总结经验教训，学校级别的运维水平参差不齐，从 7 升级到 8 翻车是难免的。年底不能白嫖 CentOS 以后肯定得换系统，到时候接着翻车。
第 1 条附言 2021-03-22 14:54:29 +08:00
强行升级的原因是去年年底购置了一台新的集群（就在官宣 CentOS Stream 之前一个月上线的，倒了血霉），7/8 混用了一段时间，结果不少软件都出兼容性问题，屡遭师生投诉，于是下狠心全给升级了。
 | 1 venster 2021-03-22 12:47:10 +08:00 via Android 我觉得只要系统能起来，都不算重大事故吧。 |
 | 2 cmos 2021-03-22 12:48:03 +08:00 via Android 明明 centos8 年底就要转 stream 了，这管理员也太胆大了吧，毕竟 7 的 eol 比 8 长，而且 7 也没什么问题啊。 |
 | 3 yyyb 2021-03-22 12:49:12 +08:00 哪里的运维都有干活不带脑子的 |
 | 4 m4d3bug 2021-03-22 12:51:53 +08:00 via Android 事实上，编译的事情你换个 os 也一样后果 |
 | 5 Xusually 2021-03-22 12:52:16 +08:00 这波操作看不懂啊？ 明明 CentOS 8 的 EOL 就是今年年底了。CentOS 7 可以到 2024 年。 |
 | 8 sadfQED2 2021-03-22 12:54:41 +08:00 via Android 这么前卫吗，我司线上还是 centos4，从来没有谁提过要升级 |
 | 9 matolv 2021-03-22 12:58:55 +08:00 你校运维不看看新闻？为何要 49 年入国军？不过 centos 8 转 centos 8 stream 也就 3 行代码。只是 centos 8 stream eol 和 centos7 一样，都是 2024 年。 |
 | 12 zengxs 2021-03-22 14:04:34 +08:00 centos 8 到 oracle linux, rocky linux, almalinux 这些都是有一键切换脚本的，基本上算是可以无缝切换吧，也不算特别大的事 |
 | 14 Lee2019 2021-03-22 14:40:53 +08:00 centos7 没必要上 8 吧 你们的运维老哥是闲着没事干了吗 还是他的 kpi 就是每年升级几次操作系统 |
 | 16 LokiSharp 2021-03-22 14:50:41 +08:00 不翻几次车怎么体现运维工作的重要性（滑稽 |
 | 17 ReZer0 2021-03-22 14:54:11 +08:00 我的个人经验是，只要稳定跑，就不去搞升级。除非当前环境满足不了需求了才考虑升级，否则坚决不升。（手动斜眼 |
 | 18 Ansen 2021-03-22 15:09:16 +08:00 换 ubuntu 2004? |
 | 20 swulling 2021-03-22 15:11:04 +08:00 CentOS 7 真的足够了，如果采购的集群是 8，那就降级到 7 就好了。 依赖尽量通过 Container 来解决，没必要动基本系统。 |
 | 21 superrichman 2021-03-22 16:08:22 +08:00 生产环境敢直接给系统跨版本升级的简直是勇者 |
 | 22 haisi0525 2021-03-22 17:04:57 +08:00 牛比～ CentOS 我们现在大部分业务都还是 6 的，7 的只有新业务在用。8 的都还没业务的正式环境敢用。 |
 | 23 byzf 2021-03-22 17:09:46 +08:00 上 8 还是要折腾一番的，要是遇到点问题不是下线个几个钟头就能搞定的。 |
 | 24 ji39 2021-03-22 17:12:44 +08:00 怕怕，谁的坑 |
 | 25 aaa5838769 2021-03-22 17:52:43 +08:00 至少过 1-2 年再考虑上 8 |
 | 26 onice 2021-03-22 18:48:36 +08:00 我也是和其他 V 友有同一个疑问，centos8 马上都要结束生命周期了，为啥还要升级了。centos 整个发行版都要升级为 stream，未来 centos 就再也不是企业级了。不过 centos7 还可以战几年。 |
 | 27 salmon5 2021-03-22 19:10:39 +08:00 企业 2022-2023 年再考虑 8 也不迟，到时候直接上 centos stream 9 |
 | 28 waising 2021-03-22 19:12:05 +08:00 为了不纠结 7 还是 8，新服务器都用了 debian 10 |
 | 29 vhwwls 2021-03-22 19:17:43 +08:00 搞了六七年 Linux 的运维过来唠叨一句 无论是从实际经验还是从一些项目的官方文档建议来看，升级操作系统只有在少数的几种情况下是必要的： - 重大的安全漏洞 - 当前旧版本上的某个软件存在某个 Bug，该 Bug 已经触发或者有潜在触发的可能 - 在当前系统上跑的软件需要系统更新至更新的版本 不过就实际经验来看，在线上跑的软件很少需要整个系统都升级的情况，即使像 K8s 明确在 3.10 内核上频繁创建 Pod 会触发 CGroup 内存泄露的 Bug 的这种问题，也可能通过仅仅升级内核而非整个操作系统都升级来解决。 所以这个帖子除了吐槽没有任何意义，正常的运维只要带了脑子上班都不会升级操作系统。 ：） |
 | 30 secretman 2021-03-22 19:40:11 +08:00 我选 ubuntu |
| 31 m4d3bug 2021-03-22 19:51:35 +08:00 via Android 世界前 20 的超算跑 ubuntu 的一个手都数得过来，楼上几个花式创造 kpi ？ |
 | 32 Tony042 2021-03-22 19:53:12 +08:00 你们学校运维上线太快了，我校超算软硬件升级（ RHEL 系统迁移+新增 EPYC 节点+安装从 NVIDIA 那里薅来的 5000w 美元显卡羊毛）整整花了圣诞节 1 个月的假期，期间超算完全关闭，登陆节点都上不去，然后软硬件搞好后还试运行了好一阵子，才 OK，升级系统这种大事，上线快肯定要出毛病的 |
| 33 Tony042 2021-03-22 19:55:16 +08:00 @venster 超算上大部分都是科学计算程序，并行程度很高，一个任务都是几百个 cpu 核心同时算，内存都是几百 g 或者上 T 占用，mpi 很重要，根本离不开 |
| 35 sadfQED2 2021-03-22 20:30:51 +08:00 via Android |
 | 36 mikeguan 2021-03-22 20:45:01 +08:00 via Android 我的关注点是编辑器为什么用 nano ？ vi 虽然比 vim 难用很多但也是秒 nano 的啊，进到 nano 页面完全不知所措 |
 | 38 Nitroethane 2021-03-22 21:18:59 +08:00 8 就是个坑，官方仓库里好多 package 有问题，我已经遇到好多问题了，真被恶心到了。赶紧要么降级，要么换别的系统 |
 | 39 ulosggs 2021-03-22 21:30:00 +08:00 学校的运维大部分是本校研究生兼职的，有时候爱把集群当自己的 PC 折腾。 |
 | 40 abbottcn 2021-03-22 21:31:36 +08:00 从描述来看, 运维经验不足呀. 没有编辑器, 可以结合 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. 就是之前滞后的命运要完犊子. |
 | 41 Jat001 2021-03-22 21:39:38 +08:00 我想知道容器化解决不了这种场景吗？性能有损耗？ |
| 42 abbottcn 2021-03-22 21:48:05 +08:00 via iPhone @Jat001 我的应用用，性能几乎无损耗。 测试软件，典型的量子化学电子结构计算软件，gaussian16 。 TF-DFT 计算频率，36 核心，120GB 内存， 主机裸体跑，4 小时左右。 容器方式，多五秒。 软件自己统计的时间。 我认为效率无差异。 可能是，所谓超算的运维， 不晓得容器化技术。 |
| 43 Jat001 2021-03-22 22:05:54 +08:00 @abbottcn #42 看你们的运维平常是怎么维护系统的了，如果是一台台上去维护，那不懂也正常…… 如果使用 Ansible 之类的工具批量运维，能够保证每台机器环境基本一致，那是正常水平，估计是不想转 还有看你们的集群有多大，就几台的话上容器也没啥必要，k8s 学习成本太高 |
 | 44 FucUrFrd 2021-03-22 22:07:01 +08:00 via Android 我之前在 mit 人工智能数据中心，我们用免费的 rhel 授权 |
| 45 FucUrFrd 2021-03-22 22:17:01 +08:00 via Android UC 震惊部总监：中国知名高校完犊子了，被卡脖子了，无法编译美国发明的 mpi，中国高校中国魂，中国芯片中国造 |
| 46 Jat001 2021-03-22 22:39:36 +08:00  1 搜 Singularity 的时候找到了交大超算平台的用户手册，发现他们并没有通过虚拟化技术做用户隔离，这让普通程序员很难想象，就算是学校内部使用，如此规模的用户数，竟然不做隔离 https://docs.hpc.sjtu.edu.cn/faq/index.html#q-sudo |
| 47 abbottcn 2021-03-22 23:19:36 +08:00 2 @Jat001 你说的 Ansible 我不懂, 也用不到. 我自己做的集群, 还用不到这么高级的东西. 实际应用中, 除非硬件损坏, 几乎碰不到节点需要维护的情形. k8s 没玩过. 计算化学并行计算方面, 使用 singularity 就解决问题了. 十分简单. 对于用户而言, 无非就是, 原来是 mpirun -np $NP AAAA 现在是 mpirun -np $NP singularity exec AAAA 其他方案, 对于用户而言, 学习成本偏高. 用户的水平可以这样描述: 如果在说明里面写, 系统有多个 intel 编译器版本, 使用 XXX 请运行 source /opt/scirpt/enable_intelXXX.sh 激活. 用户会来 BB, 啥, 你到底会不会弄呀, 还让我自己激活 Intel 编译器? 我去那里搞激活码, 序列号? 用户大概都是这个水准的. 以上仅仅来自个人工作经历. 我仅仅管理过顶多 50 节点左右的并行计算集群. 我自己做的集群, 仅限课题组小规模使用. 部分言论, 可能有不严谨, 请见谅. |
 | 48 xuegy OP @mikeguan 1. 超算用户基本都不是学 CS 的。会用 vi 的凤毛麟角。 2. 一般也就是进配置文件改个数。这种事情 nano 就能轻轻松松完成。 |
| 50 Jat001 2021-03-23 00:14:34 +08:00 @abbottcn #47 这 50 节点都是物理机吗？并行计算的时候节点之间如何通信？ 正常用 docker，如果有特殊的依赖，都是用户自己根据需要写 dockerfile，在干净的系统镜像上自行编译安装。如果是运维负责维护镜像，那应该把不同版本的编译器放到不同的 image 里去，由用户自行选择，但如果用户连用哪个编译器版本都不知道的话……那我也不知道怎么办了 其实 singularity 我也是第一次听说，同样是高性能计算，学校和企业的要求完全不一样，像用户隔离，这对于企业来说是基本要求，数据泄露是绝对不能承担的风险。一个用户无论怎么折腾，都不会对其他用户有任何影响，这是虚拟化的优势，但虚拟化也有性能损耗。singularity 为了性能而弱化了隔离，这是企业用户不能接受的，估计也是 singularity 在商业领域不怎么火的原因 |
| 51 xuegy OP @Jat001 我有限的知识：节点间通信是 infiniband，这里面是个大坑，你用虚拟化容易玩崩。 |
| 53 xuegy OP @waising 超算领域 CentOS 是事实标准。而且因为它是事实标准，所有工业软件基本都只做 RHEL 版的。 |
| 55 xuegy OP 调度是 Slurm 管，用户写好了自己需要多少个 CPU 提交脚本就行了，slurm 算法自动管理队列。通信是 mpi 管的，infiniband 负责传输，用户无需插手。 |
| 58 abbottcn 2021-03-23 08:13:57 +08:00 via iPhone 记得有位网友问我，怎么搭建计算用的并行集群？ 说自己看了些都是 k8s 集群。 我说你看错方向了。 计算用的和 k8s 集群是两会事。 去小破站找我的视频，能有点帮助。 id 一样的。 后来他搞定了。 |
| 60 m4d3bug 2021-03-23 11:00:15 +08:00 via Android https://mp.weixin.qq.com/s/yFUIZqOPrhbWQXwbOutrGQ 去申请一个 RHEL 用吧 |
 | 61 DaGongRen001 2021-03-23 11:18:26 +08:00 7 的用户比 8 的多不少吧 |
| 62 xuegy OP @m4d3bug “RHEL for Open Source Infrastructure 不适合单个开发人员，以及当前想要在独立的开源项目基础架构之外使用 RHEL 的红帽客户 /合作伙伴、政府组织、医疗机构、学术机构或非营利组织。红帽将继续为传统的非营利组织、学术机构和政府实体探索新计划” |
| 63 abbottcn 2021-03-23 11:53:57 +08:00 顺便吐槽一下. 很多超算中心写的那个使用说明, 太过于专业化了. 99%的用户, 仅仅是来做计算, 让计算跑起来, 又不是 CS 专业的, 谁理解什么容器啥意思? 手册应该分两版本, 简明版, 只需要讲, 怎么到这个机器来, 怎么拿走数据? 如果你的程序手册告诉你, 是这么运行, 那么在这个机器, 是如此运行. 需要对中心提供的每一个程序都要写类似的说明. 高阶版, 一定要提醒客户, 如果没有任何计算机基础, 请一定找一个 CS 专业的人员, 陪同一起看使用说明. 我课题组的机器, 从单个服务器到计算集群, 自己做. 只要是机器上提供的计算软件, 每一个, 操作流程都是: 用户提供输入控制文件到指定目录; mkdir ~/input 用户拷贝脚本到目录; cp /opt/share/scripts/run-XXX.sh ~/input 需要更换 XXX 为对应的程序名称, 手册有列表. 最后, 运行计算, bash ~/input/run-XXX.sh 所有计算, 会自动加载到队列中. 会自动设定 CPU 核心数目, 内存数目等. 只用如何登录以及拿走数据, 录制视频, 演示 windows + MobaXterm 如何搞. 就是这样的简易使用策略, 学生都能搞错. 还想指望学生能看懂诸如 容器 之类的名词, 是不现实的. |
 | 64 tom8 2021-03-23 12:03:15 +08:00 没事升级新系统那个干啥 新系统有的问题谷歌不到呀 我司都还是 centos 7 呢 |
| 65 m4d3bug 2021-03-23 12:03:58 +08:00 via Android @xuegy 而个人开发者可以通过更新的红帽开发者计划轻松访问 RHEL，更多信息点击《新年新项目：让红帽企业 Linux 更易获得》。 |
 | 66 mostkia 2021-03-23 12:10:33 +08:00 服务器还在用 centos7，之前尝鲜升级到 8，结果一堆兼容问题，然后又退回去了。踩过的众多坑告诉我，不要在生产环境下手贱去尝鲜新事物，可能是习惯了这种保守策略，导致我连普通软件只要能用就非常抗拒升级，否则少不了乱七八糟的各种毛病。 |
| 68 xuegy OP @abbottcn 管理员说我是全校唯一一个需要编译 C++的。别人要么用现成的商业软件要么就是 python 练丹师。他手册里编译器那页写那么长就我一个人在看... |
| 69 abbottcn 2021-03-23 12:21:21 +08:00 via iPhone @xuegy 只要支持 singularity 就可以了。 在自己机器上编译处理完毕，拷贝上去就可用了。我认为特别好用。 我把它当作可以秒开的虚拟机，网络用户啥都不用考虑，数据还在原来地方，只是环境不同了。 前一秒还是 c7，后一秒可能就是 apt 可用可。 我个人认为，这是针对科学计算方面十分优秀的解决方案。 |
| 72 sadfQED2 2021-03-23 12:56:41 +08:00 via Android @chenqh php 的项目，php5.4，而且 php 还自己写了很多 c 扩展，nginx 又加了些 lua 扩展啥的。导致这么多年来根本没人敢动 |
 | 75 yanqiyu 2021-03-25 16:31:59 +08:00 编译的时候发生混沌 /软件包版本混沌有个很直接的解决方案：自己搭建 dist-git/koji 等一套软件包编译打包系统。软件包管理就能解决找出没有被满足的依赖、以及提示冲突的老包。而不是一股脑 make install，然后谁也不记得哪些文件是哪些软件的。 并且上游有包(印象中 openmpi 就在 centos 有打包)并且能满足需求就直接用呗。就算是 CERN 的集群都有安装 EPEL 包...虽然大家用软件都是直接去 cvmfs 上面 source 的。 |
Select Language