Oracle Exadata Exascale: Big architecture shift for small workloads

Oracle’s recently announced Exadata Database Service on Exascale (ExaDB-XS) aims to improve performance for database workloads and reduce costs.

The architecture in Exascale, which is Oracle’s multi-tenant architecture that intelligently allocates pools of compute optimised for its databases, is built on the same appliances – X8M, X9M and X10M – Oracle uses on its Exadata Database Service on Dedicated Infrastructure. Exadata dates back a decade and is Oracle’s infrastructure for its relational database.

What’s new is a focus on artificial intelligence (AI) workloads and vector databases, as well as a pay-to-use cost structure.

Since its X8M appliances became available, Oracle has connected servers to storage via RoCE networking, and Oracle’s storage servers are equipped with its XRMEM memory, accessed via RDMA from NVMe drives and HDDs to form three tiers of storage: hot, warm and cold.

That logic has been adapted to a shared architecture, principally by modifying software management of the databases.

“Before this, every tenant had its own dedicated Exadata compute and storage,” said Kodi Umamageswaran, senior vice-president for Exadata and scale-out technologies at Oracle.

“And we had software called Automatic Storage Management (ASM) that was used to distribute storage between databases,” he said. “Now, a common pool of Exascale compute and storage will take charge of thousands of tenants and millions of databases.”

To sum up, a specific Exascale control plane is used to manage VMs and storage.

Traditionally, Oracle represented each hard drive in the OS via a logical unit number (LUN) and managed all logical assets in the form of files, as data in a database, snapshots, redo logs, clones and storage blocks.

But with Oracle ASM, each file type is shared per each group of drives associated with the database, its recovery files, snapshots and extended storage configuration. That serves to ensure redundancy of the data and its separation between discrete storage volumes.

From now, with Exascale, it will be the file type that determines redundancy. Templates allow for configuration of levels of redundancy and the control plane ensures data isn’t stored on the same drive.

Also, files are divided into 8MB “extents”, as Oracle calls them, a size chosen to optimise performance in the multitenant architecture. “These 8MB fragments are sufficiently large to get good sequential performance when we scan contiguous data,” said Umamageswaran. “And sufficiently small to allow distribution of a database across the storage cloud in order to share the I/O load.”

Extents are allocated to storage buckets via a hash code, and a mapping table indicates which disk they are stored on. “All the extents that reside in a bucket are stored in a redundant manner on three disks on three storage servers to protect against storage outages and service interruptions,” said Umamageswaran.

The maximum number of buckets is fixed at 100,000. “It’s sufficient to share the data between thousands of storage servers and small enough for the correspondence table that’s held in cache in client database servers,” he said.