2. Nexus平台与架构基础
在数据中心迁移与升级工程中，理解 Nexus 平台的底层架构是制定迁移方案、评估风险与选择割接窗口的前提。Nexus 并非“一台更快的交换机”，而是由 NX-OS 操作系统、专用硬件形态、分离的控制平面与数据平面，以及虚拟化/容器化能力共同构成的平台体系。迁移工程师需要把“设备型号”“软件版本”“转发行为”“虚拟化边界”四件事放在同一张图上思考，否则很容易在 VPC、VDC、vPC 或 NX-OS 升级时出现预期外的中断。
NX-OS：为数据中心而生的模块化网络操作系统
NX-OS 的架构核心是“微内核 + 模块化进程 + 集中式配置管理”。与 IOS 不同，NX-OS 使用 Linux 内核作为底层，各协议（如 BGP、OSPF、vPC、FabricPath）以独立进程运行，单个进程异常通常不会拖垮整机控制平面。配置层面，NX-OS 采用“候选配置—提交”模型：在配置模式下修改后，只有执行 copy running-config startup-config 或 commit（部分特性）才真正生效并持久化。迁移前必须确认 running-config 与 startup-config 一致，否则设备重启后可能回到旧配置。
NX-OS 的版本命名也直接影响迁移路径。例如 7.0(3)I7(9) 中，7.0 是主版本，3 是次版本，I7 表示平台/特性分支，9 是维护版本。升级时通常要求先升级到目标分支的“推荐版本”，再跨大版本。以下是一个典型的版本检查与升级前确认示例：
# 查看当前版本与运行时间
show version
# 查看启动镜像与备用镜像
show boot
# 查看 running 与 startup 是否一致
show running-config | diff startup-config
# 查看升级前关键进程状态
show processes cpu | include bgp|ospf|vpc
如果 show boot 显示当前启动镜像与 running 版本不一致，说明设备可能处于“已升级但未重启”或“回退未完成”状态，此时不应直接进入割接窗口，而应先统一启动镜像与运行版本。
Nexus 交换机硬件形态：从固定式到模块化
Nexus 硬件大致分为三类：固定式（Fixed）、模块化（Modular）和 Fabric 扩展型。固定式如 Nexus 9300 系列，端口密度固定，适合 Leaf 角色；模块化如 Nexus 9500 系列，通过线卡和 Supervisor 扩展，适合 Spine 或核心；Nexus 7000 系列则常见于传统核心，支持较多线卡与 Fabric 模块。迁移时，硬件形态决定了“能否在线更换 Supervisor”“是否支持 ISSU”“Fabric 模块带宽是否足够承载迁移流量”。
以 Nexus 9500 为例，Supervisor 负责控制平面，线卡负责数据平面，Fabric 模块负责线卡间互联。若迁移过程中需要临时提高东西向流量，必须确认 Fabric 模块的背板带宽与线卡收敛比，否则可能出现丢包。固定式交换机则没有独立 Supervisor，控制平面与数据平面在同一主板上，升级通常需要重启，割接窗口更短。
控制平面与数据平面：迁移中真正决定“断不断”的分界
控制平面负责路由协议、ARP、MAC 学习、vPC 协商等；数据平面负责实际转发。迁移工程中最危险的情况是“控制平面正常但数据平面黑洞”，例如路由表已收敛，但 ACL、TCAM 或 VPC 一致性检查导致部分流量被丢弃。因此，迁移验证不能只看 show ip route，还要看数据平面计数与 TCAM 使用率。
# 控制平面检查
show ip route summary
show vpc brief
# 数据平面检查
show interface counters errors
show hardware access-list tcam usage
show system internal forwarding statistics
如果 show vpc brief 显示 vPC 状态为 peer-link not ready，即使路由正常，双活流量也可能单边转发。此时应优先检查 peer-link 与 peer-keepalive 链路，而不是继续推进迁移。
虚拟化与容器化：迁移边界往往由它们决定
Nexus 的虚拟化能力主要包括 VDC（Virtual Device Context）和 vPC。VDC 把一台物理交换机划分为多个逻辑设备，每个 VDC 拥有独立的管理平面、配置和接口。迁移时，如果目标设备启用了 VDC，必须确认接口归属哪个 VDC，否则会出现“接口在物理上存在，但在目标 VDC 中不可见”的问题。vPC 则让两台 Nexus 对下游呈现为一个逻辑端口通道，迁移中若只升级其中一台，必须确保 peer-link 与 peer-keepalive 仍然健康，否则 vPC 会进入不一致状态。
容器化方面，NX-OS 支持 Guest Shell 与 Docker 容器，可在交换机上运行 Python 脚本、自动化工具或监控代理。迁移工程中常用 Guest Shell 执行批量配置备份与合规检查。例如：
# 进入 Guest Shell
guestshell
# 在容器内执行 Python 脚本备份配置
python /bootflash/backup_config.py --host 10.0.0.1 --user admin
# 退出并查看容器状态
exit
show guestshell detail
需要注意的是，Guest Shell 与 NX-OS 共享部分资源，若脚本占用过多 CPU 或内存，可能影响控制平面进程。迁移前应检查 show guestshell detail 中的资源配额，并在割接窗口内避免运行大规模自动化任务。
迁移视角下的架构检查清单
把上述四层落到迁移工程中，可以形成一份可执行的检查清单。以下字段直接对应迁移前必须确认的架构事实，而不是泛泛的管理项：
| 检查项 | 命令/对象 | 合格判据 | 不合格时的动作 |
|---|---|---|---|
| NX-OS 版本一致性 | show version / show boot |
running 与 startup 镜像一致，且为目标推荐版本 | 先统一启动镜像，再进入割接 |
| 控制平面健康 | show vpc brief / show ip route summary |
vPC 状态正常，路由收敛无震荡 | 检查 peer-link 与 keepalive |
| 数据平面无黑洞 | show interface counters errors / TCAM usage |
错误计数不增长，TCAM 未超阈值 | 排查 ACL 与 TCAM 表项 |
| 硬件形态支持 | Supervisor / 线卡 / Fabric 模块 | 支持 ISSU 或在线更换，背板带宽足够 | 调整割接窗口或分批迁移 |
| 虚拟化边界清晰 | VDC 接口归属 / vPC 域 | 接口与 VDC 对应关系明确，vPC 域无跨边界 | 重新规划 VDC 与 vPC 归属 |
show version、show boot、show vpc brief、show interface counters errors、show hardware access-list tcam usage 五条命令的输出保存为基线文件。割接后逐项对比，任何一项偏离基线都应暂停后续步骤，先定位原因。
理解 NX-OS 的模块化进程、Nexus 的硬件分层、控制平面与数据平面的分工，以及 VDC/vPC/容器带来的虚拟化边界，才能在后续的迁移规划中准确判断“哪些操作可以在线做、哪些必须停机、哪些会影响双活流量”。这些架构事实是后续所有迁移步骤的约束条件，而不是背景知识。