Re: High Availability options

Stephen Kirkpatrick wrote:
> Ed Wilts wrote:
>> On Thu, Jul 13, 2006 at 11:23:48AM -0500, Stephen Kirkpatrick wrote:
>>  
>>> I am seeking advice from those of you who have experience with high
>>> availability on RHEL3.  I have been researching this through Google
>>> and have observed several options, but don't know what would be most
>>> appropriate for our deployment.
>>>     
>>
>> I think you're simply out of luck with a Linux-based solution on your
>> current hardware.  All of the HA solutions essentially allow a stateless
>> application to fail over from node to node.  ssh requires an active
>> state and an active connection.  After all, the application has
>> permanent memory assigned.  Your hardware failure could be memory so you
>> have to realize that the only way you can survive this is if the memory
>> is redundant.
>>
>>  
>>> My main concern with providing HA for our environment is to not
>>> interrupt our SSH login sessions.  While there are other network
>>> services running, such as Apache, these services could tolerate a
>>> short interruption in the event of a failover.
>>>     
>>
>> To survive hardware failures for an ssh session, you'll need
>> fault-tolerant hardware like a Tandem system.  They're extremely pricey
>> but they do what they're designed to do - basically give you 100% uptime
>> for your front-end application so it can talk to back-end servers that
>> have failover functionality.
>>
>> You might be cheaper off rewriting your application to eliminate the ssh
>> front-end, or else to allow that to fail and have a user sign back on to
>> another host in a cluster quickly.  The latter is what I do with my
>> VMScluster - the cluster has over 7 years of uptime, but if a node
>> crashes, the user loses his/her session and immediately signs back on
>> again and starts working again.  The application has to start up
>> quickly, and hopefully you've got some sort of journalling within your
>> app, but you don't have a lot of choices.
>>
>> Your problem is not HA software - it's HA hardware.  No add-on software
>> that I'm aware of will maintain your ssh state while the system crashes
>> out from under it.
>>
>>         .../Ed
>>
>>   
> Thanks for the reply. We are using proprietary third party
> development tools, so we are stuck with using SSH for the
> login session (or rewriting nearly 20 years worth of development
> in another language). While no interruption of the sessions would
> be desired, a brief interupption would be tolerable. I will
> then plan on using the scheme you mentioned where the users log
> back into the system after a node goes down.
> 
> With that being said, any recommendations for HA software?
> 
> Thanks,
> Stephen Kirkpatrick
> 
> -- 
> Taroon-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/taroon-list

I use the RH cluster tools.  They are fairly well documented; the 
biggest problem I had was the implementation details - things like 
single host SCSI chains, and a mounting/failover plan to prevent two 
hosts from accessing the same partition at the same time.  I use HP 
DL380s with an MSA500 shared SCSI storage, and haven't had many problems 
at all.  The problems I have had were usually due to my error and not 
the HW or SW.  I plan on experimenting with GFS this fall.

--
Taroon-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/taroon-list