Prerequisites and compatibility

This page describes the prerequisites and compatibility for the installation of the WEKA system.

Important: The versions mentioned on the prerequisites and compatibility page apply to the WEKA system's latest minor version (5.1.X). For information on new features and supported prerequisites released with each minor version, refer to the relevant release notes available at get.weka.io.

Check the release notes for details about any updates or changes accompanying the latest releases.

In certain instances, WEKA collaborates with Strategic Server Partners to conduct platform qualifications alongside complementary components. If you have any inquiries, contact your designated WEKA representative.

Minimal server configuration for a WEKA cluster

The minimal configuration for a new WEKA cluster installation is 8 servers. This ensures optimal performance, resilience, and scalability for most deployments.

On a small cluster, each server is a larger share of the cluster's resources. While servers or containers are out of service, such as during a failure or a rolling upgrade, performance follows the resources in service. See Performance in a degraded state.

For cloud-based installations, WEKA supports a minimal configuration of 6 servers to accommodate the unique requirements of cloud environments.

CPU

CPU family/architecture	Supported on backends	Supported on clients
Intel Xeon E5 v3 (Haswell) through Xeon 6 (Granite Rapids / Sierra Forest) with up to 256 total CPU cores	👍 Dual-socket	👍 Single-socket and dual-socket
AMD EPYC™ processor families 2nd (Rome) through 5th (Turin) Generations with up to 256 total CPU cores	👍 Single-socket	👍 Single-socket and dual-socket
ARM (AArch64) - NVIDIA Grace single or dual-processor with up to 144 total CPU cores	👍 NVIDIA Grace	👍 NVIDIA Grace

The following requirements must be met:

• AES is enabled.

• Secure Boot is disabled.

• AVX2 is enabled.

Memory

• Sufficient memory to support the WEKA system needs as described in memory requirements.

• More memory support for the OS kernel or any other application.

Operating system

Every effort is made to support upcoming releases of the operating systems in the lists within one quarter (three months) of their respective General Availability (GA) dates. When an operating system version is deprecated, WEKA will cease to ensure its software continues to work with that operating system version.

Support policy

Manage operating system and kernel lifecycle

Maintain system reliability by following the WEKA support policy for Linux distributions. This policy applies to WEKA software on customer-managed Linux servers in on-premises and cloud environments.

This policy excludes Linux distributions bundled as part of the WEKA Software Appliance (WSA).

Lifecycle definitions

• End of Support (EoS): The date a vendor stops providing routine updates and patches.

• End of Life (EoL): The date a vendor ceases all standard support and maintenance for a distribution or kernel version.

Lifecycle stages

• General Availability (GA): WEKA aims to support new GA releases within three months of the vendor release date. After addition to the supported list, these versions receive full support, including certification, ongoing validation, and defect remediation aligned to the Release support and commitments.

• End of Support and End of Life: After a vendor EoS date, WEKA stops active testing and validation. Field issues receive best-effort remediation. If vendor backports are unavailable, fixes may require upgrading to a supported version. Plan migrations before the vendor EoL date.

Custom kernel support

For custom kernel certification, contact the Customer Success Team.

Backends

• Rocky Linux:

  • 10 (x86 and ARM), 9, 8 Release lines

• RHEL:

  • 10, 9, 8 Release lines

• CentOS Stream:

  • 10, 9, 8 Release lines

• AlmaLinux OS:

  • 10, 9, 8 Release lines

• Ubuntu:

  • 24.04, 22.04, 20.04, 18.04

• Amazon Linux:

  • AL2023 (x86 and ARM), AMI 2018.03, AMI 2017.09, Amazon Linux 2 LTS

Clients

• Rocky Linux:

  • 10 (x86 and ARM), 9, 8 Release lines

• RHEL:

  • 10, 9, 8 Release lines

• CentOS Stream:

  • 10, 9, 8 Release lines

• AlmaLinux OS:

  • 10, 9, 8 Release lines

• Ubuntu:

  • 24.04, 22.04, 20.04, 18.04

