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 specificcontainer-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-id>
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: You can dynamically expand some of the resources on active containers and others only after deactivating the container. For example, you can add CPU cores only on a deactivated container.
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 |
---|---|---|
| Show hardware information about the containers. | |
| Set the failure domain on the container. | Can only be done on a deactivated container. |
| Set the containers as dedicated to the WEKA cluster. | |
| Limit the bandwidth of the containers. | |
| Change the number of cores in the containers. | Can only be done on a deactivated container. |
| Set the RAM size dedicated to the container. | |
| Set the time to wait before removing the containers if it disconnects from the cluster. The minimum value is 60. Use 0 to disable automatic removal. | This subcommand only applies to clients. |
| Set the management IPs of the container. To achieve high availability, set two IPs. | |
| Get the resources of the containers. | |
| Restore staged resources of the containers or all containers to their stable state. | Specify the list of containers with a space delimiter. |
| Apply changes to the resources on the containers. | Specify the list of containers with a space delimiter. |
| Activate the containers. | Specify the list of containers with a space delimiter. |
| Deactivate the containers. | Specify the list of containers with a space delimiter. |
| Clear the last failure fields of the containers. | Specify the list of containers with a space delimiter. |
| Add a container to the cluster. | |
| Remove a container from the cluster. | |
| List the WEKA-dedicated networking devices in the containers. | 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:
After reducing the memory allocation for a container, follow these steps to release hugepages on each container:
Stop the container locally. Run
weka local stop
Release hugepages. Run
weka local run release_hugepages
Restart the container locally. Run
weka local start
Modify the network configuration
Run the following command lines on the active container:
Modify the container IP addresses
Run the following command lines on the active container:
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 a deactivated container. The added cores must be dedicated to a specific process type: compute, drives, or frontend.
For clarity, the following procedure exemplifies expansion on the container running the compute processes.
Procedure
Deactivate the container. Run the following command:
weka cluster container deactivate <container-ids>
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
Apply the changes. Run the following command:
weka cluster container apply <containr-id>
Check the number of cores dedicated to the compute processes. Run the following command:
weka cluster container <container-ids>
Activate the container. Run the following command:
weka cluster container activate <container-ids>
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
Ensure the cluster has a drive core to allocate for the new SSD. If a drive core is required, deactivate the container and then add the drive core to the container. See Add CPU cores to a container.
Identify the relevant container ID to which you want to add the SSD drive. Run the command:
weka cluster container
Scan for new drives. Run the command:
weka cluster drive scan
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 |
---|---|---|
| Import resources from a file. | |
| Export stable resources to a file. | |
| Restore resources from stable resources. | |
| Apply changes to the resources locally. | |
| Change the number of cores in the container. | Can only be done on a deactivated container. |
| Change the port-range used by the container. Weka containers require 100 ports to operate. | |
| Set the RAM size dedicated to the container. | |
| Set the container as dedicated to the WEKA cluster. | |
| Limit the bandwidth of the container. | |
| Set the container's management IPs. To achieve high-availability, set two IPs. | |
| Set the IPs and ports of all containers in the cluster. This enables the container to join the cluster using these IPs. | |
| Set the container failure-domain. | Can only be done on a deactivated container. |
| List the WEKA-dedicated networking devices in a container. |
Options
Option | Description | Comment |
---|---|---|
| List the resources from the last successful container boot. | |
| The container name. |
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.
Last updated