CN111130953B - Vnf可用性监测方法、设备及介质 - Google Patents

Abstract

本公开提供了一种通用用户端设备上的VNF可用性监测方法，包括：定期发送服务状态请求报文，所述服务状态请求报文包括VNF的服务状态上报间隔；监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文，所述服务状态回复报文包括VNF的服务可用状态；响应于监测到所述各虚拟网络接口在预设时间内接收到服务状态回复报文，根据与所述服务状态回复报文对应的虚拟网络接口确定所述服务状态回复报文与VNF的对应关系；以及根据所述对应关系确定接收到服务状态回复报文的VNF的服务状态是否可用。还提供了一种通用用户端设备、VNF、电子设备及计算机可读存储介质。

Description

VNF可用性监测方法、设备及介质

技术领域

本公开涉及计算机技术领域，更具体地，涉及一种VNF(虚拟网元)可用性监测方法、通用用户端设备、VNF、电子设备及计算机可读存储介质，还涉及一种计算机程序产品。

背景技术

通用用户端设备(uCPE，universal Customer Premises Equipment)使用通用硬件平台并提供虚拟化功能，包括在开放服务器上托管的标准操作系统上运行的虚拟网络功能/虚拟网元(VNF)，形成了一种新的网络设备产品形态。当前uCPE越来越广泛地应用软件定义广域网(SDWAN)接入、一体化安全网关以及云安全资源池等场景。

通常，uCPE中的VNF会根据业务编排组成服务链，形成一个业务功能。如使用防火墙，入侵防护系统(IPS，Intrusion Protect Systems)，入侵检测系统(IDS，IntrusionDetection Systems)，探针等各种功能的VNF，形成一个特定流量的安全业务链。uCPE平台将流量传递给服务链，流量将流经这些VNF结点，各个VNF结点完成各自业务处理。

在实现本公开构思的过程中，发明人发现现有技术中至少存在如下问题：当业务链中的某个VNF出现故障时，如VNF内某个关键进程死锁或崩溃，或者出现内存接收耗尽等情况，此时VNF在uCPE平台看来仍然是运行(RUNNING)状态，接口都处于正常连接(LINK-ON)状态，但该VNF业务已不可用，导致不能将流量传递给该VNF，会引起流量断流或其他业务故障，影响用户正常网络业务访问。

另外VNF在启动过程或恢复重启过程中，正在加载配置，特别是用于安全业务的VNF，需要加载大量配置如各种对象、安全管理策略、以及平面转换(IPS)、深度包检测(DPI)、反病毒(AV)特征库等，需要等待很长时间才能完成配置加载，此时VNF在uCPE平台看来已经是RUNNING状态，VNF的网络接口在uCPE平台看来是正常的LINK-ON状态，并且二三层也转发正常，但是如果此时过早的将流量传递给VNF，也将导致业务断流。

因此需要一种能够使uCPE监测VNF业务可用性状态的方法，并且能够及时地改变流量的引流，从而保证业务的连续性和可用性。

发明内容

有鉴于此，本公开提供了一种VNF可用性监测方法、通用用户端设备、VNF、电子设备及计算机可读存储介质，还提供了一种计算机程序产品。

本公开的第一个方面提供了一种VNF可用性监测方法，应用于通用用户端设备，所述通用用户端设备用于运行多个VNF，所述通用用户端设备设置有与各VNF分别连接的多个虚拟网络接口，所述方法包括：定期发送服务状态请求报文，所述服务状态请求报文包括VNF的服务状态上报间隔；监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文，所述服务状态回复报文包括VNF的服务可用状态；响应于监测到所述各虚拟网络接口在预设时间内接收到服务状态回复报文，根据与所述服务状态回复报文对应的虚拟网络接口确定所述服务状态回复报文与VNF的对应关系；以及根据所述对应关系确定接收到服务状态回复报文的VNF的服务状态是否可用。

根据本公开的实施例，所述方法还包括：响应于监测到多个虚拟网络接口之一在预设时间内未接收到服务状态回复报文，确定与虚拟网络接口对应的VNF的服务状态不可用。

根据本公开的实施例，所述方法还包括：标记多个VNF中处于开启状态的VNF的初始服务状态为不可用；以及响应于监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文的结果，更新各个VNF的服务状态。

根据本公开的实施例，所述服务状态请求报文和所述服务状态回复报文均采用二层以太网报文格式。

根据本公开的实施例，响应于VNF的服务状态不可用，所述通用用户端设备切断用于分发给当前服务状态不可用的VNF的流量。

本公开的第二个方面提供了一种VNF可用性监测方法，包括：接收服务状态请求报文，所述服务状态请求报文包括VNF的服务状态上报间隔；VNF监控自身服务状态是否可用；根据监控结果确定要上报的VNF的服务可用状态；以及按照所述服务状态上报间隔定期发送服务状态回复报文，所述服务状态回复报文包括VNF的服务可用状态。

