Centralized Control Panel - Decentralized Services

In theory, all you'd need to do is create a "base-line" install with or without the GUI frontend of Webmin/Virtualmin for each system which manages all the core system features like "users, quotas, etc".

Then instead of having each system take on the load of managing all web-facing services, you'd simply allow someone to install (perhaps using the VM installer) the services they want that node to handle.

Finally, in your "master" virtualmin installation (the management interface), you'd tell the system which server or group of servers are handling what task.

Personally for me, it doesn't have to be overly complex. It just means that the management server needs to keep track of which server to poll for each service based on domain or account ownership. Since the agents could be setup to "push" data back to the management server, this could effectively take away some of the challenges of the management server having to figure out where everything is.

Just another two cents on the topic ;-)

BTW, Webmin/Virtualmin already in my opinion has most of the key components in place, it's just a matter of allowing one installation to act as a master over the others, and remove or disable features not needed on certain nodes so that load is managed, and tasks are allocated.

-Peter

An illustration of the perfect cluster (at least for my needs)

*** Naturally there could be further separation than listed above, but that's just to give you an idea. ***

The idea behind this design is to have Virtualmin at the top of the architecture, handle all management (Manager) of accounts through a central control panel.

The rest of the cluster would be designed a way which allows for scaling to almost unlimited capacity by grouping nodes to handle a smaller amount of tasks (ie: Web, Mail, MySQL, etc)

If you like this kind of design, please post your comments here so we can rally enough interest in this design, and work together to iron out the best deployment strategy.

-Peter

It should be noted as stated in a former comment, that each node would likely have a thin layer of Virtualmin Agent (as I like to refer to it as) which handles the communication between nodes, and the "Manager". This would also handle tasks like user/group management, quotas, and other basic node operations.

Optionally, there could be a GUI for each node allowing a system administrator to do maintenance on a specific node if required.

*** These are all just ideas at the moment ***

-Peter

Jamie,

I've considered over the past few weeks, putting "Cloudmin for Physical Systems" into our network design. Would this version work with what you're mentioning here?

We utilize VPS's which then run Virtualmin at the moment. This allows us to provision machines in multiple geographical regions. Our VPS infrastructure was in place long before Cloudmin matured, and has worked for us well. However, I believe using the non-VPS version mentioned above could become useful for managing our cluster of nodes.

*** On another note, I noticed in the API documentation that it seems the Cloudmin API is a bit limited in terms of managing services and creating domains across multiple machines, in comparison to Virtualmin's API (obvious Virtualmin has been around longer and is more mature).

Our current cluster makes use of a custom built database, and a set of shell run scripts that run to execute the Virtualmin API for a select service, on a group of nodes. (ex. web, dns, and mysql *** mail is currently outsourced to Google Apps, though this may be changing soon given Google's recent announcement on the topic). ***

-Peter

Jamie,

Just a thought to consider, perhaps to make Cloudmin that much more powerful as a sort of "console" would be to allow Cloudmin to issue commands to each of the individual Virtualmin installs.

That is, say I want to setup:

"hosting" on server #1

"mysql databases" on server #2

"dns" on server #3 and server #4

"email" on server #5

You might be able to issue from Cloudmin something like:

cloudmin create-domain --domain mydomain.com --hosting "s1" --mysql "s2" --dns-master "s3" --dns-slave "s4" --email "s5"

Which would cause a user to be created on each of the servers, along with the appropriate services enabled.

This ofcourse is a pretty rough example, but I'm sure you can see what I'm talking about.

What would make such a feature even more interesting would be to later offer the ability to choose which node a domain/service is added to based on "resources" and "groups".

"groups" would be say "hosting" (which would include all your hosting servers), "mysql" (which would include all your mysql servers).

"resources" would be say "cpu", "memory", "disk space", etc...

This added functionality would be nifty, cause then Cloudmin would be sort of the "manager" of all these servers where as Virtualmin would then handle the actually tasks on the individual nodes.

Further, say I setup a cluster of "hosting", "mysql", etc nodes in my "Fremont, CA" data center, I could then make sure that an account is created on all nodes that belong to that data center... (ex. "hosting-fremont", "mysql-fremont", etc)

Just adding to the brainstorming as always :-)

Feel free to run with any of these ideas, or any variation of them...

-Peter

Jamie,

I hear what you're saying, however in our custom design which is powered by Virtualmin, we just create the same user on multiple nodes. Then enable each service individually. This simplifies a bit of what you're saying because each node operates technically, independently. No NFS or LDAP required.

Maybe this type of design (that we're using) isn't always consider optimal, it is however in some ways more simply and why not make things simple if you can :-)

*** NFS, and LDAP offer as you noted complexity, so I try not to do this type of stuff if possible ***

If one node dies, it won't take down the rest because they're running independently. It technically means that Cloudmin is just secretly talking to Virtualmin's individual API in theory... Just making issuing a command to a number of nodes a bit easier than doing them all manually one by one.

The other thing is, for services that don't require shell access (mail, mysql, etc) you simply don't enable it for that user on that node :-)

*** you could go one step further by not adding unneeded directories to the home of each user on each node. don't need a maildir on a "hosting-only" node for instance, or a public_html directory on a "mail-only" node. these directories and related settings could be added based on what that node is suppose to handle. ***

-Peter