i-MSCP 2.0.0 Multi-Server - Possible Layouts

  • 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.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • I would suggest an even more complicated, but also more flexible Layout:


    • Multiple front ends for high availability


    • Separated nodes for services and storage of customer data or databases
    • Back end services on all necessary nodes


  • Benedikt,


    Your schema involves a replication and also a VIP which can be re-assigned to other server at runtime. The problem is that such architecture is not possible everywhere.


    You're talking about hight-availability which is not really our main priority.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • I'm fully interested on this topic.


    From my point of view, here are the Pro and Cons I see on both systems:


    Centralized:


    PROS
    [*]

    • Easy management
    • Just http API needed to comunicate with other server backends

    [*]CONS

    • All servers must be on the same iMSCP version, and same packages installed
    • Probably all servers must have same plugins installed
    • Many services duplicated using resources
    • Different Mail host addresses per each node, or relay needed.



    Distributed


    PROS

    • Optimal resources consumption
    • Big Scalability and possibilities
    • Load balancing according to the resources
    • Plugins managed just by 1 host
    • MySQL/ PostgreSQL servers
    • Maybe apache / nginx servers also

    CONS

    • Harder code development i think
    • srv1 or other host must be relay


    About non-free plugins, in Distributed maybe you must go to a "license per host" model
    Maybe you must think on distribute your software only just for debian, create a repository, and deploy the software like this... apt install imscp-mysql / ismcp-frontend imscp-apache imscp-nginx imscp-mailserver
    Later, just an apt update on each machine will give the last version of the frontend, backend, and rest of services
    On this way, all the people can have the same imscp version with the same rest of packages version and avoid incompatibilities...


    Just ideas...