企业官网建设流程全解析

1. 先把方案定下来：平台选型、节点规模与网络拓扑

1.1 为什么这套组合至今仍然值得用

用 VMware Workstation Pro 16 搭一套 CentOS 8 虚拟机集群，说白了就是在一台物理机上用软件“造”出三到五台互相能通的服务器，用来做分布式练习、主从复制实验、集群中间件部署这些活。我在带新人的时候基本都用这套组合起步，原因是它的门槛足够低：不需要额外的物理机，不需要采购服务器，一台 16G 内存的笔记本就能跑起来三个节点，关机快照一打，实验环境随时能回滚到干净状态。

Workstation Pro 16 这个版本有几个实际好用的点。一是它对硬件版本的支持比较新，虚拟机可以开到 18 及以上的硬件版本，对多核、大内存的调度比老版本顺畅；二是快照管理和克隆功能做得比较成熟，一台配好的“模板机”能快速复制出整个集群；三是虚拟网络编辑器可以自己规划子网和 DHCP 范围，这对集群来说很关键，因为集群里的机器必须用固定 IP，不能让 DHCP 随机分配。

CentOS 8 作为操作系统，选它有历史和生态的原因。它的包管理用 dnf，和 yum 命令基本兼容，systemd、firewalld、NetworkManager 这套组合和主流企业发行版一致，学到的操作习惯可以平滑迁移。需要提前说清楚的一点是，CentOS 8 的生命周期已经结束，官方主镜像不再维护，默认的 yum 源大概率是拉不动的，后面第 4 节会专门讲怎么把源换到归档地址，这一步不做，后面所有装包操作都会卡住。

适合看这篇内容的人大概分三类：一是刚开始接触 Linux 集群概念，想在自己电脑上把环境跑起来的；二是需要一套可反复销毁重建的实验环境，做数据库主从、消息队列集群、容器编排前置练习的；三是想搞清楚虚拟机克隆、网络规划这些“环境工程”细节的。整套流程不需要你提前懂集群软件，但基本的 Linux 命令得会敲。

1.2 节点数量与资源分配的计算过程

集群节点数不是拍脑袋定的。做最小可用的分布式实验，三台是最常见的起点，因为多数集群软件的心智模型就是“多数派”，三节点能容忍一台挂掉，两节点反而容易出现脑裂判断的尴尬。如果你的目标是练容器编排或者分布式存储，三台是底线；如果只是练主从复制、负载均衡这类，两台也能凑合，但很多演示效果出不来。

资源分配要做一道简单的算术题。假设宿主机是 16G 内存、8 核 CPU：

这个配置刚好卡在临界点上，宿主机只剩 4G 左右给系统和其他软件，浏览器多开几个标签页就开始转圈。我的建议是：宿主机内存 16G 时，节点内存压到 3G，或者干脆把节点数减到两台做入门；宿主机有 32G 的话，三节点各给 4G 甚至 6G 都毫无压力。

CPU 这块有个常见的误区，就是觉得“我给虚拟机多分点核，它就跑得快”。实际不是这样。虚拟机分到的 vCPU 是要宿主机真实核心来调度的，如果你给三台虚拟机各分 4 核，总共有 12 个 vCPU 抢 8 个物理核心，结果就是 CPU 就绪时间飙升，虚拟机里的操作会明显发涩。稳妥的做法是总 vCPU 数不超过物理核心数的 1.2 倍，每台给 2 核是比较舒服的配比。

磁盘容量也要留够。CentOS 8 最小安装大概占 2G 出头，加上后续装中间件、存日志、放数据，20G 是起步线。如果打算在同一套集群上练容器和镜像仓库，单台给到 40G 更从容。另外注意，完整克隆三台机器意味着宿主机磁盘上会实打实多出 60G 以上的占用，克隆之前先看一眼宿主机剩余空间，别等到克隆到一半才提示磁盘不足。

1.3 网络模式选型：NAT、桥接还是仅主机

这是整套方案里最容易被忽略、但后期最折磨人的一环。Workstation Pro 提供三种主要网络模式，各自的适用场景差别很大。

