基于图形集群的远程实时渲染平台构建方法专利检索-操作系统系统软件软件计算机系统电脑零配件专利检索查询-专利查询网

基于图形集群的远程实时渲染平台构建方法

阅读：1发布：2022-03-08

专利汇可以提供基于图形集群的远程实时渲染平台构建方法专利检索，专利查询，专利分析的服务。并且本发明公开了一种基于图形集群的远程实时渲染平台构建方法，包括利用Docker架构在图形集群内部实现虚拟桌面系统的部署；在虚拟桌面系统中嵌入VNC服务端，VNC客户端访问所述VNC服务端后，通过VNC协议建立远程桌面连接；图形集群根据远程桌面连接情况进行动态负载均衡，建立图形集群动态任务调度与管理机制；通过图形集群动态任务调度与管理机制，在平台客户端与图形集群服务端间建立实时图像传输通道,综合集成基于图形集群的远程实时渲染平台。本发明针对大量远程用户基于不同需求的渲染应用问题，根据面向多用户的异步分布式工作模式，依托图形集群硬件环境，利用虚拟化手段来满足不同用户按需使用的需求，既方便管理又确保了数据安全。，下面是基于图形集群的远程实时渲染平台构建方法专利的具体信息内容。

权利要求

1.基于图形集群的远程实时渲染平台构建方法，包括：
步骤一、利用所述Docker架构在图形集群内部实现虚拟桌面系统的部署；
步骤二、在所述虚拟桌面系统中嵌入VNC服务端，VNC客户端访问所述VNC服务端后，通过VNC协议建立远程桌面连接；
步骤三、图形集群根据远程桌面连接情况进行动态负载均衡，建立图形集群动态任务调度与管理机制；
步骤四、通过图形集群动态任务调度与管理机制，在平台客户端与图形集群服务端间建立实时图像传输通道,综合集成基于图形集群的远程实时渲染平台。
2.如权利要求1所述的基于图形集群的远程实时渲染平台构建方法，其特征在于，步骤一，具体包括：
在图形集群渲染节点操作系统上创建Docker容器；
将封装后的虚拟桌面系统做成Docker镜像存入共享存储系统中；
Docker容器通过加载Docker镜像，在图形集群内部实现虚拟桌面系统的部署，同时在虚拟桌面系统内实现基于Docker架构的GPU渲染加速。
3.如权利要求1或2所述的基于图形集群的远程实时渲染平台构建方法，其特征在于，所述在虚拟桌面系统内实现基于Docker架构的GPU渲染加速的步骤，包括：
将图形集群渲染节点操作系统的显卡驱程内核文件映射到Docker容器的集成环境中，同时调用OpenGL的窗口扩展插件，实现在虚拟桌面系统内的GPU实时渲染加速。
4.如权利要求1至3之一所述的基于图形集群的远程实时渲染平台构建方法，其特征在于，所述虚拟桌面系统的显示采用虚拟外接输出的方式，该方式包括：
为每一个Docker容器分配虚拟的显示输出，当用户访问该Docker容器时，Docker容器中的图形通过虚拟的显示输出，输出至客户端，使得GPU渲染不依赖于实际的图形卡输出接口。
5.如权利要求1所述的基于图形集群的远程实时渲染平台构建方法，其特征在于，步骤二具体包括：
VNC服务端利用分块匹配的区域变化检测算法对发生变化的图像区域进行筛选，经图像压缩后发送给对应的VNC客户端，通过VNC协议建立基于C/S架构的远程桌面连接。
6.如权利要求5所述的基于图形集群的远程实时渲染平台构建方法，其特征在于，所述VNC服务端利用分块匹配的区域变化检测算法对发生变化的图像区域进行筛选，包括：
设定需要变化检测的单位区域；
获取截获系统屏幕重绘区域的信息；
若截获的系统屏幕重绘区域小于单位区域，发送该区域位置信息；
若截获的系统屏幕重绘区域大于单位区域，将截获系统屏幕重绘区域进行拆分，将拆分区域的坐标信息存储至链表中，对链表中每个拆分区域的坐标信息进行遍历检测后得到需要重新发送的变化区域位置信息，将需要重新发送的变化区域的位置信息进行存储并发送。
7.如权利要求1所述的基于图形集群的远程实时渲染平台构建方法，其特征在于，步骤三中，所述图形集群动态任务调度与管理机制包括：
在一定的负载均衡策略下，由集群管理节点合理安排渲染节点为用户提供服务资源；
所述图形集群动态任务管理与调度涉及到包括但不限于单用户对单节点、多用户对单节点、单用户对多节点和/或多用户对多节点四种情况中的一种或多种情况间动态转换。
所述负载均衡策略包括：
在单用户对单节点情况下，采用轮询策略分配渲染节点；
在多用户对多节点的情况，综合考虑渲染节点的资源利用率、网络带宽以及I/O速率等指标，利用动态负载均衡模型求解渲染系统负载方差或标准差为极小值的单目标规划问题，得到优化后的图形集群负载均衡策略。
8.如权利要求1所述的基于图形集群的远程实时渲染平台构建方法，其特征在于，所述综合集成的基于图形集群的远程实时渲染平台包括平台客户端、图形集群管理节点、图形集群渲染节点和共享存储系统四个部分；
平台客户端部署于用户操作终端，用于向图形集群服务端发起应用请求；
图形集群管理节点和图形集群渲染节点部署于图形集群服务端，用于响应平台客户端发起应用请求；
共享存储系统，用于存储管理用户配置文件、虚拟桌面系统镜像和/或渲染模型数据信息。
9.如权利要求8所述的基于图形集群的远程实时渲染平台构建方法，其特征在于，步骤四具体包括：
将VNC客户端嵌入到平台客户端，Docker容器和VNC服务端嵌入到图形集群渲染节点，Docker镜像存储于共享存储系统中，由图形集群管理节点依据动态任务调度与管理机制进行集群负载均衡；
接收到平台客户端发起应用请求时，图形集群管理节点为平台客户端指定渲染节点，渲染节点启动Docker容器并加载Docker镜像，同时利用VNC协议建立远程实时渲染通道，为用户提供远程实时渲染服务。
10.如权利要求1-9之一所述的基于图形集群的远程实时渲染平台构建方法，其特征在于，
所述远程实时渲染平台的应用模式包括：
图形集群服务端在接到平台客户端发起的应用请求后，由图形集群管理节点将渲染任务分配至渲染节点，渲染节点通过创建独立的虚拟桌面系统为用户提供渲染服务。

