Deployments and Architectures

The architectures available for Drupal are those of other LAMP-stack software, and the techniques used
to scale are applicable to Drupal as well. Thus, we’ll concentrate on the Drupal-specific tips and gotchas
for different architectures.

1.Single Server
This is the simplest architecture. The web server and the database run on the same server. The server
may be a shared host or a dedicated host. Although many small Drupal sites run happily on shared
hosting, serious web hosting that expects to scale should take place on a dedicated host.
With single-server architecture, configuration is simple, as everything is still done on one server.
Likewise, communication between the web server and the database is fast, because there is no latency
incurred by moving data over a network. Clearly, it’s advantageous to have a multi-core processor, so the
web server and database don’t need to jockey as much for processor time.

2.Separate Database Server
If the database is your bottleneck, a separate and powerful database server may be what you need. Some
performance will be lost because of the overhead of sending requests through a network, but scalability
will improve.

3. Separate Database Server and a Web Server Cluster
Multiple web servers provide failover and can handle more traffic. The minimum number of computers
needed for a cluster is two web servers. Additionally, you need a way to switch traffic between the
machines. Should one of the machines stop responding, the rest of the cluster should be able to handle
the load.

4. Load Balancing
Load balancers distribute web traffic among web servers. There are other kinds of load balancers for
distributing other resources, such as hard disks and databases, but here, I’m just talking about
distributing HTTP requests. In the case of multiple web servers, load balancers allow web services to
continue in the face of one web server’s downtime or maintenance.
There are two broad categories of load balancers. Software load balancers are cheaper or even free
but tend to have more ongoing maintenance and administrative costs than hardware load balancers.
Linux Virtual Server (www.linuxvirtualserver.org/) is one of the most popular Linux load balancers.
Hardware load balancers are expensive, since they contain more advanced server switching algorithms,
and tend to be more reliable than software-based solutions.
In addition to load balancing, multiple web servers introduce several complications, primarily file
uploading and keeping the code base consistent across servers.

5.File Uploads and Synchronization
When Drupal is run on a single web server, uploaded files are typically stored in Drupal’s files
directory. The location is configurable at Configuration -> File system. With multiple web servers, the
following scenario must be avoided:
1. A user uploads a file on web server A; the database is updated to reflect this.
2. A user views a page on web server B that references the new file. File not found!
Clearly, the answer is to make the file appear on web server B also. There are several approaches.

1)Using a Shared, Mounted File System
Rather than synchronize multiple web servers, you can deploy a shared, mounted file system, which
stores files in a single location on a file server. The web servers can then mount the file server using a
protocol like GFS, AFS, or NFS. The advantages of this approach are that cheap additional web servers
can be easily added, and resources can be concentrated in a heavy-duty file server with a redundant
storage system like RAID 5. The main disadvantage to this system is that there is a single point of failure;
if your server or file system mounts go down, the site is affected unless you also create a cluster of
file servers.
If there are many large media files to be served, it may be best to serve these from a separate server
using a lightweight web server, such as Nginx, to avoid having a lot of long-running processes on your
web servers contending with requests handled by Drupal. An easy way to do this is to use a rewrite rule
on your web server to redirect all incoming requests for a certain file type to the static server. Here’s an
example rewrite rule for Apache that rewrites all requests for JPEG files:

RewriteCond %{REQUEST_URI} ^/(.*\.jpg)$ [NC]
RewriteRule .* <a href="http://static.example.com/%1">http://static.example.com/%1</a> [R]

The disadvantage of this approach is that the web servers are still performing the extra work of
redirecting traffic to the file server. An improved solution is to rewrite all file URLs within Drupal, so the
web servers are no longer involved in static file requests.

2). Beyond a Single File System
If the amount of storage is going to exceed a single file system, chances are you’ll be doing some custom
coding to implement storage abstraction. One option would be to use an outsourced storage system like
Amazon’s S3 service.

6.Multiple Database Servers
Multiple database servers introduce additional complexity, because the data being inserted and updated
must be replicated or partitioned across servers.
1).Database Replication
In MySQL database replication, a single master database receives all writes. These writes are then
replicated to one or more slaves. Reads can be done on any master or slave. Slaves can also be masters in
a multitiered architecture.
2). Database Partitioning
Since Drupal can handle multiple database connections, another strategy for scaling your database
architecture is to put some tables in one database on one machine, and other tables in a different
database on another machine. For example, moving all cache tables to a separate database on a separate
machine and aliasing all queries on these tables using Drupal’s table prefixing mechanism can help your
site scale.