CN110226155B - 在主机上收集和处理上下文属性 - Google Patents

Abstract

本发明的一些实施例提供了一种新颖的体系架构，其用于捕获执行一个或多个机器的主机计算机上的上下文属性，以及用于消费所捕获的上下文属性以在主机计算机上执行服务。在一些实施例中，机器是虚拟机(VM)，在其它实施例中是容器，或者在其它实施例中是VM和容器的混合。一些实施例在每台机器上执行客户内省(GI)代理，需要从该代理捕获上下文属性。除了在每个主机计算机上执行一个或多个机器之外，这些实施例还在每个主机计算机上执行上下文引擎和一个或多个基于属性的服务引擎。通过主机上的机器的GI代理，在一些实施例中那个主机的上下文引擎收集与网络事件和/或机器上的处理事件相关联的上下文属性。上下文引擎然后向服务引擎提供上下文属性，服务引擎进而使用这些上下文属性来识别服务规则以进行处理。

Description

在主机上收集和处理上下文属性

背景技术

历史上，中间盒服务一直是在企业或数据中心的网络拓扑中的一个或多个点处实现的硬件电器。随着软件定义联网(SDN)和网络虚拟化的出现，传统硬件电器无法利用SDN和网络虚拟化提供的灵活性和控制。因而，近年来，一些人已经提出了在主机上提供中间盒服务的各种方法。但是，这些中间盒解决方案中的大多数都没有利用可以为主机上的每个数据消息流捕获的丰富上下文数据。对此的一个原因是现有技术不提供用于过滤数千个捕获的上下文属性以便高效地处理根据更小的上下文属性集定义的服务规则的高效分布式方案。

发明内容

本发明的一些实施例提供了一种新颖的体系架构，用于捕获执行一个或多个机器的主机计算机上的上下文属性，以及用于消费所捕获的上下文属性以在主机计算机上执行服务。在一些实施例中，机器是虚拟机(VM)，在其它实施例中是容器，或者在其它实施例中是VM和容器的混合。

一些实施例在每台机器上执行客户内省(GI)代理，需要从中捕获上下文属性。除了在每个主机计算机上执行一个或多个机器之外，这些实施例还在每个主机计算机上执行上下文引擎和一个或多个基于属性的服务引擎。通过主机上的机器的GI代理，在一些实施例中，那个主机的上下文引擎收集与网络事件和/或机器上的处理事件相关联的上下文属性。如下面进一步描述的，上下文引擎然后向服务引擎提供上下文属性，服务引擎进而使用这些上下文属性来识别服务规则，这些服务规则指定要对在机器上执行的处理和/或由机器发送或为机器接收的数据消息流执行的基于上下文的服务。

在一些实施例中，主机的上下文引擎通过各种不同方式从那个主机上的机器的GI代理收集上下文属性。例如，在一些实施例中，机器上的GI代理向机器的操作系统中的一个或多个模块(例如，内核空间模块或用户空间模块)注册钩子(例如，回调)以用于所有新的网络连接事件和所有新的处理事件。

在发生新的网络连接事件后，GI代理从OS接收回调，并且基于这个回调向上下文引擎提供网络事件标识符。网络事件标识符提供与网络事件有关的属性集。在一些实施例中，这些网络事件属性包括所请求的网络连接的五元组标识符(即，源端口和IP地址、目的地端口和IP地址及协议)，请求网络连接的处理的处理标识符，与发出请求的处理相关联的用户标识符，以及与发出请求的处理相关联的组标识符(例如，活动目录(AD)标识符)。

在一些实施例中，上下文引擎指示GI代理从OS模块收集与其随网络事件接收的处理标识符(ID)相关联的附加处理参数。在一些实施例中，这些附加的处理参数包括处理名称、处理散列、具有命令行参数的处理路径、处理网络连接、处理加载的模块，以及指定处理对机器的一个或多个资源的消耗(例如，中央处理单元消耗、网络消耗和存储器消耗)的一个或多个处理消耗参数。代替使用处理标识符来向GI代理查询与网络事件相关联的附加处理参数，其它实施例中的上下文引擎在GI代理向上下文引擎报告网络事件时一次性接收与网络事件相关联的所有处理参数。

在一些实施例中，机器上的OS保持新的网络事件(即，不开始发送针对网络事件的数据消息)，直到机器上的GI代理指示它继续处理网络事件。在这些实施例的一些当中，GI代理仅允许OS在上下文引擎已经收集了这个事件的所有所需属性之后(例如，在从上下文引擎接收到指定其已经接收到对于新网络事件其所需的所有处理或网络属性的消息之后)继续处理网络事件。

在一些实施例中，上下文引擎使用它从GI代理接收的处理散列来识别处理所属的应用(即，软件产品)的名称和版本。为此，在一些实施例中，上下文引擎存储处理散列和相关联的应用名称/版本，将其从GI代理接收的处理散列与存储的处理散列进行比较以识别匹配的散列，然后使用匹配散列的应用名称/版本作为与事件相关联的处理的应用名称和版本。

在一些实施例中，上下文引擎从一个或多个网络或计算管理器获得处理散列和应用名称/版本，其可以在另一个设备或计算机上操作。在其它实施例中，上下文引擎将与处理标识符相关联的散列提供给网络或计算管理器，然后网络或计算管理器将这个散列与其处理散列记录进行匹配，并将相关联的处理的应用名称/版本提供给上下文引擎。一旦上下文引擎获得与网络事件关联的应用名称/版本，它就可以向基于属性的服务引擎提供名称和版本属性，这些服务引擎可以使用这个信息(即，应用名称和/或版本)来识别要强制执行的服务规则。

在发生处理事件后，GI代理从OS接收回调并基于这个回调向上下文引擎提供处理事件标识符。处理事件标识符提供与处理事件有关的属性集。在一些实施例中，该组属性包括处理标识符。在一些实施例中，这个集合还包括用户标识符和/或组标识符(例如，活动目录(AD)标识符)。

在一些实施例中，GI代理在向上下文引擎报告处理事件时向上下文引擎提供与处理事件相关联的所有处理参数(例如，处理标识符、用户ID、组ID、处理名称、处理散列、加载的模块标识符、消耗参数等)。在其它实施例中，上下文引擎指示GI代理从OS模块收集与上下文引擎随处理事件接收的处理标识符相关联的附加处理参数。在一些实施例中，这些附加的处理参数与上面针对报告的网络事件提到的处理参数相同(例如，处理名称、处理散列、加载的模块标识符、消耗参数等)。

一些实施例的上下文引擎利用其从在主机上执行的其它模块接收的上下文属性来增强其从GI代理接收的上下文属性。例如，在一些实施例中，深度分组检测(DPI)模块在主机上执行。上下文引擎或另一个模块(例如，防火墙引擎)指示这个DPI引擎检查与处理ID相关联的数据消息流的数据消息，以识别由与该处理ID相关联的应用在这些数据消息中发送的流量的类型。

识别出的流量类型身份今天通常被称为AppID。而且，目前有多个DPI模块分析数据消息流的消息以生成AppID。在一些实施例中，上下文引擎将其为网络事件获得的AppID与其为这个事件识别出的其它上下文属性(例如，通过使用事件的五元组标识符将AppID与收集的上下文属性相关联)组合在一起以便产生非常丰富的属性集，服务引擎可以使用该属性集来执行其服务。这个丰富的属性集提供真实的应用身份(即，应用名称、应用版本、应用流量类型等)，服务引擎可以基于这些身份执行其服务。

而且，在一些实施例中，威胁检测模块与上下文引擎一起在主机计算机上执行。一旦上下文引擎获得指定处理已在机器上起动或正在机器上发送数据消息的处理参数集，在一些实施例中，上下文引擎就向威胁检测模块提供一个或多个处理参数(例如，处理散列、应用名称、应用版本、AppID、其它处理参数等)。然后，这个威胁检测模块为识别出的处理生成威胁级别指示符(例如，低、中、高等)，并将这个威胁级别指示符提供给上下文引擎。然后，上下文引擎将这个威胁级别指示符提供给一个或多个服务引擎，作为用于对新处理事件或新网络事件的数据消息执行服务的另一个上下文属性；服务引擎可以使用威胁级别指示符作为另一个属性来识别要强制执行的服务规则。

在一些实施例中，上下文引擎使用推送模型将收集的上下文属性分发给服务引擎，而在其它实施例中它使用拉取模型将这些属性分发给服务引擎。在还有其它实施例中，内容引擎针对一些服务引擎采用推送模型并针对其它服务引擎采用拉取模型。在推送模型中，上下文引擎向服务引擎分发其针对处理事件或网络事件收集的上下文属性，其具有处理的标识符和/或网络事件的流标识符(例如，流的五元组标识符)。在一些实施例中，上下文引擎仅向服务引擎分发与那个服务引擎的服务规则相关的上下文属性。

在拉取模型中，上下文引擎从服务引擎接收针对上下文引擎已针对特定处理或网络连接收集的上下文属性的查询。在一些实施例中，上下文引擎利用来自服务引擎的查询接收处理ID或流标识符(例如，五元组标识符)，并使用接收到的标识符来识别它必须提供给服务引擎的属性集。在一些实施例中，上下文引擎为与服务引擎相关的属性集生成服务令牌(也称为服务标签)，并将这个服务令牌提供给另一个模块(例如，GI代理或主机上的另一个模块)，以传递给服务引擎(例如，在数据消息的封装报头中传递)。然后，服务引擎提取服务令牌并将这个服务令牌提供给上下文引擎，以便识别上下文引擎必须向服务引擎提供的上下文属性。

在一些实施例中，上下文引擎向其主机计算机上的若干基于上下文的服务引擎提供上下文属性。在一些实施例中，上下文引擎和服务引擎都是管理程序的内核空间组件，多个VM或容器在其上执行。在其它实施例中，上下文引擎和/或一个或多个服务引擎是用户空间处理。例如，在一些实施例中，一个或多个服务引擎是服务VM(SVM)。

不同的实施例使用不同类型的基于上下文的服务引擎。例如，在一些实施例中，基于属性的服务引擎包括(1)防火墙引擎，其对由机器发送或为机器接收的数据消息执行基于上下文的防火墙操作，(2)处理控制引擎，对在机器上起动的处理强制执行基于上下文的处理控制操作(例如，处理评估和终止操作)，(3)负载平衡引擎，执行基于上下文的负载平衡操作，以将数据消息流从机器分发到一个或多个目的地/服务节点集群中的不同目的地或服务节点，以及(4)加密引擎，其执行基于上下文的加密或解密操作以加密来自机器的数据消息，或者解密为机器接收的数据消息。

在一些实施例中，另一个基于上下文的服务引擎是发现服务引擎。在一些实施例中，发现引擎从上下文引擎捕获新的处理事件和新的网络事件，以及上下文引擎针对这些处理和网络事件收集的上下文属性。然后，发现服务引擎将这些事件及其相关联的上下文属性中继到一个或多个网络管理器(例如，服务器)，这些管理器提供允许网络管理员可视化数据中心中的事件并指定用于数据中心中的计算和网络资源的策略的管理层。

在将这些事件和属性中继到网络管理层时，一些实施例的发现模块执行这些事件和属性的某种预处理。例如，在一些实施例中，发现模块过滤其中一些网络或处理事件，同时聚合这些事件及其属性中的一些或全部。而且，在一些实施例中，发现引擎指示上下文引擎通过GI代理或其它模块(例如，DPI引擎或威胁检测引擎)收集用于处理或网络事件的附加上下文属性，或捕获其它类型的事件(诸如文件事件和系统事件)。

例如，在一些实施例中，发现引擎指示上下文引擎构建安装在机器上的应用的库存，并定期刷新该库存。发现引擎可能根据管理平面的请求或者基于管理或控制平面为发现引擎指定的操作配置来指示上下文引擎。响应于来自发现引擎的请求，在一些实施例中，上下文引擎使其每个主机的机器上的每个GI代理发现机器上的所有已安装的处理，以及所有正在运行的处理和服务。

在构建已安装的应用和正在运行的处理/服务的库存之后，数据中心中的主机计算机的发现引擎将这个信息提供给管理平面中的网络/计算管理器。在一些实施例中，管理平面从除主机计算机发现和上下文引擎之外的源收集上下文属性。例如，在一些实施例中，管理平面从一个或多个服务器收集计算上下文(例如，来自云供应商的云上下文，或通过数据中心虚拟化软件计算虚拟化上下文)、来自目录服务服务器的身份上下文、来自移动性管理服务器的移动性上下文、来自DNS(域名服务器)和应用库存服务器的端点上下文，来自网络虚拟化服务器的网络上下文(例如，虚拟网络上下文)等。

通过收集上下文信息(例如，来自发现和上下文引擎的信息和/或来自其它上下文源的信息)，管理平面可以向网络/计算管理员提供用户界面以可视化数据中心中的计算和网络资源。而且，所收集的上下文属性允许管理平面通过这个用户界面提供控制，以便这些管理员指定基于上下文的服务规则和/或策略。然后将这些服务规则/策略分发到主机计算机，使得这些计算机上的服务引擎可以执行基于上下文的服务操作。

前面的发明内容旨在用作对本发明的一些实施例的简要介绍。这并不意味着是对本文档中公开的所有发明性主题的介绍或概述。以下的具体实施方式和在具体实施方式中提及的附图将进一步描述在本发明内容中描述的实施例以及其它实施例。因此，为了理解由本文档描述的所有实施例，需要对发明内容、具体实施方式、附图和权利要求书进行全面审阅。而且，所要求保护的主题不受发明内容、具体实施方式和附图中的说明性细节的限制。

附图说明

本发明的新颖特征在所附权利要求中阐述。但是，为了解释的目的，在以下图中阐述了本发明的若干实施例。

图1图示了使用本发明一些实施例的上下文引擎和基于上下文的服务引擎的主机计算机。

图2图示了主机计算机的更详细示例，在一些实施例中，主机计算机用于建立分布式体系架构，用于在数据中心中配置和执行上下文丰富的基于属性的服务。

图3图示了由一些实施例的上下文引擎执行的处理。

图4图示了一些实施例的负载平衡规则的示例。

图5图示了一些实施例的在若干应用服务器之间分发web服务器流量的负载平衡器。

图6图示了在一些实施例中负载平衡器执行的处理。

图7图示了这种防火墙规则的若干示例。

图8图示了一些实施例的基于上下文的防火墙规则的若干更详细示例。

图9-12呈现了各种示例，其图示了防火墙引擎对各种基于上下文的防火墙规则的强制执行。

图13图示了每当从GI代理接收到新的网络连接事件时上下文引擎执行以收集用户和组标识符的处理。

图14图示了在一些实施例中防火墙引擎执行的处理。

图15图示了这种基于上下文的加密规则的示例。

图16图示了一些实施例的加密器执行以加密由主机上的VM发送的数据消息的处理。

图17图示了加密引擎执行以解密转发元件端口在执行数据消息的目的地VM的目的地主机上接收的加密数据消息的处理。

图18图示了加密引擎执行以解密包括其报头中的密钥标识符的加密数据消息的处理。

图19图示了处理控制规则的若干示例。

图20图示了在一些实施例中处理控制引擎执行的处理。

图21图示了在一些实施例中如何管理服务引擎的示例。

图22概念性地图示了用于实现本发明的一些实施例的计算机系统。

具体实施方式

在本发明的以下详细描述中，阐述和描述了本发明的许多细节、示例和实施例。但是，对于本领域技术人员将清楚和显而易见的是，本发明不限于所阐述的实施例，并且本发明可以在没有所讨论的一些具体细节和示例的情况下实践。

本发明的一些实施例提供了一种新颖的体系架构，用于捕获执行一个或多个机器的主机计算机上的上下文属性，以及用于消耗所捕获的上下文属性以在主机计算机上执行服务。一些实施例在需要从其捕获上下文属性的每台机器上执行客户内省(GI)代理。除了在每个主机计算机上执行一个或多个机器之外，这些实施例还在每个主机计算机上执行上下文引擎和一个或多个基于属性的服务引擎。通过主机上的机器的GI代理，在一些实施例中，那个主机的上下文引擎收集与网络事件和/或机器上的处理事件相关联的上下文属性。上下文引擎然后向服务引擎提供上下文属性，服务引擎进而使用这些上下文属性来识别服务规则，这些服务规则指定要对在机器上执行的处理和/或由机器发送或为机器接收的数据消息流执行的基于上下文的服务。