说明书全文

基于图形集群的远程实时渲染平台构建方法

技术领域

[0001] 本发明属于计算机图形渲染技术领域，尤其涉及一种基于图形集群的远程实时渲染平台构建方法，用于给多用户提供一种远程实时高效的图形渲染环境，有助于军事仿真、教育训练、移动办公以及自主可控系统推广等方面的工作。

背景技术

[0002] 图形渲染系统是视景仿真、虚拟现实和增强现实等技术的实现基础。图形渲染解决方案从最初的基于SGI(Silicon Graphics，美国硅图公司)的专用图形工作站，发展到多机并联的图形集群系统，再到采用NVIDIA(美国英伟达公司)的SLI(Scaleable Link Interface，可升级连接界面)或AMD(Advanced Micro Devices，美国超微半导体公司)的CF(CrossFire，显卡交火)技术的多显卡图形工作站，硬件技术发展使得图形渲染应用模式呈现出螺旋上升的态势。为了解决大规模、远程、实时渲染的问题，同时也为了有效整合图形资源，提高资源使用效率，基于图形集群的渲染模式再次成为业界研究的焦点。

[0003] 一般情况下，与图形集群配套使用的集群渲染系统也称作分布式渲染环境或渲染农场，它是指由许多运行渲染软件的计算机组成，在集群渲染管理软件的统一调配下，协调工作以并行方式完成所分配的渲染任务。从实时性的角度大致可分为两类：一类是非实时渲染系统，即管理端向图形集群下发渲染指令，图形集群在一定的时间内完成渲染任务后将渲染场景发送至管理端或存储系统，再由用户检验调用渲染成果。这种渲染系统多用于影视、动漫制作等领域；另一类是实时渲染系统，即管理端向图形集群下发渲染指令，图形集群完成渲染任务后将渲染结果实时反馈给用户，同时响应用户的交互与控制指令。这种渲染系统多用于视景仿真和虚拟现实系统。

[0004] 通过对当前远程实时渲染平台相关的厂家与技术进行调研，发现其涵盖的核心技术主要包括VDI(Virtual Desktop Infrastructure，虚拟桌面架构)、VMM(Virtual Machine Monitor，虚拟机监视器)、DCV(Desktop Cloud Visualization，桌面云可视化)、vGPU(Virtual Graphics Processing Unit，虚拟图形处理器)等，其面向的应用情况主要体现在以下三个方面。

[0005] 1、单机访问单站获取虚拟桌面服务

[0006] 用户在本地安装客户端软件，远端的图形工作站节点安装服务软件，利用RDP(Remote Desktop Protocol，远程桌面协议)将图形工作站桌面虚拟到本地，实现对图形软件的远程访问与显示。

[0007] 事实上，基于Windows的RDP协议可以有效支持远程桌面的文件操作以及简单的文档处理等，但并不适合对视频以及动态图像的处理。在此基础上，惠普公司提出了RGS(Remote Graphics Software，远程图像软件)解决方案，该方案在RDP协议的基础上做了很多优化，包括使用具有自主专利的图像压缩/解压缩技术(可达到170:1的压缩率)，大大减小了网络传输负载，另外通过对RDP的扩展，能够实现远程多用户共享桌面服务的功能(Windows的远程桌面连接同一时间只允许一个用户访问，且访问后服务端变成锁屏状态；惠普的RGS允许多个用户同时访问服务端的桌面，而服务端的桌面还可以正常显示)。这种方案支持Windows、Linux和Unix 操作系统，基本上能够满足远程渲染任务的需求，但是该服务端软件要求必须安装在惠普的图形工作站上，并且在图形渲染资源的分配上并没有做其他的优化处理工作。

[0008] 2、多机访问单站获取虚拟桌面服务

[0009] 前面提到的方案比较适合于多人协同开展同一工作，不能满足多人通过共享图形资源来开展不同工作的需求，如果要实现每个用户都能够获取独立的虚拟桌面而又能共享图形资源，则需要在图形工作站节点上为每个用户都能开辟出独立的桌面系统，即VDI架构的部署与运行。目前，主流的VDI技术主要包括Hyper-V+RGS、XenServer+HDX和NICE DCV三种解决方案，对比分析如下：

