一种基于FSM管理虚拟端口的方法及云平台

摘要

本发明提供了一种基于FSM管理虚拟端口的方法以及基于该方法所形成的云平台，该云平台，包括：受控于用户的控制节点，至少一个计算节点，每个计算节点上的每个虚拟端口独立配置且具唯一属性的FSM，控制节点依用户所发出的指令在计算节点上配置虚拟端口的FSM，并通过控制节点向用户做出响应，以向用户返回与该虚拟端口所对应的FSM的配置结果。在本发明中，通过FSM对计算节点的虚拟端口在配置过程中所发生的状态进行记录，并根据前述状态执行对应状态下的预定义操作，从而极大程度地避免了大规模的云平台中由于环境的复杂性导致的配置乱序、管理复杂、底层配置错误的缺陷。

说明书

技术领域

本发明涉及云计算技术领域，尤其涉及一种基于FSM管理虚拟端口的方法以及基于该方法所配置形成的一种云平台。

背景技术

虚拟机(VM)是真实的物理计算机系统(PM)的抽象-“虚拟化”。在云计算环境中，用户无论在使用基于公有云、私有云或者是混合云的云计算架构中，都需要创建虚拟机，并通过虚拟机执行具体的计算、存储操作。在现有技术中，虚拟机在被创建时需要用户制定各种规则，例如：限速设置、安全组设置、启用禁用设置等等。目前，主流云计算平台使用Openstack作为管理平台，并使用Neutron-ovs-agent作为tap端口的配置管理程序。

Linux主要使用以下三种设备模型：Bridge、TAP、VETH、VLAN。Bridge设备是基于内核实现的二层数据交换设备，其作用类似于现实世界中的二级交换机。TAP设备是一种工作在二层协议的点对点网络设备，每一个TAP设备都有一个对应的Linux字符设备，用户程序可以通过对字符设备的读写操作，完成与Linux内核网络协议栈的数据交换工作，在虚拟化环境中经常被模拟器使用。VETH设备是一种成对出现的点对点网络设备，从一段输入的数据会从另一端改变方向输出，通常用于改变数据方向，或连接其它网络设备。VLAN设备是以母子关系出现的一组设备，是Linux里对802.1.Q VLAN技术的部分实现，主要完成对802.1.Q VLAN Tag的处理。Neutron为每一个network分配一个本地的VLAN ID，每个network分配一个network namespace，该DHCP通过一个tap端口连接在br-int(用于用来处理虚拟机流量分类的虚拟交换机)上，该tap端口的tag为该local VLAN ID。因此，Tap端口本质上是一种虚拟网卡，且是一种虚拟端口。

基于Openstack架构的云平台中，对于tap端口的配置基于异步远程调用模式，用户通过控制程序操作tap端口的配置(限速设置，安全组设置，启用禁用设置等等)，控制程序发送异步的远程调用消息配置该tap端口，之后就不再进行管理。

因此，上述现有技术基于Neutron-ovs-agent对tap端口进行配置的话，仅仅对云平台中节点较少的场景中适用，并具有对tap端口配置效率较高的优点。但是，但是对于大规模云平台而言，尤其是云平台中的计算节点数量非常多时，采用Neutron-ovs-agent对tap端口进行配置的技术手段是存在一定瑕疵的，其缺陷简要如下：

(1)平台管理员无法准确实时的获得tap端口的状态，并对单个虚拟tap端口进行精确管理。因此，当tap端口在正常运行过程中出现问题，无法及时的通知到云平台的管理员或者运维人员。

(2)由于故障的tap端口还在运行，对最终租户会造成较大影响，比如防火墙失效导致租户的虚拟机处于脆弱状态等等。当平台发现虚拟tap端口出现问题时，需要底层运维人员去定位具体的问题，需要从计算节点大量的(通常数量级需要以千为单位)防火墙规则，流表规则，限速规则中找出错误的地方，这个过程极其容易发生错误，并导致更大的问题。

