虚拟机快照是保留和恢复虚拟机配置非常有效的方法之一。但同时也需要更好地管理来避免性能问题。在本文中,我们将讨论几个高级用户快照管理技巧(对于快照基础和VMware快照工作原理的部分,参考我的上一篇文章)。 磁盘空间和删除多个快照 为VMware VMFS卷提前规划足够的磁盘空间以满足快照文件的需求很重要。
可借鉴的经验是至少保留该虚拟机总磁盘大小20%的空间用于快照。但是这个数量很大程度上依赖于服务器的类型、快照保存的时间、以及是否计划使用多个快照等因素。如果您计划通过快照保护内存数据,那么需要至少保留跟分配给该虚拟机的内存大小相当的额外磁盘空间。 拥有不止一个快照的虚拟机在删除或提……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
![TechTarget微信公众号二维码](/wp-content/uploads/res/images/spriteimg/ttweixin.jpg)
TechTarget
官方微博
![TechTarget中国官方微博二维码](/wp-content/uploads/res/images/spriteimg/ttweibo.jpg)
TechTarget中国
虚拟机快照是保留和恢复虚拟机配置非常有效的方法之一。但同时也需要更好地管理来避免性能问题。在本文中,我们将讨论几个高级用户快照管理技巧(对于快照基础和VMware快照工作原理的部分,参考我的上一篇文章)。
磁盘空间和删除多个快照
为VMware VMFS卷提前规划足够的磁盘空间以满足快照文件的需求很重要。可借鉴的经验是至少保留该虚拟机总磁盘大小20%的空间用于快照。但是这个数量很大程度上依赖于服务器的类型、快照保存的时间、以及是否计划使用多个快照等因素。如果您计划通过快照保护内存数据,那么需要至少保留跟分配给该虚拟机的内存大小相当的额外磁盘空间。
拥有不止一个快照的虚拟机在删除或提交(这里用提交的说法是因为快照的delta文件中保留的变化量数据在删除时会合并到原始虚拟磁盘文件,或称为VMDK中。)快照时需要额外空间。同时在删除快照时会创建一个helper delta文件。其中记录了在快照删除过程中对虚拟机磁盘做的所有改变。Helper delta文件根据快照删除所需的时间不同,大小有所差异。不过它不会很大,因为多数快照在一个小时内都可以删除掉。
根据vSphere版本的不同,在有多个快照的情况下,根据快照合并到原始磁盘文件的方式不同,删除快照需要相应的额外磁盘空间支持。
删除多个快照的过程在不同的vSphere版本中有所变化。在老版本的vSphere 4.0和VMware Infrastructure 3(VI3)中,假设虚拟机有三个快照需要删除,过程如下:快照3被拷贝到快照2,然后被拷贝到快照1。接下来,快照1被拷贝到原始磁盘文件,helper快照同时也被拷贝到原始文件中,如下图所示。
该过程需要额外的空间,因为每个快照在前一快照合并过来时都会变大。如果在数据存储盘上没有足够的剩余空间,快照将无法提交。
在之后的vSphere 4.0和vSphere 4.1版本中,每个快照都直接合并到原始磁盘文件,而不是到前一时间点快照。图2演示了一台拥有三个快照的虚拟机在删除快照时发生的过程。
由于每个快照都是直接合并到原始磁盘文件的,除了helper文件外,不需要额外的空间支持。
如果您使用的是老版本的vSphere 或VI 3,还有一种删除快照的方式可以减少删除快照时的额外空间需求,那就是逐个删除快照,首先从快照树位于最远端的快照删起。这种方式下,快照在合并到前一时间点空间需求会变大,然后按顺序进行删除。虽然有点麻烦,不过这种方法对额外空间的需求小。
重要提示:不要在虚拟机拥有活动快照的时候进行磁盘碎片整理。碎片整理动作会更改很多的磁盘块,可能引起快照文件大小迅速增长。
快照删除所需的时间
在通过vSphere Client进行快照删除时,任务栏的状态可能会引起误解。通常,任务状态很快跳到95%完成,但是您将发现在95%状态会持续很长时间不变直到整个提交过程完成。vCenter Server对所有任务默认设定15分钟的超时(这是可以增加的)。这样的话,即使该快照还在合并中,vCenter Server可能会提示操作超时。
检查任务是否完成的方式之一是通过vSphere Client的Datastore Browser观察虚拟机的目录。当delta文件消失时,您可以知道该快照的删除完成了。在ESX和ESXi中通过命令行方式也可以监控到快照删除的过程。
活动快照如果创建的时间过长(文件将会变得非常的大),可能需要很长时间才能完成提交和删除。快照提交所需的时间取决于虚拟机的活动水平,如果虚拟机处于关机状态速度会快一些。宿主机的磁盘子系统可提供的活动资源也对快照提交所需时间造成影响。
100GB的快照文件将花费几个小时时间完成合并到原始磁盘的动作,这会影响虚拟机和宿主机性能。考虑到这点,您需要限制快照保留的时间,在不需要时立刻进行删除。
快照和元数据锁定对宿主机性能的影响
快照对宿主机性能会带来几个方面的负面影响。在第一次创建快照时,虚拟机活动需要短暂暂停,如果在创建快照时去ping虚拟机会观察到一些延时。同样,创建快照会导致元数据更新,从而引发SCSI预留冲突,会短暂锁定LUN。因此,LUN在某个短时间段内只对单个宿主机开放。
如果您创建了虚拟机的快照并运行虚拟机,快照就处于活动状态。如果快照是活动的,虚拟机的性能会下降,因为宿主机开始写入delta文件而不是标准VMDK文件,效率会差一些。而且,当delta文件每增长到16MB大小时(在这一系列的第一部分讨论过),将会再次引起元数据锁定。这会对虚拟机和宿主机产生影响。对性能的影响程度取决于虚拟机和宿主机的繁忙程度。在本系列的第三篇中我将深入探讨VMware快照的故障诊断来避免发生性能问题。
最后,删除/提交快照也会引起元数据锁定。另外,在删除快照提交delta文件的时候,也会极大降低虚拟机的性能。如果虚拟机繁忙,影响会很明显。为避免这个问题,删除大的或多个快照的动作最好在非高峰时间或者是宿主机不忙碌的时候进行。
永远不要在快照运行时扩展磁盘文件
您永远不要在有活动快照的情况下扩展虚拟磁盘。通过vmkfstools—X命令或vSphere Client可以扩展磁盘。在VI3中,如果使用VI Client对磁盘做扩展,会显示任务成功完成。但是实际上不会真的扩展磁盘文件。如果在VI3中,有活动快照的时候,通过vmkfstools做了虚拟磁盘扩展,虚拟机将无法启动,您会收到错误信息:不能打开.vmdk文件或某个快照所在的磁盘。原因:在子磁盘创建后父虚拟磁盘被调整。幸运地是,这种情况还可以恢复。
在vSphere中,在快照运行时是不能扩展虚拟机虚拟磁盘的,如果您运行vmkfstools命令,会收到错误报告:无法扩展磁盘。锁定文件失败。在vSphere Client中如果在快照运行时编辑虚拟机的设置,选中其中的一个虚拟磁盘,可以看到对磁盘的resize命令是灰色的。一旦快照删除,就可以对虚拟磁盘大小做调整。
如果虚拟机使用RDM(Raw Device Mapping)磁盘格式,磁盘(LUN)的大小是由物理存储系统管理的而不是vSphere。这样的话,您可以在不涉及vSphere的情况下更改LUN大小,理论上即使创建了活动快照,RDM磁盘的大小也是可以增加的。但是该动作会恶化RDM磁盘的状态,所以在调整RDM磁盘大小之前,也需要确保首先删除快照。
从快照保护中去除虚拟磁盘
如果您的虚拟机跨多个磁盘,而您希望可以在快照中不包含某个磁盘,可以通过编辑虚拟机的设置来更改磁盘模式到Independent(确保选定了Persistent)。独立磁盘模式的设置可以帮助用户实现分别管理每个磁盘的功能,在磁盘文件或架构上没有差别。一旦磁盘设为独立模式,将不会包含在任何快照中。
另外,如果虚拟机设置了独立磁盘将无法进行内存快照。这么做是为了防止用户在对某个带有内存快照的快照进行恢复时,如果有正在运行的应用恰好需要向独立磁盘写入数据,这么做可以对独立磁盘进行保护。因为在其它磁盘恢复时,独立磁盘是不进行的,这会引发潜在的数据失效。
对于拥有RDM磁盘的虚拟机,如果RDM配置为物理兼容模式,将不会在虚拟机快照中包含。如果RDM设置为虚拟兼容模式,会自动包含在快照中。
在虚拟机运行时使用快照进行备份
快照提供了很好的在线虚拟机裸VMDK文件备份方法。所有对原始磁盘文件的写入操作都被禁止,因此可以安全地把它拷贝到其它的存储卷,从而供Veeam Backup & Replication 和Quest vRanger等备份应用在虚拟化层面上进行保护操作。他们可以对虚拟机做快照、备份磁盘文件然后在完成后删除快照。
还有一些免费的用户脚本和工具可以提供类似功能。这些程序可以让用户把VMDK文件拷贝到本地存储或网络共享设备,提供对重要虚拟机的额外保护途径。
作者
相关推荐
-
2015年 不可不知的五大热点话题
在过去的一年当中,从容器技术变革到针对常见虚拟机问题的全新解决方案,服务器虚拟化市场延续了火热态势。
-
正确使用VMware虚拟机快照的方式
虚拟机快照技术是VMware乃至任何虚拟化平台最为重要的组件之一。如果使用得当,其将会是一种理想的即时镜像工具。
-
虚拟机做快照的时候能在虚拟机里做操作么?做的操作会影响快照吗?
-
为什么需要巨大的虚拟磁盘文件?
老一代的IT人可能记得逻辑块寻址(LBA)出现在上世纪90年代早期,作为解决磁盘大小受限于504MB的一种方法。