# F.7 商用互连网络的实际问题 除了前面介绍的技术问题，各类互连网络还有一些重要的实际问题需要考虑。下面列举其中几项。 ## 连接能力 通信设备的类型、数量及通信要求，会影响互连网络及其协议的复杂度。协议必须面向最大的网络规模，并处理系统范围内可能出现的异常事件。需要考虑的问题包括：网络接口的硬件与软件应有多轻量？应接到存储器网络还是 I/O 网络？是否应支持 缓存 一致性？如果每次网络事务都需要操作系统介入，发送与接收开销就会很大。如果网络接口连接到 I/O 网络，例如 PCI Express 或 HyperTransport，其注入与接收带宽便受到 I/O 网络带宽限制。Cray XT3 SeaStar、Intel Thunder Tiger 4 QsNet II 以及许多其他超级计算机、集群网络都是如此。为支持一致性，发送者可能每次发送前都要刷出 缓存，接收者每次接收前也可能需要刷出 缓存，以避免陈旧数据问题。这些操作进一步增加发送与接收开销，常使网络接口成为网络瓶颈。 计算机系统通常有多套互连，功能及成本—性能目标各不相同。例如，处理器—存储器互连通常比 I/O 互连带宽更高、延迟更低，也更可能支持 缓存 一致性，但较少遵循或成为标准。个人计算机通常有处理器—存储器互连，以及 PCI-X 2.0、PCIe 或HyperTransport 等 I/O 互连，后者连接快慢不同的设备，例如 USB 2.0、千兆以太网 LAN、FireWire 800。Blue Gene/L 超级计算机采用五套互连网络；其中只有一套是承担大部分处理器间应用流量的三维 torus。其余包括用于广播和多播的树形集合通信网络，用于合并结果及 散布（scatter）、聚集（gather） 的树形屏障网络，用于诊断、调试和初始化的控制网络，以及负责节点与磁盘间 I/O 的千兆以太网。 得克萨斯大学奥斯汀分校的 TRIPS EDGE 处理器具有八套专用片上网络，互连构成两个处理器核及片上 L2 缓存 的 106 个异构 tile。有的双向通道宽达 128 位，有的每方向宽达 168 位。它还有芯片间交换网络，在多处理器配置中互连多个芯片。片上网络中有两套交换网络：一套传送操作数，另一套用于片上存储器通信。其他网络本质上是用于状态和控制的扇出树或重新汇合的专用链路网络。互连占据相当大的芯片资源：七个金属层中有五个用于全局网络布线。 ## 标准化：跨公司的互操作性 标准在计算机设计的许多方面都很有用，互连网络也不例外。成功的标准具有低成本和稳定性等优点。客户可以选择多家供应商，竞争使价格接近成本，也使互连方案的生存不再依赖某一家公司的稳定性。为标准互连设计的部件还可能拥有更大市场，较高销量可降低供应商成本，进一步让客户受益。最后，标准允许多家公司构建采用统一接口的产品，客户不必等某一家公司开发出与所有目标产品相连的接口。 标准的一个缺点是，委员会和各利益群体需要很长时间才能就定义达成一致；技术迅速变化时，这尤其成问题。另一个问题是什么时候标准化：设计者一方面希望在任何东西造出来之前已有标准，另一方面，先造出一些东西再标准化更好，可以避免把无用功能写进规范，或漏掉重要功能。如果过早标准化，往往完全由委员会设计，就像让法国所有厨师合做一道菜，很少能端出杰作。标准固定了接口，也可能抑制该层面的创新，至少在下一版标准出现前如此，而更新间隔可能数年甚至更久。越来越常见的做法，是公司组成联盟，共同定义并认可某种技术，使之成为“事实上的”行业标准；InfiniBand 就是这样。 LAN 和 WAN 使用标准，并能有效互操作。WAN 涉及多种公司，必须连接众多品牌的计算机，很难想象专有 WAN 会成功。以太网无处不在，说明标准在 LAN 和 WAN 中都受欢迎；多数客户不太可能把自己 LAN 的生存绑定在某一家公司的稳定性上。有些 SAN 已标准化，例如 Fibre Channel，但多数仍是专有网络。OCN 大多也采用专有设计，少数在片上系统（SoC）中获得广泛商用，例如 IBM CoreConnect 和 ARM AMBA。 ## 拥塞管理 当过多分组试图使用同一链路或链路集合，所需带宽超过可用带宽时，就会发生拥塞。拥塞本身并不降低性能，拥塞链路只是运行在最大容量。性能下降发生在 HOL 阻塞存在时：发往非拥塞目的地的分组，被发往拥塞目的地的分组挡住，部分链路带宽浪费，网络吞吐量下降，原书指向 F.4 节末例题加以说明。**拥塞控制**是指当所有节点的总流量超过网络承受能力时，用于减少流量的机制。 电路交换网络的一个优点是，一旦建立电路，就保证有足够带宽交付沿该电路发送的全部信息。电路建立时预留互连带宽；网络满了，就不能再建立电路。其他交换技术通常不预留带宽，因此互连可能被过多分组堵塞。就像高峰时段通勤者遭遇堵车，分组拥堵会增加延迟，极端情况下甚至使每秒交付的分组更少。分组交换网络必须实现某种拥塞管理。机制可分两类：一类控制拥塞，另一类消除拥塞造成的性能下降。 互连网络有三种基本拥塞控制方案，各有缺点：丢包、流量控制，以及抑制分组（choke packet）。最简单的是 F.2 节简述过的**丢包**：分组到达交换机时，如果缓冲区没有空间，就将其丢弃。这依靠处理传输错误的高层软件重发丢失分组。已发送或重发的分组可能随后又被丢弃，造成大量带宽浪费，因此通常只用于互联网这样的有损网络。 第二种方案依靠前述**流量控制**。缓冲区满时，链路级流量控制反馈，阻止继续发送分组。这种反压反馈迅速向后传播，直到造成拥塞的源节点，迫使它们降低注入速率。主要缺点是，源节点得知拥塞时已经太晚，网络早已拥塞，而且该方案没有采取额外措施缓解拥塞。反压流量控制常用于无损网络，例如超级计算机及企业系统的 SAN。 更复杂的流控方式，是在发送与接收端节点之间直接实施，统称**端到端流量控制**。**窗口机制**是一种基于 credit的端到端流控，窗口必须足够大，才能让分组高效地在网络中流水传输。窗口限制未确认分组数，从而在拥塞发生时，限制各源节点对拥塞的贡献。TCP 使用滑动窗口。注意，端到端流控只描述互连网络中两个节点之间的交互，并不覆盖全部端节点之间的整个网络。因此，它有助于拥塞控制，但不是全局解决方案。 第三种方案使用**抑制分组**，出发点是只有网络存在拥塞时才限制流量注入。各交换机监测繁忙程度，超过阈值就进入警告状态。处于该状态的交换机，对收到的每个分组，向源节点回送包含原目的地的抑制分组，要求源节点按固定比例减少发往该目的地的流量。由于源节点可能已沿相同路径发送其他分组，它会等在途分组返回后，再响应抑制分组。该方案降低分组注入速率，直到流量减小，就像高速公路入口的调节信号灯控制车辆进入速率一样。反馈延迟短时很有效；若拥塞通知耗时较长，通常是因为飞行时间长，这种控制可能不稳定，反应过慢或使注入速率振荡，都会降低带宽利用率。 另一条思路不是控制拥塞，而是消除其负面后果，即如前所述，消除每台交换机的 HOL 阻塞。可以使用虚拟输出队列，但每个输入端口所需队列数须等于网络设备数，成本极高且完全不具备扩展性。幸运的是，只动态分配少量专设队列，单独存放经过某些网络热点区域的拥塞分组，就能取得良好效果，类似 缓存 只保存更频繁访问的内存位置。这称为**区域显式拥塞通知**（regional explicit congestion notification，RECN）。 ## 容错 随着晶体管集成密度及系统设备数增加，系统发生故障的概率也提高。因此，可靠性与可用性已成为主要关注点，未来互连设备越来越多时还会更加重要。一个实际问题是：互连网络是否要求所有设备都正常，整个网络才能正常工作？软件故障通常远多于硬件故障，因此还必须考虑：单个设备的软件崩溃，会不会阻止其他设备通信？有些硬件设计者试图构建无故障网络，但实际问题只能是故障率多高，而不是能否彻底避免。通信子系统必须具备故障发生时的应对机制，因为故障终将发生。 互连网络的故障主要有**瞬态**和**永久**两类。瞬态故障通常由电磁干扰引起，可以用 F.2 节技术检测和纠正，往往只需链路级或端到端重传。永久故障则是某个部件不再按规格工作，常由过热、偏置过大、过度使用、老化等造成，不能仅靠高层软件协议重传恢复。网络中必须存在其他物理路径，并由路由算法提供以绕过故障；否则，网络就会受损，无法交付那些唯一可用路径经过故障资源的分组。 处理永久故障的技术主要有三类：资源备用、容错路由、网络重配置。**资源备用**将故障资源关闭或旁路，并接入备用资源替代。例如 ServerNet 有两套相同交换结构，任一时刻只使用一套；一套故障就切换到另一套。也可不接入备用资源，而在故障后降级运行。例如 IBM Blue Gene/L 能旁路故障网络资源，同时保留基本拓扑和路由算法。主要缺点是，为保留三维 torus 等基本拓扑，一处故障之后可能必须关闭大量正常资源，例如 midplane 节点板。 **容错路由**利用拓扑已有的多条路径，在故障下路由消息，无须备用资源。设计时为每种支持的故障组合确定备选路径，并纳入路由算法；检测到故障后使用适当路径。困难在于故障模式可能任意出现，必须保证采用备选路径后，算法仍然无死锁。直接网络的规则性可能被故障破坏，尤其难处理。Cray T3E 是在三维 torus 直接网络上成功采用该技术的例子。间接网络中也有许多实例，如 ASCI White 和 ASC Purple 的双向多级网络。它们提供端节点间多条最短路径，本身没有路由死锁问题，见 F.5 节；发生故障时，由源节点选择替代路径。 **网络重配置**更通用，可处理故障或其他原因造成的主动和被动拓扑变化。重配置时，先发现拓扑中无故障的部分，再计算新的路由表，并分发到相应交换机或端节点。根据路由方式，它需要可编程交换机、可编程网络接口，或两者；也可使用 up*/down* 之类通用算法，配置到故障后可能出现的所有拓扑上。这样，设计者无须事先为每种故障组合提供路径。可编程网络部件提供高度灵活性，代价是成本和延迟更高。用于集群和 SAN 的多数标准或专有互连，包括 Myrinet、Quadrics、InfiniBand、Advanced Switching 和 Fibre Channel，都带有按当前拓扑配置或重新配置路由的软件。 另一个实际问题与节点容错有关：网络即使能承受故障，在新增或移除节点时，能否继续运行？这通常称为**热插拔**。若不能，每次增删节点都将使网络停用，对 WAN、LAN 不现实，对多数 SAN 也无法接受。在线扩容需要热插拔，因此多数网络支持它。通常通过**动态网络重配置**实现，即不停止用户流量便重配置网络。困难在于，交换机或端节点路由表动态、异步更新期间，网络中可能同时存在多个甚至相互冲突的路由算法，必须仍保证无死锁。多数 WAN 通过必要时丢包解决，但无损网络中的动态重配置复杂得多。最近已有若干理论和实用技术，能高效应对这一问题。 ### 例题：容错能力如何影响用户可用性 图 F.27 给出了一个局域网中 58 台桌面计算机，在略超过一年内的故障数量。假定一种 LAN 要求所有机器正常，网络才能发送数据：某节点崩溃后无法接收消息，待交付数据便会堵塞互连。另一种是传统 LAN，它能在节点故障时继续运行，只需丢弃发往拒绝接收消息节点的数据。假定你必须同时使用自己的工作站和 LAN 才能工作，相比传统 LAN，不容错 LAN 使你无法工作的概率高多少？假定每次崩溃的停机时间少于 30 分钟，使用图中的一小时时段数据计算。 | 每时段故障机器数 | 具有该故障机器数的一小时时段数 | 按一小时时段统计的故障总数 | 具有该故障机器数的一天时段数 | 按一天时段统计的故障总数 | |---:|---:|---:|---:|---:| | 0 | 8605 | 0 | 184 | 0 | | 1 | 264 | 264 | 105 | 105 | | 2 | 50 | 100 | 35 | 70 | | 3 | 25 | 75 | 11 | 33 | | 4 | 10 | 40 | 6 | 24 | | 5 | 7 | 35 | 9 | 45 | | 6 | 3 | 18 | 6 | 36 | | 7 | 1 | 7 | 4 | 28 | | 8 | 1 | 8 | 4 | 32 | | 9 | 2 | 18 | 2 | 18 | | 10 | 2 | 20 | | | | 11 | 1 | 11 | 2 | 22 | | 12 | | | 1 | 12 | | 17 | 1 | 17 | | | | 20 | 1 | 20 | | | | 21 | 1 | 21 | 1 | 21 | | 31 | | | 1 | 31 | | 38 | | | 1 | 38 | | 58 | | | 1 | 58 | | **合计** | **8974** | **654** | **373** | **573** | {#fig-F.27 .wide .expand num="F.27" caption="58 台运行 Ultrix 的 DECstation 5000 在 373 天中的重启测量。重启按一小时和一天两种时段归集。第一列按每时段故障机器数分类；随后两列为一小时时段，最后两列为一天时段。第二、四列给出各类时段数；第三、五列等于故障机器数乘以时段数。例如，有 50 个一小时时段各有 2 台机器故障，合计 100 次；有 35 天各有 2 台机器故障，合计 70 次。每时段故障数自然会随时段长度而变，例如发生 31 次故障的一天，可能包含一个发生 11 次故障的小时及一个发生 20 次故障的小时。末行汇总各列。两种统计的故障总数不相等，是因为同一机器在同一时段多次重启不重复计数。数据由加利福尼亚大学伯克利分校的 Randy Wang 收集。"} **解答** 按图 F.27，不容错网络中无法工作的小时比例为： $$ \begin{aligned} \frac{\text{有故障时段数}}{\text{总时段数}} &=\frac{\text{总时段数}-\text{无故障时段数}}{\text{总时段数}}\\ &=\frac{8974-8605}{8974}=\frac{369}{8974}\approx4.1\% \end{aligned} $$ 传统网络中，只有自己的工作站崩溃时才不能工作。若故障均匀分布到各工作站，则比例为： $$ \frac{\text{故障总数}/\text{机器数}}{\text{总时段数}} =\frac{654/58}{8974}=\frac{11.28}{8974}\approx0.13\% $$ 因此，按图 F.27 的故障统计，使用不容错 LAN 时，无法工作的概率超过传统 LAN 的 30 倍。换句话说，负责维护 LAN 的人，会接到多出约 30 倍的愤怒用户来电！