一种实现用户隔离的方法及系统与流程

本发明涉及计算机领域，特别涉及一种实现用户隔离的方法及系统。

背景技术：

目前，在使用GPU(Graphics Processing Unit，图形处理器)编程环境中，GPU服务器通常是以普通服务器的形式被使用，如图1所示，多个用户使用同一个GPU服务器，该多个用户分别将自己的代码上传到该同一个GPU服务器上进行处理。

该种使用方式，使得多个用户共用使用同一个运行环境且多个用户之间没有相互隔离。然而，在实际应用中，不同的用户对运行环境的需求不一样，例如用户A需要使用软件1，而用户B需要使用软件2，又或者多个用户即使需要的软件一样但是需要该软件的版本不一致，从而将可能导致多个用户的代码的运行环境产生冲突，难以找到一个满足所有用户需求的基础环境，基础环境难以维护。

另外，多个用户共同使用同一个GPU服务器处理代码，将可能会存在互相抢占GPU服务器使用权，导致代码运算速度缓慢的问题。

技术实现要素：

鉴于上述问题，本发明提供一种实现用户隔离的方法及系统，以解决现有技术中使用GPU编程环境导致运行环境冲突以及代码运算速度缓慢的技术问题。

本发明实施例，第一方面，提供一种实现用户隔离的方法，方法包括：

控制服务器接收携带有目标docker镜像的软件资源信息和硬件资源信息的用户请求；

控制服务器根据所述用户请求中的软件资源信息指示选取的构建服务器生成目标docker镜像；

控制服务器根据所述用户请求中的硬件资源信息从图形处理器GPU服务器集群中选取满足所述硬件资源的GPU服务器，并指示所述GPU服务器启动所述目标docker镜像。

本发明实施例，第二方面，提供一种实现用户隔离的系统，该系统包括：

控制服务器，用于在接收携带有目标docker镜像的软件资源信息和硬件资源信息的用户请求时，根据所述用户请求中的软件资源信息向选取的构建服务器发送目标docker镜像生成请求；以及，从所述GPU服务器集群中选取满足所述用户请求中的硬件资源的GPU服务器，并向选取的GPU服务器发送目标docker镜像启动请求；

构建服务器，用于根据接收到的目标docker镜像生成请求生成所述目标docker镜像；

GPU服务器，用于根据接收到的目标docker镜像启动请求启动所述目标docker镜像。

本发明技术方案，一方面，搭建GPU服务器集群，使用docker容器为不同的用户提供独立的运行环境，不同的用户可以根据自身的需求设置相应的运行环境，能够满足各个用户对运行环境的需求，克服现有技术中多个用户的运行环境发生冲突的问题；另一方面，针对不同的docker容器从GPU服务器集群中分配相应的宿主机，避免不同用户相互争夺GPU服务器使用权而导致代码运行速度缓慢的技术问题。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。

图1为现有技术中多个用户使用同一GPU服务器的示意图；

图2为本发明实施例中实现用户隔离的方法的流程图之一；

图3为本发明实施例中实现用户隔离的方法的流程图之二；

图4为本发明实施例中实现用户隔离的方法的流程图之三；

图5为本发明实施例中实现用户隔离的方法的流程图之四；

图6为本发明实施例中实现用户隔离的方法的流程图之五；

图7为本发明实施例中实现用户隔离的系统的结构示意图之一；

图8为本发明实施例中实现用户隔离的系统的结构示意图之二；

图9为本发明实施例中实现用户隔离的系统的结构示意图之三；

图10为本发明实施例中实现用户隔离的系统的结构示意图之四。

具体实施方式

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

实施例一

参见图2，为本发明实施例中实现用户隔离的方法流程图，该方法包括：

步骤S100、控制服务器接收携带有目标docker镜像的软件资源信息和硬件资源信息的用户请求；

步骤S200、控制服务器根据所述用户请求中的软件资源信息指示选取的构建服务器生成目标docker镜像；