如在本文档中所使用的，数据消息是指跨网络发送的特定格式的位集合。本领域普通技术人员将认识到的是，术语“数据消息”可以在本文中用于指可以跨网络发送的各种格式化的位集合，诸如以太网帧、IP分组、TCP片段、UDP数据报等。而且，如本文档中所使用的，对L2、L3、L4和L7层(或第2层、第3层、第4层、第7层)的引用分别是对OSI(开放系统互连)层模型的第二数据链路层、第三网络层、第四传输层和第七应用层的引用。

图1图示了使用本发明一些实施例的上下文引擎和基于上下文的服务引擎的主机计算机100。如图所示，主机计算机100包括若干数据计算节点105、上下文引擎110、若干基于上下文的服务引擎130、威胁检测器132和深度分组检查(DPI)模块135。基于上下文的服务引擎包括发现引擎120、处理控制引擎122、加密引擎124、负载平衡器126和防火墙引擎128。它还包括基于上下文的服务规则存储装置140和属性存储装置145。

DCN是在主机计算机100上执行的端点机器。在一些实施例中，DCN是虚拟机(VM)，在其它实施例中是容器，或者在其它实施例中是VM和容器的混合。在每个DCN上，GI代理150执行以便收集上下文引擎110的上下文属性。在一些实施例中，上下文引擎110通过各种不同方式从其主机上的DCN的GI代理150收集上下文属性。例如，在一些实施例中，DCN上的GI代理向DCN的操作系统中的一个或多个模块(例如，内核空间模块或用户空间模块)注册钩子(例如，回调)以用于所有新的网络连接事件和所有新的处理事件。

在发生新的网络连接事件后，GI代理150从其DCN的OS接收回调，并且基于这种回调，向上下文引擎110提供网络事件标识符。网络事件标识符提供与网络事件有关的属性集。在一些实施例中，这些网络事件属性包括所请求的网络连接的五元组标识符(即，源端口和IP地址、目的地端口和IP地址及协议)、请求网络连接的处理的处理标识符、与发出请求的处理相关联的用户标识符，以及与发出请求的处理相关联的组标识符(例如，活动目录(AD)标识符)。

在一些实施例中，上下文引擎指示GI代理150从OS模块收集与其随网络事件接收的处理标识符(ID)相关联的附加处理参数。在一些实施例中，这些附加的处理参数包括处理名称、处理散列、具有命令行参数的处理路径、处理网络连接、处理加载的模块，以及指定处理对机器的一个或多个资源的消耗(例如，中央处理单元消耗、网络消耗和存储器消耗)的一个或多个处理消耗参数。代替使用处理标识符来向GI代理150查询与网络事件相关联的附加处理参数，其它实施例中的上下文引擎110在GI代理向上下文引擎报告网络事件时一次性接收与网络事件相关联的所有处理参数。

在一些实施例中，DCN的OS保持新的网络事件(即，不开始发送针对网络事件的数据消息)，直到那个DCN上的GI代理150指示它继续处理网络事件。在这些实施例的一些中，GI代理150仅允许OS在上下文引擎110已经收集了这个事件的所有所需属性之后(例如，在从上下文引擎接收到指定它已接收到它针对新网络事件所需的所有处理或网络属性的消息之后)继续处理网络事件。

在一些实施例中，上下文引擎110使用其从GI代理150接收的处理散列来识别该处理所属的应用(即，软件产品)的名称和版本。为此，在一些实施例中，上下文引擎110存储处理散列和相关联的应用名称/版本，将其从GI代理接收的处理散列与存储的处理散列进行比较以识别匹配的散列，然后使用匹配散列的应用名称/版本作为与事件相关联的处理的应用名称和版本。

在一些实施例中，上下文引擎110从一个或多个网络或计算管理器获得处理散列和应用名称/版本，其可以在另一个设备或计算机上操作。在其它实施例中，上下文引擎将与处理标识符相关联的散列提供给网络或计算管理器，然后网络或计算管理器将这个散列与其处理散列记录进行匹配，并将相关联的处理的应用名称/版本提供给上下文引擎。一旦上下文引擎110获得与网络事件关联的应用名称/版本，它就可以向基于属性的服务引擎提供名称和版本属性，这些服务引擎可以使用这个信息(即，应用名称和/或版本)来识别要强制执行的服务规则。

在DCN 105上发生处理事件后，在一些实施例中，DCN的GI代理150从DCN的OS接收回调，并基于这个回调向上下文引擎110提供处理事件标识符。处理事件标识符提供与处理事件有关的属性集。在一些实施例中，该属性集包括处理标识符。在一些实施例中，这个集合还包括用户标识符和/或组标识符(例如，活动目录(AD)标识符)。

在一些实施例中，GI代理在向上下文引擎报告处理事件时向上下文引擎提供与处理事件相关联的所有处理参数(例如，处理标识符、用户ID、组ID、处理名称、处理散列、加载的模块标识符、消耗参数等)。在其它实施例中，上下文引擎指示GI代理从OS模块收集与上下文引擎随处理事件接收的处理标识符相关联的附加处理参数。在一些实施例中，这些附加的处理参数与上面针对报告的网络事件提到的处理参数相同(例如，处理名称、处理散列、加载的模块标识符、消耗参数等)。

一些实施例的上下文引擎110利用其从在主机上执行的其它模块接收的上下文属性来增强其从GI代理150接收的上下文属性。DPI模块135(也称为深度分组检测器)和威胁检测器132(也称为威胁检查模块)是两个这样的模块，其提供上下文属性以增强上下文引擎从GI代理150收集的那些。在一些实施例中，DPI模块由上下文引擎110或另一个模块(例如，防火墙引擎128)引导以检查与处理ID相关联的数据消息流的数据消息，以识别由与处理ID相关联的应用在这些数据中发送的流量的类型。

识别出的流量类型身份如今通常被称为AppID。而且，当前存在多个DPI模块，其分析数据消息流的消息以生成数据消息流的AppID。在一些实施例中，上下文引擎将其为网络事件获得的AppID与其为这个事件识别出的其它上下文属性组合，以便产生服务引擎随后可以用于执行其服务的非常丰富的属性集。这个丰富的属性集提供真实的应用身份(即，应用名称、应用版本、应用流量类型等)，服务引擎可以基于这些应用身份执行其服务。在一些实施例中，上下文引擎110使用网络事件的五元组标识符来将这个事件的数据消息流的AppID与上下文引擎从与数据消息流相关联的DCN(例如，数据消息流从其发出的DCN)的GI代理收集的上下文属性相关联。

威胁检测器132提供威胁级别指示符，其指定与在DCN上执行的特定应用相关联的威胁级别。一旦上下文引擎获得指定处理已在机器上起动或正在机器上发送数据消息的处理参数集合，在一些实施例中，上下文引擎就向威胁检测模块提供一个或多个处理参数(例如，处理散列、应用名称、应用版本、AppID、其它处理参数等)。

然后，这个威胁检测模块为识别出的处理生成威胁级别指示符(例如，低、中、高等)，并将这个威胁级别指示符提供给上下文引擎。在一些实施例中，威胁检测器基于各种应用行为因素向在DCN上运行的应用指派威胁得分，所述因素诸如(1)它是否进行差的输入验证，(2)它是否通过未加密的网络链路传递认证凭证，(3)它是否使用弱的密码和账户策略，(4)它是否以明文形式存储配置机密，(5)它是否可以传送文件，(6)是否知道应用传播恶意软件，(7)是否应用故意逃避，(8)应用是否具有已知的漏洞，等等。在一些实施例中，威胁检测器是第三方白名单应用，诸如Bit9。

在一些实施例中，上下文引擎将威胁检测器132产生的威胁级别指示符提供给一个或多个服务引擎，作为用于对新处理事件或新网络事件的数据消息执行服务的另一个上下文属性；服务引擎可以使用威胁级别指示符作为另一个属性来识别要强制执行的服务规则。

上下文引擎110存储它为属性存储装置145中的网络事件和处理事件收集的上下文属性。在一些实施例中，上下文引擎将每个上下文属性集与一个或多个网络事件标识符和/或处理标识符一起存储。例如，在一些实施例中，上下文引擎110为具有处理标识符或对这个标识符的引用的新处理事件存储所收集的上下文属性。然后，上下文引擎使用处理标识符将收集的上下文属性提供给执行针对处理事件的服务的服务引擎(例如，处理控制引擎122)。

在一些实施例中，上下文引擎为具有网络连接事件的五元组标识符或具有对这个五元组标识符的引用的新网络连接事件存储所收集的上下文属性。在这些实施例的一些中，上下文引擎向服务引擎提供针对网络事件的上下文属性以及这个事件的五元组标识符。针对这个网络事件的数据消息将使用这个五元组标识符，因此服务引擎可以使用提供的五元组标识符来识别与数据消息流相关联的上下文属性。

在一些实施例中，上下文引擎使用推送模型将收集的上下文属性分发给服务引擎130，而在其它实施例中该引擎使用拉取模型将这些属性分发给服务引擎130。在还有其它实施例中，内容引擎针对一些服务引擎采用推送模型并针对其它服务引擎采用拉取模型。在推送模型中，上下文引擎向服务引擎分发其针对处理事件或网络事件收集的上下文属性以及处理的标识符和/或网络事件的流标识符(例如，流的五元组标识符)。

在一些实施例中，上下文引擎仅向服务引擎分发与那个服务引擎的服务规则相关的上下文属性。换句话说，在这些实施例中，上下文引擎将所收集的属性集(例如，用于网络事件或处理事件)中的每个收集的属性与服务引擎的服务规则所使用的属性列表进行比较，并丢弃服务规则未使用的每个收集的属性。然后，上下文引擎仅向服务引擎提供引擎的服务规则正在使用的收集属性的子集(在所收集的属性集中)。在其它实施例中，服务引擎执行这个过滤操作以丢弃不需要的上下文属性。

在拉取模型中，上下文引擎从服务引擎接收针对上下文引擎已针对特定处理或网络连接收集的上下文属性的查询。在一些实施例中，上下文引擎利用来自服务引擎的查询接收处理ID或流标识符(例如，五元组标识符)，并使用接收到的标识符来识别它必须提供给服务引擎的属性集。

在一些实施例中，上下文引擎为与服务引擎相关的属性集生成服务令牌(也称为服务标签)，并将这个服务令牌提供给另一个模块(例如，GI代理或主机上的另一个模块)，以传递给服务引擎(例如，在数据消息的封装报头中传递)。然后，服务引擎提取服务令牌并将这个服务令牌提供给上下文引擎，以便识别上下文引擎必须向服务引擎提供的上下文属性。

在一些实施例中，上下文引擎110和服务引擎130全部是管理程序的内核空间组件，多个VM或容器在其上执行，如下面参考图2进一步描述的。在其它实施例中，上下文引擎和/或一个或多个服务引擎是用户空间处理。例如，在一些实施例中，一个或多个服务引擎是服务VM(SVM)。在一些实施例中，一个或多个服务引擎位于DCN的入口数据路径和/或出口数据路径中，以便接收对去往和来自DCN的数据消息流的访问，以对这些数据消息流执行服务。在其它实施例中，主机100上的一个或多个其它模块拦截来自入口/出口数据路径的数据消息，并将这些消息转发到一个或多个服务引擎，以便这些引擎对数据消息执行服务。下面将参考图2描述一种这样的方法。

不同的实施例使用不同类型的基于上下文的服务引擎。在图1所示的示例中，服务引擎130包括发现引擎120、处理控制引擎122、加密引擎124、负载平衡器126和防火墙引擎128。这些服务引擎130中的每一个都具有基于属性的服务规则存储装置。图1共同表示具有基于上下文的服务规则存储装置140的这些服务引擎的所有基于上下文的服务规则存储装置，以便简化在这个图中呈现的图示。

在一些实施例中，基于上下文的服务规则存储装置140中的每个服务规则具有用于与处理或流标识符匹配的规则标识符，以识别针对处理或网络事件强制执行的规则。在一些实施例中，基于上下文的服务规则存储装置140以分层方式定义，以确保规则检查在匹配较低优先级规则之前将匹配较高优先级规则。而且，在一些实施例中，基于上下文的服务规则存储装置140包含指定用于任何规则检查的默认动作的默认规则，如下面进一步解释的。

防火墙引擎128对由DCN 105发送或为DCN 105接收的数据消息执行防火墙操作。这些防火墙操作基于基于上下文的服务规则存储装置140中的防火墙规则。其中一些防火墙规则纯粹根据层2-层4属性来定义，例如，根据五元组标识符。其它防火墙规则是根据上下文属性定义的，上下文属性可以包括一个或多个收集的上下文属性，诸如应用名称、应用版本、AppID、资源消耗、威胁级别、用户ID、组ID等。在一些实施例中，还有其它防火墙规则根据L2-L4参数和上下文属性二者来定义。由于防火墙引擎128可以解析通过参考上下文属性定义的防火墙规则，因此这个防火墙引擎被称为基于上下文的防火墙引擎。

在一些实施例中，基于上下文的防火墙引擎128可以基于任何数量的上下文属性来允许、阻止或重新路由数据消息流，因为其防火墙规则可以根据所收集的上下文属性的任意组合来识别。例如，当用户是护士用户组的一部分、当一个防火墙规则指定当流与护士组ID相关联时应当阻止数据消息，AppID将流量类型识别为电子邮件，并且应用名称为Chrome时，这个防火墙引擎可以阻止来自chrome.exe的所有电子邮件流量。类似地，基于上下文的防火墙规则可以阻止与视频会议、在线视频查看或使用旧版本软件相关联的数据消息流。此类规则的示例将阻止所有Skype流量、阻止所有YouTube视频流量、当应用版本号早于特定版本号时阻止所有HipChat音频/视频会议、阻止针对任何具有高威胁得分的应用的数据消息流，等等。

负载平衡引擎126对由DCN 105发送的数据消息执行负载平衡操作，以将数据消息流分发到一个或多个目的地/服务节点集群中的不同目的地或服务节点。这些负载平衡操作基于基于上下文的服务规则存储装置140中的负载平衡规则。在这些实施例的一些中，每个负载平衡规则可以指定针对分发流量的一个或多个负载平衡标准(例如，循环标准、加权循环标准等)，并且每个标准可以限于特定的时间范围。在一些实施例中，负载平衡操作涉及用另一个目的地网络地址替换数据消息流的目的地网络地址(例如，目的地IP地址、目的地MAC地址等)。

其中一些负载平衡规则纯粹根据L2-L4属性来定义，例如，根据五元组标识符。其它负载平衡规则根据上下文属性定义，上下文属性可以包括一个或多个收集的上下文属性，诸如应用名称、应用版本、AppID、资源消耗、威胁级别、用户ID、组ID等。在一些实施例中，还有其它负载平衡规则根据L2-L4参数和上下文属性二者来定义。由于负载平衡引擎126可以解析通过参考上下文属性定义的负载平衡规则，因此这个负载平衡引擎被称为基于上下文的负载平衡器。

在一些实施例中，基于上下文的负载平衡器126可以基于任何数量的上下文属性来分发数据消息流，因为其负载平衡规则可以根据所收集的上下文属性的任意组合来识别。例如，负载平衡器126的数据分发可以基于用户和应用数据的任意组合。此类负载平衡操作的示例包括：(1)在所有负载平衡池上分发与财务部门相关联的数据消息流，(2)当用于这个部门的主池减少时，将所有财务部门的流量重定向到另一个池以使该部门的流量高度可用，以及(3)使与医生的用户组相关联的所有流量高度可用。在一些实施例中，还可以根据收集的资源消耗来定义负载平衡规则，以便分发流量以向DCN上消耗大量资源的应用提供更多或更少的资源。

加密引擎124对由DCN 105发送或为DCN 105接收的数据消息执行加密/解密操作(统称为加密操作)。这些加密操作基于基于上下文的服务规则存储装置140中的加密规则。在一些实施例中，这些规则中的每一个包括加密/解密密钥标识符，加密引擎可以使用该标识符从主机上的或在主机外部操作的密钥管理器检索加密/解密密钥。在一些实施例中，每个加密规则还指定加密模块必须执行的加密/解密操作的类型。

每个加密规则还具有规则标识符。对于一些加密规则，规则标识符纯粹根据L2-L4属性来定义，例如，根据五元组标识符。其它加密规则是根据上下文属性定义的，上下文属性可以包括一个或多个收集的上下文属性，诸如应用名称、应用版本、AppID、资源消耗、威胁级别、用户ID、组ID等。在一些实施例中，还有其它加密规则根据L2-L4参数和上下文属性二者来定义。由于加密引擎124可以解析通过参考上下文属性定义的加密规则，因此这个加密引擎被称为基于上下文的加密引擎。

