CN112087332A - 一种云边协同下的虚拟网络性能优化系统 - Google Patents

一种云边协同下的虚拟网络性能优化系统 Download PDF

Info

Publication number
CN112087332A
CN112087332A CN202010917539.9A CN202010917539A CN112087332A CN 112087332 A CN112087332 A CN 112087332A CN 202010917539 A CN202010917539 A CN 202010917539A CN 112087332 A CN112087332 A CN 112087332A
Authority
CN
China
Prior art keywords
virtual
communication
cloud
resources
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010917539.9A
Other languages
English (en)
Other versions
CN112087332B (zh
Inventor
张伟哲
方滨兴
何慧
王德胜
周擎阳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Harbin Institute of Technology
Original Assignee
Harbin Institute of Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Harbin Institute of Technology filed Critical Harbin Institute of Technology
Priority to CN202010917539.9A priority Critical patent/CN112087332B/zh
Publication of CN112087332A publication Critical patent/CN112087332A/zh
Application granted granted Critical
Publication of CN112087332B publication Critical patent/CN112087332B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种云边协同下的虚拟网络性能优化系统，属于边缘计算技术领域，用以解决云边平台交互中网络时延问题。该系统包括系统部署模块和系统架构模块，其中，系统部署模块负责把容器和虚拟机按照相关算法部署在不同或者相同的服务器上，算法通过合并发送相同数据的虚拟节点到同一个物理主机上，使系统在通信前就尽可能的把要通信的数据量降到最低；系统架构模块则负责在部署之后完成服务器本身以及服务器和服务器之间的通信，系统架构使得虚拟机和容器之间能够高效率的无障碍通信。系统部署模块和系统架构模块相辅相成，共同解决了边缘云内部以及边缘云和中心云之间的网络时延问题，最大程度地减少云边平台交互中的网络时延。

Description

一种云边协同下的虚拟网络性能优化系统
技术领域
本发明涉及边缘计算技术领域，具体涉及一种云边协同下的虚拟网络性能优化系统。
技术背景
边缘计算是云计算方向的崭新领域，相比较传统的云计算，它使得服务更加贴近用户端，并且能对用户的行为做出更快、更准确的反应。通过边缘计算，用户也可以更方便快速定制自己设计的程式。因此，边缘计算在物联网行业，尤其是在无人驾驶、智慧城市、监视、虚拟现实和实时交通监视等方面被广泛应用。
但是在实际部署中，中心云和边缘云之间的通信问题依然亟待解决。如果云边通信不能够在大流量情况下依然保持平稳使用，出现延迟忽高忽低的情况，那么对于类似智能交通这种对时延要求苛刻的任务，云边协同将失去它应有的意义。
在实际云边平台交互中，通信的时延和不稳定性一直是难以解决的问题。时延过长会导致云边协同失去其存在意义，而通信过程不稳定使得很多系统会存在许多安全隐患。在云平台上有一套完整的软件定义网络来解决网络通信问题，而很多传输层面的通信优化算法都可以直接移植到软件定义网络技术上。但是在边缘平台上，尤其是在云边交互上通信有着自身的特点：边缘平台上的节点既有自身的独立性，同时又和云计算平台有相对紧密的联系。目前大多数的现有技术，依然是基于云平台的软件定义网络技术，把云计算的网络虚拟解决方案移植到边缘平台上，这样虽然能够保证边缘平台上虚拟节点的独立性，但是并没有彻底挖掘边缘平台和云平台在通信层面上不同所在，更加没有考虑优化边缘平台和中央云计算平台的通信。因此，在保证虚拟节点在边缘计算节点上独立性的前提下，如何提高虚拟节点和中央云之间的通信速度是亟待解决的问题。
发明内容
本发明要解决的技术问题是：本发明在保证虚拟节点在边缘计算节点上独立性的前提下，优化虚拟节点和中央云之间的通信速度，进而提供了一种云边协同下的虚拟网络性能优化系统，用以解决云边平台交互中网络时延问题。
本发明为解决上述技术问题所采用的技术方案是：
该系统包括系统部署模块和系统架构模块，所述系统部署模块用于根据设计算法将容器和虚拟机部署在不同或者相同的服务器上；所述系统架构模块用于在部署之后完成服务器自身，以及服务器之间的通信。
进一步地，系统部署模块中所述设计算法包括LPT-优先保证计算节点资源算法，所述LPT-优先保证计算节点资源算法的具体步骤为，首先对于所有虚拟节点进行资源分配；然后对于仍然包含未分配虚拟节点的资源组进行拆组重新分配，分配的原则是首先在剩余资源最多的物理节点上分配，如果物理节点达到了资源上限，那么资源组接下来在剩余资源次多的物理节点上分配，以此类推；其中，资源组定义为互相之间产生联系的所有虚拟节点。
进一步地，系统部署模块中所述设计算法包括LPT-优先保证平均分布算法，所述LPT-优先保证平均分布算法的具体步骤为，首先对于所有虚拟节点进行资源分配；然后引入优先队列，优先队列以物理节点上已部署的资源作为权重；然后以优先队列为分配依据，使得剩余未分配的虚拟节点可以按照当前物理节点上已部署资源从少到多进行填充。
进一步地，LPT-优先保证平均分布算法中对于除了已经达到上限的物理资源节点，所有物理资源节点容纳的资源都相等的情况，资源将会被均匀的分配至每一个节点上。
进一步地，所述对于所有虚拟节点进行资源分配的方法为采用LPT最长时间处理算法进行资源分配。
进一步地，所述系统架构模块包括同一物理节点架构模块和不同物理节点架构模块；其中，同一物理节点架构模块中采用共享内存技术即允许两个不相关的进程访问同一个逻辑内存，把相同的物理地址映射到不同进程的虚拟地址，从而进行进程间通信；不同物理节点系统架构模块中采用RDMA(远程直接数据存取)进行通信。
进一步地，对于容器采用共享内存技术进行通信时，把共享内存直接挂载即可进行通信。
进一步地，对于虚拟机采用共享内存技术进行通信时，首先将物理地址和用户内核态中的一个PCI设备进行对应；然后在用户机用户态中将对应的PCI地址取出，并映射到本身的用户机进程中即可完成通信。
进一步地，系统架构模块中选择利用unix domain socket(进程间通信，又叫IPCsocket)来将同一物理节点架构模块和不同物理节点架构模块相结合，具体包括在物理主机上启用unix socket服务器，在虚拟节点写入数据，写入完毕后通知IPC服务器，IPC服务器收到信号后通知RDMA客户端，RDMA客户端收到信号后，把数据推送到远端RDMA服务端中，从而完成本机以及远程的通信。
本发明具有以下有益技术效果：本发明系统部署模块负责把容器和虚拟机，按照相关算法部署在不同或者相同的服务器上，算法通过合并发送相同数据的虚拟节点到同一个物理主机上，使系统在通信前就尽可能的把要通信的数据量降到最低；系统架构模块则负责在部署之后完成服务器本身，以及服务器和服务器之间的通信，系统架构使得虚拟机和容器之间能够高效率的无障碍通信。系统部署模块和系统架构模块相辅相成，共同解决了边缘云内部以及边缘云和中心云之间的网络时延问题，最大程度上使得边缘计算可以投入实用。
附图说明
图1示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统的整体结构示意图。
图2示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中同一物理主机上的虚拟网络架构设计的通信流程图。
图3示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中不同物理主机上的虚拟网络架构设计的拓扑架构图。
图4示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中不同物理主机上的虚拟网络架构设计的通信流程图。
图5示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中系统架构模块设计的通信流程图。
图6示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中系统部署模块设计的性能测试图。
图7示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中同一物理主机上的虚拟网络架构设计的通信优化对比图。
图8示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中不同物理主机上的虚拟网络架构设计的通信优化对比图。
具体实施方式
为使本领域的技术人员更好地理解本发明的技术方案，下面结合附图来对本发明进行详细描述。
本发明为了深刻挖掘边缘计算的通信特点，在保证虚拟节点在边缘计算节点上独立性的前提下，优化虚拟节点和中央云之间的通信速度，进而提供了一种云边协同下的虚拟网络性能优化系统。图1示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统的整体结构示意图。
如图1所示，该优化系统包括系统部署模块和系统架构模块，系统部署模块用于根据设计算法将容器和虚拟机部署在不同或者相同的服务器上；系统架构模块用于在部署之后完成服务器自身，以及服务器之间的通信。
进一步地，系统部署模块中设计算法包括LPT-优先保证计算节点资源算法，LPT-优先保证计算节点资源算法的具体步骤为，首先对于所有虚拟节点进行资源分配；然后对于仍然包含未分配虚拟节点的资源组进行拆组重新分配，分配的原则是首先在剩余资源最多的物理节点上分配，如果物理节点达到了资源上限，那么资源组接下来在剩余资源次多的物理节点上分配，以此类推；其中，资源组定义为互相之间产生联系的所有虚拟节点。
进一步地，系统部署模块中设计算法包括LPT-优先保证平均分布算法，LPT-优先保证平均分布算法的具体步骤为，首先对于所有虚拟节点进行资源分配；然后引入优先队列，优先队列以物理节点上已部署的资源作为权重；然后以优先队列为分配依据，使得剩余的未分配虚拟节点可以按照当前物理节点上已部署资源从少到多进行填充。
进一步地，LPT-优先保证平均分布算法中对于除了已经达到上限的物理资源节点，所有物理资源节点容纳的资源都相等的情况，资源将会被均匀的分配至每一个节点上。
进一步地，对于所有虚拟节点进行资源分配的方法为采用LPT最长时间处理算法进行资源分配。
进一步地，系统架构模块包括同一物理节点架构模块和不同物理节点架构模块；其中，同一物理节点架构模块中采用共享内存技术即允许两个不相关的进程访问同一个逻辑内存，把相同的物理地址映射到不同进程的虚拟地址，从而进行进程间通信；不同物理节点架构模块中采用RDMA(远程直接数据存取)进行通信。
进一步地，对于容器采用共享内存技术进行通信时，把共享内存直接挂载即可进行通信。
进一步地，对于虚拟机采用共享内存技术进行通信时，首先将物理地址和用户内核态中的一个PCI设备进行对应；然后在用户机用户态中将对应的PCI地址取出，并映射到本身的用户机进程中即可完成通信。
进一步地，系统架构模块中选择利用unix domain socket(进程间通信，又叫IPCsocket)来将同一物理节点架构模块和不同物理节点架构模块相结合，具体包括在物理主机上启用unix socket服务器，在虚拟节点写入数据，写入完毕后通知IPC服务器，IPC服务器收到信号后通知RDMA客户端，RDMA客户端收到信号后，把数据推送到远端RDMA服务端中，从而完成本机以及远程的通信。
本发明通过两个方面进行设计从而满足需求：系统架构模块设计和系统部署模块设计。其中系统部署模块设计则是根据相关算法，解决需求中提出的部署问题；系统架构模块设计又分为同一物理节点上架构模块设计和不同物理节点上架构模块设计。下面分别进行阐述。
具体实施例一
在云边平台仿真模拟过程模拟背景下，部署模块的问题建模与相关算法验证。
对模拟过程在部署层面遇到的的问题进行合理抽象，在满足需求条件的前提下完成有关算法的设计。
实际中在部署层面遇到了相关的问题：在实际情况下，经常会遇到多个虚拟节点尝试发送相同的数据的情况。那么，系统能否在部署层面上就尝试合并发送相同数据的虚拟节点到同一个物理主机上，从而能够达到减少数据通信量的目的？如果仅仅使用前面的架构模块，则只能优化通信时带来的时延问题，而不能在通信前就尽可能的把要通信的数据量降到最低。
本发明首先给出相关的数学描述：由于边缘云和中央云的相似性，因此统一用C1...Cn来表示边缘计算节点和中央云节点，并把它们统称为云端节点。其中n为边缘云和中央云的总和。在每一个云端Ci上，有Wi个计算节点，负责启动以及运行虚拟节点。同时，本发明假定所有的计算节点拥有资源上限分别为L1...LWi。
为了更好的体现把相同通信节点部署到同一个物理节点这种想法，本发明把互相之间产生联系的所有虚拟节点称之为一资源组。根据实际情况，本发明合理假设虚拟节点在云端之间无法迁移，但是虚拟节点可以在云端内部进行合理迁移。也即是说，当需要部署的虚拟节点总量定下来后，每一组在每个云端上布置的资源总量也就确定了。因此系统用一个n元组R＝(R1,R2,...,Rn)作为资源组的数学表达。其中Ri表示，在第i个云端节点Ci上，需要的虚拟节点资源总量。在这里，系统简单的用虚拟机与容器个数的加权和表示，即公式(1)。
Ri＝α*Niv+β*Nic (1)
其中，Niv表示在第Ci的云端上，需要部署的虚拟机的个数；Nic表示在第Ci的云端上，需要部署的容器的个数。ɑ，β分别是虚拟机和容器所占资源的加权。
由资源组定义，本发明可以很轻松的导出下列结论：所有的通信只能在资源组内发生，资源组之间并不会产生通信请求。因此，本发明就把虚拟节点的部署问题，转换为资源组的部署问题。
通过考察单个云端中，在系统架构模块的基础上，每个资源组在物理节点上的分布系统性能的影响，本发明得出了这样的结论：单个云端中，系统的整体性能并不取决于单个物理节点上部署虚拟节点的多少，而是取决于每个资源组占用了多少个物理节点。根据前一节的介绍，系统实际上是以物理节点为单位，而不是以虚拟节点为最小通信单位来进行数据传输的。这就导致了系统的整体性能并不取决于虚拟节点的具体放置方案，而是取决于资源组能否尽可能少的占用物理计算节点。因此，如果尽可能的把某一个云端上的某一资源组所需要的资源，完全部署在某一个物理节点上，则相同数据的传输量就会大量减少。
根据以上分析，本发明给出了云边平台仿真模拟过程中的部署问题具体的数学模型。
变量：
W1,W2,...,Wn:n个云端设备中含有的计算节点数目。
Li1,Li2,...,LiWi:第i个云端中，每一个计算节点的资源上限。
R1,R2,...,Rk：k个资源组，其中每一个Ri＝(Ri1,Ri2,...,Rij,...,Rin)，表示每一个资源组Ri，在第j个云端上需要消耗的虚拟节点资源总量。
Gc(r,w)：表示部署方案，Gc(r,w)表示在第c个云端上，第r资源组，即Rrc部署到第w个机器上的资源量。
F(Gc)：评价函数，表示对Gc部署方案的评估。
详细的变量表示如表1所示。
表1部署模块数学模型的变量
Figure BDA0002665552420000061
目标函数：
Figure BDA0002665552420000062
限制条件：
1)计算节点数目限制：
Figure BDA0002665552420000071
2)所有组资源被分配，且被完全分配：
Figure BDA0002665552420000072
3)分配过程中，分配到某一个物理节点上的资源不能超过每个物理节点的资源上限。
Figure BDA0002665552420000073
评价函数，系统可以有多种选择，根据相关背景，系统选择了能够让组资源比较均匀分布的评价函数。这是因为只有这种分布，才能更大意义上的保证系统的平稳性。不会因为性能问题而最后不能满足对于实时性的要求。综上，系统选了公式(6)作为最后的评价函数。
Figure BDA0002665552420000076
公式的含义，是选择能够同时最小化资源组占用物理机的个数，以及在每个云端节点上，每个计算节点包含资源的最大值最小的那种方案。可以看出，公式(6)是一个偏序集。这也就意味着，问题可能会存在多个互相不能比较大小的最优解。如何根据具体情况在这些最优解中选择最合适的部署方案，是本发明启发式算法中最重要的问题。根据不同的情况，本发明给出了不同的启发式算法。
算法1资源无限情况下的部署算法
当计算节点资源趋向于无穷大，公式(5)就失去了意义。而此时既然计算节点资源无穷多，那么所有的组资源都可以被放在同一个物理节点上。也就是说，在这种条件下，公式(7)成立：
Figure BDA0002665552420000074
同时，那么所有的组资源都可以被放在同一个物理节点上，那么目标函数里面的第一维就失去了意义。也就是说，目标函数变成了公式(8)。此时目标函数从一个偏序集变成了全序集，这也就意味着，一定会有一个最有解而不是有一组最优解，即此时系统则不需要考虑选择最优解的问题。
Figure BDA0002665552420000075
为了更好说明计算节点资源趋向于无穷大时候问题是一个NP-Hard的问题，首先介绍多核进程调度问题：假设有一个系统，其中有m个CPU，而系统中有n个程序等待处理。第i个程序预计处理时间为Ti。问题是请给出一个调度算法，使得n个程序尽可能短的在m个CPU中被处理完毕。
这是一个十分经典的NP-Hard问题，其本质为数字分割问题。下面将要证明，当计算节点资源趋向于无穷大时候，部署问题可以规约到此问题上，因此计算节点资源趋向于无穷大时候的部署问题也是一个NP问题。
命题：以公式(8)为目标函数，公式(3)，公式(4)，公式(7)为约束条件，计算节点资源趋向于无穷大的部署问题是NP-Hard问题。
证明：对于上文描述的多核进程调度问题，对于每一个云端，算法做如下规约：把R1c,...,Rkc看做k个进程对应的时间T1,...,Tk，把Wc个物理节点看成m个CPU。因此，寻找使得k个资源在Wc上最大值尽可能小的部署方案，就转化为了寻找使得n个程序尽可能短的在m个CPU中被处理完毕这样的部署方案。说明计算节点资源趋向于无穷大时，每一个云端中的部署问题都可以规约到多核进程调度问题。而多核进程调度问题是NP-Hard问题，则每一个云端中，命题中的部署问题也是NP-Hard问题。又由于云端间相互独立，所以整体来看，当所有的计算节点资源都趋向于无穷大时，命题中给出的部署问题是NP-Hard问题。证讫。
既然需要求解的问题，存在于变为NP-Hard问题的可能性，本发明自然考虑修改相关启发式算法，在启发式算法中加入有关限制条件，从而完成解决部署过程中遇到的难题。
上文提到的多CPU调度问题本质上是数字分组问题。数字分组问题被人戏称为“最简单的最难问题”，这是因为实际上其有动态规划算法，但是时间复杂度依然不是线性的。常见的启发式计算法中，最长时间处理算法(LPT)是最常见的算法，这是一个标准的贪心算法。把LPT算法对应到要求解的问题中便为下述算法1。算法1伪代码表述如下所示。
Figure BDA0002665552420000081
Figure BDA0002665552420000091
若要优先保证资源组使用的物理计算节点数目最少，则需要在算法1中做有关改动。具体来说，系统首先按照算法1的方式对于所有虚拟节点进行分配。随后，对于所有没有分配的资源，也就意味着其无法在某一个物理节点上完全分配，系统需要考虑把资源组拆开然后进行分配。资源组首先在剩余资源最多的物理节点上分配，如果物理节点达到了资源上限，那么资源组接下来在剩余资源次多的物理节点上分配，以此类推。由此，提出优先保证资源组使用的计算节点资源最少的算法2，称为LPT-优先保证计算节点资源算法，算法2伪代码如下所示。
Figure BDA0002665552420000092
Figure BDA0002665552420000101
在3-11行第一个for循环中，系统首先把那些能够在限制以内的资源组放置在物理节点上。在13-27行第二个for循环中，系统循环的对于每一个不能满足条件的资源组，把它们以最少分组的思路放置在物理节点上，从而完成了部署方案的创建。
根据堆的性质，对有N个元素的堆进行插入操作的时间复杂度是O(logN)。因此在最差的情况下，3-11行的时间复杂度为O(KlogN)。而13-27行中时间复杂度，在最差情况为O(KN)。因此整体算法的时间复杂度为O(KN)。可以知道此算法的时间复杂度为多项式级别的，符合具体需求。
那么，为了优先保证虚拟节点平均分布，提出LPT-优先保证平均分布算法，系统首先也是把所有能部署的资源组都部署到物理节点上。但是对于不能部署的资源组，系统采取了另一种思路：系统不再是按照空闲资源的大小挑选物理节点，而是按照已经部署多少资源的顺序来部署物理节点。对于某一个无法单独部署到计算节点的资源组来说，系统首先计算出物理节点中，物理节点已经消耗资源的最大值，然后所有节点以这个最大值为上限去部署相关资源组。这样的好处在于系统可以尽可能保持部署个数平均，从而使得系统中的物理节点消耗的资源也比较平均。算法3伪代码如下所示。
Figure BDA0002665552420000111
Figure BDA0002665552420000121
算法3在3-11行，和算法2相同，也是首先把所有能放置的资源节点都放置到物理节点上。在第13行，算法引入了优先队列p，其以物理节点上已部署的资源作为权重。在第14-42行，算法对根据优先队列的情况，按照当前物理节点上已部署资源从少到多进行填充。值得注意的是在16-18行，系统考虑了如果所有物理节点都已经被“填平”的后果：也就是除了那些已经达到上限的物理资源节点，所有物理资源节点容纳的资源都相等，那么资源将会均匀的放置在每一个节点上。
类似于上一个算法，3-11行的时间复杂度为O(KlogN)。而14-42行中时间复杂度，在最差情况为O(KN)。因此整体算法的时间复杂度为O(KN)。可以知道此算法的时间复杂度为多项式级别的，符合具体需求。
本发明提出算法2和算法3两种算法，在实际应用中，系统需要在性能和传输速度中平衡取舍。算法2可以最大程度的保证传输速度，但是可能会导致系统在某些特定物理节点上过于拥挤；而算法3可以保证分布的平均性，但是同时会导致牺牲传输速度。在实际中可以根据实际情况选择应用。
具体实施例二
云边协同下在同一物理主机上的虚拟网络架构设计，即同一物理节点架构模块设计。在同一物理主机上，本发明完成相关设计使得虚拟机和容器之间能够高效率的无障碍通信。图2示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中同一物理主机上的虚拟网络架构设计的通信流程图。
在相同的物理主机上，由于不同的虚拟技术、不同的虚拟网络架构导致在虚拟机和容器这两种常见的虚拟架构中，直接进行通信相当的困难。同时，由于多层网络虚拟化的原因，容器和虚拟机在同一物理主机上进行相互访问会有一些不必要的性能损失。因此本发明在同一物理节点上架构模块设计中解决的问题就是如何解决在同一物理节点上，虚拟机和容器之间访问障碍的低效问题。本发明中采用共享内存技术来解决这一难题。
共享内存就是允许两个不相关的进程访问同一个逻辑内存。为了更好的利用物理内存资源，linux中MMU硬件会进行虚拟地址到物理地址的映射。本发明实际上把相同的物理地址映射到不同进程的虚拟地址，这样不同的进程实际上就会操作相同的物理内存，达到了进程通信的目的。
本发明使用了POSIX方案进行进程间通信，利用shm_open在/dev/shm文件夹下创建了一个虚拟文件。利用mmap把相关内存映射到用户空间的指针上。虽然是看起来这种方式创造了一个文件，但是实际上，这个文件只存在于内存之中，是一个类型为tmpfs的内存块以文件的形式展现。进程可以像操作文件一样操作共享内存。这样把共享内存映射到虚拟机的问题就转化为把文件映射到虚拟机的问题，大大减少了逻辑难度。
在使用共享内存中，虚拟机和容器也是采取了不同的解决办法。容器由于和进程在内存层面有很多相似之处，因此简单的利用docker本身提供的挂载功能，把共享内存文件挂载到docker之中，docker就可以直接操作共享内存而不需要借助其他的工具。
虚拟机层面上，DPDK提供了称为ivshmem的工具。Ivshmem的核心思路，是利用QEMU提供的PCI模拟，在虚拟机一侧，把共享内存模拟成PCI设备，另一侧利用PCI设备的特点，把共享内存地址在虚拟机的PCI驱动中进行注册。这样，系统以为自己在访问一个新的PCI设备，其实他在读取系统内部的共享内存数据，从而达到了数据交互的目的。
综上所述，容器层面，共享内存直接挂载即可进行通信。虚拟机层面，首先本发明使用ivshmem技术，把物理地址和用户的内核态中某一个PCI设备进行对应。然后在用户机用户态中，本发明利用设备映射技术，取出对应的PCI地址，映射到本身的用户机进程中，从而完成有关通信。通过多种方案的比较和尝试，最终本发明选择了共享内存技术作为同一物理节点上的网络优化通信方案。
具体实施例三
云边协同背景下在不同物理主机上的虚拟网络性能架构设计，即不同物理主机架构模块设计。在不同物理主机上，能够利用相关技术，减少数据在网络传输的延迟，达到数据传输效率的提升。本发明在不同物理节点上架构模块设计中解决的问题就是如何通过相关技术，解决在不同物理节点上，虚拟机和容器访问的低效问题。本发明最终采用了RDMA技术来解决这一问题。结合云边协同背景下在同一物理主机上的虚拟网络架构设计，图3示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中不同物理主机上的虚拟网络架构设计的拓扑架构图。
此架构设计主要涉及到RDMA客户端和服务端的操作。RDMA使用了标准的CS架构：服务器端监听特定的频道(channel)，客服端负责发送信息。具体来说，双方的通信有建立连接阶段和发送数据两个阶段。对于不同阶段的不同状态，系统有着不同的操作。图4示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中不同物理主机上的虚拟网络架构设计的通信流程图。
RDMA在发送阶段有5种状态需要处理。首先服务器端要进入监听数据的状态，然后客户端会发起连接要求。客户端首先要处理服务器端的IP地址，并把IP地址转换为RDMA能够理解的地址，其次服务器端要根据IP地址解决路由问题，当客户端成功连接上服务器时，服务器端就进入了连接要求状态。这里服务器端通过一定的手段，判断客户端是否满足安全性需求。如果满足，服务器端就会建立这次连接的RDMA环境，建立PD，CQ，QP等队列，并把上文提到的共享内存地址推送到接受队列中。服务器完成环境建立后，自己会进入连接完成状态，同时会向客户端发送信息，客户端接受到信息后也会进入连接完成状态。此时双方连接完成，都进入了发送信息的状态。如果想要传输数据，只需要客户端往发送队列中推送有关数据地址即可。此时RDMA会自动检测客户端发送队列中有没有数据，而服务器端会在每次接受数据之后都把内存再次推送到接受队列中准备下一次的通信。
本发明在RDMA实现中，会在每一个物理节点上面启动一个RDMA sever和RDMAclient，这样发送数据的时候推送数据到RDMA client上，接受数据的时候直接在RDMAserer上进行观察即可。这样的传输高效便捷，比传统的TCP/IP节约了不少的时间。
具体实施例四
本发明最后考虑如何把跨物理节点上的RDMA通信解决方案和单一物理节点上的共享内存解决方案进行结合。本发明最后选择利用unix domain socket通信来达到目的。IPC通信不通过网络栈而是通过信号传递的形式传输数据，这样提升了通信的效率。图5示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中系统架构模块设计的通信流程图。
系统在物理主机上启用一个unix socket服务器，当数据彻底完成写入之后，不论是容器还是虚拟机都会向服务器发送信号。服务器接受到信号之后，就意味着数据已经彻底写入共享内存中，可以向远端发送了。因此服务器会调用RDMA模块，把数据发送出去。系统通信的具体步骤为：虚拟节点写入数据-写入完毕后通知IPC服务器-IPC服务器收到信号后通知RDMA客户端-RDMA客户端收到信号后，把数据推送到远端的RDMA服务端中。
具体实施例五
作为测试的比较组，本发明采用常见的Kafka方案作为基础对照组。Kafka是一个分布式的发布-订阅消息系统，能够支撑海量数据的数据传递，Kafka会将消息持久化到磁盘中，并对消息创建了备份保证了数据的安全，Kafka在保证了较高的处理速度的同时，又能保证数据处理的低延迟和数据的零丢失。
1)验证在云边平台仿真模拟过程模拟背景下，系统部署模块设计的有效性。
假设当前云节点有两个物理计算主机，两个资源组，每一个资源组分别具有一个虚拟机和n个容器，本发明采用以下三种方案来比较算法性能：(a)Kafka方案：所有的虚拟节点是随意的部署在所有的物理主机上，并用kafka进行数据传输；(b)随机部署方案：所有的虚拟节点是随意的部署在所有的物理主机上，并用系统架构模块进行数据传输；(c)使用本发明系统部署模块方案：由于在给定的情景下，LPT-优先保证计算节点资源算法和LPT-优先保证平均分布算法的结果相同，因此所有的虚拟节点按照上述算法的结果部署在所有的物理主机上，并用系统架构模块进行数据传输。系统分别取n＝50,100来测试。图6示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中系统部署模块设计的性能测试图。
如图6所示，当n＝50的时候，使用本发明系统部署模块方案比用Kafka方案传输数据时间延迟减少了10％，比随机部署方案时间延迟减少了5％；当n＝100的时候，使用本发明系统部署模块方案比用Kafka方案传输数据时间延迟减少了9％，比随机部署方案时间延迟减少了2％。可以看出，本发明系统部署模块设计可以有效的提升传输性能，主要的原因是本发明系统部署模块可以最大程度的使得部署方案规避网络传输这一性能瓶颈。实际上，本发明系统部署模块在提高了传输性能的同时也提高了稳定性，因为当系统越少的需要网络传输，它的稳定性也就有越高的提升。毕竟相比于内存读取，网络的不确定性质更大。
2)验证在云边协同背景下同一物理主机上的虚拟网络架构设计的有效性。
为了测试虚拟节点之间的通信优化，本发明设计了如下的测试方案：在Kafka中，启动一个虚拟机并使其作为生产者发送64KB的数据；分别启动1，10，20，30，40，50，60，70，80，90，100个容器作为消费者，检测其收到生产者发送数据的时间。在通信优化系统中，系统令其中一个虚拟机充当生产者的角色，负责发送64KB大小的数据；其他的容器充当消费者，负责接受生产者产生的数据。图7示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中同一物理主机上的虚拟网络架构设计的通信优化对比图。
如图7所示，Kafka方案在所有的列中通信的时延都大于本发明同一物理节点上系统架构设计方案的时延。通过计算每组提升百分比的加权平均可以看到，本发明同一物理节点架构模块设计方案相对于Kafka方案的时延降低了5％，这5％的优化来源于本发明系统不需要传输绝大部分的数据，证明了在同一物理节点上，相比较Kafka通信方式，本发明同一物理节点架构模块设计方案有着速度上的优势，也就说明了本发明同一物理节点架构模块设计方案的确起到了优化效果。
3)验证在云边协同背景下不同物理主机上的虚拟网络架构设计的有效性。
实验具体来说如下：Kafka方案和本发明不同物理节点架构模块设计方案都在物理主机1上启动一个虚拟机并使其作为生产者发送64KB的数据，二者分别在另一台物理主机2启动1，10，20，30，40，50，60，70，80，90，100个docker作为消费者，检测其收到生产者发送数据的时间。图8示出了根据本发明实施例一种云边协同下的虚拟网络性能优化系统中不同物理主机上的虚拟网络架构设计的通信优化对比图。
如图8所示，Kafka方案在所有的列中，时延都大于本发明不同物理节点架构模块设计方案的时延，进一步的，通过计算每组提升百分比的加权平均可以指出，本发明不同物理节点架构模块设计方案相对于kafka方案的时延降低了10％。和常见的不同物理节点上通信方案相比，本发明不同物理节点上系统架构设计方案带来的效果更加明显，这是因为10％的优化来源于通信优化只需要传输一次数据就可以完成所有数据的传输，从而更好的提升了性能。因此，本发明可以得出如下结论：不论是在不同物理节点还是在相同的物理节点上，本发明系统架构设计方案都相比较kafka通信方式有着速度上的优势，也就说明了本发明系统架构设计方案对于通信性能的优化的确起到了作用。
本发明在理论和实际两个层面上都具有重要的意义，理论上本发明抽象出了一类问题的数学模型并给出了解决方案，实际应用上深刻挖掘了边缘计算通信和云计算通信之间的不同，在保证虚拟节点独立性的前提下，利用相关算法与技术设计了符合边缘计算特性的网络优化系统，对于边缘计算平台上的通信优化问题提出了有针对性的解决方案。
尽管根据有限数量的实施例描述了本发明，但是受益于上面的描述，本技术领域内的技术人员明白，在由此描述的本发明的范围内，可以设想其它实施例。此外，应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。