• Amazon Linux:

  • AL2023 (x86 and ARM), AMI 2018.03, AMI 2017.09, Amazon Linux 2 LTS

• SLES:

  • 16, 15, 12

• Oracle Linux:

  • 9, 8.9

• Debian:

  • 13, 12 (with Linux kernel 6.6), 10

• Proxmox Virtual Environment:

  • 9, 8.2, 8.14

• Azure Linux

  • 3

Configuration

General

• All WEKA servers must be synchronized in date/time (NTP recommended)

• A watchdog driver should be installed in /dev/watchdog (hardware watchdog recommended); search the WEKA knowledge base in the WEKA support portal for more information and how-to articles.

• If using mlocate or alike, it's advisable to exclude wekafs from updatedb filesystems lists; search the WEKA knowledge base in the WEKA support portal for more information and how-to articles.

SELinux

• Supported only on clients.

• Supported in both permissive and enforcing modes.

  • The targeted policy is supported.

  • The mls policy is not supported yet.

• To set the SELinux security context for files, use the -o acl in the mount command, and define the wekafs to use extended attributes in the SELinux policy configuration (fs_use_xattr).

• The maximum size for the Extended Attributes (xattr) is limited to 1024. This attribute is crucial in supporting Access Control Lists (ACL) and Alternate Data Streams (ADS) in SMB. Given its finite capacity, exercise caution when using ACLs and ADS on a filesystem using SELinux.

• Amazon Linux: WEKA does not support kernel versions 5.15 and later.

• Disable automatic kernel updates to prevent upgrades to unsupported versions.

• CentOS Stream 8: Deprecated because the vendor ended support.

WEKA installation directory

• Installation directory:

  • Set the WEKA installation directory directly to /opt/weka.

  • Avoid using symbolic links. They are not supported.

  • Ensure /opt/weka resides on high-availability storage if it's shared.

• Boot drive requirements:

  • Type and quantity: 2 NVMe SSDs

  • Capacity: 960 GB each

  • Durability: 1 DWPD (Drive Writes Per Day)

  • Write throughput: 1 GB/s

• Boot drive setup:

  • Dedicate one boot drive for the OS and the other for the /opt/weka directory.

  • Do not share the boot drive.

  • Do not mount using NFS.

  • Do not use a RAM drive remotely.

  • Do not use software RAID to have two boot drives.

• Storage space requirements:

  • Ensure a minimum of 26 GB is available for the WEKA installation.

  • Allocate an additional 10 GB per core used by WEKA.

• Filesystem configuration:

  • Create a separate filesystem on a dedicated partition for /opt/weka.

Networking

Adhere to the following considerations when choosing the adapters:

• LACP: LACP is supported when bonding ports from dual-port Mellanox NICs into a single Mellanox device but is not compatible when using Virtual Functions (VFs). On CX-5, CX-5 EX, CX-5 BF, CX-6, and CX-6 LX adapters, LACP provides link failover only; throughput is that of a single link.

• MTU It is recommended to set the MTU to at least 4k on the NICs of WEKA cluster servers and the connected switches.

• Jumbo Frames If any network connection, irrespective of whether it’s InfiniBand or Ethernet, on a given backend possess the capability to transmit frames exceeding 4 KB in size, it is mandatory for all network connections used directly by WEKA on that same backend to have the ability to transmit frames of at least 4 KB.

• IOMMU support WEKA automatically detects and enables IOMMU for the server and PCI devices. Manual enablement is not required.

When the Linux operating system is configured with iommu=1, IOMMU is enabled system-wide, and all PCI devices operate under IOMMU control. It is not possible to selectively exclude specific PCI devices from IOMMU when this mode is active.

• Single IP Single IP (also known as shared networking) allows a single IP address to be assigned to the Physical Function (PF) and shared across multiple Virtual Functions (VFs). This means that a single IP can be shared by every WEKA process on that server, while still being available to the host operating system.

