RE: package management on clusters

From: Matthew Zito <>
Date: Thu, 12 Feb 2009 21:01:59 -0500
Message-ID: <>

Well, there's a couple ways to do this. First off, OS packages can get pretty ugly for this sort of thing, for the reasons you've identified, but also because most OS packages only allow you to install one instance of a package. So, the instant you want to do separate homes, let's say, you can't just do a pkgadd -d Oracleinstall.pkg again to make a separate home. Also, most OS packaging systems are lousy about changing layout or configuration - so you might be able to change the root directory, but if you want to do something like "oracle gets installed in /u01/app/oracle/{version}/{sid}", you can't without all sorts of horrible post-script mojo.

But back to ways to deal with this problem -

One is (let's get this out of the way quickly) you can use a cluster-aware database deployment and automation software package like the one my company makes, which removes the whole OS packaging out of the picture, and handles these types of environments.

Another is that you actually move the content out of the OS package, and basically use the scripts in the package to do everything. In this scenario, the package has a placeholder file, something like /etc/pkgname.isinstalled (or whatever you want to call it), and nothing else for the content, but there are post-scripts that run. That post-script looks for the presence of the files on the CFS, and if not found, it contacts an external fileserver and downloads the tarball and extracts it. When the same package is installed on the other node, the script sees the files are already there and simply downloads the local bits. Uninstall works in reverse - you could even do something crafty like having the remove post-script detect whether it's the last node being removed from (i.e. you put your placeholder files on the CFS, so when there's just one left, you know that's the last node), and if it is, it removes the CFS components.

The last is to use a configuration management system that is built like a state machine, instead of around packages. You would define a configuration based on the files, and when it's done on the first node, it will install everything, when it runs on the second node, it will see most of the files are already there. I believe you can do this with Bladelogic (now owned by BMC), and Puppet is an open-source config management system that can do this.

Hope this helps,

-----Original Message-----

From: on behalf of Jeremy Schneider Sent: Thu 2/12/2009 8:22 PM
Subject: package management on clusters  

This question is peripherally related to Oracle... but maybe someone has a good idea.

Does anyone have a suggestion for managing packages on a cluster? We typically repackage database binaries as RPMs for wide-scale deployment. Most of the clusters we have currently utilize a CFS. Support scripts are installed onto the CFS with a tarball and we arbitrarily pick a node to install the database server package onto the CFS. The other nodes don't know that the database package is installed and the OS package inventories across the cluster are out of sync. We manually sync up the Oracle inventories as part of the installation (happily, they are cluster-aware).

Any ideas how we could manage files which are installed into a cluster filesystem and available across the cluster? Should they even be registered in the OS's package DB or perhaps we should just use a tarball? (But we don't want another database server package to make with every build. and there are some great benefits to the package management on non-cluster systems...) Not really interested in actually running the installer in silent mode since it's much faster this way and we have tight control over server configurations the package is getting installed into.

I really can't think of a good solution that keeps the benifits of package management without the downsides of non-cluster-aware-ness on both Solaris and Linux.



Jeremy Schneider
Chicago, IL


-- Received on Thu Feb 12 2009 - 20:01:59 CST

Original text of this message