Re: RFC: updating cluster.conf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Teigland wrote:
Hi,

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
   feedback.)

After stabilizing the config, ~never, but probably will be something like 1 per 6months. Prior to setting the system in production, very frequent updates (several per day).

2. What changes do you make?  e.g. add nodes, change fencing settings,
   add or change rgmanager settings.

During test, change fencing settings, modify services / hosts.

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?

Cluster online:
 1. Edit cluster.conf.new in Puppet working copy
 2. Commit to Puppet SVN
3. "puppetd -t" on all nodes or verify that cluster.conf.new is updated on all nodes if Puppet is running automatically.
 4. "ccs_tool update /etc/cluster/cluster.conf.new"

Like about it :
 * Centralized storage of all configuration in Puppet
 * Full control of update process
* Revision control of configuration makes it easier to debug errors due to changes

Areas that could be improved :
 * Very manual process

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?

Would be great if I could have some sort of automated loading of configuration changes when all nodes have the correct version of the config.

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.

Maybe. Not sure if the added complexity would be worthwhile in this small setup. For larger clusters I understand the benefits.

Should at least be an optional way of doing things imho.

Regards
--
DenisB

--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster

[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux