平滑扩缩容应用案例

一些对于 RT 高度敏感的业务，在执行租户的扩缩容时，需要严格限制日志流 Leader 所在的节点执行的负载均衡操作，这些负载均衡操作包括 Transfer 任务、日志流副本的迁移复制、Leader 切主等。此时，可以借助异构 Zone，避免业务高峰期切主和 Leader 副本迁移的发生，使整个扩缩容过程更加平稳。

注意事项

原则上，在执行扩缩容或回滚操作时，仅 UNIT_NUM 数量发生变化的 Zone 会发生迁移复制，其他 Zone 不会出现日志流的迁移复制，只会有本地 Transfer。但如果执行扩缩容操作前，租户为非均衡状态，例如，系统正在做分区均衡，或者前一个扩容任务未完成就发起了新的扩缩容任务，此时系统无法保证其他 Zone 不会迁移日志流。

场景一：通过新增 Zone 进行扩缩容

当租户的 PRIMARY_ZONE 打散，并且不能集中到一个 Zone 时，如果要达到平滑扩缩容，就需要使用 Locality 变更的方式来进行扩缩容，即先新增扩容或者缩容后的 Zone，然后通过 Locality 变更方式，在新增的 Zone 上新增副本，补副本的过程可以保证均衡的完成。

下面以扩容为例。

场景信息

假设当前有一租户 tenant1，其 Locality 为 F@zone1，F@zone2，A，PRIMARY_ZONE 为 zone1,zone2，租户有一资源池 pool，分布在 zone1 和 zone2上，且 UNIT_NUM 为 2（即 UNIT_NUM 配置为 2:2），其用户日志流的分布情况，如下图所示。

现在需要将租户资源池的 UNIT_NUM 扩容为 4:4。

操作步骤

1. 使用 root 用户登录到集群的 sys 租户。

2. 关闭配置项 enable_ls_leader_balance。

   租户级配置项 enable_ls_leader_balance 是日志流 Leader 均衡的开关，在自动负载均衡的总开关 enable_rebalance 开启时，它可以单独控制日志流 Leader 的自动均衡。默认值为 True，表示默认开启日志流 Leader 的自动均衡。

   obclient(root@sys)[(none)]> ALTER SYSTEM SET enable_ls_leader_balance = False TENANT = 'tenant1';
   

3. 增加 2 个 4 节点的 Zone，并为租户在新的 Zone 上添加资源。

   1. 参考 添加 Zone，在集群中分别添加 zone3、zone4。

   2. 参考 添加节点，分别向新增的 zone3、zone4 中各添加 4 个节点。

   3. 在新增的 Zone3、Zone4 上创建与原 Unit 规格相同且 UNIT_NUM 为 4 的资源池 pool2。

      obclient(root@sys)[(none)]> CREATE RESOURCE POOL pool2 UNIT='unit_name', UNIT_NUM = 4, ZONE_LIST=('zone3','zone4');
      

      其中，unit_name 需要替换为实际的 Unit 名。

   4. 修改租户的资源池，将新增加的资源池 pool2 分配给租户。

      obclient(root@sys)[(none)]> ALTER TENANT tenant1 RESOURCE_POOL_LIST =('pool','pool2');
      

      执行成功后，此时，租户在 zone1、zone2、zone3、zone4 上的 UNIT_NUM 分别为 2:2:4:4。

4. 修改租户的 Locality，将新增的 zone3、zone4 添加到 Locality 中。

   将 Locality 从 F@zone1，F@zone2，A 修改为 F@zone1，F@zone2，F@zone3，F@zone4，A，语句如下。

   obclient(root@sys)[(none)]> ALTER TENANT tenant1 LOCALITY="F@zone1，F@zone2，F@zone3，F@zone4，A";
   

   语句执行成功后，系统会在新增的 Unit 上自动补齐日志流副本，并且均匀地打散在每个 Unit 上。此过程新增的均为 Follower 副本，故不会发生切主。

   此时，用户日志流的分布情况如下图所示。

   

