Shulou(Shulou.com)06/01 Report--

Today, I would like to talk to you about how to understand instance snapshot. Many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something from this article.

The instance snapshot operation can be used to back up or save the instance as a new image. If you perform a snapshot operation in a production system, you must ensure that this operation is fast and safe. Here are two key points:

fast.

In order to ensure the consistency of data, pause instance is required for snapshot, and then resume after operation. In this process, instance cannot be served externally. In order to reduce the impact on the business, we hope that snapshot will be better as soon as possible.

It's clear.

That is, data consistency. The image out of snapshot cannot have data that has not been dropped, and can be started normally. So you usually want to pause instance before executing snapshot, pausing all IO operations.

Default snapshot

Does the snapshot operation in the default configuration meet both fast and secure conditions?

Snapshot is a snapshot of the image file (system disk) of instance, which is located in the compute node / var/lib/nova/instances//disk. In part 036, we discussed in detail the steps to implement snapshot:

Pause instance

Execute the qemu-img convert command to copy the disk file and generate a snapshot file

Resume instance

Upload snapshot files to Glance

Step 1 ensures security, and whether it is fast depends on how long step 2 takes. The execution time of qemu-img convert depends on the size of disk and its backing files, and instance system disks are usually in G units, so the time spent in step 2 is at the level of minutes.

Pausing the production system for a few minutes is usually unacceptable, so the default snapshot operation is not fast.

What is the solution?

Unreliable live snapshot

Nova has long proposed an alternative to live snapshot, which can be found on the official website http://docs.openstack.org/ops-guide/ops-user-facing-operations.html#live-snapshots.

The principle of live snapshot is: do not pause instance when making a snapshot, but execute qemu-img convert directly. That is, to miss steps 1 and 3.

In this way, although the fast conditions are met, the business will not be affected. However, because there is no pause instance, it is possible that new data is constantly written into the disk file in the snapshot process, so it is difficult to ensure the consistency of the data, and the security becomes a problem again.

The official website document suggests: if you want to do live snapshot, users must ensure the consistency of the data, such as making a snapshot to ensure that all data has been dropped, and no new data will be written in. Personally, live snapshot is basically impossible to use in production.

The real solution.

The problem with the default snapshot is that qemu-img convert takes too long, and the reason is that instance's system disk is a file, and copying the file itself is a time-consuming operation. The real solution is:

Let instance boot from cinder volume and use storage provider's own snapshot technology to achieve fast replication.

Modern storage systems (whether open source or commercial storage) basically provide the snapshot function of volume, and this snapshot is pointer-based and does not really copy data, so it is very fast, usually done in an instant, with little impact on the business. So if instance is launched from cinder volume, OpenStack will use storage provider's snapshot to complete the operation when taking a snapshot. This makes it both safe and fast.

Let's demonstrate this process using the popular distributed storage system ceph. The configuration method of ceph as cinder backend is omitted here.

Boot from volume

Specify the creation of the volume when deploying the instance.

The image we chose here is xenial (Ubuntu 16.04) with a size of 2.20 GB. Make sure the Create New Volume option is Yes. Volume Size is 3 (greater than image 2.20 GB). After the deployment, OpenStack does the following:

Create a 3 GB volume in ceph.

Copy image data to the volume.

Instance starts from this volume.

You can see the newly created volume in the volume administration interface.

Ubuntu-test is the instance that we deployed. Next, snapshot the ubuntu-test.

The operation is completed in an instant!

Notice that the Size of the snapshot snap-test is 0 bytes because it is actually stored in cehp. The instance deployed through snap-test is directly from boot from volume.

Boot from volume is actually the best practice for OpenStack to deploy instance. The boot disk and data disk of instance are managed by cinder, and it is convenient to make snapshots and backups.

Instance customization is actually a very important content, and there is a great demand in the production environment. At present, the most mainstream solution is cloud-init, of course, only cloud-init is not enough, but also need the support of OpenStack services. The reason why it was not discussed earlier is mainly because this topic will involve both nova and neutron modules, which requires more comprehensive knowledge and skills, but now is a very good time.

After reading the above, do you have any further understanding of how to understand instance snapshot? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.