• SR-IOV VF

  Single Root I/O Virtualization Virtual Functions enable direct hardware access for virtual machines, improving network performance by reducing CPU overhead.

Shared networking configuration for NIC models:

• NVIDIA NICs: When implementing Shared Networking (Single IP), Virtual Functions (VFs) are not required.

• Broadcom NICs: VFs must be configured when deploying Shared Networking architecture.

• Mixed networks

  A mixed network configuration connects a WEKA cluster to both InfiniBand and Ethernet networks.

  RDMA is supported in mixed networks on adapters that support both mixed networks and RDMA. Review the remaining limitations and supported settings:

  • Non-supported features in mixed networks:

    • VLAN

    • IPv6

  • Supported MTU settings in mixed networks:

    • Ethernet (9000) + InfiniBand (4K)

  • Non-supported MTU settings in mixed networks:

    • Ethernet (1500) + InfiniBand (4K)

    • Ethernet (9000) + InfiniBand (2K)

• Routed network

  Enables communication between subnets using Layer 3 routing, allowing WEKA clusters to span multiple network segments.

• HA (High Availability)

  Ensures system uptime through redundant components and automatic failover.

• RX Interrupts

  Receive interrupts that notify the CPU when network packets arrive, critical for optimizing network processing performance.

• IP addressing for dataplane NICs Exclusively use static IP addressing. DHCP is not supported for dataplane NICs.

• WEKA peer connectivity requires NAT-free networking

  WEKA requires visibility and connectivity to all peers, without interference from networking technologies like Network Address Translation (NAT).

• PKEY (Partition Key) A feature specific to InfiniBand networks that enables the creation of isolated virtual networks (partitions) on a single physical fabric, controlling which endpoints can communicate.

• Ethernet flow control (pause frames)

  Disable 802.3x link-level flow control on the dataplane interfaces of all backend servers and clients: ethtool -A <interface> rx off tx off. Some NIC drivers force pause frames on without autonegotiation, which appears as Autonegotiate: off, RX: on, TX: on in the ethtool -a output. Do not run the cluster with this setting. If the site network policy requires flow control and RoCE is not in use, autonegotiate it with the switch (Autonegotiate: on) rather than forcing it on.

  Apply the same setting to every backend server and client, and match it to the switch port configuration. Mismatched flow control causes intermittent performance degradation that is difficult to diagnose.

  The ethtool -A setting does not survive a reboot or a driver reload. When NetworkManager manages the interface, set ethtool.pause-autoneg no, ethtool.pause-rx off, and ethtool.pause-tx off on the connection profile. NetworkManager reapplies its own ethtool state on every activation and overrides settings applied by scripts or udev rules. Otherwise, apply the setting from a udev rule with systemd-run --no-block. A blocking script in the interface-up path can prevent interfaces from coming up on boot. Verify the result with ethtool -a <interface>.

On RoCE fabrics, turn link-level flow control fully off on the dataplane interfaces: ethtool -A <interface> autoneg off rx off tx off. Priority Flow Control (PFC) and 802.3x global pause are mutually exclusive. A switch port with PFC enabled ignores global pause frames, so a server that emits them runs with no working flow control. Autonegotiated flow control is also unsafe, because negotiation can re-enable pause.

Disable global pause only after the switch PFC no-drop class is in place. Removing it first leaves the path with no flow control at all.

Related topics

Networking

Supported network adapters for backends and clients

The WEKA system is compatible with various network adapters for both backend servers and clients. The following table lists these adapters, detailing their protocol type and a breakdown of both supported and unsupported features.

Use this information to verify hardware compatibility and understand the specific capabilities of each adapter within a WEKA environment.

