On 07/27/2011 08:05 AM, Jason Guiditta wrote:
> On Wed, 2011-07-27 at 10:43 -0400, Hugh Brock wrote:
>> On Wed, Jul 27, 2011 at 10:26:08AM -0400, Jason Guiditta wrote:
>>> Hello list (and Steve), I have been tasked with looking into the
>>> following nebulous feature item for consideration of being included in
>>> Iteration 4:
>>> '* HA configuration available?'
>>>
>>> This is from an 'infrastructure around aeolus' perspective, if that
>>> helps context at all.
>>>
>>> There was brief discussion of this in an extremely broad way on a recent
>>> call, and given my lack of involvement with anything HA, I find myself
>>> with absolutely no idea how to describe what might need doing here, let
>>> alone how it might be done. I will be looking through the list archives
>>> to see what has been discussed, but all the threads I recall seeing were
>>> very long and detailed, and I would rather get a synopsis if someone can
>>> summarize the current thinking in this area. Also, any links to specific
>>> threads or documentation/designs would be much appreciated. Thanks for
>>> any direction here,
>>
>> Sure.
>>
>> One of the requirements the SAs brought up is that it should be
>> possible to make Conductor and its attendant pieces highly
>> available. I'm not sure this is something we need to actually
>> implement for release 0.4.0, but it would be nice to at least have a
>> design for it by then. At a minimum we would need the entire app to be
>> able to run in failover mode on two machines. We don't have to provide
>> the infrastructure to deal with the failover, but the app needs to
>> handle being failed over gracefully without data loss or (much)
>> service interruption.
>>
>> Does that help at all?
>>
>> --Hugh
>>
>
> If that is really the gist, then yes, it is a start, thanks. Sounds
> like a feature to see how to best setup rails/$backing-db to be
> clustered, and possibly separate tasks to research same some some of the
> other components (iwhd seems a likely candidate). However, I have this
> feeling there is much more to it than that. Perhaps this task/feature
> is a combination of documenting how to do some of these thing, and
> writing up what what does and does not currently exist for this kind of
> scenario? Also, probably something around 'what is going to be the
> aeolus story for HA, and what does it mean?'.
>
> -j
>
>
Jason,
Our current plans around HA are focused on providing high levels of
service availability for resources/assemblies/deployables. A good
understanding of HA theory as well as our plans is explained here:
http://www.redhat.com/summit/2011/presentations/summit/whats_new/thursday...
Since this task is on HA of the infrastructure itself (rather then the
end user applications), I'd recommend looking into refining this task to
the following:
* Contain infrastructure in a deployable *
Rather then has been previously suggested, this is not a circular
dependency issue or infinite regression issue, but rather a
bootstrapping task, much like creating a toolchain.
Why go to the trouble? We get automatic high availability (from
www.pacemaker-cloud.org), the ability to scale out, and an easy
configuration model for our users.
If you like, my team will take on this task during the next iteration.
Steve,
One thing to consider is that (perhaps) not everyone will want to run
the Aeolus infrastructure in the cloud that they are managing. I agree
that this is a valid deployment model, but perhaps does not cover the
span of what people will want.
So to address the various deployment models for Aeolus, how about:
1. Separate bare metal cluster of hosts that run Aeolus infrastructure
components that utilizes the 'Cluster Stack' (be it rgmanager or
Pacemaker based) to provide HA of those server components
2. Deploy Aeolus infrastructure on internal cloud (RHEV, VMware, etc)
and monitor/provide HA via Pacemaker Cloud
The former is really just a documentation effort and perhaps creation of
some resource agents specific to aeolus components. So limited dev work
needed here
The latter is (I think) what you are getting at. No objection to it,
just think that it is complementary with the rgmanager/Pacemaker solution
Thoughts?
Perry