FUNCTIONAL REQUIREMENT
- Web server, Internet access.
- Static Web pages
- Dynamic pages via PHP
- Servlets (Java code on the server)
- Data stored in a database
ROBUSTNESS AND LOADING REQUIREMENT
Requirement for parallel provision of all elements
- To ensure that the system remains operation on any one failure
- To provide extra load handling capability
- To provide a system that can be extended by adding extra parallel units
CHOSEN COMPONENT PARTS
- Apache httpd web server
- PHP
- Tomcat
- JSDK
- MySQL
APPLICATION OVERVIEW
The application has a number of clients who connect in using their browsers, and who log in to the system to go through a series of transactions in a session. In the rare event of a component failing, it is acceptable for their session to be dropped, but they must be able to log back in and continue their work. Around 30% of the SQL requests are Insert / Update / Replaces, but they are very simple enquiries. The remaining 70% or so may be quite complex selects and it's anticipated that the main system load will be in this area and in the PHP and Java that's making those select enquiries.
SCHEME - MANAGEMENT OVERVIEW
All systems to be built the same, with slightly varied configuration files to control their functionality. Three different functional configurations.
a) FRONT END system. Receives all incoming requests (httpd) and passes on the requests to the appropriate MIDDLE TIER system. One front end system running at a time, with fail-over.
b) MIDDLE TIER system. Running httpd (and PHP), Tomcat (and Java) and MySQL as a slave server. Runs requests passed on (through mod_rewrite or mod_proxy) from the front end system. SELECT queries are run on the local slave server on each middle tier system. Queries that change the database are run on the Master database system.
c) MASTER DATABASE SYSTEM. Running the MySQL Master. All inserts and other database changes are made on this one system, and those changes are replicated out to all Slave servers on the middle tier systems. One Master database system running at a time, with failover.
The Front end and Master database system both support all the operations of the middle tier systems, and in a small system (three systems in total) will take an equal proportion of the traffic that's being shared out by httpd on the front end system. As the number of middle tier systems is increased, the middle tier functionality will be handed out with more of a bias until (in a setup with - say - 9 computers) the front end and master database system are providing only that functionality.
Let's number the front end system "1", the middle tier systems "2", "3" and "4", and the master database system "5". Then ....
System 2 will run an extra task that monitors the front end system and if the front end system fails, takes over.
System 4 will run an extra task that monitors the master database system and if that fails, takes over.
Such failovers can be programmed to go "along the line" if necessary. Restoration will be a manual process, but a straightforward one once the reason for the failure has been diagnosed and fixed.
In an extreme situation, it's possible for the whole system's functionality to be being provided by a single machine (extended power failure, running very few computers off a generator perhaps?) and it would be possible to configure a setup with just front end and master database systems. I'm recommending strongly against this for the first configuration tested, since it would not be possible to provide adequate Research and Development testing.
CONSIDERATIONS IN THE DESIGN
How to ensure that a returning session is always passed on to the correct machine.
How to ensure there are not long delays at failover.
Ensuring that data entered on one system is timelessly available on others.
Ensuring data integrity through failures.
Ensuring that the whole system isn't overspec'ed and overcomplex.
Ensuring that the system is easy to operate and maintain.
ELEMENT DETAILS / CONFIGURATION INFORMATION
This would turn into a very long article - subject(s) covered on our courses - further content may be added here in due course
See also
Deploying Apache httpd and Tomcat
Please note that articles in this section of our
web site were current and correct to the best of our ability when published,
but by the nature of our business may go out of date quite quickly. The
quoting of a price, contract term or any other information in this area of
our website is NOT an offer to supply now on those terms - please check
back via
our main web site