---
schema_version: "1"
id: 9394dcca39548d3005a7a561432a626b2838626be0e06ce9bafe33fe71c967d6
title: Hardware Prerequisites
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/private-cloud/3.2/prereq-hardware.md
canonical_url: https://docs.mulesoft.com/private-cloud/3.2/prereq-hardware
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 12ebaee83b7d05b8ea153e677650c0a91e3ab6193a036f5252f7041034d565df
description: MuleSoft Documentation Site
release: "3.2"
latest: false
---
---
product: Anypoint Platform Private Cloud Edition
version: 3.2
---

# Hardware Prerequisites

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

To ensure the performance and stability of Anypoint Platform Private Cloud Edition (Anypoint
Platform PCE), every node in your Anypoint Platform PCE environment must meet the requirements
described in this topic.

> [!IMPORTANT] Before you install Anypoint Platform PCE, your infrastructure team must review each
> of the following sections and verify that your environment meets the stated disk and device
> requirements. If needed, contact your MuleSoft representative for assistance.

There are 2 components of PCE:

- Anypoint Platform Core

- Anypoint Monitoring (optional)

To ensure platform performance, stability, and high availability, Anypoint Platform Private Cloud
Edition (Anypoint Platform PCE) supports two network configurations: 4-node and 7-node.

Small configuration:

- 4 nodes for Control Plane

- 3 additional nodes for Anypoint Monitoring (optional add-on)

- NFS for asset storage

- Load balancer

Large configuration:

- 7 nodes for Control Plane

- 3 additional nodes for Monitoring (optional)

- NFS for asset storage

- Load balancer

To ensure high availability and performance, each node must run on its own server in both
configurations. If you are using a virtual machine to host the nodes, you must ensure that each VM
node is running on a separate physical server.

## Anypoint Platform Core

Prerequisites for 4-nodes or 7-nodes to run the Anypoint Platform Core.

### Memory and CPU Requirements

The following are the minimum requirements needed for the Anypoint Platform core. Depending on your
environment, you may need more CPU or memory.

<table><caption>Table 1. Memory and CPU Requirements</caption> <colgroup><col> <col></colgroup><thead><tr><th>Component</th><th>Requirement</th></tr></thead><tbody><tr><td><p>RAM</p></td><td><p>32 GB</p></td></tr><tr><td><p>CPU</p></td><td><p>8 Cores</p></td></tr></tbody></table>

> [!IMPORTANT] If the stated requirements for Memory and CPU are not met, Anypoint Platform PCE
> installation will fail.

For production environments, each node in your configuration must have the following dedicated
devices. All devices must be formatted either as **xfs** or **ext4**.

<table><caption>Table 2. Dedicated Device Requirements</caption> <colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Component</th><th>Size</th><th>Minimum IOPS</th><th>Mount Point</th><th>Description</th></tr></thead><tbody><tr><td><p>HDD 2 <a href="#system-state-directory-device">System State Directory Device</a></p></td><td><p>250 GB</p></td><td><p>1500</p></td><td><p>/var/lib/gravity</p></td><td><p>Stores system configuration and metadata, including databases and packages. Because package sizes can be large, it is important to estimate the minimum size requirements and allocate enough space as a dedicated device before installation.</p></td></tr><tr><td><p>HDD 3 <a href="#application-data-device">Application Data Device</a></p></td><td><p>250 GB</p></td><td><p>1500</p></td><td><p>/var/lib/data</p></td><td><p>Stores application configuration and data. The amount of space required should be at least 250 GB, but can vary depending on your specific use case. It is important to estimate the minimum size requirements and allocate enough space as a dedicated device ahead of time.</p></td></tr><tr><td><p>HDD 4 <a href="#docker-device">Docker Device</a></p></td><td><p>100 GB</p></td><td><p>3000</p></td><td><p>/var/lib/gravity/planet/docker</p></td><td><p>Used by Docker’s overlay storage driver. A minimum of 100GB is required for the overlay directory. Devices with 50GB or less will experience degraded system performance or might not work at all.</p></td></tr><tr><td><p>HDD 5 <a href="#etcd-device">Etcd Device</a></p></td><td><p>20 GB</p></td><td><p>3000</p></td><td><p>/var/lib/gravity/planet/etcd</p></td><td><p>Provides dedicated storage for the distributed database used for cluster coordination.</p></td></tr><tr><td><p>/tmp (Installer)</p></td><td><p>50 GB</p></td><td><p>N/A</p></td><td></td><td></td></tr><tr><td><p>/ (root)</p></td><td><p>50 GB</p></td><td><p>N/A</p></td><td></td><td><p>You must have at least 50GB in your home directory to download and unzip the installer file.</p></td></tr></tbody></table>