对集群练习来说，NAT 模式是最省心的选择。虚拟机共享宿主机的网络出口，装包、拉镜像、访问外部服务都不受影响，同时又和宿主机所在的局域网隔离开，不会因为虚拟机的 IP 和公司网络里的设备冲突而被网管找上门。桥接模式虽然能让虚拟机看起来像局域网里的一台真机，但它会占用局域网 IP 段，一旦你的笔记本换了办公地点，IP 网段变了，之前配好的静态 IP 全部失效，得逐个改，很麻烦。仅主机模式适合做完全隔离的环境，但代价是虚拟机上不了外网，装包得靠本地镜像源，前期准备成本高。

用 NAT 模式要记住两个关键数字。打开虚拟网络编辑器，能看到 VMnet8 的子网地址和 NAT 设置。默认情况下 NAT 网关地址是子网里的.2，比如子网是192.168.100.0/24，网关就是192.168.100.2。DHCP 的地址池默认从.128开始到.254，也就是说.1到.127这段是留给静态 IP 的。规划集群 IP 时就往这段里挑，比如.11、.12、.13，既不会和 DHCP 撞车，也不会和网关冲突。这个细节不注意，你配好静态 IP 用了几天，某天宿主机重启后 DHCP 把同一个地址分给了别的虚拟机，就会出现“莫名其妙连不上”的情况。

如果后期想更进一步，可以给每台虚拟机加第二块网卡，走仅主机模式 VMnet1，专门承载集群内部通信。这样外网流量走 NAT，节点之间的数据同步走内网，互不干扰，也更接近真实机房的网络分层。这个做法在第 3 节会展开。

2. 宿主机准备与第一台“模板机”的落地

2.1 宿主机上必须先做的三项检查

很多人卡在第一步，不是不会装，而是装完发现虚拟机性能差得离谱，或者“虚拟化引擎”那个选项灰掉点不动。这类问题的根源基本都在宿主机层面，装系统之前先检查三件事，能省掉后面大半的折腾。

第一件事，确认宿主机没有启用相互冲突的虚拟化功能。Windows 系统上如果开了“虚拟机监控程序平台”“虚拟机平台”这类功能，Workstation 就无法直接接管 CPU 的虚拟化指令，会退化成用户态模拟模式，性能直接掉一大截。表现就是开机慢、CPU 占用高、想勾选嵌套虚拟化选项时提示不支持。处理办法是在系统的“启用或关闭功能”里把相关项取消勾选，重启后再开 Workstation。同时留意一下内核隔离、内存完整性这类安全特性，它们也可能影响虚拟化指令的可用性。

第二件事，确认 VT-x 或 AMD-V 已经在固件里打开。任务管理器里能看到“虚拟化：已启用”才算过关。如果显示已禁用，需要进固件设置里找对应开关，通常叫虚拟化技术、虚拟化支持之类。这一步不过关，虚拟机连正常安装都跑不起来，更别说勾选嵌套虚拟化。

第三件事，把虚拟机存储目录规划好。默认情况下虚拟机会放在系统盘的用户目录下，三台机器加上快照，几十上百 G 的空间很快就吃满了。建议在空间充裕的非系统盘上建一个专门的目录，比如命名为集群实验，然后在 Workstation 的偏好设置里把默认虚拟机位置改到那里。这样后续所有克隆都落在正确的盘上，也不用担心系统盘爆掉导致整台电脑卡死。

2.2 CentOS 8 安装过程中的关键选择

安装介质从归档站点下载即可，选择 DVD 版的 ISO 镜像比较省事，它自带基础软件包，装完不用立刻联网。下载完成后校验一下文件完整性，镜像损坏导致安装中途报错的情况并不少见，尤其是在网络不稳定的环境里下的包。

新建虚拟机时，Workstation 会问你用哪种安装方式。这里选“稍后安装操作系统”，不要用自动安装或者简易安装。自动安装会套用一套它认为合理的默认配置，分区方案、软件包选择都由它决定，后期想改回来很麻烦。手动走一遍安装流程，虽然多点几下，但你能控制每一个关键参数。