Adapter	Protocol	Supported features	Unsupported features
Amazon ENA	Ethernet	✅ SR-IOV VF	❌ Single IP ❌ HA ❌ Routed network ❌ LACP ❌ Mixed networks ❌ RX interrupts ❌ RDMA ❌ IOMMU
NVIDIA Mellanox CX-8	Ethernet InfiniBand	✅ Single IP ✅ RX interrupts ✅ RDMA ✅ HA ✅ Routed network (ETH only) ✅ PKEY (IB only) ✅ IOMMU	❌ LACP ❌ Mixed networks ❌ SR-IOV VF
NVIDIA Mellanox CX-7 single-port	InfiniBand	✅ Single IP ✅ RX interrupts ✅ RDMA ✅ HA ✅ PKEY ✅ IOMMU	❌ Mixed networks ❌ SR-IOV VF ❌ Routed network
NVIDIA Mellanox CX-7 dual-port	InfiniBand	✅ Single IP ✅ RX interrupts ✅ RDMA ✅ HA ✅ PKEY ✅ IOMMU	❌ Mixed networks ❌ SR-IOV VF ❌ Routed network
NVIDIA Mellanox CX-7-ETH single-port	Ethernet	✅ Single IP ✅ RDMA ✅ HA ✅ Routed network ✅ IOMMU	❌ LACP ❌ Mixed networks ❌ SR-IOV VF ❌ RX interrupts
NVIDIA Mellanox CX-7-ETH dual-port	Ethernet	✅ LACP ✅ Single IP ✅ RDMA ✅ HA ✅ Routed network ✅ IOMMU	❌ Mixed networks ❌ SR-IOV VF ❌ RX interrupts
NVIDIA Mellanox CX-6 LX	Ethernet	✅ Single IP ✅ RDMA ✅ RX interrupts ✅ HA ✅ Routed network ✅ IOMMU ✅ LACP (failover only)	❌ Mixed networks ❌ SR-IOV VF
NVIDIA Mellanox CX-6 DX	Ethernet	✅ LACP ✅ Single IP ✅ RX interrupts ✅ RDMA ✅ HA ✅ Routed network ✅ IOMMU	❌ Mixed networks ❌ SR-IOV VF
NVIDIA Mellanox CX-6	Ethernet InfiniBand	✅ Mixed networks ✅ Single IP ✅ RX interrupts ✅ RDMA ✅ HA ✅ IOMMU ✅ LACP (failover only)	❌ Routed network ❌ SR-IOV VF
NVIDIA Mellanox CX-5 EX	Ethernet InfiniBand	✅ Mixed networks ✅ RDMA ✅ HA ✅ PKEY (IB only) ✅ IOMMU ✅ Single IP ✅ LACP (failover only)	❌ Routed network ❌ SR-IOV VF ❌ RX interrupts
NVIDIA Mellanox CX-5 BF	Ethernet	✅ Mixed networks ✅ RDMA ✅ HA ✅ IOMMU ✅ Single IP ✅ LACP (failover only)	❌ Routed network ❌ SR-IOV VF ❌ RX interrupts
NVIDIA Mellanox CX-5	Ethernet InfiniBand	✅ Mixed networks ✅ RX interrupts ✅ RDMA ✅ HA ✅ Routed network (ETH only) ✅ PKEY (IB only) ✅ IOMMU ✅ LACP (failover only) ✅ Single IP	❌ SR-IOV VF ❌ Routed network (IB)
VirtIO	Ethernet	✅ HA ✅ Routed network	❌ Mixed networks ❌ Single IP ❌ LACP ❌ RX interrupts ❌ SR-IOV VF ❌ IOMMU

NVIDIA Mellanox ConnectX-4 (CX-4 / CX-4 LX)

This adapter is not supported starting with WEKA 5.1.0. DPDK support for ConnectX-4 was discontinued, and the adapter reached end-of-life in January 2022.

Supported network adapters for clients-only

The following network adapters support Ethernet and SR-IOV VF for clients only:

• Intel X540

• Intel X550-T1 (avoid using this adapter in a single client connected to multiple clusters)

• Intel X710

• Intel X710-DA2

• Intel XL710

• Intel XL710-Q2

• Intel XXV710

• Intel 82599ES

• Intel 82599

• Broadcom BCM957508-P2100G

• Broadcom BCM957608-P2200G

