Wednesday Nov 12, 2014

Compare and Contrast (and mix-n-match) Oracle's SPARC V12N choices

new white paper from Oracle's Elite Engineering Exchange team provides an excellent guide to the different virtualization technologies available on SPARC platforms, including guidance on when to employ each - either alone, or in combination with another technology.  PDoms, LDoms, and different flavors of Solaris Zones are evaluated in terms of

  • Security Isolation
  • Resource Isolation
  • Efficiency
  • Availability
  • Serviceability
  • Flexibility
  • Agility

Although the paper is not specific to database deployments, the key points apply to all workload tiers.  And while the discussion is on SPARC technologies, many points apply to all virtualization technologies.  For example, from our DBaaS perspective, the following quote from the paper couldn't say it better:

"When a traditional  monolithic virtualization approach is taken where machines are mapped one-to-one to virtual machines, there is no overall reduction in the operational complexity of the system, because there are still the same number of entities to be managed ... the aim should be to consolidate workloads, not simply to consolidate machines, because it is workload consolidation that will drive the operational efficiencies of the data center."

 This summary from the paper shows the full scope of the discussion - the paper looks at each of these rows in detail, and finishes with an evaluation of the combinations that make sense (and when they are indicated).  Great reading for anyone looking to consolidate workloads onto SPARC platforms.

Tuesday Aug 27, 2013

The High Price of Over-Virtualizing

It seems that most of the collateral we read about cloud will blithely assert that the first step in creating a cloud environment is to virtualize.  Often we're not told specifics until we read the details, when we discover that the advice is to shovel everything in to virtual machines. Other times, the author will simply lead with virtual machines as the entry point to cloud.  In both cases, the proposition that a cloud must be based on virtual machines is simply taken for granted.  And many people seem to have no qualms about this, and they start their evolution to the cloud by shuffling their physical server silos into VM silos.    Is that always the right thing to do?

Let's consider the idea that "more is better."  A friend of mine is looking for a home to buy and debating different down payment vs. loan options.  I'm reminded of when I was on the market and someone gave me this advice: since you can deduct home mortgage interest from your federal taxes, you should make the smallest possible down payment.  This will maximize your interest payment, and therefore your tax deduction. 

So my question was - if a bigger deduction is better, why not look for a loan with a high interest rate?  Then I can pay more interest and get a bigger deduction!

The same fallacy is plaguing many discussions about virtualization in the move to cloud.  Virtualization has many benefits, and comes in many forms.  Assuming that virtualizing as much as possible - i.e., deploying in VMs - leads you down a path that will simply replace your physical silos with virtual silos.  If you want to simplify your environment and make better use of pooled resources, consider the virtualization available in the applications you are deploying.  With a product such as the Oracle Database, you'll discover that features and options such as Database Resource Manager, Instance Caging, and Oracle Multitenant will handle the vast majority of use cases you thought you needed VMs for - without the added elements to deploy and manage.

Friday Mar 01, 2013

Oracle RAC in Solaris 11 Zones

In database cloud deployments, companies host multiple databases for use by various internal groups (private clouds) or external clients (public or community clouds). Whenever multiple databases are deployed together on shared infrastructure, the solution must take into account the degree of isolation each database will require with respect to faults, operations, security, and shared resources.

In many database cloud deployments, Oracle Database features and options will provide the required isolation. This allows consolidating multiple Oracle databases natively onto a shared infrastructure, without the need for further isolation. In native consolidations, all databases share a single Oracle Grid Infrastructure. This approach is described in detail in the Oracle white paper "Best Practices for Database Consolidation in Private Clouds" which is posted on our OTN page.

Database clouds hosting databases with security or compliance considerations have higher requirements for isolation. These could include sensitive data with privacy requirements, or data from multiple companies who cannot be aware of each other (i.e., a public cloud). Such deployments may need to apply additional technologies or controls beyond those available in a native consolidation.

Implementing higher degrees of isolation can be accomplished by encapsulating each database environment. Encapsulation can be accomplished with physical or logical isolation techniques. Oracle recently certified 11gR2 RAC in Solaris 11 Zones,  which is an important capability for database clouds, because it enables strong isolation between databases consolidated together on a shared hardware and O/S infrastructure. We've just published a new white paper that describes the options and makes a detailed analysis of how Oracle Solaris 11 Zones efficiently provide encapsulation to Oracle database clouds.  To see how this technology set can be leveraged on SPARC SuperCluster, read about the Oracle Optimized Solution for Enterprise Database Cloud.



The Database Cloud Architecture Team at Oracle develops and documents best practices for designing and delivering database consolidation and database-as-a-service projects for on-premises database clouds.


« July 2016