Shulou(Shulou.com)05/31 Report--

This article introduces you how to carry on the VMware virtual machine snapshot in-depth analysis, the content is very detailed, interested friends can refer to, hope to be helpful to you.

What is a snapshot?

Snapshots save the state and data of the virtual machine at a specific time.

"status includes the power status of the virtual machine (for example, power on, power off, suspend)."

The data includes all the files that make up the virtual machine. This includes disks, memory, and other devices (such as virtual network interface cards).

Virtual machines provide several operations for creating and managing snapshots and snapshot chains. With these operations, we can create snapshots, restore to any snapshot in the chain, and remove snapshots.

II. Snapshot files

Snapshots consist of files stored on supported storage devices. The perform Snapshot operation creates .vmdk,-delta.vmdk, .vmsd, and .vmsn files. By default, the first and all incremental disks are stored with the base .vmdk file. The .vmsd and .vmsn files are stored in the virtual machine directory.

Incremental disk file: a .vmdk file that can be written by the client operating system. An incremental disk represents the difference between the current state of the virtual disk and the last time the snapshot was performed. When you perform a snapshot, the condition of the virtual disk is preserved, preventing client operating system from writing, and an incremental disk or subdisk is created.

An incremental disk has two files, a smaller descriptor file that contains information about the virtual disk, such as geometry and parent-child relationship information, and a corresponding file that contains raw data.

Note: if you want to use the data Store browser in vSphere Client to view the data store, you will see only one entry representing these two files.

The files that make up the incremental disk are called subdisks or redo logs. The subdisk is sparse. Sparse disks use the replication-on-write mechanism, where the virtual disk does not contain any data until the data is copied to the disk by a write operation. This optimization saves storage space. Granularity is the unit of measurement in which sparse disks use the replication mechanism on write. Each granularity is a sector block that contains virtual disk data. The default size is 128 sectors or 64 KB.

Flat file

-flat.vmdk file, one of the two files that make up the basic disk. The flat disk contains the raw data of the basic disk. The file does not appear as a single file in the data store browser.

Database file

The .vmsd file, which contains snapshot information for the virtual machine, and is the main source of information for the snapshot manager. This file contains line entries that define the relationship between snapshots and between the subdisks of each snapshot.

Memory file

A .vmsn file that contains the activity status of the virtual machine. By capturing the memory state of the virtual machine, it can be restored to the turned on virtual machine condition. With non-memory snapshots, you can only restore to the shut down virtual machine condition. It takes longer to create a memory snapshot than it takes to create a non-memory snapshot. The time it takes for an ESX host to write memory to disk is related to the amount of memory used by the configuration virtual machine.

III. Snapshot principle

The snapshot adopts the technology of "copy on write (Copy On Write)", and the implementation principle is relatively simple. When taking a snapshot, copy an index of the original disk, and the actual data pointed to are all the data of the original disk. Only when the data of the original mirror changes, will the data before the change be copied to the corresponding location of the snapshot. So when you take a snapshot, the data is relatively small, and then it will get bigger and bigger.

The virtual machine disk is a file in vmdk format. If the virtual machine has several disks to take a snapshot of the virtual machine, there will be several vmdk files. The data generated by the virtual machine snapshot is stored in the same storage space as the virtual machine disk data, so the storage location is the storage location of the virtual machine itself, that is, if the virtual machine storage can not be accessed, its snapshot can not be restored.

When we create a snapshot of the virtual machine, the currently writable VMDK file becomes read-only, and a new file (called the snapshot file) is created to hold the changed contents (using in-file delta technology).

Snapshot chain: a relational chain of multiple snapshots arranged in chains according to the time they were created

In the initial state, the size of the snapshot file is 16MB and grows as the virtual machine writes to the disk file. Snapshot files grow according to the size of the 16MB to reduce SCSI reservation conflicts. When the virtual machine needs to modify the blocks of the original disk file, these changes are saved to the snapshot file. When the modified blocks in the snapshot file need to be modified again, these modifications will overwrite the blocks in the snapshot file, and the snapshot file size will not change. Therefore, the size of the snapshot file will never exceed the size of the original VMDK file.

