Expand specific resources of a container

Guidelines for expansion processes that only involve the addition of a specific resource.

Expanding resources within a container involves dynamically adjusting the allocation of CPU, memory, storage, and other system resources to meet applications' changing demands. By effectively managing these resources, organizations can optimize performance, enhance scalability, and ensure the smooth operation of their containerized applications.

Expansion guidelines

The following commands are available to expand the containers' resources:

• weka cluster container: Run actions on a remote container (or containers for specific sub-commands).

• weka local resources: Run actions locally.

Adhere to the following guidelines when expanding specific resources:

• Specify the container: Run the relevant weka cluster container command with the specific container-id you want to expand. Once you run the command, the container is staged to update in the cluster.

• View existing resources: To view the non-applied configuration, run the weka cluster container resources <container-id> command.

• Apply changes on a specific container: To apply changes on a specific container in the cluster, run the weka cluster container apply <container-ids> command. It is possible to accumulate several changes on a container and apply only once on completion.

• Apply changes on a local server: To apply changes in the local container, run the weka local resources apply command.

• The apply command saves the last configuration: Once the apply command is complete, the last local configuration of the container that successfully joined the cluster is saved. If a failure occurs with the new configuration, the container automatically remains with the existing stable configuration. Run the weka cluster container resources <container-id> --stable command to view the existing configuration.

• Expansion on active or deactivated containers: Some resources can be expanded on active containers, such as adding CPU cores. Others require container deactivation, like setting failure domain.

weka cluster container command description

Command: weka cluster container <sub-command> <container-id> [options]

Some sub-commands accept <container-ids>. See details in the following table.

Subcommands

Sub-command	Description	Comment
activate	Activate the containers.	Specify the list of containers with a space delimiter.
add	Add a container to the cluster.
apply	Apply changes to the resources on the containers.	Specify the list of containers with a space delimiter.
auto-remove-timeout	Set the time to wait before removing the containers from clients if they disconnect from the cluster. The minimum value is 60. Use 0 to disable automatic removal.	This subcommand only applies to clients.
bandwidth	Limit the bandwidth of the containers.
clear-failure	Clear the last failure fields of the containers.	Specify the list of containers with a space delimiter.
cores	Change the number of cores in the containers.	Increasing the number of cores does not require deactivating the container, whereas decreasing the core count requires deactivation.
deactivate	Deactivate the containers.	Specify the list of containers with a space delimiter.
deactivation-check	Check if the provided containers can be deactivated.
dedicate	Set the containers to be dedicated to the WEKA cluster.
failure-domain	Set the failure domain on the container.	Requires deactivating the container.
info-hw	Show hardware information about the containers.
join-secret	Set the secret this container uses when joining or validating other backends.
management-ips	Set the management IPs of the container. To achieve high availability, set two IPs.
memory	Set the RAM size dedicated to the container.
net	List the WEKA-dedicated networking devices in the containers.	Specify the list of containers with a space delimiter.
remove	Remove a container from the cluster.
requested-action	Set the specified containers' requested action to stop, restart, or apply resources gracefully.
resources	Get the resources of the containers.
restore	Restore staged resources of the containers or all containers to their stable state.	Specify the list of containers with a space delimiter.

Options

Option	Description
-b	Only return backend containers.
-c	Only return client containers.
-l	Only return containers that are part of the cluster leadership.
-L	Only return the cluster leader.

Expansion procedures on a remote container

Modify the memory

Run the following command lines on the active container:

weka cluster container memory <container-id> <capacity-memory>
weka cluster container apply <container-ids>

Example

To change the memory of container-id 0 to 1.5 GiB, run the following commands:

weka cluster container memory 0 1.5GiB
weka cluster container apply 0

After reducing the memory allocation for a container, follow these steps to release hugepages on each container:

1. Stop the container locally. Run weka local stop

2. Release hugepages. Run weka local run release_hugepages

3. Restart the container locally. Run weka local start

Modify the network configuration

Run the following command lines on the active container:

weka cluster container net add <container-id> <device>
weka cluster container apply <container-ids>

Example

To add another network device to container-id 0, run the following commands:

weka cluster container net add 0 eth2
weka cluster container apply 0

Modify the container IP addresses

Run the following command lines on the active container:

weka cluster container management-ips <container-id> <management-ips>
weka cluster container apply <container-ids>

Example

To change the management IPs on container-id 0, run the following commands:

weka cluster container management-ips 0 192.168.1.10 192.168.1.20
weka cluster container apply 0

The number of management IP addresses determines whether the container uses high-availability (HA) networking, causing each IO process to use both containers' NICs.

A container with two IP addresses uses HA networking. A container with only one IP does not use HA networking.

If the cluster uses InfiniBand and Ethernet network technologies, you can define up to four IP addresses.

Add CPU cores to a container

You can add dedicated CPU cores to a container locally and on an active container.

For clarity, the following procedure exemplifies expansion on the container running the compute processes.

Decreasing the number of cores, requires container deactivation before setting the number of cores, using the command: weka cluster container deactivate <container-ids>.

Reactivate the container after completing the procedure below.

Procedure

1. Run the following command line to set the number of dedicate cores to the compute container: weka cluster container cores <container-id> <number of total cores> --compute-dedicated-cores <number of total cores> --no-frontends

2. Apply the changes. Run the following command: weka cluster container apply <container-ids>

3. Check the number of cores dedicated to the compute processes. Run the following command: weka cluster container <container-ids>

Example

