Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1999-06-30
2002-09-03
Baderman, Scott (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S047300, C709S241000
Reexamination Certificate
active
06446218
ABSTRACT:
BACKGROUND OF THE INVENTION
List of Related Applications
The following applications are related to the present disclosure and are incorporated by reference herein.
Application entitled “Data Mining Aggregator Architecture with Intelligent Selector (Attorney Docket No. BHUBP001), filed on even date by inventor Roy P. D'Souza; application entitled “Data Mining with Dynamic Events (Attorney Docket No. BHUBP002), filed on even date by inventor Roy P. D'Souza; and application entitled “Data Mining with Decoupled Policy From Business Application (Attorney Docket No. BHUBP003), filed on even date by inventor Roy P. D'Souza.
The present invention relates to an improved computer architecture. More particularly, the present invention relates to techniques for improving the reliability and response time of a scalable computer system of the type employed in e-commerce applications through the Internet.
E-commerce, or electronic commerce through the Internet, places stringent requirements on the planning and implementation of the computer infrastructure that supports the service. As the e-commerce service is in its infancy, it is important for economic reasons to minimize the cost of the computing infrastructure employed to service the few initial users or early adopters. As the use of the service becomes wide-spread among many users, which in the e-commerce age could be in a matter of days or weeks, the initial computing infrastructure must grow correspondingly to offer reliable and fast service to users or risk losing users to competing services.
To facilitate scaling of computing capabilities to meet a potentially explosive growing demand while minimizing upfront costs, many scalable architectures have been proposed. In one approach, the processing load is borne by a single centrally located computer and as the processing load increases, that computer may be upgraded to have a more powerful processor or, in the case with parallel processors, be endowed with additional processors to handle a higher processing load.
However, there are limits to the level of processing power that can be provided by a single machine. This is typically due to limitations in the processing capability of the single processor or in the upper limit on the number of parallel processors that can be provisioned in the computer. Further, limitations in memory access, bus speed, I/O speed and/or the like also tend to place an upper limit on the ultimate processing capability this approach can offer. Even if the ultimate upper limit is not reached, there are economic disincentives to adopting this approach for e-commerce usage due to the fact that marginal increases in computing power for these high-end machines tend to come at great financial cost. For example, a two-fold increase in processing power of such a computer typically requires substantially more than a two-fold increase in cost.
Clustering represents another computer architecture that readily scales to adapt to changing processing loads. In clustering, multiple inexpensive and/or low power computers are clustered together to service the processing load. Typically, the individual computers are interconnected using some type of network connection, such as Ethernet. Each time a machine is connected to the cluster, it publishes its presence to the cluster to signal its ability to share the processing load. Thus, as the processing load increases or decreases, the number of computers in the cluster may be correspondingly increased or decreased to meet the need of the changing processing load.
To facilitate discussion,
FIG. 1
illustrates a prior art computer architecture wherein the computers are clustered in various stages to service the processing needs of the stages. With reference to
FIG. 1
, there is shown a computer system
102
, representing a typical prior art clustered computer system employed to service Internet-based transaction requests. Computer system
102
, which is typically connected to a larger network such as the Internet or a portion thereof, includes a webserver stage
104
, application server stage
106
, and a data repository stage
108
. As can be seen in
FIG. 1
, each stage is implemented by a group or cluster of servers.
In general, a user may access computer system
102
by typing in a URL (Uniform Resource Locator) and obtaining a page from a webserver of webserver stage
104
. In the typical situation, the first few pages returned may include general introductory information as well as an authentication facility to allow the user to sign in. Once the user is properly authenticated (by entering user name and password, for example), a menu of contents and/or applications may then be served up to the user. If the user chooses an application, the request is serviced by one of the application servers in application server stage
106
, which acts in concert with one or more databases in the data repository stage
108
, to respond to the user's request.
Due to the use of clustering technology, however, many other intervening steps occur in between. Beginning with the user's access request
110
(by, for example, typing in the URL at the user's web browser), the request is forwarded to a webserver router
112
, which arbitrates among the webservers
114
(
a
)-
114
(
e
), to decide which of these webserver should service this user's request. As a threshold determination, webserver router
112
may ascertain whether the user had recently accessed the service through a particular webserver of webserver stage
104
. If he did, there is usually data pertaining to this user that is cached at the webserver that last serviced him, and it may be more efficient to continue assigning this user to the webserver that serviced him earlier.
On the other hand, if it is determined that this user has not recently accessed the service or if there is no cached data pertaining to this user on any of the webservers, webserver router
112
may assign the user to one of webservers
114
(
a
)-
114
(
e
). The decision of which webserver to assign is typically made based on the current load levels on the respective webservers, the information pertaining to which is periodically received by webserver router
112
from the webservers through path
116
. Once the user is assigned one of the webservers, subsequent traffic may be directly transmitted between the user's terminal and the assigned webserver without going through the router.
After authentication, if the user subsequently indicates that he wishes to employ a particular application, the webserver assigned to him then accesses another router, which is shown in
FIG. 1
as application server router
118
. Like webserver router
112
, application server
118
picks among application servers
120
(
a
)-
120
(
d
) of application server stage
106
based on the current load levels on the application servers. The information pertaining to the current load levels on the application servers are periodically received by application server router
118
through path
122
as shown. At any rate, one of application servers
120
(
a
)-
120
(
d
) will be assigned to the user to service the user's request. As in the case with the webservers, once the user is assigned one of the application servers, subsequent traffic may be directly transmitted between the web server that services the user and the assigned application server without going through the router that performed the assignment.
If the application employed by the user requires data from data repository stage
108
, the application server may consult yet another router (shown in
FIG. 1
as database router
130
), which may pick the most suitable database server
132
(
a
)-
132
(
c
) for serving up the data. Again, data base router
130
has information pertaining to the level of load on each database server since it periodically receives feedback from the database servers (via path
134
).
Since the processing load at each stage is shared by multiple computers or servers, scalability is achieved. Further, the overall cost
B-Hub, Inc.
Baderman Scott
Beyer Weaver & Thomas LLP
Chu Gabriel
LandOfFree
Techniques for maintaining fault tolerance for software... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Techniques for maintaining fault tolerance for software..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Techniques for maintaining fault tolerance for software... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2838730