KR20140018076A - Virtual desktop service system for client that has multiple user accounts - Google Patents

Abstract

The present invention relates to a virtual desktop service system for a client having multiple user accounts and may provides a separated virtual desktop service from one data center to a plurality of companies or group clients by providing a virtual desktop system including a plurality of user virtual machines; a router virtual machine for supporting a virtual desktop service to the user virtual machines; and a desktop delivery control virtual machine to the respective clients. [Reference numerals] (AA) Internet

Description

Virtual desktop service system for client that has multiple user accounts}

The present invention relates to a system for providing a virtual desktop service to a client having a plurality of user accounts, wherein the virtual desktop can provide a virtual desktop service separated from each other to a plurality of enterprise or organization clients in one data center. It relates to a service system.

Desktop virtualization can be divided into Server-Based Computing (SBC) and Virtual Desktop Infrastructure (VDI). While SBC provides users with a virtual desktop environment through terminal services provided by the server operating system, VDI creates a virtual machine for the desktop environment on the server and installs the operating system and applications on the created virtual machine to the user There is a difference in that it implements a virtual desktop environment. Among them, VDI services are in the spotlight in that they can have a desktop environment more similar to a user's local desktop environment.

In the case of providing a VDI service to a client having a plurality of user accounts, that is, an enterprise or an organizational unit, one physical hardware and virtualization software has been provided for each client.

However, as the number of clients in an enterprise or an organization wanting VDI services increases, there is a need for a system capable of providing VDI services to a plurality of companies or organizations in a single data center.

An object of the present invention is to provide a virtual desktop service system capable of providing virtual desktop services separated from each other to a plurality of enterprise or organization clients in a single data center.

Technical problems to be achieved by the present invention are not limited to the above-mentioned technical problems, and other technical problems not mentioned above may be clearly understood by those skilled in the art from the following description. There will be.

In order to achieve the above technical problem, a virtual desktop service system includes a plurality of user virtual machines for providing a virtual desktop environment using a virtual computing resource virtualized a physical computing resource of a data center; At least one router virtual machine for allocating IP to the user virtual machine to mediate communication between the user virtual machine and an external network and to route communication within the private network of the user virtual machine; A desktop delivery control virtual machine connecting a session between the user virtual machine and a user account accessing the user virtual machine and managing a virtual desktop service provided by the user virtual machine; And an Active Directory virtual machine that authenticates a user account accessing at least one of the user virtual machine and the desktop delivery control virtual machine.

More preferably, each client may have a set of independent system virtual machines including a router virtual machine, a desktop delivery control virtual machine, and an active directory virtual machine.

More preferably, the router virtual machine may include a DHCP server for assigning a floating IP to the user virtual machines.

More preferably, the router virtual machine can be dynamically expanded or reduced depending on the number of the user virtual machines.

More preferably, a first subnetwork between the router virtual machine and an external public network, a second subnetwork for controlling the router virtual machine, the active directory virtual machine, and the desktop delivery control virtual machine in a management system of a service provider. The third subnet for communicating with the router virtual machine, the active directory virtual machine, and the desktop delivery control virtual machine in the user virtual machine may be logically separated from each other.

More preferably, when there are a plurality of router virtual machines, the third subnetwork may include a plurality of subnetworks allocated to each of the plurality of router virtual machines and logically separated from each other.

More preferably, when there are a plurality of router virtual machines, the sub-network may further include a sub-network for sharing routing information between the plurality of router virtual machines.

In order to achieve the above technical problem, a method for preparing a virtual desktop service mediates communication with an external network of a user virtual machine providing a virtual desktop environment using a virtual computing resource virtualized from a physical computing resource of a data center, and a user virtual machine. A router virtual machine generation step of creating a router virtual machine for routing the communication in the sub-network of the network; An active directory generation step of generating an Active Directory virtual machine that receives an IP of a sub-network from a router virtual machine and authenticates a user account accessing the user virtual machine based on the assigned IP; And desktop delivery that creates a desktop delivery virtual machine that connects the session between the user virtual machine and the user account based on the assigned IP from the router virtual machine and manages the virtual desktop service provided by the user virtual machine. Generating step; And updating the port forwarding rule of the router virtual machine based on the predefined port of the IP of the desktop delivery virtual machine.

