[Linux-cluster] RFC: updating cluster.conf
jstoner at opsource.net
Mon Jun 23 20:06:18 UTC 2008
1. and 2. Our cluster changes across all clusters happen on an
infrequent basis (6 or fewer a month) and typically involve simple
changes such as changing a SAN mount point (changing the device name or
where to mount it,) adding a SAN mount or changing the user password for
our fencing devices.
3. How we propogate the changes depends on who's making the change. I
typically roll several changes (app and cluster) into the same
maintenance window so I can bring down the cluster, at which point I
simply vi the cluster.conf files (after testing the changes in staging,
making backups, etc. etc. etc.) Other sys admins use ccs_tool to roll
out simple changes. We don't have Conga deployed because, quite frankly,
it wasn't enterprise ready when we last tested it (RHEL4 flavor, we have
not deployed any RHEL5 clusters.)
4. While I prefer delimited flat files, there are occassions where a
more structured config file is warranted (Apache jumps to mind.) I
detest the use of XML as a straight-up configuration file. I am not an
XML parser. That being said, what I would like to see for a command-line
interface to configuration is something similar to what Augeas
(augeas.net) aims to provide. A program that parses the existing config
into a tree in memory, then acts as a shell to allow me to browse the
tree, make changes as appropriate then validate the changes when it
writes out the config or aborting with appropriate error messages on
Using a "Augeas-type" tool might look something like the following:
> get /files/etc/cluster/cluster.conf/1/name
> set /files/etc/cluster/cluster.conf/1/name fred
> set /files/etc/cluster/cluster.conf/1/fence_domain/post_join_delay 10
Successfully deployed configuration version 97 to cluster "fred"
The "save" command would validate the configuration and write out the
XML file. The "deploy" command would push the config to the other
clusters the way css_tool does today.
My understanding from the Augeas talk at the Redhat Summit is no lenses
have been created that deal with XML-formatted files and David believes
it's possible to do, he just simply hasn't tried it yet.
I absolutely do not want to install X just to use system-config-cluster.
We have clusters around the world and the latency imposed by the network
on top of the latency of forwarding X over ssh is too painful. Our half
dozen cluster admins all share this view.
5. Does it have to be LDAP? Can you make it a pluggable architecture w/
API so we can use whatever backend we want (MySQL/Postgres/SQLite, LDAP,
Active Directory, DT+BG server*, etc.)? This feature should be optional,
though. Centralized management of cluster configurations would be nice
but, as others have said, introduces possible dependencies and points of
*Duct Tape and Bubble Gum
Sr. Systems Engineer/Performance Engineer
"Your Success is Our Success"
> -----Original Message-----
> From: linux-cluster-bounces at redhat.com
> [mailto:linux-cluster-bounces at redhat.com] On Behalf Of David Teigland
> Sent: Monday, June 23, 2008 12:16 PM
> To: linux-cluster at redhat.com
> Subject: [Linux-cluster] RFC: updating cluster.conf
> We're looking into how cluster.conf updates should be done in future
> versions and we'd like some feedback about how you currently
> do this, and
> what you'd like to see.
> 1. How often do you update cluster.conf? ("Never" would be valuable
> 2. What changes do you make? e.g. add nodes, change fencing settings,
> add or change rgmanager settings.
> 3. How do you currently update cluster.conf? Cluster online
> or offline?
> Manually scp to all nodes? ccs_tool? conga? What do you
> like and not
> like about the method you use now?
> 4. How would you like to do updates to cluster.conf in the future?
> Conga (graphical management interface)? Command line program that
> updates /etc/cluster/cluster.conf on all cluster nodes?
> Manually scp to all nodes? Other?
> 5. Would you like to use an LDAP server? All cluster nodes would read
> cluster.conf info from the server; updates would just be made on
> the server.
> Linux-cluster mailing list
> Linux-cluster at redhat.com
More information about the Linux-cluster