在一些实施例中，基于上下文的加密模块124可以基于任何数量的上下文属性来加密或解密数据消息流，因为其加密规则可以根据所收集的上下文属性的任意组合来识别。例如，加密引擎124的加密/解密操作可以基于用户和应用数据的任意组合。此类加密操作的示例包括：(1)加密从Outlook(在任何计算机上起动)到Exchange Server的所有流量，(2)加密三层Web服务器、应用服务器和数据库服务器中的应用之间的所有通信，(3)加密所有源自管理员Active Directory组的流量，等等。

处理控制引擎122对在DCN 105上起动的处理强制执行基于上下文的处理控制操作(例如，处理评估和终止操作)。在一些实施例中，每当上下文引擎110从DCN的GI代理150接收到新的处理事件时，它就将与这个处理事件相关联的处理参数提供给处理控制引擎122。然后，这个引擎使用接收到的处理参数集来检查其基于上下文的服务规则存储装置140，以识别匹配的基于上下文的处理控制规则。

处理控制引擎122可以指示上下文引擎指示DCN的GI代理以对处理执行处理控制操作。这种处理控制操作的示例包括(1)终止具有特定版本号的视频会议应用，(2)终止显示YouTube流量的浏览器，以及(3)终止具有高威胁级别得分的应用。

发现引擎120是另一个基于上下文的服务引擎。在一些实施例中，发现引擎120从上下文引擎捕获新的处理事件和新的网络事件，以及上下文引擎针对这些处理和网络事件收集的上下文属性。如下面进一步描述的，发现服务引擎然后将这些事件及其相关联的上下文属性中继到一个或多个网络管理器(例如，服务器)，其中网络管理器提供允许网络管理员可视化数据中心中的事件并指定用于数据中心中的计算和网络资源的策略的管理层。

在将这些事件和属性中继到网络管理层时，一些实施例的发现模块执行这些事件和属性的某种预处理。例如，在一些实施例中，发现模块过滤其中一些网络或处理事件，同时聚合这些事件及其属性中的一些或全部。而且，在一些实施例中，发现引擎120指示上下文引擎110通过GI代理150或其它模块(例如，DPI引擎或威胁检测引擎)收集处理或网络事件的附加上下文属性，或捕获其它类型事件，诸如文件事件和系统事件。

例如，在一些实施例中，发现引擎指示上下文引擎构建安装在机器上的应用的库存，并定期刷新该库存。发现引擎可能根据管理平面的请求或者基于管理或控制平面为发现引擎指定的操作配置来指示上下文引擎。响应于来自发现引擎的请求，在一些实施例中，上下文引擎使其主机的每个机器上的每个GI代理发现机器上的所有已安装的处理，以及所有正在运行的处理和服务。

在构建已安装的应用和正在运行的处理/服务的库存之后，数据中心中的主机计算机的发现引擎将这个信息提供给管理平面中的网络/计算管理器。在一些实施例中，管理平面从除主机计算机发现和上下文引擎之外的源收集上下文属性。例如，在一些实施例中，管理平面从一个或多个服务器收集计算上下文(例如，来自云供应商的云上下文，或通过数据中心虚拟化软件计算虚拟化上下文)、来自目录服务服务器的身份上下文、来自移动性管理服务器的移动性上下文、来自DNS(域名服务器)和应用库存服务器的端点上下文、网络上下文(例如，来自网络虚拟化服务器的虚拟网络上下文)等。

通过收集上下文信息(例如，来自发现和上下文引擎的信息和/或来自其它上下文源的信息)，管理平面可以向网络/计算管理员提供用户界面以可视化数据中心中的计算和网络资源。而且，所收集的上下文属性允许管理平面通过这个用户界面提供控制，以便这些管理员指定基于上下文的服务规则和/或策略。然后将这些服务规则/策略分发到主机计算机，使得这些计算机上的服务引擎可以执行基于上下文的服务操作。

在上述一些实施例中，相同的服务引擎130(例如，相同的防火墙引擎128)基于可以根据消息流标识符(例如，五元组标识符)或者根据与数据消息流相关联的收集的上下文属性(例如，AppID、威胁级别、用户标识符、组标识符、应用名称/版本等)定义的服务规则来执行相同类型的服务(例如，防火墙服务)。但是，在其它实施例中，不同的服务引擎基于消息流标识符(例如，五元组标识符)并基于所收集的数据消息流的上下文属性来提供相同类型的服务。例如，一些实施例使用一个基于流的防火墙引擎，其基于根据流标识符定义的规则来执行防火墙操作，以及另一个基于上下文的防火墙引擎，其基于根据上下文属性(例如，AppID、威胁级别、用户标识符、组标识符、应用名称/版本等)定义的规则来执行防火墙操作)。

图2图示了主机计算机200的更详细示例，在一些实施例中，主机计算机200用于建立分布式体系架构，用于在数据中心中配置和执行上下文丰富的基于属性的服务。这个主机计算机200包括许多与主机计算机100相同的组件，诸如上下文引擎110、服务引擎130、威胁检测器132、DPI模块135、基于上下文的服务规则存储装置140和上下文属性存储装置145。与图1中一样，图2中的服务引擎130包括发现引擎120、处理控制引擎122、加密引擎124、负载平衡器126和防火墙引擎128。

在图2中，DCN是在管理程序上执行的VM 205。而且，在图2中，主机计算机200包括软件转发元件210、属性映射存储装置223、连接状态高速缓存存储装置225、MUX(多路复用器)227和上下文引擎策略存储装置143。在一些实施例中，上下文引擎110、软件转发元件210、服务引擎130、基于上下文的服务规则存储装置140、连接状态高速缓存存储装置225、上下文引擎策略存储装置143和MUX 227在管理程序的内核空间中操作，而VM 205在管理程序的用户空间中操作。在其它实施例中，一个或多个服务引擎是用户空间模块(例如，是服务VM)。

在一些实施例中，VM 205用作数据中心中的数据端点。这种机器的示例包括web服务器、应用服务器、数据库服务器等。在一些情况下，所有VM属于一个实体，例如，操作主机的企业。在其它情况下，主机200在多租户环境中(例如，在多租户数据中心中)操作，并且不同的VM 205可以属于一个租户或多个租户。

每个VM 205包括GI代理250，其与上下文引擎110交互以向这个引擎提供上下文属性集，并从这个引擎接收指令和查询。GI代理250和上下文引擎110之间的交互类似于上面描述的GI代理150和上下文引擎110之间的交互。但是，如图2中所示，在一些实施例中，上下文引擎110和GI代理250之间的所有通信都通过MUX 227中继。此类多路复用器的一个示例是VMware公司的ESX管理程序的端点安全(EPSec)平台使用的多路复用器。

在一些实施例中，GI代理通过快速通信信道(诸如ESX的VMCI信道)与MUX 227通信。在一些实施例中，这个通信信道是共享存储器信道。如上面所提到的，在一些实施例中由上下文引擎110从GI代理250收集的属性包括丰富参数组(例如，层7参数、处理标识符、用户标识符、组标识符、处理名称、处理散列、加载的模块标识符、消耗参数等)。

如图所示，在一些实施例中，每个VM 205还包括虚拟网络接口卡(VNIC)255。每个VNIC负责在其VM和软件转发单元(SFE)210之间交换消息。每个VNIC连接到SFE 210的特定端口260。SFE 210还连接到主机的物理网络接口卡(NIC)(未示出)。在一些实施例中，VNIC是由主机的一个或多个物理NIC(PNIC)的管理程序创建的软件抽象。

在一些实施例中，SFE 210为每个VM的每个VNIC维护单个端口260。SFE 210连接到主机PNIC(通过NIC驱动器(未示出))以发送传出消息并接收传入消息。在一些实施例中，SFE 210被定义为包括端口265，端口265连接到PNIC的驱动器以向PNIC发送消息和从PNIC接收消息。SFE 210执行消息处理操作以将其在其一个端口上接收的消息转发到其另一个端口。例如，在一些实施例中，SFE尝试使用消息中的数据(例如，消息报头中的数据)来将消息与基于流的规则匹配，并且在找到匹配后，执行由匹配规则指定的动作(例如，将消息传递到其端口260或265之一，其指示消息被提供给目的地VM或PNIC)。

在一些实施例中，SFE 210是软件交换机，而在其它实施例中，它是软件路由器或组合的软件交换机/路由器。在一些实施例中，SFE 210实现一个或多个逻辑转发元件(例如，逻辑交换机或逻辑路由器)，其中SFE在多主机环境中的其它主机上执行。在一些实施例中，逻辑转发元件可以跨越多个主机以连接在不同主机上执行但属于一个逻辑网络的VM。

可以定义不同的逻辑转发元件以为不同的用户指定不同的逻辑网络，并且每个逻辑转发元件可以由多个主机上的多个软件转发元件来定义。每个逻辑转发元件将一个逻辑网络的VM的流量与另一个逻辑转发元件服务的另一个逻辑网络的VM隔离。逻辑转发元件可以连接在同一主机和/或不同主机上执行的VM。在一些实施例中，SFE从数据消息中提取逻辑网络标识符(例如，VNI)和MAC地址。这些实施例中的SFE使用提取的VNI来识别逻辑端口组，然后使用MAC地址来识别端口组内的端口。

软件交换机(例如，管理程序的软件交换机)有时被称为虚拟交换机，因为它们在软件中操作并且它们向VM提供对主机的(一个或多个)PNIC的共享访问。但是，在本文档中，软件交换机被称为物理交换机，因为它们是物理世界中的物品。这个术语还将软件交换机与逻辑交换机区分开来，逻辑交换机是由软件交换机提供的连接类型的抽象。存在用于从软件交换机创建逻辑交换机的各种机制。VXLAN提供了一种创建此类逻辑交换机的方式。VXLAN标准在Mahalingam，Mallik；Dutt，Dinesh G.；等人的(2013-05-08)VXLAN：AFramework for Overlaying Virthalized Layer 2Networks over Layer 3Networks，IETF中描述。

在一些实施例中，SFE 210的端口包括对一个或多个模块的一个或多个功能调用，这些模块对在端口处接收的传入和传出消息实现特殊输入/输出(I/O)操作。由端口260实现的I/O操作的示例包括ARP广播抑制操作和DHCP广播抑制操作，如美国专利9,548,965中所述。在本发明的一些实施例中，可以如此实现其它I/O操作(诸如防火墙操作、负载平衡操作、网络地址翻译操作等)。通过实现这种功能调用的堆栈，在一些实施例中，端口可以对传入和/或传出的消息实现一系列I/O操作。而且，在一些实施例中，数据路径中的其它模块(诸如VNIC 255、端口265等)代替端口260或与其结合来实现I/O功能调用操作。

在一些实施例中，SFE端口260的一个或多个功能调用可以是一个或多个服务引擎130，其处理基于上下文的服务规则存储装置140中的基于上下文的服务规则。在一些实施例中，每个服务引擎130具有其自己的基于上下文的服务规则存储装置140、属性映射存储装置223和连接状态高速缓存存储装置225。图2仅呈现了用于所有服务引擎的一个基于上下文的服务规则存储装置140、属性映射存储装置223和连接状态缓存存储装置225，以便不用不必要的细节模糊这个图中的表示。而且，在一些实施例中，每个VM具有其自己的每个服务引擎130的实例(例如，其自己的发现引擎120、处理控制引擎122、加密引擎124、负载平衡器126和防火墙引擎128的实例)。在其它实施例中，一个服务引擎可以服务于针对主机上的多个VM(例如，用于相同逻辑网络的VM)的数据消息流。

为了执行其对数据消息流的服务操作，在一些实施例中，服务引擎130尝试将流标识符(例如，五元组标识符)和/或流的相关联的上下文属性集匹配到在其基于上下文的服务规则存储装置140中的其服务规则的规则标识符。具体而言，为了让服务引擎130对数据消息流执行其服务检查操作，调用服务引擎的SFE端口260供应端口接收的消息的属性集。在一些实施例中，该属性集是消息标识符(诸如传统的五元组标识符)。在一些实施例中，标识符值中的一个或多个可以是为逻辑网络定义的逻辑值(例如，可以是在逻辑地址空间中定义的IP地址)。在其它实施例中，所有标识符值都在物理域中定义。在还有其它实施例中，其中一些标识符值在逻辑域中定义，而其它标识符值在物理域中定义。

然后，在一些实施例中，服务引擎使用接收到的消息的属性集(例如，消息的五元组标识符)来识别服务引擎已在属性映射存储装置223中为这个流存储的上下文属性集。如上面所提到的，在一些实施例中，上下文引擎110将用于新流(即，新网络连接事件)和用于新处理的上下文属性连同流标识符(例如，五元组标识符)或处理标识符一起供应给服务引擎130。上下文引擎策略存储装置143包含控制上下文引擎110的操作的规则。在一些实施例中，这些策略指示上下文引擎生成服务引擎的规则或指示服务引擎生成规则(例如，当高威胁应用在VM上运行时，指示加密引擎针对相同主机上的所有其它VM加密他们的数据消息流量)。这些实施例中的服务引擎130将它们从上下文引擎接收的上下文属性存储在属性映射存储装置223中。

在一些实施例中，服务引擎130将具有那个流的标识符(例如，五元组标识符)或那个处理的标识符的每个新流或新处理的上下文属性集存储在属性映射存储装置中。以这种方式，服务引擎可以通过在其属性映射存储装置223中搜索具有匹配的流标识符的上下文记录来识别它从SFE端口260接收的每个新流的上下文属性集。具有匹配的流标识符的上下文记录包括该流的上下文属性集。类似地，为了识别处理事件的上下文属性集，在一些实施例中，服务引擎在其属性映射存储装置223中搜索具有匹配处理标识符的上下文记录。

如上面所提到的，在一些实施例中，一些或全部服务引擎从上下文引擎中拉取新流或新处理的上下文属性集。例如，在一些实施例中，服务引擎将其从SFE端口260接收的新流的五元组标识符供给上下文引擎110。然后，这个引擎110检查其属性存储装置145以识别为这个五元组标识符存储的属性集，然后将这个属性集(或者通过过滤为服务引擎识别出的属性集而获得的该属性集的子集)供给服务引擎。

如上所述，一些实施例通过使用服务令牌来编码用于新消息流的属性集来实现拉取模型。当被通知新的网络连接事件时，在一些实施例中上下文引擎110(1)收集新事件的上下文属性集，(2)过滤这个集合以丢弃与对流执行一个或多个服务无关的属性，(3)将剩余的过滤属性子集与服务令牌一起存储在属性存储装置145中，(4)将服务令牌提供给GI代理250。然后，GI代理250使这个令牌被带内(例如，在代理的VM发送到目的地的数据消息的报头中)或带外(即，与从代理的VM发送到目的地的数据消息分离地)传送到(一个或多个)服务引擎。

当服务引擎通过SFE端口260获得新流时，它将这个流的服务令牌提供给上下文引擎，该上下文引擎使用这个服务令牌在其属性存储装置145中识别要提供给服务引擎的上下文属性。在SFE端口不向服务引擎提供该服务令牌的实施例中，服务引擎首先必须通过在将服务令牌供应给上下文引擎之前使用流的标识符搜索其数据存储来识别服务令牌。

在识别出数据消息流的上下文属性集之后，在一些实施例中，服务引擎130基于存储在基于上下文的服务规则存储装置140中的服务规则来执行其服务操作。为了执行其服务操作，服务引擎130将接收到的属性子集与为服务规则存储的对应属性集进行匹配。在一些实施例中，基于上下文的服务规则存储装置140中的每个服务规则具有规则标识符和动作参数集。

如上面所提到的，在一些实施例中，服务规则的规则标识符可以根据不是L2-L4报头参数的一个或多个上下文属性来定义(例如，是L7参数、处理标识符、用户标识符、组标识符、处理名称、处理散列、加载的模块标识符、消耗参数等)。在一些实施例中，规则标识符还可以包括L2-L4报头参数。而且，在一些实施例中，可以根据个体值或通配符值来指定规则标识符中的一个或多个参数。而且，在一些实施例中，规则标识符可以包括各个体值的集合或组标识符，诸如安全组标识符、计算构造标识符、网络构造标识符等。

为了将接收到的属性集与规则相匹配，服务引擎将接收到的属性集与存储在基于上下文的服务规则存储装置140中的服务规则的关联标识符进行比较。在识别出匹配的规则后，服务引擎130基于匹配规则的动作参数集(例如，基于允许/丢弃参数、负载平衡标准、加密参数等)执行服务操作(例如，防火墙操作、负载平衡操作、加密操作、其它中间盒操作等)。

