Introduction Although Exalogic is widely used as a consolidation platform due its concept of data center in-a-box, most customers look after it as a technical solution for improving application throughput. Counting with a powerful 40GB/s bandwidth InfiniBand fabric, applications running on top of Exalogic can benefit from the high throughput, low latency and efficient network layer […]
Having completed the CreateAssembly (Create Assets) re-write of the SimpleExaCli I decided it was time to migrate some of the additional functionality I use and enhancing the outputs to match my requirements. This quick blog entry will describe the currently migrated commands and their new output structure. In accordance with my previous CreateAssembly blog I […]
Following the success of the CreateAssets shell script and it’s subsequent merging into the SimpleExaCli script I decided to extend the features and leverage the full functionality of the 2.0.6.x (Echo) IaaS. As part of the revisit of the code a rewrite in python was performed and the primary reason for this was it allowed […]
This is a very quick observation on a simple performance tuning fix for SOA Suite on Exalogic. The problem SOA Suite appears to grind to a halt when a load is imposed upon it, when running on Exalogic. CPU may or may not be spiked on SOA at this point in time. SOA may become […]
With the latest release of the Exalogic Virtual Environment (126.96.36.199.0) an number of modifications have been implemented and one of these is the introduction of an LVM based Guest Template. LVM was a much requested feature for the base template but it’s introduction means the information provided in my blog entry Exalogic Virtual Tea Break […]
Exalogic Virtual Tea Break Snippets – Creating Assets with the Simplified Exalogic Cli (A SimpleExaCli.sh Tutorial)
In a previous blog entry I described a script for creating assets (Distribution Groups, vServers, etc) but since that initial script I have written and blogged about the Simple Exalogic Cli Script and therefore have decided to write this short tutorial on the “–create-asset” command option. This version is expanded from it’s original release last […]
In previous blogs I have built and documented a number of extensions to the standard Exalogic IaaS Cli that either simplify the Cli usage or provide additional functionality. Following feedback from the various user I have enhanced and amalgamated a number of my scripts into a new single “SimpleExCli.sh”. In addition the SimpleExCli.sh script contains […]
Having worked with the Exalogic Command Line for a while I
decided to wrap some of the common functions in a simplified bash
script. This saves me creating the keys, connecting and
identifying the appropriate Ids. Instead I can simply specify the
Name and the script will do the rest of the work. This initial
version has just a few commands in it but as I add more the blog
entry will expand, as will the script, and document the new
Following on from my Blog entry “Scripted
Template Generation from an existing vServer” I have built a
wrapper script that can be used to execute the Template Generation
script or Clone a specific vServer. This script was not
incorporated into the original script because it must be executed
on a Compute Node with access to the /OVS/Repositories directory
and the Compute Node are a minimal install and hence do not have
all the required software available. As part of the Cloning
process this new script will create an Assets input file that can
be used with the CreateAssets.sh describe in the blog “Scripting
Asset Creation” and optionally execute the result to create
To successfully run the script you will need the following 3
scripts located in the same directory on a machine with the EMOC
cli/api rms installed.
As part of your Exalogic Virtual environment you may want to
build vServer that will be used, going forwards, as a template for
future vServers. Currently the “Exalogic
Elastic Cloud Administrator’s Guide” has an appendix
describing how this can be achieved using the OVMM interface.
Based on internal A-Team work it is now possible to achieve this
directly from a compute nodes command-line without accessing OVMM.
As a result of this I have built the script below that will take
the files associated with a “Stopped” vServer and converts them to
For this templating process to work the script will need to be
executed on a machine with access to the /OVS/Repositories/*
directories and this means running directly on one of the Compute
Nodes (I generally run it on Compute Node 1).
Because of the space and resource limitations of the Compute Node
(minimal OS) we will need to create a and mount a Share from the
internal ZFS to save the working files and ultimately the
Template. To this end the script will take a number of parameters
that will specification of these directories. If these are not
specified the script assumes we have the ZFS /export/common/images
mounted on /u01/common/images.
As can been seen from the Usage section below the script only
mandates the Name of the vServer to be copied but assumes that the
user has stopped the vServer previously. Once the template has
been created, or post copy, the vServer can be restarted.
Following on from my previous blog entry “Modifying
the Base Template” I decided to put together a quick blog to
show how to create a small VirtualBox, guest, that can be used to
execute the ModifyJeOS and hence edit you templates. One of the
main advantages of this is that Templates can be created away from
the Exalogic Environment. For the Guest OS I chose Oracle Linux
6u3 and decided to create it as a basic server because I did not
require a graphical interface but it’s a simple change to create
it with a GUI.
By default running your Exalogic in a Virtual provides you with,
what to Cloud Users, is a single large resource and they can just
create vServers and not care about how they are laid down on the
the underlying infrastructure. All the Cloud Users will know is
that they can create vServers. For example if we have a Quarter
Rack (8 Nodes) and our Cloud User creates 8 vServers those 8
vServers may run on 8 distinct nodes or may all run on the same
Although in many cases we, as Cloud Users, may not be to worried
how the Virtualisation Algorithm decides where to place our
vServers there are cases where it is extremely important that
vServers run on distinct physical compute nodes. For example if we
have a Weblogic Cluster we will want the Servers with in the
cluster to run on distinct physical node to cover for the
situation where one physical node is lost.
To achieve this the Exalogic Virtualised implementation provides
Distribution Groups that define and anti-aliasing policy that the
underlying Virtualisation Algorithm will take into account when
It should be noted that Distribution Groups must be created
before you create vServers because a vServer can only be added to
a Distribution Group at creation time.
Having installed your Exalogic Virtual environment by default you
have a single template which can be used to create your vServers.
Although this template is suitable for creating simple test or
development vServers it is recommended that you look at creating
your own custom vServers that match the environment you wish to
build and deploy. Therefore this Tea Time Snippet will take you
through the simple process of modifying the standard template.
So far in this series we have looked at creating asset within the
EMOC BUI but the Exalogic 2.0.1 installation also provide the Iaas
cli as an alternative to most of the common functionality
available within EMOC. The IaaS cli interface provides access to
the functions that are available to a user logged into the BUI
with the CloudUser Role.
As such not all functionality is available from the command line
interface however having said that the IaaS cli provides all the
functionality required to create the Assets within a specific
Account (Tenure). Because these action are common and repeatable I
decided to wrap the functionality within a simple script that
takes a simple input file and creates the Asset.
Following the Script through will show us the required steps
needed to create the various Assets within an Account and hence I
will work through the various functions within the script below
describing the steps.
You will note from the various steps within the script that it is
designed to pause between actions allowing the proceeding action
to complete. The reason for this is because we could swamp EMOC
with a series of actions and may end up with a situation where we
are trying to action a Volume attached before the creation of the
vServer and Volume have completed.
Before we can create Virtual Servers within Enterprise Manager
Ops Centre (EMOC) we will need to import an appropriate Server
Template that will be used to create the Virtual Server. Server
templates are associated with accounts and hence may be imported
on an account by account basis or for common base templates we can
import them once and make them Public. Once we have configured the
imported template to be Public it will be available to all
accounts and users.
Serve templates can be uploaded to an account in 3 simple steps
although this initial upload will make the template private to an
account its properties can be set to public by simply changing the
“Public” flag within the account Server Template tab. The
following steps are required to import a template and make it
Once we have created our Users and Networks we will want to
enable the Virtual Data Centre (vDC) for access by the Cloud
Users. To facilitate this we will need to create Accounts within
the vDC / Cloud and allocate the users to these accounts. Once a
Cloud User has been allocated to an account they will be able to
access that account and hence create / manage Virtual Servers
within that account / Pool.
To create an Account within a vDC / Pool you will
need to be logged into Enterprise Manager Ops Centre (EMOC) with
the appropriate Role, and this is generally done using you Cloud
Administrator, then simply navigate to the vDC Management
Accordion, vDC, your Cloud and finally Accounts.
By default once a Network has been created within the Enterprise
Manager Ops Centre (EMOC) it can be allocated to vServers during
their creation. At this point an IP Address will be allocated
automatically from the pool of Allocated IPs associated with the
Network and Account combination.
In many customer solutions the vServers will need to be allocated
a specific IP address so that they can be accessed externally at a
know location. To achieve this we must Allocate a number of vIPs
within the range allocated to the Account. This is done on an
Account by Account basis as follows.
In the majority or Real World scenarios we will need to access
the Virtual Servers running within the Exalogic from an external
client network. To facilitate this we will want to leverage the
10Gb Ethernet connection and hence we will need to create 1 or
more EoIB networks that can be accessed by the Virtual Servers.
During the installation of the Exalogic 2.0.1 Virtual environment
we create a single “EoIB-external-mgmt” network that we could, in
theory, use to access the Virtual Servers we create. Although this
is possible, assuming it has enough IP Address, this would be bad
practice because this network is intended solely for management
functionality and access to the Control VMs. Therefore to provide
the Virtual Servers with external Ethernet access we will need to
create additional EoIB interfaces. Each of these will need to be
VLAN tagged to provide network isolation and partitioning.
Creating Cloud Users and Administrators will be one of the first
tasks when setting up a new Exalogic 2.1 environment. We will step
through the simple process of creating users and describe a few
key user types. Initially we will need to login as either the root
user or the exl-admin user.
Before adding users to the Exalogic 2.1 environment they must
exist as either local users on the physical machine running the
Exalogic Control Virtual Server or existing within an appropriate
repository, LDAP etc, used by the machine for authentication. This
is required because Enterprise Manager Ops Centre 12c (EMOC) does
not store any account authorisation information instead this is
left tot he underlying OS. It is assumed within this blog that
this has been done.
At the Oracle Open World 2011 conference, I had presented a session titled “Enterprise-class SOA on Exalogic“
along with Vikas Anand and Manas Deb. Exalogic is part of Oracle’s new
breed of engineered systems, and is geared towards the middleware space.
For those new to the term, an ‘engineered system’ is one where a single
vendor provides everything from hardware, network, OS, middleware,
applications, etc in one appliance. The hardware and software are fully
integrated out of the box and designed for… read more