第8章 虚拟化与服务器硬件（实施核心竞争力章）

对应简历：技能第3条「熟练掌握 FusionCompute + DME 虚拟化平台交付：CNA / VRM 安装、RAID 规划、集群与分布式交换机配置、虚拟机批量发放与统一纳管」；技能第4条「具备 TaiShan 国产服务器上架经验，熟悉 iBMC 远程安装与硬件问题排查」；技能第1条「独立完成国产化平台从硬件上架到系统交付的全流程实施」；项目一 P1-1「iBMC 远程安装 CNA / VRM（RAID 规划、网络与时区配置），完成集群、分布式交换机与端口组配置及 15+ 台虚拟机批量发放，DME 22.0 统一纳管」。 实施版定位：全量保留并扩写——虚拟化与硬件是实施工程师的核心竞争力。本章在原底稿（运维版第 8 章）基础上新增四块实施专属内容：上架 checklist（8.12）、RAID/规格决策框架（8.13）、割接前环境验证清单（8.14）、DME 交接要点（8.15）。 华为产品深挖引用（不重复展开）：鲲鹏/TaiShan 规格 → 华为篇第 1 章；FusionCompute 安装全流程 → 华为篇第 2 章；DME 部署对接 → 华为篇第 3 章；iBMC/CE 交换机/双平面组网 → 华为篇第 7 章。 本章全部为项目一（某大型银行数字人民币智能合约引擎国产化部署）真实经历，4 台 TaiShan 2280 + FusionCompute 8.3.0 + DME 22.0，细节可放心讲。术语：FusionCompute 下文简称 FC。

8.1 虚拟化概念与 Hypervisor 两类 【必背】

标准回答： 一句话说，虚拟化就是把一台物理服务器的 CPU、内存、存储、网络这些硬件资源抽象出来池化，再切分成多台相互隔离的虚拟机共同使用。它解决的是三个问题：一是提高资源利用率，一台 96 核的物理机如果只跑一个应用，大部分算力是浪费的，切成十几台虚拟机就能把资源吃满；二是交付快，新建一台业务机器从"采购上架装系统"的周级变成点几下鼠标的分钟级——这对实施交付尤其重要，项目工期紧的时候，资源交付速度就是交付进度；三是隔离和统一管理，每台虚拟机有独立的操作系统和配额，互不影响，还可以统一做快照、迁移和高可用。支撑这一切的核心软件叫 Hypervisor，也就是虚拟机监控器，它负责把物理资源切分调度给各个虚拟机。Hypervisor 分两类：一类是裸金属型（Type 1），直接跑在物理硬件上，不依赖宿主操作系统，性能好、稳定性高，生产数据中心用的都是它，比如华为的 CNA、VMware 的 ESXi、微软的 Hyper-V；另一类是宿主型（Type 2），是装在 Windows 或 Linux 之上的一个应用程序，虚拟机性能损耗大，一般只用于个人电脑和学习实验，比如 VMware Workstation、VirtualBox。我在银行项目里部署的 FusionCompute，它的计算节点 CNA 就是典型的裸金属型——整个操作系统就只做虚拟化这一件事，装完就是一个 Hypervisor。

追问链：

• 追问1：CPU 虚拟化具体靠什么实现的？ → 答：靠硬件辅助虚拟化，Intel 叫 VT-x，AMD 叫 AMD-V，ARM 架构上也有对应的虚拟化扩展。原理是 CPU 提供了根模式和非根模式，敏感指令直接陷入 Hypervisor 处理，不再需要早期二进制翻译的全模拟方案，所以现代虚拟化的性能损耗能控制在很低水平。这也是为什么装 CNA 或开 KVM 之前要在 iBMC/BIOS 里确认虚拟化开关是打开的——装机前检查项之一。
• 追问2：全虚拟化和半虚拟化有什么区别？ → 答：全虚拟化对客户机操作系统完全透明，虚拟机里的系统不知道自己跑在虚拟机上，敏感操作由硬件辅助捕获交给 Hypervisor 处理；半虚拟化要求客户机装上特殊的驱动、知道自己被虚拟化了，主动走优化过的 IO 通道，代表就是 KVM 里的 virtio 网卡和磁盘。生产上最常见的组合是"硬件辅助的全虚拟化 + virtio 半虚拟化 IO"，计算用全虚拟化保证兼容，IO 用 virtio 换性能。
• 迭问3：为什么银行这种客户一定要用虚拟化而不是一台物理机跑一个业务？ → 答：第一是资源利用率，银行业务系统多但单个负载不一定重，十几台虚拟机共享四台物理机成本和机房空间都省；第二是高可用，虚拟机可以热迁移、可以 HA，物理机坏了虚拟机在别的机器上拉起来，容灾比纯物理机灵活太多；第三是交付效率，试点业务要扩容，发一台虚拟机是分钟级，采购物理机是周级——第三条对实施岗尤其实在：我们项目 15 台虚拟机的规模，如果没有虚拟化底座，光等机器到货项目就得往后拖几周。

8.2 KVM 与 VMware 要点（口径：熟悉） 【理解】

标准回答： 先说 KVM：它是 Linux 内核内置的虚拟化模块，本身只负责 CPU 和内存的虚拟化，依赖硬件辅助虚拟化；设备仿真靠 QEMU 完成，管理面靠 libvirt 这一层，上层用 virsh 命令行或者 virt-manager 图形界面操作。它是开源免费的，OpenStack 和华为 FusionCompute 底层用的都是 KVM 技术，所以说我在银行项目操作 FC，本质上就是在用华为把 KVM 这套东西产品化封装后的平台——这个认知让我在 FC 出问题时知道往哪一层去想。再说 VMware vSphere，它是商业闭源套件，架构三件套：ESXi 是装在物理机上的裸金属 Hypervisor，vCenter 是集中管理节点，vSphere Client 是 Web 管理入口。两个生态的概念可以一一对照，面试里主动把对照关系说出来是加分项：ESXi 对应华为的 CNA，vCenter 对应 VRM，vSphere 的分布式交换机 vDS 对应 FC 的 DVS。我在生产上实际操作的是 FusionCompute；KVM 原生这块我在课程实验里做过完整练习——virt-install 命令行装虚拟机、配桥接网络、做快照和克隆——所以 FC 底下的原理我是能串起来的，不是只会点 Web 页面。

追问链：

• 迭问1：KVM 里虚拟机网卡有几种模式？ → 答：三种。NAT 是默认模式，虚拟机借宿主机的网络地址转换出网；桥接模式是把虚拟机网卡通过 bridge 设备直接桥到物理网络，虚拟机拿到和宿主同网段的 IP，像一台独立物理机，生产环境基本都用这种；仅主机模式是虚拟机只能和宿主机通不出网，用于隔离测试。银行项目里虚拟机走的是分布式交换机的端口组，本质就是桥接到物理网络并打上 VLAN 标签。
• 迭问2（兜底话术示范）：被问 KVM 内存气球、大页这类细节 → 答："生产上我用的是封装好的 FusionCompute，KVM 原生这块我课程实验做过基本操作，内存气球这类细节我理解到它是做内存超额分配、可回收空闲内存的思路，更深的实现细节可以会后补。"诚实给边界，不装懂。

8.3 FusionCompute 架构：CNA 与 VRM 【必背】

标准回答： FusionCompute 是华为基于 KVM 做的服务器虚拟化平台，架构上就两个核心角色：CNA 和 VRM。CNA 的全称是 Compute Node Agent，计算节点代理，安装在每一台物理服务器上，是裸金属型的 Hypervisor，虚拟机的实际运行、计算存储网络三类资源的虚拟化都在 CNA 上落地。VRM 的全称是 Virtual Resource Manager，虚拟资源管理节点，是管理角色，负责集群管理、资源调度、虚拟机生命周期管理，还有 HA 和热迁移这些高级特性的编排，日常操作的 Web 管理入口就是 https://VRM的IP:8443。银行项目的实际部署是 CNA 三台加 VRM 一台，都是物理机部署；VRM 本身支持主备部署对外提供浮动 IP，也支持单节点用管理平面 IP，我们项目规模用的是单节点。这套架构给我印象最深的一点是管理面和数据面分离：VRM 挂了，跑在 CNA 上的虚拟机一点不受影响，只是新建虚拟机、迁移、打开控制台这些管理操作暂时不可用。这个设计后来我在 Kubernetes 里又见到一次——apiserver 挂了业务 Pod 照样跑，两个体系是同一个思想，我面试时喜欢拿这个对比讲，能体现出我是理解了架构而不是背了架构。

追问链：

• 迭问1：VRM 挂了虚拟机会不会停？ → 答：不会停。已经在 CNA 上运行的虚拟机继续正常跑，业务不受影响，受影响的只是管理面——新建虚拟机、热迁移、快照、打开 VNC 控制台这些操作会失败，等 VRM 恢复后自动续上。这也是我在真机上验证过的行为，答这个题我有底气。处理思路就是先确认业务无影响，再去排查 VRM 节点本身的网络、进程和磁盘。
• 迭问2：FC 和 DCS 是什么关系？ → 答：DCS 是数据中心虚拟化解决方案的缩写，是 FC 加上 DME 等组件组合成的整体方案名。我们项目的建设方案文档里就写的是"通过 TaiShan 服务器和 CE 交换机构建物理环境，用 FC 8.3.0 加 DME Data 构造 DCS 虚拟化平台"，虚拟机由这个平台统一发放、统一管理、统一监控。简单说 FC 是虚拟化本体，DME 是运维管理面，两者打包叫 DCS——DME 的产品全景见华为篇第 3 章 3.2。
• 迭问3：VRM 为什么要用浮动 IP？ → 答：主备部署的两台 VRM 共享一个浮动 IP，主节点持有它，主挂了备节点接管浮动 IP，管理员始终访问同一个地址，不用关心当前谁是主。这个思路和我后来在 Nginx + Keepalived 里做的 VIP 漂移、Vastbase 的数据库浮动地址是一回事——"一个虚拟地址加故障切换"是高可用设计的经典模式，我在第 3、4 章都回指过它。

8.4 FusionCompute 安装流程（iBMC 挂 ISO → cnaInit/vrmInit） 【必背】

标准回答： 这套流程我完整做过，六步讲。第一步先做 RAID：系统盘两块 600G SAS 组 RAID1，数据盘 3.84T 的 SSD 组 RAID5，注意 TaiShan 2280 这款机器不带 RAID 卡，是在安装过程中组软 RAID（规划依据见 8.9，决策框架见 8.13）。第二步用 iBMC 远程装系统：登录 iBMC 的 Web 管理页面，打开虚拟控制台，把本地的 ISO 镜像挂载成虚拟光驱——CNA 一个 ISO、VRM 一个 ISO，都是 ARM_64 版本，挂上之后把虚拟光驱连接起来再重启机器从光驱引导。第三步是安装向导里的配置：选安装目标逻辑盘比如 /dev/sda，配管理平面网络给 eth0 配规划好的管理 IP（不划分 VLAN 就选非 VLAN 模式），再设主机名如 CNA_01、时区、root 密码和 grub 密码；装 VRM 时还多一步选密码算法模式——0 是国际算法 1 是国密，这个只能设一次、装完不能改，必须提前和银行客户对好口径，金融客户一般要求国密——FC 里的这类"不可逆项"清单见华为篇第 2 章 2.6.1。第四步装完自动重启，root 登录后执行初始化：CNA 节点跑 cnaInit，VRM 节点跑 vrmInit，设置 gandalf 用户密码、Portal 端密码、高斯 Postgres 密码、Galax 密码这几套密码（建议设成一致的便于交付交接时移交），一直等到回显 "The VRM is initialized successfully" 才算完成。第五步浏览器登录 https://VRM浮动IP:8443 做软件初始化：加载 License、配 MAC 地址段（默认即可）、配 NTP 时钟源和时区。第六步进资源初始化：创建集群、添加 CNA 主机、添加存储、创建网络资源（8.5 展开）。整个流程我后来沉淀进了《智能合约引擎安装部署指南》，成为公司的标准实施文档——每一步的截图、参数、注意事项都在里面，同事照着能复现。

追问链：

• 迭问1：装 CNA 之前要做哪些检查？ → 答：我会过一张检查单：iBMC 能正常登录、虚拟控制台能打开、键盘布局切好；对应架构的安装镜像拿到了（ARM 机器必须是 ARM_64 版本）；磁盘 RAID 已经按规划划好；管理 IP、主机名、root 密码、管理 VLAN 都和规划表核对过。这些前置检查不到位，装到一半返工是最浪费时间的——"装机检查表"华为篇第 2 章 2.4.1 有一屏版。
• 迭问2：装完之后想改网络配置怎么办？ → 答：在 CNA 节点的终端执行 /usr/bin/hostconfig 命令可以重新配置网络。但有个限制要注意：管理平面的 IP 类型安装之后就不支持切换了，所以装之前必须把管理平面的规划和网络团队对清楚——这是实施文档里专门标红的注意事项，也是"环境规划阶段要多花时间"的最好例证（第 15 章 15.3）。
• 迭问3：iBMC 装系统踩过什么真实的坑？ → 答：键盘布局的坑。iBMC 虚拟控制台默认是英文键盘布局，进安装向导后方向键会失灵、菜单选不了，一开始以为是浏览器或者 Java 版本问题，后来发现要把虚拟控制台的键盘布局切换成日语（Japanese）才能正常操作。这个坑我写进了部署指南的注意事项，后面同事再去实施就没再踩——坑变成文档条目，就是实施经验的公司化。
• 迭问4：为什么时区和 NTP 要在初始化阶段就配好？ → 答：因为虚拟化平台、数据库、K8s 集群这些上层系统全都依赖时间一致，时间不同步会造成证书校验失败、数据库主备复制异常、日志时间戳对不上这些莫名其妙的问题。所以我在流程里把 NTP 时钟源配置放在很靠前的位置，虚拟机发放出来之后第一件事也是配时间同步——这条和第 1 章 1.2 初始化基线、第 6 章 K8s 避坑清单是同一条纪律在不同层的体现。

实操模板（安装检查单，可直接背）：

□ iBMC 可访问、虚拟控制台可打开、键盘布局切好（日语布局防方向键失灵）
□ RAID：系统盘 RAID1 / 数据盘 RAID5（TaiShan 2280 软 RAID，Disk Cache Policy=Disabled）
□ 镜像：FusionCompute_CNA-8.3.0-ARM_64.iso / FusionCompute_VRM-8.3.0-ARM_64.iso
□ 规划信息：管理 IP、主机名、时区、root/grub 密码、密码算法模式（0 国际/1 国密，只可设一次）
□ 安装 → 重启 → cnaInit / vrmInit 初始化（等到回显 initialized successfully）
□ https://VRM-IP:8443 登录 → License → MAC 段 → NTP

8.5 集群、分布式交换机与端口组 【必背】

标准回答： 装完 CNA 和 VRM 之后就是资源初始化，四件事按顺序做。第一件创建集群，把多台 CNA 主机组成一个统一的资源池，集群级别把 HA 打开，这样某台主机故障时它上面的虚拟机会自动在集群里其他 CNA 上重新拉起。第二件添加主机，把装好的 CNA 用它的管理 IP 和 root 密码一台台加进集群。第三件添加存储资源，扫描本地磁盘或对接专用存储，创建数据存储，虚拟机的磁盘文件就放在数据存储上。第四件创建网络资源，这是最有讲究的一步：先建分布式交换机 DVS，它是横跨所有 CNA 主机的一台"虚拟交换机"；然后给 DVS 添加上行链路，把物理网卡绑定上去，打通虚拟网络和物理网络；最后在 DVS 上创建端口组，每个端口组绑定一个 VLAN ID，虚拟机的网卡挂到哪个端口组，就自动进入哪个 VLAN 的网络。一句话概括三者关系：DVS 是全集群统一的虚拟交换机，上行链路是它伸向物理网络的出口，端口组是带 VLAN 标签的虚拟网口模板。银行项目里我按网络规划表建了管理、业务等好几个端口组，十五台虚拟机的网卡分别挂到对应端口组上，网络隔离一次到位，客户网络团队验收也是按这张表核对的——网络规划和 IP 规划表在实施前期就要和网络团队对定，这是我在第 15 章 15.3 环境规划阶段的核心产出之一。

追问链：

• 迭问1：一个端口组不配 VLAN，能通到什么范围？ → 答：只能和同一个端口组内的虚拟机二层互通。要跨 VLAN、跨网段通信，必须经过三层设备，要么是物理交换机的 VLANIF 接口做网关，要么是路由器。所以做隔离规划时，端口组的 VLAN 划分本身就是第一道隔离措施——这也是客户安全团队认可的隔离设计。
• 迭问2：HA 生效的前提条件是什么？ → 答：两个前提：一是虚拟机磁盘放在共享存储上，这样主机坏了别的 CNA 才能读到它的磁盘把它拉起来；二是发放虚拟机时没有勾选"与所选主机绑定"——勾了绑定等于指定这台虚拟机只能在这台主机跑，HA 就失效了，这两个条件互斥。我批量发放那十五台虚拟机时特别注意了这个勾选项，除了一台明确要绑定主机的之外都没勾——这种细节就是"发放检查单"存在的意义。
• 迭问3：为什么用分布式交换机，而不是每台主机单独配标准虚拟交换机？ → 答：核心是配置一次、全集群生效。分布式交换机的配置保存在 VRM 上，所有 CNA 共享同一份网络策略，虚拟机从主机 A 热迁移到主机 B，网络配置原样跟着走，不用在目标主机重新配；如果是每台主机各配各的，不仅工作量大，还容易出现某台配置漂移导致迁移后网络不通的问题。这个思路和 K8s 里网络插件统一管 Pod 网络是一个道理——网络策略要跟着资源走，不能跟着物理位置走。

实操模板（FC 资源初始化顺序，可背）：

1 登录 https://VRM浮动IP:8443
2 License 加载 → MAC 地址段（默认）→ NTP/时区
3 创建集群（开启 HA）
4 添加主机：录入 CNA 管理IP/root 密码，逐台加入
5 存储：扫描存储设备 → 添加数据存储
6 网络：创建 DVS → 添加上行链路 → 创建端口组（按规划逐个 VLAN）
7 验证：集群下主机"运行中"、数据存储容量正确、端口组列表齐全

