比思論壇
標題:
VMware Snapshot 工作原理
[打印本頁]
作者:
妖刀路过
時間:
2020-12-24 09:02
標題:
VMware Snapshot 工作原理
VMware
中的快照是对
VMDK
在某个
时间
点的
“
拷贝
”
,这个
“
拷贝
”
并不是对
VMDK
文件的复制,而是保持磁盘文件和
系统
内存在该时间点的状态,以便在出现故障后虚拟机能够恢复到该时间点。如果对某个虚拟机创建了多个快照,那么就可以有多个可恢复的时间点。
当我们为虚拟机创建的快照时,当前可写的
VMDK
文件变成为只读状态,并且创建一个新文件(称之为快照文件)来保存变化的内容(使用
in-file deltatechnology
)
。
在初始状态下,快照文件的大小为
16MB
,并随着虚拟机对磁盘文件的写操作而增长。快照文件按照
16MB
的大小进行增长以减少
SCSI reservation
冲突。当虚拟机需要修改原来的磁盘文件的
数据
块时,这些修改会被保存到快照文件中。当在快照文件中的已经修改过的数据块需要被再次修改时,这些修改将覆盖快照文件中的数据块,此时,快照文件大小不会改变。因此,快照文件的大小永远不会超过原来的
VMDK
文件的大小。
快照文件的变化频率取决于虚拟机应用的写的繁忙程度,例如对于
Exchange
和
SQL
等应用,快照文件变化比较快。多个快照的情况下,在创建新的快照时,之前的快照文件变成只读的状态。
不同类型的快照文件
*-delta.vmdk
文件:该文件就是前面我们所提到的快照文件,也可以理解为
redo-log
文件。在每创建一个快照时就会产生一个这样的文件。而在删除快照或回复到快照时间点状态时该文件会被删除。
*.vmsd
文件:该文件用于保存快照的
metadata
和其它信息。这是一个文本文件,保存了如快照显示名、
UID(Unique Identifier)
以及磁盘文件名等。在创建快照之前,它的大小是
0
字节。
*.vmsn
文件:这是快照状态文件,用于保存创建快照时虚拟机的状态。这个文件的大小取决于创建快照时是否选择保存内存的状态。如果选择的话,那么这个文件会比分配给这个虚拟机的内存大小还要大几兆。
创建快照
快照的创建可以通过
VMware VI
客户端的
Snapshot
Manager
来实现,或者通过
ESX
服务器
的
ServiceConsole
的命令行
vmware-cmd
来实现。无论虚拟机是在运行、关机还是挂起的状态,都可以创建快照。
Snapshot
可以通过
VI
客户端直接连接到
ESX
Server
或者连接到
VirtualCenter
来管理。
删除快照或者回滚到快照点状态
当删除虚拟机的所有快照时,针对该虚拟机所创建的所有
delta
文件中的内容将会合并到原来的
vmdk
文件中,合并完成后再删除
vmdk
文件。如果只选择删除一个快照,那么这个快照的
delta
文件将和其父快照的
delta
文件进行合并。如果选择回滚到某一个快照,那么当前的磁盘和内存状态将会被丢弃,而且虚拟机会转变到
revert-to
的状态。无论选择哪个快照进行回滚,该快照都会变成当前的父快照,就是说当前运行的虚拟机会在这个快照之下。因此,父快照不一定是最近所创建的快照(在没有回滚的情况下,父快照一般都是最近所创建的快照)。在
Snapshot Manager
中父快照之下一般有
“You are here”
的标记。
如果选择回滚的快照不包含内存状态,那么该虚拟机将会被关机,在管理员启动该虚拟机时应用所选择的快照。如果包含内存状态的话,那么虚拟机会短暂的停顿一下,然后回复到快照时的磁盘和内存状态。
磁盘空间和删除多个快照
在创建快照前,所有的写操作都写入磁盘文件。但是有了快照之后,磁盘文件保持不变,而写操作写入
delta
文件,同时,如果保存内存状态的话,
vmsn
文件还要占用比该虚拟机稍大一些的空间。
在只有一个快照时,在删除快照时不需要额外的空间。因为要么直接删除快照文件,要么把快照文件和
VMDK
磁盘文件相合并。但是在有多个快照的情况时,效果就不一样了。
假设要删除一个虚拟机的所有快照,该虚拟机有三个快照,
snap1
、
snap2
和
snap3
。首先,
snap3
的快照文件要被合并到
snap2
的快照文件中,导致
snap2
占用空间增加。然后,
snap2
被合并到
snap1
中,导致
snap1
占用的空间增加。最后,
snap1
合并到
VMDK
文件中,此时不会增加空间开销。在合并完成后,快照才会被删除。
一种替代的方式是依次删除快照,这样就不会增加所需要的空间,只是稍微繁琐一些。
删除快照所需要的时间
通过
VI
客户端删除快照时,
VI
的状态栏中显示的信息可能会产生误导。通常,状态栏会很快到达
95%
完成的状态,但是会在
95%
的状态等待较长的时间一直到合并完成。
VirtualCenter
对所有的任务都有
15
分钟的超时值,即使后台还在合并,但是过了
15
分钟后,
VirtualCenter
会报告该操作超时。
一种查看该任务是否完成的方式是通过
VI
客户端来浏览该虚拟机的
datastore
。如果该快照对应的
delta
文件不存在了,则说明该快照被删除了。
如果快照存在的时间比较长,那么快照文件就会变得比较大,因此在删除快照时就需要比较长的时间进行合并。合并的时间取决于虚拟机的繁忙程度,在关机的状态下合并的速度较快。而
ESX
服务器后端的磁盘子系统的繁忙程度也会影响合并的时间。
一个
100GB
的快照文件可能需要
3-6
个小时来合并到原来的
VMDK
文件中。而从
ESX3.5
开始,由于
VMware
修改了合并的算法,可能需要更长的时间来合并(参见
VMware
文档
Consolidationof large or deeply nested snapshots
)。这会影响虚拟机和
ESX
服务器的性能。因此,建议限制快照的保留时间,当不需要时即刻删除快照。
快照和
metadata
锁对
ESX
性能的影响
快照对
ESX
服务器以及虚拟机的性能影响体现在几个方面。但创建快照时,虚拟机的活动会暂时停顿一下,此时如果通过
ping
命令去检查虚拟机的状态,可以看到一些
timeout
的
response
。此外,创建快照会导致
metadata
的更新,为了避免
SCSI Reservations
冲突会短时间内对
LUN
加锁,从而导致在短暂的时间内,这个
LUN
将只能由一个
ESX
服务器进行排他性访问。
如果为虚拟机创建了快照,虚拟机在运行的状态中,该快照是活跃的。只要快照是活跃的,那么虚拟机的性能就会下降。因为
ESX
服务器对
delta
文件的写入方式不同于
VMDK
文件,而且效率相对较低。
delta
文件每次以
16MB
的大小来增长,它会导致另一种
metadata
锁。
最后,删除或者回滚快照都会创建一个
metadata
锁。此外,删除快照时可能会导致性能比较大的下降,虚拟机越忙越明显。为了避免这个问题,快照的删除最好在非高峰时期。
歡迎光臨 比思論壇 (http://108.170.5.77/)
Powered by Discuz! X2.5