More preferably, the router virtual machine generation step may include: assigning a management IP through a management network logically separated from the service network; Creating a router virtual machine based on the assigned management IP; Requesting allocation of public IP and service IP for the generated router virtual machine; And updating the initial configuration of the router virtual machine based on the public IP and the service IP assigned in response to the request.

More preferably, the generating an active directory may include: assigning a management IP through a management network logically separated from a service network; Creating an Active Directory virtual machine based on the assigned management IP; Requesting the router virtual machine for service IP allocation for the created Active Directory virtual machine; And updating the initial setting of the Active Directory based on the service IP assigned in response to the request.

More preferably, the desktop delivery generation step is a step of receiving a management IP through a management network logically separated from the service network; Creating a desktop delivery virtual machine based on the assigned management IP; Requesting the router virtual machine for service IP allocation for the created desktop delivery virtual machine; And updating the initial setting of the desktop delivery virtual machine based on the service IP assigned in response to the request.

According to the present invention, it is possible to provide virtual desktop services separated from each other to a plurality of enterprise or organization clients in one data center.

In particular, it is possible to provide a virtual desktop service that meets the client's IT environment by more faithfully reflecting the needs for different hardware and software for each client.

1 is a view showing the overall configuration of a virtual desktop service system according to an embodiment of the present invention.
2 is a diagram illustrating a conceptual configuration of a VMS that is one component of a virtual desktop service system according to an exemplary embodiment of the present invention.
3A and 3B are diagrams illustrating a control authority of a service API used in a VMS of a virtual desktop service system according to an exemplary embodiment of the present invention, and a service API that can be executed according to the authority.
4A to 4B illustrate a request and response format of a service API used in a VMS of a virtual desktop service system according to an exemplary embodiment of the present invention.
5 is a diagram illustrating a process of creating a system VM allocated to each client in a service process of a VMS according to an exemplary embodiment of the present invention.
FIG. 6 is a diagram illustrating a process of setting a basic environment for performing a VDI service in a user VM of each client in a service process of a VMS according to an exemplary embodiment of the present invention.
7 is a diagram illustrating a multi-tenancy virtual desktop service provided by a data center according to an exemplary embodiment of the present invention.
8 is a diagram illustrating a network environment that is independently configured for each client according to an embodiment of the present invention.
FIG. 9 illustrates a process of deployVDI API for creating a virtual desktop environment for a user belonging to a specific client of a multi-tenancy virtual desktop service according to an exemplary embodiment of the present invention.

The following merely illustrates the principles of the invention. Thus, those skilled in the art will be able to devise various apparatuses which, although not explicitly described or shown herein, embody the principles of the invention and are included in the concept and scope of the invention. Furthermore, all of the conditional terms and embodiments listed herein are, in principle, intended only for the purpose of enabling understanding of the concepts of the present invention, and are not intended to be limiting in any way to the specifically listed embodiments and conditions . It is also to be understood that the detailed description, as well as the principles, aspects and embodiments of the invention, as well as specific embodiments thereof, are intended to cover structural and functional equivalents thereof. In addition, these equivalents should be understood to include not only equivalents now known, but also equivalents to be developed in the future, that is, all devices invented to perform the same function regardless of structure.

Thus, the functions of the various elements shown in the drawings, including the functional blocks shown in the figures or similar concepts, may be provided by use of dedicated hardware as well as hardware capable of executing software in connection with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which may be shared. Also, the use of terms such as processor, control, or similar concepts should not be construed as exclusive reference to hardware capable of executing software, but may include, without limitation, digital signal processor (DSP) hardware, (ROM), random access memory (RAM), and non-volatile memory. Other hardware may also be included.

The above objects, features and advantages will become more apparent from the following detailed description in conjunction with the accompanying drawings. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

On the other hand, when an element is referred to as " including " an element, it does not exclude other elements unless specifically stated to the contrary.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a view showing the overall configuration of a virtual desktop service system 100 for one client according to an embodiment of the present invention.

Referring to FIG. 1, the virtual desktop service system 100 according to the present embodiment manages a client-specific virtual desktop system 110, which is a set of virtual machines allocated to each client, and the virtual desktop systems 110, And a centralized management system 120 of the service provider that controls. It is apparent that other components in addition to the above components may be included in the virtual desktop service system 100 according to the present embodiment.

