R&D@whizz

   WhizzBee Family 2.0
     Overview
     Features
     Cluster architecture
     Products
     · Web Server
     · Site Accelerator
     · Proxy Server
     · Proxy-Accelerator
     Deployment
     Case studies
     Sys. requirements
     FAQ
     Performance
     Industrial ratings

   Technology

   Documents

   Downloads

   Purchase

   Support

   Contact Us

Deploying WhizzBee
Case Studies

Three case studies are given below to illustrate how WhizzBee can be deployed in real life situations.

• A basic load-balancing server cluster
• A high-availability server cluster
• A deluxe server cluster

For the definitions of the terms like dispatcher, management console, etc., please refer to the WhizzBee cluster architecture page.

Notes:

• the cases shown below are applicable to all four products in the WhizzBee Family 2.0
• "CSP" stands for "Cluster Server Package"
• "AP" stands for "Administration Package

Case I - A basic load-balancing server cluster

Suppose you have a few server nodes and would like to evenly distribute web requests to them, while maintaining a single-system-image to clients, i.e. clients can use a single hostname to access the cluster service offered by the server nodes. A typical configuration is shown below.

Machine	Linux/kernel	RPM to be installed
Dispatcher AND Management console	RedHat 7.1 UP	CSP RH71-UP AP RH71-UP
Server node 1	RedHat 7.2 SMP	CSP RH72-SMP
Server node 2	RedHat 7.1 SMP	CSP RH71-SMP

Notes:

• Although this is a minimal configuration of a WhizzBee cluster, the cluster also enjoys the performance gain brought by the EC-Cache Engine.
• The cluster service will be interrupted when the dispatcher fails, as a backup dispatcher is not in place.
• The dispatcher also acts as the management console so as to better-utilize all computing resources.
• If a cluster node also acts as the management console, administrators might not be able to manage the cluster when that particular node fails. This is basically a trade-off between cost-effectiveness and manageability.
  

Case II - A high-availability server cluster

Suppose you are going to build a cluster with emphasis on high-availability. Your goal is to remove all single points of failure in the cluster, i.e. failure of a single component would not bring down the cluster service. A typical configuration is shown below.

Machine	Linux/kernel	RPM to be installed
Dispatcher	RedHat 7.1 UP	CSP RH71-UP
Backup dispatcher AND Management console	RedHat 7.2 UP	CSP RH72-UP AP RH72-UP
Server node 1	RedHat 7.2 SMP	CSP RH72-SMP
Server node 2	RedHat 7.1 UP	CSP RH71-UP

Notes:

• The backup dispatcher also acts as the management console so as to better utilize computing resources.
• If a dedicated machine cannot be allocated for running as a management console, the backup dispatcher is usually a good candidate for taking up this role as it is mostly idle, except the case when the primary dispatcher fails.
  

Case III - A deluxe server cluster

Here is a typical configuration of a powerful WhizzBee server cluster. It enjoys the unparalleled performance and scalability offered by the EC-Cache Engine, while maintaining high availability as all single points of failure are removed. Furthermore, a dedicated machine is chosen to run as the management console, thus enabling cluster adminstration even when some cluster components fail.

Machine	Linux/kernel	RPM to be installed
Dispatcher	RedHat 7.1 UP	CSP RH71-UP
Backup dispatcher	RedHat 7.2 UP	CSP RH72-UP
Management console	RedHat 7.2 UP	AP RH72-UP
Server node 1	RedHat 7.2 SMP	CSP RH72-SMP
Server node ...	...	...
Server node ...	...	...
Server node N	RedHat 7.1 SMP	CSP RH71-SMP

Product Brochure [PDF]

Download WhizzBee

Documents

FAQ

Purchase