Massively Scalable System Architecture

This section details the deployment patterns and implementation strategies used to achieve massive scalability. This influences the hardware configuration of computer systems and the virtualization techniques used for efficient resource management. 1.1. Architecture of Massive Scalable Systems – Overview

Distribution techniques allow the system to be scaled by adding additional commodity hardware as needed, taking an incremental approach to scaling rather than requiring to retrofit the hardware platform with more physical resources such as processors, memory or disks etc. Scaling the system is a matter of configuring the deployment environment as necessary rather than rebuilding or re-customizing the applications themselves every time the load requirements or use cases change.

System performance and capacity overhead/degradation as a result of employing these distribution patterns should be predictable enough to be suitable for planning purposes. Documented best practices [6] and deployment strategies take the form of design patterns and implementation recommendations that address scalability issues across a number of architectural areas common to applications deployment (see Figure 1), namely:

 Scaling of logic: Serving very large numbers of concurrent clients within an adequate response time,

 Scaling of data: Integrating many back-end systems without compromising performance and scalability,

 Scaling of events: Managing large numbers of events, e.g. billing, performance metrics, faults without compromise.

F e d e ra tio n T ra n s a c tio n a l C a c h in g J 2 E E C lu s te rin g L o g ic D a ta E v e n ts _{F e d e ra tio n} T ra n s a c tio n a l C a c h in g J 2 E E C lu s te rin g F e d e ra tio n T ra n s a c tio n a l C a c h in g J 2 E E C lu s te rin g L o g ic D a ta E v e n ts

Figure 1. Scalability patterns

The deployment architecture of such systems consists of a number of tiers, each of them responsible for a specific logical function within the overall solution. Each tier is a logical partition of the separation of concerns of the system and is assigned a unique responsibility. The whole system is represented as a stack of tiers, logically separated from one another. Each tier is loosely coupled with the adjacent tier and can be scaled independently of the others.

C u s to m e r R e q u e s ts W e b S e r v e r s S e r v le t C lu s te r s D a ta C lu s te r / C a c h e M e s s a g e B r o k e r C lu s te r D a ta B a s e C lu s te r A p a c h e B E A W L S / J E S B E A W L S / J E S J M S O r a c le C u s to m e r R e q u e s ts W e b S e r v e r s S e r v le t C lu s te r s D a ta C lu s te r / C a c h e M e s s a g e B r o k e r C lu s te r D a ta B a s e C lu s te r A p a c h e B E A W L S / J E S B E A W L S / J E S J M S O r a c le

Figure 2. Typical multi-tired system

An example of such a system is shown in Figure 2. It consists of the following tiers:

x Web Servers – accepts customer HTTP requests and passes them to the servlet

cluster layer,

x Servlet Cluster – responds to HTTP requests from the web servers with the

appropriate customer information from the underlying data cluster,

x Data Cluster – supports a unified view of all customers and their related order

status,

x Message Broker Cluster – provides the infrastructure for managing the

propagation of events from the back-end operational systems to the data cluster,

1.2. Deployment Patterns

Deployment patterns and implementation strategies are designed to promote perfor- mance and scalability in a typical applications integrated environment. A deployment pattern defines a recurring solution to a problem in a particular context. A context is the environment, surroundings, situation, or interrelated conditions within which some- thing exists. A problem is an unsettled question, something that needs to be inves- tigated and solved. A problem can be specified by a set of causes and effects. Typically, the problem is constrained by the context in which it occurs. Finally, the solution refers to the answer to the problem in a context that helps resolve the issues.

Detailed analysis of a massively scalable system leads to the conclusion that most commonly used deployment patterns through every tier of the system depicted in Figure 2 are as follows:

x Application server pooling and clustering,

x Transactional Data Caching,

x Cache routing.

The clustering technique assumes that execution components are replicated and deployed over a larger number of computing elements and there exists a system element that is responsible for load distribution among them. This means that a large number of execution components must be effectively managed in each tier of the system. The Data Caching pattern assures that most of read data are available locally and remote accesses are eliminated through a Cache Routing pattern [6].

1.3. Blade – Architecture

From the already discussed requirements of massively scalable systems it is evident that the most suitable hardware architecture is a cluster of computers that may be used in each tier. Unfortunately, a typical cluster built of independent computers interconnected with a high-speed communication network e.g. gigabit Ethernet, does not support the following:

x Higher server density to reduce the amount of floor and rack space required,

x Increased server utilization by just-in-time provisioning of servers to services

as customer demands fluctuate,

x Shared infrastructure that reduces per-server energy consumption and cooling

requirements while simultaneously increasing availability,

x Reducing administration costs by simplifying the physical plant, and also by

managing a pool of servers as a single resource, with provisioning and re- provisioning simplified through state-of-the-art management software.

Searching for the solution, the largest hardware vendors such as Intel, IBM, HP and SUN have invented the so-called blade architecture. This architecture assumes that a single board computers, called blades, are plugged-in into a rack-mount “intelligent” shelf. The shelf may host typically up to 16 or 24 blades and is equipped with a com- munications subsystem and control logic that may support system redundancy. In our

study we have used the SunFire Blade Platform architecture. The Sun Fire B1600 Intelligent Shelf is depicted in Figure 3.

Figure 3. Sun Fire B1600 Intelligent Shelf

1.4. Virtualization

The most effective technique for complex hardware resource management is their virtualization. The best-known example of this technique application is an operating system which virtualizes computer resources providing standard APIs. Clusters of computers as well as large Symmetric Multi-Processing (SMP) computers require new levels of virtualization for their effective utilization.

In the case of computer clusters, virtual farms can be easily organized. Each virtual farm consists of a collection of computers interconnected with VPNs. This way each farm is isolated from the others and may be handled as an independent cluster.

For SMP computers, the container technology [7] or logical/virtual partitions [8] are offered by leading operating system producers. These technologies support virtual servers, allowing us to partition a single physical server into more than one protected operating environment, with applications running in each virtual server essentially isolated from all others. One of the most scalable virtual server technologies is the Sun Solaris Containers technology implemented by Solaris 10 OS. This system can run up 8192 containers on a single server.

Both virtualization levels introduce a large number of logical elements that must be efficiently configured and managed. This fact places configuration management at the forefront of contemporary massive scalable system requirements.