※本ページは、”Exadata and ASM Auto Rebalance“の翻訳です。
はじめに
Oracle Exadataは、AI、オンライン・トランザクション処理（OLTP）、分析を含むOracle Databaseワークロードに対して最適化された性能を提供するよう設計されたエンジニアド・データベースプラットフォームです。Exadataはデータ最適化プラットフォームであり、高性能なコンピュートサーバ、インテリジェントなストレージサーバ、そして低レイテンシなデータアクセスを実現するRemote Direct Memory Access（RDMA）対応の高速ネットワークを統合しています。その結果として得られる極限のパフォーマンスは、リソース効率を向上させ、あらゆるワークロードのスケーラビリティと統合を可能にします。Oracle Exadataはリソーススタック全体で高可用性を重視しており、特にストレージ層に重点を置いています。継続的なデータアクセス性を確保するため、Exadataのアーキテクチャでは少なくとも3台のストレージサーバが必要です。この構成により、ストレージサーバ間でのデータストライピングとミラーリングが可能となり、ハードウェア障害リスクを軽減します。本記事では、ディスク障害やストレージサーバ追加統合など、重要なインフラ事象の際にExadataがどのようにデータ冗長性とシステム整合性を維持するのかを解説します。
リバランスとは？
Exadata環境のスケーリングには、単にハードウェアを追加するだけでなく、利用可能なリソースを効率的かつ均等に活用することが求められます。特にストレージ層ではその重要性が高くなります。ASMリバランスは、データエクステントを利用可能なすべてのディスクに再分散することでこれを実現します。RoCEファブリックを介してストレージサーバ間でI/Oを並列化することは、Exadataにおける主要な性能向上要因です。ワークロードをすべてのストレージサーバへ均等に分散することで、安定した低レイテンシと高可用性を実現し、Oracle RACクラスタ全体が最大限の性能を発揮できるようになります。リバランス操作は、次のいずれかのシナリオでトリガーされます。
- ハードディスクの障害および交換
- セルのローリングアップグレード中のハードディスクリシンク
- 既存クラスタへのセル追加
- フラッシュ障害後の再ミラー（リシルバリング）
- ASM Scrubが破損したエクステントを検出し修復する場合
- 既存クラスタからのストレージサーバー削減
ASM Redundancy
Oracle Database管理の世界では、Automatic Storage Management（ASM）の冗長性（redundancy）はレジリエントなインフラストラクチャの要です。ASMは、複数の障害グループにまたがってデータエクステントをミラーリングすることで、ディスク障害が発生した場合でも環境が稼働し続けることを保証します。ノーマル冗長性 (Normal Redundancy)（2重ミラー）を採用する場合でも、高冗長性（High Redundancy）*（3重ミラー）を採用する場合でも、目的は同じです。すなわち、ストレージ層における単一障害点を排除することです。冗長性レベルの選択では、ストレージコストとダウンタイムのバランスを考慮する必要がありますが、データ保護が最重要となるエンタープライズ環境では高冗長性が推奨されます。
*Oracleは、最大限のデータ保護とアプリケーション可用性を確保するため、Exadataでは高冗長性（3重ミラー）を推奨しています。（推奨）
何故リバランスが必要なのでしょうか？
Exadataでは、リバランスは通常、前述のような構成変更によってトリガーされます。Exadataはインテリジェントなストレージサーバに依存しているため、データ分散に偏りがあると、一部のサーバだけに負荷が集中し、クエリ応答時間のばらつきにつながる可能性があります。例えば次のようなケースです。
- 容量追加：新しいストレージサーバやディスクを追加すると、リバランスにより既存データが新しいハードウェアへ移動され、全体スループットが向上します。
- 障害対応：ディスクまたはストレージサーバ全体が故障した場合、ASMは冗長ミラーを用いて残存する健全なディスク上にデータを再構成します。
- メンテナンス：パッチ適用のためにストレージセルを安全にオフラインへ移行する必要がある場合、「drop」または「offline」操作によってリバランスがトリガーされ、データ保護が維持されます。
ASMリバランスはどのように実行され、管理されるでしょうか？
リバランスを開始し制御する方法は、大きく分けて自動と手動の2つがあります。
デフォルトでは、ASMはディスクが追加・削除（ドロップ）された場合、またはオンラインに復帰した場合にリバランスを開始します。この処理速度はASM_POWER_LIMITによって制御されます。
ALTER DISKGROUP data_group REBALANCE;ASM_POWER_LIMIT：性能を損なわずにリバランスをスケール
ASMリバランスはASM_POWER_LIMITパラメーターによって制御できます。ASM_POWER_LIMITが大きいほど、リバランス処理により多くのI/Oリソースが割り当てられます。リバランス処理は、本来データベースI/Oを支えるはずのシステムリソースを消費します。このため、管理者はASM_POWER_LIMITパラメーターを調整し、リバランス速度とアプリケーション性能のバランスを取ることができます。ASM_POWER_LIMITを増やすとデータ再分散は高速化されますが、ピーク負荷時のI/Oスループットへの影響を慎重に考慮する必要があります。
ASM_POWER_LIMIT表：
| ASM_POWER_LIMIT | 指向 | 挙動 |
| 1 – 8 (Lower limit) | データベース性能優先 | データベースI/Oへの影響は最小限。リバランスには時間がかかりますが、ユーザーのクエリやトランザクションがI/O時間のほぼ100%を利用できるようにする。 |
| 9 – 31 (middle ground) | バランス | 手動リバランス操作では、多くの管理者にとってここが「スイートスポット」。低いレンジよりも多くの並列プロセスを利用することで、データベースを完全に圧迫することなく、より高速なリバランスを実現。 |
| 32 – 1024 (Higher limit) | リバランス性能優先 | データ移動のスループットを最大化。通常、メンテナンスウィンドウ中やディスク障害後に、できるだけ早く冗長状態へ復帰させたい場合に使用。 |
プロのヒント：Exadata環境では、メンテナンスウィンドウ中にASM_POWER_LIMITを高めに設定し、業務時間帯にはALTER DISKGROUPコマンドで動的にに低い値へ戻す運用が一般的です。
アクティブなリバランス操作を監視する方法
ASM_POWER_LIMITパラメータは、ASMリバランスが消費するI/O帯域幅を制御します。データベースI/Oとの競合を防ぐため、これらの手動操作は綿密に監視することが重要です。アクティブなリバランスタスクの進捗およびリソース消費を追跡するには、以下のSQLクエリを使用してください。
SELECT g.name AS diskgroup, o.state, o.power, o.actual, o.pass, o.est_work AS total_au_to_move, o.est_rate, o.est_minutes FROM v$asm_diskgroup g, v$asm_operation o WHERE g.group_number = o.group_number;| DISKGROUP | OPERATION | STATE | POWER | PASS | EST_WORK | EST_RATE | EST_MINUTES |
| DATA_C1 | REBAL | RUN | 32 | REBALANCE | 845,200 | 12,500 | 67 |
| RECO_C1 | REBAL | WAIT | 32 | COMPACT | 112,000 | 0 | 0 |
- STATE：STATEがWAITの場合、そのグループの作業はまだ計算されていません
- EST_WORK：この操作で移動が必要なAU（割り当てユニット）の総数
- EST_RATE：1分あたりに移動されるAU数
- POWERとACTUAL：POWERは要求した値、ACTUALはASMが現在実際に使用している値（システムのI/O負荷が高い場合、ACTUALが低くなることがあります）。
この出力は、リバランス操作がディスクグループ間で直列に実行されていることを示しています。この逐次的なアプローチにより、バックグラウンドのデータ移行がデータベースI/Oと競合することを防ぎ、アプリケーション性能が維持されます。
CellCLIを使用した物理ディスクの監視
Exadataを利用する利点の1つは、CellCLI管理ユーティリティを使用してストレージサーバ上のアクティビティを詳細に監視できることです。いずれかのストレージセルにcelladminユーザーとしてログインし、ASMがデータを移動している間にハードウェアが想定どおりに動作していることを以下のコマンドを使用して確認できます。
- 物理ディスクのステータス確認
これにより、リバランスのボトルネックになり得る「Predictive Failure」または「Poor Performance」状態の物理ドライブが存在しないことを確認できます。
CellCLI> LIST PHYSICALDISK ATTRIBUTES name, status, diskType;
0:0 normal HardDisk
0:1 normal HardDisk
0:2 normal HardDisk
0:3 normal HardDisk
0:4 normal HardDisk
0:5 normal HardDisk
0:6 normal HardDisk
0:7 normal HardDisk
0:8 normal HardDisk
0:9 normal HardDisk
0:10 normal HardDisk
0:11 normal HardDisk
FLASH_1_1 normal FlashDisk
FLASH_1_2 normal FlashDisk
FLASH_3_1 normal FlashDisk
FLASH_3_2 normal FlashDisk
FLASH_6_1 normal FlashDisk
FLASH_6_2 normal FlashDisk
FLASH_8_1 normal FlashDisk
FLASH_8_2 normal FlashDisk
M2NVME_SYS_0 normal M2Disk
M2NVME_SYS_1 normal M2Disk- セルディスクのアクティビティ監視
これにより、「リバランス」負荷がセルディスク全体に均等に分散されているかを確認できます。
CellCLI> LIST CELLDISK ATTRIBUTES name, status, freeSpace;
CD_00_scaqaw13celadm07 normal 1.50439453125T
CD_01_scaqaw13celadm07 normal 1.50439453125T
CD_02_scaqaw13celadm07 normal 1.50439453125T
CD_03_scaqaw13celadm07 normal 1.50439453125T
CD_04_scaqaw13celadm07 normal 1.50439453125T
CD_05_scaqaw13celadm07 normal 1.50439453125T
CD_06_scaqaw13celadm07 normal 1.50439453125T
CD_07_scaqaw13celadm07 normal 1.50439453125T
CD_08_scaqaw13celadm07 normal 1.50439453125T
CD_09_scaqaw13celadm07 normal 1.50439453125T
CD_10_scaqaw13celadm07 normal 1.50439453125T
CD_11_scaqaw13celadm07 normal 1.50439453125T
FD_00_scaqaw13celadm07 normal 0
FD_01_scaqaw13celadm07 normal 0
FD_02_scaqaw13celadm07 normal 0
FD_03_scaqaw13celadm07 normal 0- アクティブなアラートの確認
リバランスが想定より遅い場合、温度上昇やハードウェア障害によりセルがI/Oをスロットリングしていないか確認してください。
CellCLI> LIST ALERTHISTORY WHERE severity like ‘warning|critical’;| 3_1 | 2025-12-08T22:29:11-08:00 | critical | The prerequisite check for the update 25.2.90.0.0.251203 failed. |
| 4 | 2025-12-10T00:33:38-08:00 | warning | type=AVC msg=audit(1765355618.282:152): avc: denied { transition } for pid=19299 comm=rpm path=/usr/bin/bash dev=md24p6 ino=25168754 sco ntext=system_u:system_r:ker nel_t:s0 tcontext= system_u: system_r:rpm_script_t:s0 tclass=process permissive=1 |
Exadataリバランスの重要メトリクス
ASMリバランス中、Exadataは移動中データとフラッシュキャッシュを同期させることで、パフォーマンスの一貫性を維持します。エクステントが新しい物理ディスクへ移行する際、システムは関連するキャッシュ済みデータを移行先セルの対応するフラッシュキャッシュへ自動的に移行し、「ホット」データが即座にアクセス可能な状態を保ちます。セル自体でリバランスの具体的なI/Oスループットを監視できます：
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME, DESCRIPTION WHERE OBJECTTYPE = GRIDDISK;| Metric Name | Description |
| GD_IO_BY_R_LG_SEC | Large reads per second (typically rebalance traffic) グリッド・ディスクから大きいブロックを読み取るときの1秒当たりの読取りMB数。 |
| GD_IO_BY_W_LG_SEC | Large writes per second. グリッド・ディスクに大きいブロックを書き込むときの1秒当たりの書込みMB数。 |
| CL_CPUT | CPU Utilization; if this is near 100%, the rebalance power should be lowered depending on the active workloads currently running on the system. Use the ASM_POWER_LIMIT table above. CPU使用率：これが100%近い場合、システム上で現在稼働中のアクティブなワークロードに応じてリバランスパワーを下げる必要があります。上記のASM_POWER_LIMIT表を参照してください。 |
Exadataにおける自動リバランスのフレームワーク
リバランスがなぜ不可欠かを理解することは第一歩にすぎず、それを効果的に管理するには重要メトリクスの継続的な監視が必要です。ASM_POWER_LIMITを高く設定すると大きな帯域幅を消費し得るため、管理者は再分散の速度と稼働中データベース環境のI/O要件のバランスを取らなければなりません。ASM_POWER_LIMITを上げればリバランスは加速しますが、稼働中のデータベースI/Oに影響を与える可能性があります。逆に、ASM_POWER_LIMITを下げるとリバランスの所要時間は長くなります。管理者は通常、データベースI/OとリバランスI/Oのバランスを取るために、監視しながらASM_POWER_LIMITを変更します。管理者がより重要な作業に集中できるよう、Exadata System Software 25.1では自動リバランスフレームワークが導入されました。この機能は、データベースI/Oを事前に保護しつつ、リバランス速度を最大化するようにasm_power_limitを動的に調整します。ExadataシステムソフトウェアはデータベースI/Oを継続的に監視し、データベースI/O性能を保護しながらASMのパワーリミットを自動調整します。Grid Infrastructure 26aiは、最適なASM_POWER_LIMITを得るためにExadataストレージサーバをポーリングし、リバランス速度を動的に調整します。この機能では、Oracle Exadata System SoftwareがI/O性能を継続的に監視し、利用可能なI/O帯域幅が十分にある場合はasm_power_limitの値を自動的に引き上げます。同様に、クライアントのデータベースワークロードを検知すると、それらのワークロードを優先するためにasm_power_limitの値を自動的に引き下げます。
まとめ
さまざまなシナリオにおけるリバランス管理は、もはや手動でのトレードオフ調整を必要としません。Exadata System Software 25.1の自律機能により、システムはリアルタイムのワークロード需要に基づいてリバランス操作を自己調整できるようになりました。これにより、データ再分散はデータベースSLAを保護しつつ可能な限り迅速に完了し、その性能向上は上図にも明確に示されています。Oracle Exadataの自動リバランスメカニズムは、データ移動経路を最適化することで、手動介入を大きく上回る性能を発揮します。主要な性能ベンチマークとして、ディスク障害後にフル冗長へ戻るまでが3.6倍高速化、メンテナンスウィンドウ中の再同期（resync）操作が2倍高速化、さらに新しいストレージノードを追加してインフラをスケールアウトする際の再分散効率が2.6倍向上しています。
最終的に、ASM Auto Rebalanceの導入は、自律的なストレージ管理への大きな転換点を示します。手動介入を不要にし、管理スピードとアプリケーション安定性の従来のトレードオフを解消することで、このフレームワークはExadata環境の高可用性と一貫した高性能を確保します。この自動化は運用ワークフローを簡素化するだけでなく、ワークロード需要が変動する状況下でもプラットフォームが最大効率を維持できる能力をさらに強化します。