在一些实施例中，基于上下文的服务规则存储装置140以分层方式定义，以在消息的属性子集匹配多个规则时确保在匹配较低优先级规则之前消息规则检查将匹配较高优先级规则。而且，在一些实施例中，基于上下文的服务规则存储装置140包含默认规则，这个默认规则指定不能识别任何其它服务规则的任何消息规则检查的默认动作；在一些实施例中，这个默认规则将是所有可能的属性子集的匹配，并确保服务规则引擎将返回针对所有接收到的属性子集的动作。在一些实施例中，默认规则将不指定服务。

例如，当消息是与两个机器之间的一个通信会话相关联的一个流的一部分时，多个消息可以具有相同的消息标识符属性集。因而，在基于消息的识别出的上下文属性集将数据消息与在基于上下文的服务规则存储装置140中的服务规则匹配之后，一些实施例的服务引擎将服务规则(或对服务规则的引用)存储在连接状态高速缓存存储装置225中，以便稍后可以将这个服务规则用于同一个流的后续数据消息。

在一些实施例中，连接状态高速缓存存储装置225存储服务引擎130针对不同消息标识符集(例如，用于识别不同数据消息流的不同五元组标识符)识别的服务规则或对服务规则的引用。在一些实施例中，连接状态高速缓存存储装置225存储每个服务规则或对服务规则的引用以及从匹配的消息标识符集生成的标识符(例如，流的五元组标识符和/或流的五元组标识符的散列值)。

在使用基于上下文的服务规则存储装置140检查特定消息之前，一些实施例的服务规则引擎130检查连接状态高速缓存存储装置225以确定这个存储装置是否先前已经为这个消息的流识别出服务规则。如果不是，那么服务引擎130为消息流识别出上下文属性集，然后检查基于上下文的服务规则存储装置140以寻找与消息的识别出的属性集和/或其五元组标识符匹配的服务规则。当连接状态数据存储装置具有特定消息的条目时，服务引擎基于这个服务规则的动作参数集执行其服务操作。

在图2的服务体系架构中，DPI模块135在防火墙引擎128的方向上对数据消息流执行深度分组检查。具体而言，当防火墙引擎128接收到作为新数据消息流的一部分的新数据消息时，在一些实施例中，防火墙引擎指示DPI模块检查该新数据消息和同一个流中接下来的一些数据消息中的一个或多个。基于这种检查，DPI引擎识别在这个数据消息流中发送的流量类型(即，线上的应用)，生成针对这个流量类型的AppID，并将这个AppID存储在属性存储装置145中。在一些实施例中，基于流标识符和/或处理标识符将上下文属性集存储在属性存储装置中。因而，在一些实施例中，DPI引擎135基于那个流的五元组标识符将新数据消息流的AppID存储在属性存储装置145中。

在一些实施例中，一旦DPI引擎将AppID存储在属性存储装置145中，上下文引擎110就向服务引擎130推送用于新数据消息流的AppID。在其它实施例中，每当服务引擎查询数据消息流的上下文属性时，上下文引擎110就从属性存储装置145中拉取AppID。在一些实施例中，上下文引擎110使用流的五元组标识符来识别属性存储装置145中具有匹配的记录标识符和AppID的记录。

图3图示了在每次向其通知新处理或网络连接事件时上下文引擎在一些实施例中执行110的处理300。从VM 205的GI代理250，处理300最初接收(在305处)关于新处理或网络连接事件的通知。接下来，在310处，处理300收集关于所通知的事件的所有期望的上下文属性。

如上所述，在一些实施例中，上下文引擎110与报告GI代理250交互(在310处)以收集关于所报告的事件的附加信息。在一些实施例中，GI代理与VM的OS内核空间中的网络堆栈和/或处理子系统交互，以收集关于处理或网络事件的上下文属性。在一些实施例中，GI代理还从在用户空间处理(例如，VMtool.exe)中操作的用户空间模块(例如，用户模式动态链接库，DLL)收集该信息以收集上下文属性。在使用Microsoft Windows的VM上，在一些实施例中，GI代理在Windows过滤平台(WFP)中注册钩子以获得网络事件，同时在Windows的处理子系统中注册以收集与处理相关的属性。在一些实施例中，GI代理钩子位于WFP的应用层强制执行(ALE)层，使得它可以捕获来自VM上的应用处理的所有套接字连接请求。

在一些实施例中，上下文引擎110与管理或控制平面交互以收集上下文属性，和/或接收其可以检查的记录以识别用于识别出的网络或处理事件的上下文属性。在这些实施例的一些中，上下文引擎与管理或控制平面代理(在其主机上操作)交互，以便从在主机外部操作的管理或控制平面服务器获得数据。在这些实施例的一些中，上下文引擎在内核空间中操作。

在310处收集上下文属性之后，该处理使用(在315处)所接收事件的属性或者为所接收事件收集的上下文属性来识别上下文引擎策略存储装置143中的一个或多个策略。在315处，该处理识别具有与所收集的属性和事件属性匹配的策略标识符的任何策略。

接下来，在320处，该处理基于在315处识别出的策略为一个或多个服务引擎产生上下文属性映射记录。所识别出的策略中的一个或多个可以指定对于特定处理或网络事件，需要向特定服务引擎集通知该事件(例如，与新数据消息流有关)，其中每个服务引擎接收与那个服务引擎相关的上下文属性的子集，以执行用于那个事件的处理。在一些实施例中，这个操作涉及上下文引擎不包括与其提供给那个特定服务引擎的上下文属性的子集中的每个特定服务引擎无关的属性。

在一些实施例中，某些事件可能需要为一个或多个服务引擎创建新的服务规则。例如，当在一个VM上识别出高威胁应用时，策略可能指定那个主机上的其它VM可能必须开始加密其数据消息流量。在一些这样的实施例中，上下文引擎策略存储装置143包括指导上下文引擎在某些情况下为服务引擎生成服务规则或指示服务引擎生成这样的服务规则的策略。对于这样的实施例，如果需要，处理(在320处)在某些情况下为服务引擎生成服务规则，或者指示服务引擎生成这样的服务规则。

在325处，处理300将映射记录和/或生成的服务规则/指令分发到一个或多个服务引擎。如上面所提到的，上下文引擎可以采用推送模型或拉取模型来分发这样的记录和/或规则/指令。当采用拉取模型时，在一些实施例中，处理300不仅响应于来自服务引擎的查询而执行操作325，而且还响应于这个查询而执行操作320中的一些或全部。在325之后，该处理结束。

负载平衡引擎126是基于上下文的负载平衡器，其基于负载平衡规则来执行其负载平衡操作，所述负载平衡规则不仅可以根据L2-L4参数来指定，而且还可以根据上下文属性来指定。图4图示了这种基于上下文的负载平衡规则的示例。这些规则由不同主机500上的不同负载平衡引擎126独立使用，以将来自这些主机上的不同web服务器VM 505的数据消息分发到不同的应用服务器VM 510，如图5中所示。在一些实施例中，主机500类似于主机200，并且web服务器VM 505和应用服务器VM 510类似于图2的VM 205。为了避免用不必要的细节模糊图形，图5中所示的主机500的仅有的组件是负载平衡器126和web服务器VM 505，其中负载平衡器作为服务模块出现在web服务器VM 505的出口路径中。

在图5所示的示例中，负载平衡器126共同形成分布式负载平衡器(即，单个概念逻辑负载平衡器)，其跨越多个主机以在应用服务器VM上均匀地分布web服务器VM流量。如下面进一步描述的，在一些实施例中，用于不同负载平衡器126的负载平衡规则的负载平衡标准是相同的，以确保对web服务器VM流量的统一处理。如由主机500b所示，多个web服务器VM505可以在同一个主机500上执行，这些web服务器VM中的每一个由不同的负载平衡器126服务。在其它实施例中，一个负载平衡器可以服务于同一主机上的多个VM(例如，用于同一主机上的同一租户的多个VM)。而且，在一些实施例中，多个应用服务器VM可以在同一个主机上彼此和/或与web服务器VM一起执行。

在图4-5所示的示例中，负载平衡器126执行目的地网络地址翻译(DNAT)，其将应用服务器的虚拟IP(VIP)地址变换为具体应用VM的IP地址，称为目的地IP地址或DIP。在其它实施例中，DNAT操作可以翻译其它网络地址，例如，它可以翻译MAC地址以实现MAC-重定向。而且，尽管图4-5中的负载平衡器在应用服务器组(集群)的应用服务器之间分发Web服务器流量，但是负载平衡器也可以用于在任何服务/计算节点集群的服务或计算节点之间分发来自一个或多个服务或计算节点的任何集合的流量。

图4图示了存储若干LB规则的负载平衡(LB)规则存储装置140，其中每个LB规则与一个负载平衡的计算或服务集群相关联。每个负载平衡规则包括(1)规则标识符405，(2)负载平衡的节点组的若干节点的若干IP地址410，以及(3)每个IP地址的权重值415。每个规则标识符405指定可以用于识别与数据消息流匹配的规则的一个或多个数据元组。

在一些实施例中，规则标识符可以包括规则的相关联DCN组的VIP地址(诸如图5中的应用服务器组的VIP地址)。如图所示，规则标识符在一些实施例中可以包括任何L2-L4参数(例如，源IP地址，源端口，目的地端口，协议等)。而且，如图所示，用于LB规则的规则标识符可以包括上下文属性，诸如AppID、应用名称、应用版本、用户ID、组ID、威胁级别、资源消耗等。在一些实施例中，通过将一个或多个消息属性(例如，五元组报头值、上下文属性)与规则标识符405进行比较以识别具有匹配规则标识符的最高优先级规则，负载平衡器搜索LB数据存储装置。

每个LB规则的IP地址410是计算或服务节点的IP地址，其是与规则相关联的负载平衡计算或服务组的成员(例如，与规则的标识符405中指定的VIP地址相关联的负载平衡的组的成员)。如下面进一步描述的，在一些实施例中，通过配置负载平衡器的控制器集来供应这些节点的地址。在一些实施例中，负载平衡器将接收到的数据消息的目的地IP地址翻译成IP地址410之一(例如，将包含在数据消息中的VIP翻译成DIP)。

在一些实施例中，负载平衡器基于一个或多个负载平衡标准来执行其负载平衡操作。一些实施例的LB规则包含这样的LB标准，以便在每个规则内指定当消息流匹配那个规则时负载平衡器应当如何在负载平衡组的节点之间扩展流量。在图4所示的示例中，负载平衡标准是加权循环方案，其由每个规则的权重值415定义。具体而言，用于每个LB规则的每个IP地址的权重值415为负载均衡器提供将流量扩展到LB节点组的节点的标准。

例如，图5的应用服务器组具有五个应用服务器。假设用于在这五个应用服务器之间分发web服务器流量的负载平衡规则为五个应用服务器的五个IP地址指定权重值1、3、1、3和2。基于这些值，负载平衡器将按以下次序分发作为十个新流的一部分的数据消息：第一个流到第一IP地址，第二到第四个流到第二IP地址，第五个流到第三IP地址，第六到第八流到第四IP地址，而第九和第十个流到第五IP地址。根据这个方案，下一批新流的指派通过这些IP地址循环(例如，第十一个流将被指派给第一IP地址，依此类推)。

在一些实施例中，用于LB规则的权重值由控制器集基于LB统计数据来生成和调整，其中LB统计数据是负载平衡器(1)关于它们在(一个或多个)LB节点组的节点之间分发的数据消息流收集的并且(2)提供给控制器集。而且，为了在不同的负载平衡标准之间进行平稳切换，在一些实施例中，LB规则为对于不同时间段有效的LB规则的不同负载平衡标准指定时间段。因而，在一些实施例中，负载平衡规则可以指定具有指定何时每个地址集有效的不同时间值的多个不同目的地网络地址集。在一些实施例中，这些集合中的每一个可以包括其自己的一个LB标准集(例如，其自己的权重值集)。

图6图示了在一些实施例中负载平衡器126执行的处理600。如图所示，当负载平衡器从其对应的SFE端口260接收(在605处)数据消息时，处理600开始。这个端口在从其VM或为其VM接收到数据消息时中继这个消息。在一些实施例中，端口通过向负载平衡器传递对数据消息或数据消息的报头值的引用(例如，识别存储器中存储数据消息的位置的句柄)来中继数据消息。

该处理确定(在610处)连接状态高速缓存225是否存储识别数据消息应当被转发到的目的地的记录。如上面所提到的，每次负载平衡器使用LB规则将新数据消息流指引到负载平衡节点组的节点时，在一些实施例中，负载均衡器在连接状态高速缓存225中创建记录以存储所选择节点的物理IP地址，以便当负载平衡器接收到同一个流中的另一个数据消息(即，具有相同的五元组标识符)时，它可以将其转发到它用于同一个流中先前的数据消息的同一个节点。连接状态高速缓存225的使用允许负载平衡器126更快地处理数据消息流。在一些实施例中，连接状态高速缓存225中的每个高速缓存记录具有根据数据消息标识符(例如，五元组标识符)定义的记录标识符。在这些实施例中，该处理将接收到的数据消息的标识符(例如，五元组标识符)与高速缓存的记录的记录标识符进行比较，以识别具有与接收到的数据消息的标识符匹配的记录标识符的任何记录。

当处理600在连接状态高速缓存225中识别出(在610处)用于接收到的数据消息的流的记录时，处理(在615处)然后用存储在连接状态高速缓存225中的记录中的目的地地址(例如，DIP)代替消息的目的地地址(例如，VIP地址)。在615处，该处理沿着其数据路径发送经地址翻译的数据消息。在一些实施例中，这个操作需要将通信返回到SFE端口260(其称为负载平衡器以发起处理600)以指示负载平衡器完成其对VM数据消息的处理。然后，SFE端口260可以将数据消息移交到SFE，或者可以调用I/O链操作符中的另一个服务引擎以对数据消息执行另一个服务操作。在615处，处理600还在一些实施例中更新其维护的关于其数据消息流处理的统计数据。在615之后，处理600结束。

当处理600确定(在610处)连接状态高速缓存225没有存储用于接收到的数据消息的流的记录时，处理600识别出(在620处)这个数据消息流的一个或多个上下文属性。如上面所提到的，不同实施例的服务引擎以不同方式执行这个操作。例如，在一些实施例中，负载平衡器126检查属性映射存储装置223以查找具有与接收到的数据消息的报头值(例如，其五元组标识符)匹配的记录标识符的记录。然后，它使用(在620处)这个匹配记录的上下文属性集作为接收到的数据消息流的上下文属性集。

在其它实施例中，负载平衡器126查询上下文引擎以获得针对接收到的数据消息的上下文属性集。利用这个查询，负载平衡器供应接收到的消息的流标识符(例如，五元组标识符)或其相关联的服务令牌。然后，上下文引擎使用消息的流标识符或其相关联的服务令牌在其上下文属性存储装置145中识别上下文属性集，然后它将识别出的上下文属性集提供给负载平衡器126，如上面所解释的。

一旦处理600已经获得针对接收到的数据消息的上下文属性集，它就使用这个属性集以及消息的其它标识符来识别(在625处)LB规则存储装置140中针对在605处接收到的数据消息的LB规则。例如，在一些实施例中，LB规则具有规则标识符405，其根据五元组属性中的一个或多个以及一个或多个上下文属性(诸如应用名称、应用版本、用户ID、组ID、AppID、威胁级别、资源消耗级别等)来定义。为了识别LB规则存储装置140中的LB规则，在一些实施例中，该处理将接收到的数据消息的上下文属性和/或其它属性(例如，五元组标识符)与LB规则的规则标识符(例如，规则标识符405)进行比较，以识别具有与消息的属性集匹配的标识符的最高优先级规则。

在一些实施例中，该处理使用不同的消息属性集来执行这个比较操作。例如，在一些实施例中，消息属性集包括消息的目的地IP地址(例如，被寻址的节点组的VIP)以及一个或多个上下文属性。在其它实施例中，消息属性集包括其它属性，诸如其它五元组标识符中的一个或多个(例如，源IP、源端口、目的地端口和协议中的一个或多个)。在一些实施例中，消息属性集包括逻辑网络标识符，诸如虚拟网络标识符(VNI)、虚拟分布式路由器标识符(VDRI)、逻辑MAC地址、逻辑IP地址等。

如上面所提到的，在一些实施例中，每个LB规则包括两个或更多个目的地地址(例如，IP地址410)，其是作为负载平衡的节点组的成员的节点的目的地地址(例如，IP地址)。当该处理识别出LB规则时(在630处)，它选择规则的目的地地址之一(例如，IP地址)以代替该消息中的虚拟地址(例如，VIP地址)。而且，如上面所提到的，在一些实施例中，每个LB规则存储负载平衡标准集，用于促进处理选择LB规则的目的地地址之一以代替消息的虚拟目的地标识符。在一些实施例中，所存储的标准是上面参考图4和5描述的权重和/或时间值。因而，在一些实施例中，处理600基于存储在规则中的选择标准选择匹配规则的目的地地址之一，并将消息的目的地地址改变为所选择的目的地地址。

