Citrix在桌面虚拟化领域一直是业内领导者,其中对于虚拟桌面的批量置备和管理的技术,拥有PVS和MCS两种成熟的技术。这两种技术的好处就是能够基于一个模板批量的对大量的虚拟桌面进行统一维护和更新管理。在本文中咱们简要聊聊MCS置备模式。算法
MCS模式在Citrix是XenDesktop 5.0的版本的时候推出的功能,整体来讲仍是比较年轻的,不想PVS久经风霜。那个时候正是Citrix的XenDesktop 4.x的IMA架构迈向XenDesktop 5.x的FMA架构的时候,能够说MCS是FMA架构的基础和核心。FMA起初仅仅是应用于VDI架构的,你看XenApp在6.5还在使用IMA就知道那个时候Citrix的产品方向就是这样设计的。数据库
其实从本质上来讲,无论是MCS仍是PVS,都是一种纯粹的存储技术,MCS就是基于存储所谓的“连接克隆”技术而建立。MCS经过“连接克隆”建立虚拟机,建立的每一个VM都分配了两个或三个盘:缓存
Master Image(主映像):这是基于模板虚拟机的快照而建立的虚拟磁盘,这个磁盘自己建立出来以后是只读的属性,包含了模板虚拟机系统盘里面的内容。服务器
Differencing Disk(差别磁盘):差别磁盘链接到建立出来的虚拟机,里面存储了虚拟机的全部变化(做为写缓存)。架构
Identity Disk(身份盘):大约为16 MB 空间大小的一个磁盘。该磁盘包含了一些基本的信息,如机器名、SID、域计算机账户密码等等信息,这些信息在启动操做系统的时候被注入到虚拟机里面,以保证虚拟机能够被正确识别。并发
Personal vDisk(我的虚拟磁盘)(可选):该磁盘存储咱们想要永久保存的数据(超出本文的范围)。app
具体以下图所示:运维
好比咱们经过MCS模式建立了一组虚拟桌面,那么这组虚拟桌面在Studio中表现为一个计算机目录,在该计算机目录中,对应与服务器虚拟化底层的一个存储LUN,该LUN内存在一个Master Image。同时存在多个Differencing Disk和Identity Disk一块儿构成该计算机目录资源池。全部在该计算机目录中的虚拟机都同时读取Master Image上面的操做系统。而后再由写入时才会将各自的写IO缓存到各类虚拟机挂载的Differencing Disk中进行缓存。ide
而咱们知道Citrix的MCS模式下存在着池静态和池动态之分,池静态就是在虚拟机重启以后,不对LUN内的虚拟机挂载的Differencing Disk进行删除,这样就可保存咱们写入的缓存信息在咱们虚拟机从新启动以后还存在。而池动态模式模式下,每次重启虚拟机都保证将虚拟机挂载的Differencing Disk删除掉,在虚拟机从新启动的时候,复制MasterImage磁盘的空间从新生成Differencing Disk并将其格式化以后挂载给虚拟机。这样的情形下咱们上次写入的缓存信息是不会获得保留的。性能
主要有两点:
一、占用空间过多
二、对Master Image磁盘读IO压力大
上面大体说了MCS的一些基本概念,接下来,咱们书接上文继续说说在MCS建立好计算机目录以后,将虚拟桌面分配给了用户进行使用。使用一段时间以后管理员须要对虚拟桌面京维护更新,他只须要在模板虚拟机上面将须要更新的部分安装配置完毕,而后基于这个安装更新对模板虚拟机制做一个快照,便可基于这个快照进行更新。
MCS在这里就出现了其缺陷,咱们的每一次更新,在服务器虚拟化底层的LUN中,都会将更新的快照从新生成一个新的Master Image,以下图中,好比咱们更新的新的Master Image叫B,原始第一个叫A。在更新的过程当中,在保持A及其生成挂载到虚拟机的磁盘不变外,还须要重复第一次建立计算机目录的过程,生成B的Master Image并生成相应的虚拟机的Differencing Disk。所不一样的是Identity Disk不在生成。那么在这个时候,其对应咱们的存储空间的占用的双倍的。咱们必须保证有足够多的空间用于咱们进行这样的更新操做。
但B的Differencing Disk建立完毕后,会自懂将A的Differencing Disk删除,而后将B的Differencing Disk挂载给对应的虚拟机。知道全部的虚拟机都完成这个操做,即更新完成。这个时候A的Master Image还不会自动删除,须要大概六个小时以后才会自动进行删除。A在不自动进行删除的状况下,即在这六个小时以内,咱们是能够进行回滚操做的。
上述说明MCS在更新的时候占用空间过大,那么Citrix是如何来解决这个占用空间过大的问题的呢?这个问题客官您等会看第三小节。我继续说MCS的不足。
上面我说了,MCS的建立的一个LUN里面,若是对应一个计算机目录,那么这个计算机目录内的因此虚拟机都会同时去读取相同的Master Image,那么毫无疑问的是,在会对Master Image所知的磁盘形成很大的读IO压力。测试结果代表在MCS模式下,虚拟机对于磁盘的读写IO比为75%:25%。若是是HDD的磁盘,那么在大量并发下读IO就不行了,这个时候桌面运行就显得很缓慢。
解决方案:
一、占用空间大:精简置备
二、读IO高:SSD加速、缓存到内存
针对于MCS占用空间的不足,解决方法是什么:使用存储精简置备技术,按需使用存储空间,对上层应用欺骗以达到按需使用的目的,减小存储空间的占用。
那么存储精简置备技术是咋实现的呢?
看上面的图,无论是什么牌子的存储,其底层无非就是两种新形式:块和文件,固然这里不包括对象存储。事实上对象存储也不适合这样的业务场景。有了上述基础以后,咱们再来讲,块存储在底层是直接将数据存储到磁盘上,而且以磁盘的块为单位,是直接裸盘存储。而文件呢,则稍微有所区别,文件是将磁盘上的块单位的这一片空间提交给文件系统维护管理,因此的虚拟机保存的数据都是叫给文件系统,有文件系统将这些数据保存到磁盘上,至于怎么保存,虚拟机无论。有了这样一个中间人以后就好办了,我只须要在文件系统上标记说这一段空间给你了,而实质上这一点空间我只给了你须要使用的那部分,剩余的部分文件系统可能就另外挪做他用了。但虚拟机须要使用的时候,向文件系统发起存储请求时文件系统在给他再一块空间给虚拟机使用,是否是感受和社会上的某种风气相似,其实都是源于社会上来实践,才能想出这样的设计。固然毫无疑问,社会上的这种风气被人吐槽,这种设计也好不到哪里去是吧。为何这么说呢?好比说你使用精简置备模式,那天应用一抽风,一小时以内给你把盘塞满你来得及加盘不?没事,我有备用盘。那就更无语了,备一堆盘不如开始就加上去呢?此外,不只对运维来讲压力大,在性能上也是有影响的。因为是使用按需分配,若是有多个逻辑资源同时并行写入,这个时候这些逻辑资源在物理视图上就是交织分配的,就变得空间上不连续了,不连续的文件灵碎的放置在机械盘上,对机械盘的寻道是致命的影响,性能不降低才怪。
书归正传,那么回答了上述问题,存储的精简置备是怎么实现的?存储设备的精简各自有各自的作法,底层存在必定差别,但大体上思路相似。能实现LUN精简置备的存储基本上是智能的,下层几乎都有一个fs结构来统治块的分配和归属。例如netapp是采用LUN on file,即每个LUN都对应一个文件,和实际的块松绑。初建时文件很小,随着写入持续增大至预约义的大小上限。
基于这个,再次引伸出一个问题?为啥XenServer上不支持块存储的精简置备,只有NFS才支持呢?XenServer上由于自己没有本身的文件系统,虚拟机之间写块存储设备,是直接写入到磁盘的。因此不像VMWare这样,自己有VMFS这样的文件系统能够在虚拟化层实现精简置备。那么虚拟化层不能实现这个技术,那么只有靠存储来提供了。因此在XenServer上使用精简置备须要使用NFS了。固然XenServer就是一块存储,可不能够实现精简置备,固然也没有问题,这就靠提供块存储的存储设备在底层实现,而后将接口API和XenServe集成便可实现。固然不只仅是FS这一层了,还有Locking问题,因此也很差作滴。
MCS的第二个不足是读IO较高,由于全部的虚拟机都会同时的去读Master Image。解决办法是采用SSD来进行加速。MCS须要存储(读)IOPS较多。相对而言,相比于PVS,MCS大约须要的IOPS是PVS的1.6倍。
对于这方面的优化,Citrix的XenServer推出了Intellicache的功能,IntelliCache支持MCS的Pooled和Dedicated这两种模式;Pooled模式支持本地的读和写的Caching,可是不支持XenMotion,能最大存储的IO和空间节省。可是若是是Dedicated模式,就只支持本地的读,因此能够作XenMotion了,也能节省存储的读IO。IdentityDisk就一直都是放在存储上,由于自己体积小,就不用参与其中了。好了,将缓存放从共享存储移到主机的本地磁盘,是节省了必定的存储链路开销,可是本地存储的IOPS不够支撑虚拟机的磁盘在本地存储上读写怎么办?这个时候主机上的本地磁盘就得加SSD了。
IntelliCache对Cache是写到硬盘中,那么咱们可不能够将其采用PVS的相似技术同样,写到内存中呢?答案确定是能够的,在XenServer6.5版本中,就开发了这样一个技术,叫内存的读缓存技术,XenServerv6.5的内存读缓存技术是对IntelliCache技术的一个进一步改进。能够把基础镜像模板放到服务器的本地内存中缓存。这样对虚拟桌面环境下的虚拟机启动将会带来飞跃,同时带来性能的提高。
主要有两个:
一、MCS模式下,在LUN生成的虚拟机文件不能迁移?使用MCS虚拟机故障切换是没有问题的,即HA。但若是你想移动虚拟机磁盘/文件以及使用的Storage vMotion,好比使用存储实时迁移或存储的XenMotion,这就不支持了。这是由于虚拟机驻留在磁盘ID /数据存储(存储在中央站点数据库信息)之间存在很强的依赖性,一旦这个关联关系中断你的虚拟机将不能正常启动。
二、XenServer内存读缓存然并卵,还须要相似于PVS的Cache in RAM with overflow to disk的机制?服务器主机的内存老是紧俏资源,至少如今来讲是的。咱们有那么多的内存拿去作缓存使用吗?并且在XenServer大规模部署环境下,每一个LUN得一个Master Image,每个Master Image缓存到内存须要多大的空间,那么多的Master Image我有那么多了内存来放吗?因此仍是作点向阶段来讲比较物美价廉的功能吧?因此MCS还须要相似PVS的Cache inRAM with overflow to disk的机制。那你要问了,这个机制实现起来容易吗?固然这是Citrix的问题,可是从技术角度来讲,实现是没有问题的,难易程度我就不便成说,毕竟不是搞开发的。
那基于上面的俩个想法,我认为第一点问题,Citrix自己须要从产品层面去解决。为何有这样的改进呢,我认为这样的改进能够方面我多DR?作存储的HA?对吧!在Citrix没有改进产品以前,固然不知道会不会有改进了。那么咱们的临时解决方案是什么呢?咱们考虑实施一些SDS解决方案来达到DR或者存储HA的效果,像Nutanix,Atlantis,VSAN,VPLEX等解决方案,使您能够在 MCS下也能移动虚拟机,包括虚拟机的磁盘,不管是自动仍是手动,同时保持虚拟机磁盘ID依赖使用并结合像影子克隆,数据局部性,数据同步等功能。许多SDS解决方案不只能够帮助MCS利用存储的自动精简配置,并且还能够提升读取缓存。在超过400个桌面的单位模板读取中,咱们看到读缓存率一般为85-90%。而这能够在没有使用任何固态硬盘的SDS数据存储上实现!SDS存储能够提供比intellicache甚至新的XenServer 6.5读取内存中的企业和桌面+版本缓存更好的结果。
因此我认为,要解决这个问题,软件定义的存储是关键。Citrix的软件定义存储什么出来啊?结合XenServer好好弄弄仍是有戏的。
如何使用Nutanix计算平台解决CitrixMCS的3个最大的挑战,综合我上述所言,其挑战主要以下:
读IO
数据存储
连接克隆技术和数据局部性
1)读IO
首先让咱们来看看Nutanix Distributed Storage Fabric(NDSF)I/O路径:
Oplog角色:持久性写缓存
描述:Oplog 相似于文件系统的日志(journal),用来处理突发的写操做,并聚合这些写操做顺序地写到 ExtentStore 中。为了保证数据高可用性的要求,在写操做完成(Ack)以前,数据写入Oplog 的同时被同步复制到另外一个 CVM 的Oplog 中。全部CVM的Oplog 都参与复制操做,并依据CVM负载状况自动选择。 Oplog 保存在CVM的SSD层以提供极高的IO写性能,特别是随机IO写操做。
Extent Store角色:持久性数据存储
描述:Extent Store 是DSF 中持久性大容量存储组件,它横跨 SSD和HDD,而且能扩展到其余节点的存储设备上。有两种数据流进入Extent Store, 一种是从 Oplog 中被合并的数据顺序写入到 Extent Store,另一中是绕过 Oplog 的顺序写操做直接写入 Extent Store 中。Nutanix 的 ILM(informationlifecycle management)基于IO 类型(IOPattern)动态决定数据保存的热分层位置,而且在不一样热分层之间移动数据。
Unified Cache角色:动态读缓存
描述:Unified Cache 是可消重的读缓存,它横跨CVM 的内存和SSD。当读取的数据不在缓存中(或基于一个特定的指纹),数据会放到Unified Cache的Single-touch池,该池彻底保留在内存中,而且使用 LRU(最近最少使用算法)直到数据被弹出。若是后续有对该数据的读取操做,数据会被“移动”(其实没有实际的数据移动,移动的只是数据的元数据(metadata)到 Multi-touch池(Multi-toiuch 池跨内存和SSD)中的内存段。这时开始,数据块具有 2 个 LRU,一个是其位于内存段的LRU,若是LRU耗尽,则数据被移动到Multi-touch池的 SSD段,并被赋予一个新的LRU。若是数据再次被读取,则数据被移动到Multi-touch池的顶端。
缓存的粒度和逻辑:
数据是以 4K 粒度读进缓存的,全部缓存是实时完成的,没有延迟,也没有采用批处理方式把数据读进缓存中。
总之,处理读取IO的NutanixDSF是容易的,提供最优的IO路径处理读写请求。
2)单一的数据存储
传统的Citrix MCS实现计算节点(刀片、机架设备等)。使用SSD也能达到虚拟桌面的IO所须要的速度。可是这种体系结构有两个主要的缺点:
管理开销
缓慢的更新过程
具备多个数据存储库,将致使管理开销,在更新/部署的时候部署的数量,错误的次数等也会相应的增长。同时复杂的也是有的。
其次,每次更新须要复制咱们的数据存储,可能会致使一个很是缓慢的更新过程。有一个软件定义的存储解决方案或HCI,像Nutanix。会给咱们带来全部的共享存储和本地存储的性能和未曾有的无论理便捷性。同时因为其底层采用的多副本机制,MCS发布出来的虚拟机磁盘文件是支持进行存储迁移的。
3)连接克隆技术
正如上面前面提到的,MCS是基于连接克隆技术,其中MCS的过程以下:
建立主映像
建立快照
建立计算机目录,选择快照等
此后,该快照的完整副本Master Image将被用来为每个虚拟机建立差别磁盘和身份磁盘。
那么从IO角度看,假如咱们经过MCS建立8个目录,每一个目录包含100台虚拟机。全部虚拟机的读取都是基于作快照的完整副本,800台虚拟机经过单一VMDK/ VHD进行读取文件,而后全部的写操做留在本地的差别磁盘。Nutanix有一个技术是专门针对Citrix MCS的连接克隆,称之为影子克隆技术。它利用数据局部性解决有MCS的Master Image的克隆和更新问题。