Claims (9)

1.一种云边协同下的虚拟网络性能优化系统，其特征在于，包括系统部署模块和系统架构模块，所述系统部署模块用于根据设计算法将容器和虚拟机部署在不同或者相同的服务器上；所述系统架构模块用于在部署之后完成服务器自身，以及服务器之间的通信。
2.根据权利要求1所述一种云边协同下的虚拟网络性能优化系统，其特征在于，系统部署模块中所述设计算法包括LPT-优先保证计算节点资源算法，所述LPT-优先保证计算节点资源算法的具体步骤为，首先对于所有虚拟节点进行资源分配；然后对于仍然包含未分配虚拟节点的资源组进行拆组重新分配，分配的原则是首先在剩余资源最多的物理节点上分配，如果物理节点达到了资源上限，那么资源组接下来在剩余资源次多的物理节点上分配，以此类推；其中，资源组定义为互相之间产生联系的所有虚拟节点。
3.根据权利要求1所述一种云边协同下的虚拟网络性能优化系统，其特征在于，系统部署模块中所述设计算法包括LPT-优先保证平均分布算法，所述LPT-优先保证平均分布算法的具体步骤为，首先对于所有虚拟节点进行资源分配；然后引入优先队列，优先队列以物理节点上已部署的资源作为权重；然后以优先队列为分配依据，使得剩余未分配的虚拟节点可以按照当前物理节点上已部署资源从少到多进行填充。
4.根据权利要求3所述一种云边协同下的虚拟网络性能优化系统，其特征在于，LPT-优先保证平均分布算法中对于除了已经达到上限的物理资源节点，所有物理资源节点容纳的资源都相等的情况，资源将会被均匀的分配至每一个节点上。
5.根据权利要求3或4所述一种云边协同下的虚拟网络性能优化系统，其特征在于，所述对于所有虚拟节点进行资源分配的方法为采用LPT最长时间处理算法进行资源分配。
6.根据权利要求1所述一种云边协同下的虚拟网络性能优化系统，其特征在于，所述系统架构模块包括同一物理节点架构模块和不同物理节点架构模块；其中，同一物理节点架构模块中采用共享内存技术即允许两个不相关的进程访问同一个逻辑内存，把相同的物理地址映射到不同进程的虚拟地址，从而进行进程间通信；不同物理节点系统架构模块中采用RDMA进行通信。
7.根据权利要求6所述一种云边协同下的虚拟网络性能优化系统，其特征在于，对于容器采用共享内存技术进行通信时，把共享内存直接挂载即可进行通信。
8.根据权利要求6所述一种云边协同下的虚拟网络性能优化系统，其特征在于，对于虚拟机采用共享内存技术进行通信时，首先将物理地址和用户内核态中的一个PCI设备进行对应；然后在用户机用户态中将对应的PCI地址取出，并映射到本身的用户机进程中即可完成通信。
9.根据权利要求1所述一种云边协同下的虚拟网络性能优化系统，其特征在于，系统架构模块中选择利用unix domain socket来将同一物理节点架构模块和不同物理节点架构模块相结合，具体包括在物理主机上启用unix socket服务器，在虚拟节点写入数据，写入完毕后通知IPC服务器，IPC服务器收到信号后通知RDMA客户端，RDMA客户端收到信号后，把数据推送到远端RDMA服务端中，从而完成本机以及远程的通信。
CN202010917539.9A 2020-09-03 2020-09-03 一种云边协同下的虚拟网络性能优化系统 Active CN112087332B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010917539.9A CN112087332B (zh) 2020-09-03 2020-09-03 一种云边协同下的虚拟网络性能优化系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010917539.9A CN112087332B (zh) 2020-09-03 2020-09-03 一种云边协同下的虚拟网络性能优化系统