The virtual desktop system 110 and the central management system 120, which are components of the virtual desktop service system 100 according to the present embodiment, include at least a program module for communicating with an external terminal device or an external server, These program modules may be included in the virtual desktop service system 100 as an operating system, an application program module, and other program modules, and may be physically stored in various kinds of known storage devices. In addition, these program modules may be stored in a remote storage device capable of communicating with the virtual desktop service system 100. These program modules, on the other hand, encompass routines, subroutines, programs, objects, components, data structures, etc., that perform particular tasks or perform particular abstract data types as described below in accordance with the present invention, Do not.

The client-specific virtual desktop system 110 according to the present embodiment is a user virtual machine 115 each assigned to a plurality of user accounts, and a system virtual machine assigned to each client to support virtual desktop services of individual user virtual machines. One of them (111 to 114).

The user virtual machines 115 provide a virtual desktop environment for each user account by using virtual computing resources that virtualize the physical computing resources of the data center, and are similar to using local physical computing resources in the local desktop environment. In order to provide a virtual desktop environment, the same operating system and applications as the local desktop environment may be installed and run.

The system virtual machines may include router virtual machines (RVMs) 111 to 112, active directory virtual machines (ADs 113), and desktop delivery control virtual machines (DDCs) 114.

That is, according to the present embodiment, each client has a set of independent system virtual machines including a router virtual machine (RVM), an active directory virtual machine (AD), and a desktop delivery control virtual machine (DDC). When a virtual desktop service request is received from a user, the system virtual machines are separately created and assigned to the corresponding client before the user virtual machines are directly provided to provide the virtual desktop service, and the functions of each of the system virtual machines are provided. The first step is to install the software package.

The router virtual machines (RVMs) 111 to 112 allocate service IPs to the user virtual machines 115 to mediate communication between the user virtual machines 115 and the external network, and between the user virtual machines 115. Performs a router function of a virtual sub-network for each client that routes communication in the sub-network. For example, in order to access the Internet in a virtual desktop environment provided through the user virtual machines 115, the user accesses the Internet through a router virtual machine. At this time, the router virtual machine (RVM, 111 to 112) can perform a function as a client external Internet aggregation switch.

 In addition, the router virtual machines (RVM) 111 to 112 may include a DHCP server for allocating a dynamic IP to the user virtual machines (115).

Router virtual machines (RVMs) 111 to 112 may be scaled up or reduced dynamically according to the number of user virtual machines.

A desktop delivery control virtual machine (DDC) 114 connects a session between a user virtual machine and a user account accessing the user virtual machine, and manages the virtual desktop service provided by the user virtual machine.

The Active Directory Virtual Machine (AD) 113 manages the information of the user accounts of the user virtual machines and the desktop delivery control virtual machine, and authenticates the user account that accesses them. In other words, the Active Directory virtual machine 114 provides an Active Directory service that manages user account information in a virtual sub-network for each client including virtual machines provided for each customer. To this end, both the user virtual machines and the desktop delivery control virtual machine must be joined to the active directory of the active directory virtual machine 113.

The service provider's central management system 120 according to the present embodiment may include a VMS 121, a Portal 122, a VSV 123 and a VMS-UI 124.

The VMS 121 is a component for performing a core management function and a VDI extension function of the entire data center, wherein the core management function is a function for managing physical computing resources belonging to a data center in units of Zone / Pod / Cluster / Storage / Host Manage the entire storage and network resources in the data center, manage packages or templates to be installed in user virtual machines and system virtual machines, manage pools of virtual machines to be used in creating or adding virtual machines, The VDI extension function is a function of the virtual desktop service which is independently provided for each client through control of the desktop delivery control virtual machine 113 and the active directory virtual machine 114, You can adjust things.

Portal 122, VSV 123, and VMS-UI 124 are all components that provide a user interface. Portal 122 receives a subscription request for a virtual desktop service from a client and is provided to the client. Provides a user interface for the billing portion of the service, the VSV 123 provides a user interface for the VDI extension function part of the management functions of the VMS 121, and the VMS-UI 124 provides the user interface. It provides a user interface for the core management function portion of the management function of one VMS (121).

