Workload Consolidation in Oracle Engineered Systems
Consolidation of workload is one of the key benefits highlighted for Oracle Engineered Systems (OES). Being a heavily packed set of machines, this is indeed the major benefit of OES as well. Over several years, organization might have deployed workloads across several hundreds of servers with lot of considerations like time zone, business criticality, application functionality, production vs non-production etc. Obviously, the management of these distributed systems would definitely add huge overhead in terms of space, power, resources, licenses etc. OES is definitely a choice if you consider workload consolidation. However, you must carefully evaluate pros and cons of consolidation approach through proper analysis of existing environments and their characteristics.
- Being packed with multiple redundant sets of servers with powerful intel new generation processors, integrated proprietary software which orchestrates high performance servers with storage and other peripherals, OES offer exceptional option to consolidate highly distributed workloads into a concise and organized environment.
- OES offer robust, proprietary methods in performance, the hardware footprint is reduced nearly half when compared to traditional systems which brings direct savings in real estate, power and resources. Oracle Exadata is an example of this. Its high performance compute and storage , integrated with its proprietary storage software (Link) which has features like writeback flash cache, IORM etc reduces both the hardware physical footprint and licenses (Note : actual benefits need to be thoroughly tested and benchmarked before taking decisions. Refer the points here before jumping to such decisions)
- When you consolidate, you are naturally centralising or tying-together several applications or databases. Hence, any changes applicable to the specific OES may affect the availability and performance of the hosted applications or databases. For example , suppose you consolidated workloads of 10 different physically separated databases into one single Exadata Quarter Rack box where each of these run as separate Oracle Database instances. In the event of an upgrade of Exadata Quarter Rack to full rack AND/OR critical Patch Udpate of its firmware/storage/infiniband etc, the change management overhead is extremely complex. In the event of an unforeseen exception during that change, the hosted systems and its end users (business) might experience an unavailability of performance degradation.
- Again, changes in underlying system hardware or software required for one specific customer brings in management complexity. If other customer systems are not compatible with such changes (and don’t agree to the same), the change management will be a pain for the administrators.
- If you don’t consolidate the environments by carefully segregating customers according to time zones or functionality, the consolidation exercise may lead to catastrophes and a spike in costs. For example, if two customers from two different regions are hosted together and both of them utilizes the system uniformly across time, when some conflicts happen, it will be extremely difficult to manage. For example, suppose if databases of two airline systems from 2 different regions hosted in a single Exadata partition and they have round-the-clock schedule, the system maintainability will be a challenge.
Must Dos for Consolidation
- Segregate target environments according to customer time zones (or business hours), application functionality or criticality etc. Your target for consolidation should be to reduce hardware footprint and sweat the OES at reasonable levels round-the-clock. At the same time, take extreme care not to bundle together multiple workloads with conflicting features which would lead to issues mentioned in disadvantaged section.
- Analyse the CPU and RAM utilization of workloads and document them. Select realistic business hours of customers for at least a week, plot the data and benchmark how much resources are required to run the actual workload. This data needs to be compared with benchmarks for the same application in Oracle Engineered Systems and arrive at the target capacity required in OES.
- Thoroughly test and benchmark the target applications for consolidation in OES. This is extremely critical and essential to compare your current workload benchmarks. This is the step where you actually derive the cost benefits of moving to OES. For example, when you test a specific application’s database in Oracle Exadata, you should run different application mix, with real world business scenarios in it. Collect utilization data for Exadata servers (Compute, Storage) etc and output of application. If an application which can serve 1000 users in a minute in traditional servers can serve 2000 users in a minute with half the capacity in Exadata (in comparison to current environment), it is a good candidate for migration. This is an activity fully focused by senior management to insist architects on including “real world scenarios” rather than hypothetical scenarios just to complete the tasks; which will defeat the purpose.
- Never take a decision to migrate workloads to OES just by marginal cost benefits. Consider all the factors together such as application availability, maintainability, ease of changes, overall savings in terms of space, power, resources, licenses etc.
- Never driven away by technology enhancements available in OES alone. The decision should be based on business benefits rather than technology enhancement. For example, if the Organization has a larger interest to move out of Oracle and the plan seems to brings in 10 x benefits compared to this, then the decision should be aligned with Organization’s strategy rather than siloed approach of moving to OES. The investments in OES has effects over an exceptionally long period. The 42 U racks will sit in your data center (if you don’t opt Oracle Cloud option), for more than 5 years. Hence your decision should be fully vetted as per the “Must Dos” above.
Next : Oracle Engineered Systems as Simplified Cloud ( To be published)
Sethunath U N
This is Part 3 of Many in this series which discusses about Oracle Engineered Systems. If you think of considering Oracle Engineered Systems adoption or want to evaluate your decision, do contact us at firstname.lastname@example.org for a comprehensive analysis to help you take the right decision.