桌面云服务器部署，大部分麻烦不是虚拟化平台本身，而是网络层面。计算、存储资源都集中在服务器，数百台虚拟桌面的流量全部经过网线，配置不合理，用户使用就会卡顿、掉线、开机缓慢。端口聚合是必须处理的环节，但聚合模式、配置方法有不少细节，踩过坑才清楚。
先说部署阶段的网络规划。桌面云流量分为四类，管理流量、存储流量、虚拟机业务流量、客户端接入流量，四类流量混在一起传输风险很高。稳妥方案至少单独隔离存储网络，虚拟存储副本同步走独立链路。存储网络一旦抖动，后果比业务网中断严重，可能直接造成虚拟机崩溃、数据不一致。服务器一般配置万兆光口专门承载存储流量，千兆电口负责管理和业务。服务器网卡做端口聚合，尽量让聚合使用的两块网卡分属不同网卡板卡，防止单块板卡故障，直接导致整个聚合组失效。
存储网交换机配置有一处容易忽略。如果使用交换机堆叠，服务器端口聚合选择单交换机链路聚合，堆叠后两台交换机逻辑上合并为一台，跨交换机聚合在该场景并不合适。没有堆叠，使用两台独立交换机实现跨设备聚合，配置方式不一样，需要参考交换机型号和支持能力。
端口聚合模式选择，是最容易出问题的地方。交换机侧分为手工模式和LACP模式，服务器侧bond模式必须和交换机匹配。深信服桌面云这里有典型坑点：虚拟化平台UI配置端口bond，对端交换机必须使用静态链路聚合。交换机配置LACP模式的话，trunk口状态会变成down，子接口虽然up，聚合端口整体无法使用。初次遇到这个现象会很费解，服务器网卡状态正常，但网络不通。配置前确认桌面云平台支持的聚合模式，不要直接套用通用方案。
手工静态聚合，所有链路同时转发流量，一条链路断开，剩余链路分摊流量。不需要交换机支持LACP协议，配置简单，但存在隐患：链路接线错误或者网线接触不良但没有完全断开，交换机无法识别，故障链路依旧转发数据包，引发丢包。LACP模式采用M+N结构，活动链路故障自动切换备用链路，交换机可以识别错误链路并剔除转发。LACP可靠性更强，但桌面云平台不支持的情况下，只能选用静态聚合。
服务器端bond配置，必须和交换机侧对齐。Linux常用bond模式，bond4对应802.3ad也就是LACP，交换机同步开启LACP，两端速率双工保持一致。bond1为主备模式，仅一条链路工作，另一条作为备用，这种场景交换机不能配置聚合，否则会丢包。bond0轮询模式，数据包依次从不同网卡发出，对端交换机配置静态聚合。
配置细节，LACP模式下xmit_hash_policy参数决定流量分发到各物理链路。默认layer2哈希只参考MAC地址，如果虚拟机MAC、服务器网卡MAC固定，所有流量会集中在单条链路，端口聚合失去作用。修改为layer3+4，依靠源目IP和端口号计算哈希，流量分布更均匀。宿主机运行大量虚拟机的桌面云场景，这个参数非常关键。
验证聚合是否生效，不能只看服务器bond状态正常就判定成功。从其他机器向服务器传输大文件，同时查看交换机各个成员口流量统计，只有单条网卡跑流量，说明哈希策略失效或者配置异常。也可以手动断开一条物理链路，验证网络是否正常连通，这是最简单的冗余测试。静态聚合场景，断开单条链路业务无感知，流量自动转移到剩余链路。
桌面云服务器部署端口聚合，核心要点就是服务器端和交换机侧模式匹配，并且以桌面云平台支持能力为准。不是所有场景都可以启用LACP，静态聚合配置简单但存在局限。配置前花十分钟确认平台文档和交换机型号，比配置完成之后长时间排查网络故障更高效。