- Basic Application Requirements
- Integration Concepts
- Summary
- Review Questions
- Applied Solutions
Applied Solutions
Scenario: e-commerce Web Site Requirements
Problem
Your company has responded to a request for proposals to build an e-commerce web site for a company that currently has a modest web presence with no interactivity or e-commerce funtionality. Its business requirements indicate that it has allocated a sufficient budget to provide some degree of redundancy and fault tolerance, but not a complete cross-connected matrix of redundant hardware. Identify the basic application requirements and specify the hardware configurations needed to build a basic e-commerce platform for the client.
Solution
Figures 4-2 through 4-6 in this chapter represent a prototypical, e-commerce web site architecture with moderate levels of redundancy and fault tolerance in key locations. I have chosen to make the figures based on a Sun Solaris platform because it has time and again proven to be a reliable and scalable platform. This does not, however, mean that other operating systems can't be used in a similar arrangement of servers.
This basic architecture could easily be used as a baseline architecture for an Internet-based customer care application, a workforce optimization application (such as a time and expense reporting tool), a supply-chain management system, or an e-learning or e-publishing system. Only a few components would need to be added to accommodate these various purposes. Many of the single servers and components could be replaced with multiple servers or network hardware depending on the kinds of transactions being performed and the demands placed on each layer of the architecture.
Solution Details
The firewalls are configured in a failover setup, with one firewall serving as active and the other as standby. Redundant routers could be added to this front-end connection, if desired. Active and standby load balancers could likewise be added, depending on the application's needs and expected traffic levels. Three web servers currently make up the web farm, but another dozen could be added as the site scales for growth.
A firewall is placed between the web servers and the rest of the servers because the web servers are the only machines that need to have publicly routed IP addresses and represent the first point of attack or possible entry. The front-end firewalls would be configured to allow only port 80 (HTTP) and port 443 (HTTPS) traffic. Administrative access to the systems could be provided by means of a VPN tunnel, a dedicated back-end private network connection, or a dial-up ISDN connection. Even with a back-end private network connection, however, firewalls should be added on each side of the private link so that a compromise in the e-commerce site would not compromise internal development servers on the administrative team's network.
The application servers are configured with dual processors and 2 GB of RAM, as this layer is expected to perform the bulk of the work in processing user requests. Connection pooling on the application servers will reduce the impact of high-usage levels experienced by the database. Both the application servers and the web servers have two mirrored 9 GB internal disks.
The database is configured with dual, internal, mirrored 18 GB SCSI disks. The external fiber channel disk array is used for the data partitions, while the internal disks contain the operating system and database software. Depending on the application and transaction needs, the disk array can have more disks added. The disk should be configured as a shared node for high availability clustering. If a fault is detected by the clustering software (Veritas or Sun cluster, for example), the disk array is unmounted by the failed machine and handed over to the second database server.
Optional components that could be added to this architecture include the following:
Dedicated intrusion detection servers (Host-based intrusion detection would be added to these machines after they have been "hardened" by shutting off unused services such as printer daemons, NFS daemons, email daemons, and so on.)
An active/active database solution instead of active/standby. Oracle Parallel Server is an example of this kind of high performance, high availability solution.
syslog log server for firewall syslogs, web logfiles, and application logfiles.
Search server providing dedicated content index and search functionality.
Image server providing dedicated image serving if the site is heavy on graphic images or images of catalog contents.
Mail server for dedicated processing outbound and inbound e-mails.
Additional database servers to host specific tablespaces instead of having all databases on one machine.
logfile stats server to provide dedicated reporting and analysis of web site traffic.
FTP server if application or service requires transfer of documents and data with clients or partners.
Other specialized servers or segregated instances of web, application, or database services.
The core architecture does not really change, but you could develop a few more network connections alongside the web servers, or with the application and database servers. Additionally, a site does not need to necessarily use the Apache web server, Tomcat application server, or Oracle database.
Netscape web server, ATG Dynamo application server, Weblogic application server, DB2, or my SQL databases have all been used in projects I have worked on depending on budget, essential functionality, legacy compatibility, and so on. Restrictions on mixing and matching components have decreased over the last few years, so it is unlikely that you will choose two components and realize while installing one of them that no module or plug-in is available to connect it with another component.