步骤S300、控制服务器根据所述用户请求中的硬件资源信息从图形处理器GPU服务器集群中选取满足所述硬件资源的GPU服务器，并指示所述GPU服务器启动所述目标docker镜像。

优选地，本发明实施例中，前述步骤S200中控制服务器根据所述用户请求中的软件资源信息指示选取的构建服务器生成目标docker镜像，可通过但不限于以下方式实现：

步骤A1、控制服务器从预置的软件资源信息与软件工具信息的对应关系中，确定所述目标docker镜像的软件资源信息对应的软件工具信息，并生成携带有该软件工具信息的目标docker镜像生成请求；

其中，软件资源信息与软件工具信息的对应关系可以通过列表、索引存储结构等方式存储，本申请对于该对应关系的存储方式不做严格限定。

步骤A2、控制服务器将所述目标docker镜像生成请求发送给选取的构建服务器，以指示所述构建服务器生成目标docker镜像。

本发明实施例中，控制服务器可以通过有线或无线的方式向选取的构建服务器发送目标docker镜像生成请求。本发明不做严格限定。

优选地，本发明实施例中，构建服务器生成目标docker镜像可通过但不仅限于以下方式实现：

步骤B1、根据所述目标docker镜像生成请求中的软件工具信息生成docker文件；

步骤B2、根据所述docker文件生成用户个性化docker镜像；

步骤B3、根据预置的基础镜像和所述用户个性化docker镜像，生成所述目标docker镜像。

优选地，本发明实施例中，预先针对一些数据量大的常见软件工具包生成相应的基础镜像，后续在接收到软件工具信息时，对于该软件工具信息中包含的常见软件工具包无需再生成docker镜像，仅针对软件工具信息中的用户个性化的软件工具包生成Dockerfile文件，再根据Dockerfile文件生成用户个性化docker镜像，再将软件工具信息中的常见软件工具包对应的基础镜像和该用户个性化docker镜像合并生成目标docker镜像，从而提高了生成目标docker镜像的速度和效率。例如：将SSH、VNC认为是常见的软件工具包，可预先生成一个基于Ubuntu16.04并包含SSH(Secure Shell，安全壳)服务、VNC(Virtual Network Console，虚拟网络控制台)服务的基础镜像，用户个性化需求NumPy、OpenCV，则在其Dockerfile中增加安装NumPy、OpenCV的命令，从而生成一个用户的个性化目标docker镜像，此目标docker镜像基于Ubuntu16.04，并包含SSH、VNC、NumPy、OpenCV。

优选地，本发明实施例，为更进一步提高docker镜像被启动的速度以及便于对docker镜像的管理，本发明实施例中，针对不同用户对应的docker镜像进行集中存储，以便GPU服务器从该集中存储的docker镜像中获取指定的docker镜像。因此，在前述图2所示的流程的步骤S200与步骤S300之间还包含以下步骤，如图3所示：

步骤S200A、所述构建服务器将生成的目标docker镜像及该目标docker镜像对应的标识关联存储至预置的docker镜像仓库中。

此时，前述步骤S300中，控制服务器指示所述GPU服务器启动所述目标docker镜像，具体实现如下：生成携带有所述目标docker镜像的标识的docker镜像启动请求，以指示所述GPU服务器启动所述目标docker镜像。

GPU服务器启动所述目标docker镜像，具体包括：GPU服务器根据docker镜像启动请求中携带的标识，从所述docker镜像仓库中获取与该标识对应的目标docker镜像，并采用docker程序启动该目标docker镜像。

优选地，为便于发起用户请求的用户能够及时了解目标docker镜像的生成和启动的情况，本发明实施例，在前述图2或图3所示的方法流程中的步骤S300之后还可以包括以下步骤S400～步骤S500，例如在图3所示的方法流程中还包含以下步骤S400～步骤S500，如图4所示：