2 is a diagram illustrating a conceptual configuration of a VMS 200 as one component of a virtual desktop service system according to an exemplary embodiment of the present invention.

Referring to FIG. 2, the VMS 200 of the virtual desktop service system according to the present embodiment, as described above, is a component for performing a core management function and a VDI extension function of the entire data center. And a broker unit 220.

A program module belonging to the API layer 211 of the core unit 210 is activated by calling a service API in a RESTful manner outside the VMS 200 (for example, Portal, VSV, and VMS UI of FIG. 1), and each of these is activated. By the function call included in the program modules, a core management function for managing an infrastructure or a virtual machine, a VDI function for managing an AD or a DDC, a monitoring function, and a scheduling function may be performed on the command layer 212.

In this embodiment, the service API is an API that can be called from outside the VMS 200 (eg, the Portal, VSV, and VMS UI of FIG. 1). The service API is provided to individual functions configuring the virtual desktop service for the outside of the VMS 200. Can provide request and response points.

The broker unit 220 is a program module for managing or controlling a system virtual machine allocated to each of the hypervisor and the client, and includes a hypervisor manager 221, an RVM manager 222, a DDC manager 223, and an AD manager 224. ) And the TVM manager 225.

In this case, when a new creation of a system VM is required, the hypervisor manager 221 receives a VM from a cluster pool in which a plurality of VMs are created in advance, creates a system VM of a required type, and then assigns the VM to a corresponding client. Assign.

The RVM manager 222, the DDC manager 223, and the TVM manager 225 are program modules that manage and control the RVMs, DDCs, and TVMs, which are system VMs allocated to each client, respectively. Through the XML-RPC protocol, each system VM can be managed and controlled by calling a remote procedure in XML format.

The AD manager 224 is a program module for managing and controlling AD, which is a system VM for a directory service allocated to each client, and may preferably use LDAP, which is a communication protocol for directory services.

The core unit 210 and the broker unit 220 may perform communication for management and control necessary for each other through API calls in a RESTful manner.

In the present embodiment, a REST (Representational State Transfer) ful method used for a service API or an API between the core unit 210 and the broker unit 220 may request a service resource identified in the form of a URI without an intermediate agent. By allowing CRUD to be controlled and controlled through the POST / GET function, it is more convenient and easier to call and manipulate or control each other's resources or program modules.

3A and 3B are diagrams illustrating a control authority of a service API used in a VMS of a virtual desktop service system according to an exemplary embodiment of the present invention, and a service API that can be executed according to the authority.

Referring to FIG. 3A, among the service APIs according to the present embodiment, A1 is an authority granted to an administrator account of the entire service. , RW) authority.

A2 is an authority granted to the administrator account for monitoring the service. The A2 has an authority (READ ONLY, RO) except for creation and deletion for all APIs through the infrastructure management function module (Infra Manager) among the core management functions.

B1 is an authority granted to an individual client's VDI manager account and has control (READ & WRITE, RW) authority of the client's VDI management API through a VDI manager.

B2 is an authority granted to an administrator account for monitoring VDI of an individual client. The B2 authority has the remaining (READ ONLY, RO) rights except for creation and deletion of the VDI management API of the client through the VDI management function module.

Referring to FIG. 3B, DeploySVM among the service APIs creates a system VM such as RVM, AD, and DDC assigned to each client, and can be called only from a service full administrator account having A1 authority.

DeployVM creates regular user VMs, not system VMs, and can be invoked from the VDI administrator account on clients with B1 privileges as well as A1 privileges.

ListHost is a hypervisor listing API such as XenServer. It can be called from a service administrator account with the same privileges as A1 or A2.

4A to 4B illustrate a request and response format of a service API used in a VMS of a virtual desktop service system according to an exemplary embodiment of the present invention.

Referring to FIG. 4A, a request of a service API according to the present embodiment may include parameters of session 411, method 412, request 413, and async 414, and the service resource may be RESTful. Is delivered in a way.

The session 411 corresponds to a parameter for receiving a session key of a string type, and is essential when requesting all other APIs except the SessionLogin API among the service APIs according to the present embodiment.

method 412 corresponds to a parameter that receives a method name to be called as a string. In this example, the method named “ListZones” is called.

