As previously mentioned in a reply to another response, I still question
the savings and I still don't see the benefit. Keeping configuration
files and binaries in sync with each other seems like a full time job if
cloning and /usr sharing were to be used. And contrary to your comment I
would believe that the more systems you have the worst off you are. Today
if I were to go through an upgrade process or a patch process I would
simply apply my patches to each guest as I get scheduled time from my
customers. And continue to proceed in that manner, coordinate with the
customer a time to upgrade / patch their system. No all or nothing stuff.
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.
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. 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.
I appreciate the feedback please keep it coming. I have a planning
meeting with IBM on Monday and I need to argue one way or the other. I am
still not sold on the idea that cloning will work in my environment. And
is DASD really that expensive? I know my time is. Also, is levanta not
the product that once its in its almost impossible to get it out. I am
not certain I like that idea.
Eric Sammons
"Post, Mark K" <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port <[EMAIL PROTECTED]>
01/24/2004 03:20 PM
Please respond to Linux on 390 Port
To: [EMAIL PROTECTED]
cc:
Subject: Re: Pros and Cons to sharing /usr
Yes, these are all tough issues. The answer as to "why" is that, done
correctly, it can significantly reduce the amount of people time to keep
systems maintained, and reduce the (not insignificant) cost of DASD
storage.
Doing it yourself is hard, which is why Linuxcare has produced Levanta,
and
Aduva/BMC has their Deployment Manager for Linux. Neither one of them is
cheap, in Intel terms, but for mainframe class software they're not bad.
The IBM Linux Community Development System has just a couple/few people
managing it, which at one point had 600 concurrent Linux/390 guests
running.
They were able to do this because of their extensive home-grown automation
for system creation/deletion, sharing of /usr, etc. (Richard Lewis has
given a couple presentations on this automation.) I think they're down to
"only" 250 or so at the moment, but they didn't have to remove anyone from
the support team because of the reduced workload. The system was just
that
scalable that the number of guests didn't affect how much work they needed
to do.
In the final analysis, if you're only going to be dealing with, say, less
than 10 Linux/390 systems, it may not be worth your time to worry about
the
whole thing. If you get up into the 20-30-40 range, suddenly the savings
get pretty big, pretty fast.
Mark Post
-----Original Message-----
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Eric Sammons
Sent: Saturday, January 24, 2004 9:28 AM
To: [EMAIL PROTECTED]
Subject: Pros and Cons to sharing /usr
In today's Unix world we tend to put everything, almost, under /. With
the elimination of the 2GB filesystem limit there hasn't been a need to
split out every filesystem for quite some time. However, in looking at
the cloning documentation there is a suggestion that /usr/src and /usr be
shared as R/O. I am wondering what others have found to be the pros and
cons to this? Also, is it possible to share other filesystems? I have
heard my management state that the sharing of WebSphere binaries would be
desired, I am personally not sure that that is possible. And to be honest
I am not sure that the sharing of /usr is a good idea. Being experienced
in Linux/x86 and other variants of Unix this is my reasoning for not
liking the sharing /usr.
There have been and will continue to be numerous times where an upgrade to
the binaries (found in /usr) depend on a configuration file in /etc. /etc
clearly is not a filesystem nor is it part /usr. This being the case my
greatest fear is that /usr binaries would be upgraded while leaving legacy
/etc configurations behind that may or more likely will not work. One
example might be the going from inetd to xinetd. Other examples might be
configuration parameters specific to one version of a product, OpenLDAP,
may not work in a future version thus preventing the applicaiton from
starting. And to make matters worst /var, having to be unique to each
system has been known to see changes that are directly impacted by a newer
version of a binary. Take Apache as an example when they moved the
default DOCROOT from /home to /var. And because apache installs its
configurations in /etc, there lies the biggest issue, the potential to
change or touch /etc, /home, /var, and /usr. So my question is why would
sharing /usr be a good idea? and how would you ensure that the
configurations are up-to-date on all guests after an upgrade has been done
to the master copy. And finally the entire sharing thing, unless planned
very carefully, could result in an all or nothing situation. All guests
get upgraded and it works or all guests get upgraded and nothing works. Of
course with planning this can be addressed.
Thoughts? Is anyone cloning? Yes, how are you addressing the /etc
issues?
Thanks!
Eric Sammons
