基于 Flow 的云网分析.docxVIP

基于 Flow 的云网分析本文简介：利用 Flow 的技术（软件定义探针）解决云网络可视化与安全，提升运维效率。作者张天鹏在这几年和各个云的对接以及面向我们的客户、合作伙伴，帮他们解决网络故障检修以及提供网络的整体方案过程中，我们深切的感受到如果想给一个云提供一个高质量的SLA是非常不容易的。今天我们聚焦在一个很小的点，即如何用 flow 的技术去做网络的虚拟化、可视化并提高运维效率以及解决云的内网安全的问题。业务云化的三大难题云的网络实际上是从传统的业务网络不断的向云端迁移和演进的过程。相比传统 IT 架构而言云非常大，要解决网络虚拟化必须引入SDN、OpenFlow或者各种比较复杂的技术。事实上，从逻辑上数据中心、云平台、租户网络是紧密耦合在一起的。举一个例子，两个 VM 的通讯有可能是在一个服务器内部，也有可能跨了机柜甚至数据中心等等，但是租户并不关心这个过程，他只关心网络的性能是否OK、连接是否正常。但云的运维者必须非常了解这个过程，否则你就没有办法做 trouble shooting。由于云规模的“大”随之而来的性能、高可用的难题便复现出来，具体表现为：Scale 的问题：一般云的规模都会比较大，比如100～200个机柜左右。VTEP 终结点：终结点在 Server/Tor 交换机上这会带来两个问题，性能和管理的问题。流量模型复杂：网络通信到底是二层还是三层，等等。在长时间跟很多云沟通以后，大家形成了这样一个共识：在设计云的网络时，除了生产网络还应该考虑监控网络。实际上监控网络后端的核心是一个分析平台，通过探针采集把云平台各种流包能够抓取过来，按照分析需求把采集到的流量导入相应的分析集群。但是不同的探针点在云平台里的部署难度是不一样的：在南北向的接口做流量分光相对容易；在接入层做做流量镜像/分光比较难。首先是架构设计上没有预留镜像的接口；其次做分光会引起业务中断，所以很难实施；在 Open vSwitch上引流会对租户网络性能有影响。在我看来这是一个探针部署的问题，探针的部署应该是非侵入式的，最好是一个开源、开放的框架，这样 load 会比较轻。云网分析的设计理念那么从运维的角度来说，目前这样一个 Scale 比较大的网络分析的要求有哪些？云网分析的需求第一、可视化，这里面包括虚拟网络和物理网络。什么意思呢？就是不但能把租户的拓扑呈现出来，而且能把租户的流量映射到物理交换机上并做出关联分析、能做历史回溯，当有异常发生的时候立刻展现出来。第二、扩展性。现在很多市场上的分析的产品，实际上就是一个分析能力有限的盒子，但是云的规模在不断扩大，堆盒子的做法显然是不可持续的，最好是一个弹性开放的架构；同时能和现有的很多分析工具结合在一起，而不需要自己开发。第三、快速定位。从业务和运维的角度来讲，最重要的要把运维和业务的边界划分清楚。当别人告诉你出现问题的时候，你能迅速定位出来这是谁的问题。第四、智能。所谓智能主要是一个自动化的呈现和报告。我们原来在设计的时候定了一个规格，大概能处理 10,000 个 IP ，但我们有一个 Scale 不大的金融行业客户的云里有 60,000 个 IP 超过 3,000 个业务。在这样的一个场景里面，他的运维不可能把每一个业务都看一遍，他希望能够有一些智能的发现。另外，一些行为分析在做 DPI 的时候也需要智能的联动。技术选型在不改变原有生产网络的前提下部署监控网络的难点不一而足，具体到我们经历过的 Case 有以下四个方面需要重点考量。探针的选择，SFlow、Netflow/IPFIX、分光、镜像等各有优缺点。我们要考虑哪一种是最适合自己的。在云环境里当一个用户给你报障的时候，你需要快速定位出来，这个时间不能太长，否则用户会无法接受。数据的存储，云的流量非常大，尤其是东西向的流量。基础设施应该有能力做一些处理，再把流量送到后端。如果没有这种基础架构，现有的分析工具很难进行工作。多分析工具的支持，由于客户现有的业务和运维环境，我们不可能要求客户更改或重新开发相关的工具和插件，因此必须支持原有的分析工具。云感知与流量获取，在虚拟化环境里面资源经常在发生迁移，你怎么跟云的平台资源做联动，然后感知到目前问题发生的原因。我们选择用 Flow 的方式来处理，根据我们的实践 Flow 做云网分析有较大的优势。并且我们通过分析从 Flow 中采集到的数据，发现很多有意思的事情。轻量，Flow 只把五元组、连接状态、字节数、握手关闭、持续时间等信息，大概一个 Flow 有几百个字节。适合行为分析，按需与DPI结合。隐私安全，无需看用户数据。用 Flow 做云网分析的过程中，一个很关键的技术点是探针。软件定义探针通过 SDN 的能力我们把智能探针（Traffic Intelligence）部署在生产网络中，使用 F