G'day Eric, On Sat, 24 Jan 2004, Eric Sammons wrote:
> Perhaps I should explain my business, we service, well about 13 very > unique customers. Each has their own application and environment > requirements. Each has their own operating hours and SLAs. I am not an > ISP, but I am a service provider. I simply provide the service of an > environment where my customers pay me to run their applications in my > environment. This environment is primarily web and websphere applications > with of course back end databases. This probably makes it harder for you to realise the benefits of sharing. If all your customers are different there is very little in common between them, hence an increasing complexity in trying to share between them. You may only benefit from sharing if each customer is runs 20+ images of their own, and all of the images within a customer's area are identical. > So with this said you can see that management of said environment will be > a challenge. And each guest will be unique in some way, be it from the > actual configuration or simply the SLA. In this scenario I do not believe > that a shared filesystem will work when the risk of having a mismatched > /usr and /etc is so great. Nobody says that a site will have *only one* /usr, shared by everyone. In your case maybe two or three customers have a build similar enough that they could share, or (as I mentioned previously) one customer has a high enough number of identical images that sharing between those images becomes viable. In any environment that does sharing, there will be two numbers: the number of shareable /usr filesystems to be maintained (I'll call this U) and the total number of guests in the environment (G). As U approaches G, due to the uniqueness of guests, the value gained from sharing decreases. Each individual site would have to choose the threshold for U where sharing is inviable -- for one site it might be G/2, for another site it might be G-1. > And then should I run a shared /usr filesystem how do I ensure that /etc > and /var are kept up to date. We must remember that /var contains the > rpm database. WebSphere, IBM HTTPD, and IBM DB2 I believe all make use > of the rpm database, what are the risks associated with having the > package database so far out of whack. Installs may not work correctly > because a prerequisite is falsely listed as failed, though there are > ways around this, it seems like a huge risk. Sharing /usr, to a certain extent, means that parts of other filesystems are also shared. For an RPM distribution, that means the RPM database too (possibly amongst other things). The basevol/guestvol proposal from the Large Scale Redbook discusses this, IIRC, using bind mounts and other tricks. Regardless of the options available for sharing though, it might just not be a good fit for your site. For that reason, products like Levanta may provide a better way of managing your particular needs. Hoo-roo, Vic Cross