> [!NOTE] The space requirements listed in the previous table are based on average use. For
> environments with heavy traffic, validate the amount of space needed with MuleSoft Professional
> Services.

### System State Directory Device

The main purpose of the system state directory device is to store system configuration and metadata,
for example, database and packages. As package sizes can be arbitrarily large, it is important to
estimate the minimum size requirements and allocate enough space for the dedicated device.

Format this device either as `xfs` or `ext4` and mounted as `/var/lib/gravity`.

The following shell snippet is provided as an example for mounting the system state directory device
using systemd mount files and cannot be used as-is in production. You can also mount the system
state directory device by using `/etc/fstab` or some other method. Consult with your system
administrator to determine the best way to meet this requirement. If you use the following example
to guide this process, make sure to specify the correct device name in two places.

sudo mkfs.ext4 /dev/<device name> sudo mkdir -p /var/lib/gravity echo -e
"\[Mount\]\\nWhat=/dev/<device name>\\nWhere=/var/lib/gravity\\nType=ext4\\n\[Install\]\\nWantedBy=local-fs.target"
| sudo tee /etc/systemd/system/var-lib-gravity.mount sudo systemctl daemon-reload sudo systemctl
enable var-lib-gravity.mount sudo systemctl start var-lib-gravity.mount

### Application Data Device

The main purpose of the application data directory device is to store application configuration and
data. The minimum amount of space required is 250GB, but your use case might require more. It is
important to allocate enough space for the dedicated device.

Format this device either as `xfs` or `ext4` and mounted as `/var/lib/data`.

The following shell snippet is provided as an example for mounting the application data device using
systemd mount files, and cannot be used as-is in production. You can also mount the application data
device using `/etc/fstab` or some other method. Consult with your system administrator to determine
the best way to meet this requirement. If you use the following example to guide this process, make
sure to specify the correct device name in two places.

sudo mkfs.ext4 /dev/<device name> sudo mkdir -p /var/lib/data echo -e
"\[Mount\]\\nWhat=/dev/<device name>\\nWhere=/var/lib/data\\nType=ext4\\n\[Install\]\\nWantedBy=local-fs.target"
| sudo tee /etc/systemd/system/var-lib-data.mount sudo systemctl daemon-reload sudo systemctl enable
var-lib-data.mount sudo systemctl start var-lib-data.mount

### Etcd Device

The main purpose of the etcd device is to provide dedicated storage for a distributed database used
for cluster coordination. It does not require much space, 20GB is adequate.

Format this device either as `xfs` or `ext4` and mounted as `/var/lib/gravity/planet/etcd`.

The following shell snippet mounts the etcd device using systemd mount files to the path
`/var/lib/gravity/planet/etcd`.

You can also mount the etcd device using `/etc/fstab` or another method. Consult with your system
administrator to determine the best way to meet this requirement. If you use the following example
as a guide for this process, specify the correct device name in two places.

> [!NOTE] Mount this device AFTER you mount the System State device under `/var/lib/gravity/planet`.
> If you are using systemd units to mount the volumes, declare mount dependencies using
> `After=<device-name>.<mount>`.

sudo mkfs.ext4 /dev/<device name> sudo mkdir -p /var/lib/gravity/planet/etcd echo -e
"\[Mount\]\\nWhat=/dev/<device name>\\nWhere=/var/lib/gravity/planet/etcd\\nType=ext4\\n\[Install\]\\nWantedBy=local-fs.target"
| sudo tee /etc/systemd/system/var-lib-gravity-planet-etcd.mount sudo systemctl daemon-reload sudo
systemctl enable var-lib-gravity-planet-etcd.mount sudo systemctl start
var-lib-gravity-planet-etcd.mount