[0010] (1)Hyper-V+RGS

[0011] Hyper-V(美国微软公司推出的基于Windows的虚拟化产品)内置于Windows Server 2008及以后的操作系统产品中，相对于微软过去的虚拟化技术多了一层操作系统，兼容性好，但速度较慢。Hyper-V让虚拟机可以较直接的使用实体主机的硬件资源，以提高虚拟系统之效能。Hyper-V借用微软平台优势切入到服务器虚拟化领域，但在对于Linux系统支持上，Hyper-V还有所不足。RGS软件的功能与不足如前所述。

[0012] (2)XenServer+HDX

[0013] XenServer(美国思杰公司推出的虚拟化软件产品)是一种全面而易于管理的服务器虚拟化平台，能高效地管理Windows和Linux虚拟服务器，可提供经济高效的服务器整合和业务连续性，XenServer具备了操作系统的功能，能直接安装在服务器上引导启动并运行。美国思杰公司的HDX(High Definition Experience，高清使用体验)则是针对桌面虚拟化和应用虚拟化市场推出的远程高清交互式产品，能实现对多媒体、语音、视频和3D图形交互。但在工程设计领域，该产品只能实现基于Windows平台的桌面虚拟化交互，而且无法实现对GPU资源的共享。

[0014] (3)KVM+NICE DCV

[0015] NICE DCV(美国亚马逊公司旗下的NICE公司推出的DCV产品)是一种能在标准网络上远程访问2D或3D应用的交互式产品，使用户可利用远端的3D高端图形卡、快速的I/O性能，以及大量的内存节点。值得强调的是，通过在KVM(Kernel-based Virtual Machine，基于内核的虚拟机)虚拟化平台上部署NICE DCV，能充分发挥该软件的性能。该方案能支持Linux操作系统，而且在硬件层面上NICE DCV支持各种GPU虚拟化技术，利用NVIDIA公司的专用图形卡配合vGPU驱程，给每个虚拟机分配vGPU，可在一定程度上实现了GPU资源的共享。

[0016] 3、多机访问图形集群获取虚拟桌面服务

[0017] 前面两种方案中提到的虚拟桌面服务，都是建立在单台图形工作站基础上实现虚拟桌面服务的，如果用户数量过多，则在单台图形工作站上创建虚拟机的形式就无法满足应用需求，因此就需要以多台图形工作站的形式来代替单台图形工作站，这就是图形集群的概念。第三种方案主要是建立在前两种方案的基础上，重点解决图形集群的聚合问题，即怎样组织管理当前的多台图形工作站，使他们能够像一台机器一样方便高效的实现对多用户的图形服务。

[0018] 如果要把独立的多台图形工作站聚合成为统一的图形集群系统，首先需要有渲染任务管理软件进行资源分配与调度，典型的如VCM(Visualization Cluster Manager，可视化集群管理器)和TechViz(法国TechViz公司的可视化软件产品)等。

[0019] (1)VCM

[0020] 以色列Orad公司推出的VCM是在图形集群管理节点上安装的集群管理软件，它是通过规划图形节点的连接方式来分配渲染任务，再利用专用集成接口实现图像的集成与同步。这种集群管理方式较好的实现了渲染任务的分配与管理，但其理念主要是为多通道显示系统提供服务，比较适合多路同步输出的大屏显示，在应用方面明显不够灵活与智能。

[0021] (2)TechViz

[0022] TechViz在集群管理方面采用了另外一种思路，在集群的管理节点上安装完整的图形应用软件，当图形应用软件运行后本来是要直接调用本地的图形卡进行渲染显示，但是TechViz软件将高分辨率的图形渲染任务以OpenGL(Open Graphics Library，开放图形库)指令流的形式通过网络分配到渲染节点上，再利用渲染节点的图形卡进行渲染输出，各渲染节点之间通过同步卡进行输出同步。这种集群管理方案不需要在渲染节点上安装图形应用软件，而且在渲染任务的分配上也要灵活很多。

[0023] (3)其他的软件

[0024] 除了上述两种软件外，国内外还有一些针对图形渲染的集群管理软件，比如Muster(美国Virtual Vertex公司的集群渲染软件)、Platform LSF(美国IBM公司的集群管理调度软件)和EnFuzion(中国拓林思公司的集群渲染软件)等，它们能实时管理和监视渲染节点的工作情况，避免渲染节点的空闲，使用户在最短的时间得到最终渲染产品。

[0025] 图形集群系统在为多用户提供远程实时渲染服务方面提供了良好的硬件基础，而现阶段的集群渲染软件系统研究多侧重于集群架构、集群管理、负载均衡以及并行渲染等方面，虽能够在同步并行模式下为用户提供更快速、更高效的解决方案，但并未解决大量远程用户基于不同需求的渲染应用问题。

[0026] 不同于传统意义上的集群渲染系统，本发明提出的技术主要采用面向多用户的异步分布式工作模式，依托图形集群硬件环境，利用虚拟化手段来满足不同用户按需使用的需求。其核心思想是用户远程访问图形集群，图形集群为用户提供实时高效的运行环境，同时响应用户在本地的交互操作，使用户获得一种接近图形工作站的工作体验，其数据资源和计算程序都部署在远端，既方便管理又确保了数据安全。

发明内容