The request 413 is a part that receives the parameter so-called request parameters defined on the API to be input when the method is called. In this embodiment, the ID is input as the request parameter of the method named “ListZones”. API is defined to receive, and accordingly, numeric data of 2 is passed as input value for ID.

async 414 is a parameter that requires additional input when the method has permission to execute Asyc job, and receives a boolean value indicating whether to execute the method as an Async job. In this embodiment, “ListZones In order not to execute the method named “Async job”, “false” is transmitted as the input value of the parameter.

Referring to FIG. 4B, the request of the service API according to the present embodiment may include response values of status 421, response 422, and total count 423, and are provided in a RESTful manner from a service resource. Receive.

The status 421 is a string type and corresponds to a part for transmitting the execution status according to the request. In this embodiment, the success is indicated through a status value of “success”.

The response 422 is a part defined on the API to deliver response values including the result of the execution of the corresponding method. In this embodiment, the id is “1” as the response value. It has a name of “EPC-KR0”, a data record meaning “EPC-VDI-DEV MOK-DONG”, an id of “2”, a name of “EPC-KR1”, and an “EPC-VDI- DEV MOK-CHEON ”is delivered as a result of executing the method call in the form of a list.

total count (423) is additionally returned when the method is a LIST API that provides list-type data as a response value. The total count (423) is a total count of elements in the list provided as a response value. Can return.

The table below illustrates representative methods of the system API with a request and response format according to the present embodiment.

Referring to the above table, the DeploySVM among the system APIs according to the present embodiment can be limitedly invoked only in a program module executed in an account having the A1 privilege. The request parameters include serviceprofile_id, description, cpus, mem_size, host_id, storage_id, serviceprofile_id, cpus, mem_size, host_id, storage_id, and org_id can be input as integer values. Of these, serviceprofile_id must be included as a request parameter in the method call. One can omit the rest or enter it selectively.

The DeploySVM performs the request with the following information: id, name, description, os_id, os_name, status, cpus, mem_size, vmtype_id, vmtype_name, system_type, org_id, org_name, host_id, host_name, cluster_id, cluster_name, pod_id, pod_name, zone_id, The response values corresponding to zone_name, created, uptime, boot, iso_id, iso_name, ha, locked, nics, and disks can be delivered to the program module that called the method. Among these, id, cpus, mem_size, vmtype_id, org_id Response values corresponding to host_id, cluster_id, pod_id, zone_id, and iso_id have an integer form, response values corresponding to created and uptime represent a specific time, and response values corresponding to nics and disks Defined as having a list type

In addition, DeployVDI in the system API according to the present embodiment can be called not only in the account having the A1 privilege, but also in the program module executed in the account having the B1 or C1 privilege. It can have storage_id, org_id, data_disks, allocator, and user_uri, and among these, serviceprofile_id, cpus, mem_size, host_id, storage_id, org_id can receive input values of integer type, and among these, serviceprofile_id, org_id, and user_uri are When calling a method, it must be included as a request parameter, but the rest can be omitted or optionally entered.

The DeployVDI performs the result of request, id, name, description, os_id, os_name, status, cpus, mem_size, vmtype_id, vmtype_name, system_type, org_id, org_name, host_id, host_name, cluster_id, cluster_name, pod_id, pod_name, zone_id, Responses corresponding to zone_name, created, uptime, boot, iso_id, iso_name, ha, nics, disks, user_uri, user_id, firstname, lastname, user_type, and connection_status can be delivered to the program module that called the method. Response values corresponding to id, cpus, mem_size, vmtype_id, org_id, host_id, cluster_id, pod_id, zone_id, and iso_id have an integer form, and response values corresponding to created and uptime represent a specific time. Responses corresponding to nics, disks and disks are defined as having a list form.

5 is a diagram illustrating a process of creating a system VM allocated to each client in a service process of a VMS according to an exemplary embodiment of the present invention.

Referring to FIG. 5, system VMs allocated to each client according to the present embodiment are RVM, AD, and DDC. Accordingly, the DeploySVM API for creating a system VM for each client is changed three times by changing an input parameter (serviceprofile_id). By invoking over, it is possible to perform a preparation process for providing a VDI service to each client.

