Scaling Up an Existing HA Group
This section shows you the steps to increase the scaling parameters for the primary and backup software event brokers in a high-availability (HA) group using the Solace CLI .
This procedure changes system-wide scaling parameters. Upon completion, you may need to modify other parameters for individual Message VPNs. For example, you may need to modify the maximum number of client connections permitted for a specific Message VPN (Configuring Maximum Connections) or for a specific client profile (see Configuring Max Connections Per Username). For more information, see Configuring Message VPNs.
System scaling parameters can only be increased.
This procedure is service affecting in versions 10.11.0 and earlier. To change system scaling parameters other than max-subscriptions or the Kafka scaling parameters (Kafka bridges or Kafka broker connections) in these versions, you must shut down the message backbone and message spool.
The following steps show you how to increase the scaling parameters for event brokers for both the primary and backup:
Step 1: Review System Resource Requirements and HA Status
Step 2: Increase the Value of the Scaling Parameters
Step 1: Review System Resource Requirements and HA Status
Before you increase the value of any scaling parameters of your brokers:
- Ensure that you can adequately provision your system for the new scaling parameter values. See System Resource Requirements for details about the available tiers and the required resources for each one.
- Verify that HA is operationally up on all event brokers in the HA group and that the
Activity Status for each event broker is correct. You can use the show redundancy command to check operational states, as shown in the following example.
For example, in versions 10.11.0 and earlier, if you have two brokers in an HA pair, where solace-primary is the primary and solace-backup is the backup, the output of the show redundancy command looks similar to the following for the primary broker (note that
Redundancy Status is Up, Active-Standby Role is Primary, the Activity Status of the Primary Virtual Router is Local Active, and the Message Spool Status is AD-Active):
solace-primary# show redundancy
Configuration Status : Enabled
Redundancy Status : Up
Operating Mode : Message Routing Node
Switchover Mechanism : Hostlist
Auto Revert : No
Redundancy Mode : Active/Standby
Active-Standby Role : Primary
Mate Router Name : solace-backup
ADB Link To Mate : Up
ADB Hello To Mate : Up
Primary Virtual Router Backup Virtual Router
---------------------- ----------------------
Activity Status Local Active Shutdown
Routing Interface intf0:1 intf0:1
Routing Interface Status Up
VRRP Status Initialize
VRRP Priority 250
Message Spool Status AD-Active
Priority Reported By Mate Standby
The output of the show redundancy command looks similar to the following for the backup broker (note that
Redundancy Status is Up, Active-Standby Role is Backup, the Activity Status of the Backup Virtual Router is Mate Active, and the Message Spool Status is AD-Standby):
solace-backup# show redundancy
Configuration Status : Enabled
Redundancy Status : Up
Operating Mode : Message Routing Node
Switchover Mechanism : Hostlist
Auto Revert : No
Redundancy Mode : Active/Standby
Active-Standby Role : Backup
Mate Router Name : solace-primary
ADB Link To Mate : Up
ADB Hello To Mate : Up
Primary Virtual Router Backup Virtual Router
---------------------- ----------------------
Activity Status Shutdown Mate Active
Routing Interface intf0:1 intf0:1
Routing Interface Status Up
VRRP Status Initialize
VRRP Priority 100
Message Spool Status AD-Standby
Priority Reported By Mate Active
In versions 10.11.1 and later, either event broker can be active before you increase the value of the scaling parameters.
Step 2: Increase the Value of the Scaling Parameters
The primary and backup event brokers within an HA group must be configured to use the same system scaling parameters. If this is misconfigured, the HA group will not work properly. You can use the show redundancy command to check operational states.
For replicated sites, the primary and replication event broker sites should have the same resources and maximum number of client connections.
- Scaling parameters are not automatically synchronized. For further information, refer to Config-Sync Configuration.
- This procedure changes system-wide scaling parameters. After completing this procedure, you can then modify other parameters for specific Message VPNs (for example, Configuring Maximum Connections) or for clients using a specific client profile (see Configuring Services).
In versions 10.11.0 and earlier, before proceeding with these steps, ensure that the message spool status of the primary event broker is AD-Active and the message spool status of the backup broker is AD-Standby by running show message-spool or following the example in Step 1: Review System Resource Requirements and HA Status.
In versions 10.9.1 and earlier of the event broker, any change to a single parameter requires an event broker restart. However, with versions 10.10.0 and later, you can now upscale multiple parameters before an event broker restart is required. To increase the value of system scaling parameters for an HA group, click on your event broker version below and follow the steps provided:
Increase the Value of Scaling Parameters in Event Broker Versions 10.11.1 and Later
- On both the primary and backup event brokers, in the Solace CLI, enter the
show system detail command to review the current scaling values. You can also review the memory, cores, and storage requirements that correspond to the requirements output from the system resource calculator (see System Resource Calculator). This command helps you evaluate if additional resources must be added: solace> show system detail
System Uptime: 1d 0h 45m 21s
Last Restart Reason: User request
Scaling:
Max Bridges: 25
Max Connections: 100
Max Queue Messages: 100M
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Subscriptions: 500000
Topic Routing:
Subscription Exceptions: Enabled
Subscription Exceptions Defer: Enabled
System Resources for Virtual Machine
System Resource Available Required Units
--------------------------------- ------------ ------------ ----------
CPU
Cores 2 2
Memory
---Press any key to continue, or `q' to quit---
RAM 5.0 4.0 GiB
Storage Devices
/dev/dm-0 9.8 Mi 12.9 Mi 1K-Blocks
contains: spool-cache
contains: spool-cache-backup
contains: config
contains: diagnostics
contains: jail
contains: spool
contains: var
/dev/dm-6 6.0 Mi 1.4 Mi 1K-Blocks
contains: root
- On the standby event broker (either primary or backup depending on the state of your deployment), update the required system scaling parameters.
You can increase the values of the following system scaling parameters:
There are two ways to increase scaling parameter values:
- Non-Interactive CLI mode: Use the
scale command followed by the parameter name and value. You can upscale as many parameters as required in one command using this pattern: scale <parameter 1> <value 1> <parameter 2> <value 2> ... <parameter n> <value n>. For example, step 1 shows that the initial value of the client connection limit is 100, and the maximum number of queue messages is 100 million. To increase the connection limit to 1,000 and the queue message limit to 240 million, enter the following commands:solace2(configure)# system
solace2(configure/system)# scaling
solace2(configure/system/scaling)# scale max-connections 1000 max-queue-messages 240
This command causes a reload of the system.
Do you want to continue (y/n)? y
- Interactive CLI mode: Use the
scale command without any parameters to display a list of your current scaling parameter values. The CLI then prompts you to enter new values for each parameter in the following order:max-connectionsmax-bridgesmax-kafka-bridgesmax-kafka-broker-connectionsmax-queue-messages-in-millionsmax-subscriptions
For each prompt, the current parameter value is displayed in square brackets, and if you do not enter a new value, the value remains the same. For example, step 1 shows that the initial value of the client connection limit is 100, and the maximum number of queue messages is 100 million. To increase the connection limit to 1,000 and the queue message limit to 240 million, enter the following commands:solace2(configure)# system
solace2(configure/system)# scaling
solace2(configure/system/scaling)# scale
Current Scaling:
Max Connections: 100
Max Bridges: 25
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Queue Messages: 100M
Max Subscriptions: 500000
Enter max connections (or q to quit) [100]: 1000
Max bridges should not be greater than max connections (1000)
Enter max bridges (or q to quit) [25]:
Max kafka bridges should not be greater than max connections (1000)
Enter max kafka bridges (or q to quit) [0]:
Enter max kafka connections (or q to quit) [0]:
Enter max queue messages in millions (or q to quit) [100]: 240
Max subscriptions should be greater than max connections (1000)
Enter max subscriptions (or q to quit) [500000]:
Updated Scaling:
Max Connections: 1000
Max Bridges: 25
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Queue Messages: 240M
Max Subscriptions: 500000
This command causes a reload of the system.
Do you want to continue (y/n)? y
Changing the value of system scaling parameters causes the system to reload, stopping the container. For container images, you may need to manually restart the container, depending on the restart policy of your container runtime. In addition, if changes to the scaling parameters require additional resources, such as additional CPUs or more memory, you may need to recreate the container using a modified command line. For details, see the System Resource Calculator.
If your HA cluster is running in Kubernetes, the backup and monitoring pods may restart automatically. During this process, the READY status reported by kubectl show pods may be incorrect.
- Restart or recreate the container if required, then enter the Solace CLI again and confirm the new parameter has been applied.
In this example, the maximum number of client connections has been increased to 1,000 and maximum number of queue messages to 240 million.
solace2> show system
System Uptime: 1d 0h 49m 13s
Last Restart Reason: User request
Scaling:
Max Bridges: 25
Max Connections: 1000
Max Queue Messages: 240M
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Subscriptions: 500000
Topic Routing:
Subscription Exceptions: Enabled
Subscription Exceptions Defer: Enabled
- On the standby event broker, verify that the
Redundancy Status is Up, the message spool Synchronization Status is Synced, and the Operational Status is AD-Standby. This ensures that the current state of the active event broker has been copied to the standby.
- On the active event broker, run the
release-activity command to move activity to the standby.solace1> enable
solace1# configure
solace1(configure)# redundancy release-activity
- On the previously active, now standby event broker, update the system scaling parameters to match the settings on the currently active event broker.
Changing the value of system scaling parameters causes the system to reload, stopping the container. For container images, you may need to manually restart the container, depending on the restart policy of your container runtime. In addition, if changes to the scaling parameters require additional resources, such as additional CPUs or more memory, you may need to recreate the container using a modified command line. For details, see the System Resource Calculator.
- Restart or recreate the container if required, then enter the Solace CLI again and confirm the new parameter has been applied by running the
show system command.For example:
solace1> show system
System Uptime: 1d 0h 49m 13s
Last Restart Reason: User request
Scaling:
Max Bridges: 25
Max Connections: 1000
Max Queue Messages: 240M
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Subscriptions: 500000
Topic Routing:
Subscription Exceptions: Enabled
Subscription Exceptions Defer: Enabled
- On the previously active, now standby event broker, verify that the
Redundancy Status is Up, the message spool Synchronization Status is Synced, and the Operational Status is AD-Standby.
- Enable the event broker to take activity at the new scale by running the
no release-activity command. solace1> enable
solace1# configure
solace1(configure)# redundancy no release-activity
- Verify that the
Redundancy Status is Up on all nodes in the HA group:
On the standby event broker:
solace1> show redundancy
On the active event broker:
solace2> show redundancy
On the monitoring node:
solace-monitoring> show redundancy
Increase the Value of Scaling Parameters in Event Broker Versions 10.10.0 to 10.11.0
In the steps that follow, solace-primary is the primary event broker, and solace-backup is the backup event broker.
- On the primary event broker, in the Solace CLI, enter the
show system detail command to review the current scaling values. You can also review the memory, cores, and storage requirements that correspond to the requirements output from the system resource calculator (see System Resource Calculator). This command helps you evaluate if additional resources must be added: solace-primary> show system detail
System Uptime: 1d 0h 45m 21s
Last Restart Reason: User request
Scaling:
Max Connections: 100
Max Bridges: 25
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Queue Messages: 100M
Max Subscriptions: 500000
Topic Routing:
Subscription Exceptions: Enabled
Subscription Exceptions Defer: Enabled
System Resources for Virtual Machine
System Resource Available Required Units
--------------------------------- ------------ ------------ ----------
CPU
Cores 2 2
Memory
---Press any key to continue, or `q' to quit---
RAM 5.0 4.0 GiB
Storage Devices
/dev/dm-0 9.8 Mi 12.9 Mi 1K-Blocks
contains: spool-cache
contains: spool-cache-backup
contains: config
contains: diagnostics
contains: jail
contains: spool
contains: var
/dev/dm-6 6.0 Mi 1.4 Mi 1K-Blocks
contains: root
- On the backup event broker, shut down the message backbone service and message
spool:
If you are increasing max-subscriptions or the Kafka scaling parameters (max-kafka-bridges or max-kafka-broker-connections), you do not need to shut down the msg-backbone or message-spool
solace-backup(configure)# service msg-backbone shutdown
All clients will be disconnected.
Do you want to continue (y/n)? y
solace-backup(configure)# hardware message-spool shutdown
All message spooling will be stopped.
Do you want to continue (y/n)? y
- On the primary event broker, shut down the message backbone service and message spool:
If you are increasing max-subscriptions or the Kafka scaling parameters (max-kafka-bridges or max-kafka-broker-connections), you do not need to shut down the msg-backbone or message-spool.
solace-primary(configure)# service msg-backbone shutdown
All clients will be disconnected.
Do you want to continue (y/n)? y
solace-primary(configure)# hardware message-spool shutdown
All message spooling will be stopped.
Do you want to continue (y/n)? y
- On the primary event broker, update the required system scaling parameters.
You can increase the values of the following system scaling parameters:
There are two ways to increase scaling parameter values:
- Non-Interactive CLI mode: Use the
scale command followed by the parameter name and value. You can upscale as many parameters as required in one command using this pattern: scale <parameter 1> <value 1> <parameter 2> <value 2> ... <parameter n> <value n>. For example, step 1 shows that the initial value of the client connection limit is 100, and the maximum number of queue messages is 100 million. To increase the connection limit to 1,000 and the queue message limit to 240 million, enter the following commands:solace(configure)# system
solace(configure/system)# scaling
solace(configure/system/scaling)# scale max-connections 1000 max-queue-messages 240
This command causes a reload of the system.
Do you want to continue (y/n)? y
Moving ADB messages to disk : 100%
Backing up ADB config to disk: 100%
Performing database consolidation
- Interactive CLI mode: Use the
scale command without any parameters to display a list of your current scaling parameter values. The CLI then prompts you to enter new values for each parameter in the following order:connection-limitmax-bridgesmax-kafka-bridgesmax-kafka-broker-connectionsmax-messages-in-millionsmax-subscriptions
For each prompt, the current parameter value is displayed in square brackets, and if you do not enter a new value, the value remains the same. For example, step 1 shows that the initial value of the client connection limit is 100, and the maximum number of queue messages is 100 million. To increase the connection limit to 1,000 and the queue message limit to 240 million, enter the following commands:solace(configure)# system
solace(configure/system)# scaling
solace(configure/system/scaling)# scale
Current Scaling:
Max Connections: 100
Max Bridges: 25
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Queue Messages: 100M
Max Subscriptions: 500000
Enter max connections [100]: 1000
Max bridges should not be greater than max connections (1000)
Enter max bridges [25]:
Max kafka bridges should not be greater than max connections (1000)
Enter max kafka bridges [0]:
Enter max kafka connections [0]:
Enter max queue messages in millions [100]: 240
Max subscriptions should be greater than max connections (1000)
Enter max subscriptions [500000]:
Updated Scaling:
Max Connections: 1000
Max Bridges: 25
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Queue Messages: 240M
Max Subscriptions: 500000
This command causes a reload of the system.
Do you want to continue (y/n)? y
Moving ADB messages to disk : 100%
Backing up ADB config to disk: 100%
Performing database consolidation
Changing the value of system scaling parameters causes the system to reload, stopping the container. For container images, you may need to manually restart the container, depending on the restart policy of your container runtime. In addition, if changes to the scaling parameters require additional resources, such as additional CPUs or more memory, you may need to recreate the container using a modified command line. For details, see the System Resource Calculator.
If your HA cluster is running in Kubernetes, the backup and monitoring pods may restart automatically. During this process, the READY status reported by kubectl show pods may be incorrect.
- Restart or recreate the container if required, then enter the Solace CLI again and confirm the new parameter has been applied.
In this example, the maximum number of client connections has been increased to 1,000 and maximum number of queue messages to 240 million.
solace-primary> show system
System Uptime: 1d 0h 49m 13s
Last Restart Reason: User request
Scaling:
Max Connections: 1000
Max Bridges: 25
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Queue Messages: 240M
Max Subscriptions: 500000
Topic Routing:
Subscription Exceptions: Enabled
Subscription Exceptions Defer: Enabled
- In the Solace CLI, enable the message spool and message backbone for the primary event broker:
If you are increasing max-subscriptions or the Kafka scaling parameters (max-kafka-bridges or max-kafka-broker-connections), you do not need to shut down the msg-backbone or message-spool.
solace-primary(configure)# no hardware message-spool shutdown
solace-primary(configure)# no service msg-backbone shutdown
- On the primary event broker, verify that the message spool’s
Operational Status is AD-Active:
solace-primary(configure/service/msg-backbone) show message-spool
Config Status: Enabled (Primary)
. . .
Operational Status: AD-Active
. . .
ADB Disk Total
Current Persistent Store Usage (MB) 0.0000 19.0375 19.0375
Number of Messages Currently Spooled 0 1 000 1 000
If you are increasing parameters other than max-subscriptions or the Kafka scaling parameters (Kafka bridges or Kafka broker connections), the primary message spool status must be AD-Active before continuing with this procedure or message loss will occur.
If you are increasing max-subscriptions or the Kafka scaling parameters (max-kafka-bridges or max-kafka-broker-connections), verify that the status on the primary event broker is AD-Standby and on the backup it is AD-Active. When you upscale the backup, the status will change to AD-Standby.
- On the backup event broker, update the system scaling parameters to match the settings on the primary broker.
Changing the value of system scaling parameters causes the system to reload, stopping the container. For container images, you may need to manually restart the container, depending on the restart policy of your container runtime. In addition, if changes to the scaling parameters require additional resources, such as additional CPUs or more memory, you may need to recreate the container using a modified command line. For details, see the System Resource Calculator.
- Restart or recreate the container if required, then enter the Solace CLI again and confirm the new parameter has been applied by running the
show system command.For example:
solace-backup> show system
System Uptime: 1d 0h 49m 13s
Last Restart Reason: User request
Scaling:
Max Bridges: 25
Max Connections: 1000
Max Queue Messages: 240M
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Subscriptions: 500000
Topic Routing:
Subscription Exceptions: Enabled
Subscription Exceptions Defer: Enabled
- In the Solace CLI, enable the message spool and message backbone service for the backup event broker:
If you are increasing max-subscriptions or the Kafka scaling parameters (max-kafka-bridges or max-kafka-broker-connections), you do not need to shut down the msg-backbone or message-spool.
solace-backup(configure)# no hardware message-spool shutdown
solace-backup(configure)# no service msg-backbone shutdown
- On the backup event broker, verify that the message spool’s
Operational Status is AD-Standby:
solace-backup(configure/service/msg-backbone)# show message-spool
Config Status: Enabled (Backup)
. . .
Operational Status: AD-Standby
. . .
ADB Disk Total
Current Persistent Store Usage (MB) 0.0000 0.0000 0.0000
Number of Messages Currently Spooled 0 0 0
- Verify that the
Redundancy Status is Up on all nodes in the HA group:
On the primary event broker:
solace-primary> show redundancy
On the backup event broker:
solace-backup> show redundancy
On the monitoring node:
solace-monitoring> show redundancy
Increase the Value of Scaling Parameters in Event Broker Versions 10.9.1 and Earlier
In the steps that follow, solace-primary is the primary event broker, and solace-backup is the backup event broker.
- On the primary event broker, in the Solace CLI, enter the
show system detail command to review the current scaling values. You can also review the memory, cores, and storage requirements that correspond to the requirements output from the system resource calculator (see System Resource Calculator). This command helps you evaluate if additional resources must be added: solace-primary> show system detail
System Uptime: 1d 0h 45m 21s
Last Restart Reason: User request
Scaling:
Max Bridges: 25
Max Connections: 100
Max Queue Messages: 100M
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Subscriptions: 500000
Topic Routing:
Subscription Exceptions: Enabled
Subscription Exceptions Defer: Enabled
System Resources for Virtual Machine
System Resource Available Required Units
--------------------------------- ------------ ------------ ----------
CPU
Cores 2 2
Memory
---Press any key to continue, or `q' to quit---
RAM 5.0 4.0 GiB
Storage Devices
/dev/dm-0 9.8 Mi 12.9 Mi 1K-Blocks
contains: spool-cache
contains: spool-cache-backup
contains: config
contains: diagnostics
contains: jail
contains: spool
contains: var
/dev/dm-6 6.0 Mi 1.4 Mi 1K-Blocks
contains: root
- On the backup event broker, shut down the message backbone service and message
spool:
If you are increasing max-subscriptions or the Kafka scaling parameters (max-kafka-bridges or max-kafka-broker-connections), you do not need to shut down the msg-backbone or message-spool
solace-backup(configure)# service msg-backbone shutdown
All clients will be disconnected.
Do you want to continue (y/n)? y
solace-backup(configure)# hardware message-spool shutdown
All message spooling will be stopped.
Do you want to continue (y/n)? y
- On the primary event broker, shut down the message backbone service and message spool:
If you are increasing max-subscriptions or the Kafka scaling parameters (max-kafka-bridges or max-kafka-broker-connections), you do not need to shut down the msg-backbone or message-spool.
solace-primary(configure)# service msg-backbone shutdown
All clients will be disconnected.
Do you want to continue (y/n)? y
solace-primary(configure)# hardware message-spool shutdown
All message spooling will be stopped.
Do you want to continue (y/n)? y
- On the primary event broker, update the required system scaling parameter.
You can increase the values of the following system scaling parameters:
For example, Step 1 shows that the initial value of the client connection limit is 100. To increase the connection limit to 1,000, enter the following commands:
solace-primary(configure)# system
solace-primary(configure/system)# scaling
solace-primary(configure/system/scaling)# max-connections 1000
Changing the value of system scaling parameters causes the system to reload, stopping the container. For container images, you may need to manually restart the container, depending on the restart policy of your container runtime. In addition, if changes to the scaling parameters require additional resources, such as additional CPUs or more memory, you may need to recreate the container using a modified command line. For details, see the System Resource Calculator.
If your HA cluster is running in Kubernetes, the backup and monitoring pods may restart automatically. During this process, the READY status reported by kubectl show pods may be incorrect.
- Restart or recreate the container if required, then enter the Solace CLI again and run the
show system command to confirm the new parameter has been applied.
In this example, the maximum number of client connections has been increased to 1,000.solace-primary> show system
System Uptime: 1d 0h 49m 13s
Last Restart Reason: User request
Scaling:
Max Bridges: 25
Max Connections: 1000
Max Queue Messages: 100M
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Subscriptions: 500000
Topic Routing:
Subscription Exceptions: Enabled
Subscription Exceptions Defer: Enabled
- Optionally, repeat the preceding two steps to increase another scaling parameter.
- In the Solace CLI, enable the message spool and message backbone for the primary event broker:
If you are increasing max-subscriptions or the Kafka scaling parameters (max-kafka-bridges or max-kafka-broker-connections), you do not need to shut down the msg-backbone or message-spool.
solace-primary(configure)# no hardware message-spool shutdown
solace-primary(configure)# no service msg-backbone shutdown
- On the primary event broker, verify that the message spool’s
Operational Status is AD-Active:
solace-primary(configure/service/msg-backbone) show message-spool
Config Status: Enabled (Primary)
. . .
Operational Status: AD-Active
. . .
ADB Disk Total
Current Persistent Store Usage (MB) 0.0000 19.0375 19.0375
Number of Messages Currently Spooled 0 1 000 1 000
If you are increasing parameters other than max-subscriptions or the Kafka scaling parameters (Kafka bridges or Kafka broker connections), the primary message spool status must be AD-Active before continuing with this procedure or message loss will occur.
If you are increasing max-subscriptions or the Kafka scaling parameters (max-kafka-bridges or max-kafka-broker-connections), verify that the status on the primary event broker is AD-Standby and on the backup it is AD-Active. When you upscale the backup, the status will change to AD-Standby.
- On the backup event broker, update the system scaling parameters to match the settings on the primary broker.
For example, to increase the connection limit to 1,000, enter the following commands:
solace-backup(configure)# system
solace-backup(configure/system)# scaling
solace-backup(configure/system/scaling)# max-connections 1000
Changing the value of system scaling parameters causes the system to reload, stopping the container. For container images, you may need to manually restart the container, depending on the restart policy of your container runtime. In addition, if changes to the scaling parameters require additional resources, such as additional CPUs or more memory, you may need to recreate the container using a modified command line. For details, see the System Resource Calculator.
- Restart or recreate the container if required, then enter the Solace CLI again and confirm the new parameter has been applied by running the
show system command.For example:
solace-backup> show system
System Uptime: 1d 0h 49m 13s
Last Restart Reason: User request
Scaling:
Max Bridges: 25
Max Connections: 1000
Max Queue Messages: 100M
Max Kafka Bridges: 0
Max Kafka Broker Connections: 0
Max Subscriptions: 500000
Topic Routing:
Subscription Exceptions: Enabled
Subscription Exceptions Defer: Enabled
- Optionally, repeat the preceding two steps to increase another scaling parameter to match the settings on the primary event broker.
- In the Solace CLI, enable the message spool and message backbone service for the backup event broker:
If you are increasing max-subscriptions or the Kafka scaling parameters (max-kafka-bridges or max-kafka-broker-connections), you do not need to shut down the msg-backbone or message-spool.
solace-backup(configure)# no hardware message-spool shutdown
solace-backup(configure)# no service msg-backbone shutdown
- On the backup event broker, verify that the message spool’s
Operational Status is AD-Standby:
solace-backup(configure/service/msg-backbone)# show message-spool
Config Status: Enabled (Backup)
. . .
Operational Status: AD-Standby
. . .
ADB Disk Total
Current Persistent Store Usage (MB) 0.0000 0.0000 0.0000
Number of Messages Currently Spooled 0 0 0
- Verify that the
Redundancy Status is Up on all nodes in the HA group:
On the primary event broker:
solace-primary> show redundancy
On the backup event broker:
solace-backup> show redundancy
On the monitoring node:
solace-monitoring> show redundancy