本帖最后由 laoyu 于 2020-9-15 09:37 编辑
一、MCS概述
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（个人虚拟磁盘）（可选）：该磁盘存储我们想要永久保存的数据（超出本文的范围）。
具体如下图所示： 比如我们通过MCS模式创建了一组虚拟桌面，那么这组虚拟桌面在Studio中表现为一个计算机目录，在该计算机目录中，对应与服务器虚拟化底层的一个存储LUN，该LUN内存在一个Master Image。同时存在多个Differencing Disk和Identity Disk一起构成该计算机目录资源池。所有在该计算机目录中的虚拟机都同时读取Master Image上面的操作系统。然后再由写入时才会将各自的写IO缓存到各种虚拟机挂载的Differencing Disk中进行缓存。 而我们知道Citrix的MCS模式下存在着池静态和池动态之分，池静态就是在虚拟机重启之后，不对LUN内的虚拟机挂载的Differencing Disk进行删除，这样就可保存我们写入的缓存信息在我们虚拟机重新启动之后还存在。而池动态模式模式下，每次重启虚拟机都保证将虚拟机挂载的Differencing Disk删除掉，在虚拟机重新启动的时候，复制MasterImage磁盘的空间重新生成Differencing Disk并将其格式化之后挂载给虚拟机。这样的情形下我们上次写入的缓存信息是不会得到保留的。
二、MCS的不足
主要有两点： 1、占用空间过多 2、对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就不行了，这个时候桌面运行就显得很缓慢。
三、MCS的性能提升
解决方案： 1、占用空间大：精简置备 2、读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我认为还需要改进的地方
主要有两个： 1、MCS模式下，在LUN生成的虚拟机文件不能迁移？使用MCS虚拟机故障切换是没有问题的，即HA。但如果你想移动虚拟机磁盘/文件以及使用的Storage vMotion，比如使用存储实时迁移或存储的XenMotion，这就不支持了。这是因为虚拟机驻留在磁盘ID /数据存储（存储在中央站点数据库信息）之间存在很强的依赖性，一旦这个关联关系中断你的虚拟机将不能正常启动。 2、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好好弄弄还是有戏的。
五、软件定义存储如何解决MCS的上述挑战解读
如何使用Nutanix计算平台解决CitrixMCS的3个最大的挑战，综合我上述所言，其挑战主要如下：
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的克隆和更新问题。
| 
发表于 2020-9-15 09:34:46