进入 Anaconda 安装界面后，有四个地方的设置值得停下来想一想。

其一是安装源和软件选择。软件选择里选“最小安装”还是“带 GUI 的服务器”，取决于你的用途。集群节点通常是纯命令行的，选最小安装就够，装完系统干净、占用少、没有一堆用不上的服务在后台跑。需要图形界面的场景才选带桌面的选项，但代价是内存占用高、开机慢，三台一起开的时候宿主机压力会很明显。

其二是分区方案。选自动分区也能用，但自动分区往往会给你弄出一个体积不太合理的根分区。手动分区的话，/boot给 1G，交换分区给 2G，剩下的全给根分区，用 xfs 文件系统，这是 CentOS 8 默认的搭配，稳定且够用。如果你的机器内存给到了 4G 以上，交换分区甚至可以只给 1G 或者干脆不要，因为集群里通常更希望通过配置调整来避免频繁换页，而不是靠交换分区硬扛。

其三是网络和主机名。安装界面的右下角可以先把主机名改好，比如node01，并且把网卡开关打开。这里打开之后会触发 DHCP 分配地址，虽然集群最终要用静态 IP，但安装阶段能在线拉包会方便很多。如果打算装完立刻换源，也可以先在这里把网络配通。

其四是根密码和用户。集群环境里我习惯直接设置 root 密码并允许 root 登录，省得每次操作都加 sudo。这只是实验环境的选择，正式环境应该建普通用户并配置提权。密码别设太简单，某些系统策略会校验复杂度，设得太弱会卡在安装最后一步过不去。

2.3 模板机装完立刻要做的五件收敛动作

装完重启之后，这台机器还不叫“模板机”，只能叫“装好了系统的机器”。想要它配得上模板这两个字，得先做一轮收敛，把后面批量复制时会出问题的地方提前处理掉。

第一件，把软件源换到归档地址。这个动作放在最前面，因为后面所有装包操作都依赖它。CentOS 8 的默认源指向的地址已经不提供服务了，直接执行装包命令会报找不到仓库或者超时。具体怎么改，第 4 节会给完整的配置文件内容，这里先记住这个顺序：换源 → 清理缓存 → 重新生成缓存，三步做完再干别的。

第二件，装上常用的基础工具。最小安装的系统里连vim、wget、net-tools、bash-completion这些都没有，不装的话后面每一步都会别扭。一条命令批量装掉：

dnf install -y vim wget curl net-tools bash-completion lsof tar unzip

装bash-completion之后记得重新登录一次 shell，命令补全才生效，很多人装完发现补全没反应就是没重连。

第三件，处理安全策略。实验环境里 firewalld 和 SELinux 经常是各种“服务起不来”“端口访问不到”的元凶，我一般在模板机阶段就把它们调成宽松状态，减少干扰。防火墙用systemctl disable --now firewalld停掉并禁止开机自启，SELinux 临时用setenforce 0切到宽容模式，再把配置文件里的默认值改成 permissive，重启后依然生效：

setenforce 0 sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config

注意，这只是实验环境的取舍。如果你的集群练习本身就包含安全加固环节，那这两项应该保留并且按规范配置端口放行规则，别图省事全关掉。

第四件，安装虚拟机增强工具。它能让虚拟机和宿主机之间的时间同步更准、鼠标切换更顺、剪贴板共享可用。命令很简单：

dnf install -y open-vm-tools

如果装了图形界面，再补一个open-vm-tools-desktop。纯命令行环境只装前者就够了，装桌面版反而会带进一堆图形依赖。

第五件，清理痕迹并关机。删掉安装日志、清空命令历史、把临时文件清干净，然后执行关机。关机之后再给这台机器拍一个快照，命名为“模板基线”。这个快照的价值在于：后面克隆出来的所有节点如果被玩坏了，你可以随时从这个基线重新克隆，而不用再走一遍安装流程。

dnf clean all history -c poweroff

关机状态下的克隆和快照，文件一致性最好，不会出现内存里的脏数据被复制过去的问题。养成“关机再克隆”的习惯，能避免很多玄学问题。

3. 克隆出整个集群并打通网络

3.1 完整克隆与链接克隆怎么选

Workstation 提供两种克隆方式，选错了后期会很别扭，值得单独说清楚。

集群节点我强烈建议用完整克隆。原因很直接：链接克隆的磁盘是分层的，读数据的时候要一层层往回找，节点多了以后 I/O 会有可感知的延迟，而且只要父机的磁盘文件被动过或者被删掉，整条克隆链上的机器全部起不来。集群练习往往要跑好几个月，链接克隆这种脆弱性不值得省那点磁盘。

完整克隆的操作路径是在虚拟机关机状态下，右键虚拟机 → 管理 → 克隆 → 选择“虚拟机中的当前状态” → 选择“创建完整克隆” → 指定名称和存放位置。名称建议直接用节点名，比如node02、node03，存放位置放到同一个父目录下，方便统一管理。

克隆数量按你的规划来。三节点集群就克隆两台，加上原来的模板机正好三台。克隆过程会复制磁盘文件，20G 的盘大概需要几分钟，期间宿主机磁盘会有明显的写入压力，别同时开着别的大文件操作。

3.2 克隆后必改的四样东西

克隆出来的机器是“双胞胎”，如果什么都不改就直接开机联网，会出现各种诡异现象：IP 冲突、主机名混乱、SSH 连上去发现连的不是以为的那台。有四样东西必须在开机后第一时间改掉。

第一样是主机名。用hostnamectl set-hostname node02设置，改完重新登录一次 shell 才会在提示符里体现。同时要把/etc/hosts里对应本机 IP 的那一行也改掉，否则有些服务解析自己的名字时会拿到旧值。

第二样是机器标识。这个文件是很多系统服务的唯一标识来源，克隆后三台机器如果标识相同，会出现日志混淆、DHCP 客户端标识重复、某些授权类服务判断异常等问题。处理方式：

truncate -s 0 /etc/machine-id systemd-machine-id-setup

执行完可以用cat /etc/machine-id确认三台机器各不相同。

第三样是 MAC 地址。克隆时 Workstation 一般会自动重新生成 MAC，但保险起见还是检查一下。在虚拟机的设置里找到网络适配器，点高级，看看 MAC 地址是否和原机不同，如果相同就点“生成”换一个。MAC 相同而 IP 不同，在同一个虚拟网络里会造成交换表混乱，表现为时通时不通。

第四样是网卡配置文件。克隆后最常见的情况是：网卡的实际设备名变了，比如原来是ens33，克隆后变成了ens37，但 NetworkManager 里还是那个叫ens33的连接配置，于是nmcli connection show看到配置存在，ip addr却看不到 IP。这个问题在 5.2 节会给出完整的排查和修复步骤，这里先记住：看到“配置在但 IP 没有”，八成就是网卡名对不上。

3.3 静态 IP 与双网卡规划

IP 规划要在动手之前定好，写在纸上或者记在文档里，不要边配边想。以 VMnet8 子网192.168.100.0/24、网关.2为例：

配置命令用nmcli最稳妥，CentOS 8 上 NetworkManager 是默认网络管理组件，用命令行改配置比手写配置文件不容易出错：

nmcli connection modify ens33 \ ipv4.method manual \ ipv4.addresses 192.168.100.11/24 \ ipv4.gateway 192.168.100.2 \ ipv4.dns 114.114.114.114 \ connection.autoconnect yes nmcli connection up ens33

参数逐个解释一下。ipv4.method manual表示手动配置，不走 DHCP；ipv4.addresses里的/24是子网掩码，不能省；ipv4.gateway填虚拟网络编辑器里看到的 NAT 网关地址，填错了就上不了外网；connection.autoconnect yes保证开机自动启用。配置完用ip addr和ping验证，先 ping 网关，再 ping 一个外部地址，两步都通说明网络没问题。