Publications (2)

Publication Number Publication Date
CN112087332A true CN112087332A (zh) 2020-12-15
CN112087332B CN112087332B (zh) 2022-06-21

Family

ID=73731526

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010917539.9A Active CN112087332B (zh) 2020-09-03 2020-09-03 一种云边协同下的虚拟网络性能优化系统

Country Status (1)

Country Link
CN (1) CN112087332B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112764877A (zh) * 2021-01-06 2021-05-07 北京睿芯高通量科技有限公司 一种用于硬件加速设备与docker内进程通信的方法与系统
CN113438678A (zh) * 2021-07-06 2021-09-24 中国联合网络通信集团有限公司 一种为网络切片分配云资源的方法及装置
WO2022183518A1 (zh) * 2021-03-02 2022-09-09 山东大学 一种面向云计算的高性能区块链架构方法
CN114826900B (zh) * 2022-04-22 2024-03-29 阿里巴巴（中国）有限公司 针对分布式云架构的服务部署处理方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105975330A (zh) * 2016-06-27 2016-09-28 华为技术有限公司 一种网络边缘计算的虚拟网络功能部署方法、装置和系统
US20180191623A1 (en) * 2016-12-29 2018-07-05 Google Inc. Dedicated-core computer hardware component
CN108287723A (zh) * 2016-12-30 2018-07-17 华为技术有限公司 一种应用交互方法、装置、物理机及系统
CN110365787A (zh) * 2019-07-19 2019-10-22 南京工业大学 一种应用容器并基于微服务框架的边缘计算最优化布局方法
CN110601913A (zh) * 2018-06-13 2019-12-20 丛林网络公司 虚拟化基础设施底层网络性能测量和监视的方法及系统
CN110750282A (zh) * 2019-10-14 2020-02-04 支付宝(杭州)信息技术有限公司 用于运行应用程序的方法、装置及gpu节点

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105975330A (zh) * 2016-06-27 2016-09-28 华为技术有限公司 一种网络边缘计算的虚拟网络功能部署方法、装置和系统
US20180191623A1 (en) * 2016-12-29 2018-07-05 Google Inc. Dedicated-core computer hardware component
CN108287723A (zh) * 2016-12-30 2018-07-17 华为技术有限公司 一种应用交互方法、装置、物理机及系统
CN110601913A (zh) * 2018-06-13 2019-12-20 丛林网络公司 虚拟化基础设施底层网络性能测量和监视的方法及系统
CN110365787A (zh) * 2019-07-19 2019-10-22 南京工业大学 一种应用容器并基于微服务框架的边缘计算最优化布局方法
CN110750282A (zh) * 2019-10-14 2020-02-04 支付宝(杭州)信息技术有限公司 用于运行应用程序的方法、装置及gpu节点

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112764877A (zh) * 2021-01-06 2021-05-07 北京睿芯高通量科技有限公司 一种用于硬件加速设备与docker内进程通信的方法与系统
CN112764877B (zh) * 2021-01-06 2024-04-26 北京中科通量科技有限公司 一种用于硬件加速设备与docker内进程通信的方法与系统
WO2022183518A1 (zh) * 2021-03-02 2022-09-09 山东大学 一种面向云计算的高性能区块链架构方法
CN113438678A (zh) * 2021-07-06 2021-09-24 中国联合网络通信集团有限公司 一种为网络切片分配云资源的方法及装置
CN113438678B (zh) * 2021-07-06 2022-11-22 中国联合网络通信集团有限公司 一种为网络切片分配云资源的方法及装置
CN114826900B (zh) * 2022-04-22 2024-03-29 阿里巴巴（中国）有限公司 针对分布式云架构的服务部署处理方法及装置