Broadcom NICs are unsupported for guest VMs on KVM or VMware.

OFED drivers

OFED is not required for standard Ethernet deployments. OFED is required only when using LACP on a single NIC with dual ports to enable load balancing between the ports, on adapters that support LACP load balancing (CX-6 DX and CX-7-ETH dual-port). This requirement is driven by the NIC networking stack, not by WEKA.

OFED is not a WEKA dependency. When required, it is due to NIC driver behavior needed to support LACP load balancing.

Ethernet drivers and configurations

Ethernet drivers

Supported Mellanox OFED versions for the Ethernet NICs:

• 24.10

• 24.04

• 23.10

• 23.04

Qualify a newer OFED version before you deploy it. NVIDIA maintains backward compatibility for its hardware, and a version later than those listed becomes supported once it is qualified with a WEKA release.

To use OFED 25.07, distributed with DOCA 3.1, run WEKA 5.1.33 or later. That release includes the RDMA memory registration handling this driver version requires. On earlier versions, use one of the OFED versions listed above.

Supported ENA drivers:

• 1.0.2 - 2.0.2

• A current driver from an official OS repository is recommended

Supported ixgbevf drivers:

• 3.2.2 - 4.1.2

• A current driver from an official OS repository is recommended

Supported Broadcom drivers:

• 228: Minimum required for 100/200 Gbps 57508 NIC

• 231: Minimum required for 200/400 Gbps 57608 NIC

Ethernet configurations

• NICs bonding:

  • Supports bonding dual ports on the same NVIDIA Mellanox NIC using mode 4 (LACP) for redundancy. On adapters that support LACP load balancing, the bond also increases throughput.

• Ethernet speeds:

  • 400 GbE / 200 GbE / 100 GbE / 50GbE / 40 GbE / 25 GbE / 10 GbE.

• IEEE 802.1Q VLAN encapsulation:

  • Supports VLAN tagging with a single VLAN tag on NVIDIA Mellanox NICs.

• VXLAN:

  • Virtual Extensible LANs are not supported.

• DPDK backends and clients using NICs supporting shared networking (single IP):

  • Require one IP address per client for both management and data plane.

  • SR-IOV enabled is not required.

• DPDK backends clients using NICs supporting non-shared networking:

  • IP address for management: One per NIC (configured before WEKA installation).

  • IP address for data plane: One per WEKA core in each server (applied during cluster initialization).

  • Virtual Functions (VFs):

    • Ensure the device supports a maximum number of VFs greater than the number of physical cores on the server.

    • Set the number of VFs to match the cores you intend to dedicate to WEKA.

    • Note that some BIOS configurations may be necessary.

  • SR-IOV: Enabled in BIOS.

• UDP clients:

  • Use a single IP address for all purposes.

When assigning a network device to the WEKA system, no other application can create VFs on that device.

InfiniBand drivers and configurations

InfiniBand drivers

WEKA supports the following Nvidia major OFED versions for the InfiniBand adapters:

• 24.10

• 24.04

• 23.10

• 23.04

Qualify a newer OFED version before you deploy it. NVIDIA maintains backward compatibility for its hardware, and a version later than those listed becomes supported once it is qualified with a WEKA release.

To use OFED 25.07, distributed with DOCA 3.1, run WEKA 5.1.33 or later. That release includes the RDMA memory registration handling this driver version requires. On earlier versions, use one of the OFED versions listed above.

InfiniBand configurations

WEKA supports the following InfiniBand configurations:

• InfiniBand speeds: Determined by the InfiniBand adapter supported speeds (FDR / EDR / HDR / NDR).

• Subnet manager: Configured to 4092.

• One WEKA system IP address for management and data plane.

• PKEYs: One partition key is supported by WEKA.

• Redundant InfiniBand ports can be used for both HA and higher bandwidth.

If it is necessary to change PKEYs, contact the Customer Success Team.

Required ports

When configuring firewall ingress and egress rules the following access must be allowed.

Right-scroll the table to view all columns.

