1.2.21.2 Intra-Vault Resource Management Using Exascale Resource Profiles

Intra-vault resource management defines how resources are shared by the Exascale clients (Oracle databases and block store volumes) that use a vault. Within Exascale, intra-vault resource management is governed by resource profiles.

By default, without any resource profiles in the system, every Exascale client has access to all of the resources in their associated vault. Furthermore, I/O resources are shared equally when the system is under load.

To enable more granular I/O resource management and prioritize resource utilization, you can associate each Exascale client with a resource profile. Resource profiles enable consistent resource management across numerous clients by defining resource settings once and applying them to all associated clients. In most deployments, a small number of profiles define a resource hierarchy, and each client is assigned to a single profile.

Each resource profile contains the following resource limits and settings:

  • I/O Bandwidth (IOPS) — For each Exascale media type (HC, EF, and XT), you can define a limit value and a share value. While I/O bandwidth utilization is less than the vault capacity, the limit controls each client. However, when I/O bandwidth utilization reaches capacity, resource allocation across all clients is further governed by the share values.

    The limit value specifies the absolute limit of I/O bandwidth for each client associated with the resource profile. The value represents a fraction of the available I/O bandwidth. If not specified, the default value is 100% of the available I/O bandwidth (effectively unlimited).

    The share value defines the proportional share of I/O bandwidth available to each client associated with the resource profile. Each client’s share is relative to all other client shares. A higher share value implies higher priority. The range of valid share values is 1-100. If not specified, the default share value is 1.

    For example, consider a system with 2 clients, where client A has 2 shares and client B has 1 share, resulting in a total of 3 shares across the system. In this case, client A gets 66.67% of the I/O bandwidth (2 out of 3 shares), and client B gets 33.33% (1 out of 3 shares). Next, consider adding client C with 7 shares. After the addition of client C, there are a total of 10 shares across the system. Now, client A gets 20% of the I/O bandwidth (2 out of 10 shares), which is still twice as much as client B (10%, 1 out of 10 shares), but client C gets 70% of the I/O bandwidth (7 out of 10 shares).

  • Flash Cache and Exadata RDMA Memory (XRMEM) Cache — For each type of cache, you can enable or disable use of the cache by clients associated with the resource profile. Then, for each enabled cache type, you can specify a minimum usage value and maximum size.

    The minimum value guarantees a portion of the cache for each client associated with the resource profile. The value nominally represents a fraction of the cache. However, if the sum of all minimums (across all clients and resource profiles) exceeds 100% of the cache size, then all values are scaled down proportionally to ensure that minimum guarantees can be honored. If not specified, the default minimum value is 0 (no guaranteed minimum).

    The maximum size specifies the absolute limit of cache space available to each client associated with the resource profile. The value represents a fraction of the cache. If not specified, the default value is 100% of the cache size (effectively unlimited).

  • Flash Log — You can enable or disable use of the flash log accelerator for clients associated with the resource profile. If not specified, the default setting enables the use of flash log.

You can define any number of resource profiles, but you can only associate an Exascale client with one resource profile at a time.

You can also create a system-reserved resource profile named $UNASSIGNED. All Exascale clients not explicitly associated with a resource profile are automatically governed by the $UNASSIGNED profile. The $UNASSIGNED resource profile has only two modifiable attributes that define the maximum fractions of flash cache and XRMEM cache space assigned to the profile. All other attributes of the $UNASSIGNED resource profile use the previously described default values.

All Exascale clients governed by the $UNASSIGNED profile share the specified cache resources. The behavior differs from regular resource profiles, where each application of the resource profile defines the resource allocation for one associated client.

If you do not create the $UNASSIGNED resource profile, the system reserves 5% of each cache for unassigned Exascale clients. These clients can also use any remaining unassigned flash cache and XRMEM cache space.

Resource over-provisioning across multiple clients and resource profiles is allowed. For over-provisioned resources, the system automatically adjusts the resource shares to maintain the relative proportions for each client.

For example, consider a system with the following resource profiles:

  • GOLD resource profile:

    • EF IOPS: share=11, limit=51%
    • HC IOPS: share=40, limit=52%
    • XT IOPS: share=3, limit=unlimited
    • Flash Cache: enabled=TRUE, minimum=5%, maximum=10%
    • XRMEM Cache: enabled=TRUE, minimum=4%, maximum=8%
    • Flash Log: enabled=TRUE

  • SILVER resource profile:

    • EF IOPS: share=6, limit=25%
    • HC IOPS: share=20, limit=25%
    • XT IOPS: share=2, limit=unlimited
    • Flash Cache: enabled=TRUE, minimum=3%, maximum=6%
    • XRMEM Cache: enabled=TRUE, minimum=2%, maximum=4%
    • Flash Log: enabled=TRUE

  • BRONZE resource profile:

    • EF IOPS: share=3, limit=9%
    • HC IOPS: share=10, limit=15%
    • XT IOPS: share=1, limit=10%
    • Flash Cache: enabled=TRUE, minimum=2%, maximum=5%
    • XRMEM Cache: enabled=TRUE, minimum=1%, maximum=2%
    • Flash Log: enabled=FALSE

  • $UNASSIGNED resource profile:

    • Flash Cache: maximum=10%
    • XRMEM Cache: maximum=5%

Also, imagine that the system hosts 8 databases, which are associated with the resource profiles as follows:

  • DB1 and DB2 are associated with the GOLD resource profile.
  • DB3 is associated with the SILVER resource profile.
  • DB4 and DB5 are associated with the BRONZE resource profile.
  • DB6, DB7, and DB8 are not explicitly associated with any resource profile. Therefore, they are implicitly associated with the $UNASSIGNED resource profile.

Now consider how the resource profiles are used to manage a specific resource. For example, consider I/O bandwidth on high capacity storage media (HC IOPS):

  • While the resource utilization is less than 100% of the vault capacity, each database is capped using the applicable limit value.

    For example:

    Database Resource Profile HC IOPS Limit
    DB1 GOLD 52%
    DB2 GOLD 52%
    DB3 SILVER 25%
    DB4 BRONZE 15%
    DB5 BRONZE 15%
    DB6 $UNASSIGNED 100% (default value, effectively unlimited)
    DB7 $UNASSIGNED 100% (default value, effectively unlimited)
    DB8 $UNASSIGNED 100% (default value, effectively unlimited)

    If the limits keep utilization within the capacity of the vault, then no further intervention is required.

  • When the resource utilization reaches the capacity of the vault, share-based allocation is used. In this case, each database receives a portion equal to its share value divided by the sum of all shares in the system.

    For example:

    Database Resource Profile HC IOPS Share Value HC IOPS Allocation
    DB1 GOLD 40

    35.52%

    (40 out of 123 shares)
    DB2 GOLD 40

    35.52%

    (40 out of 123 shares)
    DB3 SILVER 20

    16.26%

    (20 out of 123 shares)
    DB4 BRONZE 10

    8.13%

    (10 out of 123 shares)
    DB5 BRONZE 10

    8.13%

    (10 out of 123 shares)
    DB6 $UNASSIGNED 1 (default value)

    0.81%

    (1 out of 123 shares)
    DB7 $UNASSIGNED 1 (default value)

    0.81%

    (1 out of 123 shares)
    DB8 $UNASSIGNED 1 (default value)

    0.81%

    (1 out of 123 shares)

Related Topics

Parent topic: Resource Management