[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ha-dev
Subject:    Re: [Linux-ha-dev] ocf script for mysql
From:       Alan Robertson <alanr () unix ! sh>
Date:       2007-03-22 1:43:32
Message-ID: 4601DF44.3050301 () unix ! sh
[Download RAW message or body]

Joe Bill wrote:
> Hi Alan,
> 
> Thank you so much for your insight in your last post.
> 
> --- Alan Robertson <alanr@unix.sh> wrote:
>> Was this of any help?
>>
> 
> You bet!
> 
>> If you need two versions on your machine
>> simultaneously for some other
>> reason (like one customer needs one, and the other
>> needs another), then
>> there are ways of dealing with this - without quite
>> as much madness as
>> the upgrade case.
>>
> 
> Well, I won't hide behind customers to justify this
> need, but may I kindly ask you to elaborate on those
> "other means" you have in mind ?

I had something specific in mind, which might not meet your needs, or
that of some mythical customer ;-).

Let's say I have one web site that needs apache 2.1 and another which
needs apache 2.5.

You install both apache 2.1 and apache 2.5 on your machines in separate
locations by whatever means you like.  They have no files in common
except things like libc.  And for good measure install them on all your
machines.

So, in the resource agent parameters to apache, there is a parameter
called httpd - which is known to the script as OCF_RESKEY_httpd.

There is another parameter called configfile (aka OCF_RESKEY_configfile)
which tells it what apache configuration file to use for this web server.

So, on one of the resources you specify parameters something like this:
  <nvpair name="httpd" value="/path/to/1stwebserver/bin/httpd">
  <nvpair name="configfile" value="/path/to/1stwebserver/httpd.conf">

And in the other one you specify parameters something like this:
  <nvpair name="httpd" value="/path/to/2ndwebserver/bin/httpd">
  <nvpair name="configfile" value="/path/to/2ndwebserver/httpd.conf">

And now everyone is happy, provided that you make your two httpd.conf
files not conflict with each other (in particular they have to have
separate pid files - which are specified in the httpd.conf files).

Heartbeat has no trouble with doing this, and keeping these resources
separate.  But, for any given resource, the version of httpd it uses is
the same - regardless of which machine it's run on.  You can change it
for either resource, and it will take effect immediately.  But you can't
readily use this method to do rolling upgrades like you talked about.
Once you change it -- it changes for all instances of that resource at
once.  (Note that in the example above, there were two separate
resources, not instances of the same resource).  [This talk about
instances of the resource assumes you're running the same web server on
several machines at once as clone resources with a load balancer in
front.  If you do this, then when you change one, you change them all]

Lars also suggested another method -- I think it's documented on the web
site somewhere...

You can also assign arbitrary attributes to nodes, and by changing the
attributes you can also force things to happen.  You could even read the
values of these attributes in your resource agents.

If one really needed to, one could get even more creative to do most any
wild and crazy thing that one wanted to do...  But don't ;-).

Simple is usually best - "Complexity is the enemy of reliability"

For a properly configured HA system, human errors are typically the
causes of the biggest outages.  Complex systems tend to encourage humans
to make more errors.

-- 
    Alan Robertson <alanr@unix.sh>

"Openness is the foundation and preservative of friendship...  Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic