Commodity Rack Mounted Server Benchmark

Progress Software

Informations

• Publié par: Itto
• Nombre de lectures: 16
• Langue: English

Extrait

Server Commodity Rack Mounted
Server Benchmark
Whitepaper
Table of Contents
Table of Contents.........................................................................................................................................................2
Introduction ..................................................................................................................................................................3
Hardware and Software Summary..............................................................................................................................3
2Continuous Availability Architecture – CA ...............................................................................................................4
Benchmark Details.........................................5
Benchmark Results......................................................................................................................................................5
Combined Replication Time – Linear Scalability...................................................................................................................... 6
Replication Throughput – Flat Response......................................................................................... 7
Connected Server versus Disconnected Workstation.............................................................................................................. 8
Conclusions .................................................................................................................................................................9
About Progress Real Time Division .........................................................................................................................10

2 of 10 InnerEdge Server: Commodity Rack Mounted Server Benchmark
Introduction
The price difference between commodity rack mounted server hardware and large SMP
servers justifies alternate deployment strategies. This white paper explores the use of
rack mounted servers in a load-sharing environment to support complete database
applications. Benchmarks are presented to illustrate the performance of replication
operations in this environment and the relative cost of replication for a range of overall
database change within a database. Replication costs are approximated for operations
during a typical 8-hour work day as a percentage of overall time.
Hardware and Software Summary
For this benchmark the server was not a typical database server with multiple CPUs and
large I/O bandwidth. Instead a desktop-PC class hardware is demonstrated as an
effective DataXtend RE InnerEdge™ or OuterEdge™ Server. The software
configuration ran on Microsoft Windows 2000 Professional with Microsoft SQL Server
2000 personal edition. This software platform is considered appropriate for this
hardware. Limits in the operating system that impact I/O subsystem configuration and
memory utilization were not an issue with the hardware. Limits in the database software
on multi-processor utilization and memory use were also not issues for the configuration.
The database software ran effectively in a single-user multi-threaded mode sufficient for
a simple web application.
The specific hardware target for this benchmark is commodity rack-mounted servers
from vendors like IBM, HP, or Dell. Pictured below is a Dell 350-series server as an
example.


Uniprocessor 1GHz Intel PIII

512MB Ram, 40GB 7200 RPM HD
Figure 1 - Front and Back of Dell 350-Series Server
Today's rack mounted servers are remarkable for the density that can be created within
limited floor space. In a typical rack up to 40 of these individual servers can be
configured to provide a complete infrastructure for a significant organization.
There are three major configurations possible for most applications with this hardware
utilizing a three-tier hardware architecture with tier-1 containing web server, tier-2
application server, and tier-3 database server. For small applications the three tiers can
be collapsed into a single configuration. For security issues the web server may need to
be split off from the application server and database servers providing a second approach.
And to maximize hardware resources all three tiers can be split into individual machines.
3 of 10 InnerEdge Server: Commodity Rack Mounted Server Benchmark To scale up an application, multiple devices can be configured at each layer. For this
benchmark the application was collapsed into a single tier configuration.
2Continuous Availability Architecture – CA
It is important to keep in mind that while the results are for a single server, continuously
available configurations can be built from commodity rack mount servers. With most
application deployment models, the database is restricted to a single layer in the hardware
deployment, and in fact a single device. Applications that deploy with commodity rack-
mounted hardware are often forced to place the database on a large server while the web
server and application server layers can be spread over the appropriate number of
devices. With bi-directional replication technology provided by a Progress®
DataXtend™ RE InnerEdge™ server, the database layer can be deployed on multiple
rack mounted servers and maintained as a synchronized single resource.
This approach differs from typical fail-over or cluster configurations which often require
expensive specialized software and hardware solutions. With InnerEdge server’s
scalability can be achieved at the database level using commodity hardware. Rather than
a complex fail-over scheme, the DataXtend RE Continuous Availability Architecture –
2 2CA – can be used to provide a scalable reliable deployment. In a CA environment
multiple database servers provide the same dataset for one or more applications and any
individual server can be off-line without impacting overall application availability. There
is no fail-over process or management and there is no recovery process or management
aside from repairing hardware.


CA2 Characteristics


Fully Redundant Datasets

Synchronized Updates

No Fail-over Processing

No Fail-back Management

2The DataXtend RE CA approach is a marked contrast to typical fail-over schemes that
require significant operational decisions to be made during a failure event. Even more
significant is the difference after a failure has been resolved and fail-back is necessary.
Fail-back operations are often as significant from a business and management perspective
2as the original failure. With CA , commodity hardware can be configured to provide
very low cost continuous operation environments
In this benchmark we are limiting measurements to replication time and throughput on a
single server. The results of this benchmark apply not only to a single server, but can be
2applied to a rack of DataXtend RE InnerEdge CA Servers. Figure 2 illustrates an
example of this configuration. In a multi-machine configuration each Server would need
to perform one additional replication pass which would result in doubling of overall
4 of 10 InnerEdge Server: Commodity Rack Mounted Server Benchmark replication times regardless of the number of servers. Peak replication rates would
remain consistent.
Benchmark Details
To analyze performance of the hardware with varying workloads and database sizes a
benchmark was prepared with multiple databases that ranged in size from 100,000 to
5,000,000 records in the largest table (for discussion we use the terms 100K, 1M, 2M,
3M, and 5M to represent the databases containing these tables. The 5M row database
exceeded 2GB in total disk space use. Secondary tables were used with smaller number
of rows. All tables were indexed and all were modified as part of the transactions of the
benchmark. For each database size, the benchmark was designed to modify a varying
amount of data, from 1% to 20% randomly throughout the dataset. This change is called
a database delta. For most applications a 1% delta during a single day would satisfy real-
world workloads. For the most demanding applications, a 20% delta in the dataset was
modeled to provide an extreme measurement that might involve major bulk-load or batch
update processing.
An individual delta is not equal to a single update to a record. A record can be updated
any number of times since it was last replicated, yet requires only a single delta to
represent the change. From this perspective the database delta we are working with is net
change to the overall dataset; the number of database operations executed to modify the
database is generally significantly higher. It is common practice in applications to update
records multiple times as part of a single business process. These updates may be part of
one or multiple transactions. Regardless of the number of transactions, or the number of
updates, if a record has been changed since it was last replicated it is only a single delta.
This concept is a critical difference between the DataXtend RE replication mechanism
and log-based replication schemes. In a log-based scheme, each individual update
operation would need to be replicated, dramatically increasing the nu