Virtualised Oracle Database Appliance POC - #4 WebLogic... we have lift-off!
20 Jul 2013 by Simon Haslam (in Hardware)
To readers who have been following my ODA posts this one will come as a bit of a surprise, given that my last post (#3) was about physical networking: I now have Oracle Traffic Director and a 4 node WebLogic cluster up and running! Note: this work was actually done about 3 weeks ago but I have only just found time to write about it.
What's happening is that my customer's DBAs have been beavering away on
Dom1 (aka "ODA Base") creating a RAC database and importing data, whereas I
am focussed on WebLogic. Therefore once Dom1 was running we've been able
to work in parallel. There are actually some really interesting aspects
about running databases on the virtualised ODA too, but to be honest I
was too excited by this WebLogic stuff to blog in a more
Deploying WebLogic to Your ODA
So, once you have your ODA installed, booting from the virtual image, ODA Base loaded and configured, you're ready to install WebLogic. To do this firstly you need to scp the special "WebLogic for ODA" VM template to both hosts - currently you can choose either 11g (10.3.6) or 12c (12.1.1) - and, if you're going to run Oracle Traffic Director (OTD), the special OTD template (188.8.131.52) too.You also need to scp and extract the clumsily-named "Oracle WebLogic Server Configuration for ODA Utility" (wls_configurator_...tar.gz) onto ODA Base (apparently this should be on Node 0, presumably because it does operations on the second node and assumes that will be Node 1). The next step is to log into ODA Base, set the DISPLAY to point to an X server on your desktop, and run up this WLS Config Utility (as I'll call it). Note you can actually pre-create the configuration elsewhere but you still end up running the utility interactively anyway as far as I could tell (albeit the pre-created configuration file would pre-fill fields).
As Frances Zhao points out on the official WebLogic blog, there aren't many forms to fill in for the WLS Config Utility. As this was a Proof of Concept I had asked for a block of generic DNS names/IP addresses to play with. I wanted to build a 4 node WLS cluster (this is what the customer has at the moment for their main application) so I actually needed 9 IP addresses (3 for OTD, 1 for the application VIP, 1 for the admin server and 4 for managed servers). Following from the Welcome screen (which allows you to load a previously created configuration file) you start entering details of your required environment:
I didn't create any JDBC or JMS configuration from this utility since it doesn't affect the layout of the virtual machines and would be configured with WLST in our environment build anyway. Note however if you choose to set up JMS the logs will be automatically be stored in a database (see below).
I've put both OTD and WLS on the same network (eth1) as we were using the second ODA network (eth2) for storage traffic. I expect you should be able to put the front end of OTD into the different network, for example if you were wanting to provide VLAN segregration (possibly even for running it in the DMZ though I haven't thought that through yet).
You then get the Summary screen, which allows you to optionally save a copy of the configuration, click Install and off it goes!
What Happens Next?
Well, it takes a while (about half an hour for my 4 node cluster) but you get a progress window to watch. We're building a 4 node cluster, this is Oracle, so the first thing to happen is... you've guessed it... it creates a database!
This is a 2 node RAC database is called w0l0sint (WLS internal presumably, I'm not sure about the zeroes - padding perhaps) and is configured as a JDBC store for both JMS and JTA, as well as containing the leasing table for Whole Server Migration - very nice!
The rest of the time is spent actually creating the virtual machines and configuring the domain including load balancer.
The End Result
At the end of this process the utility has created the following virtual machines to run WLS and OTD:
[root@datavm1 ~]# oakcli show vm
NAME MEMORY VCPU STATE REPOSITORY
OTD_veriton1_AdminNode_1 4096 2 ONLINE odarepo2
OTD_veriton1_AdminNode_2 4096 2 ONLINE odarepo1
OTD_veriton1_AdminServer 1024 2 ONLINE odarepo2
WLS_veriton1_AdminServer 2048 2 ONLINE odarepo1
WLS_veriton1_ManagedServer_1 6144 2 ONLINE odarepo2
WLS_veriton1_ManagedServer_2 6144 2 ONLINE odarepo1
WLS_veriton1_ManagedServer_3 6144 2 ONLINE odarepo2
WLS_veriton1_ManagedServer_4 6144 2 ONLINE odarepo1
You can log into the WLS admin console (NB: the default administrator user name is called system NOT weblogic):
Or you can log into OTD and you already have a VIP with origin servers ready to go:
I have done some digging into the WebLogic configuration and like much of what I see: a lean build for the VMs (only 175 RPMs - even less than the 366 I install on my OFM kickstart builds), a separate channel to keep the application traffic away from the administration and cluster communication, JMS and JTA stored in the database to save any need for shared storage, and so on. Currently you are constrained to having only one domain and one cluster, which is very restrictive especially for a test ODA, and inevitably there are one or two other things I'm not so keen on and would customise, but by and large it's a very nicely set up WebLogic system.
Whichever way you look at it, for a non-specialist to be able to build a properly configured, highly available WebLogic cluster (including load balancer), ready to deploy applications, in less than an hour is impressive. Whilst you can script something similar yourself, unless you've done it before, you will have quite a steep learning curve and spend a fair amount of time testing. If you have a moderately sized Enterprise Java application, are considering or already own an ODA for databases but are using less than full capacity, then WebLogic on ODA could be an attractive option.
Stay tuned for further analysis about the remainder of the ODA Proof of Concept.