LVM Thin Provision: operating experience at a small facility
I want to share my experience in operating LVM Thin Provision, and stuffed cones. Overall, I am pleased with this technology.
I already wrote about thin volumes in an earlier article . The performance is good, it depends little on the number of shots, for more than a year, there were no failures due to LVM, all the problems were created by me personally for myself.
Anyone who begins to use thin volumes is strongly recommended to read man lvmthin with addiction. The omission of the seemingly unimportant aspect that a place in the pooled volume can end, can lead to dire consequences.
Depending on FS. Usually, after stopping io with a full volume, the file system remains intact, especially if the file system is journaling. If you managed to expand the pool, and io-operations did not have time to fall off on timeout, then everything will be fine. Otherwise, a log rollback and a small data loss.
')
This is a very daunting situation, since it leads to stopping the correct operation of the entire thin pool, with the need to offline restore the integrity of the pool data. This often leads to serious violations in Data space, and in 2 cases out of 3, it was easier to kill XFS and roll back than to try to restore it.
Set the policy for automatically expanding thin volumes globally. By setting reasonable values, you can then, using profiles, configure any other policy for the pool. However, if the system does not apply the profile (the profile name that could have been deleted is stored in the pool's metadata), it will report this fact somewhere in the logs (which you may not notice), but thanks to global policy, everything will be relatively good.
LVM Thin Provision works great in a lazy planning situation. This means that it is worthwhile for different tasks to create pools of thin volumes of reasonably small sizes. Create volumes in these pools, and just observe how the sizes of pools grow as you fill. To allocate a place immediately is not worth it, it is not always possible to predict what space is needed.
Set chunksize sizes based on the task. Larger sizes will lead to lower overhead costs in metadata, but will entail a greater expenditure of space on the images (if it coincides with RAID5-6, then there will be a bonus).
Zeroing - if you turn it off, you will get a bit of a speed bonus, but get ready, you may encounter all sorts of rubbish in the selected blocks.
The snapshot is created without problems, but its use can cause some problem. The thing is that while the volume is active (although not used), the snapshot does not apply to it until the next activation (or it is applied in the lazy mode). Therefore, before you roll up the snapshot, deactivate the target volume.
By default, snapshots are created with the activation cancel flag. This can be discouraging when trying to connect it.
Brief introductory
I already wrote about thin volumes in an earlier article . The performance is good, it depends little on the number of shots, for more than a year, there were no failures due to LVM, all the problems were created by me personally for myself.
Rake
Anyone who begins to use thin volumes is strongly recommended to read man lvmthin with addiction. The omission of the seemingly unimportant aspect that a place in the pooled volume can end, can lead to dire consequences.
Exhaustion of a place in Data space:
Depending on FS. Usually, after stopping io with a full volume, the file system remains intact, especially if the file system is journaling. If you managed to expand the pool, and io-operations did not have time to fall off on timeout, then everything will be fine. Otherwise, a log rollback and a small data loss.
')
Exhaustion of a place in the Metadata space:
This is a very daunting situation, since it leads to stopping the correct operation of the entire thin pool, with the need to offline restore the integrity of the pool data. This often leads to serious violations in Data space, and in 2 cases out of 3, it was easier to kill XFS and roll back than to try to restore it.
Recommendations:
Set the policy for automatically expanding thin volumes globally. By setting reasonable values, you can then, using profiles, configure any other policy for the pool. However, if the system does not apply the profile (the profile name that could have been deleted is stored in the pool's metadata), it will report this fact somewhere in the logs (which you may not notice), but thanks to global policy, everything will be relatively good.
LVM Thin Provision works great in a lazy planning situation. This means that it is worthwhile for different tasks to create pools of thin volumes of reasonably small sizes. Create volumes in these pools, and just observe how the sizes of pools grow as you fill. To allocate a place immediately is not worth it, it is not always possible to predict what space is needed.
Set chunksize sizes based on the task. Larger sizes will lead to lower overhead costs in metadata, but will entail a greater expenditure of space on the images (if it coincides with RAID5-6, then there will be a bonus).
Zeroing - if you turn it off, you will get a bit of a speed bonus, but get ready, you may encounter all sorts of rubbish in the selected blocks.
Work with pictures
The snapshot is created without problems, but its use can cause some problem. The thing is that while the volume is active (although not used), the snapshot does not apply to it until the next activation (or it is applied in the lazy mode). Therefore, before you roll up the snapshot, deactivate the target volume.
By default, snapshots are created with the activation cancel flag. This can be discouraging when trying to connect it.
Source: https://habr.com/ru/post/326746/
All Articles