Tenant resource management

OceanBase Database is a multi-tenant database system. A cluster can contain multiple tenants, and each tenant provides independent database services. OceanBase Database manages the available resources of tenants based on the following concepts: resource unit configuration, resource pool, and resource unit.

Create tenant resources

Before you create a tenant, you must specify the resource unit configuration and resource application scope of the tenant. To create a tenant, perform the following steps:

• Create a resource unit configuration

• Create a resource pool

• Create a tenant

Create a resource unit configuration

The resource unit configuration describes the specifications of each resource unit in the resource pool, such as the available CPU cores, memory, storage space, and input/output operations per second (IOPS). You can modify the resource unit configuration to dynamically adjust the specifications of resource units. The resource unit configuration specifies the service capabilities rather than the real-time load of each resource unit. A sample statement for creating a resource unit configuration is as follows:

obclient> CREATE RESOURCE UNIT uc1 MAX_CPU 5, MIN_CPU 4, MEMORY_SIZE '36G', MAX_IOPS 128000, MIN_IOPS 128000, LOG_DISK_SIZE '2T' ;

Required parameters in the CREATE RESOURCE UNIT statement include the following ones:

• MAX_CPU

• MEMORY_SIZE

Take note of the following description about the optional parameters MIN_CPU, MAX_IOPS, MIN_IOPS, and LOG_DISK_SIZE:

• By default, the value of MIN_CPU equals to that of MAX_CPU.

• By default, the value of MIN_IOPS equals to that of MAX_IOPS.

• By default, the value of LOG_DISK_SIZE is three times of the memory size, and is 2 GB at the minimum.

• The minimum values of MAX_IOPS and MIN_IOPS are both 1024, and the value of MAX_IOPS must be greater than or equal to that of MIN_IOPS.

• If the values of MIN_IOPS and MAX_IOPS are not specified,

  • the values of MIN_IOPS and MAX_IOPS are automatically generated based on the value of MIN_CPU. One CPU core corresponds to 10,000 IOPS. In other words, MAX_IOPS = MIN_IOPS = MIN_CPU * 10000.

  • If IOPS_WEIGHT is not specified, IOPS_WEIGHT = MIN_CPU. If IOPS_WEIGHT is specified, the value specified for IOPS_WEIGHT prevails.

• If only MAX_IOPS is specified,

  • the value of MAX_IOPS is used for MIN_IOPS, and vice versa.

  • If IOPS_WEIGHT is not specified, the default value 0 is used.

Here, MIN_CPU indicates the minimum CPU resource that can be provided by a resource unit that uses the resource unit configuration.

Resource configuration of a meta tenant

A meta tenant is not configured with independent resource units. Tenant resource management does not involve the meta tenant. By default, the system reserves resources for the meta tenant when a user tenant is created. These resources are automatically deducted from the resources of the user tenant. The resources of a meta tenant, including CPU, MEMORY, IOPS, and LOG_DISK_SIZE, use default settings and cannot be specified by users.

Take note of the following items:

• CPU resources: A meta tenant shares CPU resources with the corresponding user tenant. The minimum specification available on ApsaraDB for OceanBase is 1C2G. Therefore, the minimum CPU specification is one core. The CPU resource specification of the meta tenant displayed in the GV$OB_UNITS view is NULL, which indicates that the meta tenant share the CPU resources with the user tenant.

• Memory resources: Memory resource sharing is not allowed. Memory resources of the meta tenant are isolated from those of the user tenant. By default, the meta tenant occupies 10% of the overall tenant memory specification. To ensure the normal operation of the meta tenant, the meta tenant must have at least 512 MB of memory. The memory specification of the user tenant is the overall tenant memory specification minus the memory specification of the meta tenant. The minimum overall tenant memory specification is adjusted to 1 GB. Here are some examples:

  1. If the overall tenant memory specification is greater than or equal to 10 GB, the ratio of the memory specification of the meta tenant to that of the user tenant is 1:9.

  2. If the overall tenant memory specification is greater than or equal to 2 GB and smaller than 10 GB, the memory size of the meta tenant is fixedly 1 GB, and the remaining memory is allocated to the user tenant.

  3. If the overall tenant memory specification is less than 2 GB, the memory size of the meta tenant is fixedly 512 MB, and the remaining memory is allocated to the user tenant.

  4. The minimum overall tenant memory specification is 1 GB. In this case, the meta tenant and the user tenant each occupy 512 MB of memory.

