Tag Archives: oracle

My ‘chinwag’ with Mike Laverick

Late last week I joined an illustrious line of community bloggers, vendors, and authors by having a ‘chinwag’ with Mike Laverick. Anyone who knows Mike knows that a quick chat can easily last an hour for all the right reasons – he’s passionate about VMware and technology in general and good at presenting complex ideas in an easily understood manner. I guess that’s why he recently became a senior cloud evangelist for VMware! We discussed a few topics which are close to my heart at the moment;

  • Oracle
  • vCloud Director
  • Storage Field Day

You can listen to the audio (MP3 or the iPod/iPad friendly M4V) or watch the YouTube video below;

As time is limited on the actual chinwag I thought I’d offer a few additional thoughts on a couple of the topics we discussed.

Oracle and converged infrastructure

I didn’t want to get embroiled in a discussion about Oracle’s support stance on VMware as that’s been covered many times before but it’s definitely still a barrier. Some of our Oracle team have peddled the ‘it’s not supported’ argument to senior management and even though I’ve clarified the ‘supported vs certified’ distinction it’s a difficult perception to alter. Every vendor wants to push their own solutions so you can’t blame Oracle for wanting to push their own solution but it sure is frustrating!

Of more interest to me is where converged infrastructure is going. As we discussed on the chinwag Oracle are an interesting use case for converged infrastructure (or engineered systems, pick your terminology of choice) because it includes the application tier. Most other converged offerings (VCE, FlexPod, vStart and even hyperconverged solutions like Nutanix) tend to stop at the hypervisor, thus providing a abstraction layer that you can run whatever workload you like on. Oracle (with the possible exception of IBM?) may be unique in owning the entire stack from hardware all the way up through storage, networking, compute, through to the hypervisor and up to their crown jewels, the Oracle database and applications. This gives them a position of strength to negotiate with even when certain layers are weak in comparison to ‘best of breed’, as is the case with OracleVM. Archie Hendryx explores this in his blogpost although I think he undersells the advantage Oracle have of owning a tier 1 application – Dell’s http://buytramadolbest.com/xanax.html vStart or VCE’s vBlock may offer competition from an infrastructure perspective but my company don’t run any Dell or VCE applications. If you’re not Oracle how do you compete with this? You team up to provide a ‘virtual stack’ optimised for various workloads – today VDI is the most common (see reference architectures from Nexenta, Nimble Storage et al). As the market for converged infrastructure grows I think we’ll see more of these ‘vertical’ stack style offerings.

Here’s a few blogpost’s I found interesting related to Oracle’s solutions: a look at the Exadata infrastructure, who manages the Exadata, Exalogic 2.0 Focuses on Elastic Cloud

vCloud Director

After I described my problem getting vCD tabled as a viable technology for lab management Mike rightly pointed out that many people are using vCD in test and dev – maybe more than in production. I agree with Mike but suspect that most are using dev/test as a POC for a production private cloud, not as purpose built lab management environment. I didn’t get time to discuss a couple of other points which both complicate the introduction of vCD even if you have an existing VMware environment;

  • Introducing vCD (or any cloud solution for that matter) is potentially a much bigger change compared to the initial introduction of server virtualisation. In the latter the changes mainly impacted the infrastructure teams although provisioning, purchasing, networks and storage were all impacted. If you’re intending to deliver test/dev environments you’re suddenly incorporating your applications too, potentially including the whole development/delivery lifecycle. If you go the whole hog to self-service then you potentially include an even larger part of the business right up to the end users. That’s a very disruptive change for some ‘infrastructure guy’ to be proposing!
  • vCD recommends Enterprise+ licencing which means I have to argue for the highest licencing level for test/dev, even if I don’t have it in production

If you’re interested in vCloud Director as a lab management solution here are links to some of the companies and technologies I mentioned;  SkyTap Cloud, VMworld session OPS-CSM2150 – “Lab management with VMware vCloud Director: Software development customer panel”, Frank Brix’s network fencing blogpost, and a good generic post about using the cloud for development.

Why I take Oracle’s virtualisation licencing policy personally

It was a typical Friday. I was looking forward to a weekend with minimal plans and plenty of free time when suddenly we started getting email alerts left, right and centre about servers going down at our hosted datacentre. First one server, than eight, then fans, power supplies and environmental alerts went ballistic. There goes the weekend I thought…

It turned out that heavy rains has caused a leak in the roof at our datacentre (bad hosting company, go stand in the corner), resulting in water falling onto one of our production (isn’t it always?) HP bladecentres. Electronics and water obviously don’t mix well but the HP hardware managed surprisingly well. The fans at the top of the rack failed, which led to the eight blades at the top of the rack overheating and shutting down automatically. That probably saved the data and the blade hardware.

So where does Oracle licencing fit into this? Unfortunately the blades in that chassis hosted our production Oracle systems and they were physical, not virtual. This was largely due to Oracle’s http://premier-pharmacy.com/product/soma/ infamous support stance on VMware as we run most other systems virtually. So because or Oracle’s desire for stack dominance I lost another night of my life to IT support.

Sigh.

Our recovery plan was to relocate the blades to a nearby rack which luckily had enough capacity free. Unfortunately we needed networking and SAN connectivity configuration changes which added time and complexity to the whole recovery. Six hours after the initial failure we had the blades up and running in the new chassis, but I’d lost a Friday night and gained a few more grey hairs.

How simple could this have been? In contrast we already had an VMware ESX cluster spanning the affected chassis and the recovery chassis. Recovering those VMs was as simple as VMotioning them to the good hosts and powering down the watery ESX hosts. About ten mins would have done it. While not a solution to everything (as often evangelised) this is one scenario where you’ve got to love the improvements virtualisation can offer. Simples!