Results 1 to 4 of 4
Thread: NFS Efficiency
Enjoy an ad free experience by logging in. Not a member yet? Register.
The current situation is
/data/ avatars (Exported and mounted remotely) user1 user2 ... snip ... user100000 file-store (Exported and mounted remotely) user1 user2 ... snip ... user100000 images (Exported and mounted remotely) user1 user2 ... snip ... user100000
/data/ (Exported and mounted remotely) avatars user1 user2 ... snip ... user100000 file-store user1 user2 ... snip ... user100000 images user1 user2 ... snip ... user100000
- Join Date
- Oct 2012
- Delhi, India
i think the second will be better instead of exporting three
I would keep the separation of the three exports as each has its specific purpose (judging from the name).
Then, if the situation calls for it, then you can relatively simple offload these three exports to a nfs server each.
Which would also lessen the impact of the downtime of one of those machines to the nfs service as a whole.
(e.g. only avatars are unavailabe. The rest is working.)
Also processing is more specific. On a file-store nfs machine will be only file-store related cronjobs, etc.
About inotify aka csync2 + lsyncd combination:
Possible, but needs
- careful setup, especially with more than two nodes and in an "all can write" mode:
Two nodes change the same file at the same time. Who wins?
- periodic "full syncs", to be sure that really all files are on each machine. Think network issues, one machine getīs rebooted, etc
- monitoring of the syncs
Tbh, with lsyncd I would go so far to build a slave nfs machine, that I can use for a quick service recovery.
Aka: A master syncs to a slave, end of story.You must always face the curtain with a bow.
Thanks. Lots of food for thought here.