• Log disk resources: You can leave the log disk resource specification unspecified. By default, the log disk size is three times the memory size. The minimum log disk size is 2 GB. Like memory resources, log disk resources cannot be shared between the meta tenant and the user tenant. By default, the meta tenant occupies 10% of the overall tenant disk space. To ensure the normal operation of the meta tenant, the meta tenant must have at least 512 MB of log disk space.

• IOPS resources: The meta tenant shares IOPS resources with the corresponding user tenant. The IOPS resource specification of the meta tenant displayed in the GV$OB_UNITS view is NULL, which indicates that the meta tenant share the IOPS resources with the user tenant.

The following table lists the resource specifications of a user tenant and a meta tenant.

Create a resource pool

A resource pool consists of multiple resource units. You can apply a resource unit configuration to a resource pool to specify physical resources for each resource unit in the resource pool. A sample statement for creating a resource pool is as follows:

obclient> CREATE RESOURCE POOL rp1 UNIT 'uc1', UNIT_NUM 2, ZONE_LIST ('zone1', 'zone2');

The statement creates a resource pool named rp1. You must configure the following fields to create a resource pool:

• The UNIT 'uc1' field specifies that the resource unit configuration of the resource pool is uc1. Each resource unit in the resource pool is configured based on the specifications of uc1.

• The ZONE_LIST ('zone1','zone2') field specifies the application scope of the resource pool and specifies that you want to create the resource units in the resource pool in zone1 and zone2.

• The UNIT_NUM 2 field specifies the number of resource units in the resource pool, indicating that two resource units are to be created in each zone specified by the ZONE_LIST field.

You must deploy each resource on a physical server that can accommodate the resource. A physical server can accommodate only one resource unit in the same resource pool. If zone1 or zone2 contains only one physical server or the resources on the physical server do not meet the specifications of uc1, the sample statement fails to create the resource pool.

Create a tenant

After you create the resource pool, you can create a tenant. A resource pool can belong to only one tenant, but a tenant can have one or more resource pools. A tenant can have only one resource pool in the same zone, which means that the zones of multiple resource pools that belong to the same tenant cannot overlap. The set of all resource units in all resource pools of a tenant describes all physical servers available for the tenant.

Sample statements for creating a tenant are as follows:

obclient> CREATE RESOURCE POOL pool1 UNIT 'uc1', UNIT_NUM 2, ZONE_LIST ('z1', 'z2');
obclient>CREATE RESOURCE POOL pool2 UNIT 'uc1', UNIT_NUM 1, ZONE_LIST ('z3');
obclient>CREATE TENANT tt resource_pool_list=('pool1','pool2');

In the example, two resource pools pool1 and pool2 are created, and then the tenant tt is created. The tenant tt has two resource units in both z1 and z2 and one resource unit in z3. The specifications of each resource unit comply with the resource configuration specified by uc1.

Change tenant resources

To change the resources of a tenant, you can modify one or more of the following fields: UNIT, ZONE_LIST, and UNIT_NUM. You can also perform the SPLIT and MERGE operations on resource pools to change tenant resources.

Modify resource configurations

You can modify the CPU or memory specifications of a resource unit configuration to adjust the resource specifications and service capabilities of a tenant in the resource pool. Sample statements for modifying a resource unit configuration are as follows:

obclient> CREATE RESOURCE UNIT uc1 MAX_CPU 5, MIN_CPU 4, MEMORY_SIZE '32G', MMAX_IOPS 128000, MIN_IOPS 128000, LOG_DISK_SIZE '2T';

obclient> CREATE RESOURCE POOL pool1 UNIT 'uc1', UNIT_NUM 2, ZONE_LIST ('z1', 'z2');

obclient> CREATE RESOURCE POOL pool2 UNIT 'uc1', UNIT_NUM 1, ZONE_LIST ('z3');

obclient> CREATE TENANT tt resource_pool_list=('pool1','pool2');