The following example sets 10 cores to the compute0 container. The container id is 1. It is important to add --no-frontends to allocate the cores dedicated to the compute processes.

weka cluster container cores 1 10 --compute-dedicated-cores 10 --no-frontends
weka cluster container apply 1
weka cluster container 1
//response
ROLES       NODE ID  CORE ID
MANAGEMENT  0        <auto>
COMPUTE     1        <auto>
COMPUTE     2        <auto>
COMPUTE     3        <auto>
COMPUTE     4        <auto>
COMPUTE     5        <auto>
COMPUTE     6        <auto>
COMPUTE     7        <auto>
COMPUTE     8        <auto>
COMPUTE     9        <auto>
COMPUTE     10       <auto>

Expand SSDs only

You can add new SSD drives to a container. However, adding SSD drives may alter the ratio between SSDs and drive cores, potentially impacting performance. For optimal system efficiency, take note of this adjustment when considering expansion.

Procedure

1. Ensure the cluster has a drive core to allocate for the new SSD.

2. Identify the relevant container ID to which you want to add the SSD drive. Run the command: weka cluster container

3. Scan for new drives. Run the command: weka cluster drive scan

4. To add the SSDs, run the following command: weka cluster drive add <container-id> <device-paths> Where: container-id is the Identifier of the drive container to add the local SSD drives. device-paths is a list of block devices that identify local SSDs. It must be a valid Unix network device name. Format: Space-separated strings. Example: /dev/nvme0n1 /dev/nvme1n1

weka local resources command description

You can also modify the resources on a local container by connecting to it and running the weka local resources command equivalent to its weka cluster remote counterpart command.

These local commands have the same semantics as their remote counterpart. You do not specify the container-id as the first parameter. All actions are done on the local container.

Command: weka local resources

Subcommands

Sub-command	Description	Comment
apply	Apply changes to the resources locally.
auto-remove-timeout	Set the time to wait before removing the containers from clients if they disconnect from the cluster. The minimum value is 60. Use 0 to disable automatic removal.	This subcommand only applies to clients.
bandwidth	Limit the bandwidth of the container.
base-port	Change the port range used by the container. WEKA containers require 100 ports to operate.
cores	Change the number of cores in the container.	Increasing the number of cores does not require deactivating the container, whereas decreasing the core count requires deactivation.
dedicate	Set the container to be dedicated to the WEKA cluster.
export	Export stable resources to a file.
failure-domain	Set the container failure-domain.	Requires deactivating the container.
fqdn	Configure the FQDN for other containers for TLS hostname verification when interacting with the cluster.
import	Import resources from a file.
join-ips	Set the IPs and ports of all containers in the cluster. This enables the container to join the cluster using these IPs.
join-secret	Configure the secret used when joining a cluster as a backend.
management-ips	Set the container's management IPs. To achieve high-availability, set two IPs.
memory	Set the RAM size dedicated to the container.
net	List the WEKA-dedicated networking devices in a container.
restore	Restore resources from stable resources.

Options

Option	Description	Comment
--stable	List the resources from the last successful container boot.
-C	The container name.

Example: Set dedicated cores for the compute processes locally

The following example sets 10 cores to the compute0 container. The container id is 1. It is important to add --no-frontends to allocate the cores dedicated to the compute processes. Connect to the relevant server to run the following commands locally.

weka local resources cores 10 --compute-dedicated-cores 10 -C compute0 --no-frontends
weka local resources -C compute0

//response
ROLES       NODE ID  CORE ID
MANAGEMENT  0        <auto>
COMPUTE     1        <auto>
COMPUTE     2        <auto>
COMPUTE     3        <auto>
COMPUTE     4        <auto>
COMPUTE     5        <auto>
COMPUTE     6        <auto>
COMPUTE     7        <auto>
COMPUTE     8        <auto>
COMPUTE     9        <auto>
COMPUTE     10       <auto>

Graceful container management: ensuring safe actions

The weka local stop, restart, and apply resources commands perform graceful stop operations by default, ensuring actions are executed safely to minimize the risk of unexpected issues or disruptions. The system automatically prioritizes safety during cluster maintenance without requiring the --graceful option. If non-graceful action is required, add the --force option.

Additionally, stopping and starting dependent containers is the default behavior for the weka local stop/start commands, providing seamless management of dependent services. To override this behavior, use the --skip-start-and-enable-dependent or --skip-stop-and-enable-dependent options.

How the default graceful process works:

• Action Initiation: Sends a request to the container for the specified action (STOP, RESTART, or APPLY_RESOURCES).

• Safety check: Evaluates feasibility based on current state and safety constraints (for example, ensuring sufficient resources post-action).

• Draining and execution: If safe, the container transitions to the DRAINING state to complete ongoing operations. Once DRAINED, the action is executed.

Example: Prioritizing stability

If stopping a container would violate minimum failure domain requirements, the graceful stop prevents the action to maintain system health.

The graceful process applies exclusively to cluster containers, not to protocol containers.

Example: prioritizing stability

CONTAINER ID  HOSTNAME  CONTAINER  IPS             STATUS          REQUESTED ACTION  REQUESTED ACTION FAILURE
0             Host-0    drives0    10.108.206.201  UP              STOP              Upon completion of this operation, there are 4 reliable containers available for cluster leadership, while the requirement is for 5.                 
6             Host-0    compute0   10.108.206.201  DRAINED (DOWN)  STOP                                 
12            Host-0    frontend0  10.108.206.201  DRAINING        RESTART