有鉴于此，有必要对现有技术中的对tap端口的配置管理方法予以改进，以解决上述问题。

发明内容

本发明的目的在于揭示一种基于FSM管理虚拟端口的方法，同时揭示一种基于上述方法的一种云平台，用以克服现有技术中云平台中计算节点数量较大时所存在无法对虚拟端口进行有效配置及管理的技术缺陷，实现管理员精确掌控计算节点中所出现的虚拟端口的故障或者错误，并协助运维人员对出现故障虚拟端口的快速定位与故障修复。

为实现上述发明目的，本发明首先提供了一种云平台，包括：受控于用户的控制节点，至少一个计算节点，其中，每个计算节点上的每个虚拟端口独立配置且具唯一属性的FSM，所述控制节点依用户所发出的指令在计算节点上配置虚拟端口的FSM，并通过控制节点向用户做出响应，以向用户返回与该虚拟端口所对应的FSM的配置结果。

作为本发明的进一步改进，所述FSM由指令接收单元、执行单元及状态单元组成，所述指令接收单元受控于控制节点，当计算节点自控制节点接收到用户发出创建虚拟端口的指令时，在计算节点上创建并运行仅属于该虚拟端口的FSM，并由执行单元对虚拟端口进行配置操作。

作为本发明的进一步改进，所述控制节点采用同步调用方式或者采用异步调用方式或者采用异步调用方式与同步确认的方式在计算节点上配置虚拟端口的FSM。

作为本发明的进一步改进，所述计算节点仅通过虚拟端口对应的FSM进行虚拟端口的配置及监控。

作为本发明的进一步改进，所述虚拟端口选自tap端口、macvtap端口、tun端口、veth pair设备、数据包转发端口、DPDK加速端口或者SR-IOV虚拟子接口。

作为本发明的进一步改进，所述指令接收单元接受外部指令，并向外部指令的发出主体进行响应；

所述状态单元用于记录FSM的状态、虚拟端口的配置属性及记录执行单元的执行结果；

所述执行单元根据状态单元所处的状态，执行对应状态下的预定义操作；

其中，FSM的状态仅包含CONFIG状态、RUN状态、ERR状态及END状态。

作为本发明的进一步改进，所述FSM将状态单元进行状态转换时所产生的日志文件保存至计算节点的日志目录中，所述日志文件的格式为txt格式、XML格式或者JSON格式。

同时，为实现上述另一个发明目的，本发明还公开了一种基于FSM管理虚拟端口的方法，所述方法用于对云平台中的计算节点的虚拟端口进行配置，所述云平台包括：受控于用户的控制节点，至少一个计算节点；

所述方法包括以下步骤：为每个计算节点上的每个虚拟端口独立配置且具唯一属性的FSM，所述控制节点依用户所发出的指令在计算节点上配置虚拟端口的FSM，并通过控制节点向用户做出响应，以向用户返回与该虚拟端口所对应的FSM的配置结果。

作为本发明的进一步改进，所述FSM由指令接收单元、执行单元及状态单元组成，所述指令接收单元受控于控制节点，当计算节点自控制节点接收到用户发出创建虚拟端口的指令时，在计算节点上创建并运行仅属于该虚拟端口的FSM，并由执行单元对虚拟端口进行配置操作。

作为本发明的进一步改进，通过所述指令接收单元接受外部指令，并向外部指令的发出主体进行响应；通过所述状态单元记录FSM的状态、虚拟端口的配置属性及记录执行单元的执行结果；通过所述执行单元根据状态单元所处的状态，执行对应状态下的预定义操作；

其中，FSM的状态仅包含CONFIG状态、RUN状态、ERR状态及END状态。

