《Cloud Native Data Center Network》读书笔记-4

第四章第一小节 对网络设备的要求

关注高效操作。换句话说，可以减少管理网络工作设备的负担。

关注敏捷性：更新的速度，维护和升级的速度，以及推出新的服务和设备的速度。

从这两个需求中产生了云原生时代任何网络设备的以下需求：

设备的可编程性

能够运行第三方应用程序

能够用同等产品更换供应商提供的部件

操作员修复代码中的错误的能力

换句话说，网络设备必须的行为更像一个服务器平台，而不是它长期以来的嵌入式盒或专用设备。

第四章第二小节 软件定义的网络和Openflow的兴起

网络研究界—如何使用一个由专有交换芯片组成的垂直集成交换机和一个非为平台设计的NOS来进行有用的研究？

使用大多数包交换芯片上可用的流程表来确定包处理。这将允许研究人员决定新的数据包转发行为。

允许流程表的切片，以允许操作员在同一个框上运行生产和研究数据。这将允许研究人员在真实的网络上测试新的想法，而不干扰生产流量。

定义一个新协议，允许远程运行的软件对这些流程进行编程并交换其他信息。

流表：

将数据包转发到由IP路由或桥接提供的不同目的地

删除数据包

执行计数、网络地址转换(NAT)等其他操作。

远程编程流表的节点称为控制器。控制器运行软件来确定如何编程流程表，并编程OpenFlow节点

具有一个中央控制平面和一个分布式数据平面，因此被称为软件定义网络(SDN)。其想法是将流表转换成为一个通用的、转换芯片硬件中的转发行为的软件抽象。这是一种打破特定于供应商的网络工作世界的新方法。

4.2.1 关于SDN和Openflow的更多细节

图4-1 OpenFlow与SDN
4.2.2 OpenFlow的问题

OpenFlow将多个问题合并为一个问题，将更多的抽象问题合并，那就需要更多的办法来解决

与路由器交换机相比较，流表芯片并不便宜

数据中心并不关心研究的过程

OpenFlow的抽象模型要么过于有限，要么太松散。无法得到市场大多数厂家支持

人们没有看到新意及带来的真正的价值

4.2.3 OVS

开放虚拟交换机（OVS）是在linux上开源实现的。

OVS附带了一个名为OVS DB服务器或只是OVSDB的组件，用于配置和查询OVS本身。OVS DB规范已由IETF作为RFC7047发布。图4-2显示了OpenFlow控制器、OVS DB和OVS之间的关系。

图4-2 OVS组件和OpenFlow控制器
4.2.4 SDN和OpenFlow对网络解耦的影响

OpenFlow和SDN在广域网还有其发展的空间

在数据中心里很少被使用

云内的问题还没解决

第四章第三小节 NOS设计模型

Linux：这是几乎每个NOS的基本操作系统。是指做处理和内存管理以及非网络设备I/O的部分，主要是存储。

Intel x86/ARM ：一个NOS需要一个CPU才能继续运行。

操作系统充当资源和想要使用这些资源的应用程序之间的调节程序。

每个操作系统都有一个用户空间和一个内核空间，主要通过受保护的内存访问来区分。操作系统还提供了一个标准的应用程序编程接口(API)，以允许应用程序请求、使用和释放资源。

图4-3 CPU和分组交换芯片在一个交换机组合体中
NOS的主要任务是运行控制和管理协议，维护诸如计数器这样的附加状态，并设置数据包交换芯片来转发数据包。

4.3.1 交换机网络状态的位置

交换机网络状态表示与交换机上的数据包转发相关联的所有内容，从查找表到访问控制列表(acl)到计数器。

特定于供应商的用户空间模型

最常见的模型只将网络状态存储在用户空间中特定于nos供应商的软件中。

思科的NX-OS和基于DPDK的网络操作系统实现了这个模型。

混合模型

特定于供应商的用户空间供应商堆栈。但是，NOS也将此状态的部分与内核中的同等部分同步。

Arista的可扩展操作系统(EOS)、微软的SONiC、IP注入的OcNOS、戴尔的OpenSwitch和其他许多公司都遵循这种混合模型

