Deploy Linearly Scalable Sharded Oracle Databases Distributed Across Oracle Cloud, Microsoft Azure, and Amazon Web Services

When you need a database that supports extreme scale-out with complete data isolation distributed across different cloud providers, deploy sharded instances of Oracle Database in a fault-tolerant topology. You can deploy the topology across Oracle Cloud, Microsoft Azure, and Amazon Web Services.

Oracle Sharding enables hyperscale, globally distributed, converged databases. It supports applications that require linear scalability, elasticity, fault isolation and geographic distribution of data for data sovereignty. It does so by distributing chunks of a data set across independent Oracle databases (shards). You can deploy shards in the cloud or on-premises without needing any specialized hardware or software. Shards don't communicate with each other at run time in this shared-nothing architecture, which enables you to deploy shards in one cloud while other shards are in a different cloud or on-premises.

Architecture

The following architecture shows a fault-tolerant, sharded Oracle Database 19c topology. The primary shards are distributed across regions in Oracle Cloud, Microsoft Azure, and Amazon Web Services. For each primary shard, a standby shard is provisioned within the same region.

The architecture has redundant resources in every layer (shard director, catalog, and shards) in each cloud provider, to ensure maximum availability of the sharded database.

The following diagram illustrates this reference architecture.

Description of the illustration sharded-db-oci-azure-aws.png

The architecture has the following components:

• Internet gateway

  The internet gateway allows traffic between the public subnets and the public internet. Each cloud provider is connected to the public internet.

• Shard directors

  A shard director (also called global service manager) is a network listener that enables high performance connection routing to the appropriate database shards based on sharding keys.

  You can specify the number of shard directors required. The shard directors are deployed on individual compute instances in each cloud provider. You can choose the shape of the compute instances to be used for the shard directors.

• Primary and standby shard catalogs

  A shard catalog is a special-purpose Oracle Database instance that supports automated shard deployment, centralized management of a sharded database, and multishard queries.

  This architecture contains a primary-standby pair of catalog databases, each in a single-node database system. You can choose the database shape and available storage capacity for the catalog databases. A primary-standby pair of catalog databases is deployed in each cloud provider.

• Database shards

  Each database shard is a single-node database system. The primary shards are distributed across Oracle Cloud, Microsoft Azure, and Amazon Web Services. Each primary shard has an associated standby shard.

Recommendations

Use the following recommendations as a starting point to deploy Oracle Database shards in Oracle Cloud, Microsoft Azure, and Amazon Web Services. Your requirements might differ from the architecture described here.

• Size and number of shards
  While deploying the stack, you can specify the database shape to be used and the number of shards.

  • Choose an appropriate shape based on your workload requirements. The shape you specify is used for all the shards.

    After deployment, you can change the shape of the individual shards to adapt to changes in the workload. The shard that you change the shape for is stopped and then restarted using the new shape.

  • In general, a large number of small shards provides better overall fault tolerance than a small number of large shards. To scale out the topology or to improve fault tolerance, you can add shards at any time without affecting the availability of the existing shards. When required, you can scale in the sharded database; the last created shard is removed first after moving the data to the other shards.
• Shards availability

  To ensure high availability of the shards, provision standby shards and use Oracle Data Guard for primary-to-standby synchronization and for failover.

• Shard catalog availability

  For high availability of the shard catalog, provision a standby catalog and use Oracle Data Guard for synchronization and failover. Note that the availability of the shard catalog has no impact on the availability of the sharded database. An outage of the shard catalog affects only the ability to perform maintenance operations or multishard queries while failing over to the standby catalog. OLTP transactions continue to be routed to the shards.

• Shard director availability

  For high availability of the shard director layer, deploy multiple shard directors. You can deploy up to five shard directors in a region. Oracle recommends that you deploy at least two shard directors. In Oracle Cloud, Oracle recommends isolating the shard directors in separate availability domains or fault domains.

• Storage

  Choose a storage capacity that's appropriate to your workload. For example, either local storage or a block volume of a specified size is attached to each database shard.

  You can scale up the storage at any time without affecting the availability of the database based on the cloud storage providers capability. For shards located in Oracle Cloud, see the Oracle Cloud Infrastructure Database documentation for more information about storage in Oracle Cloud.

Considerations

• Application design

  Any application that has a well-defined data distribution strategy and accesses data primarily by using a sharding key (such as customer ID, account number, and so on) is suited for sharded databases.

• Scalability

  After deploying the sharded database, you can increase or decrease the number of shards by editing the stack and applying the changes. Depending on the replication factor that you specify while deploying the stack, the standby shards are also scaled.

  You can scale the number of shard directors as well.

• Security

  While deploying the sharded database, specify an SSH public key to enable secure SSH connections to the database servers.

  Use firewalls and proxies, as appropriate, based on your specific use cases and security requirements.

• Network isolation

  To ensure network isolation, the best practice is to deploy the sharded database in a private subnet. Routing and firewall solutions will need to be determined based on your application design and requirements.

Explore More

Review these additional reference architectures and solution playbooks:

• Deploy linearly scalable, fault-tolerant, sharded Oracle databases on Oracle Cloud Infrastructure
• Learn about interconnecting Oracle Cloud with Microsoft Azure

Using Oracle Sharding (Oracle Database 19c documentation)