如果你打算用双网卡方案，给每台虚拟机加一块仅主机模式的网卡，子网设成192.168.200.0/24，宿主机上不配网关。这样集群内部通信走192.168.200.x这个网段，外网访问走192.168.100.x。这么做的好处是：集群节点之间大量数据同步时不会挤占 NAT 通道，而且即使宿主机断网，节点之间的通信依然正常，实验可以继续做。

提示，双网卡配置时要注意路由优先级。如果两个网段都有默认网关，可能出现流量走错网卡的情况。仅主机网卡不要配网关，让它只承担同网段通信即可。

3.4 主机名解析与 SSH 免密

集群里的机器要互相认识，靠 IP 记太累，配好 hosts 文件是最省事的办法。三台机器的/etc/hosts都加上同样的内容：

cat >> /etc/hosts <<'EOF' 192.168.100.11 node01 192.168.100.12 node02 192.168.100.13 node03 EOF

加完之后用ping node02测试，能通说明解析生效。这一步在集群软件部署时非常关键，很多集群组件默认用主机名做节点标识，主机名解析不通会直接导致节点加入失败。

SSH 免密是另一个必做项。集群部署脚本、批量分发文件、节点间互信，都依赖免密登录。生成密钥对：

ssh-keygen -t rsa -b 4096 -N "" -f /root/.ssh/id_rsa

-N ""表示不设密码短语，方便脚本自动执行。然后把公钥分发到所有节点，包括本机：

for h in node01 node02 node03; do ssh-copy-id -i /root/.ssh/id_rsa.pub root@$h done

分发过程中会要求输入各节点的 root 密码，输一次就行。全部完成后用ssh node03 hostname测试，如果不需要密码就直接返回了主机名，说明配置成功。

实操心得，ssh-copy-id偶尔会因为目标机的/root/.ssh目录权限不对而失败。如果提示权限问题，先在目标机上执行chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys再重试。

配置完成后建议把/root/.ssh目录整个打包备份一份，后面如果重新克隆节点，直接解压就能恢复免密关系，不用再走一遍分发流程。

4. 让集群“像一个整体”：环境统一化配置

4.1 yum 源失效后的替代配置

这一步是所有后续操作的前提。CentOS 8 的主镜像服务早已停止，默认仓库地址访问会失败，症状是dnf install卡住很久然后报“无法下载元数据”或者超时。解决办法是把仓库地址指向归档站点。

先备份原有配置，避免改错了没法回退：

mkdir -p /etc/yum.repos.d/bak mv /etc/yum.repos.d/CentOS-*.repo /etc/yum.repos.d/bak/

然后写一份新的仓库配置：

cat > /etc/yum.repos.d/CentOS-Vault.repo <<'EOF' [baseos] name=CentOS-8-BaseOS baseurl=https://vault.centos.org/8.5.2111/BaseOS/x86_64/os/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial enabled=1 [appstream] name=CentOS-8-AppStream baseurl=https://vault.centos.org/8.5.2111/AppStream/x86_64/os/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial enabled=1 [extras] name=CentOS-8-Extras baseurl=https://vault.centos.org/8.5.2111/extras/x86_64/os/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial enabled=1 EOF

8.5.2111是 CentOS 8 最后一个归档版本号，路径必须精确匹配，写错了会返回 404。三个仓库分工不同：BaseOS 放系统核心包，AppStream 放应用层软件包，Extras 放补充工具，三个都配齐才不会出现“某个包明明存在却装不上”的情况。

配置完刷新缓存：

dnf clean all dnf makecache

如果makecache报证书错误，先检查系统时间是否准确，时间偏差过大会导致 TLS 握手失败，这是新手最常踩的坑之一。用date看一眼，如果时间差了好几年，先手动校准再重试。

提示，归档站点在境外，拉取速度可能不理想。部分国内开源镜像站也保留了归档目录，可以把baseurl换成对应的国内地址，速度会快不少。换之前先确认该镜像站确实保留了8.5.2111这个版本目录。

这台机器的源配好并且验证通过之后，再去做克隆，后续所有节点天然就是可用的。这个顺序很关键，先克隆再配源，就得重复配三遍。