作为本发明的进一步改进，所述方法还包括：通过执行单元将虚拟端口的配置操作结果通过短信、电子邮件或者电话的方式通知管理员和/或运维人员；所述虚拟端口选自tap端口、macvtap端口、tun端口、veth pair设备、数据包转发端口、DPDK加速端口或者SR-IOV虚拟子接口。

与现有技术相比，本发明的有益效果是：

(1)在本发明中通过在计算节点中为每个虚拟端口配置FSM，可通过FSM对计算节点的虚拟端口在配置过程中所发生的状态进行记录，并根据前述状态执行对应状态下的预定义操作，从而极大程度地避免了大规模的云平台中由于环境的复杂性导致的配置乱序、管理复杂、底层配置错误的缺陷；

(2)通过在云平台的每个计算节点上的每个虚拟端口独立配置且具唯一属性的FSM，隔离虚拟端口的管理和监控，因此当某个虚拟端口出现故障时，该虚拟端口在所属的计算节点上对应的FSM可以将其所在计算节点和故障虚拟端口信息通知平台管理员和/或运维人员，从而有利于管理员和/或运维人员对出现虚拟端口配置故障的计算节点进行准确且快速的定位，从而便于管理员和/或运维人员对出现故障的虚拟端口进行故障排除操作，以简化运维流程并降低了运维人员的工作难度。

附图说明

图1为本发明一种云平台的示意图；

图2为本发明所示出的云平台中的FSM的状态呈CONFIG状态时对虚拟端口进行配置的示意图；

图3为本发明所示出的云平台中的FSM的状态呈RUN状态时对虚拟端口进行配置的示意图；

图4为本发明所示出的云平台中的FSM的状态呈ERR状态时对虚拟端口进行配置的示意图；

图5为本发明所示出的云平台中的FSM的状态呈END状态时对虚拟端口进行配置的示意图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

目前，当大规模云计算环境中出现某个虚拟端口配置失败时，管理员和/或运维人员无法及时获得通知。虚拟端口配置失败发生的原因通常包括以下几种：(1)程序错误；(2)虚拟端口配置下发冲突；(3)运维人员的错误配置操作，导致虚拟端口呈现状态异常。上述虚拟端口配置失败的风险在大规模的云平台中，尤其是云平台中包含几千个甚至几万个计算节点的场景中尤为明显。因此，本申请所揭示的一种云平台，以及基于FSM(即“有限状态机”)管理虚拟端口的方法所追求解决的技术问题即是如此。

实施例一：

参图1所示，其揭示了一种云平台100。该云平台100可基于Openstack架构进行组建，也可以是基于Hadoop架构进行组建或者其他任何形式且逻辑架构上由资源层、虚拟层、中间层、应用层所组成的计算服务。

本申请首先具体揭示了一种云平台100，包括：受控于用户的控制节点10，至少一个计算节点20。为简化表示，本领域技术人员均可知，云平台100中的计算节点20的数量可以是两个或者成千上万个。该云平台100可是SAAS架构，也可是PAAS架构或者IAAS架构。

同时，控制节点10包括网络控制、调度管理、api服务、存储卷管理、数据库管理、身份管理和镜像管理等。计算节点20主要提供nova-compute服务。控制节点10的服务可以分开在多个节点，我们把提供nova-network服务的节点称为网络控制器。基于OpenStack架构的网络由nova-network(网络控制器)管理，它会创建虚拟网络，使主机之间以及与外部网络互相访问。OpenStack的API服务器通过消息队列分发nova-network提供的命令，这些命令之后会被nova-network处理，其主要的操作有：分配ip地址、配置虚拟网络和通信。

通常的，控制节点10中通常包含以下三个模块：(1)haproxy：提供负载均衡，收到请求后，分发到各个计算节点；(2)openvswitch：利用虚拟平台，通过软件的方式实现虚拟交换机；(3)zabbix：主要负责监控物理机(即物理节点，在图1中未具体示出)。

