Prerequisites for GCP Anthos
Environment 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 9002.
- For telemetry, open ports 9024, 12001, and 12002. Ensure you are running Portworx Operator version 23.7.0 or higher to configure the telemetry port:
- Portworx Versions 2.13.7 and Older: Open port 9024 specifically for telemetry.
- Portworx Versions 2.13.8 and Newer: Use port 9029 for telemetry.
Kubernetes | Description |
---|---|
9001 | Portworx management port [REST] |
9002 | Portworx node-to-node port [gossip]/UDP |
9003 | Portworx storage data port |
9004 | Portworx namespace [RPC] |
9012 | Portworx node-to-node communication port [gRPC] |
9013 | Portworx namespace driver [gRPC] |
9014 | Portworx diags server port [gRPC] |
9018 | Portworx kvdb peer-to-peer port [gRPC] |
9019 | Portworx kvdb client service [gRPC] |
9021 | Portworx gRPC SDK gateway [REST] |
9022 | Portworx health monitor [REST] |
9029 | Telemetry log uploader |
12002 | Telemetry phone home |
Kubernetes | Description |
---|---|
9001 | Portworx management port [REST] |
9021 | Portworx gRPC SDK gateway [REST] |
Supported Kubernetes versions
Before you install Portworx on Kubernetes, ensure that you're using a supported Kubernetes version:
Portworx Enterprise supported Kubernetes versions
- 3.2
- 3.1
- 3.0
Type | Supported Versions |
---|---|
Bare metal |
|
VMware |
|
Type | Supported Versions |
---|---|
Bare metal |
|
VMware |
|
Supported Kubernetes Version |
---|
Bare metal
|
Supported disk types
Portworx provides multiple disk types to meet different platform needs. This document lists all the disk types that Portworx supports for disk provisioning across different cloud providers.
Cloud provider | Disk types |
---|---|
vSphere |
|
GKE |
|
Considerations/Warnings
By default, Google includes Kernel version 5.15 from Anthos version 1.14 for vSphere. Therefore, upgrading to Anthos version 1.14 or newer can result in Kernel performance issues, leading to a drop in the sequential write operations. Avoid using this Anthos version and Kernel version until the issue is fixed. See the bug description for more information.
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 Prevent accidental VM deletion on Google cloud compute engine.