4.2 内网时间同步

集群里时间不一致是隐形杀手。表现是：SSH 免密突然要求输密码、日志时间戳对不上排查困难、集群组件之间心跳检测失败、证书校验报错。宿主机休眠唤醒之后，虚拟机时钟跑偏是常事，多台机器各跑各的，偏差会越来越大。

解决办法是选一台机器做内网时间服务器，其他机器向它同步。选 node01 做服务端，编辑它的时间同步配置：

vim /etc/chrony.conf

把默认的服务器列表注释掉，改成能被外部同步的地址，同时允许内网段来同步：

server ntp.aliyun.com iburst allow 192.168.100.0/24 local stratum 10

iburst表示启动时快速发几个包加快同步；allow放开内网段的查询权限；local stratum 10是个兜底配置，意思是即使外部源全部不可达，这台机器也能把自己当作一个较低层级的时间源对外提供服务。这一行在实际使用中很有用，因为你的宿主机可能经常断网，没有这一行的话，断网期间客户端会同步失败。

node02 和 node03 的配置更简单，只指向 node01：

server 192.168.100.11 iburst

三台机器都执行启动并设置开机自启：

systemctl enable --now chronyd

在客户端上用chronyc sources -v查看同步状态，看到 node01 那一行前面有个星号就表示同步成功。刚配置完可能需要等几十秒，不用急着判断失败。

注意，如果你之前改过系统时间做测试，记得把时间调回来再启用同步。chrony 默认会拒绝与偏差过大的源同步，时间差太多时需要加makestep参数强制跳变，具体做法是在配置文件里加一行makestep 1.0 -1。

4.3 安全策略与基础工具的统一

模板机阶段已经处理过一次安全策略，克隆出来的节点会继承这些设置，理论上不用再动。但有两件事需要在集群层面补一下。

一是确认三台机器的防火墙状态一致。有些人在某台机器上手动开了端口，另一台忘了开，结果集群部署时一台能通一台不通，排查半天。统一用systemctl status firewalld看一眼，三台结果应该一样。

二是如果选择保留防火墙（比如你的实验包含安全配置环节），那就要在每台机器上放行集群需要的端口。以常见的集群通信为例：

firewall-cmd --permanent --add-port=22/tcp firewall-cmd --permanent --add-port=6443/tcp firewall-cmd --permanent --add-port=2379-2380/tcp firewall-cmd --permanent --add-port=10250-10252/tcp firewall-cmd --reload

端口号按你实际要部署的组件来定，这里只是举例说明写法。放行后别忘了--reload，不重载配置是不生效的，这个细节漏掉的人特别多。

基础工具的统一也值得花两分钟。三台机器上装同一套工具，避免出现“这台有telnet那台没有”的尴尬：

dnf install -y vim wget curl net-tools lsof tar unzip tree bash-completion

如果打算做容器相关练习，还得把交换分区关掉并调整内核参数，这部分内容超出本次范围，但思路是一样的：所有节点做同样的操作，别只改一台。

4.4 虚拟机工具与快照策略

open-vm-tools在模板机阶段已经装了，克隆后不用重装，但要确认服务在跑：

systemctl status vmtoolsd

正常应该是运行状态。如果没起来，systemctl enable --now vmtoolsd拉起来即可。这个服务负责虚拟机和宿主机之间的信息交换，时间同步、优雅关机、IP 地址上报都靠它，停掉的话在 Workstation 界面里就看不到虚拟机的 IP 了，管理起来很不方便。

快照策略这件事，踩过坑的人才知道重要。我的做法是分三层：

最关键的一条经验是：快照不是备份，不要长期挂着不删。快照文件记录的是磁盘变化量，你用的时间越长、写入越多，快照文件就越大，最后可能比原磁盘还大。我见过有人挂了一年多的快照，虚拟机跑得越来越慢，磁盘占用翻了几倍才发现问题。

另一个细节是拍快照的时机。关机状态拍快照最干净，恢复后不会出现文件系统不一致的问题；运行状态拍快照速度快，但恢复后可能有些服务需要手动重启。做关键组件的实验前，我会选择关机拍快照，多花十几秒换来的稳定性是值得的。

