Appearance
第1章 鲲鹏与 TaiShan 服务器：从芯片讲到我亲手配 RAID 的 4 台机器
对应简历：技能第 11 条「熟悉服务器硬件运维：TaiShan 上架、iBMC、RAID 规划」+ 技能第 1 条中的国产化部署部分；项目一「TaiShan 2280 服务器（鲲鹏 ARM，4 台，48×2 核 / 32G×12 / 3.84T SSD / 600G×2 SAS）」。 口径提醒：这一章的"硬件部分"（规格、RAID、上架）是我真实动手的，放开讲；"芯片部分"（微架构、制程、指令集细节）按【理解/了解】准备，讲到"能解释选型逻辑"的深度即可——面试官如果真问芯片微架构，那是芯片岗，不是运维岗。 配套章：本章往下接第 02 章（在这 4 台机器上装 FusionCompute）、第 07 章（iBMC 与 CE 交换机组网）；主宝典 08 章 8.9/8.10 是本章的速答版。
1.1 ARM vs x86：一个运维视角的讲法【必背】
标准回答： 先给一句话结论：ARM 和 x86 是两种 CPU 指令集架构，x86（Intel/AMD）是过去二十年服务器市场的绝对主流，ARM 是这几年在服务器端快速崛起的挑战者，我们项目选 ARM 的直接原因是信创要求用国产鲲鹏芯片。
展开讲三个差异。第一，指令集设计哲学：x86 是 CISC 复杂指令集，指令功能密集、单条指令干得多，靠高主频和超线程推单线程性能；ARM 是 RISC 精简指令集，指令简单、定长、低功耗高能效，靠"堆核"取胜——鲲鹏 920 单颗最高 64 核，我们单颗 48 核、两颗 96 核，而同期 x86 主流单颗 20 多核，核数差出一个量级。
第二，生态：x86 的软件生态无可比拟，几乎所有企业软件原生就有 x86 包；ARM 服务器生态以前是短板，靠鲲鹏这样的厂商牵头做兼容认证和软件移植在补课。我们的项目就是生态补课完成的证明：OS、JDK、数据库、容器全都有 aarch64 版本，我全部装过。
第三，功耗：同性能下 ARM 通常更省电，对数据中心意味着电费和散热压力小——单台差异不大，机柜级和数据中心级才显形。
落到我的场景：虚拟化平台、数据库、K8s 这些吞吐型负载吃多核红利，正是鲲鹏的甜点区；如果跑单线程极端敏感的应用就要先评估。这个"多核吞吐 vs 单线程峰值"的取舍框架，是我答一切"ARM 性能怎么样"问题的骨架。
ARM vs x86 对比速查表：
| 维度 | x86（Intel/AMD） | ARM（鲲鹏） | 对我们的意义 |
|---|---|---|---|
| 指令集 | CISC，变长指令 | RISC，定长精简指令 | 后台知识，答哲学差异用 |
| 核数策略 | 少核高频（单颗 20+ 核） | 多核中频（单颗最高 64 核） | 96 核是虚拟化的本钱 |
| 单核性能 | 占优 | 略逊 | 单线程敏感应用要评估 |
| 内存带宽 | 平台相关 | 鲲鹏 8 通道 DDR4-2933 | 数据库/虚拟化受益 |
| 软件生态 | 存量最大 | 主流已通、长尾要移植 | 我有全栈 aarch64 装机清单 |
| 功耗能效 | 较高 | 同性能更省电 | 大规模部署 TCO 优势 |
| 信创合规 | 不在目录 | 鲲鹏在目录内 | 金融场景一票制 |
追问链：
- 追问1：ARM 以前主要在手机上，为什么现在能上服务器？ → 答：三个条件凑齐了。一是 64 位化——ARMv8 引入 aarch64 后才具备跑企业级负载的能力；二是厂商投入——华为鲲鹏、亚马逊 Graviton、苹果 M 系列这些大厂下场做高性能 ARM 芯片，把"ARM=低性能"的印象打破了；三是软件生态成熟——Linux 内核、主流数据库和容器生态都完成了 ARM 适配。我用两年生产环境验证过第三条：整条鲲鹏栈稳定跑着数币试点业务。
- 追问2：x86 会不会被替代掉？你怎么看技术路线之争？ → 答：我不站队路线，只讲工程事实：x86 靠生态和单核性能还会长期是主流；ARM 在多核吞吐、能效、自主可控三个维度有不可替代的价值，两者会是长期共存、按负载选型的局面。我的职业策略也是"两边都能干"——鲲鹏全栈我部署过，x86 云原生我也运维过，技术路线怎么摇摆我都有饭吃。
- 追问3：aarch64 和 ARM64 是一个东西吗？ → 答：是一个东西的两个名字：AArch64 是 ARMv8 架构的 64 位执行状态，ARM64 是更常用的工业叫法，软件包名里两种拼法都可能出现（Linux 包名多用 aarch64）。我们 Vastbase 安装包文件名里的 aarch64 就是它——看到这个词就等于"鲲鹏/ARM 平台专用包"。
关联话术："这题我一定带上自己的机器做例子：'我们 4 台 2280 是 2×48 核共 96 核，这个核数放同期 x86 双路机型上是高配才有的'——用自己真实配置单佐证观点，比背行业报告有说服力。"
一句话背法：CISC 高频强单核、RISC 低功耗多核堆吞吐；我们选 ARM 的第一因是合规，技术甜点是多核虚拟化。
1.2 鲲鹏 920 处理器：讲得出规格，说得清定位【理解】
标准回答： 鲲鹏 920 是华为自研的 ARM 服务器处理器，2019 年发布。我的记忆按"规格五件事"来讲——这套讲法覆盖了运维需要的全部芯片知识：
① 指令集：兼容 ARMv8.2，64 位 aarch64——这是它能跑企业软件的门票，也是"所有软件都要 aarch64 包"的根源。
② 核心：多核设计，单颗提供多种核数规格，我们用的是 48 核版（系列最高 64 核），主频 2.6GHz。注意它的策略是"核多频率够用"，不是冲高频——单颗内部是多个 die（芯片模块）组合，每个 die 带自己的内存控制器。
③ 内存：8 通道 DDR4-2933，内存带宽较上代提升 60%——这对数据库和虚拟化这种内存密集负载是实打实的收益，我们 12 条 32G 内存插满通道就是为了吃满带宽（展开见 1.4）。
④ IO：PCIe 4.0（IO 带宽较上代提升约三分之二）、支持 100GE 网络接口——盘和网络都不容易成为先到的瓶颈。
⑤ 互联：多颗 CPU 之间用华为自研 HCCS 互联总线（片间带宽最高 480Gbps）；同时它是 SoC 化设计，把南桥、网卡、硬盘控制器集成进芯片，板上器件更少、路径更短。
华为做鲲鹏的方式是"自研芯片 + 开放生态"：芯片和主板开放给整机伙伴，软件上靠 openEuler/openGauss 开源加鲲鹏展翅认证把生态拉起来。我作为部署者的直接体感是：芯片本身我没感知（它就躺在机箱里），我感知到的是它的"衍生品"——96 核的 lscpu 输出、12 条内存的插法、所有软件都要 aarch64 包。
鲲鹏 920 规格速查表（数字以官网产品页为准）：
| 项目 | 规格 | 一句话记忆 |
|---|---|---|
| 指令集 | ARMv8.2（aarch64） | 企业软件的门票 |
| 核心数 | 单颗最高 64 核（我们有 48 核版） | 堆核策略 |
| 主频 | 2.6GHz | 够用不冲高 |
| 内存 | 8 通道 DDR4-2933，带宽较上代 +60% | 数据库的甜点 |
| IO | PCIe 4.0、支持 100GE | 不让 IO 先到瓶颈 |
| 互联 | HCCS 总线，最高 480Gbps | 多颗 CPU 的桥 |
| 集成度 | SoC（南桥/网控/盘控入芯片） | 器件少路径短 |
| 安全 | 支持 SM3/SM4等国密算法、安全启动 | 金融场景加分项 |
追问链：
- 追问1：鲲鹏 920 和 Intel 至强比性能怎么样？ → 答：分维度。多核吞吐：96 核双路对大部分并行负载（虚拟化、数据库连接池、容器集群）吞吐占优，我们 15 台虚拟机加 K8s 加数据库全跑在上面，就是实证。单核性能：2.6GHz 的单线程能力与同期高端至强有差距，对单线程极端敏感的负载要先评估。我的结论句式："鲲鹏赢在核数和内存带宽，x86 赢在单核和生态存量——选型看负载画像，我们的负载画像适合鲲鹏。"
- 追问2：ARM 是英国的架构，用 ARM 授权算自主可控吗？ → 答：这个我知道到授权模式层面：华为获得的是 ARMv8 指令集架构授权，可以基于指令集自主设计微架构和核心，不依赖 ARM 公司逐颗供货——类似"买了地皮自己盖楼"。更深入的商业和法律细节我不评论，工程上我能给的证据是：鲲鹏芯片供应没有卡住我们的项目。这题答到授权模式加工程证据就够了，不陷入口水战。
- 追问3：一颗 CPU 里的 die 和 NUMA 有什么关系？ → 答：鲲鹏 920 单颗内部多个 die、每个 die 带自己的内存控制器，所以操作系统看到的 NUMA 节点会按 die 细分——一颗 48 核 CPU 可能对应多个 NUMA 节点，lscpu 一看便知。这直接影响数据库绑核和内存分配策略，是 1.5 节的主题。
关联话术："芯片题我主动控制在'规格五件事'的深度，讲完补一句'更深的微架构我就不装了，我给您讲讲这颗芯片落到服务器上我怎么用的'——顺势滑到 1.3/1.4 我最熟的整机层，把面试官带进我的主场。"
一句话背法：ARMv8.2 / 48核2.6GHz / 8通道DDR4 / PCIe4.0 / HCCS——五件事讲完一颗芯。
1.2.1 从 lscpu 输出认识我的宿主机（命令佐证）
讲芯片规格最好的证据是登录机器敲命令。这是我们宿主机上 lscpu 关键字段的讲解版（面试可以口述"我在我们宿主机上敲 lscpu 看到什么"）：
text
Architecture: aarch64 ← ARM 64 位架构（不是 x86_64）
CPU(s): 96 ← 2 颗 × 48 核的总核数
Model name: Kunpeng-920 ← 处理器型号
NUMA node(s): 4 ← NUMA 节点数（按 die 细分，比 x86 多）
NUMA node0 CPU(s): 0-23 ← 每个节点自己的核组
...三个讲解点：①Architecture: aarch64 一行字就回答了"你们是不是真 ARM 环境"——比任何口头描述都硬；②CPU(s): 96 与简历配置单互为印证；③NUMA 节点数和各节点 CPU 列表，就是 1.5 节 NUMA 话题的入口——"我在自己机器上看到的拓扑"。
配套还有两条硬件侧命令也值得口述：free -h 看 384G 内存的总量与可用（配平 15 台 VM 的账）、lsblk 看系统盘（RAID1 后的 md 设备）与数据盘（SSD）的块设备布局——"lscpu/free/lsblk 三连"是我接管任何一台新宿主机的第一个动作，也是向面试官展示"命令级熟悉"的低成本方式。
追问：为什么 NUMA 节点是 4 个不是 2 个？ → 答：直觉上双路机器是 2 个节点（每颗 CPU 一个），但鲲鹏 920 单颗内部是多 die 结构、每个 die 带独立内存控制器，操作系统按内存控制器粒度划分节点，所以 2 颗 CPU 会呈现 4 个或更多 NUMA 节点。这个数字以 lscpu 实际输出为准——我讲这个细节是想说明：NUMA 节点数由内存控制器拓扑决定，不是简单数 CPU 颗数。
1.3 TaiShan 200 家族与 2280 的定位【必背】
标准回答： TaiShan 是华为基于自研鲲鹏处理器的服务器品牌：TaiShan 100 是第一代（鲲鹏 916），TaiShan 200 是第二代（鲲鹏 920），我们用的就是 200 系列；后续还演进出了 200 Pro 等更高主频版本。
TaiShan 200 按场景分型号，家族速记：1280 是 1U 高密型（机架空间紧张场景）；2280 是 2U 双路均衡型——通用计算主力机型，我们用的就是它；2480 是高性能型；5280/5290 是存储型（4U、大盘位）；X6000 是多节点高密型。选型逻辑一句话："按物理形态（1U/2U/4U）和负载倾向（均衡/性能/存储/密度）对号入座"。
"均衡型"三个字是理解 2280 的钥匙：它不追求单项极限，而是在计算密度、内存容量、存储扩展、网络接口之间取平衡——2U 的空间里放下两颗 CPU、32 条 DIMM 插槽、十几个盘位和多个 PCIe 插槽，什么负载都接得住。这正好匹配我们的负载画像：一台机器上要同时跑虚拟化计算、大内存的数据库 VM、多平面的网络端口需求——均衡型就是为这种"一机多职"设计的。
两个补充背景：①我们的 4 台是 V2 版本；②华为后来把鲲鹏主板开放给整机伙伴（市场上还有超聚变、神州鲲泰等品牌的鲲鹏机型），芯片和生态同一套——面试被问"为什么不是别的牌子"，答"配套表定的是华为原厂整机 TaiShan 2280"。
TaiShan 200 家族速查表：
| 型号 | 形态 | 定位 | 一句话 |
|---|---|---|---|
| 1280 | 1U 双路 | 高密型 | 空间紧张塞机器 |
| 2280 | 2U 双路 | 均衡型 | 通用主力，我们的 4 台 |
| 2480 | 2U 双路 | 高性能型 | 计算更激进 |
| 5280/5290 | 4U 双路 | 存储型 | 大盘位大容量 |
| X6000 | 多节点 | 高密多节点 | 一个箱体多台服务器 |
追问链：
- 追问1：2U 是什么意思？机架怎么规划的？ → 答：U 是机架服务器的高度单位，1U 约 4.45 厘米，2U 就是两倍。标准 42U 机柜里，4 台 2U 服务器加 4 台交换机只占一部分高度，但重点不是"塞得下"而是"电和散热"——每台双路服务器近千瓦功耗，机柜供电和风道要跟机房提前确认，这是上架前检查清单的必查项（详见 1.9）。
- 追问2：为什么不选存储型放更多盘？ → 答：我们的存储架构是"虚拟化统一本地盘"——每台 2280 上的 SSD 作为 FC 数据存储，3.84T 已够当前规模，数据库的 800G 虚拟盘也从这里切。如果未来数据量上量，正确路径是外接集中存储（OceanStor 这类）而不是换存储型服务器——那是架构升级，不是加盘能解决的。这样答显示我理解"机型只是架构的一环"。
关联话术："机型定位题我会用'钥匙'这个词：'2280 是均衡型，均衡就是它的定位钥匙——我们一台机要跑虚拟化、数据库、多平面网络，正是均衡型的目标场景'——用场景反推选型，显得是自己想明白的而不是背的。"
一句话背法：TaiShan 200 家族按"高密 1280 / 均衡 2280 / 高性能 2480 / 存储 5280"排；我们是 2280 均衡型，一机多职的正选。
1.3.1 2280 的关键部件布局（产品页规格对照）
以官网产品页规格为参照，把我们用到的部件过一遍——面试被问"这台机器有哪些扩展能力"时按这张表答：
| 部件位 | 2280 规格（产品页口径） | 我们项目的用法 |
|---|---|---|
| 处理器槽位 | 2 路（2×鲲鹏 920） | 2×48 核 |
| 内存插槽 | 32 个 DDR4 DIMM 槽 | 插 12 条 32G（留扩容余量） |
| 盘位 | 最多 16 个 3.5 寸或 27 个 2.5 寸盘位（配置不同） | 2×600G SAS + 1×3.84T SSD |
| NVMe | 支持 NVMe SSD | 未配置（未来 IO 升级方向） |
| PCIe | 最多 8 个 PCIe 4.0 插槽 | 板载网口承担双平面，未额外加卡 |
| 网络插卡 | 板载 2 个网络插卡位（各 4 端口） | 管理网 + 业务网双平面 |
| 电源 | 2 个热插拔电源（1+1 冗余） | 双路分接 A/B 供电 |
| 风扇 | 热插拔风扇（N+1 冗余） | 免维护，传感器监控 |
| 管理口 | iBMC 独立管理网口 | 接 BMC 交换机平面 |
看点：①内存槽 32 个我们只插 12 个——扩容不需要换机器，加条就行，这是"配置留白"的思路；②支持 NVMe 意味着 IO 升级有路——如果数据库盘成为瓶颈，加装 NVMe 是第一选项；③电源风扇全冗余——任何单点坏了机器不停，这是"两年零硬件故障停机"的架构基础之一。
1.4 我的 4 台 2280：规格逐项解读【必背·核心】
标准回答： 这节是我硬件经历的"主场"。规格单原文我背得出来：TaiShan 2280 V2，4 台，每台 48 核×2 颗鲲鹏 920、32G×12 条内存、1 块 3.84T SSD、2 块 600G SAS 盘。逐项解读为什么这么配——
CPU（48 核 ×2 = 96 物理核）：这是虚拟化宿主机的核心筹码。按 CPU 超分 1:4~1:8 的行业常规水位，96 核理论可切 384~768 vCPU；我们实际只分配 100 出头 vCPU（约 1:1~1:2 的保守水位），支撑 15 台虚拟机绰绰有余。银行生产环境主动保守——稳定优先于利用率。
内存（32G ×12 = 384G）：内存是虚拟化最容易被吃光的资源，而且不能像 CPU 那样超分（内存复用技术有性能风险，生产慎用）。算账：15 台 VM 规划合计约 240G（明细见追问1），加 CNA/VRM 自身开销、故障迁移要求目标主机有空闲内存的水位——384G 是"算过账"的配置。另外 12 条还有个讲究：8 通道 DDR4 要插满对应槽位才能吃满带宽，插一半带宽就浪费；同等容量下 12×32G 优于 6×64G，就是通道数的原因。
数据盘（3.84T SSD ×1）：作为 FC 的数据存储，放全部虚拟机磁盘文件。选 SSD 的理由是随机 IO：十几台 VM 混合读写叠加后是典型的随机负载，机械盘的 IOPS 撑不住。
系统盘（600G SAS ×2）：小容量企业盘专门做系统盘，两块组 RAID1 镜像保操作系统——系统盘和数据盘分置是虚拟化宿主机的标准做法：系统挂了可以重装不影响数据，数据盘满了不影响系统运行。
RAID（该配置无 RAID 卡）：必须如实讲的细节——这批 2280 配置不带 RAID 卡（部署指南明确写了 TaiShan 200 Model 2280 该配置不支持 RAID 卡、安装过程组软 RAID），所以 RAID 用内核 mdadm 软件阵列落地：系统盘软 RAID1、数据盘按 RAID5 基线。软硬 RAID 的取舍展开在 1.8。
规格速记表（面试报数用，一字不能错）：
| 部件 | 配置 | 合计/说明 | 为什么这么配（一句话） |
|---|---|---|---|
| CPU | 鲲鹏 920 ×2，单颗 48 核 2.6GHz | 96 物理核 | 虚拟化吃多核，96 核是超分的本钱 |
| 内存 | 32G DDR4 ×12 | 384G | 内存不可超分，按规划+水位配足；插满吃带宽 |
| 数据盘 | 3.84T SSD ×1 | FC 数据存储 | 随机 IO 匹配多 VM 混合负载 |
| 系统盘 | 600G SAS ×2 | 组 RAID1 | 双盘镜像保系统，系统/数据分置 |
| RAID | 无 RAID 卡（该配置） | 软 RAID1 + RAID5 | 无卡配置的工程处理，见 1.8 |
| 网络 | 板载多网口 + iBMC 独立口 | 管理/业务双平面 | 双平面组网，详见第 07 章 |
| 整机 | TaiShan 2280 V2，2U | ×4 台 | 3 台做 CNA + 1 台做 VRM |
这份配置单的每一项我都能讲出"为什么"——这就是"装过"和"懂配置"的区别。
追问链：
- 追问1：384G 内存怎么分给 15 台虚拟机的？ → 答：规划明细我背得出：3 台 K8s master 各 8G、2 台 BCS 管理面分别 8G/16G、2 台数币中间件各 32G、6 台 BCS 数据面各 32G、2 台数据库各 64G——合计约 240G，宿主机再留虚拟化层开销和迁移水位。为什么数据库给到 64G：数据库 VM 的内存直接决定缓存命中和并发能力，是全平台最该给足的资源。这题答得出明细，"规划过"三个字就不用自证了。
- 追问2：CPU 超分多少倍合适？超分了会怎样？ → 答：行业常见 1:4~1:8，前提是负载低且错峰；我们实际 1:1~1:2，银行环境求稳。超分的风险是"挤兑"：多台 VM 同时高负载时宿主机 CPU 就绪队列变长，虚拟机内表现为卡顿——Linux 上看 top 的 steal 时间（st 列）、虚拟化平台看 CPU 就绪率指标。发现持续挤兑的处理：限流（vCPU 限额）、迁移 VM 均衡负载、扩容宿主机。
- 追问3：为什么系统盘用 SAS 不用 SSD？ → 答：系统盘的负载画像是低频写入、容量小、可靠性优先——两块 600G SAS 组 RAID1 镜像冗余足够，SAS 企业盘的稳定性表现成熟；SSD 的大容量和高随机 IOPS 留给真正需要的数据存储。预算花在刀刃上，这是配置单背后的经济学。
- 追问4：96 核的宿主机，VRM 为什么独占一台？ → 答：VRM 是管理节点，它自己就是一台装了管理软件的物理机（我们采用物理部署）。管理面与计算面分机部署，好处是计算宿主机资源全部给业务 VM、管理故障域独立——这是中小规模下简单可靠的架构；更大规模会考虑 VRM 虚拟化部署甚至主备。这个细节衔接第 02 章 2.2。
关联话术："这一节是我的'规格脱口秀'——面试官问'你们服务器什么配置'，我从 CPU 讲到内存讲到盘，每一项带一句为什么，90 秒讲完。对方听完的反应通常是'你是真碰过这些机器的'——细节密度就是我的信任状。"
一句话背法：96 核 / 384G（12×32 插满通道）/ 3.84T SSD 数据 + 600G SAS×2 系统 RAID1 / 无卡走软 RAID。
1.4.1 15 台虚拟机的资源账（CPU/内存分配明细）
这一小节是 1.4 追问1 的展开版——把明细背成表，"规划过"三个字就不证自明。
| 虚拟机角色 | 数量 | vCPU | 内存 | 磁盘 | OS |
|---|---|---|---|---|---|
| K8s master（后升级 3 master） | 3 | 4 | 8G | 100G | UOS 20 |
| BCS 管理平面 | 2 | 4/8 | 8G/16G | 200G | UOS 20 |
| 数币中间件 | 2 | 16 | 32G | 200G | UOS 20 |
| BCS 数据面 | 6 | 16 | 32G | 500G | UOS 20 |
| 数据库（Vastbase 主/备） | 2 | 32 | 64G | 800G | 麒麟 V10 SP1 |
| 合计 | 15 | 约 160 vCPU | 约 264G | — | — |
两个看点：①vCPU 合计约 160，对 3 台 CNA 共 288 核（96×3），水位约 0.55:1——远低于超分水位，为在线迁移和故障 HA 留足余量；②数据库两台给了单台 32C/64G/800G 的"大规格"，是全平台资源倾斜最明显的角色——数据库是稳定性锚点，资源优先级最高。磁盘从 SSD 数据存储切出来，DME 三节点的三台 VM（各 1T）也从 FC 的存储里分配。
1.4.2 磁盘容量账（3.84T 怎么够 15 台 VM）
面试可能追问"15 台 VM 的磁盘加起来早就超 3.84T 了怎么放下"——答案分两层：
第一层：磁盘是分布在 3 台 CNA 上的本地存储，不是一台扛全部。每台 CNA 的数据存储约 3.84T，虚拟机落在哪台主机、磁盘就占哪台的存储；FC 创建 VM 时按主机/集群调度放置。
第二层：规划容量 ≠ 已用容量。15 台 VM 的规划盘合计约 4.5T（见 1.4.1 表），摊到 3 台 CNA 每台承载约 1.5T 的规划量，对单台 3.84T 水位约四成——瘦分配机制下实际占用更低，且为 DME 三节点（每台 1T）预留后仍在安全水位。容量水位线我们按 70% 管——超线就触发扩容评估，这是从主宝典 8.16 超分与容量管理延续下来的纪律。
追问：数据库 VM 为什么不给 1T 以上？ → 答：800G 是配套表的规划值，按"数据文件 + WAL 预留（安装要求预留 30G WAL + 数据增长预估）"算出来的；更大容量的正确路径是外挂集中存储或扩数据盘，不是一次给足——金融环境资源分配讲"按需 + 可扩"，留变更余地。
1.5 多核与 NUMA：96 核的调度地形【理解】
标准回答： NUMA（非统一内存访问，Non-Uniform Memory Access）是多路服务器的内存拓扑：每颗 CPU（甚至每个 die）有自己"就近"的本地内存，访问快；访问其他节点的内存要走互联总线（鲲鹏上是 HCCS），慢一大截。所以 96 核机器在操作系统眼里不是一个"均匀的大锅"，而是多个 NUMA 节点——每个节点有自己的核组与本地内存。
NUMA 对运维的实际影响三个：第一，内存尽量本地分配——跨节点访存让数据库这类内存密集应用性能掉一截；第二，绑核绑节点——高性能场景用 numactl 把进程绑到固定节点，避免调度器把线程在节点间搬来搬去；第三，数据库的 NUMA 感知参数——openGauss/Vastbase 明确提供相关配置，我真实调过的就有 numa_distribute_mode（NUMA 分发模式）和线程池绑核配置 thread_pool_attr 里指定 allbind——1.4 的 96 核地形，直接决定 04 章的数据库参数，这是我"硬件和数据库知识打通"的实例。
查看拓扑与状态的命令三连（鲲鹏上节点数比同核数 x86 更多，更要看）：
bash
lscpu | grep -i numa # 节点数量与各节点 CPU 列表
numactl --hardware # 节点内存大小与距离矩阵
numastat # 各节点内存分配统计（大量远端命中=亲和没做好）我的理解深度到"拓扑 + 三个影响 + 我调过的参数"这一层；NUMA 内部的缓存一致性协议、内核页迁移算法属于【了解】层，面试点到"我知道有这个机制，具体实现没深入"即可。
追问链：
- 追问1：NUMA 不当会出什么实际故障？ → 答：典型是"资源没满但性能抖"——CPU 利用率不高、内存也够，但数据库延迟周期性变差；numastat 一看大量内存落在远端节点。处理思路：数据库绑核绑节点、检查 NUMA 相关参数、确认虚拟机 vNUMA 拓扑暴露策略。我在 Vastbase 里配 numa_distribute_mode 和线程池绑核就是"让线程和内存按节点分布"的预防性优化。
- 追问2：虚拟机会遇到 NUMA 问题吗？ → 答：会，而且多一层：宿主机 NUMA + 虚拟机 vCPU 调度可能跨节点，等于"套娃跨访存"。缓解手段：大规格 VM 尽量整体调度到单节点（虚拟化平台的 NUMA 调度策略）、数据库类 VM 不做 CPU 过度绑定、宿主机侧保持 NUMA 统计监控。我们在 FC 上的数据库 VM 给到 32 vCPU/64G，属于"要让平台调度器认真对待 NUMA"的规格，这正是我知道这个话题的原因。
关联话术："NUMA 这题是我把硬件和数据库两章缝起来的绝佳机会：'96 核双路的 NUMA 地形，直接决定了我在 Vastbase 里配 numa_distribute_mode 和线程池绑核'——一句话让面试官看到我的硬件知识和数据库调优是通的。"
一句话背法：本地内存快、跨节点慢；lscpu/numactl/numastat 三连；数据库要 NUMA 感知——我调过 numa_distribute_mode。
1.6 aarch64 软件生态与移植：没有 ARM 包怎么办【理解】
标准回答： 鲲鹏落地的工程难点不在芯片在软件：所有软件都必须有 aarch64 版本。我的实战清单可以证明主流栈已通：操作系统——统信 UOS/麒麟 V10 有鲲鹏版本；Java——毕昇 JDK 8u362 aarch64；数据库——Vastbase 安装包文件名就写着 aarch64_kunpeng；容器全家桶——Docker 下载 aarch64 静态包、K8s 用 aarch64 的 yum 源（我真实配过华为云镜像源的 kubernetes aarch64 仓库）、flannel 与 BCS 镜像全是 aarch64 离线 tar 包。
识别方法一行字：包名带 aarch64 / arm64 就是 ARM 包，x86_64 / amd64 的在鲲鹏上装不上或跑不了。
遇到没有官方 ARM 包的软件，我的四步决策链：①查鲲鹏社区兼容性列表，看有没有伙伴移植版或认证版本；②找软件自身的 arm64 源码构建——开源软件基本都能源码编译，我的 Redis 5.0.3 就是在 ARM 上源码编译装的，流程与 x86 无异（差异只在依赖核对）；③评估功能等价的替代品；④都不行就提请方案变更。这是信创项目真实的决策链——不是所有软件都硬移植，工程上有"换"这个选项。
另外鲲鹏社区提供 x2openEuler 这类迁移评估工具（扫描 x86 环境输出移植报告），属于生态的工程化武器，我按"知道用途、没做过大规模迁移评估"的口径掌握。
我的 aarch64 装机清单（生态成熟度的证据链，逐项装过）：
| 软件层 | 我们用的 | 获取方式 | 包名里的架构标识 |
|---|---|---|---|
| OS | 统信 UOS Server 20 / 麒麟 V10 SP1 | 官方 ISO | aarch64 ISO |
| JDK | 毕昇 JDK 1.8.0_362 | 鲲鹏镜像站 | linux-aarch64.tar.gz |
| 数据库 | Vastbase G100 2.2 | 海量侧提供 | aarch64_kunpeng 包名 |
| 容器运行时 | Docker 18.09 | 官方静态包 | docker-xx.tgz(aarch64 目录) |
| K8s | v1.17.3 | 华为云镜像 yum 源 | kubernetes-el7-aarch64 仓库 |
| 网络 | flannel | 离线 yaml + 镜像 | aarch64 镜像 tar |
| 区块链 | BCS 边缘自治 1.2.6 | 镜像 tar 包 | 1.2.6-aarch64 文件名 |
| 缓存 | Redis 5.0.3 | 源码编译 | 编译产物即本地架构 |
追问链：
- 追问1：源码编译 ARM 包和 x86 有什么不同？ → 答：流程完全一样（configure/make/make install），差异在依赖：要确认所有依赖库都有 aarch64 版本，某个依赖只有 x86 包就得先把依赖编出来。我编 Redis 没遇到依赖问题（gcc 是系统自带的 aarch64 版）；但如果编依赖重的项目（比如带 openssl 的 nginx）就要逐个核对。经验法则：越底层的库越早有人移植，越冷门的应用越可能踩坑。
- 追问2：Docker 镜像分架构吗？拉错会怎样？ → 答：分。仓库的同一 tag 可以对应多架构 manifest，ARM 机器上 docker pull 默认拉 aarch64 变体；但手工导入离线 tar 包时没人替你把关——把 x86 镜像 load 进 ARM 机器，load 能成功，run 时报 "exec format error"（可执行文件格式不对）。我们 BCS 离线交付全用 aarch64 镜像 tar 包，就是防这个。这个报错我讲得出来，因为 ARM 迁移期它太常见。
- 追问3：怎么在装机前评估一个软件能不能迁到鲲鹏？ → 答：三查：查鲲鹏兼容性认证列表（有没有认证）；查软件官方是否发布 arm64 构建（发行页/镜像仓库）；查社区案例（搜"aarch64 + 软件名"的部署文章）。三查都空白的软件要安排 PoC 编译验证——把不确定性消灭在装机之前，这是实施计划的组成部分，不是临时救火。
关联话术："'软件兼容怎么办'是所有国产化面试的必问题，我的答案结构是'主流已通的证据清单 + 遇到没有包的四步决策链'——前者证明生态成熟度，后者证明我有工程判断力，不是无脑吹。"
一句话背法：认准 aarch64/arm64 标识；主流栈已全通（我有装机清单）；没包走"查认证→源码编→找替代→提变更"四步。
1.7 选型对比：鲲鹏方案 vs x86 方案【理解】
标准回答： 面试官爱问"鲲鹏比 x86 好在哪 / 换 x86 方案要改什么"，我用一张对比表加一个结论句回答。对比五维度：核数密度——96 核双路对同期 x86 双路 40~56 核，吞吐型负载鲲鹏占优；单核性能——x86 高频占优；内存带宽——鲲鹏 8 通道 DDR4 是卖点；生态存量——x86 完胜，鲲鹏靠认证补齐主流；功耗能效——ARM 同性能更省电；合规——鲲鹏在信创目录内，x86 不在，这一条在金融场景是一票制。
如果把我们方案换成 x86，改动清单逐层：服务器换 x86 机型；FC 换 x86 版 ISO（产品本身双架构，流程完全一样）；OS 可换 CentOS 系或国产 x86 版；JDK 换 OpenJDK x64（毕昇也有 x64 版本）；Vastbase 换它的 x86 安装包（产品双架构）；BCS/Docker/K8s 全换 x86 镜像与包——链路技术上走得通，但信创合规一关过不了，这正是我们选鲲鹏的根本原因。结论句："技术上 x86 方案成立，商业和合规上不成立——技术选型永远服务于约束条件。"
国产芯片横向定位（【了解】层，说清格局即可）：鲲鹏（华为，ARM 授权自研核）、飞腾（ARM 系，党政市场多见）、海光（x86 授权系，兼容 x86 生态存量）、龙芯（自研指令集 LoongArch，自主度最高生态最小）。格局记忆法："ARM 系两家（鲲鹏/飞腾）、x86 系一家（海光）、完全自研一家（龙芯）"——金融行业主流试点是鲲鹏和海光两条路线，我们项目是鲲鹏路线。
鲲鹏 vs x86 方案对比表：
| 维度 | 鲲鹏方案（我们） | x86 方案 | 判断 |
|---|---|---|---|
| 核数 | 2×48=96 核 | 双路 40~56 核 | 吞吐负载鲲鹏优 |
| 单核 | 2.6GHz | 高频占优 | 单线程敏感需评估 |
| 内存带宽 | 8 通道 DDR4 | 平台相关 | DB/虚拟化受益 |
| 生态存量 | 主流通、长尾移植 | 全覆盖 | x86 完胜 |
| 能效 | 更省电 | 较高 | 大规模 TCO 差异 |
| 信创合规 | 在目录 | 不在 | 金融一票制 |
"如果换 x86"逐层改动清单（追问高频，按层背）：
| 层 | 鲲鹏现状 | 换 x86 后 | 改动量 |
|---|---|---|---|
| 服务器 | TaiShan 2280 ×4 | x86 双路机型 | 采购替换 |
| 虚拟化 | FC 8.3.0 ARM 版 ISO | FC x86 版 ISO | 流程完全一样，换镜像 |
| OS | UOS/麒麟 aarch64 | 同名 x86 版或 CentOS 系 | 换 ISO 重装 |
| JDK | 毕昇 8u362 aarch64 | OpenJDK x64（毕昇也有 x64） | 换包重配 |
| 数据库 | Vastbase aarch64_kunpeng 包 | Vastbase x86 包 | 换包重装 |
| 容器 | aarch64 镜像 + ARM yum 源 | x86 镜像 + x86 源 | 全量换镜像 |
| 合规 | 信创目录内 | 不在目录 | 过不了关（根本障碍） |
这张表的讲法重点：技术列全部"可替换、流程不变"，最后一行"合规不可替换"——把结论钉死在约束上，而不是技术偏好上。
追问链：
- 追问1：海光和鲲鹏怎么选？ → 答：核心差异是生态策略：海光走 x86 兼容路线，存量 x86 软件直接跑、迁移成本低，但指令集授权来源决定其自主层级有争议；鲲鹏走 ARM + 自建生态路线，迁移要做 aarch64 适配，但生态自主度和多核上限更高。金融核心系统两条路线都在试点，我们项目定鲲鹏。我按"约束条件决定选型"讲，不替客户下结论。
- 追问2：都说 ARM 省电，具体省多少有意义吗？ → 答：单台差异不大（几十到一二百瓦），机柜级和数据中心级才显形——百台规模一年电费差出几万到十几万，加上散热联动，TCO 差异是真实的。我们 4 台规模省电不构成选型理由（合规才是），但讲得出 TCO 视角说明我理解机房经济学。
- 追问3：国产化迁移最大的坑是什么？ → 答：我的 TOP1 是"隐性架构依赖"：有的软件包名没写架构、有的脚本里写死了 x86 路径或依赖、有的第三方驱动只有 x86 版——这些不在"有没有 ARM 包"的显式检查里，装机到一半才爆。对策是装机前做一次依赖扫描 + 预装演练（先在一台测试机全流程走通再批量）。这个坑的完整版在第 08 章问答集还有专设题。
关联话术："对比题我最喜欢，因为它把话题从'背规格'升级到'做决策'——我用'约束条件决定选型'收尾，面试官会记住我是一个有选型框架的工程师，而不只是个装机员。"
一句话背法：技术上双栈都通、合规上只有一条路；对比永远分维度带场景。
1.8 RAID 规划：无 RAID 卡的真实处理【必背】
标准回答： RAID 规划是我装机前必做的第一件事，原则先讲：系统盘要冗余（系统挂了整机躺平），数据盘要兼顾容量、性能和冗余。
我们的实际处理——这批 TaiShan 2280 的配置不带 RAID 卡（部署指南原话：TaiShan 200 Model 2280 该型号不支持 RAID 卡，安装过程中组软 RAID），所以：两块 600G SAS 系统盘组软 RAID1（镜像，容量减半但任意一块盘坏系统无恙）；数据盘按部署基线"其余硬盘组 RAID5"执行（我们单块 3.84T SSD 承载数据存储，RAID5 为规划基线态）。
软 RAID 用的是内核 mdadm 机制，不占 RAID 卡预算，代价是校验计算吃 CPU、没有硬件缓存加速——但对我们 SSD 数据盘的负载（虚拟机磁盘文件混合读写）够用，这是配置约束下的务实解。如果是重载数据库直连存储且预算允许，我会建议上硬 RAID 卡——"约束下能落地、有预算讲最优"，两头都站得住。
另一个必须会讲的知识点：RAID 的 Disk Cache Policy 要设 Disabled——海量 Vastbase 的安装要求里明确写了这一条，原因是 RAID 卡缓存里的脏数据在异常掉电时会丢（除非有 BBU 电池/电容保护），而数据库自己的 WAL 日志已经保证了持久性语义，RAID 层再"善意"缓存反而破坏它。这是"RAID 设置影响数据库可靠性"的典型教学案例，我专门记过。
RAID 级别速查（项目用到 RAID1/RAID5，另两个是追问储备）：
| 级别 | 机制 | 容量利用率 | 冗余能力 | 项目用途 |
|---|---|---|---|---|
| RAID0 | 纯条带 | 100% | 无（挂一块全没） | 未用；追问答"只要性能不要命" |
| RAID1 | 双盘镜像 | 50% | 挂一块无恙 | 系统盘 600G SAS ×2 |
| RAID5 | 条带+分布式校验 | (N-1)/N | 挂一块可重建 | 数据盘基线 |
| RAID10 | 镜像+条带 | 50% | 可挂多块（限不同镜像对） | 高性能 DB 常用；预算够可上 |
软 RAID 常用命令（mdadm，装机与排障都用得上）：
bash
cat /proc/mdstat # 一眼看所有软 RAID 阵列状态
mdadm --detail /dev/md0 # 单个阵列详情（级别/成员/状态）
mdadm -C /dev/md0 -l 1 -n 2 /dev/sda /dev/sdb # 创建 RAID1 示例
mdadm /dev/md0 -f /dev/sda # 模拟标记故障盘（演练用）
mdadm /dev/md0 -r /dev/sda # 移除故障盘
mdadm /dev/md0 -a /dev/sdc # 加新盘进阵列（重建）追问链：
- 追问1：软 RAID 和硬 RAID 怎么选？ → 答：硬 RAID 优势——独立 RAID 卡有自己的处理器和缓存（带 BBU 时写性能好）、校验不占主机 CPU、热备与在线扩容成熟；软 RAID 优势——零成本、机制透明（mdadm 可查可控）、不依赖特定硬件、换平台可迁移。我们用软 RAID 是配置约束下的选择并被两年运行验证。生产建议按"负载轻重 + 预算"分层：系统盘和数据量不大的场景软 RAID 够用；重载数据库直连大盘位就上硬卡。
- 追问2：RAID5 挂了两块盘会怎样？ → 答：RAID5 只容忍单盘故障，双盘同时故障阵列即不可用，只能靠备份恢复。所以运维动作是：单盘故障立即换盘重建；重建期间是"裸奔窗口"（第二块盘故障概率上升、重建 IO 压力大），要盯紧；有条件配热备盘缩短窗口。把"重建窗口风险"讲出来，说明我理解 RAID 不是保险箱。
- 追问3：为什么数据库场景特别在意 Disk Cache Policy？ → 答：数据库的 WAL/redo 机制建立在"我写成功=已持久"的语义上；如果 RAID 卡把写请求缓存在易失缓存里就向上层回了成功，掉电时这段数据就没了——数据库以为已经持久的事务实际丢失，这是最恶性的"静默丢数据"。所以要么 Disabled，要么确保 BBU/电容保护 + 正确的缓存策略。Vastbase 安装文档把这条写成硬性要求，道理就在这。
关联话术："RAID 题我必带两个一手细节：一是'我们这批 2280 没 RAID 卡、装软 RAID'的真实处理，二是 Vastbase 文档里 Disk Cache Policy Disabled 的要求——两个细节都是'文档级证据'，别人编不出来。"
一句话背法：系统 RAID1 保命、数据 RAID5 平衡；我们没卡走 mdadm 软阵列；DB 场景 RAID 缓存必须 Disabled 或有 BBU。
1.9 我的操作叙事：从上架到交出虚拟化宿主机【必背】
标准回答： 把 1.4 到 1.8 串成一个完整 STAR。
背景（S）：项目启动，4 台 TaiShan 2280 到货，两周内要交出可安装 FusionCompute 的虚拟化宿主机底座。
任务（T）：我负责服务器的上架检查、RAID 规划和系统准备，交出 3 台 CNA + 1 台 VRM 的安装底座。
行动（A）：第一步上架前检查（清单见下）；第二步网络规划——给每台服务器分配管理平面 IP 与 BMC IP（管理网段），首次登录 iBMC 修改默认口令、核对 BMC 固件版本统一到基线、确认传感器读数正常（详细 iBMC 操作在第 07 章）；第三步 RAID——确认这批配置无 RAID 卡后按软 RAID 落地：系统盘两块 SAS 组 RAID1，数据盘按 RAID5 基线；第四步预检——通过 iBMC 远程控制台确认能正常启动进安装引导、磁盘与网卡识别齐全，把 4 台机器交接给 FusionCompute 安装流程（第 02 章 2.4）。
结果（R）：4 台服务器一次通过硬件验收；后续 FC 安装和两年运行期没出过硬件层故障；这套上架检查和 RAID 规范沉淀成公司实施文档的硬件章节。
我的上架前检查清单（七项，逐项打钩）：
- [ ] 配置单核对：CPU/内存/硬盘的型号与数量逐项对单（96 核、12 条内存、1 SSD + 2 SAS）
- [ ] 外观检查：运输损伤、导轨配件、理线空间
- [ ] 供电：双电源模块分接 A/B 供电回路（一路断电不断机）
- [ ] 机柜规划：U 位、重量分布、风道方向与机房冷热通道一致
- [ ] iBMC 初始化：改默认口令、设 BMC IP、核对固件版本基线
- [ ] 传感器基线：温度/电压/风扇转速读数正常、SEL 日志无预置故障
- [ ] 部件识别：lscpu/盘位/网卡数量与配置单一致
追问链：
- 追问1：上架前检查具体怎么执行？ → 答：清单化逐项打钩——"没有清单的检查叫看一眼"。每项的判断标准写进检查表（比如供电一项明确"双电源分接不同回路"），异常项当场拍照记录、开箱单留档。这套清单本身是我做的交付物之一。
- 追问2：硬件故障两年零，是运气还是管理？ → 答：三分运气七分管理：上架基线把住入口（固件统一、口令合规、部件识别核对）；运行期 iBMC 传感器告警接入监控，硬盘健康趋势（介质错误计数等）有人看，苗头在变成故障前处理掉。硬件"不出事"是带外管理和巡检纪律的结果——这题顺势把话题引到第 07 章 iBMC。
- 追问3：如果上架时发现配置与订单不符怎么办？ → 答：流程三步：当场拍照留证、按箱单差异记录开异常单、联系供应商/华为渠道走补货或换货——绝不"先装上凑合"。银行环境里硬件底账必须和配置单完全一致，否则后续维保和故障处理都会扯皮。原则：问题在上架阶段解决成本最低。
关联话术："这段 STAR 是我答'你在项目里做过什么硬件工作'的标准答案——注意我讲的不是'服务器上架'四个字，而是七个检查项、RAID 决策和固件基线这些可验证的动作。细节颗粒度决定可信度。"
一句话背法：两周、4 台、七项检查、软 RAID 落地、零硬件故障两年——S/T/A/R 各一句话能背下来。
1.9.1 交付时间线（叙事的"节奏版"）
有些面试官喜欢听时间线而不是 STAR——按天讲一遍（数字口径：两周窗口）：
| 时间 | 动作 | 交付物/检查点 |
|---|---|---|
| D1 | 到货开箱、配置单核对 | 箱单差异记录=0 |
| D2 | 上架、供电接入、iBMC 首配 | 4 台 BMC IP 全通、口令合规 |
| D3 | 固件基线核对、传感器基线采集 | SEL 日志干净、读数正常 |
| D4 | RAID 规划评审（无卡→软 RAID 方案确认） | 方案写进实施文档 |
| D5 | 软 RAID 落地（RAID1/RAID5） | /proc/mdstat 状态确认 |
| D6 | 预检：远程控制台引导测试、部件识别 | lscpu/free/lsblk 三连核对 |
| D7 | 管理/业务网络联调（配合 CE 交换机配置） | 双平面互通测试通过 |
| D8+ | 交接 FusionCompute 安装流程（第 02 章） | 装机底座验收单签字 |
时间线讲法的两个加分点：①每天有可验证的交付物——"做完"的定义清楚；②D4 的"RAID 方案评审"暴露了我做过决策而不只是操作——把一天花在"想清楚"上，是实施和搬箱的分水岭。
1.10 兜底话术与本章红线【必背】
兜底话术集（被问到边界外时逐条使用）：
- 被问芯片微架构（流水线/缓存层次/制程）："微架构级我没深入研究，我的理解到'多核 + 8 通道内存 + NUMA 拓扑'这一层，这已经覆盖我做选型和调参需要的全部信息；更深的属于芯片设计领域，我会如实说没到。"
- 被问 SPEC 跑分数据："具体跑分数字我记不准，不现编。我的实测口径是：96 核承载 15 VM + K8s + 数据库集群稳定运行两年，这个负载画像是它能力的直接证据。"
- 被问 BIOS/固件级调优："BIOS 层我只动过装机必需项（启动顺序、RAID 相关设置），性能向的 BIOS 调优知道方向但项目里没做专项——属于'知道工具在哪、没用过'的层，不冒充。"
本章红线：
- 规格数字（96 核/384G/3.84T/600G×2）一字不能错——这是全章可信度的锚。
- "无 RAID 卡、组软 RAID"必须如实讲——它是真实细节也是加分项，但别升级成"我做了硬 RAID 在线扩容"这类没做过的事。
- 性能对比永远"分维度 + 带场景"，不做"ARM 全面超越 x86"式的判断。
- 芯片授权、路线之争这类敏感题，答到工程层就收，不评论商业和法律。
1.11 本章案例
- 【真实项目】（银行）4 台 2280 的 RAID 决策：背景是该配置不带 RAID 卡而部署基线要求 RAID。任务是在装机前定下软 RAID 落地方式。行动：确认 mdadm 软 RAID 方案——600G SAS ×2 组 RAID1 保系统、SSD 数据盘按 RAID5 基线，并把"该配置无 RAID 卡"写进实施文档的硬件说明，避免后人误以为漏配。结果：FC 安装与两年运行验证方案可靠。教学点：配置约束不是事故，是决策题——实施工程师的价值就是给出约束下的最优解并留档。
- 【真实项目】（银行）内存通道的"配满"讲究：规划 384G 内存时如果只看容量，插 6 条 64G 也能到 384G，但 8 通道 DDR4 插不满就吃不到满带宽，对数据库 VM 不利——最终按 12×32G 插满通道的方案走。教学点：容量和通道数是内存配置的两个独立维度，都要算——这个案例我用来回答"内存配置有什么讲究"。
- 【真实项目】（银行）exec format error 一次排障：离线导入一批容器镜像后，BCS 相关容器起不来，报 exec format error。定位：load 全部成功、run 报格式错——典型"镜像是 x86 的"；追溯发现混入了一批未标注架构的第三方镜像。处理：替换为 aarch64 版镜像 tar 包后恢复。教学点：ARM 环境离线交付必须校验镜像架构，我们后来在交付清单里加了"架构核验"一列——坑变成流程。
1.11.1 硬件层高频场景速答（30 秒版）
| 场景 | 30 秒答案要点 |
|---|---|
| 服务器开机无显示 | 先走带外：iBMC 看 SEL 日志和传感器 → 远程 KVM 看卡在哪个阶段 → 电源灯/告警灯 → 再考虑现场 |
| 硬盘告警灯亮（黄） | iBMC/RAID 状态确认是哪块盘 → 预报还是已故障 → 已故障按 RAID 级别处置（RAID1 直接换盘重建）→ 记录并观察重建 |
| 内存告警 | 定位 DIMM 槽位 → 计划窗口拔插/替换 → 开机内存自检核对容量恢复 |
| 系统盘一块故障（RAID1） | 系统仍在跑（镜像保护）→ 立即换盘重建 → 重建期间监控另一块盘健康 |
| 性能突然下降 | 先看资源（top/vmstat）再往下：NUMA 统计、磁盘 IO util、网络丢包 → 硬件苗头查 iBMC 传感器趋势 |
| 换电源模块 | 双电源冗余下支持热插拔 → 拔故障模块换新 → 确认两路供电指示正常 |
速答的公共原则一句话：硬件问题先带外（iBMC）后现场、先看状态灯和日志再动手、冗余设计内的问题按预案换件——这是 1.9 检查清单与第 07 章 iBMC 能力的合流。
章末自测清单（快问快答）
- ARM 和 x86 的一句话差异框架？ → CISC 高频强单核 vs RISC 低功耗多核；鲲鹏赢在核数/带宽/能效/合规，x86 赢在单核/生态存量。
- 鲲鹏 920 规格五件事？ → ARMv8.2；多核（单颗最高 64 核、2.6GHz）；8 通道 DDR4-2933；PCIe 4.0/100GE；HCCS 互联 + SoC 集成。
- 我们单台服务器 CPU 核数？ → 2×48=96 物理核（鲲鹏 920）。
- 内存配置与讲究？ → 32G×12=384G；插满通道吃满 8 通道带宽；内存不可超分按规划配足。
- 系统盘和数据盘怎么分？ → 600G SAS×2 组 RAID1 做系统盘；3.84T SSD 做 FC 数据存储。
- 这批机器 RAID 是软还是硬？为什么？ → 软 RAID——该配置不带 RAID 卡（部署指南明确），系统 RAID1 + 数据盘 RAID5 基线。
- Disk Cache Policy 为什么 Disabled？ → RAID 卡缓存脏数据掉电丢失，破坏数据库 WAL 持久性语义（Vastbase 安装要求原文）。
- NUMA 一句话 + 我调过的相关参数？ → 本地内存快、跨节点慢；调过 numa_distribute_mode 与线程池绑核（thread_pool_attr allbind）。
- 查 NUMA 拓扑三命令？ → lscpu / numactl --hardware / numastat。
- 没有 ARM 包的软件四步决策？ → 查鲲鹏兼容列表 → 源码编译/官方 arm64 构建 → 评估替代 → 提请方案变更。
- ARM 机器导入 x86 镜像的报错？ → exec format error（load 成功、run 报格式错）。
- 换 x86 方案要动哪些层？ → 服务器/FC ISO 架构版/JDK/DB 包/容器镜像全换 x86 版本——技术上通、合规上不过。
- 国产芯片格局一句话？ → ARM 系（鲲鹏、飞腾）、x86 系（海光）、自研指令集（龙芯）——金融主流是鲲鹏与海光两条路线。
- CPU 超分的水位与风险？ → 常见 1:4~1:8，我们实际约 1:1~1:2 保守；超分挤兑时 VM 内 steal 升高卡顿。
- RAID5 双盘故障会怎样？ → 阵列不可用只能靠备份恢复；单盘故障要立即重建，重建期是裸奔窗口。
- TaiShan 200 家族四型号定位？ → 1280 高密 1U / 2280 均衡 2U（我们的）/ 2480 高性能 / 5280 存储 4U。
- 看软 RAID 状态的命令？ → cat /proc/mdstat + mdadm --detail /dev/mdX。
- 上架前检查七项里最重要的两项？ → 供电（双电源 A/B 分路）与配置单核对（底账一致原则）。
- 单颗 48 核 CPU 内部结构与 NUMA 的关系？ → 多 die 各带内存控制器，OS 看到的 NUMA 节点按 die 细分。
- 2280 为什么叫均衡型？ → 计算密度/内存/存储/网络在 2U 内取平衡，一机多职的通用主力——匹配我们混合负载。
- lscpu 在我们宿主机上最该报的三行？ → Architecture: aarch64 / CPU(s): 96 / NUMA node(s)（按 die 细分不止 2 个）。
- 15 台 VM 的 CPU/内存合计大约多少？ → 约 160 vCPU / 约 264G（数据库两台 32C/64G 是资源倾斜最重的角色）。
- 3.84T 单盘怎么装下 15 台 VM 的磁盘？ → 磁盘分布在 3 台 CNA 的本地存储 + 瘦分配 + 约 40% 水位；单机不是扛全部。
- 硬盘故障的标准处置节奏？ → iBMC/RAID 确认状态 → RAID1 场景直接换盘重建 → 盯重建窗口（裸奔期）→ 记录归档。
- 双电源的意义与检查方法？ → 1+1 冗余分接 A/B 回路，单路断电不停机；上架检查"两路指示灯 + 拔一路演练"。
参考资料（链接采集时间：2026-10）
核实说明：标注"WebFetch 核实"的链接已直接抓取确认内容；标注"搜索核实"的链接经搜索引擎索引确认存在（support.huawei.com 为动态页面无法直接抓取正文）；标注"导航路径"的表示独立 URL 未能逐字核实，按导航步骤使用。本章共 9 个官方入口，满足每章 ≥3 个的规范要求。
- 鲲鹏社区官网（生态/兼容性/计算产业总入口）：https://www.hikunpeng.com —— 产品页/生态入口（WebFetch 核实）
- 鲲鹏 920 处理器规格页（核数/主频/内存通道/PCIe/HCCS 数据来源）：https://www.hikunpeng.com/compute/kunpeng920 —— 规格页（WebFetch 核实）
- TaiShan 服务器产品总览（家族型号 1280/2280/2480/5290/X6000 数据来源）：https://e.huawei.com/cn/products/computing/kunpeng/taishan —— 产品页（搜索核实）
- TaiShan 200 2280 均衡型产品页（2U2 路、32 DIMM、盘位与 RAID 支持数据来源）：https://e.huawei.com/cn/products/computing/kunpeng/taishan/taishan-2280-v2 —— 规格页（WebFetch 核实）
- TaiShan 200（型号 2280）支持页面（用户指南/维护手册入口）：https://support.huawei.com/ts200-2280-pid-250697162 —— 文档入口（搜索核实，动态页）
- 华为技术支持官网（服务器文档/固件/配套表检索入口）：https://support.huawei.com —— 文档中心（导航入口）
- 鲲鹏生态兼容性查询：官网导航——鲲鹏社区（hikunpeng.com）→ 生态 → 兼容性查询（首页确认栏目存在，具体查询页未逐字核实，按导航使用）
- 毕昇 JDK 鲲鹏镜像（aarch64 包目录，8u262–8u502，含 8u362）：https://mirrors.huaweicloud.com/kunpeng/archive/compiler/bisheng_jdk/ —— 下载目录（WebFetch 核实）
- openEuler 社区（鲲鹏支持的开源 OS，详见第 06 章）：https://www.openeuler.org（跳转 openatom 站点）—— 开源 OS（WebFetch 核实跳转）
本章规格数据以华为官网产品页与我方项目《版本配套表/硬件配置表》为准；TaiShan 200 2280 具体出货配置以订单配置器输出为准——本章解读基于我项目 4 台的真实配置。
本章复习优先级（时间不够时）
- 第一优先：1.4 规格逐项解读 + 1.4.1 资源账——数字和"为什么"必须脱口而出，这是全章的信任锚。
- 第二优先：1.8 RAID（含 Disk Cache Policy 教学案例）+ 1.1 ARM vs x86 框架——两个最高频考点。
- 第三优先：1.9 操作叙事（STAR 与时间线两版）+ 1.6 aarch64 四步决策链。
- 第四优先：1.2 鲲鹏 920 五件事、1.3 家族定位、1.5 NUMA——概念层，答标准回答即可。
- 兜底：1.10 话术集——面试前夜读一遍，边界题不慌。
（全篇完 · 01 章）
章节衔接：硬件底座就绪后，下一章在这 4 台机器上安装 FusionCompute 8.3.0（CNA×3 + VRM×1）；带外管理的操作细节（挂 ISO、远程控制台）在第 07 章展开，本章只保留装机衔接所需的最小集。 数字自检：96 核、384G、3.84T、600G×2、4 台、15 VM、约 160 vCPU / 264G——报数前扫一眼这行。
（本章完）
复查提示：本章与宝典 08 章 8.9（RAID）/8.10（TaiShan）口径一致；面试先用宝典速答版，再用本章细节加厚。