XenServer中VM的存储格式对空间以及性能的影响

在XenServer中,基本的存储库(SR)、物理块设备、虚拟磁盘映像、虚拟块设备之间的关系如下图:

其中,PBD为物理存储设备的抽象,基本无法改变,SR为XenServer对物理存储设备的抽象,起到组织管理的作用,SR的类型对虚机VDI的格式以及性能有一定的影响,但是SR的类型受限制于物理存储的形式,所以,暂停也跳过,VBD与VDI对应,而最终VM拿到的虚拟块设备VBD,则为VDI的虚拟,所以,SR中VDI的格式对存储空间消耗以及性能产生比较重要的影响。

基于不同的SR,一般情况下,VDI的物理保存方式有三种:

  • File-based VHD(基于文件的VHD):VM的image将会以精简置备(thin provisioning)的VHD格式保存在本地的EXT格式的SR或者共享的NFS的存储上。
  • LVM-based VHD(基于LVM逻辑卷的VHD):默认XenServer连接光纤(LVMoHBA)、iSCSI(LVMoISCSI)或者SAS(LVM0HBA)的本地存储,以及基于SAN附加的LUN,这些类型存储上的VDI,都是卷管理器中的卷,并以VHD格式保存,以支持快照和克隆引用节点的精简置备。
  • LUN per VHD(每个LUN作为一个VDI):这种类型主要指Netapp,Equallogic或者StorageLink提供的存储类型,这种方式由于会有特殊的插件提供支持,所以VDI会直接抽象为存储中的一个LUN,然后直接附加到VM。很明显,该种方式对存储性能的利用最好,而且能够更方便的管理存储,因为都是基于存储的管理功能,而不是XenServer本身的功能。
每种VHD类型,有每一种的特点,以及对存储空间的占用,存储的性能损耗都不一样:
首先说明一下,在XenServer中,模板生成虚机都是采用VDI连接的形式进行管理的。
由于每VDI使用一个LUN,这种形式,VHD的管理由存储控制器来管理,所以,其大小和性能由存储的管理方式来决定,所以这里就不准备详细讨论了,但相对于其他两种形式而言,每VDI一个LUN的形式,其性能最高。比如,存储支持Thin Provisioning,那么空间占用将会由实际大小决定,不管XenServer声明该VHD的大小是多少,如果不支持,那么声明多少,将占用多少。性能,由存储管理方式决定,比如,跨多少磁盘,RAID的级别等等。
下面,主要介绍基于LVM和文件的两种VHD对存储空间的占用大小以及管理方式。
如上图:假设,XenServer创建一VM,并分配20G大小的空间给VM,VM实际使用数据空间为10G,然后我们基于该VM复制两个出来,然后第一个VM,改变了5G的数据后,做快照,成为最终的VM1,而VM2虚机改变了2G的数据。
基于该假设,存储中,VDI的空间消耗如上图所示。
首先,基于LVM的VHD格式,最开始20G的VM,需要消耗20G空间,在转成模板以后,copy出VM1和VM2以后,原始VM空间将会压缩到实际大小10G,然后形成两个链接,供VM1和VM2使用,VM改变5GB大小以后,快照,则,快照只保存更改的数据5GB,新的VM1,将会占用20G空间,而VM2 copy出来也会占用20G空间。
而基于文件的VHD格式,很容易理解,再任何时候,VM以及快照的大小为实际改变大小。
基于VHD克隆或者copy的VM,每个子VM都会形成一个链,修改写入新的VDI,读取则从父模板读取,如果进一步,讲子VM在克隆,这样,链接将会越来越长,存储的性能也会越来越差。XenServer中,最大的链接长度为30,使用copy命令复制VM,讲会将链接长度重置为0.
VHD链的合并
VHD链接树会不断的创建、修改、删除。在删除链中的VDI时,XenServer会合理化链中的其他VDI,并删除非必要的VDI。合并过程为异步运行,且对于SR来说,永远只有一个合并过程处于活动状态,该过程由SR主节点主机的线程处理。
这里说明一点,VDI的删除,会导致VHD链的合并,但不是马上合并,该操作为异步执行,但最终会合并,而不是只删除链接节点名称保留直接链接。