Application of Snapshot Technologies

• Online data restoration: Snapshot technologies can be used to restore data online and restore a storage device to the state at the snapshot point in time in the case of storage device failure or damage.
• Available copies: Snapshot technologies provide another data access channel for storage users. When the source data is being processed online, users can access and use the snapshot data to perform tasks, such as testing.

Concepts

• Data organization

  Storage systems use virtual storage technology. Each LUN created in a storage pool is composed of both a meta volume and a data volume, where:

  • A meta volume records the data organization form and attributes of a LUN. Each meta volume is arranged in a tree structure.
  • A data volume stores the actual user data. Data is read and written in units of extent.
• Source volume

  A volume that stores the source data for a snapshot and is represented as a source LUN to users. A source LUN consists of a meta volume and a data volume, where:

  • The meta volume records the location of the source data in the source LUN.
  • The data volume records the service data saved in the source LUN.
• Snapshot volume

  A logical data copy generated after a snapshot is created for a source LUN. A snapshot LUN consists of a snapshot meta volume and a snapshot data volume, where:

  • The snapshot meta volume contains the snapshot metadata. One snapshot has one snapshot meta volume.
  • The snapshot data volume corresponds to the snapshot meta volume and records new data written into the snapshot LUN.
• COW data space

  An amount of storage space dynamically allocated by the storage system from the storage pool where the source LUN resides to store COW data after a snapshot is generated and activated. All the snapshot LUNs of the same source LUN share one COW data space. A COW data space consists of a COW meta area and a COW data area, where:

  • The COW meta area is shared by all snapshots in the source LUN. It is used to store the COW mapping information of the snapshot LUNs if new data is written into their source LUN, that is, the mapping relationships between COW data and data locations in the COW data area.
  • The COW data area corresponds to the COW meta area. It is used to record COW data if new data is written into the source LUN.
• Mapping table

  A mapping table records the data changes on the source and snapshot LUNs at a point in time as well as the new locations of such data. Mapping tables are classified into shared mapping tables and private mapping tables, where:

  • A shared mapping table, which is stored in the COW meta area, records the mapping relationships between COW data and COW data locations in the COW data area.
  • A private mapping table, which is stored in the snapshot meta volume of each snapshot LUN, records the mapping relationships between data written into the snapshot LUN and data locations in the snapshot LUN.

In a COW technology, when new data is written to a specific storage location for a first time, original content is first read and written to the COW data space, and then the new data is written to the storage device. No COW operation is required for next write operations on this location. When data is first written to a location, COW completes a read operation (reading the original data from the location) and two write operations (writing the original data to the snapshot space and writing new data to the location). It takes a lot of I/Os for frequent writing. Therefore, COW can be used when the number of read operations on a LUN is far more than that of write operations. In addition, if an application is prone to write hotspots, that is, only write data to a limited range of data, then the COW snapshot technology is recommended because multiple write operations to the same data will only lead to one COW operation.

After a snapshot is created and activated, a data copy that is identical to the source volume is generated. The storage system allocates COW data space from the source LUN and generates a snapshot volume. Because no data is written to snapshot or source volumes, no data is recorded to the COW meta and data areas or to the snapshot meta and data volumes. The following figure shows the initial state of a snapshot.

Figure 1-1 Initial state of a snapshot

Writing Data to a Source Block

If an application server attempts to write data to a source LUN of an activated snapshot, the storage system does not process the write request immediately. Instead, the storage system uses the COW mechanism to copy COW data to the COW data space, changes the mapping relationships in the mapping table, and then writes new data to the source volume. The application server sends a request to write the source volume at Time1:

1. Data1 is changed to DataX.
2. The COW mechanism is triggered to copy Data1 to the COW data space.
3. The mapping relationships are updated in the mapping table. The location of Data1 is changed to g0 in the COW data space.
4. DataX is written into the source volume.

When COW creates a snapshot, there is no physical data copying action, only the physical location metadata (pointer information) of the source data block where the original data resides is copied. Therefore, COW snapshot creation is very fast and can be completed instantly. After the snapshot is created, snapshot software monitors and traces changes in the original data (write operations to the source data block), and copies data on the source data block to the new data block before the original data in the source data block is rewritten. New data is written to the source data block to overwrite the original data. All source data blocks constitute the so-called source data volume and new data blocks constitute the snapshot volume. The snapshot volume retains only changed data blocks and is much smaller than the source data volume. COW has an obvious shortcoming that the write performance of the source data volume deteriorates. Because each time new data is rewritten, actually two write operations are performed.

Writing Data to a Snapshot Volume