The change frequency of snapshot files depends on the busy degree of write of virtual machine applications. For example, for Exchange, SQL, ORACLE and other applications, snapshot files change quickly. In the case of multiple snapshots, the previous snapshot file becomes read-only when a new snapshot is created.

IV. Virtual machine snapshot

The virtual machine snapshot function of VMware is to create a copy of a certain state of the virtual machine disk file VMDK. When there is an exception in the system, you can restore the snapshot to ensure that the system is normal. VMwware's virtual machine snapshot technology is very useful, but it also has limitations that need to be noted.

1. Snapshots are not very suitable for data protection

Whether it is based on SAN snapshot technology, or built on the file system or operating system, snapshot technology can minimize losses when errors occur. But not all snapshot technologies are aimed at unexpected data loss, such as snapshot technology on VMware ESX servers and virtualization platforms, and database snapshots.

Fundamentally speaking, the snapshot of VMware is more suitable for two situations: 1, isolate the disk of a virtual machine and no longer write data, so that you can backup 2 and provide a short-term automatic recovery function during patches and software upgrades. In a development environment, it may be common to see mirrors that use snapshots to save some real-time state, but this approach is not desirable in a performance-sensitive production environment.

In this diagram, the virtual machine can be easily restored to the state before each patch.

In a typical environment, the disk resources of a virtual machine are made up of VMDK files (abbreviations for virtual machine disk) located on VMware's unique VMFS file system or NFS storage, and its size is almost equal to the disk resources of the virtual machine. So if your Windows 2000 professional has a 15GB system hard drive, then a 15GB VMDK file will appear on the VMFS volume.

If you use hypervisor to take a snapshot of a virtual machine, the system creates a second VMDK file (sometimes called redo log) that stores everything written to the virtual machine after the snapshot, which has several obvious advantages:

First, because the snapshot VMDK file stores writes to the underlying VMDK, the underlying VMDK is not actually changed. This means that if some errors occur after the snapshot is established, you can easily "throw away" these errors and return to the underlying disk state before the snapshot. Similarly, since the underlying VMDK is not written when the snapshot exists, it is safe to create a copy of the underlying VMDK for backup.

2. Snapshots tend to consume a lot of storage space

When the virtual machine performs a read operation after the snapshot is created, hypervisor checks the snapshot VMDK to see if there are any chunks being read. If so, the chunk is provided for the virtual machine from the snapshot, and if not, the virtual machine also needs to read the underlying VMDK. If there is only one snapshot, this is not a problem, just repeat to read the VMDK. But if there are a large number of snapshots, such as creating one per day for two weeks, then hypervisor needs to look for this chunk among 14 snapshot files, which consumes a lot of reading Ibind O.

To make matters worse, there is no perfect mechanism to stop the growth of these snapshots. If you take a snapshot of a Windows 2000 virtual machine every day, you will probably need to consume 2GB storage space every day, which is a very conservative figure for most virtual machines. In general, you need to configure double the space for the virtual machine to store these changes.

On the other hand, almost all snapshot technologies, including SAN snapshots, consume a lot of storage space. However, the difference is that VMware snapshots do not have an automatic protection mechanism to prevent VMFS volumes from being filled with growing snapshots. Most SAN automatically deletes the oldest snapshot when the allocated snapshot space is filled. Once the VMSF volume is filled, the current snapshot file can no longer be written, and the virtual machine may crash. If there are many virtual machines and the snapshots are all on the same VMFS volume, these virtual machines can crash, which is catastrophic.

There is also a potential trap that hypervisor will attempt to confirm the persistent state of the snapshot application through the disk quiesce process (disk quiescing). Although it is possible to create a snapshot without halting the hard disk, only a crash-consistent snapshot can be created at this time. If the underlying disk is restored after the crash-consistent snapshot is established, the operating system and applications will appear to be in the state of an abnormal shutdown. The disk pause feature allows operating systems and applications to find suitable pause points, such as completing writes, to prevent data corruption.