在改变数据消息的目的地地址之后，该处理(在630处)沿着其数据路径发送数据消息。同样，在一些实施例中，这个操作需要将通信返回到SFE端口260(其调用负载平衡器以发起处理600)以指示负载平衡器完成其对VM数据消息的处理。然后，SFE端口260可以将数据消息移交到SFE或VM，或者可以调用I/O链操作符中的另一个服务引擎以对数据消息执行另一个服务操作。

在630之后，该处理转到635，其中在连接状态高速缓存存储装置225中，它创建记录以识别负载平衡组中的计算或服务节点(即，识别节点目的地标识符)以使用其转发作为与605处接收到的数据消息属于的同一流的一部分的数据消息。在635处，处理600还更新它为处理600将消息寻址到的节点维护的统计数据。这个更新反映了向这个节点传输新数据消息。在635之后，该处理结束。

由于其使用上下文属性来定义LB规则的规则标识符，因此基于上下文的负载平衡器126可以基于任何数量的上下文属性来分发数据消息流。如上面所提到的，此类负载平衡操作的示例包括：(1)在所有负载平衡池上分发与财务部门相关联的数据消息流，(2)在用于这个部分的主池发生故障时将所有财务部门的流量重定向到另一个池，以使这个部门的流量高度可用，(3)使得与医生用户组相关联的所有流量高度可用，以及(4)在低等待时间服务节点组的服务节点之间分发财务应用的数据消息流。在一些实施例中，还可以根据收集的资源消耗来定义负载平衡规则，以便分发流量以向消耗DCN上的大量资源的应用提供更多或更少的资源。

在一些实施例中，管理平面获得在数据中心中的主机上的VM上运行的所有处理和服务的库存。在一些实施例中，主机200的发现引擎120帮助从在其主机上执行的VM收集这种数据。在一些实施例中，库存的处理/服务被称为库存的应用，其包括利用网络输入/输出的所有客户端处理、服务或守护进程以及已经注册以监听(即，获得消息)某些网络连接的所有服务器处理。在一些实施例中，发现引擎使用GI代理250和MUX 227来收集这个数据。

基于由所有主机上的所有发现引擎收集的数据，管理服务器(例如，网络管理器和/或计算管理器)构建正在运行的应用的库存。在一些实施例中，通过将从VM 205获得的其文件散列与存储在管理平面的应用数据存储装置中的应用文件的散列进行比较来识别每个应用。在一些实施例中，管理平面使发现引擎更新其数据集合，使得管理平面可以按计划刷新其库存。

然后，在一些实施例中，管理平面提供规则创建接口，用于允许管理员为LB引擎126创建基于上下文的LB规则和/或策略(以及用于其它服务引擎130的服务规则)。规则创建接口允许管理员基于通过由发现引擎120收集的数据所列出的应用以及由上下文引擎110和由管理平面的与其它管理服务器集群的接口收集的上下文属性来定义高级LB策略(和其它服务策略)。

一旦在管理平面中定义了高级LB策略(和其它服务策略)，管理平面就直接将这些策略中的一些或全部供给主机200上的管理代理(未示出)，和/或通过控制器(例如，网络控制器)的集合间接地将这些策略中的一些或全部供给这些代理。在一些实施例中，管理代理将接收到的策略作为规则发布到基于上下文的服务规则存储装置140。在一些实施例中，代理在将这些策略发布到基于上下文的服务规则存储装置140之前变换这些策略。例如，在一些实施例中，策略与AppliedTo元组一起发布，所述AppliedTo元组识别它们所关联的服务节点和/或逻辑网络。在这些实施例的一些中，在将策略作为服务规则推送到服务规则存储装置140之前，主机上的管理代理从每个服务策略中移除AppliedTo元组。而且，如上面所提到的，在一些实施例中，主机200上的上下文引擎110基于所收集的上下文属性来解析策略，以便为服务引擎生成规则。

防火墙引擎128是基于上下文的防火墙引擎，其基于防火墙规则来执行其防火墙操作，该防火墙规则不仅可以根据L2-L4参数来指定，而且还可以根据上下文属性来指定。图7图示了此类防火墙规则的若干示例。这个图图示了一些实施例的防火墙规则数据存储库140。如图所示，每个防火墙规则包括规则标识符705和防火墙动作参数710。

在一些实施例中，防火墙动作参数710可以指定传统防火墙动作中的任何一个，诸如允许、丢弃、重新路由等。每个规则标识符705指定可以用于识别与数据消息流匹配的规则的一个或多个数据元组。如图所示，在一些实施例中，规则标识符可以包括任何L2-L4参数(例如，源IP地址、源端口、目的地端口、协议等)。这些参数中的一个或多个可以是虚拟参数(例如，目的地集群的VIP)或逻辑标识符(例如，逻辑网络标识符)。

在一些实施例中，规则标识符还可以包括上下文属性，诸如AppID、应用名称、应用版本、用户ID、组ID、威胁级别和资源消耗。在一些实施例中，防火墙引擎通过将一个或多个消息属性(例如，五元组报头值、上下文属性)与规则标识符705进行比较来搜索防火墙数据存储装置，以识别具有匹配规则标识符的最高优先级规则。

在一些实施例中，不同主机上的不同防火墙引擎128强制执行相同的防火墙规则集。例如，在一些实施例中，不同的防火墙引擎128在一个逻辑网络的VM的不同主机上处理相同的防火墙规则，以便提供关于由这些VM发送或为这些VM接收的数据消息的安全级别。对于这种逻辑网络，这些防火墙引擎128共同形成跨越多个主机的分布式防火墙引擎(即，单个概念逻辑防火墙引擎)。

图8图示了一些实施例的基于上下文的防火墙规则的若干更详细示例。在这些示例中，每个规则的规则标识符705以五元组标识符和一个或多个上下文属性表示。每个规则在其五元组标识符中都有一个或多个属性，这些属性是由星号表示的通配符值，以便指定这些属性的值无关紧要(即，数据消息流对于这些属性可以具有任何值而不会不能匹配规则)。

第一规则835指定应当丢弃来自Skype版本1024的所有数据消息流。这个规则的规则标识符仅根据数据消息流的上下文属性来表述。如上面所提到的，并且在下面进一步描述，每次防火墙引擎128识别出新的数据消息流时，它通过与上下文引擎交互或通过检查其属性映射存储装置223中的记录来识别流的上下文属性以识别指定流的五元组标识符的上下文属性的记录。

第二规则830指定要丢弃具有等于护士的组ID和等于YouTube流量的AppID的所有数据消息流。通过强制执行这个规则，防火墙引擎128可以确保登录到其VM 205的护士不能查看YouTube流量。同样，这个规则的规则标识符仅根据数据消息流的上下文属性来表述。在这个示例中，上下文属性是组ID和AppID。

图9呈现了图示防火墙引擎128对第二规则830的强制执行的示例。具体而言，它示出了这个防火墙引擎128允许来自浏览器910的第一数据消息905通过，同时阻止来自这个浏览器的第二数据消息915。如图所示，这两个数据消息都与护士920在浏览器上执行的操作相关联。允许第一数据消息流通过，因为它与护士通过浏览器发送的电子邮件有关。这个防火墙引擎128允许这个消息通过，因为它与要求阻止消息的任何防火墙规则不匹配。另一方面，防火墙引擎128阻止第二数据消息，因为它与试图观看YouTube视频的护士有关，并且规则830禁止这种类型的数据消息流。

图8中的第三规则825指定如果它们去往特定目的地IP地址A那么应当阻止与高威胁级别指示符相关联的所有数据消息流。这个规则的规则标识符根据数据消息的五元组标识符中的上下文属性(即，高威胁级别指示符)和一个属性(目的地IP地址)定义。

图10呈现了在两个阶段中图示防火墙引擎128对这个规则825的强制执行的示例。具体而言，它在第一阶段1002中示出防火墙引擎128允许数据消息1010从VM 205传递到具有特定目的地IP地址A的另一个VM 1020(在主机外部)。在第二阶段1004中，应用1005安装在VM 205上。这个应用被威胁检测器132指定为高威胁应用。每当在VM上起动新的数据消息流时，上下文引擎将这个数据消息流与高威胁级别标记相关联。因而，在第二阶段1004中，防火墙引擎128阻止从VM 205到另一个VM 1020的数据消息1050，因为这个数据消息与高威胁级别相关联，并且规则815禁止将这样的数据消息发送到VM 1020的IP地址A。

图8中的第四和第五规则820和815指定与医生和护士组相关联的数据消息可以访问与VIP地址A相关联的VM，而与会计组相关联的数据消息不能访问这些VM。第四规则的规则标识符根据数据消息的五元组标识符中的两个上下文属性(即，医生和护士组标识符)和一个属性(VIP目的地地址A)来定义。第五规则的规则标识符根据数据消息的五元组标识符中的一个上下文属性(即，会计组标识符)和一个属性(VIP目的地地址A)来定义。在一些实施例中，VIP地址是执行相同功能的VM集群的地址，并且负载平衡器将这个VIP地址翻译为集群中的VM之一的IP地址。

图11呈现了图示由防火墙引擎128对第四和第五规则820和815的强制执行的示例。具体而言，它示出两个用户同时登录到一个充当终端服务器的VM。这些用户中的一个是护士X，而另一个用户是会计Y。图11还示出防火墙引擎128允许来自护士X的会话的第一数据消息1105传递到由目的地IP地址VIP A识别出的VM集群1150中的VM。它还示出防火墙引擎阻止来自会计Y的会话的第二数据消息1110到达这个VM集群中的任何VM，因为第五规则815阻止与会计组ID相关联的数据消息到达目的地IP地址VIP A。

在图11中，两个数据消息是针对同时登录到VM的两个不同的实际用户。在其它情况下，只有一个用户可能实际登录到VM，但管理处理连同为由登入用户起动的应用运行的处理可能正在VM上运行。管理处理可以是在与登入用户不同的用户上下文中的VM中运行的服务/守护进程。服务一般在admin/root上下文中运行，而不是在登入用户上下文中运行。这是个潜在的安全漏洞，因为它可能允许在非登入用户上下文中运行的任何应用访问网络资源。因而，即使当只有单个用户登录到VM时，也可以期望指定将与后台管理处理相关联的数据消息与从为登入用户起动的应用运行的处理相关联的数据消息区别对待的防火墙规则。

作为示例，第六规则810允许与由高安全性组中的个体操作的应用相关联的处理的数据消息访问具有敏感数据的其它VM(在这个示例中，这些VM是与IP地址VIP B相关联的VM集群的一部分)，而第七规则805阻止与后台管理处理相关联的数据消息访问这些VM。这对于确保IT人员或黑客无法通过安装访问高安全性VM的管理处理来创建后门以访问敏感数据非常有用，这些高安全性VM可以通过适当的间隙捎带用户的登录会话。

图12呈现了图示防火墙引擎128对第六和第七规则810和805的强制执行的示例。具体而言，它示出了从一个VM同时发出的两个数据消息流。一个数据消息流与CEO相关联，而另一个数据消息流与称为实用程序Q的后台IT实用程序处理相关联。图12进一步示出防火墙引擎128允许来自CEO的会话的数据消息1205传递到高安全性集群1250中的由VIP地址B识别的VM。它还示出防火墙引擎阻止来自实用程序Q的会话的第二数据消息1210到达高安全性集群中的任何VM，因为第七规则805阻止与管理处理(诸如实用程序Q处理)相关联的数据消息到达VIP地址B。

防火墙引擎可以区分用于两个不同登录/管理凭证的在VM上并发运行的两个不同处理的数据消息流，因为当每个流开始时，上下文引擎收集针对每个数据消息流的用户和组标识符，并且将每个流与其用户和组标识符相关联。图13图示了上下文引擎每次从GI代理接收到新的网络连接事件时执行以收集用户和组标识符的处理1300。

处理1300最初从VM 205上的GI代理250接收(在1305处)新网络连接事件的通知。如上面所提到的，在一些实施例中，GI代理在新的网络连接通知中提供以下信息：连接的五元组标识符，请求网络连接的处理的标识符，与发出请求的处理相关联的用户标识符以及与发出请求的处理相关联的组标识符。

接下来，在1310处，处理1300查询GI代理以收集新网络连接事件所需的任何其它上下文属性。这些附加参数的示例包括与请求网络连接的处理相关联的附加参数。在1315处，处理1300然后将一个或多个上下文属性记录发布到一个或多个服务引擎。在一些实施例中，到每个服务引擎的每个上下文属性记录包括连接的五元组标识符和一个或多个上下文属性的集合，包括用户标识符和/或组标识符。然后，服务引擎将提供的上下文属性记录存储在它们的属性映射存储装置223中，以便它们可以使用这些记录来识别与它们处理的不同数据消息流相关联的上下文属性集。对于针对不同用户账户具有用于在VM上并发运行的不同处理的不同服务规则的服务引擎，上下文属性集包括用户标识符或组标识符，以允许这些服务引擎将来自VM的不同数据消息流关联到不同用户/组标识符。

在一些实施例中，上下文引擎不在服务引擎的上下文属性记录中不包括服务引擎不需要的上下文属性。而且，在一些实施例中，上下文引擎向同一网络连接事件的不同上下文引擎提供不同的上下文属性记录，因为不同的服务引擎需要不同的上下文属性集。如上所述，在一些实施例中，上下文引擎110不将用于新网络连接的上下文属性集推送到一些或全部服务引擎，而是让这些服务引擎拉取这些属性集。

在一些实施例中，上下文引擎可以将具有源VM(即，作为数据消息流的源的VM)的源主机上的数据消息流与同一个主机或不同目的地主机上的目的地VM的上下文属性相关联。然后，这些实施例中的防火墙引擎128可以使用这种基于目的地的上下文属性来解析防火墙规则。例如，防火墙引擎可以丢弃寻址到特定类型的服务器(例如，Sharepoint服务器)的所有数据消息。为了支持这种基于目的地的规则，一些实施例的上下文引擎指示GI代理识别在特定端口上注册通知的处理，并将这个信息与处理标识符和散列一起使用以识别充当数据消息流的目的地的应用。由管理平面(例如，由在分离的计算机上或在执行VM的相同主机上操作的管理服务器)收集由不同主机上的上下文引擎收集的信息，其聚合这个数据并将聚合的数据分发到其它上下文引擎。然后，分发的信息可以由主机上的上下文引擎用来解析这些主机上的上下文策略，以便为这些主机上的基于上下文的服务引擎供应基于上下文的规则。

图14图示了在一些实施例中防火墙引擎128执行的处理1400。如图所示，当防火墙引擎从其对应的SFE端口260接收到(在1405处)数据消息时，处理1400开始。这个端口在从其VM或为其VM接收到数据消息时会中继这个消息。在一些实施例中，端口通过向防火墙引擎传递对数据消息或数据消息的报头值的引用(例如，识别存储器中存储数据消息的位置的句柄)来中继数据消息。

该处理确定(在1410处)连接状态高速缓存225是否存储识别用于接收到的数据消息的消息流的防火墙动作的记录。如上面所提到的，每次防火墙引擎使用防火墙规则处理新数据消息时，在一些实施例中，防火墙引擎在连接状态高速缓存225中创建记录以存储所执行的防火墙动作，以便当防火墙引擎接收到同一流中的另一个数据消息(即，具有相同的五元组标识符)时，它可以执行与在同一个流中的先前数据消息上执行的相同的防火墙动作。连接状态高速缓存225的使用允许防火墙引擎128更快地处理数据消息流。在一些实施例中，连接状态高速缓存225中的每个高速缓存的记录具有根据数据消息标识符(例如，五元组标识符)定义的记录标识符。在这些实施例中，该处理将接收到的数据消息的标识符(例如，五元组标识符)与高速缓存的记录的记录标识符进行比较，以识别具有与接收到的数据消息的标识符匹配的记录标识符的任何记录。

当处理1400在连接状态高速缓存225中识别出(在1410处)接收到的数据消息流的记录时，该处理(在1415处)然后执行在这个记录中指定的防火墙动作(例如，允许、丢弃、重新路由等)。假设防火墙动作不需要丢弃数据消息，那么处理1400沿着其数据路径发送经处理的数据消息。在一些实施例中，这个操作需要将通信返回到SFE端口260(其调用防火墙引擎以发起处理1400)以指示防火墙引擎完成其对VM数据消息的处理。然后，SFE端口260可以将数据消息移交到SFE或VM，或者可以调用I/O链操作符中的另一个服务引擎以对数据消息执行另一个服务操作。

