Skip to main content
Version: 3.3

Planning your Portworx Deployment

Before installing Portworx Enterprise, it’s important to evaluate your environment and make key architecture decisions based on your requirements The following aspects will influence how you deploy and manage your Portworx installation:

  1. Type of Platform Support – Kubernetes, OpenShift and Provider Distributions: Portworx Enterprise integrates with majority of CNCF-certified Kubernetes distributions, including upstream Kubernetes and Red Hat OpenShift. It also supports the managed offerings from major cloud providers—Amazon EKS, Google Kubernetes Engine (GKE), Oracle Cloud Kubernetes (OKE), IBM Cloud Kubernetes Service, and others—so you can go for provider-specific optimizations and networking integrations. Futhermore, Portworx Enterprise runs on on-premises bare-metal clusters, giving you the flexibility to choose the any of the supported platform from bare metal to managed offerings.

  2. Type of Installation Environment – Air-gapped or Non-air-gapped: Depending on your security and compliance requirements, Portworx Enterprise can be deployed in a fully air-gapped cluster (no external internet access) or in a standard connected environment. In air-gapped mode, you’ll need to mirror all container images and Helm charts into a private registry and pre-stage any CRDs or operator bundles. This ensures all binaries and dependencies reside within your secured perimeter. In non-air-gapped mode, Portworx Enterprise automatically pulls the necessary images and updates from public registries when external connectivity is allowed, without requiring any additional steps as part of the installation process.

  3. Type of deployment - Disaggregated or Converged: By default, Portworx Enterprise is installed as a converged configuration, where compute and storage coexist on the same nodes. If you need a disaggregated setup, where compute and storage are on separate node groups, you must designate your nodes as storage and storageless (for compute) before installation. During deployment, you are required to add necessary labels to make sure Portworx identifies the disaggregated setup. These labels you can find in the environment specific installation steps.

  4. Type of storage management - PX-StoreV1 or PX-StoreV2: Portworx offers two types of storage volume management solution. First, PX-StoreV1 that operates as a full filesystem, suitable for general-purpose storage needs. Second, PX-StoreV2 focuses on high-performance volume management with optimized metadata handling and performance tracking. It also enables PX-Fast, a feature that provides an accelerated I/O path for volumes. Note: PX-Fast is only supported with PX-StoreV2.

  5. Type of Disaster Recovery (DR): Portworx offers two DR options across clusters. Synchronous DR ensures zero recovery point objectives (RPO) with real-time replication but requires a shared external KVDB and a stretched cluster. Asynchronous DR uses scheduled snapshots, supports independent clusters, can tolerate higher latencies. Choose based on your recovery objectives (RTO & RPO), network setup, and operational needs.

Disaggregated or Converged Deployment​

There are two approaches you can take when you architect Portworx Enterprise deployment:

  • Disaggregated deployment - where the storage nodes and compute nodes are in separate groups.
  • Converged deployment - where the compute and storage nodes are in the same group.

Disaggregated Deployment - Separate Storage and Compute Node Groups​

Disaggregated Deployment Architecture

In disaggregated deployment, the storage nodes are in a separate storage node group (for ex, green above), and they have disks associated with them. The compute nodes are in a separate group (for ex, yellow above), and the application container workloads run on these storageless nodes. The Portworx Enterprise installation (for ex, indicated as orange above) spans across both node groups to provide a single storage fabric. The storage and compute node groups are part of the same orchestrator cluster (Single Kubernetes cluster).

You can choose to deploy using a disaggregated model if you have a very dynamic compute environment, where the number of compute nodes can elastically increase or decrease based on workload demand. Some examples of what can cause this elasticity are:

  • Autoscaling up or down due to increasing and decreasing demands. An example would be to temporarily increase the number of worker nodes from 30 to 50 to handle the number of PODs in the system.
  • Instance upgrades due to reasons like kernel updates, security patches or more.
  • Orchestrator upgrades (Example: Kubernetes upgrade)

Separating storage and compute clusters mean such scaling & management operations on the storage cluster don't interfere with the compute cluster, and vice versa.

note

Disaggregated deployment option is recommended in autoscaling cloud environments.

Converged Deployment: Hyperconverged Storage and Compute clusters​

Converged Deployment Architecture

In converged deployment, a single cluster consists of nodes providing both storage and compute. For example, a single Kubernetes cluster. The cluster might have certain nodes that don't have disks. These nodes can still run stateful applications.

Scaling and managing operations on this cluster affect both the storage and compute nodes. This approach is suitable for clusters that typically have the following characteristics:

  • Hyperconverged compute and storage to achieve high performance benchmarks
  • The instances in the cluster are mostly static. This means they don't get recycled very frequently.
  • Scaling up and scaling down of the cluster is not that frequent
  • The cluster admins don't want separation of concern between the Storage and Compute parts of the cluster.

Reference architectures​

Reference architectures for Portworx Enterprise in the different environments are available to help you plan your deployment. These architectures provide guidance on how to set up Portworx in various scenarios, including:

What to do next​

System Requirements

Learn about the system requirements for deploying Portworx Enterprise.

Installing Portworx Enterprise

Learn how to install Portworx Enterprise on your infrastructure.

Last updated on