第8章 虚拟化与服务器硬件

对应简历：技能第10条「熟练掌握 FusionCompute + DME 虚拟化平台建设（CNA / VRM、集群与分布式交换机、虚拟机批量发放）」+ 第11条「熟悉服务器硬件运维，具备 TaiShan 国产服务器上架、iBMC 远程管理与 RAID 规划实施经验」/ 项目一职责「负责 FusionCompute 虚拟化底座建设：通过 iBMC 远程控制台完成 CNA / VRM 节点安装（镜像挂载、RAID 规划、网络与时区配置），完成集群创建、分布式交换机与端口组配置及虚拟机批量发放」「负责 DME 22.0 的安装部署与 FusionCompute 对接，实现虚拟化资源统一纳管、告警同步与集中监控」

本章全部为项目一（某大型银行数字人民币智能合约引擎国产化部署）真实经历，4 台 TaiShan 2280 + FusionCompute 8.3.0 + DME 22.0，细节可放心讲；KVM / VMware 为"熟悉"口径（课程实验 + 生产接触理解）。术语：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，物理机坏了虚拟机在别的机器上拉起来，这在容灾上比纯物理机灵活太多；第三是交付效率，试点业务要扩容，发一台虚拟机是分钟级，采购物理机是周级。

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

标准回答： 先说 KVM：它是 Linux 内核内置的虚拟化模块，本身只负责 CPU 和内存的虚拟化，依赖硬件辅助虚拟化；设备仿真靠 QEMU 完成，管理面靠 libvirt 这一层，上层用 virsh 命令行或者 virt-manager 图形界面操作。它是开源免费的，OpenStack 和华为 FusionCompute 底层用的都是 KVM 技术，所以说我在银行项目操作 FC，本质上就是在用华为把 KVM 这套东西产品化封装后的平台。再说 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。
• 追问3：VRM 为什么要用浮动 IP？ → 答：主备部署的两台 VRM 共享一个浮动 IP，主节点持有它，主挂了备节点把浮动 IP 接管过去，管理员始终访问同一个地址，不用关心当前谁是主。这个思路和我后来在 Nginx + Keepalived 里做的 VIP 漂移是一回事，都是"一个虚拟地址加故障切换"的经典模式。

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

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

追问链：

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

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

□ iBMC 可访问、虚拟控制台可打开、键盘布局切好
□ RAID：系统盘 RAID1 / 数据盘 RAID5（TaiShan 2280 软 RAID）
□ 镜像：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 标签的虚拟网口模板。银行项目里我按网络规划表建了管理、业务等好几个端口组，十五台虚拟机的网卡分别挂到对应端口组上，网络隔离一次到位，客户网络团队验收也是按这张表核对的。

追问链：

• 追问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 规划表里的分级规格来，网卡选好挂哪个端口组，最后确认创建，可以勾上"创建完成后直接启动"。虚拟机创建出来是个裸机，装系统的动作是：给虚拟机挂光驱、挂上统信 UOS 或麒麟 V10 的 ARM 版 ISO，设置光驱启动，重启后从 VRM 的网页里打开 VNC 控制台进安装界面，和装物理机一样走完安装向导。银行项目里我批量发放了十五台以上，做法是先把一台的标准系统装好、基础配置调好，后续用统一规格逐台发放和克隆，规格和 IP 严格按部署 IP 规划表执行，装完每台再装 Guest Tools、改主机名、配 IP 和时间同步，最后过一遍安全基线。这个批量交付的环节是我对"实施工程师"这份工作最有体感的部分——规划表做细，发放就是体力活；规划表不细，每一台都是坑。

追问链：

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

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

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

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

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

追问链:

• 追问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 同步失败，这个在实施文档里是标红项。

追问链：

• 追问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 数据库的部署规范，是验收检查项。

追问链：

• 追问1：RAID5 重建期是什么风险？ → 答：坏一块盘后阵列处于降级状态，换上新盘要把数据重新算出来写回去，这个过程叫重建。重建期间所有成员盘都处于高负荷读状态，恰好是整个阵列最脆弱的窗口——如果这期间再坏一块盘，RAID5 只能承受一块，整组数据就失效了。所以要有坏盘告警，iBMC 和 DME 都会报，发现坏盘要尽快换、尽快重建，重建期间还要避免高 IO 业务冲击。
• 追问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 就是专门针对鲲鹏优化过的。