First, in order to create an RVM among the system VMs, the WAS is assigned a DHCP IP of the management interface through the management network, and the RVM is generated based on the DHCP IP of the management interface. Afterwards, the WAS requests an additional IP for the corresponding virtual machine, that is, an IP in the Internet network (a public IP) and an IP in the service network. Update the DHCP configuration information for the private network based on the additional IP information configured by the WAS. If there is port forwarding information for the RVM, update it and perform other configuration tasks. In addition, by completing all the settings necessary for the initial operation of the RVM and running the RVM, a series of generation of the RVM 501 may be completed.

After the RVM is created, the WAS is assigned a DHCP IP of the management interface through the management network to create an AD, and the AD is generated based on the DHCP IP of this management interface, and then serviced through the RVM. Allocate IP on the network and perform other configuration tasks. Then, by completing all the settings necessary for the initial driving of the AD and driving the AD, a series of generation processes 502 of the AD can be completed.

After the RVM and AD are created, the WAS is assigned a DHCP IP of the management interface through the management network to create a DDC, and the DDC is generated based on the DHCP IP of the management interface, and then the RVM is created. Through the assignment of IP in the service network and other configuration work. In addition, by completing all the settings necessary for the initial driving of the DDC and driving the DDC, a series of generation 503 of the DDC may be completed.

Finally, WAS can include port 80 of the DDC's service IP in the RVM's port forwarding rules so that VDI service users can access the DDC and update it to apply it in future port forwarding of the RVM (POST PROCESS). , 504).

FIG. 6 is a diagram illustrating a process of setting a basic environment for performing a VDI service in a user VM of each client in a service process of a VMS according to an exemplary embodiment of the present invention.

Referring to FIG. 6, the VMS creates a user VM through Xen Server, a hypervisor manager module, assigns an IP to it, boots the user VM based on the assigned IP, and obtains initial configuration information required for the user VM. To do this, call getProvisioninginfo API to obtain the information necessary for initial configuration from AD, generate sysprep configuration information based on this, reboot the user VM, and change the operating system level initial configuration to match the generated sysprep configuration information. And reboot your VM.

When the user VM is rebooted and secondly, the getProvisioninginfo API is called, the user VM is mapped to the VDI service user through the DDC, and port 80 of the DDC's service IP is ported to the RVM so that the VDI service user can access the DDC. The update is included in the forwarding rule to complete the basic configuration process for performing VDI services in the user VM.

FIG. 7 is a diagram illustrating a multi-tenancy virtual desktop service provided by the data center 700 according to an exemplary embodiment of the present invention. The user virtual machines 715 to 716, 725, and 735 according to the present embodiment are illustrated. , RVMs 711-712, 721, 731, AD 713, 723, 733, and DDCs 714, 724, 734 are user virtual machines 115, 116, routers of the virtual desktop services system shown in FIG. 1. The virtual machines 111 to 112, the active directory virtual machine 113, and the desktop delivery control virtual machine 114 may respectively correspond. Therefore, the same items as those in the description of the virtual desktop service system shown in Fig. 1 are referred to.

In the multi-tenancy virtual desktop service according to the present embodiment, a plurality of independent clients should be provided with the same type of virtual desktop service in one data center 700, and the virtual desktop service for one client is a virtual desktop for another client. The data center 700 according to the present exemplary embodiment must logically separate and manage client-specific information. For this purpose, the data center 700 according to the present exemplary embodiment must manage the client-specific information logically. Provide a virtual desktop system.

Referring to FIG. 7, the client-specific virtual desktop systems 710, 720, and 730 according to the present embodiment are sets of user and system virtual machines including user virtual machines, RVM, AC, and DDC for each client, and are independent of each other. It is assumed that the security between the systems is maintained by concealing each other.

Since the RVMs 711, 721, and 731 must allocate service IPs to the user virtual machines 715, 725, and 735, and the number of assignable IPs is limited, the number of user virtual machines to be serviced can be allocated. If more than, the additional RVM 712 is generated and configured in the form of multi-RVM. In this case, a network between the user virtual machines 715 connected to the existing RVM 711 and the existing RVM 711 and the user virtual machines 716 connected to the generated RVM 712 and the additional RVM 711 may be added to prevent IP collision. Networks between RVMs must be logically separated from each other.

