Oracle ‘Soft Partitioning’ and vSphere DRS Clusters

Those of you who have considered or are currently running Oracle workloads on VMware vSphere have probably come across the term ‘Soft Partitioning’ at some stage of your investigation. While the concept of Soft Partitioning has been around for a few years now, there still appears to be some confusion about what it actually means and how it applies to vSphere clusters. In this post I will attempt to explain in simple terms what Soft Partitioning is, what it isn’t and how it affects your vSphere Cluster design. Note that this is my current understanding of Oracle licensing on vSphere and I would more than welcome any official documentation from an Oracle representative if anything I state here is incorrect. Unfortunately, Oracle has so far been fairly silent on this topic, leading to a certain amount of confusion among their customers.

What is ‘Soft Partitioning’

In the Oracle Partitioning Document at http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf, you will find ‘Soft Partitioning’ defined as follows:

Soft partitioning segments the operating system using OS resource managers. The operating system limits the number of CPUs where an Oracle database is running by creating areas where CPU resources are allocated to applications within the same operating system. This is a flexible way of managing data processing resources since the CPU capacity can be changed fairly easily, as additional resource is needed.
Examples of such partitioning type include: Solaris 9 Resource Containers, AIX Workload Manager, HP Process Resource Manager, Affinity Management, Oracle VM, and VMware.

Aside from the fact that ‘VMware’ is not a product, the interesting thing to note there is that Oracle VM is also listed as a Soft Partitioning technology. I’ll come back to this later.

So what does it mean? Basically what it is saying is that regardless of the number of vCPUs you configure for the VM, you have to license the entire physical host on which the Oracle workload is running. So, for example, if you create a 4 vCPU VM running Oracle and allow it to run on an ESXi host containing 2 CPU sockets and 6 cores per socket you need to purchase sufficient Oracle Standard licenses to cover 2 sockets or Oracle Enterprise licenses sufficient to cover 12 cores. (Oracle Standard edition is licensed per physical socket while Enterprise Edition is licensed per physical core) The size of the VM doesn’t play any part in the licensing calculations.

How does CPU Affinity affect my Oracle licensing obligations?

In short, it doesn’t. vSphere CPU affinity allows you to ‘pin’ a virtual machine to a specific physical core or set of cores within your ESXi host. Aside from the fact that this isn’t usually a good idea for performance and management reasons, to my knowledge it is not recognised by Oracle as a means of limiting your licensing obligations. Regardless of any CPU affinity rules you have in place, you still need to license the entire host.

Fig 1. vSphere Web Client showing a virtual machine with CPU affinity configured to only allow the VM to run on physical cores 1 and 2

The Double Standard