Disk quiesce can be achieved in different ways according to the operating system's performance in the virtual machine. All of these require the application of the VMware toolkit installed in the virtual machine operating system. If you are running a recent version of the Windows system, the VMware tool will use Microsoft's Volume Shadow copy Service (VSS) to create a temporary pause in the virtual machine Ibino, allowing the VMware software to create a lower-level disk snapshot.

However, in virtual machines that do a large number of disk Iramo transfers, such as the Microsoft SQL database platform or Exchange, the Shadow copy Service (VSS) may require a lot of debugging to work properly. VSS work is not so stable, sometimes, this time is normal, but next time there may be a failure. This is annoying, especially when you want to better back up the virtual machine by pausing snapshots.

3. Snapshot and disk space utilization

If the virtual machine is running a snapshot, it is making changes to the subdisk or sparse disk. The more writes are performed to the disk, the larger the disk becomes until it reaches the upper limit (the sum of the underlying disk size and a small amount of overhead).

Among the space requirements of a child disk, there are additional requirements in addition to the space requirements of the parent disk on which it depends. If the virtual machine has a 10 GB disk with one subdisk, the space used is 10 GB + snapshot size + .vmsn file size + overhead.

Subdisks can grow so large that they fill the entire data store, but this is because the LUN that contains the data store is not large enough to accommodate the underlying disk, the number of snapshots created, the associated overhead, and the .vmsn files created.

The growth rate of the subdisk is directly determined by the amount of Iscrap O performed on the disk.

The size of the subdisk directly affects the time it takes to delete the snapshot associated with the subdisk.

4. Snapshot integration

The snapshot consolidation command searches for hierarchical or incremental disks to be combined without violating data dependencies. After consolidation, redundant disks are removed, which improves virtual machine performance and conserves storage space. Snapshot consolidation: consolidate all snapshots into one snapshot, which will remove redundant disks later, which can improve the performance of virtual machines.

When there is only one snapshot, no additional space is required when deleting the snapshot. Because either delete the snapshot file directly or merge the snapshot file with the VMDK disk file. (if a virtual machine contains multiple disks, there are snapshot files on multiple disks for virtual machine snapshots. During integration, you need to estimate the remaining space of each disk (if there is not enough space, you need to hang a large disk to cover the amount of data). And the operation during integration is serial.)

But when there are multiple snapshots, the effect is different.

Suppose you want to delete all snapshots of a virtual machine that has three snapshots, snap1, snap2, and snap3. First of all, the snapshot files of snap3 will be merged into the snapshot files of snap2, resulting in an increase in snap2 footprint. The snap2 is then merged into the snap1, resulting in an increase in the space consumed by snap1. Finally, snap1 is merged into the VMDK file with no additional space overhead at this time. The snapshot will not be deleted until the merge is complete.

An alternative is to delete the snapshots in turn so that you don't need more space, just a little more tedious.

Time required to delete a snapshot

When deleting a snapshot through a VI client, the information displayed in the status bar of the VI may be misleading. Typically, the status bar will quickly reach the 95% complete state, but will wait a long time in the 95% state until the merge is complete. VirtualCenter has a 15-minute timeout for all tasks, even though the background is still merging, but after 15 minutes, VirtualCenter reports that the operation timed out.

One way to see if the task is completed is to browse the datastore of the virtual machine through the VI client. If the corresponding delta file for the snapshot no longer exists, the snapshot has been deleted.

If the snapshot exists for a long time, the snapshot file becomes larger, so it takes a long time to merge when the snapshot is deleted. The time of merging depends on how busy the virtual machine is, and the merging speed is faster when the virtual machine is turned off. The busyness of the disk subsystem at the back end of the ESX server will also affect the merger time.