FIG. 8 is a diagram illustrating a network environment that is independently configured for each client according to an exemplary embodiment of the present invention. The user virtual machines 815 to 816, RVMs 811 to 812, and AD 813 according to the present embodiment are illustrated. ) And the DDC 814 are the user virtual machine 115-116, the router virtual machine 111-112, the active directory virtual machine 113, and the desktop delivery control virtual machine 114 of the virtual desktop service system shown in FIG. 1. Respectively). Therefore, the same items as those in the description of the virtual desktop service system shown in Fig. 1 are referred to.

Referring to FIG. 8, a virtual desktop system provided for each client according to the present embodiment is connected to a plurality of subnetworks Network A to E, and these subnetworks are IPs assigned to component nodes of these subnetworks. Logically separated from each other through the VLAN to avoid collisions.

Network A is a network between the RVM 811 and an external public network (eg, the Internet).

Network B is a network between system virtual machines assigned to the same client, that is, the RVMs 811 to 812, the AD 813, the DDC 814, and the service provider's management system 820.

Network C is a network between a VDI service provided through a user virtual machine and system virtual machines for supporting such a VDI service, that is, an RVM 811, an AD 813, and a DDC 814.

Network D is a network between user virtual machines and an additional RVM 812 in a multi-RVM environment formed when the number of user virtual machines exceeds the number of IPs that can be allocated in RVM, and performs the same function as Network C. It should be logically separated from Network C.

Network E is a network between a plurality of RVMs 811 and 812 in a multi-RVM environment formed when the number of user virtual machines exceeds the number of IPs that can be allocated in the RVM. It can be used for purposes.

FIG. 9 illustrates a process of deployVDI API for creating a virtual desktop environment for a user belonging to a specific client of a multi-tenancy virtual desktop service according to an exemplary embodiment of the present invention.

DeployVDI API according to the present embodiment is a series of preprocessing process to check the availability of logically separated hardware resources for each client and to allocate the resources of the virtual machine to implement the user virtual desktop environment to provide a multi-tenancy virtual desktop service (S902 to S906).

First, when a DeployVDI request is received through a call to the DeployVDI method for creating a user VM through an administrator account of a client (S901), a list of servers assigned to the client is inquired (S902). Check whether there is (S903).

If there is no server that can be allocated to the new user VM, a message indicating that the server resource allocated to the client is insufficient is notified to the hypervisor manager or the like (S908). The hypervisor manager can notify the administrator account of the client to request additional payments for the allocation of new server resources, or check the current available server resources in the data center and take additional actions such as assigning new server resources to the client. However, this is only one embodiment for convenience of description, and the present invention is not limited thereto.

If there is a server assignable to the new user VM, the list of storage resources allocated to the corresponding client is queried (S904) to check whether there is a storage resource assignable to the new user VM (S905).

If there is no storage resource that can be allocated to the new user VM, a message indicating that the storage resource allocated by the corresponding client account is insufficient is notified to the hypervisor manager (S909). The hypervisor manager can notify the administrator account of the client to request additional payments for the allocation of new storage resources, or check the current available storage resources in the data center and take additional actions such as allocating new storage resources to the client. However, this is only one embodiment for convenience of description, and the present invention is not limited thereto.

The server and storage resources to be allocated to the new user VM are selected from among the assignable server and storage resources identified through the steps S903 and S905 (S906). For example, among the assignable server resources, you can select the server resource with the lowest current VM allocation, and also select the storage associated with the selected server resource among the storage resources assigned to the client, and the storage associated with the selected server resource You can choose the storage resource with the fewest VMs allocated.

As described above, DeployVDI after a series of preprocessing steps (S902 through S906) of checking availability of logically separated hardware resources for each client and allocating resources of a user virtual machine to implement a virtual desktop environment of the user. By performing the method (S907), a user virtual machine to create a virtual desktop environment of the user is created.

In the case of implementing and providing a virtual desktop system for each customer according to the present invention, virtual desktops separated from each other to a plurality of enterprise or organization clients in one data center without having to operate a separate data center for each customer. To provide services.

In particular, it is possible to more faithfully reflect the needs of different hardware and software for each client, but can provide a virtual desktop service for each IT environment of the client without conflicting computing resources or IP for each client.

