The emerging
Database Area Network (DAN) technology promises a solution to these problems.
The DAN Solution
The DAN concept
has parallels in current large 4-tiered system architectures. Figure 1
illustrates how easily computing resources can be added at the Web server and
application server levels. Large enterprises can add and remove application
servers on a just-in-time basis, always ensuring that there are appropriate
computing resources to match the load of their end-user community.
Figure 1: A typical 4-tiered server architecture.
In addition,
the advent of Storage Area Networks (SAN) technology has made it easy to move
disk storage from server to server, allowing the IT staff to dynamically
relocate disk storage as needs change. While SAN has been highly successful
for storage relocation, the database layer remains a serious system resource
bottleneck.
With the
exception of complex parallel architectures such as Oracle's Real Application
Clusters, database management systems can generally run on only one server at
a time, and databases must be moved between servers manually. This limitation
has led to a situation in which huge amounts of computer resources are wasted
because of the difficulty of balancing server load at the database level.
To resolve this
issue, research labs are exploring the concept of the Database Area Network,
dubbed DAN. In the DAN architecture, a database switch is used with the
underlying SAN to allow databases to move from server to server without
affecting their availability.
The DAN
technology promises the following benefits:
Let's take a look
at how a DAN achieves these benefits.
Inside the DAN Architecture
The DAN
architecture achieves its flexibility by "virtualizing" the Oracle layer
(refer to Figure 2). A high-speed database switch (dbSwitch™) is placed
between the application layer and the database layer. This switch enables
databases to be transparently relocated onto new servers without the need to
modify applications connections to the database. The database servers, in
turn, are connected to a shared storage such as SAN, such that database files
can be quickly remapped onto a different server.
Using IP
address masks enables virtualization of database addresses. To the database
clients, each database is identified by a unique virtual IP address (VIP).
These VIPs are not defined on any specific machine on the network, and are
routable by the dbSwitch™ using Network Address Translation (NAT). This allows
the DAN to move Oracle instances without affecting the application server
layer.
Figure 2: The DAN architecture.
Traditionally,
load balancing of database servers has been complex and problematic. Many
companies waste millions of dollars each year by over-allocating database
server resources. Worse yet, because they lack knowledge of and visibility
into database resource utilization requirements and patterns, many enterprises
also under-allocate server resources, forcing end users to endure unacceptable
response times until the DBA can manually relocate the database to a larger
server.
To address this
inefficient use of database server resources, researchers are exploring DAN
techniques to allow for the dynamic relocation of database instances, to
optimally match server processing capacity to database resource requirements.
Dynamic
Management of Oracle Server Resources
One exciting
feature of a database area network is the promise of using intelligent
algorithms to establish database usage patterns over time. By constantly
polling the resource consumption metrics of databases, saving this history,
and analyzing it, a DAN will be able to anticipate future problems and
bottlenecks and take proactive actions to prevent a slow down.
The management
console can advise the Oracle DBA of how best to arrange database instances on
the servers, and further assist the DBA to perform database relocation.
It is important
to note that the DAN technology is a Decision Support System (DSS) because it
provides the Oracle DBA with both visibility into database resource usage
(including current and historical charts) as well as recommendations for
changes, deferring to the DBA for the final resolution.
The management
console allows servers and databases to be easily added to and removed from
the DAN. The combination of resource optimization and instance relocation
allows the DAN to drive database servers with just the right level of
utilization. This enables large enterprises to consolidate servers and realize
dramatic savings in hardware, software licenses, and administration costs.
All savvy
database professionals know that database servers develop well-known stress
"signatures." These signatures develop because of the periodic nature of the
application (e.g., a billing application running on fixed billing cycles) or
end-user processing (e.g. , eCommerce shopping picking up before holidays),
and can be seen when server stress is plotted by the hour or the day, as
shown, for example, in Figure 3. The DAN resource optimization algorithms use
statistical techniques to identify and take advantage of these historical
usage patterns, and can thus recommend the best "mix" of instances on database
servers.
Figure 4: A server utilization signature.
As this
technology matures, DANs will evolve to use historical metrics on CPU and RAM
usage in order to predict when a database may experience stress, and
proactively relocate the database to a more available server, just in time to
accommodate the increased needs.
Let's take a
closer look at how DAN technology accomplishes database relocation between
servers.
Database Relocation in the DAN
The internal
mechanism for relocation may be quite complex, but the idea is simple. We'll
start with a simple example using SAN. In a SAN environment, relocation of a
database instance involves the following steps:
1. Shut down
the database.
2. Un-mount the
SAN data file systems from the source server, and then mount them on the
target server.
3. Re-start the
database on the new server.
4. Use the
dbSwitch™ routing mechanism to redirect transactions accessing the database
(VIP) to the new server.
A typical time
for such relocation is 10 — 20 seconds. Using products such as Oracle's
Transparent Application Failover (TAF) may allow instance relocation to be
performed such that the move to another server is transparent to the database
clients and application end users.
Conclusion
The Oracle
database load balancing enabled by DAN technology has important ramifications
for the IT manager. With millions of dollars spent in hardware, the IT
manager's job is to maximize the utilization of expensive server resources,
while maintaining acceptable response time for the end users. Using a DAN to
make intelligent database relocation decisions based on resource usage history
can allow IT management to consolidate servers, saving millions of dollars
each year in hardware costs and software licensing fees.
Any DBA with a
SAN can move databases from server to server by running database and storage
commands, with a few minutes of system downtime. When DAN technology is added,
relocation can be done by pressing a button, and it can be completed in
seconds using intelligent agents on the database servers, without losing
transactions or breaking applications or end user sessions.
Of course, DAN
technology is still in its nascent stage, and a few brave companies are
exploring this new technology. It will be interesting to see how this exciting
new technology evolves, and how quickly large data centers adopt the DAN
technology and leverage it to achieve database server consolidation, resource
optimization and high availability.