[0027] 为了解决上述技术问题，本发明提供了一种基于图形集群的远程实时渲染平台构建方法，通过基于Docker架构的虚拟桌面系统部署，在图形集群上部署和运行VDI，为用户开辟独立的虚拟桌面系统，在Docker运行环境下直接调用显示驱动以实现GPU(Graphics Processing Unit,图形处理器)加速渲染，同时采用VNC协议建立远程桌面连接，为用户建立实时的图像传输通道，结合图形集群动态任务调度与管理机制，为多用户提供一种异步分布式的实时渲染服务。

[0028] 本发明的目的通过以下技术方案来具体实现：

[0029] 基于图形集群的远程实时渲染平台构建方法，包括：

[0030] 步骤一、利用Docker架构在图形集群内部实现虚拟桌面系统的部署；

[0031] 步骤二、在所述虚拟桌面系统中嵌入VNC服务端，VNC客户端访问所述VNC服务端后，通过VNC协议建立远程桌面连接；

[0032] 步骤三、图形集群根据远程桌面连接情况进行动态负载均衡，建立图形集群动态任务调度与管理机制；

[0033] 步骤四、通过图形集群动态任务调度与管理机制，在平台客户端与图形集群服务端间建立实时图像传输通道,综合集成基于图形集群的远程实时渲染平台。

[0034] 步骤一，具体包括：

[0035] 在图形集群渲染节点操作系统上创建Docker容器；

[0036] 将封装后的虚拟桌面系统做成Docker镜像存入共享存储系统中；

[0037] Docker容器通过加载Docker镜像，在图形集群内部实现虚拟桌面系统的部署，同时在虚拟桌面系统内实现基于Docker架构的GPU渲染加速。

[0038] 其中，所述在虚拟桌面系统内实现基于Docker架构的GPU渲染加速的步骤，包括：

[0039] 将图形集群渲染节点操作系统的显卡驱程内核文件映射到Docker容器的集成环境中，同时调用OpenGL(Open Graphics Library，开放图形库)的窗口扩展插件，实现在虚拟桌面系统内的GPU(Graphics Processing Unit,图形处理器)实时渲染加速。

[0040] 其中，所述虚拟桌面系统的显示采用虚拟外接输出的方式，该方式包括：

[0041] 为每一个Docker容器分配虚拟的显示输出，当用户访问该Docker容器时，Docker容器中的图形通过虚拟的显示输出，输出至客户端，使得GPU渲染不依赖于实际的图形卡输出接口。

[0042] 步骤二具体包括：

[0043] VNC服务端利用分块匹配的区域变化检测算法对发生变化的图像区域进行筛选，经图像压缩后发送给对应的VNC客户端，通过VNC协议建立基于C/S架构的远程桌面连接；

[0044] 其中，所述VNC服务端利用分块匹配的区域变化检测算法对发生变化的图像区域进行筛选，包括：

[0045] 设定需要变化检测的单位区域；

[0046] 获取截获系统屏幕重绘区域的信息；

[0047] 若截获的系统屏幕重绘区域小于单位区域，发送该区域位置信息；

[0048] 若截获的系统屏幕重绘区域大于单位区域，将截获系统屏幕重绘区域进行拆分，将拆分区域的坐标信息存储至链表中，对链表中每个拆分区域的坐标信息进行遍历检测后得到需要重新发送的变化区域位置信息，将需要重新发送的变化区域的位置信息进行存储并发送。

[0049] 步骤三中，所述图形集群动态任务调度与管理机制包括：

[0050] 在一定的负载均衡策略下，由集群管理节点合理安排渲染节点为用户提供服务资源；

[0051] 所述图形集群动态任务管理与调度涉及到包括但不限于单用户对单节点、多用户对单节点、单用户对多节点和/或多用户对多节点四种情况中的一种或多种情况间动态转换。

[0052] 所述负载均衡策略包括：

[0053] 在单用户对单节点情况下，采用轮询策略分配渲染节点；

[0054] 在多用户对多节点的情况，综合考虑渲染节点的资源利用率、网络带宽以及I/O(Input/Output，输入/输出)速率等指标，利用动态负载均衡模型求解渲染系统负载方差或标准差为极小值的单目标规划问题，得到优化后的图形集群负载均衡策略。

[0055] 其中，所述综合集成的基于图形集群的远程实时渲染平台包括平台客户端、图形集群管理节点、图形集群渲染节点和共享存储系统四个部分；

[0056] 平台客户端部署于用户操作终端，用于向图形集群服务端发起应用请求；

[0057] 图形集群管理节点和图形集群渲染节点部署于图形集群服务端，用于响应平台客户端发起应用请求；

[0058] 共享存储系统，用于存储管理用户配置文件、虚拟桌面系统镜像和/或渲染模型数据信息。

[0059] 步骤四具体包括：

[0060] 将VNC客户端嵌入到平台客户端，Docker容器和VNC服务端嵌入到图形集群渲染节点，Docker镜像存储于共享存储系统中，由图形集群管理节点依据动态任务调度与管理机制进行集群负载均衡；

[0061] 接收到平台客户端发起应用请求时，图形集群管理节点为平台客户端指定渲染节点，渲染节点启动Docker容器并加载Docker镜像，同时利用VNC协议建立远程实时渲染通道，为用户提供远程实时渲染服务。

[0062] 其中，所述远程实时渲染平台的应用模式包括：