Purpose	Source	Target	Target Ports	Protocol	Comments
WEKA server traffic for bare-metal deployments	All WEKA backend IPs	All WEKA backend IPs	14000-14059 (drives) 14200-14259 (frontend) 14300-14359 (compute)	TCP and UDP TCP and UDP TCP and UDP	These ports are the default for the Resources Generator for the first three containers. You can customize the ports.
WEKA client traffic	Client host IPs	All WEKA backend IPs	14000-14059 (drives) 14300-14359 (compute)	TCP and UDP TCP and UDP	These ports are the default. You can customize the ports.
WEKA backend to client traffic	All WEKA backend IPs	Client host IPs	14000-14059 (frontend)	TCP and UDP	These ports are the default. You can customize the ports.
WEKA SSH management traffic	All WEKA backend IPs	All WEKA backend IPs	22	TCP
WEKA server traffic for cloud deployments	All WEKA backend IPs	All WEKA backend IPs	14000-14059 (drives) 15000-15059 (compute) 16000-16059 (frontend)	TCP and UDP TCP and UDP TCP and UDP	These ports are the default. You can customize the ports.
WEKA client traffic (on cloud)	Client host IPs	All WEKA backend IPs	14000-14059 (drives) 15000-15059 (compute)	TCP and UDP TCP and UDP	These ports are the default. You can customize the ports.
WEKA backend to client traffic (on cloud)	All WEKA backend IPs	Client host IPs	14000-14059 (frontend)	TCP and UDP	These ports are the default. You can customize the ports.
WEKA GUI access	Admin workstation IPs	All WEKA management IPs	14000	TCP	User web browser IP
NFS	NFS client IPs	WEKA NFS backend IPs	2049 <mountd port>	TCP and UDP TCP and UDP	You can set the mountd port using the command: weka nfs global-config set --mountd-port
NFSv3 (used for locking)	NFS client IPs	WEKA NFS backend IPs	<status monitor port> <lock manager port> 111 (rpcbind)	TCP and UDP	The status monitor and lock manager use dynamic ports by default. To set fixed ports, use the command: weka nfs global-config set --statmon-port --lockmgr-port
SMB/SMB-W	SMB client IPs	WEKA SMB backend IPs	139 445	TCP TCP
SMB-W	All WEKA SMB-W backend IPs	All WEKA SMB-W backend IPs	2224	TCP	This port is required for internal clustering processes.
SMB/SMB-W	WEKA SMB backend IPs	All Domain Controllers for the selected Active Directory Domain	88 389 464 636 3268 3269	TCP and UDP TCP and UDP TCP and UDP TCP and UDP TCP and UDP TCP and UDP	These ports are required for SMB/SMB-W to use Active Directory as the identity source. Furthermore, every Domain Controller within the selected AD domain must be accessible from the WEKA SMB servers.
SMB/SMB-W	WEKA SMB backend IPs	DNS servers	53	TCP and UDP
S3	S3 client IPs	WEKA S3 backend IPs	9000	TCP	This port is the default. You can customize the port.
wekatester	All WEKA backend IPs	All WEKA backend IPs	8501 9090	TCP TCP	Port 8501 is used by wekanetperf.
WEKA Management Station	User web browser IP	WEKA Management Station IP	80 <LWH> 443 <LWH> 3000 <mon> 7860 <admin UI> 8760 <deploy> 8090 <snap> 8501 <mgmt> 9090 <mgmt> 9091 <mon> 9093 <alerts>	HTTP HTTPS TCP TCP TCP TCP TCP TCP TCP
Cloud WEKA Home, Local WEKA Home	All WEKA backend IPs	Cloud WEKA Home or Local WEKA Home	80 443	HTTP HTTPS	Open according to the directions in the deployment scenario: - WEKA server IPs to CWH or LWH. - LWH to CWH (if forwarding data from LWH to CWH) Endpoint URLs: api.home.weka.io get.weka.io
Client telemetry and statistics	WEKA client IPs	Cloud WEKA Home or Local WEKA Home	80 443	HTTP HTTPS	Lack of connectivity prevents client-related statistics from being reported.
Troubleshooting by the Customer Success Team (CST)	All WEKA backend IPs	CST remote access	4000 4001	TCP TCP
Traces remote viewer	All WEKA backend IPs	CST remote access	443	TCP
KMS: Vault or OpenBao	All WEKA backend IPs	Vault/OpenBao server	8200 8201	TCP TCP	Default vault ports: 8200 is configurable for client requests, while 8201 (base_port+1) handles internal cluster communication.
KMS: KMIP	All WEKA backend IPs	KMIP server	5696	TCP	The default KMIP port, 5696, is configurable. Per the KMIP specification, servers must use this port when operating with the TTLV encoding format.