### Docker Device

Unless specified, Docker configuration defaults to the use of the overlay driver, which is
recommended for production.

Format this device as `xfs` or `ext4` and mount as `/var/lib/gravity/planet/docker`.

The following example shell snippet mounts the Docker device using `systemd` mount files to the path
`/var/lib/gravity/planet/docker`. You can also mount the Docker device using `/etc/fstab` or another
method. Consult with your system administrator to determine the best way to meet this requirement.
If you use the following example as a guide for this process, replace `<device name>` with the
correct device name in two places.

> [!NOTE] Mount this device AFTER you mount the System State device under `/var/lib/gravity/planet`.
> If you are using system.d units to mount the volumes, declare mount dependencies using
> `After=<device-name>.<mount>`

sudo mkfs.ext4 /dev/<device name> sudo mkdir -p /var/lib/gravity/planet/docker echo -e
"\[Mount\]\\nWhat=/dev/<device name>\\nWhere=/var/lib/gravity/planet/docker\\nType=ext4\\n\[Install\]\\nWantedBy=local-fs.target"
| sudo tee /etc/systemd/system/var-lib-gravity-planet-docker.mount sudo systemctl daemon-reload sudo
systemctl enable var-lib-gravity-planet-docker.mount sudo systemctl start
var-lib-gravity-planet-docker.mount

## Anypoint Monitoring

