salesforce Dreamforce On-Demand
Contact Us 1-800-596-4880
  1. Homepage
  2. Anypoint Platform Private Cloud Edition (2.0)
  3. Product Prerequisites

  4. Hardware Prerequisites

Hardware Prerequisites

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.

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.

Memory and CPU Requirements

Component Requirement

RAM

32 GB

CPU

8 Cores
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. Except for the Docker device, all devices must be formatted either as xfs or ext4.

Component Size Minimum IOPS Mount Point Description

HDD 2 System State Directory Device

100 GB

1500

/var/lib/gravity

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.

HDD 3 Application Data Device

250 GB

1500

/var/lib/data

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.

HDD 4 Docker Device

100 GB

3000

Not mounted

Used by Docker’s Device Mapper storage driver. A minimum of 100Gb is required for the Device Mapper directory. Devices with 50Gb or less will experience degraded system performance or might not work at all.

HDD 5 Etcd Device

20 GB

3000

/var/lib/gravity/planet/etcd

Provides dedicated storage for the distributed database used for cluster coordination.

/tmp (Installer)

20 GB

N/A

/ (root)

10 GB

N/A

You must have at least 10GB in your home directory to download and unzip the installer file.
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 your Customer Success Manager.

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 is provided as an example for mounting the etcd device using systemd mount files, and cannot be used as-is in production. The end result of this step mounts the Etcd device to the path /var/lib/gravity/planet/etcd. You can also mount the etcd 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/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 Device Mapper in loopback mode (using /dev/loopX devices), which is not recommended for production. To configure Docker to use a dedicated device for Device Mapper storage driver, an unformatted device or a partition (/dev/sdd) can be provided during installation. This directory is automatically configured and set up for use.

Unformatted devices potentially usable for system directory / Device Mapper are automatically discovered by agents running on each node. Discovered devices are offered on a drop-down menu for configuration before the installation is started.

You can list unmounted devices with the following command:

lsblk --output=NAME,TYPE,SIZE,FSTYPE -P -I 8,9,202|grep 'FSTYPE=""'

Unmounted devices have an empty value in FSTYPE column. Devices with TYPE="part" are partitions on another device. The following command lists only specific device types:

Device type

Description

8

SCSI disk devices

9

Metadisk (RAID) devices

202

Xen virtual block devices (Amazon EC2)

Reset Docker Device

Using Logical Volume Manager, you can group multiple physical volumes into a single storage volume (volume group) and then divide these into logical volumes. Physical volumes are either a whole device or a partition.

When a Docker device is in use by another logical volume or you want to manually reset a Docker device previously configured for Device Mapper, perform the following commands to reset the Docker device:

# In order to clean the Docker volumes, you might need to first reboot the server
# to force clean down any handles to the Docker Device.
# This allows you to perform the proper clean-up.

# Identify whether the docker logical volume was created.
sudo lvs | grep docker
# If the volume exists, remove it.
sudo lvremove docker

# Identify whether the docker volume group was created.
sudo vgs | grep docker
# If the volume exists, remove it.
sudo vgremove docker

# Identify whether the docker physical volume was created.
sudo pvs | grep docker
# If the volume exists, remove it.
sudo pvremove <PV Name>

# Clean the docker device by replacing "{docker-device}" in the following command:
sudo parted /dev/{docker-device} mklabel gpt -s

Verify Devices

To verify that all devices are set up the same way on all nodes, run the lsblk command. 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 {Docker volume (not formatted)}
xvdc    202:32   0   20G   0 disk /var/lib/gravity/planet/etcd
xvdd    202:48   0  250G   0 disk /var/lib/data
xvde    202:64   0  100G   0 disk /var/lib/gravity
xvdf    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.

If using the AWS Provisioner for Anypoint Private Cloud, 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. The load balancer should be accessible through an IP address that is available to all machines in your network.

Your load balancer must route the following TCP ports:

Load Balancer Port Instance Port Internal Usage

80

30080

HTTP redirects to HTTPs.

443

30443

HTTPS port

8889

30889

WebSocket port for Runtimes to connect

9500

32009

Ops Center access port

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:10248/healthz to run a health check on your platform servers and confirm that they are accessible.

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.

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/*.

    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

    server {
   listen 80;
   proxy_pass 0.0.0.0:30080;
}

server {
   listen 443;
   proxy_pass 0.0.0.0:30443;
}

server {
   listen 8889;
   proxy_pass 0.0.0.0:30889;
}

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