当在1415处执行的防火墙动作导致丢弃数据消息时，处理1400向SFE端口260通知(在1415处)这个操作。而且，当在1415处执行的防火墙动作要求重新路由数据消息时，处理1400对数据消息执行(在1415处)网络地址翻译，以便实现这个重新路由，然后将数据消息返回(在1415处)到SFE端口，以便数据消息可以沿着其数据路径发送。在1415之后，处理1400结束。

当处理1400确定(在1410处)连接状态高速缓存225没有存储用于接收到的数据消息的流的记录时，处理1400识别出(在1420处)这个数据消息流的一个或多个上下文属性。如上面所提到的，不同实施例的服务引擎以不同方式执行这个操作。例如，在一些实施例中，防火墙引擎128检查属性映射存储装置223以查找具有与接收到的数据消息的报头值(例如，其五元组标识符)匹配的记录标识符的记录。然后，它使用(在1420处)这个匹配记录的上下文属性集作为接收到的数据消息流的上下文属性集。

在其它实施例中，防火墙引擎128查询上下文引擎以获得针对接收到的数据消息的上下文属性集。利用这个查询，防火墙引擎供给接收到的消息的流标识符(例如，五元组标识符)或其相关联的服务令牌。然后，上下文引擎使用消息的流标识符或其相关联的服务令牌来在其上下文属性存储装置145中识别上下文属性集，如上面所解释的。

一旦处理1400已经获得针对接收到的数据消息的上下文属性集，它就使用这个属性集以及消息的其它标识符来识别(在1425处)防火墙规则数据存储库140中的防火墙规则以用于1405处接收到的数据消息。例如，在一些实施例中，防火墙规则具有规则标识符705，其根据五元组属性中的一个或多个以及一个或多个上下文属性(诸如应用名称、应用版本、用户ID、组ID、AppID、威胁级别、资源消耗级别等)来定义。为了识别防火墙规则数据存储库140中的防火墙规则，在一些实施例中，该处理将接收到的数据消息的上下文属性和/或其它属性(例如，五元组标识符)防火墙规则的规则标识符(例如，规则标识符705)进行比较，以识别具有与消息的属性集匹配的标识符的最高优先级规则。

在一些实施例中，该处理使用不同的消息属性集来执行这个比较操作。例如，在一些实施例中，消息属性集包括其它五元组标识符中的一个或多个(例如，源IP、源端口、目的地端口和协议中的一个或多个)以及一个或多个上下文属性。在一些实施例中，消息属性集包括逻辑网络标识符，诸如虚拟网络标识符(VNI)、虚拟分布式路由器标识符(VDRI)、逻辑MAC地址、逻辑IP地址等。

在处理识别出防火墙规则(在1425处)之后，它执行(在1430)这个规则对接收到的数据消息的防火墙动作(例如，允许、丢弃、重新路由等)。假设防火墙动作不需要丢弃数据消息，那么处理1400沿着其数据路径发送(在1430处)经处理的数据消息。在一些实施例中，这个操作需要将通信返回到SFE端口260(其调用防火墙引擎以发起处理1400)以指示防火墙引擎完成其对VM数据消息的处理。然后，SFE端口260可以将数据消息切换到SFE或VM，或者可以调用I/O链操作符中的另一个服务引擎以对数据消息执行另一个服务操作。

当在1430处执行的防火墙动作导致数据消息的丢弃时，处理1400向SFE端口260通知(在1430处)这个操作。而且，当在1430处执行的防火墙动作要求重新路由数据消息时，处理1400执行(在1430处)关于数据消息的网络地址翻译以便实现这个重新路由，然后将数据消息返回(在1430处)到SFE端口，以便数据消息可以沿着其数据路径发送。

在1430处执行防火墙动作之后，该处理在连接状态高速缓存存储装置225中创建(在1435处)记录。这个记录识别接收到的数据消息流的防火墙操作。在一些实施例中，这个记录具有通过参考数据消息流的标识符(例如，其五元组标识符)来定义的记录标识符。在1435之后，该处理结束。

如上面所提到的，一些实施例中的管理服务器与在数据中心中的主机200上执行的发现引擎120交互，以获得并刷新在主机上的VM上运行的所有处理和服务的库存。在一些实施例中，管理服务器(上面和下面也称为管理平面)然后提供规则创建接口，用于允许管理员为防火墙引擎128创建基于上下文的防火墙规则和/或策略(以及用于其它服务引擎130的服务规则)。规则创建接口允许管理员基于通过由发现引擎120收集的数据库存的应用以及由上下文引擎110和由与其它管理服务器集群的管理平面的接口收集的上下文属性来定义高级防火墙策略。

一旦在管理平面中定义了高级防火墙策略(和其它服务策略)，管理平面就直接将这些策略中的一些或全部供给主机200上的管理代理(未示出)，和/或通过控制器(例如，网络控制器)的集合间接地将这些策略中的一些或全部提供给这些代理。在一些实施例中，管理代理将接收到的策略作为规则发布到基于上下文的服务规则存储装置140。在一些实施例中，代理在将这些策略发布到基于上下文的服务规则存储装置140之前变换这些策略。例如，在一些实施例中，策略与AppliedTo元组一起发布，所述元组识别它们所关联的服务节点和/或逻辑网络。在这些实施例的一些中，在将策略作为服务规则推送到服务规则存储装置140之前，主机上的管理代理从每个服务策略中移除AppliedTo元组。而且，如上面所提到的，在一些实施例中，主机200上的上下文引擎110基于所收集的上下文属性来解析策略，以便为服务引擎生成规则。

加密引擎124是基于上下文的加密器，其基于加密规则来执行其加密/解密操作，所述加密规则不仅可以根据L2-L4参数来指定，而且还可以根据上下文属性来指定。图15图示了这种基于上下文的加密规则的示例。这些规则由不同主机200上的不同加密引擎124独立使用，以加密/解密由这些主机上的VM 205发送和为其接收的数据消息。以这种方式，在不同主机(例如，用于一个租户或一个逻辑网络的)上强制执行相同加密规则的加密引擎124共同形成跨越多个主机以统一执行期望的加密和解密操作的集合的分布式加密引擎(即，单个概念逻辑加密引擎)。在一些实施例中，每个VM 205具有其自己的加密引擎，而在其它实施例中，一个加密引擎124可以服务于同一主机上的多个VM 205(例如，用于同一主机上的同一租户的多个VM)。

图15图示了存储若干加密规则的加密规则数据存储库140。每个加密规则包括(1)规则标识符1505，(2)加密类型标识符1510，以及(3)密钥标识符1515。每个规则标识符1505指定可以用于识别与数据消息流匹配的规则的一个或多个数据元组。在一些实施例中，规则标识符可以包括任何L2-L4参数(例如，源IP地址、源端口、目的地端口、目的地IP、协议等)。在一些实施例中，这些L2-L4参数可以在物理域或逻辑域中定义。而且，如图所示，规则标识符可以包括上下文属性，诸如AppID、应用名称、应用版本、用户ID、组ID、威胁级别和资源消耗。

在一些实施例中，加密器124通过将一个或多个消息属性(例如，五元组报头值、上下文属性)与规则标识符1505进行比较来搜索加密规则数据存储库140以识别具有匹配的规则标识符的最高优先级规则。而且，在一些实施例中，加密规则数据存储库140具有在没有其它规则与数据消息流匹配时使用的默认规则。在一些实施例中，默认规则不指定加密密钥，因为不存在用于加密数据消息流的规则。而且，在一些实施例中，当默认规则返回到加密器124时，加密器124不加密它正在对其执行检查的数据消息流。

每个加密规则的加密类型1510指定要使用的加密/解密的类型，而每个规则的密钥标识符1515识别用于加密/解密的密钥。在一些实施例中，加密规则仅指定密钥标识符1515并且不指定加密类型1510，因为密钥标识符识别密钥和加密/解密的类型两者，或者这些类型以其它方式在加密器中指定(例如，预先配置)。

现在将参考图16-18描述加密引擎124的加密和解密操作。在一些实施例中，加密和解密操作使用相同密钥或相同密钥的转置版本，因为这些实施例使用对称加密方案，其中相同密钥用于加密和解密消息，或相同密钥的转置版本用于加密和解密消息。其它实施例使用非对称加密方案(例如，使用其私钥的源加密器，以及使用源加密器的公钥的目的地加密器)。

图16图示了加密器124执行以加密由主机200上的VM 205发送的数据消息的处理1600。如图所示，当加密器124从其对应的SFE端口260接收(在1605处)到数据消息时，处理1600开始。这个端口在从其VM接收到数据消息时中继这个消息。在一些实施例中，该端口通过向加密器传递对数据消息或数据消息的报头值的引用(例如，识别存储器中存储数据消息的位置的句柄)来中继数据消息。

接下来，在1610处，加密器确定其连接状态高速缓存225是否存储用于接收到的数据消息的高速缓存的加密记录。在一些实施例中，在一些实施例中在每次加密器找到用于VM数据消息的加密规则时，它在连接状态高速缓存225中创建高速缓存的加密记录，其存储加密规则、对加密规则的引用、加密密钥和/或加密密钥的标识符。

加密器创建这个高速缓存记录，使得当其接收针对同一数据消息流的另一个数据消息时，加密器不必搜索加密规则数据存储库140以识别用于同一个流中后续接收的数据消息的加密规则。在一些实施例中，连接状态高速缓存225中的每个高速缓存的记录具有根据数据消息标识符(例如，五元组标识符)定义的记录标识符。在这些实施例中，处理1600将接收到的数据消息的标识符(例如，五元组标识符)与高速缓存的记录的记录标识符进行比较，以识别具有与接收到的数据消息的标识符匹配的记录标识符的任何记录。

当处理1600在连接状态高速缓存225中识别出(在1610处)接收到的数据消息的高速缓存的加密记录时，该处理(在1615处)然后使用由识别出的加密记录识别出的密钥来加密接收到的数据消息。在高速缓存的记录包含加密规则或对加密规则的引用的实施例中，处理1600从存储或引用的规则中检索密钥标识符，并使用这个标识符从存储在主机200上的密钥数据存储库中或从在主机上的或在主机外部操作的密钥管理器检索密钥。类似地，在高速缓存的记录包含密钥标识符的实施例中，处理1600从高速缓存的记录中检索密钥标识符，并使用这个标识符从本地或远程密钥数据存储库或密钥管理器检索密钥。

在一些实施例中，该处理通过使用识别出的加密密钥来加密(在1615处)数据消息的有效载荷(例如，L2有效载荷)，同时生成有效载荷的完整性检查值(ICV)散列以及报头值(例如，物理L3和L4报头值和/或逻辑L2或L3报头值)的一些或全部，以便消息的目的地将(1)解密数据消息的加密部分，以及(2)核实用于ICV计算的有效负载和报头值的真实性和完整性。

对于数据消息的一些或全部，在一些实施例中，加密处理1600还加密(在1615处)数据消息报头的一部分。对于在与逻辑网络相关联的机器之间交换的数据消息，一些实施例加密数据消息的所有物理报头值。这些实施例中的一些对逻辑网络标识符(例如，VNI)和有效载荷执行ICV操作，使得目的地主机处的解密器可以核实加密数据消息的真实性和完整性。

在加密数据消息之后，该处理(在1615处)沿着其数据路径发送加密的数据消息。在一些实施例中，这个操作需要将通信返回到SFE端口260(其调用加密器以发起处理1600)以使端口知道加密器已完成其对数据消息的处理。然后，SFE端口260可以将数据消息移交到SFE 210，或者可以调用另一个I/O链操作符以对数据消息执行另一个操作。在1615之后，处理1600结束。

当处理1600确定(在1610处)连接状态高速缓存225没有存储与接收到的数据消息匹配的任何高速缓存的记录时，处理1600识别(在1620处)这个数据消息流的一个或多个上下文属性。如上面所提到的，不同实施例的服务引擎以不同方式执行这个操作。例如，在一些实施例中，加密引擎124检查属性映射存储装置223以查找具有与接收到的数据消息的报头值(例如，其五元组标识符)匹配的记录标识符的记录。然后，它使用(在1620处)这个匹配记录的上下文属性集作为接收到的数据消息流的上下文属性集。

在其它实施例中，加密引擎124查询上下文引擎110以获得针对接收到的数据消息的上下文属性集。利用这个查询，加密引擎供应接收到的消息的流标识符(例如，五元组标识符)或其相关联的服务令牌，然后上下文引擎使用该标识符在其上下文属性存储装置145中识别上下文属性集，如上面所解释的。

一旦处理600已经获得针对接收到的数据消息的上下文属性集，它就自己将这个属性集或者连同消息的其它标识符(例如，五元组标识符)一起使用来识别(在1625处)加密规则数据存储库140中匹配接收到的数据消息的属性的加密规则。例如，在一些实施例中，加密规则具有根据非上下文属性(例如，五元组属性、逻辑属性等)中的一个或多个和/或一个或多个上下文属性(诸如应用名称、应用版本、用户ID、组ID、AppID、威胁级别、资源消耗级别等)来定义的规则标识符。为了识别加密规则数据存储库140中的加密规则，在一些实施例中该处理比较接收到的数据消息的上下文属性和/或其它属性(例如，五元组标识符)与加密规则的规则标识符(例如，规则标识符1505)，以识别具有与消息的属性集匹配的标识符的最高优先级规则。

在1625之后，该处理确定(在1630处)它是否识别出指定应当加密接收到的数据消息的加密规则。如上面所提到的，加密规则数据存储库140具有与所有数据消息匹配的默认加密规则，并且在没有其它加密规则与接收的数据消息匹配时返回。在一些实施例中，默认加密规则指定不应当加密接收到的数据消息(例如，指定与非加密操作对应的默认密钥标识符)。

当处理1600确定(在1630处)数据消息不应当被加密时，该处理沿着消息的数据路径发送(在1635处)未加密的消息。这个操作1630需要通知其SFE端口260它已完成处理数据消息。在1635之后，该处理转到1645，其中在连接状态高速缓存存储装置225中，它创建记录以指示不应当对接收到的数据消息流执行加密。在一些实施例中，基于这个流的五元组标识符在连接状态高速缓存225中寻址这个记录。在1645之后，该处理结束。

当该处理确定(在1630处)数据消息应当被加密时，该处理然后(在1640处)从识别出的规则中检索密钥标识符，使用这个标识符从本地或远程密钥数据存储库或管理器检索密钥，如上所述，并且用检索到的密钥加密接收到的数据消息。数据消息的这种加密(在1640处)与上面描述的加密操作1615完全相同。例如，如上所述，处理1600通过使用识别出的加密密钥来加密数据消息的有效载荷(例如，L2有效载荷)，同时对有效载荷和一些或全部报头值(例如，物理L3和L4报头值，逻辑L2或L3报头值，和/或逻辑网络标识符，诸如VNI和VDRI)执行ICV操作。对于一些或全部数据消息，在一些实施例中，加密处理1600还加密(在1640处)数据消息的一些或全部报头。

在加密数据消息之后，该处理沿着其数据路径发送(在1635处)加密的数据消息。同样，在一些实施例中，这个操作需要将通信返回到SFE端口260，以使端口知道加密器完成了对数据消息的处理。然后，SFE端口260可以将数据消息移交到SFE 210，或者可以调用另一个I/O链操作符以对数据消息执行另一个操作。

当在1630处识别出的加密规则是在动态检测到事件之后动态创建的规则时，加密器必须确保(在1640处)用于加密数据消息的密钥的密钥标识符在发送数据消息报头之前包含在该数据消息报头中。处理1600在不同实施例中以不同方式实现这个目标。在一些实施例中，处理1600将密钥标识符传递(在1640处)到(调用它的)SFE端口260，使得它调用的端口或I/O链操作符可以将密钥标识符插入数据消息报头中。例如，在一些实施例中，一个服务引擎(例如，另一个I/O链操作符)用用于建立覆盖逻辑网络的隧道报头封装数据消息。在这些实施例的一些中，SFE端口260将其从处理1600接收的密钥标识符传递给这个服务引擎，以便它可以在其报头中包括这个密钥标识符。

在其它实施例中，处理1600不将密钥标识符传递到SFE端口，并且这个端口不让另一个服务引擎将密钥标识符封装在覆盖网络的隧道报头中。在这些实施例的一些中，SFE端口260简单地使服务引擎在覆盖网络的隧道报头中包括数据消息被加密的指示。在这些实施例中，在具有目的地DCN的主机上执行的解密器(例如，加密引擎124)可以基于预先配置的信息(例如，允许解密器基于指定用于与源DCN通信的先前密钥，或基于数据消息流的报头值挑选正确密钥的白盒解决方案)或者基于与源主机上的控制器或模块关于要使用的适当密钥的带外通信识别用于解密数据消息的正确密钥。