[0063] 图形集群服务端在接到平台客户端发起的应用请求后，由图形集群管理节点将渲染任务分配至渲染节点，渲染节点通过创建独立的虚拟桌面系统为用户提供渲染服务。

[0064] 本发明针对大量远程用户基于不同需求的渲染应用问题，依托图形集群硬件环境，利用基于Docker架构的虚拟化手段来为用户提供实时高效的运行环境，同时响应用户在本地的交互操作。该方法不仅适用于不同的硬件环境与操作系统平台，而且能够实现多用户共享GPU渲染资源，使用户获得一种接近图形工作站的工作体验。附图说明

[0065] 图1是基于图形集群的远程实时渲染平台构建方法流程图。

[0066] 图2是虚拟机与Docker的技术机制对比图。

[0067] 图3是基于图形集群的远程实时渲染平台总体框架图。

[0068] 图4是基于图形集群的远程实时渲染平台功能模块设计图。

[0069] 图5是用户使用远程实时渲染平台的应用流程示例图。

[0070] 图6a是主机操作系统渲染效果图；图6b是Docker容器渲染效果图。

[0071] 图7a是单节点支持两用户示意图；图7b是单节点支持四用户示意图。

具体实施方式

[0072] 为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

[0073] 参照图1，图1示出了本发明提供的一种基于图形集群的远程实时渲染平台构建方法的一实施例的流程图，该方法包括：步骤一至步骤四。

[0074] 在步骤一中，利用Docker架构在图形集群内部实现虚拟桌面系统的部署。

[0075] 首先，在图形集群上部署和运行VDI，为用户开辟独立的虚拟桌面系统，可较好的满足不同用户的应用需求。考虑到虚拟机运行模式对GPU渲染能力的制约，系统采用基于Docker(应用容器引擎)的VDI解决方案，在Docker运行环境下直接调用显示驱动，大大提升了GPU渲染效率。

[0076] 一般基于虚拟机的虚拟桌面系统都是通过调用基础操作系统的显示驱动实现显示功能，其本身显示资源有限且处理模式多属于串行工作模式，无法充分发挥图形集群高端显卡的GPU渲染能力。基于Docker的VDI解决方案利用GPU虚拟化技术穿透基础操作系统的显示驱动，在多个独立的虚拟机内部实现基于GPU的图形加速，从而在一定程度上实现多用户对GPU资源的共享。参考图2，图2为虚拟机与Docker的技术机制对比示意图。

[0077] 该步骤具体包括：在图形集群渲染节点操作系统上创建Docker容器；将封装后的虚拟桌面系统做成Docker镜像存入共享存储系统中；Docker容器通过加载Docker镜像，在图形集群内部实现虚拟桌面系统的部署，同时在虚拟桌面系统内实现基于Docker架构的GPU渲染加速。

[0078] 其中，Docker是基于LXC(Linux Container，Linux容器)的高级容器开源引擎，主要包括三种部件，即守护进程(Docker daemon)，镜像(Image)和容器(Container)，其中，守护进程作为服务端接收来自客户的请求并进行处理，镜像是容器运行时的只读模板，容器包含用户应用运行所需要的集成环境。

[0079] 渲染加速的步骤具体包括：将图形集群渲染节点操作系统的显卡驱程内核文件映射到Docker容器的集成环境中，同时调用OpenGL(Open Graphics Library，开放图形库)的窗口扩展插件，实现在虚拟桌面系统内的GPU(Graphics Processing Unit,图形处理器)实时渲染加速。

[0080] 由于Docker容器与主机操作系统共享操作系统内核，用户应用可直接调用主机操作系统中的硬件资源。但在实际应用过程中，用户在容器直接提供的集成环境中运行应用无法实现有效的GPU渲染。经过大量的测试实验，将主机操作系统的显卡驱程内核文件映射到容器的集成环境中，同时调用OpenGL的X窗口扩展插件，能够较好的实现GPU的渲染加速。

[0081] 进一步的，所述虚拟桌面系统的显示采用虚拟外接输出的方式，该方式包括：

[0082] 为每一个Docker容器分配虚拟的显示输出，当用户访问该Docker容器时，Docker容器中的图形通过虚拟的显示输出，输出至客户端，使得GPU渲染不依赖于实际的图形卡输出接口。

[0083] 通常情况下，GPU渲染流水线进行屏幕在线式的渲染，而多用户的异步访问无法实现屏幕共享。针对这一问题，采用虚拟外接输出的方式，为每一个容器分配虚拟的显示输出，当用户访问该容器时图形将显示输出至客户端，使得GPU渲染不依赖于实际的图形卡输出接口，较好的解决了多用户异步应用的问题。

[0084] 在步骤二中，在所述虚拟桌面系统中嵌入VNC(Virtual Network Console，虚拟网络控制台)服务端，VNC客户端访问所述VNC服务端后，通过VNC协议建立远程桌面连接。

[0085] VNC服务端利用分块匹配的区域变化检测算法对发生变化的图像区域进行筛选，经图像压缩后发送给对应的VNC客户端，通过VNC协议建立基于C/S架构的远程桌面连接。

[0086] 其中，所述VNC服务端利用分块匹配的区域变化检测算法对发生变化的图像区域进行筛选，包括：

[0087] 设定需要变化检测的单位区域；