obclient> ALTER RESOURCE UNIT uc1 MAX_CPU 6,  MEMORY_SIZE '36G';

In the example, the resource unit configuration specified for the resource pools pool1 and pool2 is uc1. The ALTER RESOURCE UNIT uc1 MAX_CPU 6, MEMORY_SIZE '36G' statement changes the value of the MAX_CPU parameter of uc1 to 6 and the value of the MEMORY_SIZE parameter to 36G. Other configurations remain unchanged. You can modify the resource parameters to adjust the resource specifications of the resource pool for a tenant in the corresponding zone, so as to adjust the service capability of the tenant.

Switch resource unit configurations

You can switch the resource unit configuration of a resource pool to adjust the resource specifications of each resource unit in the resource pool. This way, the resource specifications and service capabilities of the tenant in the resource pool are adjusted.

A sample statement for switching the resource unit configuration of a resource pool is as follows:

obclient> ALTER RESOURCE POOL rp1 UNIT 'uc2';

In this example, the original resource unit configuration of the resource pool rp1 is uc1. The statement switches the resource unit configuration of rp1 from uc1 to uc2. Theoretically, OceanBase Database allows you to modify the MIN_CPU, MAX_CPU, and MEMORY_SIZE parameters at the same time. If you want to adjust the service capabilities of a tenant, you can modify or switch the resource unit configuration. This is equivalent to modifying the specifications of resource units for the tenant. You can modify the specifications of a resource in the following scenarios:

• Increase resource specifications

  You can scale out CPU and memory resources for a tenant.

  Example 1:

  obclient> CREATE RESOURCE UNIT u_c0 MAX_CPU 5, MIN_CPU 4, MEMORY_SIZE '36G', MAX_IOPS 128000, MIN_IOPS 128000, LOG_DISK_SIZE '2T';
  
  obclient> CREATE RESOURCE POOL pool1 unit='u_c0', unit_num=3, zone_list=('z1','z2','z3');
  
  obclient> ALTER RESOURCE UNIT u_c0 MAX_CPU 10, MIN_CPU 8, MEMORY_SIZE '72G';
  

  In example 1, resource unit configuration u_c0 and resource pool pool1 are created. Resource pool pool1 uses resource unit configuration u_c0. Then, you can increase the value of the MIN_CPU, MAX_CPU, or MEMORY_SIZE parameter of u_c0. The adjustment is intended to increase the resource specifications of pool1, to upgrade the service capability of the corresponding tenant.

  Example 2:

  obclient> CREATE RESOURCE UNIT u_c0 MAX_CPU 5, MIN_CPU 4, MEMORY_SIZE '36G', MMAX_IOPS 128000, MIN_IOPS 128000, LOG_DISK_SIZE '2T';
  
  obclient> CREATE RESOURCE UNIT u_c1 MAX_CPU 10, MIN_CPU 8, MEMORY_SIZE '72G', MMAX_IOPS 128000, MIN_IOPS 128000, LOG_DISK_SIZE '2T';
  
  obclient> CREATE RESOURCE POOL pool1 unit='u_c0', unit_num=3, zone_list=('z1','z2','z3');
  
  obclient> ALTER RESOURCE POOL pool1 unit='u_c1';
  

  In example 2, two resource unit configurations u_c0 and u_c1 and a resource pool named pool1 are created. pool1 originally uses the resource unit configuration u_c0 and then switches to the resource unit configuration u_c1. The adjustment is intended to increase the resource specifications of pool1, to upgrade the service capability of the corresponding tenant.

• Decrease resource specifications

  You can decrease resource specifications in the same manner that you increase resource specifications.

Modify UNIT_NUM for unallocated resource pools

You can modify the UNIT_NUM parameter of a resource pool to adjust the number of resource units in each zone of the resource pool. This allows you to upgrade or downgrade the service capabilities of the tenant in a specified zone.

Sample statements for modifying the UNIT_NUM parameter of a resource pool are as follows:

obclient> CREATE RESOURCE POOL rp1 UNIT 'uc1', UNIT_NUM 2, ZONE_LIST ('zone1', 'zone2');

obclient> ALTER RESOURCE POOL rp1 UNIT_NUM 3; // Increase the value of the UNIT_NUM parameter.

