虚拟化环境的网络流量镜像，这三种实现方式哪个最佳？

如何规划建设虚拟化环境的网络流量镜像？

目前，公司正在建设基于网络流量镜像的相关系统，如npm、bpc、数据库sql语句审计等。并已初步搭建了type交换机网络。 但虚拟化平台中，部分虚拟机的网络流量可能在物理机内部的虚拟交换机中完成交互，无法从物理交换机上获取流量镜像。 我们了解到了虚拟化环境的网络流量镜像的以下三种方式： 1、使用VMware VDS分布式交换机的端口镜像功能 2、在每台宿主机上安装第三方的虚拟机，用于收集这台宿主机内部的虚拟机网络流量 3、在需要镜像流量镜像的虚拟机上安装第三方agent，收集自身的网络流量 三种方式都将通过区别业务网卡的单独网卡将镜像流量传送至type网络。 本人目前倾向于选择第一种方案，但是对于VMware的端口镜像功能是否会影响宿主机的整体性能存在担忧。 想向各位金融行业的前辈们请教下三种方案的优劣，大家都是使用哪种方式来实现的？实施过程中有没有踩过什么坑？

（@linjh 某证券 系统工程师）

以下是社区用户的讨论：

黄江 技术支持 , 某银行

目前，某银行使用的是：
2、在每台宿主机上安装第三方的虚拟机，用于收集这台宿主机内部的虚拟机网络流量
我行主要使用Gigamon的解决方案。

Gigamon 的虚拟化流量采集方案部署由 3 部分组成，包括 FM 集中管理平台、 VM 虚拟化采集探针和 GigaSmart 流量处理引擎。
GigaVUE-FM 集中管理平台 ( 矩阵管理器 ) ： Gigamon 的集中式管理程序 , 紧密整合 VMware vCenter, 用于批量部署和配置 GigaVUE-VM 矩阵节点采集虚拟机层面的流量监测策略。 可利用 vCenter 的 API, 在动态资源调度 (DRS) 和高可用性 (HA) 集群环境下追 踪 vMotion 事件 , 使可视化策略与被监视的虚拟机绑定 , 并随着虚拟机在物理宿主机之间的迁移而迁移。
GigaVUE-VM 矩阵节点： 是一套 vSphere 客户机虚拟机系统 , 部署在每一台宿主机， 无需特定的软件、内核加载模块或更改 Hypervisor 。用于从 VMware 的虚拟交换系统采集流量，并提供高级的过滤功能和数据包截短功能，然后将数据包进行封装转发至 GigaSmart 流量处理引擎。
GigaVUE-HC： 带有 GigaSmart 卡的 HC ，通过 GigaSmart 解封装功能，能够将数据包还原至原始报文，并可以调用其它高级功能如去重、脱敏等，并将数据包转发至相应的工具。

在本方案链路通讯部署上有 2 个组成部分，包括管理层面的链路通讯， Tunneling 链路通讯。
❶ 管理层面的链路通讯：用于 FM 对 VM 的安装、配置下发
❷ Tunneling 链路通讯：用于 VM 采集虚拟机流量通过 Tunneling 封装转发到 HC上

按照简单，控制方便，需要使用IP地址。
目前来说，对服务器性能影响很小。

赵海 技术经理 , 大连

首先，如果是物理交换机的化，一般都会采用专门的端口镜像设备把交换机上的流量进行镜像，然后用专门的软件基于镜像流量进行分析。这个是比较通用和成熟的做法，具体产品有很多。
那么，在虚拟化环境当中，第一种方案与物理环境的方案基本思路完全一致，从这个角度来看，其成熟度和稳定性是不需要担心的，至于说性能，只要将网卡的配置和流量的分析做好，不会出现大的性能问题。因为它并非实时扫描业务数据包的原理，而是对镜像流量包做处理的思路，唯一的区别是硬件资源并没有完全独立。镜像本身靠虚拟交换机本身的机制完成，物理交换机能把这个事情做好，虚拟交换机也不会有太大问题。

李荣杰 网络工程师 , 招商银行

我个人觉得三种方案需要的考虑点如下
1.依赖于VDS本身提供的接口和功能，由于没实际用过，可能不全。
2.宿主机上安装会对宿主机本身增加一些开销，另外需要能适配到用的虚拟化技术，获取到虚机流量。另一方面，宿主机宕机后，上面的虚机是否还能采集到，需要提前考虑方案。
3.虚机本身安装会对虚机造成较大的工作量， 建议集成到镜像里，减少系统同事的工作量。 本身agent的资源消耗需要评估。

杨文云 数据库管理员 , GBS

虚拟化及云环境下审计尤其是数据库审计普遍三种模一般如下

a 、虚拟机虚拟网卡绑定物理网卡

要求宿主主机有多个物理网卡，每个物理网卡和上层交换机直连，虚拟机层面在安装时可以指定将虚拟网卡绑定在对应的宿主主机的物理网卡上，然后使用传统的镜像方式镜像物理网卡的流量完成审计，这种缺点非常明显，要求物理服务器要有多个网卡，因此，在实际部署上并没有那么多网卡可供绑定，存在诸多限制，实际上并无法实施。