8.6 虚拟机发放流程 【理解】

标准回答： 发放虚拟机的前提是集群、数据存储、端口组三样资源就绪，然后流程是：在资源池上右键创建虚拟机，先做基本配置填名称选位置——这里有个关键选项是选集群还是选具体主机：选集群等于让平台随机调度、可以享受 HA，选具体主机可以绑定但 HA 就失效了；接着选数据存储，然后配虚拟机规格——CPU、内存、磁盘大小按 IP 规划表里的分级规格来（业务 VM 和数据库 VM 分级），网卡选好挂哪个端口组，最后确认创建，可以勾上"创建完成后直接启动"。虚拟机创建出来是裸机，装系统的动作是：给虚拟机挂光驱、挂上统信 UOS 或麒麟 V10 的 ARM 版 ISO，设置光驱启动，重启后从 VRM 网页打开 VNC 控制台进安装界面，和装物理机一样走完安装向导。银行项目里我批量发放了十五台以上，做法是先把一台的标准系统装好、基础配置调好，后续用统一规格逐台发放，规格和 IP 严格按部署 IP 规划表执行，装完每台再装 Guest Tools、改主机名、配 IP 和时间同步，最后过一遍安全基线。这个批量交付的环节是我对"实施工程师"这份工作最有体感的部分——规划表做细，发放就是体力活；规划表不细，每一台都是坑。

追问链：

• 迭问1：模板和克隆是怎么回事？ → 答：模板是做成只读的母版虚拟机，系统、补丁、基础配置都固化在里面；克隆就是基于模板快速复制出规格一致的新虚拟机。好处是把"装系统、调配置"这个最耗时的动作只做一次，后面十几台机器分钟级交付，而且规格高度一致——不会出现手工装出来的机器各有各的小毛病。一致性就是可运维性。
• 迭问2：虚拟机的架构跟什么走？ → 答：跟集群或主机的 CPU 架构走。TaiShan 是 ARM 架构，所以上面只能发放 ARM 虚拟机，操作系统必须是统信 UOS、麒麟 V10 的 ARM 版本，软件包必须是 aarch64 的。这也是国产化项目最大的特点——所有软件选型第一件事先看有没有 aarch64 版本，我在项目里反复处理、反复写进文档。
• 迭问3：发放之前怎么确认资源够不够？ → 答：看两个水位：一是集群资源池里 CPU 和内存的"已分配/总量"——我们规划时按业务峰值再留百分之二十左右余量，避免超分太多导致性能抖动（超分原则见 8.19）；二是数据存储的剩余容量，磁盘只增不减，要预留虚拟机磁盘增长和快照占用。这两个数在 VRM 的集群页面直接看到——发放前看一眼，是"批量发放不返工"的最后一个检查动作。

实操模板（虚拟机发放检查单）：

□ 架构确认：ARM 集群（TaiShan）→ ARM 版 OS 镜像
□ 规格：按 IP 规划表（业务 VM / 数据库 VM 分级规格）
□ 网络：网卡挂对的端口组（管理/业务 VLAN 分开）——逐台核对
□ 存储：选对数据存储（系统盘/数据盘）
□ 光驱：挂对应 ISO，光驱启动，VNC 安装
□ 装机后：装 Guest Tools、改主机名/IP、时间同步、基线加固（第1章1.2七项）
□ 勾选注意：除非明确要绑定主机，否则不勾"与所选主机绑定"（HA 失效）

8.7 FC 高可用三件套：HA、热迁移、快照 【理解】

标准回答： 虚拟化层的可用性就靠这三板斧，我一个一个定位。第一个是 HA 高可用，它管的是计划外的主机故障：某台 CNA 突然宕机，集群检测到之后把它上面的虚拟机在其他 CNA 上重新开机恢复——注意它的恢复动作是"重新开机"，所以有分钟级的中断，不是无感的，前提是虚拟机磁盘在共享存储上并且没有绑定主机。第二个是在线迁移也叫热迁移，它管的是计划内维护：某台主机要打补丁、换配件，我把上面运行中的虚拟机整台搬到别的 CNA 上，业务完全不感知，搬完之后这台主机腾空了就可以放心维护——这就是"逐台迁空、滚动维护"的标准玩法，也是割接前维护窗口的常用动作（8.14）。第三个是快照，它管的是变更保护：给虚拟机某一时刻的状态做存档，记录的是磁盘的差分变化，之后要做高风险变更比如升级、改配置，先打快照，出了问题秒级回滚。但快照不是备份——它存在同一个数据存储上，存储坏了快照跟着一起没；而且快照链越长性能越差，所以我的习惯是用完就删，不把快照当长期备份挂着。这套三板斧加上备份，才构成完整的可用性体系：热迁移保计划内无感，HA 保计划外快速恢复，快照保变更可回滚，备份保彻底丢失可恢复——这四层和第 15 章割接方案里的回滚设计直接对应。

追问链：

• 迭问1：HA 和热迁移怎么选？ → 答：不是选择题，是分工。故障场景下主机已经死了，只能靠 HA 在别的机器上重启恢复，接受分钟级中断；计划内维护场景主机还是活的，用热迁移做整机无感搬迁。运维规划的原则是"能热迁移的绝不靠 HA"——把维护都安排在业务低峰做热迁移，HA 是兜底不是日常手段。
• 迭问2：快照和备份到底差在哪？ → 答：两个维度。第一存放位置，快照和虚拟机磁盘在同一个数据存储，存储故障两者一起没；备份是独立副本，放到别的机器甚至别的机房。第二解决的问题，快照解决"改坏了要回滚"，备份解决"全没了要恢复"。生产上两层都要有——这个区分在割接方案评审时客户一定会问，"你打了快照是不是就不用备份了"这种问题要能一句话答清。

8.8 DME 是什么、怎么对接 FusionCompute 【必背】

标准回答： DME 全称 Data Management Engine，数据管理引擎，是华为的数据管理运维平台，在我们项目里的定位是虚拟化资源的统一纳管和集中监控。没有 DME 的时候，每套 FC 都要单独登一次 8443 页面看资源看告警；有了 DME 之后，多套 FC、多套存储设备一个入口全看到，集中告警、容量报表都在里面——这正符合银行对集中监控运营的要求。部署和对接我全程做过：部署用的是华为 SmartKit 工具里"数据中心虚拟化解决方案部署"的向导，选 ARM 架构加 EulerOS 操作系统，做了三节点的集群部署，每个节点分了 1T 磁盘；对接就一步，在 DME 里接入 VRM 的地址，FC 上的资源就自动注册纳管过来了；然后做告警同步，在 FC 侧配置 SNMP 告警管理站指向 DME，FC 的告警就通过 SNMP 上报给 DME。我验收对接是否成功的判断标准很实在：在 FC 侧制造或确认一条告警，看 DME 侧能不能同步收到，两侧告警能对上就是对接通了。另外两个关键细节是我踩过和验证过的：一是 DME 每 30 分钟对 FC 做一次全量资源同步，所以 FC 上刚做的变更最多要等 30 分钟才在 DME 上呈现——排障时先想到这个时间差，别误判成对接故障；二是接入 VRM 之后就不要再改 DME 的管理浮动 IP，改了会导致 VRM 同步失败，这是实施文档里的标红项。DME 的三节点部署架构、账号体系、对接四步的完整展开见华为篇第 3 章 3.4–3.6，交接要点见本章 8.15。

追问链：

• 迭问1：有了 FC 为什么还要 DME？多此一举吗？ → 答：不多余，它们管的层次不一样。FC 管的是"这一套"虚拟化环境自己的资源和虚拟机；DME 是跨设备的统一运维面，能同时纳管多套 FC 和存储设备，提供集中告警、统一报表和容量视图。环境只有一套 FC 时 DME 价值不明显，但银行这类客户是多套系统、多个厂商设备并存，集中监控和统一告警是刚需——DME 解决的就是这个层面的运营问题。
• 迭问2：DME 上看不到刚在 FC 里新建的虚拟机，怎么排查？ → 答：我先想到 30 分钟全量同步机制——刚建的虚拟机可能还没到同步周期，等一个周期或手动触发同步再看。超过周期还不出现，才去查 DME 里 VRM 的接入状态是否正常、告警链路通不通、DME 侧有没有同步失败的告警。这个题考的就是知不知道那个 30 分钟机制——知道就能一步定位，不知道就会乱查一通。

8.9 RAID 0/1/5/10 区别与选型 【必背】

标准回答： RAID 我先讲原理再讲选型。RAID0 是纯条带化，数据分片跨盘并行写，性能最高、容量利用率百分之百，但没有任何冗余，坏一块盘整组数据全丢，不能用于生产数据。RAID1 是镜像，两块盘互为备份，允许坏一块，代价是容量只剩一半，写性能有损耗但读性能好。RAID5 是条带加分布式奇偶校验，至少三块盘，校验信息打散分布在所有盘上，允许坏一块盘，利用率是 N 减 1 比 N，在容量、冗余、性能三者之间取平衡，缺点是写操作有校验计算的写惩罚。RAID10 是先镜像再条带，每组镜像里允许坏一块，冗余能力和随机写性能最好，但容量利用率只有一半，最贵。银行项目的真实选型是：系统盘两块 600G SAS 组 RAID1——系统盘的要求就是"坏不掉"，镜像保命，容量损失一半无所谓；数据盘 3.84T 的 SSD 组 RAID5——容量和冗余平衡，SSD 的性能又把校验写惩罚弥补掉了。另外有个真实踩点必须说：RAID 配置里 Disk Cache Policy 必须设为 Disabled——磁盘写缓存里的数据还没落盘时机器异常掉电，缓存数据就丢了，对数据库场景是致命的，这条来自我们 Vastbase 数据库的部署规范，是验收检查项。RAID 规划怎么和硬件规格、业务负载联动起来决策，展开在 8.13 的决策框架里。

