基于华为云 FlexusX 四节点集群的云计算全栈实操一开篇与自动化运维基建系列定位这是「基于华为云 FlexusX 四节点集群的云计算全栈实操」系列的第一篇。后续会从 IaaS 一路打到 PaaS、云原生最后落到 AI 工作负载。本篇先把实验室搭起来并解决一个最现实的痛点——怎么在本地没有sshpass的情况下依然能优雅地批量操作用四台云主机。0. 引子为什么我坚持把「云计算」学在真机器上很多人学云计算止步于在本地用 Vagrant 起几台虚拟机、敲几条kubectl。这当然有用但它和「真实云」之间隔着三道墙没有真实的网络拓扑。VPC、子网、安全组、弹性公网 IPEIP这些只有在云上才会逼你真正理解。没有真实的性能边界。本地虚拟机的磁盘是宿主机的文件CPU 是分时复用iops10000这种数字对你来说只是文档里的一句话。没有真实的成本意识。云是按量计费的每一台开机的主机都在烧钱——这会反向逼你把自动化、一键启停、一键回收做得扎实。极客时间《深入浅出云计算》里反复强调一个观点云计算的「计算」二字本质是对算力、存储、网络三类资源的虚拟化与调度。要把这句话学透只有一条路自己买四台云主机亲手把这套资源拼起来、压满、再拆掉。本系列就干这件事。我用华为云 FlexusX 实例开了 4 个节点组成一个可用于后续 IaaS / PaaS / 云原生 / AI 实验的集群。本篇先把「地基」打好。1. 实验环境所有节点位于同一 VPC、同一子网192.168.0.0/24内网互通每个节点同时绑定一个弹性公网 IP 用于从本地运维。节点弹性公网 IP私有 IP规格系统node1113.47.6.41192.168.0.2528vCPU/16GiBUbuntu 24.04.4 LTSnode2124.70.93.52192.168.0.648vCPU/16GiBUbuntu 24.04.4 LTSnode31.94.220.182192.168.0.2418vCPU/16GiBUbuntu 24.04.4 LTSnode4124.70.102.139192.168.0.1508vCPU/16GiBUbuntu 24.04.4 LTS统一机型为x2e.8u.16gFlexusX 柔性算力KVM 虚拟化。后续sysbench探测到的 CPU 标识为General Purpose Processor 2.0GHz拓扑为Thread(s) per core: 2 × Core(s) per socket: 4 × Socket(s): 1即 4 个物理核、8 个逻辑线程开启超线程。2. 关于华为云 FlexusX 柔性算力选型时的几点判断FlexusX 是华为云的「柔性算力」实例族强调按需自定义 vCPU 与内存配比。我选 x2e.8u.16g 这个规格出于三个考量算力密度够后续用8 vCPU / 16GiB 在四节点上就是 32 vCPU / 64GiB 的总池子足够跑 K8s 控制面 几个 worker 一组压测工具。柔性配比不浪费钱很多业务内存吃紧但 CPU 闲柔性算力允许你按真实比例选而不是被标准型 1:2/1:4 的框死。够便宜做实验相比独占型实例FlexusX 属于共享/弹性调度单位算力成本更低适合「开机跑完就关」的实验节奏。观点对于学习型和 CI 型负载柔性算力 一键开关机比「买一台高配常驻」划算得多。真正的云成本优化第一刀永远砍在「不该开机的时段」上。3. 痛点本地没有 sshpass怎么办自动化运维的第一步是能从本地一键在多台机器上执行命令。最常见的做法是sshpass ssh# 理想中的一行流——但本机没有 sshpasssshpass-p1qazWSXsshroot113.47.6.41uptime在我的本地环境里sshpass不存在且不想为了一个实验去改系统的包管理。于是我换了一条更可控的路用 Python3 paramiko 自己写两个小工具。好处有三不污染系统环境依赖装到独立目录paramiko 比sshpass更灵活支持 SFTP 的--put/--get代码完全可控后续并发、重试、结构化输出都能改。3.1 用 pip install --target 把依赖装进独立目录# 在本地项目根目录建立独立依赖库mkdir-pdeps pipinstall--targetdeps paramiko# 调用时通过 PYTHONPATH 引用不污染全局 site-packagesPYTHONPATHdeps python tools/ssh_run.py n1uptime关键在于--targetdepsparamiko 及其依赖bcrypt、cryptography、pynacl 等全部落到deps/运行时用PYTHONPATHdeps注入即可。这和「虚拟环境」的区别是它更轻不需要activate适合塞进脚本和 CI。4. 工具一ssh_run.py —— 单节点与顺序多节点ssh_run.py解决三件事在单节点执行命令、在all上顺序执行、以及文件收发。核心结构如下节选自tools/ssh_run.pyimportsys,paramiko PASSWORD1qazWSXUSERrootNODES{n1:113.47.6.41,# private 192.168.0.252n2:124.70.93.52,# private 192.168.0.64n3:1.94.220.182,# private 192.168.0.241n4:124.70.102.139,# private 192.168.0.150}defget_client(host):cparamiko.SSHClient()c.set_missing_host_key_policy(paramiko.AutoAddPolicy())# 实验环境自动信任c.connect(host,usernameUSER,passwordPASSWORD,timeout30,banner_timeout30,auth_timeout30)returncdefrun(host,cmd,timeout1800):cget_client(host)try:stdin,stdout,stderrc.exec_command(cmd,timeouttimeout,get_ptyFalse)outstdout.read().decode(utf-8,replace)errstderr.read().decode(utf-8,replace)rcstdout.channel.recv_exit_status()# 必须读才拿得到真实退出码returnrc,out,errfinally:c.close()几个值得说一下的设计点set_missing_host_key_policy(AutoAddPolicy())实验环境 IP 会变、会重建没必要维护known_hosts自动接受最省心。生产环境请务必换成RejectPolicy并预置指纹。recv_exit_status()不能省exec_command返回的stdout不会主动告诉你命令成没成功必须读 channel 的退出状态否则你永远以为命令成功了。节点别名n1..n4与 IP 解耦代码里NODES用别名做 key真实运维时敲n1比敲 IP 舒服太多IP 一变只改一处。用法# 单节点执行PYTHONPATHdeps python tools/ssh_run.py n1uptime# 四节点顺序执行同一条命令PYTHONPATHdeps python tools/ssh_run.py allcat /etc/os-release | head -1# 推送脚本到所有节点PYTHONPATHdeps python tools/ssh_run.py n3--putscripts/fio_bench.sh /root/fio_bench.sh# 拉回结果PYTHONPATHdeps python tools/ssh_run.py n1--get/root/fiotest/result.txt ./results/--put/--get走 SFTP靠open_sftp()拿到句柄后put/get逻辑很直白这里不再贴全文。5. 工具二fanout.py —— 用线程池并行扇出ssh_run.py all是顺序执行的四台机器一台跑完再下一台。做批量运维时这太慢了尤其命令本身要跑 20 秒比如后面的 fio 压测顺序执行就是 80 秒。于是有了fanout.py——用ThreadPoolExecutor把命令同时扇出到所有节点importsys,concurrent.futures,paramikodefmain():selsys.argv[1]# n1,n2,n3,n4 或 allcmdsys.argv[2]targetslist(NODES.keys())ifselallelsesel.split(,)results{}# max_workers 等于节点数一节点一线程真正并行withconcurrent.futures.ThreadPoolExecutor(max_workerslen(targets))asex:fut{ex.submit(run,NODES[t],cmd):tfortintargets}forfinconcurrent.futures.as_completed(fut):# 谁先返回先处理谁tfut[f]try:results[t]f.result()exceptExceptionase:results[t](-1,,str(e))# 最后按 targets 顺序打印输出稳定可 difffortintargets:rc,o,eresults[t]print(f\n [{t}{NODES[t]}] exit{rc})ifo:print(o,endifo.endswith(\n)else\n)ife:print([stderr],e,endife.endswith(\n)else\n)三个设计要点为什么用线程池而不是多进程paramiko 的connect/exec_command是网络 IO 密集型线程在 IO 等待时让出 GIL四节点的并发毫无压力进程池反而更重。max_workerslen(targets)节点就 4 个每个分配一个线程简单且够用若将来管上百台应改成固定大小的池如 32避免打爆本地。as_completed 末尾按targets顺序输出并发返回顺序不确定但打印时按n1..n4重排保证每次运行输出格式一致方便做文本 diff 与归档。实测一条uptime在 4 节点上并行跑端到端耗时≈单节点耗时而不是 4 倍——这就是「fanout」的意义。6. 观点为什么不用 Ansible 也能轻量自动化你可能会问都批量运维了为啥不直接上 Ansible我的看法是——对「实验型 / 一次性 / 强定制」的云上实验室自写的 100 行 paramiko 工具反而更合适Ansible 需要 inventory、playbook、模块心智模型学习成本摊到 4 台机器上不划算我们需要的常常是「在这 4 台上一句同样的 shell」fanout 一行搞定结果文件results/*.txt是我们自己拼的字符串后续做数据解析/画图最方便依赖只有 paramiko且能装进独立目录不碰系统。一句话Ansible 适合「生产环境的声明式配置管理」paramiko 小工具适合「实验环境的命令式批量执行」。二者不矛盾分场景用。等系列进展到要长期维护 K8s 集群时我会认真评估引入 Ansible/Ansible Playbook 的时机。7. 后续系列全景路线图本系列会按照「由底向上、由浅入深」的顺序推进IaaS 层本篇所在层 ├─ (1) 开篇与自动化运维基建 ← 你在这里 ├─ (2) 云虚拟机性能基准CPU/内存 └─ (3) 云硬盘 IO 压测fio / IOPS / 吞吐 PaaS 层 ├─ 对象存储 / 块存储实战 ├─ 负载均衡与弹性伸缩 └─ 数据库上云RDS vs 自建 云原生层 ├─ 四节点 K8s 集群搭建kubeadm ├─ 网络CNI、存储CSI深入 └─ 可观测性监控 / 日志 / 链路 AI 层 ├─ GPU/算力调度跑推理 └─ 模型服务化与弹性部署每一篇都会像本篇一样真实环境 真实命令 真实数据 我的判断不会给你一段跑不通的 demo。8. 配套脚本../tools/ssh_run.py单/多节点命令执行、文件收发--put/--get。../tools/fanout.py基于ThreadPoolExecutor的并行扇出同时操作 4 节点。../scripts/fio_bench.sh云硬盘 fio 全场景压测脚本下一篇会用到。9. 小结本篇我们完成了三件事明确了「为什么要在真云主机上学云计算」并选定华为云 FlexusX 柔性算力作为实验底座用pip install --targetPYTHONPATH绕开了「本地无 sshpass」的坑把 paramiko 装进独立目录自己写了ssh_run.py顺序/单点/收发和fanout.py线程池并行搭好了可一键批量运维的实验室地基。下一篇我们用sysbench给这 4 台云虚拟机做一场 CPU 与内存的「深度体检」看看柔性算力的真实成色。
基于华为云 FlexusX 四节点集群的云计算全栈实操（一）：开篇与自动化运维基建
基于华为云 FlexusX 四节点集群的云计算全栈实操一开篇与自动化运维基建系列定位这是「基于华为云 FlexusX 四节点集群的云计算全栈实操」系列的第一篇。后续会从 IaaS 一路打到 PaaS、云原生最后落到 AI 工作负载。本篇先把实验室搭起来并解决一个最现实的痛点——怎么在本地没有sshpass的情况下依然能优雅地批量操作用四台云主机。0. 引子为什么我坚持把「云计算」学在真机器上很多人学云计算止步于在本地用 Vagrant 起几台虚拟机、敲几条kubectl。这当然有用但它和「真实云」之间隔着三道墙没有真实的网络拓扑。VPC、子网、安全组、弹性公网 IPEIP这些只有在云上才会逼你真正理解。没有真实的性能边界。本地虚拟机的磁盘是宿主机的文件CPU 是分时复用iops10000这种数字对你来说只是文档里的一句话。没有真实的成本意识。云是按量计费的每一台开机的主机都在烧钱——这会反向逼你把自动化、一键启停、一键回收做得扎实。极客时间《深入浅出云计算》里反复强调一个观点云计算的「计算」二字本质是对算力、存储、网络三类资源的虚拟化与调度。要把这句话学透只有一条路自己买四台云主机亲手把这套资源拼起来、压满、再拆掉。本系列就干这件事。我用华为云 FlexusX 实例开了 4 个节点组成一个可用于后续 IaaS / PaaS / 云原生 / AI 实验的集群。本篇先把「地基」打好。1. 实验环境所有节点位于同一 VPC、同一子网192.168.0.0/24内网互通每个节点同时绑定一个弹性公网 IP 用于从本地运维。节点弹性公网 IP私有 IP规格系统node1113.47.6.41192.168.0.2528vCPU/16GiBUbuntu 24.04.4 LTSnode2124.70.93.52192.168.0.648vCPU/16GiBUbuntu 24.04.4 LTSnode31.94.220.182192.168.0.2418vCPU/16GiBUbuntu 24.04.4 LTSnode4124.70.102.139192.168.0.1508vCPU/16GiBUbuntu 24.04.4 LTS统一机型为x2e.8u.16gFlexusX 柔性算力KVM 虚拟化。后续sysbench探测到的 CPU 标识为General Purpose Processor 2.0GHz拓扑为Thread(s) per core: 2 × Core(s) per socket: 4 × Socket(s): 1即 4 个物理核、8 个逻辑线程开启超线程。2. 关于华为云 FlexusX 柔性算力选型时的几点判断FlexusX 是华为云的「柔性算力」实例族强调按需自定义 vCPU 与内存配比。我选 x2e.8u.16g 这个规格出于三个考量算力密度够后续用8 vCPU / 16GiB 在四节点上就是 32 vCPU / 64GiB 的总池子足够跑 K8s 控制面 几个 worker 一组压测工具。柔性配比不浪费钱很多业务内存吃紧但 CPU 闲柔性算力允许你按真实比例选而不是被标准型 1:2/1:4 的框死。够便宜做实验相比独占型实例FlexusX 属于共享/弹性调度单位算力成本更低适合「开机跑完就关」的实验节奏。观点对于学习型和 CI 型负载柔性算力 一键开关机比「买一台高配常驻」划算得多。真正的云成本优化第一刀永远砍在「不该开机的时段」上。3. 痛点本地没有 sshpass怎么办自动化运维的第一步是能从本地一键在多台机器上执行命令。最常见的做法是sshpass ssh# 理想中的一行流——但本机没有 sshpasssshpass-p1qazWSXsshroot113.47.6.41uptime在我的本地环境里sshpass不存在且不想为了一个实验去改系统的包管理。于是我换了一条更可控的路用 Python3 paramiko 自己写两个小工具。好处有三不污染系统环境依赖装到独立目录paramiko 比sshpass更灵活支持 SFTP 的--put/--get代码完全可控后续并发、重试、结构化输出都能改。3.1 用 pip install --target 把依赖装进独立目录# 在本地项目根目录建立独立依赖库mkdir-pdeps pipinstall--targetdeps paramiko# 调用时通过 PYTHONPATH 引用不污染全局 site-packagesPYTHONPATHdeps python tools/ssh_run.py n1uptime关键在于--targetdepsparamiko 及其依赖bcrypt、cryptography、pynacl 等全部落到deps/运行时用PYTHONPATHdeps注入即可。这和「虚拟环境」的区别是它更轻不需要activate适合塞进脚本和 CI。4. 工具一ssh_run.py —— 单节点与顺序多节点ssh_run.py解决三件事在单节点执行命令、在all上顺序执行、以及文件收发。核心结构如下节选自tools/ssh_run.pyimportsys,paramiko PASSWORD1qazWSXUSERrootNODES{n1:113.47.6.41,# private 192.168.0.252n2:124.70.93.52,# private 192.168.0.64n3:1.94.220.182,# private 192.168.0.241n4:124.70.102.139,# private 192.168.0.150}defget_client(host):cparamiko.SSHClient()c.set_missing_host_key_policy(paramiko.AutoAddPolicy())# 实验环境自动信任c.connect(host,usernameUSER,passwordPASSWORD,timeout30,banner_timeout30,auth_timeout30)returncdefrun(host,cmd,timeout1800):cget_client(host)try:stdin,stdout,stderrc.exec_command(cmd,timeouttimeout,get_ptyFalse)outstdout.read().decode(utf-8,replace)errstderr.read().decode(utf-8,replace)rcstdout.channel.recv_exit_status()# 必须读才拿得到真实退出码returnrc,out,errfinally:c.close()几个值得说一下的设计点set_missing_host_key_policy(AutoAddPolicy())实验环境 IP 会变、会重建没必要维护known_hosts自动接受最省心。生产环境请务必换成RejectPolicy并预置指纹。recv_exit_status()不能省exec_command返回的stdout不会主动告诉你命令成没成功必须读 channel 的退出状态否则你永远以为命令成功了。节点别名n1..n4与 IP 解耦代码里NODES用别名做 key真实运维时敲n1比敲 IP 舒服太多IP 一变只改一处。用法# 单节点执行PYTHONPATHdeps python tools/ssh_run.py n1uptime# 四节点顺序执行同一条命令PYTHONPATHdeps python tools/ssh_run.py allcat /etc/os-release | head -1# 推送脚本到所有节点PYTHONPATHdeps python tools/ssh_run.py n3--putscripts/fio_bench.sh /root/fio_bench.sh# 拉回结果PYTHONPATHdeps python tools/ssh_run.py n1--get/root/fiotest/result.txt ./results/--put/--get走 SFTP靠open_sftp()拿到句柄后put/get逻辑很直白这里不再贴全文。5. 工具二fanout.py —— 用线程池并行扇出ssh_run.py all是顺序执行的四台机器一台跑完再下一台。做批量运维时这太慢了尤其命令本身要跑 20 秒比如后面的 fio 压测顺序执行就是 80 秒。于是有了fanout.py——用ThreadPoolExecutor把命令同时扇出到所有节点importsys,concurrent.futures,paramikodefmain():selsys.argv[1]# n1,n2,n3,n4 或 allcmdsys.argv[2]targetslist(NODES.keys())ifselallelsesel.split(,)results{}# max_workers 等于节点数一节点一线程真正并行withconcurrent.futures.ThreadPoolExecutor(max_workerslen(targets))asex:fut{ex.submit(run,NODES[t],cmd):tfortintargets}forfinconcurrent.futures.as_completed(fut):# 谁先返回先处理谁tfut[f]try:results[t]f.result()exceptExceptionase:results[t](-1,,str(e))# 最后按 targets 顺序打印输出稳定可 difffortintargets:rc,o,eresults[t]print(f\n [{t}{NODES[t]}] exit{rc})ifo:print(o,endifo.endswith(\n)else\n)ife:print([stderr],e,endife.endswith(\n)else\n)三个设计要点为什么用线程池而不是多进程paramiko 的connect/exec_command是网络 IO 密集型线程在 IO 等待时让出 GIL四节点的并发毫无压力进程池反而更重。max_workerslen(targets)节点就 4 个每个分配一个线程简单且够用若将来管上百台应改成固定大小的池如 32避免打爆本地。as_completed 末尾按targets顺序输出并发返回顺序不确定但打印时按n1..n4重排保证每次运行输出格式一致方便做文本 diff 与归档。实测一条uptime在 4 节点上并行跑端到端耗时≈单节点耗时而不是 4 倍——这就是「fanout」的意义。6. 观点为什么不用 Ansible 也能轻量自动化你可能会问都批量运维了为啥不直接上 Ansible我的看法是——对「实验型 / 一次性 / 强定制」的云上实验室自写的 100 行 paramiko 工具反而更合适Ansible 需要 inventory、playbook、模块心智模型学习成本摊到 4 台机器上不划算我们需要的常常是「在这 4 台上一句同样的 shell」fanout 一行搞定结果文件results/*.txt是我们自己拼的字符串后续做数据解析/画图最方便依赖只有 paramiko且能装进独立目录不碰系统。一句话Ansible 适合「生产环境的声明式配置管理」paramiko 小工具适合「实验环境的命令式批量执行」。二者不矛盾分场景用。等系列进展到要长期维护 K8s 集群时我会认真评估引入 Ansible/Ansible Playbook 的时机。7. 后续系列全景路线图本系列会按照「由底向上、由浅入深」的顺序推进IaaS 层本篇所在层 ├─ (1) 开篇与自动化运维基建 ← 你在这里 ├─ (2) 云虚拟机性能基准CPU/内存 └─ (3) 云硬盘 IO 压测fio / IOPS / 吞吐 PaaS 层 ├─ 对象存储 / 块存储实战 ├─ 负载均衡与弹性伸缩 └─ 数据库上云RDS vs 自建 云原生层 ├─ 四节点 K8s 集群搭建kubeadm ├─ 网络CNI、存储CSI深入 └─ 可观测性监控 / 日志 / 链路 AI 层 ├─ GPU/算力调度跑推理 └─ 模型服务化与弹性部署每一篇都会像本篇一样真实环境 真实命令 真实数据 我的判断不会给你一段跑不通的 demo。8. 配套脚本../tools/ssh_run.py单/多节点命令执行、文件收发--put/--get。../tools/fanout.py基于ThreadPoolExecutor的并行扇出同时操作 4 节点。../scripts/fio_bench.sh云硬盘 fio 全场景压测脚本下一篇会用到。9. 小结本篇我们完成了三件事明确了「为什么要在真云主机上学云计算」并选定华为云 FlexusX 柔性算力作为实验底座用pip install --targetPYTHONPATH绕开了「本地无 sshpass」的坑把 paramiko 装进独立目录自己写了ssh_run.py顺序/单点/收发和fanout.py线程池并行搭好了可一键批量运维的实验室地基。下一篇我们用sysbench给这 4 台云虚拟机做一场 CPU 与内存的「深度体检」看看柔性算力的真实成色。