尤其是需要说明的是，在本申请各个实施例中，控制节点10可为上述基于Openstack架构所组建的云平台中，控制节点10包含传统意义上云计算OS结构的网络节点(未示出)；同时，本领域的普通技术人员均知道可将网络节点单独剥离，以成为云平台100的一个独立组件。

在本实施例中，每个计算节点20上的每个虚拟端口独立配置且具唯一属性的FSM(即有限状态机)201，控制节点10依用户1所发出的指令在计算节点20上配置虚拟端口203的FSM201，并通过控制节点10向用户做出响应，以向用户1返回与该虚拟端口203所对应的FSM201的配置结果。有限状态机(Finite-state machine，FSM)是一种用来进行对象行为建模的工具，其作用主要是描述对象在它的生命周期内所经历的状态序列，以及如何响应来自外界的各种事件。

具体的，该FSM201由指令接收单元211、执行单元221及状态单元231组成。指令接收单元211受控于控制节点10，当计算节点20自控制节点10接收到用户1发出创建虚拟端口203的指令时，在计算节点20上创建并运行仅属于该虚拟端口203的FSM，并由执行单元221对虚拟端口203进行配置操作。

具体的，用户1首先执行步骤S101：用户1向控制节点10发出创建虚拟端口203的指令；步骤S102：控制节点10接收到上述指令后在指定的计算节点20中配置仅属于该虚拟端口203的且具唯一属性的FSM201，从而保证了每个计算节点20中各种虚拟端口203所配置的FSM201的独立性与唯一性，从而便于后期运维人员2和/或管理员3通过有限状态机201的状态变化对出现虚拟端口203配置异常或者错误的计算节点20进行快速定位与故障排除；然后，执行步骤S103：FSM201向控制节点10返回虚拟端口203创建结果；最后，执行步骤S104：控制节点10向用户1返回某个具体的计算节点20中的虚拟端口203创建完成的消息。

控制节点10采用同步调用方式或者采用异步调用方式或者采用异步调用方式与同步确认的方式在计算节点20上配置虚拟端口203的FSM201，在本实施例中具体选用控制节点10采用采用异步调用方式与同步确认的方式在计算节点20上配置虚拟端口203的FSM201。

本实施例中，首先采用采用异步调用的方式创建虚拟端口203，待虚拟端口203创建之后再进行同步确认该虚拟端口203是否创建成功，因此具有兼顾效率与可靠性的优点。

控制节点10进行同步调用方式在计算节点20上配置虚拟端口203的FSM201需要等待该FSM201创建成功返回，对于规模较小的云平台而言(例如云平台100中含几十个计算节点20)可以使用，不会太浪费时间，从而影响用户体验，但当云平台100中的计算节点20达到成千上万时就不太适应实际使用需求了，因此当云平台100中的计算节点20数量较少时，控制节点10可采用同步调用方式，在计算节点20上配置虚拟端口203的FSM201。

控制节点10进行异步调用方式在计算节点20上配置虚拟端口203的FSM201不需要等待该FSM201创建成功，只要FSM201开始初始化就返回，用户可以直接进行下一步操作，不需要等待太久，对于任意规模的云平台100都可以使用，但是可靠性有所欠缺，当用户执行的某项操作出现错误时，会导致用户延迟感知，造成较大影响。

因此，在本实施例中，控制节点10采用异步调用与同步确认的方式在计算节点20上配置虚拟端口203的FSM201，FSM201不需要等待该FSM201创建成功，只要FSM201开始初始化就返回，用户1可以直接进行下一步操作，之后用户1第二次再进行配置该FSM201时需要等待控制节点10确认之前操作成功，解决了上一种方式下的错误延迟感知问题。因此，在实施例中，采用采用异步调用的方式创建虚拟端口203，待虚拟端口203创建之后再进行同步确认该虚拟端口203是否创建成功，因此具有兼顾效率与可靠性的优点。该方式可以支持大规模的云平台环境，同时能有较好的效率和可靠性。