追问链：

• 迭问1：RAID5 重建期是什么风险？ → 答：坏一块盘后阵列处于降级状态，换上新盘要把数据重新算出来写回去，这个过程叫重建。重建期间所有成员盘都处于高负荷读状态，恰好是整个阵列最脆弱的窗口——如果这期间再坏一块盘，RAID5 只能承受一块，整组数据就失效了。所以要有坏盘告警（iBMC 和 DME 都会报），发现坏盘要尽快换、尽快重建，重建期间还要避免高 IO 业务冲击——这套"重建窗口风险"的意识和第 3 章数据库、第 15 章割接窗口的风险管理是同一类思维。
• 迭问2：为什么不用 RAID0 加备份来省钱？ → 答：因为可用性和恢复时间不可接受。RAID 解决的是"坏一块盘业务不停"，是高可用问题；备份解决的是"误删或者机房级灾难后能恢复"，是数据保护问题。RAID0 坏盘后业务直接中断，等从备份恢复可能要几个小时，这个停机窗口生产业务扛不住。两者是互补关系，不是二选一。
• 迭问3：RAID10 和 RAID5 随机写谁快？为什么？ → 答：RAID10 快。因为 RAID10 写数据就是写镜像的两个盘，没有额外计算；RAID5 每次写都要算奇偶校验，随机小块写还可能引起读-改-写放大。所以高写入的数据库场景首选 RAID10。我们项目数据量级用 RAID5 加 SSD 已经够用——按业务规模做取舍，不是无脑上最贵的方案，这个"够用且可解释"的口径在方案评审时最有说服力。

实操模板（RAID 规划表，可背）：

服务器：TaiShan 2280（鲲鹏 ARM，48×2 核 / 32G×12 / 3.84T SSD / 600G SAS×2）
系统盘：2 × 600G SAS  → RAID1（无 RAID 卡，软 RAID）
数据盘：3.84T SSD     → RAID5
关键参数：Disk Cache Policy = Disabled（防掉电丢数据，数据库部署规范项、验收检查项）

8.10 TaiShan 鲲鹏 ARM 服务器特点 【理解】

标准回答： TaiShan 是华为基于自研鲲鹏 920 处理器的数据中心服务器，鲲鹏 920 是 ARMv8 架构、aarch64 指令集。我们项目用的是 TaiShan 2280，2U 双路机型，每颗 CPU 48 核、两颗 96 核，配 12 条 32G 内存、3.84T 的 SSD 加两块 600G SAS。银行选它的核心原因是金融信创的国产化要求——芯片、操作系统、数据库、中间件全链路国产，鲲鹏加统信麒麟加 Vastbase 这一套就是典型的全栈信创组合。ARM 架构给实施带来的最大差异是软件生态：所有软件必须用 aarch64 版本，操作系统装 ARM 版统信 UOS 和麒麟 V10，软件源配 aarch64 的源，容器镜像必须是 arm64 的，很多海外镜像拉不到就只能离线下载再 docker load 导入——这些我在项目里反复处理，闭着眼都能说出哪些软件要先确认架构。性能特点上，鲲鹏是核多、并行吞吐型负载有优势，单核频率敏感型的负载比高端 x86 弱一些；金融场景选它首先是满足自主可控，性能靠配套软件栈优化来补，比如毕昇 JDK 就是专门针对鲲鹏优化过的。另外鲲鹏是多路 NUMA 架构，96 核的调度地形对数据库调优有实际影响——我配 Vastbase 的 numa_distribute_mode 参数（第 3 章 3.3）就是在吃这个理解。鲲鹏与 x86 的选型对比、NUMA 展开、我的 4 台机器规格逐项解读见华为篇第 1 章（1.4/1.5/1.7）。

追问链：

• 迭问1：ARM 的软件能装到 x86 机器上吗？反过来呢？ → 答：都不能，指令集不同，二进制不兼容，x86 的 rpm 装到 ARM 机器上直接报架构错误。所以我的习惯是选任何软件包先看架构标签——aarch64 还是 x86_64，这也是我们部署文档里每个软件包都标注架构字段的原因：不标清楚，现场必然返工。
• 迭问2：既然 ARM 这么麻烦，直接用 x86 服务器不行吗？ → 答：普通行业完全可以，x86 生态确实更省心。但这个项目是数字人民币方向，金融信创是硬性要求，国产化是入选条件不是可选项。而且做了这个项目之后我对国产化整套体系的理解深了很多——从芯片、OS 到数据库怎么配套、怎么避坑，这恰恰是我简历上的差异化能力，再遇到信创项目我可以直接复用这套经验——ARM 踩坑的"麻烦"本身就成了我的资产。

8.11 iBMC 远程管理 【必背】

标准回答： iBMC 全称 Intelligent Baseboard Management Controller，智能主板管理控制器，是华为服务器主板上一个独立的管理芯片，它有自己的固件、自己的管理网口和管理 IP，跟主机操作系统完全独立——就算服务器操作系统崩了、断电了，只要主板通着电，iBMC 就能管理这台机器，同类产品是 Dell 的 iDRAC 和 HPE 的 iLO。它的核心能力五点：一是远程 KVM 虚拟控制台，浏览器里看到服务器屏幕、控制键盘鼠标，等于人坐在机房前面；二是挂载虚拟光驱，把本地电脑的 ISO 映射成服务器的光驱，这是远程装系统的关键；三是远程开关机和重启；四是硬件状态监控，温度、电压、风扇、磁盘、内存的健康状态都在 iBMC 里看；五是 SEL 事件日志和 SNMP 告警上报，硬件出了什么事都有时间戳记录，还能推给监控平台——DME 对接的告警链路就靠 SNMP。银行项目里我把 4 台 TaiShan 的 BMC 口全部接到独立的管理交换机上，形成带外管理网，日常运维和装系统基本不用进机房——银行机房管理很严，不是随便能进的，带外管理网络就是驻场实施的基本保障。踩过的坑也说一句：虚拟控制台默认英文键盘布局导致方向键失灵，要切日语布局，这个坑写进了部署指南。iBMC 挂 ISO 装机的完整操作流、双平面组网（管理+业务分离）的架构展开见华为篇第 7 章（7.3/7.6）。

追问链：

• 迭问1：操作系统都起不来了，你怎么装系统或者救机器？ → 答：走 iBMC。打开虚拟控制台就能看到机器的屏幕输出，挂载虚拟光驱放 ISO 就能引导装系统；就算机器完全死机也能远程强制断电重启。整个过程人不用进机房。银行机房进出要审批，这个能力在驻场场景下是刚需，也是我把 4 台机器 BMC 全部规范接入管理网的原因。
• 迭问2：带内管理和带外管理的区别？ → 答：带内管理走业务网络和操作系统，比如 SSH 登录、装 agent 上报监控，它的局限是操作系统一挂就完全失明；带外管理走独立的物理管理网络和独立的管理芯片，iBMC 就是带外，机器断电重启都能看到状态、都能操作。生产环境标配双平面——业务走带内，救急走带外，两者互为备份——我们项目"管理+业务双平面"的组网设计见华为篇第 7 章 7.6。
• 迭问3：iBMC 自己的安全怎么管？ → 答：我的实践是四条规定：改掉默认口令——弱口令是带外管理的第一风险；只接管理网不接业务网，减少暴露面；账号按人分配不共用，操作可追溯；管理网在防火墙策略里限制源地址，只允许运维终端网段访问。核心逻辑：管理平面是所有服务器的总钥匙，谁拿下 iBMC 谁就拿下整台机器，它的安全等级必须按全环境最高标准来管——这也是银行客户安全检查的必查项，我按这套口径通过过检查。

8.12 服务器上架检查清单（扩写版） 【必背】

标准回答： 上架这个活我有完整的现场经验——简历技能第 4 条"TaiShan 国产服务器上架经验"就是这段。全流程分上架前、上架中、加电验收、交付归档四段。上架前（准备段）：到货先和华为原厂一起做开箱验收——核对工单：型号、序列号、配置是不是和采购单一致，双方在验收记录上签字，这是正式交付流程的一部分；同时 RAID 方案和 IP 规划表要提前评审定稿——机器没到之前规划就该做完，机器到位了才开始想怎么配就晚了；机房资源确认——机柜 U 位、电力容量、网络端口和管理交换机端口都提前申请好。上架中（安装段）：电源必须双路冗余，两路接不同的 PDU 或列头柜，任何一路断电机器不停；iBMC 管理口接到管理交换机，配置 BMC 的 IP，这是最先要做的事——先通带外，后面装系统、救机器、看硬件状态都不依赖进机房；网线按规划表打标签，业务口和管理口分开走。加电验收段：先看前面板健康指示灯，绿色健康、橙色降级、红色故障；登 iBMC 概览页确认 CPU、内存、磁盘、网卡识别齐全；查 SEL 日志有没有历史严重告警；看风扇温度是否正常；进系统后再用 ethtool 和网卡亮灯确认物理连线端口对不对。交付归档段：上架记录、开箱验收单、iBMC 地址表、序列号清单归档进项目交付物——这批材料在后面维保换件时都要用。这套清单我每次实施都走一遍，看似繁琐，但机房返一次工的成本远高于多检查十分钟。完整的"从上架到交出虚拟化宿主机"操作叙事见华为篇第 1 章 1.9。

