Oracle データベースでの Amazon EBS エラスティックボリュームの使用 (パート 3): Oracle ASM を使ったデータベース

このブログシリーズのパート 1 とパート 2 では、Amazon EBS のエラスティックボリューム機能と、Oracle データベースのストレージレイアウトとの連携について説明します。オペレーティングシステムにあるファイルシステムおよび、データベースストレージ管理のための Logical Volume Managers (LVM) を使用するデータベースとのエラスティックボリュームについてお話しします。この記事では、Oracle Automated Storage Management (Oracle ASM) を使った Oracle データベース用 Amazon EC2 のストレージレイアウトについて解説します。可用性に影響を与えずに、データベースストレージを拡張する方法をご紹介します。また、Oracle データベースでエラスティックボリュームを使用する利点について、いくつかを検討します。

Oracle ASM を使用したデータベースのストレージ操作

このセクションでは、ストレージ管理のための Oracle ASM を使用した Oracle データベース用 Amazon EC2 のストレージレイアウトについてまず簡単に説明します。次に、エラスティックボリューム機能が導入される前に、ストレージの増強やプロビジョニングされた IOPS の変更など、Oracle データベースストレージの変更がどのように行われたかについて解説します。関連する課題についてもお話しします。最後に、ある例を参考に、エラスティックボリュームを使って、これらの問題をいくつか解決する方法を示します。

Oracle ASM を使用するデータベース用ストレージレイアウト

Oracle ASM は、Oracle データベース用ストレージを管理するためのボリュームマネージャーです。これには、データベース専用に設計されたファイルシステムが含まれています。Oracle ASM は、ディスク全体にデータを分散し、一貫したパフォーマンスを約束します。また、ディスクの追加や削除などのストレージ構成の変更後に、自動的にデータを再調整することもできます。

Oracle ASM を使用する場合、1 つ以上の ASM ディスクを含む ASM ディスクグループを作成します。ASM ディスクは、EBS ボリュームのようなストレージデバイスです。ASM ディスクグループは、データ、制御、REDO ログファイルといったデータベースファイルを格納する Oracle データベースインスタンスへのファイルインタフェースとして公開されています。Oracle ASM は Oracle ASM インスタンスを使用します。このインスタンスは、ディスクグループの構成および管理に使用される、特殊な Oracle インスタンスです。また、ファイルレイアウト情報を Oracle データベースインスタンスに提供します。Oracle データベースインスタンスは、Oracle ASM インスタンスを経由せずに、ストレージ I/O 操作を直接実行します。

次の図は、Oracle ASM を使用したデータベースレイアウトを示しています。DATA と RECO という 2 つの ASM ディスクグループがあり、それぞれ 5 つと 3 つの ASM ディスク (EBS ボリューム) があります。

エラスティックボリュームのない Oracle データベースのストレージ操作

データベースにプロビジョニングしたストレージまたは IOPS を増やすには、新しい ASM ディスク (EBS ボリューム) を作成します。次の手順で、それらを ASM ディスクグループに追加します。

新しい EBS ボリュームを作成し、それを EC2 インスタンスに添付する
デバイスにプライマリパーティションを作成する
oracleasm createdisk コマンドを使用して、ASM ディスクを作成し、Oracle ASM で使用できるようにする
ALTER DISKGROUP ... ADD DISK コマンドを使用して、ASM ディスクを ASM ディスクグループに追加する

ストレージ構成が変更されると、Oracle ASM は自動的にリバランス操作を開始して、データをディスク全体に均等に分散します。power setting パラメータは、リバランス操作の速度を制御します。ASM_POWER_LIMIT データベース初期化パラメータを使用してデフォルト電力制限を設定するか、または POWER 節 (ALTER DISKGROUP 文の中にある) を使用してデフォルト電力制限を特定することができます。

エラスティックボリュームを使用した、Oracle データベースのストレージ操作

EBS ボリュームを変更するには、AWS CLI の modify-volume コマンド、または AWS マネジメントコンソールの「ボリュームの変更」オプションを使用します。新しいボリュームサイズと IOPS を指定します。

ボリュームサイズは変更せずに、プロビジョニングした IOPS のみを変更した場合、オペレーティングシステムまたは Oracle ASM レベルでの変更の必要はありません。EBS ボリュームのサイズを変更する場合、ALTER DISKGROUP ... RESIZE ALL コマンドを使用して、ASM ディスクのサイズを変更する必要があります。

EBS ボリュームのサイズまたは IOPS を変更すると、データは自動的に複数のバックエンドデバイスに分散されます。このアプローチでは、ホットスポットを回避し、IOPS を確実にプロビジョニングできるようにします。

例 : Oracle ASM を使用するデータベースのストレージを増やす

