[Linux-ha-dev] A proposal for setup and management tools
Andrew Beekhof
beekhof at gmail.com
Thu Dec 16 14:17:13 MST 2004
The easy one first...
> 2) Support resource group in release 2
> Now there is no resource group function in release 2 as release 1.x
not true (anymore). support for resource groups has already been added to CVS.
Moving on...
I much prefer manage-arch2.jpg as it also allows you to create a
simple daemon which then could work as manage-arch1.jpg would.
In fact we can even use SWIG to create python (or was it perl?)
bindings which opens up yet more possibilities for people to write
admin tools.
> 1) Need to add client library for some daemons, such as crmd.
> It's not suitable to call a *admin*tools to interact with a daemon in another
> program written or a python binding library.
Can you clarify what you're saying here? I'm not convinced I
understand you accurately enough to comment.
Lastly, I would like to draw your (and others') attention to the new
and improved CIB. Most people probably dont know that recent changes
mean it is now a completely entity from the CRM.
It has a nice little client API (if I do say so myself), will
automatically synchronize changes to the entire cluster and comes with
a notification engine and sample client. Notifications result from
changes to the CIB, this currently includes:
- nodes leaving, joining or failing
- resources starting, stopping, failing
- nodes, resources, constraints being added, updated or removed
- probably something else thats slipped my mind
Its even been written such that the "backend" could be replaced by a
database, an LDAP server, or anything anyone is crazy enough to use.
Right now there is only CRM data in there but there is no reason why
other subsystems could not also put their configuration in there too.
So please consider how you might be able to leverage this in the
overall management layout. Of course I have the odd idea and I'd be
happy to answer any related questions.
Andrew
On Thu, 16 Dec 2004 23:49:59 +0800, Sun Jiang Dong <hasjd at cn.ibm.com> wrote:
> We'll begin to implement setup and management tools for linux-ha cluster. Before
> that, put our thought here, your feedbacks and proposals are appreciated.
>
> By the way, will put this document to wiki later, and the future detailed
> document&design will be only putted there.
> http://wiki.trick.ca/lha
>
> Wish to throw out a minnow to catch a whale. ;-)
>
> 1. Which release will it support?
> Currently only for the future release 2 after taking the time into account. It
> is much more necessary for release 2, because it is more complex to
> setup/configure/management release 2 than release 1.
>
> As for release 1, let's provide the same function tools in the future according
> to the users' requirements.
>
> 2. Function Scope
> * Cluster setup/initial configuration
> - Create the initial configuration files and validate them.
> - Distribute the configuration files to the other nodes.
> Perhaps use scp to do that, but can be configurated by a user.
> - Start up the cluster if the user want.
>
> * Cluster management/administration
> - Nodes addition & remove, including start/stop.
> - Resources addition & removing & movement.
>
> * Not to do
> - Cluster status notification, will it be done by the new monitor and
> recovery subsystem?
>
> 3. Top level architecture
> There are two options, please help us to choose the better. Or provide a
> another from you. ;-)
>
> 1) Option one with a management daemon
>
> * Diagram
> Please refer to the first attachment.
> Besides, the management daemon can run on only one node or several nodes.
>
> * Its advantage.
> - Can log the status history, since it's always running.
>
> * Its disadvantage.
> - a bit more complex. At least have to face the security issue.
> - May need to provide different versions of its client. For example, for
> Linux, MacOS, FreeBSD, windows and etc. Even more, may need provide different
> binary for different linux distributions such as suse8, suse9, redhat9, fedora...
>
> * Questions
> - Need provide a character window based tool with the same function?
>
> 2) Option two without a management daemon
> * Diagram
> Please refer to the second attachment.
>
> * Its advantage.
> - Seems a bit more simple.
> - Don't need to face the security issue. For example, when a administrator
> want to manage cluster remotely, he can just ssh to one node and run the
> character window based tool. The network flow is little enough to support even a
> dialing line.
>
> * Its disadvantage.
> - Cannot log the status history, since it's not always running.
> - To access remotely, have to provide a character window based tool, or the
> GUI tool will squish the low speed network connection.
>
> 4. Language & widget
> - C for daemon and others.
> - Python and TK for the GUI tools and others.
> - Curse or newt for the character window based tool.
> - The user interface will written in python plus TK.
> - If the user interface written in gtk or qt, may require a specific
> environment.
> - Now APIs of many components are not stable enough, so use python plus TK to
> adapt to this temporary situation.
>
> 5. Sketch map of the management tool
> please refer to the third attachment, for your preview.
> Now we hope to merge the setup(initial configuration) and management
> functions into only a single tool instead of two separate tools.
>
> 6. Open issues
> 1) Need to add client library for some daemons, such as crmd.
> It's not suitable to call a *admin*tools to interact with a daemon in another
> program written or a python binding library.
>
> 2) Support resource group in release 2
> Now there is no resource group function in release 2 as release 1.x
>
> 3) Other ways for remote accessing the cluster management function.
> Support webmin and others?
>
> 4) Need a wizard for setup/initial configuration?
>
> 5) ... (Please give yours, TIA. ;-) )
>
> --
> BRs,
>
> Sun Jiang Dong
>
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>
>
>
>
More information about the Linux-HA-Dev
mailing list