4.5 交付前的集群验收清单

环境搭完，别急着往上装软件，先跑一遍验收，确认基础是牢的。这一步花五分钟，能省掉后面几小时的排查。

这张表里我特别想强调的是机器标识和 MAC 地址这两项。它们平时不显眼，但一旦出问题，症状会非常迷惑，比如日志里两台机器的记录混在一起，或者 SSH 连上去发现操作的是另一台机器。养成克隆后先检查这两项的习惯，能少走很多弯路。

5. 踩坑记录：常见问题与排查路径

5.1 网络类问题的定位思路

网络问题占了我在这套环境上排查时间的一大半，但绝大多数都能通过一个固定的顺序定位出来。

先看链路层通不通：ip link看网卡是不是 UP 状态。如果显示DOWN，说明网卡没启用，用nmcli connection up 连接名拉起来。这一步没解决，后面所有检查都是白费。

再看有没有拿到 IP：ip addr看对应网卡下有没有inet那一行。如果没有，回到 NetworkManager 里查配置。常见原因是配置写在了ens33上，但实际网卡叫ens37，配置根本没生效。

然后看网关通不通：ping 网关地址。不通的话检查虚拟网络编辑器里的 NAT 子网和网关设置，以及虚拟机的网络适配器是不是连到了正确的 VMnet。

最后看外网通不通：ping 一个外部 IP。如果 IP 能通但域名不通，那是 DNS 配置的问题，检查/etc/resolv.conf或者nmcli里的 DNS 设置。如果 IP 也不通，回到上一步查网关。

这个顺序的价值在于，它把“网络不通”这个大问题拆成了四个小判断，每一步都有明确的通过或不通过，不会陷入“到底是哪出问题了”的盲目猜测。

还有一种情况是“时通时不通”，这通常和 IP 冲突有关。三个节点如果用的是克隆出来的同一份配置，又有某台没改 IP，就会出现两个设备抢同一个地址。排查方法是挨个ping一下规划中的 IP，对比 MAC 地址对不对得上，或者干脆在虚拟网络编辑器里看 DHCP 租约列表，确认没有设备占用你规划给静态 IP 的地址。

5.2 克隆后的网卡名错位

这是克隆操作里最高频的问题，值得单独展开。症状很典型：开机后nmcli connection show能看到一个叫ens33的连接，状态是已激活，但ip addr里只能看到lo，没有任何 IP 地址。

原因在于，克隆时 Workstation 重新生成了网卡，设备名从ens33变成了ens37（或者别的编号），但 NetworkManager 里的那份连接配置还绑在旧的接口名上，于是配置悬空了，新网卡没有配置可用，自然拿不到 IP。

处理办法有两种。稳妥一点的做法是删掉旧配置，按新网卡名重建：

nmcli connection delete ens33 nmcli connection add type ethernet ifname ens37 con-name ens37 \ ipv4.method manual \ ipv4.addresses 192.168.100.12/24 \ ipv4.gateway 192.168.100.2 \ ipv4.dns 114.114.114.114 nmcli connection up ens37

另一种做法是直接修改现有配置的接口绑定，保留原有设置省得重配一遍：

nmcli connection modify ens33 connection.interface-name ens37 nmcli connection up ens33

实操心得，改完之后如果nmcli connection show里出现两个连接同时抢同一个网卡，会导致行为不确定。改之前先nmcli connection show确认只有一份配置对应这块物理网卡，多余的删掉。

还有一种更彻底的做法，是把网卡命名规则改成传统的eth0风格，这样无论怎么克隆名字都固定。做法是在内核启动参数里加net.ifnames=0 biosdevname=0，改完重启。这个方案适合喜欢固定命名的人，但要注意配置文件里的网卡名全都要跟着改，否则又是一轮排查。

5.3 软件源与时间类问题

软件源相关的报错有几种典型形态，认准了修起来很快。