步骤S400、所述GPU服务器成功启动所述目标docker镜像之后，向所述控制服务器发送携带有端口信息的成功启动消息；

步骤S500、所述控制服务器向发起用户请求的用户反馈包含所述端口信息的响应信息。

其中，端口信息例如可以包含启动docker的SSH端口号或VNC端口号。

优选地，为便于本领域技术人员进行分析和统计等工作，本发明实施例，还可以在前述构建服务器根据docker文件不能生成目标docker镜像时，记录失败日志；还可以在构建服务器将生成的目标docker镜像存储至docker镜像仓库中失败时，记录失败日志；还可以在GPU服务器启动目标docker镜像失败时，记录失败日志。本申请不做严格限定，本领域技术人员可以根据实际需求灵活设置。

优选地，为进一步提高处理速度和效率，各服务器包含多台形成分布式处理。因此，本发明技术方案中预先设置有控制服务器集群，该控制服务器集群包含至少一台控制服务器；以及，预先设置有构建服务器集群，该构建服务器集群中包含至少一台构建服务器。

一种实现方案是，预先设置有负载均衡器，通过该负载均衡器统一接收携带有目标docker镜像的软件资源信息和硬件资源信息的用户请求，由该负载均衡器采用负载均衡原则从控制服务器集群中选取其中一台控制服务器以及从构建服务器集群中选取一台构建服务器对该用户请求相关的事项进行处理。另一种实现方案是，预先设置有负载均衡器，通过该负载均衡器统一接收携带有目标docker镜像的软件资源信息和硬件资源信息的用户请求，由该负载均衡器采用负载均衡原则从控制服务器集群中选取其中一台控制服务器处理该用户请求，以及控制服务器再从构建服务器集群中选取一台构建服务器进行目标docker镜像的生成。

针对以上两种实现方案，进行以下描述。

优选地，本发明实施例，在前述图2～图4所示的方法流程中，还可以包括以下步骤S100A，如图5所示，在图4所示的方法流程中包含以下步骤S100A：

步骤S100A、负载均衡控制器在接收到所述用户请求时，从预设的控制服务器集群中选取一个控制服务器以及从预置的构建服务器集群中选取一个构建服务器，并将所述用户请求以及选取的构建服务器的标识发送给所述控制服务器。

优选地，本发明实施例，还可以在前述图2～图4所示的方法流程中，还可以包括以下步骤S100B和步骤S100C，如图6所示，在图4所示的方法流程中包含以下步骤S100B和步骤S100C：

S100B、负载均衡控制器在接收到所述用户请求时，从预设的控制服务器集群中选取一个控制服务器，并将该用户请求发送给所述控制服务器；

S100C、控制服务器器从预置的构建服务器集群中选取一个构建服务器。

本发明实施例中，除了通过负载均衡器通过负载均衡原则选取控制服务器和构建服务器之外，本领域技术人员还可以采用其他方式实现，例如：通过性能优先的选择方式选取性能较好的控制服务器。本发明对于控制服务器的选取不做严格的限定。

本发明实施例中，为了便于用户对其运行环境的个性化设定，为用户提供用于设置docker镜像的用户界面；用户登录该用户界面之后，在相应的窗口填写或者从预置的菜单中选择用户需要的docker镜像(后续称为目标docker镜像)所需的软件资源信息和硬件资源信息；在用户提交之后，生成携带有目标docker镜像的软件资源信息和硬件资源信息的用户请求。当然，该用户请求中还可以携带有用户的用户标识以及为该目标docker镜像分配的标识。

优选地，由于用户对应的目标docker镜像可能会有多个，用户可能在某一时间段需要频繁的切换多个目标docker镜像，因此需要在多个不同的GPU服务器之间频繁切换，而不同的GPU服务器在启动相同用户的相应目标docker镜像均需要加载该用户的个人文件，因此，为避免用户在不同的GPU服务器中频繁切换需要来回拷贝用户个人文件的问题，本发明实施例，对于用户的个人文件进行集中存储，集中存储在NAS(Network Attached Storage，网络附属存储)服务器中，以便各GPU服务器在启动相应的目标docker镜像过程中使得个人文件能够通过ISCIS(Internet Small Computer System Interface，小型计算机系统接口)协议从NAS服务器挂载到GPU服务器中。

