テナントのスケーリングを行う前に、現在のリソース使用状況とスケーリング計画に基づいてリソース計画を立てることができます。
ユニット数の増加やプライマリゾーンの追加などのテナント拡張シナリオ
ユニット数の増加やプライマリゾーンの追加などのテナント拡張シナリオでは、拡張時に新しいログストリームを作成することでデータの均衡を図る場合があります。新しいログストリームの作成にはより多くのリソースが必要となるため、拡張前にユニットリソースが要件を満たしているかどうか事前に確認する必要があります。
rootユーザーでクラスタのsysテナントにログインします。
obclient -h172.30.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -Aoceanbaseデータベースに移動します。obclient> USE oceanbase;各ユニット上のテナントの論理リソース使用状況を確認します。
obclient [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)を持ち、同時に存在した最大ログストリーム数(MAX_UTILIZATION)は2つ、作成可能な最大ログストリーム数(LIMIT_VALUE)は13個であり、この13個の上限値はテナントメモリ(memory)に基づいて計算されます。2行目の結果から、ユーザーテナント1002は
172.xx.xxx.xxx:2882ノード上で、現在668個のTABLET(CURRENT_UTILIZATION)を持ち、同時に存在した最大TABLET数(MAX_UTILIZATION)は668個、作成可能な最大TABLET数(LIMIT_VALUE)は100000個であり、この100000個の上限値は構成パラメータ値(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値を表し、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 [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 [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数を調整してテナントのスケールダウンを実現する際、テナントが複数のUnitグループを持ち（異なるZone間で同一の UNIT_GROUP_ID を持つUnitは同一のUnitグループに属する）、かつ各Unitグループが比較的空いている場合、どのUnitグループを削除するか決められない場合は、以下の方法で対処できます。
rootユーザーでクラスタのsysテナントにログインします。
obclient -h172.30.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -Aoceanbaseデータベースに移動します。obclient> USE oceanbase;スケールダウン対象のテナントが保有するUnitを確認します。
obclient> SELECT * FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1002;クエリ結果は次のとおりです：
+---------+-----------+--------+------------------+---------------+----------------------------+----------------------------+-------+----------------+----------+---------------------+-----------------------+----------------+----------------+---------+---------+-------------+---------------+---------------------+---------------------+-------------+ | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | CREATE_TIME | MODIFY_TIME | ZONE | SVR_IP | SVR_PORT | MIGRATE_FROM_SVR_IP | MIGRATE_FROM_SVR_PORT | MANUAL_MIGRATE | UNIT_CONFIG_ID | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE | MAX_IOPS | MIN_IOPS | IOPS_WEIGHT | +---------+-----------+--------+------------------+---------------+----------------------------+----------------------------+-------+----------------+----------+---------------------+-----------------------+----------------+----------------+---------+---------+-------------+---------------+---------------------+---------------------+-------------+ | 1016 | 1002 | ACTIVE | 1003 | 1006 | 2024-05-13 11:06:38.569419 | 2024-05-13 14:01:30.069547 | zone1 | xxx.xx.xxx.194 | 2882 | NULL | NULL | NULL | 1002 | 1 | 1 | 5368709120 | 16106127360 | 9223372036854775807 | 9223372036854775807 | 1 | | 1017 | 1002 | ACTIVE | 1003 | 1007 | 2024-05-13 11:06:38.571540 | 2024-05-13 11:06:51.030929 | zone1 | xxx.xx.xxx.198 | 2882 | NULL | NULL | NULL | 1002 | 1 | 1 | 5368709120 | 16106127360 | 9223372036854775807 | 9223372036854775807 | 1 | | 1018 | 1002 | ACTIVE | 1003 | 1006 | 2024-05-13 11:06:38.573614 | 2024-05-13 14:01:30.070603 | zone2 | xxx.xx.xxx.192 | 2882 | NULL | NULL | NULL | 1002 | 1 | 1 | 5368709120 | 16106127360 | 9223372036854775807 | 9223372036854775807 | 1 | | 1019 | 1002 | ACTIVE | 1003 | 1007 | 2024-05-13 11:06:38.575723 | 2024-05-13 11:06:51.030929 | zone2 | xxx.xx.xxx.196 | 2882 | NULL | NULL | NULL | 1002 | 1 | 1 | 5368709120 | 16106127360 | 9223372036854775807 | 9223372036854775807 | 1 | | 1020 | 1002 | ACTIVE | 1003 | 1006 | 2024-05-13 11:06:38.579946 | 2024-05-13 14:01:30.070603 | zone3 | xxx.xx.xxx.204 | 2882 | NULL | NULL | NULL | 1002 | 1 | 1 | 5368709120 | 16106127360 | 9223372036854775807 | 9223372036854775807 | 1 | | 1021 | 1002 | ACTIVE | 1003 | 1007 | 2024-05-13 11:06:38.581002 | 2024-05-13 11:06:51.031986 | zone3 | xxx.xx.xxx.197 | 2882 | NULL | NULL | NULL | 1002 | 1 | 1 | 5368709120 | 16106127360 | 9223372036854775807 | 9223372036854775807 | 1 | +---------+-----------+--------+------------------+---------------+----------------------------+----------------------------+-------+----------------+----------+---------------------+-----------------------+----------------+----------------+---------+---------+-------------+---------------+---------------------+---------------------+-------------+ 6 rows in setクエリ結果によると、スケールダウン対象のテナントの各Zoneには2つのUnitがあります。そのうち、
UNIT_IDが1016、1018、1020のUnitは同一のUnitグループに属し、そのUNIT_GROUP_IDは1006です。UNIT_IDが1017、1019、1021のUnitは別のUnitグループに属し、そのUNIT_GROUP_IDは1007です。以下のコマンドを実行して、テナントの各Unitグループ内の各Unitに必要な最小物理リソースをそれぞれ計算します。
この例では、
UNIT_GROUP_ID = 1006とUNIT_GROUP_ID = 1007の各Unitに必要な最小物理リソースを個別に取得する必要があります。ここで、UNIT_GROUP_ID = 1006に対応するノードはxxx.xx.xxx.194:2882、xxx.xx.xxx.192:2882、xxx.xx.xxx.204:2882であり、UNIT_GROUP_ID = 1007に対応するノードはxxx.xx.xxx.198:2882、xxx.xx.xxx.196:2882、xxx.xx.xxx.197: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に必要な最小物理リソースを順番に取得した後、リソース需要量が比較的少ないUnitグループを選択して削除します。