计算节点20不需要运行传统云平台的虚拟端口配置程序及虚拟端口监控程序，仅通过虚拟端口203对应的FSM201进行虚拟端口203进行配置及监控，从而通过消息修改FSM201的状态并执行自FSM201所发出的消息。具体的，在本实施例中，该虚拟端口203选自tap端口、macvtap端口、tun端口、veth pair设备、数据包转发端口、DPDK加速端口或者SR-IOV虚拟子接口。在本实施例中，申请人示范性的将该虚拟端口203选用tap端口进行示范性的说明。

在计算节点20中配置有独立配置且具唯一属性的FSM201。进一步的，该FSM201由指令接收单元211、状态单元231及执行单元221组成。指令接收单元211接受外部指令，并向外部指令的发出主体进行响应；状态单元231用于记录FSM201的状态、虚拟端口203的配置属性及记录执行单元221的执行结果；执行单元221根据状态单元231所处的状态，执行对应状态下的预定义操作；其中，FSM201的状态仅包含CONFIG状态、RUN状态、ERR状态及END状态。

具体的，指令接收单元211与外界交互来源30中的管理员3和/或运维人员2对某个具体的计算节点进行配置与维护。管理员3可直接向指令接收单元211下发配置命令，并由该指令接收单元211向管理员3反馈虚拟端口203配置的结果、状态等参数。同时，运维人员2可在虚拟端口203在配置及计算节点20的运行过程中所出现的故障向指令接收单元211下发维护命令，并由该指令接收单元211向运维人员2反馈虚拟端口203配置的结果、状态等参数。有些维护指令会对虚拟端口203产生数据包进行实际验证测试，可以快速帮助运维人员2确认虚拟端口203的状态和虚拟端口203所出现的问题，但是会对用户1的正常使用有一定的影响。

下述表一示出了常用的几种维护命令及该维护命令所对应的具体作用。

表一

FSM201将状态单元231进行状态转换时所产生的日志文件保存至计算节点20的日志目录中，所述日志文件的格式为txt格式、XML格式或者JSON格式。

在本实施例中，为每个计算节点20上的每个虚拟端口单独创建具唯一属性的FSM201，起到了对同一计算节点20上不同虚拟端口203的隔离效果。当运维人员2需要对特定的计算节点20的虚拟端口203进行修复时，传统云平台需要停止与该计算节点20关联的neutron-agent，敲打底层代码命令以修复出现故障的虚拟端口203。只需要和该虚拟端口的FSM进行交互从而实现了对虚拟端口203出现故障的计算节点20进行快速定位与修复。

同时，在本实施例中，该日志文件可作为引导运维人员2或者管理员3对出现故障的虚拟端口203起到引导作用。运维人员2或者管理员3可直接登录到虚拟端口203出现故障的计算节点20，并查看该日志文件，定位出现故障的虚拟端口203，并进行快速修复。

申请人以OVS流表丢失的问题为范例，具体说明。

传统云平台的解决办法包含以下步骤：

(1)停止本计算节点20上的neutron-agent，防止在解决问题的同时造成其他影响；

(2)敲打OVS底层命令“ovs-ofctl dump-flows br-int”，其中包含了本计算节点20上所有虚拟端口203的流表；

(3)从中找到出现异常的虚拟端口的流表，这一步非常耗时，很容易出现错误；

(4)对比数据库，确认为OVS流表丢失；

(5)将相关丢失流表使用OVS底层命令“ovs-ofctl add-flows br-int in-port＝1，priority＝100，icmp6，reg5＝0x83a，dl_dst＝fa：16：3e：61：df：97，icmp_type＝1 32actions＝strip_vlan，output：2106”添加到虚拟端口203上；

(6)打开第一步停止的neutron-agent；

由此可见，申请人认为现有技术所采用的解决方式，存在效率非常低下，容错率低，客户体验差的缺陷。