HA

See Network High Availability

SSD requirements

Review the requirements for SSDs used in a WEKA cluster.

• SSDs must support Power Loss Protection (PLP).

• Dedicate the entire SSD for WEKA system storage. Partitioning the drive is not supported.

• SSDs must support an LBA format with a metadata size of 0. When the SSD supports a 4K block size, the system formats it to 4K blocks when you add it to the cluster.

• Use SSDs with a capacity of up to 122.88 TB.

• Maintain a capacity ratio of 8:1 or less between the smallest and largest SSDs in each drive pool.

• Use a single SSD capacity where possible, and keep the total SSD capacity equal across failure domains. Equal capacity spreads the load evenly across failure domains.

• Maintain a ratio of 8000:1 or less between the total SSD capacity and the total RAM of the cluster.

To get the best performance, ensure TRIM is supported by the device and enabled in the operating system.

Mixed TLC and QLC configurations (AlloyFlash)

An AlloyFlash^TM configuration combines TLC and QLC SSDs in one cluster. Apply the following requirements:

• Use TLC drives with a capacity of at least 6.4 TB and an endurance of 3 DWPD (Drive Writes Per Day).

• Use up to 11 QLC drives for each TLC drive.

• Add drives with weka cluster drive add --pool auto. The cluster assigns each drive to a pool by its indirection-unit size. To override the assignment, set --pool iu4k (typically TLC) or --pool iubig (typically QLC).

Object store

• API must be S3 compatible:

  • GET

    • Including byte-range support with expected performance gain when fetching partial objects

  • PUT

    • Supports any byte size of up to 65 MiB

  • DELETE

• Data consistency: Amazon S3 consistency model:

  • GET after a single PUT is strongly consistent

  • Multiple PUTs are eventually consistent

WEKA integrates with object stores for three primary purposes: extending the filesystem capacity with a lower-cost tier, creating local backups, and creating remote backups for disaster recovery. Support for these functions varies by the object store provider and its specific configuration.

• Tiering: Moves inactive data from the high-performance SSD tier to a local object store bucket. This frees up SSD capacity while keeping the data accessible within the unified filesystem namespace. Tiering requires high performance and consistency from the object store.

• Local Snap-to-Object: Sends immutable snapshots of a filesystem to a local object store bucket, one that is close to the cluster. This provides an efficient and secure method for local backup and fast recovery.

• Remote Snap-to-Object: Sends immutable snapshots of a filesystem to a remote object store bucket, typically in a different geographic location. This provides an efficient and secure method for remote backup and disaster recovery.

Related topics

Snap-To-Object and tiering (how Tiering and Local Snap-to-Object share the same object data when they use the same bucket.)

Certified object stores and support status

The following table details the support status for certified object store solutions.

