Hi, I have two servers at two different locations, the requirement is to have two Shared storage servers where users can read/write locally and the data gets synchronized between the two servers. The users will be connected using samba, sometime they will be working at one location and sometimes at other. If it could be LAN then, normal replication can this requirement. Problem at both side is bandwidth, I need fast read/write access to local users and data would later get synchronized with other server. The all I understand about geo replication is, slave needs to be a third machine and if this is the case then I might need 4 machines? I have only two machines and I want something like master-master concept, I tried that but can not succeed. Can anyone help please? Thanks Regards, Zohair Raza -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20121125/e62099b1/attachment.html>
Robert Hajime Lanning
2012-Nov-25 18:50 UTC
[Gluster-users] geo-replicated Master Master cluster
On 11/25/12 08:59, Zohair Raza wrote:> If it could be LAN then, normal replication can this requirement. > Problem at both side is bandwidth, I need fast read/write access to > local users and data would later get synchronized with other server.Unfortunately, Gluster is not going to be a solution for you. It's design goals have local replicas and an off-site, eventually consistent, one-way replica as a backup. The geo-replication is basically a one-way rsync with smart file queuing.> The all I understand about geo replication is, slave needs to be a third > machine and if this is the case then I might need 4 machines? > > I have only two machines and I want something like master-master > concept, I tried that but can not succeed.Multi-master is Hard(tm) with the same issues as healing a split-brain cluster. How do you merge updates to a file from different sources, without full understanding of the file format. Multi-master at the filesystem level usually means synchronous locks and writes, between all masters. What you can do with Gluster is create a replicated volume that spans the sites. Read requests should be satisfied from the local replica brick, while writes will be synchronous to both sites. With quorum set correctly, if the link between sites goes down, then only the primary site will have access to the volume. -- Mr. Flibble King of the Potato People
Understand your point, by the time I also tried with NFS like clustering but didn't help There is master-master geo replication planned in 3.4 http://www.gluster.org/community/documentation/index.php/Planning34 I think it is for the same purpose, has anyone got an idea on it? Regards, Zohair Raza On Mon, Nov 26, 2012 at 2:58 PM, Robert Hajime Lanning <lanning at lanning.cc>wrote:> On 11/25/12 23:26, Zohair Raza wrote: > >> Hi, >> >> Thanks for reply, >> >> Can you please elaborate more on the last line, I understand that read >> will have no issues. I tried implementing a replicated volume but the >> problem is gluster starts uploading the file to node2 while copying for >> example if I have a 500MB file in site1 which is being copied from a LAN >> machine to node1 copies at the speed of my internet link which I want to >> get copied at much faster speed (in MBps) as it is LAN. >> >> Isn't there any way by which I can set synchronization speed or set >> gluster to sync after the file is copied? >> > > All the smarts are in the client. > > If you have a replica count of 2, then when a client is writing, it is > writing to 2 bricks at the same time. There is no such thing as queuing > for later sync. > > What happens if a client at site A is writing to the same file as a client > at site B? If you have a delayed write to a remote site, how do you solve > write conflicts? You would need to completely understand the file format > and it's transactional state, so that the 2 separate writes can be merged > without corrupting the file. > > If there is a conflict, there is no way to notify the process that was > writing, because the write would have already returned as successful, since > it was queued for later execution on the file. > > The only way to solve this, is to have synchronized locks and synchronized > writes. It needs to behave like a local filesystem with 2 processes > writing. > > Geo-replication solves this by saying one site is the master and all > writes happen there. The other site is a replica of the master, period. > This gives you a single source of truth about file state and no conflicts > to mediate. > > For a database with ACID transactions and atomic data structures, you can > design the data and data structures for multi-master replication. You can > state that the latest update of an atomic structure wins, then design your > application around that. For a filesystem, you can't, as you do not have > visibility into the structure of the files. > > The commercial NAS systems that have multi-master capabilities, do it at > the block level (not file) and do it synchronously. > > I currently do not know of a way to implement a multi-master asynchronous > network filesystem, without introducing the possibility of file corruption. > > > -- > Mr. Flibble > King of the Potato People >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20121126/42743e54/attachment.html>
On Sun, Nov 25, 2012 at 08:59:04PM +0400, Zohair Raza wrote:> I have only two machines and I want something like master-master > concept, I tried that but can not succeed.Gluster won't do this for you. You could look at something like 'unison' or 'csync', but they may not scale up to your needs. I use unison to synchronise my laptop with my desktop. It handles split-brain by doing nothing. If a file has been changed on both machines since the last sync then it leaves both sides unchanged (unless you force copying from A->B or B->A)