规划部署虚拟桌面环境前,必须先估算目前所使用实体桌面环境的工作负载与IOPS性能,并慎选储存设备。唯有谨慎估算贴近实际的IOPS性能,才能有效避免日后部署时出现任何不必要的性能问题。
虚拟化议题已经日渐发酵,许多企业及组织已经从早期持观望态度转而引进内部测试环境,待确定虚拟化技术真的可行后,也纷纷将线上营运服务迁移到虚拟化环境当中。
事实上,虚拟化基础架构只是踏入云端的第一步,也就是为日后的应用环境将地基先打稳,以便硬件资源得以弹性扩充及充分利用。所以,将服务器完成虚拟化建设之后的下一步是什么呢?通常接着会将「桌面环境」也进行虚拟化。除了得以将使用者桌面环境整合统一集中管理外,对企业或组织来说,整体安全性的提升才是最直接的效益。
但是,桌面虚拟化与服务器虚拟化在规划上有很大的不同。以选择储存设备为例,虽然服务器虚拟化环境也需要考量储存设备的IOPS性能,但并不需要精准地计算到一分一毫(因为VM虚拟主机的数量相比之下较少)。
桌面虚拟化就不是这么回事,因为若没有考虑并计算好储存设备的IOPS性能,那么当使用者连上虚拟桌面环境后便会发现操作回应时间缓慢或使用不顺畅。
当使用者体验不佳时,就容易导致虚拟桌面方案导入失败,因此本文将与读者讨论在规划虚拟桌面环境时,对于选择储存设备应该注意哪些方面,以及该如何估算储存设备及使用者操作环境的IOPS性能数据,以求届时使用者能够顺畅地操作其虚拟桌面环境。
Q 1:如何估算Windows Disk I/O工作负载?
在虚拟桌面环境中,储存设备的性能非常重要,那么应该要如何概要估算每个Windows虚拟桌面环境的Disk I/O负载?现有的实体桌面主机应用环境为何?现有实体桌面主机的CPU/Memory规格为何?是否常常有磁盘I/O的操作?是否常常有网路带宽使用率高的情况?
针对以上的问题,首先要设计出适当的储存空间大小,这之前还需要了解「磁盘I/O(Disk Input and Output)」,以及使用者端操作系统Windows XP及Windows 7的特性,并且区分出「轻度(Light)」及「重度(Heavy)」使用者之间的差别。
所谓轻度使用者,通常就是利用桌面环境处理日常工作所需,例如E-Mail(如Outlook、Notes)、Office(如Word和Excel)、Web Browser等等,简单来说,就是一般文书处理的工作。
而重度使用者除了以上所述的一般文书处理工作外,还要同时处理大型简报数据、美术图档、3D图档等等工作。
在一般情况下,使用者在大部分90%的工作负载都会是磁盘I/O的「读取(Read)」(当然仍有例外)。
举例来说,NTFS文件系统一般数据分配大小为4KB(Allocation Size)以及64KB(Block Size)的数据块大小,而Windows 7操作系统数据读写作业,一般使用1MB的数据块大小进行,因此以表1中重度使用者的磁盘读写I/O值为7MB/Sec,并且以64KB数据块大小来计算运行20台Windows 7操作系统的虚拟桌面环境大约需要112 IOPS。
表1 轻度使用者与重度使用者比较
若是非一般环境的重度使用者,则通常会预估数据读取部分为40%,而数据写入部分为60%来进行估算(表2),甚至在某些极重度使用者的环境中,数据写入部分可能高达80%或90%。
表2 重度使用者数据读取与写入比例
如果觉得这样的统计数据太过两极化,那么可以将使用者环境等级再区分得更细致一点,例如有些虚拟桌面可能配置了1颗虚拟处理器(1 vCPU)与1GB的虚拟内存,因此只要执行些许的应用程序便可以完成日常工作所需。但有些使用者可能就需要更多的虚拟资源,如2颗虚拟CPU及3GB的虚拟内存,才得以完成工作。
那么该怎么预估这些虚拟桌面环境届时会使用到多少IOPS储存性能呢?表3依据各类使用者环境配置,提供IOPS预估,可作为参考。
表3 各类使用者环境配置分析
Q 2:如何规划Windows XP/7的虚拟资源?
目前使用者桌面环境最常使用的操作系统是Windows XP和Windows 7,虽然Windows XP操作系统即将在2014年4月8日终止支持,但是依然有许多企业或组织的应用程序运作在此操作系统环境中,因此虚拟桌面环境中仍有可能使用此操作系统。
表4 Windows XP/7虚拟资源分配
在虚拟桌面环境的规划上,由于Windows XP 64位版本并不普及,因此在如表4所示的虚拟资源表格中并不会考虑该版本,而Windows 7操作系统部分则分为32位及64位。在Windows 7 32位版本中,因为会有内存支持上限的问题,所以一般在规划上最多不会分配超过3GB的内存(在实体机上Windows 7的32位版本约可抓到3.25 GB内存,但虚拟环境中只会抓到3GB内存)。
Q 3:如何估算储存设备的IOPS性能数值?
储存设备在虚拟桌面环境中担任非常重要的角色,所以在选购储存设备时必须了解所选择的储存设备(NAS或SAN)之数据读写性能如何,也就是IOPS(I/O operations Per Second)数值,硬盘的IOPS计算公式如下(图2):
▲ 图2 硬盘IOPS计算公式。
但是,在选择储存设备时往往常常会令人陷入两难的局面,也就是如何在「性能(Performance)及容量(Capacity)」间进行取舍?
举例来说,7,200 RPM SATA3(Serial ATA)的主流硬盘在容量上已经可达到304TB空间大小,并且售价通常也令人感到满意,但在性能表现方面,即IOPS数值,则大约落在75左右。而15,000 RPM SAS(Serial Attached SCSI)主流硬盘容量为3000900GB,虽然采购费用是SATA硬盘的好几倍,并且空间也小很多,但是其IOPS性能数值大约可达175左右。
如果采用的是SSD(Solid-State Disk)固态硬盘,它并不像传统硬盘需要磁盘、读写头等等零件,并使用Flash Memory如EEPROM(Electronically Erasable Programmable Read Only Memory)进行数据的读写,其中又可区分为SLC Flash(Single Level Cell)和MLC Flash(Multi Level Cell)两种等级,SLC Flash储存One Bit到每个Cell内,MLC Flash则储存Multiple Bits于每个Cell中。所以,SLC Flash相较于MLC Flash大约多出「10倍」的数据写入能力(当然价格也贵上许多)。
有此可见,选择储存设备时,如何在性能与容量之间取得平衡点相当重要。表5为目前市面上常见的硬盘其IOPS性能表现。
表5 市面上常见的硬盘种类及其IOPS性能表现
除了硬盘的类型及转速影响IOPS性能数值外,还有磁盘阵列(Redundant Array of Independent Disks,RAID)的「处罚(Penalty)」和「快取(Cache)」部分需要考量,因为不同类型的磁盘阵列RAID模式,会影响到整体IOPS性能数值。举例来说,建立RAID-5、RAID-6磁盘阵列类型时,因为要进行「奇偶校验(Parity Checking)」,所以虽然整体容量空间损失较少,但所带来的影响则是在IOPS Write I/O Penalty部分较多,如表6所示。
表6 各种磁盘阵列IOPS Write I/O Penalty比较
在大致了解硬盘种类及转速所带来的IOPS性能数值,以及选择RAID磁盘阵列类型所带来的数据写入性能处罚之后,就可以估算出选择储存设备后所能得到的IOPS性能数值(图3)。
▲ 图3 储存设备IOPS性能数值估算公式。
如果有「一台」VM虚拟主机的工作负载为25 IOPS,并且数据的读取及写入比例为40/60,而储存设备的RAID磁盘阵列采用RAID-5,那么即表示后端的储存设备要负载这样的一台VM虚拟主机时,必须具备「(25×0.4 + ((25×0.6)×4) = 70 IOPS」才行。
同样的条件下,如果届时这台储存设备所要负载的VM虚拟主机是「500台」,那么后端的储存设备必须具备「(( 12,500×0.4) + ((12,500×0.6)×4)) = 35,000 IOPS」才行。
Q 4:储存设备该采用哪种传输协定?
目前在虚拟化环境中皆支持储存设备采用FCP(Fiber Channel Protocol)、FCoE(Fiber Channel Protocol over Ethernet)、iSCSI(Internet Small Computer System Interface)等储存区域网路(Storage Area Network,SAN)环境,以及采用NFS(Network File System)的网路连接储存(Network Attached Storage,NAS)环境。
SAN(FC、FCoE、iSCSI)储存区域网路技术为采用Block-Level协定的Raw Storage类型,从ESX 2.0版本开始便支持FC协定,对Hypervisor来说,它就像使用本机硬盘一样,其分享的储存空间将由ESXi主机将所挂载的LUN空间格式化为VMFS文件系统,且VM虚拟主机的硬盘格式可以支持Thick(Lazy、Eager),但必须注意最多只能有32台ESXi Host同时存取的限制。除此之外,Hypervisor虽然也支持RDM(Raw Disk Mapping)机制,但若使用于虚拟桌面环境的话,Windows XP/7并不支持此机制。
同时,现在许多应用都采用iSCSI储存设备,若连接iSCSI储存设备时采用软件(也就是使用一般网卡),则会增加ESXi主机的CPU负载,当然也可以使用Jumbo Frame机制来提高iSCSI的传输效率,ESXi主机支持的Frame Size为9,000 Bytes。
NAS(NFS)为File-Level协定,从ESX 3.0版本便开始支持NFS传输机制,因为NFS已经采用储存设备本身或网路服务的文件系统(例如Ext4、ZFS等等),所以对Hypervisor而言则不会将分享资源进行格式化,同样有着最多只支持32台ESXi Host同时存取的限制,并且NFS同样为软件驱动(Software Driven)的方式进行存取,因此也会增加ESXi主机CPU负载。最后值得注意的是,若采用NFS,VM虚拟主机将只支持Thin磁盘格式。
表7整理了FCP、FCoE、iSCSI、NFS等各种储存传输协定在采用10Gbps网路环境时,理论上可达到的传输速度及IOPS性能。
表7 各类传输协定之传输速度和IOPS性能比较
Q 5:如何选择虚拟桌面的复制方式?
在虚拟桌面的环境中,当要执行部署作业之前,必须要决定采用何种大量部署方式,例如完整复制(Full Virtual Machine Clones)、连结复制(Linked Virtual Machine Clones)、磁盘阵列复制(Array- Based Virtual Machine Clones)、VCAI复制(VCAI Virtual Machine Clones)等。
而这些复制方式又分别有什么优缺点?以下就来详细说明。
完整复制(Full Virtual Machine Clones)
「完整复制」是由vSphere发起的Full-Clone操作,通常这种复制方式都搭配使用专用虚拟桌面(Dedicated Desktop)时使用,也就是每个虚拟桌面环境都有专属的使用者,而每次连结都到同一个虚拟桌面环境,如图4所示。
▲图4 完整复制(Full Virtual Machine Clones)运作模式。
但此机制的缺点是Master Image若是60GB,那么复制出来的VM虚拟主机同样也是60GB。
连结复制(Linked Virtual Machine Clones)
「连结复制」则是采用View Composer机制,它会为每个VM虚拟主机建立「唯一指标(Unique Pointers)」,因此每台VM虚拟主机所占用的空间只有「差异」的部分而已,如图5所示。与Master Image占用空间相较之下,通常可以减少50070%的空间大小。
▲图5 连结复制(Linked Virtual Machine Clones)运作模式。
磁盘阵列复制(Array-Based Virtual Machine Clones)
简单来说,「磁盘阵列复制」不使用vSphere完整复制机制,而改为采用Block-Based Array Cloning机制,也就是储存设备针对Master Image所使用的「数据块Block」进行完整复制,如图6所示。
▲图6 磁盘
阵列复制(Array-Based Virtual Machine Clones)运作模式。
VCAI复制(VCAI Virtual Machine Clones)
如果所使用的NAS储存设备支持VAAI(vSphere API for Array Integration)机制,那么当View Composer在准备进行复制部署作业时,便会透过VCAI(View Composer Array Integration)机制以高效率模式执行,如图7所示。
▲图7 VCAI复制(VCAI Virtual Machine Clones)运作模式。 (图片来源: VMware White Paper – Storage Considerations for VMware Horizon View 5.2)
但是,VCAI机制仍处于技术预览(Tech Preview)阶段,并且仅支持采用NFS储存传输协定,所以可能不适合目前的部署环境需求。
Q 6:如何计算虚拟桌面占用空间?
在部署虚拟桌面之前,除了确认采用何种复制方式之外,还必须要计算每个虚拟桌面所会占用的空间大小,以便在选择储存设备时能够达到性能及容量之间的平衡点。
如图8~9所示,虚拟桌面的占用空间除了原本的操作系统数据外,还有Virtual Machine Swap数据(.vswp)会占用空间,这个数据是虚拟桌面「开机(Power On)」时才会产生,假设会与VM虚拟主机的内存一样大小,所以若VM虚拟主机的内存为4GB,则这个数据大小也会是4GB,除非已经为VM虚拟主机设定了「保留(Reservation)」机制。
▲图8 完整复制(Full Clone)模式虚拟桌面占用空间。
▲图9 连结复制(Linked Clone)模式虚拟桌面占用空间。
例如,将VM虚拟主机设定为3GB的虚拟内存保留,那么Virtual Machine Swap数据就只会占用1GB,除此之外,还要保留一些额外开销(Overhead)。
当使用者在操作虚拟桌面时还会需要使用者设定档(User Profile)、应用程序数据(Application Data)、我的文件(My Documents)等等数据,也就是使用者数据(User Data)以及企业数据(Corp Data),所以还必须加上这些占用空间才对,如图10所示。
▲ 图10 完整/连结复制模式虚拟桌面占用空间估算。 (图片来源: VMware White Paper – Storage Considerations for VMware Horizon View 5.2)
Q 7:如何回收虚拟桌面占用空间?
为了储存设备的容量考量,通常会使用连结复制(Linked Clone)方式来节省磁盘空间,但是随着使用者建立新数据又删除不必要的旧数据,这些曾经被占用的空间在早期是无法「自动回收」,现在则可以透过SE Sparse(Space-Efficient Sparse Virtual Disks)机制自动回收没有被使用到的数据块,此空间自动回收机制是采用「Wipe→Shrink」的方式达成,如图11所示。
▲图11 Space-Efficient Sparse Virtual Disks机制运作原理。
总结
透过本文的说明,读者应该已经了解在计画部署虚拟桌面环境之前,应该要先估算使用者目前使用之实体桌面环境的工作负载和IOPS性能,然后,在储存设备的选购上,除了采用的硬盘种类将影响IOPS性能外,采用的RAID磁盘阵列模式和储存传输协定影响也很大。
储存设备预估太大,会造成资源浪费、采购预算过高,预估不足则造成IOPS性能不够应付虚拟桌面使用,让使用者操作体验不良。唯有尽量贴近实务的IOPS性能估算,才能有效避免日后真正部署时发生任何性能问题。
本文由小编翻译并编辑,转载请注明
原文作者:王偉任