Tom should stay thin
In the comments to our post about the 3Par InServ architecture, we were asked to tell in more detail how the thin reclamation mechanism is implemented for 3Par. Work on your applications is probably the most enjoyable part of keeping this blog, so we are happy to tell.
First of all, let's see why, in fact, requires thin reclamation. 3Par, and after it, other vendors of disk arrays used thin provisioning technology in their systems, which allows allocating capacity to applications from the virtual pool of disk resources. At the same time, the allocated virtual capacity can be much larger than the physical one, due to which it is possible to significantly save on disks when purchasing an array.
Good decision. But there is a problem. If the application frees some of this virtual capacity, or it turns out that it has been allocated extra virtual capacity, then at the physical level the disks that correspond to this freed virtual capacity will still remain behind this application and cannot be transferred to other applications.
For example, consider the following scenario: the host file system contains 100 GB of data and it is allocated the same capacity from the virtual volume on the array disks. If you delete a group of files with a total size of 10 GB, the array will not be able to learn about this deletion and 100 GB will still be allocated for the file system on it.
')
If then instead of old files new ones of the same size will be recorded, then they will need to allocate an additional 10 GB of capacity on the disks, although the size of the file system itself will remain the same - 100 GB. As a result, a thin volume (thin volume) will gradually grow and become fat (fat volume).
To solve this problem, 3Par has added the Thin Persistence feature to the InServ operating system (free translation - maintaining volumes in sports form). Thin Persistence works in real time and analyzes the data before it is written to the thin volume. In the data that the host writes, the function looks for blocks consisting of only zeros (this is an indication of erased data or unused capacity), and then returns these blocks in 16-KB portions to the free virtual capacity pool. The function of searching for zeros is built into the specialized 3Par ASIC Gen3 chip and therefore Thin Persistence does not slow down the operation of the InServ Storage Server array.
The Thin Copy Reclamation function works in a similar way. With the difference that it struggles with the thickening of the volumes, which occurs due to the removal of snapshots, not files. When you delete a snapshot, the virtual volume capacity allocated to it returns to the virtual pool and can be redistributed among other volumes.
Particularly worth mentioning is that 3Par, as the pioneer of thin provisioning technology, was the first among the manufacturers of disk arrays to implement API support for Thin Reclamation for Veritas Storage Foundation version 5 and higher. Using them, the VxFS file system running on the host itself informs the disk array (SCSI-command WRITE SAME) about deleting files, so the InServ Storage Server array can find the capacity allocated to these files without searching for blocks of zeros ( more on this here ).
In addition, Oracle, together with 3Par, developed the Oracle Automatic Storage Manager (ASM) Storage Reclamation utility to free up capacity for the Oracle Database 10g and 11g DBMS on the InServ Storage Server disk arrays ( more here ).
Hope that was interesting.
First of all, let's see why, in fact, requires thin reclamation. 3Par, and after it, other vendors of disk arrays used thin provisioning technology in their systems, which allows allocating capacity to applications from the virtual pool of disk resources. At the same time, the allocated virtual capacity can be much larger than the physical one, due to which it is possible to significantly save on disks when purchasing an array.
Good decision. But there is a problem. If the application frees some of this virtual capacity, or it turns out that it has been allocated extra virtual capacity, then at the physical level the disks that correspond to this freed virtual capacity will still remain behind this application and cannot be transferred to other applications.
For example, consider the following scenario: the host file system contains 100 GB of data and it is allocated the same capacity from the virtual volume on the array disks. If you delete a group of files with a total size of 10 GB, the array will not be able to learn about this deletion and 100 GB will still be allocated for the file system on it.
')
If then instead of old files new ones of the same size will be recorded, then they will need to allocate an additional 10 GB of capacity on the disks, although the size of the file system itself will remain the same - 100 GB. As a result, a thin volume (thin volume) will gradually grow and become fat (fat volume).
To solve this problem, 3Par has added the Thin Persistence feature to the InServ operating system (free translation - maintaining volumes in sports form). Thin Persistence works in real time and analyzes the data before it is written to the thin volume. In the data that the host writes, the function looks for blocks consisting of only zeros (this is an indication of erased data or unused capacity), and then returns these blocks in 16-KB portions to the free virtual capacity pool. The function of searching for zeros is built into the specialized 3Par ASIC Gen3 chip and therefore Thin Persistence does not slow down the operation of the InServ Storage Server array.
The Thin Copy Reclamation function works in a similar way. With the difference that it struggles with the thickening of the volumes, which occurs due to the removal of snapshots, not files. When you delete a snapshot, the virtual volume capacity allocated to it returns to the virtual pool and can be redistributed among other volumes.
Particularly worth mentioning is that 3Par, as the pioneer of thin provisioning technology, was the first among the manufacturers of disk arrays to implement API support for Thin Reclamation for Veritas Storage Foundation version 5 and higher. Using them, the VxFS file system running on the host itself informs the disk array (SCSI-command WRITE SAME) about deleting files, so the InServ Storage Server array can find the capacity allocated to these files without searching for blocks of zeros ( more on this here ).
In addition, Oracle, together with 3Par, developed the Oracle Automatic Storage Manager (ASM) Storage Reclamation utility to free up capacity for the Oracle Database 10g and 11g DBMS on the InServ Storage Server disk arrays ( more here ).
Hope that was interesting.
Source: https://habr.com/ru/post/113771/
All Articles