Messages in this thread |  | | Date | Wed, 16 May 2001 08:34:00 +0200 (CEST) | From | Christoph Biardzki <> | Subject | Storage - redundant path failover / failback - quo vadis linux? |
| |
Hi,
I was investigating redundant path failover with FibreChannel disk devices during the last weeks. The idea is to use a second, redundant path to a storage device when the first one fails. Ideally one could also implement load balancing with these paths.
The problem is really important when using linux for mission-critical applications which require large amounts of external storage.
There are two solutions for Linux at the moment:
- The "T3"-Patch for 2.2-Kernels which patches the sd-Driver und the Qlogic-FC-HBA-Driver. When you pull an FC-Cable on a host equiped with two HBAs the failover is almost immediate and an automatic failback (after "repairing") is possible
- The "multipath"-Personality-patch for the md-Driver by Ingo Molnar (intergrated in the redhat 2.4.2-Kernel) You set up an md-device on two devices (which are actually the same physical device seen twice on the dual paths) and when the primary one fails, the system will access the other one. There seems to be no failback possibility, however, and the failover takes around 30s.
My question is which way is the more probable solution for future linux kernels?
The low-level-approach of the "T3"-patch requires changes to the scsi-drivers and the hardware-drivers but provides optimal communication between the driver and the hardware
The high-level-approach of the "multipath"-personality is hardware-independant but works very slowly. On the other hand I see no clear way how to check for availability of the (previously failed) primary channel to automate a fail-back.
Neither driver imlement load-balancing at the moment.
Does anyone have an idea how these integration problems are solved in ther OSs?
Best regards,
Christoph
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |