Deploying Oracle in the Cloud

In the previous blog post, I looked at the issue of licencing Oracle database for a cloud environment.  My conclusion was that despite Oracle’s opposition, this is perfectly feasible provided that certain conditions are met; namely that the software is tied to particular physical processors, and that log records are kept to prove that it doesn’t migrate elsewhere.

In this article I’ll take a large-scale online application which use Oracle database, look at some typical architectures, and discuss the trade-offs associated with them.  I’ll show that the necessity of licencing Oracle correctly has a significant influence on infrastructure design.

Example - a large set of applications

Let’s assume that we are developing one or more online applications which are based around an established COTS product that requires Oracle Enterprise Edition as its database.  The Oracle database, however, is only one of many software components that constitute the application(s).  We will look at the development and test environments, because there are likely to be a significant number of these - 20 or 30 is not unusual -  and the number could vary over time, as new requirements appear or new workstreams are set up.

I’ve created this example as an illustration, but the conclusions apply to other cases too.  The key factors which make this applicable are:-

1. We have one or more applications that require an Oracle database
2. Oracle is only one of many components in the application architecture
3. We need to create a large number of environments, either because we have a complex application that requires many development and test environments, or because we have multiple simpler applications to develop and manage
4. We want to host these environments in the cloud

Incidentally, with regard to development and test, note that all multi-user environments running Oracle must be licenced appropriately.  In this case this means both Production and non-Production environments.  It is a common (and expensive!) mistake to assume that development and test environments don’t need to be licenced.  This is only the case, however, under very restricted circumstances, e.g. for a development environment running on a single laptop and only accessible by one person.

Using an authorised cloud

We can deploy onto an Oracle-authorised cloud environment (i.e. Amazon EC2 or S3, Microsoft Azure, or an environment running Oracle’s own virtualisation technology) and meet the licencing requirements.  Each environment has a dedicated database in its own VM, and all of the VMs are allowed to move within the cloud environment.  The diagram below shows the arrangement.

This is technically a good solution;  each environment has an independent Oracle DB running in its own VM, so there is no interference between environments.  We are free to make these DBs as close to Production as we want, and provided that we have automated the environment build process, there is little overhead in creating them.  By virtualising in the cloud we (or the cloud provider) can take advantage of server consolidation to keep down hardware costs.

However, we get no benefit from licence consolidation in this solution.  Each environment is licenced separately, using the virtual processor count.  So if we have 20 environments, and each database VM uses 4 vCPUs, that’s a total of 80 vCPUs to licence (or 40 cores, applying a core factor of 0.5).  If we decide to licence on user count instead, we would need to purchase a minimum of 40x25 = 1000 NUPs, for the Enterprise Edition.  Thus, although this solution looks attractive at first sight, it can get very expensive if the number of environments increases.

Note that we would be in trouble if we decided to use an unauthorised cloud.  Then we would be required to licence all the physical processors in the cloud, which could amount to many hundreds.

Using a Physical CoLo

A possible solution is to extract the database from each environment and to deploy it onto a set of physical servers.  This would be housed in a physical CoLo that is logically adjacent to the cloud infrastructure.   We can either keep each DB separate, in its own VM, or we could use Oracle’s multi-tenant solution to deploy each DB as a pluggable running in a single container DB.  The arrangement is as shown below.

To licence Oracle correctly in this case, all the processors in physical server on which the database is installed and/or running must be counted.  This need not include every server in the CoLo;  servers on which Oracle is not installed or running can be excluded.  With this arrangement, we can achieve both server and licence consolidation.

However, there are a number of disadvantages of this approach:-

1. Latency between the CoLo and the Cloud.  This must be very low, or performance will suffer. Without a very fast network connection, the solution will become unworkable
2. Many of the benefits of a cloud architecture are lost for the databases.  Hardware must be procured and managed, and increases in capacity must be planned well in advance
3. The CoLo and its network connection represent a single point of failure.  Unless we build in high availability, a failure in either component will take out all the environments
4. The infrastructure and deployment is managed separately from the cloud service, so that the build and deployment tools provided by the cloud service may not be usable
5. In most cases, the physical CoLo represents a CAPEX cost, whereas cloud services are usually procured as OPEX
6. A separate third party may be required to manage the CoLo, resulting in additional management costs.

Using a “Virtual CoLo”

The third solution can be thought of as a hybrid of the previous two.  Instead of establishing a separate CoLo, a “virtual CoLo” or vCoLo is set up as an extension to the cloud service.  This is a ring-fenced area where any applications that are deployed there are confined to that area.  However, it is set up and administered using the same cloud tools that apply to the surrounding cloud service.  It also benefits from the other features of a cloud service - e.g. ability to scale up individual VMs, or to change the storage requirements on demand.

The key point about licencing here is that, as in the previous case, it is based on the actual physical processors.  All such processors in the vCoLo must be licenced, since Oracle could quite legitimately claim that the software could run on any or all of them.  The hosting provider must supply the information on servers and processors to enable the licence cost to be calculated.  However, provided the necessary precautions to prevent the software migrating outside of the vCoLo, there is no necessity to licence any other processors.  Oracle LMS may cite arguments such as the use of shared storage to extend the licence requirement into the adjacent cloud, but as discussed previously such arguments are specious and can be safely rejected.

Compared to the first solution, where licencing costs could become very high, we can use licence consolidation to keep these in check. And compared to the second solution, we can overcome many of the disadvantages of the relatively inflexible and separate physical CoLo.

So how do we set up this vCoLo?  If we are running a private cloud or on-premises hosting, we can allocate some of the underlying physical servers to this area.  The previous post explained how this can be achieved using a vSphere cluster, for instance. If we are using a public or community cloud, this may be more problematic as the cloud provider may not grant the necessary access to the underlying hardware to set this up.  Some cloud hosting providers offer a single-tenant, dedicated set of servers as an extension to their multi-tenant cloud service.  For instance, for the UK public sector Skyscape offer a “dedicated compute” area where the VMs can be localised to an identified set of physical hosts, unique to each tenant, in order to meet this requirement for separation.

Summary

It seems unlikely that Oracle will extend their Authorised Cloud Environments to other cases beyond the three already provided.  And use of an authorised environment will incur high licencing costs as the number of databases increases.  Moving Oracle databases to physical servers in a CoLo is an alternative, but risks losing many of the benefits of the cloud, and may require more complex contractual relationships.  A hybrid “vCoLo” is suggested as an alternative, where a dedicated private cloud is managed and run by the cloud provider.  This combines the economies of licence consolidation with the simplified management and flexibility of a cloud solution, whilst maintaining compliance with Oracle’s licencing obligations.