Object Store	Storage Class / Version	Supportability notes
Amazon S3	S3 Standard S3 Intelligent-Tiering	Tiering and snap-to-object
Amazon S3	S3 Standard-IA S3 One Zone-IA S3 Glacier Instant Retrieval	Snap-to-object is supported but tiering is not recommended due to slow retrieval, storage periods, and access costs. Best for backups/DR. Use Intelligent-Tiering if unsure.
Azure Blob Storage		Tiering and snap-to-object
Cloudian HyperStore	7.3	Tiering and snap-to-object
CoreWeave AI Object Storage (CAIOS)		Snap-to-object; tiering not supported
Google Cloud Storage (GCS)		Tiering and snap-to-object
Dell EMC ECS	3.5	Tiering and snap-to-object
Dell PowerScale S3	9.8.0.0	Tiering and snap-to-object (H and F models only)
HCP Classic	9.2+ (versioned buckets)	Tiering and snap-to-object
HCP for Cloud-Scale	2.x	Tiering and snap-to-object
IBM Cloud Object Storage	3.14.7	Tiering and snap-to-object
Lenovo MagnaScale	3	Tiering and snap-to-object
Quantum ActiveScale	5.5.1	Tiering and snap-to-object
Red Hat Ceph Storage	5	Tiering and snap-to-object
Scality Artesca	1.5.2	Tiering and snap-to-object
Scality RING S3 Connector	8.5	Tiering and snap-to-object
Scality RING WEKA Connector	9.5	Tiering and snap-to-object
SwiftStack	6.3	Tiering and snap-to-object
WEKA S3		Tiering and snap-to-object

S3-Compatible object store requirements

To ensure stability, performance, and data integrity, any S3-compatible object store used with WEKA must meet the following minimum requirements.

API requirements

The object store must provide a fully S3-compatible API that supports the following operations:

• GET: Must include support for byte-range requests to allow for efficient fetching of partial objects.

• PUT: Must support uploads of any object size up to 65 MiB.

• DELETE: Must support standard object deletion.

Data consistency requirements

The object store must adhere to the Amazon S3 data consistency model:

• Strong read-after-write consistency: A GET request for an object that occurs after a successful PUT request has created that object must immediately return the new object's data.

• Eventual consistency: PUT requests that overwrite existing objects, or DELETE requests, are eventually consistent. This means that a subsequent GET request might temporarily return the older version of the data before the update or deletion has fully propagated across the system.

Virtual Machines

This section outlines the use of virtual machines (VMs) with WEKA, covering backends, clients, VMware platforms, and cloud environments. While VMs can be used in certain configurations, there are specific limitations and best practices to follow.

Backends

Virtual machines may be used as backends for internal training purposes only and are not recommended for production environments.

WEKA provides best-effort support for backends deployed on virtual machines, but full support is not guaranteed. Additionally, WEKA does not guarantee support for components or configurations outside of our documented and supported cloud environments, and performance may vary.

Clients

Virtual Machines (VMs) can be used as clients. Ensure the following prerequisites are met for each client type:

• UDP clients:

  • Reserve CPU resources and dedicate a core to the client to prevent CPU starvation of the WEKA process.

  • Ensure the root filesystem supports a 3K IOPS load for the WEKA client.

• DPDK clients:

  • Meet all the requirements for UDP clients.

  • Additionally, verify that the virtual platform (hypervisor, NICs, CPUs, and their respective versions) fully supports DPDK and the required virtual network drivers.

VMware platform (client only)

When using vmxnet3 devices, do not enable the SR-IOV feature, because it disables the vMotion functionality. Each frontend process requires a dedicated vmxnet3 device and IP address, with an additional device and IP for each client VM to support the management process.

Core dedication is required when using vmxnet3 devices.

VMs and instances on cloud environments

Refer to the cloud deployment sections for the most up-to-date list of supported virtual machines and instances in various cloud environments.

Related topics

AWS: Supported EC2 instance types using Terraform

Azure: Supported virtual machine types

GCP: Supported machine types and storage

Related information

For additional information and how-to articles, search the WEKA Knowledge Base in the WEKA support portal or contact the Customer Success Team.

KMS

Supported KMS types:

• KMIP-compliant KMS: Supports protocol versions 1.2 or later and 2.x. Only TTLV is supported as the messaging protocol. Supports commercial solutions such as Thales CipherTrust Manager.

• HashiCorp Vault: Supports versions 1.x.

• OpenBao Vault: Supports version 2.5.1 or later.