Bring the Industrial Revolution to your Oracle Workloads (Learn More by Stopping at Booth 801 at OOW 2015)

When I think of how technology has changed in the data center, I am always reminded of the history of the industrial revolution. Wikipedia begins its definition and description of the industrial revolution in these words: “The Industrial Revolution was the transition to new manufacturing processes in the period from about 1760 to sometime between 1820 and 1840. This transition included going from hand production methods to machines … and the rise of the factory system.”* Wikipedia goes onto say: “The Industrial Revolution marks a major turning point in history; almost every aspect of daily life was influenced in some way”*

The industrial revolution reminds me of a strong metaphor between the productivity benefits of abstracting all attributes of UCS Servers in software (UCS Manager, UCS Central, UCS Director) and the assembly line of the industrial revolution. This historical analogy helps illustrate and underscore how much customers can benefit from a switch to Cisco UCS servers. The historical parallel between these two changes in producing goods (industrial revolution) and the provisioning and deploying servers (UCS Manager/ UCS Central/UCS Director) (producing server images in software) is striking on many levels.

Let’s take a quick look at the Cisco UCS management software and what they mean in the context of a “manufacturing processes” of server deployment and provisioning.

Industrial Revolution / Server “Revolution”

In other words, the UCS Manager manipulates service profiles (software objects which define an entire instance of servers) as whole units. Servers are abstracted in software. The power, repeatability, automation and accuracy of software-based provisioning and deployment are brought to servers. The magic of UCS is really the management software that lives in the network. No part of a UCS managed server is hard-coded with a (UUID, MAC address, WWN, WWPN, BIOS, firmware, etc…). The server becomes stateless and it can change and become a different server with different attributes (UUID, MAC address, WWN, WWPN, BIOS, Firmware etc ) associated with a different service profile. The inconsistent, ad-hoc process of server provisioning becomes timely, automatic and repeatable.

What kind of productivity benefits are we seeing with UCS servers and UCS management? Averaging benefits over a number of UCS customer reiterates this point: provisioning in software is quantum leap forward—an “industrial revolution of compute infrastructure”

Surprisingly, and unlike the industrial revolution/assembly line analogy, the stateless benefits of UCS servers extends beyond increases in server provisioning productivity. For example, in an Oracle RAC deployment, Oracle RAC is a shared-nothing architecture. All nodes see all the storage and node-coherency is maintained with cache-fusion among the different nodes.

An interesting scenario is if an Oracle RAC node fails. Normally, in case of a RAC node failure, it is a long process to bring a new piece of server and bring that node back into the RAC cluster. With UCS it is a simple process to recreate an exact copy of a failed node in minutes, not days. The service profile of the failed node (rack or blade) is instantiated onto a new, spare, node and in minutes an exact (same UUID, MAC address, WWN, WWPN, BIOS, Firmware etc) copy of the failed node is duplicated. Oracle RAC believes that the failed node is now back in the cluster, even though it is a different piece of hardware, because all of its hardware attributes are identical to the failed node. In addition, since an N+1 extra node isn’t needed, Oracle licensing costs for an entire node may be saved! The licensing savings alone can be quite substantial.

Oracle RAC Node 2 Server Fails