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 containercommand with the specificcontainer-idyou 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 applycommand.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> --stablecommand 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
info-hw
Show hardware information about the containers.
failure-domain
Set the failure domain on the container.
Can only be done on a deactivated container.
dedicate
Set the containers as dedicated to the WEKA cluster.
bandwidth
Limit the bandwidth of the containers.
cores
Change the number of cores in the containers.
Can only be done on a deactivated container.
memory
Set the RAM size dedicated to the container.
auto-remove-timeout
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.
management-ips
Set the management IPs of the container. To achieve high availability, set two IPs.
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.
apply
Apply changes to the resources on the containers.
Specify the list of containers with a space delimiter.
activate
Activate the containers.
Specify the list of containers with a space delimiter.
deactivate
Deactivate the containers.
Specify the list of containers with a space delimiter.
clear-failure
Clear the last failure fields of the containers.
Specify the list of containers with a space delimiter.
add
Add a container to the cluster.
remove
Remove a container from the cluster.
net
List the WEKA-dedicated networking devices in the containers.
Specify the list of containers with a space delimiter.
Options
-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 stopRelease hugepages. Run
weka local run release_hugepagesRestart 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-frontendsApply the changes. Run the following command:
weka cluster container apply <container-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
Identify the relevant container ID to which you want to add the SSD drive. Run the command:
weka cluster containerScan for new drives. Run the command:
weka cluster drive scanTo add the SSDs, run the following command:
weka cluster drive add <container-id> <device-paths>Where:container-idis the Identifier of the drive container to add the local SSD drives.device-pathsis 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
import
Import resources from a file.
export
Export stable resources to a file.
restore
Restore resources from stable resources.
apply
Apply changes to the resources locally.
cores
Change the number of cores in the container.
Can only be done on a deactivated container.
base-port
Change the port-range used by the container. Weka containers require 100 ports to operate.
memory
Set the RAM size dedicated to the container.
dedicate
Set the container as dedicated to the WEKA cluster.
bandwidth
Limit the bandwidth of the container.
management-ips
Set the container's management IPs. To achieve high-availability, set two IPs.
join-ips
Set the IPs and ports of all containers in the cluster. This enables the container to join the cluster using these IPs.
failure-domain
Set the container failure-domain.
Can only be done on a deactivated container.
net
List the WEKA-dedicated networking devices in a container.
Options
--stable
List the resources from the last successful container boot.
-C
The container name.
Graceful container management: ensuring safe actions
When running the commands weka local stop, weka local restart, and weka local resources apply, it is crucial to perform these actions safely to minimize the risk of unexpected issues or disruptions. To achieve this, use the --graceful option. This practice is particularly important during cluster maintenance.
By using the --graceful option with these commands, the system prioritizes safety before executing any action.
How --graceful works:
Action initiation: Sends a request to the container specifying the desired action (STOP, RESTART, or APPLY_RESOURCES).
Safety check: Evaluates feasibility based on current state and safety constraints (for example, 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, --graceful prevents the stop to maintain system health.
Last updated