[0088] 获取截获系统屏幕重绘区域的信息；

[0089] 若截获的系统屏幕重绘区域小于单位区域，发送该区域位置信息；

[0090] 若截获的系统屏幕重绘区域大于单位区域，将截获系统屏幕重绘区域进行拆分，将拆分区域的坐标信息存储至链表中，对链表中每个拆分区域的坐标信息进行遍历检测后得到需要重新发送的变化区域位置信息，将需要重新发送的变化区域的位置信息进行存储并发送。

[0091] 其中，该步骤具体为：VNC机制通过采用消息钩子机制截获系统屏幕重绘区域信息。设定需要变化检测的单位区域，如记单位区域rgn大小为32×32，若截获的系统屏幕重绘区域小于单位区域，则直接发送该区域位置信息；若截获系统屏幕重绘区域大于单位区域，则将截系统屏幕重绘获区域进行拆分，得到一个矩形链表(遍历链表)来存储拆分区域坐标信息，记为array_list，定义一个变化区域记为vnc_rgn，专门保存需要重新发送的区域位置信息，对array_list每个成员矩形调用此检测算法进行变化区域检测。

[0092] 一优选实施例：

[0093] (1)假设其中一个成员矩形为arri，如果arri的长宽都小于32×32，则直接作为需重新发送的变化区域，保存到vnc_rgn中，否则对arri进行分析检测。

[0094] (2)首先定义一个新的矩形arrj(arri.left，0，arri.right，0)，在arri中找到发生变化的行，记录该行的y坐标，记arrj.top＝y，同时y+＝16递增找到未发生变化行，暂时记arrj.bottom＝y；然后从arrj底部y-＝1进行比较，寻找内容发生变化的行，找到后将此行的y坐标设置成arrj.bottom＝y。至此确定了变化矩形arrj的最终的top、bottom坐标。同时将arri的值设为arri(arri.left，arrj.bottom，arri.right，arri.bottom)。在对arrj分析完毕后接着对arri遍历分析直至结束。

[0095] (3)确定矩形arrj后，对矩形arrj进行分析。首先定义一个矩形arrn(0，0，0，0)，在arrj中寻找最先发生改变的列，找到后记录发生变化的区域的left、top坐标，arrn.left＝x，arrn.top＝y，分别对x、y轴方向循环遍历进行分析(记为x+＝32，y+＝32)，如果此列屏幕像素数据改变，则x+＝32继续比较；否则将记录arrn.right＝x，对y轴方向进行同样的比较，y+＝32，并记录arrn.bottom＝y，最终得到需要发送的变化区域矩形坐标，并将此矩形保存到最终发送的矩形链表中，同时记录下arrk(arrn.right，arrn.top，arrj.right，arrn.bottom)、arrm(arrn.left，arrn.bottom，arrj.right，arrj.bottom)，分别将arrk、arrm赋值给arrj进行类似分析检测，依次循环遍历整个arrj，直到结束。

[0096] 通过此屏幕变化区域检测算法，对整个array_list链表的成员矩形进行遍历后得到需要重新发送的变化区域坐标信息。

[0097] 另外，对于图像的实时传输控制，系统采用C/S(Client/Server，客户端/服务器)架构在客户端与服务端之间建立图像传输通道，服务端采集、压缩图像后发送给客户端，客户端接收、解压图像后显示给用户。图像实时传输采用VNC协议，服务端利用分块匹配的区域变化检测算法对发生变化的图像区域进行筛选，经图像压缩后发送给客户端，大大减少了网络发送数据量。客户端图像刷新速度由用户自主控制，服务端在接收到客户端的刷新请求后进行图像传输，当客户端较忙或网络延迟较大时，图像刷新速度会相应的降低。

[0098] 增强图像传输实时性的方法主要包括两方面，一是提升区域变化检测算法的效率，二是使用压缩率更高并且编码时间更短的图像压缩算法。对VNC的区域变化检测算法进行了改进，通过隔行扫描对图像变化区域进行细分，进一步消除了冗余的未变化图像数据。系统对该算法进行了测试，以1280×800的24位屏幕图像为例，客户端屏幕刷新间隔为
40ms，在文字处理、网页浏览等应用上数据发送量在200kb/s左右，应用该算法平均可降低约10％的数据量；在高动态图像应用上数据发送量超过4Mb/s，应用该算法对数据量影响很小，而CPU使用率有明显提升，所以方法一对高动态图像传输的实时性影响较弱。综合考虑压缩率和编码所花费的时间，系统常采用效率更高的MJPEG(一种图像压缩算法)算法对图像进行压缩编码，实验结果表明，相同条件下采用MJPEG算法数据发送流量可降至Zlib(一种VNC协议默认的图像压缩算法)算法的50％以下，能够在一定程度上避免由于数据量过大而造成的网络拥塞问题。

[0099] 在步骤三中，图形集群根据远程桌面连接情况进行动态负载均衡，建立图形集群动态任务调度与管理机制。

[0100] 所述图形集群动态任务调度与管理机制包括：

[0101] 在一定的负载均衡策略下，由集群管理节点合理安排渲染节点为用户提供服务资源；所述图形集群动态任务管理与调度涉及到包括但不限于单用户对单节点、多用户对单节点、单用户对多节点和/或多用户对多节点四种情况中的一种或多种情况间动态转换。

[0102] 所述负载均衡策略包括：

