Storage Configuration

The software message broker stores state information in PubSub+ specific constructs called storage-elements that abstract the physical location of the message broker's state information storage. Storage-elements are portable, independent entities, and when planning for production deployments, it's recommended that they be placed on appropriately sized external storage volumes. It's important to optimize their location, capacity, and speed, and in this section we'll discuss the requirements you need to keep in mind when externalizing them.

We'll discuss the basic concepts underlying how a software message broker manages and stores data, and use that knowledge to show you how to efficiently provision storage in a production deployment. Given that such optimizations are highly dependent on the specifics of your environment we'll only discuss the basics, and provide some simple configuration examples that are illustrative of the principles you'll need to understand. If you need help sorting out the particulars of your situation, it's recommended that you contact Solace Support.

Key Points

In the subsections that follow we're going to dive into the details on how the Solace PubSub+ software message broker stores data, and what you should keep in mind when planning storage for a production deployment. We'll also give some examples on how to assign storage-elements to external storage. Here are the key points that'll be discussed.

  1. The software message broker's state information is stored in portable, independent constructs called storage-elements.
  2. There are 6 storage-elements: jail, diagnostics, var, adb, adbBackup, and spool.
  3. For production deployments, one or more storage-elements may need to be migrated to external storage, and the characteristics of that storage will depend on,
    • the software message broker's configured connection scaling tier
    • the storage-element's IOPS
    • the storage-element's write load
    • the need to persist data; for example, the need to support upgrading
  4. Storage-elements are portable, independent entities, and each can be configured to reside on its own separate external volume, or in combinations on shared volumes.
  5. Software message broker Docker Images and software message broker Machine & Cloud Images use different techniques for the assignment of storage-elements to external storage.

What you can do next

Storage-Element Characteristics & Requirements

Storage-elements are PubSub+ specific constructs used by the software message broker that abstract the physical location of state information storage. All ephemeral and persistent data within a software message broker is written to storage-elements. They are portable and independent entities which makes them easy to assign to external storage, either on an individual, one-to-one mapping basis, or in combinations.

The following table lists all six storage-elements, and explains what each is for in the 'Use' column. As well, the table lists their associated mount points, shows the IOPS recommendation for an external device, and notes the recommended persistence and associated write load.

Storage-Element Properties

Storage Element

Use Mounted On IOPS Persisted? Write Load
jail Storage for logs and backup configuration files. This storage-element is used during an upgrade of the configuration and spool. /usr/sw/jail Medium Yes  
diagnostics Storage for diagnostic data. /var/lib/solace/diags Medium Yes  
spool Storage for spooled messages. This storage-element is used during an upgrade of the configuration and spool. /usr/sw/internalSpool High Yes High
adb Storage for the state of undelivered messages. This storage-element is used during an upgrade of the configuration and spool. /usr/sw/internalSpool/softAdb High Yes High
adbBackup Storage for run-time state used for recovery during system shutdown. This storage-element is used during an upgrade of configuration and spool /usr/sw/adb Low Yes Low
var Storage for the software message broker's Docker container configuration. /usr/sw/var Medium Yes  

In the above table, IOPS means 'Input / Output Operations Per Second' and the column contains a recommendation for the particular storage-element. As a general recommendation, 'High' indicates that message delivery performance is related to the IOPS performance of the underlying physical media, and 'Medium' indicates that system stability is related to the underlying physical media.

Write Load is a general term used to describe the amount of data written to physical media per unit time. A High Write Load indicates that the data content changes frequently.

When a message broker is configured to operate at a particular connection scaling tier, various application limits, such as client usernames, subscriptions, and flows, are automatically scaled to match the capabilities of the newly configured connection scaling tier. And, with increasing connection scale, storage-element space requirements also increase. The following table lists the minimum recommended storage-element space you need to provision for each scaling tier.

Minimum Recommended Storage-Element Size per Scaling Tier

Scaling Tier >

Storage-Element v

up to 100

(GB)

up to 1,000

(GB)

up to 10,000

(GB)

up to 100,000

(GB)

up to 200,000

(GB)

jail 1.1 1.1 1.1 1.1 1.1
diagnostics 2.5 8.6 10.7 21.5 21.5
spool 1.1 1.1 2.2 2.2 4.3
adb 1.3 1.9 2.2 2.7 3.2
adbBackup 0.7 0.7 1.1 1.1 2.2
var 0.2 0.2 0.2 1.1 1.1

Next Steps

The procedures to migrate storage-elements to external storage depend on the type of software message broker image you're using: