8.3. バケットインデックスのリシャーディングを設定する
ストレージ管理者は、単一サイトおよびマルチサイトデプロイメントでバケットインデックスのリシャーディングを設定して、パフォーマンスを向上させることができます。
手動でオフラインで、または動的にオンラインで、バケットインデックスをリシャーディングできます。
8.3.1. バケットインデックスのリシャーディング
Ceph Object Gateway は、デフォルトで .rgw.buckets.index
パラメーターに設定されているインデックスプールにバケットインデックスデータを保存します。クライアントが、バケットあたりの最大オブジェクト数のクォータを設定せずに 1 つのバケットに多数のオブジェクトを配置すると、インデックスプールによってパフォーマンスが大幅に低下する可能性があります。
- バケットインデックスのリシャーディングは、バケットごとに多数のオブジェクトを追加する場合のパフォーマンスのボトルネックを防ぎます。
- 新しいバケットのバケットインデックスのリシャーディングを設定したり、既存のバケットのバケットインデックスを変更したりできます。
- 計算されたシャード数に最も近い素数としてシャード数を取得する必要があります。素数であるバケットインデックスシャードは、シャード間で均等に分散されたバケットインデックスエントリーでより適切に機能する傾向があります。
バケットインデックスは、手動または動的にリシャーディングできます。
バケットインデックスを動的にリシャーディングするプロセス中に、すべての Ceph Object Gateway バケットが定期的にチェックされ、リシャーディングが必要なバケットが検出されます。バケットが
rgw_max_objs_per_shard
パラメーターで指定された値よりも大きい場合、Ceph Object Gateway はバックグラウンドでバケットを動的に再シャードします。rgw_max_objs_per_shard
のデフォルト値は、シャードごとに 100k オブジェクトです。バケットインデックスのリシャーディングは、ゾーンまたはゾーングループを変更しなくても、アップグレードされた単一サイト設定で期待どおりに動的に機能します。シングルサイト設定は、以下のいずれかです。- レルムのないデフォルトのゾーン設定。
- レルムが 1 つ以上あるデフォルト以外の設定。
- 複数レルムのシングルサイト設定。
8.3.2. バケットインデックスの回復
bucket_index_max_shards = 0
で作成されたバケットを再シャーディングすると、バケットのメタデータが削除されます。ただし、影響を受けたバケットを回復することにより、バケットインデックスを復元できます。
/usr/bin/rgw-restore-bucket-index
ツールは、/tmp
ディレクトリーに一時ファイルを作成します。これらの一時ファイルは、以前のバケットのバケットオブジェクト数に基づいてスペースを消費します。1000 万を超えるオブジェクトを含む以前のバケットでは、/tmp
ディレクトリーに 4 GB を超える空き領域が必要です。/tmp
のストレージ容量が不足すると、ツールは次のメッセージを表示して失敗します。
ln: failed to access '/tmp/rgwrbi-object-list.4053207': No such file or directory
一時オブジェクトが削除されました。
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- Ceph Object Gateway が少なくとも 2 つのサイトにインストールされている。
-
jq
パッケージがインストールされている。
手順
バケットインデックスのリカバリーを実行するには、次の 2 つの手順のいずれかを実行します。
-
radosgw-admin object reindex --bucket BUCKET_NAME --object OBJECT_NAME
コマンドを実行します。 スクリプト
/usr/bin/rgw-restore-bucket-index -b BUCKET_NAME -p DATA_POOL_NAME
を実行します。例
[root@host01 ceph]# /usr/bin/rgw-restore-bucket-index -b bucket-large-1 -p local-zone.rgw.buckets.data marker is d8a347a4-99b6-4312-a5c1-75b83904b3d4.41610.2 bucket_id is d8a347a4-99b6-4312-a5c1-75b83904b3d4.41610.2 number of bucket index shards is 5 data pool is local-zone.rgw.buckets.data NOTICE: This tool is currently considered EXPERIMENTAL. The list of objects that we will attempt to restore can be found in "/tmp/rgwrbi-object-list.49946". Please review the object names in that file (either below or in another window/terminal) before proceeding. Type "proceed!" to proceed, "view" to view object list, or "q" to quit: view Viewing... Type "proceed!" to proceed, "view" to view object list, or "q" to quit: proceed! Proceeding... NOTICE: Bucket stats are currently incorrect. They can be restored with the following command after 2 minutes: radosgw-admin bucket list --bucket=bucket-large-1 --allow-unordered --max-entries=1073741824 Would you like to take the time to recalculate bucket stats now? [yes/no] yes Done real 2m16.530s user 0m1.082s sys 0m0.870s
-
このツールは、バージョン管理されたバケットに対しては機能しません。
[root@host01 ~]# time rgw-restore-bucket-index --proceed serp-bu-ver-1 default.rgw.buckets.data NOTICE: This tool is currently considered EXPERIMENTAL. marker is e871fb65-b87f-4c16-a7c3-064b66feb1c4.25076.5 bucket_id is e871fb65-b87f-4c16-a7c3-064b66feb1c4.25076.5 Error: this bucket appears to be versioned, and this tool cannot work with versioned buckets.
-
ツールの範囲はシングルサイトのみに限定され、マルチサイトではありません。つまり、サイト 1 で
rgw-restore-bucket-index
ツールを実行しても、サイト 2 のオブジェクトは復元されません。また、その逆も同様です。マルチサイトでは、回復ツールとオブジェクトの再インデックスコマンドはバケットの両方のサイトで実行する必要があります。
8.3.3. バケットインデックスのリシャーディングの制限
注意して、以下の制限を使用してください。お使いのハードウェアの選択には影響があるため、この要件を Red Hat アカウントチームと常に相談してください。
- リシャーディングが必要になる前の 1 つのバケット内のオブジェクトの最大数: バケットインデックスシャードごとに最大 102,400 個のオブジェクトを使用します。リシャーディングを最大限に活用して並列処理を最大化するには、Ceph Object Gateway バケットインデックスプールに十分な数の OSD を提供します。この並列化は、Ceph Object Gateway インスタンスの数に応じてスケーリングされ、順序が適切なインデックスシャードの列挙を数列に置き換えます。デフォルトのロックタイムアウトが 60 秒から 90 秒に延長されました。
- シャード化の使用時の最大オブジェクト数: 以前のテストに基づき、現在サポートされているバケットインデックスシャードの数は 65521 です。Red Hat の品質保証は、バケットシャーディングで完全なスケーラビリティーテストを実施していません。
- シャード化の使用時の最大オブジェクト数: 以前のテストに基づき、現在サポートされているバケットインデックスシャードの数は 65,521 です。
他のゾーンが追いつく前にバケットを 3 回再シャーディングできます。古い世代が同期されるまで、再シャーディングは推奨されません。以前の再シャーディングからの約 4 世代のバケットがサポートされます。制限に達すると、古いログ世代の少なくとも 1 つが完全にトリミングされるまで、動的再シャーディングはバケットを再度再シャーディングしません。コマンド
radosgw-admin bucket reshard
を使用すると、以下のエラーが発生します。Bucket _BUCKET_NAME_ already has too many log generations (4) from previous reshards that peer zones haven't finished syncing. Resharding is not recommended until the old generations sync, but you can force a reshard with `--yes-i-really-mean-it`.
8.3.4. シンプルなデプロイでのバケットインデックスのリシャーディングの設定
すべての新規バケットでバケットインデックスリシャードを有効にし、設定するには、rgw_override_bucket_index_max_shards
パラメーターを使用します。
パラメーターは以下のいずれかの値に設定できます。
-
0
を指定すると、バケットインデックスのシャーディングが無効になります。これがデフォルト値です。 -
0
より大きい値を有効にすると、バケットシャード化が有効になり、シャードの最大数が設定されます。
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- Ceph Object Gateway が少なくとも 2 つのサイトにインストールされている。
手順
推奨されるシャード数を計算します。
number of objects expected in a bucket / 100,000
注記現在サポートされているバケットインデックスシャードの最大数は 65,521 です。
rgw_override_bucket_index_max_shards
オプションを適宜設定します。構文
ceph config set client.rgw rgw_override_bucket_index_max_shards VALUE
VALUE を、計算されたシャードの推奨数に置き換えます。
例
[ceph: root@host01 /]# ceph config set client.rgw rgw_override_bucket_index_max_shards 12
-
Ceph Object Gateway のすべてのインスタンスに対してバケットインデックスのリシャーディングを設定するには、
rgw_override_bucket_index_max_shards
パラメーターをglobal
オプションで設定します。 -
Ceph Object Gateway の特定のインスタンスに対してのみバケットインデックスのリシャーディングを設定するには、インスタンスの下に
rgw_override_bucket_index_max_shards
パラメーターを追加します。
-
Ceph Object Gateway のすべてのインスタンスに対してバケットインデックスのリシャーディングを設定するには、
クラスター内のすべてのノードで Ceph Object Gateways を再起動して、有効にします。
構文
ceph orch restart SERVICE_TYPE
例
[ceph: root#host01 /]# ceph orch restart rgw
関連情報
- バケットインデックスを動的にリシャーディング を参照してください。
- バケットインデックスを手動でリシャーディング を参照してください。
8.3.5. マルチサイトデプロイメントでのバケットインデックスのリシャーディングの設定
マルチサイトデプロイメントでは、フェイルオーバーを管理するために、ゾーンごとに異なる index_pool
設定を使用できます。1 つのゾーングループ内のゾーンに対して一貫したシャード数を設定するには、そのゾーングループの設定で bucket_index_max_shards
パラメーターを設定します。bucket_index_max_shards
パラメーターのデフォルト値は 11 です。
パラメーターは以下のいずれかの値に設定できます。
-
バケットインデックスシャード化を無効にする場合は
0
。 -
0
より大きい値を有効にすると、バケットシャード化が有効になり、シャードの最大数が設定されます。
SSD ベースの OSD の CRUSH ルールセットにインデックスプール (該当する場合は各ゾーン) をマッピングすることも、バケットインデックスのパフォーマンスに役立つ可能性があります。詳細は、パフォーマンスドメインの確立 セクションを参照してください。
マルチサイトデプロイメントで同期の問題を回避するには、バケットに 3 世代を超えるギャップがないようにする必要があります。
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- Ceph Object Gateway が少なくとも 2 つのサイトにインストールされている。
手順
推奨されるシャード数を計算します。
number of objects expected in a bucket / 100,000
注記現在サポートされているバケットインデックスシャードの最大数は 65,521 です。
ゾーングループ設定を
zonegroup.json
ファイルにデプロイメントします。例
[ceph: root@host01 /]# radosgw-admin zonegroup get > zonegroup.json
zonegroup.json
ファイルで、名前付きゾーンごとにbucket_index_max_shards
パラメーターを設定します。構文
bucket_index_max_shards = VALUE
VALUE を、計算されたシャードの推奨数に置き換えます。
例
bucket_index_max_shards = 12
ゾーングループをリセットします。
例
[ceph: root@host01 /]# radosgw-admin zonegroup set < zonegroup.json
期間を更新します。
例
[ceph: root@host01 /]# radosgw-admin period update --commit
リシャーディングが完了したかどうかを確認します。
構文
radosgw-admin reshard status --bucket BUCKET_NAME
例
[ceph: root@host01 /]# radosgw-admin reshard status --bucket data
検証
ストレージクラスターの同期ステータスを確認します。
例
[ceph: root@host01 /]# radosgw-admin sync status
8.3.6. バケットインデックスの動的リシャーディング
バケットをリシャーディングキューに追加することで、バケットインデックスを動的にリシャーディングできます。リシャーディングされる予定です。リシャードスレッドはバックグラウンドで実行され、スケジュールされたリシャーディングを一度に 1 つずつ実行します。
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- Ceph Object Gateway が少なくとも 2 つのサイトにインストールされている。
手順
rgw_dynamic_resharding
パラメーターをtrue
に設定します。例
[ceph: root@host01 /]# radosgw-admin period get
オプション: 次のコマンドを使用して、Ceph 設定をカスタマイズします。
構文
ceph config set client.rgw OPTION VALUE
OPTION を次のオプションに置き換えます。
-
rgw_reshard_num_logs
: 再シャードログのシャードの数。デフォルト値は16
です。 -
rgw_reshard_bucket_lock_duration
: リシャード中にバケットのロックの期間。デフォルト値は360
秒です。 -
rgw_dynamic_resharding
: 動的リシャードを有効または無効にします。デフォルト値はtrue
です。 -
rgw_max_objs_per_shard
: シャードごとのオブジェクトの最大数。デフォルト値は、シャードごとに100000
オブジェクトです。 -
rgw_reshard_thread_interval
: 再シャード処理のラウンド間の最大時間。デフォルト値は600
秒です。
例
[ceph: root@host01 /]# ceph config set client.rgw rgw_reshard_num_logs 23
-
リシャーディングキューにバケットを追加します。
構文
radosgw-admin reshard add --bucket BUCKET --num-shards NUMBER
例
[ceph: root@host01 /]# radosgw-admin reshard add --bucket data --num-shards 10
リシャーディングキューを一覧表示します。
例
[ceph: root@host01 /]# radosgw-admin reshard list
バケットログの世代とシャードを確認します。
例
[ceph: root@host01 /]# radosgw-admin bucket layout --bucket data { "layout": { "resharding": "None", "current_index": { "gen": 1, "layout": { "type": "Normal", "normal": { "num_shards": 23, "hash_type": "Mod" } } }, "logs": [ { "gen": 0, "layout": { "type": "InIndex", "in_index": { "gen": 0, "layout": { "num_shards": 11, "hash_type": "Mod" } } } }, { "gen": 1, "layout": { "type": "InIndex", "in_index": { "gen": 1, "layout": { "num_shards": 23, "hash_type": "Mod" } } } } ] } }
バケットの再シャーディングステータスを確認するには、以下のコマンドを実行します。
構文
radosgw-admin reshard status --bucket BUCKET
例
[ceph: root@host01 /]# radosgw-admin reshard status --bucket data
リシャーディングキューのエントリーをすぐに処理します。
[ceph: root@host01 /]# radosgw-admin reshard process
保留中のバケットのリシャーディングをキャンセルします:
警告保留中 の再シャード操作のみをキャンセルできます。継続中 の再シャード操作をキャンセルしないでください。
構文
radosgw-admin reshard cancel --bucket BUCKET
例
[ceph: root@host01 /]# radosgw-admin reshard cancel --bucket data
検証
バケットの再シャーディングステータスを確認するには、以下のコマンドを実行します。
構文
radosgw-admin reshard status --bucket BUCKET
例
[ceph: root@host01 /]# radosgw-admin reshard status --bucket data
関連情報
- 古いバケットエントリーを削除するには、リシャーディング後にバケットエントリーの古いインスタンスをクリーニングする セクションを参照してください。
- バケットインデックスを手動でリシャーディング 参照してください。
- シンプルなデプロイでのバケットインデックスのリシャーディングの設定 を参照してください。
8.3.7. マルチサイト設定でバケットインデックスを動的にリシャーディングする
Red Hat Ceph Storage 6.0 は、マルチサイト設定でのバケットインデックスの動的再シャーディングをサポートします。この機能により、オブジェクトのレプリケーションを中断せずに、マルチサイト設定でバケットを再シャーディングできます。rgw_dynamic_resharding
を有効にすると、各ゾーンで個別に実行され、ゾーンで同じバケットに異なるシャード数が選択される可能性があります。
従う必要があるこれらの手順は、既存の Red Hat Ceph Storage クラスター 専用 です。ストレージクラスターのアップグレード後に、既存のゾーンおよびゾーングループで resharding
機能を手動で有効にする必要があります。
Red Hat Ceph Storage 6.0 の新規インストールでは、ゾーンおよびゾーングループの resharding
機能がデフォルトでサポートされ、有効にされます。
他のゾーンが追い付く前に、バケットを 3 回再シャーディングできます。詳細は、バケットインデックスのリシャーディングの制限 を参照してください。
バケットが作成され、動的にリシャーディングするためのオブジェクト数のしきい値を超えてアップロードされた場合、リシャーディングプロセスを開始するには、引き続き古いバケットに I/O を書き込む必要があります。
前提条件
- 両方のサイトの Red Hat Ceph Storage クラスターは、最新バージョンにアップグレードされている。
- 両方のサイトで有効になっているすべての Ceph Object Gateway デーモンは、最新バージョンにアップグレードされている。
- すべてのノードへの root レベルのアクセス。
手順
ゾーングループで
resharding
が有効になっているかどうかを確認します。例
[ceph: root@host01 /]# radosgw-admin sync status
ゾーングループでの再シャーディング用に
zonegroup features enabled
が有効化されていない場合は、手順を続行してください。Ceph Object Gateway がインストールされているマルチサイト設定のすべてのゾーングループで、
resharding
機能を有効にします。構文
radosgw-admin zonegroup modify --rgw-zonegroup=ZONEGROUP_NAME --enable-feature=resharding
例
[ceph: root@host01 /]# radosgw-admin zonegroup modify --rgw-zonegroup=us --enable-feature=resharding
期間を更新してコミットします。
例
[ceph: root@host01 /]# radosgw-admin period update --commit
Ceph Object Gateway がインストールされているマルチサイト設定のすべてのゾーンで、
resharding
機能を有効にします。構文
radosgw-admin zone modify --rgw-zone=ZONE_NAME --enable-feature=resharding
例
[ceph: root@host01 /]# radosgw-admin zone modify --rgw-zone=us-east --enable-feature=resharding
期間を更新してコミットします。
例
[ceph: root@host01 /]# radosgw-admin period update --commit
ゾーンおよびゾーングループで、
resharding
機能が有効化されていることを確認します。各ゾーンがsupported_features
をリスト表示し、ゾーングループでenabled_features
がリストされていることを確認できます。例
[ceph: root@host01 /]# radosgw-admin period get "zones": [ { "id": "505b48db-6de0-45d5-8208-8c98f7b1278d", "name": "us_east", "endpoints": [ "http://10.0.208.11:8080" ], "log_meta": "false", "log_data": "true", "bucket_index_max_shards": 11, "read_only": "false", "tier_type": "", "sync_from_all": "true", "sync_from": [], "redirect_zone": "", "supported_features": [ "resharding" ] "default_placement": "default-placement", "realm_id": "26cf6f23-c3a0-4d57-aae4-9b0010ee55cc", "sync_policy": { "groups": [] }, "enabled_features": [ "resharding" ]
同期のステータスを確認します。
例
[ceph: root@host01 /]# radosgw-admin sync status realm 26cf6f23-c3a0-4d57-aae4-9b0010ee55cc (usa) zonegroup 33a17718-6c77-493e-99fe-048d3110a06e (us) zone 505b48db-6de0-45d5-8208-8c98f7b1278d (us_east) zonegroup features enabled: resharding
この例では、
resharding
機能がus
ゾーングループに対して有効になっていることを確認できます。オプション: ゾーングループの
resharding
機能を無効にすることができます。Ceph Object Gateway がインストールされているマルチサイトのすべてのゾーングループで、機能を無効にします。
構文
radosgw-admin zonegroup modify --rgw-zonegroup=ZONEGROUP_NAME --disable-feature=resharding
例
[ceph: root@host01 /]# radosgw-admin zonegroup modify --rgw-zonegroup=us --disable-feature=resharding
期間を更新してコミットします。
例
[ceph: root@host01 /]# radosgw-admin period update --commit
関連情報
- 動的なバケットインデックスのリシャーディングの設定可能なパラメーターの詳細については、Red Hat Ceph Storage Object Gateway Configuration and Administration Guide の _ Resharding bucket index dynamically_ セクションを参照してください。
8.3.8. バケットインデックスの手動リシャーディング
バケットが最適化された初期設定よりも大きくなった場合は、radosgw-admin bucket reshard
コマンドを使用してバケットインデックスプールをリシャーディングします。このコマンドは、次のタスクを実行します。
- 指定されたバケットのバケットインデックスオブジェクトの新しいセットを作成します。
- これらのバケットインデックスオブジェクトにオブジェクトエントリーを分散します。
- 新規バケットインスタンスを作成します。
- 新規インデックス操作すべてが新規バケットインデックスを通過するように、新しいバケットインスタンスをバケットとリンクします。
- 古いバケット ID および新しいバケット ID をコマンド出力に出力します。
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- Ceph Object Gateway が少なくとも 2 つのサイトにインストールされている。
手順
元のバケットインデックスをバックアップします。
構文
radosgw-admin bi list --bucket=BUCKET > BUCKET.list.backup
例
[ceph: root@host01 /]# radosgw-admin bi list --bucket=data > data.list.backup
バケットインデックスを再シャード化します。
構文
radosgw-admin bucket reshard --bucket=BUCKET --num-shards=NUMBER
例
[ceph: root@host01 /]# radosgw-admin bucket reshard --bucket=data --num-shards=100
検証
バケットの再シャーディングステータスを確認するには、以下のコマンドを実行します。
構文
radosgw-admin reshard status --bucket bucket
例
[ceph: root@host01 /]# radosgw-admin reshard status --bucket data
関連情報
- 詳細については、Red Hat Ceph Storage Object Gateway ガイド の マルチサイトデプロイメントでのバケットインデックスのリシャーディングの設定 を参照してください。
- バケットインデックスを動的にリシャーディング を参照してください。
- シンプルなデプロイでのバケットインデックスのリシャーディングの設定 を参照してください。
8.3.9. リシャーディング後のバケットエントリーの古いインスタンスのクリーニング
リシャーディングプロセスでは、バケットエントリーの古いインスタンスが自動的に消去されない場合があり、これらのインスタンスはストレージクラスターのパフォーマンスに影響を与える可能性があります。
古いインスタンスがストレージクラスターのパフォーマンスに悪影響を与えないように、手動でクリーンアップします。
古いインスタンスを消去する前に、Red Hat サポート にお問い合わせください。
この手順は、マルチサイトクラスターではなく、単純なデプロイメントでのみ使用してください。
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- Ceph Object Gateway がインストールされている。
手順
古いインスタンスをリスト表示します。
[ceph: root@host01 /]# radosgw-admin reshard stale-instances list
バケットエントリーの古いインスタンスを消去します。
[ceph: root@host01 /]# radosgw-admin reshard stale-instances rm
検証
バケットの再シャーディングステータスを確認するには、以下のコマンドを実行します。
構文
radosgw-admin reshard status --bucket BUCKET
例
[ceph: root@host01 /]# radosgw-admin reshard status --bucket data
8.3.10. 圧縮の有効化
Ceph Object Gateway は、Ceph の圧縮プラグインを使用してアップロードしたオブジェクトのサーバー側の圧縮をサポートします。これには、以下が含まれます。
-
zlib
: サポート対象。 -
snappy
: サポート対象。 -
zstd
: サポート対象。
Configuration
ゾーンの配置ターゲットで圧縮を有効にするには、--compression=TYPE
オプションを radosgw-admin zone placement modify
コマンドに指定します。圧縮 TYPE
は、新しいオブジェクトデータの書き込み時に使用する圧縮プラグインの名前を指します。
圧縮される各オブジェクトは圧縮タイプを保存します。設定を変更しても、既存の圧縮オブジェクトをデプロイメントします。また、Ceph Object Gateway は強制的に既存オブジェクトを再圧縮する訳ではありません。
この圧縮設定は、この配置ターゲットを使用してバケットにアップロードされるすべての新規オブジェクトに適用されます。
ゾーンの配置ターゲットで圧縮を無効にするには、 --compression=TYPE
オプションを radosgw-admin zone placement modify
コマンドに指定して、空の文字列または none
を指定します。
例
[root@host01 ~] radosgw-admin zone placement modify --rgw-zone=default --placement-id=default-placement --compression=zlib { ... "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "default.rgw.buckets.index", "data_pool": "default.rgw.buckets.data", "data_extra_pool": "default.rgw.buckets.non-ec", "index_type": 0, "compression": "zlib" } } ], ... }
圧縮の有効化または無効化後に Ceph Object Gateway インスタンスを再起動して、変更を反映します。
Ceph Object Gateway は デフォルト
ゾーンとプールのセットを作成します。実稼働デプロイメントの場合は、レルムの作成 セクションを最初に参照してください。
統計
既存のコマンドおよび API は、圧縮されていないデータに基づいてオブジェクトおよびバケットサイズを引き続き報告しますが、radosgw-admin bucket stats
コマンドにはすべてのバケットの圧縮統計が含まれます。
radosgw-adminbucket stats
コマンドの使用タイプは次のとおりです。
-
rgw.main
は、通常のエントリーまたはオブジェクトを指します。 -
rgw.multimeta
は、不完全なマルチパートアップロードのメタデータを指します。 -
rgw.cloudtiered
は、ライフサイクルポリシーによってクラウド層に移行されたオブジェクトを指します。restart_head_object=true
で設定すると、データを含まないヘッドオブジェクトが残されますが、それでも HeadObject リクエストを介してオブジェクトのメタデータを提供できます。これらのスタブヘッドオブジェクトは、rgw.cloudtiered
カテゴリーを使用します。詳細は、Red Hat Ceph Storage オブジェクトゲートウェイガイド の Amazon S3 クラウドサービスへのデータの移行 セクションを参照してください。
構文
radosgw-admin bucket stats --bucket=BUCKET_NAME
{
...
"usage": {
"rgw.main": {
"size": 1075028,
"size_actual": 1331200,
"size_utilized": 592035,
"size_kb": 1050,
"size_kb_actual": 1300,
"size_kb_utilized": 579,
"num_objects": 104
}
},
...
}
size
は、バケット内の非圧縮および非暗号化のオブジェクトの累積サイズです。size_kb
はキロバイト単位の累積サイズであり、ceiling(size/1024)
として計算されます。この例では、ceiling(1075028/1024) = 1050
です。
size_actual
は、各オブジェクトが 4096 バイトのブロックのセットに分散されてからの全オブジェクトの累積サイズです。バケットに 2 つのオブジェクト (1 つはサイズ 4100 バイト、もう 1 つは 8500 バイト) がある場合、最初のオブジェクトは 8192 バイトに切り上げられ、2 番目のオブジェクトは 12288 バイトに切り上げられ、バケットの合計は 20480 バイトになります。size_kb_actual
はキロバイト単位の実際のサイズで、size_actual/1024
として計算されます。上記の例では、1331200/1024 = 1300
になります。
size_utilized
は、圧縮または暗号化、もしくはその両方が行われた後のデータの合計サイズ (バイト単位) です。暗号化するとオブジェクトのサイズが増加する可能性がありますが、圧縮するとオブジェクトのサイズが減少する可能性があります。size_kb_utilized
はキロバイト単位の合計サイズで、ceiling(size_utilized/1024)
として計算されます。この例では、ceiling(592035/1024)= 579
です。