Resource management for tenants

OceanBase Database is a multi-tenant database system. A cluster can contain multiple independent tenants, each providing its own database services. In OceanBase Database, the available resources for each tenant are managed using three concepts: resource configuration (unit_config), resource pools, and resource units.

Create a tenant

Before you create a tenant, determine the tenant's resource specifications and resource allocation range. The general procedure for creating a tenant is as follows:

• Create resource specifications.

• Create resource pools.

• Create a tenant.

Create a resource specification

Resource specifications describe the configurations of resource pools. The specifications describe the specifications of CPU, memory, storage space, and IOPS for each resource unit in a resource pool. You can modify the resource specifications to dynamically change the specifications of resource units. Take note of the fact that resource specifications specify the service capabilities that can be provided by the corresponding resource units, rather than the actual resource utilization of the resource units. An example statement for creating resource specifications 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' ;

The required parameters for the CREATE RESOURCE UNIT statement are as follows:

• MAX_CPU: the maximum CPU capacity available for a resource unit that uses the specified resource specification.

• MEMORY_SIZE: the memory capacity available for a resource unit that uses the specified resource specification.

The optional parameters for MIN_CPU, MAX_IOPS, MIN_IOPS, and LOG_DISK_SIZE are as follows:

• MIN_CPU: the minimum CPU capacity available for a resource unit that uses the specified resource specification. The default value is equal to MAX_CPU.

• MAX_IOPS and MIN_IOPS: the maximum and minimum IOPS that can be provided by a resource unit that uses the specified resource specification, respectively. The minimum value for both is 1024. The requirement is that MAX_IOPS >= MIN_IOPS.

  • If you do not specify values for MIN_IOPS and MAX_IOPS, the default values are INT64_MAX.

  • If you specify only a value for MAX_IOPS, the value of MIN_IOPS is the same as that of MAX_IOPS. The same applies if you specify only a value for MIN_IOPS and MAX_IOPS is not specified.

• LOG_DISK_SIZE: the size of the log disk. The default value is 3 times the memory size, and the minimum value is 2 G.

Resource specifications of the Meta tenant

The Meta tenant has no independent resource unit and is not managed in the process of managing resource tenant specifications. The system automatically reserves resources for the Meta tenant when it creates a resource tenant. The reserved resources for the Meta tenant are deducted from the resources of the resource tenant. At present, the Meta tenant uses the default configurations and the users cannot specify the resource specifications for the Meta tenant, which include CPU, memory, IOPS, and LOG_DISK_SIZE.

The resource specifications for the Meta tenant are as follows:

• CPU resource: The Meta tenant and the resource tenant share the CPU resources, and no isolation is performed. Considering that the minimum selling specifications in the public cloud are 1C2G, the minimum CPU specifications for the Meta tenant is 1C. The value of the Meta tenant's CPU specifications in the GV$OB_UNITS view is NULL, indicating that it shares the CPU resources with the resource tenant.

• MEMORY resource: The memory resources are not shared by the Meta tenant and the resource tenant. The minimum MEMORY size for the Meta tenant is 512 MB, and no maximum MEMORY size is specified. The total tenant MEMORY size is subtracted by the Meta tenant's MEMORY size to obtain the resource tenant's MEMORY size. The minimum total tenant MEMORY size is 1 G. The following provides a specific example.

  1. If the total tenant size is at least 10 GB, the ratio of the Meta tenant's MEMORY size to the resource tenant's MEMORY size is 1:9.

  2. If the total tenant size is at least 2 GB, the MEMORY size of the Meta tenant is 1 GB. The remaining resources are allocated to the resource tenant.

  3. If the total tenant size is less than 2 GB, the MEMORY size of the Meta tenant is fixed at 512 MB, and the remaining resources are allocated to the resource tenant.

  4. If the total tenant size is at least 1 GB, the MEMORY size of the Meta tenant is 512 MB, and the MEMORY size of the resource tenant is 512 MB.

• LOG_DISK_SIZE resource: You do not need to specify the value of the LOG_DISK_SIZE resource. The default value is three times the memory size, and the minimum value is 2 G. The Log disk resources cannot be shared between the Meta tenant and the resource tenant. The minimum LOG_DISK_SIZE resource of the Meta tenant is 512 MB, and the default value is the tenant's LOG_DISK_SIZE size. If the total tenant LOG_DISK_SIZE size is at least 10%, the Meta tenant occupies 512 MB, and the resource tenant occupies the remaining LOG_DISK_SIZE resources.

