> For the complete documentation index, see [llms.txt](https://docs.weka.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.weka.io/planning-and-installation/prerequisites-and-compatibility.md). # Prerequisites and compatibility Verify server, operating system, network, storage, and object store compatibility before installing WEKA. {% hint style="warning" %} **Important:** The versions mentioned on the prerequisites and compatibility page apply to the **latest revision** (6.0.**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](https://get.weka.io/). Check the release notes for details about any updates or changes accompanying the latest releases. {% endhint %} {% hint style="info" %} 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. {% endhint %} ## Minimal server configuration for a WEKA cluster The minimal configuration for a new cluster installation is **8 servers**. This ensures optimal performance, resilience, and scalability for most deployments. {% hint style="info" %} 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](/weka-system-overview/cluster-capacity-and-redundancy-management.md#performance-in-a-degraded-state). {% endhint %} {% hint style="info" %} For cloud-based installations, the cluster supports a minimal configuration of **6 servers** to accommodate the unique requirements of cloud environments. {% endhint %} ## 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 | {% hint style="info" %} The following requirements must be met: * AES[^1] is enabled. * [Secure Boot](#user-content-fn-2)[^2] is disabled. * AVX2[^3] is enabled. {% endhint %} ## Memory * Sufficient memory to support the cluster needs as described in [memory requirements](/planning-and-installation/system-installation-on-bare-metal-servers/plan-hardware-requirements.md#memory-resource-planning). * More memory support for the OS kernel or any other application. ## Operating system {% tabs %} {% tab title="Support policy" %} **Manage operating system and kernel lifecycle** This policy applies to WEKA software on customer-managed Linux servers. Support is declared per operating system version, separately for backends and clients. {% hint style="info" %} This policy excludes Linux distributions bundled as part of the WEKA Platform Appliance (WPA). {% endhint %} **What this means for you** * Your cluster keeps its operating system version for the life of its Release Line. WEKA does not remove a version from a Release Line after GA. * Full support lasts as long as vendor standard support. After that, support is best-effort. * To move to a different operating system version, choose one with at least 12 months of vendor standard support remaining, and upgrade one server at a time. Each server restarts while the cluster stays available, and if the version you want was added in a later Release Line or Service Pack, upgrade WEKA in the same maintenance window. * To upgrade to a new Release Line, run a version listed for that line. See the **Backends** and **Clients** tabs. **Definitions** * **Baseline:** The operating system versions WEKA supports for a Release Line, published at its GA. Reviewed at the start of each stage (N, N-1, N-2): a version with under 12 months of vendor standard support left is not carried into that stage. The Backends and Clients tabs list the baseline for this Release Line. * **Carried:** A baseline version that passes the stage review and stays on the baseline for that stage. A version that is not carried gets no Service Packs from that stage, and clusters running it stay on their last Service Pack. * **Supported:** WEKA investigates, fixes, and validates issues on the version. Applies while the version is on the baseline, or not carried but still within vendor standard support. * **Best-effort:** Vendor standard support has ended. Customer Success continues to take your cases. WEKA does not test or certify anything specific to that version, so resolution may require moving to a supported operating system version. * **Vendor standard support:** The period in which the vendor provides routine updates at no additional cost. Paid extensions, such as RHEL Extended Life Cycle Support, SLES Long Term Service Pack Support, and Ubuntu Expanded Security Maintenance, are not vendor standard support. **Custom kernel support** Support covers the kernel the vendor ships for the listed version. For derivative distributions or custom kernels, contact the Customer Success Team. {% endtab %} {% tab title="Versions per distribution" %} WEKA supports a fixed number of the most recent versions of each distribution. When a vendor releases a new major version, the oldest version is not included in the next Release Line baseline. The count is a maximum: a version is supported only while the vendor provides standard support.
DistributionBackendsClients
Ubuntu3 most recent LTS3 most recent LTS
RHEL3 most recent major versions3 most recent major versions
Rocky Linux3 most recent major versions3 most recent major versions
Amazon Linux2 most recent major versions2 most recent major versions
DGX OS2 most recent major versions2 most recent major versions
AlmaLinux OSNot supported3 most recent major versions
Oracle LinuxNot supported3 most recent major versions
DebianNot supported3 most recent stable versions
CentOS StreamNot supported2 most recent major versions
SLESNot supported2 most recent major versions
Proxmox Virtual EnvironmentNot supported2 most recent major versions
Azure LinuxNot supported2 most recent major versions
{% endtab %} {% tab title="Backends" %} | Family | Supported | | ------------ | ---------------------- | | Amazon Linux | AL2023 (x86 and ARM) | | DGX OS | 8, 7.4 | | RHEL | 10, 9, 8 | | Rocky Linux | 10 (x86 and ARM), 9, 8 | | Ubuntu | 26.04, 24.04 | | {% endtab %} | | {% tab title="Clients" %} | Family | Supported | | ------------- | ---------------------- | | AlmaLinux | 10, 9, 8 | | Amazon Linux | AL2023 (x86 and ARM) | | Azure Linux | 3 | | CentOS Stream | 10 | | Debian | 13, 12 | | DGX OS | 8 (x86 and ARM), 7.4 | | Oracle Linux | 10, 9, 8 | | Proxmox VE | 9 | | RHEL | 10, 9, 8 | | Rocky Linux | 10 (x86 and ARM), 9, 8 | | SLES | 16, 15 | | Ubuntu | 26.04, 24.04 | | {% endtab %} | | {% tab title="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](http://support.weka.io) 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](http://support.weka.io) 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. {% hint style="info" %} * 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. {% endhint %} {% endtab %} {% endtabs %} {% hint style="info" %} * **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. {% endhint %} ## 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 software installation. * Allocate an additional 10 GB per core used by system. * **Filesystem configuration:** * Create a separate filesystem on a dedicated partition for `/opt/weka`. ## Networking Adhere to the following considerations when choosing the adapters: * [**LACP**](#user-content-fn-4)[^4]**:** LACP is supported when bonding the ports of a dual-port Mellanox NIC, or ports on two different Mellanox NICs. A bond across two NICs works like an HA dual-NIC configuration and uses the bond's IP address. LACP is not compatible with Virtual Functions (VFs). On CX-5, CX-5 EX, CX-5 BF, CX-6, and CX-6 LX adapters, an LACP bond on a single NIC provides link failover only; throughput is that of a single link. * [**MTU**](#user-content-fn-5)[^5]\ It is recommended to set the MTU to at least 4k on the NICs of the cluster servers and the connected switches. * [**Jumbo Frames**](#user-content-fn-6)[^6]\ 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 the cluster on that same backend to have the ability to transmit frames of at least 4 KB. * [**IOMMU**](#user-content-fn-7)[^7] **support**\ The cluster automatically detects and enables IOMMU for the server and PCI devices. Manual enablement is not required. {% hint style="info" %} 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. {% endhint %} * **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 cluster 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. {% hint style="info" %} 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. {% endhint %} * **Mixed networks** A mixed network configuration connects the cluster to both InfiniBand and Ethernet networks. In a mixed network, InfiniBand uses DPDK. On CX-6 DX, CX-6 LX, CX-7, and CX-8 adapters, Ethernet runs in UDP mode. 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 the cluster 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. * **Cluster peer connectivity requires NAT-free networking** The system 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 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 `. {% hint style="warning" %} On RoCE fabrics, turn link-level flow control fully off on the dataplane interfaces: `ethtool -A 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. {% endhint %} **Related topics** [Networking](/weka-system-overview/networking-in-wekaio.md) ### Supported network adapters for backends and clients The 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 the environment.
AdapterProtocolSupported featuresUnsupported features
Amazon ENAEthernetβœ… SR-IOV VF

❌ Single IP

❌ LACP

❌ RDMA

❌ RX interrupts

❌ HA

❌ Routed network

❌ IOMMU

❌ Mixed networks

NVIDIA Mellanox CX-8

Ethernet

InfiniBand

βœ… Single IP

βœ… LACP

βœ… RDMA

βœ… RX interrupts

βœ… HA

βœ… Routed network (ETH only)

βœ… PKEY (IB only)

βœ… IOMMU

βœ… Mixed networks

❌ SR-IOV VF
NVIDIA Mellanox CX-7 single-portInfiniBand

βœ… Single IP

βœ… RDMA

βœ… RX interrupts

βœ… HA

βœ… PKEY

βœ… IOMMU

βœ… Mixed networks

❌ Routed network

❌ SR-IOV VF

NVIDIA Mellanox CX-7 dual-portInfiniBand

βœ… Single IP

βœ… RDMA

βœ… RX interrupts

βœ… HA

βœ… PKEY

βœ… IOMMU

βœ… Mixed networks

❌ Routed network

❌ SR-IOV VF

NVIDIA Mellanox CX-7-ETH single-portEthernet

βœ… Single IP

βœ… RDMA

βœ… HA

βœ… Routed network

βœ… IOMMU

βœ… Mixed networks

❌ LACP

❌ RX interrupts

❌ SR-IOV VF

NVIDIA Mellanox CX-7-ETH dual-portEthernet

βœ… Single IP

βœ… LACP

βœ… RDMA

βœ… HA

βœ… Routed network

βœ… IOMMU

βœ… Mixed networks

❌ RX interrupts

❌ SR-IOV VF

NVIDIA Mellanox CX-6 LXEthernet

βœ… Single IP

βœ… LACP (failover only)

βœ… RDMA

βœ… RX interrupts

βœ… HA

βœ… Routed network

βœ… IOMMU

βœ… Mixed networks

❌ SR-IOV VF
NVIDIA Mellanox CX-6 DXEthernet

βœ… Single IP

βœ… LACP

βœ… RDMA

βœ… RX interrupts

βœ… HA

βœ… Routed network

βœ… IOMMU

βœ… Mixed networks

❌ SR-IOV VF
NVIDIA Mellanox CX-6Ethernet InfiniBand

βœ… Single IP

βœ… LACP (failover only)

βœ… RDMA

βœ… RX interrupts

βœ… HA

βœ… IOMMU

βœ… Mixed networks

❌ Routed network

❌ SR-IOV VF

NVIDIA Mellanox CX-5 EXEthernet InfiniBand

βœ… Single IP

βœ… LACP (failover only)

βœ… RDMA

βœ… HA

βœ… PKEY (IB only)

βœ… IOMMU

βœ… Mixed networks

❌ RX interrupts

❌ Routed network

❌ SR-IOV VF

NVIDIA Mellanox CX-5 BFEthernet

βœ… Single IP

βœ… LACP (failover only)

βœ… RDMA

βœ… HA

βœ… IOMMU

βœ… Mixed networks

❌ RX interrupts

❌ Routed network

❌ SR-IOV VF

NVIDIA Mellanox CX-5Ethernet InfiniBand

βœ… Single IP

βœ… LACP (failover only)

βœ… RDMA

βœ… RX interrupts

βœ… HA

βœ… Routed network (ETH only)

βœ… PKEY (IB only)

βœ… IOMMU

βœ… Mixed networks

❌ Routed network (IB)

❌ SR-IOV VF

VirtIOEthernet

βœ… HA

βœ… Routed network

❌ Single IP

❌ LACP

❌ RX interrupts

❌ IOMMU

❌ Mixed networks

❌ SR-IOV VF

{% hint style="info" %} **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. {% endhint %} ### 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 {% hint style="info" %} Broadcom NICs are unsupported for guest VMs on KVM or VMware. {% endhint %} The following NVIDIA BlueField adapters are supported in NIC mode for clients only: * NVIDIA BlueField-3 ### 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, CX-7-ETH dual-port, and CX-8). This requirement is driven by the NIC networking stack, not by WEKA. {% hint style="info" %} OFED is not a WEKA dependency. When required, it is due to NIC driver behavior needed to support LACP load balancing. {% endhint %} ### Ethernet drivers and configurations {% tabs %} {% tab title="Ethernet drivers" %} **Supported Mellanox OFED versions for the Ethernet NICs:** * 24.10 * 24.04 * 23.10 * 23.04 **Supported NVIDIA DOCA versions, including their OFED drivers:** * 3.5.0 * 3.2.3 {% hint style="info" %} 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. {% endhint %} **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 {% endtab %} {% tab title="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. Also supports LACP or static bonding across ports on two different NVIDIA Mellanox NICs. The cluster handles the bond like an HA dual-NIC configuration, with one IP address. * **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. * Network spaces for native multi-tenancy use VLAN tagging and require an NVIDIA Mellanox NIC on every backend server. Broadcom NICs do not support VLAN tagging or network spaces. See [Multi-tenancy cluster-level administration](/operation-guide/weka-native-multi-tenancy-management/multi-tenancy-cluster-level-administration.md). * **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](/planning-and-installation/system-installation-on-bare-metal-servers/plan-hardware-requirements.md#cpu-resource-planning) in each server (applied during cluster initialization). * [Virtual Functions](https://en.wikipedia.org/wiki/Network_function_virtualization) (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. {% hint style="info" %} When assigning a network device to the WEKA system, no other application can create VFs on that device. {% endhint %} {% endtab %} {% endtabs %} ### InfiniBand drivers and configurations {% tabs %} {% tab title="InfiniBand drivers" %} The cluster supports the following NVIDIA major OFED versions for the InfiniBand adapters: * 24.10 * 24.04 * 23.10 * 23.04 **Supported NVIDIA DOCA versions, including their OFED drivers:** * 3.5.0 * 3.2.3 {% hint style="info" %} 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. {% endhint %} {% endtab %} {% tab title="InfiniBand configurations" %} The cluster 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. * Redundant InfiniBand ports can be used for both HA and higher bandwidth. {% hint style="info" %} If it is necessary to change PKEYs, contact the [Customer Success Team](/support/getting-support-for-your-weka-system.md#open-a-support-case). {% endhint %} {% endtab %} {% endtabs %} ### Required ports When configuring firewall ingress and egress rules the following access must be allowed. {% hint style="info" %} Right-scroll the table to view all columns. {% endhint %}
PurposeSourceTargetTarget PortsProtocolComments
Server traffic for bare-metal deploymentsAll backend IPsAll backend IPs14000-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.
Client trafficClient host IPsAll backend IPs14000-14059 (drives)
14300-14359 (compute)		TCP and UDP
TCP and UDP		These ports are the default. You can customize the ports.
Backend to client trafficAll backend IPsClient host IPs14000-14059 (frontend)TCP and UDPThese ports are the default. You can customize the ports.
SSH management trafficAll backend IPsAll backend IPs22TCP
Server traffic for cloud deploymentsAll backend IPsAll 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.
Client traffic (on cloud)Client host IPsAll backend IPs

14000-14059 (drives)

15000-15059 (compute)

TCP and UDP
TCP and UDP		These ports are the default. You can customize the ports.
Backend to client traffic (on cloud)All backend IPsClient host IPs14000-14059 (frontend)TCP and UDPThese ports are the default. You can customize the ports.
GUI accessAdmin workstation IPsAll management IPs14000TCPUser web browser IP
NFSNFS client IPsNFS backend IPs2049
<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 IPsNFS backend IPs

<status monitor port>
<lock manager port>

111 (rpcbind)

TCP and UDPThe 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-WSMB client IPsSMB backend IPs139
445		TCP
TCP
SMB-WAll SMB-W backend IPsAll SMB-W backend IPs2224TCPThis port is required for internal clustering processes.
SMB-WAll SMB-W backend IPsAll SMB-W backend IPs5405UDPThis port is required for cluster communication (Corosync) between SMB-W servers.
SMB/SMB-WSMB backend IPsAll 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 SMB servers.
SMB/SMB-WSMB backend IPsDNS servers53TCP and UDP
S3S3 client IPsS3 backend IPs9000TCPThis port is the default. You can customize the port.
wekatesterAll backend IPsAll backend IPs8501
9090		TCP
TCP		Port 8501 is used by wekanetperf.
Cloud WEKA Home, Local WEKA HomeAll 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 statisticsClient 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 backend IPsCST remote access4000
4001		TCP
TCP
Traces remote viewerAll backend IPsCST remote access443TCP
KMS: Vault or OpenBaoAll backend IPsVault/OpenBao server8200
8201		TCP
TCP		Default vault ports: 8200 is configurable for client requests, while 8201 (base_port+1) handles internal cluster communication.
KMS: KMIPAll backend IPsKMIP server5696TCPThe default KMIP port, 5696, is configurable. Per the KMIP specification, servers must use this port when operating with the TTLV encoding format.
## HA See [Networking](/weka-system-overview/networking-in-wekaio.md#high-availability) ## SSD requirements Review the requirements for SSDs used in the cluster. * SSDs must support Power Loss Protection (PLP). * Dedicate the entire SSD for the cluster 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. {% hint style="info" %} To get the best performance, ensure [TRIM](https://en.wikipedia.org/wiki/Trim_\(computing\)) is supported by the device and enabled in the operating system. {% endhint %} ### Mixed TLC and QLC configurations (AlloyFlash) An AlloyFlashTM 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](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel): * GET after a single PUT is strongly consistent * Multiple PUTs are eventually consistent The system 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. ### Certified object stores and support status The following table details the support status for certified object store solutions.
Object StoreStorage Class / VersionSupportability 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 StorageTiering and snap-to-object
Backblaze B2Tiering and snap-to-object
Cloudian HyperStore7.3Tiering 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 ECS3.5Tiering and snap-to-object
Dell PowerScale S39.8.0.0Tiering and snap-to-object (H and F models only)
HCP Classic9.2+ (versioned buckets)Tiering and snap-to-object
HCP for Cloud-Scale2.xTiering and snap-to-object
HPE Alletra Storage MP X100002.1.0.0Tiering and snap-to-object
IBM Cloud Object Storage3.14.7Tiering and snap-to-object
Lenovo MagnaScale3Tiering and snap-to-object
Quantum ActiveScale5.5.1Tiering and snap-to-object
Red Hat Ceph Storage5Tiering and snap-to-object
Scality Artesca1.5.2Tiering and snap-to-object
Scality RING S3 Connector8.5Tiering and snap-to-object
Scality RING WEKA Connector9.5Tiering and snap-to-object
SwiftStack6.3Tiering and snap-to-object
WasabiTiering and snap-to-object
NeuralMesh S3Tiering and snap-to-object
### S3-Compatible object store requirements To ensure stability, performance, and data integrity, any S3-compatible object store used with NeuralMesh 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](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel): * **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 the cluster, 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. The cluster provides best-effort support for backends deployed on virtual machines, but full support is not guaranteed. Additionally, the cluster 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 cluster 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](/planning-and-installation/aws/supported-ec2-instance-types.md) Azure: [Supported virtual machine types](/planning-and-installation/weka-installation-on-azure/supported-virtual-machine-types.md) GCP: [Supported machine types and storage](/planning-and-installation/weka-installation-on-gcp/supported-machine-types-and-storage.md) \ **Related information** For additional information and how-to articles, search the WEKA Knowledge Base in the [WEKA support portal](http://support.weka.io) or contact the [Customer Success Team](/support/getting-support-for-your-weka-system.md#open-a-support-case). ## KMS **Supported KMS types:** * [**KMIP-compliant KMS**](http://docs.oasis-open.org/kmip/spec/v1.2/os/kmip-spec-v1.2-os.html)**:** Supports protocol versions 1.2 or later and 2.x. Only TTLV[^8] is supported as the messaging protocol. Supports commercial solutions such as Thales CipherTrust Manager. * [**HashiCorp Vault**](https://www.hashicorp.com/products/vault/)**:** Supports versions 1.x. * [**OpenBao Vault**](https://openbao.org/): Supports version 2.5.1 or later. [^1]: **AES (Advanced Encryption Standard)** in BIOS settings refers to hardware acceleration for AES encryption. Enabled by default, it speeds up encryption tasks using AES-NI. Disabling it may affect performance in encryption-heavy applications. [^2]: **Secure Boot** is a BIOS/UEFI feature that ensures only trusted software is loaded during startup. If Secure Boot is disabled, the system allows any software to run. [^3]: **AVX2 (Advanced Vector Extensions 2)** is a CPU instruction set that enhances performance on floating-point and integer operations. It is enabled by default on supported hardware, but can be disabled in virtual machines, depending on the hypervisor configuration. Ensure your VM settings allow AVX2. [^4]: LACP stands for "Link Aggregation Control Protocol." It is a networking protocol that enables the bundling of multiple network connections in parallel to increase bandwidth and provide redundancy. [^5]: MTU (Maximum Transmission Unit) represents the maximum size of a data packet that can be transmitted over a network. [^6]: Jumbo Frames refer to network frames that exceed the standard Maximum Transmission Unit (MTU) size, allowing for larger data packets to be transmitted over a network. [^7]: The IOMMU (Input/Output Memory Management Unit) is a hardware component that manages and controls data transfers between devices (like graphics cards) and a computer's main memory, enhancing system security and performance. [^8]: **TTLV (Tag-Length-Value)** is a binary encoding format used in KMIP for structured and efficient messaging between a KMS and its clients. It consists of a tag (data type), length (size), and value (data). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.weka.io/planning-and-installation/prerequisites-and-compatibility.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.