7.6. Using SSD Drives

Virtuozzo Storage supports SSD drives formatted to the ext4 file system and optionally mounted with TRIM support enabled.


Virtuozzo Storage SSD usage scenario does not generate TRIM commands. Also, modern drives like Intel SSD DC S3700 do not need TRIM at all.

Along with all-flash setups where SSD drives are used for storing data chunks, Virtuozzo Storage also supports hybrid clusters where SSDs are used for write journaling. You can attach an SSD drive to an HDD-based chunk server and configure the drive to store a write journal. By doing so, you can boost the performance of write operations in the cluster by up to two and more times.

The following sections provide detailed information on configuring SSD drives for write journaling and data caching.

Take note of the following:

  • Not all solid-state drives obey flush semantics and commit data in accordance with the protocol. This may result in arbitrary data loss or corruption in case of a power failure. Always check your SSDs with the vstorage-hwflush-check tool (for more information, see Checking Data Flushing).

  • It is recommended to use Intel SSD DC S3700 drives. However, you can also use Samsung SM1625, Intel SSD 710, Kingston SSDNow E or any other SSD drive with support for data protection on power loss. Some of the names of this technology are: Enhanced Power Loss Data Protection (Intel), Cache Power Protection (Samsung), Power-Failure Support (Kingston), Complete Power Fail Protection (OCZ). For more information, see SSD Drives Ignore Disk Flushes.

7.6.1. Calculating Write Journal Size

Using SSD drives for write journaling can help you reduce write latencies, thus improving the overall cluster performance. If you have multiple chunk servers on a single host, create a separate SSD journal for each CS.

To determine the size of each CS journal on the SSD, follow these guidelines:

  1. Find out how many HDDs the SSD can service based on Hardware Requirements. You can also use this formula:

    SSD_SSWS * 0.8 / HDD_SSWS


    • SSD_SSWS is the sustained sequential write speed of the SSD.

    • HDD_SSWS is the sustained sequential write speed of an HDD (provided that identical HDD models are used as recommended).

    • 0.8 is the approximate percentage of error.


    The sustained sequential write speed is the average sequential write speed measured over a period of 60 seconds.

  2. Reserve 20% of the SSD volume for normal operation, checksum storage, and metadata if needed. Typically, reserve 1GB of SSD space for checksums per each 1TB of HDD space. The rest of these 20% is reserved for emergency needs and also to prevent the SSD from filling up completely because its performance would then degrade.

  3. Divide the remaining 80% of the SSD volume by the allowed number of HDDs.

For example, a 512 GB SSD rated at 1500 MB/s SSWS will be able to service 1500 * 0.8 / 150 = 8 HDDs rated at 150 MB/s SSWS. And the journal size for each CS (i.e. HDD) will be (512 - 20%) / 8 = 51 GB.


Make sure your hardware follows the Hardware Recommendations

The following table gives a few examples of SSD models and the amount of HDDs they can service:

SSD type

Number of SSDs

Intel SSD 320 Series, Intel SSD 710 Series, Kingston SSDNow E enterprise series, or other SATA 3Gbps SSD models providing 150-200MB/s of sequential write of random data.

1 SSD per up to 3 HDDs

Intel SSD DC S3700 Series, Samsung SM1625 enterprise series, or other SATA 6Gbps SSD models providing at least 300MB/sec of sequential write of random data.

1 SSD per up to 5-6 HDDs

7.6.2. Setting Up Chunk Servers with a Journal on SSD

To set up a CS that stores a journal on an SSD drive, do the following:

  1. Log in to the Node you want to act as a chunk server as root or as a user with root privileges. The Node must have at least one hard disk drive (HDD) and one solid state drive (SSD).

  2. Download and install the following RPM packages: vstorage-ctl, vstorage-libs-shared, and vstorage-chunk-server.

    These packages are available in the Virtuozzo remote repository (this repository is automatically configured for your system when you install Virtuozzo) and can be installed with this command:

    # yum install vstorage-chunk-server
  3. Make sure that cluster discovery is configured for the server. For details, see Configuring Cluster Discovery.

  4. Authenticate the server in the cluster, if it is not yet authenticated:

    # vstorage -c stor1 auth-node
  5. If required, prepare the SSD as described in Preparing Disks for Virtuozzo Storage.

  6. Create the chunk server configuration, repository, and the journal, for example:

    # vstorage -c stor1 make-cs -r /vstorage/stor1-cs -j /ssd/stor1/cs1 -s 30720 -T ssd

    This command:

    1. Makes the /vstorage/stor1-cs directory on your computer’s hard disk drive and configures it for storing data chunks.

    2. Configures your computer as a chunk server and joins it to the stor1 Virtuozzo Storage cluster.

    3. Creates the journal in the /ssd/stor1/cs1 directory on the SSD drive and allocates 30 GB of disk space to this journal.

    4. Tunes the journal for improved write and read performance on SSD, with best results noticeable on random writes on all-flash clusters.


    When choosing a directory for the journal and deciding on its size, allocate the required space for the journal and make sure there is 1GB of SSD space per each 1TB of HDD space for checksums.

  7. Start the chunk server management service vstorage-csd and configure it to start automatically on the chunk server boot:

    # systemctl start vstorage-csd.target
    # systemctl enable vstorage-csd.target

7.6.3. Adding, Destroying, and Configuring CS Journals in Live Storage Clusters


To obtain CS repository paths, use the vstorage -c <cluster> list-services -C command. Adding CS Journals

To add a new journal to a chunk server, use the vstorage configure-cs -a -s command. For example, to add a 2048MB journal to the chunk server CS#1, place it in a directory on an SSD drive mounted to /ssd, and tune the journal for SSDs, run:

# vstorage -c stor1 configure-cs -r <CS_repository_path> \
-a /ssd/stor1-cs1-journal -s 2048 -T ssd

Restart the CS service to apply changes implied by the -T parameter:

# systemctl status vstorage-csd* | grep -m1 "stor1-cs1"
vstorage-csd.stor1.1027.service - vstorage-csd(/vstorage/stor1-cs1)
# systemctl restart vstorage-csd.stor1.1027.service Destroying CS Journals

To destroy a chunk server journal, use the vstorage configure-cs -d command. For example:

# vstorage -c stor1 configure-cs -r <CS_repository_path> -d Moving CS Journals

To change the chunk server journal directory, do the following using the commands above:

  1. Destroy the existing journal

  2. Add a new journal with the required size at the required location. Resizing CS Journals

To resize a chunk server journal, use the vstorage configure-cs -s command. For example, to resize a CS journal to 4096MB:

# vstorage -c stor1 configure-cs -r <CS_repository_path> -s 4096

7.6.4. Disabling Checksumming

Using checksumming, you can provide better reliability and integrity of all data in the cluster. When checksumming is enabled, Virtuozzo Storage generates checksums each time some data in the cluster is modified. When this data is then read, the checksum is computed once more and compared with the already existing value.

By default, data checksumming is automatically enabled for newly created chunk servers that use journaling. If necessary, you can disable this functionality using the -S option when you set up a chunk server, for example:

# vstorage -c stor1 make-cs -r /vstorage/stor1-cs -j /ssd/stor1/cs1 -s 30720 -S

7.6.5. Configuring Data Scrubbing

Data scrubbing is the process of checking data chunks for durability and verifying their contents for readability and correctness. By default, Virtuozzo Storage is set to examine two data chunks per minute on each chunk server in the cluster. If necessary, you can configure this number using the vstorage utility, for example:

# vstorage -c stor1 set-config mds.wd.verify_chunks=3

This command sets the number of chunks to be examined on each chunk server in the stor1 cluster to 3.