1

I'm investigating how a Drupal site can be scaled across multiple geographical locations. The primary requirement for this is high availability. The site should be able to run despite some sort of outage on a single location.

The site is a "heavy read, low write" site, meaning that users will never create accounts and edit content. All content is edited by moderators only.

The following two options pop into my mind. I'd be interested in hearing if anyone else have experiences with similar setups - or just general feedback on how viable these options are.

1 WAN-wide cluster

A WAN-wide cluster could be achieved using a database cluster and a storage cluster. However, the immediate implications - as far as I see it - is latency. If we choose to go with a MariaDB/Galera cluster (which is synchronous replication), performance will be very dependent on network latency. For storage, something like GlusterFS (separate storage tier) could solve our needs. However, this again is latency dependent and I'm not so sure replication across an entire WAN is a good idea. The idea of a synchronous cluster (Galera/GlusterFS) is compelling as it removes a few timing issues (replication lag) which you need to take into account otherwise.

The other option for a WAN-wide cluster would be a "regular" master-slave database cluster, where we would have a single master database where all content editing is made. The master database will be located in one location, and the other geographical location(s) will have slave databases only. However, you can never guarantee that some Drupal node not will attempt to write to a database - so all Drupal nodes regardless of location will need to have the possibility to get in touch with the master database to execute write queries. This could be achieved using the AutoSlave module. However, this design makes the other geographical locations dependent on the single master node. If some sort of outage happens here, the master node will no longer be available and all other sites will possibly fail. This defeats the entire idea of high availability. With regards to storage, something simple like lsyncd/csync2 or BitTorrent sync could solve file replication. This would be asynchronous file replication, but I don't think that would be a problem as the site is "heavy read, low write". Only a couple of images a day gets uploaded. Cached JS/CSS and thumbnails would possible be excluded from synchronization, which would put a little more load on all frontends - but that would be a question of testing how much load that would be.

2 Content sharing between locations

I'm not sure how this one could be done, and I'm afraid complexity grows. However, separate - but identical - Drupal installations could be set up at multiple locations. All content editing could be made at one of the sites (master), which would publish content to the other sites. There would be no database or storage dependencies between the sites. However, I'm not sure if this is all that easy to to - especially when content gets complex with multiple fields, media types, images etc.

Improve this question
4
  • Quick question. In one section you identify this as a single-site but later you talk about separate Drupal installations. Is this, in fact, just one site that needs to serve multiple geographic locations or is it multiple sites serving based on their location? Let me know and I'll be happy to help with some guidance. – webkenny Dec 22 '14 at 14:09
  • Sorry I didn't read your whole question since I'm in train and a goddamn kid is crying next to me. If your site has low writes, why not give a try to front end caches. Drupal.org runs on surprisingly cheap hardware compared some of the startups I've seen, so it is possible to handle almost any traffic. Drupal.org uses varnish. Did you try it? – AyeshK Dec 22 '14 at 15:10
  • @webkenny it is a single site, but a requirement for high availability dictates that the site can't rely on a single geographic location. – sbrattla Dec 22 '14 at 16:39
  • @AyeshK we will use Varnish, but 90% of the site is what i would call "long tail content". By that I mean that Varnish cached content will likely expire before any next user can take advantage of that cache. The content changes fairly often (product data), so too long cache times is ruled out. – sbrattla Dec 22 '14 at 16:42
2

I'll address your two points one by one and then discuss suggestions. This is a massive question in scope so I'm doing the best I can with what we've been provided.

WAN-wide cluster

Galera would be your best option if you wish to do an Active/Active setup. It's a tricky setup though and only the best hosts have figured it out (platform.sh comes to mind). Your other option is, by far, the most common. i.e. Master-Slave replication. You may find support for that in the Drupal community is more prevalent and that is worth its weight in database queries. :)

Content sharing between locations

You have some options when it comes to this. If your editors are to be collocated into a single geographical space, then sharing content isn't a problem. If you have a need to allow editors access from many geographical locations, you can do this in a two primary ways:

  • Active/Active using a Galera cluster as you indicated.
  • Active/Passive sites using a content deployment model using the Deploy module, Migrate module, Feeds module, or some combination of those.

Suggestions

  • Start thinking in terms of a single site, not sites. Ultimately, you'll employ a CDN of some kind to deliver content across regions. You had mentioned a concern with freshness of content but there are many ways to achieve the balance. i.e. Look to the Drupal modules Purge, Cache Actions, and Rules.
  • Consider Edge Side Includes which will allow the static serving of some content on a page but assets served from the edge for others.
  • I can't stress the importance of dedicated Memcache servers enough.
  • CDNs, Varnish and a module such as Boost are not mutually exclusive concepts. They can all be employed to keep things fast on the anonymous side. Bear in mind, however, the more layers you add; the greater the possible complexity.

Hope this is helpful.

Improve this answer
8
  • Thanks! Could you elaborate on why Galera (Active/Active) is a tricky setup? – sbrattla Dec 23 '14 at 11:57
  • On more question; do you have experience using the "Active/Passive" sites model? – sbrattla Dec 23 '14 at 13:25
  • 1
    Active/Active historically has been difficult because of the way in which Drupal stores its data. So it's more about the CMF than the technology powering it. As for Active/Passive, I do. I used to head one of the Acquia Support teams and we used Active/Passive on all cloud hosting. – webkenny Dec 23 '14 at 13:54
  • Do you see any limitations with the combo Drupal+Gluster? As far ad I can see, such a cluster should be transparent to Drupal. – sbrattla Dec 23 '14 at 20:23
  • 1
    Gluster is a great pair for the Drupal file system and what Acquia Cloud uses for file replication. So you're perfectly safe in that setup. Galera will work, don't get me wrong, it's just a steep learning curve for those who aren't system admin gurus. If this was all helpful don't forget to mark the answer accepted and good luck scaling your site! – webkenny Dec 24 '14 at 12:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.