After a snapshot is activated, application servers can send read/write requests to its snapshot LUN. Write requests are directly processed by the snapshot LUN, and then the private mapping table records the data location in the snapshot LUN.

1. An application server sends a request for writing Data a to the snapshot volume at Time2. Data a is written directly to the snapshot volume.
2. The private mapping table records that Data a is stored in location g'0 of the snapshot LUN.

Reading Snapshot Data (Data Written to the Snapshot Volume)

To access snapshot data of a certain point in time, the system directly read unchanged data blocks from the data volume, and changed and copied data blocks from the snapshot space. Once created, a snapshot traces and records the metadata information that describes block changes.

If the application server writes Data a into the snapshot volume, the application server reads snapshot data as follows:

1. The application server sends a request to read snapshot data.
2. The private mapping table locates the desired snapshot data.
3. The application server reads the snapshot data. In the following figure, this is Data a.

Reading Snapshot Data (No Data Written to the Snapshot Volume)

If the application server has written data to the source volume but not the snapshot volume, the application server reads snapshot data from the source volume or COW data space, as shown in the following figure.

1. The application server sends a request to read snapshot data.
2. The shared mapping table locates the desired snapshot data.
3. The application server reads the snapshot data. In the following figure, this is Data 0, Data 1, Data 2, and Data 3.

The implementation principle of ROW is very similar to COW. The difference is that ROW's first write operation to the original data volume will redirect the new data to the reserved snapshot volume. Therefore, the original data in the ROW snapshot remains in the source data volume, and in order to ensure the integrity of the snapshot data, the state of the source data volume will change from read-write to read-only when the snapshot is created.

When creating a snapshot, ROW will also copy a source data pointer table as a snapshot data pointer table. At this time, the pointer records of the two tables are the same, as shown in Figure 2-6.

After a user creates a snapshot at Time0, the internal processing flow of the storage system is as follows:

1. Copy the snapshot mapping table according to the source volume mapping table.
2. Create a snapshot volume to store newly written data.

Writing Data to the Source Volume

1. The application server sends a request to write the snapshot volume at Time1 to change Data1 to DataX.
2. The original data in the source data volume receives an update operation instruction and new data is written into the new snapshot volume.
3. The source volume mapping table is updated.

Steps 1 to 3 are repeated in subsequent writes until the next snapshot is generated. In the preceding steps, the old data at the previous snapshot time point Time0 is still stored in the source volume, while the new data is finally stored in the reserved snapshot volume. Data in the snapshot volume mapping table remains unchanged.

If you take multiple snapshots of a VM, a snapshot chain is generated, and the disk volume of the VM is always mounted at the very end of the snapshot chain, that is, all write operations of the VM will be placed in the last snapshot volume. This feature causes a problem that if 10 snapshots are taken in total, when restoring to the latest snapshot point, you need to merge 10 snapshot volumes to obtain a complete latest snapshot time point data; if it is restored to the 8th snapshot time point next time, then you need to merge the previous 8 snapshot volumes into a complete snapshot time point data. It can be seen from this that the main disadvantage of ROW is that there is no complete snapshot volume, and the relationship between the snapshots is chained. If there are more snapshot levels, the system overhead for performing snapshot recovery will be greater.

Reading the Source Volume

A reading operation is redirected if a writing redirection has been performed on the location since the last snapshot. Otherwise, the reading operation does not need to be redirected.

1. The application server sends a request at Time2 to read data from G1 of the source volume.
2. If redirect-on-write is performed on G1 at Time1, data reading is redirected to L0 of the snapshot volume.

A new snapshot does not contain any user data but only a group of pointers for locating user data of the source file system. As a result, users accessing snapshot data are actually accessing the data of the source file system. When data in the source file system is modified, the snapshot retains the space occupied by the original data for protection. The protected space will not be reclaimed unless the snapshot is deleted.

Updates to the source file system cause the snapshot to retain more of the original data blocks and increase the snapshot space. However, the snapshot only retains the data at the point in time when it was created. New data written after that time point is not protected by the snapshot and does not occupy snapshot space. Snapshot rollback restores the data to its original state at the time of creation to prevent data loss from misoperations or viruses.

Exercise caution when performing snapshot rollback because its changes are irreversible. A rollback can restore data to a specified point in time, but data written after that time will be lost with the snapshot after a rollback. Manually copy individual files from the snapshot to the source file system for small-scale restoration to avoid rolling back the entire file system. Because snapshot rollback will cause the loss of file system data or the snapshot, services may be interrupted if you are accessing the data during the rollback. Exercise caution when performing snapshot rollback.