Falco项目:将交换机软硬件去耦合

简介:

三年前我们的数据中心的应用程序面临着一个潜在的严重问题,我们没有根据应用程序的需求对网络基础设施进行缩放,这些需求包括高速、高可用性以及快速部署。我们需要在网络层更好的控制功能,但我们在实现该目标的时候面临着障碍。

生产工程运营团队(Production Engineering Operations team,PEO)发现很难满足我们对应用程序的需求,尤其是网络中的路由器和交换机由厂商控制特性并修复Bug。一年以前我们发起了一个叫做Falco的项目,专注于对网络中的软硬件进行解耦。Falco工作组花了11520个小时研发我们的第一款网络交换机Pigeon,该交换机能够兼容这种控制。Pigeon将部署在我们位于Oregon的新一代大规模数据中心。

Pigeon是一个3.2 Tbps交换平台,可以作为leaf switch或者spine switch来使用。Pigeon是我们在交换机领域首次涉及软件研发,我们不会冒险研发我们自己的交换机,因为我们更希望成为交换机和路由领域的专家。我们将持续支持商业厂商,并与他们在解耦模型中持续合作。

研发交换平台的历程

软件工程团队发现的问题引起了PEO团队的注意,这两个团队发现数据中心的应用程序有着很高的延迟,这是一个没有任何结论性日志记录的很有挑战性的问题。几个网络工程师为解决这个问题殚精竭虑,最终发现这是一个微爆发的问题。当短时内连续发送数据包,导致线性时间内网络数据包缓冲区溢出堆栈,就产生了微爆发问题。这很难检测出来,因为缓冲区位于不能完全由商用交换机厂商直接接触的第三方商用芯片中。

当我们得出引起微爆发的原因是由应用程序的高延迟导致的,我们努力的寻找有效的方法来预测短时溢出,但我们越想解决这个问题,越难找出一个简单且优雅的解决方案。

然后,我们尝试从不同角度看问题。假如我们有商用芯片厂商遥测的数据会有什么效果?我们购买商用芯片的厂商不向我们提供读取/写入遥测数据的功能。我们解决微爆发的唯一途径是依靠我们的交换机供应商提供解决方案,但是我们发现这种方式不能及时适应我们的快节奏的环境。

我们开始关注除了商用芯片厂商遥测数据的其他挑战,包括:

软件中不能及时解决的Bug

数据中心环境中不需要的交换机软件功能,我们还必须处理与这些功能相关的Bug

缺乏基于Linux平台的自动化工具,如Chef/Puppet/CFEngine

过时的管理和日志记录软件,即缺乏对SNMP的依赖

高成本的扩展软件许可和支持

我们研究了由基于厂商的交换机引起的问题,我们经常反问自身“我们理想的交换机是什么样的?能够实现什么程度的控制?”我们对理想的交换平台提出了以下功能:

在任何硬件平台都能运行我们的商用芯片

在我们应用程序服务器上的交换平台能够运行一些基础设施软件和工具,如遥测、报警、日志、安全、Kafka。

快速响应需求和变化

推进DevOps运行,这样交换机能够像服务器一样运行,并且共享一个自动化操作平台

无限的可编程选择

功能速率

更快更好的创新周期

更好的控制软硬件成本

当我们看到理想中的交换机,我们以单一维度的视角思考微爆发/缓冲问题,控制交换机的可编程性为我们打开了实现可编程数据中心的大门。

在过去的两年中,我们一直在观察硬件和软件领域崩溃的现象,传统设备制造商(ODM)市场向任何购买其交换机的人开放其硬件,不再是著名的交换机厂商主导市场。这也意味着用户可以直接与多个芯片厂商合作,并且能完全访问芯片编程(如Trident,Trident II,Tomahawk)。

大约一年前,我们开始发展我们自己的交换平台,以上文中提到的指导思想为原则,提出了我们自己的基础架构,如下图所示

我们关注的应用层使用的是基于服务器的工具也是现有Linkendln基础设施的一部分,LinkedIn tools是一个管理配置和自动化的基础设施自动化工具阵列。Auto-Alerts是绑定在Nurse上的检测和报警客户端,是一个自动修复平台。该交换机的应用层也能支持Kafka客户机,Kafka是一个发布/订阅大量指标信息的管道系统,商用芯片SDK的遥测客户机接口能够获得最新的缓冲数据。

Pigeon的产品化之路

我们在LinkedIn发布了canary版本的软件,通过代码改变少量的主机。canary测试的目标是确保由代码引起的变化都能在现实工作环境中生效,在基础设施中也不会产生变化。经过3个月的实验室测试,我们在孤立的环境中生产,并且把部署了canary的交换机在生产环境中测试。

该交换机的架构是基于最新的Tomahawk 3.2 Tbps 32X100G商用芯片。

  未来的工作

我们将持续推进Falco项目的发展,我们对厂商支持的交换平台ONIE感兴趣,将接入他们的ASIC和商用芯片,借此我们可以在他们的硬件平台上运行我们的应用软件平台。交换抽象接口(SAI)也是我们发展的规划之一。

后记

Pigeon是基于LinkedIn的PEO工作组开展的Falco项目,特别感谢Shawn Zandi,Saikrishna Kotha,James Ling,Sujatha Madhavan,Navneet Nigori,Yuval Bachar以及项目经理Vish Shetty,Fabio Parodi。

注:编译类仅出于传递更多信息之目的,系SDNLAB对海外相关站点最新信息的翻译稿,仅供参考,不代表证实其描述或赞同其观点,投资者据此操作,风险自担;翻译质量问题请指正。

本文转自d1net(转载)

相关文章
|
11天前
|
安全 Linux API
Linux设备模型统一:桥接硬件多样性与应用程序开发的关键
在Linux的宏大世界中,各种各样的硬件设备如星辰般繁多。从常见的USB设备到复杂的网络接口卡,从嵌入式设备到强大的服务器,Linux需要在这些差异极大的硬件上运行。这就引出了一个问题:Linux是如何统一这些不同硬件的设备模型的呢?本文将探讨Linux是如何针对不同的硬件统一设备模型的,这一统一的设备模型对于应用程序开发人员来说又有何意义。让我们一探究竟🕵️‍♂️。
Linux设备模型统一:桥接硬件多样性与应用程序开发的关键
|
2月前
|
安全 Linux 网络虚拟化
关于容器云的三种网络设计
【2月更文挑战第9天】容器网络设计:隧道、路由、VLAN。
|
11月前
|
存储 监控 数据管理
「微服务架构」编曲与编舞——让系统协同工作的不同模式
「微服务架构」编曲与编舞——让系统协同工作的不同模式
|
人工智能 运维 算法