Centralized management layout
i-MSCP srv1
- i-MSCP Frontend
- i-MSCP backend for managed services
- Http, Ftp, SQL, SMTP/POP/IMAP... services
i-MSCP srv2
- i-MSCP backend for managed services
- Http, Ftp, SQL, SMTP/POP/IMAP... services
i-MSCP srv3
- i-MSCP backend for managed services
- Http, Ftp, SQL, SMTP/POP/IMAP... services
...
That layout is fairly simple. Many i-MSCP servers are managed through the same i-MSCP frontEnd instance. The simplest way for managing such layout is to allow the administrator to specify how many clients a server can host. It should be also possible to assign a specific server to one reseller.
Distributed services layout
i-MSCP srv1
- i-MSCP Frontend
- i-MSCP backend for managed services
- Http, Ftp Service
i-MSCP srv2
- i-MSCP backend for managed services
- Database service (MySQL)
i-MSCP srv3
- i-MSCP backend for managed services
- Database service (MySQL)
i-MSCP srv4
- i-MSCP backend for managed services
- Database service (PostgreSQL)
i-MSCP srv5
- i-MSCP backend for managed services
- Mail service (SMTP/POP/IMAP)
i-MSCP srv6
- i-MSCP backend for managed services
- Mail service (SMTP/POP/IMAP)
...
This layout is really more complicated. Here, we stay with a single i-MSCP frontEnd instance but the services are distributed through several servers. Implementation of such a layout is more difficult in sense that we must found out how to and where to store client data. One of the way is to operate on a per subscription plan basis. Here, each subscription should define a feature set, and according those features, client data would be assigned to differents servers. Another way (more simple to my eyes) is to allow the administrator to create virtual i-MSCP servers (abstract concept). Here, an i-MSCP virtual server would be composed of many servers, each providing one or many services. A virtual server should fullfit some requirements (must provide expected services as a whole) to be valid. Then, each client, as in the precedent layout, would be assigned to a specific virtual server.