在1640之后，该处理过渡到1645，其中在连接状态高速缓存存储装置225中，它创建记录以存储在1625处识别出的加密规则、对这个加密规则的引用、在这个加密规则中指定的密钥标识符，和/或由这个密钥标识符指定的检索出的密钥。如上面所提到的，这个高速缓存的记录具有记录标识符，在一些实施例中，该记录标识符包括接收到的数据消息的标识符(例如，五元组标识符)。在1645之后，该处理结束。

图17图示了加密引擎124执行以解密SFE端口260或265在执行数据消息的目的地VM的目的地主机上接收的加密数据消息的处理1700。这个加密引擎在下面被称为解密器。在一些实施例中，解密器在其对应的SFE端口调用解密器以检查接收到的数据消息是否被加密时执行这个操作，并且如果是，那么解密这个消息。

在一些实施例中，当SFE端口确定接收到的数据消息被加密时，SFE端口调用加密引擎124。例如，在一些实施例中，数据消息沿着隧道被发送到目的地主机，并且这个隧道的报头具有指定数据消息被加密的标识符。在一些实施例中，仅当接收到的数据消息的报头值未指定识别用于解密数据消息的密钥的密钥标识符时，解密器才执行这个处理。当报头值确实指定了这样的密钥标识符时，解密器使用图18的解密处理1800，这将在下面描述。

而且，在一些实施例中，接收到的数据消息具有指定消息是否被加密的值(例如，位)。通过分析这个值，解密器将知道消息是否被加密。当这个值指定消息未加密时，解密器不会调用处理1700或1800来解密加密的消息。相反，解密器通知SFE端口它可以沿着其数据路径发送数据消息。

如图所示，处理1700最初识别(在1705处)该处理用来识别适用于接收到的数据消息的加密规则的消息属性集。在不同的实施例中，用于检索规则的消息属性集可以是不同的。例如，在一些实施例中，这个消息-属性集包括接收到的数据消息的五元组标识符。在一些实施例中，这个消息-属性集还包括与接收到的数据消息相关联的逻辑网络标识符。

在1705之后，解密器确定(在1710处)其加密状态高速缓存225是否存储用于在1705处识别出的消息属性集的高速缓存的加密规则。与加密器类似，在一些实施例中在每次解密器找到数据消息的加密规则时，它在连接状态高速缓存225中存储加密规则、对加密规则的引用、这个规则的密钥标识符或这个规则的密钥，以便当它接收到具有相同的已识别出的消息-属性集的另一个数据消息时(例如，当它接收到作为与原始数据消息相同的数据流的一部分的另一个数据消息时)，解密器不必搜索(一个或多个)加密规则数据存储库为随后接收的数据消息识别加密规则。如上面所提到的，在一些实施例中，连接状态高速缓存225基于数据消息的五元组标识符存储加密规则。因而，在搜索加密规则数据存储库140之前，在一些实施例中，解密器首先确定连接状态高速缓存225是否存储用于接收到的数据消息的匹配的高速缓存记录。

当处理1700在连接状态高速缓存225中识别出(在1710处)用于接收到的数据消息的匹配的高速缓存记录时，该处理(在1715处)然后使用该记录来识别密钥，然后该密钥用于解密接收到的数据消息的加密部分的密钥。在一些实施例中，高速缓存的记录包括密钥，而在其它实施例中，这个记录包括密钥标识符或规则或对规则的引用，其包含密钥标识符。在后面的实施例中，该处理使用高速缓存的记录中或存储或引用的规则中的密钥标识符从本地或远程密钥数据存储库或管理器检索密钥，然后用检索出的密钥解密接收到的数据消息的加密部分。

在一些实施例中，解密操作的一部分(在1715处)是认证ICV生成的数据消息报头和有效载荷的散列。具体而言，当由加密器通过ICV操作将接收到的数据消息的一部分(例如，其物理(例如，L3或L4)报头值或其逻辑(例如，VNI)报头值)与有效载荷一起散列时，解密操作核实这个部分以验证加密数据消息的真实性和完整性。

在解密数据消息(在1715处)之后，该处理(在1715处)沿着其数据路径发送解密的数据消息。在一些实施例中，这个操作需要将通信返回到SFE端口(其调用解密器以发起处理1700)以使端口知道解密器已完成其对数据消息的处理。然后，SFE端口可以允许数据消息到达目的地VM，或者可以调用另一个I/O链操作符，以对数据消息执行另一个操作。在1715之后，处理1700结束。

当处理1700确定(在1710处)连接状态高速缓存225没有存储用于在1705处识别出的属性集的加密规则时，处理1700搜索(在1720处)加密规则数据存储库140以识别用于接收到的数据消息的加密规则。在一些实施例中，目的地主机从源主机(直接地或通过控制器集)接收带外通信，其提供目的地主机可以从其识别密钥标识符的数据，或具有密钥标识符的加密规则，用于解密加密的数据消息。在这些实施例的一些中，带外通信包括数据消息的标识符(例如，五元组标识符)。

在其它实施例中，目的地主机上的加密引擎124基于预先配置的信息识别用于解密数据消息的正确密钥。例如，在一些实施例中，源和目的地主机上的加密引擎124使用(1)根据预配置的方案逐步通过各加密密钥，或者(2)基于数据消息的属性(例如，五元组标识符)选择加密密钥的白盒解决方案。通过使源和目的地加密引擎遵循相同的方案来逐步通过或选择加密密钥，白盒方案确保目的地主机的加密器124处的加密引擎可以选择与用于加密数据消息的源主机的加密器124相同的加密密钥用于解密接收到的数据消息。

当处理1700找不到识别密钥的加密规则时，在一些实施例中，处理1700发起错误处置处理以解决用于解密加密消息的解密密钥的不可用性。在一些实施例中，这个错误处置处理查询网络代理以确定它或控制器集是否存储用于在1705处识别出的消息属性集的加密规则。当代理具有这样的加密规则时，它将其提供给处理(在1720处)。但是，在其它实施例中，错误处置处理不联系网络代理以获得密钥。相反，它只标记此问题以供管理员解决。

当该处理识别出(在1720处)密钥标识符或具有密钥标识符的加密规则时，该处理(在1725处)使用密钥标识符从本地或远程密钥数据存储库或管理器检索密钥，并且用检索到的密钥解密接收到的数据消息。在一些实施例中，解密操作的一部分(在1725处)用于认证ICV生成的数据消息报头和有效载荷的散列。具体而言，当接收到的数据消息的一部分(例如，其物理(例如，L3或L4)报头值或其逻辑(例如，VNI)报头值)由加密器通过ICV操作连同有效载荷一起进行散列时，解密操作核实这个部分以验证加密的数据消息的真实性和完整性。

在解密数据消息之后，该处理(在1725从)沿着其数据路径发送解密的数据消息。在一些实施例中，这个操作需要将通信返回到SFE端口(其调用解密器以发起处理1700)以使端口知道解密器已完成其对数据消息的处理。然后，SFE端口可以允许数据消息到达目的地VM，或者可以调用另一个I/O链操作符以对数据消息执行另一个操作。

在1725之后，该处理转到1730，其中在连接状态高速缓存存储装置225中，它创建记录以指定应当用于用类似于在1705处识别出的集合的消息属性集来解密数据消息(例如，来解密作为与接收到的数据消息相同的流的一部分的数据消息)的解密密钥或这个密钥的标识符。在一些实施例中，基于接收到的数据消息的五元组标识符在连接状态高速缓存存储装置225中寻址这个记录。在1730之后，该处理结束。

在一些实施例中，接收到的加密数据消息的报头值(例如，隧道报头)存储识别用于解密数据消息的密钥的密钥标识符。然后，主机设备上的加密引擎124通过使用由密钥标识符识别出的密钥来执行其解密操作。图18图示了加密引擎124执行以解密在其报头中包括密钥标识符的加密数据消息的处理1800。在一些实施例中，加密引擎124中的解密器在其对应的SFE端口260或265调用解密器以检查接收到的数据消息是否被加密时执行这个操作，并且如果是，那么解密这个消息。在一些实施例中，仅当接收到的数据消息的报头值指定识别用于解密数据消息的密钥的密钥标识符时，解密器才执行这个处理。

如图所示，处理1800最初从接收到的数据消息中提取(在1805处)密钥标识符。接下来，该处理使用(在1810处)密钥标识符从目的地主机上的本地密钥数据存储库/管理器或不在目的地主机上的远程密钥数据存储库/管理器检索密钥，然后使用(在1815处)这个密钥解密接收到的数据消息。如上面所提到的，解密操作的一部分(在1815处)是认证用数据消息的有效载荷加密的ICV生成的(接收到的数据消息的报头和有效载荷的)散列。在一些实施例中，处理1800在高速缓存数据存储库225中存储密钥，使得它不需要为与接收的数据消息相同的数据消息流中的其它数据消息识别这个密钥。

在解密数据消息之后，该处理沿着其数据路径发送(在1820处)解密的数据消息。在一些实施例中，这个操作需要将通信返回到SFE端口(其调用解密器以发起处理1800)以使端口知道解密器完成了其对数据消息的处理。然后，SFE端口可以允许数据消息到达目的地VM，或者可以调用另一个I/O链操作符以对数据消息执行另一个操作。在1820之后，处理1800结束。

由于其使用上下文属性来定义加密规则的规则标识符，因此基于上下文的加密器124可以基于任何数量的上下文属性来分发数据消息流。如上面所提到的，此类加密操作的示例包括：(1)加密从Outlook(在任何机器上起动)到Exchange Server的所有流量，(2)加密三层Web服务器、应用服务器和数据库服务器中的应用之间的所有通信，(3)加密源自管理员Active Directory组的所有流量，等等。

如上面所提到的，在一些实施例中，管理服务器与在数据中心中的主机200上执行的发现引擎120交互，以获得并刷新在主机上的VM上运行的所有处理和服务的库存。然后，在一些实施例中，管理平面提供规则创建接口，用于允许管理员为加密引擎124创建基于上下文的加密规则和/或策略(以及其它服务引擎130的服务规则)。规则创建接口允许管理员基于通过发现引擎120收集的数据库存的应用以及由上下文引擎110和管理平面与其它管理服务器集群的接口收集的上下文属性来定义高级加密策略(和其它服务策略)。

一旦在管理平面中定义了高级加密策略(和其它服务策略)，管理平面就直接将这些策略中的一些或全部供给主机200上的管理代理(未示出)，和/或通过控制器(例如，网络控制器)的集合间接地将这些策略中的一些或全部供给这些代理。在一些实施例中，管理代理将接收到的策略作为规则发布到基于上下文的服务规则存储装置140。在一些实施例中，代理在将这些策略发布到基于上下文的服务规则存储装置140之前变换这些策略。例如，在一些实施例中，策略与AppliedTo元组一起发布，所述元组识别它们所关联的服务节点和/或逻辑网络。在这些实施例的一些中，在将策略作为服务规则推送到服务规则存储装置140之前，主机上的管理代理从每个服务策略中移除AppliedTo元组。而且，如上面所提到的，在一些实施例中，主机200上的上下文引擎110基于所收集的上下文属性来解析策略，以便为服务引擎生成规则。

处理控制(PC)引擎122是基于上下文的PC引擎，其基于可以根据上下文属性指定的PC规则来执行其PC操作。图19图示了这种PC规则的若干示例。这个图图示了一些实施例的PC规则数据存储库140。如图所示，每个PC规则包括规则标识符1905和PC动作1910。在一些实施例中，PC动作1910可以是(1)允许，(2)停止和不允许，或(3)停止和终止。

每个规则标识符1905指定可以用于识别与数据消息流匹配的规则的一个或多个数据元组。如图所示，规则标识符可以包括上下文属性，诸如AppID、应用名称、应用版本、用户ID、组ID、威胁级别、资源消耗等。在一些实施例中，PC引擎通过比较一个或多个消息属性(例如，上下文属性)与规则标识符1905来搜索PC数据存储装置，以识别具有匹配规则标识符的最高优先级规则。在一些实施例中，规则标识符1905还可以包括与数据消息流相关联的L2-L4参数(例如，五元组标识符)，并且PC引擎基于每个流执行其PC操作。在其它实施例中，PC引擎122仅对处理事件执行其PC操作，并将其留给防火墙引擎128以基于每个流执行PC操作。因而，在一些实施例中，用于PC引擎的PC规则的规则标识符1905不包括任何L2-L4参数。

在一些实施例中，不同主机上的不同PC引擎122强制执行相同的PC规则集。例如，在一些实施例中，不同的PC引擎122在用于一个逻辑网络的VM的不同主机上处理相同的PC规则，以便为在这些VM上运行的处理提供安全级别。对于这个逻辑网络，这些PC引擎122共同形成跨越多个主机的分布式PC引擎(即，单个概念逻辑PC引擎)。

图19图示了一些实施例的基于上下文的PC规则的三个详细示例。第一个规则1920指定Skype版本1024应当被停止和禁止。在一些实施例中，每次PC引擎122识别出新的处理事件时，它通过与上下文引擎交互或通过检查其属性映射存储装置223中的记录来识别事件的上下文属性，以识别指定针对处理标识符的上下文属性的记录。

第二个规则1925指定具有高威胁级别的所有处理应当被停止和不允许。如上面所提到的，上下文引擎110或服务引擎130可以与威胁检测器132交互以评估与处理相关联的威胁级别。在一些实施例中，威胁检测器生成威胁得分，其中上下文引擎、PC引擎或其它服务引擎量化为若干类别之一。例如，在一些实施例中，威胁检测器产生从0到100的威胁得分，并且引擎110或130中的一个将0到33之间的得分指定为低威胁级别，将34到66之间的得分指定为中等威胁级别，并将67到100之间的得分指定为高威胁级别。

第三个规则1930指定生成YouTube流量的所有处理应当被停止和终止。在一些实施例中，这个规则由PC引擎强制执行，而在其它实施例中，类似的规则由防火墙引擎强制执行。当防火墙引擎强制执行这种规则时，它会在每个流的基础上强制执行这个规则，并且其动作是丢弃与这个流相关联的分组。当检查处理事件时，或者当SFE端口260调用它以对特定流执行PC检查时，PC引擎可以强制执行该规则。

图20图示了在一些实施例中PC引擎122执行的处理2000。如图所示，当PC引擎从上下文引擎110接收(在2005处)到处理标识符时，处理2000开始。当上下文引擎在VM 205上从GI代理250接收到处理通知时，该上下文引擎中继这个处理ID。

处理2000确定(在2010处)连接状态高速缓存225是否存储识别用于接收到的处理ID的PC动作的记录。每次PC引擎使用PC规则来处理新的处理标识符时，在一些实施例中，PC引擎在连接状态高速缓存225中创建记录以存储所执行的PC动作，使得其随后可以依赖于这个高速缓存以更快地处理相同的处理标识符。在一些实施例中，连接状态高速缓存225中的每个高速缓存记录具有根据处理标识符定义的记录标识符。在这些实施例中，该处理将接收到的标识符与高速缓存的记录的记录标识符进行比较，以识别具有与接收到的处理标识符匹配的记录标识符的任何记录。

当处理2000在连接状态高速缓存225中识别出(在2010处)接收到的处理事件的记录时，该处理(在2015处)然后执行在这个记录中指定的PC动作。当这个操作是不允许或终止时，PC引擎指示上下文引擎110不允许或终止该处理。为此，上下文引擎110指示报告该事件的GI代理不允许或终止该处理。然后，GI代理指示OS的处理子系统不允许或终止该处理。在2015之后，处理2000结束。

当处理2000确定(在2010处)连接状态高速缓存225没有存储接收到的处理标识符的记录时，处理2000识别出(在2020处)这个处理标识符的一个或多个上下文属性。如上面所提到的，不同实施例的服务引擎以不同方式执行这个操作。在一些实施例中，PC引擎指示上下文引擎收集接收到的处理事件的附加处理属性，并且上下文引擎通过与GI代理交互来收集这个信息。

一旦处理2000已经获得针对接收到的数据消息的上下文属性集，它就使用这个属性集来识别(在2025处)PC规则数据存储库140中的PC规则。在一些实施例中，PC规则具有根据一个或多个上下文属性(诸如应用名称、应用版本、用户ID、组ID、AppID、威胁级别、资源消耗级别等)定义的规则标识符1505。为了识别数据存储装置140中的PC规则，该处理在一些实施例中将收集到的上下文属性与PC规则的规则标识符(例如，规则标识符1905)进行比较，以识别具有与所收集的属性集匹配的标识符的最高优先级规则。