然而，在本实施例中，云平台100针对上述问题的解决办法包含以下步骤：

(1)运维人员2直接与出现异常的虚拟端口203对应的FSM201进行交互；

(2)发送get ovs指令给FSM201的指令接收单元211获取当前底层虚拟端口203的OVS配置：

(3)发送get status ovs指令给FSM201的指令接收单元211获取用户配置的虚拟端口203的OVS配置；

(4)比对步骤(2)和步骤(3)的结果，确认为OVS流表丢失；

(5)发送reconfig ovs指令给FSM201的指令接收单元211，让FSM201重新配置虚拟端口203的底层ovs流表。

可以看到采用了本实施例所揭示的一种云平台100，对于运维人员2和/或管理员3的技术水平要求大大降低，具有效率高、提升容错性、修复速度的优点，因此能够显著地提高用户体验。

具体的，当虚拟端口203为tap端口203a时，该指令接收单元211接收运维人员2或者管理员3的指令对FSM201所执行的状态转移及对应的作用如下表二所示：

表二

例如，管理员3发送“get status”查询指令给有限状态机主动查询状态，FSM201的指令接收单元211收到指令之后从状态单元231中读取当前FSM201所处于的状态，以通过指令接收单元211返回管理员3。

又例如，管理员3发送特权指令“reconfig”给FSM201，FSM201的指令接收单元211收到指令之后，改变该状态单元231的状态为CONFIG，之后执行单元221读取到状态单元231呈CONFIG状态，进行配置tap端口203a的操作，从而达到强制刷新tap端口203a的作用。

还例如，用户1发送普通指令“config iptables allow tcp 22 from 0.0.0.0/0”，FSM201的指令接收单元211收到指令之后，FSM201的状态单元231变状态为CONFIG，之后执行单元221读取到，FSM201的状态单元231CONFIG状态，则把用户1下发的iptables防火墙规则213在底层完成配置。参图1所示该虚拟端口203所能够完成的配置除了上述iptables防火墙规则213之外，还包括OVS流表规则223及TC流量限速规则233。

在本实施例中，该状态单元231仅具有四个状态就能够对虚拟端口203进行配置与日常维护：

(1)CONFIG状态，表示虚拟tap端口203a正在配置，用户不能使用；

(2)RUN状态，表示虚拟tap端口203a正在正常运行，用户可以使用；

(3)ERR状态，表示虚拟tap端口203a出现错误，用户不能使用；

(4)END状态，表示虚拟tap端口203a正在删除，用户不能使用。

执行单元221负责执行状态单元231中所处状态下的预定义动作，其中，每种状态下执行单元221所做的操作如下表三所示：

表三

接下来对上述表二中状态单元231所分别历经的四个状态时对虚拟端口203进行配置及维护的过程进行详细介绍。

第一种状态：CONFIG状态

参图2所示，当状态单元231处于CONFIG状态时，执行单元221通过读取状态单元231中虚拟tap端口203a的具体配置，将这些配置转化为tap端口203a底层的配置命令。

例如，状态单元231中的具体配置如下所示：

执行单元221根据上述配置，转化为底层具体的命令，具体如下所示：

执行单元221执行上述底层指令，并检查执行命令的结果。若执行成功，则把状态单元231的状态修改为RUN状态；若执行失败，则把状态单元231的状态修改为ERR状态，同时将结果记录到状态单元231中。

第二种状态：RUN状态

参图3所示，当状态单元231处于RUN状态时，执行单元221读取状态单元231中tap端口203a的具体配置；执行单元221使用命令查看tap端口203a当前的底层设置，具体如下所示：

然后，将状态单元231中的tap端口203a设置和底层的结果进行对比，若判断对比结果一致，则维持状态单元231的状态为RUN状态；若判断对比结果不一致，则把状态单元231的状态转变为ERR状态，同时将结果记录到状态单元231中。