The virtual desktop system according to the present invention can be embodied as computer readable code on a computer readable recording medium. A computer-readable recording medium includes all kinds of recording apparatuses in which data that can be read by a computer system is stored. Examples of the computer-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, and the like. In addition, the computer-readable recording medium may be distributed over network-connected computer systems so that computer readable codes can be stored and executed in a distributed manner. In addition, functional programs, codes, and code segments for implementing the present invention can be easily inferred by programmers of the technical field to which the present invention belongs.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is clearly understood that the same is by way of illustration and example only and is not to be taken by way of limitation, You will understand. Accordingly, the true scope of protection of the present invention should be determined only by the appended claims.

Claims (11)

A plurality of user virtual machines providing a virtual desktop environment by using a virtual computing resource virtualized from a physical computing resource of a data center;
At least one router virtual machine for allocating an IP to the user virtual machine to mediate communication between the user virtual machine and an external network and to route communication within a sub-network of the user virtual machine;
A desktop delivery control virtual machine for connecting a session between the user virtual machine and a user account accessing the user virtual machine and managing a virtual desktop service provided by the user virtual machine; And
And an active directory virtual machine for authenticating a user account accessing at least one of the user virtual machine and the desktop delivery control virtual machine. The method of claim 1,
A virtual desktop service system comprising a set of independent system virtual machines including a router virtual machine, a desktop delivery control virtual machine, and an Active Directory virtual machine for each client. The method of claim 1,
The router virtual machine includes a DHCP server for assigning a dynamic IP to the user virtual machines. The method of claim 1,
The router virtual machine may be dynamically expanded or reduced in accordance with the number of the user virtual machines. The method of claim 1,
A first sub-network between the router virtual machine and an external public network, a second sub-network for controlling the router virtual machine, the active directory virtual machine and the desktop delivery control virtual machine in a management system of a service provider, the user virtual machine And the third sub-network for communicating with the router virtual machine, the active directory virtual machine, and the desktop delivery control virtual machine is logically separated from each other. 6. The method of claim 5,
When there are a plurality of router virtual machines,
The third sub-network includes a plurality of sub-networks allocated to each of the plurality of router virtual machines and logically separated from each other. The method according to claim 6,
When there are a plurality of router virtual machines,
The private network further comprises a subnetwork for sharing routing information between the plurality of router virtual machines. A router virtual machine that mediates communication with an external network of a user virtual machine providing a virtual desktop environment by using a virtual computing resource that virtualizes a physical computing resource of a data center and routes communication within a subnetwork of the user virtual machine. Router virtual machine generation step of generating a;
An active directory generation step of generating an active directory virtual machine which receives an IP of the sub-network from the router virtual machine and authenticates a user account accessing the user virtual machine based on the assigned sub-network IP; And
A desktop that receives an IP of the sub-network from the router virtual machine and connects a session between the user virtual machine and the user account based on the assigned sub-network IP and manages a virtual desktop service provided by the user virtual machine. A desktop delivery generation step of creating a delivery virtual machine; And
Updating a port forwarding rule of the router virtual machine based on a predefined port of an IP of the sub-network of the desktop delivery virtual machine. How to prepare. 9. The method of claim 8,
The router virtual machine creation step
Receiving a management IP through a management network logically separated from a service network including the sub network;
Creating the router virtual machine based on the assigned management IP;
Requesting allocation of public IP and service IP for the created router virtual machine; And
And updating the initial settings of the router virtual machine based on the public IP and the service IP assigned in response to the request. 9. The method of claim 8,
The active directory generation step
Receiving a management IP through a management network logically separated from a service network including the sub network;
Creating the active directory virtual machine based on the assigned management IP;
Requesting the router virtual machine for service IP allocation for the created Active Directory virtual machine; And
Updating the initial configuration of the Active Directory based on the service IP assigned in response to the request. 9. The method of claim 8,
The desktop delivery generation step
Receiving a management IP through a management network logically separated from a service network including the sub network;
Creating the desktop delivery virtual machine based on the assigned management IP;
Requesting the router virtual machine for service IP allocation for the created desktop delivery virtual machine; And
And updating an initial setting of the desktop delivery virtual machine based on the service IP assigned in response to the request.

Images