作者简介

李洪亮

NETOPS 高级经理

07年加入360，见证并带领团队支撑了公司网络规模从千台到10万台 server 规模的发展；历任高级网络安全工程师，经理和高级经理。

一、软件在奇虎网络发挥的作用

软件和网络相关的我们做的第一件事情是对出口流量的分析，大家做过一些基础的运维，一开始通过其他软件比较方便获取到通过 Cacti 获取网络设备的流量，但是我能知道设备跑 1G 还是 10G。

但是不知道里面跑了哪些应用，和 IP 地址，包括其他的东西通过有一些采样，但是这里有非常多的限制，效果也是非常不好的。

但我们这样通过两年时间的努力，把整个奇虎360接近1T的出口流量进行了盘路分析，这里能把里面具体哪一个 IP 地址跑哪些流量，哪些协议比较好的分析出来，其中对接近几百个G核心机房进行全流量的分析。

对全流量进行采集之后实现基层的分析，然后从里面获取到一些比较有用的信息提供给安全团队，有他们进行后一步的分析，这里这个功能上线之后，已经是帮助他们几起侵蚀事件。

这个是大体量的架构，在座的各位如果有做过流量分析有一个设备少不了的，就是对流量进行重新的 hash，使同一个 tcp 连接的数据流能够到达通一台主机上。

另外一个现在做的一个事情，可能在座各位做网络运维可能每天接到案子拓扑3个有业务部门告诉你从一个 IP 地址到另外一个 IP 地址慢，但是这个慢到底因为什么原因，有可能是流量满了，有可能是丢包。

我可能需要根据它的原横点 IP，打开这么多网络设备具体查找是哪个口出了问题，这个其实我们在网络之后是非常困扰我们的事情。

然后这个东西是接近几个月的时间完成的工作，当我输入业务部门提供的原 IP，在这个平台里查，就可以把所有经过的网络设备全都描述出来。

然后同时，根据我点对应的口，可以把它到底跑多少流量里的错误这些信息全都展示出来，能非常快的定位我们出现的问题，这个功能看似简单，是我们团队接近两年时间积累的结果，因为这里要完成这件事情首先要对所有 AIP 根据收集，对所有地址进行收集，同时要把所有的整个路径查找做好。

还有一个是 LLDP 信息也做收集，同时把这个东西关联起来，这件事情还是比较有挑战的工作，这个可以说是接近2年时间积累后得到的成果。这个是我们整个大体上的一个架构，收集了路由表、ARP 等等信息，但是同时还是有一些不太满意的地方，一个是收集是周期性的，没有办法做到实时的效果。

做的第三件事情是网络带宽之间的监控，这样网络运维的可能经常也收到业务部门去问，为什么昨天晚上几点到几点业务量掉下来了，肯定忘了不好，其实是没有很好的办法反击他说网络是好的，有了这个是有一个比较好的数据，证明在这个点从这个点到全国各个地方网络品质是保证的，你的业务流量掉是运维的问题。

但是这样还是有一些我们在做完这个工作之后还是有一些局限性，首先覆盖的范围不够广，不能太好的说明问题。

另外不能发现交换机丢包的问题，现在这种监控方式可能小于10%左右的丢包，但是千分之一或者到百分之一的丢包率现有方法是没有有效的方法可以检测出来的。

我们现在也在调研一个微软的方法，可以到一个 fullmesh 的监控结果，同时把这个数据放在 Hadoop 里面，通过进行计算，这只是一个思路，但是具体我们到底要投入多少成本才可以做这件事情内部还没有开始做这件事情。

第四件事情我们实现对机房攻击自对和手动的 block，是现在主流路由器有比较好的支持，它的好处是对于基于五连组规则对流量进行评比，甚至是限速的规则，这个其实是对我们来说这件事情不是太难，有一个软件叫 Exabgp，可以和程序有比较好的互动。

经过这两年我们的积累一些大数据，已经证实了网络可以通过 ES、Hadoop 这些大数据应用分析真正帮助我们去发现更多问题，去解决我们一些问题。

对于和网络设备自动化打交道，其实我们在之前这个过程中发现非常痛苦，因为各个厂家的接口是不一样的，而且这个厂家不同版本之间的命令也会不一样，这样这件事情会非常痛苦。

二、奇虎在硬件设备上VxLAN实践

第二部分讲一下 OpenStack 在私有云和公有云里面的实践。最早我们公司通过 OpenStack 实现私有云和大家一样，通过 vlan 方式进行实践网络的接入。

