There's no doubt that "the cloud" is coming, even in the relatively conservative world of mission-critical Oracle platforms.
At the end of 2012 I took a trial of what was then "Java (or WebLogic) as a Service" (now known as "SaaS Extension"). Back then I wasn't hugely impressed - yes, I could deploy a simple web app, but the WebLogic environment was very heavily constrained and almost entirely hidden from the administrator - no WebLogic console, no WLST, minimal logs. As a result as soon as I tried to deploy something non-trivial, in this case Apache Roller (the software running this blog), I ran into all sorts of class white-list issues and with little debug information so I quickly gave up in despair!
Anyway here we are, over 2 years later, and Oracle's latest "Java Cloud Service" (JCS) is looking far more promising, so here are my initial impressions of what I've seen and read. First things first: JCS comes in 3 variants:
- Java Cloud Service - SaaS Extension: essentially this is product I tried previously which is now targetted at extending Oracle's SaaS applications (including cloud-based Oracle Fusion Applications), presumably with relatively simple ADF apps.
- Java Cloud Service - Virtual Image: this is a single instance WebLogic VM intended for development use and simple testing.
- Java Cloud Service: the "full" version (Oracle doesn't seem to have a distinct name to differentiate it) which can be clustered and is designed for production workloads.
For this article I'm only going to focus on the last of these options, i.e. fully clustered WebLogic with root level access to the VMs but automated provisioning and management provided by Oracle!
Pricing
Before we get into too much technical detail, let's get an idea of pricing for a single, production-grade environment. To keep it simple I'm going to make some assumptions:
- I need WebLogic Suite for all its various benefits, as well as the option to run SOA Suite, etc.
- I'm only considering a 2 node cluster of 2 x 2 vCPU (or 2 x 4 vCPU) running in a single data centre.
- The cluster is of static specification and running 24/7 for a year.
- I need a load balancer to front my cluster and for SSL termination.
Oracle has come up with a term called the Oracle (OCPU) for billing purposes. 1 OCPU equates to the "CPU capacity of an Intel Xeon E5-2600 ... processor core with hyper threading enabled. Each OCPU corresponds to two hardware execution threads, known as vCPUs." Elsewhere (I can't find it now) I've seen it called a "2012 model 3.0 GHz Xeon core", which would be an E5-26xx (v1) processor, though, like Amazon EC2, I suspect there will be some variability - if you're lucky you might "land" on a new E5-26xx v3-based server. Very sensibly Oracle are allocating those vCPUs from the same cores (see below) - modern hyper-threading gives you a performance boost but it's a long way from double the single core performance, and having vCPUs on hyper-threads on different, fully populated, cores would be very bad for performance.
The virtual machines, aka instances, come in what Oracle called "shapes". A shape is a very similar concept to Amazon's EC2 instance type and describes fixed vCPU/memory permutations. There's a full table of VM shapes here but, for this article, we're interested in the following:
- OC3: 2 vCPU, 7.5 GB => 1 OCPU (general purpose)
- OC1M: 2 vCPU, 15 GB => 1 OCPU (high memory)
- OC2M: 4 vCPU, 30 GB => 2 OCPU (high memory)
At time of writing, a JCS WebLogic Suite high memory instance is $2900 per OCPU per month (there's also a more flexible hourly rate but that's more expensive). Note the difference between the normal and the high memory shape is only $100 per month (<4%). In the 2vCPU example we can see that it increases the virtual memory from 7.5GB per core to 15GB per core - when you think that we will need to leave a few GB for the OS that probably means a 7.5 GB general purpose VM should be avoided for WebLogic instances.
Now, for my cluster I'll need:
- two instances for WebLogic: depending on whether I want 2 or 4 vCPU nodes (see later) I'm going to need either 2 x OC1M or 2 x OC2M VMs, giving a total of 2 or 4 OCPUs (high memory)
- one instance for Traffic Director, say 1 x OC3, which is 1 OCPU (general purpose)
Let's say we go for the smallest configuration of two 2 vCPU version for WebLogic (and ignore Traffic Director for now): that's 2*2900=$5800 per month or $69,600 per year (list price). To put that figure roughly into perspective, a 1 year term licence for WebLogic Suite is $9,000 per Oracle Processor (4 vCPU) plus 22% of perpetual price for Updates & Support, giving an annual amount of $18,900 per year (list price). Of course on top of that you need to add the cost of Oracle Linux support, a load balancer, servers, running your own data centre, staff costs, and so on. JCS also comes with Oracle's Developer Cloud Service (SCM, CI, wiki etc) so like-for-like comparisons will need far more detailed analysis.
Returning to the overall cost for running our example environment on JCS...
I'm not entirely sure what WebLogic edition I need to run OTD so am going to assume the same as the origin server WebLogic type for now. This gives, if my calculations are correct, a JCS list price of:
- two 2 vCPU configuration: 2*2900+1*2800 => $103,200 per year
- two 4 vCPU configuration: 4*2900+1*2800 => $172,800 per year
You will see why I'm considering both versions shortly...
WebLogic Domain Topology
Now let's look at what WebLogic on JCS looks like. Here's a diagram from a recent Oracle presentation:
As you can see there is one managed server per VM which I actually rather like as it's cleaner for performance monitoring and tuning purposes. However it does adopt the model of having the Admin Server on the same VM as the first managed server. I have spoken and written previously as to why I prefer to have the admin server separately, primarily when running modern Oracle Fusion Middleware stacks like SOA Suite. This is why I've been "hedging my bets" earlier about whether to have 2 or 4 vCPU VMs - if you had a 2 vCPU VM (which is only really about 1.25 of a processor core) with both a SOA Admin Server and Managed Server, my concern would be that the Fusion Middleware Control could impact the service level provided by the SOA managed server.
A second observation, other than the OTD admin server sharing the same VM as the OTD processing node itself (which I can live with as it's very lightweight), is that there's no passive OTD node. Instead, if the hardware that OTD is running on fails, the VM will be restarted elsewhere. This will provide a highly available solution, but the fail-over time for a VM will be probably of the order of a minute or so (depending on the failure type and detection mechanism) whereas if you run OTD in an active-passive pair it will fail over very quickly indeed (of the order of seconds). On the other hand Oracle is maybe thinking that most customers wouldn't want to spend an extra OCPU per month for this extra responsiveness to handle what should be a very rare event.
Finally, all servers seem to be in the same network zone - it will be interesting to see what's between the outside interface of OTD and the internet at large. Other than that it's much as you'd expect.
Provisioning
JCS allows you to choose from the full range of WebLogic editions:
- WebLogic Suite
- WebLogic Server Enterprise Edition
- WebLogic Server Standard Edition
For these products it offers you the most commonly required versions:
- 12c: 12.1.3
- 11g: 10.3.6 (i.e. for 11.1.1.7 Fusion Middleware)
In addition you can also add on a Coherence cluster, which runs in its own VMs (i.e. will cost more OCPUs) but is fully integrated with the JCS domain.
Provisioning is a very straight-forward business: you specify your WebLogic edition/version, cluster size, node VM shape, whether you want a load balancer (and its VM shape), whether you want a Coherence cluster (size and VM shape), database service (mandatory but provisioned separately) and which persistent storage to use (also provisioned separately and similar to Amazon EBS I think but perhaps also offering shared storage). All the WebLogic domains come with EM Fusion Middleware Control and JRF/ADF pre-installed (i.e. Fusion Middleware Infrastructure in 12c terminology).
Management and Patching
Patching is where JCS really comes into its own! Here's a relatively old screenshot of JCS Manager's patching and rollback page:
Pre-tested and automated patch application is going to be a big benefit to WebLogic administrators. For me the key features are:
- Automated backup - scheduled and ad-hoc.
- Restore can be synchronised with the database to get point in time recovery across both tiers.
- You can chose which patch sets to apply (from a list - no more hunting around MOS!) and when.
- Patches are applied in rolling manner, with automated rollback if required.
Coordinating this kind of thing manually is not easy - it seems most people patch as little as possible and, when they do so, they arrange for complete outages. Backup it often left to a nightly batch job, irrespective of what the middle tier is doing. Therefore "push button" backup and patching like this is very attractive and I think will help improve platform service levels.
Finally JCS offers the ability to scale up and scale down clusters. Whilst technically this is just as feasible with WebLogic run on-premise I have never seen that happen, in my experience of mid-sized organisations, primarily because it would require additional licences to be bought. With JCS you are paying for the licences by the hour/month in the overall price so that barrier is removed.
No comments:
Post a Comment