[0103] 在单用户对单节点情况下，采用轮询策略分配渲染节点；在多用户对多节点的情况，综合考虑渲染节点的资源利用率、网络带宽以及I/O(Input/Output，输入/输出)速率等指标，利用动态负载均衡模型求解渲染系统负载方差或标准差为极小值的单目标规划问题，得到优化后的图形集群负载均衡策略。

[0104] 远程实时渲染系统的任务调度与管理机制为在一定的负载均衡策略下，由集群管理节点合理安排渲染节点为用户提供服务资源。一般情况下，集群管理涉及到单用户对单节点、多用户对单节点、单用户对多节点和多用户对多节点四种情况，而在系统运行过程中可能还会出现多种情况的动态转换问题。

[0105] 在单用户对单节点情况下，可采用轮询策略分配渲染节点，而在实际应用中更多的是多用户对多节点的情况。在用户数和渲染节点数一定的情况下，综合考虑渲染节点的资源利用率、网络带宽以及I/O速率等指标，负载均衡策略可归纳为在渲染节点的选择中做决策，即求解渲染系统负载方差或标准差为极小值的单目标规划问题；若用户数或渲染节点数发生变化，则在一个时段内求解过程可能演变成为复杂的动态规划问题，但是在当前时刻还是可以作为单目标规划问题来对待。

[0106] 设Ei为第i台渲染节点的负载值，则：

[0107] Ei＝w1Ci+w2Mi+w3Gi+w4Ni+w5IOi (1)

[0108] 式中，Ci、Mi、Gi分别为第i台渲染节点CPU、内存和GPU的占用率，Ni为网络利用率，IOi为I/O速率，wj(j＝1,2,…,5)为对应上述5项指标的权重值，各指标项与负载值Ei均需做归一化处理。

[0109] 渲染系统的总负载均值为：

[0110]

[0111] 将求解渲染系统负载方差简化为求解各渲染节点负载与总负载均值差值的极小值，即：

[0112]

[0113] 经负载均衡后，各渲染节点的负载值总体上会稳定在系统总负载均值上下。为避免由于新增用户过多而影响当前用户的渲染体验，管理节点在监测到渲染节点当前用户的渲染帧频低于设定值(默认为24帧/秒)时，按照规则会优先将用户请求分配至其他渲染节点或拒绝用户的访问请求。

[0114] 在步骤四中、通过图形集群动态任务调度与管理机制，在平台客户端与图形集群服务端间建立实时图像传输通道,综合集成基于图形集群的远程实时渲染平台。

[0115] 如图3所示，该步骤具体包括：

[0116] 接收到平台客户端发起应用请求时，将VNC客户端嵌入到平台客户端(图3中简称客户端n，n≥1)，Docker容器(图3中简称容器n，n≥1)和VNC服务端嵌入到图形集群渲染节点(图3中简称节点)，Docker镜像(图3中简称镜像)存储于共享存储系统中，由图形集群管理节点依据动态任务调度与管理机制进行集群负载均衡；

[0117] 图形集群管理节点为平台客户端指定渲染节点，渲染节点启动Docker容器并加载Docker镜像，同时利用VNC协议建立远程实时渲染通道，综合集成基于图形集群的远程实时渲染平台。

[0118] 所述综合集成的基于图形集群的远程实时渲染平台包括平台客户端、图形集群管理节点、图形集群渲染节点和共享存储系统四个部分；平台客户端部署于用户操作终端，用于向图形集群服务端发起应用请求；图形集群管理节点和图形集群渲染节点部署于图形集群服务端，用于响应平台客户端发起应用请求；共享存储系统，用于存储管理用户配置文件、虚拟桌面系统镜像和/或渲染模型数据信息。

[0119] 所述远程实时渲染平台的应用模式包括：图形集群服务端在接到平台客户端发起的应用请求后，由图形集群管理节点将渲染任务分配至渲染节点，渲染节点通过创建独立的虚拟桌面系统为用户提供渲染服务。

[0120] 一实施例，远程实时渲染系统利用Docker架构实现虚拟桌面系统部署，使用VNC建立远程桌面连接。远程用户向集群服务端发出Docker容器管理请求，利用VNC客户端与VNC服务端建立远程桌面连接。在图形集群服务端，集群管理节点通过Docker守护进程对容器进行管理调度，Docker注册表用于保存用户自定义的镜像文件。当服务端收到客户端发出的容器管理请求后，由Docker守护进程搜索注册表中的镜像并创建用户容器，同时在容器中启动VNC服务端。

[0121] 图形集群在接到用户终端发起的应用请求后，由管理节点将渲染任务分配至渲染节点，渲染节点通过创建独立的虚拟桌面系统为用户提供渲染服务。基于图形集群的远程实时渲染平台主要包括平台客户端、图形集群管理节点、图形集群渲染节点和共享存储系统四部分，其中平台客户端部署于用户操作终端，图形集群管理节点和渲染节点部署于图形集群服务端，共享存储系统主要为用户配置文件、虚拟桌面系统镜像以及渲染模型数据等提供方便可靠的存储管理。平台功能模块如图4所示。

[0122] 平台客户端通过用户注册/登录模式向图形集群管理节点发送虚拟桌面请求，待管理节点指定渲染节点后负责与提供渲染服务的渲染节点建立远程桌面连接。平台客户端可直接访问共享存储系统，在用户权限范围内上传、下载或修改特定的配置文件。