当该处理识别出PC规则时(在2025处)，它对接收到的处理事件执行这个规则的PC动作(例如，允许、停止和不允许、停止和终止等)。当这个操作是不允许或终止时，PC引擎指示上下文引擎110不允许或终止该处理。为此，上下文引擎110指示报告该事件的GI代理不允许或终止该处理。然后，GI代理指示OS的处理子系统不允许或终止该处理。在2030处执行PC动作之后，该处理在连接状态高速缓存存储装置225中创建(在2035处)记录。这个记录识别接收到的处理事件的PC动作。在2035之后，该处理结束。

如上面所提到的，在一些实施例中管理服务器与在数据中心中的主机200上执行的发现引擎120交互，以获得并刷新在主机上的VM上运行的所有处理和服务的库存。然后，在一些实施例中，管理平面提供规则创建接口，用于允许管理员为PC引擎122创建基于上下文的PC规则和/或策略(以及用于其它服务引擎130的服务规则)。规则创建接口允许管理员基于通过发现引擎120收集的数据库存的应用以及由上下文引擎110和管理平面与其它管理服务器集群的接口收集的上下文属性来定义高级PC策略(和其它服务策略)。

一旦在管理平面中定义了高级PC策略(和其它服务策略)，管理平面就直接将这些策略中的一些或全部供给主机200上的管理代理(未示出)，和/或通过控制器(例如，网络控制器)的集合间接地将这些策略中的一些或全部提供给这些代理。在一些实施例中，管理代理将接收到的策略作为规则发布到基于上下文的服务规则存储装置140。在一些实施例中，代理在将这些策略发布到基于上下文的服务规则存储装置140之前变换这些策略。而且，如上面所提到的，在一些实施例中，主机200上的上下文引擎110基于所收集的上下文属性来解析策略，以便为服务引擎生成规则。

图21图示了在一些实施例中如何管理服务引擎130的示例。这个图图示了数据中心中的多个主机200。如图所示，每个主机包括若干服务引擎130、上下文引擎110、威胁检测器132、DPI模块135、若干VM 205和SFE 210。它还图示了用于管理服务引擎130、VM 205和SFE 210的控制器集2110。如上面所提到的，在一些实施例中，上下文引擎110收集通过网络2150(例如，通过局域网、广域网、网络的网络(例如、互联网)等)传递给控制器集中的管理服务器的上下文属性。控制器集为管理员提供用户接口，以根据这些收集的上下文属性定义基于上下文的服务规则，并通过网络2150与主机通信以提供这些策略。主机还通过这个网络2150通信地彼此连接。

许多上述特征和应用被实现为软件处理，其被指定为记录在计算机可读存储介质(也被称为计算机可读介质)上的一组指令。当这些指令被一个或多个处理单元(例如，一个或多个处理器、处理器的核心、或其它处理单元)执行时，它们使得这(一个或多个)处理单元执行在指令中指示的动作。计算机可读介质的示例包括，但不限于，CD-ROM、闪存驱动器、RAM芯片、硬盘驱动器、EPROM等。计算机可读介质不包括无线地或通过有线连接传递的载波和电子信号。

在本说明书中，术语“软件”是指包括驻留在只读存储器中的固件或者可以被读入到存储器中用于被处理器处理的存储在磁存储装置中的应用。此外，在一些实施例中，多个软件发明可以被实现为更大程序的子部分，同时保持明显的软件发明。在一些实施例中，多个软件发明也可以被实现为单独的程序。最后，一起实现本文所描述的软件发明的单独程序的任意组合是在本发明的范围之内。在一些实施例中，当软件程序被安装以在一个或多个电子系统上操作时，该软件程序定义运行和执行该软件程序的操作的一个或多个特定的机器实现。

图22概念性地示出了实现本发明的一些实施例的计算机系统2200。计算机系统2200可以用于实现任何上述主机、控制器和管理器。由此，它可以用于执行任何上述处理。该计算机系统包括各种类型的非临时性机器可读介质和用于各种其它类型的机器可读介质的接口。计算机系统2200包括总线2205、(一个或多个)处理单元2210、系统存储器2225、只读存储器2230、永久存储设备2235、输入设备2240和输出设备2245。

总线2205统一地表示通信地连接计算机系统2200的众多内部设备的所有系统、外围设备和芯片组总线。例如，总线2205将(一个或多个)处理单元2210与只读存储器2230、系统存储器2225和永久存储设备2235通信地连接。

从这些各种存储器单元中，(一个或多个)处理单元2210检索要执行的指令和要处理的数据，以便执行本发明的处理。(一个或多个)处理单元在不同实施例中可以是单个处理器或多核心处理器。只读存储器(ROM)2230存储由(一个或多个)处理单元2210和计算机系统的其它模块所需要的静态数据和指令。另一方面，永久存储设备2235是读和写存储器设备。这个设备是即使当计算机系统2200关闭时也存储指令和数据的非易失性存储单元。本发明的一些实施例使用大容量存储设备(诸如磁或光盘及其对应的盘驱动器)作为永久存储设备2235。

其它实施例使用可去除存储设备(诸如软盘、闪存驱动器等)作为永久存储设备。与永久存储设备2235一样，系统存储器2225是读和写存储器设备。但是，与存储设备2235不同，系统存储器是易失性读和写存储器，诸如随机存取存储器。系统存储器存储处理器在运行时需要的一些指令和数据。在一些实施例中，本发明的处理被存储在系统存储器2225、永久存储设备2235和/或只读存储器2230中。从这些各种存储器单元中，(一个或多个)处理单元2210检索要执行的指令和要处理的数据，以便执行一些实施例的处理。

总线2205还连接到输入和输出设备2240和2245。输入设备使用户能够传递信息和选择到计算机系统的命令。输入设备2240包括字母数字键盘和定点设备(也称为“光标控制设备”)。输出设备2245显示由计算机系统生成的图像。输出设备包括打印机和显示设备，诸如阴极射线管(CRT)或液晶显示器(LCD)。一些实施例包括用作输入和输出设备两者的诸如触摸屏的设备。

最后，如图22所示，总线2205还通过网络适配器(图中未示出)将计算机系统2200耦合到网络2265。以这种方式，计算机可以是计算机的网络(诸如局域网(“LAN”)、广域网(“WAN”)、或内联网、或诸如互联网的网络的网络)的一部分，计算机系统2200的任何或所有组件可以与本发明结合使用。

一些实施例包括电子组件，诸如微处理器、在机器可读或计算机可读介质(可替代地称为计算机可读存储介质、机器可读介质或机器可读存储介质)中存储计算机程序指令的存储设备和存储器。这种计算机可读介质的一些示例包括RAM、ROM、只读压缩盘(CD-ROM)、可记录压缩盘(CD-R)、可重写压缩盘(CD-RW)、只读数字多功能盘(例如，DVD-ROM，双层DVD-ROM)、各种可记录/可重写DVD(例如，DVD-RAM、DVD-RW、DVD+RW等)、闪存存储器(例如，SD卡、小型SD卡、微型SD卡等)、磁和/或固态硬盘驱动器、只读和可记录Blu-盘、超密度光盘、任何其它光或磁介质、以及软盘。计算机可读介质可以存储可由至少一个处理单元执行的并且包括用于执行各种操作的指令集合的计算机程序。计算机程序或计算机代码的示例包括诸如由编译器产生的机器代码，以及包括由计算机、电子组件、或利用解释器的微处理器执行的更高级代码的文件。

虽然以上讨论主要指执行软件的微处理器或多核心处理器，但是一些实施例由一个或多个集成电路来执行，诸如专用集成电路(ASIC)或现场可编程门阵列(FPGA)。在一些实施例中，这种集成电路执行在该电路自身上存储的指令。

如在本说明书中所使用的，术语“计算机”、“服务器”、“处理器”、以及“存储器”都是指电子或其它技术设备。这些术语不包括人或人群。为了本说明书的目的，术语显示或正在显示意味着在电子设备上显示。如本说明书中所使用的，术语“计算机可读介质”、“多个计算机可读介质”和“机器可读介质”被完全限制为以由计算机可读的形式存储信息的、有形的、物理的对象。这些术语不包括任何无线信号、有线下载信号、以及任何其它短暂或临时信号。

虽然本发明已经参考许多特定细节进行了描述，但是本领域普通技术人员将认识到，在不脱离本发明的精神的情况下，本发明可以以其它特定形式体现。例如，几个图概念性地示出了处理。这些处理的特定操作可能没有以所示出和描述的确切顺序执行。特定操作可能没有在一系列连续的操作中执行，并且不同的特定操作可能在不同的实施例中执行。此外，处理可以使用若干子处理来实现，或者作为更大的宏处理的一部分来实现。因此，本领域普通技术人员将理解，本发明不受上述说明性细节的限制，而是由所附权利要求来定义。

Claims (24)

1.一种用于收集上下文属性以处理用于特定机器的服务规则的方法，所述特定机器在具有多个其它机器的主机计算机上执行，所述方法包括：

在所述特定机器之外并且在主机计算机上，

指示在所述主机计算机上执行的深度分组检查模块检查来自所述特定机器的特定数据消息流的数据消息的集合，以生成指定所述特定数据消息流的数据消息中包含的流量类型的第一标识符；

从在所述特定机器上执行的客户内省(GI)代理接收上下文属性集，所述上下文属性识别第一应用的第一处理，所述第一处理(i)在所述特定机器上执行并且(ii)生成所述特定数据消息流的数据消息；

使用所接收的上下文属性集来识别第二标识符，所述第二标识符识别生成所述特定数据消息流的数据消息的所述第一应用；以及

在所述主机计算机的存储装置中将所述第一和第二标识符存储为所述特定数据消息流的上下文属性，其中所述第一和第二标识符被存储为服务引擎的上下文属性，所述服务引擎在所述主机计算机上与所述特定机器分离地执行，所述上下文属性用于(i)识别可应用于所述特定数据消息流的基于上下文的服务规则，以及(ii)基于所识别的基于上下文的服务规则在所述特定数据消息流上执行基于上下文的服务。

2.如权利要求1所述的方法，还包括：

从所述特定机器接收网络事件的标识符，所述网络事件标识符(i)包括处理标识符，并且(ii)与特定数据消息流相关联；

其中接收上下文属性集包括使用处理标识符将处理查询发送到在所述特定机器上执行的GI代理并且响应于处理查询而接收上下文属性集。

3.如权利要求2所述的方法，其中接收网络事件标识符包括从所述特定机器的GI代理接收网络事件标识符。

4.如权利要求2所述的方法，其中所述特定机器是虚拟机(VM)，并且GI代理被安装在VM上。

5.如权利要求2所述的方法，其中所述特定机器是容器，并且GI代理是在容器的存储空间内执行的模块。

6.如权利要求2所述的方法，还包括：

执行过滤操作以从所接收的上下文属性集中移除与在所述主机计算机上强制执行的基于上下文的服务规则无关的至少一个上下文属性；

其中将所述第一和第二标识符存储为上下文属性包括存储不包括被移除的上下文属性的经过滤的上下文属性集。

7.如权利要求6所述的方法，其中执行过滤操作包括(i)将上下文属性集中的上下文属性与用于在主机计算机上强制执行的服务规则的属性进行比较，以识别所接收的集合中未在任何服务规则中使用的任何上下文属性，并且(ii)丢弃未在任何服务规则中使用的任何识别出的上下文属性。

8.如权利要求2所述的方法，其中接收到的上下文属性集包括：

以下各项中的至少一个：(i)在所述特定机器上执行并且与所述特定数据消息流相关联的特定处理的名称、(ii)所述特定处理的散列、(iii)用于所述特定处理的具有命令行参数的路径、以及(iv)由所述特定处理加载的模块。

9.如权利要求1所述的方法，其中接收所述上下文属性集包括接收识别所述第一处理的标识符，所述方法还包括：在所述特定机器之外并且在所述主机计算机上使用所述第一处理的标识符来获得所述第二标识符。

10.如权利要求9所述的方法，其中所述第一处理的标识符是所述处理的散列，并且所述第二标识符包括所述第一应用的名称，所述名称由所述服务引擎用于与服务规则的规则标识符匹配。

11.如权利要求1所述的方法，其中所述第一标识符是由所述深度分组检查模块产生的AppID，用于识别流量的类型。

12.如权利要求1所述的方法，其中在所述主机计算机的存储装置中将所述第一和第二标识符存储为上下文属性还包括：

将所接收的上下文属性集存储在所述主机计算机的存储装置中。

13.一种存储程序的非瞬态机器可读介质，所述程序用于存储属性以处理用于特定机器的服务规则，所述特定机器在具有多个其它机器的主机计算机上执行，所述程序与所述特定机器分离地执行，所述程序包括用于以下的指令集：

指示在所述主机计算机上执行的深度分组检查模块检查来自所述特定机器的特定数据消息流的数据消息的集合，以生成指定所述特定数据消息流的数据消息中包含的流量类型的第一标识符；

从在所述特定机器上执行的客户内省(GI)代理接收上下文属性集，所述上下文属性识别第一应用的第一处理，所述第一处理(i)在所述特定机器上执行并且(ii)生成所述特定数据消息流的数据消息；

使用所接收的上下文属性集来识别第二标识符，所述第二标识符识别生成所述特定数据消息流的数据消息的所述第一应用；以及

在所述主机计算机的存储装置中将所述第一和第二标识符存储为所述特定数据消息流的上下文属性，其中所述第一和第二标识符被存储为服务引擎的上下文属性，所述服务引擎在所述主机计算机上与所述特定机器分离地执行，所述上下文属性用于(i)识别可应用于所述特定数据消息流的基于上下文的服务规则，以及(ii)基于所识别的基于上下文的服务规则在所述特定数据消息流上执行基于上下文的服务。

14.如权利要求13所述的非瞬态机器可读介质，其中所述程序还包括用于从所述特定机器接收网络事件的标识符的指令集，所述网络事件标识符(i)包括处理标识符，并且(ii)与特定数据消息流相关联，其中用于接收上下文属性集的指令集包括用于使用处理标识符将处理查询发送到在所述特定机器上执行的GI代理并且响应于处理查询而接收上下文属性集的指令集。

15.如权利要求14所述的非瞬态机器可读介质，其中用于接收网络事件标识符的指令集包括用于从所述特定机器的GI代理接收网络事件标识符的指令集。

16.如权利要求14所述的非瞬态机器可读介质，其中所述特定机器是虚拟机(VM)，并且GI代理被安装在VM上。

17.如权利要求14所述的非瞬态机器可读介质，其中所述特定机器是容器，并且GI代理是在容器的存储空间内执行的模块。

18.如权利要求14所述的非瞬态机器可读介质，其中所述程序还包括用于执行过滤操作以从所接收的上下文属性集中移除与在所述主机计算机上强制执行的基于上下文的服务规则无关的至少一个上下文属性的指令集，其中将所述第一和第二标识符存储为上下文属性包括存储不包括被移除的上下文属性的经过滤的上下文属性集。

19.如权利要求18所述的非瞬态机器可读介质，其中用于执行过滤操作的指令集包括用于以下的指令集：

将所接收的上下文属性集中的上下文属性与用于在主机计算机上强制执行的服务规则的属性进行比较，以识别所述集合中未在任何服务规则中使用的任何上下文属性；以及

丢弃未在任何服务规则中使用的任何识别出的上下文属性。

20.如权利要求14所述的非瞬态机器可读介质，其中接收到的上下文属性集包括：

以下各项中的至少一个：(i)在所述特定机器上执行并且与所述特定数据消息流相关联的特定处理的名称、(ii)所述特定处理的散列、(iii)用于所述特定处理的具有命令行参数的路径、以及(iv)由所述特定处理加载的模块；以及

以下各项中的至少一个：(i)与所述特定处理相关联的产品名称、(ii)与所述特定处理相关联的产品版本，以及(iii)与由该特定处理消耗的资源相关联的至少一个消耗参数。

21.如权利要求20所述的非瞬态机器可读介质，其中所消耗的资源是中央处理单元消耗、网络消耗和存储器消耗中的至少一个。

22.如权利要求13所述的非瞬态机器可读介质，其中所述程序还包括用于从主机计算机上的威胁检测器获得第一处理的威胁级别指示并将威胁级别指示与所述第一和第二标识符一起存储为上下文属性的指令集。

23.一种电子设备，包括：

一组处理单元；以及

存储程序的机器可读介质，所述程序在被所述处理单元中的至少一个执行时实现如权利要求1-12中任一项所述的方法。

24.一种用于收集上下文属性以处理用于特定机器的服务规则的系统，所述特定机器在具有多个其它机器的主机计算机上执行，所述系统包括用于实现如权利要求1-12中任一项所述的方法的装置。