Cross-zone management of tenant resources

You can adjust the zone distribution of a resource pool to adjust the number of replicas for each data record of a tenant, so as to adjust the data disaster recovery capability and resource management method of the tenant.

You can use the ZONE_LIST parameter of a resource pool to perform the following operations:

• Modify the ZONE_LIST parameter

• Split a resource pool

• Merge resource pools

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.

The following example shows how to modify the ZONE_LIST parameter 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');

If you modify the ZONE_LIST parameter, you can specify a value to expand or narrow the scope of 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.

Expand the scope of zones

You can expand the scope of zones in the following typical scenarios:

• Scenario 1: Increase the number of replicas for a tenant to improve service availability of the tenant.

• Scenario 2: Complete data in the destination zone when data is migrated between zones.

Here are some examples:

• Scenario 1: Increase the number of replicas

  Increase the number of replicas for tenant tt from 3 to 5, and expand the scope of zones from 'z1', 'z2', 'z3' to 'z1','z2','z3','z4','z5'. This improves service availability of the tenant.

  obclient>CREATE RESOURCE POOL r_p0 UNIT 'uc1', UNIT_NUM 1, ZONE_LIST ('z1', 'z2', 'z3');
  obclient>CREATE TENANT tt RESOURCE_POOL_LIST = ('r_p0');
  
  obclient>ALTER RESOURCE POOL r_p0 ZONE_LIST=('z1','z2','z3','z4');
  obclient>ALTER TENANT tt locality="F@z1,F@z2,F@z3,F@z4";// Add data for tenant tt in zone z4.
  
  obclient>ALTER RESOURCE POOL r_p0 ZONE_LIST=('z1','z2','z3','z4','z5');
  obclient> ALTER TENANT tt locality="F@z1,F@z2,F@z3,F@z4,F@z5";// Add data for tenant tt in zone z5.
  

• Scenario 2: Complete data in the destination zone

  Data completion is a sub-operation of data migration. Assume that a tenant wants to migrate data from zone z1 to zone z4. You can execute the following statements to complete data in the destination zone:

  obclient> CREATE RESOURCE POOL r_p0 UNIT 'uc1', UNIT_NUM 1, ZONE_LIST ('z1', 'z2', 'z3');
  obclient> CREATE TENANT tt RESOURCE_POOL_LIST = ('r_p0');
  
  // Complete data in the destination zone.
  obclient> ALTER RESOURCE POOL r_p0 ZONE_LIST=('z1','z2','z3','z4');
  obclient> ALTER TENANT tt locality="F@z1,F@z2,F@z3,F@z4";// Add data for tenant tt in zone z4.
  // Then, you need to delete data from the source zone. For more information, see Narrow the scope of zones.
  

  The preceding operation adds data to zone z4 to complete data in the zone during data migration.

Narrow the scope of zones

You can narrow the scope of zones in the following typical scenarios:

• Scenario 1: Decrease the number of replicas for a tenant to reduce the storage resource usage of the tenant.

• Scenario 2: Delete data from the source zone when data is migrated between zones.

Here are some examples:

• Scenario 1: Decrease the number of replicas

  Decrease the number of replicas for tenant tt from 5 to 3, and narrow the scope of zones from 'z1','z2','z3','z4','z5' to 'z1','z2','z3'. This reduces the storage resource usage of the tenant.

  obclient> CREATE RESOURCE POOL r_p0 UNIT 'uc1', UNIT_NUM 1, ZONE_LIST ('z1','z2','z3','z4','z5');
  obclient> CREATE TENANT tt RESOURCE_POOL_LIST = ('r_p0');
  
  obclient> ALTER TENANT tt locality="F@z1,F@z2,F@z3,F@z4";// Delete data from zone z5 for tenant tt.
  obclient> ALTER RESOURCE POOL r_p0 ZONE_LIST=('z1','z2','z3','z4'); // Delete zone z5 for the resource pool.
  obclient> ALTER TENANT tt locality="F@z1,F@z2,F@z3";// Delete data from zone z4 for tenant tt.
  obclient> ALTER RESOURCE POOL r_p0 ZONE_LIST=('z1','z2','z3'); // Delete zone z4 for the resource pool.
  

• Scenario 2: Delete data from the source zone

  Data deletion is another sub-operation of data migration. Assume that a tenant wants to migrate data from zone z1 to zone z4. You can execute the following statements to delete data from the source zone:

  obclient> CREATE RESOURCE POOL r_p0 UNIT 'uc1', UNIT_NUM 1, ZONE_LIST ('z1', 'z2', 'z3');
  obclient> CREATE TENANT tt RESOURCE_POOL_LIST = ('r_p0');
  
  // Complete data in the destination zone.
  obclient> ALTER RESOURCE POOL r_p0 ZONE_LIST=('z1','z2','z3','z4');
  obclient> ALTER TENANT tt locality="F@z1,F@z2,F@z3,F@z4";// Add data for tenant tt in zone z4.
  
  // Delete data from the source zone.
  obclient> ALTER TENANT tt locality="F@z2,F@z3,F@z4";// Delete data from zone z1 for tenant tt.
  obclient> ALTER RESOURCE POOL r_p0 ZONE_LIST=('z2','z3','z4');
  

  The preceding operations add data to zone z4 and delete data from zone z1 to migrate tenant data from zone z1 to zone z4.

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

Here is a typical scenario: Resource pool pool1 applies to zones z1, z2, and z3, and uses the same resource configuration uc0 in all the zones. However, OBServer configurations in zones z1, z2, and z3 may vary greatly. If the same resource configuration uc0 is used in all the zones, OBServer nodes in each zone may not be fully utilized. In this case, you can split a multi-zone resource pool into multiple single-zone resource pools and configure resources for each single-zone resource pool.

In this example, the multi-zone resource pool pool1 that spans 'z1','z2','z3' is split into three single-zone pools: pool10, pool11, and pool12. The ZONE_LIST parameter of pool10 is set to z1, and pool10 inherits the resource units of pool1 in zone z1. The ZONE_LIST parameter of pool11 is set to z2, and pool11 inherits the resource units of pool1 in zone z2. The ZONE_LIST parameter of pool12 is set to z3, and pool12 inherits the resource units of pool1 in zone z3. After the splitting is completed, pool10, pool11, and pool12 still use resource configuration uc0 of pool1 by default. You can adjust resource configurations of the new resource pools based on resources in each zone.

Merge resource pools

You can merge multiple resource pools into one resource pool. Sample statements for merging 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');

Merging resource pools is a reverse operation of splitting a resource pool. Here is a typical scenario: Resource pool pool1 applies to zone z1 and uses resource configuration uc0. Resource pool pool2 applies to zone z2 and uses resource configuration uc0. Resource pool pool3 applies to zone z3 and uses resource configuration uc0. pool1, pool2, and pool3 use the same resource configuration. Therefore, you can merge them into one resource pool to reduce the management and maintenance costs of the resource pools.

In this example, the three single-zone resource pools pool1, pool2, and pool3 are merged into one multi-zone resource pool pool0.

Take note of the following limitations:

• The resource pools to be merged have the same UNIT_NUM settings.

• The resource pools to be merged must use the same resource configuration.