• IOPS resource: The Meta tenant and the resource tenant share the IOPS resources, and no isolation is performed. The IOPS specifications of the Meta tenant in the GV$OB_UNITS view are NULL, indicating that the Meta tenant shares the IOPS resources with the resource tenant.

The following table lists the resource specifications of the resource tenant and the Meta tenant.

Create a resource pool

A resource pool is composed of one or more resource units. You can specify the resource specifications of the resource pool to determine the physical resources of each resource unit. An example statement for creating a resource pool is as follows:

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

In the preceding example statement, the CREATE RESOURCE POOL statement creates a resource pool named rp1. The resource pool has three elements: UNIT, ZONE_LIST, and UNIT_NUM. You cannot omit any of the elements.

• UNIT 'uc1' specifies the resource specification uc1 for the resource pool, and each resource unit of the resource pool uses the uc1 resource specification.

• ZONE_LIST ('zone1','zone2') specifies the zones in which the resource pool will create resource units.

• UNIT_NUM 2 specifies the number of resource units in the resource pool. The resource pool will create two resource units in each zone specified by ZONE_LIST.

Each resource unit of the resource pool must be placed on a host that has enough resources to accommodate the resource unit. Moreover, only one resource unit of the same resource pool can be placed on the same host. If the number of hosts on zone1 and zone2 is less than 2 or the resources of a host are less than those of uc1, the previous example statement will fail. Therefore, the resource pool cannot be created.

Create a tenant

After you create a resource pool, you can create a tenant. A resource pool belongs to only one tenant. A tenant can have one or more resource pools. A tenant can have only one resource pool in the same zone. Therefore, the ZONE_LIST of each resource pool of the tenant cannot overlap with that of another resource pool. All the resource units in all resource pools of a tenant collectively describe the physical resources that can be used by the tenant.

An example statement for creating a tenant is 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 2, ZONE_LIST ('z3');
obclient>CREATE TENANT tt resource_pool_list=('pool1','pool2');

In the preceding example statement, first two resource pools named pool1 and pool2 are created. Then, a tenant named tt is created. The tenant tt has two resource units in each zone, z1, z2, and z3. The specifications of each resource unit of the tenant tt are defined by uc1.

Change tenant resources

You can change the resources of a tenant by adjusting the three elements of each resource in the tenant. Specifically, you can separately modify the Unit configuration, ZONE_LIST, and UNIT_NUM of a resource pool to change the resources of a tenant. In addition, you can split or merge a resource pool.

Modify the resource pool configuration

Modifying the resource pool configuration directly adjusts the CPU or memory values of the resource pool, which directly affects the resource specifications and service capabilities of the tenant on that resource pool. Here is an example statement for modifying the resource pool configuration:

obclient> CREATE RESOURCE UNIT uc1 MAX_CPU 5, MIN_CPU 4, MEMORY_SIZE '32G', MAX_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 2, ZONE_LIST ('z3');

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

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

In this example, the resource pool pool1 and pool2 use the resource unit uc1. The statement ALTER RESOURCE UNIT uc1 MAX_CPU 6, MEMORY_SIZE '36G'; adjusts the MAX_CPU of the resource unit uc1 to 6 and the MEMORY_SIZE to 36G, while keeping other configuration options unchanged. By adjusting the various options of the resource pool configuration, you can modify the resource specifications of the tenant's resource pool in the corresponding zone, thereby affecting the tenant's service capabilities.

Switch the resource pool configuration

Switching the resource pool configuration allows you to adjust the resource specifications of each resource unit within the resource pool, thereby adjusting the resource specifications and service capabilities of the tenant on that resource pool.

Here is an example statement for switching the resource pool configuration:

obclient> ALTER RESOURCE POOL rp1 UNIT 'uc2';

Assuming the resource pool rp1 previously used the resource unit uc1, the example statement changes the resource unit of rp1 to uc2. Theoretically, OceanBase Database supports simultaneously modifying the resource specifications MIN_CPU, MAX_CPU, and MEMORY_SIZE. However, typically, both modifying the resource pool configuration and switching the resource pool configuration can adjust the service capabilities of the tenant. At the tenant level, this means adjusting the specifications of the tenant's resource units. The modification of resource specifications typically involves the following two scenarios:

• Increasing resource specifications

  Increasing resource specifications is mainly used in scenarios where the tenant needs to expand its resources. You can expand the resources of the tenant separately for CPU and memory.

  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 the preceding example, a resource unit u_c0 is created, and a resource pool pool1 is created. The resource pool pool1 uses the resource unit u_c0 as its configuration. Then, the MIN_CPU, MAX_CPU, or MEMORY_SIZE of the resource unit u_c0 is increased. This adjustment aims to increase the resource specifications of the resource pool pool1, thereby improving the service capabilities of the corresponding tenant.

  Example 2:

  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 UNIT u_c1 MAX_CPU 10, MIN_CPU 8, MEMORY_SIZE '72G', 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 POOL pool1 unit='u_c1';
  

  In the preceding example, two resource units u_c0 and u_c1 are created. A resource pool pool1 is created, and the resource pool pool1 initially uses the resource unit u_c0 as its configuration. Then, the resource unit of the resource pool pool1 is changed to u_c1. This adjustment aims to increase the resource specifications of the resource pool pool1, thereby improving the service capabilities of the corresponding tenant.

• Decreasing resource specifications

  Based on the examples of increasing resource specifications, the system also supports decreasing resource specifications, using the same methods as increasing resource specifications.

Change the UNIT_NUM

The current version supports both homogeneous zone mode and heterogeneous zone mode for tenants:

• In homogeneous zone mode, the UNIT_NUM of each zone under a tenant must be the same.

• In heterogeneous zone mode, the UNIT_NUM of each zone under a tenant can be different, but a tenant can have at most two different UNIT_NUM values across all zones.

Change the UNIT_NUM in homogeneous zone mode

• Change the UNIT_NUM of an unassigned resource pool

  In homogeneous zone mode, if a resource pool is not assigned to a tenant, you can use the CREATE RESOURCE POOL statement to adjust the UNIT_NUM of the resource pool, thereby changing the number of resource units in each zone of the resource pool.

  Assume the information of an unassigned resource pool is as follows:

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

  Here is an example statement for adjusting the UNIT_NUM of the resource pool:

  obclient> ALTER RESOURCE POOL rp1 UNIT_NUM 3; // Increase UNIT_NUM
  

  obclient> ALTER RESOURCE POOL rp1 UNIT_NUM 2; // Decrease UNIT_NUM
  

  obclient> ALTER RESOURCE POOL rp1 UNIT_NUM 1 DELETE UNIT = (1001, 1003); // Specify resource units to decrease UNIT_NUM
  

  Changing the UNIT_NUM can be divided into two categories: increasing UNIT_NUM and decreasing UNIT_NUM. In the preceding statements, ALTER RESOURCE POOL rp1 UNIT_NUM 3; is used to increase UNIT_NUM, while ALTER RESOURCE POOL rp1 UNIT_NUM 2; and ALTER RESOURCE POOL rp1 UNIT_NUM 1 DELETE UNIT = (1001, 1003); are used to decrease UNIT_NUM.

• Change the UNIT_NUM of a tenant resource pool

  In homogeneous zone mode, after a resource pool is assigned to a tenant, you can also change its UNIT_NUM. However, the change must be applied to all resource pools of the tenant.

  Assume the information of the tenant's resource pools is 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');
  

  Here is an example statement for adjusting the UNIT_NUM of the tenant's resource pools:

  obclient> ALTER RESOURCE TENANT tt UNIT_NUM = 3;// Increase UNIT_NUM
  

  obclient> ALTER RESOURCE TENANT tt UNIT_NUM = 1;// Decrease UNIT_NUM
  

  Note that in heterogeneous zone mode, you cannot decrease the UNIT_NUM by specifying UNIT_GROUP.

  In addition, in heterogeneous zone mode, you can adjust the UNIT_NUM of a single resource pool. Here are the statements:

  obclient> ALTER RESOURCE POOL pool2 UNIT_NUM = 3;// Increase UNIT_NUM
  

  obclient> ALTER RESOURCE POOL pool2 UNIT_NUM = 1;// Decrease UNIT_NUM
  

  obclient> ALTER RESOURCE POOL pool2 UNIT_NUM 1 DELETE UNIT = (1001, 1003); // Specify resource units to decrease UNIT_NUM
  

Change the ZONE_LIST

You can modify the ZONE_LIST of a resource pool to change the scope of the resource pool in the zone dimension, thereby changing the service scope of tenant data in the zone dimension.

The following example shows how to modify the ZONE_LIST of a resource pool:

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');

Changing the ZONE_LIST can be divided into two types: expanding the scope of the resource pool in the zone dimension and narrowing the scope of the resource pool in the zone dimension. The statement ALTER RESOURCE POOL pool1 ZONE_LIST=('z1','z2','z3','z4'); expands the scope of the resource pool in the zone dimension, and the statement ALTER RESOURCE POOL pool2 ZONE_LIST=('z1','z2'); narrows the scope of the resource pool in the zone dimension.

Split a resource pool

You can split a resource pool into multiple resource pools. The basic syntax and example 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. The basic syntax and example 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');