基于华为云 FlexusX 四节点集群的云计算全栈实操（一）：开篇与自动化运维基建

基于华为云 FlexusX 四节点集群的云计算全栈实操（一）：开篇与自动化运维基建

系列定位：这是「基于华为云 FlexusX 四节点集群的云计算全栈实操」系列的第一篇。后续会从 IaaS 一路打到 PaaS、云原生，最后落到 AI 工作负载。本篇先把实验室搭起来，并解决一个最现实的痛点——怎么在本地没有sshpass的情况下，依然能优雅地批量操作用四台云主机。

0. 引子：为什么我坚持把「云计算」学在真机器上

很多人学云计算，止步于在本地用 Vagrant 起几台虚拟机、敲几条kubectl。这当然有用，但它和「真实云」之间隔着三道墙：

1. 没有真实的网络拓扑。VPC、子网、安全组、弹性公网 IP（EIP），这些只有在云上才会逼你真正理解。
2. 没有真实的性能边界。本地虚拟机的磁盘是宿主机的文件，CPU 是分时复用，iops=10000这种数字对你来说只是文档里的一句话。
3. 没有真实的成本意识。云是按量计费的，每一台开机的主机都在烧钱——这会反向逼你把自动化、一键启停、一键回收做得扎实。

极客时间《深入浅出云计算》里反复强调一个观点：云计算的「计算」二字，本质是对算力、存储、网络三类资源的虚拟化与调度。要把这句话学透，只有一条路：自己买四台云主机，亲手把这套资源拼起来、压满、再拆掉。

本系列就干这件事。我用华为云 FlexusX 实例，开了 4 个节点，组成一个可用于后续 IaaS / PaaS / 云原生 / AI 实验的集群。本篇先把「地基」打好。

1. 实验环境

所有节点位于同一 VPC、同一子网（192.168.0.0/24），内网互通；每个节点同时绑定一个弹性公网 IP 用于从本地运维。

统一机型为x2e.8u.16g（FlexusX 柔性算力），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-p'1qaz@WSX'sshroot@113.47.6.41'uptime'

在我的本地环境里sshpass不存在，且不想为了一个实验去改系统的包管理。于是我换了一条更可控的路：用 Python3 + paramiko 自己写两个小工具。好处有三：

1. 不污染系统环境，依赖装到独立目录；
2. paramiko 比sshpass更灵活（支持 SFTP 的--put/--get）；
3. 代码完全可控，后续并发、重试、结构化输出都能改。

3.1 用 pip install --target 把依赖装进独立目录

# 在本地项目根目录建立独立依赖库mkdir-pdeps pipinstall--target=deps paramiko# 调用时通过 PYTHONPATH 引用，不污染全局 site-packagesPYTHONPATH=deps python tools/ssh_run.py n1'uptime'

关键在于--target=deps：paramiko 及其依赖（bcrypt、cryptography、pynacl 等）全部落到deps/，运行时用PYTHONPATH=deps注入即可。这和「虚拟环境」的区别是：它更轻，不需要activate，适合塞进脚本和 CI。

4. 工具一：ssh_run.py —— 单节点与顺序多节点

ssh_run.py解决三件事：在单节点执行命令、在all上顺序执行、以及文件收发。核心结构如下（节选自tools/ssh_run.py）：

importsys,paramiko PASSWORD="1qaz@WSX"USER="root"NODES={"n1":"113.47.6.41",# private 192.168.0.252"n2":"124.70.93.52",# private 192.168.0.64"n3":"1.94.220.182",# private 192.168.0.241"n4":"124.70.102.139",# private 192.168.0.150}defget_client(host):c=paramiko.SSHClient()c.set_missing_host_key_policy(paramiko.AutoAddPolicy())# 实验环境自动信任c.connect(host,username=USER,password=PASSWORD,timeout=30,banner_timeout=30,auth_timeout=30)returncdefrun(host,cmd,timeout=1800):c=get_client(host)try:stdin,stdout,stderr=c.exec_command(cmd,timeout=timeout,get_pty=False)out=stdout.read().decode("utf-8","replace")err=stderr.read().decode("utf-8","replace")rc=stdout.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 一变只改一处。

用法：

# 单节点执行PYTHONPATH=deps python tools/ssh_run.py n1'uptime'# 四节点顺序执行同一条命令PYTHONPATH=deps python tools/ssh_run.py all'cat /etc/os-release | head -1'# 推送脚本到所有节点PYTHONPATH=deps python tools/ssh_run.py n3--putscripts/fio_bench.sh /root/fio_bench.sh# 拉回结果PYTHONPATH=deps 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():sel=sys.argv[1]# "n1,n2,n3,n4" 或 "all"cmd=sys.argv[2]targets=list(NODES.keys())ifsel=="all"elsesel.split(",")results={}# max_workers 等于节点数，一节点一线程，真正并行withconcurrent.futures.ThreadPoolExecutor(max_workers=len(targets))asex:fut={ex.submit(run,NODES[t],cmd):tfortintargets}forfinconcurrent.futures.as_completed(fut):# 谁先返回先处理谁t=fut[f]try:results[t]=f.result()exceptExceptionase:results[t]=(-1,"",str(e))# 最后按 targets 顺序打印，输出稳定可 difffortintargets:rc,o,e=results[t]print(f"\n===== [{t}{NODES[t]}] exit={rc}=====")ifo:print(o,end=""ifo.endswith("\n")else"\n")ife:print("[stderr]",e,end=""ife.endswith("\n")else"\n")

三个设计要点：

1. 为什么用线程池而不是多进程？paramiko 的connect/exec_command是网络 IO 密集型，线程在 IO 等待时让出 GIL，四节点的并发毫无压力；进程池反而更重。
2. max_workers=len(targets)：节点就 4 个，每个分配一个线程，简单且够用；若将来管上百台，应改成固定大小的池（如 32）避免打爆本地。
3. 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. 小结

本篇我们完成了三件事：

1. 明确了「为什么要在真云主机上学云计算」，并选定华为云 FlexusX 柔性算力作为实验底座；
2. 用pip install --target+PYTHONPATH绕开了「本地无 sshpass」的坑，把 paramiko 装进独立目录；
3. 自己写了ssh_run.py（顺序/单点/收发）和fanout.py（线程池并行），搭好了可一键批量运维的实验室地基。

下一篇，我们用sysbench给这 4 台云虚拟机做一场 CPU 与内存的「深度体检」，看看柔性算力的真实成色。