本公开的第三个方面提供了一种通用用户端设备，所述通用用户端设备用于运行多个VNF，所述通用用户端设备设置有与各VNF分别连接的多个虚拟网络接口，所述通用用户端设备包括：第一报文发送模块，用于定期发送服务状态请求报文，所述服务状态请求报文包括VNF的服务状态上报间隔；第一报文接收模块，用于监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文，所述服务状态回复报文包括VNF的服务可用状态；报文与VNF对应关系确定模块，用于响应于监测到所述各虚拟网络接口在预设时间内接收到服务状态回复报文，根据所述服务状态回复报文对应的虚拟网络接口确定所述服务状态回复报文与VNF的对应关系；以及服务状态确定模块，用于根据所述对应关系确定接收到服务状态回复报文的VNF的服务状态是否可用。

根据本公开的实施例，所述通用用户端设备为多个VNF配置有内部管理接口，所述内部管理接口连接至同一内部管理网络；其中，所述内部管理网络通过所述虚拟网络接口与各VNF的内部管理接口进行连接。

根据本公开的实施例，所述通用用户端设备还包括：初始服务状态标记模块，用于标记各个处于开启状态的VNF的初始服务状态为不可用；以及服务状态更新模块，用于响应于监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文的结果，更新各个VNF的服务状态。

本公开的第四个方面提供了一种VNF，包括：第二报文接收模块，用于接收服务状态请求报文，所述服务状态请求报文包括VNF的服务状态上报间隔；服务状态监控模块，用于监控VNF服务状态是否可用；服务状态确定模块，用于根据监控结果确定要上报的VNF的服务可用状态；以及第二报文发送模块，按照所述服务状态上报间隔定期发送服务状态回复报文，所述服务状态回复报文包括VNF的服务可用状态。

本公开的第五个方面提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行本公开提及的任一种方法。

本公开的第六个方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

本公开的第七个方面提供了一种计算机程序产品，包括计算机可读指令，所述指令在被执行时用于实现如上所述的方法。

根据本公开的实施例，可以至少部分地解决由于业务链中的某个VNF出现故障、正在启动或恢复重启过程中导致的流量分发无效的问题，通过uCPE定期发送服务状态请求报文，并接收业务链中各个VNF的服务状态回复报文，报文中携带有VNF的服务可用状态，从而能够实时获知各个VNF真实的服务状态是否可用。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的VNF可用性监测方法和通用用户端设备的应用场景；

图2示意性示出了根据本公开实施例所示的在uCPE上设置与各VNF分别连接的多个虚拟网络接口的示意图；

图3示意性示出了根据本公开实施例的uCPE与VNF之间的协议报文交互方式示意图；

图4示意性示出了根据本公开实施例的应用于uCPE的VNF可用性监测方法的流程图；

图5示意性示出了在图4示意流程图之上还包括的实施步骤流程图；

图6示意性示出了根据本公开实施例的应用于VNF的VNF可用性监测方法的流程图；

图7示意性示出了根据本公开实施例所示的二层以太网报文的协议报文格式示例；

图8示意性示出了根据本公开实施例所示的长度可变数据变量(Variable-LengthData)的组成形式示例；

图9示意性示出了根据本公开实施例所示的选项(Option)的编码格式示例；

图10示意性示出了根据本公开实施例所示的选项(Option)的定义示例。

图11示意性示出了根据本公开实施例所示的uCPE的结构框图。

图12示意性示出了根据本公开实施例所示的VNF的结构框图。

图13示意性示出了根据本公开实施例所示的依据VNF可用性监测方法在uCPE上给多个VNF分配流量的示意图；以及

图14为根据本公开一实施例所示的电子设备的示意图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

本公开的第一个示例性实施例提供了一种VNF可用性监测方法，本实施例的监测方法应用于通用用户端设备，该通用用户端设备用于运行多个VNF，并且通用用户端设备设置有与各VNF分别连接的多个虚拟网络接口。

图1示意性示出了根据本公开实施例的VNF可用性监测方法和通用用户端设备的应用场景。

参照图1所示，在一场景中，通用用户端设备(uCPE)用于运行多个虚拟网元(VNF)，内部设置有内部管理网络(或者也称内部管理平台)，用于管理各个虚拟网元VNF的任务发放。示例性的，图1中示意了四个VNF，分别表示为VNF1、VNF2、VNF3和VNF4，其中，各个VNF的功能可以相同，也可以不同，例如相同形状示意的VNF的功能相同，以不同形状示意的VNF的功能不同，比如以椭圆形示意的VNF1和VNF2功能相同，各个VNF的功能例如以矩形、三角形和椭圆分别示意的VNFVNF1、VNF3和VNF4的功能各不相同。