A snapshot file of a 100GB may take 3-6 hours to merge into the original VMDK file. Starting with ESX3.5, it may take longer to merge because VMware modifies the merge algorithm (see the VMware document Consolidation of large or deeply nested snapshots). This affects the performance of virtual machines and ESX servers. Therefore, it is recommended that you limit the retention time of snapshots and delete snapshots immediately when they are not needed.

Impact of Snapshot and metadata Lock on ESX performance

The performance impact of snapshots on ESX servers and virtual machines is reflected in several aspects. However, when you create a snapshot, the activity of the virtual machine pauses temporarily, and if you check the status of the virtual machine with the ping command, you can see some response of timeout. In addition, creating a snapshot will cause updates to the metadata, and the LUN will be locked in a short period of time to avoid SCSI Reservations conflicts, resulting in exclusive access to the LUN by only one ESX server for a short period of time.

If a snapshot is created for a virtual machine, the snapshot is active while the virtual machine is running. As long as the snapshot is active, the performance of the virtual machine degrades. Because the ESX server writes delta files differently from VMDK files, and it is relatively inefficient. Each time the delta file grows by the size of the 16MB, it results in another metadata lock.

Finally, deleting or rolling back a snapshot creates a metadata lock. In addition, deleting snapshots may result in significant performance degradation, and the busier the virtual machine is, the more obvious it is. To avoid this problem, it is best to delete snapshots during off-peak hours.

5. Restrictions on snapshots

Snapshots may affect virtual machine performance and do not support certain disk types or virtual machines configured using bus sharing. Snapshots are useful as a short-term solution to capture the state of a point-in-time virtual machine, but not for long-term virtual machine backups. In addition, avoid multiple snapshots and do not keep snapshots for too long.

■ VMware does not support snapshots of bare disks, RDM physical mode disks, or client operating systems that use iSCSI initiators in the client.

■ must power off virtual machines with independent disks before performing snapshots. Snapshots of powered on or suspended virtual machines with stand-alone disks are not supported.

Snapshots are not supported on the ■ PCI vSphere Direct Path I Pot O device.

■ VMware does not support snapshots of virtual machines configured for bus sharing. If you need to use bus sharing, as an alternate solution, consider running backup software in the client operating system. If the virtual machine currently has snapshots and prevents you from configuring bus shares, delete (consolidate) these snapshots.

■ snapshots provide point-in-time images of disks that can be used by backup solutions, but snapshots are not a reliable method of backup and recovery. If the file containing the virtual machine is lost, its snapshot file is also lost. In addition, a large number of snapshots will be difficult to manage, take up a lot of disk space, and will not be protected in the event of a hardware failure.

Backup solutions, such as VMware Data Recovery, use snapshot mechanisms to freeze the health of virtual machines. The Data Recovery backup method has other features that reduce snapshot limits.

■ snapshots can have a negative impact on the performance of virtual machines. Performance reduces the time it takes to stay in place based on the snapshot or snapshot tree, the depth of the tree, and the extent to which the virtual machine and its client operating system change after taking the snapshot. In addition, you may see that it takes longer to power on the virtual machine. Do not run the production virtual machine permanently from the snapshot.

Despite its shortcomings, snapshots of VMware can be an excellent tool if used correctly, whether it's creating short, real-time replicas of virtual machines before major upgrades or patches, or allowing third-party backup software to perform direct-from-SAN backups of virtual machines. However, the prerequisite for effective use of snapshot capabilities is an understanding of how they work, and some debugging may be required occasionally.

It is also important to note that if you want to apply VMware snapshots to virtual machines running critical tasks, you should be more careful and it is best to test them first.

Note: VMWARE recommends that the maximum retention time of a single snapshot instance is 72 hours.

Backups and snapshots are not the same.

When a virtual machine is restored from a backup, it must be restored before it can be powered on.

The virtual machine can remain powered on when it is restored from the snapshot

This is the end of the in-depth analysis of the virtual machine snapshot of VMware. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.