On-Premises Private

Pre installation

Systems Requirements

For a normal installation of CARTO Builder On-Premises, the following hardware requirements are needed:

• 8GB memory
• 4 CPU cores

Although it is possible that your installation may work with lower resources, stability of the platform is not guaranteed. It is recommended to use the the optimal requirements.

The platform is only compatible with Red Hat and CentOS 7.x / 8.x servers using systemd.

A clean installation is required. No other service, or extra software, should be running in the same server. This ensures that you will avoid any incompatibility or resources sharing issues.

The only extra packages required are redhat-lsb-core and gcc: (These prerequisites for the server should be installed before the On-Premises installation)

1
sudo yum -y install gcc redhat-lsb-core

System Recommendations

It is a very common need to perform debugging operations in the system where CARTO BUILDER is installed, especially when support is involved. The installation of the process, network, IO, and memory debugging tools is highly recommended.

1
sudo yum -y install tcpdump strace lsof net-tools sysstat procps

In order to avoid caching and logging issues is recommended to run a Time Synchronization software.

Disk Considerations

Some parts of CARTO intensively use the disk. It is important to have a proper configuration of the disks in production, to avoid disk IO bottlenecks.

There is no a silver bullet regarding the configuration of the disks. The performance of the disks may have a impact on the general performance of CARTO, but there are not any restriction to run CARTO on only one disk. For example, as long as the disks is big enough to store all the data, logs, backups, etc.

There are several components that rely on sensible usage of disk space.

PostgreSQL

In PostgreSQL, CARTO stores Builder metadata and user data. The more Builder is used, the bigger the usage of metadata storage in PostgreSQL. Metadata resource consumption will only be significant under very high Builder usage. With low usage, and a reduced number of Builder users, metadata disk usage should be less noticeable.

Regarding user data, the disk usage in terms of size and performance depends on the amount of data CARTO users are storing, and the amount (and type) of queries that they are running. More complex queries against bigger datasets typically involve more disk IO operations; especially if the dataset is not in memory, if there are indexes missing, or if the queries require intensive sorting operations.

Redis

In Redis, CARTO stores some type of application metadata that is normally used by the NodeJS APIs, and by Builder application. Redis can be configured to not persist data in disk. CARTO configuration persists data with redis. When redis decides that it needs to write memory data in disk, it forks the process and writes the data. The frequency that redis uses to store the data is configurable. The performance impact of this write operations in disk should be very low, even for loaded environments. Read operations will not have default disk IO impact, since all the data is configured to be in memory.

Backups

Data backups should be done frequently. At the very minimum, there should be backups of redis and postgresql dbs.

Regarding PostgreSQL, the strategy to write the WAL transactions to dist in order to do backups, or possible replications in the future, will impact directly on the disk size usage and the IO performance. There are several PostgreSQL configuration parameters that can be modified in order to have different transactions behavior. This involves transactions committing frequency, size thresholds, etc. You can have aggressive WAL transactions writing configurations, in order to minimize data loss in case of server crash, but this comes with a performance cost.

Logs

Logs are another type of CARTO data that grows in time. It is recommended to have a good log rotation policy and send archived CARTO logs outside of the server.

Temporal Data

CARTO requires a certain amount of disk to perform temporal data processing. There are two main operations that will write temporal data. Importing and exporting. The performance of the disk for these operations must not be exceptionally high, but depending on the data the user is going to import in CARTO and export from it, there may be a required high disk partition. Once the import/export operation has finished, any data stored in this partition is useless and can be destroyed.