在uCPE进行任务发放时，对应各个VNF的功能不同，内部管理网络根据业务编排为各个VNF发放流量，以执行对应功能的业务，从而各个VNF根据业务编排会形成一个服务链，由服务链整体组成一个业务功能。例如继续参照图1所示，业务1通过编排分为四个功能执行过程，分别为业务1a、业务1b、业务1c和业务1d，业务1a、业务1b、业务1c和业务1d被对应分发至VNF1、VNF2、VNF3和VNF4，各个VNF根据业务编排会形成一个服务链，功能执行顺序在图1中以空心粗箭头进行示意。例如使用防火墙(FW)、入侵防护系统(IPS，IntrusionProtect Systems)、入侵检测系统(IDS，Intrusion Detection Systems)、以及探针等各种功能的VNF，形成一个特定流量的安全业务链。

正常情况下，各个VNF提供各自的功能服务，按照执行顺序完成各自的功能，从而由上述服务链输出的业务正常输出。在一些情况下，比如，某个VNF发生故障，比如由于VNF内某个关键进程发生死锁或者崩溃，或者出现内存接收耗尽等情况导致故障，例如图1中示意的VNF2发生故障，或者某个VNF在启动或者处于重启状态下，需要加载大量的配置，此时无法实际去执行由内部管理网络分发的对应任务，即尽管接收到了任务，但是不具备提供服务的能力，无法进行执行，因此，此时该发生故障或者处于启动/重启状态的VNF对应的服务状态是不可用的，由于现有技术中不存在监测VNF实际状态的方法或者对应功能模块，因此在uCPE的内部管理平台上显示的实际发生故障的VNF2仍然处于运行状态(实际服务状态不可用)，接口也处于正常的连接状态，还按照正常情况下进行分发流量，由此会导致业务断流或者其他业务故障，影响用户对网络业务进行正常访问。

因此，基于上述场景下发现的问题，传统的uCPE的内部管理平台只能看到VNF的运行(Running)状态，无法监测到VNF真实的服务状态是否可用，因此本公开提供了一种VNF可用性监测方法，通过uCPE定期发送服务状态请求报文，并接收业务链中各个VNF的服务状态回复报文，报文中携带有VNF(VNF)的服务可用状态，从而能够实时获知各个VNF真实的服务状态是否可用，以便于停止对不可用VNF供应流量，避免流量断流或其他业务故障，从而避免了某个VNF由于服务状态不可用而影响用户对于网络业务的正常访问，保证了流量的正确分发。

下面先对本公开的uCPE内部管理网络如何管理各个VNF进行介绍。

图2示意性示出了根据本公开实施例所示的在uCPE上设置与各VNF分别连接的多个虚拟网络接口的示意图。

参照图2所示，本实施例中，以VNF1用于执行FW(防火墙)业务，VNF2用于执行IPS(入侵防护系统)业务，VNF3用于执行IDS(入侵检测系统)业务作为示例。

在uCPE上为每个VNF分配一个用于内部管理的内部管理接口，例如图2中示意的分别为VNF1、VNF2和VNF3均配置了一个内部管理接口，对应的各个VNF的内部管理接口分别以E01、E02和E03表示。

在一实施例中，uCPE为多个VNF配置有内部管理接口，该内部管理接口连接至同一内部管理网络。其中，内部管理网络通过所述虚拟网络接口与各VNF的内部管理接口进行连接。

参照图2所示，在uCPE上将所有VNF的内部管理接口连接到uCPE的同一内部管理网络/内部管理平台，并且在uCPE上建立内部管理网络VLAN的多个虚拟网络接口，例如图2示意的虚拟网络接口1一端连接至内部管理网络的虚拟接口Vlan 4095，另一端连接至VNF1的内部管理接口E01；虚拟网络接口2Vlan一端连接至内部管理网络的虚拟接口Vlan 4095，另一端连接至VNF2的内部管理接口E02；虚拟网络接口3的一端连接至内部管理网络的虚拟接口Vlan 4095，另一端连接至VNF3的内部管理接口E03。上述虚拟网络接口1-3为用于各个VNF与内部管理网络进行数据传输连接的数据接口。各个虚拟网络接口1-3能够使得内部管理网络Vlan辨识接收的是哪一个VNF传输的信息。

接下来结合附图对本实施例的VNF可用性监测方法进行详细介绍。

图3示意性示出了根据本公开实施例的uCPE与VNF之间的协议报文交互方式示意图；图4示意性示出了根据本公开实施例的应用于uCPE的VNF可用性监测方法的流程图。

结合图3和图4所示，先从uCPE一侧来描述，本实施例的VNF可用性监测方法包括以下步骤S11，步骤S12，步骤S13-1和步骤S14。

在步骤S11中，定期发送服务状态请求报文，服务状态请求报文包括VNF的服务状态上报间隔。

该步骤S11中，在一实施例中，uCPE直接通过二层以太网报文的协议格式进行传输，即服务状态请求报文通过二层以太网报文的协议格式进行传输。下面介绍的步骤S12中，服务状态回复报文也采用二层以太网报文的协议格式进行传输。这种传输方式不依赖于网络层地址的配置参数，可以有效减少配置步骤，并且不需要复杂的应用层服务。

