路由器架构简史

2021-03-25   出处: https://blog.apnic.net/  作/译者:Tony Li /Elaine66

        

        在过去的50年里,从少数几台计算机的微型互连发展到拥有数十亿节点的全球网络,我们在发展互联网方面取得了很大的进步。在这个过程中,我们学到了很多关于如何建立网络和连接网络的路由器的知识。而我们走的弯路对于后来的学习者来讲,无疑成为了宝贵的经验和启发。

        起初,路由器只是将网络接口卡(NIC)连接到总线上的普通的计算机。


        这在一定程度上是可行的。在这种架构中,数据包进入网卡,然后由CPU从网卡传输到内存。CPU做出转发决定,再将数据包推到出站网卡。CPU和内存是集中式资源,本身就受它们所能支持的资源的限制。而此外,总线又是另一个额外限制: 总线带宽必须能够同时支持所有网卡的带宽。

        在你想扩大规模的时候,问题很快就会显现出来。你可以购买更快的CPU,但总线规模如何扩大呢? 如果你把总线的速度提高一倍,那么你也必须把每个网卡和CPU卡上的总线接口的速度提高一倍。这使得所有的卡都更贵。

        启发1:路由器的成本应该随容量线性增长。

        尽管有了这个启发,但进行扩展的权宜之计仅仅是添加另外的总线和处理器:


        附加算术逻辑单元(ALU)是一种数字信号处理(DSP)芯片,因其优异的性价比而被选用。附加的总线增加了带宽,但架构仍然无法扩展。换句话说,你不能永远通过添加更多的ALU和更多的总线来获得更高的性能。

        由于ALU仍然是一个重要的限制,下一步就是在架构中添加一个现场可编程门阵列(FPGA),以减轻最长前缀匹配(LPM)查找的工作量。


        但令人惊讶的是,这种帮助非常有限。ALU仍然是饱和的。LPM在工作负载中占了的很大一部分,但哪怕如果去掉这部分问题,集中式体系结构仍然无法扩展。

        启发2: LPM可以在定制硅片中实现,并且不会成为性能的障碍。

        在这个启发之下,下一步发展是朝着另一个方向进行:用通用处理器替换ALU和FPGA,并尝试通过增加更多的CPU和总线来扩展。实现一个小的增量增益需要花费大量的努力,并且仍然受到集中式总线带宽的限制。

        在互联网发展的这个阶段上,更大的力量开始发挥作用 随着网络知识的普及,互联网的巨大潜力变得越来越明显。电信公司收购了NSFnet的区域网络,并开始部署商业主干网。专用集成电路(asic)成为可靠的技术,允许更多的功能直接在硅片中实现。对路由器的需求猛增以及对大规模可扩展性改进的需求最终压倒了工程保守主义。为了满足这一需求,许多初创公司涌现出来,并且提供了各种各样的潜在解决方案。

        另一种方向是设置crossbar(交叉/纵横式开关矩阵):


        在这种架构中,每个网卡都分别是一个输入和一个输出。网卡上的处理器做出转发决定,选择输出网卡,并为crossbar发送调度请求。调度器接收来自从网卡的所有请求,找出一个最佳的解决方案,并用其对crossbar进行编程,提示输入进行传输。

        这样做的问题是,每个输出在同一时间只能读一个输入,而互联网流量是突发性的。如果两个数据包需要到达同一个输出,那么其中一个就必须等待。如果必须等待的数据包导致同一输入上的其他数据包发生等待,那么系统将遭受线端阻塞(HOLB),从而导致路由器性能非常差。

        启发3::路由器的内部结构需要是非阻塞的,即使在压力条件下也是如此。

        向定制硅片的转变也鼓励了设计师向基于单元的内部结构转变,因为实现小型固定大小单元的交换比处理可变长度(有时是大数据包)要容易得多。但是切换单元也意味着调度器必须以更高的每单元速率运行,这使得调度更加困难。

        另一种创新方法是将NICs排列在一个环面上:


        在这里,每个网卡都与四个相邻网卡相连,输入网卡必须计算出穿过结构的路径才能到达输出链路卡。这就有一个问题——带宽并不是一致的。由于南北方向的带宽大于东西方向的带宽,如果输入的传输模式需要在东西向进行,就会出现拥堵。

        启发4:路由器的内部结构必须具有统一的带宽分布,因为我们无法预测流量的分布。

        另一种完全不同的方法是创建一个NIC到NIC链路的完整网格,并将单元分布到所有NIC:


        尽管吸取了以前的教训,新的问题还是存在。在这个架构中,一切看起来都能正常运行。但是如果有人需要更换一张卡进行维修,问题就暴露了出来。由于每个NIC都持有系统中所有数据包的单元,所以当一张卡被取出时,任何数据包都无法重建,从而导致无法避免的中断。

        启发5:路由器不能有单点故障。

        我们将这个架构从头到尾梳理了一下:


        在这里,所有的数据包都流入中央内存,然后流向输出网卡。这种方法运行得不错,但扩展内存仍是一个挑战。你可以添加多个内存控制器和内存组,但在某种程度上,总带宽实在是太大了,在物理设计上十分困难。这种限制使得我们不得不从其他方向思考。

        从电话网中,我们找到了灵感。Charles Clos很久以前就意识到,可以通过构建更小交换机网络来构建可扩展的交换机。事实证明,我们所需要的以下属性在Clos网络中都能实现:


        Clos网络:


  • 与容量匹配良好。
  • 没有单点故障。
  • 支持足够的冗余,使我们能够抵御故障。
  • 通过在整个结构中分配负载来处理突发的拥塞。


        我们总是把输入和输出放在一起,所以通常在图中会以重叠的虚线来表示。这就产生了折叠式Clos网络,这就是我们今天在集群路由器中使用的的网络,一些信元有一层交换机和许多网卡,而更多的信元带有额外的交换机层。


        不幸的是,即使是这种架构也不是没有问题的。交换机之间使用的信元格式是芯片供应商专有的,从而导致了芯片组锁定。与芯片供应商联系起来并不比与单一路由器供应商捆绑好,因为它也有类似的单一来源定价和可用性问题。硬件升级很有挑战性,因为新的信元交换机必须能够为实现传统和升级的链路和信元格式的交互提供同步支持。

        每个信元必须有一个地址来指示它应该流向的输出网卡。这种寻址必然是有限的,这导致了可扩展性的上限。到目前为止,集群的控制和管理仍然是少数企业专营的,这给软件堆栈引入了单一供应商的问题

        幸运的是,我们可以通过改变我们的架构理念来解决这些问题。在过去的50年里,我们一直在努力扩大路由器的规模。我们从构建大型云的经验中学到的是,扩展理念通常更成功。

        在横向扩展架构中,与其试图构建一个庞大的、速度极快的单个服务器,为什么不考虑分而治之呢?一个由许多小型服务器的组成架构可以完成同样的工作,同时也更有弹性、灵活性和经济性。

        应用到路由器时,思路也是相似的。我们是否可以将一些较小的路由器安排在Clos拓扑结构中,通过类似的架构优势,从而避免基于单元的问题? 事实证明,这并不是太难:


        通过将单元交换机替换为分组交换机(如路由器),并保留Clos拓扑,就可以比较容易地保证其可扩展性。

        我们可以在两个维度上进行扩展: 要么通过增加更多的入口路由器和分组交换机来与现有的层并行,要么通过增加额外的交换器层。由于单个路由器现在是相对通用的,因此避免了厂商锁。这些链路都是标准的以太网,所以交互操作性没有问题。

        升级是一目了然的:如果一个交换机上需要更多的链路,那就换一个更大的交换机。如果一个给定的链路需要升级,例如链路的两端都有扩展能力,那么只需升级光学器件即可。在结构内运行异构链路速度不是问题,因为每个路由器可以充当速度匹配设备。

        这种架构在数据中心领域已经很常见了,根据交换机的层数,它被称为 leaf-spine架构或super-spine架构,并且已经被证明是非常健壮、稳定和灵活的。

        从转发平面的角度来看,很明显这是一个可行的替代架构。剩下的问题是在于控制平面和管理平面。向外扩展控制平面需要在控制协议的规模上有一个数量级的改进。我们试图通过创建架构的代理(将整个拓扑表示为单个节点)来改进我们的抽象机制来实现这一点。

        类似地,我们正在开发管理平面抽象,它允许我们将整个Clos结构作为单个路由器进行控制。这项工作是作为一个开放标准进行的,因此所涉及的技术都不是专营的。

        在过去的50年里,路由器体系结构在技术之间的权衡中不断发展,出现了许多失误。很明显,我们的进化尚未完成。在每次迭代中,我们都处理了上一代的问题,并发现了一组新的关注点。

        希望通过认真总结过去和现在的经验,能够让我们以一个更灵活和健壮的架构向前推进,并在未来无需forklift upgrades就可不断改进。


关于作者:

Tony Li作为互联网路由领域的先驱者已经有30年的历史,他帮助扩展了互联网架构,领导了BGP和CIDR的部署。

{测试窝原创译文,译者:Elaine66}


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
304° /3040 人阅读/0 条评论 发表评论

登录 后发表评论