5. 修改租户的 PRIMARY_ZONE 为新增的 zone3、zone4，并开启配置项 enable_ls_leader_balance。

   将 PRIMARY_ZONE 从 zone1,zone2 修改为 zone3,zone4，语句如下。

   obclient(root@sys)[(none)]> ALTER TENANT tenant1 PRIMARY_ZONE='zone3,zone4'; 
   

   开启配置项 enable_ls_leader_balance，语句如下：

   obclient(root@sys)[(none)]> ALTER SYSTEM SET enable_ls_leader_balance = True TENANT = 'tenant1';
   

   上述语句均执行成功后，各日志流会自动将 Leader 副本切换到 zone3、zone4 上。仅更改日志流的 PRIMARY_ZONE 时，过程很快，影响范围可控。

6. 再次修改租户的 Locality，删除 Locality 中的 zone1、zone2。

   将 Locality 从 F@zone1，F@zone2，F@zone3，F@zone4，A 修改为 F@zone3，F@zone4，A，语句如下。

   obclient(root@sys)[(none)]> ALTER TENANT tenant1 locality="F@zone3，F@zone4，A";
   

   语句执行成功后，zone1、zone2 中的日志流副本会被删除，zone3、zone4 不受影响。

7. 修改租户的资源池，删除原资源池 pool，仅保留新增的资源池 pool2。

   obclient(root@sys)[(none)]> ALTER TENANT tenant1 RESOURCE_POOL_LIST =('pool2');
   

   原来的资源池 pool 从租户中移除后，原来 2 个节点的 zone1、zone2 也可以删除。

   操作完成后，当前租户下只有 4 个节点（UNIT_NUM 为 4）的 zone3、zone4，扩容完成。

场景二：原地扩缩容

对于一些 PRIMARY_ZONE 集中的租户，可以进行原地扩缩容。原地扩缩容可以保证仅操作 Follower 副本所在的 Zone。

下面以扩容为例。

场景信息

假设当前有一租户 tenant1，其 Locality 为 F@zone1，F@zone2，A，PRIMARY_ZONE 为 zone1，租户有一资源池 pool，分布在 zone1 和 zone2上，且 UNIT_NUM 为 2（即 UNIT_NUM 配置为 2:2），其用户日志流的分布情况，如下图所示。

现在需要将租户资源池的 UNIT_NUM 扩容为 4:4。

操作步骤

1. 使用 root 用户登录到集群的 sys 租户。

2. 将租户的资源池分裂为 zone1 的 pool1 和 zone2 的 pool2。

   obclient(root@sys)[(none)]> ALTER RESOURCE POOL pool SPLIT INTO ('pool1','pool2') ON ('zone1','zone2');
   

   有关分裂资源池的详细操作及说明，参见 合并和分裂资源池。

3. 将分裂出的资源池 pool2 的 UNIT_NUM 修改为 4。

   obclient(root@sys)[(none)]> ALTER RESOURCE POOL pool2 UNIT_NUM = 4;
   

   语句执行成功后，日志流会自动分裂并在 zone2 上打散到 4 个 Unit 上。此时，用户日志流的分布情况如下所示。

   

4. 修改租户的 PRIMARY_ZONE 为 zone2。

   obclient(root@sys)[(none)]> ALTER TENANT tenant1 PRIMARY_ZONE='zone2'; 
   

5. 将分裂出的资源池 pool1 的 UNIT_NUM 修改为 4。

   obclient(root@sys)[(none)]> ALTER RESOURCE POOL pool1 UNIT_NUM = 4;
   

   语句执行成功后，系统内部开始均衡，均衡完成后，扩容完成。用户日志流最终的分布情况如下所示。

   

6. （可选）如果希望 Leader 副本仍然集中在 zone1 上，可以将租户的 PRIMARY_ZONE 再修改回 zone1。

   obclient(root@sys)[(none)]> ALTER TENANT tenant1 PRIMARY_ZONE='zone1';