追问链：

• 迭问1：上架完第一个动作做什么？为什么？ → 答：先通带外——配 iBMC 的 IP、接入管理网、验证虚拟控制台能打开。原因是带外一通，后面装系统、救机器、看硬件状态都不依赖进机房，哪怕机器系统盘是空的也完全可以远程开始干活。先通带外是实施效率的关键顺序，我把这条写进了实施手册的第一章。
• 迭问2：为什么强调双电源？ → 答：电源是整机级单点，单电源一路电断了整台机器就下线，上面所有虚拟机全部中断。双电源两路分接不同的供电回路，任何一路故障业务完全无感知。这是花最小成本消除最大单点的做法，和 RAID 消磁盘单点、双平面管理消管理单点是同一个思路——逐个消除单点故障，实施工程师在规划阶段就要有这个清单思维。
• 迭问3：开箱验收为什么要和原厂一起做？ → 答：三个原因：配置核对有争议时当场解决，避免装机时才发现少内存条这类问题责任扯不清；序列号与保修绑定，原厂登记后后续换件走保修才顺畅；双方签字的验收单是正式交付流程的法定节点——银行客户对流程合规很敏感，这一步不做，后面的付款和维保条款都可能受影响。多方协同的完整口径见 15.14。

实操模板（上架 checklist，可整张背）：

【上架前】
□ 与华为原厂开箱验收：型号/序列号/配置对采购单，双方签字
□ RAID 方案与 IP 规划表已评审定稿（含管理/业务网段）
□ 机柜 U 位、电力、网络端口、管理交换机端口已申请
【上架中】
□ 双路电源接不同 PDU/列头柜
□ iBMC 管理口接管理交换机并配 IP —— 最先做
□ 网线按规划表打标签，业务/管理分走
【加电验收】
□ 前面板指示灯：绿=健康 橙=降级 红=故障
□ iBMC 概览：CPU/内存/磁盘/网卡识别齐全
□ SEL 日志无历史严重告警；风扇温度正常
□ ethtool/网卡亮灯核对物理连线端口
【交付归档】
□ 上架记录、开箱验收单、iBMC 地址表、序列号清单归档

8.13 硬件规格与 RAID 决策框架 【必背】（实施版新增）

标准回答：实施工程师在现场要能独立做"规格怎么分、RAID 怎么组"的决策并向客户解释理由，我的决策框架三步。第一步算需求账：从业务倒推——多少台虚拟机、每台什么规格、什么负载类型。银行项目的账是：4 台 TaiShan 2280、每台 96 核 384G，要承载 15+ 台国产化虚拟机，其中数据库节点 IO 敏感、业务节点中等负载、管理节点轻负载——先有虚拟机规格规划表，再定物理机怎么分，顺序不能反。第二步分资源层级：CPU 按超分原则（业务峰值留 20% 余量，CPU 可适度超分、内存不超，见 8.19）；内存按 1:1 加余量倒推；存储按负载选介质——系统盘选 SAS 机械盘因为系统盘负载轻只求可靠、数据盘选 SSD 因为虚拟机磁盘和数据库是随机 IO 密集，"按负载选介质"而不是"越贵越好"；网络按平面分，管理、业务、存储流量隔离。第三步定 RAID 并写理由：系统盘 RAID1——镜像保命、容量损失可接受；数据盘 RAID5——容量冗余平衡加 SSD 弥补写惩罚；数据库专属场景若写入重可升 RAID10（我们量级 RAID5 够用且可解释）；所有阵列 Disk Cache Policy=Disabled。决策的输出口径是规划表加一段理由说明——客户技术评审问"为什么这么配"，我按这三步复述，每一项都有因果。这套框架的本质：硬件决策不是查手册抄答案，是把业务需求翻译成资源配置的推导过程——华为篇第 1 章 1.4（我的 4 台 2280 规格逐项解读、15 台虚拟机的资源账）是这个框架的完整算例。

追问链：

• 迭问1：客户预算有限，规格上什么可以省、什么不能省？ → 答：我的优先级：不能省的是冗余类——双电源、系统盘 RAID1、管理平面独立，这些省的是"出事的代价"；可以省的是性能余量类——CPU 超分比适当提高、内存按实际峰值配不追大、SSD 容量按增长预测分批扩；绝对不能动的是安全合规类——Disk Cache Policy、密码策略这些规范项。答这题的逻辑是"按出事代价排优先级"，不是按价格排。
• 迭问2：虚拟机规格怎么分级？ → 答：三级模板：数据库 VM（高内存大磁盘独立数据盘、绑定特定主机或存储）、业务 VM（中等规格 8-16G 可超分调度）、管理/监控 VM（轻规格 4-8G）。分级的好处是发放时按表选型不用现场决策，资源利用率也可预期——这个分级表就长在 IP 规划表里，两表合一。

8.14 割接前环境验证清单 【必背】（实施版新增）

标准回答：上线割接前，虚拟化底座要做一轮完整的环境验证——这轮验证是我在银行项目割接流程里负责的环节，清单八项，目的是"把问题消灭在割接窗口之前"。第一项主机健康：所有 CNA 主机"运行中"无失联告警，硬件 SEL 无未处理告警——底座带病割接是大忌。第二项资源水位：集群 CPU/内存已分配率和数据存储余量在安全线内，预留割接期间可能的操作空间（快照会占存储）。第三项HA 与迁移演练：割接前完成一次热迁移演练（证明计划内维护能力）和一次 HA 演练或至少确认 HA 前提条件（共享存储、未绑定主机）——不演练的高可用是纸面的。第四项网络连通矩阵：按端口组逐 VLAN 抽验连通性——管理、业务、数据库网段两两之间按规划该通的通、该断的断，用 ping/telnet 打点验证并记录。第五项时间同步：全节点 chrony 锁定状态——割接涉及证书和集群认证，时间不同步是隐患。第六项备份与快照基线：割接前对关键虚拟机打快照、确认备份完成点——这是回滚设计的物理前提（第 15 章 15.12 的回滚基线）。第七项告警链路：FC→DME 的 SNMP 告警链路验证通——割接窗口里告警必须灵。第八项变更与回滚方案齐备：割接方案、回滚步骤、责任人、决策点（何时继续何时回滚）评审通过并打印在场——环境和文档都 green 才进窗口。这八项做完输出一张《割接前环境验证表》，逐项打勾签字——割接成功的秘诀从来不在割接当晚，而在割接之前的验证深度。

追问链：

• 迭问1：为什么网络要按"连通矩阵"验证而不是抽几台 ping？ → 答：因为虚拟化环境里"通不通"是由端口组 VLAN、上行链路、交换机 trunk 三层共同决定的，A 到 B 通不代表 A 到 C 通。按矩阵逐对验证（管理×业务×数据库的网段组合），能把"挂错端口组""trunk 没放行 VLAN"这类问题提前暴露——我在发放检查单里加"端口组逐台核对"就是被这类问题教育出来的。
• 迭问2：HA 演练和热迁移演练割接前一定要做吗？ → 答：原则上是——因为割接方案里很可能用到它们（迁移腾空主机做维护、故障时靠 HA 兜底），不演练就是拿生产窗口赌。实在没条件做完整演练，至少做"前提条件核查"：共享存储确认、绑定勾选核查、集群 HA 开关确认——纸面核查替代不了实操，但有核查比没有强。

实操模板（割接前环境验证表骨架）：

□ 1 主机健康：CNA 全部"运行中"，SEL 无未处理严重告警
□ 2 资源水位：CPU/内存已分配率、数据存储余量安全线内
□ 3 演练：热迁移演练通过；HA 前提核查（共享存储/未绑定）
□ 4 网络连通矩阵：按端口组逐 VLAN 两两抽验并记录结果
□ 5 时间同步：全节点 chrony 锁定（^* 状态）
□ 6 回滚基线：关键虚拟机快照完成、备份完成点确认
□ 7 告警链路：FC→DME SNMP 链路验证通（制造测试告警对上）
□ 8 文档齐备：割接方案/回滚步骤/责任人/决策点评审通过并打印在场

8.15 DME 交接要点与统一纳管移交 【必背】（实施版新增）