第三种状态：ERR状态

参图4所示，执行单元221读取状态单元231中tap端口203a的具体配置，然后发送邮件或者短信的方式将实时的tap端口203a具体配置和状态通知管理员3或者运维人员2；维持状态单元231的状态呈ERR状态，同时将结果记录到状态单元231中。

第四种状态：END状态

参图5所示，首先执行单元221读取状态单元231中tap端口203a的具体配置；然后，执行单元221删除tap端口203a；最后，销毁FSM201。

在本实施例所揭示的一种云平台100中，由于采用了为每个计算节点20的虚拟端口203配置独立的FSM201进行隔离管理，FSM201内部可以给出此虚拟端口203出现错误状态的原因并计入在日志文件中，从而能够快速帮助运维人员2或者管理员3定位到有问题的计算节点20，并通过状态单元231所呈现的不同状态及执行单元221执行状态单元231中所处状态下的预定义动作，以排除虚拟端口203所出现的故障，从而极大地简化了运维工作。

实施例二：

结合图1～图5所示，本实施例揭示了一种基于FSM管理虚拟端口的方法，该方法用于对云平台100中的计算节点20的虚拟端口203(在本申请中，该虚拟端口以tap端口203a为范例作示范性的说明)进行配置。该云平台100包括：受控于用户的控制节点10，至少一个计算节点20。通过本实施例所揭示的上述方法可形成如实施例一揭示的一种云平台100。

基于FSM管理虚拟端口的方法包括以下步骤：

为每个计算节点20上的每个虚拟端口独立配置且具唯一属性的FSM201，该控制节点10依用户所发出的指令在计算节点20上配置虚拟端口的FSM(有限状态机)201，并通过控制节点10向用户做出响应，以向用户返回与该虚拟端口所对应的FSM201的配置结果。FSM201由指令接收单元211、执行单元221及状态单元231组成，指令接收单元211受控于控制节点10，当计算节点20自控制节点10接收到用户发出创建虚拟端口的指令时，在计算节点20上创建并运行仅属于该虚拟端口的FSM，并由执行单元221对虚拟端口进行配置操作。

通过所述指令接收单元211接受外部指令，并向外部指令的发出主体进行响应；通过所述状态单元231记录FSM201的状态、虚拟端口的配置属性及记录执行单元221的执行结果；通过所述执行单元221根据状态单元231所处的状态，执行对应状态下的预定义操作；其中，FSM201的状态仅包含CONFIG状态、RUN状态、ERR状态及END状态。

在本实施例中，该方法还包括：通过执行单元221将虚拟端口的配置操作结果通过短信、电子邮件或者电话的方式通知管理员3和/或运维人员2。虚拟端口选自tap端口、macvtap端口、tun端口、veth pair设备、数据包转发端口、DPDK加速端口或者SR-IOV虚拟子接口。

在本实施例中，仅通过四种状态就能够对虚拟端口203进行配置与日常维护，在本实施例中，该虚拟端口选自DPDK加速端口。

(1)CONFIG状态，表示DPDK加速端口正在配置，用户不能使用；

(2)RUN状态，表示DPDK加速端口正在正常运行，用户可以使用；

(3)ERR状态，表示DPDK加速端口出现错误，用户不能使用；

(4)END状态，表示DPDK加速端口正在删除，用户不能使用。

在本实施中，为每个计算节点20上的每个虚拟端口203独立配置且具唯一属性的FSM201，管理员3或者运维人员2实现了对环境的完全可控制，即使底层出现问题，也可以通过FSM201的执行单元221监控实时地反馈到FSM201中，并执行相应状态对应的动作，使得管理员3或者运维人员2对出现故障的虚拟端口203进行快速定位与故障排除，从而提高了大规模云环境中对计算节点20的虚拟端口203进行配置的稳定性和容错性。

实施例与实施例一中相同部分的技术特征，请参实施例一所述，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。