[0123] 图形集群管理节点主要包括初始化、任务管理和节点管理3个模块。系统启动后首先完成集群内部连接与配置文件加载等初始化功能；任务管理模块主要完成任务的存储、调度与查询等功能，在接到平台客户端的虚拟桌面请求后，对集群中各渲染节点的负载情况进行查询，同时利用动态负载均衡算法为平台客户端指定渲染节点，若为新用户注册模式则渲染节点新开辟虚拟桌面系统，若为用户登录模式则渲染节点从共享存储系统中加载虚拟桌面系统文件；节点管理主要完成对渲染节点的增删、配置和状态查询等功能。

[0124] 图形集群渲染节点在启动虚拟桌面系统后，通过远程桌面管理与平台客户端建立独立的数据连接通道，为用户提供远程渲染服务。渲染节点主要包括虚拟桌面系统管理与远程桌面系统管理两部分，前者负责创建与管理虚拟桌面系统，为用户提供实时渲染服务，后者主要用于远程显示与交互控制。

[0125] 虚拟桌面系统管理模块主要是在Linux操作系统上创建Docker容器，将封装后的虚拟桌面系统做成Docker镜像存入共享存储系统中，在需要创建虚拟桌面系统时通过加载Docker镜像来实现VDI部署，同时利用基于Docker的GPU渲染技术解决在虚拟桌面系统内的实时渲染问题。

[0126] 远程桌面管理模块主要采用VNC解决方案，由于VNC是采用消息钩子机制截获系统屏幕重绘区域信息，所以远程桌面管理模块需要为每一个用户的虚拟桌面系统创建显示输出接口映射，即创建虚拟“屏幕”。在虚拟桌面系统中安装VNC服务端，平台客户端通过调用VNC客户端与虚拟桌面系统建立远程桌面连接，采用基于VNC的图像实时传输控制方法对传输实时性进行了优化处理。用户使用远程实时渲染平台的应用流程示例如图5所示，包括：

[0127] 平台客户端发起连接请求，图形集群管理节点接收连接请求，图形集群管理节点为用户选择渲染节点，判断是否为新用户连接，是，则启动应用容器引擎，创建虚拟桌面系统；否，则启动应用容器引擎，加载虚拟桌面系统镜像；图形集群渲染节点响应用户连接请求，图形集群渲染节点创建VNC实时渲染通道，平台客户端完成远程桌面连接，用户启动系统应用。

[0128] 为测试系统应用效果，选择两台图形工作站组成图形集群，两台均为渲染节点，其中一台作为管理节点，平台客户端安装在普通PC上，网络环境为千兆局域网。其中图形集群节点硬件配置为英特尔至强四核处理器，16G内存，Nvidia Q7000专业图形卡(显存6G)，操作系统为64位Ubuntu Kylin 16.04(乌班图麒麟操作系统)。平台客户端登录后与图形集群渲染节点建立远程桌面连接，在1280×800分辨率上分别进行GPU渲染效率和多用户异步应用实验。

[0129] GPU渲染效率实验：在主机操作系统和Docker容器环境中分别运行相同的图样测试样例，由于受屏幕刷新频率的限制，运行效果如图6a所示主机操作系统上运行帧频不超过60帧/秒，Docker容器环境下的运行帧频可达85帧/秒，运行效果如图6b所示。测试结果显示，基于Docker的GPU渲染效率已基本接近主机操作系统上的使用效率。

[0130] 多用户异步应用实验：多平台客户端同时启动后，在系统稳定运行情况下渲染帧频随平台客户端数量的增加而逐步下降，各平台客户端间的渲染帧频差异不大，平台客户端显示无明显卡顿现象。当单渲染节点支持1个用户时平均帧频可达140帧/秒，支持2个用户时约为120帧/秒，平台客户端显示效果如图7a所示，支持4个用户时则将至75帧/秒左右，平台客户端显示效果如图7b所示。

[0131] 综上，本发明实施例针对大量远程用户基于不同需求的渲染应用问题，根据面向多用户的异步分布式工作模式，依托图形集群硬件环境，利用虚拟化手段来满足不同用户按需使用的需求。其核心思想是用户远程访问图形集群，图形集群为用户提供实时高效的运行环境，同时响应用户在本地的交互操作，使用户获得一种接近图形工作站的工作体验，其数据资源和计算程序都部署在远端，既方便管理又确保了数据安全。

标题	发布/更新时间	阅读量
一种充电桩手机端操作系统及其工作方法	2020-05-08	712
加密方法、解密方法及装置	2020-05-08	635
一种手势操作的识别方法	2020-05-08	33
水下操作系统	2020-05-08	705
一种新旧代码共同运行的kbroker分布式操作系统	2020-05-08	463
内存操作系统制作方法、装置、电子设备和存储介质	2020-05-08	580
用于切换模式电力转换器的控制器、切换方法和操作系统	2020-05-08	711
一种新型车载信息娱乐系统	2020-05-08	537
步兵战车驾驶训练模拟系统	2020-05-08	441
一种堆高车	2020-05-11	54

基于图形集群的远程实时渲染平台构建方法

基于图形集群的远程实时渲染平台构建方法

技术领域

背景技术

发明内容

具体实施方式

该功能需要专业版企业版VIP权限，您可以：