Bug 17781 - Multiple redundant servers
Summary: Multiple redundant servers
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat High Availability Server
Classification: Retired
Component: piranha   
(Show other bugs)
Version: 1.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Phil Copeland
QA Contact: Phil Copeland
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-09-21 22:46 UTC by blane.dabney@belointeractive.com
Modified: 2007-04-18 16:28 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-09-21 22:46:40 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Red Hat Bugzilla 2000-09-21 22:46:38 UTC
One feature that would be nice in the future is the ability to support 
multiple redundancy, like TurboLinux Cluster Server does.

Comment 1 Red Hat Bugzilla 2000-09-21 23:08:11 UTC
Thanks for your feedback. By this do you mean that:

1. If you failover to a system, and THAT system fails, it failsover to yet
another system? Some people call this a double failure and typically overkill
for HA software solutions, some call it a new single failure.

2. Or do you mean that more than one system can failover to a shared standby?

3. Something else entirely.


Piranha already does something similar to #1, in that if the original system
comes back online and the currently active system fails, it will fail back to
the original system.

In all of the above, we are considering the exmaples as possible architecture
options for future versions of the software.




Comment 2 Red Hat Bugzilla 2000-09-22 15:13:15 UTC
I was referring to the way that TurboLinux handles multiple failover. When you 
set up their clustering routers, you set up a "router pool". When the routers 
first start up (or start up their clustering daemons), they check the status of 
all the other routers in the pool, and if none of them declare themselves as 
master, it will attach the virtual server IP's and declare itself as master. 
After that, TurboLinux arbitrarily decides what priority the other servers will 
have when failing over. I think right now it uses the alphabetical order of the 
hostnames of the routers to determine what order the servers will failover to. 
There's no reason this couldn't be assigned manually. When a router goes down, 
and the services failover to another server, it becomes the master. If the 
original router comes back up, it doesn't try to take the master status. This 
obviously has its good and bad points, but its fairly flexible.

Comment 3 Red Hat Bugzilla 2000-09-25 13:51:20 UTC
Got it. Thanks again.



Note You need to log in before you can comment on or make changes to this bug.