Small Private Cloud Deployment Solution

项目背景

为用户提供可访问的桌面虚拟机，方便软件研发人员日常办公，软件开发，编译等工作。主要操作包括Visor制图、程序开发测试以及使用office软件办公。
目前阶段需要支持100台虚拟机（4VCPU， 8GB MEM，80GB Disk， Windows7）；将来随着业务的扩展，需要支持200台，甚至更多桌面虚拟机。
在已经提供硬件的基础上设计满足以上要求的基于OpenStack(Liberty version)的小型私有云部署方案。目前硬件设备包括10台服务器，基本配置：CPU:X5482；MEM:196GB；DISK：1TB。

关键问题

从项目背景需求可知，该项目需要解决为研发人员提供云桌面服务，用户独占虚拟机资源（一台虚拟机仅分配给一个用户使用），用户桌面之间基于虚拟机隔离。因此该项目需要解决的关键问题是：

• 高质量用户体验：
  对于主要是提供桌面服务的云来说，用户体验永远是第一位需要考虑的。用户要获取如同访问物理机一样顺畅自如，画质清晰的使用体验。
• 数据安全：
  和其他云服务不同，桌面云需要确保为用户数据提供持久，安全存储，此外还需要提供快速方便的的数据备份和恢复机制。
• 高可用：
  桌面云系统需要克服单点失效，解决负载均衡以及高效运维等问题。
• 可扩展：
  方便后续演进和扩容，即在不更改现有架构的前提下，方便添加控制节点和计算节点，达到快速扩容的目的。

当然还有其他问题，比如成本通常是需要重点考虑的问题。这里暂不将成本问题放置在优先考虑的问题。

解决方案

对上述提到的4个优先需要解决的问题，下面分别给出解决方案，为实际部署方案提供理论依据。

高质量用户体验

为达到如同使用物理机一般访问效果，高配置的虚拟机以及优秀的远程显示协议固然是影响因素，但不是重点。云系统的基本服务包括计算，网络以及存储，每一个都有不同的资源需求，如何平衡这些服务，最终提供高性能的系统，是接下来设计时刻需要考虑的问题。

• 规划计算资源
  Openstack支持配置资源超分配比例，默认的CPU超分配比例是16:1，默认的内存超分配比例是1.5:1。以需求中提到的虚拟机配置为例，在默认情况下，且开启超线程技术，1台服务器可以提供4 * 2 * 16 /4 = 32 实例；如果按照内存算的话，可以提供192 * 1.5 /8 = 36 个实例。
  但是，无论是CPU还是MEM，追求更多的可用虚拟CPU或者虚拟内存都是以牺牲实例性能为代价的。实际的生产环境不建议开启内存超分配，对于CPU超分配也有严格的限制。受已有硬件设备限制，为平衡实例数量和实例性能的考量，本项目将CPU超分配比例设置为6:1，内存超分配比设置为1:1。

参考：
http://docs.openstack.org/openstack-ops/content/compute_nodes.html
http://www.ibm.com/developerworks/cn/cloud/library/1408_zhangxl_openstack/

• 规划网络资源
  传统Openstack云会有多个网段，每个网段所要实现的用途不一样。比如公共网络是给租户和管理员用于访问云的；管理网络为该网段内所有硬件节点提供互联互通，提供云内部各服务的通信；为存储提供专门的存储网络已提高访问速度。
  分析项目的需求发现，用户日常工作中有大量且频繁的IO操作，如果创建专门的块存储节点来存储数据，每一次用户操作都将不得不通过网络，即使该网络（存储网络）有很高的带宽，也比不上在本地磁盘上直接操作的性能。因此本方案不单独设计存储节点，也就不存在存储网络。所有实例的持久化都在计算节点上实现。
  另外，该桌面云系统不需要为终端用户提供全部的控制权来建立虚拟网络资源，事实上，桌面用户也没有必要去创建，管理网络资源。为简化管理和部署，本方案不采用具有3层网络服务的网络部署方案。

参考：
http://docs.openstack.org/liberty/install-guide-ubuntu/overview.html
http://docs.openstack.org/openstack-ops/content/compute_nodes.html

• 规划存储资源
  Openstack提供块存储和对象存储。事实上，在该项目中，没有必要单独设立对象存储节点，镜像和实例快照存在glance服务器上就已经足够（毕竟控制节点1TB的空间足够大）。本方案也不单独设立存储节点和存储网络，正如上面所说，跨网络的IO操作明显影响性能。
  不设立块存储节点不意味着不需要块存储服务（cinder）。相反，对于提供桌面服务的云系统来说，除性能以外，用户数据的持久性保存是非常必要的。本方案将计算服务和存储服务都安装在资源节点（计算节点）上。计算服务更多关注的是主机的CPU和内存，而存储服务更多关注的是硬盘。恰好，在本项目中，每台服务器提供多达1TB大小的磁盘空间，足够为实例提供本地持久化存储。

参考：
http://docs.openstack.org/openstack-ops/content/compute_nodes.html

数据安全

对于主要提供桌面服务的云系统来说，保证用户数据（包括虚拟机操作系统和私有数据）不丢失，以及云系统数据的异地备份是很重要的。
OpenStack中实例的持久化需要块存储服务来支持，通常需要额外的存储节点和存储网络支持。本项目设计直接将存储和计算集中在同一资源节点上，这样做的优点显而易见：（1）一台资源节点上密集IO操作不会影响到其他资源节点上的实例性能；（2）直接IO访问比跨网络IO访问性能明显提高。
考虑资源利用率和性能，将存储磁盘做RAID5处理。
需要注意的是，要做到虚拟机实例持久化，需要从卷（volume）启动实例（这与架构无关，与云系统管理操作有关）。
另外，需要额外部署具有大存储空间的备份系统（节点），比如NAS，提供重要备份数据的异地备份机制，以便于保存实例快照以及云系统备份数据。实例快照用于实例的快速恢复和迁移，避免某个资源节点宕机而实例不可用。云系统备份数据用于系统快速复原，避免因某个节点出现系统级别故障而不可用。

