テナントのスケーリングを実施する前に、テナントの現在のリソース使用状況およびスケーリング計画に基づいてリソース計画を立てることができます。
背景
現在のバージョンでは、OceanBaseデータベースはテナントの同種ゾーンモードと異種ゾーンモードをサポートしています。
同種ゾーンモードでは、テナント内の各ゾーンの
UNIT_NUMが同じである必要があります。異種ゾーンモードでは、テナント内の各ゾーンの
UNIT_NUMは同じでも異なっていても構いませんが、同一テナント内のすべてのゾーンでUNIT_NUMの種類は最大2種類に制限されます。
注意
通常、既存のテナントやアップグレードされたテナントは、デフォルトで同種ゾーンモードに設定されています。異種ゾーンモードを有効にする場合は、テナントレベルの構成パラメータ zone_deploy_mode の値を hetero（異種ゾーンモード）に変更する必要があります。変更後は、homo（同種ゾーンモード）に戻すことはできません。
本記事では、同種ゾーンモードにおけるテナントのリソーススケーリング計画を例に操作手順を説明します。異種ゾーンモードにおけるテナントの操作も同様です。
ユニット数の増加やプライマリゾーンの追加などによるテナント拡張シナリオ
ユニット数の増加やプライマリゾーンの追加などによるテナント拡張シナリオでは、拡張時にデータの均等化のため新しいログストリームを作成する場合があります。新しいログストリームの作成にはより多くのリソースが必要となるため、拡張前にユニットのリソースが要件を満たしているか事前に確認する必要があります。
rootユーザーでクラスタのsysテナントにログインします。
obclient -h172.30.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -Aoceanbaseデータベースに入ります。obclient(root@sys)[(none)]> USE oceanbase;テナントが各ユニット上で使用する論理リソースの状況を確認します。
obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.GV$OB_TENANT_RESOURCE_LIMIT WHERE TENANT_ID=1002;クエリ結果は次のとおりです：
+----------------+----------+-----------+-------+---------------+---------------------+-----------------+----------------+-------------+----------------------+ | SVR_IP | SVR_PORT | TENANT_ID | ZONE | RESOURCE_NAME | CURRENT_UTILIZATION | MAX_UTILIZATION | RESERVED_VALUE | LIMIT_VALUE | EFFECTIVE_LIMIT_TYPE | +----------------+----------+-----------+-------+---------------+---------------------+-----------------+----------------+-------------+----------------------+ | 172.xx.xxx.xxx | 2882 | 1002 | zone1 | ls | 2 | 2 | 0 | 13 | memory | | 172.xx.xxx.xxx | 2882 | 1002 | zone1 | tablet | 668 | 668 | 0 | 100000 | configuration | +----------------+----------+-----------+-------+---------------+---------------------+-----------------+----------------+-------------+----------------------+ 2 rows in set最初の行の結果から、ユーザーテナント1002は
172.xx.xxx.xxx:2882ノード上で、現在2つのログストリーム(CURRENT_UTILIZATION)を持ち、一度に最大2つのログストリーム(MAX_UTILIZATION)を同時に保持したことがあり、最大で13個のログストリーム(LIMIT_VALUE)を作成できます。この13個のログストリームの上限値は、テナントメモリ(memory)に基づいて計算されます。2番目の行の結果から、ユーザーテナント1002は
172.xx.xxx.xxx:2882ノード上で、現在668個のTABLET(CURRENT_UTILIZATION)を持ち、一度に最大668個のTABLET(MAX_UTILIZATION)を同時に保持したことがあり、最大で100000個のTABLET(LIMIT_VALUE)を作成できます。この100000個のTABLETの上限値は、パラメータ値(configuration)に基づいて計算されます。実際の拡張シナリオに基づき、拡張後に必要な論理リソースを計算します。
OceanBaseデータベースでは、テナントのLSとTabletに関連する計算式は以下のとおりです：
ユーザーテナントのすべてのノードで安定状態に達したログストリームの数
ユーザーテナントにブロードキャストログストリームがある場合：
U * P + 2ユーザーテナントにブロードキャストログストリームがない場合：
U * P + 1
任意のログストリームがパーティションを他のログストリームに転送する可能性があるため、同一ノード内のログストリーム間で転送が発生しても新しいログストリームは作成されません。異なるノード間のログストリーム間で転送が発生すると、新しいログストリームが作成されます。転送が発生した場合、ユーザーテナントの最大一時ログストリーム数：
(U * P) * ((U - 1) * P)転送が発生した場合、単一ノード上の最大ログストリーム数：
((U * P) * ((U - 1) * P)) / U + (P + 2)ユーザーテナントが各ノード上で作成できるTablet数の上限
パラメータ値によって制限される上限：
(MEMORY_SIZE/1GB) * _max_tablet_cnt_per_gbテナントメモリによって制限される上限：
(MEMORY_SIZE * _storage_meta_memory_limit_percentage) / 200MB * 20000
上記の式において、
Uは同種ゾーンモードではテナントのUNIT_NUMの値を表し、異種ゾーンモードではテナントの2つの異なるUNIT_NUMの最小公倍数を表します。PはテナントPRIMARY_ZONEの第一優先順位の数を表します。上記の式におけるその他のパラメータの詳細については、テナントとリソース情報の確認を参照してください。上記の計算式に基づき、同種ゾーンモードのテナント1002の
PRIMARY_ZONE第一優先順位の数を1、UNIT_NUMの数を2と仮定し、ブロードキャストログストリームがある場合、拡張後に必要な論理リソースを計算します。今回、テナントのPRIMARY_ZONE第一優先順位の数を3に変更する必要がある場合、そのテナントのすべてのノードで安定状態に達したログストリームの数は8個(2*3 + 2)となります。これらのログストリームで転送が発生した場合、単一ノード上に同時に存在する最大ログストリーム数MAX_UTILIZATIONは14個(((2 * 3) *（2-1）*3)/2 + 3 + 2)に達する可能性があるため、14個のログストリームをサポートできるようにテナントを拡張する必要があります。拡張後に必要な論理リソースを計算した後、ノードの現在の論理リソースの制約要因を考慮して、調整が必要な物理リソースまたはパラメータを確認します。
テナントが各ノード上で作成できる論理リソースは、さまざまな物理リソースやパラメータ値によって制限されるため、ビュー
GV$OB_TENANT_RESOURCE_LIMIT_DETAILを使用して、テナントの論理リソースが具体的にどのような制約を受けているか、および各制約の上限値を確認できます。obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.GV$OB_TENANT_RESOURCE_LIMIT_DETAIL WHERE TENANT_ID=1002;クエリ結果は次のとおりです：
+----------------+----------+-----------+---------------+---------------+---------------------+ | SVR_IP | SVR_PORT | TENANT_ID | RESOURCE_NAME | LIMIT_TYPE | LIMIT_VALUE | +----------------+----------+-----------+---------------+---------------+---------------------+ | 172.xx.xxx.xxx | 2882 | 1002 | ls | configuration | 90 | | 172.xx.xxx.xxx | 2882 | 1002 | ls | memstore | 9223372036854775807 | | 172.xx.xxx.xxx | 2882 | 1002 | ls | memory | 13 | | 172.xx.xxx.xxx | 2882 | 1002 | ls | data_disk | 9223372036854775807 | | 172.xx.xxx.xxx | 2882 | 1002 | ls | clog_disk | 32 | | 172.xx.xxx.xxx | 2882 | 1002 | ls | cpu | 9223372036854775807 | | 172.xx.xxx.xxx | 2882 | 1002 | tablet | configuration | 100000 | | 172.xx.xxx.xxx | 2882 | 1002 | tablet | memstore | 9223372036854775807 | | 172.xx.xxx.xxx | 2882 | 1002 | tablet | memory | 102400 | | 172.xx.xxx.xxx | 2882 | 1002 | tablet | data_disk | 9223372036854775807 | | 172.xx.xxx.xxx | 2882 | 1002 | tablet | clog_disk | 9223372036854775807 | | 172.xx.xxx.xxx | 2882 | 1002 | tablet | cpu | 9223372036854775807 | +----------------+----------+-----------+---------------+---------------+---------------------+ 12 rows in setクエリ結果から、テナント1002は
172.xx.xxx.xxx:2882ノード上で、ログストリームの作成数を制限する要因は、パラメータ(configuration)が90、テナントメモリ(memory)が13、ログディスク(clog_disk)が32であることがわかります。Tabletの作成数を制限する要因は、パラメータ(configuration)が100000、テナントメモリ(memory)が102400であることがわかります。これらの上限値に基づき、調整が必要な物理リソースを特定できます。例えば、上記の例で、単一ノードが最大14個のログストリームをサポートできるようにするには、テナントメモリ(
memory)とログディスク(CLOG_DISK)を調整する必要があります。拡張後に必要な論理リソースに基づき、拡張後の単一ノードに必要な物理リソース量を計算します。
拡張後、単一ノードに必要な最大一時ログストリーム数を14、作成する最大Tablet数を40000と仮定した例は以下のとおりです：
obclient(root@sys)[oceanbase]> CALL DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_LOGIC_RES("LS:14, TABLET:40000");計算結果は次のとおりです：
+------------------------+------------+ | PHYSICAL_RESOURCE_NAME | MIN_VALUE | +------------------------+------------+ | memstore | 0 | | memory | 5553258496 | | data_disk | 0 | | clog_disk | 7516192768 | | cpu | 0 | +------------------------+------------+ 5 rows in set得られた結果に基づき、リソース仕様の調整によるテナントの拡張・縮小を参照して、テナントのリソース仕様を拡大します。
テナントのスケールインシナリオ
テナントのスケールインシナリオについても、前述のスケールアウトシナリオと同様の方法で、業務運用に必要な論理リソースの需要量を見積もった後、DBMS_OB_LIMIT_CALCULATOR システムパッケージの CALCULATE_MINPHY_RES_NEEDED_BY_LOGIC_RES サブプログラムを呼び出して、これらの論理リソースに必要な物理リソース量を計算します。最後に、業務の実際の状況に応じて、適切にテナントのリソース仕様を小さく調整します。
また、同種ゾーンモードのテナントにおいて、Unit Numberを調整してテナントのスケールインを実現する場合、テナントが複数のUnit Groupを持っている場合（ビュー DBA_OB_UNITS では、異なるZone間で同じ UNIT_GROUP_ID を持つUnitは同一のUnit Groupに属します）、かつ各Unit Groupが比較的空いていて、どのUnit Groupを削除するか決められない場合、以下の方法で対処できます。
同様に、異種ゾーンモードのテナントにおいて、テナントの単一リソースプールのUnit Numberを調整してテナントのスケールインを実現する場合、各Unitが比較的空いていて、どのUNIT_LISTを削除するか決められない場合も、以下の方法で対処できます。
rootユーザーでクラスタのsysテナントにログインします。
obclient -h172.30.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -Aoceanbaseデータベースに入ります。obclient(root@sys)[(none)]> USE oceanbase;スケールイン対象のテナントが保有するUnitを確認します。
obclient(root@sys)[oceanbase]> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, SVR_IP, SVR_PORT FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1002;クエリ結果は次のとおりです：
+---------+-----------+--------+------------------+---------------+-------+----------------+----------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE | SVR_IP | SVR_PORT | +---------+-----------+--------+------------------+---------------+-------+----------------+----------+ | 1016 | 1002 | ACTIVE | 1003 | 1006 | zone1 | xxx.xx.xxx.194 | 2882 | | 1017 | 1002 | ACTIVE | 1003 | 1007 | zone1 | xxx.xx.xxx.198 | 2882 | | 1018 | 1002 | ACTIVE | 1003 | 1006 | zone2 | xxx.xx.xxx.192 | 2882 | | 1019 | 1002 | ACTIVE | 1003 | 1007 | zone2 | xxx.xx.xxx.196 | 2882 | | 1020 | 1002 | ACTIVE | 1003 | 1006 | zone3 | xxx.xx.xxx.204 | 2882 | | 1021 | 1002 | ACTIVE | 1003 | 1007 | zone3 | xxx.xx.xxx.197 | 2882 | +---------+-----------+--------+------------------+---------------+-------+----------------+----------+ 6 rows in setクエリ結果によると、スケールイン対象のテナントの各Zoneには2つのUnitがあり、
UNIT_IDはそれぞれ1016、1017、1018、1019、1020、1021です。以下のコマンドを実行し、テナント内の各Unitが必要とする最小物理リソースを個別に計算します。
各Unitが必要とする最小物理リソースを個別に取得する必要があります。例えば、この例では、
UNIT_IDが1018のUnitに対応するノードはxxx.xx.xx.192:2882です。ユーザーテナント1002が
xxx.xx.xx.192:2882ノード上のUnitに必要とする最小物理リソースを取得する例を以下に示します：obclient [oceanbase]> CALL DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_UNIT(TENANT_ID => 1002, SERVER => "xxx.xx.xx.192:2882");実行結果は次のとおりです：
+----------------+----------+-----------+------------------------+------------+ | SVR_IP | SVR_PORT | TENANT_ID | PHYSICAL_RESOURCE_NAME | MIN_VALUE | +----------------+----------+-----------+------------------------+------------+ | xxx.xx.xxx.192 | 2882 | 1002 | memstore | 0 | | xxx.xx.xxx.192 | 2882 | 1002 | memory | 4294967296 | | xxx.xx.xxx.192 | 2882 | 1002 | data_disk | 0 | | xxx.xx.xxx.192 | 2882 | 1002 | clog_disk | 1073741824 | | xxx.xx.xxx.192 | 2882 | 1002 | cpu | 0 | +----------------+----------+-----------+------------------------+------------+ 5 rows in set上記の方法を参考に、すべてのUnitが必要とする最小物理リソースを順次取得した後、同種ゾーンモードのテナントでは、リソース需要量が相対的に少ないUnit Groupを選択して削除します。異種ゾーンモードのテナントでは、リソースプール内でリソース需要量が相対的に少ないUNIT_LISTを選択して削除します。