SDN实战团分享（十五）：2Cloud Aladdin：谈谈云中网络运维

大家晚上好，今天我来分享一些云杉在网络运维中的所做所想，现在开始密集轰炸了。相信不少人看到了云杉年初发布的NSP解决方案，以及上周的新闻稿。我今天主要讲的也是2Cloud NSP，中的一环2Cloud Aladdin：谈谈云中网络运维。

一般人们关注SDN都是在控制能力上，都希望了解能用SDN实现哪些新功能。但SDN真的要跑严肃业务，运维是非常重要的。举个例子

这是云。管理员收到了报障，有个虚机不通了。这时候他应该怎么办？这套云网络不是以往托管机房的网络，他不知道故障到底在哪。可能在公网，可能在fabric，可能在ovs，也可能在vm里面。再举个例子

用户的业务是这样的，lb后面挂一堆web, app, db。现在android访问正常，但ios访问就是慢。管理员接到报障也一头雾水。我们的阿拉丁，就是这样一个系统，希望帮助云的运营和运维者更轻松的面对这个复杂的、多租户交错的虚拟网络。

接下来我大概会从两方面来介绍：事先怎么做监控，以及事后怎么做分析。

监控一般包括主动和被动监控。主动监控通俗来说就是发包探测网络状况。一般来说对于公网的监控使用传统方法就可以了，现在也有很多成熟的服务，像听云、监控宝等等。但私有网络内部的监控是不太好做的。

在虚拟机内部安装agent并不是所有用户都愿意的事情，如果这个agent恰好由于bug比如删错了一些文件，那问题就更大了。所以我们的做法是在vswitch上构造报文进行探测。这里面涉及到两个问题：怎么处理回包、怎么并发探测。

如果设置规则截获回包，规则设置不准可能会导致虚拟机正常的通信被我们的监控系统截获。我们采用的做法不是截获，而是嗅探。这样的话，虚拟机会多收到一些包，但不会由于少收到包而影响正常通信。

另外就是私有网络的规模可能很大，如果要做到n*n的密集探测，探测进程的资源利用率会上去，因此要考虑并发探测、以及合理选择恰当的探测间隔。探测间隔不必是固定的，根据最近一段时间的网络状况可以进行灵活调整。

总的来说，除了私有网络内部的监控以外，主动监控的这部分做法还是比较传统的。下面我要说的是我们的被动监控

被动监控这部分也是最初Aladdin名称的由来——我们希望做一个平台，从数据的采集、存储、简单分析、展现，到向第三方合作伙伴的开放。这些都依赖于我们的分布式探针DFI——Deep Flow Inspection。

一般都谈论DPI，但DPI的问题是：如果不采样，流量太大；如果采样，不准。所以DPI一般用在南北向，或者针对特定用户使用。数据中心中绝大部分流量是东西向内网流量。如果要把这些流量都送出去做DPI，一来会加重末端vswitch的负载，二来会使得东西向流量double——相当于tor上行少了一半。（当然这里没考虑分布式DPI）

DFI的做法是，在内核空间获取ovs的flow统计信息，并周期性复制到用户空间。对比其他类似方法，比如IPFIX，有一些优点。

当然，我们的这套探针也是可以接IPFIX后端的。主要用于无法更换内核模块的场景，代价就是上面说的性能和信息损耗。DFI解决了流的采集问题，我后面会讨论包的采集问题。除了这些网络上的信息，我们同时也采集了一些传统的东西：

我们用Fluentd/syslog采集了所有宿主机、交换机、安全设备上的日志，也包括我们控制器自身的日志。利用Collectd/Telegraf/QGA和一些plugin采集宿主机、交换机、虚拟机的负载和资源用量。这些探针都是分布在云中每个物理节点上的，这些信息弄到一起，下一步就是存储和分析。

我们的NSP主要面向云平台，因此存储和分析也在用云的能力解决云的问题——利用一堆线性扩展的虚拟机来存储和分析收集到的这些信息。对于一个虚拟机，大概是这样的

收集到的实时流数据，通过缓存、分发后由各个APP打上资源、租户的关联信息，进行实时处理。处理结果储存在两个地方：对于描述用量、状态、特征的信息，存储在时序数据库influxdb中，对于原始flow、日志等信息存储在全文检索引擎elasticsearch中。另外一部分是用于离线计算的，存储在hbase中。各自用于不同的目的。

简单来说，我们基于DFI和其它探针采集数据，然后基于EFK（Elasticsearch Fluentd Kibana）、TIGK（Telegraf InfluxDB Grafana Kapacitor）以及HBase/Spark等技术栈，构建起来一个分析平台。

当然云杉的强项不在于怎么做分析，而在于怎么高效的拿数据。因此分析这方面我们也有和工业界、学术界进行合作。目前我们的这个东西，管理员还是比较喜欢的。