下面结合图7-图10来介绍该实施例二层以太网报文的格式定义。

图7示意性示出了根据本公开实施例所示的二层以太网报文的协议报文格式示例。

由于计算机编码中采用的为英文，因此在图7中以对应编码的英文形式进行示意，英文对应的中文翻译会在描述中进行解释。“MAC地址”称为物理地址或硬件地址，后面直接采用MAC地址的表述。如图7所示，二层以太网共有16个字节，分别对应数字0、1、2、……、14和15。

Destination MAC Address表示目的MAC地址，占据6字节，在uCPE向特定VNF发送时为单播MAC地址，否则为组播MAC地址。组播MAC地址可以是：51:41:58:71:61:78或51:41:58:72:62:79。

Source MAC Address表示源MAC地址，为6字节，为发送方发送接口的实MAC地址。

Ethtype表示以太网类型的字段及值，占据2字节，一般取固定值0X90FA。

Ver表示协议版本号，占据1字节，在一实例中，该协议版本号取值为1，在其它实施例中，对应的协议号可以根据实际情况进行变化。

Op表示操作类型，占据1字节。

其中，Op＝1表示服务状态请求(Service-Status-Request)，

Op＝2表示服务状态回复(Service-Status-Reply)。

Id表示地址，为网络字节序，占据4字节，每次发包应当自增1，从0开始。

Length表示Variable-Length Data的长度之和，为网络字节序，占据2字节，取值为0-1490。

Variable-Length Data表示长度可变数据变量，其占据的字节数可以变化。

参照图7所示的二层以太网报文格式，Destination MAC Address、Source MACAddress和Ethtype均为以太网首部字段，表明目的MAC地址、源MAC地址和以太网类型。后面的信息为该协、议报文携带的信息内容。

图8示意性示出了根据本公开实施例所示的长度可变数据变量(Variable-LengthData)的组成形式示例。

下面参照图8来介绍长度可变数据变量的组成。长度可变数据变量(Variable-Length Data)包括0个、1个或多个选项(Option)，如图8所示，分别以Option Type 1、Option Type 2、……、Option Type N进行示例。

图9示意性示出了根据本公开实施例所示的选项(Option)的编码格式示例。图10示意性示出了根据本公开实施例所示的选项(Option)的定义示例。

下面参照图9和图10来介绍Option的编码格式以及定义。

参照图9所示，Option Type表示选项类，占据2字节。Option Length表示选项长度，为网络字节序，占据2字节。Option Value表示选项值，如果是整数类型，应该是网络字节序；如果是字符串，应该包括字符串终结符’\0’。

参照图10所示，本实施例中，用到的选项有两类，分别为Option1和Option 2。

其中，Option 1表示服务可用状态，用于在服务状态回复(Service-Status-Reply)中回复VNF的服务是否可用。Option 1的Option Length为2字节。Option 1的选项值为2字节整型，0表示服务状态可用，1表示服务状态不可用。VNF的服务是否可用的情况由各个VNF内部自行进行定义和监控，比如VNF可以根据一些内部的关键元件或者根据一些进程的监控情况是否正常来确定自身的服务状态是否可用。

Option 2表示服务状态上报间隔，用于通知VNF上报服务状态的间隔。Option 2的Option Length为2字节。Option 2的选项值为2字节整型，单位为毫秒，取值范围为50-60000。

在一实施例中，参照图3所示，两条虚线表示时间轴，uCPE要定期发送服务状态请求报文，该服务状态请求报文包括基本的目的MAC地址、源MAC地址和以太网类型之外，携带的信息内容包括：VNF的服务状态上报间隔，即Option 2。

在一实例中，例如可以在uCPE定时器1上设置定时参数，以确定发送服务状态请求报文的时间间隔，另外，还可以在uCPE上配置VNF定时器1以及VNF定时器2等定时器的时间参数，以定义好或者设定好各个VNF的服务状态上报间隔。图3中以uCPE定时器1界定发送的时间间隔，以VNF定时器1界定VNF1的服务状态上报间隔，例如VNF定时器1界定的上报间隔对应服务准备就绪后的上报间隔时间，该时间可以等于或不等于VNF定时器2的时间。以VNF定时器2界定VNF2的服务状态上报间隔，该VNF定时器2界定的上报间隔对应。一般默认设置为1000ms(毫秒)，当然，上述数值仅作为示例，具体数值可以在uCPE定时器1上进行设置(定义)。

在一场景中，由uCPE向多个VNF同时发送服务状态请求报文，此时对应的目的MAC地址为：组播MAC地址，选用51:41:58:71:61:78。源MAC地址填写uCPE内部管理网络(内部管理平台)VLAN的MAC地址，比如图2中示例的Vlan 4095。报文携带的选项(Option)类型为：Option 2，例如服务状态上报间隔的时间值为S，则Option 2用于通知VNF将服务状态上报间隔调整为S。

