Server-farms have created new challenges for managing fast-changing, application data, such as ASP.NET session-state and shopping carts. To allow effective load-balancing, "workload" data needs to be accessible across the farm and must survive server outages. A popular solution to this problem is to move workload data out of the application's local memory, where it is inaccessible to other servers and susceptible to loss, and to store it in a centralized, backend database or object server. While this approach keeps data uniformly accessible, it introduces a bottleneck to performance that impacts response times and limits scalability.
A new software product, called ScaleOut StateServer, eliminates this bottleneck and offloads back-end storage servers by storing workload data directly on the farm using distributed, in-memory storage. To maximize application performance, this product holds workload data close to where it is used and automatically scales as the farm grows. ScaleOut StateServer also employs intelligent data replication to maintain high availability in case a server fails. Applications take full advantage of the farm's power to deliver scalable performance and high availability.
Server Farms Can Create a Storage Bottleneck
The emergence of load-balanced server farms has removed an important barrier to the rapid growth of e-commerce by enabling Web sites to scale capacity and maintain 24/7 reliability. As the popularity of Web and application server farms - and the amount of data they must manage - has steadily grown, a new type of mission-critical but relatively short lived data, called workload data, has emerged that puts increasing pressure on database servers. These data include session-state, shopping carts, SOAP requests, intermediate business logic results, and other fast changing application state information. Workload data typically are updated several times prior to committing changes to the line-of-business (LOB) database, which normally holds inventory, purchase orders, billing records, and other long lived business data. The following table compares traditional LOB data and workload data:
|
Characteristic |
LOB Data |
Workload Data |
|
Volume |
High |
Low |
|
Lifetime/turnover |
Long/slow |
Short/fast |
|
Access queries |
Complex |
Simple |
|
Data preservation |
Critical |
Critical, but reproducible |
|
Access:update ratio |
~4:1 |
~1:1 |
|
Fast access and update |
Less important |
Very important |
Applications traditionally store workload data within the local memory of the running process. This technique, called "in process," works well on a single server but is ineffective on server-farms, where workload data need to be accessible across the farm so that they can be retrieved by any server at all times. This maximizes overall quality of service by allowing the incoming client load to be evenly distributed across the farm and by ensuring that clients are not affected by server failures.
To solve these problems, applications often store workload data in a centralized, back-end database server (DBMS) so that these data can be retrieved from any server and preserved in case of server outages. This approach can be costly (especially if a clustered database server is used), and traffic to and from the data storage tier creates a bottleneck that impacts both performance and scalability. Database caches alone aren�t the answer because they can�t accelerate updates to fast-changing workload data.
Some workload data, such as session-state for ASP.NET applications, also can be stored in an in-memory storage service running on a separate server. Although this solution saves the cost and overhead of employing a DBMS to hold workload data, it also creates a bottleneck to scaling performance. In addition, a stand-alone server cannot be taken down for maintenance, and stored data do not survive a server failure.
ScaleOut StateServer Scales Performance
ScaleOut StateServer targets these problems by hosting workload data directly on the server farm using software-based, distributed, in-memory storage. This product offloads workload data from the back-end database server to increase performance and lower infrastructure costs. It also provides scalability that continues to boost performance as a farm grows. Its patent-pending storage technology allows farm-wide access to all stored data and intelligently replicates data among the servers to maintain high availability during server outages or planned downtime.
Intended for use within a data center, ScaleOut StateServer is installed as a Windows service on all servers within a Web or application server farm, and uses the Web farm�s existing LAN. The software stores, reads, updates, and removes contiguous, opaque, binary data objects based on an identifying 128-bit key. These data objects contain serialized program data, such as ASP.NET session data, business logic objects, and datasets. Stored objects can be uniformly accessed from any server in the farm.
The following diagram shows ScaleOut StateServer installed on a Web farm with three servers:
ScaleOut StateServer scales throughput and maintains fast response times by partitioning and dynamically load-balancing workload data across the servers within a farm. By allowing simultaneous access to multiple data objects stored on different servers, performance and storage capacity scale as the farm grows. When a new server is added to the farm, the product automatically integrates the server into the store and migrates a portion of the data to it, dynamically adjusting the amount of data that are stored and managed by each server in the farm.
ScaleOut StateServer works seamlessly with the server farm's IP load-balancer. Since all servers can access any workload data object, it eliminates the need for the load-balancer to maintain �server affinity� with individual clients. This boosts performance by allowing client requests to be more evenly distributed across the farm. It also avoids the potential loss of service that could result if a client's workload data were stored only within a single server and the server fails. In any case, the load-balancer often cannot effectively maintain server affinity because client IP addresses can change mid-session; ScaleOut StateServer lets the application sidestep this problem.
The use of distributed storage eliminates the bottleneck created by a centralized DBMS and avoids the overheads of DBMS and disk access. Performance data have demonstrated substantial performance gains, including a 6X improvement in response time and linear throughput scaling for e-commerce applications, as shown in the following response time comparison:
More details on this performance analysis can be found at http://www.scaleoutsoftware.com/products/stateServer/technology.html.
Maintaining High Availability with Data Replication and Self-Healing
To avoid the reliability issues associated with a stand-alone, in-memory storage server, ScaleOut StateServer intelligently replicates stored data object across up to two additional servers and ensures that updates are reliably committed, even in the case of server or network failures. The following diagram illustrates the creation of two replica objects (shown in blue) for each data object (shown in red).
When a computer fails or loses network connectivity, ScaleOut StateServer automatically retrieves an object from one of the replicas stored on other servers in the farm. Recovery requires less than ten seconds to detect a failure and resume access to the affected data (versus one or more minutes for a clustered DBMS). After several additional seconds, the distributed store �self-heals� by removing a failed or inaccessible server and then reconstructing data replicas on the remaining servers. This restores full data redundancy in case of a subsequent server failure.
Keeping Management Costs Low with Self-Aggregation
ScaleOut StateServer was designed to be as simple to install and use as possible. After it is installed and activated on the first server in a farm, the service creates a store. When activated on additional servers in the farm, ScaleOut StateServer automatically finds the store (�self-discovers�) and then joins the store (�self-aggregates�) to take on a portion of its workload. Application programs can uniformly access and update any stored data object from all servers in the store.
ScaleOut StateServer�s management console, which runs on any server in the farm, uses a centralized, graphical user interface that shows the status and performance of the distributed store and of its participating servers (called hosts). The management console uses the self-discovery mechanism to identify the store's hosts. It allows each host to be independently configured and controlled, as illustrated in the following screenshot:
An additional command-line program provides all of the capabilities of the management console with individual commands that can be run from a command prompt or incorporated into command-line scripts.
Transparent Support for ASP.NET
ScaleOut StateServer transparently stores ASP.NET session state, providing a seamless environment for ASP.NET applications. Once installed, ScaleOut StateServer automatically saves ASP.NET session-state objects in its distributed store and retrieves them when needed to complete a Web request. As the farm�s IP load-balancer directs Web requests to different servers, ScaleOut StateServer makes all session objects instantly available, regardless of the server that handles the request.
The following table compares ScaleOut StateServer (SOSS) to the use of a DBMS, a stand-alone, in-memory server, and ASP.NET's default, "in-process" method for storing session state:
|
Benefit |
SOSS |
DBMS |
In-memory server |
In-process |
|
Eliminates performance bottleneck |
Yes |
No |
No |
Yes |
|
Eliminates need for server affinity |
Yes |
Yes |
Yes |
No |
|
Eliminates single point of failure |
Yes |
Requires cluster |
No |
No |
|
Allows server maintenance |
Yes |
Requires cluster |
No |
No |
|
Low cost |
Yes |
No |
N/A |
N/A |
Support for .NET Languages and C/C++
.NET and C/C++ applications can directly access ScaleOut StateServer�s distributed store using the application programming interfaces (APIs) supplied with the product. This provides the flexibility needed to incorporate ScaleOut StateServer into existing applications and delivers the highest possible performance. The .NET APIs support all .NET languages, including C#, C++, and Visual Basic. Additional APIs support stand-alone ("unmanaged code") C/C++ applications.
ScaleOut StateServer�s APIs provide simple, straightforward access to the distributed store to:
- store serialized data objects identified by a 128-bit key,
- read previously stored data objects,
- update previously stored data objects, and
- remove data objects from the store.
Summary
Server-farm applications typically store fast-changing workload data, such as ASP.NET session-state, in a centralized, back-end storage server as the only option for ensuring high availability and farm-wide accessibility. A new software product, called ScaleOut StateServer, lowers infrastructure costs, boosts performance, and offloads the back-end storage server by hosting session-state directly on the farm using distributed, in-memory storage. This new storage technique scales performance and storage capacity as the farm grows, while maintaining high availability. This enables server-farm applications to meet growing business demands and deliver fast response times to their clients.
Download ScaleOut StateServer