实施例二

参见图7，为本发明实施例二提供的一种实现用户隔离的系统的结构示意图，该系统包括控制服务器71、构建服务器72和GPU服务器73，其中：

控制服务器71，用于在接收携带有目标docker镜像的软件资源信息和硬件资源信息的用户请求时，根据所述用户请求中的软件资源信息向选取的构建服务器72发送目标docker镜像生成请求；以及，从所述GPU服务器集群中选取满足所述用户请求中的硬件资源的GPU服务器73，并向选取的GPU服务器73发送目标docker镜像启动请求；

构建服务器72，用于根据接收到的目标docker镜像生成请求生成所述目标docker镜像；

GPU服务器73，用于根据接收到的目标docker镜像启动请求启动所述目标docker镜像。

优选地，本发明实施例中，控制服务器71根据所述用户请求中的软件资源信息向选取的构建服务器72发送目标docker镜像生成请求，具体用于：

控制服务器71从预置的软件资源信息与软件工具信息的对应关系中，确定所述目标docker镜像的软件资源信息对应的软件工具信息，生成并向所述构建服务器72发送携带有该软件工具信息的目标docker镜像生成请求。

其中，软件资源信息与软件工具信息的对应关系可以通过列表、索引存储结构等方式存储，本申请对于该对应关系的存储方式不做严格限定。控制服务器71可以通过有线或无线的方式向选取的构建服务器72发送目标docker镜像生成请求。本发明不做严格限定。

优选地，所述构建服务器72，具体用于：根据接收到的目标docker镜像生成请求中的软件工具信息生成docker文件；根据所述docker文件生成用户个性化docker镜像；根据预置的基础镜像和所述用户个性化docker镜像，生成所述目标docker镜像。

优选地，本发明实施例中，预先针对一些数据量大的常见软件工具包生成相应的基础镜像，后续在接收到软件工具信息时，对于该软件工具信息中包含的常见软件工具包无需再生成docker镜像，仅针对软件工具信息中的用户个性化的软件工具包生成Dockerfile文件，再根据Dockerfile文件生成用户个性化docker镜像，再将软件工具信息中的常见软件工具包对应的基础镜像和该用户个性化docker镜像合并生成目标docker镜像，从而提高了生成目标docker镜像的速度和效率。例如：将SSH、VNC认为是常见的软件工具包，可预先生成一个基于Ubuntu16.04并包含SSH服务、VNC服务的基础镜像，用户个性化需求NumPy、OpenCV，则在其Dockerfile中增加安装NumPy、OpenCV的命令，从而生成一个用户的个性化目标docker镜像，此目标docker镜像基于Ubuntu16.04，并包含SSH、VNC、NumPy、OpenCV。

优选地，所述构建服务器72进一步用于，将生成的目标docker镜像及该目标docker镜像对应的标识关联存储至预置的docker镜像仓库中；

GPU服务器73，具体用于，根据所述目标docker镜像启动请求中携带的标识，从所述docker镜像仓库中获取与该标识对应的目标docker镜像，并采用docker程序启动该目标docker镜像。

优选地，所述GPU服务器73进一步用于，在启动所述目标docker镜像之后，向所述控制服务器71发送携带有端口信息的成功启动消息；

所述控制服务器71进一步用于，向发起用户请求的用户反馈包含所述端口信息的响应信息。

其中，端口信息例如可以包含启动docker的SSH(Secure Shell，安全壳)端口号或VNC端口号。