在步骤S12中，监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文，服务状态回复报文包括VNF的服务可用状态。

参照图3所示，由uCPE向多个VNF同时发送服务状态请求报文，对应在多个VNF接收到服务状态请求报文后，各VNF会按照服务状态请求报文中要求的服务状态上报间隔S向uCPE发送服务状态回复报文，服务状态回复报文中携带的信息包括VNF的服务可用状态。

在一实例中，参照图3所示，可以由uCPE监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文。预设时间例如可以设置为：VNF定时器2的整数倍，例如选为3倍。

在步骤S13-1中，响应于监测到各虚拟网络接口在预设时间内接收到服务状态回复报文，根据与服务状态回复报文对应的虚拟网络接口确定服务状态回复报文与VNF的对应关系。

结合图2和图3所示，不同的虚拟网络接口1-3分别与各个VNF1-3对应连接，那么各个虚拟网络接口在预定时间内接收到服务状态回复报文时，会辨识出接收到服务状态回复报文的虚拟网络接口对应哪一个VNF，从而确定服务状态回复报文与VNF的对应关系。uCPE的内部管理网络通过虚拟网络接口1接收到服务状态回复报文，可以确定该服务状态回复报文对应VNF1。

在步骤S14中，根据对应关系确定接收到服务状态回复报文的VNF的服务状态是否可用。

比如，根据上述对应关系可以确定接收到服务状态回复报文的VNF是哪一个，该VNF的服务状态回复报文中携带了服务状态可用信息，服务状态可用信息例如为服务状态可用，或者为服务状态不可用，从而在uCPE中记录该VNF的服务状态是否可用。

在一实施例中，参照图4所示，上述方法还包括步骤S13-2，在步骤S13-2中，响应于监测到多个虚拟网络接口之一在预设时间内未接收到服务状态回复报文，确定与虚拟网络接口对应的VNF的服务状态不可用。

在一实施例中，如果如果uCPE长时间未收到VNF的服务状态回复报文(Service-Status-Reply)报文，在uCPE上的该VNF的状态标记为不可用。

图5示意性示出了在图4示意流程图之上还包括的实施步骤流程图。

在另一实施例中，参照图5所示，该方法还包括以下步骤S15和步骤S16。

在步骤S15中，标记多个VNF中处于开启状态的VNF的初始服务状态为不可用。

在uCPE上启动VNF后，应当标记各个VNF为服务不可用状态。此时过需要等待步骤S12的监测结果，然后根据各个VNF的服务状态是否可用来确定分发流量的操作，以避免由于过早分发流量或者不清楚各个VNF的服务状态是否可用就分发流量造成的业务故障或者流量中断的问题。

在步骤S16中，响应于监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文的结果，更新各个VNF的服务状态。

步骤S16与步骤S12存在逻辑的先后关系，步骤S16是根据步骤S12得到的监测结果来更新各个VNF的服务状态。

监测结果包括如下情况的其中一种：(a)多个虚拟网络接口之一在预设时间内未接收到服务状态回复报文，则在uCPE中将该虚拟网络接口对应的VNF的服务状态继续标记为不可用；(b)在预设时间内接收到服务状态回复报文，在报文内容为可用的情况下，在uCPE中更新对应VNF的服务状态的标记为可用；(c)在预设时间内接收到服务状态回复报文，在报文内容为不可用的情况下，在uCPE中更新对应VNF的服务状态的标记为不可用。

根据本公开的实施例，在确定了各个VNF的服务状态的情况下，响应于VNF的服务状态不可用，通用用户端设备切断用于分发给当前服务状态不可用的VNF的流量。

本公开的第二个示例性实施例提供了一种VNF可用性监测方法，本实施例的监测方法应用于VNF。

图6示意性示出了根据本公开实施例的应用于VNF的VNF可用性监测方法的流程图。

参照图6所示，本实施例从VNF一侧来描述该监测方法，包括步骤S21、步骤S22、步骤S23和步骤S24。

在步骤S21中，接收服务状态请求报文，服务状态请求报文包括VNF的服务状态上报间隔。

结合图3和图6所示，在一应用场景中，在多个VNF接收到由于uCPE发送的服务状态请求报文后，记录下Option 2中的服务状态上报间隔值S，以及报文源MAC地址，为了后面描述方便，该场景后续描述将报文源MAC地址采用M表示。

在步骤S22中，VNF监控自身服务状态是否可用。

在一实施例中，VNF的服务是否可用的情况由各个VNF内部自行进行定义和监控，比如VNF可以根据一些内部的关键元件或者根据一些进程的监控情况是否正常来确定自身的服务状态是否可用。

在步骤S23中，根据监控结果确定要上报的VNF的服务可用状态。

在一实施例中，VNF根据监控结果确定要上报的VNF的服务可用状态为：服务状态可用，或者为服务状态不可用。