このセクションでは、ダウンタイムなしで、ストレージ管理用 Oracle ASM を使用し、Oracle データベースにプロビジョニングしたストレージを増やす方法を示します。Red Hat Enterprise Linux 上で動作する Oracle 12c データベースを使用し、実証します。それぞれ 50 GiB の 6 つの EBS ボリュームを EC2 インスタンスに接続しています。これらは ASM ディスクとして Oracle ASM に提示されています。これらの 6 つの ASM ディスクから、合計サイズ 300 GB の ASM ディスクグループ DATA を作成しました。今回のデモンストレーションでは、ダウンタイムなしで、データベースにプロビジョニングしたストレージを、300 GiB から 600 GiB に増やします。

信頼性が高くかつ自動化された方法で、Oracle Database 12c Enterprise Edition を AWS にデプロイするには、Oracle Database on AWS Quick Start を使用します。このデプロイには、ストレージ管理用の Oracle ASM が含まれます。

リサイズがデータベースのダウンタイムなしに実行されたことを示すために、evtestproc というデータベースストアドプロシージャを作成しました。このプロシージャでは、レコードを 10 秒間隔で evtesttab というテーブルに挿入します。このプロシージャは、サイズ変更操作が行われている間に実行されます。レコードが 10 秒間隔で evtesttab テーブルにギャップを置かず挿入されたことを確認することによって、データベースのダウンタイムなしにサイズ変更が行われたことを確認できます。Evtestproc ストアドプロシージャの定義については、このブログシリーズのパート 1 を参照してください。

ステップ 1: 現在の設定を確認する

AWS マネジメントコンソールから、EBS ボリュームのサイズを確認します。現在、6 つの EBS ボリュームの 1 つは、次のスクリーンショットが示すように、50 GiB です。

次に、v $ asm_diskgroup ビューをクエリします。DATA ディスクグループの合計サイズは 300 GB で、次のスクリーンショットに示すように、それぞれ 50 GB の 6 つの ASM ディスク (6 つの EBS ボリュームでバックアップされている) を含んでいます。

次のスクリーンショットが示すように、EVTestTablespace という、250 GB の大きなファイルテーブルスペースを作成しました。

次のスクリーンショットから、DATA と呼ばれる ASM ディスクグループ用にプロビジョニングした 300 GB から、250 GB を少し上回って使用されていることが分かります。

ステップ 2: ストアドプロシージャの設定

Evtestproc ストアドプロシージャを開始して、データベースにプロビジョニングしたストレージを増やしながら、レコードを evtesttab テーブルに挿入します。

begin
  evtestproc();  //PLSQL procedure to insert records into the EVTESTTAB table at 10-second intervals
end;

SQL Workbench からテーブルをクエリして、レコードが挿入されていることを確認します。

ステップ 3: EBS ボリュームのサイズ変更

AWS CLI を使用して、EBS ボリュームのサイズを 100 GiB から 50 GiB に増やしました。

$ aws ec2 modify-volume --region us-west-2 --volume-id vol-0c8a98c35d4126d50 --size 100
{
    "VolumeModification": {
        "TargetSize": 100,
        "TargetVolumeType": "io1",
        "ModificationState": "modifying",
        "VolumeId": "vol-0c8a98c35d4126d50",
        "TargetIops": 2000,
        "StartTime": "2018-03-17T12:53:20.000Z",
        "Progress": 0,
        "OriginalVolumeType": "io1",
        "OriginalIops": 2000,
        "OriginalSize": 50
    }
}

6 つの EBS ボリュームごとに、これを行います。しばらくしてから、AWS CLI を使用して、ボリューム変更要求のステータスを確認します。これで、ボリュームが最適化状態に入ったことがわかり、次のスクリーンショットに示すように、新しいサイズが AWS マネジメントコンソールに反映されます。

$ aws ec2 describe-volumes-modifications --region us-west-2 --volume-id vol-0c8a98c35d4126d50
{
    "VolumesModifications": [
        {
            "TargetSize": 100,
            "TargetVolumeType": "io1",
            "ModificationState": "optimizing", 
            "VolumeId": "vol-0c8a98c35d4126d50",
            "TargetIops": 2000,
            "StartTime": "2018-03-17T12:53:20.689Z",
            "Progress": 0,
            "OriginalVolumeType": "io1",
            "OriginalIops": 2000,
            "OriginalSize": 50
        }
    ]
}

注 : ASM ディスクにマップした EBS ボリュームを判別する必要がある場合は、次の例を参照してください。この例では、DATA1 ASM ディスクにマップした EBS ボリュームを見つける方法を示しています。

この例では Oracleの、ORACLE_HOME のセットアップに使用された OS ユーザーとしてログインします。oracleasm querydisk コマンドを使用して、次のようにデバイスのメジャー番号とマイナー番号を検索します。