参考：
http://docs.openstack.org/admin-guide/blockstorage-boot-from-volume.html

高可用

为减少系统的宕机时间和数据丢失，为每个服务提高冗余，防止单点失效导致系统宕机，显得尤为重要。
OpenStack由总多组件总多服务构成，仔细分析这些服务，有些是有状态的，有些是无状态的。其中nova-api, nova-conductor, nova-scheduler, glance-api, keystone-api, neutron-api，因其不存储数据和状态，因此没有必要为这些集群或者复制这些服务；数据库服务和消息队列服务属于有状态服务；因其存储数据，需要对其集群或者复制。所有这些服务都集中在控制节点上，考虑到项目的实际需求（100 VM）与设备限制，本项目设计使用2台控制器。
接下来要考虑的是将这些服务设计成双活模式（active-active），还是主被模式（active-passive）。双活模式提供更为良好的弹性，主从切换时间短。因此，本项目中上述所提供的服务都被设计成双活模式，使用HAProxy+Keepalived完成流量到各个Openstack API的负载均衡和状态探测；为数据库服务同步复制机制，为消息队列进行集群。

参考：
http://docs.openstack.org/ha-guide/
https://www.mirantis.com/blog/software-high-availability-load-balancing-openstack-cloud-api-servic/

实际部署

硬件列表

10台服务器（2台用于控制节点，8台用于资源节点）；
1个NAS存储节点；
其他必备网络设备：24 或者48 口具有VLAN功能的交换机，路由器，防火墙

主机操作系统

宿主机操作系统：OpenStack社区对Ubuntu支持比较完善，Ubuntu更新速度快，内核版本比较新，可以支持更高版本的KVM，对OpenStack使用者来说，Ubuntu可以提供更好的性能，据调查，约为55%用户在构建Openstack时选择Ubuntu。

Openstack组件选择

对于小型桌面云来说，只需要必要的组件就足够了：Nova，Neutron，Cinder，Keystone，Glance，Horizon这六个组件。

其他软件选择

提供负载均衡的软件：HAProxy； Keepalived;
数据库软件：MariaDB，Memcached; 其中Memcached 缓存系统用于减轻认证服务的负载，提高读写速率；
消息队列软件：RabbitMQ；
数据库集群软件：Galera

网络规划

整个云系统分两个网络：公共网络和管理网络，公共网络就是公司内网，管理网络可以是一个C类地址的私网。

图4.5-1 基本节点部署图

图4.5-2 具体部署图

主机服务布局

由于没有物理负载均衡设备，改用负载均衡软件代替，且直接将HAProxy，Keepalived安装到两个控制节点上。

图4.6 主机服务分布

监控软件实施

桌面云系统中，不仅仅需要监控各个集群节点的性能指数，更关心的是众多Openstack服务，进程是否允许正常。基于此使用Nagios + NagiosGraph部署监控系统。Nagios可扩展性强，管理人员可以更加自己的程序语言强项编写插件，完成服务的监控。
参考：
http://docs.openstack.org/openstack-ops/content/logging_monitoring.html#process_monitoring
https://exchange.nagios.org/directory/Plugins/Cloud/openstack_vm_monitoring/details

备份策略

管理人员可编写脚本定期自动将实例快照和云系统各节点重要数据（包括操作系统，应用软件，特别是/var/lib/glance, /var/lib/nova等重要数据目录）增量备份至远程NAS服务器。
参考：
http://docs.openstack.org/openstack-ops/content/backup_and_recovery.html

远程显示协议选择

因实例操作系统是window系，故建议采用window系统自带RDP。如果不想在瘦终端安装远程显示协议客户端，可以采用VNCServer + NoVNC直接在终端使用浏览器访问虚拟桌面。

方案已知缺陷

实例可用磁盘小

计算节点实例可用磁盘太小，8台计算节点，如果要达到100个虚拟机的目标，每台计算节点至少可创建12台VM。CPU资源和内存资源足够（CPU超分配比例为6:1，可用vCPU为426=48，内存超分配比为1:1，可用内存为192GB）；
每台计算节点的可用磁盘空间900GB（出去系统占用空间），每个虚拟机可获得的磁盘空间为900/12=75GB。
因此，如果实例需要更多的持久化存储空间，最经济的办法是在计算节点上直接挂在更多的磁盘。

实例无法热迁移

因实例的存储是固定在节点上，没有做存储空间的共享，因此如果实现实例的热迁移。放弃热迁移功能的考虑是基于实例性能的考虑，实例无需跨网络读写IO。

租户没有网络资源管理权力

租户没有权力创建，管理网络资源，只有管理员才可以。这是基于目前该桌面云系统用户使用场景考虑的。用户使用场景可概括为：
（1）用户想管理员申请虚拟桌面；
（2）管理员创建虚拟机，分配float IP，将该虚拟机挂接可用子网；
（3）管理员告知用户虚拟机float IP；
（4）用户通过RDP登录远程虚拟桌面。
为防止用户登入其他桌面，故不允许用户有直接访问云系统的权限，因为一旦可用访问，他便可以查看和他在同一项目下的其他虚拟机，尽管每个虚拟机有密码防护，但为了减少潜在的安全弊端，租户（用户）没有直接登录云系统的必要。
这样做缺点也是显而易见的，即虚拟机一旦关闭，用户没有权限启动机器，只有通知管理员进行（除非开发另一套虚拟机管理程序）。