在步骤S24中，按照服务状态上报间隔定期发送服务状态回复报文，服务状态回复报文包括VNF的服务可用状态。

如图3所示，在一实例中，在某个VNF的监控结果为服务状态不可用时，该VNF可按照VNF定时器2设置的时间间隔定时向uCPE发送三次服务状态回复报文，即发送报文携带的信息为：Option 1，根据一实施例的定义，此时Option 1的值为0。在该VNF发送三次上述服务状态回复报文之后，停止发送服务状态回复报文。等待服务再次准备就绪之后，再重新开始发送服务状态回复报文，服务状态回复报文的内容根据自身监控结果进行更新。

在一些特殊情况下，例如，一些VNF不支持上述协议格式，可以在uCPE中标记该VNF为不支持，在VNF中忽略丢弃此种报文。选用其它支持的VNF进行监测。从而使得uCPE可以根据监测结果分发流量，避免业务发生故障以及流量中断的问题。

本公开的第三个示例性实施例提供了一种通用用户端设备，该通用用户端设备用于运行多个VNF，通用用户端设备设置有与各VNF分别连接的多个虚拟网络接口。

图11示意性示出了根据本公开实施例所示的uCPE的结构框图。

本实施例中，参照图11所示，该通用用户端设备包括：第一报文发送模块31、第一报文接收模块32、报文与VNF对应关系确定模块33以及服务状态确定模块34。

其中，第一报文发送模块31，用于定期发送服务状态请求报文，服务状态请求报文包括VNF的服务状态上报间隔。第一报文接收模块32，用于监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文。服务状态回复报文包括VNF的服务可用状态。报文与VNF对应关系确定模块33，用于响应于监测到各虚拟网络接口在预设时间内接收到服务状态回复报文，根据服务状态回复报文对应的虚拟网络接口确定服务状态回复报文与VNF的对应关系。服务状态确定模块34，用于根据对应关系确定接收到服务状态回复报文的VNF的服务状态是否可用。

根据本公开的实施例，通用用户端设备(uCPE)为多个VNF配置有内部管理接口E0(分别在图2中示意为E01、E02和E03)，内部管理接口连接至同一内部管理网络VLAN。其中，内部管理网络通过虚拟网络接口与各VNF的内部管理接口进行连接。

根据本公开的实施例，在一实施例中，通用用户端设备还包括初始服务状态标记模块35和服务状态更新模块36。其中初始服务状态标记模块35，用于标记各个处于开启状态的VNF的初始服务状态为不可用。服务状态更新模块36，用于响应于监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文的结果，更新各个VNF的服务状态。

本公开的第四个示例性实施例提供了一种VNF。

图12示意性示出了根据本公开实施例所示的VNF的结构框图。

参照图12所示，本实施例的VNF包括第二报文接收模块41、服务状态监控模块42、服务状态确定模块43以及第二报文发送模块44。其中第二报文接收模块41，用于接收服务状态请求报文。服务状态请求报文包括VNF的服务状态上报间隔。服务状态监控模块42，用于监控VNF服务状态是否可用。服务状态确定模块43，用于根据监控结果确定要上报的VNF的服务可用状态。第二报文发送模块44，按照服务状态上报间隔定期发送服务状态回复报文。服务状态回复报文包括VNF的服务可用状态。

根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，第一报文发送模块31、第一报文接收模块32、报文与VNF对应关系确定模块33、服务状态确定模块34、初始服务状态标记模块35以及服务状态更新模块36中的任意多个可以合并在一个模块中实现，第二报文接收模块41、服务状态监控模块42、服务状态确定模块43以及第二报文发送模块44中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，第一报文发送模块31、第一报文接收模块32、报文与VNF对应关系确定模块33、服务状态确定模块34、初始服务状态标记模块35以及服务状态更新模块36中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，第二报文接收模块41、服务状态监控模块42、服务状态确定模块43以及第二报文发送模块44中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

下面结合一具体应用场景来介绍本公开实施例的VNF可用性监测方法的应用过程。

图13示意性示出了根据本公开实施例所示的依据所述VNF可用性监测方法在uCPE上给多个VNF分配流量的示意图。

参照图13所示，本实例中，三台相同规格的基于视觉的页面分割算法(vIPS)VNF组成一个vIPS负载均衡备份组，兼有备份和负载均衡功能。图13可以结合图2来看，在图2中已经描述过的内容这里不再赘述。

uCPE内部管理网络/平台将收到的流量通过HASH算法负载分担到三台VNF上。HASH(哈希值)值为0的流量交给VNF1处理，HASH值为1的流量交给VNF2处理，HASH值为3的流量交给VNF3处理，图12分别以带箭头的点划线示意VNF的流量输入/输出通道，VNF1、VNF2和VNF3分别对应的流量输入/输出接口为：E11/E12、E21/E22以及E31/E32，流量输入/输出通道右侧的数字分别对应各个输入输出通道上流量的哈希值。本实施例中，外部流量从接口ge1入，从ge2流出，对称地，或从ge2流入，ge1流出。接口ge1和ge2可以在uCPE的内部网络平台进行配置。