标准回答：项目质保期结束或运维移交时，DME 侧的交接是虚拟化交付的最后一块，我的交接要点六项。第一项账号与权限移交：DME 的账号体系按客户运维角色重建——管理员、只读审计账号分设，密码按客户密码策略重置，我方临时账号到期回收——DME 部署时设过一批密码（华为篇第 3 章 3.5.3 有账号体系全景表），交接时逐个过。第二项纳管关系与链路确认：DME 纳管的 FC、存储设备清单与实物一致；对接参数（VRM 地址、SNMP 告警站）书面化；再次验证"FC 造告警 DME 能收到"。第三项不可变项与慢变量交代：这是 DME 交接最容易踩雷的部分——管理浮动 IP 接入后不可改（改了 VRM 同步失败）、30 分钟全量同步的时间差、License 有效期——这三条要写进交接文档的"注意事项"置顶位置，华为篇第 3 章 3.7.1 有完整的"不可变项清单"。第四项巡检动作移交：把我的 DME 巡检动作（告警页按级别过滤、容量趋势、同步状态）写成每日巡检 SOP 交给客户，配合一次陪同巡检。第五项告警闭环流程约定：什么级别告警客户自己处理、什么情况找原厂、什么情况找我方——三方责任矩阵写清楚（完整协同框架见 15.14）。第六项文档包归档：DME 部署记录、对接配置、账号表、注意事项、巡检 SOP 打包归档进项目交付物。交接的核心思想一句话：把"我知道的"变成"文档里有的、客户会做的"——这也是第 15 章 15.8 培训交付和 15.9 质保衔接的虚拟化部分。

追问链：

• 迭问1：交接后客户改了浮动 IP 导致同步失败找你，怎么办？ → 答：先恢复业务再复盘：按交接文档把 IP 改回（或按官方流程重新配置对接关系），验证同步恢复；然后把这次事件作为案例补进交接文档的注意事项并和客户做一次强调——交接文档的价值就在这种时刻体现：问题有出处、解法有文档。同时我也会反思交接时这条有没有讲到"必考级"——交接质量的责任在我，补救之后要改进移交方式。
• 迭问2：怎么验证交接是成功的？ → 答：我的标准是"客户独立完成一周日常运维不需要找我"——交接后陪跑几天，然后让客户独立执行巡检 SOP、处理一条测试告警、做一次虚拟机发放，全程不问我，能做到就算交接收口。交接不是"我把东西给你了"，是"你能独立干了"——这个验收口径我在 15.13 培训一节也用。

8.16 硬件故障排查思路 【理解】

标准回答： 硬件故障我按四步法排查。第一步先看指示灯：前面板和硬盘背板的健康灯直接给结论，橙色降级、红色故障，硬盘故障灯亮能直接定位到槽位——最快的定位手段。第二步进 iBMC 看告警：系统概览页把故障部件直接标红——哪根内存、哪块盘、哪个电源；再配合 SEL 事件日志看时间戳和错误码，SEL 日志是报给华为原厂的第一手证据，截图发过去他们就能定位。第三步在操作系统里辅助确认：dmesg 过滤 error/fail 看内核层硬件报错，ipmitool sel list 在系统内读事件日志，smartctl 看磁盘 SMART 健康结论，配合 RAID 工具看阵列状态——多源交叉验证避免误判。第四步处置：按错误码定位部件，银行现场走华为原厂的换件流程——我们有备件和原厂支持渠道，换盘之后盯着 RAID 重建进度到百分之百，期间控制 IO 负载，最后 SEL 清理归档、记录故障台账。这套流程我在驻场期间处理过硬盘、内存告警的真实案例，最深的体会是：硬件故障不可怕，可怕的是没有告警和没有流程——这也是我在 8.14 割接验证里把"告警链路"列为必验项的原因。

追问链：

• 迭问1：磁盘怎么提前发现要坏？ → 答：看三个信号：SEL 日志出现 media error 这类介质错误；SMART 数据里重映射扇区数在增长，说明盘面开始出坏区；iBMC 里磁盘健康状态从 OK 变 Degraded。出现这些就提前申请换盘，别等它真坏了 RAID 进降级甚至重建窗口被动挨打——把故障处理从事后救火变成事前置换，这就是监控告警对实施交付的价值。
• 迭问2：内存报错怎么处理？ → 答：SEL 会记录具体槽位的 ECC 或 CE 可纠正错误。处理顺序：先重新插拔、换槽位交叉验证，区分是内存条问题还是槽位/主板问题；换槽还报就换条；多根内存在不同槽位并发报错要怀疑主板或 CPU 内存控制器。银行现场这类换件都走原厂流程，我们负责定位和验证。

实操模板（硬件巡检命令组，可背）：

ipmitool sel list                   # SEL 事件日志（时间戳+错误码）
ipmitool sensor list                # 温度/电压/风扇传感器
dmesg -T | grep -iE 'error|fail'    # 内核层硬件报错
smartctl -H /dev/sda                # 磁盘健康结论（PASSED/FAILED）
# iBMC Web：系统概览看部件健康 → 告警错误码对照手册 → 报原厂换件

8.17 虚拟化与容器对比 【必背】

标准回答： 这题我按五个维度对比，然后一定补一句"互补不替代"。隔离级别：虚拟机是操作系统级隔离，每台虚拟机有自己独立的内核；容器是进程级隔离，共享宿主机内核，靠 Namespace 隔离视图、Cgroup 限制资源。资源开销：虚拟机 GB 级内存占用、分钟级启动；容器 MB 级、秒级启动，密度高得多。解决的问题：虚拟化解决资源池化和强隔离多租户；容器解决交付一致性和弹性伸缩。安全性：虚拟机强隔离更安全；容器共享内核存在逃逸风险，要靠最小权限等手段缓解。典型寿命：虚拟机以年计长期运行，容器以天计随发随销。最关键是两者的关系是互补的，我的两个项目就是现成证据：银行项目里，先用 FC 虚拟化把 4 台 TaiShan 切成 15 台国产化虚拟机做资源底座，再在虚拟机之上部署 Kubernetes 集群跑容器化应用；移动云项目里，云厂商的 ECS 本质也是虚拟机，上面照样跑 K8s。所以业界的标准形态就是"虚拟化做资源底座、容器做应用平台"，两层叠着用，不是谁取代谁——这条演进线也是我答"虚拟化和云原生什么关系"的固定框架。

追问链：

• 迭问1：什么场景必须用虚拟机不能用容器？ → 答：三种典型：需要不同操作系统或内核（Linux 和 Windows 混部，容器做不到）；强隔离需求，多租户或安全等级高的业务，虚拟机硬件级隔离比共享内核可靠；有状态的重量级负载或没法容器化的遗留系统，比如一些传统数据库直接跑虚拟机更稳妥。
• 迭问2：容器性能为什么能接近原生？ → 答：因为容器没有 Hypervisor 这层虚拟化翻译开销，容器进程就是直接的宿主机进程，跑在宿主内核上；Namespace 只是隔离了进程看得见的视图，Cgroup 只是限制了资源配额，都是内核原生机制，几乎不损失性能。虚拟机则要经过 Hypervisor 的 CPU 调度和设备模拟，损耗天然比容器大。

8.18 虚拟机在线迁移原理 【理解】

标准回答： 在线迁移就是把运行中的虚拟机从主机 A 搬到主机 B 而业务不中断，核心机制叫内存预拷贝 pre-copy，我按流程讲。迁移启动后，第一轮先把虚拟机的全部内存从 A 传到 B，这期间虚拟机继续跑、内存继续被写，所以传过去的数据很快就"旧"了。接下来进入多轮迭代：每一轮只传上一轮传输期间被写脏的那部分内存页，因为虚拟机的写入通常集中在热点区域，脏页会一轮比一轮少，差距逐步收敛。收敛到足够小之后，进入一个极短的停顿窗口：暂停虚拟机，把最后一批脏页加 CPU 和设备状态传过去，在 B 上恢复执行。业务侧的表现就是一次毫秒到百毫秒级的瞬间抖动，连接不断。网络怎么跟上？虚拟机的 MAC 地址不变，靠分布式交换机的 MAC 表学习更新，流量自然切到新主机。前提条件三个：目标主机有同等资源、CPU 兼容（同架构同集群）、网络可达；共享存储时不迁移磁盘，本地存储就得把磁盘数据也同步过去，耗时上一个数量级。最典型的失败场景是：虚拟机内存写入速度持续高于网络传输带宽，脏页永远追不完、一直不收敛，迁移超时失败——所以迁移要挑业务低峰做，我的习惯也是这么执行的。

追问链（兜底话术示范）：

• 迭问1：你在 FC 里实际做过迁移吗？参数怎么调？ → 答："做过虚拟机在 CNA 之间热迁移的操作，主要是主机维护场景下逐台迁空。原理层面我理解到预拷贝、迭代收敛、停机切换和收敛条件这一层；XBZRLE 压缩这类参数级的调优我还没有深入实操过，可以会后补。"按真实边界答，不夸大。
• 迭问2：迁移和 HA 的区别再总结一下？ → 答：一句话，迁移是计划内的主动搬迁，整机状态保真、业务无感；HA 是计划外故障后的被动恢复，虚拟机在别的 CNA 上重新开机，有重启中断，靠共享存储保住磁盘数据。一个管维护窗口的体验，一个管故障时刻的兜底。

8.19 虚拟化资源超分与容量水位管理 【理解】