优选地，为便于本领域技术人员进行分析和统计等工作，本发明实施例，前述构建服务器72根据docker文件不能生成目标docker镜像时，还可以记录失败日志；构建服务器72将生成的目标docker镜像存储至docker镜像仓库中失败时，还可以记录失败日志；GPU服务器73启动目标docker镜像失败时，还可以记录失败日志。本申请不做严格限定，本领域技术人员可以根据实际需求灵活设置。

优选地，为进一步提高处理速度和效率，各服务器包含多台形成分布式处理。因此，本发明技术方案中预先设置有控制服务器集群，该控制服务器集群包含至少一台控制服务器；以及，预先设置有构建服务器集群，该构建服务器集群中包含至少一台构建服务器。在本发明实施例图7所示的系统还可以包括负载均衡控制器70。

在一种实现方式中，如图8所示，负载均衡控制器70，用于在接收到所述用户请求时，从预设的控制服务器集群中选取一个控制服务器71，以及从预置的构建服务器集群中选取一个构建服务器72，将所述用户请求以及选取的构建服务器72的标识发送给所述控制服务器71。

在另一种实现方式中，如图9所示，负载均衡控制器70，用于在接收到所述用户请求时，从预设的控制服务器集群中选取一个控制服务器71，并将该用户请求发送给所述控制服务器71；控制服务器72进一步用于，在接收所述用户请求之后，从预置的构建服务器集群中选取一个构建服务器72。

本发明实施例中，除了通过负载均衡器通过负载均衡原则选取控制服务器和构建服务器之外，本领域技术人员还可以采用其他方式实现，例如：通过性能优先的选择方式选取性能较好的控制服务器。本发明对于控制服务器的选取不做严格的限定。

本发明实施例中，为了便于用户对其运行环境的个性化设定，为用户提供用于设置docker镜像的用户界面；用户登录该用户界面之后，在相应的窗口填写或者从预置的菜单中选择用户需要的docker镜像(后续称为目标docker镜像)所需的软件资源信息和硬件资源信息；在用户提交之后，生成携带有目标docker镜像的软件资源信息和硬件资源信息的用户请求。当然，该用户请求中还可以携带有用户的用户标识以及为该目标docker镜像分配的标识。

优选地，由于用户对应的目标docker镜像可能会有多个，用户可能在某一时间段需要频繁的切换多个目标docker镜像，因此需要在多个不同的GPU服务器之间频繁切换，而不同的GPU服务器在启动相同用户的相应目标docker镜像均需要加载该用户的个人文件，因此，为避免用户在不同的GPU服务器中频繁切换需要来回拷贝用户个人文件的问题，本发明实施例，对于用户的个人文件进行集中存储，集中存储在NAS服务器中，以便各GPU服务器在启动相应的目标docker镜像过程中使得个人文件能够通过ISCIS(Internet Small Computer System Interface，小型计算机系统接口)协议从NAS服务器挂载到GPU服务器中。因此，优选地，本发明实施例中，在前述图7～图9所示的系统中还可以包含NAS服务器74，如图10所示，为在图8所示的系统中包含NAS服务器74，其中：

NAS服务器74，用于存储GPU服务器集群的相关文件以及用户个人文件。

本发明技术方案中，一方面，搭建GPU服务器集群，使用docker容器为不同的用户提供独立的运行环境，不同的用户可以根据自身的需求设置相应的运行环境，能够满足各个用户对运行环境的需求，克服现有技术中多个用户的运行环境发生冲突的问题；另一方面，针对不同的docker容器从GPU服务器集群中分配相应的宿主机，避免不同用户相互争夺GPU服务器使用权而导致代码运行速度缓慢的技术问题；再一方面，通过NAS服务器集中存储用户个人文件，使得用户在多个GPU服务器中频繁切换执行不同的目标docker镜像时，统一从NAS服务器中读取个人文件即可，无需频繁拷贝用户的个人文件。

以上是本发明的核心思想，为了使本技术领域的人员更好地理解本发明实施例中的技术方案，并使本发明实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对本发明实施例中技术方案作进一步详细的说明。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。