下面结合图13以及上述介绍的VNF可用性监测方法的来描述本实例场景下的操作过程。

在操作(a)中，uCPE内部管理网络(后续称之为cCPE平台)定期从平台接口Vlan4095发送服务状态请求(Service-Status-Request)报文，uCPE定时器1的时间间隔采用默认值。

在操作(b)中，vIPS负载均衡备份组创建时，uCPE平台将组中各个VNF状态标记/记录为服务不可用状态。此时没有状态可用VNF，流量不能分发给VNF。否则会引起业务中断。

在操作(c)中，各个VNF启动之后开始从E0接口接收服务状态请求(Service-Status-Request)报文，并根据服务状态请求报文中的参数配置自身运行参数，参数包括：VNF定时器1时间间隔，VNF定时器2时间间隔等。

在操作(d)中，各个VNF配置加载过程完成之后开始VNF开始检查自身状态，如果各个组件已经准备应绪，按照VNF定时器1时间间隔，通过E0接口发送Service-Status-Reply报告服务状态可用。

在操作(e)中，uCPE平台收到第一个VNF(例如为VNF1)的服务状态回复(Service-Status-Reply)报告服务状态可用后，标记该VNF为可用，将HASH模数改为1，将流量负载给该VNF。依次地，组内其他VNF通过服务状态回复(Service-Status-Reply)报告服务状态可用后，将HASH模数改为当前可用VNF数量，将流量负载给组内所有可用VNF。

在操作(f)中，VNF周期性检查/监控自身状态。如果检查/监控自身工作状态正常，并非故障或者处理启动/重启等配置的过程，则通过E0接口发送服务状态回复(Service-Status-Reply)报告服务状态可用。

在操作(g)中，VNF如果发现自身不能满足正常工作条件，则通过E0接口发送三个服务状态回复(Service-Status-Reply)报告服务状态不可用。uCPE平台收到后，修改该VNF状态为不可用，并将HASH模数减一。uCPE平台的流量将不再分发给该不可用的VNF，其他VNF起到了备份作用。

在操作(h)中，如果VNF整个CRASH(崩溃)停机，uCPE平台不能定时收到Service-Status-Reply报文，超时检测机制会发现该VNF不可用，uCPE平台会修改该VNF状态为不可用，并将HASH模数减一，将流量负载到其他VNF上。

本公开的第五个示例性实施例提供了一种电子设备。

本实施例的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，其中，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器执行本公开提及的任一种方法。

图14为根据本公开一实施例所示的电子设备的示意图。图14示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图14所示，本实施例中，电子设备5包括处理器501，其可以根据存储在只读存储器(ROM)502中的程序或者从存储部分508加载到随机访问存储器(RAM)503中的程序而执行各种适当的动作和处理。处理器501例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器501还可以包括用于缓存用途的板载存储器。处理器501可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 503中，存储有电子设备5操作所需的各种程序和数据。处理器501、ROM 502以及RAM 503通过总线504彼此相连。处理器501通过执行ROM 502和/或RAM 503中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM502和RAM 503以外的一个或多个存储器中。处理器501也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，电子设备5还可以包括输入/输出(I/O)接口505，输入/输出(I/O)接口505也连接至总线504。电子设备5还可以包括连接至I/O接口505的以下部件中的一项或多项：包括键盘、鼠标等的输入部分506；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分507；包括硬盘等的存储部分508；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至I/O接口505。可拆卸介质511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器510上，以便于从其上读出的计算机程序根据需要被安装入存储部分508。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分509从网络上被下载和安装，和/或从可拆卸介质511被安装。在该计算机程序被处理器501执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 502和/或RAM 503和/或ROM 502和RAM 503以外的一个或多个存储器。

本公开的实施例还提供了一种计算机程序产品，该计算机程序产品包括一个或多个可读指令/程序，当上述一个或多个指令/程序被执行时，实现根据本公开实施例的方法。

综上所述，本公开提供了一种VNF可用性监测方法、通用用户端设备、VNF、电子设备及计算机可读存储介质，还提供了一种计算机程序产品，可以至少部分地解决由于业务链中的某个VNF出现故障、正在启动或恢复重启过程中导致的流量分发无效的问题，通过uCPE定期发送服务状态请求报文，并接收业务链中各个VNF的服务状态回复报文，报文中携带有VNF的服务可用状态，从而能够实时获知各个VNF真实的服务状态是否可用，以便于停止对不可用VNF供应流量，避免流量断流或其他业务故障，从而避免了某个VNF由于服务状态不可用而影响用户对于网络业务的正常访问，保证了流量的正确分发。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合或/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (10)

