云终端系列报道第七十六期 - 实现虚拟云桌面 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分配一台虚拟给，返回给用户。
    
    最后，对用户部门来说，看到的是用户属于一个组，这个组对应特定的虚拟机。只需调整用户属性，即可实现用户分配特定的虚拟机，充分满足他们的各种需求。