W E K A
4.4
4.4
  • WEKA v4.4 documentation
    • Documentation revision history
  • WEKA System Overview
    • Introduction
      • WEKA system functionality features
      • Converged WEKA system deployment
      • Optimize redundancy in WEKA deployments
    • SSD capacity management
    • Filesystems, object stores, and filesystem groups
    • WEKA networking
    • Data lifecycle management
    • WEKA client and mount modes
    • WEKA containers architecture overview
    • Glossary
  • Planning and Installation
    • Prerequisites and compatibility
    • WEKA cluster installation on bare metal servers
      • Plan the WEKA system hardware requirements
      • Obtain the WEKA installation packages
      • Install the WEKA cluster using the WMS with WSA
      • Install the WEKA cluster using the WSA
      • Manually install OS and WEKA on servers
      • Manually prepare the system for WEKA configuration
        • Broadcom adapter setup for WEKA system
        • Enable the SR-IOV
      • Configure the WEKA cluster using the WEKA Configurator
      • Manually configure the WEKA cluster using the resources generator
        • VLAN tagging in the WEKA system
      • Perform post-configuration procedures
      • Add clients to an on-premises WEKA cluster
    • WEKA Cloud Deployment Manager Web (CDM Web) User Guide
    • WEKA Cloud Deployment Manager Local (CDM Local) User Guide
    • WEKA installation on AWS
      • WEKA installation on AWS using Terraform
        • Terraform-AWS-WEKA module description
        • Deployment on AWS using Terraform
        • Required services and supported regions
        • Supported EC2 instance types using Terraform
        • WEKA cluster auto-scaling in AWS
        • Detailed deployment tutorial: WEKA on AWS using Terraform
      • WEKA installation on AWS using the Cloud Formation
        • Self-service portal
        • CloudFormation template generator
        • Deployment types
        • AWS Outposts deployment
        • Supported EC2 instance types using Cloud Formation
        • Add clients to a WEKA cluster on AWS
        • Auto scaling group
        • Troubleshooting
    • WEKA installation on Azure
      • Azure-WEKA deployment Terraform package description
      • Deployment on Azure using Terraform
      • Required services and supported regions
      • Supported virtual machine types
      • Auto-scale virtual machines in Azure
      • Add clients to a WEKA cluster on Azure
      • Troubleshooting
      • Detailed deployment tutorial: WEKA on Azure using Terraform
    • WEKA installation on GCP
      • WEKA project description
      • GCP-WEKA deployment Terraform package description
      • Deployment on GCP using Terraform
      • Required services and supported regions
      • Supported machine types and storage
      • Auto-scale instances in GCP
      • Add clients to a WEKA cluster on GCP
      • Troubleshooting
      • Detailed deployment tutorial: WEKA on GCP using Terraform
      • Google Kubernetes Engine and WEKA over POSIX deployment
    • WEKA installation on OCI
  • Getting Started with WEKA
    • Manage the system using the WEKA GUI
    • Manage the system using the WEKA CLI
      • WEKA CLI hierarchy
      • CLI reference guide
    • Run first IOs with WEKA filesystem
    • Getting started with WEKA REST API
    • WEKA REST API and equivalent CLI commands
  • Performance
    • WEKA performance tests
      • Test environment details
  • WEKA Filesystems & Object Stores
    • Manage object stores
      • Manage object stores using the GUI
      • Manage object stores using the CLI
    • Manage filesystem groups
      • Manage filesystem groups using the GUI
      • Manage filesystem groups using the CLI
    • Manage filesystems
      • Manage filesystems using the GUI
      • Manage filesystems using the CLI
    • Attach or detach object store buckets
      • Attach or detach object store bucket using the GUI
      • Attach or detach object store buckets using the CLI
    • Advanced data lifecycle management
      • Advanced time-based policies for data storage location
      • Data management in tiered filesystems
      • Transition between tiered and SSD-only filesystems
      • Manual fetch and release of data
    • Mount filesystems
      • Mount filesystems from Single Client to Multiple Clusters (SCMC)
      • Manage authentication across multiple clusters with connection profiles
    • Snapshots
      • Manage snapshots using the GUI
      • Manage snapshots using the CLI
    • Snap-To-Object
      • Manage Snap-To-Object using the GUI
      • Manage Snap-To-Object using the CLI
    • Snapshot policies
      • Manage snapshot policies using the GUI
      • Manage snapshot policies using the CLI
    • Quota management
      • Manage quotas using the GUI
      • Manage quotas using the CLI
  • Additional Protocols
    • Additional protocol containers
    • Manage the NFS protocol
      • Supported NFS client mount parameters
      • Manage NFS networking using the GUI
      • Manage NFS networking using the CLI
    • Manage the S3 protocol
      • S3 cluster management
        • Manage the S3 service using the GUI
        • Manage the S3 service using the CLI
      • S3 buckets management
        • Manage S3 buckets using the GUI
        • Manage S3 buckets using the CLI
      • S3 users and authentication
        • Manage S3 users and authentication using the CLI
        • Manage S3 service accounts using the CLI
      • S3 lifecycle rules management
        • Manage S3 lifecycle rules using the GUI
        • Manage S3 lifecycle rules using the CLI
      • Audit S3 APIs
        • Configure audit webhook using the GUI
        • Configure audit webhook using the CLI
        • Example: How to use Splunk to audit S3
        • Example: How to use S3 audit events for tracking and security
      • S3 supported APIs and limitations
      • S3 examples using boto3
      • Configure and use AWS CLI with WEKA S3 storage
    • Manage the SMB protocol
      • Manage SMB using the GUI
      • Manage SMB using the CLI
  • Security
    • WEKA security overview
    • Obtain authentication tokens
    • Manage token expiration
    • Manage account lockout threshold policy
    • Manage KMS
      • Manage KMS using GUI
      • Manage KMS using CLI
    • Manage TLS certificates
      • Manage TLS certificates using GUI
      • Manage TLS certificates using CLI
    • Manage Cross-Origin Resource Sharing
    • Manage CIDR-based security policies
    • Manage login banner
  • Secure cluster membership with join secret authentication
  • Licensing
    • License overview
    • Classic license
  • Operation Guide
    • Alerts
      • Manage alerts using the GUI
      • Manage alerts using the CLI
      • List of alerts and corrective actions
    • Events
      • Manage events using the GUI
      • Manage events using the CLI
      • List of events
    • Statistics
      • Manage statistics using the GUI
      • Manage statistics using the CLI
      • List of statistics
    • Insights
    • System congestion
    • User management
      • Manage users using the GUI
      • Manage users using the CLI
    • Organizations management
      • Manage organizations using the GUI
      • Manage organizations using the CLI
      • Mount authentication for organization filesystems
    • Expand and shrink cluster resources
      • Add a backend server
      • Expand specific resources of a container
      • Shrink a cluster
    • Background tasks
      • Set up a Data Services container for background tasks
      • Manage background tasks using the GUI
      • Manage background tasks using the CLI
    • Upgrade WEKA versions
    • Manage WEKA drivers
  • Monitor the WEKA Cluster
    • Deploy monitoring tools using the WEKA Management Station (WMS)
    • WEKA Home - The WEKA support cloud
      • Local WEKA Home overview
      • Deploy Local WEKA Home v3.0 or higher
      • Deploy Local WEKA Home v2.x
      • Explore cluster insights
      • Explore performance statistics in Grafana
      • Manage alerts and integrations
      • Enforce security and compliance
      • Optimize support and data management
      • Export cluster metrics to Prometheus
    • Set up WEKAmon for external monitoring
    • Set up the SnapTool external snapshots manager
  • Kubernetes
    • Composable clusters for multi-tenancy in Kubernetes
    • WEKA Operator deployment
    • WEKA Operator day-2 operations
  • WEKApod
    • WEKApod Data Platform Appliance overview
    • WEKApod servers overview
    • Rack installation
    • WEKApod initial system setup and configuration
    • WEKApod support process
  • AWS Solutions
    • Amazon SageMaker HyperPod and WEKA Integrations
      • Deploy a new Amazon SageMaker HyperPod cluster with WEKA
      • Add WEKA to an existing Amazon SageMaker HyperPod cluster
    • AWS ParallelCluster and WEKA Integration
  • Azure Solutions
    • Azure CycleCloud for SLURM and WEKA Integration
  • Best Practice Guides
    • WEKA and Slurm integration
      • Avoid conflicting CPU allocations
    • Storage expansion best practice
  • Support
    • Get support for your WEKA system
    • Diagnostics management
      • Traces management
        • Manage traces using the GUI
        • Manage traces using the CLI
      • Protocols debug level management
        • Manage protocols debug level using the GUI
        • Manage protocols debug level using the CLI
      • Diagnostics data management
  • Appendices
    • WEKA CSI Plugin
      • Deployment
      • Storage class configurations
      • Tailor your storage class configuration with mount options
      • Dynamic and static provisioning
      • Launch an application using WEKA as the POD's storage
      • Add SELinux support
      • NFS transport failback
      • Upgrade legacy persistent volumes for capacity enforcement
      • Troubleshooting
    • Convert cluster to multi-container backend
    • Create a client image
    • Update WMS and WSA
    • BIOS tool
Powered by GitBook
On this page
  • Expansion guidelines
  • weka cluster container command description
  • Expansion procedures on a remote container
  • Modify the memory
  • Modify the network configuration
  • Modify the container IP addresses
  • Add CPU cores to a container
  • Expand SSDs only
  • weka local resources command description
  • Graceful container management: ensuring safe actions
  1. Operation Guide
  2. Expand and shrink cluster resources

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     
PreviousAdd a backend serverNextShrink a cluster

Last updated 12 days ago