1.一种VNF可用性监测方法，应用于通用用户端设备，所述通用用户端设备用于运行多个VNF，所述通用用户端设备设置有与各VNF分别连接的多个虚拟网络接口，所述通用用户端设备为每个VNF分配一个用于内部管理的内部管理接口，所述内部管理接口连接至同一内部管理网络，所述内部管理网络通过所述虚拟网络接口与所述内部管理接口进行连接，所述方法包括：

定期发送服务状态请求报文，所述服务状态请求报文包括VNF的服务状态上报间隔；

监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文，所述服务状态回复报文包括VNF的服务可用状态；

响应于监测到所述各虚拟网络接口在预设时间内接收到服务状态回复报文，根据与所述服务状态回复报文对应的虚拟网络接口确定所述服务状态回复报文与VNF的对应关系；以及

根据所述对应关系确定接收到服务状态回复报文的VNF的服务状态是否可用；

其中，所述服务状态请求报文和所述服务状态回复报文均采用二层以太网报文格式。

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

响应于监测到多个虚拟网络接口之一在预设时间内未接收到服务状态回复报文，确定与虚拟网络接口对应的VNF的服务状态不可用。

3.根据权利要求1所述的方法，还包括：

标记多个VNF中处于开启状态的VNF的初始服务状态为不可用；以及

响应于监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文的结果，更新各个VNF的服务状态。

4.根据权利要求1所述的方法，其中，响应于VNF的服务状态不可用，所述通用用户端设备切断用于分发给当前服务状态不可用的VNF的流量。

5.一种VNF可用性监测方法，应用于VNF，所述VNF设置有用于内部管理的内部管理接口，所述内部管理接口连接至同一内部管理网络，所述内部管理接口通过通用用户端设备设置的虚拟网络接口与所述内部管理网络进行连接，所述方法包括：

接收服务状态请求报文，所述服务状态请求报文包括VNF的服务状态上报间隔；

VNF监控自身服务状态是否可用；

根据监控结果确定要上报的VNF的服务可用状态；以及

按照所述服务状态上报间隔定期发送服务状态回复报文，以使所述通用用户端设备根据与所述服务状态回复报文对应的虚拟网络接口确定所述服务状态回复报文与VNF的对应关系，以及

根据所述对应关系确定接收到服务状态回复报文的VNF的服务状态是否可用，

所述服务状态回复报文包括VNF的服务可用状态；

其中，所述服务状态请求报文和所述服务状态回复报文均采用二层以太网报文格式。

6.一种通用用户端设备，所述通用用户端设备用于运行多个VNF，所述通用用户端设备设置有与各VNF分别连接的多个虚拟网络接口，所述通用用户端设备为每个VNF分配一个用于内部管理的内部管理接口，所述内部管理接口连接至同一内部管理网络，所述内部管理网络通过所述虚拟网络接口与所述内部管理接口进行连接，所述通用用户端设备包括：

第一报文发送模块，用于定期发送服务状态请求报文，所述服务状态请求报文包括VNF的服务状态上报间隔；

第一报文接收模块，用于监测各虚拟网络接口在预设时间内是否接收到服务状态回复报文，所述服务状态回复报文包括VNF的服务可用状态；

报文与VNF对应关系确定模块，用于响应于监测到所述各虚拟网络接口在预设时间内接收到服务状态回复报文，根据所述服务状态回复报文对应的虚拟网络接口确定所述服务状态回复报文与VNF的对应关系；以及

服务状态确定模块，用于根据所述对应关系确定接收到服务状态回复报文的VNF的服务状态是否可用；

其中，所述服务状态请求报文和所述服务状态回复报文均采用二层以太网报文格式。

7.一种VNF，所述VNF设置有用于内部管理的内部管理接口，所述内部管理接口连接至同一内部管理网络，所述内部管理接口通过通用用户端设备设置的虚拟网络接口与所述内部管理网络进行连接，所述VNF包括：

第二报文接收模块，用于接收服务状态请求报文，所述服务状态请求报文包括VNF的服务状态上报间隔；

服务状态监控模块，用于监控VNF服务状态是否可用；

服务状态确定模块，用于根据监控结果确定要上报的VNF的服务可用状态；以及

第二报文发送模块，按照所述服务状态上报间隔定期发送服务状态回复报文，以使所述通用用户端设备根据与所述服务状态回复报文对应的虚拟网络接口确定所述服务状态回复报文与VNF的对应关系，以及

根据所述对应关系确定接收到服务状态回复报文的VNF的服务状态是否可用，

所述服务状态回复报文包括VNF的服务可用状态；

其中，所述服务状态请求报文和所述服务状态回复报文均采用二层以太网报文格式。

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

一个或多个处理器；

存储装置，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行权利要求1-5中任一项所述的方法。

9.一种计算机可读存储介质，其上存储有可执行指令，该指令用于执行权利要求1-5中任一项所述的方法。

10.一种计算机程序产品，包括计算机可读指令，该指令用于执行权利要求1-5中任一项所述的方法。

Images