I mentioned earlier in this article that Oracle VM is also considered to be a Soft Partitioning technology. Where it gets a little blurred is that if you configure CPU affinity on a virtual machine running on Oracle VM it magically transforms itself into a Hard Partitioning technology, so the licensing restrictions no longer apply. (refer to http://www.oracle.com/technetwork/server-storage/vm/ovm-hardpart-168217.pdf ) Using Oracle VM with CPU Pinning configured you only need to license the physical cores on which the VM is configured to run, but you do lose the ability to do any form of live migration with that VM so it’s really a pointless exercise. If you are considering deploying OVM purely for the preferential Oracle licensing, keep in mind that you give up a lot of availability and performance features for that ‘benefit’.

So why the inconsistency in licensing terms? Why is CPU Affinity on vSphere treated differently to CPU Pinning on Oracle VM when they are basically the same thing? I have no idea.

If someone from Oracle would like to chime in on the comments and provide some explanation as to how this seemingly contradictory position was reached I’m sure it would be appreciated by a lot of people.

How does ‘Soft Partitioning’ apply to DRS Clusters?

So now we know that you have to license the entire ESX host regardless of how many physical cores/CPUs are executing the Oracle workloads. What this means in terms of vSphere is that you must license all hosts that an Oracle workload touches. If you VMotion a virtual machine running Oracle to a physical host, even if only for a second, that host must be fully licensed. On the flip side, you don’t need to license hosts that never have and never will run an Oracle workload. (That would be a bit silly – paying to license hosts that will never run Oracle workloads)

So how do you prevent Oracle workloads from touching unlicensed hosts? You have a number of options here. You could deploy separate vSphere clusters for the Oracle workloads, zone the storage so that the Oracle virtual machine files are only presented to a subset of hosts, or use DRS Affinity rules. There are probably other methods but all that’s important here is that you prevent workloads from migrating to unlicensed ESXi hosts. DRS Affinity Rules allow you to specify that a virtual machine will only ever run on a specified subset of ESXi hosts within the HA/DRS Cluster. By specifying a “Must run on hosts in group” rule you also ensure that HA won’t inadvertently start the VM on an unlicensed host in the event of a host failure.

Fig 2. DRS VM to Host affinity rule creation

I have heard a number of anecdotal claims in the past that Oracle does not officially recognise DRS Affinity as a means to control your licensing obligations and that it is considered a form of ‘Soft Partitioning’ so you need to license the entire cluster. Let’s address those two points.
In terms of Oracle not officially recognising DRS Affinity this is absolutely correct. Oracle has not to my knowledge ever published a document stating that DRS Affinity can be used to control your licensing obligations. They also haven’t published a document stating that storage zoning is a valid method to control your licensing obligations, nor physically separate clusters. Come to think of it, I don’t think I have seen an Oracle document stating that not installing Oracle prevents you from having to license a server. The fact is that Oracle does not publish anything that specifies what you don’t need to license, presumably because the list would be never ending. What they do publish is a Software Investment Guide (SIG) available at http://www.oracle.com/us/corporate/pricing/sig-070616.pdf that is pretty clear-cut in terms of what does need to be licensed. You will note within this document that you are required to acquire licenses for the following types of environments:

  • Development
  • Test/Staging
  • Production
  • Failover (>10 days)
  • Standby
  • Remote Mirroring

ESXi hosts outside of the DRS Affinity rule do not fall into any of these categories and therefore require no licenses. The Oracle binaries are never installed on these hosts, no Oracle workloads ever run on them and the VMs running Oracle workloads are never even registered on the hosts.

On the topic of Soft Partitioning, you will notice that the Partitioning Guide mentioned earlier in this post contains the following sentence:

The operating system limits the number of CPUs where an Oracle database is running by creating areas where CPU resources are allocated to applications within the same operating system

Note the phrase “within the same operating system”. Assuming that Oracle also consider the VMKernel to be an “operating system”, it’s pretty clear from that phrase that they are referring to partitioning within a single physical host. The definition of Soft Partitioning has no relevance to vSphere clusters as each node within the cluster contains its own independent hypervisor/operating system. So in addition to the SIG, the Partitioning Guide also supports the case for not having to license hosts that will never run Oracle workloads.

In Conclusion…..

I hope that clarifies how the definition of Soft Partitioning affects Oracle licensing on vSphere. While Oracle definitely don’t provide the most virtualisation or cloud-friendly licensing in the world, it’s not as bad as some would have you believe. The basic three rules are:

  1. If an Oracle workload ever runs on an ESXi host you must license the entire host, regardless of the size of the VM
  2. If an Oracle workload never runs on an ESXi host you do not need to license that host
  3. How you prevent Oracle workloads running on unlicensed hosts is entirely up to you

Once again, this is my understanding of Oracle’s current licensing conditions based on the published information. If an Oracle representative has official documentation stating otherwise (e.g That you do in fact need to license hosts that never run Oracle workloads) I will be more than happy to post a correction.

 

Leave a comment

19 Comments

  1. Great article,
    Having just seen the end of a lengthy process working with our DBA Team and Oracle, we reached the very same conclusions, notably that despite my first instinct to use DRS affinity rules they are not accepted by Oracle as hard boundaries for licensing. For virtualised instances of Oracle physically separate storage boundaries and separate clusters are needed.
    From a design perspective it raises many challenges – Appropriately sized clusters are key if Oracle workloads need a certain level of high availability, performance etc… (i.e. you may need to ensure 25 or 50% workload availability which will affect cluster size and how you license that respectively).However, what if you only have a few Oracle instances that you need to protect, does it really warrant a separate dedicated vSphere cluster? In that case I know the answer invariably ‘depends’ – on the individual vm availability requirements (SLO/SLA etc..).

    This does raise allot of questions around the design decisions for virtual implementation of oracle databases, a positive point to take from this is, as I have seen Microsoft change & design it’s products around its maturing hypervisor (which has also benefitted VMware vSphere implementations), hopefully as Oracle VM (virtual box) matures we will see this reciprocated.

    Gareth

    Reply
    • Andrew Mitchell

      Andrew Mitchell

       /  February 20, 2014

      Hi Gareth.
      You are correct in stating that DRS Affinity is not recognised by Oracle but, as stated in the article, it doesn’t need to be.
      Oracle does not recognise any method for preventing Oracle applications from running on a given host. All they specify is that hosts running an Oracle workload need to be appropriately licensed.
      It stands to reason that hosts not running Oracle applications require no license but how you prevent those applications running on the unlicensed host is entirely up to you and DRS Affinity is a perfectly valid way of achieving this goal.

      Reply
  2. Pierre-Yves

     /  February 20, 2014

    Hello Gareth,
    I have studied this precise question at length for my previous employer.
    First it is interesting to note that, per Oracle admission, the SIG is not a binding document.

    Second, you only have the license host where Oracle is installed or running. This is the ONLY obligation you have. That means from a Vsphere point of view that is your Oracle VMs never touch an ESXi you do not have to license this host. The means used to achieve this goal are entirely up to you (DRS, dedicated cluster or storage). Oracle has absolutely no say in this matter and DRS is a perfectly valid way to achieve that. You must keep the relevant technical logs, though.

    A dedicated cluster may be a simpler option in terms of assuring your obligation towards Oracle are met sure, but it is not the only option.

    Reply
  3. Martijn

     /  February 20, 2014

    My experience is that Oracle does not accept DRS affinity as well. The flipside of that is that they have stated that because you cannot control which host in a cluster is running the Oracle VM(s) that by default you need to license the entire cluster.

    This was in 2007 and to my knowledge the position has not changed since then. I remember reading a similar complaint in 2010/2011 and recently I was in a discussion about Oracle licensing again and was told the same rules have continued to apply.

    Reply
    • Andrew Mitchell

      Andrew Mitchell

       /  February 20, 2014

      Hi Martjin,
      I have heard of this coming up a few times and the simplest way to deal with it appears to be to ask for a response from Oracle (in writing) that details the section of your OMA or OLSA (your contract with Oracle) that specifies you must pay to license hosts that have never and will never run an Oracle workload. Such a clause will never appear in your contract to the best of my knowledge.

      Reply
  4. Pierre-Yves

     /  February 21, 2014

    Hello Martinj,
    The core issue here is that Oracle has absolutely no say on how you fulfill your obligation per the OLSA as long as you fulfill them. When you are using their product you have a contract with them saying that you must pay for all the CPU for all the servers where Oracle is installed or running.
    As long as this requirement is met, there is nothing more they can do except try to intimidate you.

    You can read more here
    http://oraclestorageguy.typepad.com/

    http://www.vmware.com/files/pdf/techpaper/vmw-understanding-oracle-certification-supportlicensing-environments.pdf

    Reply
  5. Firstly apologies if I have missed something here… Reviewing the Oracle SIG [070616], page – 29.

    “A storage device is defined as “shared” when it is connected to and used by two or more systems.”….
    “When deploying on shared storage devices, standard-licensing policies applies. All processors where the Oracle programs are installed and/or running need to be licensed.”

    In the licensing scenarios (#10a) it states… “All software is installed in a single volume on a shared storage and the volume is mounted onto all the compute nodes.

    In my opinion this could be open to interpretation. I understand this in context to vSphere (but could apply to any hypervisor). Any ESXi host that has access to the LUN that the Oracle workload exists on needs to be licensed.
    Again in my opinion the safest option is… …unless you want to license all your hosts that have access to the LUN housing Oracle workloads (VM’s). You need to employ hard boundaries between hosts that protect said`Oracle workloads and those that don’t.

    Reply
    • Andrew Mitchell

      Andrew Mitchell

       /  February 22, 2014

      In this case the ‘volume’ would be the vmdk which is only ever ‘mounted’ on the hosts running the VM.

      Reply
      • Pierre-Yves

         /  February 23, 2014

        I think this section in the SIG covers a specific deployment mode which is NFS. In this case, you could install the binaries and the datafiles on 2 shares and mount them on different servers to create a RAC clusters. It makes makes perfect sense that those nodes should be licensed even though the binaries are not physically installed on the nodes.

        Reply
  6. Pierre-Yves

     /  February 22, 2014

    Gareth, If you read closely the SIG, you will find at the bottom of each page
    This document is for educational purposes only and provides guidelines regarding Oracle’s policies in effect as of September 30, 2013. It may not be incorporated into any contract and does not constitute a contract or a commitment to any specific terms.

    The 10a point, if we followed your interpretation, would mean that all servers connected to a storage arrays containing Oracle binaries would have to be licensed. That seems a bit far fetched, even for Oracle….

    Reply
  7. OraEmployee

     /  August 22, 2014

    I have worked in the pre-sales side of Oracle for several years and can share a few pieces where your post is incorrect:

    1) VMWare clusters: the entire cluster needs to be licensed, no way around this. I used to recommend separating a couple servers off into a different cluster, but based on the newest version of VMWare that introduces more flexibility to move VMs around, they now say that any cluster on the same storage as the Oracle cluster needs to be licensed as well

    2) My understanding of Oracle VM is that in order to un-pin the cores, you would need to modify the vm.cfg file and reboot. I believe in VMWare this reboot of the cluster is not required, and therefore why it isn’t recognized as hard partitioning. Basically, anything that would allow you to move Oracle environments around easily is not recognized. Many customers would try to take advantage of this and scale up capacity or failover onto other servers for planned downtime, etc. While Oracle software is pricey, there need to be hard rules in place to prevent customers from trying to cheat the system. Unfortunately, this makes the licensing policy much less flexible.

    Reply
    • OraEmployee

       /  August 22, 2014

      Also, to the shared storage comments. This does impact licensing in several ways. Customers using SAN replication need to license the remote side if they are copying the Oracle binaries and not just the database specific files like dbf files. This means that in 95% of cases, what they would consider a way to meet DR needs and avoid licensing, actually requires licensing. I see this happen a lot.

      Reply
    • Andrew Mitchell

      Andrew Mitchell

       /  September 9, 2014

      Thanks for chiming in. In relation to (1) That’s where a lot of the problems begin. The pre-sales teams are being told that customers need to license entire clusters but there is absolutely nothing within Oracle’s documentation or the individual customer contract that states this. Every instance that I’m aware of where a customer has challenged this and stuck to their guns, they have successfully negotiated a better outcome.

      If Oracle was serious about serving their customers they could quite easily address this confusion by posting clear and concise *official* guidance on licensing in a VMware environment. (And no, the partitioning guide is not clear and concise) After all, despite the competition catching up, VMware still maintains a healthy lead in market share so I’m sure many Oracle customers would appreciate some clarification.

      Reply
  1. Don't create a Frankencluster just because you can...
  2. Baut keine Frankencluster!

Leave a Reply

Your email address will not be published. Required fields are marked *