Using compression with flash module drives (FMDs)
Some storage contains flash module drives (FMDs) that transparently compress the data stored on them. Compression is a powerful way to reduce storage costs, but it does require extra care and monitoring by the administrator.
Not all data is equally compressible. For example, plain English text is readily compressible, whereas media files or archives that have already been compressed cannot be compressed again. Therefore, the amount of data that an FMD can store depends on the nature of that data. Even in the absence of file system snapshots, if a client deletes a large directory of plain text files and replaces it with a directory of media files of the same total size, more physical space will be needed, and the HDP pool may run out of space.
If the HDP pool runs out of space, it will be blocked, and all spans that use DP-Vols on that HDP pool will fail. The server issues warnings when physical space is low. However, the administrator must monitor physical space on the HDP pool and prevent it from running out of space.
To set up an HDP pool on FMDs, follow these steps in your storage configurator (such as Storage Navigator):
- Create one or more parity groups on FMDs.
- Enable compression on the parity groups. The storage configurator now treats each parity group as if it were 8 times its actual size.
- Create LDEVs on these parity groups. Avoid filling up the available space with LDEVs. For example, if the physical capacity of a parity group is 10 TiB, switching on compression will enable you to create 80 TiB of LDEVs on the parity group. Never do this, because the FMDs cannot achieve an 8:1 compression ratio.
- Create an HDP pool on the LDEVs. The LDEVs are now known as pool volumes.
- Create DP-Vols on the HDP pool.
- Assign the DP-Vols to host paths, and give them host LUNs. Use HDP thin provisioning; make the total capacity for the DP-Vols roughly three times that of all the underlying pool volumes.
- On the server, license the DP-Vols (perhaps using sd-allow-access) and create a span (perhaps using span-create).
Ideally, the ratio of LDEV space to parity group space will be very slightly smaller than the compression ratio achieved by the FMDs. However, actually, it is impossible to make an accurate prediction of the compression ratio that FMDs will achieve before the data has been written. Indeed, the ratio will change as old data is deleted and new data is written. When setting up a new system, therefore, it is wise to assume that the FMDs will achieve no compression at all. On each 10 TiB parity group, set up only 10 TiB of LDEVs.
Once you have a mature span containing a good deal of data of the kind you wish to store, determine the compression ratio, create more LDEVs, and add them to the HDP pool. For example, if you find that the FMDs have achieved a 1.5:1 compression ratio, create a further 4 TiB of LDEVs for each 10 TiB parity group, or an extra 8 TiB for each 20 TiB parity group, and so forth. Assuming that the FMDs will achieve 1.4:1 when they have proved themselves capable of achieving 1.5:1 gives you a margin of error and ensures safety, provided that the nature of the data stored on the HDP pool does not change.
For further information on compression and how to avoid over-committing space, see the span-fmd-compression man page.