标准回答： 先说结论：超分就是把物理资源按超过 1:1 的比例分配给虚拟机，它是虚拟化提高利用率的核心手段，但超多少必须配合水位管理，否则就是拿稳定性换利用率。CPU 超分是可行的，因为虚拟机不太可能同时把所有 vCPU 跑满，行业常见 CPU 超分比 1:2 到 1:4——96 核按 1:3 超可以分出 288 vCPU；内存超分要非常谨慎，因为内存是"实占"资源，分配出去就锁定了，超内存等于开空头支票，物理内存真耗尽就触发交换或 OOM，性能雪崩。所以我的容量规划 CPU 和内存分开算：CPU 按业务峰值乘超分比，内存按 1:1 再留余量——银行项目的口径是按业务峰值预留 20% 余量，既不浪费也不冒进。日常看水位：集群页面的 CPU/内存"已分配/总量"和"实际使用/总量"两组数一起看——前者是承诺、后者是真实消耗，承诺满了就要扩容或控制新建虚拟机，不能等真实使用顶到天花板才动作。这套"超分有度、水位有表、扩容有前置"的思路，跟我后来在 K8s 里做 resource requests/limits 的规划是同一个思想——资源管理本质是承诺和真实消耗的两本账都要管。

追问链：

• 迭问1：CPU 超分为什么可以、内存超分为什么危险？ → 答：因为消耗形态不同。CPU 是时间片资源，峰值错开就能超卖，最坏情况是大家同时满载整体变慢，是性能问题；内存是空间资源，写进去的数据必须一直占着物理位置，超卖后虚拟机真用满，物理机没有退路，只能换页或 OOM，是可用性问题。所以 CPU 适度超分、内存不超或只超很小比例。
• 迭问2：发现一台虚拟机持续吃掉大量资源影响邻居，怎么处理？ → 答：三步：资源监控确认是哪台哪类资源异常，是业务正当高峰还是异常行为；正当高峰就跟业务方协调扩容或热迁移到空闲主机，用调度手段解决争抢；异常行为就进虚拟机排查应用。虚拟化平台的价值就在这——资源争抢不用停机，迁移和限制都能在线做。

8.20 FusionCompute 日常运维与告警处理 【理解】

标准回答： 驻场近两年，FC 的日常运维我形成了一套固定动作。巡检三处：一是集群和主机状态页，确认所有 CNA 主机"运行中"、无失联，资源水位正常；二是告警页，按严重级别过滤，紧急和重要告警当天必须闭环，告警要看到"清除"状态才算处理完——银行环境对告警闭环率有考核；三是数据存储页，看容量增长趋势——磁盘只增不减，容量告警要提前响应。常见告警我按处理思路说四类：主机失联类——先区分网络问题还是主机问题，ping 管理口、看主机指示灯和 iBMC，确认虚拟机是否受影响，必要时按 HA 预案处理；存储容量类——清理无用虚拟机磁盘和快照、扩容数据存储，快照堆积是隐形容量杀手；虚拟机性能类——看是资源争抢还是应用自身问题，对应做迁移或扩配；硬件类告警——按 8.16 四步法走 iBMC 和 SEL 定位，换件走华为原厂流程。还有一个习惯动作：DME 集中监控侧同步核对告警，确认 FC 到 DME 的告警链路正常、两侧能对上——集中监控的价值要在日常就验证，不能等出事才发现链路早断了。

追问链：

• 迭问1：巡检发现告警但业务没受影响，还要处理吗？ → 答：要，这正是巡检的意义。告警是风险的前置信号：一块盘 Degraded，RAID 还能撑着业务不中断，但这时不换盘，等第二块也坏就是数据丢失级事故。我的原则是"业务影响决定紧迫度，告警本身决定必须处理"——不受影响的按流程排期，受影响的立即处理，两者都不能装看不见。
• 迭问2：虚拟机蓝屏或卡死怎么处理？ → 答：先在 FC 页面看虚拟机状态和所在主机有没有异常告警；VNC 控制台进去看卡在系统层还是应用层；能进系统就查日志，进不去就强制重启先恢复业务；反复出现要怀疑底层——存储 IO、资源争抢或镜像问题，配合迁移到别的主机做对照测试切分变量。处理完一定补复盘：发生几次了、共同点是什么。

8.21 服务器规格与配置单解读 【了解】

标准回答： 看服务器配置单是实施工程师的基本功——跟华为原厂和客户谈方案时能听懂配置、核对到货、给容量规划提依据，不能只会装、要看懂单子。银行项目 4 台 TaiShan 2280 的规格我能直接背：鲲鹏 920 双路、每颗 48 核共 96 核，内存 12 条 32G 共 384G，数据盘 3.84T SSD，系统盘两块 600G SAS。解读配置单我抓五个字段：CPU 看"路数乘核数乘主频"，双路 48 核意味着并行吞吐强，适合虚拟化这种多虚拟机分时复用的负载；内存看容量和通道数——通道插满才能跑满带宽，鲲鹏平台 12 条正好是满通道配置；存储分层看介质——按负载选介质（8.13 的决策框架）；网卡看速率和数量，万兆是虚拟化环境起步配置，数量决定能不能做绑定冗余和多平面隔离；RAID 卡看有没有卡、缓存多大、支持哪些级别——TaiShan 2280 不带 RAID 卡所以走软 RAID，这点直接影响安装流程。规格逐项解读的完整版（含 15 台虚拟机的资源账、磁盘容量账）见华为篇第 1 章 1.4。

追问链：

• 迭问1：为什么系统盘用 SAS 机械盘、数据盘反而用 SSD？ → 答：按负载特点分配介质。系统盘读写量小且顺序，机械 SAS 盘的企业级可靠性和容量刚好匹配，没必要上 SSD 花冤枉钱；数据盘承载虚拟机磁盘文件和数据库 IO，随机读写密集，SSD 的随机性能比机械盘高两个数量级——把钱花在刀刃上，存储选型从来不是越贵越好。

8.22 RAID 在线扩容与热备盘 【了解】

标准回答： 这两个是 RAID 进阶话题，我按"理解 + 口径"讲。热备盘（Hot Spare）是预先插在阵列里、平时不承载数据的备用盘：一旦阵列里某块成员盘故障，RAID 卡或软件自动用热备盘顶上开始重建，不需要等人到场换盘——价值是把"坏盘到开始重建"的窗口从小时级压缩到分钟级，大幅降低重建窗口期再坏一盘的风险。全局热备给整机所有阵列共用，局部热备只服务指定阵列。在线扩容是容量不够时，不停机往 RAID 组加盘或换更大容量的盘，阵列后台重新分布数据——耗时长、期间性能有影响，做之前必须先备份。这两块我如实说没有深度实操——银行项目的 RAID 是安装时一次性规划好的（系统盘 RAID1、数据盘 RAID5），没做过在线扩容，热备盘在软 RAID 场景也用不上；我的理解停在概念和适用场景层面，被深挖就用兜底话术："生产上我做过 RAID 规划和降级处置，在线扩容这类操作理解到原理，没实操过，可以会后补。"

追问链：

• 迭问1：RAID5 和 RAID6 的选择？ → 答：核心差别是冗余能力：RAID5 一块分布式校验允许坏一盘；RAID6 两块独立校验允许同时坏两盘，代价是更重的写惩罚和少一块容量。趋势是大容量单盘重建时间越来越长（8T 盘重建可能要一两天），重建窗口里再坏一盘的概率不可忽视，所以大容量盘的海量存储场景越来越多用 RAID6。我们项目 3.84T 盘加 SSD 介质重建快、且有坏盘告警快速响应机制，RAID5 加运维纪律足够——按规模做取舍。

8.23 本章案例

