No problem, I'm glad to answer your questions to ensure I'm providing all
relevant info. I do have five wikis, not just one as used in the previous
explanation. Each of the five wikis has its own Apache vhost and
documentroot directory on each of the four servers, making for 20 copies of
MediaWiki. (I'm thinking of moving to a wiki family
<http://www.mediawiki.org/wiki/Manual:Wiki_family> architecture to reduce
that to one copy per server, but that will take a lot of work to refactor
LocalSettings.php into separate files to split out common and wiki-specific
configs that can be require()d, including Jinja templating for use by
SaltStack states to generate the actual configs based on a centralized
dataset in Salt Pillar.)
Each of the four servers has a single NFS mount and each of the 20 wiki
directories has a symlink to its corresponding subdirectory in the NFS
mount. For example, on each server the vhosts DocumentRoots are
/var/www/sites/wiki1 through /var/www/sites/wiki5. The NFS-shared directory
is mounted on each of the web servers as /var/www/images and each wiki
DocumentRoot has a symlink called images to a subdirectory of that, e.g.
/var/www/sites/wiki1/images is a symlink to /var/www/images/wiki1, which
contains the hashed upload contents
<http://www.mediawiki.org/wiki/Manual:$wgHashedUploadDirectory>.
And to directly address your question, even if this were a single wiki,
there is plenty of traffic (multiple accesses per second per server) to
prevent rsync from being viable for synchronization across the four servers
since every page request results in multiple subrequests that get
distributed across all four servers. (I may also have more than four
servers in the future since I'll move to AWS and gain the potential to
easily scale horizontally, possibly even dynamically, using CloudFormation
and Elastic Load Balancing.) Basically all of my web servers need that
simultaneous read-write access to the same content and with appropriate
write-lock semantics such as that provided by NFS.
Again, perhaps there's a better way to architect a resilient set of wikis
that would simplify this design, and I'm open to all suggestions, so far
what I have is the best I've come up with in the time I've managed these
wikis. The current architecture has had its pros and cons but has worked
reasonbly well. I'm just reevaluating things in light of the move to AWS
and taking a step back to see if I can improve the reliability and simplify
the management of the environment.
Justin
On Mon, Oct 27, 2014 at 11:27 PM, Jonathan Aquilina <eagles051387(a)gmail.com>
wrote:
Another question if this is a single wiki why not
again rsync that across
the 4 servers that way when you update one you have them all updated easily
via rsync when a new release of MW comes out.
I think its best I step back on this as I am no wiki expert at all. I can
provide solutions to certain issues in terms of server layout and what not
but that is about it :(
On Tue, Oct 28, 2014 at 7:14 AM, Justin Lloyd <jclbugz(a)gmail.com> wrote:
I think my explanation was not the clearest it
could have been. Let's say
for the moment that I have one wiki. That wiki is served by a load
balancer
in front of a server farm consisting of four
Apache vhosts, one per
physical server, each with its own copy of MediaWiki, LocalSettings.php,
etc. Thus, a request for say
http://wiki.domain.com/wiki/Main_Page (and
thus all of its included images, css, js, etc.) is actually distributed
by
the load balancer across the four vhosts. Each of
the four physical hosts
NFS mounts the same shared directory from the single NFS server so that
all
four Apache vhosts have simultaneous read-write
access to the same
uploaded
multimedia content.
In case that description is missing your point, I'll add that I do indeed
rsync the NFS server's shared directory to another server nightly (I
could
easily shorten that interval), which in turn gets
rsynced to an offsite
server. So the NFS server is a single point of failure, but I do have
both
local and remote copies of the uploaded content.
My desire is for
increased
reliability of that backend fileserver.
Does that answer your question or am I still missing your point? :)
Justin
On Mon, Oct 27, 2014 at 10:41 PM, Jonathan Aquilina <
eagles051387(a)gmail.com>
wrote:
> You are mentioning NFS why not use rsync to replicate to a 2ndary nfs
> server and set it to run lets say every 5 to 10 min or how ever often
you
> want to keep the 2ndary server updated.
>
> On Tue, Oct 28, 2014 at 1:13 AM, Justin Lloyd <jclbugz(a)gmail.com>
wrote:
> Hi all,
>
> Currently I have five wikis with the largest one being about 35k
articles
> (109k pages) and pretty heavily trafficked.
My basic server
architecture
is
> four web servers behind a load balancer and with a single NFS server
that
> > shares out a directory that contains the upload directory content for
> each
> > of the five wikis, e.g. /wiki/wiki1, /wiki/wiki2, etc. (There are
also
MySQL and Memcached servers but they are not relevant
to this
discussion.)
Each web server mounts /wiki in one location, say
/var/www/images and
each
> of the five MediaWiki instances on the server has its images
subdirectory
> > as a symlink to its corresponding subdirectory under the mount, e.g.
> > /var/www/images/wiki2.
> >
> > Obviously the NFS server is a single point of failure but I've yet to
> come
> > up with a good alternative shared-filesystem architecture that
doesn't
>
require an expensive license like SNFS.
>
> Finally, I'm considering moving the whole shebang to AWS but using S3
> directly on the web servers doesn't seem viable in this architecture.
>
> So I'm wondering how others are approaching the design of load
balancing
> (multiple instances of) MediaWiki across
multiple web servers while
> maintaining a single source for each wikis upload directory content.
I'm
> > willing to COMPLETELY reevaluate my wiki server architecture as long
as
it's fast and highly available, so all suggestions
are welcome!
Justin
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
--
Jonathan Aquilina
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
--
Jonathan Aquilina
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l