Questions about geom-gate and RAID1/10 and CARP

[Michael Schuh]

Hello Eric,
Hello List,

2005/12/16, Michael Schuh <michael.schuh at gmail.com>:
> > There are others, like lustre, gfs, polyserve, etc, however none of them
> > work in FreeBSD at this point.  A few people (including myself) have
> > started a project to port gfs to FreeBSD (gfs4fbsd project on
> > sourceforge).
> Oh i think this was a very good idea......i'm will watch this project.
> another good thing was gpfs from IBM.......
> >
> >
> >
> > I'm wondering actually if you couldn't actually do this with NFS, and
> > hacking some pieces together.  Haven't thought through it, but seems
> > like maybe you could make the active writer an nfs server, that also
> > mounts it's own nfs share rw, but the nfs sharing would be on a virtual
> > interface, or at least the one that 'moves' with your failover.  The
> > other machines would mount that nfs server's export ro, and when it
> > fails over, the one taking over would have to run a script to begin
> > serving that export rw to all, and it's own client would continue its
> > connection but now on it's new virtual interface.  You'd also have to
> > have the ggate stuff set up, so that it was mirroring the original
> > 'master' disk, but when the failover occurred, you would quickly mount
> > your local mirrored disk rw, ignoring the 'unclean' message, begin a
> > background fsck, then start the nfs server on that mount point.  You
> > would probably also have to fail the original drive in the mirror to
> > effectively 'fence' that node from making disk changes at the same time
> > the new master did.
I have made a quick lookup into the coda-doc's and it seems to me,
that coda is exactly the solution for this Problem, but im not
really sure. i do further reading the doc's of coda.......

>
> Oh yes, this was also possible, but i would slunk around the script/cron-hell.
> It wasn't really a hell, but a serious error source.....
> my prior idea was to mount union two different mounted nfs-servers.....
> like your suggestion, but here comes the next problem......unionfs....
> and later the sync.......
>
> I hope a good solution for real HA is around the corner....
>
> michael
>

Thanks to all

regards

michael