Hardware Requirements

Introduction

The Tk20 system uses an n-tier, Java 2 Enterprise Edition architecture, built using a proven, open-source operating system and software components.

It is written in Java, and comprises of three tiers: a web tier, a middle tier, and a database tier. All tiers function independently, and have their own interfaces for communication. They can be physically located in the same server, or have multiple servers allocated to each one, depending upon load and configuration.

Recommended Hardware Configuration

The Tk20 system can be deployed using a single server or have multiple servers allocated to different tiers of the application depending on the load and configuration. The number of servers depends on the estimated number of users and the concurrent load at any given time. Based on our experience working with more than 100 institutions of different sizes and the functionality provided by Tk20 software the following is our recommended hardware requirement matrix:

Total Number of Users	Recommended Servers to be purchased
Less than 500	1
500-3000	2 (2-tier deployment)
3000-10,000	3 (3-tier deployment)
10,000-50,000	4 (3-tier deployment with file server)

2-Tier Deployment

Tk20 uses several software components, mainly Apache/Tomcat on the web tier as http server and Servlets container, JBoss as application server and postgres as a database. Our recommended hardware configuration is to have two separate machines with one machine hosting the web tier and the other machine hosting the middle tier and database.

The recommended 2-tier deployment topology is depicted in the diagram below.

The factors for considering two separate physical servers include performance, vertical scalability, security and redundancy. Separating the more resource-intensive presentation layer from the business and the database layer gives us dedicated resources to the application components in these layers. The web tier server is configured to work independently on I/O intensive tasks like managing user files uploaded using our system, caching for better speeds, session management and features that are found in authentication-based web systems. See the hardware matrix section for scalability of the system based on the load. The components involved in a presentation layer are more prone to regular software component upgrades, so separating the physical server will help maintain it easily without affecting the business and the database layer. The second physical machine is used to host the application server and the database server. Since our machines are identical in this set up, it also serves as redundant hardware for failover.

Additionally, in a multi-tier architecture, access to each tier is restricted to the tier above it, effectively securing the tiers behind the firewall. For example, while clients (users accessing the system through a web) access the web server, they neither have access to the middle tier/database servers nor are they aware of their existence.

N-Tier Architecture

Many elements need to be considered when deciding on the architecture of the application, such as performance, scalability and future development issues. N-tier architecture refers to the architecture of an application that has at least three "logical" layers -- or parts -- that are separate. Each layer interacts with only the layer directly below, and has a specific function that it is responsible for.

Because each layer can be located on physically different servers, they scale out and handle more server load. Also, what each layer does internally is completely hidden to other layers and this makes it possible to change or update one layer without recompiling or modifying other layers.

This is a very powerful feature of n-tier architecture, as additional features or change to a layer can be done without redeploying the whole application.

An n-tier application usually has three tiers, and they are called the presentation tier, the business tier and the data tier. The presentation layer is the layer responsible for displaying the user interface and "driving" that interface using business tier classes and objects. The business tier is the layer responsible for accessing the data tier to retrieve, modify and delete data to and from the data tier and send the results to the presentation tier. The data tier is the database or the source of the data itself.

Deployment Topology

Three-Tier Deployment

Depending upon the total number of concurrent users using the system and the intended functional use of the system, the deployment topology can be changed such that the middle tier and database tier are deployed on the separate machines, resulting in the three-tier deployment topology.

The three-tier deployment topology is depicted in the diagram below.

Three-Tier Deployment with File Server

In addition to the servers hosting the application, an additional server can be purchased to store the files uploaded by system users as part of application usage. A file server can be purchased at any time and can be seamlessly integrated into the existing hardware after the configuration.

A three-tier deployment topology with an additional file server is depicted in the diagram below.

Training Server

Tk20 is a comprehensive system that includes involvement from multiple groups of users including administrators, faculty, students, and additional assessors outside the institution.  Training is a vital piece of the adoption and it is our recommendation that a separate server be purchased that is dedicated to this purpose.  The training server will allow administrators of the system to conduct training sessions as needed with the individual groups on and off campus without impact on your production server or data reports.  In addition to training, this will allow administrators of the system to test functionality, view the system from other users' perspectives, and troubleshoot questions that may arise.

Server Specifications

Tk20 recommends servers with specifications similar to the following:

PowerEdge R410:	Chassis w/up to 4 cabled HDs and Quad-Pack LED Diagnostics (224-6303)
Processor:	Intel Xeon E5504, 2.0Ghz, 4M Cache, Turbo, HT, 800MHz Max Mem (317-1208)
Additional Processor:	Intel Xeon E5504, 2.0Ghz, 4M Cache, Turbo, HT, 800MHz Max Mem (317-1276) (317-1220)
Memory:	8GB (8x1GB), 1066 MHz, Single Ranked UDIMMs for 2 Processor (317-1285)
Primary Hard Drive:	146GB 15K RPM Serial-Attach SCSI 3.5” Cabled Hard Drive (341-9200)
2nd Hard Drive:	146GB 15K RPM Serial-Attach SCSI 3.5” Cabled Hard Drive (341-9200)
Hard Drive Configuration:	Add-in SAS6/iR (SATA/SAS Controller) which supports 2 Hard Drives – Raid 1 (341-9183)
Operating System:	Red Hat Enterprise Linux 5.3, 2S; Fl x 64, 1yr, Auto-Entitle, Lic & Media (421-0921)
Power Supply:	Power Supply, Redundant, 500W (330-4141)
Server Accessories:	Keyboard and Optical Mouse, USB, Black, English (310-8360) (310-9638)
CD-ROM or DVD-ROM Drive:	DVD-ROM, Internal (313-5884) (313-7834)
Bezel:	Bezel  (313-7839)
Documentation Diskette:	Electronic System Documentation, OpenManage DVD Kit (330-4148)
Chassis Configuration:	Sliding Ready Rails With Cable Management Arm (330-4140)
Service:	3Yr Basic HW Warranty Repair with SATA Ext: 5x10 HW-Only, 5x10 NBD Onsite (993-7452) (993-9412) (994-2610) (994-4500) (994-6019) (994-6058) (994-6627)
Installation:	On-Site Installation Declined (900-9997)
Power Cords:	No Additional Power Cord (310-9057)
1st Hard Drive:	HD Multi-Select (341-4158)
Embedded Management:	Baseboard Management Controller (313-7919)