NFS or rsync for sharing files between FreeBSD servers?

[Amitabh Kant]

On Wed, Sep 7, 2016 at 9:58 PM, Matthew Seaman <matthew at freebsd.org> wrote:

> On 2016/09/07 17:09, Amitabh Kant wrote:
> > We need to share a number of directories between 3 servers running 9.3 .
> > Most of these directories contain php/html/js/images files which do not
> > change frequently.
> >
> > We need to keep the directories in sync on all three servers. Currently,
> we
> > run a rsync command every time there is a change in one of the
> > files/directories. Sometimes it does happen that we forget to run the
> rsync
> > script making one of the servers return old versions.
> >
> > That is where we are planning to introduce a nfs_server on one of the
> > servers, while the other two will be nfs_clients accessing the files
> > through a shared directory. I understand that it would present a single
> > point of failure, but in terms of disk access speed, will it make a huge
> > difference further impacting the web servers running on the nfs_client
> > servers ? The servers are connected to each other over gigabit lines, and
> > the files are themselves not greater than 20-30 kb on an average, with
> some
> > of  the larger image files somewhere around 4-5 MB.
>
> Alternative 1)
>
> Set up your web servers to proxy and cache the content from one machine
> which is assumed to have the definitive copy.  That will work well with
> plain html, js or images -- but you'll have to be a bit cunning about
> getting the PHP files as raw content and then using them asa PHP
> application.  You'll need to play with the cacheing parameters until you
> achieve a good compromise between discovering updates in a timely
> manner, not continually going back to the origin server and keeping
> locally cached copies considered 'fresh' even if the origin server has
> gone away.
>
> Alternative 2)
>
> Use ZFS to make regular snapshots and send any new content to the other
> servers.  This is effectively like using rsync, but even more efficient,
> as ZFS already knows exactly what changed, so you don't have to scan
> bother sender and receiver to work out what changed.
>
> Alternative 3)
>
> Simply run your rsync job out of cron regularly.
>
> Both options 2 and 3 assume you'll set up password-less SSH keys to
> authenticate unattended connections.  This is reasonably safe if a) you
> do it as non-root and ensure the userid you login to has just the
> minimal permissions it needs to be able to fulfil its function and b)
> you take advantage of the features in the authorized_keys file that
> allow you to prescribe where a key can be used to login from, and maybe
> even to use a forced command.
>
>         Cheers,
>
>         Matthew
>
>
Sounds like we should stick to rsync in a cron job, with a restricted user
and ip bindings in ssh keys.

Thanks

Amitabh