1. 课程导入与协同架构总览

在数据中心里，服务器、存储和网络往往由不同团队按各自标准选型与运维：服务器关注CPU、内存与PCIe带宽，存储关注IOPS、时延与容量利用率，网络关注端口密度、收敛比与转发时延。三者单独看都"达标"，但业务上线后仍可能出现数据库响应抖动、虚拟机迁移卡顿、备份窗口超时等问题。原因通常不在某个部件性能不足，而在于三者之间的能力匹配与路径协同没有统一设计。本课程讨论的"协同架构设计"，就是把这三种资源当作一条端到端的数据通路来规划，而不是三份独立清单。

Lenovo服务器、存储与网络协同设计的核心目标可以归纳为三条主线：性能对齐——让服务器侧PCIe/内存带宽、存储侧控制器与介质能力、网络侧端口速率与收敛比在同一量级上匹配，避免单点瓶颈；可靠性贯通——从服务器网卡绑定、交换机堆叠/MLAG、存储双控到多路径，形成无单点故障的冗余链路；可管理性与可扩展性——通过统一命名、统一监控与标准化布线，使扩容时只需按既定规则增加节点，而不必重构架构。价值定位上，协同设计带来的不是某一项跑分提升，而是可预测的时延、可复制的部署模板和更低的总体拥有成本。

整体框架可以按"四层一纵"理解。物理层包括服务器网卡与PCIe插槽、存储控制器端口、交换机端口与光模块/线缆；链路层包括链路聚合、VLAN、多路径与堆叠/MLAG；协议与服务层包括iSCSI/NVMe over Fabrics、NFS/SMB、RDMA（RoCEv2）等；管理与编排层包括带外管理、监控采集与自动化部署。纵向贯穿的是命名规范、地址规划、安全策略与变更流程。下面这张图给出协同架构的整体关系：服务器通过冗余链路接入网络，网络再分别连接存储前端与业务区，管理面独立组网。

理解框架之后，需要明确"协同"在工程上到底改什么。举一个常见的教学示例：某业务要求单台服务器到存储的持续读带宽不低于 8GB/s，时延 P99 小于 1ms。若服务器配置双口 25GbE 做 Bond，理论聚合 50Gb/s（约 6.25GB/s），单口即成为瓶颈；此时应改为双口 100GbE 或采用 NVMe over RoCEv2 并启用多路径。再往下看，若交换机上行收敛比为 4:1，则多台服务器并发时上行链路会先拥塞，需要在 Leaf 侧预留带宽或调整收敛比。存储侧若控制器前端只有 4×25GbE，则即使网络与服务器都升级到 100GbE，存储前端仍限制在约 12.5GB/s 以内。这个例子说明：协同设计的第一步是画出端到端路径并逐段标注能力上限，找出最小瓶颈，而不是先买最快的部件。

在实操层面，建议按以下顺序推进一次协同设计评审。第一，梳理业务路径清单，明确每条路径的源（服务器/虚拟机）、目的（存储卷/共享）、协议与SLA；第二，为每条路径标注各段能力上限，包括网卡速率、交换机端口与上行、存储控制器前端与后端；第三，检查冗余是否端到端成立，例如服务器双网卡是否分别接入两台Leaf、存储双控是否分别接入不同Leaf、多路径策略是否启用；第四，核对命名与地址规划，确保新增节点可沿用现有VLAN、IP段与多路径配置；第五，形成一份可执行的参数对照表，作为后续章节设计与验收的依据。