This is part three of a three-part series on Exascale. If you haven’t read the articles, I suggest starting out here.
New OCI possibilities unlocked
In the previous two articles, we have focused on the functional changes brought by Exascale as the heir to ASM. This change could/will technically be applicable to any Exadata platform, whether in Oracle Cloud Infrastructure (OCI), on-premises, or even in a Multicloud environment. The only requirement is the use of the latest software versions and an Exadata platform. Additionally, Oracle’s commitment to OCI is well known, so it’s no surprise that the first Oracle solution with Exascale software is precisely on OCI, named “Exadata Database Service on Exascale Infrastructure” (ExaDB-XS)“; a variation of “Exadata Database Service on Dedicated Infrastructure” (ExaDB-D).
ExaDB-D systems are dedicated hardware infrastructures for the client, and therefore, the client must commit to infrastructure based on their maximum estimated potential load. As such, part of the monthly cost is the fixed cost of the reserved hardware infrastructure, and another variable part depends on the number of OCPUs activated (this part can significantly reduce the bill – fewer active OCPUs per unit of time means lower cost).
Focusing on the ExaDB-D infrastructure, although it is indeed flexible and can be expanded – both in compute nodes and cells – this growth in infrastructure is not immediate. Therefore, when using ExaDB-D, one must try to adjust the shape to the immediate potential peaks that it must serve.
And here comes the key issue: the fact that we have to decide on a “shape” of physical infrastructure, and that there is a minimum shape of 2 compute nodes and 3 cells, means that some companies do not have enough critical mass to make it worthwhile to invest in dedicated infrastructure.
ExaDB-XS uses Exascale software to provide the same service as an ExaDB-D but reserves a virtual infrastructure. Instead of defining how many physical compute nodes we need, we choose how many virtual machines our virtual cluster will have. Instead of choosing how many storage cells we need, we choose how much space in Exadata cells (and flash cache) we need. By reserving a virtual infrastructure, the amount of resources we can commit to has much lower minimums. Another advantage of using a virtual infrastructure is that infrastructure growth is also more agile.
Thus, there is no longer a need to choose between the big leap from a DBSystem without Exadata infrastructure to an ExaDB-D with dedicated Exadata infrastructure. We now find an intermediate term where we can have a VC ExaDB-D with operations identical to an ExaDB-D, but with a virtual infrastructure.
Exadata Database Service on Dedicated Infrastructure on Exascale Infrastructure
The ExaDB-XS service leverages Exascale capabilities in terms of its ability to work with a single large storage pool in cell for different clients and virtual clusters of the physical infrastructure. Thus, when we require more disk space from the cells, the space is unlocked for us immediately; it is simply an online change in the profile of the vault that has been associated with us.
Focusing on resources, this ExaDB-XS service without dedicated hardware has a minimum shape of 2 virtual machines per cluster, each with a minimum of 8 ECPUs and 22 GB of memory. ECPUs are units familiar to those who have already worked with autonomous databases, where 4 ECPUs essentially equal 1 core. To scale vertically, the service allows increasing in multiples of 4 ECPUs. In addition, 2.75GB of RAM is allocated per additional ECPU. Similarly to what happens with autonomous databases, CPU and memory go hand in hand in this service.
Regarding the space in Exadata cells (Exascale space), the initial minimum is 300GB. Moreover, they give you more space in flash cache proportionally to the GB of space you reserve. Just as with space, the amount of flash cache accessible to the service is changed immediately and online.
While it is very easy to calculate the infrastructure in terms of ECPUs and memory – since there is a fixed relationship between the two, and we know the equivalences of the ECPUs – the same is not true with the IOPS/throughput of storage. Oracle tells us that the amount of flash cache assigned for object caching is proportional to the space in the cell we have reserved, but they do not give us a table of IOPS/throughput. This leads us to scratch our heads a bit more to be able to calculate the IOPS/throughput that our environment will have, since obviously the flash cache will play a very important role in the QOS of our IO. One way to do this is to obtain the IOPS/throughput that a complete system with n TB of net space has, and make a linear rule to obtain the proportionate IOPS to a lower net occupancy size.
Based on the above, although the system can reach figures of many millions of IOPS, our ExaDB-XS system will have the IOPS assigned based on the chosen space. This can be a problem for environments where databases are small in size, yet require a substantial amount of IOPS – something not at all infrequent. Because of this, an alternative way to increase the quality of IO in ExaDB-XS – beyond assigning more space – is to expressly add additional flash cache space to the service in addition to the flash cache space that corresponds to us for occupied space. This additional space in flash cache is charged separately.
Two additional points that you will want to keep in mind if you are interested in the service are:
- Although the minimum space in the cell is 300GB, 50GB will be deducted to create an ACFS mount point to store software images. Therefore, from the net space you choose, always subtract 50GB.
- The default service limit for the service is 2TB. This does not mean that you cannot have larger databases, but it will be necessary to request an increase in the “service limit.” As in other cases, this allows Oracle to verify that the necessary resources exist, and if they do not, to add them before validating the increase in the service limit. In most cases, this request may take 1 day, with available resources. If you request many TB, it is possible that they will have to increase the resources in the infrastructure first.
If you need further details about the service, you can check the official ExaDB-XS documentation here.
Virtual infrastructure vs Dedicated Infrastructure
A quick summary of the service: There is a fixed infrastructure cost composed of the number of virtual machines in the cluster + ECPUs enabled in the infrastructure (not necessarily active) + GB available in the local filesystem for virtual machines – storage that is presented remotely + GB of space in Exascale storage + optional additional GB of Flash cache. Then, a variable cost of ECPU consumption, depending on how many ECPUs we have enabled and the time they are enabled.
Finally, If you are wondering whether it makes sense to migrate all databases from ExaDB-D to ExaDB-XS, the answer is “not always.” The ExaDB-XS service is more interesting with small or medium installations. The ExaDB-D service continues to be more interesting for medium-large installations. Oracle has a public website here where you can do sizing exercises to see what type of installation might be more interesting for each case.
Wrapping up
Exascale is transformative software in the history of Oracle, and it will eventually replace ASM not only in ExaDB-XS but in other Exadata services in the cloud, on-premises, and perhaps in multicloud. It is the piece we needed to make the most of our Exadata space, avoiding fragmentation and exposing us to making compromise decisions in the distribution of space that tomorrow will force us to carry out rebalances, or even, to rebuild virtual clusters. It is also the piece that allows us to achieve granularity of redundancy by file type using templates, control space consumption at the storage level, and integrate IORM QOS with the same extent manager. And it is the piece that allows us to create a read-write clone of a 200TB database immediately, without duplicating space and with all the SMART SCAN capabilities of Exadata, without changing a comma of the syntax we were using in multitenant.
In the next articles, we will describe the new multitenant architectures that Exascale technology enables. See you then!
Oracle and Me 