完整的内核模型

使用Linux内核的数据结构作为网络状态的最终真实来源。积云Linux是此模型背后的主要NOS供应商。

4.3.2 可编程的交换芯片

图4-4 用户空间交换-芯片驱动程序如何获取信息
交换辅助接口

大多数NOS供应商都定义了自己的硬件抽象层(HAL)和使用芯片供应商驱动程序的芯片特定部分

Switchdev

为了应对包交换芯片缺乏内核抽象的问题，积云网络和Mellanox以及其他一些内核开发人员在Linux内核中启动了一个新的设备ab约束模型。这称为交换开发。

4.3.3 API

当内核在标准结构中保持本地网络状态时，标准的Linux内核API就是编程API

4.3.4 不同答案背后的原因

linux内核进化

第四章第四小节 用户接口

用于传统网络设备CLI的网络操作员将不知道如何继续操作。

第四章第五小节 比较NOS模型与云原生NOS需求

4.5.1 用一个示例来说明这些模型

Ping

假设，ping 10.1.1.2，假设内核路由表都包含相关信息，首先，在内核和混合模型中，交换芯片端口都在Linux内核中重新表示为常规的以太网端口，但它们的名称不同。在任何一种模型中，一些实现都可能会选择实现一个专有的内核驱动程序，它连接在表示交换硅端口的网络设备后面。其他程序可能会选择使用内核的Tun/Tap驱动程序将数据包引导回NOS供应商的用户空间组件，以处理转发。

交换芯片供应商定义了CPU复合体和用于交换芯片之间的包通信的内部包头。这个内部标头指定了从哪个数据包接收或需要发送的端口，交换芯片所需的任何通告数据包处理，等等。

当发出ping命令时，会发生以下操作序列：

1、应用程序ping打开一个套接字，将数据包发送到10.1.1.2。这和它在运行Linux的服务器上一样。

2、内核的路由表指向swp2作为下一个跳点。交换芯片的tx/rx驱动程序将数据包传递到交换芯片，以便传输到下一跳路由器。

3、当ping回复到达时，交换芯片将数据包传送到内核。交换芯片的tx/rx驱动程序接收数据包，内核处理数据包就像它进入网卡一样。

4、内核确定将数据包传递给的套接字，然后ping应用程序接收它。

包转发行为是芯片，而不是Linux内核。

其他一些商业网络操作系统，它们使用被称为Tun/Tap的虚拟网络设备，在内核内创建映射到交换芯片端口的交换机端口。

NOS供应商在作为虚拟机运行时，在其用户空间堆栈中实现了数据包转发。ping的步骤顺序如下：

1、应用程序ping打开一个套接字，将数据包发送到10.1.1.2。

2、内核为此包进行包转发，并将其发送给内核路由表指定的端口et2。

3、et2是一个Tun/Tap设备，因此数据包被发送到NOS供应商的用户空间堆栈。

4、用户空间堆栈执行必要的任何供应商特定的处理，然后使用包交换芯片的实际驱动程序将包发送到适当的前面板端口。

5、当接收到ping回复时，交换芯片将数据包传递到用户空间堆栈。

6、处理包后，用户空间堆栈将包写入相应的Tun/Tap设备。例如，如果通过交换芯片端口3接收应答，则将数据包写入et3，即与该端口对应的Tun/Tap端口。

7、内核接收这个数据包并处理它，就像它来自一个常规的网络工作设备，比如网卡一样。

8、最终，内核将数据包交给ping进程。

运行一个不同的路由协议

在混合模式下，如果路由协议套件需要编写与内核不同步的编程状态，则需要进行修改以使用NOS供应商的API。即使这个第三方路由套件想要对内核进行编程，它也必须采用NOS供应商在内核中实现交换硅接口的特性。

第四章第六小节 NOS还剩下什么要做呢？

除了编程交换芯片，NOS还需要读取和控制盒子上的各种传感器，如电源、风扇和接口上的led。还有用户界面，光学器件等。

第五章 路由协议选择（略）