# Prerequisites and compatibility

{% hint style="warning" %}
**Important:** The versions mentioned on the prerequisites and compatibility page apply to the WEKA system's **latest minor version** (5.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 WEKA cluster installation is **8 servers**. This ensures optimal performance, resilience, and scalability for most deployments.

{% hint style="info" %}
For cloud-based installations, WEKA supports a minimal configuration of **6 servers** to accommodate the unique requirements of cloud environments.
{% endhint %}

## CPU

<table><thead><tr><th width="338">CPU family/architecture</th><th width="210">Supported on backends</th><th>Supported on clients</th></tr></thead><tbody><tr><td>2013 Intel® Core™ processor family and later</td><td><span data-gb-custom-inline data-tag="emoji" data-code="1f44d">👍</span><br>Dual-socket</td><td><span data-gb-custom-inline data-tag="emoji" data-code="1f44d">👍</span><br>Dual-socket</td></tr><tr><td>AMD EPYC™ processor families 2nd (Rome), 3rd (Milan-X), and 4th (Genoa) Generations</td><td><span data-gb-custom-inline data-tag="emoji" data-code="1f44d">👍</span><br>Single-socket</td><td><span data-gb-custom-inline data-tag="emoji" data-code="1f44d">👍</span> <br>Single-socket and dual-socket</td></tr><tr><td>ARM (AArch64)</td><td></td><td><span data-gb-custom-inline data-tag="emoji" data-code="1f44d">👍</span><br>NVIDIA Grace</td></tr></tbody></table>

