聊聊VDI虚拟桌面的重复SID问题(上)
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了聊聊VDI虚拟桌面的重复SID问题(上)相关的知识,希望对你有一定的参考价值。
? SID是个很久远的东西了,最早去了解这个东西,还是第一次尝试迁移Windows NT 4的域到Windows 2000…开始是知道SID相同加域会报错,后来迁移项目做多了,也就熟悉了SID History…然后是在SCCM/OSD的时候了解Client ID…后来,我给微软发布Windows 2012做全国TTT的时候,开始深入 VDI,再后来,莫名其妙就做了Citrix和VMware的VDI……
? 扯的有点远了……写段简历,其实是为了后面分不同角度来讨论SID在今天的环境中关联的一些问题。之所以把SID和VDI两件事情扯到一起,是因为长期以来对于VDI都会有挺多的有意思的细节,当然也因为我经常和伙伴及客户所强调的,VDI的出现,改变了 整个PC桌面管理的方式。所以接下来会讨论一点技术细节,同时也尝试讨论带来技术细节所带来的背景和方向。
为什么主流VDI的制备方式默认都不使用Sysprep了?
? 所谓天下大势,分久必合,合久必分,从主机时代走来的PC,带来的是计算的革命。从集中到分散,坐在数据中心维护机器变成了到处帮用户装机器…因而出现了一大批“终端管理”的解决方案,例如AD/GPO,SCCM,Landesk…而到了“近现代”,由于移动互联网的兴起,终端更加的离散,更多的终端节点意味着更多数据失控的可能,所以基于远程访问的VDI突然就站到风口了。
? 如VDI的全称Virtual Desktop Infrastructure所昭示的,VDI是基于Windows虚拟机、通过远程协议访问虚拟机中的Agent,实现“数据不落地”的桌面使用的架构。由于操作系统和应用程序以及核心的数据不再位于终端上,而是运行在数据中心,因此带来了安全边界的收缩以实现更高的安全性。正是这样的架构,决定了桌面从以前的分散管理,又变成了集中管理的模式。可以说,从根本上也解决了PCLM类终端管理无法保证覆盖全部终端,维持100%全面配置基线、安全基线的问题。
? 因此,VDI的桌面天生就是集中化的管理模式。那么问题就来了,我们应该“安装”或完整克隆一堆的VM当成PC来管理,还是应该通过标准化的制备方式快速获得呢?
? 从VDI本身的意义来说,一方面实现了小而完整的安全边界,另一方面就是通过虚拟化、云化实现了资源的动态调度,从而提高硬件利用率。实际上由于很多场景下考虑到用户并发上线使用数量,按照接近峰值的资源计算VDI硬件,再加上服务器硬件组件的可靠性及使用强度和寿命的因素,并不会比现在越来越便宜的PC便宜多少。如果再使用传统PC的管理模式管理,将会使得原本分散的终端管理问题集中起来并且显得更加尖锐。因此,除非不得已,以我多年的经验,是强烈不建议使用全克隆方式制备出一堆虚拟机,用以往的PC管理方式进行管理的。上VDI项目之前,就应该考虑是否对PC管理进行标准化,并对支持的PC配置标准进行合并裁撤。只有这样,才能够通过VDI项目收获最大的管理效益。至此,前面提出的问题的答案也就呼之欲出了,除非满足特定需求,我们应该尽可能通过标准化来实现对虚拟桌面的批量制备。
? 如果您是一位曾经部署过大量桌面的工程师,或者曾经将通过ghost类似软件复制的桌面加入到AD域中,肯定会知道,如果一个桌面的SID和其他桌面相同,加域要么不成功,要么会出现一些奇奇怪怪的问题。所以,有经验的管理员,会使用微软的一个自带的工具,Sysprep来重新为计算机生成新的SID。这个工具是微软官方认可的,解决SID重复当然没有问题。可是放在VDI场景里,问题就来了——Sysprep需要完成后,系统进行一次重新启动方才全面生效。而当我们启动“复制”标准虚拟机镜像的时候,是不希望每个最终用户花费几分钟去完成大家熟悉的、Windows第一次启动时需要好几分钟的那个初始化过程的。更别说,不保留系统变更的“无状态”虚拟桌面“每一次”进入虚拟桌面都要完成这个过程……
? 所以,除了保留系统更改的“有状态”桌面,目前已经很少在VDI部署中看到使用Sysprep进行SID重置初始化的做法了。
VDI架构真的都不生成或更新SID了吗?
? 关于这一点,我们可以找到如下的KB文章或者材料进行确认。首先看看VMware的官方知识库文章:
? Differences between VMware ClonePrep, QuickPrep and Microsoft Sysprep (2003797)
? 在这篇KB中,主要针对不同的VDI桌面预备方式,介绍了不同的系统准备方式(Sysprep、QuickPrep、ClonePrep)。对于全克隆桌面,比较推荐使用Sysprep;而链接克隆桌面,可以视需要选择QuickPrep或者Sysprep;对于即时克隆,则建议使用ClonePrep为制备大量桌面进行准备。为了便于理解这几个比较陌生的词,我们对批量制备桌面最为关键的一些要求进行比较:
功能 | ClonePrep | QuickPrep | Sysprep |
---|---|---|---|
修改计算机名 | Yes | Yes | Yes |
使用新实例加域 | Yes | Yes | Yes |
变更安全标识 (SID) | No | No | Yes |
生成新安全标识 SID | No | No | Yes |
重启次数 | 0 | 0 | 1 |
? 在这个表格里,我们关心的几个功能都有直接的对比。首先大量制备桌面虚拟机时,肯定都要给每个虚拟机进行命名,并且加入到AD活动目录域中,便于集中管理和提供全局登录。表中可以看到这个要求三种预备方式都能够支持。那么那些功能对于三种预备方式是有区别的呢?主要在于是否变更SID/生成新的SID以及需要重启的次数。如表格所示,Sysprep能够”严格“按照微软要求,为每一个桌面生成新的SID,但是无法避免需要进行一次额外的重启,因此在很多时候我们会选择非Sysprep的方式来预备桌面。
? 除了制备阶段,在这篇KB中其实还介绍了整个桌面虚拟机生命周期中不同阶段对SID的处理方式。对于 链接克隆方式,实际上可以同时支持标准的Sysprep和快速的QuickPrep:
Creation | Refresh | Recompose | Rebalance | |
---|---|---|---|---|
Sysprep | New SIDs are generated for the Desktops | SIDs are preserved | New SIDs are generated for the Desktops | New SIDs are generated for the Desktops |
QuickPrep | Master Image‘s SID are used for the Desktops | SIDs are preserved | SIDs are preserved unlessMaster Image is changed | SIDs are preserved unless Master Image is changed |
? 随着产品发展,链接克隆将逐步退出历史舞台,在新的Horizon版本中,即时克隆已经下沉到更低版本,成为批量制备的优先选择。即时克隆与链接克隆机制上有所区别,因此其虚机的生命周期环节也稍有不同:
Creation | Push Image | On User Logout | |
---|---|---|---|
ClonePrep | Master Image‘s SID are used for the Desktops | SIDs are preserved unless Master Image is changed | SIDs are preserved unless Master Image is changed |
? 从以上两种不同的预备方式,都能够看到,实际批量制备桌面时,并没有生成新的SID,跟我们所熟悉 的“每一个加域的计算机都需要使用不同的的SID”的认知貌似有所不同。
? 实际上,不仅VMware是这样处理虚拟机的,Citrix也是这样处理的。可以参考Citrix的官方支持文章:
? MCS Provisioned VMs Share an Identical Machine SID (CTX226711)
? 我没有找到关于PVS制备方式对SID处理的官方KB,但是以我对PVS制备方式的了解以及社区文章的描述,PVS也是不会生成和更新桌面虚拟机的SID的。而这篇描述MCS制备方式的KB对与SID问题的描述非常简单:重复的SID不是个问题……不信你去看微软的介绍……
? 而微软自己其实从Windows Server 2008开始也提供了基于RDS架构的VDI,可是我并没有找到有关制备时SID的处理的介绍……
? Recommended settings for VDI desktops
? 到底VDI中使用重复SID是不是问题呢?下一篇我们用微软的文章来说明。
以上是关于聊聊VDI虚拟桌面的重复SID问题(上)的主要内容,如果未能解决你的问题,请参考以下文章