但是这种有两个问题，一个需要通过堆叠解决，真要实践经验，如果比较有心的工程师，大家都知道能不用堆叠的地方尽量不用堆叠的方式，因为堆叠说是能比较好的做冗余，但是实际上带来的问题比解决的问题还要多。

第二个是虚机不能实现热的迁移，因为一些配置没有办法做到一个统一化。在第二个版本使用中，我们已经做了一些工作，包括把 OVS 到 DPDK 的版本，把网卡升级，能够卸载 VxLAN 的 checksum，和卸载 Vmlan 封装和解封装。

通过一段时间的工作，我们也验证 VxLAN 和 OVS 结合的可能性，最后我们就实现了 EVPN 这个东西，一个我们想出具体这个东西在我们场景下怎么落地，同时是等待网络设备厂商一直在发展支持这项技术。

因为毕竟不可能自己做网络设备的东西，所以还是依赖于网络厂商实现这样功能。现在来看，EVPN 通过我们和厂商的交流，现在 EVPN 已经是比较主流的方向。这是我们计划上线的 OpenStack 私有云的网络拓扑。

三、我们团队对SDN的看法

这里我想说一下我们团队和我对SDN的看法，接近4年的发展，SDN 现在已经处在成熟度曲线的过高峰值下滑阶段，我个人来说感觉这样是一个比较好的一个位置。

因为经过前几年的炒作，现在慢慢的有点尘埃落定的意思，伴随着这件事情，这种情况有几个好的地方，一个首先用户是比较好的想清楚 SDN 到底要帮我做什么事情。

另外设备厂商也明白了他们到底能提供什么样的 SDN 的方案去给用户解决具体什么问题，同时因为设备厂商设备生产从芯片设计到流片到设置出厂需要一段时间的周期。

经过这几年实践的发展，他们设备也在慢慢的成熟，真正的 match 到用户的场景，这是建议大家从这个可以开始做和 SDN 相关的东西。

包括做软化和网络相关的，我个人的感觉做好向南和向北这两个事情。

所谓的向南是怎么更好的和设备打交道，比如去把不同的设备厂商，不同的设备型号在我这个层面抹平，比如一个用户或者某一个人想在某个端口 Vlan，不再需要 KR 这个设备是思科的还是华为的，而是改善另外的 vlan 这是向南的事情。

向北我认为做好两件事情，一件事情是可视化，所谓的可视化是把我的网络比较好的展示出来，另外一个提供接口，真正给业务来提供比较好的接口，他们想获取什么数据就可以给他们什么树去，是这样的事情。

最后是一些思考，毕竟是软件和网络的结合，现在 OpenStack 比较热，网络工程师之前是 CCNA、CCNP、CCIE 作为发展路径，之后把 MPLS 高深的协议搞清楚就没有什么问题了。

但是现在 OpenStack 比较火，同时我们确实感受到业务部门希望能从网络获取更多的东西，我们不能指望所有的人从 CCNA 一直到 CCIE 都学好。

我们看来最好的一条路径是网络工程师学开发，这也我们这一段时间真正做的事情地真有之前 CCIE 的水平从 python 去学习，把这些比较好的展现出来。

Q&A

1. 提问：我们公司是在全国各地加了很多私有云的环境，我们想对它进行一个统一的网络管理，有几个问题，第一个对于网络自动化运维，您的建议比如我用类似于开源的监控的工具或者运维的工具把它组合起来形成一套完整的网络的自动化的运维，还是用我们公司的不研发力量，一起自己去开发一套自动化的监控系统？你这里有没有什么好的建议？

李洪亮：你现在是私有云？包括网络设备都是你们的？

2. 提问：设备本身来讲是客户的，我们负责运维，我们专门做阿里专有云的。

李洪亮：你现在涉及到网络设备和服务器的运维？

3. 提问：对，网络加上之上承载整个阿里云平台都是我们运维。

李洪亮：你想问到底用开元的方式还是自己去开发实现对它的功能？

4. 提问：考虑对全国所有专有云网络的进行自动化的管理。

李洪亮：涉及到需要对网络进行配置。我说一下我的经验，对于网络设备，我们的经验是一套商业的网络软化是必不可少的，对于网络工程师来说，怕的不是网络设备宕机，他怕的是风扇坏了或者温度高了但是你还不知道。

但是这几个信息的采集，如果从头去做，这件事情是比较难的，你把它识别成到底是温度是多少度，还是转速是多少，这是现有软件开发成本非常高。