Anypoint Monitoring is an optional add-on that Anypoint Private Cloud supports. See
[Anypoint Monitoring on Anypoint Platform PCE](https://docs.mulesoft.com/private-cloud/3.2/anypoint-monitoring) for more information.

Prerequisites: The extra 3 nodes for the Monitoring Center Add-On.

### Memory and CPU Requirements

Monitoring Center Add-On hardware requirements are different from the Platform Core nodes, they
require more CPU, more memory and different disk mounts.

<table><caption>Table 3. Memory and CPU Requirements</caption> <colgroup><col> <col></colgroup><thead><tr><th>Component</th><th>Requirement</th></tr></thead><tbody><tr><td><p>RAM</p></td><td><p>128 GB</p></td></tr><tr><td><p>CPU</p></td><td><p>32 Cores</p></td></tr></tbody></table>

For production environments, each node in your configuration must have the following dedicated
devices. All devices must be formatted either as **xfs** or **ext4**.

<table><caption>Table 4. Dedicated Device Requirements</caption> <colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Component</th><th>Size</th><th>Minimum IOPS</th><th>Mount Point</th><th>Description</th></tr></thead><tbody><tr><td><p>HDD 2 <a href="#system-state-directory-device">System State Directory Device</a></p></td><td><p>250 GB</p></td><td><p>1500</p></td><td><p>/var/lib/gravity</p></td><td><p>Stores system configuration and metadata, including databases and packages. Package sizes can be large, so it is important to estimate the minimum size requirements and allocate enough space as a dedicated device before installation.</p></td></tr><tr><td><p>HDD 3 <a href="#docker-device">Docker Device</a></p></td><td><p>100 GB</p></td><td><p>3000</p></td><td><p>/var/lib/gravity/planet/docker</p></td><td><p>Used by Docker’s overlay storage driver. A minimum of 100GB is required for the overlay directory. Devices with 50GB or less will experience degraded system performance or might not work at all.</p></td></tr><tr><td><p>HDD 4 <a href="#dias-amv-device">Cassandra AMV Device</a></p></td><td><p>500 GB</p></td><td><p>1500</p></td><td><p>/var/lib/data/dias-meld &amp; /var/lib/data/dias-cassandra</p></td><td><p>Stores Cassandra database data for Monitoring Center Add-On. The amount of space required should be at least 250 GB, but can vary depending on your specific use case. It is important to estimate the minimum size requirements and allocate enough space as a dedicated device ahead of time.</p></td></tr><tr><td><p>HDD 5 <a href="#stolon-amv-device">Stolon AMV Device</a></p></td><td><p>250 GB</p></td><td><p>1500</p></td><td><p>/var/lib/data/stolon-amv</p></td><td><p>Stores Postgres database data for Monitorng Center Add-On. The amount of space required should be at least 250 GB, but can vary depending on your specific use case. It is important to estimate the minimum size requirements and allocate enough space as a dedicated device ahead of time.</p></td></tr><tr><td><p>HDD 7 <a href="#influxdb-amv-device">InfluxDB AMV Device</a></p></td><td><p>4 TB</p></td><td><p>1500</p></td><td><p>/var/lib/data/influxdb</p></td><td><p>Stores InfluxDB data for Monitoring Center Add-On. The amount of space required should be at least 250 GB, but can vary depending on your specific use case. It is important to estimate the minimum size requirements and allocate enough space as a dedicated device ahead of time.</p></td></tr><tr><td><p>HDD 7 <a href="#logstash-amv-device">logstash AMV Device</a></p></td><td><p>500 GB</p></td><td><p>1500</p></td><td><p>/var/lib/data/logstash</p></td><td><p>Stores Logstash data for Monitoring Center Add-On. The amount of space required should be at least 250 GB, but can vary depending on your specific use case. It is important to estimate the minimum size requirements and allocate enough space as a dedicated device ahead of time.</p></td></tr><tr><td><p>/tmp (Installer)</p></td><td><p>20 GB</p></td><td><p>N/A</p></td><td></td><td></td></tr><tr><td><p>/ (root)</p></td><td><p>10 GB</p></td><td><p>N/A</p></td><td></td><td><p>You must have at least 10GB in your home directory to download and unzip the installer file.</p></td></tr></tbody></table>

> [!NOTE] The space requirements listed in the previous table are based on average use. For
> environments with heavy traffic, validate the amount of space needed with MuleSoft Professional
> Services.

### System State Directory Device

The main purpose of the system state directory device is to store system configuration and metadata,
for example, database and packages. As package sizes can be arbitrarily large, it is important to
estimate the minimum size requirements and allocate enough space for the dedicated device.

Format this device either as `xfs` or `ext4` and mount as `/var/lib/gravity`.

The following shell snippet is provided as an example for mounting the system state directory device
using `systemd` mount files and cannot be used as-is in production. You can also mount the system
state directory device by using `/etc/fstab` or some other method. Consult with your system
administrator to determine the best way to meet this requirement. If you use the following example
as a guide for this process, replace `<device name>` with the correct device name in two places.

sudo mkfs.ext4 /dev/<device name> sudo mkdir -p /var/lib/gravity echo -e
"\[Mount\]\\nWhat=/dev/<device name>\\nWhere=/var/lib/gravity\\nType=ext4\\n\[Install\]\\nWantedBy=local-fs.target"
| sudo tee /etc/systemd/system/var-lib-gravity.mount sudo systemctl daemon-reload sudo systemctl
enable var-lib-gravity.mount sudo systemctl start var-lib-gravity.mount

### Docker Device

Unless specified, Docker configuration defaults to the use of the overlay driver, which is
recommended for production.

Format this device as `xfs` or `ext4` and mount as `/var/lib/gravity/planet/docker`.

The following example shell snippet mounts the Docker device using `systemd` mount files to the
path: `/var/lib/gravity/planet/docker`. You can also mount the Docker device using `/etc/fstab` or
another method. Consult with your system administrator to determine the best way to meet this
requirement. If you use the following example as a guide for this process, replace `<device name>`
with the correct device name in two places.

> [!NOTE] Mount this device AFTER you mount the System State device under `/var/lib/gravity/planet`.
> If you are using system.d units to mount the volumes, declare mount dependencies using
> `After=<device-name>.<mount>`

sudo mkfs.ext4 /dev/<device name> sudo mkdir -p /var/lib/gravity/planet/docker echo -e
"\[Mount\]\\nWhat=/dev/<device name>\\nWhere=/var/lib/gravity/planet/docker\\nType=ext4\\n\[Install\]\\nWantedBy=local-fs.target"
| sudo tee /etc/systemd/system/var-lib-gravity-planet-docker.mount sudo systemctl daemon-reload sudo
systemctl enable var-lib-gravity-planet-docker.mount sudo systemctl start
var-lib-gravity-planet-docker.mount

### DIAS Data Device

The main purpose of the DIAS Data directory device is to store Monitoring Center Add-On Cassandra
and Meld database data. The minimum amount of space required is 250GB, but your use case might
require more. It is important to allocate enough space for the dedicated device.

Format this device either as `xfs` or `ext4` and mount as `/var/lib/data`.

The following shell snippet is provided as an example for mounting the application data device using
`systemd` mount files, and cannot be used as-is in production. You can also mount the application
data device using `/etc/fstab` or some other method. Consult with your system administrator to
determine the best way to meet this requirement. If you use the following example as a guide for
this process, replace `<device name>` with the correct device name in two places.

sudo mkfs.ext4 /dev/<device name> sudo mkdir -p /var/lib/data echo -e
"\[Mount\]\\nWhat=/dev/<device name>\\nWhere=/var/lib/data\\nType=ext4\\n\[Install\]\\nWantedBy=local-fs.target"
| sudo tee /etc/systemd/system/var-lib-data-dias.mount sudo systemctl daemon-reload sudo systemctl
enable var-lib-data-dias.mount sudo systemctl start var-lib-data-dias.mount

Once mounted, create the following dirs if necessary on every Monitor Center Add-On node:

- /var/lib/data/dias-cassandra

- /var/lib/data/dias-meld

### Stolon AMV Device

The main purpose of the Stolon AMV directory device is to store Monitoring Center Add-On Postgres
database data. The minimum amount of space required is 250GB, but your use case might require more.
It is important to allocate enough space for the dedicated device.

Format this device either as `xfs` or `ext4` and mount as `/var/lib/data/stolon-amv`.

The following shell snippet is provided as an example for mounting the application data device using
`systemd` mount files, and cannot be used as-is in production. You can also mount the application
data device using `/etc/fstab` or some other method. Consult with your system administrator to
determine the best way to meet this requirement. If you use the following example as a guide for
this process, replace `<device name>` with the correct device name in two places.

sudo mkfs.ext4 /dev/<device name> sudo mkdir -p /var/lib/data/stolon-amv echo -e
"\[Mount\]\\nWhat=/dev/<device name>\\nWhere=/var/lib/data/stolon-amv\\nType=ext4\\n\[Install\]\\nWantedBy=local-fs.target"
| sudo tee /etc/systemd/system/var-lib-data-stolon-amv.mount sudo systemctl daemon-reload sudo
systemctl enable var-lib-data-stolon-amv.mount sudo systemctl start var-lib-data-stolon-amv.mount

### InfluxDB AMV Device

The main purpose of the InfluxDB AMV directory device is to store Monitoring Center Add-On InfluxDB
data. The minimum amount of space required is 250GB, but your use case might require more. It is
important to allocate enough space for the dedicated device.

Format this device either as `xfs` or `ext4` and mount as `/var/lib/data/influxdb`.

The following shell snippet is provided as an example for mounting the application data device using
`systemd` mount files, and cannot be used as-is in production. You can also mount the application
data device using `/etc/fstab` or some other method. Consult with your system administrator to
determine the best way to meet this requirement. If you use the following example as a guide for
this process, replace `<device name>` with the correct device name in two places.

sudo mkfs.ext4 /dev/<device name> sudo mkdir -p /var/lib/data/influxdb echo -e
"\[Mount\]\\nWhat=/dev/<device name>\\nWhere=/var/lib/data/influxdb\\nType=ext4\\n\[Install\]\\nWantedBy=local-fs.target"
| sudo tee /etc/systemd/system/var-lib-data-influxdb.mount sudo systemctl daemon-reload sudo
systemctl enable var-lib-data-influxdb.mount sudo systemctl start var-lib-data-influxdb.mount

Once mounted, create the following dirs if necessary on every Monitor Center Add-On node:

- /var/lib/data/influxdb/data

- /var/lib/data/influxdb/meta

### Logstash AMV Device

The main purpose of the Logstash AMV directory device is to store Monitoring Center Add-On Logstash
database data. The minimum amount of space required is 250GB, but your use case might require more.
It is important to allocate enough space for the dedicated device.

Format this device either as `xfs` or `ext4` and mount as `/var/lib/data/logstash`.

The following shell snippet is provided as an example for mounting the application data device using
`systemd` mount files, and cannot be used as-is in production. You can also mount the application
data device using `/etc/fstab` or some other method. Consult with your system administrator to
determine the best way to meet this requirement. If you use the following example as a guide for
this process, replace `<device name>` with the correct device name in two places.

sudo mkfs.ext4 /dev/<device name> sudo mkdir -p /var/lib/data/logstash echo -e
"\[Mount\]\\nWhat=/dev/<device name>\\nWhere=/var/lib/data/logstash\\nType=ext4\\n\[Install\]\\nWantedBy=local-fs.target"
| sudo tee /etc/systemd/system/var-lib-data-logstash.mount sudo systemctl daemon-reload sudo
systemctl enable var-lib-data-logstash.mount sudo systemctl start var-lib-data-logstash.mount

## Verify Devices

To verify that all devices are set up the same way on all nodes, run the `lsblk` command on the
Anypoint Monitoring and Visualizer nodes. Output from `lsblk` should resemble the following example:

\[root@ip-0-0-0-0 ~\]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 90G 0 disk ├─xvda1
202:1 0 1M 0 part └─xvda2 202:2 0 90G 0 part / xvdb 202:16 0 100G 0 disk
/var/lib/gravity/planet/docker xvdd 202:48 0 250G 0 disk /var/lib/data xvde 202:64 0 250G 0 disk
/var/lib/gravity xvdf 202:64 0 250G 0 disk /var/lib/data/stolon-amv xvdg 202:64 0 250G 0 disk
/var/lib/data/influxdb xvdh 202:64 0 250G 0 disk /var/lib/data/logstash xvdi 202:64 0 20G 0 disk
/tmp

## Verify Disk IOPS

Depending on your hardware or virtualization provider, you can configure disk IOPS (I/O operations
per second). Using the `iops` command, verify available IOPS on each device:

$ sudo ./iops --time 2 /dev/xvdb /dev/xvdb, 107.37 GB, 32 threads: 512 B blocks: 1893.0 IO/s, 946.5
KiB/s ( 7.8 Mbit/s) 1 KiB blocks: 1354.8 IO/s, 1.3 MiB/s ( 11.1 Mbit/s) 2 KiB blocks: 1091.8 IO/s,
2.1 MiB/s ( 17.9 Mbit/s) 4 KiB blocks: 807.1 IO/s, 3.2 MiB/s ( 26.4 Mbit/s) 8 KiB blocks: 803.7
IO/s, 6.3 MiB/s ( 52.7 Mbit/s) 16 KiB blocks: 787.4 IO/s, 12.3 MiB/s (103.2 Mbit/s) 32 KiB blocks:
700.8 IO/s, 21.9 MiB/s (183.7 Mbit/s) 64 KiB blocks: 590.0 IO/s, 36.9 MiB/s (309.3 Mbit/s) 128 KiB
blocks: 327.6 IO/s, 40.9 MiB/s (343.5 Mbit/s) ...

## Load Balancer Requirements

Anypoint Platform PCE must run in a production environment with multiple servers. To distribute
traffic among servers and to restrict access to specific ports, you must provide and configure a
load balancer.

You can use any load balancer, including NGINX, but NGINX is not required.

> [!NOTE] If using the [AWS Provisioner for Anypoint Platform PCE](https://docs.mulesoft.com/private-cloud/3.2/prereq-aws-terraform), you do not
> need to configure a separate load balancer. An Amazon ELB with the required configuration is
> created during installation.

### Load Balancer Configuration

You can configure your load balancer to use any method for distributing client requests, but in most
contexts a round robin strategy is ideal. Make sure the load balancer is accessible through an IP
address that is available to all machines on your network (including the Anypoint Platform PCE
nodes)

Your load balancer must route the following TCP ports:

<table><caption>Table 5. TCP Port Routing Requirements</caption> <colgroup><col> <col> <col></colgroup><thead><tr><th>Load Balancer Port</th><th>Instance Port</th><th>Internal Usage</th></tr></thead><tbody><tr><td><p><code>80</code></p></td><td><p><code>30080</code></p></td><td><p>HTTP redirects to HTTPs</p></td></tr><tr><td><p><code>443</code></p></td><td><p><code>30443</code></p></td><td><p>HTTPS port</p></td></tr><tr><td><p><code>8083</code></p></td><td><p><code>30883</code></p></td><td><p>HTTPS port for Mule runtimes to authenticate and renew certificates</p></td></tr><tr><td><p><code>8889</code></p></td><td><p><code>30889</code></p></td><td><p>WebSocket port for Mule runtimes to connect</p></td></tr><tr><td><p><code>8895</code></p></td><td><p><code>30895</code></p></td><td><p>(Only when Monitoring Center is enabled)</p></td></tr><tr><td><p><code>9500</code></p></td><td><p><code>32009</code></p></td><td><p>Ops Center access port</p></td></tr></tbody></table>

In each case, your load balancer must listen on the load balancer port and redirect incoming
requests to the instance port. Your Anypoint Platform PCE installation includes an internal NGINX
server that listens on each of the configured instance ports, and then performs the action listed in
the Internal Usage column.

Your load balancer should poll the address `HTTP:10256/healthz` to run a health check on your
platform servers and confirm that they are accessible.

> [!NOTE] Do not configure SSL certificates in your load balancer. TLS termination is handled by the
> platform with the certificates configured using Access Management. See
> [Configure Anypoint Platform PCE](https://docs.mulesoft.com/private-cloud/3.2/config-workflow).

### Implement a Load Balancer Using NGINX

1.  Enable stream block in your `/etc/nginx/nginx.conf` file by referencing all the configuration
    properties defined in `/etc/nginx/stream.d/*`.

    ```json
    stream {
       include /etc/nginx/stream.d/*.conf;
    }
    ```

2.  Delete the `default.conf` file from `/etc/nginx/conf.d`

3.  Create a folder named `/etc/nginx/stream.d` and in it create a file named `onprem.conf`

4.  Paste the following content in `onprem.conf`

    ```json
    server {
       listen 80;
       proxy_pass 0.0.0.0:30080;
    }

    server {
       listen 443;
       proxy_pass 0.0.0.0:30443;
    }

    server {
       listen 8083;
       proxy_pass 0.0.0.0:30883;
    }

    server {
       listen 8889;
       proxy_pass 0.0.0.0:30889;
    }

    server {
       listen 8895;
       proxy_pass 0.0.0.0:30895;
    }

    server {
       listen 9500;
       proxy_pass 0.0.0.0:32009;
    }

    server {
       listen 9501;
       proxy_pass 0.0.0.0:30083;
    }
    ```

5.  Enable the default ports on SELinux before starting the NGINX. Run the following commands one by
    one:

    semanage port -a -t http\_port\_t -p tcp 8083 semanage port -a -t http\_port\_t -p tcp 8889
    semanage port -a -t http\_port\_t -p tcp 8895 semanage port -a -t http\_port\_t -p tcp 9500
    semanage port -a -t http\_port\_t -p tcp 9501

6.  Start NGINX:

    service nginx restart

## See Also

- [Environment Prerequisites](https://docs.mulesoft.com/private-cloud/3.2/prereq-platform)

- [Software Prerequisites](https://docs.mulesoft.com/private-cloud/3.2/prereq-software)

- [Network Prerequisites](https://docs.mulesoft.com/private-cloud/3.2/prereq-network)

- [NFS Server Prerequisites](https://docs.mulesoft.com/private-cloud/3.2/verify-nfs)

- [Preinstallation Verification](https://docs.mulesoft.com/private-cloud/3.2/prereq-gravity-check)

- [Nginx](https://www.f5.com/products/nginx)

- [Anypoint Monitoring](https://docs.mulesoft.com/private-cloud/3.2/anypoint-monitoring)