 | | | High Availability options | High Availability options 2006-07-13 - By Clint Bowen
Back
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
> Taroon-list@(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
Taroon-list@(protected)
https://www.redhat.com/mailman/listinfo/taroon-list
|
|
|