追问链：

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

8.11 iBMC 远程管理 【必背】

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

追问链：

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

8.12 服务器上架检查清单 【了解】

标准回答： 上架这个活我有完整的现场经验，分前中后三段说。上架前：到货先核对工单——型号、序列号、配置是不是和采购单一致，RAID 方案和 IP 规划要提前评审定稿，不能机器到位了才开始想怎么配。上架中：电源必须双路冗余，两路接不同的 PDU 或列头柜，任何一路断电机器不停；iBMC 管理口接到管理交换机，配置 BMC 的 IP，这是最先要做的事。上架后点亮：先看前面板健康指示灯，绿色健康、橙色降级、红色故障；登 iBMC 概览页确认 CPU、内存、磁盘、网卡识别齐全；查 SEL 日志有没有历史严重告警；看风扇温度是否正常；进系统后再用 ethtool 和网卡亮灯确认物理连线端口对不对。银行现场还有一步是与华为原厂一起做开箱验收记录，双方签字，这是正式交付流程的一部分。这套清单我每次实施都走一遍，看似繁琐，但机房返一次工的成本远高于多检查十分钟。

追问链：

• 追问1：上架完第一个动作做什么？ → 答：先通带外。配 iBMC 的 IP、接入管理网、验证虚拟控制台能打开。原因是带外一通，后面装系统、救机器、看硬件状态都不依赖进机房，哪怕机器系统盘是空的也完全可以远程开始干活。先通带外是实施效率的关键顺序。
• 追问2：为什么强调双电源？ → 答：电源是整机级单点，单电源一路电断了整台机器就下线，上面所有虚拟机全部中断。双电源两路分接不同的供电回路，任何一路故障业务完全无感知。这是花最小成本消除最大单点的做法，和 RAID 消磁盘单点、双平面管理消管理单点是同一个思路——逐个消除单点故障。

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

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

追问链：

• 追问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.14 虚拟化与容器对比 【必背】

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

追问链：

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

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

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

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

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

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

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

追问链：

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

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

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

追问链：

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

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

标准回答： 看服务器配置单是我的基本功，银行项目 4 台 TaiShan 2280 的规格我能直接背：鲲鹏 920 双路、每颗 48 核共 96 核，内存 12 条 32G 共 384G，数据盘 3.84T SSD，系统盘两块 600G SAS。解读配置单我抓五个字段：CPU 看"路数乘核数乘主频"，双路 48 核意味着并行吞吐强，适合虚拟化这种多虚拟机分时复用的负载；内存看容量和通道数——通道插满才能跑满带宽，鲲鹏平台 12 条正好是满通道配置；存储分层看介质——SAS 机械盘便宜大容量适合归档、SATA SSD 性价比均衡、NVMe 性能最强，我们系统盘用 SAS 是因为系统盘只需要可靠不需要快，数据盘用 SSD 是给数据库和虚拟机磁盘供 IO；网卡看速率和数量，万兆是虚拟化环境的起步配置，网卡数量决定能不能做绑定冗余和多平面隔离；最后看 RAID 卡——有没有卡、缓存多大、支持哪些级别，TaiShan 2280 不带 RAID 卡所以走软 RAID，这点直接影响安装流程。这套解读能力的作用是：跟华为原厂和客户谈方案时能听懂配置、核对到货、给容量规划提依据——实施工程师不能只会装，要看懂单子。

追问链：