b 、在 VDS 上配置流量镜像

Vmware ESX 推出的功能，将某虚拟机网卡流量通过 GRE 封包，直接通过 TCP 协议发送到某个 IP 地址上（数据库审计设备），数据库审计设备接收 GRE 数据包完成审计，但是这种解决方案的缺点如下：

Vmware 版本及 VDS （分布式虚拟交换机），因为版本原因部分客户现场环境实际并不支持部署。一般通过 GRE 封装做流量镜像对宿主主机的物理网卡性能影响非常严重，所有镜像流量都要通过宿主主机的物理网卡进出，极大影响了物理网卡的性能， VDS 属于虚拟交换机，其对数据包的处理依赖于 CPU ，并不像传统交换机靠硬件进行流量转发， 目前大部分客户为了避免单一硬件的故障，基本上都采用虚拟化集群的方式实现企业的虚拟化，当碰到单一硬件的故障，虚拟机会在整个硬件虚拟化资源池中自动迁移 。

c 、开启流量广播

这种方式将数据库审计以虚拟机的方式部署在对应的宿主主机，当做宿主宿主机的一个虚拟机看待，然后开启 Vmware 的流量广播功能，每个虚拟机都将收到 Vswitch 上每个端口通信的 IP 流量，因此 DB 审计设备只需要采集其虚拟网卡上的流量就可以采集到目标数据库服务器的流量，只需要在采集阶段过滤掉其他流量即可完成审计， 开启流量广播虽然大部分 Vswitch 都支持，但是这种方式就好比早期的 Hub 一样， tcp 通信能力将明显降低，严重影响整体网络传输的时延及可靠，

总体上讲，如果虚拟交换机端口资源足够的情况下， 在 VDS 上配置流量镜像更好，把镜像流量从单独的网口走出，确保宿主机影响降低到最小

潘延晟 系统工程师 , 第十区。散人

工作中并没有实际接触到需要全部镜像虚拟机w网络流量用来监控的情况。不过有过虚拟机因为中毒发包。导致整个物理机端口堵塞。无法管理，整个物理机上所有的虚机全部瘫痪的情况，结合这个需求和以前跟VMWARE做过的一些技术交流。说说一些自己的看法吧，
在每台宿主上安装第三方的虚拟机用来收集宿主内部的虚机网络流量，在资源上浪费的有些多。每个宿主都要安装调试一套收集系统，不仅要分配出一定的资源来运行第三方的虚机，如果宿主多了。整个系统的管理也会有些麻烦。
在每个虚拟机上安装第三方agent的方式，相比第二种方式，应该要好一些。因为没有实用过。只能根据其他类似部署方式的软件来参考。第三方ANENT。一般来说对系统的资源消耗都比较少，相对稳定。一次部署后就可以统一收集信息，在成本和管理上都算是不错的选择，只是第三方ANENT有时候会因为个别虚机系统本身的问题产生一些服务无法启动，或者部分系统没有响应的ANENT，或者被部分安全软件限制等问题，
第一种方式，我记得VMWARE有个网络虚拟化的功能NSX。是收费的，可以实现很详细的虚机网络的管理与安全防护，能够避免我们当时遇到的那种因为一台虚机网络发包，塞死了物理端口导致所有虚机全都无法工作。只能重启整个物理机去处理的情况。应该也可以实现更详细的端口镜像的功能。优点我觉得应该是VMWARE的原生产品，从兼容性，成熟度上都会比较好，缺点就是部署复杂，而且费用相对比较高。不过我还是倾向采用这种方式。如果资金和技术资源都比较紧张，那采用第三方ANENT的方式我觉得也不错。可以根据不同重要程度的虚机进行镜像，对于重要业务安装anent。一些辅助业务，测试业务则只通过物理交换机镜像一个物理接口。抓取数据就行了。

chinesezzqiang 信息技术经理 , M

和您的想法一致，建议采用第一个方案，原因：
1.虚拟化的流量镜像对物理主机性能的消耗非常少；
2.建议虚拟化环境具备独立的镜像网络；
3.需要实际测试，此方案使用的不多；
4.可以参考一下第三方的流量性能监控设备，NPM方面的，如Netscout。

张鹏 数备中心技术总监 , 中国金融电子化公司

没有具体实践过，所以只能单纯谈谈想法。
通过问题的描述，如果三种方式都能达到用户的需求，三者比较起来我更倾向于第三种方案。原因在于只针对需要收集流量的虚机进行流量收集，这样针对性更强，减少无关信息的干扰并且减少无关流量收集时带来的整体压力。
第一种方案我觉得要谨慎使用，VDS虽然模拟了大部分交换机的工作，但是和传统交换机还是有区别。流量镜像这种事情最要用专用的设备，例如TAP 分流设备。SDN解决方案中也有类似的vTAP解决方案。

以上就是目前本问题的探讨，如果您也想发表自己的观点，请转到该问题下进行讨论