Use Cases for Virtualizing Your Exadata Database Machine

    By: Umair Mansoob on Apr 16, 2019

    Exadata Use Cases.png

    By Umair Mansoob | Edited by Tim Boles

    It’s been awhile since Oracle has started supporting virtualization with the Exadata Machine. That means you can virtualize your Exadata Machine using Oracle Virtual Machine (VM) technology with no additional cost. Ideally, Oracle VM on the Exadata Machine should be used for database consolidation or isolation, but you are not restricted for database use only. You can use Exadata VMs to install other products like management or extract, transform and load (ETL) tools, but it’s not recommended to run major applications like SAP or EBS. Currently, Exadata VM deployment is only certified on Oracle Enterprise Linux, but perhaps in the future Oracle will start supporting other operating systems.

    Exadata Database Machine_Figure1.JPGVirtualized Exadata Machine architecture can be significantly different from a default Bare Metal installation. With a Bare Metal install, you have one Oracle cluster for a whole Exadata Machine, unless you physically partition your Exadata Machine. With a Virtualized Exadata Machine you have one management domain (dom0) and at least one user domain (domU), depending on the number of VM clusters being deployed. Management Domain (domO) is automatically created with 4 vCPU, 8 GB RAM, with no Oracle GRID and RDBMS software installed in it. Each user domain (domU) should be sized carefully based on the databases you are planning to host in future. With virtualized Exadata install, you only virtualize compute nodes and share storage between them. This also means that all the VM clusters will have their own dedicated ASM disks groups and physical disks.

    Virtualizing an Exadata Machine has become an important deployment decision for many Exadata customers and most of them like to explore or discuss virtualization to see if there are any benefits for them. Keeping that in mind, below are use cases where it makes sense to virtualize an Exadata Machine.

    Oracle Licensing (Cost Saving)

    With the introduction of elastic configuration and capacity on demand (COD), you can save a significant amount of money on licensing and initial investment. With the Exadata elastic configuration option, you can build Exadata with almost any configuration of compute and storage servers.  According to the Oracle Licensing Information User’s Guide, the capacity on demand (COD) option allows you to buy Oracle licenses in increments. A minimum of 40% CPU cores must be licensed, which allows you to buy one-eighth of a rack by only licensing eight cores per server.

    Utilizing this option can reduce the licensing cost of additional Oracle features like Advance Compression and Advance Security. Virtual machines on Exadata are considered Trusted Partitions and therefore software can be licensed at the virtual machine level instead of the physical server level. Without Trusted Partitions, database options and other Oracle software must be licensed at a server or cluster level, even if all databases running on that server may not require that option. Even with an Unlimited License Agreement (ULA), organizations don’t have unlimited licensing for everything (Golden Gate, Advance Security, Advance Compression, etc.). Some of the licensing options are very expensive and can end up playing a key role in your decision to buy an Exadata machine.

    Exadata Database Machine_Figure2.JPG

     

    I like to use Advanced Security and Advance Compression licenses as an example here to demonstrate how Exadata customers may be able to use these advanced Oracle database options with a portion of estimated cost and save hundreds of thousand dollars on the licensing cost. As you can see from the figure above, we only need to purchase to buy an Advanced Compression license for enterprise data warehouse, instead of 14 licenses if this Exadata machine was deployed as Bare Metal. Similarly, we only have to buy two Oracle Advance Security licenses for a SAP database, which is using just a portion Exadata processing power. 

    Security & Compliance (Data Classification)

    Compliance is another important reason to virtualize an Exadata Machine. Organizations must deal with different types of compliance requirements like HIPPA and PCI DSS, depending on their type of business. You might be required to isolate PCI data from non-PCI or HIPPA data from non-HIPPA for compliance reasons.

    In addition to regulatory requirements, many software vendors have their own set of requirements which you may need to comply with in order to host their application database on an Exadata Machine. For example, if a database contains sensitive customer data, you might be required to isolate that database from other databases by a vendor or business unit.  Similarly, if you are planning to host SAP databases

    with non-SAP databases, you might need to isolate relational database management system (RDBMS) and cluster ready services (CRS) homes as SAP releases its own bundle patches.

    But before you decide to deploy a virtualized Exadata Machine in your organization, make sure to carefully analyze compliance requirements. You can still achieve a different level of isolation with an Exadata machine without virtualization. For example, you can have additional Oracle RDBMS Homes for different patching requirements, you can also have different disk groups to provide storage isolation and it is also possible to have a separate physical cluster, if you have half or full Exadata rack. With OVM you will be able to install two or more VM Oracle clusters and achieve additional level of isolation. You will have a separate operating system and Oracle Homes with each cluster. Additionally, each cluster will have its set of automatic storage management (ASM) disk groups. Even though you will be sharing same network devices, network isolation will be achieved using InfiniBand partitioning and VLAN.

    There could be an extreme case when you might be required to isolate client data physically at all levels (operating system, network and storage). In that case, virtualizing an Exadata machine will not be good enough to comply with this requirement. It’s important to understand that even if you create separate ASM disk groups, you will still be sharing the same physical storage and network. I recommend exhausting all other isolation options before deciding to use OVM to achieve desired isolation.  

    Workload Isolation (PROD/TEST/DEV)

    Over the years, I found another important use case for Exadata virtualization. An Exadata machine is an expensive piece of hardware, and not all organizations have the luxury to buy multiple Exadata machines for production, test and development environments. Given the significant investment, chances are you will host a critical database on an Exadata machine. Critical databases usually require many production-like environments, where you can test changes before promoting them to production. For these reasons, I recommend at least one production-like environment for all critical databases. If it’s not possible to have separate physical Exadata Machines for your critical databases, you can choose to virtualize Exadata Machines to have production-like environments within the same Exadata Machine hardware.

    Exadata Database Machine_Figure3.JPG

    This will also provide you an opportunity to maintain separate RDBMS homes and Clusterware homes for production and production-like environments. You can also maintain different patching cycle and maintenance windows for production vs non-production databases. This is not a perfect use case to have a virtualized Exadata Machine in your environment, but I have seen many Exadata customers comfortably using it to have a production-like environment for their critical databases.

    Database Consolidation (Gold/Silver/Bronze)

    Many customers are looking to achieve operational efficiency and reduce cost at the same time by utilizing idle resources through consolidation. Database consolidation can be achieve using many ways. We can consolidate many databases into schemas, a single host, or use the Oracle multitenant feature to consolidate many instances into one. Exadata is optimized for both the On-line Analytical Processing (OLAP) and On-line Transaction Processing (OLTP) database workloads, and its balanced infrastructure makes it an ideal platform for database consolidation. As many customers have adopted the Exadata machine as their database platform for all Oracle environments, Exadata Virtualization can be used to deliver a high degree of isolation between different classes of databases. Given that, not all the databases have same SLA’s or maintenance requirements, virtualization can be a very desirable feature for consolidating all types databases into a single platform.

    Exadata Database Machine_Figure4.JPG

     

    Using OVM, multiple software clusters can be deployed on the same Exadata Database Machine, which enables consolidation of different groups of databases into each Exadata VM. For example, we can create multiple VM environments corresponding different database categories like Gold, Silver and Bronze. Ideally, we like group together databases with similar criticality, SLA’s and maintenance windows into a single group like Gold, Silver or Bronze.

    Other Considerations

    Isolation versus Efficiency  

    There are many reasons to virtualize your Exadata Machine, but the end result is to achieve some level of isolation. As isolation is probably the main reason to virtualize an Exadata Machine, we need to keep in mind that everything (CPU, memory, disk) will be hard partitioned. Even though you can overprovision CPU, Oracle recommends strongly against over provisioning any resources. With dedicated CPU, memory and disks you will be able to achieve great isolation, but it will not be an efficient use of an Exadata Machine’s resources. Similarly, Exadata virtualization will provide you with an opportunity to have different patching cycles for each Exadata VM cluster, but not without maintenance overhead.

    With virtualization you must patch and maintain multiple Oracle homes versus just one. Imagine if you have multiple virtualize Exadata Machines in your organization, you will be spending a considerable amount of time and effort to maintain their patch levels. It is also important to remember that Oracle releases four bundle patches a year and you need to apply at least two of them to be compliant with Oracle Platinum Service. Additionally, since everything is hard partitioned in a virtualized Exadata Machine, you will not be able to use IDLE hardware resources from Other VMs. Hence, you will be wasting very expensive hardware and software resources.

    As mentioned earlier, there are many levels of isolation, such as physical, operating system, storage, clusterware or RDBMS. You can still achieve some level of isolation without virtualizing an Exadata Machine. Virtualization has lower efficiency and a higher maintenance cost, so it is very important that we analyze requirement to virtualized Exadata Machine carefully. I would only recommend Exadata virtualization if it significantly reduces licensing cost or if it is required by compliance or security team. Virtualizing an Exadata Machine should not be your standard build, you should always consider Bare Metal deployment over virtualized Exadata deployment. 

    Maintenance and Support

    Maintenance and support are important factors for organizations when it comes to adopting any new technology. If you are looking to deploy a virtualized Exadata machine in your organization, it’s important that you know if you will be able to support new architecture. There is no doubt that you are introducing complexity in your environment and an additional layer of software in your Exadata stack. But careful consideration and upfront planning can make supporting virtualized Exadata task much easier. The following are important considerations when it comes to supporting virtualized Exadata machines.

    Migration: The first thing you should know about managing Exadata Machine is that you can migrate from Bear Metal Exadata Machine to virtualized Exadata Machine. Conversion from Bear Metal to virtualized Exadata Machine can be achieved with zero downtime or minimum downtime, depending on various migration methods.  

    Memory: You can decrease or increase the amount of memory allocated to a user domain with proper planning. For example, if you want to decrease the memory allocated to a user domain, you should consider instance memory parameter and make sure you still have enough memory left for a user domain to support SGA/PGA for all the running databases. Memory changes to a user domain is not dynamic and will require restart of a user domain.

    CPU: You can also dynamically increase or decrease the number of vCPU’s assigned to a user domain as long as it will not exceed the number of vCPU’s assigned to that domain by a parameter called “maxvcpus”. Overprovisioning is possible but it’s not recommended by Oracle, as it will require full understanding of the workload on all user domains.

    Storage:  Like CPU and memory, you can also increase the size of underline storage for any user domains. You can add new logical volume, increase the size of the root file system and increase the size of the Oracle Grid or RDBMS files system. 

    Conclusion

    You should analyze requirements to deploy an Exadata machine carefully and only choose virtualization if it makes sense. Exadata virtualization comes with maintenance and support overhead and it should not be your default deployment approach.

     

    References

    Oracle Licensing Information User’s Guide: https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmli/exadata-capacity-on-demand.html#GUID-AAA08D53-D5BA-41FB-838D-53B3C7A28EF7

     

     


     

    Umair Mansoob.JPG
    Umair Mansoob
     is an Oracle Certified ACE professional, working with Oracle Technologies since 1999. He is an Oracle Certified Database Professional from Oracle version 7.3 to 12c and Oracle Certified Implementation specialist for Exadata Machine, Business Intelligence, and Data Warehousing. He has served as an Oracle Consultant for many large financial clients and specialized in Exadata Implementations, data warehousing, business intelligence, cloud architecture and cloud migration. He is a regular contributor to Independent Oracle User Group (IOUG) and presented at many Oracle conferences, including Oracle OpenWorld.

    Released: April 16, 2019, 9:06 am | Updated: April 16, 2019, 9:55 am
    Keywords: Feature | SELECT Journal | Exadata | SELECT | SELECT Journal | virtualizaion


    Copyright © 2019 Communication Center. All Rights Reserved
    All material, files, logos and trademarks within this site are properties of their respective organizations.
    Terms of Service - Privacy Policy - Contact

    Independent Oracle Users Group
    330 N. Wabash Ave., Suite 2000, Chicago, IL 60611
    phone: 312-245-1579 | email: ioug@ioug.org

    IOUG Logo

    Copyright © 1993-2019 by the Independent Oracle Users Group
    Terms of Use | Privacy Policy