• 追问1：为什么系统盘用 SAS 机械盘、数据盘反而用 SSD？ → 答：按负载特点分配介质。系统盘跑的是操作系统，读写量小且顺序，机械 SAS 盘的可靠性（企业级设计寿命）和容量刚好匹配，没必要上 SSD 花冤枉钱；数据盘承载虚拟机磁盘文件和数据库 IO，是随机读写密集型负载，SSD 的随机性能比机械盘高两个数量级，用 SSD 是把钱花在刀刃上。存储选型的原则从来不是"越贵越好"，是"按负载选介质"。
• 追问2：内存 384G 怎么评估够不够？ → 答：按虚拟机内存总和加宿主机开销倒推：15 台虚拟机平均按 16 到 24G 规划，加 CNA 自身和缓存开销，384G 的配置既满足 1:1 分配还留了余量。评估的关键是先有虚拟机规格规划表，再定物理机内存——顺序反了就会要么浪费要么不够。这也是我强调 IP 规划表和资源规划表要在采购前做好的原因。

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

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

追问链：

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

8.20 本章案例

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

8.21 章末自测清单

1. Hypervisor 两类？ → 裸金属型（ESXi/CNA）跑在硬件上，宿主型（Workstation）跑在 OS 上。
2. CNA 和 VRM 各是什么？ → CNA 计算代理节点承载虚拟机，VRM 管理节点管集群与生命周期，8443 端口。
3. VRM 故障影响范围？ → 已运行 VM 不停，仅管理操作不可用。
4. CNA/VRM 安装后的初始化命令？ → cnaInit / vrmInit。
5. FC 网络配置三件套？ → 分布式交换机 DVS → 上行链路 → 端口组（绑 VLAN）。
6. 端口组是什么？ → DVS 上带 VLAN 标签的虚拟网口模板，VM 网卡挂上来入对应网络。
7. DME 对接 FC 的两个细节？ → 30 分钟全量同步；接入后浮动 IP 不可改。
8. DME 对接成功的判断标准？ → FC 告警经 SNMP 上报 DME，两侧告警同步。
9. RAID5 允许坏几块盘、利用率？ → 坏 1 块（≥3 盘），(N-1)/N。
10. 系统盘/数据盘 RAID 怎么选？ → 系统盘 RAID1，数据盘 RAID5（高写入数据库可 RAID10）。
11. Disk Cache Policy 为什么 Disabled？ → 防掉电时磁盘写缓存数据丢失。
12. iBMC 是什么、能干什么？ → 独立管理芯片：KVM 虚拟控制台、虚拟光驱、开关机、SEL 日志、SNMP 告警。
13. iBMC 装系统的经典坑？ → 默认英文键盘方向键失灵，切日语键盘布局。
14. 硬件故障四步排查？ → 指示灯 → iBMC 告警/SEL → 系统内 dmesg/ipmitool/smartctl → 换件重建。
15. 虚拟机与容器一句话区别？ → VM 独立内核 OS 级隔离分钟启动，容器共享内核进程级隔离秒级启动，互补不替代。
16. 热迁移核心机制？ → 内存预拷贝迭代收敛 + 短暂停顿切换状态 + 共享存储前提。
17. HA 的两个前提？ → 虚拟机磁盘在共享存储、未勾选"与所选主机绑定"。
18. 快照和备份的区别？ → 快照同存储可秒回滚（防改坏），备份独立副本（防全丢），两层都要。
19. CPU 和内存超分的原则？ → CPU 可适度超分（1:2~1:4，峰值错开），内存谨慎不超（实占资源，超了出可用性问题）。
20. 热备盘的价值？ → 坏盘后自动顶上开始重建，把"坏盘到重建"窗口从小时级压到分钟级。
21. RAID5 和 RAID6 怎么选？ → 大容量盘重建窗口长、需抗双盘故障选 RAID6；我们 SSD+快速换盘机制 RAID5 够用。
22. 系统盘 SAS、数据盘 SSD 的理由？ → 系统盘负载轻重可靠，SAS 够；数据盘随机 IO 密集，SSD 性能匹配——按负载选介质。

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

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 原生细节）用"课程实验 + 理解"口径，不包装成生产经历。
6. 一句话人设：这套华为虚拟化体系是我在银行生产环境从上架到发 VM 全流程亲手做的——"会装会修还能讲明白为什么"，对 3 年经验定位刚好。
7. 衔接移动云项目：被问"虚拟化和云原生什么关系"，用 8.14 的互补关系答，并点出两个项目的演进线：银行项目虚拟化底座 → 移动云项目云原生底座——正好体现技术成长轨迹。