OpenStack已经演变成一种被广泛采用的云管理框架,这是显而易见的。当openstack步入快速增长的轨道时，新一代的需求让他们感受到，必须由有一个灵活可扩展的成熟的平台来满足。其中的一个要求是能够监控在OpenStack数据中心发现的基于虚拟网络结构的流量。
从概念上讲，监控过程包括在网络基础设施的适当地点放置抽头设备，并将它镜像给流量分析仪。这些分析器可以看到相同的数据包通过这些网络段，就像他们串联在网络中一样。 一个逻辑抽头装置，可以简单地使用端口镜像功能的网络转换元件所组成，即使数据包穿过一个或多个交换机端口时，将它的一个副本的传送到本交换机的另一个端口上。这种能力几乎所有在用的物理交换机和虚拟交换机都支持。那么，它为什么仍然不能监测OpenStack虚拟网络的状态呢？ 这个问题的答案在于了解基于云的虚拟化平台的两个重要网络结构特点：多租户和位置独立性。前者允许可用资源和服务可以不同的用户组之间共享。每个组被称为一个租户，拥有完全独立的环境，以至于组中的成员都忽略了它们与其它租户共同存在于一个环境的事实。 多租户机制促使控制指令将以一种更加安全和私密的方式下发。举例来说，租户可以被允许创建和管理自己的虚拟网络。至于位置的独立性，主要是指将单个基础设施组件的身份隐藏在虚拟化负载当中。这样可以将虚拟机从一台物理机动态迁移到另外一台上面。位置独立带来的另一个同样重要的，但也许不太赞赏的好处是提高了资源分配的效率。因此租户们对他们的虚拟机运行在哪台物理主机是毫无感知的。此外，属于不同租户的虚拟机可以放置在同一物理主机上。在这样一个共享的生态系统中，它是使人感到，租户没有直接进入网络底层，即由主机级的虚拟交换机，顶部的机架交换机等组成的交换矩阵。此限制避免了任何跨租户数据泄露的可能性。不幸的是，这意味着这些交换机的端口镜像能力也不可用。 说到流量监控在虚拟网络支持的缺乏，OpenStack并不是唯一一个。其他的云解决方案，包括亚马逊网络服务（AWS），也受上述原因的限制。然而，也有一方面优势使得OpenStack能脱颖而出。那是开源技术！这给任何能够和愿意引入新的能力和进入平台的人，提供了一个机会。在Gigamon我们生活和呼吸的网络流量的可见性，所以我们决定把它带在自己身上，成为那个将指针向前的'人'。令我们惊讶和高兴的是，我们很快就得知了，爱立信的项目组也在独立地证明这个结论。我们的目标融合得非常完美，我们似乎很自然，也很适合我们共同解决这个问题。 我们的项目被称为tap-as-a-service。它是一个平台化的解决方案，设计作为Neutron的一个延伸，即OpenStack的网络服务。TaaS可提供一个简单的API，将使承租人（或云管理员）监测Neutron配置的网络端口。租户的界限分明是非常重要的，租户只能监控自己的端口，不论是它的私人虚拟网络或在一个共享的虚拟网络上创建的任何端口。TAAS工作流始于tap-service实例的建立，并将有Neutron 端口为端口镜像会话目的端口。监控虚拟机通常连接到这个端口，以消耗镜像流量。接着，一个或多个抽头流可以添加到tap-service实例。 一个tap流代表正在监控的一个（源）端口和一个tap-service实例之间的关联。TAAS允许镜像会话跨多个主机，通过远程端口镜像的特性，从而确保独立保存的位置。
一个可参考的实施是今年早些时候完成的源代码已经上传到stackforge，OpenStack的孵化器，在一个专门的Git仓库现在存在这个项目[ 1 ]。在温哥华的最后一个OpenStack峰会（2015），我们做了一个技术演示这方面的工作，包括现场演示流量使用TAAS [ 2 ]监测。该反应是非常积极的，从开发商和用户社区的支持和关注。我们将强化功能；一些计划的特点与OpenStack仪表板集成，虚拟机迁移的支持，预捕获过滤和镜像的流量速率限制等等。 同时，我们也会继续与Neutron核心团队讨论，如何接受作为未来的OpenStack发行版的一个组成部分。 端口镜像是一个交换层功能。tap-as-a-service已经有效地虚拟化的这种能力，使它可用于Neutro的用户配置网络。我们看到抗原的基本构建块上更复杂的流量可视性解决方案可以设计一组不同的使用案例，从网络管理和拍摄应用/网络安全问题，数据分析和比较。
参考文档 1. Tap-as-a-Service code repository. 2. Tap-as-a-Service (TaaS): Port Monitoring for Neutron Networks. Alan Kavanagh, Anil Rao, Vinay Yadhav, OpenStack Summit, Vancouver, Canada, May 20, 2015.
