1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

Plesk Multi Server preview

Discussion in 'Official Announcements' started by custer, Sep 15, 2016.

Thread Status:
Not open for further replies.
  1. GrZeCh

    GrZeCh New Pleskian

    0
    20%
    Joined:
    Apr 12, 2016
    Messages:
    3
    Likes Received:
    0
    Hello,

    any suggestions about this error:

    Code:
    Attempt: 1
    [2016-10-07T16:38:52+02:00] DEBUG Begin init procedure
    [2016-10-07T16:38:52+02:00] DEBUG Init procedure finished
    [2016-10-07T16:38:57+02:00] DEBUG Task has no prerequisite task
    [2016-10-07T16:38:57+02:00] DEBUG Run
    [2016-10-07T16:38:57+02:00] DEBUG Deploy service node
    [2016-10-07T16:38:58+02:00] ERR Deployer is not specified: Class is not specified
    
    during new Subscription provisioning?

    Thanks
     
  2. trialotto

    trialotto Golden Pleskian Plesk Guru

    37
     
    Joined:
    Sep 28, 2009
    Messages:
    1,445
    Likes Received:
    206
    @korsar and @custer

    A very rough manual has been provided

    but I noticed that there is no information (at all) with respect to the proper settings of IP addresses.

    As far as I can see right now, the following applies

    - the extension is not really able to deal with internal IPs (read: IPs in an internal network, of the form 10.0.0.x or similar)
    - the extension requires a public IP, but will not use that when an Onyx instance is on an internal network
    - some issues with public and internal IPs exist: for instance, using the management node to change a dedicated IP to a shared IP on the slave node will not result in a change when trying to create a new subscription (the process contains the IP value "dedicated", which should be "shared" after the change on the slave node. Settings seem to be sticky and only the removal of the node and re-assignment of the node will resolve this "sticky value" issue.)

    I would like to ask you to provide some information about this particular topic, which is very relevant for the Multi Server extension.

    After all, a "master/slave" setup is often accompanied by an internal network.

    By the way, there are some issues with page refreshing: at first, this seemed to be a problem associated with the extension, but it is more common (also on other pages).

    Regards........
     
  3. korsar

    korsar Basic Pleskian Staff Member

    25
    37%
    Joined:
    Dec 29, 2007
    Messages:
    38
    Likes Received:
    2
    @trialotto manual is in progress right now, this one is a draft. Multi Server is not released yet, as you can see in Extensions catalog.

    Regarding internal and public IPs. Could you describe your expectations?
    IP, which is used for service node registration is public since it's used for navigation between panels installed to management node (panel to provide central management experience) and service node (panel to manage a particular subscription). You possibly want to protect API communication between management and service node, but all communications are performed via usual Plesk API gate, which is exposed on a public IP for every Plesk instance.
     
  4. trialotto

    trialotto Golden Pleskian Plesk Guru

    37
     
    Joined:
    Sep 28, 2009
    Messages:
    1,445
    Likes Received:
    206
    @korsar,

    The best safeguard for API communications is present with an internal network, connecting the master and service nodes only.

    A public IP can then be added to the internal network, (only) allowing access to the Onyx panels from the outside.

    The problem with the Multi Server extension is that it (at least in a lot of situations) does not work with internal IPs (for instance 10.0.0.x) or public IPs.

    There are some things that I found remarkable: the extension is

    - resolving the internal IP to the correct (internal) FQDN (with the internal FQDN being equal to the hostname)
    - connecting to the service node with both the internal and public IP

    and it really seems to be the case that the Onyx master node wants (read: requires) a matching (public) FQDN hostname, resolvable through (public) DNS.

    I suppose that the bottleneck is related to the way FQDN hostnames are associated with (internal or public) IPs.

    This also makes another problem relevant: the way in which Plesk (in general) changes the hostname (it makes a mess of /etc/hosts when changing the hostname via the Plesk Panel and that is something new, since this issue was not really present in the past).

    In short, there is some additional work to do.

    Nevertheless, all of the above is something that you can experience for yourself, in one of my Onyx labs.

    Just start a conversation, if you want to look for yourself (and also in the case that you want to await some additional testing with alternative hostnames).

    Regards!
     
  5. Reboot

    Reboot Basic Pleskian

    5
    70%
    Joined:
    Feb 7, 2016
    Messages:
    31
    Likes Received:
    1
    So, another vote for a small connector daemon here, keeping the Plesk Panel on the management node only. The most ideal setup I like is where service nodes only contain the services I want them to serve. So, say, if a node is a webserver, only a webserver (and MySQL if chosen) is installed on the node. No panel, the panel port can be closed. Everything regarding configuration happens within the management node.

    In such a setup it's easy to keep the management channel within the private network. I agree this is more service-orchestration oriented, but I'm still convinced it's the best way security, performance and flexibility-wise.

    Edit: I just saw CloudLinux isn't supported for Multi Server. Is this a limit of CloudLinux or Plesk? Or will CL eventually be supported in the (near?) future?
     
    Last edited: Oct 23, 2016
  6. Sidimar Carniel

    Sidimar Carniel New Pleskian

    4
    20%
    Joined:
    Aug 22, 2016
    Messages:
    6
    Likes Received:
    1
    Location:
    Brazil
    Hello,

    There is some expectation on Roadmap:
    Update #1, Update #2, Update #3?

    Thanks
     
  7. korsar

    korsar Basic Pleskian Staff Member

    25
    37%
    Joined:
    Dec 29, 2007
    Messages:
    38
    Likes Received:
    2
    We are planning monthly updates.
     
  8. korsar

    korsar Basic Pleskian Staff Member

    25
    37%
    Joined:
    Dec 29, 2007
    Messages:
    38
    Likes Received:
    2
Thread Status:
Not open for further replies.
Loading...