上一节我们说到，使用原生的 VLAN 和 Linux 桥的方式来进行云平台的管理，但是这样在灵活性、隔离性方面都显得不足，而且整个 络缺少统一的视图、统一的管理。
可以这样比喻，云计算就像大家一起住公寓，要共享小区里面的基础设施，其中 络就相当于小区里面的电梯、楼道、路、大门等，大家都走，往往会常出现问题，尤其在上班高峰期，出门的人太多，对小区的物业管理就带来了挑战。
物业可以派自己的物业管理人员，到每个单元的楼梯那里，将电梯的上下行速度调快一点，可以派人将隔离健身区、景色区的栅栏门暂时打开，让大家可以横穿小区，直接上地铁，还可以派人将多个小区出入口，改成出口多、入口少等等。等过了十点半，上班高峰过去，再派人都改回来。
软件定义 络（SDN）
这种模式就像传统的 络设备和普通的 Linux 桥的模式，配置整个云平台的 络通路，你需要登录到这台机器上配置这个，再登录到另外一个设备配置那个，才能成功。
如果物业管理人员有一套智能的控制系统，在物业监控室里就能看到小区里每个单元、每个电梯的人流情况，然后在监控室里面，只要通过远程控制的方式，拨弄一个手柄，电梯的速度就调整了，栅栏门就打开了，某个入口就改出口了。
这就是软件定义 络（SDN）。它主要有以下三个特点。
SDN 控制器是如何通过 OpenFlow 协议控制 络的呢/p>
对于每一条规则，要看是否满足匹配条件。这些条件包括，从哪个端口进来的， 络包头里面有什么等等。满足了条件的 络包，就要执行一个动作，对这个 络包进行处理。可以修改包头里的内容，可以跳到任何一个表格，可以转发到某个 口出去，也可以丢弃。
通过这些表格，可以对收到的 络包随意处理。
创建好了环境以后，我们来做这个实验。
- 从 192.168.100.102 来 ping 192.168.100.103，然后用 tcpdump 进行抓包。first_if 收到包了，从 first_br 出来的包头是没有 VLAN ID 的。second_if 也收到包了，由于 second_br 是 trunk port，因而出来的包头是有 VLAN ID 的，third_if 收不到包。
- 从 192.168.100.100 来 ping 192.168.100.105, 则 second_if 和 third_if 可以收到包，当然 ping 不通，因为 third_if 不属于某个 VLAN。first_if 是收不到包的。second_if 能够收到包，而且包头里面是 VLAN ID=101。third_if 也能收到包，而且包头里面是 VLAN ID=101。
- 从 192.168.100.101 来 ping 192.168.100.104， 则 second_if 和 third_if 可以收到包。first_if 是收不到包的。second_br 能够收到包，而且包头里面是 VLAN ID=102。third_if 也能收到包，而且包头里面是 VLAN ID=102。
通过这个例子，我们可以看到，通过 OpenvSwitch，不用买一个支持 VLAN 的交换机，你也能学习 VLAN 的工作模式了。
实验二：用 OpenvSwitch 模拟 卡绑定，连接交换机
接下来，我们来做另一个实验。在前面，我们还说过，为了高可用，可以使用 卡绑定，连接到交换机，OpenvSwitch 也可以模拟这一点。
在 OpenvSwitch 里面，有个 bond_mode，可以设置为以下三个值：
- active-backup：一个连接是 active，其他的是 backup，当 active 失效的时候，backup 顶上；
- balance-slb：流量安装源 MAC 和 output VLAN 进行负载均衡；
- balance-tcp：必须在支持 LACP 协议的情况下才可以，可根据 L2, L3, L4 进行负载均衡。
我们搭建一个测试环境。
OpenvSwitch 包含很多的模块，在用户态有两个重要的进程，也有两个重要的命令行工具。
- 第一个进程是 OVSDB 进程。ovs-vsctl 命令行会和这个进程通信，去创建虚拟交换机，创建端口，将端口添加到虚拟交换机上，OVSDB 会将这些拓扑信息保存在一个本地的文件中。
- 第一个进程是 vswitchd 进程。ovs-ofctl 命令行会和这个进程通信，去下发流表规则，规则里面会规定如何对 络包进行处理，vswitchd 会将流表放在用户态 Flow Table 中。
在内核态，OpenvSwitch 有内核模块 OpenvSwitch.ko，对应图中的 Datapath 部分。在 卡上注册一个函数，每当有 络包到达 卡的时候，这个函数就会被调用。
在内核的这个函数里面，会拿到 络包，将各个层次的重要信息拿出来，例如：
- 在物理层，in_port 即包进入的 口的 ID；
- 在 MAC 层，源和目的 MAC 地址；
- 在 IP 层，源和目的 IP 地址；
- 在传输层，源和目的端口 。
在内核中，有一个内核态 Flow Table。接下来内核模块在这个内核流表中匹配规则，如果匹配上了，则执行操作、修改包，或者转发或者放弃。如果内核没有匹配上，则需要进入用户态，用户态和内核态之间通过 Linux 的一个机制 Netlink 相互通信。
内核通过 upcall，告知用户态进程 vswitchd 在用户态 Flow Table 里面去匹配规则，这里面的规则是全量的流表规则，而内核 Flow Table 里面的只是为了快速处理，保留了部分规则，内核里面的规则过一阵就会过期。
当在用户态匹配到了流表规则之后，就在用户态执行操作，同时将这个匹配成功的流表通过 reinject 下发到内核，从而接下来的包都能在内核找到这个规则。
这里调用 openflow 协议的，是本地的命令行工具，也可以是远程的 SDN 控制器，一个重要的 SDN 控制器是 OpenDaylight。
下面这个图就是 OpenDaylight 中看到的拓扑图。是不是有种物业管理员在监控室里的感觉/p>
我们还是讨论 VLAN 的场景。
在没有 OpenvSwitch 的时候，如果一个新的用户要使用一个新的 VLAN，还需要创建一个属于新的 VLAN 的虚拟 卡，并且为这个租户创建一个单独的虚拟 桥，这样用户越来越多的时候，虚拟 卡和虚拟 桥会越来越多，管理非常复杂。
另一个问题是虚拟机的 VLAN 和物理环境的 VLAN 是透传的，也即从一开始规划的时候，就需要匹配起来，将物理环境和虚拟环境强绑定，本来就不灵活。
而引入了 OpenvSwitch，状态就得到了改观。
首先，由于 OpenvSwitch 本身就是支持 VLAN 的，所有的虚拟机都可以放在一个 桥 br0 上，通过不同的用户配置不同的 tag，就能够实现隔离。例如上面的图，用户 A 的虚拟机都在 br0 上，用户 B 的虚拟机都在 br1 上，有了 OpenvSwitch，就可以都放在 br0 上，只是设置了不同的 tag。
另外，还可以创建一个虚拟交换机 br1，将物理 络和虚拟 络进行隔离。物理 络有物理 络的 VLAN 规划，虚拟机在一台物理机上，所有的 VLAN 都是从 1 开始的。由于一台机器上的虚拟机不会超过 4096 个，所以 VLAN 在一台物理机上如果从 1 开始，肯定够用了。
例如在图中，上面的物理机里面，用户 A 被分配的 tag 是 1，用户 B 被分配的 tag 是 2，而在下面的物理机里面，用户 A 被分配的 tag 是 7，用户 B 被分配的 tag 是 6。
如果物理机之间的通信和隔离还是通过 VLAN 的话，需要将虚拟机的 VLAN 和物理环境的 VLAN 对应起来，但为了灵活性，不一定一致，这样可以实现分别管理物理机的 络和虚拟机的 络。好在 OpenvSwitch 可以对包的内容进行修改。例如通过匹配 dl_vlan，然后执行 mod_vlan_vid 来改进进出出物理机的 络包。
尽管租户多了，物理环境的 VLAN 还是不够用，但是有了 OpenvSwitch 的映射，将物理和虚拟解耦，从而可以让物理环境使用其他技术，而不影响虚拟机环境，这个我们后面再讲。
小结
好了，这一节就到这里了，我们来总结一下：
- 用 SDN 控制整个云里面的 络，就像小区保安从总控室管理整个物业是一样的，将控制面和数据面进行了分离；
- 一种开源的虚拟交换机的实现 OpenvSwitch，它能对经过自己的包做任意修改，从而使得云对 络的控制十分灵活；
- 将 OpenvSwitch 引入了云之后，可以使得配置简单而灵活，并且可以解耦物理 络和虚拟 络。
- 刘超-趣谈 络协议系列课；
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！