• 【真实项目】银行 4 台 TaiShan 虚拟化底座全流程（STAR，完整版约 300 字）：背景是数字人民币智能合约平台要做全栈国产化底座，时间紧、银行机房进出管控严。任务是我负责从物理机到虚拟机的全链路建设。行动分四段：先做上架验收——4 台 TaiShan 2280 到货与华为原厂开箱核对配置、双路电源接入、iBMC 管理口全部接入带外管理网并验证虚拟控制台可用；然后做 RAID 规划——系统盘两块 SAS 组 RAID1、数据盘 SSD 组 RAID5、Disk Cache Policy 按 Vastbase 规范设 Disabled；再通过 iBMC 虚拟光驱远程安装 CNA 三台加 VRM 一台，走完 cnaInit/vrmInit 初始化、License、NTP 配置（踩掉键盘布局的坑）；最后建集群开 HA、配分布式交换机和各 VLAN 端口组、批量发放统信 UOS 和麒麟 V10 虚拟机 15 台以上，每台装机后过初始化基线和安全基线。结果是整个底座一次通过银行客户验收，我沉淀的部署指南成为公司同类项目的标准实施文档。
• 【真实项目】DME 22.0 部署与 FC 对接告警验证（STAR）：背景是银行要求虚拟化资源集中监控、告警统一归口。任务是我负责 DME 的安装部署和与 FC 的对接验证。行动是用 SmartKit 向导在 ARM 加 EulerOS 环境做三节点部署、每节点 1T 磁盘；DME 接入 VRM 地址完成资源自动纳管；FC 侧配 SNMP 告警管理站指向 DME，用"制造告警看两侧能否同步"的方式验证链路。结果是对接一次通过、告警双向对上；同时沉淀两个关键细节进文档——30 分钟全量同步的时间差、接入后浮动 IP 不可改，这两条后来都成为实施检查项和交接注意事项（8.15）。
• 【真实项目】割接前环境验证与演练（实施版新增案例）：背景是数币平台上线割接在即，底座必须确认"绿"。任务是我按 8.14 的八项清单组织验证。行动：主机健康与资源水位核查；完成虚拟机热迁移演练证明计划内维护能力；按端口组做连通矩阵验证，暴露并修正一处挂错端口组的虚拟机；全节点时间同步核查；关键虚拟机打快照建立回滚基线；制造测试告警验证 FC→DME 链路；割接方案与回滚步骤评审。结果：割接窗口内底座零意外，回滚基线虽未启用但给了客户和项目组"敢切"的底气——事后复盘认为这轮验证是"一次通过验收"的关键前置动作。
• 【课程项目】KVM 虚拟化实验（口径：课程实验 + 理解）：在课程环境用 virt-install 命令行装虚拟机、virsh 管理生命周期、配桥接网络、做快照与克隆，还人为制造过 NAT 和桥接模式的网络差异做对比验证，把 KVM 加 QEMU 加 libvirt 三层分工（KVM 管 CPU 内存虚拟化、QEMU 做设备仿真、libvirt 提供管理接口）理解透了。这段实验是我能理解 FC 底层原理的知识底座——生产上操作 FC 出问题知道往哪一层去想、该看哪层日志，不是只会点 Web 页面的实施。
• 【经典故障】RAID 降级处置（通用套路 + 本项目参数，约 250 字）：背景是运行中的服务器出现硬盘故障告警、RAID5 阵列降级。第一步止损确认：登 iBMC 看告警和硬盘定位灯确认槽位，确认 RAID 级别可承受单盘故障、业务没中断，向客户同步风险——此时最怕再坏第二块盘。第二步换盘重建：走华为原厂换件流程，观察重建进度到百分之百，期间严格控制 IO 负载。第三步复盘预防：SEL 错误码归档、坏盘告警规则确认有效、"Disk Cache Policy=Disabled、坏盘告警必接、重建窗口管控"写进巡检规范。这个案例考的是"知不知道降级窗口是高危期、会不会有序处理"。
• 【经典故障】VRM Web 无法登录排查（约 250 字）：现象是浏览器访问 https://VRM-IP:8443 打不开。排查顺序：先确认影响面——CNA 上虚拟机是否正常、业务是否正常，因为 VRM 只影响管理面，先安抚业务再排查（管理面数据面分离架构下的标准判断）；然后从服务端查起，ping 管理口、telnet 8443；再登 VRM 物理机检查进程状态和磁盘空间——磁盘打满导致服务异常是常见原因；浏览器侧顺手确认是不是自签证书告警被当故障、账号是否被锁定。都不行就联系华为原厂按组件重启流程处理，不在生产上乱杀进程。这个案例面试官真正想听的是"VRM 挂了影响什么"——答案是有计划地排查管理面，而不是慌着说平台全挂了。
• 【经典故障】数据存储容量告警（约 200 字）：现象是 DME/FC 报数据存储容量超阈值持续上涨。第一步定位增量：容量趋势加虚拟机磁盘清单排查——常见原因是快照长期未删（差分盘随写入持续膨胀）和某台虚拟机磁盘业务性暴涨；第二步处置：无用快照立即删除释放空间（删除前确认不在依赖链上），业务性增长走扩容或迁移；第三步预防：快照纳入生命周期管理——用完即删最长不过一周，容量告警阈值设在 80% 提前响应。
• 【经典故障】虚拟机网络不通的虚拟化层排查（约 220 字）：现象是单台虚拟机网络不通，宿主机和其他虚拟机正常。排查"由内向外"四步：第一步进虚拟机看——ip a、ping 同网段，排除系统内防火墙和配置问题；第二步看端口组——虚拟机网卡挂的端口组 VLAN 是否与规划一致，挂错端口组是最常见的虚拟化层网络问题；第三步看 DVS 上行链路——对应物理交换机口 trunk 是否放行该 VLAN，虚拟化侧和交换机侧对照同一张规划表核对；第四步替换法切分变量——网卡换挂到已知正常端口组测试。我在银行项目处理过端口组挂错导致的"虚拟机装完不通"，根源是发放时手误选错——所以后来发放检查单里加了"端口组逐台核对"这一项。

8.24 章末自测清单

1. Hypervisor 两类？ → 裸金属型（ESXi/CNA）跑在硬件上，宿主型（Workstation）跑在 OS 上。
2. CNA 和 VRM 各是什么？ → CNA 计算节点承载虚拟机，VRM 管理节点管集群与生命周期，8443 端口。
3. VRM 故障影响范围？ → 已运行 VM 不停，仅管理操作不可用——管理面数据面分离。
4. CNA/VRM 安装后的初始化命令？ → cnaInit / vrmInit。
5. 密码算法模式（国密/国际）什么时候定？ → 装 VRM 时设、装完不可改——提前和客户对口径。
6. FC 网络配置三件套？ → 分布式交换机 DVS → 上行链路 → 端口组（绑 VLAN）。
7. HA 的两个前提？ → 磁盘在共享存储、未勾选"与所选主机绑定"。
8. DME 对接 FC 的两个细节？ → 30 分钟全量同步；接入后浮动 IP 不可改。
9. DME 对接成功的判断标准？ → FC 造告警经 SNMP 上报 DME，两侧对上。
10. RAID5 允许坏几块盘、利用率？ → 坏 1 块（≥3 盘），(N-1)/N。
11. Disk Cache Policy 为什么 Disabled？ → 防掉电时磁盘写缓存数据丢失（数据库规范项、验收检查项）。
12. iBMC 五大能力？ → KVM 虚拟控制台、虚拟光驱、远程开关机、硬件监控、SEL 日志+SNMP 告警。
13. iBMC 装机的经典坑？ → 默认英文键盘方向键失灵，切日语布局。
14. 上架第一个动作？ → 先通带外：配 iBMC IP、接管理网、验证控制台。
15. 为什么双电源？ → 消除整机级单点，一路断电业务无感——逐个消除单点。
16. 割接前环境验证八项？ → 主机健康/资源水位/HA与迁移演练/网络连通矩阵/时间同步/快照备份基线/告警链路/方案文档齐备。
17. 硬件故障四步排查？ → 指示灯 → iBMC 告警/SEL → 系统内 dmesg/ipmitool/smartctl → 换件重建。
18. 虚拟机与容器一句话区别？ → VM 独立内核 OS 级隔离分钟启动，容器共享内核进程级隔离秒级——互补不替代（虚拟化做底座、容器做平台）。
19. 热迁移核心机制？ → 内存预拷贝迭代收敛 + 短暂停顿切换 + 共享存储前提。
20. 快照和备份的区别？ → 快照同存储秒回滚（防改坏），备份独立副本（防全丢），两层都要。
21. CPU 和内存超分原则？ → CPU 适度超分（1:2~1:4），内存不超（实占资源）——业务峰值留 20% 余量。
22. RAID 决策三步框架？ → 算需求账（VM 规划表倒推）→ 分资源层级（按负载选介质）→ 定 RAID 写理由（可解释）。
23. DME 交接最容易踩雷的三条？ → 浮动 IP 不可改、30 分钟同步差、License 有效期——写进交接注意事项置顶。
24. 交接成功的验收标准？ → 客户独立完成一周日常运维不需要找我。

8.25 本章口径红线（面试前再读一遍）

1. 角色口径：虚拟化平台选型是华为和银行定的（华为渠道商配套体系），我负责落地实施；被问"为什么选 FC/DME"答："平台选型是华为和银行按照配套体系定的，我负责按版本配套表落地实施，配套原因我能讲清楚。"不越位、不虚揽。
2. 脱敏：不报 VRM/CNA 的内网 IP、root 密码、License 来源细节；统一说"某银行内网环境"。
3. 版本配套意识：FC 8.3.0 + DME 22.0 + BCS 1.2.6 + K8s 1.17.3 是一张配套表，生产环境严格按配套来、不擅自升级——这是本项目最能体现专业度的标签，回答里多提。
4. 数字口径：4 台 TaiShan、CNA×3 + VRM×1、15+ 台国产 VM、96 核 384G 单机规格，全部有据可查，大胆说。
5. 课程级内容（KVM/VMware 原生细节、RAID 在线扩容）用"课程实验 + 理解"口径，不包装成生产经历。
6. 华为产品深挖跳转：TaiShan 规格账 → 华为篇 1；FC 安装全流程 → 华为篇 2；DME 部署对接 → 华为篇 3；iBMC/双平面组网 → 华为篇 7。本章答实施层，产品层细节主动说"华为篇/部署文档里有完整版"。
7. 一句话人设：这套华为虚拟化体系是我在银行生产环境从上架到发 VM 到 DME 交接收尾全流程亲手做的——"会装会修会验收还能交接"，对 3 年经验的实施工程师定位刚好。
8. 衔接移动云项目：被问"虚拟化和云原生什么关系"，用 8.17 的互补关系答，并点出两个项目的演进线：银行项目虚拟化底座 → 移动云项目云原生底座——正好体现技术成长轨迹；实施版还要加一句：这条线同时是"交付流程能力"的升级线——从执行安装到组织割接验收培训（第 15 章）。