You're right, I am unclear. Some years ago, we tried two versions: storage-based mirroring and host-based mirroring. As the processes were too complicated in our company we decided to mirror the disks host-based. So currently there is a /dev/md0 (simplified) consisting of sda (in Bern) and sdb (in Zurich), and each node has it's own root-fs exclusively.
This cannot work with a shared GFS, as there are several machines doing updates on the FS and no central instance does always know the current state of the device's contents, thus no host-mirroring possible. You are talking of storage-based mirrors. In case of a failure, we would have to direct the storage system to use the second mirror as primary and direct our nodes to write on sdb instead of sda. That will involve controlling the storage from our machines (our storage people will love the idea) and installing the storage-specific software on them. If the Hardware in use changes, we need to re-engineer this solution and adapt to the new storage manufacturer's philosophy, if at all possible. I still have a third opportunity. I can use Qlocig's driver-based multipathing and keep using host-based mirroring instead of using dm-multipath, which currently prevents me from setting up raid-devices as root-fs. Well, that will work, but is somewhat ugly. So far, I had only a short glimpse on OSR. I think I will need to dive deeper. -------- Original-Nachricht -------- > Datum: Fri, 05 Feb 2010 15:18:07 +0000 > Von: Gordan Bobic <[email protected]> > An: linux clustering <[email protected]> > Betreff: Re: [Linux-cluster] Quorum disk over RAID software device > Thomas Meller wrote: > > Many thanks, Gordan. > > > > This could nearly be the solution. > > But as I understand, it's not possible to mirror the root-(g)fs to > another > > computing center despite for relying on a new SPOF (if at all possible) > > or on hardware-dependent solutions. > > Not sure I follow what you mean. If your underlying storage is > synchronously mirrored, you should have no problem with GFS root on top > of it. If things disconnect, of course, it'll split-brain, and one node > will get panicked and need rebooting. > > If your mirrored SAN can't handle it gracefully, you could always use > DRBD to handle the real-time mirroring. That will even re-direct to the > remote storage node in case just the local storage fails. > > Since I added the DRBD functionality to OSR, I'm pretty sure it works. ;) > > > Hmm... our current setup addressed this with half the effort. > > If you need more graceful recovery from network outages (especially the > cross-site interconnect), you could use something like GlusterFS + OSR. > I contributed patches for that, too, but it's a bit experimental. > > > Anyway, does anyone in this forum use this technique and can send me > > the 'init'-script from the initrd? > > I'm still not entirely sure what exactly you're looking for. Can you > elaborate a bit more? > > Gordan > > -- > Linux-cluster mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/linux-cluster -- http://www.openstreetmap.org/?lat=47.172&lon=7.4395&zoom=15&layers=B000FTFTT&mlat=47.16677&mlon=7.43513 NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02 -- Linux-cluster mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-cluster