obclient> ALTER RESOURCE POOL rp1 UNIT_NUM 2; // Decrease the value of the UNIT_NUM parameter.

obclient> ALTER RESOURCE POOL rp1 UNIT_NUM 1 DELETE UNIT = (1001, 1003); // Decrease the value of the UNIT_NUM parameter by deleting the specified resource units.

When you modify the UNIT_NUM parameter, you can increase the value of the UNIT_NUM parameter or decrease the value of the UNIT_NUM parameter. The ALTER RESOURCE POOL rp1 UNIT_NUM 3 statement increases the value of the UNIT_NUM parameter. The ALTER RESOURCE POOL rp1 UNIT_NUM 2 and ALTER RESOURCE POOL rp1 UNIT_NUM 1 DELETE UNIT = (1001, 1003) statements decrease the value of the UNIT_NUM parameter.

Modify UNIT_NUM for tenant resource pools

You can modify the UNIT_NUM parameter of a resource pool after it is assigned to a tenant. However, in this case, you can only increase the value. You can modify resource pools by tenant only. The modification of a resource pool succeeds only when all resource pools are modified. Sample statements for modifying the UNIT_NUM parameter of a tenant resource pool are as follows:

obclient> CREATE RESOURCE POOL pool1 UNIT 'uc1', UNIT_NUM 2, ZONE_LIST ('zone1', 'zone2');

obclient> CREATE RESOURCE POOL pool2 UNIT 'uc1', UNIT_NUM 2, ZONE_LIST ('zone3');

obclient> CREATE TENANT tt resource_pool_list=('pool1','pool2');

obclient> ALTER RESOURCE TENANT tt UNIT_NUM = 3;// Increase the value of the UNIT_NUM parameter.

Modify the ZONE_LIST parameter

You can modify the ZONE_LIST parameter of a resource pool to adjust the scope of zones to which the resource pool applies. This allows you to adjust the scope of zones to which tenant data applies.

Sample statements for modifying the ZONE_LIST parameter of a resource pool are as follows:

obclient> CREATE RESOURCE POOL pool1 UNIT_NUM=3, UNIT='unit_config', ZONE_LIST=('z1','z2','z3');

obclient> CREATE RESOURCE POOL pool2 UNIT_NUM=3, UNIT='unit_config', ZONE_LIST=('z1','z2','z3');

obclient> ALTER RESOURCE POOL pool1 ZONE_LIST=('z1','z2','z3','z4');

obclient> ALTER RESOURCE POOL pool2 ZONE_LIST=('z1','z2');

When you modify the ZONE_LIST parameter, you can expand or narrow the scope of the zones. The ALTER RESOURCE POOL pool1 ZONE_LIST=('z1','z2','z3','z4') statement expands the scope of zones. The ALTER RESOURCE POOL pool2 ZONE_LIST=('z1','z2') statement narrows the scope of zones.

Split a resource pool

You can split a resource pool into multiple resource pools. Sample statements for splitting a resource pool are as follows:

obclient> CREATE RESOURCE POOL pool1 UNIT='uc0', UNIT_NUM=1, ZONE_LIST=('z1','z2','z3');

obclient> ALTER RESOURCE POOL pool1 SPLIT INTO ('pool10','pool11','pool12') ON ('z1','z2','z3');

obclient> ALTER RESOURCE POOL pool10 UNIT='uc1';

obclient> ALTER RESOURCE POOL pool11 UNIT='uc2';

obclient> ALTER RESOURCE POOL pool12 UNIT='uc3';

Merge resource pools

You can merge multiple resource pools into one resource pool. Sample statements for merging multiple resource pools are as follows:

obclient> CREATE RESOURCE POOL pool1 UNIT='uc0', UNIT_NUM=1, ZONE_LIST=('z1');

obclient> CREATE RESOURCE POOL pool2 UNIT='uc0', UNIT_NUM=1, ZONE_LIST=('z2');

obclient> CREATE RESOURCE POOL pool3 UNIT='uc0', UNIT_NUM=1, ZONE_LIST=('z3');

obclient> ALTER RESOURCE POOL MERGE ('pool1','pool2','pool3') INTO ('pool0');