这是其中的一个展现。请大家忽略杂乱无章的排布，这个我们还没做智能布局，不过管理员是可调的。我们能看到最近特定一段时间内，一个租户的业务网络中的通信状况：多少连接，多少不完整，质量如何。详细信息可以跳到这里：

俗话说好马配好鞍，就像发现APT光有高手还不行，还要有好工具。我们希望能做出这样好用的工具。至于规模，目前这套体系都是分布式的架构，可以线性扩展。

刚才我贴的那张网图，也能解决我开头提到的一些管理员困惑：一个lb后面挂2个web，为什么ios不能访问而android可以？如果lb和一台web之间是红的，那可能可以解释了：或许应用就是把ios负载到那台web上了。目前我们做了一些分析，比如：

好了，第一部分完事。

有了故障，管理员怎么搞。我们给出了四步

先说第0步：他不希望登陆任何一台kvm。 第一步：配置自动化检查。其实主要是网络层面的配置，虚拟、物理交换机的acl, vlan, qos, vtep等等。当然我们也有云平台，于是也做了计算和存储上的配置检查。

其实这一步没有太多难点，稍微复杂的在物理设备上，比如怎么比较数据库中的一堆策略和交换机上的一堆ACL是匹配的（也就是期望状态===实际状态）。

第二步：DPI。我们的监控是基于DFI的，但也不排斥DPI。当我们知道了问题可能的方向以后，DPI就能派上用场了。目前我们能做到的是将一个租户的多个虚拟机、虚拟网关等设备的特定流量dump下来，集中展示。但这个还不够，现在我们在把高级货往上用。高级货除了DPI盒子，还有wireshark，这个东西网管用的很溜，我们在做的事情就是把指定多个虚机的指定流量镜像到其中一台虚机上，然后管理员开个wireshark，可以干很多事。

第三步（也可能这是第二步）：主动探测一下。前面其实已经提到一些主动探测的问题。首先管理员没密码不能进虚拟机，于是我们提供了在vswitch上模拟发包探测的方法，管理员可以指定探测源和目的，利用arping/ping/traceroute等进行无扰探测。如果这还不够，我们也支持tcp探测，但这可能会对虚拟机正常通信产生影响（比如和虚拟机正在进行中的端口号重了）

这一步也能解决很多问题。但解决的都是传统网络的问题，毕竟这些工具都有了好多年了。云网络中的特点是overlay。

那么第四步：他可以用我们的物理追踪工具，把二层网络中两个虚机通信路径上的所有点dump出来，包括：宿主机、tor、spine、二层安全设备等等。

这个东西真能解决问题，比如MLAG，要求两台交换机配置一致。但管理员其实挺野的，搞得不一致了。租户网络此时体现出来的现象非常奇怪，但用物理网络追踪工具，可以明显看到流量到了tor这个层面后，只有一条通路。

目前来看这几步走下来还是很有效的，当然我们也还在做一些新的东西，比如刚才提到的将分散的流量弄到一个DPI或wireshark上去。

Q&A

Q1：请问你们OVS是纯软件交换机吗？性能怎么样？ 我们很早就做了一些内核层面的性能优化，目前也在尝试DPDK。

Q2：怎么去主动探测的？在ovs上构建流表？ 对这里的ovs只指虚拟交换机open vswitch。物理设备的接入我们也用物理交换机。造包然后发出去，利用当下火热的golang，挺方便，并发效率也高

Q3：用OVS做软交换机，性能你们达到多少呀？ 没有DPDK情况下小包应该是2G左右，大包没压力。

Q4：是不是要在所有的物理服务器上安装相关的agent? 是的，现在时髦的说法是————微控制器。

Q5：请问在ovs上做ACL效率高，还是像传统的安全组做在linux bridge上？ ovs，少了一跳，不过linux bridge有优点：可以搞带状态的。ovs实现带状态的比较麻烦，也是我们在做的一件事

Q6：如果用户不让你hook他的ovs，是不是就取不到这些数据了，也就没有然后了？ 有然后，我们也能对IPFIX

Q7：vxlan 的vtep在哪里终结？有什么经验么？ 这个问题容易引发群战。我的观点是中庸：像openstack那样做到服务器上vlan范围太小了，隧道太多了；像有些设备厂商那样仅在核心大柜子上支持，范围又太大了。我们选择在tor上终结，刚刚好

Q8：流量去重好做吗 哪方面去重？我们目前做了去重，在分析节点做的，因为一条flow可以在多个宿主机上看到。

Q9：ovs能维护多少规则呢？流表条数可以存那么多吗？ ovs上流表条数倒是可以存很多，反正都是内存都是hash，但我们目前不会让它存太多，主要是降低运维复杂度。避免流表爆炸，一方面我们用到了pkt in，另一方面用了多级流表。

Q10：ovs现在已经支持conntrack了吧？ 是的，在支持security group，带来的问题就是流表多。

Q11：如果在ovs构建流表，会和AC下发的冲突吗？ 这里的AC是中央控制器吗？我们中控不会直接千里迢迢下流表。微控制器复杂proactive和reactive下流表。