Tuesday Feb 26, 2013

Performance Tuning an Exalogic System

source

I tend to get annoyed at my engineering pals for designing performance into automobiles such as the Chevy Corvette, instead of letting the driver feel the satisfaction of increasing performance by improving his or her technique. Many sysadmins feel the same about their craft. But as the story of Paul Bunyan demonstrates, we must adapt or die.

In a previous post I discussed how Exalogic changes the way you handle provisioning. In this post, I'll focus on the way Exalogic changes the way you handle performance tuning. First, the optimizations that are already done for you, then the optimizations you can still perform yourself.

Performance Optimizations Designed Into Exalogic

Because Oracle engineering knows the exact details of the environment in which each component is operating, Oracle has configured Exalogic components to use the internal network, memory, and storage for optimum performance, availability and security. It employs two types of optimizations:

Generic Optimizations (Exabus)

These optimizations will benefit any software running on the Exalogic machine, whether Oracle or 3rd party, in physical or virtual environments. The collection of Exalogic–specific optimizations are referred to as Exabus. The purpose of Exabus is primarily to integrate Infiniband networking seamlessly into all the hardware, software, and firmware distributed throughout the system. Examples include:

  • Changes to the firmware and drivers in the network switches that increase performance by skipping protocol stack conversions
  • Use of Exalogic solid state disk caching to increase the speed and capacity of local (shared) data read and write operations, such as JMS queues and run time metadata.
  • Built in high availability at network and storage levels
  • Native Infiniband integration with any other engineered systems, such as additional Exalogic machines, ZFS storage appliances, or Exadata Database machines.
  • The ability to define Infiniband partitions, which ensure application isolation and security.

Optimizations to Run-Time Components

Oracle has engineered optimizations for Exalogic directly into Oracle WebLogic Server (WLS), Coherence, and Tuxedo. They benefit any application running on those software components, but they can only be activated on the Exalogic platform. They address performance limitations that only become apparent when the software is running on Exalogic's high-density computing nodes and very fast Infiniband switches. Examples include:

  • WebLogic Server session replication uses the SDP layer of IB networking to maximize performance of large scale data operations. This avoids some of the typical TCP/IP network processing overhead.
  • Cluster communication has been redesigned in Coherence to further minimize network latency when processing data sets across caches. Its elastic data feature increases performance by minimizing network and memory use in both RAM and garbage collection processing.
  • Tuxedo has been similarly enhanced to make increasing use of SDP and RDMA protocols in order to optimize the performance of inter–process communications within and between compute nodes.

Tuning You Can Perform on Exalogic

Benchmarks and other tests show that applications that run well on Oracle middleware will run better on Exalogic. The degree to which they run better will be affected by how well optimised they are to take advantage of the Exalogic system, as well how well the Exalogic components are set up to balance resources.

However, if your workloads or configurations change, you may need to tune your Exalogic. Here are some general notes, extracted from the Exalogic: Administration Tasks and Tools white paper.

Tuning the Middleware

At the middleware and application level most of the standard options and techniques are available to you. WebLogic Server, JRockit, Coherence and iAS, etc. operate as they do on traditional platforms.

As for the rest of the Exalogic platform, Oracle's recommendation is: leave it alone.

Tuning The Platform

Exalogic manages itself, so you don't need adjust it unless you are sure that something needs changing. This is a major change in approach, since you are used to spending considerable time tweaking your systems to accommodate the needs of different groups. Knowing exactly when and how much (or how little) to tune an Exalogic system is a big topic, but here are some general guidelines.

  • Because Exalogic has such a high density of compute resources across such a fast network, small configuration changes can have a large impact.
  • Try out your changes in a test environment, first. Make sure its resources, configurations, and workload match those of your production system as closely as possible. Oracle Application Replay is a good tool for assessing the impact of configuration and infrastructure changes on the performance of your applications. Give it a try.
  • Focus on reducing response times for users and applications. If response time is not a problem, you probably don't have an issue to resolve, regardless of internal alerts and indicators you may be noticing.
  • Capture the right performance baselines ahead of time so you can compare the results of your tuning to them.

