pantsblazing:

3-Tier Enterprise Web Architecture

Introduction

This document deals with generic cases of 3-tier Web architectures:

Tier 1: Static content
Tier 2: Application logic
Tier 3: Database

Its aim is to lay out a generic roadmap for a scaleable and cost-effective architecture, with emphasis on generic - every application is different and has different requirements. Your needs and results may vary. And as always, TMTOWTDI (There's More Than One Way To Do It).

Scope

This document covers physical architecture only. It does not cover OS- or application-level tuning.

Notes

All phases only list changes from the previous phase.

In this model, Tiers 1 and 2 are laterally equivalent in that requests to Application Server are not routed through Static Web Servers; clients connect directly to each.

Disclaimer

This information is provided as a courtesy. It may or may not be accurate and it may or may not work for you. Use at your own risk.



top of page | Skip to Phase: 1 · 2 · 3 · 4 · 5 · 6

Both application logic and static content (images, static HTML files, PDFs, etc.) reside on a single computer ("All-in-One Web Server").

The application connects to a database running on a different computer.

Strengths:

• Cheap!

Weaknesses:

• Brittle: every machine is a single point of failure - if anything fails, the entire application is inoperable.
• Limited capacity. Limited ability to quickly add capacity to meet a sudden increase in load.
• The all-in-one Web server approach doesn't maximize available resources because the computer can't be optimized for a specific purpose.

Additional All-in-One Web server clones are added for redundancy at tiers 1 and 2.

The firewall becomes a firewall/load balancer (preferably two of them clustered for automatic failover) to distribute load between and provide transparent failover for the Web servers.

If the application uses memory- or file-based session management, content- or session-aware load balancers are required to ensure that each session is directed to the computer that the session resides on. You may want to look into application servers that are capable of session failover.

One method of distributing cloned content to the Web servers is rdist. Another is outlined here (with source code) in Linux Journal.

Strengths:

• Redundancy and transparent failover (handled by the load balancer) for tiers 1 and 2.
• Tiers 1 and 2 are now quickly scalable - if you have a sudden increase in load, you can easily throw more hardware at the problem.
• Still fairly inexpensive.

Weaknesses:

• The all-in-one Web server approach doesn't maximize available resources because the system can't be optimized for a specific purpose ("not maximizing computational ROI" in suit-speak).
• The database is still a single point of failure.

Application logic and static content are separated and put on different computers. This allows the computers to be specifically optimized for the content they are delivering.

This should be done with a minimum of four computers serving tiers 1 and 2, two for each tier 1 and tier 2, maintaining redundancy for both.

NOTE: If a lot of your traffic is over SSL, consider putting a dedicated hardware SSL device between the firewall/load balancer and the HTTP servers. It plays man-in-the-middle, talking SSL to the clients and unencrypted HTTP to the Web server. SSL uses large amounts of processor time and you can squeeze significantly more capacity out of your Web servers by offloading SSL processing to the dedicated device.

Strengths:

• Tiers 1 and 2 are now independantly scalable, which saves money because:
• Tiers 1 and 2 can now use hardware appropriate to the task, which is more flexible and cost-effective, especially if you're using a commercial application server that requires a lot of resources to run. If you need more capacity at Tier 1, you can use something less expensive like a Lintel box rather than an expensive IBM or Sun server machine - while they may be necessary for Tier 2 to run your application server, they're not necessary at Tier 1.
• You can squeeze all of the capacity you can out of your expensive app server licenses without bogging them down with things that free or much less expensive software can handle easily. Why waste WebLogic licenses serving images and static HTML pages when Apache and others can do it for free and with greater resource control?

Weaknesses:

• The database is still a single point of failure.

If you've reached this point, database load has or will shortly become an issue.

If your application uses user accounts, user information from the database can be replicated to and retrieved from an LDAP server. This reduces load on the database, particularly in the case of authenticating a user, which typically results in the computationally expensive operation of a full table scan of the user table on a character column.

LDAP servers can be replicated for increased capacity and redundancy.

This is a good time to replicate (real-time or batch during low-load times) the production database to an off-line DSS (reporting) database on a separate machine and investigate a data warehousing strategy for data that needs to be kept but doesn't need to be in the live production database. Avoid running reporting queries againt the production database as they typically generate horrendous load.

If you haven't been tuning your database from the beginning, it's a good time to start .

Strengths:

• You've bought yourself more database capacity than you had before for much less (in terms of both money and downtime) than it would cost to upgrade the database machine.

Weaknesses:

• This requires a change in the authentication routines of your application logic.
• The database is still a single point of failure.

A standby database is added for redundancy. The primary database is replicated to the standby which will take over if the primary fails.

Strengths:

• Every tier is now fault-tolerant! The failure of any single machine cannot render the application inoperable, and you can now take the databases down for maintenance (one at a time) while maintaining application availability.
• To the best of my knowledge, the commercial database vendors offer standby database licenses that are a fraction of the cost of the production license (Oracle does, I'm not sure about the rest).

Weaknesses:

• While the system is now fault-tolerant (which is extremely important), the expense hasn't bought any more database capacity. This is really a statement, not a weakness.

The master/slave databases are replaced with bi-directionally replicated and load-balanced databases. This is not trivial.

For Oracle databases, see Quest Software's SharePlex.

This can be simplified somewhat by having bi-directionally replicated but not load balanced purpose-specific databases. For example, the entire schema is kept on both machines, but your application queries product information from one database and user information from another. This allows for some replication latency, or, depending on your schema and application, batch-updates.

Strengths:

• Increased database capacity.

Weaknesses:

• Can be expensive to implement.
• Can be difficult to set up and requires extensive testing.
• Requires another very expensive machine and database licenses (depending on your database software).