新闻中心/行业资讯

如何实现虚拟云桌面?

云桌面后台云平台在实践中进行了多次迭代,原有架构如上图所示。该架构特点是,直接在 OpenStack Nova 进行定制开发,添加了分配虚拟的接口,实现瘦客户端直接访问 OpenStack 获取虚拟机信息。

这个架构下,云桌面平台可以直接访问全部的虚拟机信息,直接进行全部的虚拟机操作,数据也集中存在 OpenStack 数据库,部署方便。用户权限通过 OpenStack Keystone 直接管控,管理界面使用 OpenStack Horizon 并添加云桌面管理页面。

典型的分配虚拟机用例中,瘦客户端通过 OpenStack Keystone 进行认证、获取 Token,然后访问 Nova 请求虚拟机。如上图所示,瘦客户端会通过 Keystone 进行认证,Keystone 确认用户存在后向域 LDAP 进行密码校验,确认用户合法后返回 Token;瘦客户端再通过 Token 向 Nova 申请虚拟机。

Nova 根据瘦客户端设置的坐席信息,首先查找这个坐席是否已分配虚拟机。如有直接返回对应虚拟机。如无,从后台空闲虚拟机中进行分配并更新数据库分配,返回远程桌面协议连接信息。原架构出现一些局限性,首先,业务与 OpenStack 呈强绑定关系,导致 OpenStack 升级涉及业务重写;修改业务逻辑需要对整个云平台做回归测试。

其次,用户必须要是 Keystone 用户,用户管理必须使用 Keystone 模型。导致 Keystone 与 LDAP 之间要定期同步进行,有时还需手工同步特殊用户。管理层面,因为 Horizon 的面向云资源管理的,但业务主要面向运维的。这部分差异,导致我们开发新的 Portal 来弥补,管理人员需要通过两套系统来进行运维。

整体方案上,云桌面远程桌面协议由第三方提供,如果第三方方案不支持 OpenStack,就无法在云桌面系统使用。

最后,用户部门有各种需求,直接在 OpenStack 内进行开发难度大,上线时间长,开发人员很难实现技术引领业务发展。经过架构调整,新架构实现了 OpenStack 与我们的业务解耦,同时适应用户部门的业务发展方向,方便功能快速迭代上线。

从图中可以看出,云桌面业务逻辑从 OpenStack 中独立出来,成为了 VMPool,Allocator;管理层独立开发一套面向 IT 运维的 Portal 系统,取代 Horizon;云平台可直接原生的 OpenStack。

其中 VMPool 负责维护某种规格虚拟机的可用数量,避免需要的时候没有虚拟机可用,让用户等待。Allocator 满足符合条件的用户请求,返回用户对应的虚拟机或者从 VMPool 分配虚拟机分配用户。

对于用户分配虚拟机的典型用例,与原有架构改动较大。首先,业务层瘦客户端将直接访问业务层的 API。API 层会直接通过 LDAP 进行用户认证,并获取用户 OU、组别等信息。

接着,业务层将进行用户规则匹配。每个 Allocator 通过用户组、OU、tag 等进行规则匹配,以确定该用户是否由自己进行服务。如不满足 Allocator 所定义的规则,将按 Allocator 的优先等级,继续选取下一个 Allocator 进行匹配,直到匹配或者默认规则为止。

匹配后,如果是有绑定关系的分配规则,比如用户绑定或者坐席绑定、TC 绑定,那 Allocator 将直接从数据库返回已有的绑定;如果无绑定关系,Allocator 就会从对应的 VMPool 分配一台虚拟给,返回给用户。

最后,对用户部门来说,看到的是用户属于一个组,这个组对应特定的虚拟机。只需调整用户属性,即可实现用户分配特定的虚拟机,充分满足他们的各种需求。