[oracle@ip-10-0-0-5 ~]$ /etc/init.d/oracleasm querydisk -d DATA1

Disk "DATA1" is a valid ASM disk on device [202,81]

ディスクのメジャー番号とマイナー番号 (この例では 202 と 81) が表示されたら、次のコマンドを使用して、OS レベルでのデバイス名を探します。

oracle@ip-10-0-0-5 ~]$ ls -la /dev/ | grep 202 | grep 81
brw-rw----. 1 root disk    202,   81 Mar 16 01:37 xvdf1

出力からわかるように、/dev/xvdf1 は OS レベルでのデバイス名です。/Dev/xvdf1 にアタッチされた EBS ボリュームは DATA1 ASM ディスクに対応します。

ステップ 4: EBS ボリューム上のディスクパーティションのサイズ変更

ASM ディスクグループにディスクを追加する時は、oracleasm createdisk コマンドを使用してディスク上にパーティションを作成します。また、このコマンドを実行すると、Oracle ASM でパーティションを使用できるようになります。Oracle ASM が新しいサイズを認識する前に、パーティションのサイズを変更する必要があります。次の手順で、パーティションをオンラインでサイズ変更することができます。ディスクパーティションのオンラインでのサイズ変更についての詳細は、Red Hat Enterprise Linux ナレッジベースの記事を参照してください。

図のようにパーティションのサイズを変更するには、fdisk コマンドを使用します。

[root@ip-10-0-0-5 ~]# fdisk /dev/xvdf
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): d
Selected partition 1
Partition 1 is deleted

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): 
Using default response p
Partition number (1-4, default 1): 
First sector (2048-209715199, default 2048): 
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-209715199, default 209715199): 
Using default value 209715199
Partition 1 of type Linux and of size 100 GiB is set

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

オンディスクパーティションテーブルは更新されていますが、オンメモリカーネルパーティションテーブルはまだ新しいサイズで更新されていません。Partx コマンドを使用して、次のように、オンディスクパーティションテーブルからインメモリカーネルパーティションテーブルを更新します。

[root@ip-10-0-0-5 ~]# partx -u /dev/xvdf

前述の手順を繰り返して、6 つの EBS ボリュームすべてのパーティションのサイズを変更します。

最後に、次のスクリーンショットに示すように、v $ asm_diskgroup ビューをクエリし、ASM ディスクが新しいサイズ (100 GB) を反映していることを確認します。

ステップ 5: データベースストレージの増強

次のスクリーンショットに示すように、ビッグファイルのテーブルスペースを 500 GB にリサイズすることで、使用可能なデータベースストレージを増やすことができます。

次のスクリーンショットから、DATA ASM ディスクグループ用にプロビジョニングした 600 GB から 500 GB を少し上回って使用されていることが分かります。

ステップ 6: ストレージがリサイズされている間に、データベースのダウンタイムがなかったことを確認する

Evtesttab テーブルをクエリして、PL/SQL プロシージャの実行が途切れていないことを確認します。さらに、次のスクリーンショットに示すように、10 秒間隔でギャップを置かずレコードが挿入されていることを確認します。

この例では、データベースの可用性に影響を与えずに、ストレージ管理に Oracle ASM を使用する Oracle データベースに割り当てられたストレージを増やす方法を示します。データベースの可用性やパフォーマンスに影響を与えずに、エラスティックボリュームを使用して、データベース用にプロビジョニングした IOPS を変更することもできます。加えて、データベースの可用性やパフォーマンスに影響を与えることなく、エラスティックボリュームを使用して、EBS ボリュームタイプを変更する (例えば io1 から gp2 へ) こともできます。

エラスティックボリュームを使用する利点

容易なメンテナンス – エラスティックボリュームを使用すると、シンプルな API 呼び出しを用いて、ダウンタイムやパフォーマンスに影響を与えることなく、プロビジョニングしたストレージを簡単に増やすことができます。同様に、エラスティックボリュームを使用すると、シンプルな API コールを用いて、ダウンタイムやパフォーマンスに影響を与えることなく、データベース用にプロビジョニングした IOPS を簡単に調整できます。また、これらの操作を自動化することも可能です。
予測可能なスパイクのあるワークロード – ワークロードの中には、月末処理のように、あらかじめ決められていて、容易に予測可能なスパイクがあります。エラスティックボリュームを使用すると、スパイク中にデータベース用にプロビジョニングした IOPS をダイアルアップし、その後にダイヤルダウンすることができます。これにより、データベースのパフォーマンス要件を満たし、同時にコストを最小限に抑えることができます。
コストの削減 – EBS io1 ボリュームは最高のパフォーマンスを提供できますが、価格とパフォーマンスのバランスがよい gp2 ボリュームに比べて高価です。主に平日に使用するデータベースの場合は、週末の間にプロビジョニングした IOPS をダイヤルダウンしてコストを削減できます。同様に、コストを削減するために、週末にボリュームタイプを io1 から gp2 に変更できます。

