组播业务处理方法、装置、云平台、设备及可读存储介质
阅读说明：本技术 组播业务处理方法、装置、云平台、设备及可读存储介质 (Multicast service processing method, device, cloud platform, equipment and readable storage medium ) 是由 蒋晨晓 王培辉 张兆增 于 2019-10-18 设计创作，主要内容包括：本申请公开了一种组播业务处理方法、装置、云平台、设备及可读存储介质。本申请公开的方法包括：通过多个虚拟网卡队列并行接收网络报文；若网络报文属于组播业务,则利用多个虚拟CPU并行处理网络报文,并按照OpenFlow流表传输处理后的网络报文,从而可提高组播业务的处理效率。其中,虚拟网卡队列与虚拟CPU一一对应；多个虚拟CPU对应的物理CPU属于同一NUMA域。属于同一NUMA域的物理CPU访问同一个内存区,也就是多个虚拟CPU访问同一个内存区,不会进行跨域访问,从而可避免访问延时,实现了高性能组播。相应地,本申请提供的一种组播业务处理装置、云平台、设备及可读存储介质,也同样具有上述技术效果。(The application discloses a multicast service processing method, a multicast service processing device, a cloud platform, equipment and a readable storage medium. The method disclosed by the application comprises the following steps: receiving network messages in parallel through a plurality of virtual network card queues; if the network message belongs to the multicast service, the network message is processed in parallel by using a plurality of virtual CPUs, and the processed network message is transmitted according to the OpenFlow flow table, so that the processing efficiency of the multicast service can be improved. The virtual network card queues correspond to the virtual CPUs one by one; physical CPUs corresponding to the plurality of virtual CPUs belong to the same NUMA domain. Physical CPUs belonging to the same NUMA domain access the same memory area, namely a plurality of virtual CPUs access the same memory area, cross-domain access is not performed, so that access delay can be avoided, and high-performance multicast is realized. Correspondingly, the multicast service processing device, the cloud platform, the equipment and the readable storage medium provided by the application also have the technical effects.)
技术领域
本申请涉及计算机技术领域，特别涉及一种组播业务处理方法、装置、云平台、设备及可读存储介质。
背景技术
组播能够在发送者和每一接收者之间实现点对多点的网络连接，从而提高数据传输效率，降低网络出现拥塞的可能性。
目前，组播这种通信模式与云平台相结合，为人们带来了更好的网络服务体验。但由于云平台依赖的物理设备的性能较低，导致组播业务时常出现丢包。为了解决组播业务的丢包问题，需要为云平台更换性能更好的物理设备，如此将会增加网络搭建成本。同时，由于物理设备上的物理网卡等资源为云平台上所有虚拟机所共用，因此当带宽不足或瞬发流量过大时，还是会出现丢包现象。
因此，如何提高组播业务的处理效率，避免丢包现象的发生，是本领域技术人员需要解决的问题。
发明内容
有鉴于此，本申请的目的在于提供一种组播业务处理方法、装置、云平台、设备及可读存储介质，以提高组播业务的处理效率，避免丢包现象的发生。其具体方案如下：
第一方面，本申请提供了一种组播业务处理方法，包括：
通过多个虚拟网卡队列并行接收网络报文；
若网络报文属于组播业务，则利用多个虚拟CPU并行处理网络报文，并按照OpenFlow流表传输处理后的网络报文；
其中，虚拟网卡队列与虚拟CPU一一对应；多个虚拟CPU对应的物理CPU属于同一NUMA域。
优选地，利用多个虚拟CPU并行处理网络报文，包括：
若任一个虚拟CPU对应有多个业务的处理进程，则控制组播业务的处理进程优先处理网络报文。
优选地，按照OpenFlow流表传输处理后的网络报文，包括：
按照OpenFlow流表将处理后的网络报文传输至OpenFlow流表对应的组播组。
优选地，还包括：
当组播组更新后，按照更新后的组播组调整OpenFlow流表。
优选地，每个虚拟CPU在单位时钟周期内占用的物理CPU资源高于预设的阈值。
第二方面，本申请提供了一种组播业务处理装置，包括：
接收模块，用于通过多个虚拟网卡队列并行接收网络报文；
处理模块，用于若网络报文属于组播业务，则利用多个虚拟CPU并行处理网络报文，并按照OpenFlow流表传输处理后的网络报文；其中，虚拟网卡队列与虚拟CPU一一对应；多个虚拟CPU对应的物理CPU属于同一NUMA域。
第三方面，本申请提供了一种云平台，包括：虚拟机和虚拟交换机，其中：
虚拟机包括：多个虚拟网卡和多个虚拟CPU，多个虚拟CPU对应的物理CPU属于同一NUMA域，其中：
多个虚拟网卡，用于并行接收网络报文；虚拟网卡队列与虚拟CPU一一对应；
多个虚拟CPU，用于若网络报文属于组播业务，则并行处理网络报文；
虚拟交换机，用于按照OpenFlow流表传输处理后的网络报文。
优选地，还包括：
SDN控制器，用于更新OpenFlow流表。
第四方面，本申请提供了一种组播业务处理设备，包括：
存储器，用于存储计算机程序；
处理器，用于执行计算机程序，以实现前述公开的组播业务处理方法。
第五方面，本申请提供了一种可读存储介质，用于保存计算机程序，其中，计算机程序被处理器执行时实现前述公开的组播业务处理方法。
通过以上方案可知，本申请提供了一种组播业务处理方法，包括：通过多个虚拟网卡队列并行接收网络报文；若网络报文属于组播业务，则利用多个虚拟CPU并行处理网络报文，并按照OpenFlow流表传输处理后的网络报文；其中，虚拟网卡队列与虚拟CPU一一对应；多个虚拟CPU对应的物理CPU属于同一NUMA域。
可见，该方法能够通过多个虚拟网卡队列并行接收网络报文；当网络报文属于组播业务时，可以利用多个虚拟CPU并行处理网络报文，并按照OpenFlow流表传输处理后的网络报文，从而可使云平台提高处理组播业务的能力，并提高组播业务的处理效率。同时，按照OpenFlow流表来传输处理后的网络报文，可达到组播消息可控的目的，实现计算机资源的合理利用。其中，虚拟网卡队列是虚拟网卡的功能属性，而一个虚拟网卡对应一个虚拟网卡队列，因此虚拟网卡队列与虚拟CPU一一对应，也就是虚拟网卡处理与虚拟CPU一一对应，各个虚拟网卡并行接收数据，各个虚拟CPU并行处理数据，从而提高了处理效率。其中，每个NUMA域对应一个内存区，因此属于同一NUMA域的物理CPU访问同一个内存区，也就是多个虚拟CPU访问同一个内存区，不会进行跨域访问，从而可避免访问延时，进一步提高组播业务的处理效率。可见，本申请能够提高组播业务的处理效率，实现高性能组播。
相应地，本申请提供的一种组播业务处理装置、云平台、设备及可读存储介质，也同样具有上述技术效果。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本申请公开的一种组播业务处理方法流程图；
图2为本申请公开的一种组播业务处理装置示意图；
图3为本申请公开的一种云平台示意图；
图4为本申请公开的另一种云平台示意图；
图5为本申请公开的一种组播业务处理设备示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
目前，现有云平台上的组播业务会出现丢包问题，且网络搭建成本较高。为此，本申请提供了一种组播业务处理方案，能够提高组播业务的处理效率，避免丢包现象的发生。
参见图1所示，本申请实施例公开了一种组播业务处理方法，包括：
S101、通过多个虚拟网卡队列并行接收网络报文；
S102、若网络报文属于组播业务，则利用多个虚拟CPU并行处理网络报文；
S103、按照OpenFlow流表传输处理后的网络报文。
需要说明的是，虚拟网卡队列与虚拟CPU一一对应；多个虚拟CPU对应的物理CPU属于同一NUMA域。其中，虚拟网卡队列是虚拟网卡的功能属性，而一个虚拟网卡对应一个虚拟网卡队列，因此虚拟网卡队列与虚拟CPU一一对应，也就是虚拟网卡处理与虚拟CPU一一对应，各个虚拟网卡并行接收数据，各个虚拟CPU并行处理数据，从而提高了处理效率。其中，每个NUMA域对应一个内存区，因此属于同一NUMA域的物理CPU访问同一个内存区，也就是多个虚拟CPU访问同一个内存区，不会进行跨域访问，从而可避免访问延时，进一步提高组播业务的处理效率。
NUMA(Non Uniform Memory Access Architecture)是一种物理主机系统架构，可以有效扩展、构建大型系统。利用NUMA技术，可以把几十个CPU(甚至上百个CPU)组合在一个服务器内。NUMA服务器的基本特征是具有多个CPU模块，每个CPU模块由多个CPU(如4个)组成，并且具有独立的本地内存、I/O槽口等，一个CPU模块就是一个NUMA域。不同NUMA域之间通过互联模块(如为Crossbar Switch)进行连接和信息交互，因此每个CPU可以访问整个系统的内存。
一个物理CPU可虚拟化为多个虚拟CPU，且一个虚拟机中的多个虚拟CPU可能对应一个或多个物理CPU。在本实施例中，一个虚拟机中的多个虚拟CPU对应的物理CPU属于同一NUMA域，这样可避免跨域访问不同的内存区。当然，如有需要，还可以将云平台上的多个虚拟机中的虚拟CPU对应的物理CPU设置于同一NUMA域。虚拟机中至少包括：虚拟网卡和虚拟CPU，虚拟机运行于云平台上。云平台至少包括：虚拟机、虚拟交换机和SDN控制器。
在本实施例中，每个虚拟CPU在单位时钟周期内占用的物理CPU资源高于预设的阈值。其中，单位时钟周期内物理CPU资源有限，将虚拟CPU占用的物理CPU资源高一些，可以提高虚拟CPU处理数据的能力。其中，预设的阈值可以根据实际应用情况灵活调整，如单位时钟周期内物理CPU资源可被划分为10份，虚拟机中共有5个虚拟CPU，设置每个虚拟CPU占用2份，而通常情况下，每个虚拟CPU只占用1份，此时预设的阈值可设置为1。
在一种具体实施方式中，利用多个虚拟CPU并行处理网络报文，包括：若任一个虚拟CPU对应有多个业务的处理进程，则控制组播业务的处理进程优先处理网络报文。其中，一个虚拟CPU可能对应多个业务的处理进程，而这些进程由一个虚拟CPU控制，难免出现争抢计算机资源的情况。为避免其他业务与组播业务争抢计算机资源，本实施例将每个虚拟CPU对应组播业务的处理进程的优先级设置为最高，这样当同时收到组播业务和其他业务的网络报文时，每个虚拟CPU将优先处理属于组播业务的网络报文，从而提高组播业务的处理效率。
在一种具体实施方式中，按照OpenFlow流表传输处理后的网络报文，包括：按照OpenFlow流表将处理后的网络报文传输至OpenFlow流表对应的组播组。按照OpenFlow流表传输处理后的网络报文，可将处理后的网络报文只转发至对应的端口，而不会以广播的方式转发。其中，当组播组更新后，按照更新后的组播组调整OpenFlow流表。OpenFlow流表由云平台中的SDN控制器控制和更新。当组播组和中的组播成员(接收组播消息的端口)出现变化，如删除、增加、减少等。SDN控制器就需要更新OpenFlow流表，并将更新后的OpenFlow流表发送给虚拟交换机，虚拟交换机按照OpenFlow流表传输处理后的网络报文。
可见，本申请实施例能够通过多个虚拟网卡队列并行接收网络报文；当网络报文属于组播业务时，可以利用多个虚拟CPU并行处理网络报文，并按照OpenFlow流表传输处理后的网络报文，从而可使云平台提高处理组播业务的能力，并提高组播业务的处理效率。同时，按照OpenFlow流表来传输处理后的网络报文，可达到组播消息可控的目的，实现计算机资源的合理利用，实现了高性能组播。
为实现本申请提供的组播业务处理方法，可实施如下实例。
基于OpenFlow协议的SDN(Software Defined Network，软件定义网络)构建虚拟化网络，以实现云平台。为优化云平台处理组播业务的能力，从以下几个方面进行优化。
虚拟机的优化：提高承载组播业务虚拟机进程优先级，增加虚拟机进程和物理CPU之间的亲和性，进而提升虚拟机性能。虚拟机vCPU(即虚拟CPU)的优化：虚拟机vCPU基于物理主机NUMA(Non Uniform Memory Access Architecture)架构进行优化设定，提高承载组播业务虚拟机vCPU性能，减少因为CPU切换引起的性能损耗。虚拟网卡性能的优化：开启虚拟网卡多队列的功能属性，增加虚拟网卡缓存，有效提升vCPU核、缓存与网卡队列之间的亲和性，提升虚拟网卡网络性能。虚拟交换机性能优化：基于OpenFlow协议的控制与转发分离理念，采用基于OpenFlow流表控制报文转发的方法，管理和控制UDP组播报文的转发，减少组播报文在虚拟网桥中的洪泛，提高组播报文的Qos(Service Quality，服务质量)。
具体的，虚拟机的优化主要包括：关闭虚拟机电源，进行虚拟机配置调整，具体如下：
调整vCPU份额(即虚拟CPU在单位时钟周期内占用的物理CPU资源)，vCPU份额越高，优先级也就越高，vCPU所占用的物理CPU计算资源越多。同时在不改变虚拟机vCPU个数的前提下，调整虚拟机CPU插槽数和核数关系，从M×N(插槽数×核数)调整为1×N，以使一个虚拟机中的多个虚拟CPU对应的物理CPU属于同一NUMA域，避免跨域访问不同的内存区。获取物理主机NUMA域信息(NUMA域信息就是物理CPU和NUMA域的对应关系)，设定虚拟机中的vCPU和物理CPU的对应关系，将虚拟机中的vCPU调整至同一个物理CPU NUMA域。开启虚拟机时，设定虚拟机对应后台进程优先级nice＝-20和priority＝rt，以使组播业务的处理进程与其他进程相比，优先级最高，从而虚拟CPU将优先处理属于组播业务的网络报文，提高虚拟机进程抢占CPU的能力。提高虚拟机进程抢占CPU的能力，也就是提高了虚拟机的计算性能；计算性能越高，虚拟机运行越快，也就相应提高了虚拟机接收组播、系统处理、应用处理的能力。
例如：一个虚拟机有16个vCPU，但是vCPU模拟的插槽和核数关系会有多种情况，比如1插槽×16核、2插槽×8核，但是vCPU总数都是16。插槽数和核数不同，会导致模拟的方式不同，虚拟机计算性能上略有区别，在虚拟机操作系统支持的情况下，1×16的计算性能会更好，因此这样该虚拟机中的16个vCPU对应的物理CPU属于同一NUMA域，能够避免跨域访问。
虚拟网卡的优化主要包括：关闭虚拟机电源，进行虚拟机网卡属性调整，也就是设计虚拟网卡支持虚拟网卡队列，具体如下：
设定虚拟网卡驱动类型为virtio，使虚拟网卡具有高性能驱动。配置virtio多队列，设定queues＝vCPU个数，也就是一个虚拟网卡队列对应一个虚拟网卡，而一个虚拟网卡供一个vCPU使用。设置完成后开启虚拟机，使虚拟网卡队列生效。
虚拟交换机的优化主要包括：默认虚拟交换机不开启组播支持，当需要支持组播时，通过命令配置mcast_snooping＝true，使其支持组播转发；设定mcast-snooping-disable-flood-unregistered＝true，禁止不在组播组中的端口接收组播消息，优化组播转发。SDN控制器监控组播组和其中的成员，当组播组发生变化时，重新更新OpenFlow流表并下发，以提高组播转发效率。
可见，本实施例针对UDP组播业务的特点，针对性优化组播，实现了高性能的组播业务。通过对虚拟化系统、虚拟机、虚拟网卡、虚拟交换机优化设定，有效降低了组播业务丢包率，提高网络传输性能。在不增加用户成本的前提下，支持高性能组播业务的实现。经验证，本实施例将组播丢包率从0.1‰下降到0.00001‰，能够满足绝大多数用户使用场景。组播是IP网络数据传输方式之一，一般通过UDP协议实现，因此也称为UDP组播。
下面对本申请实施例提供的一种组播业务处理装置进行介绍，下文描述的一种组播业务处理装置与上文描述的一种组播业务处理方法可以相互参照。
参见图2所示，本申请实施例公开了一种组播业务处理装置，包括：
接收模块201，用于通过多个虚拟网卡队列并行接收网络报文；
处理模块202，用于若网络报文属于组播业务，则利用多个虚拟CPU并行处理网络报文，并按照OpenFlow流表传输处理后的网络报文；其中，虚拟网卡队列与虚拟CPU一一对应；多个虚拟CPU对应的物理CPU属于同一NUMA域。
在一种具体实施方式中，处理模块具体用于：
若任一个虚拟CPU对应有多个业务的处理进程，则控制组播业务的处理进程优先处理网络报文。
在一种具体实施方式中，处理模块具体用于：
按照OpenFlow流表将处理后的网络报文传输至OpenFlow流表对应的组播组。
在一种具体实施方式中，还包括：
调整模块，用于当组播组更新后，按照更新后的组播组调整OpenFlow流表。
在一种具体实施方式中，每个虚拟CPU在单位时钟周期内占用的物理CPU资源高于预设的阈值。
其中，关于本实施例中各个模块、单元更加具体的工作过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。
可见，本实施例提供了一种组播业务处理装置，该装置能够提高组播业务的处理效率，避免丢包现象的发生。
下面对本申请实施例提供的一种云平台进行介绍，下文描述的一种云平台与上文描述的一种组播业务处理方法及装置可以相互参照。
参见图3所示，本申请实施例公开了一种云平台，包括：虚拟机301和虚拟交换机302、SDN控制器303，其中：
虚拟机包括：多个虚拟网卡和多个虚拟CPU，多个虚拟CPU对应的物理CPU属于同一NUMA域，虚拟网卡和虚拟CPU一一对应，其中：
多个虚拟网卡，用于并行接收网络报文；虚拟网卡队列与虚拟CPU一一对应；
多个虚拟CPU，用于若网络报文属于组播业务，则并行处理网络报文；
虚拟交换机，用于按照OpenFlow流表传输处理后的网络报文；
SDN控制器，用于更新OpenFlow流表。
参见图4所示，本申请实施例公开了另一种云平台，包括：SDN控制器和多个虚拟交换机，每个虚拟交换机连接有多个虚拟机，每个虚拟机包括多个虚拟网卡和多个虚拟CPU，其他详细内容请参照上述实施例的介绍本实施例不再详述。
本实施例提供的云平台能够提高组播业务的处理效率，避免丢包现象的发生。
下面对本申请实施例提供的一种组播业务处理设备进行介绍，下文描述的一种组播业务处理设备与上文描述的一种组播业务处理方法及装置可以相互参照。
参见图5所示，本申请实施例公开了一种组播业务处理设备，包括：
存储器501，用于保存计算机程序；
处理器502，用于执行所述计算机程序，以实现上述任意实施例公开的方法。
下面对本申请实施例提供的一种可读存储介质进行介绍，下文描述的一种可读存储介质与上文描述的一种组播业务处理方法、装置及设备可以相互参照。
一种可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述实施例公开的组播业务处理方法。关于该方法的具体步骤可以参考前述实施例中公开的相应内容，在此不再进行赘述。
本申请涉及的“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法或设备固有的其它步骤或单元。
需要说明的是，在本申请中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的可读存储介质中。
本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。