{% 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 WEKA system needs as described in [memory requirements](https://docs.weka.io/4.4/bare-metal/planning-a-weka-system-installation#memory-resource-planning).
* More memory support for the OS kernel or any other application.

## Operating system

{% hint style="info" %}
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.
{% endhint %}

{% tabs %}
{% tab title="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.

{% hint style="info" %}
This policy excludes Linux distributions bundled as part of the WEKA Software Appliance (WSA).
{% endhint %}

**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](https://docs.weka.io/4.4/support/release-support-and-commitments "mention").
* **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.

**Support verification**

Verify that both the kernel and operating system versions appear as supported in the backends, clients, and kernel tabs. These components require independent verification. If  a custom operating system or kernel is required, contact the [Customer Success Team](https://docs.weka.io/4.4/support/getting-support-for-your-weka-system#contact-customer-success-team).
{% endtab %}

{% tab title="Backends" %}

* **Rocky Linux:**
  * 9.6, 9.4, 9.3, 9.2, 9.1, 9.0
  * 8.10, 8.9, 8.8, 8.7, 8.6
* **RHEL:**
  * 9.6, 9.5, 9.4, 9.3, 9.2, 9.1, 9.0
  * 8.10, 8.9, 8.8, 8.7, 8.6, 8.5, 8.4, 8.3, 8.2, 8.1, 8.0
* **CentOS:**
  * 8.5, 8.4, 8.3, 8.2, 8.1, 8.0
* **Ubuntu:**
  * 24.04
  * 22.04
  * 20.04
  * 18.04
* **Amazon Linux 2023** (AL2023) with x86 distribution
* **Amazon Linux 2 LTS** (formerly Amazon Linux 2 LTS 17.12) with x86\_64 distribution
* **Amazon Linux:**
  * AMI 2018.03
  * AMI 2017.09
* **Oracle Linux:**
  * 9.6, 9
  * 8.7, 8.5
    {% endtab %}

{% tab title="Clients" %}

* **Rocky Linux:**
  * Supported on ARM: 9.5, 9.3
  * 9.6, 9.5, 9.4, 9.3, 9.2, 9.1, 9.0
  * 8.10, 8.9, 8.8, 8.7, 8.6
* **RHEL:**
  * Supported on ARM: 9.3
  * 9.6, 9.5, 9.4, 9.3, 9.2, 9.1, 9.0
  * 8.10, 8.9, 8.8, 8.7, 8.6, 8.5, 8.4, 8.3, 8.2, 8.1, 8.0
* **CentOS:**
  * 8.5, 8.4, 8.3, 8.2, 8.1, 8.0
* **Ubuntu:**
  * 24.04
  * 22.04
  * 20.04
  * 18.04
* **Amazon Linux 2023** (AL2023) with x86 and ARM distributions
* **Amazon Linux 2 LTS** (formerly Amazon Linux 2 LTS 17.12) with x86 and ARM distributions
* **Amazon Linux:**
  * AMI 2018.03
  * AMI 2017.09
* **SLES:**
  * 15 SP6
  * 15 SP5
  * 15 SP4
  * 15 SP2
  * 12 SP5
* **Oracle Linux:**
  * 9.6, 9
  * 8.9 (ARM), 8.7, 8.5
* **Debian:**
  * 12 (with Linux kernel 6.6)
  * 10
* **AlmaLinux OS:**
  * 9.4
  * 8.10
* **Proxmox Virtual Environment**:
  * 8.2
  * 8.14
    {% endtab %}

{% tab title="Supported kernels versions" %}
Identify the kernel requirements for the WEKA system to ensure platform stability and data integrity across the environment. Confirm that both the kernel version and the operating system version are listed as supported. These are distinct components with their own compatibility considerations.

**Kernel compatibility matrix**

The following table lists the supported kernel versions for WEKA servers. The range of supported versions is inclusive.

<table><thead><tr><th width="192">Kernel version</th><th>Supported operating systems</th></tr></thead><tbody><tr><td>6.14</td><td>All supported distributions</td></tr><tr><td>6.12</td><td>Amazon Linux 2023 only</td></tr><tr><td>6.8</td><td>All supported distributions</td></tr><tr><td>6.0 to 6.5</td><td>All supported distributions</td></tr><tr><td>5.3 to 5.19</td><td>Various distributions (see notes for Amazon Linux 2)</td></tr><tr><td>4.4.0-1106 to 4.19</td><td>Various distributions</td></tr><tr><td>3.10</td><td>Legacy distributions</td></tr></tbody></table>

{% hint style="info" %}
Kernels 5.15 and higher are not supported with the Amazon Linux 2 (AL2) operating system.
{% endhint %}

**Kernel update requirements**

Manage the server environment to maintain a validated state. Preventing unintended upgrades ensures the WEKA process remains compatible with the underlying kernel.

* **Disable automatic updates:** Turn off automatic kernel updates to prevent the server from upgrading to an unsupported version.
* **Verify versioning:** Ensure the kernel version and operating system version are both explicitly listed as supported before any manual upgrade.
* **Exclude kernel packages:** Configure the package manager to ignore kernel-related updates by adding `exclude=kernel*` to the configuration file (for example: `/etc/dnf/dnf.conf` or `/etc/yum.conf`).
* **Validate configuration:** Run a check-update command to confirm the package manager no longer targets kernel packages for installation.
  {% 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

* SELinux is 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 %}

#### cgroups

* WEKA backends and clients that serve protocols must be deployed on a supported OS with **cgroupsV1**.
* **cgroupsV2** is supported on backends and clients, but not in deployments with protocol clusters.
  {% endtab %}
  {% endtabs %}

{% hint style="info" %}
As of version 4.3.2, RHEL 7.X and CentOS 7.X are no longer supported due to their end-of-life status. If you need assistance upgrading your operating system, contact the [Customer Success Team](https://docs.weka.io/4.4/support/getting-support-for-your-weka-system#contact-customer-success-team) for guidance.
{% endhint %}

## WEKA installation directory

* **WEKA installation directory**:&#x20;
  * The WEKA installation directory must be set to `/opt/weka`.
  * Use a direct path; symbolic links (symlinks) are not supported.
  * The /`opt/weka` directory is critical for proper WEKA operation. If it resides on shared storage, the storage must be highly available.
* **Boot drive minimum requirements**:
  * Capacity: NVMe SSD with 960 GB capacity
  * Durability: 1 DWPD (Drive Writes Per Day)
  * Write throughput: 1 GB/s
* **Boot drive considerations**:
  * Do not share the boot drive.
  * Do not mount using NFS.
  * Do not use a RAM drive remotely.
  * If two boot drives are available:
    * It is recommended to dedicate one boot drive for the OS and the other for the `/opt/weka` directory.
    * Do not use software RAID to have two boot drives.
* **Software required space**:
  * Ensure that at least 26 GB is available for the WEKA system installation.
  * Allocate an additional 10 GB per core used by WEKA.
* **Filesystem requirement**:
  * Set a separate filesystem on a separate 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 ports from dual-port Mellanox NICs into a single Mellanox device but is not compatible when using Virtual Functions (VFs).
* **Intel E810:**
  * Only supported on RHEL 8.6 and Rocky Linux 8.6. For other operating systems, consult with the [Customer Success Team](https://docs.weka.io/4.4/support/getting-support-for-your-weka-system#contacting-weka-technical-support-team).
  * The ice Linux Base Driver version 1.9.11 and firmware version 4.0.0 are required.
* [**MTU**](#user-content-fn-5)[^5]\
  It is recommended to set the MTU to at least 4k on the NICs of WEKA 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 WEKA on that same backend to have the ability to transmit frames of at least 4 KB.
* [**IOMMU**](#user-content-fn-7)[^7] **support**\
  WEKA automatically detects and enables IOMMU for the server and PCI devices. Manual enablement is not required.
* **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.

{% hint style="info" %}
Shared networking configuration for NIC models:

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

* Broadcom/Intel E810 NICs: VFs must be configured when deploying Shared Networking architecture.
  {% endhint %}

* **Mixed networks**

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

  Certain features and configurations are not supported in mixed network setups. Review the following limitations and supported settings:

  * **Non-supported features in mixed networks:**
    * RDMA
    * 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).

**Related topics**

[networking-in-wekaio](https://docs.weka.io/4.4/weka-system-overview/networking-in-wekaio "mention")

### Supported network adapters for backends and clients <a href="#networking-ethernet" id="networking-ethernet"></a>

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.

<table><thead><tr><th>Adapter</th><th width="126">Protocol</th><th>Supported features</th><th>Unsupported features </th></tr></thead><tbody><tr><td>Amazon ENA</td><td>Ethernet</td><td><ul><li>SR-IOV VF</li></ul></td><td><ul><li>Single IP</li><li>HA</li><li>Routed network</li><li>LACP</li><li>Mixed networks</li><li>RX interrupts</li><li>RDMA</li><li>IOMMU</li></ul></td></tr><tr><td>Intel E810 2CQDA2<br><br><strong>Note:</strong> This adapter is not supported beyond 4.4.x version series.</td><td>Ethernet</td><td><p></p><ul><li>Shared networking</li><li>HA</li><li>Routed network</li></ul></td><td><ul><li>LACP</li><li>Mixed networks</li><li>RX interrupts</li><li>RDMA</li><li>SR-IOV VF</li><li>IOMMU</li></ul></td></tr><tr><td>NVIDIA Mellanox CX-7 single-port</td><td>InfiniBand</td><td><ul><li>Single IP</li><li>RX interrupts</li><li>RDMA</li><li>HA</li><li>PKEY</li><li>IOMMU</li></ul></td><td><ul><li>Mixed networks</li><li>SR-IOV VF</li><li>Routed network</li></ul></td></tr><tr><td>NVIDIA Mellanox CX-7 dual-port</td><td>InfiniBand</td><td><ul><li>Single IP</li><li>RX interrupts</li><li>RDMA</li><li>HA</li><li>PKEY</li><li>IOMMU</li></ul></td><td><ul><li>Mixed networks</li><li>SR-IOV VF</li><li>Routed network</li></ul></td></tr><tr><td>NVIDIA Mellanox CX-7-ETH single-port</td><td>Ethernet</td><td><ul><li>Single IP</li><li>RDMA</li><li>HA</li><li>Routed network (ETH only)</li><li>IOMMU</li></ul></td><td><ul><li>LACP</li><li>Mixed networks</li><li>SR-IOV VF</li><li>RX interrupts</li></ul></td></tr><tr><td>NVIDIA Mellanox CX-7-ETH dual-port</td><td>Ethernet</td><td><ul><li>LACP</li><li>Single IP</li><li>RDMA</li><li>HA</li><li>Routed network (ETH only)</li><li>IOMMU</li></ul></td><td><ul><li>Mixed networks</li><li>SR-IOV VF</li><li>RX interrupts</li></ul></td></tr><tr><td>NVIDIA Mellanox CX-6 LX</td><td>Ethernet</td><td><ul><li>Single IP</li><li>RDMA</li><li>RX interrupts</li><li>HA</li><li>Routed network (ETH only)</li><li>IOMMU</li></ul></td><td><ul><li>LACP</li><li>Mixed networks</li><li>SR-IOV VF</li></ul></td></tr><tr><td>NVIDIA Mellanox CX-6 DX</td><td>Ethernet</td><td><ul><li>LACP</li><li>Single IP</li><li>RX interrupts</li><li>RDMA</li><li>HA</li><li>Routed network (ETH only)</li><li>IOMMU</li></ul></td><td><ul><li>Mixed networks</li><li>SR-IOV VF</li></ul></td></tr><tr><td>NVIDIA Mellanox CX-6</td><td>Ethernet InfiniBand</td><td><ul><li>Mixed networks</li><li>Single IP</li><li>RX interrupts</li><li>RDMA</li><li>HA</li><li>IOMMU</li></ul></td><td><ul><li>Routed network</li><li>LACP</li><li>SR-IOV VF</li><li>PKEY</li></ul></td></tr><tr><td>NVIDIA Mellanox CX-5 EX</td><td>Ethernet InfiniBand</td><td><ul><li>Mixed networks</li><li>RDMA</li><li>HA</li><li>PKEY (IB)</li><li>IOMMU</li></ul></td><td><ul><li>Single IP</li><li>Routed network</li><li>LACP</li><li>SR-IOV VF</li><li>RX interrupts</li></ul></td></tr><tr><td>NVIDIA Mellanox CX-5 BF</td><td>Ethernet</td><td><ul><li>Mixed networks</li><li>RDMA</li><li>HA</li><li>IOMMU</li></ul></td><td><ul><li>Single IP</li><li>Routed network</li><li>LACP</li><li>SR-IOV VF</li><li>RX interrupts</li></ul></td></tr><tr><td>NVIDIA Mellanox CX-5</td><td>Ethernet InfiniBand</td><td><ul><li>Mixed networks</li><li>RX interrupts</li><li>RDMA</li><li>HA</li><li>Routed network (ETH only)</li><li>PKEY (IB only)</li><li>IOMMU</li></ul></td><td><ul><li>Single IP</li><li>LACP</li><li>SR-IOV VF</li><li>Routed network (IB)</li></ul></td></tr><tr><td>NVIDIA Mellanox CX-4 LX<br><strong>Note:</strong> This adapter was announced to be end-of-life by the manufacturer in January 2022. Its functionality in WEKA cannot be guaranteed, due to dependencies on DPDK18, limited features, and limited availability. </td><td>Ethernet InfiniBand</td><td><ul><li>Mixed networks</li><li>RX interrupts</li><li>HA</li><li>Routed network (ETH only)</li><li>IOMMU</li></ul></td><td><ul><li>Single IP</li><li>RDMA</li><li>LACP</li><li>SR-IOV VF</li><li>Routed network (IB)</li><li>PKEY</li></ul></td></tr><tr><td>NVIDIA Mellanox CX-4</td><td>Ethernet InfiniBand</td><td><ul><li>Mixed networks</li><li>RX interrupts</li><li>HA</li><li>Routed network (ETH only)</li><li>IOMMU</li></ul></td><td><ul><li>Single IP</li><li>RDMA</li><li>LACP</li><li>SR-IOV VF</li><li>Routed network (IB)</li><li>PKEY</li></ul></td></tr><tr><td>VirtIO</td><td>Ethernet</td><td><ul><li>HA</li><li>Routed network</li></ul></td><td><ul><li>Single IP</li><li>LACP</li><li>Mixed networks</li><li>RX interrupts</li><li>SR-IOV VF</li><li>IOMMU</li></ul></td></tr></tbody></table>

### 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

### 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 proper load balancing between the ports. 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 %}

{% hint style="warning" %}
DOCA-OFED 3.1.0 or later is incompatible with WEKA backends and clients using CX-7 NICs. Instead, use the Mellanox OFED version provided below or the OFED drivers included with your distribution.
{% 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
* 5.9

{% hint style="info" %}
Subsequent OFED minor versions are expected to be compatible with NVIDIA hardware due to NVIDIA's commitment to backward compatibility.
{% 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 Intel 40 drivers:**

* 3.0.1-k - 4.1.0
* A current driver from an official OS repository is recommended

**Supported ice drivers:**

* 1.9.11

**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) to enhance redundancy and performance.
* **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](https://docs.weka.io/4.4/bare-metal/planning-a-weka-system-installation#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 <a href="#networking-infiniband" id="networking-infiniband"></a>

{% tabs %}
{% tab title="InfiniBand drivers" %}
WEKA supports the following NVIDIA major OFED versions for the InfiniBand adapters:

* 24.10
* 24.04
* 23.10
* 23.04

{% hint style="info" %}
Subsequent OFED minor versions are expected to be compatible with NVIDIA hardware due to NVIDIA's commitment to backward compatibility.
{% endhint %}
{% endtab %}

{% tab title="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.

{% hint style="info" %}
If it is necessary to change PKEYs, contact the [Customer Success Team](https://docs.weka.io/4.4/support/getting-support-for-your-weka-system#contacting-weka-technical-support-team).
{% 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 %}

<table><thead><tr><th width="211">Purpose</th><th width="124">Source</th><th width="135">Target</th><th width="228">Target Ports</th><th width="135">Protocol</th><th width="352">Comments</th></tr></thead><tbody><tr><td>WEKA server traffic for bare-metal deployments</td><td>All WEKA backend IPs</td><td>All WEKA backend IPs</td><td>14000-14100 (drives)<br>14200-14300 (frontend)<br>14300-14400 (compute)</td><td>TCP and UDP<br>TCP and UDP<br>TCP and UDP</td><td>These ports are the default for the Resources Generator for the first three containers. You can customize the ports.</td></tr><tr><td>WEKA client traffic</td><td>Client host IPs </td><td>All WEKA backend IPs</td><td>14000-14100 (drives)<br>14300-14400 (compute)</td><td>TCP and UDP<br>TCP and UDP</td><td>These ports are the default. You can customize the ports.</td></tr><tr><td>WEKA backend to client traffic</td><td>All WEKA backend IPs</td><td>Client host IPs </td><td>14000-14100 (frontend)</td><td>TCP and UDP</td><td>These ports are the default. You can customize the ports.</td></tr><tr><td>WEKA SSH management traffic</td><td>All WEKA backend IPs </td><td>All WEKA backend IPs</td><td>22</td><td>TCP</td><td></td></tr><tr><td>WEKA server traffic for cloud deployments</td><td>All WEKA backend IPs</td><td>All WEKA backend IPs</td><td><p>14000-14100 (drives)</p><p>15000-15100 (compute)</p><p>16000-16100 (frontend)</p></td><td>TCP and UDP<br>TCP and UDP<br>TCP and UDP</td><td>These ports are the default. You can customize the ports.</td></tr><tr><td>WEKA client traffic (on cloud)</td><td>Client host IPs </td><td>All WEKA backend IPs</td><td><p>14000-14100 (drives)</p><p>15000-15100 (compute)</p></td><td>TCP and UDP<br>TCP and UDP</td><td>These ports are the default. You can customize the ports.</td></tr><tr><td>WEKA backend to client traffic (on cloud)</td><td>All WEKA backend IPs</td><td>Client host IPs </td><td>14000-14100 (frontend)</td><td>TCP and UDP</td><td>These ports are the default. You can customize the ports.</td></tr><tr><td>WEKA GUI access </td><td>Admin workstation IPs</td><td>All WEKA management IPs</td><td>14000</td><td>TCP</td><td>User web browser IP</td></tr><tr><td>NFS</td><td>NFS client IPs</td><td>WEKA NFS backend  IPs</td><td>2049<br>&#x3C;mountd port></td><td>TCP and UDP<br>TCP and UDP</td><td>You can set the <code>mountd</code> port using the command: <code>weka nfs global-config set --mountd-port</code></td></tr><tr><td>NFSv3 (used for locking)</td><td>NFS client IPs</td><td>WEKA NFS backend  IPs</td><td>46999 (status monitor)<br>47000 (lock manager)</td><td>TCP and UDP</td><td></td></tr><tr><td>SMB/SMB-W</td><td>SMB client IPs</td><td>WEKA SMB backend IPs</td><td>139<br>445</td><td>TCP<br>TCP</td><td></td></tr><tr><td>SMB-W</td><td>All WEKA SMB-W backend IPs</td><td>All WEKA SMB-W backend IPs</td><td>2224</td><td>TCP</td><td>This port is required for internal clustering processes.</td></tr><tr><td>SMB/SMB-W</td><td>WEKA SMB backend IPs</td><td>All Domain Controllers for the selected Active Directory Domain</td><td><p>88</p><p>389<br>464<br>636<br>3268<br>3269</p></td><td>TCP and UDP<br>TCP and UDP<br>TCP and UDP<br>TCP and UDP<br>TCP and UDP<br>TCP and UDP</td><td>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.</td></tr><tr><td>SMB/SMB-W</td><td>WEKA SMB backend IPs</td><td>DNS servers</td><td>53</td><td>TCP and UDP</td><td></td></tr><tr><td>S3</td><td>S3 client IPs</td><td>WEKA S3 backend IPs</td><td>9000</td><td>TCP</td><td>This port is the default. You can customize the port.</td></tr><tr><td>wekatester</td><td>All WEKA backend IPs</td><td>All WEKA backend IPs</td><td>8501<br>9090</td><td>TCP<br>TCP</td><td>Port 8501 is used by wekanetperf.</td></tr><tr><td>WEKA Management Station</td><td>User web browser IP</td><td>WEKA Management Station IP</td><td><p>80  &#x3C;LWH></p><p>443 &#x3C;LWH></p><p>3000 &#x3C;mon></p><p>7860 &#x3C;admin UI></p><p>8760 &#x3C;deploy></p><p>8090 &#x3C;snap></p><p>8501 &#x3C;mgmt><br>9090 &#x3C;mgmt></p><p>9091 &#x3C;mon><br>9093 &#x3C;alerts></p></td><td><p>HTTP</p><p>HTTPS</p><p>TCP</p><p>TCP</p><p>TCP</p><p>TCP<br>TCP</p><p>TCP<br>TCP</p></td><td></td></tr><tr><td>Cloud WEKA Home, Local WEKA Home</td><td>All WEKA backend IPs </td><td>Cloud WEKA Home or<br>Local WEKA Home</td><td>80<br>443</td><td>HTTP<br>HTTPS</td><td>Open according to the directions in the deployment scenario:<br>- WEKA server IPs to CWH or LWH.<br>- LWH to CWH (if forwarding data from LWH to CWH)</td></tr><tr><td><p></p><p>Client telemetry and statistics</p></td><td><p></p><p>WEKA client</p></td><td>Cloud WEKA Home<br>or Local WEKA Home</td><td>80<br>443</td><td>HTTP<br>HTTPS</td><td><p></p><p>Lack of connectivity prevents client-related statistics from being reported.</p></td></tr><tr><td>Troubleshooting by the Customer Success Team (CST)</td><td>All WEKA backend IPs </td><td>CST remote access</td><td>4000<br>4001</td><td>TCP<br>TCP</td><td></td></tr><tr><td>Traces remote viewer</td><td>All WEKA backend IPs</td><td>CST remote access</td><td>443</td><td>TCP</td><td></td></tr><tr><td>KMS: Hashicorp Vault</td><td>All WEKA backend IPs </td><td>Hashicorp Vault server</td><td>8200<br>8201</td><td>TCP<br>TCP</td><td>Default vault ports: 8200 is configurable for client requests, while 8201 (base_port+1) handles internal cluster communication.</td></tr><tr><td>KMS: KMIP</td><td>All WEKA backend IPs</td><td>KMIP server</td><td>5696</td><td>TCP</td><td>The default KMIP port, 5696, is configurable. Per the KMIP specification, servers must use this port when operating with the <a data-footnote-ref href="#user-content-fn-8">TTLV</a> encoding format.</td></tr></tbody></table>

## HA

See [#high-availability](https://docs.weka.io/4.4/weka-system-overview/networking-in-wekaio#high-availability "mention")

## SSDs

* The SSDs must support PLP (Power Loss Protection).
* WEKA system storage must be dedicated, and partitioning is not supported.
* The supported drive capacity is up to 30 TB.
* The ratio between the cluster's smallest and the largest SSD capacity must not exceed 8:1.

{% 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 %}

## Object store

WEKA integrates with object stores for two primary purposes: extending the filesystem capacity with a lower-cost tier 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 designated 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.
* **Snap-to-Object:** Sends immutable snapshots of a filesystem to a remote object store. 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.

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

### 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](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 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 (**&#x63;lient 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](https://docs.weka.io/4.4/planning-and-installation/aws/weka-installation-on-aws-using-terraform/supported-ec2-instance-types "mention")

Azure: [supported-virtual-machine-types](https://docs.weka.io/4.4/planning-and-installation/weka-installation-on-azure/supported-virtual-machine-types "mention")

GCP: [supported-machine-types-and-storage](https://docs.weka.io/4.4/planning-and-installation/weka-installation-on-gcp/supported-machine-types-and-storage "mention")

\
**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](https://docs.weka.io/4.4/support/getting-support-for-your-weka-system#contacting-weka-technical-support-team).

## 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+ 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.1.5 to 1.x.

[^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).