次の例で、潜在的なコスト削減を見てみましょう。

米国東部 (オハイオ) リージョンにデプロイしたデータベースがあり、ストレージ要件が 1 TB、ピーク IOPS 要件が 30,000 であるとします。データベースは主に平日 (月曜日〜金曜日) にアクセスされ、週末 (土曜日〜日曜日) には最小限の使用率です。

データベースストレージに、月を通して io1 ボリュームのみを使用する場合、EBS の料金は次の表に示すように月額 2075 USD です。

	プロビジョンした	Io1 ボリュームの EBS 料金 *	月額費用
ストレージ	1 TB	GB- 月あたり 0.125 USD	125 USD
IOPS	30000	プロビジョニングした IOPS- 月あたり 0.065 USD	1950 USD
総月間 EBS 料金			2075 USD

* 執筆時点では、米国東部 (オハイオ) リージョンでの料金です。

同じ構成 (io1 ボリュームではなく gp2 ボリューム) では、次の表に示すように、月額 100 USD　かかります。

	プロビジョンした	gp2 ボリュームの EBS 料金 *	月額費用
ストレージ	1 TB	GB- 月あたり 0.10 USD	100 USD
総月間 EBS 料金			100 USD

* 執筆時点では、米国東部 (オハイオ) リージョンでの料金です。

データベースは、週末にはほとんどアクセスされません。したがって、週末 (2 日間) に gp2 ボリュームに切り替えたり、平日 (5 日間) に io1 ボリュームに戻ったりしてコストを節約するのに、エラスティックボリュームを使用できます。

このシナリオでは、io1 ボリュームタイプと gp2 ボリュームタイプを切り替えることにより、毎月の EBS 料金は、次の表に示すように 1512 USD に削減されます。これは、io1 ボリューム (月額 2075 USD) のみを使用する場合と比較して、毎月 27% の節約となります。

ボリュームタイプ	月額費用	1 ヶ月に使用した割合	最適化した月額コスト
IO1	2075 USD	7 日中 5 日、または時間の 71.5％	1483.6 USD [2075 USD の 71.5％]
GP2	100 USD	7 日中 2 日、または時間の 28.5％	28.5 USD [100 USD の 28.5%]
月額費用総額			1512.1 USD

本番問題のデバッグ – 本番環境でデータベースパフォーマンスの問題に遭遇したとします (例えば、アプリケーションのパッチリリースやアプリケーションのバージョンアップ後)。この場合、エラスティックボリュームを使用して、問題をデバッグし特定するまで、データベース用にプロビジョニングした IOPS を一時的に増やすことができます。問題が解決したら、IOPS を通常のレベルにダイヤルダウンできます。この操作は、アプリケーションやデータベースのダウンタイムなしに簡単に実行できます。
パフォーマンステスト – 機能テストとパフォーマンステストに、同じ QA 環境を使用できます。例えば、gp2 ボリュームを使用して、ストレージコストを最適化するように QA 環境を設計できます。パフォーマンステストの場合、パフォーマンステストの実行中は、ストレージタイプを gp2 から io1 に変更するだけです。完了後、もう一度 gp2 に戻すことができます。このアプローチにより、パフォーマンステストのために機能テスト環境をクローンする必要がなくなり、同時にコストを節約できます。

まとめ

Amazon EBS のエラスティックボリューム機能を使用すると、ボリュームの使用中に、ボリュームサイズを増やしたり、IOPS を変更したり、ボリュームタイプを変更することができます。3 部に分かれたこのブログ記事では、データベースの可用性やパフォーマンスに影響を与えずに、Amazon EC2 上で実行する Oracle データベースのストレージを拡張する方法を説明しています。コスト削減など、Oracle データベースでエラスティックボリューム機能を使用することのさまざまな利点についても解説しています。

エラスティックボリュームの詳細については、Amazon EBS のドキュメントを参照してください。

著者について

Ashok Shanmuga Sundaram はアマゾンウェブサービスのグローバルシステムインテグレーター (GSI) チームのパートナーソリューションアーキテクトです。GSI と協力して、エンタープライズクラウドの採用、移行、戦略に関するガイダンスを提供しています。

Ejaz Sayyed はアマゾンウェブサービスのグローバルシステムインテグレーター (GSI) チームのパートナーソリューションアーキテクトです。主に取り組んでいる分野は、AWS データベースサービス、AWS 上のデータベースおよびデータウェアハウスの移行です。

Nael Haddad はアマゾンウェブサービスのElastic Block Store (EBS) チームのシニアプロダクトマネージャです。複数の EBS 製品の新機能に関する取り組みを行っています。

Amazon Web Services ブログ