Many organizations resort to database consolidation nowadays to reduce infrastructure and operational costs, and this is often achieved by allocating more resources to each database than the infrastructure can physically offer based on the assumption that the consolidated databases will not experience simultaneous peak demands for those resources. When customers decide to move these databases from their on-premises data centers (or other platforms) to Autonomous Database, they rightfully want to retain the cost savings resulting from the consolidation. Using compute auto scaling or stopping your instance when no workload is running are some of the few ways Autonomous Database offers cost savings for our customers. However, when you have hundreds of databases requiring a fraction of an ECPU or highly oversubscribed in your on-premises systems, these options may not be sufficient. Today, I'm excited to announce the general availability of a new "Elastic Resource Pools" feature that addresses such consolidation use cases in Autonomous Database. For the remainder of this blog, we are going to explore this new feature in the following order:
◉ What is an elastic resource pool?
◉ Key Benefits
◉ Use Cases
What is an elastic resource pool?
An elastic resource pool is a logical entity where you can consolidate your Autonomous Database instances in terms of their compute allocation. You can think of it as a “family plan” for your Autonomous databases. Instead of paying individually for each one of them, they are grouped into a logical pool in which you are charged for the compute usage of the entire pool. An elastic resource pool essentially is a collection of Autonomous Database instances, potentially hundreds or even thousands of them.
Depending on the number of databases you want to fit in a pool and their compute allocation needs, you can pick one of the predefined pool sizes when you create a resource pool.
An elastic resource pool allows you to provision up to 4 times the ECPU count you have as your pool size. For example, if you have a pool with a pool size of 128 ECPUs, you can provision up to 512 ECPUs in this pool.
The pool size you set for your resource pool is not a hard limit in terms of combined ECPU utilization of the pool members. For example, if you have 100 databases with 5 ECPUs each in your pool with a pool size of 128 ECPUs, the aggregated ECPU utilization of all pool members could add up to 500 ECPUs depending on the workload each one is running. You are only billed for the size of the elastic resource pool. If the aggregated ECPU utilization of all databases in the pool exceeds the pool size, you are billed for auto scaling.
Key benefits
Primary advantages of elastic resource pools include but not limited to:
- Compute cost savings up to 87% versus paying for each individual instance.
- The individual ECPU allocation of an ADB instance in a resource pool can be as low as 1 ECPU compared to 2 ECPUs for the cases that don’t include a resource pool.
- The low entry point (i.e., 1 ECPU) combined with the pool capacity of 4 times the pool size provides significant cost savings.
- An elastic resource pool is a logical grouping of Autonomous Databases. In other words, the databases that belong to a pool do not have to reside on the same physical infrastructure, unlike how database consolidation is done on on-premises.
Use Cases
Elastic resource pools play an integral role in addressing following use cases:
- Migrating from on-premises (or other platforms) with oversubscribed database systems
- For example, assume I have an on-premises data center in which I oversubscribed 200 databases in a 64-core server. How can I migrate these databases to Autonomous Database without having to sacrifice my cost savings resulting from the oversubscription?
- The answer is elastic resource pools. I can create an elastic resource pool with a pool size of 128 ECPUs, in which I provision databases whose ECPU individual ECPU allocation can add up to 512 ECPUs.
- Migrating large number of very small databases
- An example could be customers who use microservices architecture and are planning to migrate all their databases to Autonomous Database.
- SaaS providers who deploy hundreds or thousands of databases to store their customer data.
In conclusion, database consolidation has been a prevalent strategy among enterprises to reduce operational and infrastructure costs. While various approaches exist for implementing database consolidation on on-premises or other platforms, there hasn't been a native solution up until now to consolidate those databases under the Autonomous Database umbrella and achieve similar benefits in terms of cost savings. Autonomous Database now fills that gap thanks to our new feature called "Elastic Resource Pools." As we have seen in this blog post, elastic resource pools are an invaluable tool for organizations who are in pursuit of enhancing their cost-effectiveness as they move hundreds or thousands of databases to Autonomous Database in Oracle Cloud.
Source: oracle.com
Posts
0 comments:
Post a Comment