我们现在的方法是这个应该是在4年前买的一套商业版的网络软化，它的优势是他们特别好的去对市面上所有网络软件进行识别，同时有一些告警功能，当你的温度达到一定阈值，或者风扇突然转速变快了，可以产生对应的告警，这些事情如果从头做花费的精力还是比较多的，你可以有这套软件在这，对网络设计跟监控，你可能下一步要做的是他所产生日志统一的收集和处理，这是我第一个建议。

第二个建议是，如果真的想比较好的实现对网络设备的控制的话，我建议还是自己由网络团队一起去做一些定制化的开发，形成一套框架做这个事情，这是我的建议。

5. 提问：你刚才说到软化，对各个厂商碰到兼容性有没有什么问题？

李洪亮：市面上用的比较多的，国外是 solarwinds，国内好象也有几家，但是那个可能更偏向于运营商，那个价格我也未知，我们公司选择的是solarwinds，所以我对这里还是比较认可的，也不是很贵，你投一个在那干两天时间值很多。

6. 提问：我想问一个，你刚刚讲的流量分析，通过流量分析发现入侵事件，我想知道这个是怎么做到的？

李洪亮：简单来说，我对它的流量进行一个采集，采集的方法是通过分包器，或者通过端口流量镜像，通过镜像把一个流进行哈希，让这个流到倒打一台主机上，到达这台主机上就可以对它的数据一个 IP 地址到另外一个 IP 地址所有数据是到这台机器上，这样可以对它的协议进行一个还原，可以把里面 LLDP 的内容以及返回的进行收集。

这点比如做安全的知道，直接去取数据库，我们安全团队人不是太关心的信息，但是最关心的是服务器反馈的信息，如果返回是包含攻击成功的数据特征会产生很高的。

7. 提问：还有一个问题是您说的从原IP到物理IP这一段，你们有一个网络状态的监控，之前我们有项目也有类似的一个问题，因为网络太复杂，像这些路由信息比较难以收集，你们怎么处理的？

李洪亮：这个我刚才一直在说的，刚才说原和物理IP做到这个功能是我们团队接近两年时间的积累才达到这样的水平。

在此之前，比如我过去 ARP，首先要把 ARP 获取，另外路由表要获取到，这个是里面最痛苦的地方，通过一种方式没有办法得到想要的所有的东西，所以有的时候通过一个框架去周期性的取这些东西，有些是通过 SNMP 获取。

8. 提问：因为本次课题还是在于网络运维自动化，我想请教一下，前面你这边讲到对应的服务结果体量还是蛮大的，我不清楚真正上架对网络层的设备，你们实现方式是什么样的自动化法，手动物理插线逃脱不了，但是配置怎么通过自动化利用平台吗？还是通过什么脚本写入？

李洪亮：第一个问题是你想知道网络配置你认为有大量的网络配置去做，我们怎么去实现这样的功能，这个分两块，第一个上线的时候，怎么让它自动化的把这个配置获取到，这些东西业界已经有一些比较好的使用的方法，我们在一年前也已经研究出来，然后在一个机房做了试点。

但是这个结果效果不是太理想，并不是我们功能做的不好，而是比如内部想这样的一个问题，我们上线的时候需要刷配置，这点工作到底占整个在实施 IDC 机房里面到底占多大的工作量，可能是小于10%的，甚至有些是小于5%的。

第二个是内部讨论，这件事情是不是真正减轻工作量，其实不是的，因为这些配置刷这些配置这件事情是我们代理商做的，这个过程中我们去做这件事情并没有真的减轻我们的工作量，所以我们把这个东西研究出来再一一验证一下，发现并不是真的减轻工作量之后没有做这件事情了。

第二个问题是你所说的交换机配置频繁修改，怎么做自动化，这个我们已经做到一些东西了，但是我们这边的情况网络设备配置更改并没有大家想象中那么频繁，这是我这边的感觉，另外一个我们也做了一些接口，把这些接口做好了，比如要改一个端口从1变成100，那我们已经能做到这样的工作了。

9. 提问：我的网络很简单是200多服务器的网络有两个数据中心，一个是业务已经扩容了，我现在的是200台机组可以容纳，比如现在上三百台。现在网管在出口上不在内部交换机上，你刚才说内部交换机做堆叠，因为出口和冗余都做了堆叠，那用什么样的经验可以说一下吗？

李洪亮：先回答你第一个问题，堆叠这个事情，这个为堆叠这个事情的恐惧我估计你维护几百台服务器的规模，可能像大家挂彩票，出现问题的概率是比较小的。

但是当你的规模达到像我们这边交换机数量有6000台，经历的故障比较多，堆叠的故障率要远高于普通的，或者三层路由的模式，所以包括一些思科也好，后来大家有点抛弃堆叠方式，思科5、6年前就推出 VPC 的概念。