Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have been looking for some time now to find more information on how to replicate data between servers. What I'm facing is a hardware load balancer to pull from two or more servers. Since NFS would present a single point of failure, I do not want to use it; redundancy, which is the main goal would be compromised here. I could use Rsync, but I need to implement real-time replication so that clients will be able to view their uploads/updates instantly and not be confused. Also, I have GBs of data that Rsync would need to synchronize on a timely basis (very resource intensive.) I have looked at FAM and IMON but this is a very old tutorial and the SGI::FAM is so old that installation is no longer possible (I really don't want to take up the torch either as I'm no perl developer.) I understand FAM provides an API so that apps can use it to monitor file changes, but I am no C developer either! My point being there's got to be someone out there who has done real-time file replication for linux servers in a load balanced environment. Any tips will be well appreciated!
I'm not exactly sure if this is what you are looking for or if you want to have fail over capabilities as well. But for simple file synchroniztion this will work http://www.cis.upenn.edu/~bcpierce/unison/
I did look at unison. I discounted it after it seemed to me that it really isn't for real-time file replication. I will read up on it to see if possibly I can get it to work in the fashion I need it to. In the meantime, do you know of a way to implement it in a real-time (or as close as I can get) fashion?
I have looked at GFS. It is my understanding that GFS is wonderful but expensive (extra hardware to buy.) However, I am not familiar with Redhat's flavor of GFS. Also, this may not represent a high availability solution. Again... let me know if I'm wrong.
I actually posted this link in my original post. It looked like it was just what I was looking for. Since I have a 2.4.x kernel, IMON (the kernel feature has a different name but does the same thing as I recall) gives files the ability to fire an event that FAM listens for. The problem is, of course, that the perl module mentioned that hooks into FAM (via API) does not install due to dependencies that cannot be met now (again, I forgot the details.) I suppose if I were really desperate (or ambitious), I would attempt to write my own. Another issue is the fact that the perl module was not updated for so long (is this a less-than-ideal way to go about this?)
This one is very interesting. Replication was not the end goal but it may work. Allthough, it's not open-source and therefore there may be better non-free alternatives, such as:
However, I just can't believe with Load balancers out there (including LVS ) there is no implementation for doing realtime file synchronization for your web server farm.
Awesome, this looks the most promising so far. It may be tricky to implement with my existing production servers (I will need to scrounge up some boxes to test with.) However, this looks like it could be THE ANSWER I will also post my experience.
Got DRBD working on Debian servers. After all the toil, it dawns on me that the secondary block device cannot be mounted. Instead this system is meant to do a switchover in the case the primary goes down (via heartbeat.) As for the ro on secondary, this is from the drbd website:
Quote:
Do not attempt to mount a drbd in Secondary state.
On 2.6 kernels, we don't allow it. Though (on 2.4 kernels) it is still possible to mount a Secondary device readonly, changes made to the Primary are mirrored to it underneath the filesystem and buffer-cache of the Secondary, so you won't see changes on the Secondary. And changing meta-data underneath a filesystem is a risky habit, since it may confuse your kernel to death. So don't do that.
Symptoms would be loads of Assert (mdev->state == Primary) in syslog.
So it seems, this IS NOT the answer for file synchronization for one or more load balanced servers. Unless, I am mistaken, I'm back to the drawing board {SIGH}
Okay, I found some NON-free software that works very well. Only problem, it's fairly expensive: PeerFS. It does what I hoped drbd would do: that is, the files in a network block device are distributed to all nodes simultaneously and they are all instantly available for reading. The setup was extremely easy. The only downside is the dough (WAY cheaper than hardware based solutions though!) Does anybody know of opensource alternatives?
In case any thread subscribers are interested on how things turned out...well, they didn't really. PeerFS was a nightmare and another solution (that seems to work well) costs anywhere from 2-4 times as much as PeerFS (Constant Replicator.)
I do love rsync! BUT...it's not an alternative for realtime synchronization. I use it currently for my secondary peers that HAVE to be hot spares because I can only feasibly replicate every 2 hours or so (takes like 5-10 minutes just to count my 1.5 million files!) and with websites constantly changing, my clients are gonna get pissed they upload and can't see changes on a secondary load balanced peer for up to 2 hours!
I have been looking for some time now to find more information on how to replicate data between servers. What I'm facing is a hardware load balancer to pull from two or more servers. Since NFS would present a single point of failure, I do not want to use it; redundancy, which is the main goal would be compromised here. I could use Rsync, but I need to implement real-time replication so that clients will be able to view their uploads/updates instantly and not be confused. Also, I have GBs of data that Rsync would need to synchronize on a timely basis (very resource intensive.) I have looked at FAM and IMON but this is a very old tutorial and the SGI::FAM is so old that installation is no longer possible (I really don't want to take up the torch either as I'm no perl developer.) I understand FAM provides an API so that apps can use it to monitor file changes, but I am no C developer either! My point being there's got to be someone out there who has done real-time file replication for linux servers in a load balanced environment. Any tips will be well appreciated!
Now Linux has a function like FAM, maybe more powerful, that is
inotify.
This project's mirrord/fs_mirror tools is a near realtime file system
mirroring application across 2 or more hosts, to mirrors the many
small files from one to another as soon as possible when there is
any modification.
mirrord/fs_mirror makes use of inotify, which is a function
afforded by the recent Linux kernel (from 2.6.12). I think it is a
counterpart of FAM, since Linux FAM has stopped so long.
I started these projects on LFS first, but these tools can also be
applied on other distributions, for instance, I used them also on the
RHEL4 environment.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.