Tuning the Infrastructure

Storage, Infiniband, and OS are set up during initial configuration, so further tuning is not usually needed. If you need to review the kernel settings, network bonding, and MTU values, or perhaps the NFS settings, use Enterprise Manager. Finding the optimum changes tends to be an iterative process that varies with application workload.

Tuning the Middleware Runtime Environment

Ensure that Exalogic optimizations for WLS Suite are switched on (see MOS note 1373571.1), since they affect replication channels, packet sizes, and the use of the SDP protocol in the Infiniband networks.

Oracle Traffic Director is currently a unique feature of Exalogic, so is not available on other platforms. You can alter traffic routing rules for each application at any time. As workloads change and grow this is likely to be a key tuning task.

Tuning the Applications

At present you can tune business applications just as you would on traditional platforms. One possible side effect of running your business applications on Exalogic is that its enhanced performance may unmask poorly tuned applications or poorly written customizations.

For More Information

For more information, read the Exalogic: Administration Tasks and Tools white paper.

- Rick

Follow me on:
Blog | Facebook | Twitter | YouTube | The Great Peruvian Novel

Tuesday Feb 19, 2013

Provisioning Oracle Exalogic: What's Involved

source

In this interview from 2012, Marshall Choy explains to dear old Justin how Oracle's engineered systems and optimized solutions will impact the job of a sysadmin.

I was just reading a recently published Oracle White Paper that goes into a little more detail...

"While the core middleware or applications administration role is largely the same as for non-Exalogic environments, significantly less work is required to manage storage, OS, and networks. In addition, some administration tasks are simplified."

That sounded interesting, so I kept reading. Here is an excerpt of what it says about provisioning.

Provisioning New Environments

Provisioning is done so frequently in some organizations that it's almost a continuous effort. Exalogic was designed as a multi-tenant environment in which many applications and user communities can operate in secure isolation, but all running on a shared compute infrastructure. As a result, provisioning environments for development, testing or other projects is simply a case of re-configuring these existing shared resources. And it takes hours rather than weeks.

The typical steps involved are:

  1. Storage – using the ZFS BUI
    1. Create NFS v4 shares
    2. Define Access Control List
  2. Compute nodes – via standard OS commands
    1. Decide which nodes are to be used for this project. In the current Exalogic X3-2 machines each node has 16 processing cores and 256 GB RAM. For each node:
      1. Create the root OS user, if it does not already exist.
      2. Add a mount point entry for the shared storage to the /etc/fstab file and issue the mount command to enable access to it from the compute node.
  3. Network – using the Exalogic IB subnet manager
    1. Identify IP addresses for the compute nodes to be used. Add any new virtual IP addresses to be used to ensure middleware high availability.
    2. Define new virtual network interfaces (VNICs) to enable connections to Exalogic from the rest of the data Center.
    3. Associate the pre-set external facing IP addresses to the VNICs.
    4. Define Exalogic Infiniband partitions to create secure groups of compute nodes / processors.

No physical cabling is required as network configuration is defined at the software level. In the event of a major failure, however, you may need to re-image the OS on some or even all compute nodes as a faster alternative to restoring from backup.

This whole process should take no more than an hour, after which a new, fully functioning compute platform is available for the project. It does not require any other data Center resources.

Further details are available in the Exalogic Enterprise Deployment Guide

I'll keep reading it and sharing some nuggets here. See the entire paper.

- Rick

Follow us on:
Blog | Facebook | Twitter | YouTube

(psst! and don't forget to follow the Great Peruvian Novel!)

About

Contributors:
Rick Ramsey
Kemer Thomson
and members of the OTN community

Search

Archives
« February 2013 »
SunMonTueWedThuFriSat
     
1
2
3
4
6
8
9
10
12
13
14
16
17
20
23
24
25
27
28
  
       
Today
Blogs We Like