Also Published As

Publication number Publication date
CN112087332B (zh) 2022-06-21

Similar Documents

Publication Publication Date Title
CN112087332B (zh) 一种云边协同下的虚拟网络性能优化系统
US20200241927A1 (en) Storage transactions with predictable latency
US11334382B2 (en) Technologies for batching requests in an edge infrastructure
US10467725B2 (en) Managing access to a resource pool of graphics processing units under fine grain control
KR102103596B1 (ko) 계산 작업을 처리하기 위한 컴퓨터 클러스터 장치 및 이를 작동시키기 위한 방법
US20190208009A1 (en) Computing resource discovery and allocation
US10109030B1 (en) Queue-based GPU virtualization and management system
US20060026169A1 (en) Communication method with reduced response time in a distributed data processing system
CN104428752A (zh) 将虚拟机流卸载至物理队列
US11710206B2 (en) Session coordination for auto-scaled virtualized graphics processing
WO2011098482A1 (en) Optimized capacity planning
US20230100935A1 (en) Microservice deployments using accelerators
CN112286688A (zh) 一种内存管理和使用方法、装置、设备和介质
US20230138867A1 (en) Methods for application deployment across multiple computing domains and devices thereof
CN111158911A (zh) 一种处理器配置方法、装置、处理器及网络设备
CN110221902A (zh) 一种基于虚拟机的数据传输方法及相关装置
CN109558214B (zh) 异构环境下宿主机资源管理方法、装置和存储介质
US20210157626A1 (en) Prioritizing booting of virtual execution environments
CN110928683B (zh) 基于两类密集型虚拟机的边缘计算资源分配方法
Jeon et al. Large graph processing based on remote memory system
US11924336B1 (en) Cryptographic artifact generation using virtualized security modules
CN116723191B (zh) 利用加速装置执行数据流加速计算的方法和系统
CN108469990A (zh) 一种并行计算方法及系统
KR102368561B1 (ko) 하이브리드 클라우드 기반의 IoT 환경에서 실시간 동적 자원 할당 방법
CN113094320B (zh) 并行消息仲裁装置及方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant