Many times we were asked to implement support for centralized database (DB) and file storage. Which is understandable because these two features open up many convenient hosting-building scenarios that were previously unavailable or could be created only at your own risk. And also because the fewer single points of failure (SPOF) you have, the more resistant you are to faulting the solution. However, since the release of Plesk Obsidian 18.0.49, using centralized DB (as Beta) and Network File System (NFS) has become possible. Let’s find out what you can do with each of these features.
Please note if you are interested only in the centralized database feature, you can go directly to the ‘Shared or Centralized Database‘ section. However, if you want to locate vhosts files on NFS, you can skip the information about databases and start from the ‘Network File System‘ section. There is no requirement to configure these features together – each can work as a stand-alone feature if you want.
Shared or Centralized Database
Previously, it was a requirement to have a locally running database because Plesk uses it for storing its own database (called “psa”). Even if you connect an external database for the customers’ websites, you must have a local database service for Plesk. This means that you have to maintain that database like install security updates, make backups, watch logs, increase disk and other resources to the server if required, etc. And if you have lots of Plesk servers, it generates lots of additional work. This imposes another serious limitation: you can only use the database that can be installed on the operating system you are using.
But what has changed since Plesk Obsidian 18.0.49? Let’s dive a bit deeper to find out a few new scenarios:
- You can use much less databases for a fleet of Plesk servers, it reduces the amount of maintenance work with the database(s).
- You can move a database from Plesk to another server in a private network, it will increase security.
- Separating web and database services allows you to optimize each server for required tasks, e.g. adding more memory to database servers and allowing them to utilize all available memory, without competitive use with other services.
- It allows the use of MySQL-compatible databases that previously was not supported by Plesk because they could not be installed on the same server together with Plesk. An example of a possible solution is the Galera Cluster for MySQL, which provides a true multi-master and active-active cluster.
- If you prefer a SaaS database from cloud providers, you don’t even need to have a server for the database. And maintenance work can be done via the web-interface. However, this database must be compatible with one of the databases supported by Plesk.
There is also a few cons:
- If you use a single database for all Plesk servers, the database becomes a single point of failure for all those Plesk servers.
- A network speed and connectivity between database server and Plesk should be good enough and stable.
New Servers Deployment
Let’s start. It is not possible to convert an existing Plesk installation to Plesk with a remote ‘psa’ database; it should be for new Plesk installations only. I decided to use Oracle Cloud because of ARM servers and their attractive conditions of free tier for those servers.
First, I create a private network (“local”, 10.0.0.0/24) so that the traffic between Plesk and the database server goes inside this network. To make network setup easier, I allow all traffic inside the private network. As you can see in the image below, I also have a network with public access (“internet”).
English 
Français
Leave a Reply