4007676280
云终端系列报道第七十六期 - 实现虚拟云桌面 2016-09-08

炙伦云终端分享嘉宾:


如何实现虚拟云桌面
    01.云桌面原架构
    
    携程云桌面后台云平台在实践中进行了多次迭代,原有架构如上图所示。该架构特点是,直接在OpenStack Nova进行定制开发,添加了分配虚拟的接口,实现瘦客户端直接访问OpenStack获取虚拟机信息。
    这个架构下,云桌面平台可以直接访问全部的虚拟机信息,直接进行全部的虚拟机操作,数据也集中存在OpenStack数据库,部署方便。用户权限通过OpenStack Keystone直接管控,管理界面使用OpenStack Horizon并添加云桌面管理页面。
    
    典型的分配虚拟机用例中,瘦客户端通过OpenStack Keystone进行认证、获取Token,然后访问Nova请求虚拟机。如上图所示,瘦客户端会通过Keystone进行认证,Keystone确认用户存在后向域LDAP进行密码校验,确认用户合法后返回Token;瘦客户端再通过Token向Nova申请虚拟机。
    Nova根据瘦客户端设置的坐席信息,首先查找这个坐席是否已分配虚拟机。如有直接返回对应虚拟机。如无,从后台空闲虚拟机中进行分配并更新数据库分配,返回远程桌面协议连接信息。
    
    02.原架构局限性
    
    
    随着业务增长,原架构出现一些局限性,首先,业务与OpenStack呈强绑定关系,导致OpenStack升级涉及业务重写;修改业务逻辑需要对整个云平台做回归测试。
    其次,用户必须要是Keystone用户,用户管理必须使用Keystone模型。导致Keystone与LDAP之间要定期同步进行,有时还需手工同步特殊用户。
    管理层面,因为Horizon的面向云资源管理的,但业务主要面向运维的。这部分差异,导致我们开发新的Portal来弥补,管理人员需要通过两套系统来进行运维。
    整体方案上,云桌面远程桌面协议由第三方提供,如果第三方方案不支持OpenStack,就无法在携程云桌面系统使用。
    最后,用户部门有各种需求,直接在OpenStack内进行开发难度大,上线时间长,开发人员很难实现技术引领业务发展。
    
    03.新架构
    
   
    经过架构调整,新架构实现了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分配一台虚拟给,返回给用户。
    
    最后,对用户部门来说,看到的是用户属于一个组,这个组对应特定的虚拟机。只需调整用户属性,即可实现用户分配特定的虚拟机,充分满足他们的各种需求。

上一页:云终端系列报道第七十五期 - 选择OpenStack 下一页:云终端系列报道第七十七期 - 大规模部署
推荐新闻 Recommended news
帮助中心
4007676280