Prerequisites for ARO
Support for K3s is being discontinued; migrate to a supported Kubernetes platform.
Installation Prerequisites
The minimum supported size for a Portworx cluster is three nodes. Each node must meet the following hardware, software, and network requirements:
| Hardware | |
|---|---|
| CPU | 4 cores minimum, 8 cores recommended |
| RAM | 4GB minimum, 8GB recommended |
Disk
|
|
| Backing drive | 8GB (minimum required) 128 GB (minimum recommended) |
| Operating system root partition | 64 GB is the minimum required size for the root filesystem which contains the operating system 128 GB minimum recommended |
| Storage drives | Storage drives must be unmounted block storage: raw disks, drive partitions, LVM, or cloud block storage. |
| Network connectivity | Bandwidth:
Latency requirements for synchronous replication: less than 10ms between nodes in the cluster |
| Node type | Bare metal and virtual machine (VM) |
| Software | |
|---|---|
| Linux kernel and distro | Kernel version 3.10 or greater. To check if your Linux distro and kernel are supported, see Supported Kernels. |
| Docker | Version 1.13.1 or greater. |
| Key-value store | Portworx needs a key-value store to perform its operations. As such, install a clustered key-value database (kvdb) with a three node cluster.You can also use Internal KVDB during installation. In this mode, Portworx will create and manage an internal key-value store (KVDB) cluster. If you plan of using your own KVDB, refer to KVDB for Portworx for details on recommendations for installing and configuring a KVDB cluster. |
| Disable swap | Disable swap on all nodes that will run the Portworx software. Ensure that the swap device is not automatically mounted on server reboot. |
| Network Time Protocol (NTP) | All nodes in the cluster should be in sync with NTP time. Any time drift between nodes can cause unexpected behaviour, impacting services. |
| Hypervisor | |
|---|---|
| VMware vSphere |
|
Portworx network requirements
Portworx runs as a pod in a Kubernetes cluster and uses specific ports for communication, data transfer, and telemetry.
- East-to-west
- Inbound
- Outbound
Portworx also requires the following ports:
- An open KVDB port. For example, if you're using etcd externally, open port 2379.
- An open UDP port at 17002.
| OpenShift | Description |
|---|---|
| 17001 | Portworx management port [REST] |
| 17002 | Portworx node-to-node port [gossip]/UDP |
| 17003 | Portworx storage data port |
| 17004 | Portworx namespace [RPC] |
| 17009 | Portworx node-to-node communication port [gRPC] |
| 17010 | Portworx namespace driver [gRPC] |
| 17011 | Portworx diags server port [gRPC] |
| 17015 | Portworx kvdb peer-to-peer port [gRPC] |
| 17016 | Portworx kvdb client service [gRPC] |
| 17018 | Portworx gRPC SDK gateway [REST] |
| 17019 | Portworx health monitor [REST] |
| 17021 | Telemetry log uploader |
| 20002 | Telemetry phone home |
| OpenShift | Description |
|---|---|
| 17001 | Portworx management port [REST] |
| 17018 | Portworx gRPC SDK gateway [REST] |
Portworx Enterprise supported Kubernetes versions
K3s users: You must use CSI integration to generate/use PVCs.
| Type | Supported Versions |
|---|---|
| Azure Red Hat OpenShift |
|
Best practices
Prevent Accidental Deletion: If your virtualization software has a feature to prevent accidental deletion, you should enable it for the VMs hosting PX nodes. While PX is designed to handle the loss of some nodes without issue, losing a significant number of storage nodes due to VM deletion can result in a loss of quorum and an outage. For more information on how to prevent accidental deletion of VM, refer to Lock your resources to protect your infrastructure on Azure.