Date: Thu, 15 Dec 2005 12:55:06 +0100 From: Michael Schuh <michael.schuh@gmail.com> To: Eric Anderson <anderson@centtech.com> Cc: Ivan Voras <ivoras@fer.hr>, freebsd-geom@freebsd.org Subject: Re: Questions about geom-gate and RAID1/10 and CARP Message-ID: <1dbad3150512150355r576b1b0j@mail.gmail.com> In-Reply-To: <439ED00E.7050701@centtech.com> References: <1dbad3150512090509l2ab08e03k@mail.gmail.com> <43998C95.3050505@fer.hr> <1dbad3150512130421i5278d693g@mail.gmail.com> <439ED00E.7050701@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Eric, Hello list, oh my first, or better primary opinion was to have two mostly identically Machines, that uses ggated and gvinum to have an redundant system where it looks like one Machine to the public side access. But later i have realized that this whis can't run with ufs or ufs2 while it is not really good to have one filesyst= em mounted rw on both machines, so that i think i must have one Writer and two listeners. But you are right, it is also impossible to mount an Filesystem ro while another machine write things to that FS. So the only good concept is to have one writer and another (or two) listeners, there listens over NFS. But this throws my wish completely away to the stars. Only FS that i know that have these functionality is the really young ZFS from Solaris. Or do it give another solution for my whish? I would paint it to remember what my target was: 2 Machines A and B, booth mostly identical hardware and OS (RELENG_6) both machines have one private interface that is cross bind to the other ma= chine for updates on the FS and Monitoring the other..... the public interfaces of both machines should get bound to one public address with CARP and pfsync, so that clients see only one Machine. And last, my wish are the RAID1/10 do the sync of both machines automagically........hope you understand what my target is. Thanks for your help. regards michael 2005/12/13, Eric Anderson <anderson@centtech.com>: > Michael Schuh wrote: > > >Hello, > > > >thanks to Ivan for his suggestions and his experiences. > >I have this mailing first mailed to stable, but i think now this was the > >wrong place. It this the real place, or even better place as stable? > >I hope so. > > > >>From the suggestions from Ivan i have learned, that > >i must think a little bit in other directions. > >First change to following case is: > >I woud have a Machine that do the Writer Job. > >I call this Machine W. > >W binds the shared Disks (per ggated-exports) from A and B > >with his own shared Disk-Device to an RAID1 OR RAID10. > >Incoming Traffic like ftp-uploads, passwdchanges, accountchanges > >must be done on W. The Machines A and B mount the ggate-exported RAID > >on an unique mountpoint read only, so that all software work on an > >that shared RAID. On the other site all Loggings are made through the > >private interfaces to > >W. He is the only one where could write the logfiles to the RAID. > > > >For the rest of functionality look down in the original posting, i > >pasted it after this mailing. > > > >Have anyone any suggestion. Should this work ready? > >Give it another Way to work so? > > > > If I understand correctly, you would like one node to do all the writes, > and the other nodes to be read-only of that same device that node 'w' is > writing to. This would work, in the respect that it should not cause > problems, but it may not work as you expect. The nodes mounting the > device read-only would only be able to see the data that had been > commited to disk on the writer side at the time the read-only side > mounted the filesystem. This means that any changes made after the > read-only side mounted would result in an inconsistent view of the > filesystem, since the read-only side would have the inodes and dirent's > cached, and would not expect them to change. This *could* cause issues, > for instance, if the read-only machine cached an inode entry, then the > inode entry changed, but the read-only side did not know it, so it loads > the data blocks referenced in the old inode, which may not be the > correct data, so you would get a corrupt file. The only way I can think > of to prevent this is to use synchronous writes (metadata and data, so > the 'sync' option on the writer side), *AND* also somehow disable the > buffer cache on the read-only side, so for each access, it looks to the > block device for the newest information, however this would most likely > result in very poor performance. > > You might be able to make something with NFS work, but not sure the how > you would implement that completely. > > Eric > > > > > -- > ------------------------------------------------------------------------ > Eric Anderson Sr. Systems Administrator Centaur Technology > Anything that works is better than anything that doesn't. > ------------------------------------------------------------------------ > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1dbad3150512150355r576b1b0j>