报“无法下载元数据，已超出超时”或者连接超时，说明 baseurl 地址不可达，检查路径拼写、检查网络是否通、检查是否用了正确的归档版本号。用curl -I 仓库地址可以直接测通不通，比在 dnf 里等超时快得多。

报“SSL 证书校验失败”，九成是系统时间不对。TLS 握手依赖时间戳，时间偏差太大就直接拒绝。date看一眼，不对劲先手动改成大致正确的时间，再跑时间同步。这个问题在刚克隆完、还没配时间同步的阶段特别容易遇到，因为它本身就卡在“先配源还是先配时间”的死循环里。解法是先手动执行date -s "2024-01-01 12:00:00"设一个大致正确的时间，让证书能过，然后立刻把时间同步配好。

报“没有启用的仓库”，说明 repo 文件没有被识别。检查文件是否放在/etc/yum.repos.d/目录下、后缀是不是.repo、文件权限是否可读。用dnf repolist能看到当前识别到的仓库列表，如果列表是空的，问题一定在配置文件本身。

时间同步的问题则通常是“看起来配好了但不同步”。chronyc sources -v里如果源那一行前面是?，说明无法连接；如果是^开头的一大串，说明还在同步过程中。最常见的失败原因是防火墙挡住了 123 端口，或者配置文件里的allow网段写错了。还有一种情况是 chrony 服务在跑，但配置文件根本没被读取，那就要检查是不是改错了文件路径。

5.4 常见问题速查表

把上面这些经验整理成一张表，遇到问题先对照着看，比从零开始想快得多：

6. 长期使用中的资源优化与维护经验

环境搭好只是开始，真正决定这套集群好不好用的是后续怎么维护。我在这上面折腾了挺久，攒了几条比较实在的经验。

内存是最先见底的资源。三台虚拟机各 4G，加上宿主机系统，16G 的机器跑起来会很紧。有个技巧是在不用的节点上临时降配，比如平时只开两台，第三台用的时候再开。Workstation 允许在关机状态下调整内存大小，改完下次启动生效，不需要重装系统。如果只是偶尔验证一下集群拓扑，可以把节点内存降到 2G，跑完再改回来。

磁盘方面，虚拟磁盘默认是“按需分配”，实际占用会随着使用慢慢涨上去，但上限是你设置的容量。三台 20G 的盘，长期用下来实际占用可能在 25G 到 40G 之间，还算可控。真正吃空间的是快照，一个挂了半年的快照可能比原盘还大。养成习惯：实验做完就检查一下虚拟机目录下的文件大小，异常膨胀的第一时间处理。

网络方面，如果长期用这套环境，建议在宿主机上把 VMnet8 的 DHCP 服务关掉，全部用静态 IP 管理。DHCP 开着虽然方便，但和静态 IP 混用迟早出冲突。关闭位置在虚拟网络编辑器的 NAT 设置里，取消勾选 DHCP 服务即可。关掉之后所有虚拟机必须配静态 IP，所以要在确认三台都配好之后再关，顺序别搞反。

还有一个容易被忽略的点是宿主机的休眠。笔记本合盖休眠再唤醒之后，虚拟机的时钟往往会跑偏，如果时间同步没配好，就会出现各种莫名其妙的认证失败。我现在的做法是：时间同步一定要配，而且 node01 的配置文件里加了local stratum 10兜底，这样即使宿主机断网，内网时间同步依然能工作，不会因为外部时间源不可达而导致整个集群时间乱套。

最后分享一个批量操作的小技巧。三台机器重复做同样的操作很浪费时间，可以用一个简单的循环批量执行：

for h in node01 node02 node03; do echo "===== $h =====" ssh $h "hostnamectl; date; dnf repolist | head -5" done

把要检查的命令塞进引号里，一条命令就能拿到三台机器的对比结果，排查问题时比自己挨个登录快得多。这套免密登录配好之后，能玩的花样还有很多，比如批量分发文件、批量重启服务，本质上就是把重复劳动交给脚本。我个人在实际操作中的体会是，环境搭建阶段多花半小时把免密和 hosts 配扎实，后面几个月的实验能省下几十次的重复输入。